SRPG開発戦記

第6話 マップのデータ作り

　何度も２ＤのＳＲＰＧを作っているが、毎回悩むのはデータ構造だ。ＳＲＰＧはマップに付随する情報が多く、「地形の見た目」「地形の情報」「ユニットの初期位置」は最低限必要になる。

　「地形の見た目」は、画面に表示されるマップの見た目だ。レイヤー構造になっていれば1マスあたり複数回の描画が必要になる。また、そうした構造になっている場合には、実際のゲームでどの土地なのかを表す「地形の情報」が別途必要になる。

　最近私がゲームを作るときは、「Tiled」でレイヤーを伴ったマップを作り、それを「Node.js」で変換してゲーム用のJSONファイルにすることが多い。なぜ「Node.js」を使うかと言うと、私のプライマリープログラミング言語がJavaScriptだからだ。「Node.js」を使ってプログラムを書くと、最も短い時間で処理を書くことができる。

　今日は、この「Tiled」→「Node.js」→「Godot」と連携する部分のプログラムを書いた。「Godot」を触っていて思ったのが、「なるべくGodotで記述するプログラムは減らした方がよい」ということだ。普通のプログラミング言語によくある処理の書き方を探すコストが高く、無駄に時間を浪費する。なので可能な限り外部でデータを整えて、「Godot」の処理を少なくするのが得策だと感じている。

　「ユニットの初期位置」については毎回悩ましい。「Tiled」のようなマップエディターには、こうしたユニットの配置機能は付いていない。そこで私が採用しているのは、自軍は青、敵軍は赤の数字が並んでいるタイルを使うことだ。自軍1、自軍2、自軍3……と表示されるタイルを配置することで、そのタイル位置をユニットの配置位置に変換して読み取るようにしている。

　この部分は、文章で書いても分かり難いと思う。本来は、専用のＳＲＰＧマップエディターを作るのが望ましいが、それは割愛している。何せ全てを1人でやっているので省コストで臨まなければならないからだ。そこで本来とは違う用途で既存ツールを使い、誤魔化しながらやり繰りしている。

　ユニットのデータ自体は、「Excel」に書いている。こちらも「Node.js」用に書いたプログラムで情報を読み取り、ゲームに使うデータにコンバートしている。初期の頃から「Excel」はＳＲＰＧ作りに多用している。ＳＲＰＧは表でデータを管理することが多いからだ。

　ユニットの情報は、マップ内に全て埋め込むことは難しい。私が作るＳＲＰＧでは、敵ユニットの行動は、半分アルゴリズム、半分手動で設定しているからだ。敵には思考アルゴリズムを補助するいくつかのパラメータを設けている。毎回設定しているパラメータは「巡回先のマスの配列」、「防衛拠点のマスの情報」、「優先的に狙う敵の種類」、「索敵範囲」などだ。

　前回作ったＳＲＰＧでは、「群」を表現したかったので、親ユニットを設定できるようにして、その親ユニットに対してどの場所に陣取るかを設定可能にした。たとえば、親ユニットに対して前面に位置取るか、側面に位置取るか、背面に位置取るかといった情報を設定できるようにした。そうしたパラメータを設けることで、「群」で襲撃する動きを表現した。

　ＳＲＰＧのマップには、マップの情報だけでなく、その中で動くユニットの情報も必要になる。そうしたものを統合して表現できるマップエディターがあれば便利だが、作るゲームごとにパラメータもアルゴリズムも違うので、なかなか統一的なものは作れない。仮に作れたとして、コストが高くなるので簡単に手を出すことはできない。

　プログラムを書きながら、どういったデータ構造にするか、どうすればプログラム内で処理しやすいか、そうしたことを考えながら、上手い落とし所を見つけていかなければならない。

　だいたい、プログラムが長大になる時は、そもそもの設計が間違っていることが多い。なるべくシンプルなデータで、なるべく簡潔な処理で、ユーザーには複雑性が高くて妥当な動きに見える必要がある。そのために知恵を絞るのは大変だが楽しい。

　本当に「シンプル・イズ・ベスト」と「ユーザーが喜ぶ複雑性」を両立させるのは難しい。そこがまあ、ゲーム作りの醍醐味だと思うのだが。

　また今日は、マップの画像をいろいろと作成した。デザイナーがいればよいのだが、自分しかいないので、ちまちまと毎回画像を作っている。

　しかし本当に売るためには「キャラ絵」だよなあ。そこが一番ハードルが高い。

おまけ：

いろいろな同人誌や、ゲームを作って公開しています。ぜひ見てください。

最近、ゲームブックも書きました。遊んでください。

https://crocro.com/shop/