目次

• 本書について
• 本書の構成
• サンプルゲーム＆プレイ動画
• 本書の補足情報コーナーのご案内
• 謝辞
• 基本用語の整理

第0章　［速習］オンラインゲームプログラミング ――ネットワーク×ゲームプログラミングの技術基礎

0.1　［オンラインゲームプログラマのための］ネットワークプログラミングの基礎

• ネットワークプログラミングは必須（！）
• ネットワークプログラミング、インターネットプログラミング
• インターネットプログラミングの歴史と思想
• OSI参照モデル ──規格やハードウェアの変更を透過的に処理したい
• オンラインゲームシステムとレイヤ
  • レイヤ4は多くの場合TCP、レイヤ3以下は直接操作する必要なし
  • レイヤ5以上はゲームごとに実装する
• ソケットAPIの基礎知識
• オンラインゲームとソケットAPI ──レイヤ4のソケットAPIを使う
  • コネクション指向（ストリーム型）、コネクションレス指向（データグラム型）
• Column　ネットワークプログラミングの特性と、ゲーム形式の関係 ──サーバ、クライアントに求められる性能/機能

0.2　ソケットプログラミング入門 ──複数同時接続を捌く、性能を追求する

• 通信路の特定（おさらい）
• ソケットAPIの基本 ──単純なECHOサーバ、ECHOクライアントの例
• TCP通信路の状態遷移とソケットAPI
• 複数の同時接続を捌く ──非同期ソケットAPIへの道
• 同期的な呼び出し（ブロッキング）とスレッド
  • スレッド方式の処理負荷問題
• シングルスレッド、ノンブロッキング、イベント駆動 ──select関数でポーリング
• オンラインゲームにおける入出力実装の特徴 ──シングルスレッド、イベント駆動、ノンブロッキング
• オンラインゲームと実装言語
• 性能の最大化＆開発効率向上 ──まずは実装言語から、低レイヤへ
  • オンラインゲーム特有の理由による言語の性能差
• マルチコアサーバの性能を引き出す
• Column　入出力の実装指針と、今後の性能向上の可能性
  • コンテキストスイッチ ──CPUの設定状態を退避する
  • マルチコアマシンでサーバプロセス数を増やし過ぎなければOK
• マルチコアマシンとネットワークのスループット ──オンラインゲームと小さなパケット
  • Ethernetフレーム
  • ネットワーク階層ごとのヘッダ
  • マルチコアマシンの送信能力
• サーバ実装の省力化 ──libevent
  • libeventの特徴

0.3　RPCの攻略 ──最小機能の通信ミドルウェア化

• 通信ライブラリの必要性
  • フォーマットを決めて送受信をする
• オンラインゲームで使うRPCの全体像
  • RPCスタブコードを自動生成するRPCツール
  • オンラインゲームと、バイナリのデータ交換フォーマット/ライブラリ
• ［補足］UDPの利用

0.4　ゲームプログラミングの基礎

• ゲームプログラミングの歴史
• 「ドットが打てればゲームは作れる」路線で作るインベーダーゲーム
• 仮想コードで見えてくる！ ゲームプログラムの基本解剖
  • 初期化
  • 永久ループ
  • 各Spriteの動作 ──ゲームロジックの本体
  • 描画
  • サブルーチン
• ゲームプログラミングの極意 ──スレッドを使わない「タスクシステム」
• 2つのプログラミング手法の類似性 ──スレッドを使わない

0.5　まとめ

• Column　開発効率と、プラットフォーム間の移植性の確保

第1章　オンラインゲームの歴史と進化 ──ゲームが「ネットワーク」を取り込んだ！

1.1　オンラインゲームの技術史

• オンラインゲームの歴史は、まだ50年
• 1950年以前：計算機の登場
• 1950年代：初期のビデオゲーム
• 1960年代：影響力を持った各種マシンの登場
• 1970年代：オンラインゲームの基本要素の勢揃い
• 1980年代：ネットワーク対戦ゲームの登場
• 1990年代：ゲーム市場の拡大
• 2000年代前半：オンラインゲームの商業的成立
• 2000年代後半：WebブラウザベースMMOGの商業的成功
• 2010年代以降：一体、何が起こるのだろうか？

1.2　技術の変遷から見えてくるゲーム文化/経済圏

• 技術の変遷図を読み解く
• 3つの圏（カテゴリ）
  • ハッカー文化圏
  • コンソール/アーケードゲームビジネス圏
  • Microsoft圏
• 2つのゲーム経済/文化圏
• 文化や経済と、技術の関わり

