ゲームプログラミングをエンジョイしていたら自作ゲームが500個になった

以下の私の個人サイト のアニメーションGIFを2分程度見続けると、私の作ったゲームのスクリーンショットを全て確認できる。

500個と言っても、多くは1ゲーム1分程度のミニゲームだ。大作はほとんど無い。せっかくだから内訳を調べてみた。

順位 種類 件数 割合
1 ワンボタンゲーム 245 48.1%
2 Flashゲーム 114 22.4%
3 ブラウザゲーム 88 17.3%
4 Windows用 14 2.8%
5 Palm用 9 1.8%
6 その他 8 1.6%
7 Java製 7 1.4%
8 P/ECE用 5 1.0%
9 iアプリ 5 1.0%
10 Wonder Witch製 3 0.6%
11 プチコン製 3 0.6%
12 PC-9801用 2 0.4%
13 Unity製 2 0.4%
14 Pocket Cosmo用 1 0.2%
15 Ruputer用 1 0.2%
16 Zaurus用 1 0.2%
17 PC-6001用 1 0.2%
合計 509

ワンボタンゲーム、Flashゲーム、ブラウザゲームあたりがミニゲームにあたる。Flashゲームは残念ながら大半がもう遊べない。Windows用は主にシューティングゲーム、一部はXbox 360でも動くXNA製。Wonder WitchはWonder Swan向けだったり、プチコンはSwitch向けだったり、コンシューマ機で動くゲームが少しある。

その他は弾幕記述言語BulletMLやミニゲーム用ライブラリcrisp-game-libなどゲームでない物。なので上の件数にはゲーム以外も入っているけど件数合計は509だからヨシ。

PalmとかP/ECEとか、iアプリ、Pocket Cosmo、Ruputer、Zaurusなどの昔のモバイルデバイス向けに作ったものもある。デバイスごとの特性に応じてプログラムを組むのは楽しい。

私が作ったゲームでWeb上に残っている最古のものは、プログラムの投稿雑誌であるマイコンBASICマガジン、通称ベーマガの1989年9月号に掲載されたPC-6001用ゲームMeteorite だ。N60-BASICで書かれた もので、ベーマガの1ページに収まる短いプログラムで実現されている。

このプログラムの最後の方には、DATA文で定義された謎の数列がある。この数列は当時のベーマガ読者には見慣れた、マシン語の定義部だ。BASICの処理速度では間に合わない、大量の隕石の落下処理などをZ80アセンブラで書き 、それを手作業で16進数のマシン語に変換するのだ。

限られた実行速度、限られた記憶容量の中で、いかに目的のゲームロジックを実現するか、これがマシン語時代のプログラミングの醍醐味だ。ソフトウェアレイヤーの中の極めて低レイヤーを直接扱うため、当時のハードウェアの特性をよく知ることが求められる。

逆に最新の自作ゲームは、ブラウザ上で動くワンボタンアクションミニゲームだ。JavaScriptで書かれた ものだが、ベースのコードはコーディングエージェント に書かせている。

コーディングエージェントに適切なツールセットを渡し、ゲームのアイデア生成から設計、実装、改良まで行わせるというプログラミングスタイル、これはマシン語を直接書くのと比べてはるかに高レイヤーの取り組みだ。ゲームの楽しさはどのような要素で構成されているか、ゲームをメタな視点から俯瞰し、それをLLMにどのように理解させるか、というところにプログラミングの楽しさが移っている。

長い間ゲーム開発を続けていけるのも、こういった低レイヤーから高レイヤーまで、その時代に合わせた様々なゲームプログラミングの楽しみがあるおかげだ。個人ゲーム開発は、その時々の流行りの技術スタックやデバイスを使った色々な試みを行うのにはとても都合が良い。粗削りな技術、言語、ライブラリ、デバイスでも、小さなゲームを個人で作る分にはいくらでもトライ＆エラーができるし、その荒削りさがゲームプログラミング体験の面白さにつながるのだ。

今アセンブラを学ぶ価値はほとんど無いかもしれない。でも長い間個人ゲーム開発を行って得られた広範な技術レイヤーの知識が、次々に現れる新しい技術をどう扱えば楽しめるかという、より良い開発体験を継続するための基礎体力になっている。パフォーマンスに対する肌感覚や、各レイヤーが提供する抽象化を正しく扱う能力、作りたいゲームを実現するのに最適な技術を見極める目利き、こういったものに還元されているのだ。

自分の知識が新しい技術への理解を助け、好奇心を絶やさずに続けられる。結局こういったことが大事なのかもしれない。