• • 本書について
  • 本書の構成
  • 本書の読者対象および想定する前提知識
  • 動作確認環境について

第0章　［ゲーム開発者のための］レンダリング再入門――「ゲームプログラムはほとんど描画ばかりを行っている」

• 0.1　ゲームプログラムは画面をどのように描画しているか
  • 1秒間に60回，画面を書き換える――リアルタイムかつ高速に実行し続ける
    • ピクセル数の増加
  • GPUによる描画
  • ネットワーク（通信）を駆使するクラウドゲーム
    • リモートレンダリングとローカルレンダリング
    • サーバーサイドレンダリングとクライアントサイドレンダリング
    • クラウドゲームと各種レンダリング手法
  • クラウドゲームとネットワークの宿命――レスポンスと通信遅延，帯域幅，費用
• 0.2　レンダリングとは何か
  • レンダリングの基本の流れ――最小限の2Dレンダラー
    • 塗りつぶしとフィルレート
    • PNGファイルへの出力――libpng
  • 2Dスプライトゲーム向けのレンダラーへの拡張
  • 最小限の3Dレンダラー
    • 座標変換――透視投影変換
    • 塗りつぶし――フィルレートがポイント
  • 一連の描画処理と出力――最小限の3Dレンダラーと本格的なレンダラー
• 0.3　リアルタイムレンダリング
  • リアルタイムレンダリングと性能――ポリゴン描画性能とフィルレート
  • 2Dゲームのポリゴン描画性能とフィルレート
• 0.4　CPUとGPU
  • CPUとGPUのおもな違い
    • 並列計算
    • 並列化できない計算などの注意
    • CGの計算と並列化しやすいアルゴリズムの研究
• 0.5　グラフィックスライブラリ――OpenGL
  • OpenGL，基礎の基礎
    • 各種環境とグラフィックスライブラリ
• 0.6　補足：映像のエンコーディング
  • フレームバッファと圧縮
  • 差分とフレーム間予測
• [column]クラウドゲームを取り巻く，これまでの状況――「クラウドゲーム」登場からの現在までの，長い年月
• 0.7　本章のまとめ

第1章　クラウドゲームとは何か――マルチプレイゲーム開発が変わる可能性が見えてきた（!?）

• 1.1　クラウドゲームとクラウドの基礎知識――クラウドゲームの定義，クラウドの実体
  • クラウドゲームの定義
  • クラウドコンピューティング，基礎の基礎
    • クラウドの実体
    • 典型的なクラウドとオンラインサービス
  • 計算機資源の利用効率と新たなサービス――リモートデスクトップと3D CADの例
    • 大量のマシンを1ヵ所に集めると，変わること――利用効率や高速化と，ソフトウェア自体の設計見直し
  • クラウドゲームの事業化とゲーム産業のビジネスモデル
• 1.2　クラウドゲームでゲームの「何」が変わるか――クラウドゲームの技術的な特徴，ゲームの内容によらない変化
  • クラウドゲームの3つの技術的な特徴
  • 技術的な特徴から生まれる多くのメリット――ユーザー視点，開発者視点
  • クラウドゲームのおもな課題と解決の兆し――インフラ費用，通信の遅延
• 1.3　マルチプレイゲームで起きる“大”変化――マルチプレイゲームが簡単に実装できる
  • マルチプレイゲームを，オフラインゲームと同じ方法で実装できる（!?）
  • ファミリーコンピュータ時代から学びたい。みんなで楽しむマルチプレイゲームのルーツ
    • 『バルーンファイト』の協力プレイ
    • マルチプレイゲームの基本形
    • 『マリオカート８デラックス』の異なる視点のマルチプレイ
    • オフラインマルチプレイ――ゲームプログラムの基本構造は同じ
  • クラウドゲームは，コントローラーのケーブルを地球の裏側まで伸ばしてくれる
• 1.4　オンラインマルチプレイとクラウドマルチプレイの対比――ゲーム実装時，ネットワークプログラミングは不要になる
  • オンラインマルチプレイの二大実装方法のおさらい
  • クラウドマルチプレイとP2P MOゲームとの比較
  • クラウドマルチプレイとC/S MMOゲームとの比較
  • クラウドマルチプレイは富豪的な解決策（!?）
    • ゲームエンジンのマルチプレイ機能も，根本的な解決にはならない
    • スプライトストリーム――中ぐらいに富豪的な方法
