こんなソーシャルゲームを作っているとします
牧場経営ソーシャルゲーム: ユーザーは牧場を経営する。また、牧場などで育てたものを調理し、食べる事が出来る。 ユーザーにはステータスが存在し、様々な行動によってステータスが変動する。ある一定のステータスを伸ばすと出来る事が増える。 ステータスは割合で決定されており、どれかのステータスを上げると他のステータスが落ちる。 一度得た能力は消えない。
そして、このソーシャルゲームの運用はサーバーエンジニア、クライアントエンジニア、プランナー、デザイナー、プロジェクトマネージャー、ディレクターで運用されています。
サーバーエンジニア: メインの事柄は、ユーザーデータを管理。 クライアントが味噌カツを作りたいと要求してきたら、本当に味噌カツを作れるかどうか確認して、味噌カツを作る処理を行い、ユーザーデータを編集する。 味噌カツでいうと味噌カツを置く為の机や食べる人が座る為の椅子。土台。 クライアントエンジニア: ゲームの実部分。ユーザーが実際にゲームを遊ぶ部分の実装。 ユーザーが味噌カツを作る為のUIなどの表示、ユーザーが味噌カツを作るとボタンをタップしたら、サーバーに味噌カツを作ると要求を飛ばし、作れたらその旨の表示をする。 味噌カツでいうと味噌カツを食べる為の箸や味噌カツを載せる為の皿。 プランナー: ゲームの内容を決定する。 味噌カツを作ると決定する。味噌カツの味やどのような味噌カツを作れるのかなどを決定する。 味噌カツでいうと、味噌カツのレシピやメニュー。 デザイナー: ゲームの絵やUIを作成する。 味噌カツを描く。味噌カツ作成の為のUIなどを作成する。 味噌カツでいうと味噌カツ。 プロジェクトマネージャー: ソーシャルゲームのプロジェクトのマネジメントをする。 味噌カツでいうと、味噌カツを作る人を支える人。 ディレクター: ソーシャルゲームのディレクションをする 味噌カツでいうと、味噌カツの方向性を決定する人。
新規実装が決まりました
ぷらんな「先日の話し合いにより、納期までに使えるリソースを鑑みた上で、次のバージョン、ver味噌.カ.2にて、ウチの出している牧場ゲームに味噌カツを作る実装が入りました」
さーばーえんじにあ「わかりました」
ぷらんな「仕様書はまだざっくりとですが、こちらを参考にお願いします」
仕様書
仕様概要 ・既存の調理機能にて味噌カツページを作成し、ユーザーの所持する特定のアイテム群を消費する事によって、味噌カツを作れるように機能拡張 味噌カツについて ・味噌カツを消費するとユーザーのステータスのナゴヤ成分が上昇する。 ・上昇度合いは味噌カツの出来の良さによって決定される。 ・味噌カツの出来の良さは、既存の調理機能では、ユーザーのステータスだけで決定されていたが、味噌カツはそれに加え、消費するアイテムによっても変動する ・どのような味噌カツが出来るかはMisokatsuMasterで定義する ナゴヤ成分 ・ナゴヤ成分とはユーザーのステータスの新しい種類である ・ナゴヤ成分の上昇に伴う作用 ・ナゴヤ成分の割合により新たなレシピを作れるようになる(例: 小倉トースト、抹茶スパ、名古屋コーチン) ・新たなアチーブメントの追加 ※ナゴヤ成分の追加による事柄は全て既存マスタへのデータ追加で対応可能 ユーザーインターフェース要件(以下ユーザーインターフェースはUIと略す) ・調理トップ画面に味噌カツトップ画面への遷移ボタンを追加 ・味噌カツトップ画面で表示するものは以下 ・ユーザーの所持する味噌、豚肉、その他味噌カツを作成する為のアイテム一覧を表示、選択出来る ・ユーザーがこれまで作成した味噌カツを表示、消費出来る ・味噌カツ作成ボタン
ぷらんな「細かい点は追って記載しますが、現状は上記が確定事項です」
サーバーエンジニアがまず考えなければいけない事
納期までに使えるリソースを鑑みた上で、と前置きされているとは言え、サーバーエンジニアはまず最初に実装を完成させなければいけません。
そうでなければ、クライアントエンジニアはサーバーに味噌カツを作りたいと要求が出来ずに、ダミー味噌カツを使っての仮確認程度しか出来ないのですから。
なので、
・ 実装までにどれだけの時間が掛かりそうなのかをまずは計算したい
です。
その為にはまず、
・味噌カツ作りを実装する為に、サーバーはどのような事を実装しなければいけないのか
をリスト化しましょう。
それが分からなければ、実装コストも分かりません。
味噌カツ作りを実装する為に、サーバーはどのような事を実装しなければいけないのか
仕様書を見ると、味噌カツ作りの実装には3つの要素があります。
・味噌カツを作る事
・ナゴヤ成分の追加
・味噌カツの為のUIの追加
しかしながら、ナゴヤ成分の追加に関しては仕様書にも書いてある通り、既存マスタへのデータの追加で事足りると言うので、サーバーエンジニアが行う事は味噌カツを作る事及びに、味噌カツの為のUIの追加となります。
それではまず、仕様書の味噌カツについての部分を読み込んでいきましょう。
味噌カツについて ・味噌カツを消費するとユーザーの特性のナゴヤ成分が上昇する。 ・上昇度合いは味噌カツの出来の良さによって決定される。 ・味噌カツの出来の良さは、既存の調理機能では、ユーザーのステータスだけで決定されていたが、味噌カツはそれに加え、消費するアイテムによっても変動する ・どのような味噌カツが出来るかはMisokatsuMasterで定義する
その中で、トップに来ている以下の一文を見てみましょう。
・味噌カツを消費するとユーザーのステータスのナゴヤ成分が上昇する。
特定のアイテムを消費するとユーザーの特定のステータスが上昇する。これは、 ユーザーにはステータスが存在し、様々な行動によってステータスが変動する。 というゲームの特性上、普通にマスタの追加などで、サーバーの改修は必要とせずに完了しそうですね(食べるという行為をする事でステータスの上昇を今までは想定していなかったとか、そういう事がない限り、それで出来なかったらそのコードはクソです)。
まあ、上記を満たす為に行うべき事は、本当にサーバーの改修が必要でないか、の確認程度になりそうです。
プロジェクトに参画している期間にも依るでしょうが、そう時間は掛からないでしょう。
TODO: 味噌カツを消費する事でユーザーのステータスのナゴヤ成分が上昇する、は既存のコードで対応可能か確認する
とすると、残りは以下になります。
・上昇度合いは味噌カツの出来の良さによって決定される。 ・味噌カツの出来の良さは、既存の調理機能では、ユーザーのステータスだけで決定されていたが、味噌カツはそれに加え、消費するアイテムによっても変動する ・どのような味噌カツが出来るかはMisokatsuMasterで定義する
これらは既存の機能では対応できないので、既存の調理機能の改修または、味噌カツを作る為の専用機能の追加、で対応する事になりそうです。
TODO: 味噌カツ作りは既存機能では対応出来ないので、既存機能の拡張、または専用機能の追加を行う
次に、味噌カツUIの追加に関して見ていきましょう。
UIの実装に対してはサーバーエンジニアは余り影響しないような気もしなくもありませんが、そのUIを表示する為に必要な情報をクライアントが全て常に持っているとは限りません(データ漏洩などの観点から、基本的にクライアントには必要最低限の情報しか渡さないようにすべきです)。
なので、味噌カツUIを表示する為にクライアントが必要な情報をAPIを作成して適切に返してあげたりする必要があります。
UI要件 ・調理トップ画面に味噌カツトップ画面への遷移ボタンを追加 ・味噌カツトップ画面で表示するものは以下 ・ユーザーの所持する味噌、豚肉、その他味噌カツを作成する為のアイテム一覧を表示、選択出来る ・ユーザーがこれまで作成した味噌カツを表示、消費出来る ・味噌カツ作成ボタン
この要件から鑑みるに、味噌カツトップ画面でサーバーがクライアントに渡す必要がありそうな情報は、
・ユーザーの所持する味噌、豚肉、その他味噌カツを作成する為のアイテム一覧
・ユーザーがこれまで作成した味噌カツ
の二つです。
これを実際味噌カツトップ画面を表示する上で渡す必要が出てくるのならば、その情報を返すAPIを作らなくてはいけません。
クライアントエンジニアと相談になりますね。
TODO: 味噌カツトップ画面で渡すべき情報があるのならば、それ用のAPIを作成する
さて、これでサーバー側が実装すべき事は纏まりました。
・味噌カツを消費する事でユーザーのステータスのナゴヤ成分が上昇する、は既存のコードで対応可能か確認する ・味噌カツ作りは既存機能では対応出来ないので、既存機能の拡張、または専用機能の追加を行う ・味噌カツトップ画面で返すべき情報があるのならば、返すAPIを作成する
ここまで分かれば、実装に必要な期間も明確になってくるでしょう。それを共有し、スケジュールなどを組み立てましょう。
しかしながら、ここまでが分かっても、まだ実装に移るのは早いです。
次回に続く。
