おちゃめくらぶ掲示板 - 1659321896

1026：御茶目菜子：2012/05/20(日) 20:55:21: 1画面プログラムはただの自己満足なのか・・・？
久々にプチコンの1画面ゲームを作ったにょ。
前回は2分の1画面の「CAVE」だったけどこちらはGCOPYの練習用に作ったのでサイトの方
では未公開になっているからね。（GCOPYを使ったスクロール講座のサンプルプログラムと
して使用予定）
作ったのはすでに公開している「JUMPING ISLAND」の1画面版にょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/1page.htm#jump
http://www.youtube.com/watch?v=GrXhXcq_oaE

JUMPING ISLANDは当初は1画面プログラムとして作る予定だったけど基本動作部分だけでも
約1KBに達したため1画面化は諦めてその分1画面では妥協していたmkIIのホームメニュー
からの操作を可能にしたり（ゲームオーバー時にそのまま終わるのではなくリトライ機能を
付けるということ）、多少は見た目に拘ったり、そして何より1画面では真っ先に不要として
削られた各ステージごとのハイスコアセーブ機能も搭載したにょ。
そうやっていろいろ付け足していったら結局1.9KBにまでサイズがふくらんでしまったにょ。
これでリプレイデータの記録（セーブ、ロード付き）を付け加えた場合にはリプレイ対応
バージョンを見てのようにそれだけでさらに1KBも増えてしまうにょ。
100バイト削るのは非常に大変だけど1KBバイト増えるのはあっと言う間ということにょ。

だからこそ私は極力余分な機能を搭載しないようにしているにょ。
これによって公開時のQRコード枚数が抑えられるというのも1つの狙いにはなるけど実際の
ところQRコードにする場合にはzip圧縮がかかるためリスト短縮をしてリストサイズを
かなり削ってもQRコードの枚数にはそれほどの違いを見ることはできないにょ。
コピペで貼り付けたような無駄がありまくるプログラムは結構圧縮がかかるためリスト
サイズの割にはQRコードの枚数はそれほど増えないからね。

とはいえ、プチコンの保存領域は有限であるためサイズを抑えること自体は意味があるにょ。
QRコードとして出力する場合には圧縮がかかるけど本体の記録時には無圧縮だからね。
プチコンの合計保存領域が具体的にどれくらいあるのかは分からないけど1つ48KBのGRP
リソースファイルを数10個記録したらいっぱいになるみたいなので数MB程度と思われるにょ。
これは自分で作ったもののみを保存する場合にはGRPリソースファイルを多く保存しない
限りはそれほど問題はない（セーブデータにGRPを使ったりお絵かきプログラムを作って
それでGRP保存していたらすぐに無くなる可能性はある）けれどmkIIではQRコード経由で
多くの人のプログラムを簡単に取り込むことができるからね。
48KBのQRコードというのは何枚くらいかというと上記のように圧縮がかかる関係上何とも
いえないにょ。
30枚くらいになる場合もあるし、セーブデータで一部のみを使ったものならば1枚～数枚で
収まる場合もあるからね。

しかし、QRコードの枚数にかかわらずプチコン内部ではGRPリソースファイルは48KBの
領域を占有されるにょ。
CHRリソース（SPUやBGUなど）はGRPよりは小さいとはいえそれでも1つ8KBあるにょ。
これは1つ～数個のスプライトキャラをセーブしてもこの量になるため極力リソースファイル
としての保存は避けたいところにょ。
リストサイズが小さいプログラムであってもこのようにリソースファイルが別途必要な場合
には保存のための領域が増えてしまうため結果としてはリストサイズが大きくなっても
リスト内でキャラ定義をした方がトータルのサイズでは抑えられることがあるにょ。
リストサイズ2KBでもSPUが1つ（8KB）必要ならばトータルで10KBとなり、リスト内で定義
した場合にはリストサイズが5KBになった場合でもそちらの方が2KBのリストよりファイル
サイズは小さいということにょ。
私が作ったJUMPING ISLANDはそういうものもケチりまくっているため1.9KBに抑えながら
それ以外は何も無いためトータルで1.9KBという非常にコンパクト仕様にょ。

