「Flow Graph」タグの記事が3件件あります

プロシージャルダンジョンジェネレータが3つの感圧板とスパイクトラップのある部屋を生成した。次の部屋にはロックされたドアに繋がるレバーパズル。その次の部屋はボスアリーナで、ボスのヘルスフェーズに応じて環境ハザードが起動する。これらのイベントリレーションシップはエディタ時点では存在しなかった。ダンジョンレイアウトはプレイヤーが30秒前に入力したシードで決定されたものだ。

イベントをどうワイヤリングする？

従来のアプローチでは、巨大なswitch文を書く。各部屋タイプごとに手動でイベントハンドラをサブスクライブ・アンサブスクライブする。各AIの難易度ごとに手動で異なる攻撃パターンをチェインする。各MODコンテンツごとに手動でコンフィグファイルをパースしてイベント接続に変換する。「手動」の部分が問題だ——ランタイムでトポロジーが変わるたびにイベントワイヤリングロジックを再実装している。

ビジュアルノードエディタはデザインタイムで分かっているフローに最適だ。しかしゲームが実行されるまで存在しないフローを根本的に扱えない。そしてますます、最も興味深いゲームシステムはイベントグラフが動的なものだ。

プレイヤーが死ぬ。死亡サウンドと死亡パーティクルは同じ瞬間に始まるべきだ——片方を待ってからもう片方を始める理由がない。でも画面フェードはリスポーンポイントのロード前に絶対に完了しなければならない。リスポーンはプレイヤーのテレポート前に完了しなければならない。テレポートは画面フェードイン前に完了しなければならない。

1つのイベントからトリガーされる同じフロー内でのパラレルとシーケンシャル実行。そして不都合な真実：Unityのほとんどのイベントシステムはパターンを1つだけ提供する。イベントを発火し、すべてのリスナーが応答し、終わり。それらのレスポンスが同時に起きるべきか厳密な順序で起きるべきか？あなたの問題だ。

だから解決する。コルーチンで。コールバックで。_hasFadeFinishedという名前のブール値で。そして気づく前に、6つのファイルに散らばった場当たり的なステートマシンを構築してしまい、未来の自分を含めて誰もフォローできない。

プレイヤーが死ぬ。死亡サウンドが鳴る。ラグドールが起動する。UIポップアップに「You Died」が表示される。ゲームがオートセーブする。アナリティクスイベントが発火する。リスポーンタイマーがカウントダウンを開始する。6つの異なるシステムが、1つのイベントOnPlayerDeathに応答している。でも質問がある——それはどこに文書化されている？

コードの中ではない。プロジェクト管理ツールの中でもない。どんなダイアグラムの中でもない。それが存在するのは1つの場所だけ：元々それをセットアップした人の頭の中。そしてその人が6ヶ月前にチームを離れていたら、どこにも存在しない。

これがイベント駆動アーキテクチャのダーティシークレットだ。システムを疎結合にするからこそ採用する。AudioManagerがUIManagerへの参照を持つ必要がないことを喜ぶ。でも決して語られないコストがある：実行フローが見えなくなる。そして見えないものは、定義上、視覚的にデバッグすることが不可能だ。