本文へスキップ

神鏡、水銀党、霧式の3人によるマルチ創作サイト

電話でのお問い合わせはTEL.

ゲーム制作講座lecture


ツクールMVでのブラウザゲーム制作&デバッグ一般論・後編
 〜デスマーチはつづくよ〜

●ブラウザゲーム制作では、実際にブラウザでテストするのが大事
「さて、前編ではブラウザゲームについての一般論と公開方法についてまとめた。ここからは、実際にブラウザでテストする方法やデバッグの一般論について書いてみよう」
「ブラウザで……ってことは、ツクールMVのテストプレイ(エディターによるテスト)じゃなくて、Google Chromeとかfirefoxでテストする方法ってことだね?」
「そうだ」
「どうして、わざわざブラウザでテストするの?」
ブラウザで動作させると挙動が変わる場合があるためだ。ブラウザでしか機能しないプラグインなんてのもあるし、ファイル名のつけ方で上手く読み込めなくなることもある」
「げげ、それは怖いかも」
「ブラウザゲームとして公開する以上、やはり少なくとも一度はブラウザでテストしておいた方が安心だろう」
「どうやってやればいいの?」
「具体的な方法には2つある。紹介しよう」

1.ローカルサーバを構築して行うテスト(オフライン)
「デプロイメントしたファイルをそのまま開こうとしても、動作しない。これは、ブラウザのセキュリティーの関係で動作しないようになっているためらしい」
「それじゃ、テストできなくない?」
「そのままでは、な。そこで、ローカルサーバというものを構築して、そこにファイルを置いてテストすることになる。具体的な方法はツクールMVのヘルプ、『資料集』の『ローカルサーバの構築』にあるので、そちらを参照してもらうのが良いだろう」

 ツクールMVのヘルプには、ローカルサーバを構築する方法が画像付きで詳しく解説されています。著者もその通りにやってなんとかなりましたので、おそらく皆さんも大丈夫だと思います。

「ヘルプの通りに操作してっと……うん、たしかに『ローカルディスクC:』の『inetpub』に『wwwroot』ってフォルダが出来てるね。このフォルダにゲームファイルを置けばいいんだね?」
「そういうことだ。あ、一つ注意を。『wwwroot』にファイルをコピーしたり、削除したりするにはパソコンの管理者権限が必要なようだ。使っているパソコンの管理者権限が無い場合は注意しよう」
「ヘルプには、ブラウザからのアクセス方法がいくつか書いてあるけど、どれを使ったらいいのかな?」
「どれでも大丈夫だと思う。俺は、簡単だから『http://(コンピューター名)/プロジェクトフォルダ名/』を使っている。コンピューター名を調べる方法もツクールMVのヘルプに載っているので安心しよう」

たとえば、『wwwroot』に『www』というフォルダを置いてみましょう。



 このように、wwwフォルダにはindex.htmlと必要なフォルダがあるようにします。

「これは、ブラウザ用にデプロイメントしたゲームファイルのうち、wwwのフォルダをそのままコピーしたものだ」
「これをブラウザから呼び出すには、どうしたらいいの?」
「ブラウザを起動して、上段にあるアドレスバーに
『http:// (コンピューター名)/www/index.html』
と打ち込めばいい。index.htmlを省略して、
『http:// (コンピューター名)/www/』
と打ち込んでもいい」
「……おぉ! 動いた!」
「うむ。俺もちゃんと動いた時は感動した。ただし、いくつか注意点もある。後で詳しく話そう。とりあえず、ブラウザでテストするもう一つの方法について話そうか」

2.実際にサーバにアップロードして行うテスト(オンライン)
実際にFFFTP等のアップローダを利用して、自分のホームページ等にゲームをアップして行うテストだ」
「実際にアップロードしてみるってことだね!」
「そう。こうするのが、一番公開した時の状況に近い状態でテストできるだろう。そして、アップロードしたゲームフォルダの『index.html』にリンクを張れば、誰でも遊ぶことが出来るようになる=そのまま公開できる。ただ、この方法にはいくつか制限がある」
「というと?」
「まず、自分のホームページなどアップロードできる場所を持っていないと行えない。俺はLemon slice(このホームページ)があるから、ここにゲームをアップロードすることが出来るが、そうでない人はそもそもアップロード自体が出来ない。もちろん、テストのために無料のホームページ作成のスペースを借りてもいいが、多少ホームページ作成の知識がいるな」
「たしかに……」
「もう一つ、サーバの制約によってゲームファイルをアップロードできない場合が存在する。特殊文字の存在だ」
「特殊文字?」
「 ! や $ 、半角スペースやピリオドといったものだ。こういった文字はファイル名に使用することが出来ない。また、日本語(全角文字)も使えない」
「ファイル名に使えないってことは……その文字が入ったファイル名になってると、上手くアップロードできない、ってこと?」
「そういうことだ。たとえば、有名なアップローダ(ファイルをアップロードするためのソフト)である『FFFTP』だと、以下のようなエラーが出る」