• [column]vGPU機能――リモートデスクトップ用のシステム
  • クラウドマルチプレイの特徴
• 1.5　クラウドマルチプレイ最大の課題「インフラ費用」――クライアントレンダリング方式の導入
  • インフラ費用の内訳
• [column]現行のクラウドゲームの料金体系
  • マシンを保持する費用――インフラ費用❶
    • ビデオストリームとGPUの費用――GPUを用いる現在のクラウドゲームサービス
  • 通信費用（インターネットに対する送信）――インフラ費用❷
  • ビデオストリームとサーバーサイドレンダリング――従来からのクラウドゲームサービス
  • 「クライアントサイドレンダリング」という発想――数十〜数百人規模のマルチプレイゲームの実現
    • 2Dゲーム向けのゲームライブラリの開発――既存のエンジンでは未実現
• 1.6　クライアントサイドレンダリングの基礎――ゲームの入力/処理/描画の分離
  • オフラインゲームのプログラムの基本構造――古典からクラウドマルチプレイまで
  • 現代的なゲームプログラムの処理段階
  • クラウドマルチプレイは，入力がリモート
  • クライアントレンダリングで，描画する位置もリモート――現代的なゲームプログラムの設計を活かして，サーバーとクライアントが連携して描画する
    • 図解でわかるクライアントサイドレンダリングのプログラムの構造
  • クライアントサイドレンダリングは，C/S MMOより多くの帯域とCPUを消費する
  • ゲーム内容に特化した抽象化――送信データの抽象度を高める
• [column]クライアントレンダリングの2つの方式
• [column]描画バッチ送信方式，スプライトストリーム（スプライト情報送信方式）
  • サーバーから送信するデータの内容と処理負荷――クライアントサイドレンダリングと，ゲーム内容に特化した抽象化の比較
    • ビームの破片が飛び散るエフェクトの例
  • スプライトストリームの概略――クライアントサイドレンダリングで用いる抽象度の高い通信のプロトコル
    • スプライトストリームで削減できるマシンを保持する費用と通信費用――サンプルゲームを用いた測定結果について
  • クラウドでMMOG――クラウドマッシブマルチプレイゲーム
• 1.7　本章のまとめ

第2章　クラウドゲームのアーキテクチャ――実現したいゲーム×技術の適性を見定める

• 2.1　物理的接続構造――1：1/1：N/N：N/M：N
  • 物理的接続構造の分類――シングルプレイ用とマルチプレイ用
    • ゲームサーバーのプロセスとプレイヤーの対応関係
  • 1：1で見る物理的接続構造の基本――入力から出力までの流れ
  • 物理的接続構造とゲームプレイ空間――図の簡略化から
  • 1：1――技術的導入コストは低い，サーバーコストは高くなる
  • 1：N――GPUから見ると1つの画面を描画しているが，実際にはプレイヤーは複数存在する
  • N：N――マルチプレイでゲームプレイ空間を共有する場合，ゲームプレイ空間の同期が必要
  • M：N――システム構造は複雑になるが，コスト面でメリットもある
  • サーバーマシンのCPUとメモリーの節約――1：NとM：Nのみ
    • ゲームサーバーのCPU消費量の比較――1：Nのアドバンテージ❶
    • ゲームサーバーのメモリー消費量の比較――1：Nのアドバンテージ❷
• 2.2　画面描画の実装方法――サーバーサイドレンダリングとクライアントレンダリング
  • 2種類の画面描画タイプ
  • 図解でわかるサーバーサイドレンダリングとクライアントサイドレンダリング――GPUの位置に注目
    • サーバーサイドレンダリング
    • クライアントサイドレンダリング
  • サーバーサイドレンダリングとクライアントサイドレンダリングの歴史
  • サーバーサイド/クライアントサイドレンダリングの使い分け――ゲーム内容とさまざまな制約
    • サーバーサイドレンダリングを使う最大の目的――高度なグラフィックスを求める
  • 消費電力の大きさとサーバーサイドレンダリング――必要な計算処理の量を消費電力で大まかに比較する
    • ソフトウェアレンダリング――サーバーサイドレンダリングの特殊なオプション
  • クライアントレンダリングの苦手分野――クラウドゲームの制約とゲームデザイン
  • サーバーサイドレンダリングとクライアントサイドレンダリングの使い分け
