SHARP X1の限界を突破した天才プログラマーたち――Z80 4MHzで生まれた奇跡のゲーム開発秘話

『リボルティーII』の極秘スクロール技術と、『ゼビウス』を変えたナムコの厳しい品質監修

はじめに――4MHzのCPUで、どこまでできるのか

1980年代、日本のパソコン市場には個性豊かな8ビットマシンが存在した。

NECのPC-8801、富士通のFM-7、そしてシャープのX1。

私は当時、SHARP X1G model30を所有していた。

5インチフロッピーディスクドライブを2基搭載した、いかにも1980年代らしいパソコンである。

ゲームを楽しむことが主な用途だったが、今になって当時のゲーム開発技術を調べると、驚くべき事実に出会う。

当時のX1の基本性能は、現代の感覚では信じられないほど非力だった。

• CPU：Z80A互換、4MHz

• メインメモリ：64KB

• グラフィック：640×200ドット、8色

• カラーPCG搭載

• ハードウェアスプライトなし

• グラフィックのハードウェアスクロール機能なし

特に致命的だったのが、グラフィックVRAMを高速に書き換えることの難しさである。

それでも、アーケードゲームに迫る作品が次々に生み出された。

なぜそんなことが可能だったのだろうか。

今回は『リボルティーII』とX1版『ゼビウス』を中心に、開発者の証言から、ハードウェアの限界に挑んだ技術者たちの知られざる歴史を追ってみたい。

第1章　リボルティーII――常識を覆した高速スクロール

1988年、X1ユーザーを驚かせた作品

1988年、風雅システムから『リボルティーII』が発売された。

同人ゲーム『リボルティー』の流れをくむ作品であり、X1シリーズの性能を徹底的に活用したシューティングゲームである。

特筆すべきは、そのスクロール表現だった。

X1には、グラフィック画面を自由かつ高速にスクロールさせる専用機構がない。

ところが『リボルティーII』は、2ドット単位の滑らかな多色スクロールを実現していた。

しかも、X1turboの高解像度機能に依存したゲームではなく、必要な周辺機器を備えた通常のX1でも動作したのである。

一体、何が起きていたのだろうか。

秘密は「描画する情報を減らすこと」

通常のX1では、RGBの3枚のビットプレーンによって8色を表現する。

640×200ドットの画面なら、1プレーンは16KB。3プレーンで48KBになる。

この大量のデータをZ80の4MHzで書き換えることは、非常に大きな負担だった。

一般的な高速化では、色数を減らして転送量を削減する。

しかし『リボルティーII』は違った。

開発者が選択したのは、カラーPCGとグラフィック画面の表示優先順位を組み合わせる方法だった。

まず、カラーPCGに色のあるパターンを表示する。

その手前に、黒と透明を切り替えるグラフィック画面を重ねる。

そして、このマスクとなる1プレーンだけをスクロールさせる。

マスクを通して奥のPCGの色が見えるため、あたかも色彩豊かな背景そのものが動いているように見える。

残りの2プレーンは、自機や敵、弾丸などの描画に利用する。

つまり、8色の背景を表現するために、8色分のデータをすべて動かしていたわけではなかった。

動かす必要のある情報だけを動かす。

この発想こそが、高速化の秘密だった。

後年公開された風雅システム関係者による技術解説では、この仕組みをカラー液晶パネルの原理になぞらえて説明している。

実に見事な着眼点である。

背景デザイナーにも高速化を要求していた

さらに驚かされたのは、背景データの設計方法である。

『リボルティーII』では、32×16ドットの背景ブロックを使用していた。

そのマップデータには「スクロール不要ビット」が用意され、書き換えなくてもよい部分を識別できるようにしていた。

例えば、縦方向に同じ模様が続く床やパイプは、毎回すべてを描き直す必要がない。

開発者は、こうした背景の特徴を利用して処理量を減らした。

しかも、背景パターンの上端2ドットを隣接パターンと自然につながるように設計し、書き換えの省略をさらに進めていた。

ここが重要である。

単にプログラマーがアセンブラを最適化しただけではない。

グラフィックデザイナーとプログラマーが協力し、ソフトウェアの処理負荷を減らす背景そのものを設計していたのだ。

現在のゲーム開発でも、描画負荷を考慮したアセット設計は重要である。

その考え方が1988年のX1用ゲームで実践されていたことに驚かされる。

この技術は社外秘だった

開発者の回想によると、この高速スクロール技術は当時、社外秘として扱われていた。

同じようなカラーPCGと表示優先順位の制御を備えた別のハードウェアにも応用できると考えられていたためである。

単なる一時的なプログラミングの工夫ではなく、将来の製品開発にも利用できる独自技術と認識されていたわけだ。

後年、グラフィックハードウェアの進歩によって秘密にしておく必要がなくなり、その技術が公開された。

そして現在、私たちは当時の開発者が何を考えていたのかを知ることができる。

第2章　PC-9801を使ってX1のゲームを開発していた

『リボルティーII』の開発秘話には、もう一つ興味深い点がある。

