「ゲーム開発　プロジェクト管理の基本」を読んだ。読んだ理由はゲーム開発のプロジェクト管理について何も知らないのでWEB開発とどこが違うのか比較しようと思ったからである。

TD;TL

基本的にゲーム開発もIT業界の一部であるため、ゲーム特有のプロジェクト管理は少ないと感じた。したがってこの本はIT業界に詳しい人はあまり得るものが少ないかもしれない。

製品リリースまでの流れ

後の章でも書いてあったが、企画のコンセプトがぶれる、または見直しになると工程にかなりの手戻りが必要になり現実的でない
- そのため、コンセプトはかなり吟味する必要がありそう
- コンセプトがブレブレなゲームはたまに見るが、やっぱ見直すとなると工数が膨大になってしまうから、リリースしてしまう側面もあるんだろうと推測する
開発の段階は以下がある
- プロト版：プロトタイプ、基本部分やコンセプトの面白さなどの確認
- α版：使用を全体的に実装して確認
- β版：α版からバグや細かな調整をしてほぼ完成させたもの。最終確認する
- マスター：完成版

プロジェクトの構成

プロジェクトの前提として前提と制約条件を明確化する必要がある
- 前提を明確にするために、市場の状況分析や企画の経緯、組織の状況などをまとめる
- 目的はプロジェクトをスムーズに理解してもらうための導入
プロジェクトの立ち上げ段階ではゲーム開発特有のゲーム開発の特徴としては「5W1Hが不明確」である
- 本ではサッカー大会プロジェクトとゲーム開発プロジェクトの5W1Hの比較がある
  - サッカー大会プロジェクト
    - Who：サッカー大会運営者が
    - What：サッカー大会を
    - Whom：大会参加するチームのために
    - Where：サッカー競技場に
    - When：サッカーチームにとって参加しやすいシーズンに
    - How：サッカー大会を開催する
  - ゲーム開発プロジェクト
    - Who：不明（一応開発者が）
    - What：ゲームを
    - Whom：（購入者？）
    - Where：不明
    - When：不明
    - How：遊ばせる
- こうしてみると、プロデュサーなどは不明の部分を明確化していくの仕事であると察せられる

チーム開発プロジェクトの計画管理令

目的の洗い出し
- 「小学生に県内の地理を楽しく覚えてもらう授業中に使用するゲームの開発」を行う目的があるとき
  - 楽しさと学習を両立させることが大事、またユーザーが小学生であることを考慮する必要がある
  - 「目的」と「目標」の違いについて述べている
    - 上記の目的はたどり着くべきゴール、つまりMUST
    - 目標は目指す基準、例として「ゲームのユーザーの80%が面白いと評価してもらえること」のように定義することができる
    - 目的には「行動」、目標には「結果」を設定すると良いらしい

マイルストーンを活用する

タスク管理や仕様書レビューの説明もあったが、ここは私にとってはあまり読まなくてよさそうだった。
マイルストーンの中であまり聞きなれない「パーティカルスライス」という単語が出てきた
- パーティカルスライスとはゲームの序盤から途中までが完成しており、そこだけを切り出して通しでプレイできるというもの
  - 目的は、コンセプト確認用のプロト版と仕様がすべて実装されているα版では乖離が大きい。その乖離を埋めるためゲーム全体を正しく検証するためである
  - これだけ書くと分かりづらいが、RPGの1章だけを通しでプレイできるか？を検証することである
  - 1章の中には戦闘、マップ移動、イベント、ミニゲーム、メニューなどが実装されていて、結合して動かして確認する
  - これはゲームクリアという目標を用意していることの多いゲームならではのやり方だと思った
プログラムのバグについて
- 全世界で1人しか発生しないバグがあることもあり対応が難しい
  - 著者が遭遇したもので一番不可解なものは冬の北海道のよく冷えたPCだけに発生するバグがあったらしい
    - PCを冷蔵庫に持ち込むことで再現
  - このバグに対応するかは微妙なところだなという感想
- ゲームのコンセプトは面白いけど低品質なゲームが存在する
  - ゲームの処理が想定より重すぎて快適にプレイできない
  - 表示負荷が大きすぎてスローモーションになる
  - ロードに15分かかる
- ゲームの低品質化はプログラマの技術力に寄与する部分も大きそう
- 面白いけど品質がなぁというゲームは確かにあったな
  - スローモーション：地球防衛軍2、とにかく敵が多くなると重くなってまともに動けない
  - ロードに時間がかかる：クラッシュバンディクー4、ステージのロードに5分くらいかかってなかったかな？

仕様の見直し

ゲームは使用の独立性が低いので、こまめに見直しされると全体にも見直しがこまめに発生してタスク全体が混乱する
- 例えばRPGで武器の仕様を変更してパラメータを一つ追加すると、戦闘の仕様、プレイヤーキャラの仕様、敵キャラの仕様、アイテムの販売、アイテム入所の設定など全体に影響を及ぼす
- WEBアプリケーションだと、ケースバイケースだけどデータベースなどの基幹部分を変更しないときは影響範囲はここまでにはならないイメージ

不具合から出たテクニック

当初、キャンセル技はなしというコンセプトで開発されたゲームがあった
しかしプレイヤーが仕様の穴を衝いてキャンセル技を生み出した
コンセプトには反するもののキャンセル技はゲームプレイを膨らませてくれるとして残すことに
多彩なテクニックを駆使してプレイするようになり、ゲームが盛り上がった
- ここまで聞くとガンダムVSガンダムのフリーダムにのみ搭載されてた覚醒キャンセルがNEXTでは全機体に搭載されたようなものか

ウォーターフォールやアジャイルについての説明もあったが、ほぼ知っていることだったので目を通して終わった。

日記帳

プログラミングのことをつぶやく日記です。

「ゲーム開発　プロジェクト管理の基本」を読んだ