• 2.3　ネットワークプログラミングなしでMMOGをつくれるか――「1：N」と「クライアントサイドレンダリング」が持つ可能性
  • 「1：N」では1つのプロセスが1つのゲームプレイ空間を保持――プロセス間通信が不要
  • プロセス間通信のおさらい――複数のプロセスで1つのゲームプレイ空間を保持
    • プロセス間通信の要不要――N：Nと1：N
  • ネットワークプログラミング，非同期プログラミングの難しさ――ソケットを用いる場合のゲームサーバーに必要な機能
  • 「1：N」では，ネットワークプログラミングなしでマルチプレイゲームの実現が可能である――第1段階の結論
  • さらに，MMOGの実現に向けた，「クライアントサイドレンダリング」の潜在能力――第2段階の結論
  • 「ネットワークプログラミングなしでMMOGはつくれそう」である――現時点で導かれた結論
• 2.4　クラウドゲームに向いているゲーム，向いていないゲーム――遅延と経済性
  • クラウドゲームへの向き不向き――3つの観点で考える
  • ❶ ゲームが許容できる遅延の大きさ――原因，インターネットの遅延，ゲーム内容，フレームレート
    • ビデオゲーム全般における遅延の原因
    • クラウドゲーム特有の遅延の原因
  • 最大の原因はインターネットの遅延――pingコマンドで測定しておこう
  • ゲームの内容と，低遅延への要求――「リアルタイムゲーム」「ターンベースゲーム」の大枠から
    • タイミングゲーム――低遅延への要求
    • 入力方式/操作系統による低遅延への要求の違い――継続的入力，ポイント＆クリック
  • フレームレートの範囲を考える――基本とクラウドゲームでの注意点
    • フレームレートの調整時の注意点
    • フレームレートの調整とゲームプレイ――同じゲームでもコンテキスト次第で必要な条件は変わる
  • ❷ サーバー運用者にとっての経済性
  • 各種のインフラ費用――大半を占める通信費用
    • 1同時接続あたりの通信費用
    • GPU＋CPUの費用――通信以外にかかるマシン費用
• [column]ビデオストリームとスプライトストリームの通信帯域消費
  • ❸ エンドユーザーにとっての経済性
• [column]OpenGLと開発環境　moyaiで用いるグラフィックスライブラリ
• 2.5　本章のまとめ

第3章　開発の道具立て――開発環境と2Dクラウドゲームライブラリとしてのmoyai

• 3.1　開発環境の基礎知識――ゲーム開発全般からクラウドゲームまで
  • ゲーム全般の開発環境の概略――「ゲームエンジンを使う」方法から
    • ゲームエンジンを使わない方法
  • クラウドゲームのために必要な開発環境の機能――既存の開発環境の状況
    • サーバーサイドレンダリングと既存の開発環境――独立ソフトウェア方式とゲーム内蔵方式
    • クライアントサイドレンダリングと既存の開発環境
  • クラウドゲーム実装の支援はこれからの伸びしろに期待
• 3.2　moyaiの基本情報――2Dの新しいクラウドゲームライブラリ
  • moyaiとシステム構成
  • moyaiの依存関係――外部モジュール
  • プロトタイプ制作用からクラウドゲーム対応の本格ライブラリへ――moyaiの特徴，機能，実装状況
• 3.3　［速習］各種ストリーム――クラウドゲームのための通信内容
  • データストリームとインプットストリーム
  • スプライトストリームとビデオストリーム――基礎の基礎
  • オーディオイベントストリームとオーディオサンプルストリーム
    • 画面描画と音再生のストリームの組み合わせと，通信帯域
    • オーディオサンプルストリームの活用とCPU消費の注意
  • moyaiはおもにスプライトストリームとオーディオイベントストリームを想定
