最初の開発ゲームは【ベースボール】 <1982年頃> [1]


 

最初の開発ゲームは【ベースボール】 <1982年頃> [1]


 

わけもわからず作った最初のゲームが、定番の野球ゲーム。

ただし、ゲーム性ゲーム画面レイアストなどは定番ではなく、おそろしく独特!(笑)

はっきり言って誰も知らないし誰も知りたくないであろう、このゲーム。恥ずかしいので紹介したくないし、紹介したところで何の得もないのだが、『ゲーム黎明期における歴史的意義』があろうと思い、ここで紹介することにした。

 

現代のゲームに慣れた人、笑っていいよ。

 

 

ハードはNECのPC-6001(MKⅡ)。

NECから発売された「パピコン」という愛称のついたPCで、なんと10万円近くしたが、今の感覚で思えば、何もできない幼児オモチャ以下の代物だった。

(もちろん当時は、衝撃的機能?で、すごかった。どう凄かったかを説明する気力はない…)

 

ソフトの媒体は、ミュージックカセットテープ。もちろんアナログ。

テープレコーダー(ってなんだ!?って言わないで…)の音声入出力端子をパソコンにつないで、「2進数情報の音声」としてプログラムやデータを読み込む。

2進数のビット情報が、音に変換されているということ。

 

基本OSはベーシックというものでROMになっているが、ゲームの開発に使う【アセンブラー(記述したコードをマシン語に変換…アセンブラやマシン語を解説する気力もない…すみません)】などは、いちいちパソコン起動後に毎回音楽テープから音声として読み込む。

 

それが何分もかかる。待ってるだけ。

 

「ふ~むむ、なんのこと?」でしょ? (^o^:)

 

パソコンのデータ記憶媒体が【アナログ録音の音楽テープ】?

開発用言語やアセンブラソフトだけでなくも自分が作っているゲームのデータやプログラムも、電源を入れるたびにいちいちテープレコーダーで再生した音楽テープから【音声として】読み込む。

 

早くても数分~5分とか時間がかかる。

保存(録音)するときも数分~5分かかる。

 

プログラムとデータ(主にグラフィックデータ)で数十キロバイト(数百キロバイトあったっけ?…)しかないのに、それくらい時間がかかる。

 

【音楽テープ】に【アナログ音声】として【デジタル信号】を録音(保存)するのだが、ペラペラでむき出しのテープ表面に傷ができるとビット落ちし、データ内容が変わってしまう。

 

グラフィックデータ部分ならビット落ちしても、表示された絵に変な点ができるだけだが、プログラムや制御用データ部分がそうなると、要するにDNAの突然点変異と同じことで、起動しても変な動作をするか、そもそも起動さえしなくなる。

 

実のところ、あっさり最初から起動しなかったり、動作の途中に明確に変な動作をしてくれたほうが良い。特殊な条件でしか起こらない不具合(バグ)だと、ゲーム発売後に問題が起こり。面倒なことになる。

 

不具合が見つかれば、プログラムのどの部分が書き換えられているのかデバッグしなければならない。

が、そもそもデバッガーがないのだから、何が何だかわからない時も多い。

 

デバッガーのないプログラム開発って、今の人、信じられるだろうか?

 

ゲームプログラムの起動時にいきなり暴走する場合は、プログラムの最初で多数のサブルーチンをコールしている場合が多いので、もはやどの部分が悪いのかもわからない。

 

とはいえ、自分でプログラムを書いているので、起動時にコールされるサブルーチン群のどこかが【ぶっ飛んでいる】のはわかるし、前回暴走しなくて今回暴走したのなら、新しく書かれたコード部分だという見当はつく。

 

しかし、デバッガーというものがない場合は、プログラムのコード進行を制御できない。

ただ単にプログラムが暴走して、パソコンが再起動するだけのことで、ゲームを起動するたびに、単にそれが繰り返されるだけになる。

 

これでは、デバッグにもならない。

 

そこで【暴走する以前のコードのプログラムに戻って、自作の【トラップ】をあちこちに作り、【どこでプログラムが暴走するか】を見つけることから始めねばならない。

 

たとえば自作のトラップで、プログラムの各動作ポイントで、番号を1,2,3,4…と画面に表示しておき、3の表示の後に画面がフリーズするとかブラックアウトしてしまうならば、トラップ3と4の間に【間違ったコードを書ている】か【そこで参照しているデータが間違っている】とかの想定ができる。

 

そういう【原始的なデバッグ】については、この辺で…。

 

【この項、つづく】

 

<--前 Home 一覧 次-- >

<スポンサーリンク>

2018年06月06日