「『!Crystal.png』って……クリスタルのキャラクターグラフィックだよね?」
「そう。ツクールMVはデフォルトで ! や $ を使用したファイルが使われている(主にキャラクターグラフィック)。そのため、なにげなくゲームを制作してアップロードしようとすると、このファイル名の制限によってアップロードできず、困ることになる」
「そういえば、ハムちゃんもあったね。βテスターの時にゲームをアップロードしようとして、出来なかったやつ」
「あれは困った。結局、ファイル名を変えて、問題となるグラフィックを全部設定し直した。短編だったからよかったが、長編だったらと思うとぞっとするな」
「じゃあ、ブラウザゲームを作る時は、特殊文字の使われたファイルは利用できないってこと?」
「そこが難しい。制限にはサーバによる違いがあるのか、それとも別の要因があるのか分からないが、使えるケースもある。たとえば、Lemon slice(このホームページ)は『Yahoo! ジオシティーズ』を利用している。ここに『FFFTP』を利用してゲームをアップロードしようとすると、文字制限に引っかかってアップロードできない。ところが、OPEN GAME様にゲームファイルを送る(zip形式で圧縮して送るため、問題なく送れる)と、問題なく動作する」
「つまり、OPEN GAMEさんだと特殊文字も使えるってこと?」
「どこまで使えるのかは分からない( ! や $ だけなのか、全角文字はどうなのか、等)。また、他のサイト様でどうなっているかも検証は出来ていない。だが、ブラウザゲームだから一概に特殊文字は使えない、というわけではない、と覚えておこう。少なくとも、公開サイトを利用する場合はデフォルトのファイル名に関しては利用できる前提でツクって平気だと思う」
「FFFTPを使う場合は、気をつけないとね」
「一度、試しに画像ファイルだけをアップロードしてみる、というようにテストしておくのも有効かもしれないな」
「さっき話してたローカルサーバを構築してのテストでも、特殊文字は使えないの?」
「使える。だから問題なく動く。なので、オフラインでちゃんと動いたけど実際にアップロードしようとしてつまずく、ということが起こりうる。注意しよう」

 まとめると……
 ローカルサーバ(オフライン)で
テストするメリット
 デメリット
・比較的容易にローカルサーバの構築が出来る
・一度準備すれば簡単にテスト可能。修正もすぐに可能
・特殊文字を含んだファイルを使える
・アップロード時やオンラインで実際に動かした時に起きる問題に気付けない
・ファイルのDLなどが無いため、実際にオンラインで動かしたときの動作速度は分からない。

 オンラインでテストするメリット  デメリット
・実際に公開する時の状況に最も近い形でテストできる(プラグインの挙動、ゲームの動作速度まで含めてテストできる)
・テスト後、そのまま公開することが出来る
・アップロードするためのサーバやホームページスペースが必要
・特殊文字を含むファイルが使えない場合がある
・アップロードの手間がかかる

「ハムちゃんは、どうしてるの?」
「先日公開した『Rito Little Tales』の場合、さっきも言った通り、『FFFTP』でLemon sliceのスペースにアップロードしようとしても特殊文字の制限で引っかかって、アップロードできない(=オンラインでテストできない)。なので、基本はローカルサーバでテストしている」
「公開は、OPEN GAMEさんを利用してるんだよね?」
「そうだ。そこだと、特殊文字を含んだファイルも使用できる。また、テストプレイを行う機能も付いているので、実際に公開した時にどうなるのか、そこでオンラインでのテストを行っている(アップロードしてからテストプレイの準備が整うまで1,2日かかるが)」
「オンラインでテストすると、違うことってある?」
「詳しくは後で書くが、あるぞ。プラグインが予期しない挙動をしたり、読み込めるはずのファイルが読み込めなかったり……実際に公開する環境でテストすることの重要性を痛感したな」