さて、そのコンパクトサイズのJUMPING ISLANDを今回1画面プログラムにするためにさらに
コンパクトにする必要があるのだけど元々1画面プログラム並のリスト短縮をしていたため
「どうやってリスト短縮をするか」ではなく「どの機能を削るか」ということが非常に
重要になってくるにょ。
1画面というとプチコンの編集画面は29文字×24行であるため「トータルで696バイト以下」
に抑えればいいと考えるかもしれないけどプチコンの編集画面は1行の折り返し機能がない
ために「すべての行は29文字以下に抑える」という必要があるにょ。
プチコンではラベルを使った場合にはそのラベルのある行には他の命令文は書けない
仕様になっているためラベルジャンプ（GOTO、GOSUB）を使用するのはは1画面プログラム
ではかなりの無駄になってしまうにょ。
そして、引数が多い命令文やIF文などは29文字に抑えるのが難しいため分割して記述する
必要があるのでリスト短縮をするどころか逆にリストは冗長になる部分さえあるにょ。
そうなると冒頭に書いたように基本動作部分だけで約1KBもあるという状態から1画面に
抑えるということがどれだけ難しいかが分かってもらえると思うにょ。

私は1画面プログラムを作る際には「リスト短縮時には1画面に収まりそうなもの」を
想定したゲームを予め作っているにょ。（普通に作ったものをリスト短縮を行い1行
29文字という制約を元に命令の配置などを入れ替えることで1画面化を行っている）
しかし、5月6日に書いたようにこのJUMPING ISLANDでは元になった横スクロールジャンプ
アクションゲームの不満点を解消しようとしていたら必然的にサイズが膨らんだにょ。
つまり、リストサイズよりゲームデザインを優先した結果そうなったということにょ。
といっても、1画面に収まるか否かというレベルの問題であり、一般的な視点で見れば
十分にシンプルなゲームなんだけどね。

その基本動作から何を省略するかだけどその1つの候補になりそうなのがステージ選択
画面にょ。
これを削っても数10バイトしか短くならないといっても1画面プログラムにおいてそれは
極めて大きいにょ。
しかし、私はこれを削ることはやめて他の部分を地道に削っていったにょ。
というのも、このゲームはステージ自動生成がウリの1つだからね。
単にプログラムリストにおいて変数Kに入っている開始ステージをを書き換えるだけで
良くてステージそのものは自動生成とはいえ、間に人間の手が加わっていれば自動と
見なせないのでこのステージ選択画面は何とか死守したにょ。
キー入力待ちを作るためにはFOR～NEXTを余分に入れる必要があるけど1画面プログラムを
作る場合にはFOR～NEXTのわずか10数バイトさえかなりの量に感じてしまうにょ。
しかし、ここでスプライト定義部分と兼用することで一気に解決できたにょ。
当たり判定はフルバージョンでは4カ所で判定していたのを2カ所に削減していたり、
SPHOMEの設定を省略しているため拡大時の座標は若干ずれているなどの妥協している部分
こそあるけど何とか必要最小限のものを1画面に収めることができたにょ。
mkIIのホームメニューからのプレイ対応は残念ながらできなかったけどそれ以外は自分
でもいい感じになったと思っているにょ。

とはいうものの、先にフルバージョンを作っている関係上1画面版の需要はほとんど
無さそうにょ（笑）
フルバージョンがサイズがでかいかというとそんなこともなくわずか1.9KBだからね。
ハイスコア保存機能もない1画面版の方はそれほどハイスコア競争に熱くなれないだろうし
スコア計算式も簡略化しているためその影響でフルバージョンほどハイスコア競争には
それほどシビアさが要求されないにょ。（先読みジャンプの必要性はない）
まぁフルバージョンより当たり判定が厳しくなっているからフルバージョンでは簡単と
いう人にはいいかもしれないけどやっぱりこのゲームの1画面化は単なる自己満足でしか
ないと思うにょ。

時間がかかったわりに需要が無さそうなこのJUMPING ISLAND（1画面版）に対して1週間
ほど前にわずか3時間で適当に作った「リンクスライダー」（TVアニメ「ファイブレイン」
に出てきた対戦型パズルの方が反応がいいからね。（「適当に作った」というのはあまり
時間をかけずに作り、リスト短縮などのテクニックをほとんど使用していないという意味）
この「リンクスライダー」はまだサイト上では公開していないものの1週間前にtwitterで
公開してからリツイート28人、お気に入り登録26人の延べ54件の反応があったにょ。
近いうちにこちらも正式公開することにするにょ。（ファイブレインのハッシュタグは
付けておらずプチコンのハッシュタグのみだったのになぜこんなに反応があったのやら）