デバッグ機能を作るときに考えていること

デバッグ機能を作るときに 考えていること @いも 2025/02/08 Unity Fukuoka 18 1

自己紹介 いも(@adarapata) 株式会社ミラティブ Unityエンジニアやってます 趣味でゲーム開発お手伝い中 幻想戦略録 2025/02/08 Unity Fukuoka 18 2

• https://x.com/adarapata
• https://store.steampowered.com/app/1761210/__The_Touhou_Empires/?l=japanese

話すこと UnityDebugSheetの紹介 デバッグ機能を作る際に考えていること 2025/02/08 Unity Fukuoka 18 3

デバッグ機能 チートとかフラグ設定とか様々な機能 開発するうえで必須 どこのご家庭にもあるけどあんまり表に出ないやつ ゲームによって違いすぎるからね！ でも知りたくない！？ まずは自分からだよね ということで、自分がデバッグ機能を作る際に意識していることを共 有します。 2025/02/08 Unity Fukuoka 18 4

UnityDebugSheet 2025/02/08 Unity Fukuoka 18 5

UnityDebugSheet
@harumak_11さんが公開しているデバッグ画面を簡単に作れるライブ
ラリ
モバイルネイティブっぽいUIを簡単に作れる
ページの階層化が簡単
UI追加がめっちゃ簡単
AddButton("Example Button", clicked: () => { Debug.Log("Clicked"); });

2025/02/08 Unity Fukuoka 18

6

• https://x.com/harumak_11

MemoryPackでゲームのリプレイデータを作った話 リプレイを保存したりなどなど。 2025/02/08 Unity Fukuoka 18 7

• https://tech.mirrativ.stream/entry/2025/01/31/100000

デバッグ機能を作る際に考えていること 本番に影響を与えない なるべくフローは変えない ユースケースを１つは用意する 2025/02/08 Unity Fukuoka 18 8

本番に影響を与えない デバッグ機能をリリースビルドに含めると、割と良くない事が起こ る。 うっかり機能を使えてしまう 悪意ある人が使えるようにしてしまう なので絶対に本番ビルドからは抜いておきたい。 Unityではasmdefを分離することで対応可能 2025/02/08 Unity Fukuoka 18 9

asmdefの分離 ✕ ○ アプリケーションコードとデバッグ機能の依存関係を整える 2025/02/08 Unity Fukuoka 18 10

設定を変える define constraintsでアセンブリをオミットする 任意のシンボルがあるときのみアセンブリを加えることができる。 コードを丸ごと取り除けるので確実にデバッグ機能は使えなくなる。 Prefabは消えないのでコンポーネントが消えたPrefabがシーンに残っ てしまうのは注意。 2025/02/08 Unity Fukuoka 18 11

依存の向きが Development -> Game になると、外側からゲームのデー タや機能にアクセスできるような構造にしないといけない。 DIコンテナで管理してたりすると取得しやすい。 var repository = LiftimeScope.Find<LifetimeScope>().Container.Resolve<UserRepository>(); repository.UpdateMoney(manyManyMoney); デバッグ画面は雑にこういうの書きがち 2025/02/08 Unity Fukuoka 18 12

なるべくフローは変えない ドラクエのようなRPGで「バトルをすぐ終わらせてスキップさせた い」という要望があったときに、どう実装するか。 バトル終了条件は「敵モンスターが存在しなくなったとき」と仮定す る 1. ForceBattleEnd 的なものを作ってデバッグから呼び出し強制的に終 了させる 2. プレイヤーのパラメータを超強くするor敵のパラメータを超弱くす る 2025/02/08 Unity Fukuoka 18 13

1は通常のバトルの流れとは完全に違う新たなフローをデバッグ用に 作り出すことになるので、メンテナンスが難しくなりがち 本体の機能追加に伴い動かなくなる危険性が高い 前のバージョンでは使えてたんですがというあるある 2はデータを更新するのでゲームシステムの範疇で想定される結果に なる。そこで問題が発生するならむしろ解決されるべき課題であるこ とが多い。 最大HP1の相手にHP割合攻撃したら0ダメージになった！ ほぼありえない状況だけどシステム的には対処しておくべき 2025/02/08 Unity Fukuoka 18 14

フローの変更よりデータの変更 フローを変更する ≒ 新たにメンテナンスすべき対象が増える 極力データの変更だけで要件を満たせるようにしたほうが開発中は楽 になる。 -> データのハードコードは開発中であっても基本避けたほうがお得。 ScriptableObjectにするだけでも十分。 2025/02/08 Unity Fukuoka 18 15

ユースケースを一つは作る 主にQAなど非エンジニアの他者が機能を使う場合に汎用的な要件を 満たすだけでは使いづらくなりがち。 例：プレイヤーの所持金を変更できるデバッグ機能 2025/02/08 Unity Fukuoka 18 16

入力画面を作り、数値を自由に設定できる実装にする 汎用性はあるが、毎回入力させるのは手間もかかる 2025/02/08 Unity Fukuoka 18 17

なぜその機能がほしいのかを考える アイテム購入を速やかに行えるようにしたいから？ 大量に所持したときのUI崩れを見たいから？ なんらかの理由があるなら、最低限それを簡単に満たせるデバッグを 作る 2025/02/08 Unity Fukuoka 18 18

例えば買い物に困らないだけあればいいのなら、入力させずにそうい うショートカットボタンを用意してあげる 入力を自動で上限いっぱいにするだけの「お金持ち」ボタン。 実装工数に対して効果は高い。 2025/02/08 Unity Fukuoka 18 19

不要なユースケースはすぐに消す 利用者がどの機能を活用しているのかは定期的にヒアリングしてお く。 しばらく使ってないけど全面に出てる機能がないか 頻繁に使うのに奥の階層に機能がないか デバッグ機能は増え続けるものなので粛々と精査するしかない UnityDebugSheetは並び替え、削除がしやすいのでオススメ 2025/02/08 Unity Fukuoka 18 20

まとめ デバッグ機能とコードはasmdefを切ろう フローを変更する前にデータ変更だけで解決できないかがんばる 目的に応じた親切なユースケースを作ってあげよう UnityDebugSheetはいいぞ 2025/02/08 Unity Fukuoka 18 21