「Client と Server があるスマフォゲームを開発するときに人類が考えておくべき、ほとんど全てのこと」をまとめる構想

2020-01-25 (Updated : 2020-06-10)

これは何

「Client と Server があるスマフォゲームを開発するときに人類が考えておくべき、ほとんど全てのこと」をドキュメントとしてまとめようと思ったときに、何を書けばいいかをリストアップする場所
- （構想を練る目的なので、不完全な内容です）
- のんびり更新予定

モチベーション

1. 仕事上の実利

職業柄、生きていくために Client / Server 実装があるスマフォゲーム を一定期間をかけてチームで開発することが多い
ゲームのチーム開発は要素が多く、先立って考慮しておくべきことも多岐に渡る
- 「考慮しておくべきことリスト」 を用意しておくことで、考慮漏れによるミスや手戻りを減らす
- 初心者にとっては抜けていた知識の補完になり、中級者以上にとっても思考リソースの節約になる
  - 人間は問われたものに答えること （再認） は比較的簡単にできるが、必要な情報を想起すること （再生） は難しいため

2. 自分の知識の整理

10 年ほど仕事をした中で積み上がった雑多な知見を、体系化して整理しておきたい
文書化することで、自分の知識と関心事を一緒に働くチームメンバーにも伝えやすくなる

3. 自分の要件を満たす前例が無いため

「プログラマーが知るべき〜」といったコラム集や「Unity プラクティス集」などのターゲットを絞った技術記事はあるが、ゲーム開発 1 本ぶんをスコープとした 現場感のある「考慮しておくべきことリスト」 というのは、自分はまだ出会っていない
ソフトウェア開発のプロジェクト運用を扱う優れた書籍はあるが、そうした書籍は汎用的な知識が手に入る一方で実践的な具体例に欠ける面がある
ある程度普遍性を犠牲にしたとしても、 「で、実際にどうするの」ということが分かる 実利にかなったリストを作成したい

こうしたドキュメントは「チェックリスト」と呼ばれるものが近いかもしれない
- 社内向けに作られた資料を見たことはあるが、一般向けに公開されているようなものはあまり無さそう？

ターゲットとなる「ゲーム開発」の定義

2020 年現在、一般に 「スマフォソシャゲ」 と呼ばれてそうな iOS / Android 向けの商用ゲームアプリを開発することを考える
- モデルケースとしては、ここに挙げたようなゲーム
- （据え置きゲームに関しては筆者自身にはノウハウが無いが、まあモバイルゲーム開発と共有できる知見は多いだろう）
開発チーム（開発関係者）の規模感は 10 〜 50 人程度を想定
Client はただの Viewer ではなく、レンダリングからゲームロジックまで色々処理する想定
Server はただのバックアップではなく、ユーザデータを操作する処理などを行う想定
トータルで数百 MB 〜数 GB 程度のゲームアセットを扱う可能性がある
リリース後も機能のアップデートが行われたり、ゲーム内で期間限定イベントが開催されたりすることがある

カテゴライズを考える

情報は適切な粒度やルールで分類することで扱いやすく・理解しやすくなる
ひとくちにゲーム開発と言っても 「ユーザの UX を良くするために考えるべきこと」 と 「実現するための技術的な選択肢」 とでは情報のカテゴリが違うように感じられる
まずは大カテゴリとして以下の観点で分けてみる：
- （各項目がどのカテゴリに属する話か、というのを意識するようにする）

観点	例
ビジネス	ターゲッティング / マーケティング / KPI
プロダクト / サービス	製品の品質 / 要件定義 / UI / UX / セキュリティ
開発技術 / 実現方法	設計 / 実装 / 使用するソフトウェア
プロジェクト管理	全体工程 / スケジュール管理 / タスク管理
ワークフロー	チーム開発のプラクティス / アセット作成のワークフロー
チームメンバー	コミュニケーション / モチベーション管理

※ 本稿はゲームを 「どう作るか」 にフォーカスした内容とする
- Why や What （「なぜ俺たちはゲームを選んだのか」とか「面白いゲームとは何か」とか） を語るのは別の機会にしよう
- （個人的には、本当はそういうことばかり考えていたいのだが…）

目次を考える

以下、こんなことを書けば有用なんじゃないか、という案出し。