●ブラウザゲーム制作の注意点
「さて、ブラウザゲーム制作については、これが最後のテーマだ」
「制作するときの注意点、だね」
「そう。ブラウザゲームでの公開は、やはりまだまだ新しい分野だ。なので、今までにない問題や注意点が生じてくる。そういった制作上の注意点やテスト時の注意点について、簡単にまとめてみよう」

1.キャッシュ
「キャッシュというのは、ブラウザの機能の一つだ。一度読み込まれた画像を保存しておき、次回以降素早く表示できるようにする機能だな」
「たしかにホームページとかって、一度目に開く時は表示に時間がかかるけど、2回目からは早く表示されるよね」
「そう。キャッシュに画像を保存しておくことで、ダウンロードする手間をなくすんだな。それによって、素早く画像を表示できるようにする。ツクールMVのブラウザゲームでも、この機能のお世話になっている」
「確かに……最初は画像が表示されるまで一瞬タイムラグがあるけど、2回目からはタイムラグなしで表示されるね」
「便利な機能だが、テストする時に困る場合がある」
「というと?」
「キャッシュに画像が保存されているため、画像を差し換えてもすぐに反映されない場合がある。これは、ローカルサーバによるテストでも、オンラインのテストでも同様だ。ゲームのバージョンアップによって画像を差し換えた場合も、同様の事が起きると考えられる」
「たとえば、画像におかしいところを見つけて直しても……直したはずなのに元のまま、ってことが起こるんだね?」
「そう。……とはいえ、これは差し替え後の画像でなく、キャッシュに保存されていた画像が表示されているだけなので、キャッシュを削除したり、時間が経ったりすれば、ちゃんと新しい画像が表示される
「じゃあ、心配はないんだね」
「そうだ。だが、これを知らないとテストの時に『画像を差し換えたのに変わらない! どうして? バグ?』と焦ることになる。なので、知っておくといいだろう」

2.サーバにつなぐプラグイン
「プラグインの中には、サーバに接続するようなプラグインもある」
「たとえば?」
「OPEN GAME様のサーバセーブ・プラグインなどだ。ツクールMVはブラウザで動く時、ローカルストレージというところにセーブデータを保存する、と話したな? このプラグインはローカルストレージではなく、OPEN GAME様のサーバにセーブデータを保存するように変更する」
「なるほど、だから色々なデバイスでセーブデータを共用できるんだね」
「そう。だが、これはOPEN GAME様のサーバに接続するプラグインであるため、OPEN GAME様にアップロードした時しか正常に動作しない。これを知らないとテストの時などに苦労する」
「詳しく教えて!」
「このサーバセーブ・プラグインがONになっていると、ローカルサーバでのテストやアップロードしてのテストでゲームが起動しなくなる。おそらく、他の公開サイト様に送っても動かないだろう」
「ローカルサーバでもダメなんだ?」
「そう。エディターのテストプレイなら動作するので、おそらくブラウザで起動した場合に動作するプラグインなのだろうな。で、OPEN GAME様以外の場所で動作すると上手く機能せず、ゲームが動かなくなる」
「対策は、どうしたらいいのかな?」
テストの時は、プラグインをOFFにしておくといいだろう。実際にアップロードする時にONにするようにすれば、問題ないはずだ」
「なるほど」
「ローカルサーバやアップロードでゲームが動作しない場合(たいてい、起動直後にエラーになるか、そもそも起動しない)は、このようなサーバに接続するプラグインがONになっていないか確認するといいだろう」

