PC作れるようにしたり、シート見られるようにしたり、レベルエディタを作りかけていたり。

うーん。

まだゲームらしい要素は何もなく、下地を作っているにも関わらずコード量が肥大化しているのが懸念事項か。1プログラムあたりの最大行数9999行の既に1/3近くを使ってしまっている。コード以外のデータは極力コード外に追い出すようにしないと間違いなく不足はするだろう。出来るならば、極力スクリプトエンジン化してしまってゲーム進行は全部コード外にしてしまいたいところだが。
あと、マジックナンバーを減らすためにenumのような変数を定義しまくっているのだが、これも結構洒落にならない行数を食っているのでなんとかしたい。その辺のconstantな変数や配列を宣言しまくって初期化したプログラムを分けておいて最初にロード、次に本体プログラムはCLEARせずにロード、とかをやれば比較的まともに解決できそうだが、その辺の切羽詰まったやり方は最大行数に到達したら考えよう。

また、今の段階で既にコードの可読性がやばそうだったので一旦整理。
ラベル分布リストをPC上に作成する（出来れば変数もやりたいのだが、更新が面倒なのでパス）。
検索移動用のラベルを埋め込む。似た処理や続いて呼ばれるサブルーチンの配置をまとめる。更新頻度の低いサブルーチンは下の方に配置する。
変数やラベルの命名規則をガチガチに固めてしまう。グローバルに触られる変数にはprefixをつける。いわゆるローカル変数（呼び出し元や呼び出し先で弄られても影響がない変数）にはアンダースコアをつける。などなど。
プチコンではコピペが1行ずつしかできないので、一旦PC上で作業した方が良いですね。

さて、ぼちぼちと戦闘周りにとりかかっているが、ちょっとエンカウント処理を作ってみて、毎回起動の度にPCを作らんと駄目なのが面倒すぎるなということで、戦闘よりも先にセーブ/ロード周りを作らないと駄目そう。
プチコンのセーブメモリーのMEM$は255文字までなので、PC情報*PC人数+システム情報を詰めなければならないことを考慮すると、ビット単位で詰めていったとしても入りきるかどうかはかなり怪しい。
GRP領域をメモリとして割り当ててしまえば、かなりの量が確保できるが、余計に書き込み読み出しを作る必要があるのと、最終的に利用するセーブデータ量が未だ不明なので、分割して保存することを考える。MEM$なりGRP1個に収まるのならば、後でくっつけてしまえばいいわけで。
LOADは確認ダイアログを省略できるが、SAVEは確認ダイアログが必ず出るので、ダイアログ出まくりでうぜえということになるかどうかは要検証。
やるつもりはないけれど、PCロスト即セーブというのもダイアログが出るので無理なのよね。

え、続けるの？
がっつりと時間が確保できるわけではないのでぼちぼちと。進捗報告的な。

一人称視点の描き換えのちらつきと遅さは結構解消されて、10フレーム前後でちらつきも無しに。なんとかなりそう。
ただやはり、描き換えるタイルを減らそうと、差分のみ描き換えしようとしたりすると、比較が増えてかえって重たくなるのは変わらないようで。
奥から順に上書きしていっているのを、手前から描くように変更してして稼ぐやり方も、同様の理由から厳しい。これがうまくいくと、もっと軽くなる見込みだし、時折遮蔽されている奥のものが微妙にはみ出していたりするのが防げるのだが。これを諦めて、はみ出ないような絵素材にするしかないのかね。

テスト用の小規模なレベルもなんなので、どこかで見たことがあるようなレベルをちくちくと打ち込んだり。専用のレベルエディタが無いとしんどいことが分かったので、これまた作る必要がありそう。
オートマッピングは多分無しな気がする。
レベルの大きさは通行したかどうかを記録するのならば16×16が効率的で良さそう？

さっさとPCまわりを作ってみたいのだが、それにはまずテキストボックスを作らないと、ということで、チマチマと作る。
文字は横に32文字（枠で2文字分減るので実際は30文字）しかないので、定番のPC一覧表示も情報を切り詰めないと厳しそうだ。
重ねても破綻しないようにしたり、自動改行とか自動サイズ調整など。禁則処理は後回し。選択決定したりする部分も、なるべく汎用的に使い回せるように書いてみる。出来ればタッチ操作でやってしまいたいところだが、面倒なのはもとより、文字サイズが8×8しかないので押しにくかろうということで見送り気味。
ううむ、先は長い。

それはそうと、文字数取得でL=LEN(LINE$(IDX))とかやっていると、時々syntax errorとなるのは何でだろう。全く同じコードで全く同じ文字列を渡しているのに。プチコンmkII本体の未初期化なニオイがする。

グラフィック機能に関しては先のあれで大体触ったので、スプライトとBGも触る。

スプライトは、スプライトという言葉が形骸化して、ただの2Dを示すようになって以降の方が馴染みがあるので使い勝手に関してはなんともかんとも。メモリにゴリゴリと色を書き込んでいる感覚のある、グラフィック機能の方が好きかな。
サンプルなどでは固定値でN個確保してやっているのですが、これをフレキシブルに管理してみたいので、生成・破棄関数作って空きスプライトの番号を探してとるとかいうマネージメントをやってみたりするも、100個の使用状況を舐めて比較したあたりで処理落ちしだしたのであえなく終了。必要最小限に小分けするべし。
スプライト100個全部出し切って、無茶できるようになってほしいものです。

BGは、BGだけでFPVが表現できるのかなと試す。
これは全部プリセットを使っていますが、自分でキャラとパレットの定義をしないと駄目ですね。洋ゲー臭いドットと色遣いにしたいところです。ドット打てませんが。
BGは8×8単位なので、場所によっては斜めの壁と正面の壁の繋ぎ目がどうしてもずれたりするので、ちゃんと不自然に見えないようにLODを作らないと駄目なようです。
あとBGは変に工夫するよりも、そのまま出してしまう方がかえって高速なのが曲者な気がします。高速とはいっても、流石にこれだけの書き換えはすぐには終わらず、書き換えるタイミングで見えてはいけない部分が見えてしまうので、レベルの構造がばれて台無しに。かといって、一旦バッファに番号を書きだして差分だけを書き換えるとかもやってみたのですが、比較処理が増えてかなり重たくなってしまうという。
画面全部を使ったこの手のゲームがあの時代になかったように、描画サイズをこれ以上に小さくしていまえば楽ですが、それは最終手段ということで高速化の研究が必要なようです。画面サイズの倍以上BGの描画領域があるので、この余白を使わない手は無いといったところでしょうか。

しかしながら、この手の古い表現は失われていってるので、新規でアルゴリズムを考えるのに等しいのでなかなか大変ですね。今ならポリゴン置くだけで正確に描画できるし。サンプルでもラインで描画しているものがありますが、なかなか力業でやってるんだなあと。

ちなみに私はこの手の超古典的なRPGはかじった程度で碌にやったことはないので、このまま投げ出さずに出来上がっていくとどんなものができるのか、色んな意味でちょっと楽しみです（妄想しながら）。