2024年に小さな2Dプラットフォームゲームをリリースしましたが、その時の感想を書いていなかったので書き残しておこうと思います。
良かった点
2Dプラットフォームゲームを始めやすい
当初はPhaser.jsなどのライブラリを調べたこともありましたが、自分が使える時間を考えると最初から各種エディタやツールが統合された開発環境を利用した方が良い、と判断しました。
そこでUnity2Dにほんのちょっとだけ触れてみて、アングリーバード風のサンプルゲームを見たりもしたのですが、やりたいことに対してUnityは巨大すぎる印象を受けたので、機能が2Dに限定された開発環境を探すことにしました。
2D向けのゲーム開発環境は、シンプルな代わりに機能が限定的すぎるものや、機能が充実している代わりにゲームプログラミングの深い理解を要するものなどがあり、最終的に2Dプラットフォームゲームが一番作りやすそうなGDevelopに決まりました。
シーンエディタにドラッグ＆ドロップで敵キャラやアイテムを配置して、イベントシートに衝突時の処理を書くだけでそれなりにゲームになるので、とっつきやすかったです。
無料のゲーム開発環境の中では比較的情報が多い
WebでGDevelopについて検索すると、公式ドキュメントか他のユーザーの記事かフォーラムのやりとりが何かしら見つかったので、少なくとも2Dプラットフォームゲームの作成を始める際の情報には困りませんでした。
また、開発環境の入力欄の1つ1つに説明文が付いている場合が多いので、特に新しいビヘイビアを利用する際に理解しやすかったです。
作成中のゲームに新しい機能が必要になった時の典型的な流れとしては、例えばキャラクターを点滅させたい場合、まずWebで検索してフォーラムのやりとりがヒットして「Flashビヘイビアというものがある」と分かり、開発環境に戻ってキャラクターにFlashビヘイビアを設定すると、点滅の時間の入力欄と説明文が表示されるので、入力してプレビューで確認する、という順序で解決しました。
作ったゲームを公開する場所がある
昔、Windows向けのミニゲームを作っていた時は、自分のWebサイトにEXEファイルを含めたZipアーカイブを置いていました。シンプルなゲームであれば最初からWebで遊べた方が利用しやすいのですが、当時は古い技術が廃止されたり新しい技術が発展途上だったりと、なかなか手を出しづらい状況でした。
GDevelopはWebアプリ(旧HTML5アプリ)としてゲームをエクスポートできるだけでなく、エクスポート先としてgd.gamesが用意されているので、公開できる場所を探したり自前で公開するためのセットアップ作業をせずに済みました。
もちろんEXEファイルをエクスポートすることも可能で、GDevelopのクラウドサービスでビルドする場合は無料アカウントだと1日1回までですが、自力でElectronをインストールしてビルドする方法もあり、公式ドキュメントに手順が書いてあります。
既存機能で出来ないことがあった時の拡張性が高い
GDevelopも他のゲーム開発環境と同様に拡張機能(エクステンション)をサポートしているため、2D向けの高精度な物理演算やコヨーテタイム(落下中でもジャンプできる猶予時間)などの機能を作成中のゲームに組み込むことができます。多くのビジュアルプログラミング環境と同様に、複雑な処理は外部の拡張機能に任せるのがベストな選択です。
一方で、目的の機能そのものを持つ拡張機能が無かった場合、拡張機能をJavaScriptで自作するか諦めるかの単純な2択にならないのがGDevelopの特徴で、GDevelopのイベントシートは複雑な処理が書けるようにプログラミング言語の要素が一部含まれています(ローカル変数、foreachループやwhileループ、関数呼び出しなど)。デバッグの労力が増大する危険性はありますが、ゲーム内の一部の処理だけ複雑な実装をする必要がある場合に、いきなりGDevelopのJavaScript APIについて調べなくても、対応する余地はあります。
ここまではGDevelopの良かった点ですが、懸念事項も書いておきます。
懸念点
イベントシートの条件分岐の書き方が冗長になりがち
イベントシートで「変数>=0」のイベントに加えて「それ以外(プログラミング言語のelseに相当)」のイベントを用意したい場合、明示的に「変数<0」のイベントを作成する必要があります。条件が複雑な場合はNOT演算子に相当する命令を使うことで省力化できますが、元々の条件が変わる度に「それ以外」のイベントの方も条件の修正が必要になります。
代替案として、ローカル変数でフラグを用意して「変数>=0」の場合にフラグを立てるものとし、次にフラグが立っていない時に実行するイベントを用意すれば疑似的に「それ以外」のイベントとして動作しますが、やや冗長に見えます。
複雑な条件を1つのイベントにまとめて書くと読みにくくなる場合、サブイベントに分けて書くことも可能ですが、サブイベントの階層が深くなるため、後からイベントを追加する時に適切な階層を選択するように注意が必要です。
途中で処理を打ち切りたい場合はフラグが必要になる
前述の「それ以外」イベントの課題と関連しますが、イベントシートにはプログラミング言語のbreakのように処理を打ち切る方法がないため、代わりにフラグを用意して処理をスキップする必要があります。フラグが立った時の処理をサブイベントにすれば、フラグが立っていない時にまとめてスキップさせることが可能になります。
イベントに書いた内容は条件が成立する限り毎フレーム実行される
プレイヤーキャラクターの歩くアニメーションが終わった時に、歩数カウンターを増やしたいとします。もし現在のアニメーション名が"Walk"であることだけを条件に歩数カウンターを増やすイベントを書いた場合、プレイヤーキャラクターのアニメーション名が"Walk"になった直後から毎フレームで歩数カウンターが増加します。この場合、アニメーションが完了したことも条件に追加する必要があります。
イベントが毎フレーム実行される仕様は、イベントシートが大きくなって各イベントに目が届かなくなるほど厄介になります。ひとまとまりの処理をサブイベントにすることで、メインイベントの条件を満たした時だけ実行されるように制御できます。
また、「1回だけ実行」という条件を追加するとイベントが連続して実行されなくなるため便利ですが、意図したタイミングで実行されない場合もあるため、必要に応じてアニメーション終了やタイマーなどの他の条件が使えないか調べてみることも重要です。
ピクセルエディターの挙動が独特
GDevelopのピクセルエディターはレイヤー機能や同色範囲の選択ツールが使えるなど、ゲーム開発環境に付属しているお絵かきソフトとしてはそこそこ高機能なのですが、他のペイントツールと微妙に操作方法が違うので戸惑います。また、画像を複製してから変更した時に他の複製画像まで同じ変更で上書きされてしまうことがあります。
ちょっと調べてみた限りでは、piskelというGDevelopとは全く別の製品が動作しているため、動作に変なところがあってGDevelopチームに指摘しても、piskelの関係者ではないので対応は難しいようです。
最初から画像データの作成は他のペイントツールで行い、アニメーションの作成だけGDevelopで行うことで影響を小さくできますが、統合された開発環境としてのメリットは低下します。
また、ピクセルエディターで画像を作成する際に、早い段階で名前を指定しておかないとNewSprite.png、NewSprite2.png、NewSprite3.png...という具合に自動でファイル名が設定されます。リソースエディタで画像リソースと画像ファイルの関連付けを変えることができるので、画像ファイル名を変更してから画像リソースとの関連付けを再設定することもできますが、次々と作成されるNewSprite.pngに対応するのは大変なので、基本的に放っておくのが一番手間の掛からない対処法です。
イベントシートをデバッグするのが難しい
シーンエディタに様々なオブジェクトを追加したりイベントシートに処理を追加したりと、色々追加しているうちは良いのですが、全てが変な動きをしないようにデバッグするのは難しいです。ある程度の変な動きはあきらめて、自分がゲームの中で重要だと思っている部分に注力した方が効率的かもしれません。
GDevelopのデバッガーは変数の中身を細かく確認できる上に、ゲームを一時停止することもできるので便利ですが、デバッガーで特定のオブジェクトが予期せぬ状態に変わったことは分かっても、その原因を調べるのには苦労します。
同じような管理が必要なオブジェクトはグルーピング機能でまとめて、さらにイベントシートの一部を外部イベントや拡張機能として分離することで、問題の発生個所が見つけやすくなるよう工夫することはできます。
