有野課長もGAME OVERの事を「ガメオベラ」って読んでいますしね。 自分の場合、SMILE BASICの点を打つ命令(GPSET)は、昔のBASICではPSET（多分Point Setの略）という命令でしたが、当時、「ペスト」って読んでました。…エボラ出血熱と同じ位ヤバい病気。

あるいは、WHILE～WENDは、BREAKでいつでも抜け出せる事を利用して、 WHILE 1 IF （条件１） THEN PRINT "処理を実行出来ません。終了します。" BREAK ENDIF（以下条件毎に同じ処理） （処理） BREAK WEND …うーん、ループしない処理なのに、ループ命令を使うというのも美しくないなあ。

…もうやだMiiverseの字数制限。どこまで削れば投稿出来るのよ？

ここでGOTO文を使えば、 DEF （関数名） IF （条件１） THEN PRINT "処理を行えません。終了します。" GOTO @END ENDIF（以下、条件毎に同じ処理） （各種処理を行う） @END END 処理が出来なければ、一番最後に飛ばしてしまえば良いので、多重IF文にならず、非常にスッキリする。

例えばサブルーチン内で、『ある条件の時は、何も処理を行わずにそのまま抜ける』という処理を行う時、構造化プログラミングのスタイルだと、 DEF （関数名） IF （条件１） THEN PRINT "処理を行えません。終了します。" ELSE IF （条件２） THEN PRINT "処理を行えません。終了します。" ELSE IF （条件３） THEN PRINT "処理を行えません。終了します。" ELSE （処理を行う） ENDIF ENDIF END …という具合に、多重IF文の嵐になる上、ENDIFが１つでも足りないとエラーの原因になる。

通常のBASICから、X-BASICで構造化プログラミングに移った身としては、GOTO文を使うのはちと気が引けるけど、使ってしまうとやっぱり楽なのよね。『GOTO文有害論』（GOTOはどこにでも行き先を指定出来るので、乱用すると流れが分かりにくい、いわゆるスパゲッティプログラムの原因になるというもの）というのは分からなくもないが、構造化にこだわると、かえって冗長なプログラムになる事もあるからねえ。

「分からない」と嘆くだけなら誰にでも出来るだろう。しかし彼は、恐らく誰に聞いても分からないような事を、「分からないけど、多分こうなんじゃないか」と試行錯誤し、その試行錯誤の結果が、グランツーリスモという形で実を結んだ。 多分、ゲーム作りで一番必要なのは、「分からない」の先を、自分自身の手で切り開いていく力なんじゃないかと思う。

やがてOh!Xが休刊になり、連載も中途半端な所で終わってしまったが、その数年後、『グランツーリスモ』が発売される。そして、そのプログラミングを担当したのが、当時Oh!Xで『車の挙動に関するシミュレーションの手法』について延々と書き綴っていた丹明彦氏（と、同じくOh!Xで記事を書いていた横内威至氏）だった。 それを知った当時のOh!X読者は、自分の知っている人が、まるでノーベル賞を受賞したかのような驚きを感じた。その陰には、数々のノーベル賞受賞者と同じように、誰にも理解されないような努力と研究の積み重ねがあり、そういった意味では、グランツーリスモというのは、Oh!X時代から続けてきた研究成果の発表の場だった、という訳だ（ただ、グランツーリスモの場合は、一度理論を構築し直しているので、当時の連載と直接は繋がらないそうだ）。

「○○みたいなゲームを作りたい、でも作り方が分からない」というような人へ…と言うには重すぎるかも知れないけど、あるプログラマーの話。昔、Oh!Xというパソコン雑誌があって、そこで丹明彦というライターが、『車の挙動に関するシミュレーションの手法』について、連載で延々と書き綴っていた。力学やら何やら難しい話ばかりで、当時の読者の中で、彼がやろうとしている事を理解出来た人は、ほとんどいなかっただろう。

