🤢

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

2021/04/23に公開

結論

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

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

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

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

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

ビジネスデータとは?

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

ビジネスロジックとは?

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

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

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

ゲームデータとは?

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

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

ゲームロジックとは?

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

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

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

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

実際の問題

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

混在したままの未来

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

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

あとがき

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

Discussion