超連射68K 開発後記

開発の過程

• 1993 年ごろ
X680x0 の基礎ライブラリ整備


• 1995 年
超連射68K バージョン 0.10 リリース、 同人ソフトとしてコミケで販売


• 1998 年
超連射68K バージョン 1.00 完成


• 2001 年
Windows 移植版を作成、フリーソフト化して公開

開発当時の状況

• コミケで同人ソフトとして販売

超連射68K は当初同人ソフトとしてコミケなどで販売していました。 当時のコミケ会場は晴海埠頭でした。 まだ Windows 対応の同人ソフトはほとんど見られず、 歴代の国内パソコン用のソフトが集結してごった煮状態でした。 コミケで SHARP X680x0 枠が最も盛り上がりを見せたのは 90 年代末頃でした。 ゲームの配布メディアとして CD はまだ普及しておらず、 1MB のフロッピーディスクを利用していました。


• 草の根 BBS でユーザーからフィードバックをいただきつつ開発

当時、インターネットはまだ普及しておらず、 草の根 BBS と呼ばれる掲示板システムが、 有志により各地で運営されていました。 草の根 BBS は、直接管理人（シスオペと呼ばれる）の家に電話してモデムを直結し ログを読み書きをするという、非常に原始的な仕組みの掲示板です。

草の根 BBS 上では、ゲーム開発のための情報交換が活発に行われていました。 超連射68K に対するフィードバックも沢山いただく事ができました。


• SHARP X680x0 シリーズのこと

超連射68K は当初、SHARP X680x0 シリーズ上で開発されていました。 SHARP X680x0 シリーズは、1986 年リリースの国産パソコンです。 カプコンの CP システムの毛を抜いたやつにキーボードが付いた様なパソコンで、 アーケードゲームからの移植作が多く市販されており、 当時のゲーセン好きゲーマーにとっては憧れのマシンでした。

ハードウェア寿命の末期に入った頃、 相次いで内部仕様が書籍化され、 それを受けて X680x0 ユーザーコミュニティでは、 フリーソフトや同人ソフトの開発が活発化していました。


• 当時のゲーセン事情

グラディウス（1985年 コナミ） R-TYPE（1987年 アイレム）をはじめとした横シューブームが沈静化し 90 年代に入ると、 今で言う弾幕シューティングに繋がる縦シューが多くなってきました。

しかし 1994 年ごろ、シューティングゲーム自体のマニア化が進みすぎたことと、 格闘ゲームブームに押されたこと等の影響で、 このジャンルは瀕死の状態に追い込まれました。 縦シュー牽引役の東亜プランが倒産し、R-TYPE を作ったアイレムは一時撤退し、 グラディウスを作ったコナミは「ときめきメモリアル」の大ヒットで萌え事業に大きく舵を取り シューティングゲームからは遠ざかっていました。


• 影響をうけたゲーム

超連射68K は、当時ゲーセンで稼動していたシューティングゲームの影響を強く受けています。 特に影響が大きかったのは、 達人王（1992年 東亜プラン） BATSUGUN（1993年 東亜プラン） バトルガレッガ（1996年 ライジング） です。

開発当時留意していたこと

• 自機ショットのパワーバランスについて

自機ショットは、最弱状態と最強状態で、 外見上の弾数は 4 倍になっています。 しかし実際の威力の差は、わずか 1.375 倍です。

威力を見た目どおり 4 倍にしてしまうと、ゲームが破綻してしまいます。 見た目の派手さと、実際のゲームバランスは別ものと考えました。 こういった強引な調整は、往年の東亜プランのゲームバランスを参考にしています。


• 自機ショット拡散範囲について

当時ゲームセンターで稼動していたシューティングゲームは、 自機のパワーアップに伴いショット拡散範囲が広がる、 というフィーチャーを持ったものが多くありました。

自機のパワー段階に応じてショット拡散範囲を可変させると、 ゲームバランス調整が難しくなります。 スターフォース（1984年 テクモ） バルガス（1984年 カプコン） 1942（1984年 カプコン） といった拡散範囲固定型のゲーム群は、 後の世代の拡散範囲可変型のゲームにはない、 独特のゲームバランスがあります。

