「Performance」タグの記事が2件件あります

QAテスターがバグを報告する：「鍵を拾ってもドアが開かない。」

シンプルだろう？ おそらく参照漏れか条件の間違い。プロジェクトを開き、鍵を拾うと...ドアは問題なく開く。自分の環境では再現する。テスターに再現手順を聞くと「30%くらいの確率で発生する。大抵セーブ/ロードサイクルの後」とのこと。

デバッグ地獄に突入だ。鍵ピックアップイベントからインベントリ更新、クエスト進行チェック、ドアのアンロック条件に至るチェインのどこかで、何かが間欠的に失敗している。しかしどのリンクだ？ イベントが発火されなかった？ 発火されたがリスナーがサブスクライブされていなかった？ サブスクライブされていたが条件がfalseに評価された？ 条件は正しかったがロード後にドアの状態が古かった？

Unity Asset Storeのイベントシステムプラグインはどれも説明文のどこかに「高性能」と書いている。「使いやすい」と「完全なドキュメント付き」の間くらいに。でも考えてみてほしい。1msも0.001msも人間の感覚では両方とも速い。でも片方はもう片方の1000倍遅い。プラグインが「高性能」と言うとき、実際に何を意味している？何と比べて？どうやって計測した？

以前は気にしなかった。ほとんどの人がそうだ。イベントを配線して、開発マシンで問題なく動いて、出荷する。でもモバイルプロジェクトで何百ものエンティティがそれぞれ複数のイベントをリスンしている案件に携わったとき、「高性能」はマーケティングのチェックボックスではなくなった。60 FPSとスライドショーの違いだった。

この記事は、イベントシステムにとって「高性能」が実際に何を意味すべきか、なぜほとんどの実装が不十分なのか、GESがExpression Treeコンパイルを通じてどうゼロに近いオーバーヘッドを実現するのかについて。実際の数字で、手を振るのではなく。