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

1334：御茶目菜子：2012/10/03(水) 23:13:29: プチコンで1画面プログラムを作ろう
ここでも何度か採り上げたMONOistのプチコン講座「プチコン虎の穴」だけど第6回となる
今回は1画面プログラムについて書かれているにょ。
http://monoist.atmarkit.co.jp/mn/articles/1210/03/news004.html
まさか公式で1画面プログラムを薦めてくるとは思わなかったにょ（笑）
今回は工夫してリストを短くする方法が書いてあり、普通に作ったプログラムを1画面にして
それでかなり余裕があるので3行プログラムにしているにょ。
ラストに記載されたリストもまだまだ短縮できるのだけど初心者向けとして考えるならば
まぁこんなものかもしれないにょ。（例えば Y=Y-(Y>0)*(B<=0)+(B>0)*(Y<23)の部分は
Y=Y-!B*!!Y+!!B*(Y<23)とすることができる）

私はプチコンでは1画面プログラムをメインに作っているにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/1page.htm
というか、元々プチコンを買ったのは1画面プログラムを作るためだしね（笑）
といっても、発売日にプチコンを買ったのではなくDS Liteしか持っていなかった関係上
「3DSが対応したら買おう」「ピンクが出たら3DSを買おう」と考えていたのでプチコンを
買ったのは昨年の10月末にょ。
なぜ1画面プログラムかというとプチコンは高性能すぎてやろうと思えば（かつて8ビット機
で制作されたレベルのゲームならば）BASICで何でも作れてしまうからにょ。
80年代からポケコンを使っていた私だけどポケコンの高性能化によってできることがどんどん
増えた反面で制作の負担も増えていったにょ。
そこで徐々に「短くておもしろいゲーム」を作る方にシフトしていったにょ。
そういう過程があってプチコンが発売されたため大作は他の人にまかせ短いプログラムしか
興味が沸かなかったにょ。（というか、初代プチコンではリストを発表する手間が大変
だったり、発表されたゲームはすべて手入力だったので入力する側にとってもその方が都合が
いいと考えた）

「短いプログラム」というのならば1行プログラムでもいいかもしれないけどプチコンの場合は
エディタに折り返し機能がないため初代プチコンで発表する場合には編集画面の写真を1枚
撮影するだけでいい1画面プログラムがベストだと考えたにょ。
ポケコンで限界にチャレンジしていた私としても1画面に隙間無く埋め尽くされたコードは
芸術的に感じたからね。
それにPB-100が544バイト、PC-E500の2行プログラムが512バイト（改行コードや行番号を
含む）ということで500バイトくらいあれば大抵のジャンルは作れるということが分かって
いたため最大696文字（改行コードは含まず）のプチコンの1画面プログラムならば工夫次第
で何とでもなると思ったからにょ。

ここまで読んでくれた人ならば少しは1画面プログラムに興味が出ていると思うにょ。
もしくは、すでに1画面プログラムを作った経験がある人かもしれないにょ。
プチコンで1画面プログラムを作った経験がある人ならば良く分かるけど最初の難関となる
のが1画面にいかに収めるのかということにょ。
上記のようにプチコンの編集画面では折り返し機能がないため29文字×24行（＝696文字）
という制限は1行あたり最大29文字という制限にもなっているからにょ。
これがどういう意味かというと696文字をフルに使うということは極めて困難ということにょ。
そのため主に次のような問題が発生するにょ。

　(1)ラベルを使ったらその後には何も書けない
　(2)引数が多い命令や関数の後にはスペースが空きやすい
　(3)条件が複雑なIF文や複雑な式は29文字に収まらない

(1)これはプチコンの仕様であり1画面プログラムなどの行数制限のあるプログラムにおいては
「ラベルを使わない」というものが基本となるにょ。
つまり、上記のリンク先のプチコン虎の穴のようにFOR～NEXTを使ったループによって動作
させることが求められてくるにょ。