• 3.4　目指すゲームとライブラリ設計のための緻密な見積もり――MMORTS/MMORPGを例に
  • 最初のコミット――MMORTSの要素を持つMMORPGをつくる
    • Moai SDKを参考に，GLFWとC++で実装開始
  • MMORTS/MMORPGは，結果的にスプライトストリーム方式のクラウドゲーム向き（!?）
    • MMORTS/MMORPGと遅延，通信費用
  • オブジェクト数を中心とした見積もりは重要――ゲーム内容，性能，コスト
    • オブジェクト総数の見積もり
    • ゲームサーバーの1プロセスあたりの，オブジェクト数の上限――総アップデート頻度の上限
  • 実装言語による違い
    • ゲームの処理と処理系の速度――コンテナ，メンバー参照
    • オブジェクトを検索する処理の例――シューティングゲームにおける敵キャラの当たり判定
  • 思考ルーチンの計算負荷
  • 最適な開発環境を探して
  • つくりたいゲームと開発環境の性能――ゲーム内容次第で適材適所
    • もし，毎フレーム動かすわけではないなら
    • シェーダを使って実装できるもの――ただし，GPU内部で完結している場合に限る
    • 今回のゲームには大量のオブジェクトがある――変換のオーバーヘッドとその対応策，しかし――
  • サーバーとクライアントでC++コードを共有したい――さらにクラウドゲームライブラリとして実現したいポイント
    • 開発効率を重視し，「同じAPI」が良い――オブジェクトシステム，タスクシステム，算術API
  • つくりたいゲームのために，ライブラリをつくる――クラウドゲームありきではなかったmoyai
• 3.5　moyaiライブラリの基本アーキテクチャ――レンダリング工程に沿った機能の分割
  • moyaiの2つの利用形態――リモートレンダリング用，完全版
  • レンダリング工程別のレイヤー構成――「スプライトシステム」と「描画機能」
    • ローカルレンダリングとリモートレンダリングに対応するしくみ
    • リモートレンダリング用（サーバー専用ライブラリ）と完全版について
  • moyaiの対応状況と，現時点でできること
• 3.6　本章のまとめ

第4章　OpenGLを用いたローカルレンダリングのしくみ――moyaiの基礎部分。描画APIと内部動作

• 4.1　moyaiと汎用的な論理データ――レンダリング工程の第1段階
  • はじめてのmoyai――min2dでローカルレンダリングの動作確認
  • moyai APIの（汎用的な）論理データの構成――MoyaiClient，Layer，Prop2D
  • Layerの機能
  • CameraとViewportによるカリング
    • Viewportとゲーム空間における座標の関係
    • Cameraの位置
    • カリングの効果
    • Viewportの効果的な使い方
    • 複数のViewportを併用する
    • Cameraを使ってスクロールゲームをつくる
  • LayerとCamera，Viewportの自由自在な組み合わせ
  • スプライトの見た目を決定する論理データ――Texture，TileDeck，インデックス，スケール，位置，色，模様
  • OpenGLのテクスチャ描画機能とスプライトの描画
    • テクスチャとなる画像
    • PNG画像のなかみ
    • RGBAフォーマットとGPU
    • OpenGLにおける画像描画の指示――glGenTextures関数
  • UV座標（テクスチャ座標）――glDrawElements関数，頂点バッファ，インデックスバッファ
    • ポリゴンに色や模様をつける
  • スプライトシート
    • 格子状のスプライトシート
    • 柔軟なスプライトシート
    • moyaiのスプライトシート
    • TileDeckを使わず直接テクスチャを貼る方法
• 4.2　moyai内部のマシンに依存したポリゴンデータ――レンダリング工程の第2段階
  • ポリゴンデータとバッチ化
  • グラフィックスハードウェア構成とレンダリング
    • ローカルレンダリングの流れ
    • データの転送と所要時間
  • バッファオブジェクト――GPUへの転送回数を減らす
    • moyaiにおけるバッファオブジェクト――5種類
    • モバイル端末におけるOpenGL ES――バッファオブジェクトを使わないOpenGLプログラミングが不可能
  • 描画のバッチ化とglDrawElements関数
    • 複数スプライトをバッチ化するための条件――同じテクスチャと同じシェーダを用いている場合に限る
  • ドローコールの回数を減らすための設計――スプライトを「同じテクスチャ」から描画する
• [column]予習＆復習：moyaiのリモートレンダリングの基本構造
• 4.3　本章のまとめ

第5章　スプライトストリームのしくみ――リモートレンダリング方式概論，スプライトストリームの基本設計

• 5.1　クラウドゲームと画面描画――moyaiが対応する画面描画の通信方式
  • クラウドゲームにおける画面描画の通信方式――7つの方式
    • ❶外部機器方式
    • ❷キャプチャーボード方式
    • ❸独立ソフトウェア方式
    • ❹ゲーム内蔵方式
    • ❺OpenGL LAN仮想化方式
    • ❻OpenGLインターネット仮想化方式
    • ❼抽象度の高い通信方式
  • OpenGLインターネット仮想化と抽象度の高い通信（スプライトストリーム）が送信するデータ