1.3　まとめ

• Column　売れるオンラインゲームプログラマの条件

第2章　オンラインゲームとは何か？ ──さまざまな角度から見る「オンラインゲーム」

2.1　「オンラインゲーム」の用語の定義

• オンラインゲームの4つの側面

2.2　オンラインゲームの物理的側面

• 物理的な構成要素
• 物理モデル/物理的なネットワーク構成
• 本書の対象とする回線は「インターネット」ベース

2.3　オンラインゲームの概念的な側面

• オンラインゲームと基本構造
  • ゲームプレイの基本 ──「認知」「判断」「操作」の繰り返し
  • ビデオゲームのしくみ
• ゲームプレイ空間 ──ゲームプレイに必要な情報のすべて
• ゲームの進行 ──ゲームプレイ空間の変化
• 同じゲーム進行を共有する
  • 共有することが「できる」

2.4　オンラインゲームのビジネスとしての側面

• ビジネスの観点から出る要求
• テストプレイヤーを効果的に集めたい ──オンラインゲームとテスト
  • クローズドベータテスト（CBT）
  • オープンベータテスト（OBT）
• 頻繁に更新したい ──オンラインゲームの運営と更新
  • (1)定期的なパッチ
  • (2)大規模パッチ（拡張ディスク、追加パッケージ）
  • (3)緊急メンテナンス
• マシン台数と帯域を節約したい ──オンラインゲームにおける費用の特殊性
  • (1)人件費＆(2)設備コスト ──運営、発売後にかかるコストが大きい
  • マシンコストの見積もり ──サーバが壊れる確率を見込む
  • 回線コストの見積もり ──帯域はできるだけ節約する
• 小さく始めたい、スケーラビリティを持たせたい ──リスクは最小限に、勝機は逃さない（!?）
• 多くの課金オプションを提供したい ──課金決済の変化
  • ゲームポイントの登場 ──課金の細分化、リアルタイム化の実現
• 攻撃（abuse）者を安く、早く、確実に排除したい ──攻撃、不正行為とその対策
  • 商業的な意図のabuse
  • 商業的意図ではないabuse ──種々の攻撃、3Dオンラインゲームの専用ゲームクライアント
• サービス停止を少なく、短くしたい ──プレイヤーの失望につなげない
  • (1)計画的なメンテナンスによる停止
  • (2)不具合や攻撃によるサービス停止
• ゲームプレイの結果をフィードバックしたい ──ログ解析と結果の可視化
  • ゲームプレイのメタ情報
  • (1)ハイスコアランキング
  • (2)プレイ実績
  • (3)その他の統計
  • より高度な技術が要求されるプレイ実績
• もっと簡単に他のプレイヤーと出会えるようにしたい ──プレイヤーマッチング
  • (1)自動選択式
  • (2)専用ロビー
  • (3)仮想世界（ビジュアルロビー）
  • 専用ロビー形式と仮想世界の違い
  • プレイヤーマッチングの今後

2.5　オンラインゲームの人と組織の側面

• オンラインゲームサービスの運営に関わる人々
  • 3つの機能と分担のパターン
• オンラインゲームサービス運営の3つの専門機能
• 作る人たち
  • 欠かせない4つの職種
  • 小規模なチーム
  • 大規模なチーム
  • 職種のバランスに見られるゲーム開発特有のポイント ──データ作成スタッフの比率
• 運用する人たち
  • サーバ設備

2.6　オンラインゲームプログラマに求められる知識群

• オンラインゲームプログラマに必要なスキルや経験
  • プログラミングの基礎スキル
  • ゲームプログラミングの基礎知識（オンラインゲームの開発でも必要あるいは有用）
  • ゲームクライアント開発の知識
  • DBの知識
  • システム運用の知識
• 多岐にわたるオンラインゲームの開発知識

2.7　オンラインゲームを支える技術の大区分

• オンラインゲームを支える技術の4つの形式
  • C/S型とP2P型 ──物理的な構造の、2つの典型パターン
  • MMO型とMO型 ──論理的な構造の、2つの典型パターン
  • オンラインゲーム4つの形式 ──物理的な構造×論理的な構造

2.8　開発コストを左右する技術的ポイント

• オンラインゲームと、開発技法の今
• オンラインゲームのゲーム本体を支える3つの軸
  • ゲームのデータ形式
  • ゲームの通信形式
• ゲームの反応速度

2.9　まとめ

• Column　オンラインゲームプログラムの最大の難所 ──「冗長化」と「非同期化」を攻略せよ