(2)引数が多くしかもそれが省略できない命令なるとGCOPY命令やGPUTCHR命令などが挙げ
られるにょ。
引数の桁数によっては1行に収まらない場合さえあるからね。
それを別の変数に入れて1行に収めたとしても行末は数文字分空く程度なので別の処理を
入れるということは困難になり、必然的に引数の多い命令の後にはどんどん空白ができて
いくことになるにょ。

(3)そもそも1つの処理が29文字以内に収まらないと1画面プログラムとして成立しないため
IF文は論理式などを使い短くする必要があるにょ。
論理式もまた別の式を使うことで短くできるとはいえ、場合によってはIF文を使ったものが
一番短い場合もあるにょ。（THEN以下の処理内容による）
しかし、どうしても1つの行に収まらない処理は多少長くなっても複数の行に分ける必要が
出てくるにょ。
この辺が1画面プログラムが1行プログラム、3行プログラムと大きく異なる点にょ。

したがって、1画面プログラムを作るのに必要なのはまずはリスト短縮のための知識にょ。
これは決して難しいものではなく私が過去の経験で蓄積したものを下記のページにまとめて
いるのでそれを参考にしてもらえたらいいのではないかと思うにょ。

　◎プログラムリスト短縮テクニック
　　http://ww5.tiki.ne.jp/~ochame/petitcom/tips/list.htm
　◎剰余を使ったリスト短縮テクニック
　　http://ww5.tiki.ne.jp/~ochame/petitcom/tips/mod.htm

ただし、リスト短縮テクニックだけではすぐに限界が訪れるにょ。
私の経験上リスト短縮テクニックを駆使してもせいぜい2～3割短くなるくらいだからね。
3割短くなるならば元が1000文字を切るプログラムは700文字を切るレベルになり1画面に
収まると思いきや実際のところ上記の(2)や(3)の問題があるためどうしても行末には
スペースが空いてしまうにょ。
1行あたり5文字分空いたとしたら5文字x24行＝120文字が無駄になるにょ。
これは全体の17％を無駄にしているということにょ。
普通に作れば5文字どころかもっと空く場合もあり、下手をすると2割以上のスペースが
無駄になるにょ。
上記では2～3割のリスト短縮ができると書いたけどそこまでやるにはかなりの経験が必要
となるため実際は2割の短縮さえできない可能性も高いにょ。
そうなると最初の段階（1画面にする前の段階）で700文字を下回らないとリスト短縮をしても
1画面に収まらないことになるにょ。
それならば行末が空かないようにすればいいと考えるかもしれないけどそのためには
すべての処理の内容や必要な順番を把握してその処理をできるだけ細かい単位に分解して
依存性のない処理の並び替えを行いパズルのように処理をはめていけばいいにょ。
とはいえ、これは経験によって会得しないと難しいため具体的な方法についてはケースバイ
ケースとなるので別の機会に改めて書くことにするにょ。

実際にどのように1画面プログラムを作っていけばいいのかは実例を挙げるのが一番なので
私がプチコン大喜利に投稿した作品「PETIT RUN mkII」について書いてみるにょ。
とはいえ、これはいきなりできたわけではなく初代プチコンで作った「PETIT RUN」を
ベースに作りなおしたものであるためまずはそちらから見ていくにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/1page.htm#prun
というわけで、PETIT RUNのメイキングについて少し（というかやや長目？）書いていくにょ。

「PETIT RUN」は疑似3Dレースゲームなんだけどさらにその原点となったのは11年前に私が
ポケコン（PC-E650）用に作った疑似3Dレースゲーム「3D DRIVING」にょ。（このゲームは
ベーマガに投稿前にポケコン側の問題でリストを失ったためリストは現存していない）
プチコンで疑似3Dゲームを作る方法はプチコン講座第5回、第6回に書いているので詳しくは
そちらを参照して欲しいにょ。

