ゲーム開発でDDD(ドメイン駆動設計)を取り入れる話になると、最初にディレクトリ構成から整理しようとするケースがあります。Domain、Application、Infrastructureのようにフォルダを分けると、設計が前に進んでいるように見えます。
もちろん、整理された構成には意味があります。コードの置き場が決まっていれば、実装時に迷いにくくなります。レビューでも、変更されたファイルの位置から意図を追いやすくなります。
ただ、ゲーム開発では、フォルダ名を揃える前に確認したいことがあります。
それは、チーム内で使っている言葉が同じ意味で使われているかどうかです。
同じ「ヒット」という言葉でも、企画、クライアント実装、サーバー実装、演出、QAで見ているものが違うことがあります。言葉の意味がズレたまま設計だけを整えると、レイヤーはきれいでも、仕様確認や実装判断で噛み合わなくなります。
「ヒット」や「死亡」は全員が同じ意味に捉えてるとは限らない
たとえば「ヒット」という言葉があります。
演出担当者にとってのヒットは、攻撃が当たったように見えるエフェクトやリアクションを指しているかもしれません。クライアント実装では、当たり判定が成立した状態を指している場合があります。サーバー側では、ダメージ計算まで終わり、結果が確定した状態をヒットと呼んでいるかもしれません。
同じ言葉でも、見ているタイミングが違います。
「死亡」も同じです。HPが0になった瞬間を死亡と呼ぶのか、操作不能になった状態を死亡と呼ぶのか、リスポーン待ちに入ったところまで含めるのかで、実装は変わります。
画面上ではキャラクターが倒れていても、内部状態としては「HP0」「死亡演出中」「操作不能」「リスポーン待ち」「復帰処理中」のように分かれていることがあります。ここをひとつの「死亡」という言葉だけで進めると、仕様書、変数名、状態遷移、テスト項目が少しずつズレます。
そのズレは、最初は小さく見えます。けれど、レビュー時に「このDeathはどの状態ですか」と確認が増えたり、QAで「死亡中に操作できる場合がある」と報告されたときに、何を不具合として扱うのか判断しにくくなります。
DDDは設計図を増やす作業だけではない
DDDというと、エンティティ、値オブジェクト、集約、リポジトリといった設計用語が先に見えやすいです。そこから入ると、どうしてもコードの分け方やクラス名の整理に意識が向きます。
ただ、ゲーム開発でDDDを使うなら、チーム内の翻訳ミスを減らす作業として見たほうが扱いやすい場面があります。
企画書に書かれた「ヒット」と、実装上のHitが同じものを指しているか。デバッグ表示のDeadと、仕様書にある死亡が同じ状態を指しているか。レビューで話している「進行不能」と、QAが報告している「進めない」が同じ条件なのか。
こうした確認ができると、実装時に迷いにくくなります。レビューでは、名前と処理内容のズレに気づきやすくなります。テストでは、どの状態を再現すればよいかを切り分けやすくなります。
設計図を増やすより先に、チームが同じ言葉で同じ状態を見られるようにする。ゲーム開発にDDDを入れるときは、ここから始めたほうが進めやすいことがあります。
全部の機能にDDDを入れなくてもよい
DDDを入れるとなると、プロジェクト全体をきれいに作り直す話に見えやすいです。既存コードが多いプロジェクトでは、その時点で作業の優先度を上げにくくなります。
けれど、すべての機能に同じ濃さでDDDを使う必要はありません。
ゲーム開発なら、戦闘、進行管理、報酬、マッチング、イベント状態のように、仕様の分岐が多く、チーム内の言葉がズレやすい部分があります。こうしたコア部分だけでも、用語を揃える意味はあります。
たとえば戦闘であれば、「攻撃開始」「判定発生」「ヒット成立」「ダメージ確定」「のけぞり開始」「操作不能」「死亡確定」のように、処理の順番や状態を分けて考えることがあります。これをすべて同じ粒度で命名できていないと、後から修正範囲を追いにくくなります。
進行管理でも同じです。「クリア」「達成」「受け取り済み」「完了」「解放済み」のような言葉は、画面表示、保存データ、サーバー状態、報酬配布で意味が分かれやすいです。言葉が曖昧なまま進むと、表示だけは完了しているのに報酬は未配布、保存データ上は達成済みだが次の導線が開かない、といった確認が増えます。
全体を一気に変えなくても、ズレたときに影響が大きい部分から始めるだけで、仕様確認やレビューの負担は減らせます。
用語集だけで終わらせず、動くコードに落とし込む
用語を揃えるとき、Wikiに用語集を作ることがあります。これは出発点として助かります。ただ、Wikiに書いただけでは、日々の実装やレビューで使われないまま終わることもあります。
言葉を揃えるなら、変数名、クラス名、状態名、ログ、デバッグ表示に反映したほうが確認しやすくなります。
仕様書では「死亡」と書いているのに、コードではisEnd、isDown、isDead、isDisabledが混ざっていると、どれがどの状態を指しているのか追いにくくなります。ログに出ている名前と、QAが見ている画面上の状態がつながらない場合もあります。
用語をコードに落とし込むと、レビューで確認するポイントが増えます。
この変数名は仕様書の用語と合っているか。
この状態名は画面上の表示と対応しているか。
このログを見れば、どの状態まで進んだか確認できるか。
この名前で、別の担当者が修正範囲を追えるか。
こうした見方ができると、用語集はただの資料ではなく、実装やレビューを支える確認項目になります。
既存コードを全部直す必要はありません。影響範囲が大きいコードを急に触ると、別の不具合を増やすこともあります。新機能や改修対象の周辺から、用語とコードの名前を揃えていくほうが始めやすいです。
新機能から始めるとレビューで確認しやすくなる
DDDをゲーム開発に入れるとき、最初から完成形を目指すと、作業が大きく見えます。ディレクトリ構成、設計ルール、命名規則、既存コードの整理まで一度に扱うと、どこから手をつけるか判断しにくくなります。
新機能から始めるなら、確認する範囲を絞れます。
仕様書で使う言葉を決める。状態名を決める。変数名やログに同じ言葉を使う。レビューで、仕様の言葉とコードの言葉がズレていないかを見る。テストでは、どの状態を確認しているのかを用語で追えるようにする。
このくらいからでも、十分に始められます。
DDDを導入するというより、チーム内で同じ言葉を同じ意味で使えるようにする。その結果として、設計やコードの整理が進みやすくなる。ゲーム開発では、この順番のほうが自然に進めやすいと感じます。
フォルダ名を整えることは、後からでもできます。先に言葉を揃えておくと、どのコードをどこに置くべきかも判断しやすくなります。
「ヒット」はどの瞬間か。
「死亡」はどの状態まで含むのか。
「クリア」と「達成」は同じなのか。
その言葉は、仕様書、コード、ログ、テストで同じ意味になっているか。
ここを確認できるだけでも、実装時の迷いは減ります。レビューで見るポイントも揃います。あとから不具合を追うときも、どの状態でズレたのかを確認しやすくなります。
おわりに
X（旧Twitter）やBlueskyを中心に日々発信しております。
是非他のSNSもご覧いただけますと幸甚でございます。
https://x.com/itchie_tatsumi
https://bsky.app/profile/itchie-tatsumi.bsky.social
https://www.facebook.com/ichino.souta
また、辰巳電子工業SS事業部では、エンジニアが安心して長く働ける環境づくりに取り組んでおります。「今の経験で応募できるか知りたい」「案件やキャリア支援について聞いてみたい」という方は、是非カジュアル面談からお気軽にご相談願います。
