目次
- 本書について
- 本書の構成
- サンプルゲーム＆プレイ動画
- 本書の補足情報コーナーのご案内
- 謝辞
- 基本用語の整理
第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の場合
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 オンラインゲーム開発のコスト感覚