　◎プチコン講座　第5回　疑似3Dゲームを作ろう（スキーゲーム編）
　　　　　　　　　http://ww5.tiki.ne.jp/~ochame/petitcom/p005.htm
　◎プチコン講座　第6回　疑似3Dゲームを作ろう（レースゲーム編）
　　　　　　　　　http://ww5.tiki.ne.jp/~ochame/petitcom/p006.htm

1画面で作るためにはまずは「普通に作れる」ということが前提条件であり、そしてそれを
1画面で収まる内容にしていくことが必要になってくるにょ。
したがって、上記のように最初の段階で1000文字を超えるようなものだと1画面に収めるのが
かなり難しくなってくるにょ。
ポケコンで作った「3D DRIVING」のリストサイズは概ね7KB（＋プログラム内で生成される
データが50KB程度）であるため単純に考えればプチコンの1画面プログラムの上限値の10倍の
リストサイズとなっているにょ。
とはいえ、余分な演出も多々含まれているためそれを省いていけば何とかなると思ったにょ。
ポケコン版に無駄な処理が多いというわけではなくリスト短縮は十分に行っているのだけど
ポケコンの中では高速な部類に位置するPC-E650でさえプチコンと比べると60～100倍くらい
遅いため予めリアルタイムにカーブの道を描いているのではなく演算済みのグラフィック
データを表示しなくてはならないからにょ。（といってもこれも本来ならばBASICでは極めて
重い描画処理なので標準のグラフィック命令ではなく自前で用意した描画ルーチンOPASで
行っている）
つまり、リアルタイムで演算が間に合うであろうプチコンならばポケコン版と比べて
リストはかなり短縮可能ということにょ。
それにポケコン版にあった背景オブジェクトも省略しコースデータも最も短くなるものに
したためPETIT RUNは初期段階から1画面に簡単に収まったにょ。

　ver.0.1　プログラムリスト
　http://ww5.tiki.ne.jp/~ochame/petitcom/image/pr01.jpg

ここまでは数10分で作ることができたにょ。
レースゲームはポケコンでいくつも作ってきたからね。
基本的な部分（車の移動やアクセル、ブレーキ処理など）はそれを踏襲しているにょ。
完成版とはかなり異なるけど1画面で収まるかどうか分からなかったために可能な限り
シンプルにしてみたため最初の段階ではこのようになっているにょ。
最近ならば1画面でどの程度は作れるというのが粗方分かっているので最初の段階で完成版に
近いものになるのだけどこの頃はまだ今と比べて技術や経験が乏しかった無かったため
本当に必要なものだけしか実装していなかったためこのようになっているにょ。
1画面プログラムは慣れないとどの程度のことができるのか分からないため最初のうちは
あれこれ欲張らずにシンプルな題材を選び「必ず実装したい要素」と「できれば実装したい
要素」とを予め考えておくといいにょ。
このPETIT RUNの初期バージョン（ver.0.1）は必ず実装したい要素のみしか入れておらず
できれば実装したい要素はこれから入れていくにょ。（できれば実装したい要素も最初から
入れておいてどうしても1画面に収まらない場合は省くというやり方もあるし、最近の私は
そういうやり方の方が主流となっている）

私は「PETIT RUN」を作るときに考えたのが「なめらかな動作」と「タイムアタックが熱い」
という2点にょ。
すでにプチコンでは疑似3Dレースゲームはいくつか発表されており、1画面のサイズに収めて
いるPETIT RUNはどうしても見た目ではそれらと劣ったものになってしまっていたにょ。
ただし、発表されているゲームはデモ的なものでありなめらかさに欠けるものだったり、
敵車を抜いていくことに主眼が置かれているものだったりでタイムアタックを重視した
ものは無かったので「なめらか」かつ「タイムアタック重視」となればそれらとは十分に
棲み分けができ1画面で多少見た目が劣っても十分に楽しんでもらえると考えたにょ。
というか、タイムアタック重視ならば作った自分自身が楽しめるしね（笑）

