Visual event configuration and management
全てのタグを見る
プレイヤーが死ぬ。死亡サウンドが鳴る。ラグドールが起動する。UIポップアップに「You Died」が表示される。ゲームがオートセーブする。アナリティクスイベントが発火する。リスポーンタイマーがカウントダウンを開始する。6つの異なるシステムが、1つのイベントOnPlayerDeathに応答している。でも質問がある——それはどこに文書化されている？
コードの中ではない。プロジェクト管理ツールの中でもない。どんなダイアグラムの中でもない。それが存在するのは1つの場所だけ：元々それをセットアップした人の頭の中。そしてその人が6ヶ月前にチームを離れていたら、どこにも存在しない。
これがイベント駆動アーキテクチャのダーティシークレットだ。システムを疎結合にするからこそ採用する。AudioManagerがUIManagerへの参照を持つ必要がないことを喜ぶ。でも決して語られないコストがある：実行フローが見えなくなる。そして見えないものは、定義上、視覚的にデバッグすることが不可能だ。
すべてのゲームは基本的に条件の巨大な山だ。「敵が耐性を持っていない、かつプレイヤーが炎バフを持っている、かつランダムクリティカル判定をパスした場合にのみ炎ダメージを与える。」プロトタイプ中は、コールバックにif文を放り込んで先に進む。30秒。動く。生産性を感じる。
そしてプロトタイプがプロダクションに入る。その30秒のif文が増殖し始める。1つが5つに。5つが50に。50が「2体目のボスのルートドロップ率を制御する条件ってどこにあるの？」になる。そして今、デザイナーが後ろに立ってダメージ閾値を0.3から0.25に変更できるか聞いている。そして君は再コンパイルが必要だと説明している。
if-else地獄へようこそ。住民：3ヶ月以上続いたすべてのUnityプロジェクト。
火曜の午後3時。デザイナーが横から声をかけてくる。「ねえ、プレイヤーが50以上のダメージを受けた時の画面シェイク、もう少し強くできない？あと、ヒットサウンドの前に0.5秒のディレイ入れたいんだけど。あ、毒エフェクトのティック間隔も2秒じゃなくて1.5秒にしたい。」
3つの変更。デザイナーの視点からすれば実質15秒の判断。でも実際に起きることはこうだ：Sceneビューを閉じる。IDEを開く。読み込みを待つ。ダメージハンドラーを検索する。メソッド内に埋もれた画面シェイクの強度値を見つける。変更する。次にオーディオのディレイを探す——これは別のクラスにある。変更する。次に毒のコルーチンを探す——これはさらに別のクラスで、ティックレートはWaitForSecondsの中にある。変更する。3つのファイルをすべて保存。Unityに戻る。再コンパイルを待つ。テスト。
8分後、デザイナーが言う。「やっぱりシェイクは前の方が良かったかも、あと毒は1.8秒で試せる？」