レトロゲーム開発昔話 | 【はにれた】　by れたすはうす

レトロゲーム開発昔話一覧

オホーツクに消ゆ（ファミコン版）＜1987年頃＞

オホーツクに消ゆ（ファミコン版）1987年

【北海道連鎖殺人　オホーツクに消ゆ（ファミコン版）】は、1987年の6月27日に発売された。

私の記憶では、発売予定日の約２ヶ月前のゴールデンウィーク頃が最終チェック時期になっていた。

会社に泊まりこみで作業し、眠くなれば床に転がって寝て、起きたらそのままパソコンの前に座るという状況だった。

昼ごはんを食べに外に出ると、5月の陽光に満ちた街は浮かれているのに、私たち開発者は髭も剃らず風呂にも入らず…という有様…。

当時ゲーム開発をしていた者たちの現場では、そのようなことが普通のことであったろう。

今ではこういうのは『ブラック』と言われそうだし実際にそういう状況があれば『ブラック』だろう。現在ではこんな環境は無いだろうが、当時はいわばベンチャーである。

ゲーム開発業界というものもカオス期である。

強制など何もないし（納期という強制はあるけど、それを受け入れているのだし）、自分の意思での過激労働だったし、若いし元気だし、当人たちは案外楽しかったりしたと思う。

（もちろん、しんどかった！）

もうほぼディバッグも終わりで納品間近という日に、アスキーの担当者がやってきて、

「ストーリー上、一つ場面を増やすことになりました」

と言ったときには、我々はぶっ飛んだ。

場面を増やすということは、まずその場面用にもう一枚グラフィクス（ドット絵）を作成しなければならない。

また、アドベンチャーゲームであるから、その場面にはコマンド設定も必要になる。

そうなると前後のつながりや全体のシ－ンの流れなどに新たな不具合が出る可能性がある。

全面的ではなくとも、デバッグのやり直しである。

「おおおおおおー！たすけてくれぇ～！もうイヤだぁ～！」

自分たちが仕込んだストーリー（プログラムとデータ）が、「そのとおりになっているか」を延々と繰り返して確認するというデバッグ作業は、一定の期間を超えるとほんとうに精神的に拷問化するほどキツいのだ。

私はその後もたくさんの作品で、自分たちが作ったゲームのデバッグ（同時に修正や改善作業）をやりすぎて、ゲームで遊ぶということができなくなった。ゲーム画面を見たくないのだ。

（アクションものはまだ良いが、アドベンチャーやロールプレイング物は楽しめない不幸な身体に…）

ともかく１場面増やし、全員で集中的に確認作業を行い無事納品はできた。

原作者堀井雄二氏とは、開発前に一度だけ会って打ち合わせをした。

前年にドラクエがMSXでエニックス発売されていたころである。

堀井氏とはエニックスのパーティなどで会ったと記憶するが、話したのはそのとき一回だけになった。

堀井氏は忙しい身だったので、その後はアスキーの担当者が堀井氏と我々の間をつないだ。

ゲームで使用したグラフィックスは元絵をイラストレーターの方が描き、それを元にして使用されている画像は全て私がドット絵に落とした。

プログラムは、そのあといくつかいっしょにファミコンの開発（…たとえばアイスホッケー）をしたN氏。

サウンドプログラムは、これまた素晴らしいプログラマーである、H氏。（MSXバレーボール【アタック・フォーをファミコン版にしてくれた！）

私をゲーム界に引き入れ、その後独立して一緒にゲームを作ることになるＴ氏と、その後私の嫁になるＴ嬢は、アシスタントとして参加している。

このコラムを書くにあたって、ネットでこの【北海道連鎖殺人　オホーツクに消ゆ（ファミコン版）】の動画を探していくつか見てみた。

古いゲームなのに多くの投稿があるので、驚いた。

それにしても、う～ん懐かしいし、恥ずかしい。

スペックの問題があるにせよ、もっとうまく描けただろうに…。

元絵のイラストレータさん、ごめんさない。

印象的なシーンの一つに、【めぐみの入浴シーン】が紹介されていた。