上記のver0.1を動作させると30fps以上で動作しているけど「なめらかか？」と聞かれたら
微妙な感じにょ。
ポケコン用の「3D DRIVING」は8fpsということでオールBASICの割りにはそこそこ高速
だった（OPASを使わなければBASICでは0.5fpsくらいしか出ないことを考えるとこれでも
十分速いといってもいいレベルだった）けどなめらかというのにはほど遠いのに対して
プチコン用の「PETIT RUN」はこの初期の段階ですでに30fps以上で動作しているのに
なめらかに感じない理由はコースデータからコースを表示するやり方に問題があったから
といえるにょ。
PETIT RUNのコースデータは全部でカーブの曲率は左右4通りずつ計8通りと直線1つの全9
通りとなっているのだけどカーブの曲率が例えば2→4へと変わる場合に動きがガクガクに
なっているからにょ。（これはポケコンBASICで作られたゲームではごく普通のものだった）
これはポケコン版では動き自体がそれほどなめらかでなかったから気にならなかったけど
プチコン版は道路の表示がなめらかであるために相対的に曲率の変化の表示が目立つ形と
なってしまったというわけにょ。

そのためにとった方法はコースデータを1つ分先読みしてそれを無段階でスムージングを
行うというものにょ。
要するに曲率2のカーブから次の段階で曲率4に変化する場合には中間地点では曲率3に
なっており、1/4地点では曲率2.5になっているであろうということを想定することで
実現したにょ。
さらに別の補完方法もあるのだけどこれが最もお手軽だからこれで良しとしたにょ。
先読みのためにMID$を1つ増やさないといけないのでそれに余分に1行増えることになるけど
結構空きがあったのでこれはすぐに実現ができたにょ。
そして、今後公開した場合にリストを入力したユーザーがコースデータを書き換えた
場合に楽ができるようにコースデータの文字数を変数に入れることにしたにょ。（単純に
関数LENを使ったというだけなのだけど）
そして出来たのがこのver.0.2にょ。

　ver.0.2　プログラムリスト
　http://ww5.tiki.ne.jp/~ochame/petitcom/image/pr02.jpg

これで「なめらかな動作」はほぼ実現ができたにょ。（タイムアタックを熱くするため
できれば60fpsにしたいところだけどこの時点ではまだ追加したい要素も多かったため
そちらを優先した考えた）
1画面ということでこれくらいでいいや・・・とも思えるかもしれないけどリストを見れば
まだ縮まる部分が合ったのでやはり見た目を強化することにするにょ。
スクロールしている道路に対して周囲の地面が地味というのが気になったにょ。
BG画面を使って遠景スクロールを導入するというアイデアもあったけど当時の私はBG画面を
使いこなせてなかったしそれ以前にとても文字数的に足りないということで却下となった
ために実現が容易な地面のスクロールのみ導入となったにょ。
これは道路の白線の色を変えるだけなので簡単な作業とはいえ、白線と違ってあまりに
目立ちすぎると不自然であるため基本色（16色）にある黄緑（11h）と緑（10h）ではなく
中間色から選ぶことにしたにょ。
そして、出来たのがver.0.3にょ。

　ver.0.3　プログラムリスト
　http://ww5.tiki.ne.jp/~ochame/petitcom/image/pr03.jpg

これでも、リストを何度も眺めているとかなり無駄な部分が見つかってしまったにょ。
せっかくいい感じに1画面分リストが埋まっているのに空きが出来るのは嫌だし、見つけて
しまって放置するというのも嫌なのでさらに見た目を良くするためにスピードメータは
ゲージにしたにょ。（色彩バランス的に赤にした）
ギアチェンジもないので数字に拘る必要もないし、ゲージの方が速度が速いか遅いかが
瞬時に把握でいきるというメリットもあるにょ。
それにデフォのコースでは直線が少なすぎて最高速度まで上がらないため最高速度を
味わってもらうためにも最高速度に対してどれくらい出ているのかということが分かる
ようにしたかったというのもあるにょ。
ただ、これによってスピードの計算式を変えたためにバランス調整をし直すハメになって
しまったにょ。

