一般的なツクラーのプログラミングスキルはどれぐらい?

リンク

ユーザー
一般的にツクラーと言われる人のプログラミングのスキルというのはどれぐらいだと思いますか?
また僕自身のプログラミングスキルも、一般的にどれぐらいと言えるのでしょうかね?

現在、MVでは数多くのプラグインがリリースされており、RPGツクールMVの限界を超えた物が数多くあります。
そして、プラグインを上手に活用した良作も色々と出ているようです。

ただ、残念なことにプラグイン・スクリプトの構造とか作り方とかを調べたのですが、理解に至りませんでした。
一応言語はJavaScriptとのことで、一応昔HTMLを手打ちしてWebページを制作していた経験はあったので、読解してみようと思ったのですが、正直なところ全く別物にしか見えず、理解できませんでした。
にも関わらず、プラグインは大量にリリースされていますし、よくこんなの理解できるなと僕は不思議に思っています。
VXのRubyの時にも同じことを思いましたがね。

でもって、PCのVXもMVも敷居が高く感じ、一時的にちょっといじりましたが、結局スクリプト系を中心に全機能を理解することができず、CS用であるフェス、ツクトリ、の方に逃げ込みました。
流石に他作のアセットを内容がよく分かってないまま使うのも抵抗がある、アセットのコンフリクトが怖い、プラグインの仕様と自分の細かい作法ややりたいこととに差がある、などで他作のアセットに気軽に手を出すのも心配で、それはできませんでした。

で、フェスでゲームを作っていた時のことです。

今はサービス終了しましたが、当時はMiiverseという任天堂公式掲示板があり、フェス板もありました。
そこがフェスに特化した、ちょうどここツクールフォーラムみたいに製作にまつわる疑問などを質問・回答する場になっていました。

そこにこんな質問がなされていました。
「アイテムAをXX個持ってきたら、アイテムBに交換してくれるというイベントはできませんか?」
という物です。
いわゆる、錬金・調合にあたる物ですね。
僕も当時調合のあるゲームを作りたかったので、気になっていたことでしたので、印象に残っています。

フェスの場合、これを作るにあたって問題となる制約があります。
  1. アイテムの個数を直接知る為の機能がない
  2. アイテムの有無判定のみならばイベントページ条件に設定可能
  3. イベント動作の分岐は、ページ切替のみであり、条件分岐命令は無い
  4. イベントページ条件が2種類までしか設定できない
  5. フェスにあるのはマップイベントのみで、コモンイベントは無い
  6. MVにある様なアイテム選択ウインドウなどは無い
その制約の為か、錬金調合に関してはフェスでは以下の様な扱いが定説になっていました。
この手の質問が来る度に、以下の様なやり取りがなされていました。
  • 入手状況を管理できるイベントアイテムであれば、廃棄・売却不能にしておくという条件で、入手・消滅時に別途変数でアイテムの個数をカウントすれば可能である
  • イベントページ条件が2つまで設定でき、アイテムの有無のみは判定可能なので、2種類のアイテムを1個ずつという条件であれば、全てのアイテムで錬金調合が可能である(これは公式ガイドブックにも制作例が記載されていました)
  • 入手状況が管理不能な購入・売却可能アイテムやドロップアイテム複数個を錬金調合することは不可能である
しかしながら僕が色々な方法を思案しているうちに、あらゆるアイテムで錬金調合が可能な方法があることを発見しました。
ゲームとしての操作性はかなり劣悪になりますし、作るのも非常に面倒な処理にはなりますが、不可能ではありませんでした。
実際に自作ゲームに取り入れましたが、動作に問題はありませんでした。

まず、アイテム選択ウインドウは無いので、錬金調合の公式の数だけ、調合師役のイベントNPCが必要です。
その上で以下の処理を行います。
  1. (決定ボタン)調合元のアイテムの1個目を所持しているか、いないかを判定する
  2. 所持していないなら終了する
  3. 所持している場合、そのアイテムを1つ減少させ、「調合カウンタ」変数にオフセット値(以下処理内でバッティングしない数値)を代入する(ここではオフセット値は1とする)
  4. (自動実行)「調合カウンタ」=1の場合、調合元アイテムの2個目を所持しているか、いないかを判定する(それぞれの開始条件のイベントページを作る)
  5. 所持していない場合、3.で減少させたアイテムを1つ増加(元に戻す)させ、「調合カウンタ」=0を代入し、終了する
  6. 所持している場合、調合元アイテムの2個目を1つ減少させ、「調合カウンタ」=2を代入(インクリメント)する
  7. (自動実行)「調合カウンタ」=2の場合、調合元アイテムの3個目を所持しているか、いないかを判定する
  8. 所持していない場合、3.と6.で減少させたアイテムを1つずつ増加させ、「調合カウンタ」=0を代入し、終了する
  9. 所持している場合、調合元アイテムの3個目を1つ減少させ、「調合カウンタ」=3を代入する
  10. 7〜9を必要回数分、マップイベントやイベントページを作り、同様に処理を繰り返す
  11. (自動実行)「調合カウンタ」の数値を参照し、調合元アイテムが滞りなく規定数まで減少できたら、調合先アイテムを1つ増加(入手)させ、「調合カウンタ」=0を代入して、調合処理を停止させる