「あ～、思い出したぞ。確かバスタオルが…」

気になる人は、　’めぐみのバスタオル’　で検索してください。ファミコン版オホーツク通のファンなら、もう知ってるでしょうけど。

オホーツクに消ゆ（ファミコン版）　ゲーム紹介

（追記）

私が作ったPC-6001のゲームの紹介を見たことから、2018年7月くらいから、Twitter を始めた。そこでいろいろやりとりをしていると、私が知らなかったり、勘違いしている部分を指摘してくださるこ方もあり、Youtubeのスタッフロールなど見て、いろいろ思い出し、内容を修正しました。

それまで、私の勘違いが記載されていたことをお詫びします。

特にプログラム担当者の誤記。

N氏、H氏、すみません！（別の意味でT氏も…）

ゲーム開発は、若いころの強烈な体験なので、大筋は当然覚えていて間違いないんだけれど、ずっと業界にいないと、ゲームのことを忘れ、細かな記憶が失われる。

なんか、悲しい。

私にとって、『ゲーム開発』は『青春グラフィティ』というものなのだけど、ゲームを愛している方々にとっては思い出だけではなく、『ゲームの歴史・記録』なのだということを、つくづく感じました。

＜スポンサーリンク＞

エニックスのパーティ　＜1986年頃＞

エニックスのパーティ　＜1986年頃＞

すご～く昔のことだが、私は株式会社エニックス(現：株式会社スクウェア・エニックス)が、毎年行っていたゲーム開発関係者を慰労するパーティーに数回参加したことがあった。

時期は最初のドラクエが発売されたころ（1986年～）だと思う。

エニックス主催のこの種のパーティーは立食形式で、ゲーム開発者らの情報交換や懇親を深めるものであり、締めにはお決まりのビンゴが毎年あった。

パーティーに出席している者は皆、若かった。

新しい職種であるゲーム開発者ばかりだからだ。

そう、私も若かった。

ある年のパーティーで、ゲーム開発者でも会社関係者でもなさそうな品のある一人の中年の男性が、一人で皿に食べ物を取り分けている寂しそうな（あくまで私の主観…）姿を見た。

その男性はエニックスの社長さんなどお偉方とは時おり会話しているが、我々のような若い開発者とは距離があるようだった。

私は当時の福島社長さんに近寄り、「あの方はどなたですか？」

と訊いた。

それは、ドラクエの作曲を担当された＜すぎやまこういち＞先生であった。

すぎやま先生は、その当時私の父親くらいの年齢であり、かなり高名な作曲家だという意識が我々のほうにあったため、ゲーム開発で直接の関係でもなければ若い我々ではなかなか気軽に話しかけることはできない存在だったのだ。

「寂しそうだ。これは何とかせねば！先生を一人にするなんて、失礼だ！」

と、私は勝手に意気込んだ。（大きなお世話）

私は勇気を出して、一人で立っておられる先生のもとに歩み寄った。

そして、少し緊張した笑顔を作り、力強く言った。

「先生！わたしは先生の歌われてた『青春時代』が大好きでした！」、

と。

先生の孤独（あくまで私の主観…）を打破したことで、私は自己満足に浸り、にこやかに微笑んだ。

が、すぎやま先生は、なんとも言えない複雑な表情をされて、私の顔をじっと見つめておられた。

この私の行為がいかにトンでもないものかについて、話が古すぎるから、ちょっと説明が必要だろう。

このパーティーがあった時期より前に、日本歌謡界で大ヒットした【青春時代】という歌があった。

『森田公一（もりたこういち）とトップギャラン』というグループの曲で、ヒットしてから日月は経過していたが、当時は誰でも知っている歌とグループだった。

そう、私はドラゴンクエストの作曲者＜すぎやまこういち＞先生と、大ヒット曲【青春時代】を歌っていた＜森田公一（もりたこういち）＞氏を混同していたのだ！

ただたんに、名前の＜こういち＞つながりで・・・。

これは、宇多田ヒカルさんに、

「（倖田來未さんの）キューティーハニーが大好きです！」