3.プリロード系のプラグインの使用
「ゲームの動作速度を改善するためのプラグインがある。プリロード系のプラグインと呼ばれるものだ」
「プリロード?」
「実際に使用するより前に、画像や音楽を読み込んでおくことだ。あらかじめ読み込んでおくことで、実際に画像を表示したり音楽を流したりする時に、素早く、タイムラグなしに実行できるようにする」
「へぇ、便利そう」
「ブラウザゲームは、どうしても読み込みの時間によって動作速度が落ちるから、プリロード系のプラグインにはお世話になることが多いだろう。だが、これらのプラグインの中にはブラウザで動かして初めて機能を発揮するものも存在する」
「さっきの、サーバセーブ・プラグインみたいなものだね?」
「そう。こういったプラグインが正常に動作しているかは、実際にブラウザでテストしてみないと分からない。俺も、エディターでのテストで正常に動いていたのに、アップロードしたところ正常に動作しなかったことがあった。調べたところ、結局原因はプリロード系のプラグインにあったな」
「実際にブラウザでテストするのって、大事なんだね……」
「そう。繰り返しになるが、ブラウザでテストすると挙動が変わることがある、というのは覚えておいた方がいいだろう」

4.ファイル名の注意
「さっきも書いたが、アップロードする場合はファイル名に使用できない文字がある」
「! や $ 、日本語とかだね」
「そうだ。こういった命名規則は詳しい人には常識なのだと思うが、初心者には分かりにくいだろう。とりあえず、ファイル名に使えるのは『半角英数字だけ』と覚えておこう」
a ~ zと数字ってこと?」
「そうだ。記号のような物(! や $ など)と全角文字(日本語)は原則使用しない方がいいだろう(全角の数字もダメ。もちろん、半角とはいえ半角カタカナもダメ)。使えると分かっているなら使ってもいいが……まぁ、安全をとるなら使わない方がいいな」
「ツクールMVのデフォルトで使われてるのは? キャラクターグラフィックに、 ! とか $ が使われてるよ?」
「これも先ほどの内容と重複するが、FFFTPによるアップロードでは使えない場合がある。公開サイト様によっては使えるようだから、確認してもいいかもしれない。少なくとも、 ! と $ に関してはOPEN GAME様で使えることは確認している」
「公開する場所によっても、多少制限が変わるんだね。難しいなぁ」
ファイル名は半角英数字、と覚えておけば大丈夫だろう。ただ、もう一つ注意がある。大文字と小文字の違いだ」
「大文字と小文字? Aとaみたいなこと?」
「そうだ。これが曲者で、オフラインとオンラインで挙動が変化する
「詳しく教えて!」
「オフライン(エディターでのテストやローカルサーバでのテスト)では、大文字と小文字は区別されない。つまり、呼び出すファイル名が『test.png』の場合、実際のファイル名が『test.png』でも『Test.png』でも問題なく呼び出してしまう」
「どっちでも平気なんだね」
「ところが、オンライン(実際にアップロードした場合)では、大文字と小文字が区別される。つまり、呼び出すファイル名が『test.png』の場合、実際のファイル名が『test.png』でないと呼び出せない。『Test.png』は別のファイルと認識されてしまう」
「えぇ!? それって、ちょっとこわくない?」
「このことを知っていれば平気だ。また、ツクールMVのデータベースやマップ・イベントで設定する場合はファイル名がそのまま表示されるので、問題は起こらない。気を付けなければいけないのは、プラグインから直接呼び出す場合だ。特に自分でファイル名を打ち込むような場合、誤って大文字小文字を区別せずに書き込んでしまう場合がある」
「そっか……そうしてファイル名を間違えたとしても、オフラインでテストする時は区別されない――つまり、正常に動作しちゃうから、気づけないんだね?」
「そういうことだ。オフラインでは正常に動いているのに、アップロードした途端ファイルを読み込めなくてエラーになる……という現象に遭遇したら、ファイル名の大文字小文字が原因の場合がある。覚えておこう」

5.ゲームタイトルの設定
 ゲームタイトルを変更すると、ローカルストレージやサーバに保存されたセーブデータを読み込めなくなります(ゲームタイトルによってセーブデータがそのゲームの物か判定しているため)。これはブラウザでゲームを動かした時に生じる問題であり、エディターやDLしたものでは気づくことができないため注意が必要です。