• [column]スプライトストリーム以外の抽象度の高い方式についての試案――Processingストリーム
  • moyaiのビデオストリームとスプライトストリーム
• 5.2　スプライトストリームのなかみ――抽象度の高い情報
  • スプライトが持つ情報
    • OpenGL関数の呼び出しと「OpenGL呼び出し用の情報」，moyai内部の「抽象度の高い情報」
  • 2Dゲームに特有の描画パターンと通信帯域への影響
    • 大きな差が生まれる原因は「バッチ化」
• 5.3　スプライトストリームの送信内容――min2dでmoyaiの動作を見てみよう
  • min2dの動作確認とログの見方――スプライトストリームなし
• [column]OpenGLの仮想化を使う別の方法――ただし，原稿執筆時点では未実験
  • min2dでのスプライトストリーム
  • スプライトストリームの3段階の送信内容
    • 描画準備（リソース送信）の様子
    • スナップショット送信の様子
    • 差分送信の様子
  • スプライトストリームが向かない2Dゲーム
  • 3Dゲームにおけるスプライトストリーム
• [column]moyaiのWebブラウザ版Viewer
• 5.4　スプライトストリームのサーバー
  • クライアント構成とレプリケーション
  • レプリケーションの基礎――スプライトストリームの特性を活かす
    • レプリケーションサーバー
  • スプライトストリームの物理的接続構造とレプリケーション
  • レプリケーションサーバーの基本構成
    • レプリケーションツリー
    • レプリケーションのメリットとデメリット
  • レプリケーションの構成パターン
    • スプライトストリームでのゲームサーバーの仕事/処理
    • スプライトストリームでのViewerの仕事/処理
  • サーバーサイド1段レプリケーション
  • サーバーサイド多段レプリケーション
  • クライアントサイドレプリケーション
    • レプリケーションクライアントの4つの条件――リモートからの接続が可能，通信帯域，通信遅延，通信の安定性
    • レプリケーションマッチング
    • クライアントサイドレプリケーションのメリットとデメリット
    • クライアントサイドレプリケーションのセキュリティ――入力/出力，簡単な基準設定，改変の検出
  • サーバー/クライアント混成型レプリケーション――レプリケーションサーバーの柔軟性を活かす
• 5.5　レプリケーション×伝統的なMMOG
• ――スプライトストリームのレプリケーションが応用可能
  • 伝統的なMMOGの基本構成――レプリケーションサーバーなし
  • サーバーサイドレプリケーション×伝統的なMMOG
    • ゲームサーバーからの送信量――レプリケーションサーバーを使うメリットの大小
  • クライアントサイドレプリケーション×伝統的なMMOG
• 5.6　カリングとストリームのチェックサム――クライアントレプリケーションにおけるストリームの改ざんの検出
  • ストリームのチェックサムとカリングによるパケットの欠落
  • パケットのサイズと帯域消費
  • チェックサムを用いた抜き打ちの内容確認――改ざん防止
    • 抜き打ちのチェックサムのメリット――柔軟に調整できる
    • 抜き打ちのチェックサムの限界――パケットが欠損していないかはわからない
• [column]TIMESTAMPパケットとリプレイ機能
• 5.7　本章のまとめ

第6章　スプライトストリームの通信プロトコル――TCPによる送受信，ストリームのなかみ，関数群

• 6.1　スプライトストリームとネットワークレイヤー――レイヤー1〜4，レイヤー5〜7
  • スプライトストリームのクラウドゲームシステムとレイヤー――本章の解説について
  • スプライトストリームを形づくる各層
• 6.2　レイヤー1〜4：スプライトストリームの基礎部分――膨大な数の機材をつなげて，高品質な通信をどのように実現するのか
  • インターネットとは何か――地球全体をつなぐ壮大な技術
  • インターネットの基礎――パケット（データグラム）
    • パケット中継の経路を確認――traceroute/tracert
  • クラウドゲームとパケットロス
    • 電気信号（電波）のノイズによるパケットロス
    • ルーターの混雑によるパケットロス
    • ネットワークの輻輳――ルーターの混雑が悪化
    • ベストエフォート――できるだけがんばる
  • 大人数が一つの通信媒体を共有するための工夫
  • Ethernetフレーム――Ethernetでデータを送る
    • IP断片化とIP再構成
    • データの大きさと送信成功率
  • TCPの基本
    • パケットの再送――TCPの送り方❶
    • 順序保証――TCPの送り方❷
    • 輻輳制御――TCPの送り方❸
    • スロースタート（アルゴリズム）
    • TCPの歴史的発展と最適なアルゴリズムの選択
  • UDPとデータグラムの喪失――UDPならストールは発生しない？
