東方暫永台の制作

「東方暫永台」は、2Dの弾幕格闘アクションゲームです。多彩で美麗、それでいてちょっぴり危険な弾たちが織りなす弾幕は本作においても健在で、他の格闘ゲームにはない斬新な形で登場します。個性豊かな幻想郷のキャラクターで相手をぶっ飛ばそう！

これは、完全なゲームを公開する初めての試みです。Twitter での公開投稿に6,000 を超える「いいね！」が付き、YouTube で25,000 回再生され、Steam で10,000 を超えるウィッシュリストがあることを考えると、このゲームは美しい美学と高い完成度を備えていると言っても過言ではないと思います。

プロジェクト情報

役割: プログラマー、ディレクター/プロデューサー、リードアニメーター
チーム規模: 10人以上
- プログラマー 1人（私）
- アニメーター3名（私を含む）
- イラストレーター1名
- 作曲家約10名
期間: 4年(2000 年 1 月 - 現在)
ツール: Unity、C#、Box2D (Unity)、Cinemachine (Unity カメラ動作プラグイン)、Aseprite (ドット絵描画ツール)、 Unity GGPO (Unity にインポートされた GGPO Rollback-netcode Framework)、 Game 2D Water Kit (ウォーターシェーダーアセット)、

プロジェクトの目標/範囲

GGPO Rollback-netcodeを使用した 7 人のキャラクターとオンラインマッチメイキングを備えた完全なゲームが Steam でリリースされます

モチベーション

私は『大乱闘スマッシュブラザーズ』シリーズと『東方プロジェクト』が大好きなので、この2つを組み合わせることにしました。『スマッシュ』では、戦闘が行われるステージは広大ですが、あくまでも「格闘ゲーム」であるため、戦闘は近距離戦闘に重点が置かれています。

赤色: 未使用のスペース

そこから、「遠距離戦闘に重点を置いた格闘ゲームがあったらどうだろう？」と考えたのがきっかけで、インスピレーションが湧きました。東方の起源が弾幕ゲームであること、ファンゲームに対する寛容さ、そして各キャラクターがさまざまな戦闘スタイルに対応する独自の能力を持っていることを考えると、楽しいゲームになる可能性を感じ、この長い旅に乗り出すことを決意しました。

チームを率いる

プロジェクトの規模から、Twitter（現X）に投稿して東方ファンの仲間に協力をお願いすることにしました。その後、Discordグループを作ってそこでコミュニケーションをとりました。

音楽に関しては、これはファンゲームなので、ミュージシャンはまったく新しい曲を作るのではなく、既存の曲をリミックスするだけでよく、東方には確かに選択できる曲が豊富にあります。

たくさんの人が手伝ってくれたので、基本的にミュージシャンにどんなジャンルの音楽をやれるかは自由に任せましたが、分析に行き詰まって迷子になった場合に備えて、必須のトラックのリミックスのリストとジャンルのウィッシュリストも提供しました。その後、ミュージシャンがリミックスしたい曲を集めて、参照用にスプレッドシートにまとめました。

また、音楽サークルの管理経験がある音楽リーダー（正確には、自発的に志願した人）を任命し、スプレッドシートの管理、完成したアルバムのメタデータの管理、トラックのマスタリングを担当してもらいました。

アニメーションについては、アニメーションを作成するためのスプレッドシートとその簡単な手順を作成しましたが、主なコミュニケーションは Discord で行われ、新しい課題の発表もそこで行われます。それでも、以前のアニメーションに簡単にアクセスして参照したり、フレームを再利用したりできるため、スプレッドシートは依然として役立ちました。

アニメーションのワークフローにも違いがあったため、私は自分のワークフローを説明するスライドを作成したり、作業負荷を分散するための最善の妥協案について議論したりすることもありました。

以前のファイターよりもかなり詳細なキャラクターをアニメーション化するためのヒントを提供するために作成したスライド

ロールバックネットコードの設定

ロールバックネットコードは、通常は格闘ゲーム用のオンラインプレイを実装するためのネットワーク技術です。この技術は、プレイヤーが予測された入力を使用してゲームのバージョンをプレイし、必要に応じて誤った予測を調整するためにゲームを再シミュレートすることで機能し、ゼロ遅延ネットワークの錯覚を生み出します。

GGPO の要件は次のとおりです。

ゲームの現在の状態を保存できる
保存された状態の読み込み
出力をレンダリングせずにゲームを決定論的に実行する

つまり、変更される可能性のある変数はすべて記録して保存する必要があり、どのスクリプトを実行するかの順序は決定論を保証するために非常に重要でした。

データの保存には、速度、位置、衝突ポイントなど、さまざまな情報を保存する巨大な構造体を作成することで取り組みました。

残念ながら、これは一部のオブジェクトが決して使用されない冗長な情報を保持していることも意味しており、システムをより効率的にするために、Entity Component System などの原則を参考にするべきだったかもしれません。いずれにしても、ローエンドのコンピューターでテストしてもパフォーマンスにはまだ影響がないようですので、そのままにしておくことにしました。

決定論を保証するために、ゲームは最初にロールバックプロセスに関係するすべての関連スクリプトを収集し、次に割り当てられた順序に基づいてそれらを並べ替え、更新ティックごとに、収集されたスクリプトを適切な順序で実行します。

ゲームのロールバックを早期に準備するためのボーナスとして、開発の早い段階で入力ベースのリプレイシステムも可能になり、フレームごとのモードでは、非常にスローモーションでバグをチェックするデバッグ機能も可能になりました。

リプレイシステムの動作は、東方コンベンションでゲームのデモをセットアップして収集されたゲームプレイデータを使用して、2人のプレイヤーが初めてゲームを試す様子を示しています。