NUAO流ゲーム制作工程
PB-100はメモリや画面の制約があり得ないほどキツイですが、逆にフィールドが狭い分結果が早く出せて、達成感を味わえます。NUAOのようにビール片手のなんちゃってプログラミング趣味にはぴったりのプラットフォームです。ご参考に、NUAO流ゲーム制作の流れについて、ご紹介します。
１コアになるゲームネタを考える
まず、PB-100の規模感にマッチしそうなネタが降りてくるかどうか。ふとした時に閃くもので、OPE:YASHIMAはヤシマ作戦のBGMがTVで流れたときに降りてきました。SONAR ARRAYは、ミリネタ見てて「フェーズドアレイ」って名前がカッコええなぁと思ったのがきっかけです。ただし、Auyan-Tepuiは、マンデルブロ集合が何とかゲームにならないかと、かなり強引に仕立てました。。
２画面デザインを考える
PB-100ゲームでは最初にこれが来ると思います。一行12桁キャラクタのみというショボイ画面で、ピンと来るゲーム画面ができそうになければ、即刻ボツです。例えばXANADU PBは、Ixchelが「≧」で、Camazotzが「A_」で十分表現できると踏んだことが、開発着手の決め手となりました。
OPE:YASHIMAの画面デザイン
３データ構造を考える
PB-100で最も苦しむのが変数の少なさです。標準ではアルファベット26個+$の27個のみ。例えばRPGなら、最低でも自分の位置・体力・レベル・お金・装備といったパラメータが必要で、敵にも設定するならその倍です。それだけで変数を大半使ってしまいます。またローカル変数の概念がないため、サブルーチンで競合しないよう入出力変数の確保も必要です。整数部と小数部に情報を分けて入れたり、符号にフラグの意味を持たせるなどの工夫もします。きちんとした変数表を手元に置くこと、サブルーチンでの入出力と破壊変数を書き出しておくことが、バグを防ぐコツかと思います。
なお、ボードゲーム(盤面データ)やRPG(マップデータ)などメモリを大量に消費するゲームでは、データ構造の目途を立てることが、開発可否の判断基準になります。OstlePBでは、１マスの状態として「空／白／黒／穴」の４通りしかないので、最小２ビットで表現できるはず。一手先読みの為仮盤面用メモリも必要なので、データ圧縮することにしました。その代わり速度は犠牲になりましたが。
４一番「キモ」になりそうな部分についてテストプログラムを作ってみる
一番キャッチーな部分がイメージ通りの動きになるか、またアルゴリズムが肝のゲームではコアとなるロジックがモノになりそうか、テストプログラムで試して判断します。OPE:YASHIMAでは加速空洞の動き、SONAR ARRAYでは波形表示、Auyan-Tepuiでは地形表示部分です。The MAZEやOstlePBなどはデータ圧縮や思考ルーチンなどです。ここで気持ちよい動きができると、俄然制作モチベーションにスイッチが入ります。
Dq+pBのダンジョン計算式テスト(EXCEL)
５トップダウンでフローチャートを書く
拡張メモリを使用するような規模の大きい？ゲームの場合は、処理の流れも複雑になりがち。面倒ですが最初にフローチャートをしっかり書いておいた方が、スパゲッティ化が防げて結局早くコーディングが進み、美しく満足度の高いプログラムになります。最初は「スタート→表示→入力→移動→判定→繰り返し」ぐらい大雑把でもよく、アイデアが煮詰まってきたら各プロセスをさらに細分化します。
OPE:YASHIMAのフローチャートと変数表
６変数表を用意し、フローチャートを見ながら、コードを書き始める
行き当たりばったりで変数をアサインしていくと、気持ち悪いリストになります。座標系、ループカウンタ系、一時変数系など、使いそうなものはある程度最初に割り振っておき、変数表に書き出しておくとスムーズです。必ず新たな変数が必要になるので、空きを確保しておきます。フローチャートと変数表を手元において、コードを書き始めます。
７テストプレイ／デバッグする
フローチャートの最後までコーディングできたらテストプレイしてみますが、まず動かないのでデバッグします。基本的にPBでは、要所要所にSTOP命令を挿入して、その時点での変数の値が想定通りかどうかチェックする、という作業を繰り返します。その際、PB-SIMのTR機能を使うと、全変数の値が一覧表示され大変便利です（但し表示が小さくて老眼には厳しい）。昔は本体だけでデバッグしていたのですね。すごい。
バグの出るパターンは大体決まっていて、（アルゴリズム以外では）サブルーチン内で変数が競合／配列変数と固定変数が競合／MID関数やCSR関数の値が範囲外／IF文のネストで想定外の処理流れ込み／ゼロ割り算…など。
なお、実機とPB-SIMとPokecom GOでエラーの出方が結構違うので、３つとも流してみて、どれも動くように修正する場面が多いです。
PB-SIMのTR機能
８プログラムリストのシェイプアップ
PB-100プログラムは普通PB-SIM上で開発しますが、大概サイズオーバーしています。できればPB-100標準の544steps、大きくてもメモリ拡張時の1,568stepsに収めたいので、贅肉落としです。ここがPB-100プログラミングの山場、醍醐味といえる部分で、先人はいろいろなテクニックを開発しており、それらを参考に1step、また1stepと削減していきます。数十steps程度のオーバーは何とかなることが多いです。百steps単位の削減は、仕様やデータ構造やアルゴリズムの変更が必要です。
よくある小技としては、複数行をマルチステートメントに置き換え（2steps削減）／キースキャンを一般文字変数でなく$変数で実施／行番号を小さい桁数にリナンバー／関数の閉じカッコ省略、など。高度なものはIF文の関数化など。なお、PB-100はジャンプ先行番号を計算式にできたり、配列変数のポインタやCSR、MID関数指定が小数でもよいというスゴイ仕様なので、フル活用します。
９ キーとなるイラストを作成する
デバッグでバグが取れたら開発も終盤で、作品を紹介するHP制作という楽しい作業に入ります。NUAOは絵は下手クソなのですが、それでも何か一つキービジュアルが欲しい。で、娘に教わったibisPaintというスマホ無料お絵描きソフトでイラストを描くようになりました。いくらでも拡大して何度でも書き直しが効くので、そのうちそれなりなイラストが出来てくるので面白いです。また、取説とHP用にプレイ画面のスクリーンショットも取っておきます。
10 設定を考える
ゲームに設定は重要です。RPGでは何故冒険に行くのか、何を目指すのかの物語が必要です。参考にするため、Dq+pBではSwitch版のDQ1,2,3をかじってみました。SONAR ARRAYでは沈黙の艦隊を見返しました。OPE:YASHIMAでは、マクロな技術考証を実施しました。加速器関係の論文をいくつか読み込み、キーパラメータを設定。またエネルギー保存則を守りつつ、原作の設定(1億8000万kW)と辻褄が合うように陽電子数を決めています（E=mc^2も使ってます）。設定書作成にあたっては、先ずChatGPTにお願いしてから、それっぽく肉付けしました。
OPE:YASHIMAマクロ技術考証
11 プログラム説明書を作成する
作成したイラストとスクリーンショットと設定をちりばめつつ、Wordでプログラム説明書を作成します。バナー部分は横173mm×縦75mmで作り、DAISOハードケースにぴったりなゲームカードにできるようデザインします。変数アサイン表とプログラム解説を付け、フローチャートを作成しているときはそれも添付します。出来上がったらPDF化しておきます。
12 ホームページ更新のための打ち込み
当ホームページに載せるための打ち込みです。NUAOは初心者ですので、google sitesというのを使っていますが、画面のアレンジの種類が乏しいのが不満です。あと、いつまでたってもGoogleのインデックスに登録されないのは何故？ いくら調べてもわかりません。どうすればクロールされるのか、誰か教えて下さい！
13 ホームページで公開し、TwitterでPRする
せっかく作ったゲームなので、希少なポケコンおやじ(失礼)の皆さんの目に触れるよう、HPに載せ、Twitterで紹介します。最近は毎月１日にアップデートする感じです。ただ、普通、他人が作ったPBゲームは「ふーん」程度でわざわざ読み込んでプレイしないですよね。でもそれでもいいんです。PBはプレイするより作ること自体がパズルみたいで面白いんです。
14 Googleアナリティクスでアクセス状況をチェックする
公開した後は、こっそりGoogleアナリティクス（HPアクセス状況分析ツール？）でHPのアクセス状況をチェックします。「お？東京からだ」とか「へー、この話題はみんな興味あるんだな」とか、なかなか面白いです。ただ、HPを更新すると告知しなくてもアクセスが伸びるのは何故だろう？ 何か更新フラグが立つのかな？