これで、アイテム所持数の取得に制約のあるフェスでも錬金調合をすることが可能です。
要はアイテムの個数を数える=1個ずつアイテムを減じながらその回数分所持判定する。
各動作は変数をインクリメントして、自動実行イベントを変数とアイテムをトリガーにしてドミノ倒しの様に動かす。
だけどこの方法があると言い出した人は、知る限りMiiverseでは一切お見掛けしませんでした。

他にプログラミング素養が必要そうなものと言えば、ツクトリのミニゲームに神経衰弱を組み入れました。
ミニゲーム中の12箇所の草むらを調べると、宝箱が現れる。
偶数番目に調べた宝箱の色が、一つ前に調べた宝箱の色と同じなら1点、違ったら残機が1つ減り、両方の宝箱は草むらに戻ってしまう。
というルールです。

プレイして貰った人曰く、神経衰弱の正解には数パターンあって、予め隠し宝箱が並んでいるマップをランダムに切り替えることでそれを実現している、と思われてる方が結構いらっしゃいました。
例えばマリオ3の神経衰弱には正解パターンがあったので、これと近いアルゴリズムを想定したかと思われます。
で、何パターンあるんだろう?という攻略質問もありました。

でも実はその方法ではありません。
ミニゲームのマップデータは1つだけです。
で、この隠し宝箱はミニゲーム開始前に「ランダム」に並べ替えており、パターンは存在しません。

この並べ替え処理にプログラミング的な方法を使いました。
内心、配列変数があればどんだけ楽かと作りながら思いました。
  1. 変数を12個2組用意しておく。(前者をA[]、後者をB[]という配列表記にします。また配列の添字の開始値は普通はプログラミングだと0なんでしょうけど、ここでは分かりやすさを考え1にします)
  2. A[]に、1〜12の数値を昇順に代入する(A[1]=1、A[2]=2...A[12]=12)
  3. 1〜12の乱数を求め、それを変数Xとする
  4. B[1]=A[X]を代入する
  5. A[X]=A[X+1]...A[11]=A[12]まで代入する(さっき配列Bに代入した配列Aの数値を、一つずつ後ろから前にずらす)
  6. 1〜11の乱数を求め、同様にXに代入する
  7. B[2]=A[X]を代入する
  8. 5.から7.までをB[12]が決まるまで繰り返す
  9. B[]に重複のない1〜12の乱数列ができるので、これに従って隠し宝箱を並び替える
  10. お膳立てが終わったら、フェードインしてミニゲームをスタートさせる
こんな感じです。

まあ一応これぐらいのことができますが、スクリプトは1ミリも理解できませんでした。
でもプラグインやスクリプトを至極活用したり、アセットを製作されたりする方がいっぱいいます。
でも上でやったことを「高度なことしてる」と言ってくれるツクラーさんもたくさんいます。

そんな訳で、ツクラーさんの一般的なプログラミングってどれぐらいなのでしょうか?
僕自身の場合はどうだと思いますか?
 

温州みかん

ユーザー
Cをかじった程度です。ポインタ(*)の処理がイミフで、そこで妥協しました。

