　私の人生の何パーセントかはＳＲＰＧでできている。学生時代にアホのように遊んだり、独立してからはバカのひとつ覚えのように作ったり、そうした経験は私の血肉になっている。

　過去にさまざまな環境でＳＲＰＧを作ってきたが、いきなり作りはじめるわけではない。プログラムについては、いくつかの小さな部品を作って検証してから、ＳＲＰＧの本格的な開発に入る。今回は、そういった話をする。

　まずはマップの表示と操作だ。標準的なＳＲＰＧは、マップの上で遊ぶ。四角形だったり、六角形だったり、菱形だったり、3Dだったりするが、マップのないＳＲＰＧはほとんどない。このマップの表示ができなければＳＲＰＧを作ることはできない。

　マップの表示については、いくつか検討しなければならないことがある。一つ目は、どのようにマップを組み立てるかだ。一マスが一画像なら簡単だが、初期のファミコンゲームならいざ知らず、それ以降のゲームでは、もう少し複雑な描画をおこなう。

　海のマスの角が丸みを帯びているのを見たことがあるだろうか。マップのデータをもとに、そうした描画をおこなっていく必要がある。具体的にはマップチップと呼ばれる画像を用意して、周囲のマスの繋がりをもとに、自動で適切な画像を選択してレイアウトしていく。

　このマップの表現は、わりと悩ましいところだ。見栄えに直結するが、複雑にすると画像を作るのが大変になる。プログラムは一度書いてしまえば終わりだが、画像は地味に手数が掛かる。地形の分だけ描かないといけない。特に私の場合は、プログラムもグラフィックも一人で作るので、作業時間を多く取ることはできない。どういった方式を採用するのか、毎回けっこう悩む。

　二つ目の検討事項は、画面を超えるサイズのマップをどう表示するかだ。ＳＲＰＧのマップは、基本的に画面よりもサイズが大きい。コントローラーを使うのなら、方向キーによって画面をスクロールさせ、ボタンでマスを選択できる必要がある。また、マウスやタッチで操作するならば、マップをドラッグできて、かつ、各マスをクリックやタッチで選択できる必要がある。

　開発環境の中に、こうした処理を簡単に実現できる仕組みがある場合もあれば、まったくなく、自前で実装しないといけないこともある。いずれにしても一画面で遊べるマップでなければ、マップのスクロールは必ず実装しなければならない。

　三つ目の検討事項は、マップのデータをどう持つかだ。最近のゲーム開発環境ではマップエディターが付いてくることが多い。しかし、私が作るＳＲＰＧでは、直接この仕組みを利用できないことが多い。動的にステージを読み込んだり、アルゴリズムで生成したりするからだ。データをどう持つかを考えて、そこからどうゲーム画面のマップを構築するか決めて、技術的に可能か検証する必要がある。

　マップはＳＲＰＧの最も重要な部品なので、ここができれば、開発のかなりの部分をクリアーしたことになる。

　次に検証するのは、リスト選択画面だ。ＳＲＰＧでは、移動したあとに行動の選択肢をだいたい表示する。そのため、リストを表示して選択する仕組みが必要になる。一画面でリストが収まれば問題は少ないが、数が多いとどう表現するのか考えなければならない。リストをスクロールさせるのか、ページを移動させるのか表現方法はいくつかある。そうした表現が開発環境で簡単に実現できるのかを実験する。

　マップの表示と行動選択ができれば、最低限のウォーシミュレーションゲームの体裁は整う。ユニットを表示したり、移動させたりといった部分は、マップが表示できていれば何とかなるので、そこまで大きな負担ではない。

　次に検証するのは、シーン遷移だ。ほとんどのＳＲＰＧではいくつかの画面を行き来する。タイトル画面、戦場選択画面、戦闘前後の会話画面、マップ画面、戦闘画面、他にもゲームによって数が増える。これらを行き来するのが第一段階だ。

　第二段階は、シーンの上にシーンを被せられるのかを検証する。ＳＲＰＧでは多くの場合、マップ画面の途中で戦闘シーンを呼び出して、ふたたびマップ画面に戻ってくる。その時に、マップ画面を一から再構築するのは面倒だ。そのため、マップシーンの上に戦闘シーンを表示できるのが望ましい。できない場合は、行き来するたびに再構築するが、処理はなるべく簡単な方がよい。ゲーム開発環境の癖を見て、どのように実装するのが楽なのかを調べる必要がある。

　ここまで検証すれば、ＳＲＰＧのプログラムで超えるべきハードルはだいたいクリアーしている。検証用のコードを整理して、実際の開発用のコードを書き始める。

　いちおう、このまま進めば完成するのだが、実際にゲームが動き始めてからプログラムを調整していく大きな部分がもう一つ残っている。それは、敵の思考アルゴリズムだ。

　昔のゲームでは、敵のターンが数分とか十数分とかあっても普通に遊んでいた。でも、今ではさすがに厳しい。敵の１ユニットに使える思考時間は１秒未満だろう。できれば0.1～0.2秒を超えない範囲で計算が終わるのが望ましい。

　ＳＲＰＧの敵のアルゴリズムは、かなり計算量が多い。マップのマス数と自軍敵軍のユニット数によって、組み合わせが爆発的に増える。そのため無駄な計算を刈りこんで、なくしていく必要がある。ただし、人間の目で見て不自然な行動をさせては駄目だ。

　計算の処理時間は、実行するハードウェアや、開発するプログラミング言語によって大きく変わる。ハードウェアに関しては、メモリーが多い環境では使えるアルゴリズムも、メモリーが少ない環境では使えなかったりする。メモリーとＣＰＵのバランスを考えながらトレードオフしたりもする。人間の目で見て不自然でなければ、大胆に計算を省略したりもする。

　そうした部分がＳＲＰＧ開発の醍醐味の一つなのだが、あまり評価されずに地味な部分だったりする。立ち絵のキャラクターのグラフィックが主で、ゲームはおまけみたいな扱いを受けることも多い。某同人販売サイトでも、そうしたことを担当に言われて腹が立った経験がある。

　いろいろとつらつらと書いてきたが、現在こうした技術検証をしている最中なので書いた。今日は、行動リストを表示して、そこから行動を選択するプログラムを書いた。まだダイアログになっていないので、この処理をダイアログとして呼び出して使いやすいように加工する必要がある。そうして、ひとつひとつ部品を作って確かめていき、それらがある程度そろったら本格的なＳＲＰＧ開発に入る。まだまだ道のりは長いが、人生で何度もやってきたことなので完成できることは知っている。

　技術検証が終われば、用意した企画を実現できるのかすりあわせをおこなう。また、作業時間を計算して実現可能な範囲に落とし込んでいく。この作業時間の見積もりを間違うと、完成しないゲームになる。なので可能な限り小さく作り、完成したらリッチな内容に置き換えていく。

　私の場合、全てを一人で作るので、作業時間をいかに圧縮するかが重要になる。だいたい三ヶ月で完成できる範囲というのが目安だ。そのためには画像は二、三週間程度で用意できるように調整する。神絵師と組めば、もう少し開発に時間がさけ、売り上げも上がるのだろうけど、そういうのは無理だしなあ。地道にコツコツとやっていくしかない。

おまけ：

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

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

https://crocro.com/shop/