開発環境としてPC-9801を活用していたことである。

CGデータの多くはPC-9801上で作成され、MS-DOS上で動作する専用データ変換ツールがC言語で開発されていた。

X1用の200ライン画像に対応するため、グラフィック編集ツールも独自に準備していたという。

さらにオープニングのアニメーションでは、PC-9801上の3Dグラフィックツールで骨格を制作していた。

データの受け渡しには、X1のCP/M環境で利用するフロッピーディスク形式への変換を使っている。

現代の言葉で表現すれば、クロス開発環境である。

ホストマシンであるPC-9801で素材を制作し、ターゲットマシンであるX1で動作させる。

1980年代の時点で、すでに専用ツール、データ変換、ターゲット環境という開発パイプラインが成立していた。

ゲームプログラマーが1台のパソコンに向かってひたすらアセンブラを書いていた、というイメージだけでは説明できない世界があったのである。

第3章　発売1週間で破られたコピー防止技術

『リボルティーII』には、もう一つ知られざる技術が搭載されていた。

フロッピーディスクのコピープロテクトである。

当時はゲームソフトの違法コピーが大きな問題となっていた。

そこで開発側は「ギャップチェック」と呼ぶ独自方式を採用した。

フロッピーディスクには、通常のセクタデータとは別に、記録上の同期や間隔を確保する領域が存在する。

開発側は、このギャップ領域に秘密のキーワードを記録し、正規ディスクかどうかを確認するようにした。

一般的なコピーソフトでは正常に複製することが難しい方式だった。

ところが、発売から約1週間でプロテクトは解除されてしまった。

ディスクの特殊な記録方式を完全に再現したのではない。

プログラム側でプロテクトを検査する処理を見つけ、無効化してしまったのである。

これは実に興味深い。

記録媒体のコピーを困難にしても、最終的にソフトウェアが実行する検証処理を改変されれば、防御は回避されてしまう。

現代のソフトウェアライセンスやクライアント側のセキュリティにも通じる問題である。

1988年のゲーム開発者たちも、すでに攻撃者と防御者の技術競争に直面していたのだ。

第4章　X1版ゼビウス――ナムコの厳しい評価が開発を変えた

ようやく動いたゼビウス。しかし合格しなかった

1984年、電波新聞社はナムコの人気アーケードゲーム『ゼビウス』のX1版を開発していた。

中心となったのは、藤岡忠氏。通称「なにわ」である。

X1にはスプライト機能がなく、グラフィック処理にも制約が多い。

それでも開発は進み、ついに背景がスクロールする段階まで完成した。

藤岡氏は、その成果を『ゼビウス』のゲームデザイナーである遠藤雅伸氏に見せた。

しかし、遠藤氏の評価は非常に厳しいものだった。

キャラクターの見た目は悪くない。しかし、動きは駄目だという評価である。

なぜなのか。

問題は処理速度だけではなかった。

敵キャラクターの移動軌跡そのものが、アーケード版の『ゼビウス』とは異なっていたのである。

本物の動きとは何か

例えば、敵キャラクターが曲線を描いて移動する場面を考えてみよう。

X座標とY座標を単純に変化させるだけでも、それらしい移動は実現できる。

しかし、本物の『ゼビウス』が持つ独特の軌跡やタイミングを再現できていなければ、プレイヤーが感じる印象は変わってしまう。

遠藤氏が重視したのは、まさにその点だった。

藤岡氏は後年のインタビューで、移動計算を放物線に近いものへ修正するため、プログラムを大幅にやり直したと語っている。

しかも発売時期が迫っていた。

藤岡氏は社長に直訴し、発売を約1か月延期してもらった。

そして、可能な限り敵の動きを改良した。

完全な再現とはいかなかったものの、最終的に監修を通過して発売に至った。

この出来事を、藤岡氏は重要な教訓として記憶している。

単に画面が動けばよいわけではない。

ゲームには、そのゲームでなければならない動きが存在するのだ。

第5章　ゼビウスを支えた、もう一人の重要人物

X1版『ゼビウス』には、開発者以外にも重要な人物がいた。

大堀康祐氏、通称「うる星あんず」である。

大堀氏は優秀なゲームプレイヤーであり、作品に対する深い知識を持っていた。

その能力がゲームの品質評価に生かされた。

藤岡氏によると、グラフィックの違いや敵の動き、細かなタイミングについて、大堀氏は徹底的に修正を求めたという。

アーケードゲームを家庭用PCへ移植すると、画面サイズや縦横比が変わることがある。

すると敵の出現位置だけでなく、プレイヤーが反応するまでの時間も変化する。

それはゲームの難易度やプレイ感覚に直結する。

単に原作のプログラムを移植するだけでは、同じゲーム体験にならない場合があるのだ。

藤岡氏は、電波新聞社の移植作品が高い完成度を持っていた理由として、こうした評価担当者の能力を挙げている。

優秀なプログラマーだけで優秀なゲームが完成するわけではない。優秀な評価者が必要だった。

現代の品質保証にも通じる、非常に重要な証言だと思う。