さて、問題となったのはタイムにょ。
最初から暫定措置としてT/25（Tの値は1ずつ増えていく）ということで0.04刻みとなって
いたわけだけどこの「25」の理由はそうしないとプチコンの場合は演算誤差が発生する
からにょ。
0.04刻みならばT=T+0.04とやって表示は変数Tだけで済ませればいいのだけどプチコンでは
0.04を正確に扱えないからね。（「n/4096：nは整数」という数字でないといけない）
小数点以下3桁が無駄に表示されるのは気に入らないので当初は暫定的にT/25にしたけれど
0.04単位というのが個人的に気に入らないという理由で動作速度が30fpsだからということも
あり0.033単位としたにょ。（実測値から逆算した1フレームの時間）
小数第2位まで表示するために3.3ずつ足して表示段階ではFLOOR関数で整数化した後に100で
割っているにょ。
ところが、処理の効率化を図ったお陰で道路を描画するループ回数を少し減らしてやれば
60fpsが達成できる見込みができたにょ。
これでさらになめらかに動作するようになったのだけど30fpsでバランス調整をしていたため
再びバランス調整のやり直しとなったにょ。

さて、このバランス調整だけど具体的に何を調整するのかというのを感じている人もいる
かもしれないにょ。
レースゲームの場合は何よりも操作感にょ。
ボタン操作に対して違和感なく反応してくれるのかということが重要になるにょ。
特に難しいのがアクセル、ブレーキに加えてカーブの挙動にょ。
シミュレータではなくゲームとして面白いかということを重視するならばプチコンの
処理速度や1画面に収めるというリストの長さの都合上の中でシンプルかつ効果的なものを
考える必要があるにょ。
私の場合はシンプルなものはポケコンでのプログラミング経験によって蓄積されたものが
あるから特に難しくはないけど数値そのものはプログラムの実行速度によって大きく
変わってくるため機種毎に考えて作り直す必要があるにょ。
そうやって実際にテストプレイを繰り返すことでベストなものを導き出したにょ。。

デフォのコースは初期バージョンから全く変わってないのだけどこのコースは初めてこの
ゲームをプレイする人にとって（デフォで1つしかコースが収録されていないため）1つの
コースだけで判断されることになるので簡単かつ奥が深いものにしているにょ。
これは一見矛盾しているような意見だけど緩やかなカーブだけで構成されているいかにも
初心者向けというコースでは駄目で急カーブの多いテクニカルなコースでも駄目という
ことにょ。
デフォのコースは緩やかなカーブに加えて最後に急カーブを用意しているというものであり
決して凝ったコースではない（カーブの曲率が微妙に変化しているのと最終コーナーの
前に微妙に逆方向へのカーブがあるのが実は曲者）ということでバランスを合わせるならば
このコースを基準にするのがベストだと考えたからにょ。
そして、はじき出したバランスが完璧なライン取りができれば最終コーナーまでアクセル
全開で進めて最終コーナーだけは減速が必要になるというものにょ。
これはF-ZEROでダブル一点読みが成功したときのような感動を味わってもらうためにょ。
それに合わせて速度や加速度、カーブの挙動の係数を考えていったにょ。

