書籍概要

WEB+DB PRESS plus

オンラインゲームを支える技術
―壮大なプレイ空間の舞台裏

著者
発売日
更新日

概要

オンラインゲームをテーマとした技術解説書。

ソフトウェア開発において,オンラインゲーム開発者は卓越した技術力を持つ専門性の高い花形と言われています。そこでは,ゲームのアイデアをソフトウェアという形にするため,企画を熟知した上で,CPUサイクルを極限まで節約しながら続々登場する大量のオブジェクトを動かし,ネットワークで発生するミリ秒のレイテンシを徹底的に切り詰め,無数のコネクションを捌き続けることが求められます。

本書では,オンラインゲーム開発の土台となるゲーム&ネットワークプログラミング両分野の速習からスタートし,知識編として歴史的変遷,さまざまな観点からの要求の分析,システムのアーキテクチャを押さえ,さらに実践編としてサンプルゲームの実装を交えてC/S MMO,P2P MO,サーバ/インフラ,開発体制と,全体的な考え方を一気に追いかけます。

ネットワークを経由して,なぜ,あれほど多くのユーザに向けて高いレスポンスを維持しながらリッチなゲームコンテンツを届けられるのか...。普段からソフトウェア開発に携わっている方々,そして広くゲーム開発に関心のある方へ,商用サービスを視野に入れオンラインゲーム開発の舞台裏を凝縮してお届けします。

なお,紙幅の都合もあり本書ではサンプルゲーム解説で一部疑似コードを使用しているため,参考資料として実際に動く様子を確認できるプレイ動画およびサンプルコードを用意しています。サンプルコードにはソースコードを同梱(ゲームプログラム本体のみ)していますのでソースコードを学習補助資料として使用していただけますが,動作環境はMac OS X v10.6(Snow Leopard)のみとなります。あらかじめご了承ください。プレイ動画,サンプルゲームプログラムについて,詳しくはWebの本書補足情報コーナー(発売日以降,公開)および本書前付けをご参照ください。

こんな方におすすめ

  • 商用のオンラインゲーム開発の舞台裏に興味をお持ちの方
  • オンラインゲームというソフトウェアの作り方に関心のある方
  • ネットワーク,ゲームをはじめ,幅広いプログラミング技術に関する知識を深めたい方

本書の構成

本書の章構成は,以下のとおりです。なお,本書のプログラミングに関する解説(第0章,第4章~第5章)では,C言語やJavaなどの一般的なプログラミング言語に関する基本的な知識を持っていることを前提としています。それ以外の章(第1章~第3章,第6章~第8章)は,プログラマでなくても理解できる内容となっています。

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

本格的なオンラインゲーム開発者と,他の業界の開発者(Webプログラマや業務アプリケーションのプログラマなど)との知識の差分の部分を具体的に紹介します。

第1章 オンラインゲームの歴史と進化 -- ゲームが「ネットワーク」を取り込んだ!
第2章 オンラインゲームとは何か? -- さまざまな角度から見る「オンラインゲーム」
第3章 オンラインゲームのアーキテクチャ -- ゲームのおもしろさ×技術的な制約との戦い

オンラインゲームの歴史や背景,ビジネス,ジャンルごとの違い,アーキテクチャなどの背景となる考え方をまとめました。

第4章 [実践]C/S MMOゲーム開発 -- 常時稼働するゲームサーバの存在
第5章 [実践]P2P MOゲーム開発 -- 専用サーバなしでアクションゲームを実装する

オンラインゲームのほとんどをカバーする2通りの実装手法について,サンプルゲームのコードを見ながら開発の流れを体験できます。

第6章 オンラインゲームの補助的システム -- サービス強化に欠かせないしくみ
第7章 オンラインゲーム運営を支えるインフラ -- 構築,負荷テスト,運営開始
第8章 オンラインゲームの開発体制 -- チーム運営上の課題

オンラインゲームで重要な「運営」を支える,補助的な技術や考え方を紹介しています。

本書の全体構成について

一般的な書籍では,まず議論の対象となるオンラインゲームとは何かを定義し,背景を説明し,課題を認識し,解決方法の概要を説明し,サンプルプログラムを実装しながら具体的に紹介していく……という流れになるのが普通です。本書でも基本的にはそのような流れに沿って説明を進めていますが,オンラインゲームを実装するための「ネットワークプログラミング」と「ゲームプログラミング」について速習のための第0章を敢えて冒頭に配置しました。

速習の第0章では本書全体のベースとなる専門用語をできるだけ網羅していますので,最初にここをざっと見ておくことで実際に必要となる技術の概要を把握することができ,またその後の章でよくわからないことがあっても第0章に戻ることで理解が深まるようになっています。

もし読者自身が第0章で扱っている話題についてほとんど理解しているなら,オンラインゲームプログラマとしてどこの会社でも即戦力になると思って間違いありません。また,ほとんど知らないことばかり……という場合でも心配は無用です。第0章以降ではそれぞれの技術がなぜ必要になるのかをじっくりと説明していますので,往復しながら読み進めてみてください。きっと深い理解につながると思います。

目次

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

第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 オンラインゲーム開発のコスト感覚

    サポート

    正誤表

    本書掲載の記述に誤りがありました。ここに訂正し,深くお詫び申し上げます。

    (2017年10月12日最終更新)

    P.27 ページなかほど「続いて、 ...」で始まる段落内、2行め Web訂正情報掲載

    最後に図0.3❻の
    最後に図0.3

    (以下,2011年4月7日更新)

    以下,第2刷以降修正済み

    P.ⅹ 見出し語「スケーラブル」内の説明文 2行目
    拡張である
    拡張可能である

    P.6 下から6行め、および7行目(2カ所)
    P.7 上から10行目(1カ所)
    図2.A
    0.A

    P.15 リスト0.2 5行目
    whiel
    while

    ダウンロード

    本書サンプルゲームソースコードダウンロードについては,次のダウンロードページをご確認ください。

    GitHubでも公開しています(2012年1月より公開開始)。

    商品一覧