Godotでシンプルな3マッチパズルゲームを作って公開するまで

Godotの勉強の成果としてシンプルな3マッチパズルゲームを作って公開しましたので、初めてGodotに触れた感想を残しておこうと思います。

当初はGDevelopで作る予定だった

まず、GDevelopで3マッチパズルを作ろうと思って以下の2つのアプローチを考えていました。両方のやり方を試してみて、実装の手間が少ない方を採用する予定でした。

• 一時的な当たり判定オブジェクトを用意して、同色のピースが並んでいるかチェックする瞬間だけ作成と破棄を行う。重力による落下はピースに重力のビヘイビアを設定して実現する。

• パズルゲームの盤面を2次元配列で表現する。同色のチェックや重力による落下は２次元配列を処理することで実現し、パズルのピースは２次元配列の内容に合わせて描画する。

最初に2次元配列を使わない方法を試していたのですが、隣接する同色のピースのチェック処理を途中までイベントシートに書いた時点で、想像以上に複雑になっていました。さらに都合の悪いことに、GDevelopのイベントシートは同じ種類のオブジェクト同士が衝突した時に双方を区別した処理を書くのが難しい問題があるため、継続を断念しました。

次に２次元配列を処理する方法を進めてみましたが、イベントシート内に2次元配列を処理するためのロジックが膨らんでいくにつれて「こういう処理はスクリプトでやった方が良いのでは？」と思うようになりました。そこでGDevelopのJavaScript APIを調べてみたのですが、JavaScriptとGDevelopの間でデータをやりとりする際にコツが必要で、作成中のイベントシートに加えて自作のJavaScriptまで管理するのは負担が大きすぎると思ったので、最初からスクリプトが使える他の開発環境を探すことにしました。

スペックが高くないパソコンでも動作するGodotに決めた

スクリプトが使えるゲーム開発環境を探してみると、やはりUnityが筆頭で、時々GameMaker Studioが挙がりました。Unity関連の記事を見ていくと、2023年の料金体系の騒動がまだ記憶に新しく、そこでGodotが比較対象として出ていました。
Godotについては名前こそ知っていたものの、スクリプトがPythonに似ているとはいえ独自のルールを持っているので、追加で学ぶ時間が必要になる点が気に掛かりました。しかし、様々なツールが統合された開発環境であること、比較的スペックの低いパソコンでも動作することが自分にとって魅力的だったので、最終的にGodotをインストールしました。

しばらくは公式ドキュメントを読む日々

GDevelopを利用し始めた時はシーンエディタを触りながら使い方を覚えましたが、Godotについてはシーンツリーのような根幹技術について理解が必要だと感じたため、当初は余暇に公式ドキュメントを上から読み進めつつ、サンプルゲームやチュートリアル動画を時々見る日々でした。
公式ドキュメントの流れとしては、序盤のGetting startedの時点でサンプルゲームを作りますが、この時点では作ったゲームは動作しても、シーンツリーの使い方が合っているのか判断が付かない状態でした。

やっと3マッチパズル自体の複雑さに気付く

Godotでスプライトに画像ファイルを設定したりGUIを画面に配置したり、といった初歩的な操作に慣れてくると、いよいよスクリプトでパズル部分の処理の実装に取り掛かるわけですが、ここでようやく3マッチパズルの仕組みが見た目よりもずっと複雑だということに気づきました。

• T字やL字のようなパターンを考えだすと途端に処理が複雑になる。どこまでの形を1つのグループとみなすか？
• ピースの組み合わせを表すデータ構造を考える必要がある。可変長配列に同じグループのピースを入れるとして、並ぶ方向がタテかヨコかをどのように表現するか？
• ピースが消せると分かったとしても、即座にピースのデータを削除すると問題がある。例えばL字の場合、タテのラインを先に削除すると、ヨコのラインのピースが2個以下になった時に消せなくなってしまう。
• ピースをまとめて4個以上消した場合に、特別なピースが作成されるようにしたいが、どの位置に配置するのが適切か？ L字やT字の場合はタテとヨコのラインが重なる位置が良さそうだが、プレイヤーが操作したピースの位置に配置するのも良さそうに見える。
• これ以上ピースを動かせない時のルールを決めないと、プレイヤーが途中で遊べなくなってしまう。詰み状態をCPUが判断するのか？ それともプレイヤーが自主的にシャッフルやギブアップを選択するのか？

今回はできるだけ複雑な要素を減らすことを重視した結果、盤面のサイズは5×6で固定、特別な能力を持つピースは3種類だけにしました。(同色のピースをまとめて4個消すとタテまたはヨコに1ライン消すピースが発生、5個以上なら同色のピースをまとめて消す虹色のピースが発生)
また、同色のピースの並び方で特別にサポートする形は、L字とT字だけにしました。もし同色のピースが密集していた場合、虹色のピースが2個以上発生する可能性があります。

Tweenが大活躍

ピースが上から降ってきたり、スワイプで移動したり、あるいは消える直前に色が薄くなる処理や、スコアの上昇まで、動きのある部分はTweenで実装しました。状態変数を用意してフレーム単位で細かい制御をする手間を減らせたのは、Tweenの貢献が大きいです。
特に興味深い利用法はスコアの上昇で、スコアが100増えた時に段階的に加算する処理が簡単に実装できました。

どこに公開するか

UIを付けて見た目を整えて、最低限のBGMとSEも加えて、何とか完成の目途が立ちました。後は公開する場所です。GDevelopの場合は手軽にアップロードできるgd.gamesがありましたが、Godotの場合はitch.ioような公開先を探して登録するか、自前でセットアップする必要があります。
当初はGoogle Cloudに静的ファイルとして配置することも考えていましたが、調べていくうちに思った以上に設定が面倒な感じだったので、改めて公開できる場所を探すことにしました。
たまたま検索にヒットしたのがGodotPlayerで、ありがたいことにGodotの30MB以上あるランタイムを含めたHTMLファイル一式をアップロードして公開することができました。

これから

今回はGodotを利用しましたが、開発環境やエンジンごとに強みが違うので、またやりたいことがあったら改めてツールを探すところから始めます。