第3章　オンラインゲームのアーキテクチャ ──ゲームのおもしろさ×技術的な制約との戦い

3.1　ゲームプログラムの特性 ──高いレスポンスを維持し続ける

• レスポンスの重要性 ──とにかく時間が足りない！
• オンメモリが必要な理由 ──ゲームプログラミングの三重苦（!?）
• (1)16ミリ秒ごとの変化 ──扱う情報とサイズ
  • ゲーム進行を表現するのに必要な情報とサイズ
  • RDBMSを用いて実装できるか？ ──オンメモリとの対比のために
• (2)大量のオブジェクトの表示 ──CPUの処理能力
  • ファミリーコンピュータとCPUサイクル
  • PlayStation 3（PS3）とCPUサイクル ──RDBMS方式で開発できる？
• (3)プレイヤーの操作を予想することができない ──ゲーム状態の多彩な変化
  • RDBMS方式では実現できない情報量、処理速度
• CPUと同じマシンに、ゲーム進行のデータを置いておく必要がある

3.2　オンラインゲーム特有の要素

• 通信レイテンシ ──遅延による、ゲーム内容への制限
  • 通信時間の内訳
  • 避けられない遅延 ──遅延とゲームジャンル
• 帯域 ──通信量のライン
• サーバマシン ──コスト、サーバ台数の目安
• セキュリティ ──オンラインゲームの弱点
  • チート ──最大のセキュリティ上の懸念
  • チートはなぜ行われるのか？
  • チート行為の手段
  • チートの操作対象
  • ノイマン型コンピュータの宿命 ──チート行為に対する防衛サービス
  • 恐るべし... チート行為の波及効果
• 補助的システム（周辺システム）

3.3　物理アーキテクチャ詳解 ──C/S型、P2P型

• 基本のネットワークトポロジ
  • 実際に使われるのはスター（とバス）、フルメッシュ ──通信レイテンシの最小化
• 物理アーキテクチャの種類
• C/S型 ──ピュアサーバ型、リフレクト型
  • リフレクト型
• P2P型
  • NATトラバーサル
• C/S＋P2P混成型
• ad-hocモード
• Column　「ゲームクライアント」とは？

3.4　論理アーキテクチャ詳解 ──MO型

• MO、MMOとは？ ──同時プレイ数の違い
  • MMOとMOのハイブリッド（混成）
• MO型、MOG
• 同期式 ──全員分の情報が揃うまでゲームを進行させない
• 同期式/フルメッシュ型の実装 ──各端末がみんな「マスタデータ」を持っている
  • 各端末（プレイヤー）が送受信する情報の内容
  • 同期式/フルメッシュ型に必要な条件とメリット
  • 同期式/フルメッシュ型と3つの問題点 ──通信網と送受信の完全性の脆さ、ゲームへの途中参加
  • 通信路の信頼性
  • 「最も遅い端末に引っ張られる」問題
• 同期式/スター型 ──いったんサーバに入力情報を集める
  • スター型の抱える4つの問題
  • 同期式全般の大きな問題 ──途中参加ができなくなる
  • 同期式全般のメリットと問題解消のための工夫
• 非同期式 ──各端末におけるゲーム進行の状態の不整合を受け入れる
  • 非同期式における実装方針の立て方 ──ゲーム内容の詳細な分析が不可欠
• 3つの基本要素「自分」「相手」「環境」 ──非同期式実装の検討指針
  • 3つの要素の関係
• (1)自分と相手 ──直接対決ゲームと、プレイヤー間を行き交うデータの抽象度
  • 格闘ゲームの例
  • 攻撃、防御、当たり判定
  • 格闘ゲームのシーケンス図
  • 抽象度の低い、原因がわかるデータを送る必要あり ──結果への納得感
  • 結果の食い違い問題発生！
• 結果の整合性を維持する方法 ──2つの上書き方式
  • ダメージを発生させた側の結果を使う
  • ダメージを受けた側の結果を使う
  • 方式選択の原則 ──プレイヤーの満足感が総じて多くなるように
• (2)自分と環境 ──アイテムを使う格闘ゲームと、排他制御
  • 排他制御が必要なタイプの環境要素 ──競合する資源「爆弾」
  • 排他制御の必要がないタイプの環境要素 ──減らない資源「水」
  • ゲームにおける環境要素は意外と扱いが難しい ──とにかくゲーム内容を詳細に理解する