• [column]RUDP
  • ストリーム指向プロトコルであるTCP――ストリーム指向とメッセージ指向
    • データの区切り――ソケットプログラミングとバッファリング
  • TCPストリームへのデータの送信――パケットロスの影響をできるだけ小さくする
  • ネットワークを流れているパケットヘッダーの中身――Ethernet/IP/TCP
    • IPパケット
    • TCPパケット（セグメント）
  • TCPの状態遷移
  • ソケットAPI　――ブロッキング，ノンブロッキング，非同期API，select/epoll
  • libuv――非同期I/Oの実現
• 6.3　レイヤー5〜7：スプライトストリームの送信内容
  • レイヤー1〜7：スプライトストリームのデータ――moyaiのヘッダー
  • レイヤー5：スプライトストリームの接続確立と維持
  • レイヤー6：スプライトストリームのパケット構造
  • パケットの中身
  • バイナリデータ，RPCの関数ID，関数への引数データ
  • レイヤー1〜6：スプライトストリームの内容自体には関わっていない
  • レイヤー7：スプライトストリームが送出されるまで
    • スプライトストリームの実例――バイナリデータを見てみよう
  • スプライトストリームの関数呼び出し――描画準備，スナップショット送信，差分送信
    • TIMESTAMPの受信時刻に関する注意点
  • 「描画準備の送信」「スナップショット送信」「差分送信のループ」
  • （接続完了直後）描画準備の送信――scanSendAllPrerequisites関数
  • （画面全体の）スナップショット送信――scanSendAllProp2DSnapshot関数
  • （スプライトの）差分送信――スプライトの状態の変化分を送信し続ける
  • 差分抽出：すべてのスプライトの変化を検知――どのスプライトの差分を送るのかを決定する段階❶
    • Prop2Dのスナップショットの構造体――PacketProp2DSnapshot構造体
    • PacketProp2DSnapshot構造体を用いた差分抽出
  • 差分スコアリング：差分スコアでソートし，大きく動いたスプライトを優先送信――位置の同期モードと，どのスプライトの差分を送るのかを決定する段階❷
    • 差分スコアリング――位置の同期モード❶
    • 線形補間――位置の同期モード❷
    • 速い物体と壁へのめり込み問題――moyaiのデフォルトが差分スコアリングである理由
  • 可視判定：可視範囲に入っているスプライトだけを送る――どのスプライトの差分を送るのかを決定する段階❸
  • Prop2Dの差分抽出と可視判定――2つの送信モード
  • 補足：カリング処理と今後の課題――どのスプライトの差分を送るかを決定する段階を経て
  • スプライトストリームのデータ圧縮――送信量の削減❶
  • スプライトストリームのバッファリングとヘッダー圧縮――送信量の削減❷
    • ヘッダーとデータの割合
    • moyaiのスプライトストリームでは，NagleアルゴリズムOFF
    • スプライトストリームの送信頻度の変更――--send_wait_msオプション
    • 遅延とフレームレートの問題――replayerツールとTIMESTAMPの値の活用
    • ［実測］ヘッダー消費量
• 6.4　スプライトストリームとレプリケーション
  • レプリケーションサーバーにおけるカリング――送信量を削減するさらなる工夫
    • レプリケーションサーバーの実体
    • カリングの対象
  • レプリケーションサーバーでスケールアウトできる，できない
    • HUDとスプライトストリーム，レプリケーションサーバー
• 6.5　スプライトストリームの関数（抜粋）――描画準備，実際の描画，サウンド/インプットストリーム/レプリケーションサーバー制御
  • スプライトストリーム関数の命名規則
  • 描画準備のための関数群
    • 描画準備の流れ
  • インプットストリームの関数
• 6.6　本章のまとめ

第7章　［クイックスタート］クラウドゲーム――多彩な軸のサンプルゲームから見えてくる要所