「先ほども言ったが、ツクールMVはブラウザで動作する際、セーブファイルをブラウザのローカルストレージという所に保存している。ツクールMVはこのローカルストレージに保存されたデータを読み込む際に、二つの情報を使って、そのゲームのセーブファイルかどうかを判定しているようだ」
「二つの情報って?」
「一つは、globalIdという変数で、これは通常”RPGMV”という文字列が入力されている。プラグインを書き換えない限り変化しないので、あまり心配はないだろう。問題はもう一つの方で、これはゲームのタイトルだ」
「ゲームのタイトルって……データベースの『システム』で設定するやつ?」
「そう。ゲームを起動すると、ウィンドウの名前のところに表示される奴だな(『ゲームタイトルの描画』にチェックを付けていると、タイトル画面にも表示される)。これが曲者で、ゲームタイトルが一致していないと、そのゲームのセーブファイルだと認識できなくなり、セーブファイルを読み込めなくなる」
「えぇ、困るじゃん! でも、そんなのあったら、すぐ気づきそうだけど……」
「ところが、エディターのテストプレイやダウンロード式の場合、セーブファイルはゲームフォルダ内に作成され、しかも上記二つの情報(globalIdとゲームタイトル)の照合をせずに読み込めてしまう。つまり、ゲームタイトルを変更しても問題なく動作してしまうのだ。なので、ブラウザで実際に起動しないと、この問題には気付けない
「ということは……ゲームのバージョンアップをした時にゲームタイトルを変更しちゃうと、それまでのセーブデータが使えなくなっちゃうってこと?」
「そういうことだ。これは、どうやらOPEN GAME様のサーバセーブ・プラグインを使用していても同様らしい(実際にセーブファイルを読めなくなっているゲームを見た)。普通、ゲームタイトルを変更することは少ないと思うが、タイトルの後ろに『Ver. ○○』のようにバージョンを記載している人は注意しよう」
「つまり、ブラウザゲームで公開する時は、バージョンアップする時にゲームタイトルを変えちゃいけない、ってことだね」

●デバッグ一般論
「さて、最後になったが、デバッグ一般論について簡単にまとめて、筆をおこう」
「ここからは、ツクールMVに限った話じゃないんだね?」
「そうだ。最後に少しだけMV関係の注意を書くが、基本はゲーム制作全般の話になる。デバッグについての基本的な考え方や方法について、書いていこうと思う」

1.メモを取ろう
「デバッグの基本。メモを取らずしてデバッグは出来ない」
「メモって、ようするに紙とペンでメモしておくってことだよね?」
「そうだ。実際にテストして、『ここがおかしい』『あそこを直そう』と思っても、メモを取らないとすぐに忘れてしまう。忘れてしまうとテストし直しになるし、見落としたまま先に進むと公開後にバグが発覚することにもなる」
気づいたことは何でもメモしておく、ぐらいの姿勢で挑んだ方がいいかもね」

2. バグと戦う時の武器:論理的思考
「論理的思考、という概念には色々ある。ここで紹介するのは『仮説を立て、検証し、結果をまとめ、考察し、それをもとに新しい仮説を立てる』……という一連の思考の流れのことだ」

論理的思考とは
(1)仮説を立てる
(2)仮説を検証する
(3)結果をみる(問題が解決するのか、しないのか)
(4)考察する(仮説は正しかったのか。正しくないなら、何が違うのか、など)
(5)解決していない場合、新しい仮説を立てる(以下、繰り返し)

「うぅん、難しいよ! 具体的には、どんな感じ?」
「そうだな……たとえば、イベントでキャラクターを歩かせた。ところが、そのキャラクターが途中で止まって、そのままゲームが動かなくなってしまった……さぁ、どうする?」
「え? えーっと、原因はなにかなぁ、って考える!」
「なんだと思う?」
「えぇ、難しいよ……うーん、マップチップの設定が間違ってて、キャラクターが歩けない?」
「それだけ?」
「実は透明なキャラクターがいるとか、他のイベントが起動して動かないとか、プラグインが何かおかしいとか!」
「そう、色々な原因が想像できるだろう? それが『(1)仮説を立てる』ということだ。なにも難しいことではなく、『原因としては、あれが考えられるな、これもありうるな』と原因を仮定することが『仮説を立てる』ということだ」
「ふむふむ……実際に仮説を立てたら、どうするの?」
「(2)検証する。たとえば、仮説『マップチップの設定が間違っている』を検証しようと思ったら、データベースの設定を見直すことになる」
「えーっと、設定は……うぅん、別におかしくなさそう」
「なら、それが(3)結果ということになるな。マップチップの設定におかしなところは見られない。そうすると?」
「えーっと、(4)考察する……マップチップは原因ではなさそう、他の原因が考えられる、ってとこかな?」
「じゃあ、(5)マップチップの設定以外の仮説を立てて、以下繰り返し、となるな」
「地味な作業……」
「結局、こういう作業・思考の繰り返しが、デバッグという作業になるんだ」
「バグを直す時って、みんなこうしてやらないとダメなの?」
「ダメとは言わないが、きちんと原因を見つけて、それに対処するように直していく方が、結局良い結果につながると思う。もちろん、対症療法で乗り切ることも出来るのだが(この場合、キャラクターの“すり抜け”をONにするとか。原因は解決できないままだけど、とにかく動くようにする)、結局原因が分からないと、また同じような問題にぶつかることも多い。また、一度原因が分かっていれば、次から仮説を立てる時にも役に立つ」
「急がば回れ……ってことかな」
「ちなみに、今回の原因は『透明化した主人公がマップの中心にいて、それにぶつかって先に進めなかった』だ」
「Oh……」
「余談だが、この論理的思考というのは、意外と色々な場面で応用できる。理系・文系問わず研究をする時には必要になる考え方だし、仕事をする時にも、こういうものの考え方ができると問題解決能力が上がる。俺は、ゲーム制作が実生活でのスキル向上に役立つ好例だと思っているよ」