というようなもの…よりひどいのか？

ふつう、そんな間違いをするはずはないのだが、そのとき私は…どうかしていたのだ。

しかし、私は自分の失言（森田公一氏と間違えていること）に、まったく気づかずにいた。

すぎやま先生は、戸惑いも多少の憤りも感じられていたはずだが、無礼な間違いを犯した私に対して、静かに

「ありがとう」

と言われた。

なんと、度量が大きく心が広い！

私はその後も自分の愚かな間違いに気づかず、楽しくパーティーを過ごした。

その後何十年たっても、世間でドラクエの話題が出るたび、私はこのときのことを思い出す。

＜すぎやまこういち＞先生、ほんとうにすみませんでした。

集合写真（クリック）

※プライバシーに配慮し、顔表情がわからないよう画像をぼかしてあります。
私は列後方に立ち、右手を挙げています。二人いる？
さて、どちら？ (^_^;)

＜スポンサーリンク＞

スーパーファミコン用ゲーム開発機　＜1990年頃＞

スーパーファミコン用ゲーム開発機　＜1990年頃＞

ここでいう【スーパーファミコン用開発機】とは、インテリジェントシステムズ社製スーパーファミコン開発機「IS-DEBUGGER」や「IS-SOUND」（実物写真はここをクリック）である。

（他にもあるのだろうが、私はこれを使っていた。他のものは知らない）

スーパーファミコンが発売されたのは、1990年（平成2年）だから、その開発機はその以前にはあったのだろう。

私の記憶では、最初にこの開発期を眼にしたのは、スーパーファミコンでのゲーム開発が決まってすぐで、任天堂の情報開発室から２、３セットが届いた。（写真のものとは別物。写真のものは、後に独立してゲーム開発を始めてから、ゲーム発売会社が任天堂から購入して支給されたもの）

わたしは、キャラクターデザインやサウンド（サウンド制御プログラム開発、曲や効果音の作成）担当だったので、「IS-SOUND」のほうで作業を行っていた。

スーパーファミコン開発を主な仕事にしていた当時は数年間、毎日のように使用していたが、もう昔のことなので使い方などはまったく記憶にない。ちょっと悲しい。

この「IS-SOUND」は、スーパーファミコンのプログラム開発（デバッグ）機能に、サウンド開発（デバッグ）機能を付け加えたものなので、サウンド開発だけのものではなく、スーパーファミコンのプログラム開発にプラスして、サウンド開発も付いているもの（だと思う）。

マニュアルの表紙には、以下のように印刷してある。

「S-HVC プログラム開発システム　S-HVC DEBUGGING ツールソフト　SHVC取扱説明書　IS-DEBUGGER、IS-SOUND 共通　Nintendo INTELLIGENY SYSTEMS」

「IS-SOUND ツールソフト　スーパーファミコン　サウンド」開発支援ソフトウェア　取扱説明書　Nintendo INTELLIGENY SYSTEMS」

プログラムはパソコン（ＡＴ互換機、dos/vとも）でコードを書き、コンパイルした実行ファイルをこの開発機に送って動作確認（デバッグ）をした。

この開発機は、DOS－Vマシン（富士通FMR指定であった）とSCSI接続し、DOS－Vマシン側でコマンドを入力して使用した。実際のゲーム画面（ゲーム動作）はビデオ出力によりアナログＴＶに出力して見ることができた。

これ以前のファミコン用ゲームの開発は、パソコンで書いたプログラムをROMに書き込んで、そのROMを基板にセットし、それを実際にファミコン本体に差し込んで動作確認（デバッグ）をしていた。

ROMではあるが、ガラスの小窓が背中についていて、専用のイレーザーで紫外線を当てると、書き込まれた内容が消去でき。また書き込むことができた。十数回は、繰り返し使用できたと思う。

ROMに書き込んで基盤に差し込んで実際に動作させる開発方法は、忍耐の一字である。

よくわからないバグがあると、プログラム内にチェックのためのコードを書く。

あちこちにトラップを設定して、画面に処理中のパラメータなどを表示させたりするコードも書く。