超連射68K は、スターフォースに習い、 ショット拡散範囲は固定としました。 今風な派手さも欲しいということで、拡散気味のショットにしました。 ここで問題となったのは、 拡散範囲をどの程度にするのかということでした。 広く拡散させすぎると、もはや自機を移動させることに意味はなくなります。 狭くしすぎても、地味な印象になります。 妥協ラインを模索した結果、現在の拡散範囲に落ち着きました。 さらに、自機ショットの密度を、正面方向に高く、 左右方向に低くすることで、正面方向で戦う必要性を発生させ、 スターフォース型のゲームバランスに誘導しました。


• 張り付き撃ちについて

古い世代のシューティングゲームには、 「張り付き撃ち」と呼ばれる、 敵に至近距離からショットを打ち込むテクニックがしばしば求められました。 これは、ゲーム性に緩急を出すことに繋がっており、 超連射68K に是非とも取り入れたい要素でした。

古い世代のシューティングゲームにおいて、 張り付き撃ちの必要性を発生させた要因は以下のようなものでした。


• ショット発射数上限が低いというソフトウェア上の制約

当時の CPU は処理速度が低く、ワークメモリの制約も厳しく、 ゲーム画面内に出せるショット数に上限がありました。 そのため、高速でショットを連射すると、 あっと言う間に画面内上限数に達してしまい、 先に発射したショットが画面から消えるまで次のショットが発射できない 「弾切れ」と呼ばれる現象が良く起きていました。

敵に至近距離からショットを撃ち込めば、 ゲーム画面内に出るショット数を少なくすることができ、 弾切れ現象を解消して連射性能を上げることができました。

典型的な事例はコナミのグラディウス初期シリーズで、 画面内 2 発という制約が一貫して採用されています。


• ショットの拡散範囲が広い

ショットの拡散範囲が広い場合、 敵に接近することで拡散するショットの全範囲を命中させ、 大打撃を与えることができます。 従って、張り付き撃ちの必要性が生じてきます。

鮫！鮫！鮫！（1989年 東亜プラン）の水色ショットなど、 沢山の事例があります。


• ショットの射程距離が短い

ショットの射程距離が短いため、 敵に命中させるには張り付き撃ち必須という仕掛けのものがあります。

タイガーヘリ（1985年 東亜プラン）、 スラップファイト（1986年 東亜プラン）のデフォルトショット、 達人王（1992年 東亜プラン）のナパーム弾、 オメガファイター（1989年 UPL）などがあります。

しかしこれらの要素を取り入れることは、 超連射68K のコンセプトとは相反していました。 まず、従来のソフト上の制約である弾切れ現象は発生させたくありませんでした。 また、ショットの拡散範囲をなるべく狭くすることで、 スターフォース型のゲームバランスに誘導したいという思惑がありました。 ショットの射程距離を短くするというやり方も、 プレイヤの観点からすると理不尽な制約と捕らえられる可能性があります。

超連射68K では、プレイヤに張り付き撃ちを誘発させるため、 敵側の衝突判定範囲を調整することにしました。 その結果、敵キャラの衝突判定範囲調整が頻発しました。 特に調整が多かったのが 4 面で登場するザコ戦艦（8 方向に弾を発射するだけの地味なやつ）で、 調整に伴いドット絵を 4 回ほど描き直しています。


• オート連射の是非について

古い世代のシューティングゲームには、 オート連射という概念は無く、 手連射の速度がそのまま実際のゲーム中の連射速度となっていました。

手連射世代のゲームには、 後のオート連射世代には無い撃ち込み感と手ごたえがあります。 手連射はシューティングゲームの醍醐味の一つでした。 しかしある時期からゲーセン用筺体にオート連射装置が導入されるようになり （経営者側の客寄せの意図もあった）、 ゲーム側もオート連射前提のバランス調整のものが登場し、 ついにはバランス均一化の都合から、ソフト的なオート連射が当たり前になってしまいました。

手連射速度は、動体視力や敵出現パターン学習とはちがって、 プレイヤに取って鍛えることが困難なスキルの一つで、 例えば敵の固さ設定を誤ると、 プレイヤによってクリア不能な障壁を作ることになってしまう懸念があります。 したがって、ゲームバランス調整面からも、オート連射はもてはやされました。

超連射68K には、当時失われつつあった手連射要素を入れたいと考えました。 散々悩んだ結果、 セミオート連射というフィーチャーの導入にとどめました。 最低限必要な連射速度は、親指でプチプチと連射するケースを想定して、 秒間 4 発程度に設定しました。 それ以上の速度で連射しても、ショット連射速度は変わりません。


• 撃ち込み音について

