今作ってるゲームの設計の話 その2 ～ビジネスロジックとゲームロジック～

結論

ビジネスロジックとゲームロジックを分離する上での自分の答え

MVPをビジネスロジックとゲームロジックで個別に作る
ただし、お互いのデータを必要とするときはあるので、その際はインターフェイスを通して情報のみ閲覧できる形にする。

あくまでロジックの呼び出しなどは各々ネームスペース内で完結させることが理想

ビジネスロジックとビジネスデータとは？

ざっくりいうと、ビジネスデータの管理・操作・表示を行うロジックをゲームにおいてビジネスロジックと思ってます。

ビジネスデータとは？

お金や経験値、キャラクターの最大ステータスなど蓄積保存されるものが該当する
簡単に考えるならサーバーで保存しているデータはすべてビジネスデータとなる

ビジネスロジックとは？

上記のデータから当てはめるならば、表示は「ステータス画面の表示」や「所持している道具一覧」など
管理・操作は、「道具を使用した際にサーバー上で個数を減らす」や「金銭の獲得時の情報更新」などが該当する

ゲームロジックとゲームデータとは？

ユーザーのインプットやゲーム内の状況において変動するロジックの名称

ゲームデータとは？

大きく分けて二つに分類される

• エンティティデータ
  • キャラクタや建物などのオブジェクトごとに管理されるデータ
• メタデータ
  • 時間やゲームルールのような世界の構成情報とするデータ
    これらのデータはサーバーに保存されず、ゲーム内で変動、管理が行われる

ゲームロジックとは？

ジャンプした際の座標移動や当たり判定 → エンティティデータの操作
敵を攻撃した際の体力の変動 → エンティティデータの操作
時間制限でゲームが終わった時の動作 → メタデータの操作
ゲームの遊びとなる部分の処理はすべてゲームロジックといって問題ないだろう

各ロジックを考えた上でMVPをクライアントで作る

ビジネスロジックとゲームロジックの混在

これは私がゲームプログラマとして多く経験している問題でもある。
運用中のゲームでこの問題を正しく解決できているゲームはまずなかった

実際の問題

• ゲームロジックを管理するView
  • そもそもゲームロジックという概念がなく、画面で表示されるからViewで管理ってなってた
• とてもファットなPresenter
  • ゲームとビジネスロジック両方を担保してしまい、5000行を超えるコード
  • リソースのロードとサーバー更新用の処理が同時に書かれたりしてました

混在したままの未来

• 処理の分離がされないため、拡張性を担保できない
  • 仕方ないので5000行を超えるコードに足す
• 新規のゲームモードを追加する際にViewとロジックが一体化しており汎用性がなかった
  • コピペして同じような機能のクラスをもう一度定義し二重管理へ

このような顛末が多かった

あとがき

こちらは僕の個人開発での答えとなります。
「こんな考えあるよ」「こうしてみたらいいんじゃない？」
という意見がありましたら是非コメントください！