そして、それをROMで動作させ、確認する。

大げさではなく、それを延々と繰り返すのだ。ほんとうに面倒だった。

この開発機は当たり前だがパソコンと接続されているので、エミュレーターが使え、ROMで動作させる必要はない。

その上、色々なデバッグ機能が用意されていたため、開発のときのストレスがかなり軽減された。

とはいえ、WINDOWSでなく、まだ【DOS-V（ＡＴ互換機で動作）】の時代である。今となっては、想像もつかない開発環境であった。

私は今もゲームではないがプログラムを書いている。

当時の開発環境のことをもっと書きたいが、愚痴だらけになってしまいそうなので、またの機会に。

＜スポンサーリンク＞

ファミコンのディスクシステム　＜1986年頃＞

ファミコンのディスクシステム　＜1986年頃＞

任天堂が、1986年2月に【ファミコン・ディスクシステム】（写真はここ）を発売した。

そして【ディスクシステム】発売と同時に、任天堂から【ゼルダの伝説】【スーパーマリオブラザーズ】等が発売された。

私の記憶では、その後にスポーツ物が多く出されたイメージがある。

その中で、私が開発にかかわったものが、二つあった。

【バレーボール】と【アイスホッケー】である。

どちらも任天堂ブランドであり、キャラクターデザインや音楽、ゲーム演出などは情報開発室で行われたが、その情報開発室の指示の基、実際の開発は私のいた会社で行った。

バレーボールは学生時代に私自身がバレーをしていたこともあって、私が日本で始めてゲーム化したもので、ＭＳＸというパソコンのようなゲーム機用に【アッタクフォー】という作品を作っていた。

それがひょんなことで任天堂の目に留まり、私の【アタック・フォー】が原作ということで【ディスクシステム】用にリメイクされた。

よって、あの選手の「腰の動き」は、もともと私のゲームのキャラの腰振りであったのだ。（少し自慢？）

私はその頃、ＭＳＸ用バレーボールゲームの仕上げをしていたので、ファミコン用の開発には直接かかわらず、ファミコン用のプログラミングはH氏が行った。

もちろん、すぐ隣の机で開発が進んでいるので、意見を言ったり、意見を求められたりした。

なにせ私は原作者だし。

私は会社員ではなく独立したゲーム開発者で、ゲーム単位で契約している立場だった。

バレーボールの原作が私の【アタック・フォ－】なのだが、私はファミコン用にリメイクする権利を承認したが、その契約は様々な経緯（会社経営者の突然の交代）で、結局は反故にされた。

そのとき会社と任天堂で、どういう契約が交わされたのかは聞かされていない。

私は個人で【アタック・フォー】を開発していたので、その時のその会社に、どういう権利があってそういうことになったのかも、わからない。

そのとき私が『淡泊』だったから？、いまだに謎である。

そういう裏事情はともかく、ゲーム開発という楽しい部分の話に戻すと、H氏はとても優れたプログラマーであったし、ＭＳＸよりファミコンのほうがハードスペックもよかったので、ファミコン版はＭＳＸ用のゲームより大幅に良いできになっていた。

6人の選手が、表示できたし。(^o^)

自分が原作のバレーボールが【ディスクシステム】によって、任天堂ブランドで世界で発売されたことは、本当に嬉しかった。

最初のマイパソコンは　PC-6001　＜1981年頃＞

最初のマイパソコンは　PC-6001　＜1981年頃＞

1981年に登場した、PC-6001。

【パピコン】という愛称（メーカーがつけた）で、テレビCFをしていた。価格は、9万円くらいだった。

コンピューターを物心ついたときから知っている今の世代には、そのときの【驚き】など見当もつかないだろうが、当時としては、価格の割には画期的ともいえる、9色のカラー表示、ひらがな表示、三重和音のPSG音源、ジョイスティックインターフェース標準搭載などを特徴としていた。

言語は、BASIC。

今となっては１００円ショップに売ってる製品かと思うほどのロースペックであったが、当時は素晴らしい製品であり、私はこのコンピュータとの出会いでゲーム開発者になったのだ。