• 排他制御の実現 ──同期式に似たしくみを使って実現する非同期式実装
  • アイテムデュープ問題
  • アイテムに固有のIDを振る ──デュープが起きたかの判定、発生する問題
  • アイテムデュープ対策 ──調停役のソフトウェアを置く
  • 調停役の基本機能と使い方
  • 爆弾以外の環境要素の場合
• 自動的に状態が変化していくタイプの環境 ──静的な環境と動的な環境
  • 動的な環境で起きる問題 ──完全に並行に管理する方法では難あり
  • 動的な環境で起きる問題への対処の選択肢
• (3)相手と環境の関係

3.5　論理アーキテクチャ詳解 ──MMO型

• MMO型、MMOG ──長期にわたるゲーム進行を、多くのプレイヤーで共有する
  • 永続的とは？ ──ゲームプレイの所要時間と蓄積性
  • 永続的なデータ、溜まる大量データの一貫性保持の難しさ
  • クライアントとサーバの完全分離
• MMOGのしくみ
  • MMO型の実装方針 ──ブラウザ式、純粋なC/Sモデル
  • ブラウザ式と、同期式および非同期式との違い
  • MMO型におけるサーバ、クライアントの機能
  • サーバの処理 ──サーバにおいてゲームは進行し続ける
• MMO型ならではの課題

3.6　まとめ

• Column　ブラウザ式での画面表示ラグを改善する工夫

第4章　［実践］C/S MMOゲーム開発 ──常時稼働するゲームサーバの存在

4.1　オンラインゲーム開発の基本的な流れ

• プロジェクトの資料/成果物
  • 準備と初期の実装は同時並行に行われる
• 開発の進行と資料準備の流れ
• 技術者の資料/成果物

4.2　C/S MMOゲームの傾向と対策

• C/S MMOゲームの特徴
• C/S MMO型（MMO型）ならではのゲーム内容
  • C/S MMO型の制約

4.3　企画資料と5つの設計資料 ──架空のゲーム『K Online』の開発に学ぶ

• サンプルゲームの題材探し
• 企画詳細資料
  • 企画詳細資料の必要性
• MMOGの膨大なゲーム設定
• 5つの設計資料
• 設計上の重要な判断

4.4　[1]システム基本構造図の作成

• システム基本構造図の基本
• スケーラブルなサーバシステムが必要 ──ビジネスモデルの確認
• さまざまなボトルネック ──スケールアップ方式の選択に向けて
• Column　MMOクライアント特有の描画性能ボトルネック ──ゲームクライアントのボトルネック
• ゲームサーバ/DBのボトルネックを解消する
• 何も工夫しない場合（1つのサーバがゲーム世界全体を担当する）
• 空間分割法 ──ゲームサーバのボトルネック解消
  • 空間コピー
• インスタンス法 ──ゲームサーバのボトルネック解消
• パラレルワールド方式 ──DBのボトルネック解消
  • 最もボトルネックになりやすいのは、DBへの書き込み
  • パラレルワールド方式のDB分割
  • パラレルワールド方式で巻き起こる問題
• 複数の手法の併用へ ──さらなるユーザ増加への対処
• 各方式の導入難度
• ワールドごとのDB（ゲームDB）サーバの絶対性能の向上
  • アプリケーションレベルの工夫
• K Onlineでの設計の見積もり ──まずは同時接続数から
  • ボトルネックの確認
  • 設計見積もりにおける考え方の原則
• ゲームロジックの処理コストから見積もる ──敵の行動アルゴリズムにどの程度CPUを使うか
• ゲームDBへの処理負荷から見積もる ──「キャラクターデータの保存頻度」と「DB負荷」の落としどころを見極める
• スケーラビリティの最低限の検討結果、さらなるユーザ体験を求めて…
• サーバの基本構造、1システム基本構造図の作成

4.5　[2]プロセス関係図の作成

• [2]プロセス関係図の準備
• サーバ接続の構成 ──空間分割法のみを用いた場合
• サーバ接続の構成 ──パラレルワールド方式と空間分割法を使う場合
• パラレルワールド方式を使ってスケールさせる場合のポイント

4.6　[3]帯域/マシンリソース計算資料の作成

• プロセスリストを土台に、マシンリソースの見積もり準備
• CPUセントリックなマシン、ストレージセントリックなマシン
• マシンリソースのコスト見積もり ──まずは初期費用から
  • マシンリソースの維持コスト
• 帯域コストの見積もり
  • トラフィックの98％がプレイヤー/NPCの移動通知である
• 帯域半減へ向けた指針 ──まずは企画の調整、次にプログラムの工夫
  • 企画の調整 ──帯域削減作戦1
  • プログラムの工夫 ──帯域削減作戦2