第6章　1984年に約300万円の開発装置を導入していた

藤岡氏のインタビューには、もう一つ驚くべきエピソードが残っている。

電波新聞社では、ソフィアシステム製のZ80開発装置を導入していた。

藤岡氏の記憶では、価格は約300万円だった。

CPUの代わりにアダプターを接続し、プログラムの実行状態を調査できるインサーキットエミュレータを利用したシステムである。

社内には、このような高価な設備への投資を回収できるのかと疑問視する声もあった。

しかし、社長は開発に役立つのであれば購入してよいと判断した。

1980年代の300万円は、決して小さな投資ではない。

当時のゲーム開発には、個人の才能だけではなく、それを支える開発環境への投資も必要だったのである。

高度なデバッグ環境があれば、原因の特定が難しい不具合にも効率よく対応できる。

これは現代の組込み機器やファームウェア開発でも変わらない。

限界性能に挑戦するためには、優れたプログラマーと優れた開発設備の両方が必要なのだ。

第7章　リボルティーIIとゼビウス――二つの異なる技術思想

ここまでの開発史を比較すると、非常に興味深い違いが見えてくる。

『リボルティーII』が追求したのは、ハードウェアの制約を打ち破ることだった。

グラフィックVRAMを大量に更新できないなら、更新するデータを減らす。

カラーPCGとマスクを組み合わせ、ソフトウェア側の工夫で高速スクロールを実現する。

背景データも、書き換えが不要になるように最初から設計する。

これは徹底した性能最適化である。

一方、X1版『ゼビウス』が追求したのは、原作の体験を再現することだった。

描画が困難でも、敵キャラクターの動きを安易に妥協しない。

熟練プレイヤーによる厳しい評価を受け、ゲームとしての完成度を高める。

こちらは徹底した品質追求である。

両者には、現代のエンジニアリングにも共通する重要な原則がある。

仕様や性能の限界を理解することと、その限界を理由に思考停止することは、まったく違う。

制約があるからこそ、設計者には工夫が求められるのだ。

第8章　現代のPC開発者から見た1980年代のゲーム開発

私は長年PCの開発・評価に関わってきた。

現在のPCには、高性能なCPUやGPU、大容量メモリ、高度な開発ツールが存在する。

しかし、PCの性能がいくら向上しても、ソフトウェア開発の本質が変わったわけではない。

無駄な処理を減らす。

ハードウェアの特性を理解する。

開発と品質評価を連携させる。

必要な開発設備へ投資する。

そして、完成した製品がユーザーの期待に応えているかを検証する。

これらは、1980年代のX1用ゲーム開発者たちが実践していたことである。

特に『ゼビウス』の開発秘話は、品質保証の重要性を改めて考えさせてくれる。

優秀な評価者は、単に不具合を報告するだけの存在ではない。

製品が本来持つべき品質を理解し、開発者とともに完成度を高める存在なのである。

その価値を理解しない開発組織は、現代でも珍しくない。

1984年の電波新聞社には、すでにその重要性を理解した人々がいた。

おわりに――本当の限界はハードウェアではなかった

SHARP X1のCPUは4MHzだった。

メインメモリは64KB。

グラフィックVRAMも自由自在に書き換えられるわけではない。

現代のPCとは比較にならないほど厳しい制約である。

しかし、その制約の中から『リボルティーII』や『ゼビウス』のような作品が生まれた。

『リボルティーII』は、処理する情報を減らすことで高速化を実現した。

『ゼビウス』は、原作の動きとゲーム体験を再現するために、発売延期まで決断した。

そこには、優れたエンジニアリングがあった。

私は、こうした開発者たちの仕事は、もっと高く評価されるべきだと思う。

彼らは単にゲームを作っていたのではない。

ハードウェアの特性を深く理解し、限られた資源の中で最高の結果を生み出そうとしていた。

ハードウェアの性能には限界がある。しかし、その制約の中で何を実現するかは、技術者の発想と設計能力にかかっている。

1980年代のSHARP X1は、そのことを証明してくれたパソコンだった。

参考資料

本記事は、開発関係者の公開証言および技術資料を基に構成した。技術的な評価や現代の開発との比較は筆者の考察である。

1. 風雅システム『リボルティーII』技術解説
   高速スクロール、PCG、マスク処理、開発環境、コピープロテクトについての詳しい記録。

2. 藤岡忠氏インタビュー・開発環境
   Z80開発装置やICE導入に関する証言。

3. 藤岡忠氏インタビュー・ナムコの品質監修
   遠藤雅伸氏による評価と、X1版『ゼビウス』の発売延期について。

4. 藤岡忠氏インタビュー・移植作品の品質
   大堀康祐氏による評価と、電波新聞社の移植品質を支えた仕組み。

※『リボルティーII』の技術解説を、前身の同人版『リボルティー』の実装全体にそのまま適用できるわけではないため、本記事では主に商業版の技術を取り上げた。

#SHARP #X1 #レトロPC #ゼビウス #リボルティー #Z80 #ゲーム開発 #ゲーム史 #プログラミング #品質保証 #技術史