私が思っている、或いは感じているゲーム制作の現状について、思いのままに書き殴ってみました。これが歴史的に正しいかどうかなんて知りません。あくまでもこれは私が感じたままの内容となっています。だから、そういう目で読んで頂けますと幸いです。
- ゲーム制作手法の遍歴
今、ゲームを作ろうと思ったら、適当なゲームエンジンを使うのが最も手軽です。私が現状で理解できるのは Unity ですが、それ以外にも UnrealEngine とか、Godotとかいろいろ簡単に使うことが出来ます。しかも、ある程度は GUI 操作で基本的な形は出来てしまうため、あとは、その雛形に則って自分が動かしたい機能を追加していく感じで開発が進んでいきます。
今から40年前、1980年代の Z80 や 6502 に代表される 8bit CPU を搭載したパソコンやゲーム機では、そもそもゲームエンジンという考え方は存在していませんでした。何もかもが自作です。そこにあるのは、電源を入れたら特定の場所から CPU が動作し始めるだけという原始の世界です。そして、自分が最初に行うのは、ハードウェアの初期化です。ロットによって初期状態が異なる場合があるため、基本的には自力で全てを管理する必要があります。
同じハードで何度もゲームを作っていると、そのうち文字列の表示とか、画面表示とか、以前のゲームで作成したプログラムを流用し始めます。これが後のライブラリの元となる概念です。そして、それは同じ CPU であれば、ルーチンのエントリが同じであれば、表示が同じになるよう、プログラムの仕様を合わせ始めることになります。これは初期の大手メーカーが内部で独自ライブラリを作って、自社の製品制作に活かし始めることになります。これを使うと移植がラクなんです。
ところがこれも限界が来ます。ハードが次々と変わっていき、また、CPU も変化していくため、アセンブラのエントリ合わせだけでは限界が出てきてしまったのです。ただ、似たようなタイミングで、ゲーム制作の主力はアセンブラからコンパイラに移っていきました。そして、コンパイラであれば、基本的な処理の部分はコンパイラがある程度吸収するので、画面表示、音楽再生、操作入力をハード毎に用意すればよくなりました。アセンブラでも同じに思えるかもですが、エントリがレジスタやメモリなのと、関数による引数なのでは、その可用性は全く別次元となります。
すると、そのうち、ハード毎の差を吸収するライブラリを専門で販売するメーカーが現れ始めます。そして、それは次々と統合されていき、現在のゲームエンジンの礎を形取っていきました。今、それなりにラクを出来るのはこんな感じで、ゲーム制作の歴史が紆余曲折を繰り返してきた結果なんですよね。そして、だからこそ、元となっている基本に立ち返ることが出来るレトロPCでのアセンブラ開発は素敵に感じるのです。
キヤノンITソリューションズ
2023-07-03
- アセンブラ開発の遍歴
アセンブラでの開発環境は今はとてもラクになりました。昔は実機開発でした。これは、PC-8801 のゲーム開発であれば、PC-8801 の上で動く開発ツールを元に、PC-8801 のゲーム制作を行うという意味です。メモリは最大で64KBですから、開発中はどうしても FD 上で行うことになります。お金がない人はカセットテープ媒体ですし、オンメモリ開発なので、なかなか凄いモノは作りづらいんです。
それがある時、環境が一変します。それが PC-9801 と MS-DOS の登場です。PC-9801 は CPU は 16bit の 8086系です。8bit ゲーム開発には関係ないかと思っていたら、クロスアセンブラなるものが発表されました。それは OPTASM です。今までバイナリを作るにはかなり長い時間がかかっていたのですが、それが割りとあっという間に完了しました。
※ 20240311-0740追記
すいません、OPTASMはx86系アセンブラとの指摘を受けました。何を使ってたか思い出したら、また更新します…
※ 20240312-1740追記
まだはっきりと思い出したわけではないのですが、HD64180を搭載したCP/Mボードを使って、SLRのアセンブラでアセンブルしてたような気がしてきてます。
そして、その開発時間短縮に輪をかけたのが MAKE と LINKER です。ソースコード分割による差分アセンブルで、全てのコードを毎回バイナリ変換する必要がなくなります。そのソースコードの改変をチェックするのが MAKE でした。アセンブルも2段階になります。.asm というアセンブラソースコードファイルから、.o というオブジェクトファイルが生成されます。そして、それは修正単位で更新されます。最終最後に LINKER により全てのオブジェクトファイルが連結されて、一塊のバイナリファイルが生成されます。
MS-DOS のエディタもとても使いやすいものになりました。代表格は MIFES です。後に VZ Editor に私は乗り換えましたが、超高速と感じるエディタで、ソースコードの入力はとても快適になりました。そして、そのうち、コメントに日本語が使えるようになります。これは私の中では大きかったですね。ソースを追いかけるのが本当に楽になりました。
※ Vz Editor の実質的な後継ソフトといえばおそらくこれ。そして、出来上がったバイナリファイルを、最初は PC-9801 上でフロッピーに書き込んでから、PC-8801 で起動という手順を行っていました。実行したら後は見た目で判断して、バグを探すという状態だったのですが、それがインサーキットエミュレータ(以下ICEと略す)の登場で一変しました。
この ICE は、PC-8801 の CPU の代わりにソケットを差し込んで、ICE が Z80 CPU の代わりを行うという動作をします。そのため、好きなタイミングで、マシン語の実行を止めて、その時のメモリの状態や CPU レジスタの値の確認などが出来ました。特定の番地に来たら停止するブレークポイント設定や、特定の番地に値が書き込まれたら停止するライトブレークなど、本当にプログラマが欲しい機能が満載でした。
この ICE は、自分が作ったゲーム以外もそのまま解析できてしまいます。そのため、某社の描画ルーチンが速い秘密とかも、白日の下に晒されます。後期の PC-8801 のゲームが凄かったのは、こうした開発環境の向上が大きく寄与していたのではないかと思っています。まあ、ICE は安くても…ん十万円、下手すると…ん百万円と高価でしたから、とても個人が購入できるようなモノではありませんでしたが…
そして、現在です。エディタは Win や Mac の上で広大かつ複数のソースを同時に編集できる GUI 環境となっています。アセンブルは、差分アセンブルをしなくても一瞬と言っていい時間で終了します。カセットテープやフロッピーをシミュレートできるファイル形式で、実行はそのままエミュレータで行います。高価な ICE を使ったデバッグも、エミュの上で簡単にチェックできます。最終的な実機確認も、SDドライブなどのサポートであっという間にロードできたりします。
時代と共に開発環境は大きく変わりました。おそらくこれからもどんどん変わっていくことでしょう。それに追従していくことが出来なくなったら、私は引退することになるのだと思います。気持ち的にはあと10年は最低でも頑張りたいですねぇ…
※ 当時のコピーに関する記事が満載。また、当時の広告もそのまま掲載されているので、懐かしさも大爆発です。当然、当時のハードウェア資料としてもかなり秀逸です。とりあえず興味があれば押さえておくべき書籍群です!
コメント