• 帯域削減には、企画内容の見直しが効果的

4.7　[4]プロトコル定義資料の作成 ──プロトコルの基本的な性質

• [4]プロトコル定義資料の基本
• 「プロトコルの基本的な性質」のポイント
• プロトコルの種類と、プロセスの関係の種類
• 8種類のプロトコル
• C/S MMOでは、TCPを用いる
• 「プロトコルの基本的な性質」との対応一覧
  • プロトコル設計の基本戦略

4.8　[4]プロトコル定義資料 ──プロトコルのAPI仕様（概観）

• プロトコル実装の原則
  • バックエンド側に基本/汎用機能を、フロントエンド側に専用機能を実装する
  • バックエンドに対してフロントエンドが依存する構造
  • プロトコルはステートレス＆単純な操作のセットにする
  • 外部から来る例外的な事象は1ヵ所で受ける
  • 優れたAPIの呼び出しシーケンス ──呼び出さないのが優秀！？
• 8種類のプロトコルの機能/形態概要
  • gmsvプロトコル
  • loginsvプロトコル
  • msgsvプロトコル
  • dbsvプロトコル
  • worldsvプロトコル
  • commondbsvプロトコル
  • authsvプロトコル
  • logsvプロトコル

4.9　[4]プロトコル定義資料 ──プロトコルのAPI仕様（詳細）

• プロトコルのAPI仕様（詳細）の作業
• APIの関数定義
  • gmsvプロトコル
  • APIのタイプとメッセージの特性
  • loginsvプロトコル
  • msgsvプロトコル
  • dbsvプロトコル
  • worldsvプロトコル
  • commondbsvプロトコル
  • authsvプロトコル
  • logsvプロトコル
• 定数定義
• APIの呼び出しシーケンス
  • 必要なシーケンス図 ──複数のプロセスが関係する典型的な処理は何？
  • (1)認証
  • (2)gmsvでのキャラクター作成
  • (3)gmsv、msgsvへのログイン
  • (4)gmsvからのログアウト
  • (5)gmsvでのキャラクター移動
  • (6)gmsvでのキャラクターのインベントリ操作（ショップ、トレード）
  • (7)msgsvでのフレンドリストにフレンドを追加、削除
  • (8)オンラインのフレンドにメッセージを送信する
  • シーケンス図作成のポイント

4.10　[4]プロトコル定義資料 ──パケットのフォーマット

• C/S MMOではおもにTCPを用いる（おさらい）
• C/S MMOには、専用のバイト配列を持つバイナリプロトコルを使う
• バイナリプロトコルの実装 ──まずは用語の整理から
  • レコードの大きさ
  • ヘッダ
  • データ部分の圧縮と暗号化
  • 実装上のコツ
• Column　C/S MMOの圧縮と暗号化

4.11　[5]DB設計図

• 重要なテーブルの設計は、プログラミングを始める前に
• C/S MMOにおけるDB実装の歴史的変遷
• 70年代～80年代：データの永続化なし、復活の呪文
• 90年代：ファイルで格納
• 2000年代前半～：RDBMS
• K Onlineに必要なテーブルの洗い出し
• Column　百花繚乱のKVS
• C/S MMOにおける将来のDB利用像
  • 永続化が必要な情報と、データの包含関係
  • データの特性と、個別テーブルの準備
• DBの性能予測
  • DBの処理性能と見積もり
  • テーブルの特性、注意すべきテーブル
  • 発行するクエリの中身 ──read編
  • 発行するクエリの中身 ──write編

4.12　サーバ/クライアントソフトウェア＋ミドルウェア ──実践に欠かせない開発基盤

• オンラインゲームのミドルウェア
  • C/S MMO用のミドルウェア
  • フル装備型ミドルウェア
  • 小規模型MMOGミドルウェア
  • 通信ミドルウェアだけ
• 開発基盤ソフトウェア ──すぐに試せるC/S MMO開発体験
  • サーバ関連ソフトウェア
  • クライアント関連ソフトウェア

4.13　プログラム作成における基本原則

• プログラミングの始め方、続け方
• データ構造優先の原則 ──基本原則[1]
  • ビデオゲームにおけるデータ分類
• データ構造実装前の検討 ──画面に登場する/しない要素
  • 敵キャラクターとポップ設定
• プレイ可能状態維持の原則 ──基本原則[2]
• バックエンド後回しの原則 ──基本原則[3]
• 継続的測定の原則 ──基本原則[4]
  • クライアント開発における継続的測定の例
  • サーバ開発における継続的測定

