[戻る]

超連射68K 開発後記

超連射68K 開発当時の状況をふりかえってみました。

開発時系列

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

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

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

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

開発当時の状況

  • コミケ事情

  • 超連射68K をコミケでリリースしていたのは 1995 年から 1998 年までの期間でした。 当時のコミケ会場は晴海埠頭でした。 まだ Windows 対応の同人ソフトはほとんど見られず、 MSX や PC-98 シリーズなどの国内パソコン用のソフトが主にリリースされていました。 ゲームの配布メディアとして CD はまだ普及しておらず、 1MB のフロッピーディスクが主に利用されていました。

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

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

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

  • SHARP X680x0 シリーズのこと

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

    1990 年頃あたりから、ようやく内部仕様が書籍化され、 それを受けて X680x0 ユーザーコミュニティでは、 フリーソフトや同人ソフトの開発が活発化していました。

  • 当時のゲーセン事情

  • グラディウス(1985年 コナミ) R-TYPE(1987年 アイレム)をはじめとした横シューブームが一巡し、 90 年代に入ると、後の弾幕シューティングに繋がる縦シューが多くなってきました。

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

  • 影響をうけたゲーム

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

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

超連射68K を制作するにあたって、 どのような点に留意して調整を行ったのか、 また当時考察していたことを振り返ります。
  • 自機ショットのパワーバランスについて

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

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

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

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

    自機のパワー段階に応じてショット拡散範囲を可変させると、 ゲームバランス調整が難しくなります。 派手さとゲームバランスをどう両立させるかは難しい問題でした。

    ショット拡散範囲固定型のゲーム群は、 後の世代の拡散範囲可変型のゲームにはない、 独特のゲームバランスがあります。 スターフォース(1984年 テクモ) バルガス(1984年 カプコン) 1942(1984年 カプコン) などが典型的な例です。

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

  • 張り付き撃ちについて

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

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

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

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

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

      典型的な事例はコナミのグラディウス初期シリーズで、 画面内 2 発という制約が一貫して採用されており、 プレイヤに張り付き撃ちを促しています。

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

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

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

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

    • ショットの射程距離が短いため、 敵に命中させるには張り付き撃ちが求められます。

      タイガーヘリ(1985年 東亜プラン)、 スラップファイト(1986年 東亜プラン)のデフォルトショット、 達人王(1992年 東亜プラン)のナパーム弾、 オメガファイター(1989年 UPL)などがこれに該当します。

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

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

    弾幕世代以降のシューティングでも、 張り付き撃ち要素をどう発生させるかは、 各社工夫されているようです。 意図的にショット発射数制限を設けていると思われる例は多く見られます。 怒首領蜂(1997年 CAVE)シリーズのレーザー発射時のオーラ撃ちも、 張り付き撃ち要素誘発のためのフィーチャーのひとつと考えられます。

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

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

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

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

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

  • 撃ち込み音について

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

    超連射68K では、 見た目と打ち込み音を両立させるため、 角度ごとに微妙にずらしながら、秒 30 発の弾を発射するようにしました。

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

  • 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 定義領域は、 キャッシュ領域であると考えて動的に割り当て開放することで、 定義数上限をメモリの許す限り拡張可能としました。

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

  • 衝突判定まわり

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

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

Windows 移植版の開発

X680x0 版の開発が終了した翌年、 Windows の勉強がてらに移植を試みたことがきっかけで、 作成がスタートしました。

  • Windows 移植版 初版

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

    この世代の DirectX は、現在とはかなり状況が異なっており、 ハードウェアアクセラレーションのサポート状況が劣悪だったため、 描画周りは CPU によるソフトウェアレンダリングを採用しました。 描画速度を向上させるため、 オクルージョンカリングなど、思いつく限りの最適化を行い、 かろうじて 166MHz の CPU で 60fps を達成することに成功しました。

    むしろ問題は BGM の再現でした。 FM 音源周りの再現は、専門的な知識が求められ、困難を極めました。 当時出初めの mp3 や ogg vorbis などの ストリーミング系のフォーマットも検討はしたのですが、 総データ量をフロッピーディスク 1 枚(1MB)サイズに収めたいという思惑があり、 採用は見送られました。 MOD/XM フォーマットを利用し BGM は(アレンジ)移植するという案も出ましたが、 これは完成に至りませんでした。

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

  • X680x0 版と Windows 移植版の違い

  • 残念ながら、X680x0 版と Windows 移植版の動作を 完全に一致させることはできませんでした。 X680x0 版の内部実装のバグ動作が Windows 版では再現できず、 リプレイデータに互換性がありません。 また、フレームレートが若干異なっています。 オリジナルの X680x0 版が 55 fps 動作であるのに対して、 Windows 版が 60 fps 動作となっているほか、 Windows 版では処理落ちの再現は一切行っていません。 その結果難易度がかなり高くなっています。

BGM について

作曲担当は るざりん です。 るざりん は当時、このクオリティーの BGM を、 2 日 1 曲ぐらいのハイペースでリリースしていました。 丁度時期的に、ゲーセンから FM 音源が姿を消し始めた頃だったので、 FM 音源愛好家方面から 「もっとやれ」 との、 熱いエールを沢山いただきました。

現在るざりんは「巫女みこナース」などの電波ソング方面をはじめ、 各方面で活躍されています。

振り返って思うこと

開発にかかった労力のうちわけを振り返ってみると、 ゲーム本体を作っている時間よりも、その周辺の実装作業の方に、 多くの時間が投入されています。

例えば、X68K の貧弱な部分を解消する基礎ライブラリの作成、 初期の DirectX 飼いならしのための作業、 サウンドアーキテクチャの変更に伴う作業、etc...といったようなものです。

CPU の高速化、メモリやメディアの大容量化、 通信速度の高速化(=ダウンロード時間短縮)など、 時間とともに自然解決できる案件を 1〜2 年先取りするためにコードを書く行為は、 長期的に見れば労力の無駄使いでしかありませんでした。 ゲーム開発の阻害要因の解消のため、 どれだけ時間を投入するべきかのバランスは 常に考えないといけないところだと思います。 超連射68K は、このバランスがいまひとつ悪い例になってしまったように思います。

これを書いている 2009 年現在、 開発環境面での制約を感じることは無くなりました。 環境整備のオーバーヘッドが無いという環境下、 特定のアーキテクチャや OS 依存といったしがらみを離れて、 のんびりとゲーム開発を再開したいと思っています。 (仕事がひと段落したら着手したいです。といい続けて何年経過したかな・・・orz)

[戻る]