次のような観点で「使える」リストを目指したい：

エンジニア / アーティスト / ゲームデザイナーがゲームの設計を行うときに 「あー、そうだこれがあったわ」 と思い出せる
プロジェクト序盤に偉い人レイヤー（上層部 / プロデューサー / ディレクター）と現場レイヤー（エンジニア / アーティスト / ゲームデザイナー）で 「これはこうなる想定ですけど、大丈夫ですよね？」 と 認識合わせ ができる

※ 観点はエンジニア視点にこだわらないが、筆者がエンジニアのため、どうしてもエンジニア視点の内容が多くなることに留意されたい

1. ビジネスの章

上位レイヤーの観点。チームメンバーで認識を合わせておきたいやつ。

なぜ作るのか

何がビジネス上の主目的となるか。基本的にはお金を稼ぐことが大義名分となるが、プロジェクトによってはそれが目的ではないこともある：

売上
認知度向上
ブランド価値向上
研究開発（組織の技術の積み上げや、メンバーの育成）

ターゲットユーザ

メインターゲットはどんなプレイヤーか
- カジュアル / ミドル / コア
- Timmy （体験） / Johnny （自己表現） / Spike （挑戦）
  - Vorthos （フレーバー） / Melvin （メカニクス）
- Achiever （ゴールしたい） / Killer （他人に勝ちたい） / Socializer （交流したい） / Explorer （探索したい）
- Newzoo による 8 分類
年齢、性別
どんな場所で、どんな状況で遊ぶのか

マーケティング

マネタイズ

何を売るのか
広く浅く売るのか、狭く深く売るのか
課金の種類
LTV > CPI を満たせるか

KPI 分析

分析基盤をどう作るか
何の KPI を見るか

法律関連

資金決済法
ライセンス表記 / 利用規約 / プライバシーポリシー
楽曲データなどの権利問題

2. プロダクトの章

基本的な要件定義

（前提）: リソースのトレードオフ
- 基本的にソフトウェアの品質 / パフォーマンスは以下のリソースのトレードオフの上に生まれる：
  - CPU
  - GPU
  - メモリ
  - ストレージ
  - ネットワーク帯域
対象端末のスペック、対象 OS
- どこまで足切りするか
- （使いたいグラフィックス API などに依存）
インストール時のバイナリサイズ
- Wifi 無しで DL できるサイズに収めたいか
想定するストレージ消費
- アセットの品質レベルはどの程度にするか
- 軽量モードの有無
想定するバッテリー消費
- リッチさとバッテリー消費は基本、避けられないトレードオフとなる
- 低電力モードの有無

スマフォならではの制約 / 要件

画面解像度 / アスペクト比 / ディスプレイ事情
- この話：

ゲーム開発

現代のモバイルゲーム開発者が向き合うべきディスプレイ事情と、その対応方法

2019-11-29

テクスチャの解像度とレンダリング解像度（dpi）
アセットの圧縮フォーマット
縦持ち / 横持ち / プレイスタイル
- がっつり両手でプレイする想定か？ / 基本片手でプレイできるようにさせたいか？
ステータスバーの表示
デバイス間のデータ引き継ぎを行うか
- iOS / Android 間の OS をまたぐ引き継ぎを行うか
- 有償ゲーム内通貨の扱い
複数同時端末プレイを許すか
- (レベル 1) : データ引き継ぎをしない限り 1 台の端末でしか遊べない
- (レベル 2) : 同じ OS なら複数端末でプレイできる（外では iPhone, 家では iPad のように）
- (レベル 3) : OS に関わらず複数端末でプレイできる

「複数の端末で遊べる」を要件に含める場合は複雑度が上がる

同時に起動した場合は、最後にアクセスした端末が操作権を得るのが一般的

データの整合性を保つためにはユーザデータは全て Server で管理する必要がある

Android の Back キー仕様

サービスの運用ポリシー

ローカライズ
- 多言語対応をするか
- 多言語の場合、ビルドを分けるか / 同じビルドで切替可能にするか
多国同時展開
- 国ごとに Server バージョンも分けるか
- 分けない場合、期間限定イベントの開始時刻などをどうするか
メンテナンスを行うか
- ゲームがプレイ不可能になる時間が発生することを許容するか
Client の強制アップデートを行うか
ゲームの動的アセットの更新タイミング
プレイ中に日付をまたいだ時の処理
- ログインボーナスと関連が深い
長時間置いてからレジュームした時の処理
チーターの扱い / BAN する基準