4.14　C/S MMOゲーム『K Online』の実装 ──プログラミング作業スタート！

• 開発の段取り
• K Onilneにおける分担の計画
• K Onlineにおける「スケルトン」と「プロトタイプ」の段階分け
• ［ステップ1～2］スケルトン～プロトタイプの段階
  • スケルトンコードの準備
  • [1]autocli
  • [2]cli
• Column　ステップ別、お勧め進捗管理形態
  • [3]プロトコル
  • [4]ID
  • [5]gmsv
  • [6]dbsv
• 「動かしてみなければわからない！」 ──ゲーム開発の特殊性
  • 典型的なつまづき ──企業におけるオンラインゲーム開発
• Column　C/C++以外の言語について
• スケルトンの全体像
  • cliの中
  • gmsb、dbsv、protoの中
• Column　VCEとは
• どういう順番で何を書くか
• まずプロトコル定義ファイルk.xmlを書く ──開発の流れ[1]
• プロトコル定義のポイント
• 通信疎通確認：ping関数
• アカウント登録＆アカウント認証：signup関数、authentication関数
• キャラクター作成：createCharacter関数
• ログイン：login関数
• 地上移動：move関数、moveNotify
  • マス単位
  • 経路探索と実際の移動処理
  • 移動経路の送り方 ──最終結果を優先して送信する
  • 移動結果の通知範囲
  • moveNotify関数
  • attack関数、attackNotify関数
• gmsv/Makefileを書く ──開発の流れ[2]
• gmsv/climain.cppとgmsvmain.cppをサンプルからコピー ──開発の流れ[3]
  • sv.cppにsignup関数を実装
• Column　dbsvのサーバコードの自動生成 ──バックエンドサーバ実装の省力化
  • 「dbsv1回往復」型の要求とスレッド
• 自動テストクライアントautocliの実装 ──開発の流れ[4]
  • テストの状態遷移
  • autocliのmain( )関数
  • signup( )関数
• Column　gmsvにおけるスレッドなどの利用について
• グラフィカルクライアントcliの作成と動作確認 ──開発の流れ[5]
  • SDL
  • 絵を描く
  • 動作確認
  • フォント表示の実装
  • 敵を出す、敵を追いかける
  • 敵を倒す、経験値が入る
  • 続きからプレイできるようにする ──プレイ状態の保存
• スケルトン以降の開発 ──開発の流れ、その後…

4.15　まとめ

第5章　［実践］P2P MOゲーム開発──専用サーバなしでアクションゲームを実装する

5.1　P2P MOゲームの傾向と対策

• P2P MOとアクションゲーム ──ゲームの状態が高頻度で変化する
• RPC型実装と共有メモリ型実装
• P2P MOゲームの特徴 ──C/S MMOとの比較、難しい点
• P2P MOゲームの利点
• 企画当初から「マルチプレイ」を意識する

5.2　架空のゲーム『J Multiplayer』の開発に学ぶ ──『K Online』との違い

• J Multiplayer ──K Onlineとの対比
• P2P MOゲーム開発の基本的な流れ
• P2P MOゲーム開発の成果物 ──開発の段階付け、各種資料
  • 企画詳細資料
• C/S MMOとのデータ量/規模の違い

5.3　P2P MOゲームの設計資料

• システム基本構造図
• プロセス関係図
  • スター型か、フルメッシュ型か
  • まずはスター型を検討する
  • ゲームへの途中参加の実装
• 帯域/マシンリソース計算資料
• プロトコル定義資料、APIの仕様
  • プロトコルのシーケンス図
  • 関数や定数の定義
• Column　「ゲームロジック」とは？
• 帯域消費量の見積もり
  • 「600分の1」実現への道 ──ゲームの企画内容を精査して解決策を探す
• その他の資料

5.4　サーバ/クライアントソフトウェア＋ミドルウェア、基本原則

• P2P MO開発における成果物の実際の姿
• P2P MO用のミドルウェア
• プログラム作成における基本原則 ──P2P MOの場合

5.5　P2P MOゲーム『J Multiplayer』の実装 ──プログラミング作業スタート！

• J Multiplayerにおける分担の計画
• 実装作業の流れ ──K Onlineのおさらい
• J Multiplayerの開発の段取り ──どのような順番で何を書いたか
• 第1段階に必要な要素
• クライアントプログラムの実装例
• 「共有メモリ型」での実装 ──実装開始
  • 競合状態 ──共有メモリ型での注意点
  • ロック
  • P2P MOと競合状態