• 7.1　moyai_samplesのセットアップ
  • ❶ 手元のMac環境でのビルド
  • ❷ サンプルゲームを実行
  • ❸ macOSマシン上でのスプライトストリームの確認
  • ❹ Linuxでのビルド
  • ❺ Linuxでの動作確認
  • サンプルコードの基本の起動オプション――--ss/--vs
  • min起動後の画面とviewerの状態表示
    • ビデオストリームとスプライトストリームの違い
• 7.2　最小構成の設定を把握する――独自の定義は15行のサンプルプログラム「min」から
  • min.cpp
  • サンプルコードのmain関数――sample_common.h，sample_common.cpp
  • スプライトストリームの送信のための初期化――共通のオプション
• 7.3　性能限界を測定する――ベンチマークプログラム「bench」
  • benchの基本――起動，スプライトの数をどんどん増やして動作確認
  • CPU消費量――CPU時間の使い道の確認（macOSの例）
  • 通信帯域の消費量と帯域節約の検討
    • パケットの内容/サイズと通信量
    • 理論値と実際の通信量，節約の可能性
• 7.4　通信遅延と帯域消費を確認する――弾幕シューティングのサンプル「dm」
  • dmのソースコード概説
  • 通信遅延の確認――弾幕サンプルゲームの実行，遅延の追加
    • 通信のRTT――通信遅延の確認のポイント
    • 遅延を追加して動作を見る――tcコマンドのnetemフィルター
    • 遅延の許容範囲と測定――クラウドゲームとして成り立つか
  • 通信帯域の確認――スプライトストリームの送信頻度
    • 送信頻度の変更オプション
    • ゲーム内容に合わせて送信頻度を調整――等速直線運動と線形補間
    • moyaiのデフォルトの設定――アクションゲームに対応可能な最低限の頻度
    • --linear-sync-score-thresと線形補間
    • 位置更新の基準となる累積の移動距離を調整する――線形補間が使えない自機や敵
    • 最適を目指して，調整作業は続く
• 7.5　極小の「通信量×CPU消費×コード」で見えるスプライトストリームの威力――リバーシのサンプル「rv」
  • rvの基本――操作，起動，帯域消費の確認
    • クラウドゲームとモバイル環境――通信の速度と料金
  • rvのソースコード――100行＆ネッワークプログラミング一切なしで実現できるマルチプレイ
    • グローバル変数定義
    • 初期化関数reverseInitの定義
    • 更新関数
  • 通信量もCPU消費量もソースコード量も極小のrv――ネットワークプログラミングなしでマルチプレイを実現する，スプライトストリームの威力
• 7.6　通信遅延に，シビアな“衝撃波”を繰り出す―― 一対一の対戦格闘サンプル「duel」
  • duelの基本
  • 対戦格闘ゲームで確認する通信の遅延とクラウドゲームの限界
    • 自動操作とプレイ感覚の確認
    • リモートサーバーを使う場合のプレイ感覚とUDP
  • duelのソースコード概説――250行でつくる対戦格闘ゲーム
• 7.7　大人数同時プレイのMMOGへの第一歩――スクロールとDynamic Cameraを操るサンプル「scroll」
  • scrollの特徴――Dynamic CameraとDynamic Viewport
  • scrollの基本
  • scrollのソースコード
    • PCクラスの定義――画面の描画や操作をクライアントごとに保持
    • PCのコンストラクタの前半
    • PCのコンストラクタの後半
  • キーボード/マウスの個別化とDynamic Camera/Dynamic Viewport――scrollのポイント
  • scrollでのキーボード処理
• 7.8　本章のまとめ
• [column]論理データと，ポリゴンデータ/物理データの関係

第8章　［本格実装］クラウドゲーム――ネットワークプログラミングなしで，MMOGの実現へ

• 8.1　k22の開発基礎――「scroll」ベースの全方向シューティングゲーム
  • k22の基本情報――スプライトストリームのクラウドゲームのサンプル
  • k22のビルド
  • クラウドゲームでゼロからつくるMMOG！ k22の開発の流れ――マルチプレイ化が簡単
  • 開発準備：画面に描画される要素をリスト化――ゲーム内容の洗い出し，作業やコードの量の見積もり
    • k22のゲーム内容を形づくる要素のリスト
  • 各段階におけるk22のリビジョン