時代的によくある要件

申請時にリジェクトリスクのある要素
ストアの Featured 獲得に絡む要素
Push 通知の仕様
広告 SDK
コラボ案件
初回限定や期間限定の商品
サブスクリプション
- 自前か、OS の機能を使うか

イレギュラー時のハンドリング

ストレージが足りない場合の挙動
ネットワーク環境が無い場合の挙動
メインゲーム中にクラッシュした場合の復帰処理

3. 開発技術の章

開発技術の選定

Client
- 言語 / ゲームエンジン / ミドルウェア / フレームワーク / ライブラリ
Server / Infra
- 言語 / フレームワーク / ライブラリ
- クラウド or オンプレミス / インフラ構成管理
- データベース
データ作成ツール（レベルエディタ）
IDL を使うか
暗号化 / チート検出ツール
外部サービス連携
ドキュメンテーションツール

事前の取り決め

コーディング規約
- editorconfig
ディレクトリ構造

インフラ設計

想定されるユーザ数
サーバ構成 / 負荷分散
サーバの費用感

全体設計 / Client-Server 設計

ソフトウェアアーキテクチャ
Client / Server どちらにどれだけロジックを置くか
通信時のエラー処理
- Request が届かなかった
- 多重送信された
- Request は処理したが、Client が Response を受け取りそこねた
リアルタイム通信のマルチプレイがあるか
フィーチャーフラグや部分メンテナンス

セキュリティ / チート対策

防ぐか、検出可能に留めるか、そもそもどこまでやるか
チートの種類
Request / Response の Checksum
メモリ上に平文で持たないやつ
端末の時計 / 時間の取り扱い
未公開のアセットがバレる問題

リリース / アップデートに関する設計

アプリのバージョニング
アセットのダウンロード戦略
iOS 申請時のサーバ
チュートリアルの流れが変わるようなアップデート

ありがちな機能の設計

リアルタイムランキング
プレゼント配布
ガチャ
キャラクターを何百体も保持するようなゲームのインベントリ

4. プロジェクト管理の章

開発からリリースまでの工程

プリプロ、プロトタイピング、α 開発、β 開発などのフェーズ定義
ブラッシュアップ期間とれる？
サーバの負荷試験やる？
セキュリティ診断を外部会社使ってやる？
βテストやりたい？
事前予約？

開発モデル

スケジュール管理

タスク管理

プロジェクトあるある / 経験則

大抵、当初の見積もりの 1.4 倍くらいはかかる
- それを考慮していても、それ以上の時間がかかる（ホフスタッターの法則）
ブルックスの法則

5. ワークフローの章

マスタデータ

Excel か Google Spreadsheet か
マスタデータの並行開発
- 人類はまだバイナリのコンフリクトを克服できていない
マスタデータのインポートフロー / バリデーション
ツリー構造の扱い

ブランチ戦略

Git フローとかそういうやつ
ブランチごとのテスト環境

開発時のワークフロー

Pull Request 開発
コードレビューとマージ判断のルール
Server ↔ Client のつなぎ込みフロー
デイリービルド
非エンジニアの Git の取り扱い
非エンジニアの作業環境 / テスト環境

ユニットテスト

ユニットテストと CI
ロジックをヘッドレスで動かせるか？

デプロイ / 運用プロセス

Blue / Green デプロイ
マスタデータのデプロイフロー
お知らせ更新、プレゼント配布等の操作フロー
データベースのバックアップ
CS 対応 / ユーザ問い合わせ
A / B テスト
- 仕組み
- 有意性の判断 / 信頼区間
- ユーザの不公平感を出さないように注意
カナリアリリース

QA / プレイテスト

デバッグメニュー
サーバ時間の扱い
QA 捗る Tips
- 意図的に通信を失敗させられるか？
- 特定の状況のユーザデータをセーブ / ロードできるか？
- ガチャのように、多くの試行回数で確率を担保するようなものはシミュレータがあると安心
プレイテスト / レベルデザイン捗る Tips
- 本番環境のリアルなデータを検証環境に持ってこれるか？
- ダミーユーザ