3.バグと戦う時の武器2:変えるのは一度に一つずつ
「論理的思考と共に、デバッグの時に大事な考え方がある。それは、『変えるのは一度に一つずつ』というものだ」
「どういうこと?」
「先ほどの例を考えてみよう。キャラクターが歩けない……となった時に、色々な原因が考えられる。それを検証する時は、一度に一つずつ要素を変えなければいけない、ということだ」
「もう少し詳しく!」
「たとえば、原因としてマップチップ、イベントの設定、他のイベントの存在、透明化した主人公、プラグインの問題……など、いくつも仮説を立てる。これらの仮説を、全部まとめて変えたらどうなるだろう? たとえばマップチップを変え、イベントの設定も変更し、他のイベントも動かし、主人公の位置も変え、プラグインもOFFにしたら?」
「うーん、とりあえずキャラクターが歩けるようにはなりそうだけど……」
「そうだな。今回は偶然、原因である『透明化した主人公がいる』という原因が取り除かれるので、動作はするようになるだろう。だが、結局何が原因だったか分からないままになると思わないか?」
「……たしかに。一度にいくつも変更すると、仮にそれで問題が解決したとしても、どれを変えたことが解決につながったかは分からないよね」
「そういうことだ。つまり、一度にいくつもの要素を変えて上手くいったとしても原因は分からずじまいだし、根本的な解決にはならないのだ。これは、理系で実験をする時などにも重要な考え方になる」
「たとえば?」
「AとBを反応させてCを作る……という実験を考えよう。上手くCが作れない時に、反応温度を変え、反応時間も変え、抽出方法も変え、ついでにDという物質も加えて……という風にしてしまうと、それでCが作れても、何が理由でCが作れたのか分からない」
「おぉ、なるほど。たしかに、デバッグの話と同じだね」
「この時大事なのは、一度に一つずつ要素を変える、ということだ。たとえば、まず反応温度を変えてみる。上手くいかなかったら、温度が原因でないことが分かる。そこで、次は反応温度は変えず、反応時間を変える……というように、一つずつ試していく」
「たとえば反応時間を変えたことで上手く行ったら、反応時間が上手くいかなかった原因なんだな、って分かる……そういうわけだね?」
「その通り。もちろん、原因が一つでなく、複数の要素を変えて初めて上手くいくこともあるので簡単な話ではないのだが、複数の要素を変えるのは、少なくとも一つずつの要素を検証してからだな」
「上の例以外にも、デバッグで『一度に一つずつ変える』って考えを使うことある?」
「たくさんある。たとえば、プラグインやスクリプトの競合などにも有効だな。プラグイン・スクリプトが上手く動かない時、どのプラグイン・スクリプトが競合しているのか調べるために、一つずつOFFにして試していく」
「なるほど……たしかに、一つずつOFFにして競合が直ったら、そのプラグイン・スクリプトが原因だったって分かるね」
「そうだ。原因を特定する、というのは重要なポイントで、原因がはっきり特定できて初めて、適切な修正を行うことが出来る
「原因を特定するためには、一度に一つずつ要素を変えて確かめるのが確実、ってことだね」