• P2P MO実装における競合をどのように防ぐかの判断
  • 同期周りの実装例
  • 可動物の列挙とクラス設計
  • 基本動作の扱いをマトリクス化
  • ゲーム進行の状態を修正する操作の仕様化
  • PlayerCharacterの処理の仕様化
  • Enemyの処理の仕様化 ──Enemy/Create
  • Bulletの処理の仕様化
• 共有メモリをどうコード化するか ──共有メモリ型とRPC型の比較
  • RPC型 ──C/S MMOの場合
  • 共有メモリ型 ──P2P MOの場合
  • RPC型のコーディング量 ──move(5,5)
  • 共有メモリ型のコーディング量 ──move(5,5)
  • 共有メモリ型の強み、弱み
  • ［補足］コードをすっきりさせられるか？
• SyncValueクラス
• Column　データセンターの地理的分散について

5.6　C/S MOゲームを支える技術［補足］

• C/S MOとNAT問題
• NAT、NAT問題とは？
• NATトラバーサル ──NATを越えて通信路を確立する技術
  • NATトラバーサル技術の限界
  • NATトラバーサルの技術を使う場合のさらなるデメリット
• NATの問題への現実的な対処
• リレーサーバ
• リレーサーバのトレードオフ
  • (1)遅延が大きくなる問題
  • (2)サーバの帯域にコストがかかる問題

5.7　まとめ

第6章　オンラインゲームの補助的システム ──サービス強化に欠かせないしくみ

6.1　補助的システムに求められる各種機能

• 既存のサービスに見る補助的システムの機能
  • 汎用
  • ゲーム機用
  • Webブラウザベースゲーム向け
  • 既存ミドルウェア
• 既存サービスの機能一覧
• Webベースの開発手法とC/S型の開発手法

6.2　コミュニケーション/通信の補助的システム

• プレイヤーマッチング［P2P MO］
  • P2P MOゲームでマルチプレイを可能にする条件
  • マッチングサーバ
  • マルチプレイを実現する2つの条件の具現化 ──J Multiplayerの場合
  • マルチプレイを実現する2つの条件の実現 ──J Multiplayerの場合
  • マッチング結果画面
• ロビー［P2P MO］
  • ロビーとマッチング
  • StarCraft IIの例
  • 実装のポイント
• リレーサーバ［P2P MO］
  • リレーサーバに求められる性能
• チャット［P2P MO］［C/S MMO］
  • 自作チャットの実装
  • 自作チャットの基本動作
  • メッセージ同報の規模
• メール［P2P MO］［C/S MMO］
• フレンドリスト［P2P MO］［C/S MMO］
• プレゼンス［P2P MO］［C/S MMO］
  • ゲームサービスのプレゼンスの特徴
  • プレゼンスの実装
• ロックサーバ［P2P MO］［C/S MMO］
  • ロックサーバの実装
• ブラックリスト［P2P MO］［C/S MMO］
  • ブラックリストの実装
• ボイスチャット［P2P MO］［C/S MMO］

6.3　ゲームクライアント実装の補助的システム

• プレイ実績管理［P2P MO］［C/S MMO］
  • プレイ実績管理の実装について
• ストレージ機能［P2P MO］
• （ゲームクライアント）アップデート［P2P MO］［C/S MMO］
  • アップデートの基本機能
  • アップデートとアクセスパターン
  • アップデート機能自作の工夫
• ランキング［P2P MO］［C/S MMO］
  • ランキング機能の実装 ──オンラインゲーム特有の要求
• 暫定ランキング法

6.4　運営の補助的システム

• ニュース配信［P2P MO］［C/S MMO］
  • ニュース配信のしくみ

6.5　課金決済関連の補助的システム

• 課金認証［P2P MO］［C/S MMO］
  • オンラインゲームの課金
  • 決済のしくみ
  • 決済のシーケンス
  • 決済会社を使うメリット
• バーチャルポイント管理［P2P MO］［C/S MMO］
• P2P MOの場合、C/S MMOの場合

Column　C/S MMOゲームの収入

6.6　その他の補助機能

• ゲームデータ閲覧/検索ツール［P2P MO］［C/S MMO］
  • プレイデータの保存状態
  • きれい、ではない保存状態について
  • 機械にも人間にも、読める形式にしておく
  • キーワード検索のための工夫
  • ゲームの設定データとDB
• ワードフィルタ［P2P MO］［C/S MMO］

6.7　まとめ

第7章　オンラインゲーム運営を支えるインフラ ──構築、負荷テスト、運営開始

7.1　インフラ構築の基礎知識