撃ち込みの爽快感を出すため、 撃ち込み効果音の発生頻度は、秒 30 回を目標としました。 つまり、自機ショット側の発射間隔を、秒 30 回以上に設定する必要がありました。 しかし、短絡的に秒 30 発の弾が撃てるようにしてしまうと、 自機前方にウネウネとショットが出っ放しという残念な絵になってしまうので、 別の方法を考える必要がありました。

超連射68K で採用した方法は、 拡散ショットの発射周期を、発射角度ごとに微妙にずらすというものでした。 この方法は非常にうまく機能しました。


• 効果音発声優先度について

X680x0 は、ハードウェアの制約から、 複数の効果音を同時発声させることができません。

超連射68K は、コンセプト上、破壊の爽快性を最優先に掲げています。 二番手が撃ち込みの爽快性です。 ボスキャラの攻撃シーケンスに依存する効果音などは、 ゲーム攻略上重要な要素にもなり得るので、 ショット打ち込み音よりも高めの設定としています。 結果的に、効果音の優先順位は以下のようになりました。

敵破壊音 > ボス攻撃シーケンス音 > ショット打ち込み音 > 自機ショット音

• 敵弾のコントロール精度について

真っ当にプログラムを組めば、 敵弾のコントロール精度は、命中率 100% の精度になります。 プログラム的にはそれは正しいことですが、 ゲーム性の幅を考えると、精度が高いほど良いということには必ずしもなりません。

敵弾のコントロール精度の低さが醸し出すゲーム性について、 以下の事例に着目しました。


• 飛翔鮫（1987年 東亜プラン）の事例

このゲームをはじめ、東亜プランのこの時期のゲームには、 敵弾発射角度を決定するアークタンジェントテーブルに独特の誤差があり （おそらく小数以下切捨てによる誤差）、 斜め 45 度方向の敵弾コントロール精度が低くなります。 その結果、斜め 45 度方向に発生する弾幕の切れ目をかいくぐるという 「切り替えし避け」という攻略法が発生することになったと考えられます。 （※同様のコントロール精度の甘さは、 雷電（1990年 セイブ開発）の開発者達も、 意図的に導入したという逸話があります。）


• パロディウスだ！（1990年 コナミ）の事例

このゲームでは、敵弾のコントロール精度は 16 方向に固定されています。 その結果、ライン合わせなどのいくつかのテクニックが有効となり、 独特のゲーム性を醸し出すことができています。


• V.V（1993年 東亜プラン）の事例

2 周目以降、相当な量の時間差撃ち返し弾で画面中敵弾だらけになりますが、 角度段階数が低いため、弾幕に適度なムラが生じて、思ったよりも避け易いです。 また、切り返し避けのチャンスも多くなります。


これらの事例に学び、 超連射68K では、状況に応じて敵弾のコントロール精度を調整しています。 とくに後半ステージでは精度調整をかなり意識して行うようにしました。


• アイテムのシステム

欲しいものが好きに選択できるアイテムの仕組みをどう実現するかは、 長年の懸案事項でした。

究極タイガー（1987年 東亜プラン）や雷電（1990年 セイブ開発）に出てくるような 一定時間で色が変わる方式のアイテムでは、 要らない武器を取らされてしまったときにストレスになります。 1943（1987年 カプコン）や、ツインビー（1985年 コナミ）のような方式では、 欲しいものを取得するためには、ショットを撃つのをやめなければならず、 これもストレスの元でした。

これらの欠点を克服できる方法を考察した結果、 現在の仕様におちつきました。

3 個同時取りというフィーチャーは、 お遊びで入れたら本仕様化してしまったものです。 スコアシステムとも密接に絡んでしまったので、 後から撤回することはできず、最後まで残ることになりました。 当初の 3 択というコンセプトを否定する安直なフィーチャーであり、 導入したことを後悔していますが、 後から撤廃してもユーザーの納得が得られるとも思えず、 そのまま放置となってしまいました。


• スコア稼ぎ要素の必要性をめぐる考察

当時ゲーセンでは、 スコアを意識してプレイすればするほど、 本来の遊び方が崩壊してしまうゲームが多く稼動しており、 ゲームにスコアは意味のある要素なのか？ といったような そもそも論 が多く議論されていました。 超連射68K は当初、稼ぎプレイに対して完全否定の立場でしたが、 バージョン 1.01 リリースの時点で若干のスコア稼ぎ要素を導入しました。