4.デベロッパツールの使い方
「プラグイン、スクリプトの話が出たので、一応デベロッパツールにも触れておこう。とはいえ、これはプラグインやスクリプトをいじる人向けだ」
「デベロッパツールって、なんなの?」
「プラグインやスクリプトの挙動を見たり、エラーメッセージを表示させたりするのに有効なツールのことだ。RPGツクールVX Aceでは『RGSSコンソール』、ツクールMVではF8キーで呼び出せるツールがこれにあたる(Google Chrome(ブラウザ)で動かしている時はF12キー)。ツクールMVのヘルプ、『補助ツールの使い方』の項にも簡単に載っている」
「どういう風に使うのかな?」

ツクールVX Aceでは
p 変数
と記述することで、RGSSコンソールに変数を表示することが出来ます。

ツクールMVのデベロッパツールでは、
console.log(変数);
と記述することで、デベロッパツールのconsoleタブの部分に変数を表示できます。
また、エラーが生じたとき、具体的にプラグインのどこで、どんなエラーが起きたのか表示してくれます。

「ツクールMVのデベロッパツールには色々な機能があるようなのだが、俺はconsoleしか使えない。詳しい人は、もっと色々なことが出来るのだろう」
「変数を表示できるだけ? もっとすごい物かと思ってた」
「いやいや、変数を表示できるのが大きい。この場合の変数とは、普通の数字が代入された変数に加えて、文字列や配列変数も含んでいる。たとえば、actorという変数にアクターの情報を代入して、console.log(actor); というふうに表示すると、アクターに関する情報、名前とかID,装備の配列、スキルの配列……など、色々な情報をまとめて表示することが出来る」

例:ツクールMV
var test = "テスト";
var actor = $gameActors.actor(1);
console.log(test);
console.log(actor);

→こうすると、デベロッパツールのConsoleタブに
テスト
▲Game_Actor {_hp: 450, _mp: 90, _tp: 0, _hidden: false, _paramPlus: Array[8]…}
と表示される(▲は実際には右向き)。
Game_Actorの部分は、この▲の部分をクリックすることで詳しく表示できる。

「上の例はイベントコマンド>スクリプトでも試せるので、興味がある人はやってみよう」
「そういえば、ツクールの変数は数字しか入らないけど、スクリプトとかプラグインの変数って、数字以外にも色々入るって聞いたことがある!」
「そうだろう。そして、変数の処理というのは非常に“見にくい”。どういうことかというと、ゲーム画面に表示されるのはマップとかウィンドウとか、表示する処理がされた物だけなんだな。その下でどんな処理がされているのか、どんな計算がされているのかは見ることが出来ない」
「たしかに……そうか、変数も“見える”ようにする処理をしないと見えないのか」
「そういうこと。とはいえ、ゲーム画面に一々表示するのは大変だ。そこで、デベロッパツールを使用して、見えない変数を“可視化”するわけだな」
「たしかに、見えないものを直すより、見えるものを直す方が簡単そう」
「それに加えて、ツクールMVではエラーが起きた個所も詳しく教えてくれる。○○というプラグインの□行目でエラーを起こしている……というようにな。この情報が無いと、どこに問題があるのか分からず、手の打ちようがない」
「さっきの話と同じだね。原因が特定できないと修正できない、ってわけか」
「そういうこと。とはいえ、これはスクリプトやプラグインをいじる人でないと普通は使わないので、やや上級者向けの内容と言える。初心者の人は、こういう機能もあるんだな、ということを知っておけば十分だろう」