そして、やはりタイムも重要にょ。
デフォのコースは「上手くなったら20秒を切れる」ということを計算してバランスを
とっているにょ。
私はスーファミのF-ZEROのMUTECITY Iのタイムアタックにはまったけどそれは2分を切る
ということが上手いということの条件だったからにょ。
大台に乗るというのはやはりうれしいし、誰でも簡単にできるというものでなければ
なおさらにょ。
そういうバランス調整をするためには自分がプレイして上手くなるということが必要に
なってくるにょ。（まぁ理論値を演算してそれに余裕を持たせるという方法もあるけど）
それに、自分が上手くなって公式レコードを提示するということはタイムアタックに
燃える理由にもなってくるにょ。
私はMUTECITY Iの任天堂公式レコードである1分58秒97を破るためにMUTECITY Iだけで
数ヶ月間走り込んだからね。
それで何とか1分58秒68という記録を出すことができたにょ。（ダブル一点読みも成功し
最速ラップは23秒23をたたき出したけどラップタイムが不安定なのでこれが私の限界）
したがって、PETIT RUNもタイムアタックをやってもらうために公式レコードを出すことに
したにょ。（というか、私の場合はタイムアタック、スコアアタックをするゲームは大抵
「公式レコード＝私の自己記録」を公開しているけどね）

これが、バランス調整によって計算式を変えるたびにまた記録を1から作り直していたにょ。
まぁそれでも最終的に完成する時点ではコースを覚えているのでそこまで厳しくはない
けど数値を変えたら微妙に走行ラインを変えないといけないためそれだけが非常に大変
だったにょ。
というわけで、このバランス調整が出来た時点で完成となるにょ。

　「PETIT RUN」完成版　プログラムリスト
　http://ww5.tiki.ne.jp/~ochame/petitcom/image/p_run.jpg

まだ細部においては今後もかしたらこれでもまだ無駄な部分が見つかるかもしれないけど
それが1画面ゲームを作る際の面白さでもあるにょ。
こうしてみてみると1画面とはいえ、やりたいことがどれだけあるのかということが非常に
重要になっていると思うにょ。
この完成したPETIT RUNだけど数ヶ月後に改めてみると無駄な処理も多いし、プチコンmkII
発売によってそれ専用に作ることで大幅にリスト短縮が可能になるからね。
そして、初代のPETIT RUNを作った時に諦めた要素のほぼすべてを入れたのが大喜利にも投稿
したPETIT RUN mkIIとなるにょ。

　http://ww5.tiki.ne.jp/~ochame/petitcom/1page.htm#prun2
　「PETIT RUN mkII」　プログラムリスト
　http://ww5.tiki.ne.jp/~ochame/petitcom/image/prun_mk2.jpg

初代PETIT RUNからPETIT RUN mkIIへは9月16日、PETIT RUN mkII（ver1.0）からver1.1へは
9月30日に詳しく書いているので合わせて見てもらうといいかもしれないにょ。

以上、PETIT RUNのメイキングについて長々と書いていったけど最も重要なのは「1画面
プログラムを作りたい」と思うことにょ。
普通に作れば1、2時間でできるレベルのものでも1画面ならば数日かかることもあるからね。
リスト短縮に手こずれば1バイト削るのに数日かかることさえあるにょ。（ちなみにこの
PETIT RUNはプチコンスキーと並列作業をして完成まで2週間かかった）
そこまで限界に挑戦する必要はないけど1画面プログラムよりは普通に作った方が遙かに
簡単なので「1画面プログラム」に価値を見いだせないと難しいといえるにょ。
300～400文字程度のリストならばリスト短縮を特にしなくても1画面化は容易であるため
そういった極めて短いもののみ1画面にするというのも1つの方法だけど1画面プログラムの
真骨頂は1画面という制約の範囲内でどれだけの内容を盛り込むか（そしてリストに無駄が
なく1画面ギリギリに詰め込んでいるか）ということにあるのでそこに魅力を感じなければ
「普通に作るよりも苦労して1画面にする」というのはなかなかできないと思うにょ。
ということを考えるとリスト短縮の方法をあれこれ書いて作るためのハードルを下げた
しても1画面プログラムに興味を持ってくれる人は少なそうにょ。
とはいえ、1画面プログラムとはどんなものかということさえ知らない人も多くいると思う
ので、「1画面プログラム」について書いた今回のプチコン虎の穴は1画面プログラムを作る
人の増加は見込めなくても1画面プログラムに興味を持つ人の増加には繋がっているのでは
ないかと思われるにょ。