ループの中だけ見ていましたが、全体を見ると確かにそうですね。 自分を動かす→敵を動かす→自分を動かす…と交互にやらないと。

BUTTON関数の隠し機能めっけ。１３ビット目にSTART/SELECTボタンが割り当てられている。通常はRUN/STOPキーだが、これらを押してプログラムを走らせ、そのまま押しっぱなしにしている間、BUTTON関数が8192を返してくれる。まあ、もう一回押してしまうとプログラムが止まってしまうので意味無いが。あと、BREPEATは設定出来ない。

垂直同期云々というのは、画面表示側の理屈というだけであって、あくまでボタンの方は、垂直同期に関係なく、読みに行けば常にその時の状態を返してくれる方が自然だと自分は思うんですけどね（少なくともX68000はそういうハードでした）。 …もしかして、3DSのハードウェア的にそういう仕様なのかなあ？ 例えば、『ボタンの状態が読めるのは垂直帰線期間のみであり、垂直表示期間は読めないので、その間はボタンの状態変化が分からない為、仕方なく同じ値を何度も返している』…みたいな事情があったりするとか。 DSiで動くMkIIもそうだったとすると、何か、そういうようなハード上の制約に縛られているような気もしてきます。

自分がプログラミングを始めた頃は、文字とかのキャラクターグラフィックを動かす事から始めた覚えがあります。 一方で、コミュの流れを見ていると、スプライトやBGを使ってゲームを作っている人がけっこういるようですが、初心者がいきなりそれを真似するのは、結構厳しいんじゃないかって気もするんですよね。

４９行目の所ですが、WHILEの条件の所が、『敵の縦座標(EY)が２９より大きい間』になっていますね。 EYには０が入っているので、条件に合わずにそのまま抜けてしまっているので、WHILE EY<29（２９より小さい間）に直しましょう。 あと、４８～５４行目の処理を行う順番ですが、この順番だと、 EYに１を足す（縦１）→敵をスペースで消す（縦１）→敵を表示する（縦１） →EYに１を足す（縦２）→敵をスペースで消す（縦２）→敵を表示する（縦２） …というような感じで、スペースで消すべき座標を、先に＋１してしまっているので、実際には消えていない事になります。 なので、５１行目と５２行目を入れ替える事で、 敵をスペースで消す（縦１）→EYに１を足す（縦２）→敵を表示する（縦２） のように、正しく落ちてくるようになります。

ついでにもうひとつ、BREPEAT命令は、未使用(10)のボタンに対して設定しようとするとエラーになる。ダミーで良いから設定出来ても良かったかなあ。

当たり前のようにVSYNC命令を入れている人は気付いていないと思いますが、VSYNCをコメントアウトすると、こうなっちゃいます。多分、垂直同期と連動してボタンの取得をしているのね。 ちなみに、昔のBASICは、画面の描画速度が遅く、垂直同期待ちという概念自体、ほとんど無いような状態でした（マシン語だと処理が高速になるので、垂直同期待ちを考える必要が出てくる）。

引き続き、暗黙の了解との戦い。BUTTON(1)関数は、『ボタンが押された瞬間だけ』という説明があるのに、実際にやってみると、１回押しただけなのに、１０回位連続で押されたと判定される。こんなんじゃ、最初からBUTTON(0)を使って、自前で押された／離されたの管理をした方がマシじゃん…と思っていたが、VSYNC命令を入れたら、ちゃんと動くようになった。

今、変数にPRGGET$関数でプログラムを取り込むテストをやっていたら、"Internal error"（内部エラー？）とか見慣れないエラーメッセージが出た後、ハングアップしてしまいました（再現性不明）。 まだ色々と不安定なようで…。

初代PC-6001とMkIIとの間にある、深い溝を思い知らされた覚えがあります。

『ダイレクトモードでDEFを使って定義した命令を使用するとハングする』というバグは早く直して欲しい所です。 命令を呼び出して、ちゃんと動くかどうかのテストがしづらい…。