（この段階で白状しておくが、私にとってゲーム開発という仕事は『絵・音楽・ストーリー・パズル的論理的プログラミングの総体』という部分では面白くはあったが、全然好きではなかった。それまでのフリーターとは比べようもないほど稼ぎが良かったのでやっていた。はははは…）

1979年くらいに、NECから PC-8001シリーズが発売されていたが、まだ高嶺の花だった。

他のメーカーのパソコンも高価だった。

そもそも、パソコン（個人が所有するコンピュータ）が、「普通ではなかった」時代である。

その2年後に、このPC-6001シリーズが発売された。

家庭用に簡単で安価なパソコンを！　ということだった。

私は文科系の人間だし、コンピューターのことは何も知らなかったが、なぜかどうしてもそれが欲しかった。新しい未来の道具という感覚だったのだと思う。

窮乏したフリーターだったため、マルイのカードの10回払いで買った。

１週間ほどは、BASICを使い、文字をカラーで表示したり、音を鳴らしたりして遊んでいたが、それ以上は何もできないことに気づいた。そう、使えないのだ！

発売されたばかりだから、このパソコンで動作するソフトがない。

というより、他のどのパソコンであれ、当時はパソコン用ソフトじたいがほとんどない。

そもそも、フロッピーディスクとかハードディスクなども、一般人が買えるレベルでは、どこにもない。

仮に自作のプログラムが作れたとして、どこに保存するのか？

音楽テープに録音するのである。

（現代人？には、意味がわかるまい…）

OSという感覚もないし、BASICだけでは、まともなことはほとんどできない。

（後のことになるが、アセンブラ言語を使って【マシン語】というもので直接コンピューターを制御するプログラムをBASICから呼び出すことにより、少しまともなことができるようになる）

自分で何かプログラムするといっても、そもそもコンピュータの原理がわからない。

そもそも、なぜ画面に文字が出るのだ？

なぜ、画面に色がつくのだ？

なぜ、ゲームなどのキャラクタ絵が表示され動くのか？

なぜ、というより、どうやって何を制御するのだ？ということなのだが…。

情報（身近で知識のある人、わかりやすい解説本等）が、まったくない。

とりあえず、当時コンピュータ関係の月刊誌がふたつあったので、それを買った。

じっくり読んでみたが、どうしても基本的なことがわからない。

まあ、書いてないわけだが、書いてあっても、何がかいてあるのかわからない。

その最初のポイントがわからないと、最初の一歩も動けない。まさに暗闇の中である。

「コンピュータって、いったい何なんだ？」

そして、私のPC-6001は、10日後には押入れに眠った。

そして、小説を書いたり漫画を描いたりする生活に戻った。当時は、ともかく何か作品を作る創作家になりたかった。

お金もないのに使えもしないものを買ってしまい、私は落胆し失望し、そのコンピューターを見るのもイヤになったのだ。

さて、こんなことで、私はゲーム開発者になれるのか？

なったんだが…。

＜スポンサーリンク＞

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

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

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

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

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

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

ベースボールゲーム紹介はここ

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

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

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

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

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

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

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

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

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

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

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

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

保存（録音）するときも数分～5分かかる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【この項、つづく】

＜スポンサーリンク＞

最初の開発ゲームは【ベースボール】　＜1982年頃＞ [2]

最初の開発ゲームは【ベースボール】　＜1982年頃＞ [2]

そういうデバッグ作業を、デバッガーなし、ハードディスクなしという環境で行うのは忍耐でしかない。

当時はそれが誰にとっても当たり前だったので、プログラム開発者は、根気強くやっていたわけである。

話がデバッグの方向に脱線したが、話を戻せば、【記憶媒体が音楽テープなので、正確に読み書きできないリスクがかなりある】ということである。

ということで、録音時や再生時にビット落ちする可能性を考えて、毎回最低2本の音楽テープに更新したデータやプログラムを【録音（保存）】する必要があった。