JavaScriptはコマンドを追っていったら、書いてあることがなんとなく予想できる程度です(たぶんこうだろうな、と)。
どうしてそういうコマンドが必要なのかはよくわからない人です。
fanction(){ も何も考えず、これはプラグインの書き出しに書く お約束の言葉なんだ main() みたいなものだ、と勝手に解釈しました。
プラグインの改造やそれを見本に組むことはできますが、ゼロから作ることはできません。

ツクールでは、フロー管理のため、変数(スイッチ)とループ処理、分岐の概念が必須です。
そう考えると、ツクラーはすべからくプログラムの基礎を理解している、と言えます。

どうでもいいことですが、i++; というコマンドを見ると、この人はC畑出身なのかなと妄想してしまいます。
変数は i int の i
 

ゼゼゼ

ユーザー
書籍とネットの学習サイトを使い、ツクール用にRubyとjavascriptをかじった程度ですね。
基礎的なことは学んだつもりですが、一からプラグインやスクリプトを作るのは夢のまた夢です。
その基礎に関しても、付け焼き刃なのですぐに忘れてしまいましたし。

ただ、ネットで調べながら試行錯誤をすることで、簡単なものならプラグインやコアスクリプトを改造することは可能です。
以前成功したのだと、とあるプラグインを特定のスイッチがオンの時だけ動作するように改造したことがあります。
 
「ほぼ0」です。言い訳すると多分これは自分だけではないと思います。
そもそも「プログラミング知識が無くてもゲームが作れる」がツクールのコンセプトと思っています。

筋道を順序立てて考えるという「プログラミング思考」はむしろ必須だと思っていますが、言語などの「プログラミング知識」は
(もちろんあった方がいいですが)無ければ無いでどうにかなる。これがもしも「無いとお話にならない」レベルになってしまったら、
それこそツクールの基本コンセプトが崩れてしまうと思うのです。そういう意味でも一般ツクラーさんのプログラミング知識は
非常に身勝手な物言いですが0に近い人が多くあってほしい、プログラミング知識無い人お断りにはならないで欲しい、と強く願います。

ツクールでプログラミング教育的なゲームも作ってみましたが、「プログラミング知識が0でもプログラミング思考が学べる」として
ツクールとプログラミング教育の相性が抜群にいいから、という理由もありました。
 

しぐれん

ユーザー
ツクール2000時代にYADOTというサイトを参考に自作戦闘を1回組んだあとに、専門学校でC言語・直後にC++を使えるようになったぐらいです。
その時の知識をベースに現在もプラグインを作成しています。

リンクさんの書き込みを見る限り、アルゴリズムを組む能力はあると思います。

ツクールでプラグインを書こうとする場合、以下の壁があると考えられます。
  • 構造化プログラミングの壁
    イベントコマンドとプログラミング言語の相互変換ができているかどうかです。
    「構造化プログラミング」という概念があり、逐次実行(上から下へ処理する事)・分岐(if文による条件分岐)・繰り返し(forなどによるループ)の3つがあれば理論的にすべてのプログラムが記述できます。
    イベントコマンドに無くてプログラミング言語にある物となると、関数の戻り値でしょうか。
  • JavaScript文法の壁
    プログラミング言語の翻訳するのとは別に、JavaScriptの文法の壁があります。
    ただ、構造化プログラミングの壁と近い位置なので同じには見えます。
  • オブジェクト指向の壁
    これは本職のプログラマでも超えられない人がいますが、「thisって何?」となる問題です。
    (JavaScriptのthisには落とし穴があることはここでは無視します)
    慣れないうちは全ての変数がグローバル変数としてどこかに実態を持つと考えがちです。
    実際ツクールの変数も根っことなるグローバル変数はありますが、それを意識しないで書くことができます。
    その上でオブジェクトのメソッドを呼び出す(actor.addState()とか)ことの意味が理解できるかどうか。
  • ポインタ・参照の壁
    オブジェクト指向の壁のすぐ近くにある壁です。
    オブジェクト指向で書くとなるとポインタ・参照の概念が必要です。
  • API・ライブラリの壁
    コアスクリプトのメソッドに何があるかの壁です。
    ただ、全てを覚えるのは難しいので入力補完ファイルを利用して、楽をしましょう。
    ツクールMV 入力補完で検索すると、設定方法が出てきます。
分解するとこのぐらいの壁があります。
そして、理解ができない時はどの壁で悩んでいるかもわからないのです。
ただ、私はこれまでに知識0に近い領域から自力でプラグインを書くレベルまでに短期間で成長したのを見てきました。
適切な指導者がいる環境であれば、確実に伸びます。
Twitterで適当に質問を投げると、詳しい人が答えてくれますよッと。
 

リンク

ユーザー
「ほぼ0」です。言い訳すると多分これは自分だけではないと思います。
そうなんですね。

でもその割にMVには沢山のプラグインが出回っていますし、それらを上手に使いこなした作品が多く見られます。
一体どうしてなのでしょう。

残念ながらプラグイン、スクリプト絡みに関しては、理解できればと思ってソースを色々見てみたのですが、目が点になってしまい理解不能でした。
既存のアセットをなんとか使うにも、やりたいことと少し違うプラグインしかない。
カスタマイズしようにもどこをいじったらいいか分からない。
いっそリバースエンジニアリングして、自分向けでシンプルな構造のプラグインを作り直すなんてことはもっとできない。

これで結局先に進めなくなったのですよね。

で、結局イベントコマンドを繋ぎ合わせて、複雑な処理は単純な処理の集まりに読み替えるということを一義にして考えて、可能な方法を考えて行った感じです。
インタフェース周りの制約はどうにもならないことが多いですけど、内部処理に関する物は、そういう手法が取れるんじゃないか。という設計コンセプトでやることにしました。
実際はインターフェース周りも、違うものをそう見せかけるゴリ押しを通してやったこともありますが。

例えばツクトリでアイテムの錬金調合を作った時ですが、この場合「アイテム選択ウインドウ」を何度も何度も呼び出して処理しました。
これは本来は「パーティが持ってるアイテムを一覧から選ばせる」ための選択ウインドウと思います。

しかし、まず最初に「調合先のアイテムを一覧から選ばせる為」に、今できる調合を予めチェックして、出来るものの見本アイテムを隠しアイテムカテゴリに追加してアイテム選択ウインドウを表示し、調合先を選ばせる。

調合アイテムが決定したら直ちに隠しアイテムを一旦空にして、今度はその調合に使う「調合元」のアイテムの見本を隠しアイテムカテゴリに入れます。
そこでまたアイテム選択ウインドウを表示して、逆側にテキストウインドウを表示し、「上記のアイテムを使用します。OK…OKボタン キャンセル…キャンセルボタン」と表示。

これは「選択ウインドウ」ですらなくて、単なる「アイテムプレビューウインドウ」としての使用です。
戻り値が0なら調合は中止。
0でないなら調合が実行される。
その為だけです。
どちらの場合もこの処理の後でまた隠しアイテムを全削除します。

結局、ある物を上手に組み合わせて、やろうとしていることを無理やりでもいいから表現する。
出来ることがシンプルであればあるほど、潰しが効く。

こんな感じでやりました。
 
ツクール95や2000から使ってきた僕が言えるのは
そもそもツクールを使うのにプログラミングのスキルが求められる方がおかしい
ということです。
「プログラムなしで出来る」これが元来のツクールの意義であり、
今でもプログラミングの部分は分からなくても、プログラムが出来る人が作った「プラグイン」
という部品を使えば、いろんなものが作れる、それでいいじゃないですか。
プログラミングのスキルなんて求められる方がおかしいんです。

それでもツクールXPからスクリプトが導入されたのは、
「究極のツクールのためには、やはりコアスクリプト全体をスクリプト化して
皆に、あらゆる改造を可能にせねば」という尾島氏の考え方があったらしく、
編集部でも、導入に関して、そうとう揉めたと聞いております。
結果的に尾島氏の意見が通り、ツクールXPが誕生しました。

「プログラミングが出来る人がスクリプト素材を提供し、
プログラムが出来なくても、それを使えば機能の付け足しが可能にしたい」
……そういう「スクリプト素材」の考え方が、現在の「プラグイン」でしょう。

僕は、ツクールXPが導入された際、Rubyは未経験でしたが、
C++やJavaでオブジェクト指向は熟知していたのですぐ解読できましたが、
皆にそれを求めるのは酷というものでしょう。

……もっとも、「スクリプト素材」の考え方が定着したのはツクールVX以降であり、
ツクールXPのスクリプトは本体機能を犠牲にして、構造を単純にしたり、
コメントを多用したりしており、「プログラムを知らない人でも、これで慣れて欲しい」感じが
非常に強く漂っていますが、結局はそうはならなかった、と。
 

げれげれ

ユーザー
昨夏~昨秋に基情のために3か月ほどCを学び、その後、JavaScriptを初めて
半年少々の初学者です。
Cでポインタと参照を通過してきたことが結果としてオブジェクト指向の
理解に役立ちました。

おそらくここでのプログラミングスキルって他のスキル全般、絵や音楽などにも
当てはめることができる気がします。
「〇〇ができないとまともに扱えない」という状態になれば、一般向けツールとしては
意味をなさなくなりそうです。
特にツクールは「プログラムができなくてもゲームが作れる」がコンセプトのはずなので
明確に自己矛盾に陥りますね。

一方で、プラグインという概念については私は高く評価しています。

「絵ができる人がグラフィック素材を提供してくれる」
「作曲ができる人が音楽素材を提供してくれる」
のと同様に
「プログラムができる人がプラグイン素材を提供できる」
というように、プログラムスキルを素材として切り出し、提供しやすくしてくれました。
絵が描けなくても標準素材以外のグラフィック素材を利用できるように、
プログラムが書けなくても標準機能以外の機能を追加できる優れた仕組みだと思います。

また、標準機能で何でもできるようにするというのが事実上困難(何でもできる機能を
突き詰めて行くと最終的にスクリプトになる)なので、標準機能は可能な限り充実させつつも
標準機能に収まらない拡張性があることは大事かな、と。

そのうえで、現状のプラグインの課題として、公式での統一仕様見解(指針)や情報提供がほとんどなく
それこそスクリプターの力量に丸っと委ねられている印象が強い点があると思います。
なのでプラグイン制作と導入の双方をもっと簡便にしてくれるフレームワーク的なもの(※)が
用意されるといいなぁとしばしば思います。

(※プラグインパラメータの型、あれは便利でした。あーいうのをより強化したイメージ)
 

リンク

ユーザー
ツクール2000時代にYADOTというサイトを参考に自作戦闘を1回組んだあとに、専門学校でC言語・直後にC++を使えるようになったぐらいです。
その時の知識をベースに現在もプラグインを作成しています。

リンクさんの書き込みを見る限り、アルゴリズムを組む能力はあると思います。

ツクールでプラグインを書こうとする場合、以下の壁があると考えられます。
  • 構造化プログラミングの壁
    イベントコマンドとプログラミング言語の相互変換ができているかどうかです。
    「構造化プログラミング」という概念があり、逐次実行(上から下へ処理する事)・分岐(if文による条件分岐)・繰り返し(forなどによるループ)の3つがあれば理論的にすべてのプログラムが記述できます。
    イベントコマンドに無くてプログラミング言語にある物となると、関数の戻り値でしょうか。
  • JavaScript文法の壁
    プログラミング言語の翻訳するのとは別に、JavaScriptの文法の壁があります。
    ただ、構造化プログラミングの壁と近い位置なので同じには見えます。
  • オブジェクト指向の壁
    これは本職のプログラマでも超えられない人がいますが、「thisって何?」となる問題です。
    (JavaScriptのthisには落とし穴があることはここでは無視します)
    慣れないうちは全ての変数がグローバル変数としてどこかに実態を持つと考えがちです。
    実際ツクールの変数も根っことなるグローバル変数はありますが、それを意識しないで書くことができます。
    その上でオブジェクトのメソッドを呼び出す(actor.addState()とか)ことの意味が理解できるかどうか。
  • ポインタ・参照の壁
    オブジェクト指向の壁のすぐ近くにある壁です。
    オブジェクト指向で書くとなるとポインタ・参照の概念が必要です。
  • API・ライブラリの壁
    コアスクリプトのメソッドに何があるかの壁です。
    ただ、全てを覚えるのは難しいので入力補完ファイルを利用して、楽をしましょう。
    ツクールMV 入力補完で検索すると、設定方法が出てきます。
分解するとこのぐらいの壁があります。
そして、理解ができない時はどの壁で悩んでいるかもわからないのです。
ただ、私はこれまでに知識0に近い領域から自力でプラグインを書くレベルまでに短期間で成長したのを見てきました。
適切な指導者がいる環境であれば、確実に伸びます。
Twitterで適当に質問を投げると、詳しい人が答えてくれますよッと。
ありがとうございます。
プラグインが作れてしまうのは凄いと本当に思います。
僕の場合、イベントコマンドの組み合わせで一見できなさげな物を、無理矢理できるようにしてしまおうとすることは、上で例に挙げた物の程度ではちょっとできるのですが、そっからじゃあスクリプトもとなると、突然高い壁があるように見えるのです。

>構造化プログラミングの壁
これはどうなのでしょう。
はいともいいえとも言いづらいです。
一応、BASICや簡単なCぐらいなら触ったことはあります。
学生時代、C言語の授業がありましたが、これに関してはかなり簡単に感じました。
関数の戻り値に関しては、C言語にあるような奴ならまあわかります。
それ以上だとちょっと…ですね。

>JavaScript文法の壁
ドキ…これは怪しいです。
昔HTMLを手打ちでやってホームページ(死語)を作ってた頃、その延長でJavaScript、スタイルシートなどをお試しで混ぜてみたことはあります。
ステータスバーに文字列を表示させたり、マウスをかざすとアイコンがピカピカとか…。(あー懐かしい)
でも、あれはあくまでHTMLのマクロ言語みたいな感じで付け足しのように使ってただけなので、MVのスクリプトに関しては全く共通点を感じられず、完全な別物に見えてしまいます。

>オブジェクト指向の壁
ドキ…頭では分からなくもないのですが、実際にサクサクどんなのか説明してみろと言われると…うーん。
見た目的には
  • C言語の構造体みたいなのの中に、命令や関数(メソッド)もセットになっている(クラス?)
  • 基本的に内部の変数群をいきなり扱う事はせず、メソッドを経由して行う実装になっている
  • で、クラスにはメンバ変数やメソッドを書き加えて子クラスを作ったり、子クラスは部分的に挙動を変えたり(オーバーライド)などができる
  • そのクラス型で実体を実際にメモリ内に確保するのがインスタンス化?
ですかね?
オブジェクト指向系の言語というと、さわりだけObjective-Cに手を出そうとしたことがあります。
(元々はマックユーザーらしい)
ただ、お試しでおもちゃみたいなアプリを作ったことぐらいしかありません。
試しに作ってみたのが、10秒の間に何回マウスのボタンが叩けるかのMacのアプリだったり、ニンテンドーエミュレータで使うNESファイルのヘッダーをMacのGUIで編集するちっこいアプリ、ぐらいです。
というか実際の所Objective-Cそのものだけじゃなく、MacのAPIである、Cocoa APIの方で悩んだりしてました。
書籍を見様見真似でいじっただけなので、オブジェクト指向そのものはあまり理解してないと思います。
つか10年以上前の話ですし。
Objective-Cはその名の通り、ガチガチのオブジェクト指向系言語ではあるのですが。
「this」ってなに? はいあるあるです;;

>ポインタ・参照の壁
これはギリ分かってるつもりです。
実際C言語でも、ポインタを使っての参照渡しというテクニックがありますからね。
引数の一部をポインタにすることで、返り値を実質的に複数にする(渡されたポインタの実体を書き換えた状態にして関数を終了すると、呼び出し元に反映される為)、構造体丸ごとみたいな大きな物、文字列みたいな可変長な物は、実体でなくポインタとして関数に渡せばやりとりがしやすくなるし、構造体をメモリ確保と実体化してポインタ値で返す系の関数も作れる、など?がありますかね。
後、確か配列変数とポインタは似ている。配列変数の添字は、ポインタに加算するのと似ている、という話も聞いたことがあります。

>API・ライブラリの壁
ドキ…ドキ…ドキ…汗
これ、MVのスクリプトソースを見て解読しようと頑張ったものの、さっぱり分からずに挫折に追い込んだものだと感じます。
個別の命令を見たら、なんとなくこれが何をしているか、これは何関係か、ぐらいは察しがつくのですが、じゃあこの仕様をこう書き換えるにはどうしたら良いか、と言われると、うーんですし、任意のイベントコマンドをスクリプトで書き換えてみろと言われたら、やっぱりうーん、ですね。
あのクラスのこのメンバが、で、このメソッドが出ててあっちに依存して…これはどこまでのスコープの物なんだ?と考えていると、あっという間に頭がパニックを引き起こしました。

ぶっちゃけこんな感じですね。

ツクールのステップアップというと、イベントコマンドで人並み以上に複雑なことができるようになれば、スクリプトも習得できるように…なれませんでした。

初級…マップや基礎的なイベントコマンドを使い、RPGとして形になった物を作ってみる
中級…イベントコマンド、コモンイベントなどを駆使して、ちょっと凝ったアルゴリズムに挑戦する
上級…スクリプトを書き換えて独自仕様のゲームを作る

の様な単純なステップアップは成り立たないのですかね…(つくづくそう感じました)
 
最後に編集:
自身のプログラミング経験は、CとJavaです。それでかつて、資格を取ることもできました。

「コモンイベントを使って様々なことができる」と言われているウディタと比較した場合
RubyとJavaScriptは広く使われているので、言語自体のマニュアルが存在するというのは大きいです。

自作品であれば「ファンタジーヒロイン総選挙」でヒロインの得票数を並べ替えるときに
他にもいろいろ処理はしましたが、sortメソッドを軸としました。

プラグイン作成という点で見る場合、そこにも「レベル」はあると思います。
例えば、トリアコンタンさんやフトコロさんがやるような「ゲーム及び制作の基本システムに介入する」レベルの
ものであれば、かなり造詣が深くなければいけないでしょう。

ですが自分がやった「クリティカルダメージ補正を2倍にする」や
「攻撃力や防御力の値を”表示しない”(内部的には存在する)」などであれば
構造化プログラミングをかじったり、thisというのが基本的に「自分自身」のことだと
認識していればだいたいできるはずです。

余談ですが「0、null、undefined」の違いも厄介ですよね。
 
>でもその割にMVには沢山のプラグインが出回っていますし、それらを上手に使いこなした作品が多く見られます。
>一体どうしてなのでしょう。
 これは個人的な願望なのですが、プラグインがたくさん出回っているのは事実で、それを使いこなしている方が多いのも事実です。
 でもネット上の表に出てこない、ツクールを買ってもひっそり作っている「潜在ユーザー」はもっと多いと思いますし、
 そうあってほしいと願っています。「プラグインを使うともっと奥深いゲームが作れる」であって「無いと作れない、作っちゃダメ」的な
 風潮にはならないで欲しいなと。そういう意味では「ツクールデフォルトの戦闘シーンだから×」という風潮になったら怖いなと感じます。
 最近使われるようになった「ガチ勢」「エンジョイ勢」の言葉を借りるなら「ガチ勢」だけのツクールにはならないでもらいたいのです。

 そういう意味では格闘ツクールは最難関とも言える部類でした。何しろキャラ素材がほとんど無く、セットで付いて来る素材は
 サンプルゲームのために用意されたキャラグラフィックのみだったので。肝心のサンプルゲームのスクリプトもかなり複雑な処理が
 なされていて参考にできず、テンプレートのような技の組み方も無いためにほぼ独学で学ばねばならず、
 こればかりはツクールを買っただけではどうにもならない、という感じで買った当初は途方に暮れた記憶があります。
 
 極端な話、ツクールさえ買えば他には何の素材も無くとも、プログラミング知識が無くとも、ツクールに付いている機能で
 それなりのゲームがバシッと作れる(実際コンシューマー版ツクールはそうなっているはず)、新ツクールにも期待したい部分でもあります。
 

リンク

ユーザー
極端な話、ツクールさえ買えば他には何の素材も無くとも、プログラミング知識が無くとも、ツクールに付いている機能で
 それなりのゲームがバシッと作れる(実際コンシューマー版ツクールはそうなっているはず)、新ツクールにも期待したい部分でもあります。
その通りですね。
というか素材とかの話で言うと、CSのツクトリとかまさにそうですね。

その点、なんか思うんですけど、MVとツクトリ、どっちの方が「難しい」のでしょうかね?

僕から見ると、圧倒的にMVでしたが。

なにが原因かと言うと上で散々説明した通り、「スクリプト」「プラグイン」だったのですが。
でもプラグインに関しては意外にも違う見方をされている方が結構多かったみたいで
「プログラミングができなくとも、他作のプラグイン(アセット)を利用することで、高度なゲームが作れるからむしろプログラミングができない人に優しい」という考えもできるんだなと思いました。

でもいざプラグインを内製化しようと思ったら、途端に脳味噌がブルースクリーンになるぐらい難しかったので、僕から見ると難しいと感じたのです。

MVの場合​
  • プラグインが使えるから簡単に高度な物も作れる
  • プラグインを「作ろう」と思うと、急にどうにもならないほど難しくなる
  • (そうであったら困るのだけど)凝った処理はプラグインを使う事が(目立つ範疇では)一般的になっている
ツクトリの場合​
  • プラグインが使えない
  • でもプラグインのことに頭を割かれる必要はないし、アセット系全般デフォルトセットでも相対的に遜色は無い
  • 複雑なミニゲーム、独自処理はイベントコマンドを組み合わせて工夫して作ることになっている
    • スクリプトを作るのに比べたら少なくとも僕としては遥かに易しく感じる。ミニゲームのついたRPGも作ったことあるし
結局どっちが易しいツクールになるのでしょうかね?
仕様があえてほとんど同じで、大きな違いが「スクリプト」だけなので、どっちを易しいと言うべきなのだろうと思います。

少なくとも僕はツクトリでちょっと複雑なことを考えるのと、スクリプトを作るのであれば、月と鼈クラスに後者が難しいと感じます。
 

剣崎宗二

ユーザー
私は本業の言語がC#であり、JavascriptについてはツクールMVでプラグインを作ると決めてからコアスクリプトを見ての独学です。

自省して思うのは、結局理解を助けたのは「英語能力」なのだろうなとは。
例えばthis.removeState(3)のコマンド。私には例えるなら「this.ステート排除(3)」のように見えており、それが既存コードの理解を助けているのかなとは。
本業では「直し」の担当だったので既存のコードを読む事に成れていたのも有利に働いた面はありますけれどもね。

少なくとも僕はツクトリでちょっと複雑なことを考えるのと、スクリプトを作るのであれば、月と鼈クラスに後者が難しいと感じます。
「自分でプラグインを作る」と言う前提ならばそうですが、「自分で作らず他者の作った物を利用する」ならMVが簡単という、要は「前提条件の違い」かとは。
 

sally_elly

ユーザー
java scriptの構造が多少読み取れ、HTMLメールが書ける程度のスキルです。
こういう構成になってるんだな、は分かるけどもそれを応用・改変しようとすると一気に詰まるレベルですね。

ツクールは3と2000で作っていた時期が長く、正直にいえばプラグイン機能の大半が基本機能だけで再現可能です。
ですが、基本機能にない処理を追加しようとした場合、公開くださっているプラグインを利用できるとなれば、
圧倒的にMVの方が簡単ですし、正直に言えば楽です。

例えばメニュー改変はプラグインが無くとも自作メニューとして作れますが、
作成に慣れてない方からすればどちらも難しいでしょうし、作れる側としても、面倒なのでやりたくないのが本音です。

ただ、ツクールもプログラムも1から始めるのであれば、表現を広げるのはプラグインの方が簡単だと思います。
基本機能の応用は2000などゲームの中が見れるものしか参考にできないですが、
プラグインは書籍や公開されている数が圧倒的に多く、参考にしやすいためですね。
 
 僕はツクールの実行内容(イベントコマンド)は完全にプログラミングだと思っているんで、ツクラーである以上プログラムは作れていると思います。
 だから「プログラミングなしでも作れる」じゃなく「簡単にあるいはわかりやすくプログラミングできる」という方向で広報してほしいなぁ、とは思ってます。
 今はプログラミングスクールなんかも増えてるみたいですし、楽しく学べる教材として入り込んでほしいですね。

 ちなみにRPGツクールMVのJavaScriptに関しては、かなりたくさん調べて、調べたものを公開しているので参考になれば幸いです。
 
うちは、専門学校(あーもう20年前だわ)で、プログラミング言語としてはC言語とJavaを習い、他にネットワーク(ルーターなど)やデータベース(SQL)、HTMLやExcelVBA、Photoshopも少し触ったりしました。
就職してからは、設計書を書いたり、社内調整がメインだったので、プログラミングそのもののスキルは基礎知識を応用している程度ですね。
JavaScriptに関しては、(見た目が似ている)Javaの知識で書いてました。

ところで、「プログラミングスキル」と言った場合、プログラミング言語の書き方とAPI、アルゴリズムやデザインパターンの知識……辺りを指すと解釈していますが、実際の業務(非ゲーム業界)では広範な知識が要求されますし(極端な例では、サーバー室の電源容量を気にしたり、その業界の法律や慣習だったり)、ゲーム制作に関しても数学や物理の知識が必要な場面もあると思います。

しかし、RPGツクールではSQLを必要とするデータベースは使いませんし、ネットワーク知識もブラウザが隠蔽してくれてるので、要求されるコンピューター知識は少ないと思いますし、なるべく少なくしてほしいと思ってます。

尚、個人的には、プラグインはオマケ機能だと思っているので、公式サポートが無くてもそういうモノだと思ってます。
 

リンク

ユーザー
 僕はツクールの実行内容(イベントコマンド)は完全にプログラミングだと思っているんで、ツクラーである以上プログラムは作れていると思います。
 だから「プログラミングなしでも作れる」じゃなく「簡単にあるいはわかりやすくプログラミングできる」という方向で広報してほしいなぁ、とは思ってます。
 今はプログラミングスクールなんかも増えてるみたいですし、楽しく学べる教材として入り込んでほしいですね。

 ちなみにRPGツクールMVのJavaScriptに関しては、かなりたくさん調べて、調べたものを公開しているので参考になれば幸いです。
僕もこれ本当に思うんですよね。
ある意味ツクールのイベントコマンドって、RPG製作に特化した「プログラミング言語」の一種にも思います。
今度から学校でもプログラミングを教えるとか言ってますけど、だからといってCだのBASICだのを教える訳ではないですからね。
またヒューマンリソースマシーンというゲームありますよね。
あれも具体的なプログラミング言語の出てくるゲームではありませんが、ゲーム内で行なっていることはプログラミングと言って差し支えありません。
(あのゲームは非常にシンプルな物を組み合わせることを前提にしており、あえて近い言語はなにかと言われれば個人的にアセンブリ言語だと思います)

その上で
  • MV用のスクリプトプラグインはかなりの数が出回っている模様
  • MVで高度処理を行うためにプラグイン、スクリプトを使っている方、詳しい方が知る限りではかなり多い模様
その反面
  • スクリプト以外の方法で独自性を出すことは意外と話題に上がっていない模様
  • スクリプト・プラグイン機能のないCS機界隈はツクール界隈の中では今ひとつ元気がない模様
    • このフォーラムでもフェスやツクトリ板は殆ど書き込みが無い
    • 僕自身はSwitch版ツクトリユーザーですが、ツクール広場が今ひとつ盛り上がりが少ないことが気になる点
それを踏まえてなんか感じるのが、これはあくまで僕の個人的な感想なのですが、ツクールゲームをカスタマイズしたい場合、スクリプトは上で何度も申し上げている通り、理解にとてつもなく大きな壁を感じます。
しかしながら、イベントコマンドの工夫によって、ミニゲームを入れたり、特殊戦闘や特殊システムを組み入れることは、易しくはないけどなんとかはなる、と感じています。
僕自身はそれぐらいのスキルレベルだと感じています。
またその上で、CS機はスクリプト機能がないですが、それは殆どのツクラーにとっては大きなディスアドバンテージになっているのかな?とちょっと不思議に感じました。

で、ツクール界隈を見る限りだと、
  • スクリプトをバンバン作ったり使いこなしているプログラミング上級者
  • プログラミングは分からない、分からなくてもRPGを作っているよという方
にすごく二分されているように見えるのですよね。
ここでも、Twitterでツクール系のアカウントを持っている方も両方含め。
僕みたいに
「スクリプトはどうしても理解できない。けどイベントコマンドの工夫でなるべく面白い事ができそうなことを考えてみた」
な方、ほとんど見かけないのでなぜだろうなと思っていたりします。

あと、ステップアップという言葉はある物の、スクリプトを理解するということが、それ以外のツクールの機能をなるべく使いこなす、の先にある様で無い(僕はなんかそう感じます)。のも一体なぜだろうと思っています。

なんだかんだでスクリプトは、イベントコマンドとはある種別次元の難しさを感じます。

尚、個人的には、プラグインはオマケ機能だと思っているので、公式サポートが無くてもそういうモノだと思ってます。
そう言いたい所ですが、MV関係の話題を見ると、これに依存している比重、かなり重たくないでしょうか?
 

seea

ユーザー
こんばんは。では考察始めていきます。
ツクールの良いところはプログラミングスキル不要でゲームを作れるツールだと
思っているので、あまり気にしたことはありませんでした。

むしろスキルがあるならツクールを使わずに自分で作ってしまうだろうから
制作者視点では棲み分けが出来ているのでは? とまで思考ロックしておりました。

私のケースに当てはめると、むしろイベントコマンドを組み合わせて作る方がムズいです。
ツクールの王道の制作手法から外れるし良くないなとは思いつつも、
ついつい手を抜いてプラグイン化してしまいます。
どう考えてもプラグイン素材屋のほうが向いているような……。

クリエイターとエンジニアは共通する面も多いですが、ではエンジニアのスキルが
クリエイターのスキル向上に繋がるかというと微妙に感じます。
二兎を追う者になりかねません。

特にMVのプラグイン素材は神レベルの開発者が大勢いらっしゃいますので
プログラミングよりも制作が得意な方は相当恵まれているんじゃないかと、羨ましく思ってしまいます。
プラグインの登録順と相性に気を付けていれば機能拡張できるし……。

経験を積むには作品の完成させることが重要と仮定すると、
制作ができればプログラミングができなくてもゲームは完成するけど、
プログラミングができても制作が出来ないと、ゲームは完成しないでしょ。

前者は公開する度に経験値増えて内容も良くなるのでプログラミングスキルはおまけ、
後者は完成しないおそれもあるし完成しても前者と比べて微妙なので制作面の相当な努力が必要。

完成せずとも制作の過程は楽しいと思うので、後者の潜在的なユーザーはかなり多い気がする。
ただそれは作品という形で表に出て来ないのでユーザーが多いという根拠も集めようがない。
ひっそりとフェードアウトも十分有り得るケース。

このフォーラムのメンバー数はツクールのユーザー総数に比べて圧倒的に少ないので
前者と後者の比率は調べようもない。
一つ言えるのは前者のユーザーがフォーラムに登録して投稿する敷居が低いというのはある気がする。

フォーラムの投稿内容を見る限り、プログラミングスキルについてはあっても無くても
作品の完成度にあまり関係はない印象。経験と制作スキルのほうが圧倒的に重要。

プログラミングスキルが無いと作れない演出って、探さないと無いからね。
私はあえて探してそこに注力しているけれど、それは裏を返せば制作スキルが少ないからやむを得ず
そうしたということ。

制作スキルとプログラミングスキルの両方を高めるのがベスト。ベストだけど理想論に近く、
プログラミングのセンスは幼年期から青年期までの成長で決まり、
センスは年齢を重ねるごとに獲得が難しくなるので今持っていない場合は今後も無い可能性が高い。
猛烈な学習量によりひらめきが起こりセンスを獲得する可能性が無くはないが、ほぼ無い。
このセンスが無いとプログラミングに挑んだ際、センス持ちに比べて桁違いに苦労する。
続ければいずれは習得はできるが、猛烈に時間が掛かるのでコスパは悪い。
もうそれは無視して別の得意分野を伸ばして全く違う方法で制作した方が良いレベル。

しかし青年期以下の年齢(20歳頃まで)のツクラーなら、スキルではなくセンスの獲得を目指して
取り組めばほぼ確実に獲得できる。これほど恵まれた状況は以降の年齢ではまず無いので
間違いなくセンスの獲得を目指すのが得策。学習すればスキルは勝手に上がっていくのでそれは後で良い。
年齢リセのために異世界転生するのは正直あまりお勧めしない。スキルは上がるけど、センスは無理だろう。

制作スキルにも同じ事が言えるので、両方のセンス持ちは本当に恵まれている。
学習して出来るようになったらそれは元々センスを潜在的に持っていたということ。
潜在的なセンスがあるかないかは誰にも分からないので試しに1年くらい学習してみるのはあり。
ワンチャン閃くことがある。

ツクールとしてはユーザー層を考慮して特に制作スキル不足をフォローするように注力して
改善すればMZの売り上げも伸びると予想。
センスが無くてもゲームを作ることができるのがツクールの良いところだと思っているから。

ということでどうでしょうか。
 
トップ