施策管理とID　How To MD #4

ゲームプランナーのみえうです。
この記事シリーズはマスターデータをスプレッドシートで作るTIPを紹介していきます。基本的に実務で使ったものを紹介していきます。
マスターデータって入れるの面倒ですよね。楽したいんです。楽にゲームが作りたい。この記事は楽にゲームを作る方法をマスターデータの観点から紹介します。
今回は第4回です。

今日はマスターのIDの話です。
各マスターデータのレコードを特定できる一意の値を指します。これの管理って結構面倒です。
・絶対に被っちゃダメ
・複数人で追加していく
・施策によって使うテーブルと使わないテーブルがある

連番ってめんどくさい

　普通に考えると連番でいいじゃんってなるんですが、これ問題があって上記に書いた複数人で追加数っていうのがネックになります。例えば、新武器を実装する施策が二つ、ほぼ同時期に実施されるとします。この場合、時期が被るので担当者が別になることが多く、実装期間もかぶります。そうすると連番だとIDが被ります。施策が二つならいいんですが、実際には10も20も同時に動くことになるし担当者ももっと多いです。となるち連番による管理だと値がコンフリクトする確率が上がります。
　数値がコンフリクトしたら直せばいいじゃんっていうじゃん？超面倒なんですよ。施策の担当者集めて、どの数値にしたらいいか話して、数値変えて。コンフリクトに気が付いたのが実装中ならいいけど、実際はmasterブランチにマージするまで気が付かなかったりもするわけです。ID変えたらQAし直しなので、どうあがいても施策のリリースは遅延します。IDの管理なんてしょうもないものでこんなリスク背負いたくないわけです。

どんなことしてたん？

　で私が使っていた手法は以下のものです。
・施策に番号を振る
・関連するマスターのIDはすべて施策のIDを含有したものにする
です。こうすると施策ごとの番号さえ管理していればIDは被らないです。施策の番号はスケジュールの策定者が決めておけばいいので、負荷もそれほども高くないです。

具体的にどうなるかというと
・ガチャA：10001
・ガチャB：10002
・ガチャC：10003
であれば
・ガチャAの新キャラ一人目のID：1000101
・ガチャAの新キャラ二人目のID：1000102
・ガチャBの新キャラ一人目のID：1000201
・ガチャCの新キャラ一人目のID：1000301
みたいな感じです。
IDってレアリティとか属性とか入れがちなんですが、運用するコンテンツはこれが一番うまくいきましたね。そもそもIDに意味づけするなら属性とかレアリティのような下位概念を入れると混乱のもと。後から属性が変わったり、レアリティが変わらないとも限らない。その時にIDを変えるのか？といった面倒な問題が生じてきます。なのでIDに含めるなら上位概念がおすすめです。

おわり

今日の記事は書きやすかった・・・！過去一書きやすかった・・・！画像はいらないし数式関係ないし・・・！こんなネタいっぱい思いつくといいな・・・！