この【録音（保存）】が面倒だと怠っていると（実際にイヤになるほど面倒くさい…）、新しいコード部分のバグでプログラムが暴走すると、もはやパソコンをリセットするしかない。

そして極めて恐ろしいことに、【録音（保存）】していないパソコンの中の（ＲＡＭメモリ上）のプログラムは、あっさり消えてしまうということだ。

たとえば、数時間かけて新たに書いたプログラムコードは、一瞬で【消滅】する。

プログラムを作らない人でも、時間をかけて文を書いたり絵を描いたり、表を作ったりしたのに、つい保存をし忘れて、ソフトやパソコンがフリーズして【すべてが消えた！】経験はあるでしょう？

開発時にプログラムが暴走することは日常茶飯事。

ノッテくると、数時間は無意識状態で大量の行数のコードを書いていたりする。

そういうときは、たいがいバグを数か所含んでいて、動作させると、みごとに暴走する！

だから、新しいコードをある量追加し、動作確認する前には必ず、メモリ内にあるそこまでのプログラム内容を【いちいちコマメに】音楽テープに保存しておかねばならない。

ほかに保存する手段がないのだから。

開発中、数時間に数回、それを音楽テープに5分～10分ｘ２回かけて行うのである。

気分的には、保存に要する時間がプログラムを書いている時間より長いのではないかと思うほどなのだ。

集中も切れてしまう。

言葉は汚いが、「ばかげている！」でしょ？

せめてフロッピーディスクがあれば…。

（今の人は「フロッピーって何？？」だろう）

ハードディスクがあれば、保存など簡単だ！

当時レベルのプログラムやデータ量であれば、今なら数秒（いや1秒以下？）で保存できるし、読み込みもできる。どれほど開発効率がいいことか！！

ああああ、夢のよう。

最近、私が作ったデータベースのプログラムは、コンパイル後の実行版でも１０メガあるし、ソースなら１００メガあるかもしれない。このベースボールは数十キロバイト！しかないのに、この手間！

この文章の意味する【愚痴】が、平成３０年時代の人にわかるだろうか？

さて、このベースボールゲームのプログラムは、【Basic + マシン語】でできていた。

マシン語はアセンブラーを使うか、直に打ちこむ。

【キャラの動き等をサブルーチン化したマシン語でいくつも作り、それをBasicからCallしている構造】と説明しても、いまでは俄かには理解しがたいだろう…。

書いていると悲しくなってきたので、今回はここまで。

【この項、終わり】

＜スポンサーリンク＞

恐怖！ゲーム発売後のバグ【ダブル役満（ゲームボーイ）】

恐怖！ゲーム発売後のバグ

私はゲーム開発を始めた初期のころは、パソコン用ゲームソフトを一人で作っていたが、人生の先輩で超優秀なプログラマーであるＴ氏と知り合ってからは、彼と長く組んでゲーム開発をした。

Ｔ氏のことを私はすごく尊敬しているし、彼のことを書きたい気持ちもあるが、それは別の機会にしよう。（Ｔ氏の助手として参加した【世界コンピュータ囲碁選手権】のことは、こちら）

Ｔ氏はアーケード版の麻雀ゲームなども手掛けていたため、私は彼と組んで（助手？として、グラフィックと作曲とサウンド関係を担当）、幾つか麻雀ゲームを作った。

ゲームボーイ版のものは、販売数も多く、ゲームの出来も好評だったと思う。

そういう評価は、すべてＴ氏のプログラムが素晴らしいためである。

さて、ゲーム開発中は、当然ながらバグのチェックは徹底的に行う。

が、特殊な条件の時に生じるバグは、どうしても発見できなかったりする。

基本的な考え方として、

「バグは全部取りたい。でもそうはいかない。だから、ゲーム途中で停止したり、ゲーム内容が突然異常進行したりするような【致命的なバグ】でなければ、まあしょうがないだろう」

と、開発者や販売者は考えるしかない。

いくら多人数で時間をかけてデバッグをしても、数10万の本数が売れて熱心に遊戯されると、デバッグの時には生じなかったレアな状況も発生し、多様で特殊なバグが出るのである。