• 8.2　第1段階：シングルプレイゲームの実装
  • ❶ moyai_samplesからソースコードをコピーする
    • main関数と全体像の準備
    • ゲームの初期化：gameInit関数
    • ゲームのメインループ
  • ❷ ゲームのオブジェクトシステムを実装する
    • moyaiの省力化のしくみ
    • クラスの階層構造――省力化のしくみ❶
    • アップデート関数の鎖構造――省力化のしくみ❷
    • ツールで見る関数呼び出しの連鎖
    • サブモジュールのリビジョン
    • コードで見る関数呼び出しの連鎖
    • アップデート関数の鎖構造のまとめ
  • ❸ 必要なキャラクターの動きと見た目を定義する
    • プレイヤーキャラクターの登場
    • 子Prop2D――キャラクターのパーツの重ね合わせ
  • ❹ キャラクターをキーボードで操作する
    • Padクラスと2つのメリット
    • キーボードから入力をキャラクターの動きに反映させる
    • キーの押し下げ状態をベクトルに変換するPadクラス
    • 障害物や通れない場所の扱い
  • ❺ 背景と地形を表示する
    • チャンキング
  • ❻ ビーム弾を撃つ
  • ❼ 音を鳴らす
  • ❽ 敵を出現させて倒す
  • 第1段階のまとめ――シングルプレイの段階で楽しめる要素をひととおり実装する
• 8.3　第2段階：マルチプレイ化
  • マルチプレイ化の流れ
  • ❶ gameInit関数でRemoteHeadを初期化する部分を追加
  • ❷ コールバック関数を追加
  • ❸ main.cppにaddPC，delPCなどを追加――onConnectCallback，onDisconnectCallback
  • ❹ グローバル変数 g_mouse，g_keyboard などをPCクラスのメンバー変数に変更
    • k22とrvのキーボード/マウスの操作イベントの流れの違い――参加者全員でキーボードとマウスを共有するrv
  • ❺ PCクラスのコンストラクタで，keyboardやmouseなどのメンバー変数を初期化
  • ❻ キーボード操作イベントの処理内容を変更
  • ❼ マウス操作イベントの処理内容を変更――onRemoteMouseButtonCallback，onRemoteMouseCursorCallback
  • ❽ PC::charPoll関数でグローバル変数ではなく，メンバー変数を使うように変更
  • 第2段階のまとめ――桁違いに小さな作業でマルチプレイ化
• 8.4　第3段階：プログラムの性能測定と運用コスト予測
  • k22の運営のためのコストの概観
  • ゲームアプリにおけるインフラ費用予測――同時接続数から考える
  • CPU消費量――k22は何のためにCPUを消費しているか
    • キャラクターを動かす処理と通信のための処理
    • キャラクターを動かす処理とCPU消費量
    • 通信のための処理とCPU消費量
    • CPU消費量の内訳を確認――「プロセスのサンプルを収集」
    • 圧縮機能と，CPU＆通信帯域の消費量
  • 通信帯域の測定
  • k22の簡易的な負荷テスト
    • 負荷テストで見積もるCPU＆通信帯域の消費量
    • 負荷テストと実運用
  • メモリー消費量
  • インフラ費用試算の目安の値――k22のCPU，メモリー，通信帯域の消費量
  • インフラ費用の試算
    • クラウドサービスの利用――コンテナと仮想マシン
  • 仮想マシンの費用――CPUとメモリーの使用料金
• [column]AWSの各種インスタンス
  • 通信帯域の費用
  • コスト試算の結果――k22のサーバーをAWSで運用した場合
  • アクセス量の変動とピーク調整比
    • ピーク調整比を加味した，通信費用とマシン費用の予測
  • 第3段階のまとめ
• 8.5　第4段階：将来に向けた開発を見通す
  • 通信量の削減――最も効果の大きいところから順番に変更せよ
  • サーバーの運用/管理を支援するツールの開発
  • ゲーム内容の追加/修正
  • 第1段階から第4段階までの実装時間
• 8.6　思考実験――非クラウドゲームとして実装していたら，どうなっただろうか
  • ネットワークプログラミングなしと各種のトレードオフ――通信帯域，CPU負荷
  • スプライトストリームのクラウドゲーム×伝統的なMMOG
    • 出現するものごとの比較
  • スプライトストリームと典型的なオンラインマルチプレイの違い
• 8.7　本章のまとめ