目次
はじめに
謝辞
目次
第1章 ドラゴンクエストXとは何か ── ドラゴンクエストかオンラインゲームか
1.1
ドラゴンクエストのオンラインゲーム化
1.2
ドラゴンクエストX＝オンライン版ドラゴンクエスト
- ドラゴンクエストシリーズ
- RPG ── ロールプレイングゲーム
- 『ドラゴンクエストIII そして伝説へ…』が社会現象に
- 誰にでもクリアできるという衝撃
- オンラインゲーム
- MMORPG ── 大規模多人数参加型オンラインRPG
- 日本にMMORPGを広めた『ファイナルファンタジーXI』
- ドラゴンクエストなのかオンラインゲームなのか
- その芯はドラゴンクエスト
- ドラゴンクエストらしいUI
- 「サポート仲間」により1人でも4人プレイ可能に
- 「ストーリーリーダー」によりマイペースでプレイ可能に
- コラム：オンラインゲームと新宿
1.3
ドラゴンクエストXの歴史
- 開発の準備
- プロトタイプとイメージデモ動画の作成
- 基本ルールの決定
- サーバリソース規模の決定
- ゲームエンジンの決定
- 開発
- マイルストーン単位の作業
- リソースデータ，コンテンツの大量生産
- ベータテスト版マスタアップ作業
- ベータテスト
- 正式サービスの準備
- コラム：ベータテスト秘話
- 負荷検証
- 製品版マスタアップ作業
- 正式サービス
- バージョン1『目覚めし五つの種族』
- バージョン2『眠れる勇者と導きの盟友』
- バージョン3『いにしえの竜の伝承』
- バージョン4『5000年の旅路 遥かなる故郷へ』
- 海外版サービス
- コラム：海外版対応の成功と失敗
1.4
まとめ
第2章 開発・運営体制 ── ドラゴンクエストXを支える人々
2.1
さまざまな人に支えられるドラゴンクエストX
2.2
ドラゴンクエストX専属の開発コアチーム
- ゼネラルディレクター ── 堀井雄二さんの存在
- プロデューサー ── 総責任者
- プロジェクトマネージャー ── 予算やスケジュールの管理者
- ディレクター ── ゲーム内容の責任者
- シナリオ ── シナリオドリブン開発の象徴
- コラム：絶対的な責任者がいると風通しが良くなる？
- プランナー ── 細かな設定まで行う各種コンテンツ担当者
- デザイナー ── そのゲームに最適化したデータを作る絵師
- プログラマー ── 仕様調整からコーディングまで行う技術者
- コラム：事件はメールで起きているんじゃない。現場で起きてるんだ！
- Webサービス開発 ── ゲーム連動サービスの実現
2.3
ゲームタイトル横断の開発関連組織
- サウンド ── 専門設備で作る音の数々
- ムービー ── プリレンダリングで作る映像
- 研究開発 ── 将来のための研究と現在のための支援
- 品質管理 ── さまざまな視点でのテストプレイ
2.4
オンラインサービス関連組織
- インフラ ── オンラインサービスを支える基盤
- 顧客管理 ── アカウント認証と課金
- 運営 ── お客さまへ発信する専門部署
- サポート ── お客さまを支援する専門部署
- 宣伝 ── 発売日だけではない継続的な露出
2.5
ユーザーからお客さま，そして冒険者へ
2.6
まとめ
第3章 アーキテクチャ ── クロスプラットフォームMMORPGの基本構成
3.1
ドラゴンクエストXの構成要素は多岐にわたる
3.2
コンピュータの構成要素 ── ゲームを動作させるハードウェア
- CPU ── 命令を実行する装置
- メモリ ── 記憶領域
- ストレージ ── 保存領域
3.3
ゲームの構成要素
- インプット ── プレイヤー操作
- 操作機器の操作
- メニューの選択
- ロジック ── ゲームの挙動
- RPGを構成するロジック
- オンラインゲーム特有のロジック
- アウトプット ── ゲームの表現
- グラフィックス描画
- サウンド再生
3.4
ゲームアーキテクチャ ── 基本構成
- ゲームクライアント ── 見た目上のゲーム本体
- ゲームサーバ ── 真のゲーム本体
- ゲームDB ── 主要な情報の保存場所
- クラウドクライアント ── 操作情報を送信し動画を再生
- クラウドサーバ ── 動作しているのはゲームクライアント
3.5
プログラミング言語 ── CPUに与える命令を記述する言語
- プログラミング言語の基本
- CPUネイティブコードと1対1で対応するアセンブリ言語
- より扱いやすいプログラミング言語
- C++ ── 処理負荷の高い部分の実装
- CPUネイティブコードで動くオブジェクト指向言語
- コラム：プログラマークイズ
- プラットフォームごとに異なるC++ビルド環境
- Lua ── 試行錯誤したい部分の実装
- 実行時に低負荷で，構造的に記述しやすいスクリプト言語
- 仮想マシン上のプログラムとして動作
- プログラマーだけでなくプランナーも担当
- C# ── 開発スタッフ向けGUIツールの実装
- GUIツール開発に適した開発環境
- C++プログラマーが書きやすいプログラミング言語
- C++とC#のツール実装の分担
- そのほかのプログラミング言語 ── 適材適所
- コラム：障害調査に便利なツール
3.6
プロトコル ── 通信方式
- Vce ── オンラインゲーム用プロトコル
- RPC形式 ── プロトコルを意識せずにコーディング可能
- ステートフル ── 状態を保持した継続通信
- 通信内容の保証 ── 順番どおり確実な送受信
- 低遅延 ── レスポンス重視
- コラム：インターネットは不具合だらけ
- 安定した通信環境が必要 ── MMORPGで要求される通信環境の厳しさ
3.7
リソースデータ ── ゲームに必要な各種データ
- グラフィックリソース ── ゲーム画面の絵素材
- ムービーデータ ── ストリーミング動画データ
- サウンドリソース ── BGMとSEのデータ
- テキストデータ ── セリフや名称のデータ
- パラメータデータ ── 多岐にわたる変更が可能なデータ
3.8
まとめ
第4章 開発と検証 ── 並走する追加と保守のサイクル
4.1
ドラゴンクエストXに求められる追加と保守の並走
4.2
開発と検証のサイクル
- 新規コンテンツ追加の流れ
- 仕様概要の作成 ── 実装の開始を可能に
- 新規3DBGの制作開始 ── 最も時間がかかる舞台制作
- 仕様の作成 ── プレイヤー視点の遊び方
- 実装 ── 開発作業の中心
- プレイ会の実施 ── 開発スタッフによるテストプレイ
- 仕様FIX ── 残りの改修項目の洗い出し
- 改修項目の実装 ── ディレクターの要望への対応も
- 検証 ── 品質管理チームによるテストプレイ
- リリースの流れ
- リリース版の完成
- 製品サービス環境へのリリース
- 既存コンテンツ保守の流れ
- 改修仕様FIX ── フィードバックに基づく改修項目の決定
- 改修項目の実装 ── 暫定修正を行う場合も
- 改修の影響範囲の検証 ── 影響範囲に限定したテストプレイ
4.3
追加と保守の並走体制
- 追加と保守は同じチーム
- バージョン番号から見る追加と保守
- 1つ目の数値 ── 追加パッケージのバージョン
- 2つ目の数値 ── 新規コンテンツ追加のメジャーバージョン
- 3つ目の数値 ── 既存コンテンツ保守のマイナーバージョン
- アルファベット ── 既存コンテンツの緊急修正
- 並走バージョン管理
- 追加用のTrunkと保守用のMasterの並走
- コラム：バージョン管理ツールあれこれ
- 普段の開発はTrunkで管理
- リリースはMasterで管理
- 修正ポリシーの違い
- Trunkの修正は根本，Masterの修正は暫定
- Masterの修正はテクニカルディレクターを通す
- 改修ミスの自動検知
- 不審な変更検知メール
- ネタバレワード検知メール
- コラム：メール送信後もフットワークは軽く，粘り強く
4.4
多数並走する検証環境
- 検証環境の切り替え ── DNSを利用
- 社内環境 ── LANに構築された開発用
- 社内個別プログラマー環境 ── 共通システム担当プログラマー用
- 社内プログラマー環境 ── プログラマー用
- 社内先行検証環境 ── 品質管理チームによる更新可否の判断用
- 社内安定環境 ── リソースデータ制作を担当する開発スタッフ用
- 社内Master環境 ── Masterの社内検証用
- 非公開環境 ── WANに構築された本検証用
- 非公開Trunk環境 ── 次メジャーバージョンの検証用
- 非公開Master環境 ── 製品サービス環境の検証用
4.5
まとめ
第5章 メモリ管理 ── MMORPGのボトルネック
5.1
重要度の高いドラゴンクエストXのメモリ管理
5.2
ゲームクライアントのメモリ管理
- メモリの確保と解放 ── メモリフラグメントの傾向と対策
- メモリフラグメント問題 ── メモリの断片化
- コンパクションを伴う間接参照方式 ── 詰めて断片化抑制
- 固定長ブロックを利用した直接参照方式 ── 位置固定で断片化抑制
- グラフィックリソース ── 圧縮状態でインストール
- パラメータデータ ── 3種類の方法で管理
- 常駐パラメータデータ ── メモリ内で圧縮保持し都度伸張
- コラム：メモリ不足でメモリ空く
- 都度読みパラメータデータ ── 必要な場面でメモリに読み込み
- キャッシュ対応パラメータデータ ── ファイルの一部をメモリにキャッシュ
- プログラムオーバーレイ ── プログラムの入れ替え
5.3
ゲームサーバのメモリ管理
- 4Gバイト制限 ── 32ビットアプリケーションの限界
- スワップアウト抑制 ── サーバマシン搭載のメモリ容量が上限
5.4
Luaのメモリ管理
- 場所や機能ごとにファイルを細分化
- ガベージコレクションを意識したコーディング
5.5
まとめ
第6章 ゲームクライアントグラフィックス ── 魅力的な絵を描画する工夫
6.1
クロスプラットフォームのゲームクライアントグラフィックス
6.2
ゲームが動いて見えるしくみ
- フレーム ── ゲーム画面の静止画1枚1枚
- 30～60FPS ── 動いているように見えるフレームレート
6.3
3Dゲームのしくみ
- 透視変換 ── 3Dゲーム空間を2Dゲーム画面へ投影
- ライティング ── 光源の影響の反映
- 影 ── 光が届かない場所の判定
6.4
ゲームエンジン ── ゲーム開発の基本機能の提供
- マルチプラットフォーム対応 ── 各ハードウェアの機能の有効活用
- 各種ツールの提供 ── 整備されたリソースデータ制作環境
- Crystal Tools ── 内製ゲームエンジン
6.5
キャラクター ── 手描きアニメ風の表現と着替えによる多様化
- トゥーンレンダリングによる手描きアニメ風の表現
- 手描き風の色塗り
- 輪郭の描画
- 着替えによる多様化
- 部位の見た目の変更 ── 装備に対応したポリゴンモデルの差し替え
- 部位間の接続 ── 隣接箇所の表示／非表示の切り替え
- カラーリング ── 色の変更
- キャラクターモーションによる多彩な動作
- キャラクターには骨がある
- 関節が外せるキャラクターモーションで多彩な表現
- パート分けと分岐で多様な表現
- 物理骨による動的制御で揺れを表現
- フェイシャルアニメーションによる表情変化
- キャラクター制作の流れ
- キャラクターモデル制作の流れ
- コラム：制作されし十四の種族
- キャラクターモーション制作の流れ
- フェイシャルアニメーション制作の流れ
- コラム：モーションキャプチャ活用で求められる演技力
6.6
3DBG ── 冒険の舞台となる広大な世界
- 高速な非表示範囲の判定が重要
- 近付いてから読み込む室内グラフィックリソース
- 3DBG制作の流れ
6.7
エフェクト ── さまざまな視覚効果
- エフェクトのいろいろ
- エフェクト制作の流れ
6.8
カットシーン ── 物語に添える彩り
- カットシーンとムービーの違い
- 物語は最高のごちそう
- ゲームクライアントで生成されたキャラクターが演技
- カットシーン制作の流れ
6.9
メニュー ── わかりやすさの中心的役割
- 複数の解像度に対応したメニューレイアウト
- メニュー制作の流れ
6.10
まとめ
第7章 ゲームサーバプロセス ── 機能ごとに分離して負荷分散
7.1
ドラゴンクエストXのゲームサーバプロセスはシングルスレッド
7.2
シングルスレッド ── 1プロセス1スレッド
- シングルスレッドのメリット ── 不具合対応しやすい
- シングルスレッドのデメリット ── 開発と負荷分散がしづらい
- 複雑なノンブロッキング形式での開発が必要
- 1プロセス1CPUのため負荷分散しづらい
- シングルスレッドのデメリットを補う
- Luaでブロッキング
- マルチプロセスで負荷分散
7.3
ワールドプロセス ── スケールアウトのためのパラレルワールド
7.4
ゾーンプロセス ── MMORPGの主役
- 世界を多数のゾーンに分割
- ワールドプロセスとゾーンプロセスの連携
- ゾーンプロセスは高負荷
7.5
バトルプロセス ── ゾーンプロセスから分離した戦闘処理
- 戦闘開始 ── ゾーンプロセスからバトルプロセスへ処理を移管
- 戦闘中 ── バトルプロセスで処理しゾーンプロセスへ共有
- コラム：AIは賢くないほうが楽しい？
- 戦闘終了 ── バトルプロセスからゾーンプロセスへ処理を戻す
7.6
ロビープロセス ── ゲームプレイの起点
7.7
ゲームマスタープロセス ── ゲームマスターの指示を中継
7.8
ワールド間の自由移動を支えるプロセスたち
- ワールド間を自由移動できるメリット ── ワールドの垣根を越えて一緒にプレイ可能
- ワールドプロセスのマスタとスレーブ ── 複数のワールドプロセスを接続
- コラム：プレイヤーイベントあれこれ
- パーティプロセス ── ワールドを移動しても分かれないパーティの実現
- メッセージプロセス ── ワールド横断コミュニケーションの担い手
- コラム：2.27の障害対応30時間
7.9
インスタンスゾーン ── 同一場所のパラレル化
- パーティプライベート用インスタンスゾーン ── 自パーティのみの空間
- 専用ワールドのインスタンスゾーン ── 一極集中するコンテンツの舞台を分散
- 番号が割り当てられたインスタンスゾーン ── 丁目やフロアに紐付けて分割
7.10
まとめ
第8章 キャラクター移動 ── 移動干渉による押し合いへの挑戦
8.1
通常移動と移動干渉の両立
8.2
通常移動 ── ゲームクライアント主体の移動処理
- 操作プレイヤーのゲームクライアントで移動
- ゲームサーバで移動
- 他プレイヤーのゲームクライアントで移動
8.3
移動干渉 ── ゲームサーバ主体の移動処理
- 直感的な移動干渉のゲーム性
- 実現への課題
- 移動干渉を実現する挙動
- 移動干渉モードへの遷移
- コラム：操作主体が他ゲームクライアントの「ドルボード」の相乗り
8.4
移動処理の負荷軽減 ── 多人数の影響を軽減する工夫
- 1,000人が動く世界は高負荷/li>
- ゲームクライアントへの情報送信の最適化
- 空間分割 ── 空間を分けて対象を限定
- 表示中キャラクターリスト ── 情報が必要なゲームクライアントに限定
- コラム：既存のしくみを利用して低負荷にできた「すれちがい」
8.5
場所に紐付く処理 ── 指定場所への移動検知で処理実行
- ゾーンの出口から次のゾーンの入口へ移動
- 目的地に到達するとストーリーイベントが進行
8.6
まとめ
第9章 ゲームDB ── ワールド間の自由移動を実現する一元管理
9.1
ボトルネックはプレイヤーキャラクターデータの一元管理
9.2
ゲームDBの内部構成
- Oracle Exadata ── 単体でも高性能なRDBMS
- Kyoto Tycoon ── スケールアウト可能なKVS
- ゲームDB中継プロセス ── プロトコルの差異を吸収
9.3
プレイヤーキャラクターデータの保存
- 同期が不要なところは障害時の巻き戻りを許容
- 宝箱 ── 同期が不要なアイテム取得
- レベルアップ ── 同期が不要なパラメータ変化
- 同期が不要なときの保存はKVSでスケールアウト
- プレイヤーキャラクターデータキャッシュ ── Oracle Exadataへの保存頻度の低減
- 拡張プレイヤーキャラクターデータ ── Oracle Exadataに保存しないという選択
- 同期が必要なところはトランザクション処理
- 「とりひき」 ── プレイヤーキャラクターデータの同期
- 「旅人バザー」 ── 共有データとプレイヤーキャラクターデータの同期
- 「住宅村」 ── ゾーンプロセス固有データとプレイヤーキャラクターデータの同期
9.4
テーブル情報の概説
- アイテム情報テーブル
- ID ── アイテムスロットを識別する番号
- アイテム番号 ── 種別を表す番号
- 所持数 ── 同一アイテムスロットに所持している数
- 所持キャラクター ── 所持者を表す番号
- 保管場所番号 ── ゲーム上で所持する場所の種類
- 更新日時 ── 最後に変更された日時
- 状態 ── アイテムの削除はレコードの削除ではなく状態変更で処理
- 追加効果 ── アイテムに個別に付加する情報
- 所持品ソート情報テーブル
- コラム：情報量を大幅に減らした「家具庭具おきば」
- 旅人バザー関連テーブル
9.5
継続的な改善
- Oracle Exadataのアップグレード
- 投入時に発覚した10万分の2秒という重大な遅延
- アップグレード後も性能が上がらず最適化で成果
- コラム：シンプルなほうが障害に強い
- 機能追加に伴うゲームDBの最適化
- アイテム情報の読み込み最適化
- 「旅人バザー」統合のための工夫
- ゾーンプロセスによる保存頻度の抑制
- コラム：駅のベンチでメンテナンスの真相
- 継続的ボトルネック調査
- コラム：別空間の「アスフェルド学園」はゲームDBでも別空間へ
9.6
まとめ
第10章 ゲーム連動サービス ── ゲーム内とつなげるための工夫と力技
10.1
「目覚めし冒険者の広場」と「冒険者のおでかけ超便利ツール」 ── 2種類のゲーム連動サービス
10.2
ゲーム連動サービスのアーキテクチャ
- 連動サービスクライアント ── ゲーム連動サービスのブラウザとアプリケーション
- 連動サービスサーバ ── ゲーム連動サービスの中心的存在
- 連動サービスDB ── ゲーム連動サービスデータの保存場所
- MySQL ── ゲーム連動サービス専用データの保存
- Cassandra ── ゲーム連動サービス用に計算されたゲーム内データの保存
10.3
ゲームの世界との連携
- 主要ゲーム情報の利用 ── Oracle Exadataとの連携
- プレイヤーキャラクターデータキャッシュの活用 ── Kyoto Tycoonとの連携
- ゲーム外で「職人ギルド依頼」「釣り老師の依頼」「日替わり討伐依頼」 ── ゾーンプロセスとの連携
- ゲーム外で「どこでもチャット」 ── メッセージプロセスとの連携
- チャットの着信をプッシュ通知 ── ノンブロッキング形式での通信で高速化
10.4
ゲームクライアントで撮影した写真の加工と保存
- 写真の処理 ── 加工と保存の独立化
- 画像加工処理の最適化 ── オンプレミスからAWSへ移行
- 写真の管理 ── NFSからオブジェクトストレージへ移行
10.5
Webで展開しているコンテンツ
- 2D，3Dでのプレイヤーキャラクター ── ゲーム連動サービスでもプレイヤーキャラクターを表示
- 「大討伐」 ── Webサイトと連動した運営イベント
- 「コロシアム」のランキング ── ランキング形式のコンテンツ
- 「DQXショップ」 ── ゲーム内のアイテムを現実のお金で購入
10.6
まとめ
第11章 運営と運用 ── リリースしてからが本番！
11.1
攻めの運営，守りの運用 ── お客さま対応に必要な両輪
11.2
製品サービス環境へのリリース ── メンテナンスの実施
- コラム：リリース後のほうが多忙
- メンテナンスの作業内容と日時の確定
- メンテナンスの準備
- メンテナンス作業
- クローズ作業 ── ログイン制限と強制ログアウト
- 停止作業 ── サーバプロセスの停止
- 更新作業 ── バックアップの取得と各種更新
- コラム：NFSの同期タイミングはサーバマシンごと
- 起動作業 ── サーバプロセスの起動
- チェック作業 ── 作業漏れと製品サービス環境特有の問題の確認
- オープン作業 ── ログイン許可
- 部分的なメンテナンスの実施
11.3
お客さまからの不具合報告への対応
- サポートスタッフによる1次対応
- 開発コアチームによる対応
- デイリーレポート ── 日々メールでやりとりされる不具合対応
- 緊急エスカレーション ── 緊急連絡先へ電話呼び出し
- 迅速に対応するためのサーバログ調査の工夫
- 調査を意識したログフォーマット ── 必要な情報を1行に書き出し，情報位置を固定
- Arm Treasure Data eCDPの導入 ── 大量のサーバログを高速に検索できる外部サービスの利用
- コラム：サーバログの追加にご用心
- わかりやすさの追求
- NPCが保管する仕様は親切だがわかりづらいため通知を強化
- ゴールド額の表示不具合を修正したら大問題になりさらに改修
11.4
お客さまからの要望への対応
- 「提案広場」 ── お客さまの意見を受け付け回答も
- コミュニティ調査 ── 飛び交う本音の分析
- コラム：舌を引っ込めた運営スタッフ
11.5
未来へ向けた分析
- サーバ負荷の定量分析
- 施策の効果測定
- 分析に基づくゲーム内容の改修
- 行動調査から，2番目の町へ到達後の進捗が悪いことが発覚
- ゴールドなどの不足を補うコンテンツの追加
- 進めてほしいメインストーリーの惹きを強化
11.6
まとめ
第12章 不正行為との闘い ── いたちごっこ覚悟で継続対応
12.1
不正行為への継続した対応
12.2
RMTとの闘い ── 現実の金品によるゲーム内金品の売買を防ぐ
- RMTの実態 ── 業務でゴールドを稼ぐRMT業者の存在
- 不正プレイRMT業者 ── 1人では不可能な長時間プレイ
- 不正アクセスRMT業者 ── 日本における違法行為
- RMTへの対処 ── 行為検知と，利用抑制の啓蒙活動
- RMT業者の行動パターン変更に追従 ── スペシャルタスクフォースによる対処
- 利用の抑制 ── 利用者の対処と啓蒙活動
12.3
自動操縦との闘い ── 人間に不可能な長時間プレイを防ぐ
- 自動操縦の実態 ── RMT業者と一般プレイヤー
- 自動操縦への対処 ── 複数の手法で検知して対応
- 現地視認 ── ゲームマスターによる手動対処
- サーバログ調査 ── スペシャルタスクフォースによる手動対処
- 行動パターン検出 ── プログラムによる検出と自動対処
- 通報 ── お客さまの協力で行う自動隔離
12.4
不具合の不正利用との闘い ── 不当に利を得る行為を防ぐ
- 不具合の不正利用の実態 ── 残存する不具合と，それを狙うプレイヤー
- 不具合の不正利用への対処 ── 公平性を保つ対応と事前に発見するしくみ
- 困難な対処 ── 意図的かどうかの判断は難しい
- 無限増殖の不具合の検出 ── 事前に発見する工夫
12.5
プレイヤー間トラブルとの闘い ── 人間が集まると生じる問題に対応する
- プレイヤー間トラブルの実態 ── 人間が集まれば問題も
- プレイヤー間トラブルへの対処 ── 報告への対応と発生防止策
- 利用規約違反報告への対応 ── 警察のような役割のゲームマスター
- ゲーム仕様の改修で未然に防止 ── トラブルを起きづらくする工夫
12.6
チートとの闘い ── 改ざんから世界を守る
- チート行為の実態 ── 回数は少なくても大きな影響
- 発覚したチート事例 ── 通常の操作ではあり得ない状況
- カジュアルチーターの攻撃 ── 空いていたセキュリティホール
- チート行為への対処 ── ゲームサーバで防止し，ゲームクライアントで難読化
- チート行為の実施者の対処とその後 ── 残された深い傷跡
- チート防止方法 ── ゲームサーバで防ぐことが基本
- ゲームクライアントとプロトコルの難読化 ── カジュアルチーターも意識した対応