• C/S MMOとP2P MOのインフラ（おさらい）
• インフラ構築に必要な作業 ──開発全体から俯瞰する
• インフラにかかるコストと見積もり
• コストの感覚、単位
• オンラインゲームサーバである程度許容される条件
• ハードウェア、情報機器
  • サーバマシン
  • ストレージ
  • ネットワークスイッチ
  • ルータ/ファイアウォール
• ソフトウェア
  • サーバOS
  • DBMS
  • ウイルススキャンソフト
  • 仮想化ソフト
• データセンター関連
  • データセンター利用料
  • データセンター構築料
• サービス（データセンター関連を除く）
  • サーバ監視サービス
  • ドメイン使用料、電子署名サービス料
• 回線利用料
• 電気代

7.2　開発者のためのインフラ構築ノウハウ

• サービススケールの拡大/縮小 ──ユーザ数とインフラの必要量
• 典型的な環境
  • 見積もりが難しくなる条件
• 負荷の曲線
  • 最初にピークが来る前提で設計する
  • K Onlineの場合
  • J Multiplayerの場合
• 開発者のためのインフラ構築のポイント
• サーバデプロイメント
  • メンテナンス時間と、デプロイメントの自動化
• ステージング
  • オンラインゲーム特有の注意点
• サーバのモニタリング、生死監視
• ログ出力/管理
  • ログを残すポリシー ──「できるだけ全部」かつ「原因と結果の両方」
  • ログ出力の方法 ──お勧めの組み合わせ、syslogの問題
  • ログサーバ

7.3　K Online、J Multiplayerのインフラ構築

• K Onlineのインフラ
  • アルファテスト
  • クローズドベータテスト
  • オープンベータテスト
• J Multiplayerのインフラ
  • 一部の補助的システムを自作する
  • まず負荷検証を行い、インフラを見積もる
  • 同時プレイ数、登録ユーザ数 ──ランキングを例にした典型的な負荷検証手順[1]
  • プレイスタイルを予測する ──ランキングを例にした典型的な負荷検証手順[2]
  • 負荷検証の結果を設計に反映させる

7.4　負荷テスト

• 負荷テストの準備
• K Onlineでの本番環境負荷テスト
  • K Onlineのテストシナリオ
  • テストの分割
  • 負荷テストに必要な環境
• 負荷テストで使用するサーバ監視コマンド
  • vmstat、/proc/interrupts
  • ps
  • top
  • netstat
• J Multiplayerでの本番環境負荷テスト
  • J Multiplayerのテストシナリオ
  • 負荷テストに必要な環境

7.5　運用開始

• 運用開始直前 ──セキュリティ設定の確認から
  • システムの外部からの攻撃に対するセキュリティ
  • システム内部の管理手段に関するセキュリティ
• 運用開始直後 ──システム監視
• 数十台のサーバをグループ化
• トラブル発生時の対応

7.6　まとめ

第8章　オンラインゲームの開発体制 ──チーム運営上の課題

8.1　ゲームの企画内容と開発チーム ──オンラインゲーム特有の課題

• 「ゲームの企画内容」がチーム運営の鍵を握る
• ゲームデータの永続化度合い
  • 運営開始後の3ヵ月が最もハード、運営は5～10年続く
  • ゲームの運営と技術者
  • 実際のプロジェクト管理における課題
• ゲームにおけるプレイヤー同士の関係
• プレイ結果の共有範囲
• チャットシステムの内容
• メンテナンスとアップデートのスケジュール
• ソースコードの規模 ──イテレーションを廻す部分が多いかが問題になる
  • ビルド時間
  • プログラムの起動時間
  • 評価のステップ数
  • サーバプログラムの起動手順
  • データのバリデーション

8.2　オンラインゲーム開発チームの実際 ──一般のソフトウェア開発にも共通するトピック

• 作業分担
• オンラインゲームプログラマの継続的スキルアップ法
  • 武芸におけるステップアップの教え「守・破・離」に学ぶ
  • 「守」の段階 ──物真似から始めるべし
  • 「破」の段階 ──セミナー、カンファレンス、そして境界領域へ飛び込むべし
  • 「離」の段階 ──エンジニアのステップアップ、その先にあるものは…
• プロジェクト管理術 ──ゲーム開発とスクラム
• 開発環境の選定
• プロジェクト移管 ──当たり前のことをきっちり詰めておく
  • テストの準備
  • 開発環境の構築時間は短く
  • 情報セキュリティの匙加減

8.3　まとめ

• Column　オンラインゲーム開発のコスト感覚