稼ぎ要素を導入するに当たって、 一旦ミスしたら、スコア効率が復帰不能な状態になる all or nothing 方式のバランスとするのか？ それとも、ミスを連発することは許容されていて、いかに立て直しを計るかで競うバランスとするのか？ は判断を迷ったところでした。 超連射68K で採用したかったのは、後者側のバランスでしたが、 実際のゲームはどちらかというと前者よりの内容になってしまいました。

スコア稼ぎを考察する上で、 バトルガレッガ（1996年 ライジング）には、かなりの影響を受けました。 ステージ序盤に乱数要素を持ってくる構成や、 パーツ破壊系のギミックなど、かなりの部分を参考にさせてもらっています。

X680x0 版の開発

• 開発言語

X680x0 には C コンパイラがありました。 gcc も移植されていました（当時のバージョンは 1.42）。 ゲームはアセンブラで作るもの、という価値観が残っていた時代ですが、 超連射68K の開発は、90% を C 言語 で行い、 実行速度が問われる部分のみ、ピンポイント的にアセンブラを利用していました。


• スプライト数上限の拡張

X680x0 はハードウェアスプライト機能を搭載していますが、 16x16 ドットのものが同時に 128 枚しか描画できません。 スプライト表示に使う PCG（16x16 のグラフィクスパターン）は 256 パターンしか定義できません。 この制約内では、どうしてもゲームが見劣りしてしまうので、 上限を克服するためのドライバ開発を進めました。

X680x0 のハードウェアスプライト機能は、ラスター方式と呼ばれるもので、 ディスプレイの走査線が通過したスプライトを、 走査線の下に移動させ、再表示するというテクニックが使えます。 これにより、スプライト表示数上限を、 ハードウェア制約の 4 倍の 512 枚にまで向上させることができました。 また、256 パターンしかない PCG 定義領域は、 キャッシュ領域であると考えて動的に割り当て開放することで、 API 上では定義数上限が無いように見せる仕掛けとしました。

このスプライトドライバは XSP と名前でライブラリ化して、 当時の草の根 BBS で公開していました。 需要があるかどうかわかりませんが、 こちら からダウンロードできますので、興味ある方はご自由にお持ち帰りください。


• 衝突判定まわり

当時の CPU では、多 vs 多の衝突判定は非常に重い処理でした。 これを高速化するため、専用の当たり判定システムを開発しました。 画面を縦横の短冊に分けて、 その論理積で衝突を検出するという仕組みで、 当時で言う「仮想 VRAM 方式」の発展形アルゴリズムでした。

この仕組みにより、 ハードウェアのスプライト数上限を超える数のキャラクタを リアルタイムで駆動させることが可能になり、 超連射68K の開発を軌道に乗せることができました。

Windows 移植版の開発

• Windows 移植版 初版

Windows 移植版は、DirectX3 の世代に開発開始しました。

正直、当時の DirectX は相当に胡散臭いものでした。 ハードウェアスプライト機能のサポート状況が劣悪だったため、 描画周りは CPU によるソフトウェアレンダリングの手法をとることにしました。 描画速度を向上させるため、 オクルージョンカリングなど、思いつく限りの最適化を行い、 なんとか 166MHz の CPU で 60fps を達成することに成功しました。

しかし問題は BGM の再現でした。 FM 音源周りの再現は、非常に専門的な知識が求められ、困難を極めました。 当時、mp3 や ogg vorbis などのフォーマットが出始めの頃でしたが、 フロッピーディスク 1 枚（1MB）サイズに収めたいという思惑があり、 サウンドデータに 1 曲数 MB の必要になるフォーマットの利用は見送られました。 BGM データの容量を小さく保つため、 MOD/XM フォーマットを解析してサウンドドライバを作成し、 BGM の移植を試みましたが、これは結果的に完成に至りませんでした。

幸いにも、有志により X68K FM 音源エミュレータが dll として公開され、 それを全面的に利用させていただく形で、 サウンド周りを実装することができました。


• X680x0 版と Windows 移植版の違い

残念ながら、X680x0 版と Windows 移植版は、微妙に動作が異なっています。 まず、X680x0 版の内部実装のバグ動作が Windows 版では再現できず、 その結果リプレイデータにズレが生じることがあります。 それから、フレームレートが異なっており、 オリジナルの X680x0 版が 55 fps 動作であるのに対して、 Windows 版が 60 fps 動作となっています。 また Windows 版では処理落ちの再現までは行っていません。 そのためゲームがかなり難しくなっています。

BGM について

振り返って思うこと