出版社内容情報
プロ必見！ 成功するゲーム制作術のすべて
さまざまな制作現場、有名クリエーターのコメント、成功例と失敗例の数々を、著者の膨大な知識と深い考察とによって体系化して導き出した、成功するゲーム制作のための理論と法則！
■総合目次
Part 1 ゲームデザイン
第1章 コンセプト
第2章 基本デザイン
第3章 ゲームプレイ
第4章 詳細なデザイン
第5章 ゲームバランス
第6章 ルック&フィール
第7章 ゲームデザインのまとめ
第8章 ゲームデザインの未来
Part 2 チームの構成と管理
第9章 チーム管理の手法
第10章 役割と部門
第11章 ソフトウェア工場
第12章 スケジュール管理
第13章 評価と工程
第14章 トラブルへの対処
第15章 ゲーム業界の未来
Part 3 ゲームアーキテクチャ
第16章 開発の手法
第17章 基本設計
第18章 技術面の考察
第19章 オブジェクト指向のすすめ
第20章 アーキテクチャの設計
第21章 開発
第22章 リリースへの準備
第23章 プロジェクトをふりかえって
第24章 ゲーム開発の未来
Part 4 企画と設計のサンプル
第25章 サンプルゲーム「Balls!」
第26章 構想と設計のサンプル
付録A 参考資料
付録B 用語集
■目次
監訳者まえがき ―――― iii
著者/監訳者紹介 ―――― iv
はじめに ―――― v
Part 1 ゲームデザイン ―――― 1
第1章 コンセプト ―――― 3
1.1 新しさの衝撃 ―――― 3
1.2 アイデアの創出 ―――― 4
1.2.1 インスピレーション ―――― 5
1.2.2 統合 ―――― 6
1.2.3 共鳴 ―――― 7
1.2.4 収束 ―――― 8
1.3 アイデアの具体化 ―――― 8
1.3.1 ドラマ的な効果 ―――― 8
1.4 構想 ―――― 11
1.5 批評 ―――― 12
1.5.1 分析 ―――― 12
1.5.2 評価 ―――― 13
1.5.3 正当化 ―――― 13
1.6 実習 ―――― 14
1.7 実現可能性 ―――― 18
1.7.1 商業的な要因 ―――― 18
1.7.2 技術上の要因 ―――― 19
1.7.3 開発上の要因 ―――― 19
第2章 基本デザイン ―――― 21
2.1 ゲームとは何か ―――― 21
2.1.1 クールな機能 ―――― 22
2.1.2 凝ったグラフィックス ―――― 22
2.1.3 パズル ―――― 22
2.1.4 設定とストーリー ―――― 23
2.2 ゲームがすべてではない ―――― 24
2.3 ゲームとはゲームプレイ25
2.4 ゲーム仕様の作成 ―――― 27
2.4.1 機能 ―――― 27
2.4.2 ゲームプレイ ―――― 29
2.4.3 インターフェイス ―――― 30
2.4.4 ルール ―――― 31
2.4.5 レベルデザイン ―――― 32
2.5 ゲーム仕様の例 ―――― 34
2.5.1 プロトタイプの価値 ―――― 38
2.5.2 ドキュメントの必要性 ―――― 39
第3章 ゲームプレイ ―――― 41
3.1 ゲームプレイとは何か ―――― 42
3.2 ゲームプレイの実装 ―――― 42
3.2.1 絶対優位戦略の問題点 ―――― 43
3.2.2 準優位 ―――― 43
3.2.3 つまらない選択の回避 ―――― 44
3.2.4 おもしろい選択の実現 ―――― 48
3.2.5 おもしろい選択のツールボックス ―――― 49
3.2.6 ゲームプレイに関する最後の言葉 ―――― 57
3.3 インタラクティビティ ―――― 57
3.3.1 インタラクティビティの種類 ―――― 57
第4章 詳細なデザイン ―――― 63
4.1 デザイナーの役割 ―――― 63
4.2 デザインドキュメント ―――― 67
4.2.1 ゲームプレイの仕様書 ―――― 68
4.2.2 デザイナーの覚書 ―――― 68
4.3 デザインドキュメントの使用 ―――― 70
4.4 デザインと開発の合致 ―――― 72
4.5 段階とたたき台 ―――― 72
4.6 ドキュメントを使う究極的な理由 ―――― 75
第5章 ゲームバランス ―――― 77
5.1 プレイヤーとプレイヤーのバランス ―――― 78
5.1.1 均衡 ―――― 79
5.2 プレイヤーとゲームプレイのバランス ―――― 81
5.2.1 プレイヤーへの報酬 ―――― 83
5.2.2 マシンに仕事をさせる ―――― 83
5.2.3 対戦するのではなく遊べるゲームに ―――― 84
5.3 ゲームプレイとゲームプレイのバランス ―――― 86
5.3.1 コンポーネントと属性のバランス ―――― 87
5.3.2 推移的でないゲーム構造がバランスを保証する89
5.4 ゲームバランスのチェックリスト ―――― 104
第6章 ルック&フィール ―――― 107
6.1 雰囲気 ―――― 107
6.1.1 サウンド ―――― 109
6.1.2 映像 ―――― 109
6.1.3 タッチ ―――― 112
6.2 インターフェイス ―――― 113
6.3 ストーリーを伝える ―――― 116
6.3.1 ストーリーを伝えるための道具 ―――― 116
6.4 まとめ ―――― 128
第7章 ゲームデザインのまとめ ―――― 129
7.1 この道のプロの話 ―――― 130
7.1.1 ゲームのコンセプト ―――― 130
7.1.2 変更についての計画 ―――― 132
7.1.3 技術的な面 ―――― 137
7.1.4 開発 ―――― 138
7.1.5 チーム ―――― 141
7.1.6 コストと作業スケジュール ―――― 143
7.1.7 ゲームプレイ ―――― 144
7.1.8 未来 ―――― 147
第8章 ゲームデザインの未来 ―――― 151
8.1 デザインの必要性 ―――― 151
8.1.1 計画を立てることを恐れるな ―――― 152
8.1.2 なぜデザインすることがすばらしいか ―――― 154
8.2 ゲームデザインに不可欠なもの ―――― 156
8.2.1 オリジナルであるか? ―――― 156
8.2.2 一貫性があるか? ―――― 157
8.2.3 インタラクティブか？ ―――― 157
8.2.4 おもしろいか？ ―――― 158
8.2.5 楽しいか? ―――― 159
8.3 デザインの未来 ―――― 159
8.3.1 より一般的なデザイン ―――― 160
8.3.2 シンボリックでないデザイン ―――― 161
8.4 ゲームの未来 ―――― 162
8.4.1 これからの10年 ―――― 164
8.4.2 ソフトウェアの力 ―――― 164
8.4.3 創造性の交差点 ―――― 166
8.5 今後進むべき道 ―――― 170
Part 2 チームの構成と管理 ―――― 173
第9章 チーム管理の手法 ―――― 175
9.1 開発のモデル ―――― 175
9.1.1 業界の起源 ―――― 176
9.1.2 ゲーム開発者の問題点 ―――― 178
9.1.3 典型的なゲーム開発者 ―――― 182
9.1.4 過度に長い開発期間は失敗したプロジェクトの証 ―――― 187
9.1.5 ルールの例外 ―――― 188
第10章 役割と部門 ―――― 191
10.1 人員の割り当て ―――― 191
10.1.1 管理とデザイン部門 ―――― 192
10.1.2 プログラミング部門 ―――― 194
10.1.3 アート部門 ―――― 195
10.1.4 音楽、その他の部門 ―――― 195
10.1.5 サポートと品質保証部門 ―――― 196
10.2 士気の向上と労働環境 ―――― 198
10.2.1 士気を高めるもの ―――― 198
10.2.2 士気を高めるものに関する警告と注意 ―――― 204
10.3 リスクの拡散 ―――― 205
第11章 ソフトウェア工場 ―――― 207
11.1 ソフトウェア工場とは何か ―――― 207
11.2 どうしてソフトウェア工場を使うのか ―――― 209
11.2.1 ゲーム開発の問題点の解決 ―――― 209
11.3 ソフトウェア工場の組織化 ―――― 214
11.3.1 構造の概要 ―――― 214
11.3.2 部門の責任と連携 ―――― 215
11.4 ソフトウェア工場の構造と方法論の適用 ―――― 225
11.4.1 離陸せよ ―――― 225
11.4.2 各チームを利用するときを知る――並行した開発スケジュール227
11.4.3 チームメンバーの交替と再配属 ―――― 228
11.5 ソフトウェア工場の適合性 ―――― 230
11.6 最後に ―――― 230
第12章 スケジュール管理 ―――― 233
12.1 目標設定の一般的な機能 ―――― 234
12.2 あいまいな目標設定 ―――― 238
12.3 小さな目標設定 ―――― 238
12.4 目標設定を利用する場合 ―――― 239
12.5 目標設定を正確にする ―――― 240
12.5.1 チェックポイント1.0――一般的な必要条件をそろえる ―――― 243
12.5.2 チェックポイント1.1――技術的な必要条件をそろえる ―――― 244
12.5.3 チェックポイント1.2――必要なリソースをそろえる ―――― 245
12.5.4 チェックポイント2.0――一般的な実現可能性の検討 ―――― 246
12.5.5 チェックポイント2.1――技術的な実現可能性の検討 ―――― 247
12.5.6 チェックポイント2.2――利用できるリソースの検討 ―――― 248
12.5.7 チェックポイント3.0――アーキテクチャドラフト ―――― 248
12.5.8 チェックポイント3.1――プロジェクトの立ち上げ ―――― 249
12.5.9 次のステップ ―――― 249
12.6 目標設定の確定 ―――― 249
12.6.1 適切でない目標設定 ―――― 250
12.6.2 適切な目標設定 ―――― 255
12.6.3 リサーチと納期 ―――― 257
12.6.4 目標設定の評価 ―――― 257
第13章 評価と工程 ―――― 259
13.1 手続き ―――― 260
13.1.1 レビュー ―――― 260
13.1.2 テスト全般 ―――― 264
13.2 工程管理 ―――― 270
13.3 手続き――どこで利用するのか ―――― 275
13.3.1 デザインの段階 ―――― 275
13.3.2 開発段階 ―――― 278
13.3.3 テスト段階 ―――― 279
13.4 ソースコントロールとコードレビュー――相乗効果 ―――― 280
13.4.1 何のためにソースコントロールを利用するのか ―――― 282
13.5 情報伝達の重要性 ―――― 285
13.5.1 事前と事後の情報伝達 ―――― 288
第14章 トラブルへの対処 ―――― 291
14.1 リスク ―――― 295
14.1.1 デザインとアーキテクチャの問題 ―――― 299
14.1.2 スケジュールの脅威 ―――― 309
14.1.3 組織上の問題点 ―――― 315
14.1.4 外注の問題 ―――― 317
14.1.5 人員の問題 ―――― 318
14.1.6 開発の問題点 ―――― 320
14.1.7 工程管理の問題点 ―――― 324
第15章 ゲーム業界の未来 ―――― 327
15.1 業界の状態 ―――― 327
15.1.1 第一紀 ―――― 328
15.1.2 第二紀 ―――― 328
15.1.3 第三紀 ―――― 329
15.2 開発会社の新たなモデル ―――― 337
15.3 オンライン革命 ―――― 342
15.3.1 ゲームのオンライン購入 ―――― 342
15.3.2 ゲームのオンラインプレイ ―――― 343
15.4 適者生存 ―――― 344
Part 3 ゲームアーキテクチャ ―――― 345
第16章 開発の手法 ―――― 347
16.1 開発技術の歴史 ―――― 349
16.1.1 独創的なゲームの興亡 ―――― 350
16.1.2 開発環境 ―――― 352
16.2 現在の状況 ―――― 361
16.2.1 再利用性 ―――― 361
第17章 基本設計 ―――― 369
17.1 まず最初に ―――― 370
17.2 ハードウェアの抽象化 ―――― 373
17.2.1 グラフィックスハードウェアの抽象化 ―――― 373
17.2.2 サウンドハードウェアの抽象化 ―――― 377
17.2.3 その他のハードウェアの抽象化 ―――― 378
17.2.4 「自分しか信じない」症候群からの脱出 ―――― 382
17.2.5 トワイライトゾーン ―――― 384
17.3 問題領域 ―――― 385
17.3.1 ゲームとは何か（再考） ―――― 386
17.4 トークンについての考察 ―――― 387
17.4.1 Pongのトークン化 ―――― 388
17.4.2 パックマンのトークン化 ―――― 394
17.4.3 状態遷移と属性 ―――― 401
第18章 技術面の考察 ―――― 407
18.1 現在の技術水準 ―――― 410
18.1.1 3Dエンジンの興亡 ―――― 411
18.1.2 テクノロジーに関する認識 ―――― 415
18.2 青空リサーチ420
18.2.1 リサーチのタイプ ―――― 422
18.2.2 日誌をつける430
18.3 車輪の再発明 ―――― 431
18.3.1 互換性レベル ―――― 432
18.4 オブジェクトテクノロジーの使用 ―――― 436
18.4.1 最適化――コンピュータと人間 ―――― 436
18.4.2 抽象化の是非 ―――― 440
第19章 オブジェクト指向のすすめ ―――― 443
19.1 ソフトウェアの再利用 ―――― 444
19.1.1 コードの再利用 ―――― 445
19.1.2 デザインの再利用――パターン ―――― 446
19.1.3 ゲーム固有のパターン ―――― 482
第20章 アーキテクチャの設計 ―――― 485
20.1 アーキテクチャの誕生 ―――― 485
20.1.1 アーキテクチャの概念 ―――― 487
20.2 階層システム492
20.2.1 ゼロ階層――プロトタイプ493
20.2.2 第1階層以降 ―――― 498
20.3 アーキテクチャの設計 ―――― 502
20.3.1 階層ベースの手法のアーキテクチャ設計への適用 ―――― 504
20.3.2 アーキテクチャの直交性 ―――― 507
第21章 開発 ―――― 509
21.1 開発の工程 ―――― 510
21.2 コードの品質 ―――― 512
21.2.1 コーディングの基準 ―――― 513
21.3 コーディングの優先事項 ―――― 534
21.3.1 スピード ―――― 534
21.3.2 サイズ ―――― 536
21.3.3 柔軟性 ―――― 537
21.3.4 移植性 ―――― 537
21.3.5 メンテナンス性 ―――― 537
21.4 デバッグとモジュールの完成 ―――― 538
21.4.1 バグの種類 ―――― 539
21.5 7つのすばらしい作戦 ―――― 545
21.5.1 再利用 ―――― 545
21.5.2 ドキュメント ―――― 546
21.5.3 まずデザイン ―――― 547
21.5.4 スケジュール ―――― 547
21.5.5 作業を進めながら間違いを見つける ―――― 548
21.5.6 研究開発の制限 ―――― 548
21.5.7 いつ線を引くかを知る ―――― 548
21.6 3つの失敗 ―――― 549
21.6.1 悪い管理 ―――― 549
21.6.2 機能潜り込み現象 ―――― 549
21.6.3 コーダーの孤立 ―――― 549
第22章 リリースへの準備 ―――― 551
22.1 直前の評価 ―――― 552
22.1.1 最終的な分析 ―――― 552
22.1.2 ゲームが標準に達しているか ―――― 554
22.2 終盤のローカライズ563
22.2.1 ライセンス ―――― 563
22.2.2 言語 ―――― 564
22.3 デモ ―――― 565
22.4 プレイテスト567
22.5 フォーカスグループ570
22.6 Webサイト ―――― 571
22.7 ゴールデンマスターの準備 ―――― 572
22.8 パッチ573
第23章 プロジェクトをふりかえって ―――― 577
23.1 チーム内の力関係 ―――― 581
23.2 コンセプト ―――― 585
23.2.1 風潮 ―――― 585
23.2.2 受け入れやすさ ―――― 588
23.3 開発 ―――― 591
23.3.1 ソフトウェアプランニング ―――― 591
23.3.2 コーディング ―――― 594
23.3.3 テスト594
23.4 ビジネス要素 ―――― 595
23.5 事後分析の事後分析 ―――― 596
第24章 ゲーム開発の未来 ―――― 599
24.1 コンテキストの中の開発 ―――― 600
24.2 将来の開発 ―――― 603
24.2.1 マーケティング603
24.2.2 コンテンツ605
24.2.3 プランニング608
24.2.4 開発会社 ―――― 609
24.3 小さいこともいいことだ ―――― 610
24.4 将来のチームを作り上げる ―――― 611
24.4.1 性格 ―――― 611
24.4.2 動機づけ ―――― 613
24.4.3 士気 ―――― 615
24.5 開発の新しい方向 ―――― 616
24.5.1 全体論のアプローチ ―――― 616
24.5.2 「ジュラシック・パーク」ソフトウェア ―――― 618
24.5.3 遍在的な世界と超越的な世界 ―――― 619
24.6 来たるべきものの形 ―――― 622
Part 4 企画と設計のサンプル ―――― 625
第25章 サンプルゲーム「Balls!」 ―――― 627
25.1 Balls!について ―――― 627
25.2 ゲームプレイの概要 ―――― 627
25.3 プラットフォーム ―――― 628
25.3.1 対象ユーザー ―――― 629
25.4 タイムスケール ―――― 630
25.4.1 基本コンセプト ―――― 630
25.5 パズルゲームに昔ほどよいものがなくなった理由 ―――― 630
25.6 パズルゲームの魅力 ―――― 631
25.6.1 あまりにかわいらしすぎない ―――― 631
25.6.2 「真剣な」暴力を避ける ―――― 631
25.6.3 抽象的なものにする。ただし過度に抽象的なものにしない ―――― 632
25.6.4 進歩に対して報酬を与える ―――― 632
25.7 Balls!がよいゲームになる理由 ―――― 632
25.7.1 ルック&フィール ―――― 633
25.8 ゲームのデザイン――ユーザーインターフェイスの要素 ―――― 634
25.8.1 ゲーム設定時のインターフェイス ―――― 634
25.8.2 レベルのデザイン（レベルベースのゲームモード用） ―――― 636
25.8.3 レベルの進化 ―――― 639
25.9 Balls!の物理学 ―――― 639
25.10 ブロック ―――― 643
25.11 ブロックとブロックの衝突の特殊なケース ―――― 648
25.12 ゲームプレイ ―――― 651
25.12.1 戦略ゲーム ―――― 651
25.12.2 レベルベースのアクションゲーム ―――― 652
25.13 その他の装飾 ―――― 653
25.13.1 最初のオプション ―――― 654
25.13.2 2番目のオプション ―――― 655
25.14 技術仕様 ―――― 655
25.15 技術仕様――Balls!のための完全な3Dのプラグイングラフィックスモジュール ―――― 656
25.15.1 開発者への注意 ―――― 656
25.15.2 SObjectState構造体 ―――― 660
25.15.3 SShadowInfo構造体 ―――― 663
25.15.4 レベルのグラフィックスのオブジェクト ―――― 664
25.15.5 描画可能なオブジェクトについての個別の説明 ―――― 666
25.15.6 ブロックのイベント ―――― 666
25.15.7 ブロックの種類 ―――― 667
25.15.8 ボールのイベント ―――― 673
25.15.9 ボールの種類 ―――― 673
25.15.10 ボールの属性 ―――― 676
25.16 コードレビューの書式 ―――― 676
25.17 テストスクリプト ―――― 677
第26章 構想と設計のサンプル ―――― 679
26.1 Racketeers――狂乱の1920年代におけるギャングの抗争 ―――― 679
26.1.1 1. 概要 ―――― 680
26.1.2 2. ゲームの目的 ―――― 681
26.1.3 3. グラフィックス ―――― 683
26.1.4 4. ゲームのプレイ ―――― 685
26.1.5 5. キャラクターの種類 ―――― 686
26.1.6 6. 性格 ―――― 690
26.1.7 7. 命令 ―――― 692
26.1.8 8. 戦い ―――― 693
26.1.9 9. ゲームの世界 ―――― 694
26.1.10 10. ジョイント ―――― 697
26.1.11 11. メッセージ ―――― 700
26.1.12 12. チュートリアル用の一連のミッション ―――― 701
26.1.13 13. 対象となるプラットフォーム ―――― 703
26.1.14 後記 ―――― 703
26.2 Liberator ―――― 704
26.2.1 1. はじめに ―――― 704
26.2.2 2. ゲームの要素 ―――― 705
26.2.3 3. どのようにプレイするか ―――― 711
付録A 参考資料 ―――― 713
付録B 用語集 ―――― 716
索引 ―――― 718
内容説明
さまざまな制作現場、有名クリエーターのコメント、成功例と失敗例の数々を体系化して導き出した、成功するゲーム制作のための理論と法則。
目次
１ ゲームデザイン（コンセプト；基本デザイン；ゲームプレイ ほか）
２ チームの構成と管理（チーム管理の手法；役割と部門；ソフトウェア工場 ほか）
３ ゲームアーキテクチャ（開発の手法；基本設計；技術面の考察 ほか）
４ 企画と設計のサンプル（サンプルゲーム「Ｂａｌｌｓ！」；構想と設計のサンプル）
付録（参考資料；用語集）
著者等紹介
ローリングス，アンドリュー［Ｒｏｌｌｉｎｇｓ，Ａｎｄｒｅｗ］
ロンドンのインペリアルカレッジとブリストル大学で物理学の学士号（専攻科）を取得。１９９５年より、ゲーム業界から金融業界にわたり技術コンサルタントとして活躍。Ｄａｖｅとともに、コンセプトから全技術プランに至るまで、ゲームの設計に関する総合的なコンサルタント事業を営んでいる
モリス，デイブ［Ｍｏｒｒｉｓ，Ｄａｖｅ］
オックスフォード大学で物理学の修士号（専攻科）を取得。その後１５年間、ベストセラー作家兼ゲームデザイナーとして活躍し、意図せずＳｎｏｗのいう「２つの文化」にまたがって活動している。コンサルタント業では、数百万ドル規模のＷｅｂ関連企業のクリエイティブアドバイザーを務めている
※書籍に掲載されている著者及び編者、訳者、監修者、イラストレーターなどの紹介情報です。
感想・レビュー
※以下の感想・レビューは、株式会社ブックウォーカーの提供する「読書メーター」によるものです。
Jey.P.