よって発売されてしまうと、当分の間は【俎板の鯉】も気分になる。

「へんなバグが出ませんよーに」

と、発売後は、祈るしかないわけだ。

ゲームボーイ版麻雀ゲームを最初に発売して数日後、発売元の企画営業者から電話がかかってきた。時期的になんとも不吉である。

「出ました（苦笑）」

「出ましたか…」

「さっき買った人から電話があって、こう言うんですよ。

『俺はいわゆる”組”のものだが、仲間内でオタクのゲームソフトで賭け麻雀をしてる。さっき白牌が場に５枚出た。おかしいだろ？それで俺は大負けした。どうしてくれる。賠償しろ！』

そういうんですよ。ははは（苦笑）」

「はははは（苦笑）」

調べてみると、あるレアケースでは確かに白牌が５枚、場に出ることもあることが確認された。そう、れっきとしたバグである。

ふ～む。

幸いなこと？に、ハングアップ（途中でゲームが停止し再起動になる）するような致命的なバグではなく、本当にごく稀な条件でプログラムが判断ミスすることが分かった。

おそらく何十万人で毎日遊ばれても、めったに出ないし、出ても気が付かないことも多いバグだということだった。

が、バグはバグである。

こういう場合は、

「そのゲーム基板（あるいはＲＯＭなど）が、どうも製造不良かもしれません」（嘘）

と言って取り換えるという処置をする場合がある、と聞いたことがある。

もう一度同じバグが出る可能性は、極めて低いため、

「商品の交換で直った」

と思ってくれる人もいるらしい。

ほんとかな？と思うが、そういうのも営業手腕の一つかもしれない。

実際にそういうことが行われていたのか、私は具体的には知らない。あくまで噂である。

そもそも、致命的なバグでもない限り、買い手も、

「まあ、そういうこともあるから、しょうがない」

と思ってくれるし…。

しかし、人によっては、納得してくれないだろうし…。今回は相手が悪そうだ。

クレームが長引くのではないかと、なんとも胃粘膜が溶けるような気分だった。

数日して、その営業から、また電話があった。

「どうなりました？」

「仕様にしました」

「仕様？」

「ええ。普通の相手なら『ごめんなさい』という気持ちで対応するのですが、この人は恫喝して、弁償しろ！金を出せと！しつこい人なので、負けてられないと思って、『この麻雀ゲームは、そういうもんです』と言い切りました」

「そういうもの？」

「ええ。この麻雀ゲームは、【開発段階から意図して】、【仕様として】、【時々白牌が５枚出てくるサービスモードがある】と、いうことにしました」

「ほう…」すごいことを言い切ったもんだ。

「このゲームには正式な仕様として【役満モード】ってあるでしょう？上りが全部必ず役満になるという」

「そうですね。そういう遊びモードありますよね」

「だから、裏技というか非公式仕様として、楽しいサービスモードのときに【時々牌が５枚になる】と言い張りました」

「へぇ。サービスモード？」

牌が５枚出るのが、なぜサービスなのか？

そもそも、遊戯者の意志と関係なく、勝手に時にそういうサービスモードになるってわけだから、それは、う～ん？と、私は思った。

だからクレーム相手も、そう思うだろう。大丈夫なのか！？

「信念でそう言い続けると、相手も諦めました。あのバグも一回きりで、その後は何も問題なく遊べているようですし」

「まあ、そうでしょうね…」

「ということです。ではまた」

その電話の後、バグを気にして減退していた私の食欲がいっぺんに正常に戻った。

私はゲームの仕様も考える立場であったから、

「そうあれは、そういう仕様だった！そうそう、そういう意図した仕様なのだから問題ない。あれは【牌５枚探しゲーム】という【おまけモード】なのだ」

と、自分に言い聞かせながら、パクパクとその日の夕飯を大食いした。

【リアル麻雀】紹介

この『リアル麻雀』は、流行に関係ない麻雀というゲームですし、作った我々が言うのもなんですが、本当にいいバランスで遊べる、今でも十分面白いゲームではないかと。m(_　_)m

＜スポンサーリンク＞