5.プラグインを最新のものに更新する時の注意
「最後に、プラグインつながりでちょっとした注意を。ツクールMVの話になってしまうが、ツクールMVは時々本体がアップデートされる」
「たしか、今はVer.1.3.3だっけ(2016年11月)」
「そう。このアップデートの際、ゲームを動かす本体であるjsファイル(java script)もアップデートされている。基本的には最新のものを使うのが良いと思うので、適宜更新してもらえばよいと思う。が、少し注意がある。それは、基幹部分のプラグイン(rpg_core.jsなど『plugins』フォルダ以外のもの)を更新した際、既に使用しているプラグインが正常に動かなくなる場合がある、ということだ」
「既に使用している……っていうのは、プラグイン管理でONにしてるプラグインってことだね」
「そう。基幹部分がバージョンアップされることで、上手く動かなくなってしまうケースがあるんだな。それまで上手く動いていたのに、本体をバージョンアップしたら上手く動かなくなった……というケースもあるので、注意しよう」
「そういう場合、どうしたらいいのかな?」
「基本的には、プラグインの作者の人にバージョンアップに対応してもらうほかない。よほど腕のある人なら自分で直すことも出来るのだろうが、まぁ、難しいだろう。場合によっては、プラグインの使用を諦める必要が出てくることもある」
「うぅん、それはちょっと残念かも……」
「本体のバージョンアップとプラグインが使えなくなることを天秤にかけて、メリットのある方を取る、と考えるほかないだろうな。なので、いざという時のために、アップデートする前にはバックアップを取っておいた方が安心だろう」
「プラグインの作者の人が対応してくれてるかもしれないし、こまめに最新版が出ていないかチェックするのも大事かもね」


「ふぃ〜! 今日の講座は量も多いし、難しい内容も多いし、大変だったね」
「うむ。読者の人には、良くここまで読んでくれたと感謝したい」
「こうしてみると、結構難しい内容も多いよね……ゲームが作れるか、ちょっと心配になってきたな……」
「大丈夫。普通にツクる分には、大きな問題にぶつかることは少ないだろう。ただ、時々こういった難しい内容にぶつかることがある」
「たしかに、実際にハムちゃんが遭遇した問題が中心だもんね」
「最初にも書いたが、やはりツクールによるブラウザゲームというのは新しい分野だ。それゆえ、今までにない問題が起こりうる。今回、こうして講座を書いたのは、俺が実際に遭遇した問題について知ってもらうことで、これからツクる人の役に立てばいいと思ったからだ。だから、今回の講座の内容をすべて理解する必要は無い。細かい原理などはさておき、『こういう問題が起こりうるんだな』『上手く動かない……そういえば、こんなことが講座に書いてなかったっけ?』と思ってもらえればいいと思う」
「この講座を読んで、ブラウザゲームをツクる人が増えるといいね!」
「そうだな。技術的な問題で諦めてしまうのは、もったいない。ぜひ、みんなにも新しいことに挑戦してほしいな」
「うん。というわけで、はい、ハムちゃん、パソコン」
「え?」
「え? じゃないでしょ? まだデバッグ作業終わってないんだから、デスマーチしてもらわないと」
「うっ! 急に頭痛が痛くなった! すまん、フィリス、これはもう寝るしかない!」
「あ、こら! あからさまな仮病で逃げるなー!」

ぐしゃああああああ!

るはあああああああっ!
「……はっ! ハムちゃん倒しちゃったら、結局デバッグ作業できないじゃん! ほら、ハムちゃん起きて! 起きろー!」
「なにこの理不尽……」

●今日のまとめ
1)ブラウザゲームとして公開するメリットには、複数の異なるデバイスで遊べる、ダウンロードの手間が無い、ファイルの更新が確実、などがある。対してデメリットには、予期せぬ挙動をしうる、ゲームの処理能力がどうしてもダウンロードするものに比べて劣る、公開の場に制約がある、などがある。
2)ブラウザゲームとして公開するには、デプロイメントを行う。その際、未使用ファイル削除ツールに対応する必要がある。対応としては、プラグインを対応させる、削除されてしまうファイルを選んでおき、デプロイメント後のフォルダにコピーする、といった方法がある。
3)ブラウザゲームの公開に対応した公開サイト様もある。公開サイトを利用するメリット・デメリットを考えて、自分に合う公開方法を探そう。
4)ブラウザゲーム制作では、実際にブラウザでテストするのが大事。テストする方法には、ローカルサーバを構築して行うテスト(オフライン)と実際にサーバにアップロードして行うテスト(オンライン)がある。
5)ブラウザゲームの制作では、キャッシュ、サーバにつなぐプラグイン、プリロード系のプラグインの使用、ファイル名の注意、ゲームタイトルの設定、といった注意点がある。
6)デバッグには、メモを取る、論理的思考で考える、変えるのは一度に一つずつ、デベロッパツールを使う、といった考え方・方法がある。

前編に戻る