ゲーム制作において「仕様書」は、開発を進めるための大切な資料です。
しかし、ゲーム会社によって仕様書の書き方は異なります。細かく内容をまとめる会社もあれば、簡単な資料や口頭での説明を中心に制作を進める場合もあります。
これからゲームプランナーを目指す人の中には、「仕様書には何を書けばいいの？」「プログラミングの知識がないと作れないの？」と疑問に思う人もいるでしょう。
私は以前、ゲーム会社でプランナーとして働いていました。
その経験から伝えたいのは、仕様書は難しく考えすぎる必要がないということです。
もちろん、必要な情報を正確に伝えることは重要です。しかし、きれいな書式で資料を作ること自体が目的ではありません。
仕様書には、ほかの担当者に制作内容を伝える役割と、時間がたってから自分や別の担当者が内容を確認できるようにする役割があります。
この記事では、ゲームプランナーが作成する仕様書について、基本的な書き方や記載項目、具体例、管理するときの注意点を紹介します。
ゲームの仕様書とは？
ゲームの仕様書とは、ゲームに実装する機能や動作、ルール、パラメーターなどをまとめた資料のことです。
例えば、ゲームの中に落とし穴を設置するとしましょう。
単に「キャラクターが落とし穴に落ちる」という説明だけでは、実装するための情報が足りません。
プレイヤーだけが落ちるのか、敵キャラクターも落ちるのか、落ちた後にどうなるのかなど、決めておくべきことがあります。
こうした内容を文章や図、表などにまとめ、プログラマーやデザイナーなどの担当者に伝えるためのものが仕様書です。
また、ゲーム開発では制作するものに応じて、さまざまな仕様書が存在します。
- キャラクターの操作仕様
- 敵キャラクターの行動仕様
- アイテムの効果やパラメーター
- ギミックの動作仕様
- メニュー画面やUIの仕様
- ゲームの進行条件
- セーブ・ロードに関する仕様
このように、ゲーム内のさまざまな要素について、実装内容を明確にするために仕様書が利用されます。
なお、この記事で紹介するのは、主にゲームプランナーが作成する仕様書についてです。
ゲームの企画書と仕様書の違い
ゲームの企画書と仕様書は、似ているようで役割が異なります。
企画書は、どのようなゲームを作りたいのかを伝えるための資料です。
ゲームのコンセプトや特徴、面白さなどを説明することが中心になります。
一方、仕様書は、そのゲームを実際に制作するために、必要な機能や動作を具体的に説明する資料です。
例えば、企画書に「敵を倒すと武器が強くなるアクションゲーム」と書かれていた場合、仕様書では強化する条件や数値、強化後の動作などを決めていきます。
企画書と仕様書には共通する情報もありますが、目的が異なることを覚えておきましょう。
ゲーム仕様書に記載する内容
仕様書に決まった書き方があるわけではありません。
会社によってテンプレートが用意されている場合もあれば、担当者が必要な項目を考えて作成する場合もあります。
ただし、実装内容を伝える資料なので、最低限必要になる情報には共通する部分があります。
代表的な項目は次のとおりです。
| 項目 | 記載する内容 |
|---|---|
| 仕様名 | 何についての仕様書なのか |
| 概要 | どのような機能・仕組みなのか |
| 発動条件 | どのような状況で処理が始まるのか |
| 動作・処理 | 発動すると何が起こるのか |
| パラメーター | ダメージ量や速度などの設定値 |
| 例外条件 | 通常と異なる状況ではどうなるのか |
| 関連する仕様 | ほかの機能とどのようにつながるのか |
| 更新情報 | いつ、誰が、何を変更したのか |
すべての仕様書でこれらの項目が必要になるわけではありません。
例えば、簡単なギミックであれば、概要・発動条件・動作内容だけで説明できる場合もあります。
反対に、複雑なシステムでは、処理の流れを示す図や詳細なパラメーター表などが必要になることもあります。
大切なのは、実装する担当者が疑問なく制作を進められるだけの情報を記載することです。
ゲーム仕様書の書き方【落とし穴ギミックの具体例】
ここでは、ゲーム内に登場する「落とし穴」を例に、仕様書の書き方を紹介します。
落とし穴は、キャラクターが特定の場所に移動すると発動するギミックです。
基本的な仕様は、次のようにまとめられます。
落とし穴ギミックの仕様書例
仕様名：落とし穴
概要
- キャラクターが上に乗ると発動する罠
- 発動すると床が開き、キャラクターが落下する
- 落下後にダメージを与える
発動条件
- プレイヤーがギミックの上に乗った場合に発動する
- NPCがギミックの上に乗った場合は発動しない
動作
- プレイヤーが落とし穴の発動範囲に入る
- 落とし穴の蓋が開く、または消える
- プレイヤーが落下するモーションを再生する
- 着地したときにダメージを与える
パラメーター
| 項目 | 設定値 |
|---|---|
| 落下ダメージ | 30 |
| 発動対象 | プレイヤー |
| NPCへの反応 | なし |
このように、簡単なギミックであれば、文章と表を組み合わせるだけでも基本的な仕様を伝えられます。
ただし、これだけですべての処理が決まったわけではありません。
実装する際には、まだ確認しなければならない部分があります。
仕様書で不足しやすい情報
例えば、先ほどの落とし穴の仕様には、次のような疑問が残っています。
- プレイヤーがジャンプ中でも落とし穴は発動するのか
- 複数のプレイヤーが存在する場合はどうなるのか
- 落とし穴は一度発動したら元に戻らないのか
- プレイヤーが落下中に操作できるのか
- HPが30未満の場合はどうなるのか
- 落下後、プレイヤーはどこに移動するのか
- 発動中にセーブやロードを行った場合はどうなるのか
もちろん、すべてのゲームでこうした条件を考える必要があるわけではありません。
しかし、ゲームの仕様によっては、これらの情報が必要になることがあります。
そして、仕様書に記載されていない部分は、担当者が確認しなければならなくなります。
実装する担当者から質問が出た場合は、回答するだけでなく、その内容を仕様書へ追記しておくことが大切です。
口頭で説明した内容であっても、資料に残しておくことで、後から確認できるようになります。
プログラマーに渡す仕様書はプログラム言語で書く必要がある？
ゲームプランナーがプログラマーに渡す仕様書を、プログラム言語で書く必要はありません。
もちろん、プログラミングの知識があれば、技術的な制約を理解しやすくなるなどのメリットはあります。
しかし、ゲームプランナーの役割は、必ずしもプログラムそのものを作成することではありません。
何を実現したいのか、どのような条件で動作するのかを正しく伝えることが重要です。
例えば、落とし穴であれば「プレイヤーが乗ったら床が開き、着地時に30ダメージを受ける」といった仕様を明確にします。
それをどのようなプログラムで実現するかは、プログラマーが検討する部分になります。
ただし、プログラマーから「この場合はどうなりますか？」と質問されることもあります。
その際には、ゲームとしてどのような動作が望ましいのかを考え、必要に応じて仕様を追加しましょう。
仕様書は一度書いたら完成するものではなく、開発を進めながら内容を調整することもあります。
ゲーム開発では仕様書が重要になる理由
ゲーム開発は、規模によっては長期間にわたります。
小規模なゲームなら短期間で完成する場合もありますが、大きなプロジェクトでは数年かけて制作することも珍しくありません。
その間に、多くの仕様やパラメーターを決めていくことになります。
すべての内容を頭の中だけで覚えておくのは難しいものです。
そこで重要になるのが、仕様書として記録を残しておくことです。
仕様書は忘れたときのためにも書く
私が仕様書について特に重要だと思うのは、他人に伝えるためだけでなく、将来の自分が確認するためにも書いておくということです。
開発中には、次々と新しい仕様を考えたり、過去の仕様を変更したりします。
そのため、数か月前に決めた内容を、細かい部分まで正確に覚えているとは限りません。
実際にゲーム開発をしていると、「この場合はどうするんですか？」と担当者から質問されることがあります。
以前に口頭で決めた内容であっても、仕様書に書いていなければ、後から確認することが難しくなります。
私自身、こうした状況で困った経験があります。
だからこそ、細かい部分でも決定した内容は資料に残しておく方がよいと思います。
仲の良い担当者同士でも資料は必要
長くゲーム開発をしていると、プログラマーやデザイナーなど、何度も一緒に仕事をする担当者ができることがあります。
お互いの考え方や作り方を理解しているため、細かく説明しなくても意図が伝わる場合があります。
そうした関係は、開発を進めるうえで大きなメリットです。
しかし、だからといって仕様書が不要になるわけではありません。
その担当者が別のプロジェクトへ移動したり、自分が別の仕事を担当したりする可能性があるためです。
今の担当者同士で理解できていることと、将来の担当者が理解できることは別です。
口頭だけで決めた内容も、後から確認できるようにしておきましょう。
仕様書は将来の担当者のためにも残す
ゲーム開発では、途中で担当者が変更になることがあります。
例えば、ゲームプランナーが別のプロジェクトへ移動し、後任の担当者が仕様を引き継ぐ場合です。
そのときに仕様書が残されていなければ、後任の担当者は、現在のゲームがどのような考えで作られたのかを調べる必要があります。
特に困るのが、開発の終盤に追加された仕様です。
スケジュールが厳しい状況では、仕様書を更新する時間がなく、口頭での説明だけで実装を進めてしまう場合があります。
そのまま資料が残されなければ、後から仕様を変更したり、不具合を修正したりする際に問題になります。
私自身、こうした引き継ぎで困ったこともありますし、逆に十分な資料を残せなかった経験もあります。
続編や移植を制作するときにも役立つ
仕様書は、開発中だけでなく、続編や移植作品を制作するときにも役立ちます。
例えば、前作と同じシステムを利用する場合、過去の仕様が残っていれば、どのような条件で動作していたのかを確認できます。
しかし、資料が残っていないと、実際のゲームを動かしたり、プログラムの内容を確認したりしなければならなくなる場合があります。
もちろん、前作の仕様をそのまま利用できるとは限りません。
それでも、過去の判断や仕様変更の内容が記録されていれば、新しい開発を進める際の参考になります。
ゲーム仕様書を作成するときの注意点
仕様書は、難しく考えすぎる必要はありません。
会社でテンプレートが決まっているのであれば、基本的にはその形式に従って作成すればよいでしょう。
重要なのは、実装する担当者が必要な情報を確認できる状態にしておくことです。
ただし、仕様書を作成するときには、いくつか注意したいことがあります。
読む人が理解できる文章にする
仕様書を書くときは、自分にだけ分かる説明にならないように注意しましょう。
例えば「敵を素早く移動させる」という説明だけでは、具体的な動作が分かりません。
移動速度の値や動作する条件など、必要な情報を記載しておくことが大切です。
また、複雑な処理については、文章だけでなく図や表を利用する方法もあります。
特に、画面の遷移や条件分岐などは、図を使った方が分かりやすい場合があります。
仕様書の書式をできるだけ統一する
会社に決まったテンプレートがない場合でも、ある程度書式を統一しておくことをおすすめします。
例えば、概要、発動条件、動作、パラメーターなどの項目を、毎回同じ順番で記載する方法です。
担当者によって資料の構成が大きく異なると、必要な情報を探しにくくなります。
また、仕様書が大量に増えた場合、どの資料に何が書かれているのかを把握することも難しくなります。
書式をそろえることで、確認や管理の手間を減らせる場合があります。
ただし、書式を統一すること自体が目的にならないように注意しましょう。
変更した内容を記録する
ゲーム開発では、途中で仕様が変わることがあります。
例えば、プレイヤーの攻撃力を変更したり、敵の行動パターンを調整したりする場合です。
その際には、仕様書もあわせて更新しておくことが重要です。
古い仕様と新しい仕様が混在すると、担当者が誤った内容で作業してしまう可能性があります。
そのため、変更した日付や内容、必要に応じて変更理由などを残しておくとよいでしょう。
また、どの資料が最新なのか分かるようにしておくことも大切です。
仕様書を細かく書きすぎない
仕様書は詳しく書いた方がよいと思われがちですが、必ずしも文章量が多ければよいわけではありません。
すでに別の資料で説明されている内容を何度も記載すると、仕様変更があった場合に、複数の資料を修正する必要が出てきます。
また、細かい説明が多すぎると、重要な情報を探しにくくなる場合もあります。
そのため、共通する仕様は別の資料にまとめ、必要な箇所から参照できるようにする方法もあります。
必要な情報を不足なく記載しながら、できるだけ読みやすい資料を作ることを意識しましょう。
ゲーム仕様書はExcelやWordで作ればいい？
仕様書を作成するためのソフトウェアに、必ず使わなければならないものがあるわけではありません。
例えば、次のようなツールを利用できます。
| ツール | 向いている用途 |
|---|---|
| Excel・スプレッドシート | パラメーター表や一覧形式の仕様 |
| Word・文書作成ソフト | 文章を中心とした仕様書 |
| PowerPoint・スライド作成ソフト | 画面構成や動作の説明 |
| 共同編集できるドキュメント | 複数人での確認や更新 |
| プロジェクト管理ツール | 仕様とタスク、変更履歴の管理 |
重要なのは、使用するツールそのものではありません。
開発チームの担当者が資料を確認でき、必要なときに更新できることが大切です。
会社によっては管理方法が決められている場合もあるため、その場合は社内のルールに従いましょう。
まとめ：ゲーム仕様書は忘れたときに確認できる資料にしよう
ゲームの仕様書は、プランナーが考えた内容を、プログラマーやデザイナーなどの担当者へ伝えるための資料です。
しかし、それだけではありません。
時間がたってから自分が内容を思い出したり、別の担当者が仕様を引き継いだりするためにも重要な資料です。
仕様書を作成するときは、次の点を意識しましょう。
- 何を実現したいのかを明確にする
- 発動条件や動作内容を具体的に記載する
- 担当者から質問された内容を追記する
- 口頭で決定した内容も資料に残す
- 変更履歴や最新の仕様を確認できるようにする
- 読みやすい書式を意識する
仕様書は、立派な資料を作ることが目的ではありません。
自分が考えたゲームの内容を正しく伝え、開発を円滑に進めるためのものです。
そして、将来の自分や別の担当者が確認したときにも、必要な情報が分かる状態にしておくことが大切です。
「忘れたときに確認できるように書いておく」
この考え方を大切にして、ゲームの仕様書を作成してみてください。
ゲーム企画書の作り方について
ゲームの企画書では、作りたいゲームのコンセプトや面白さを、相手に分かりやすく伝えることが重要です。
企画書のまとめ方や書くときに意識したいポイントについては、こちらの記事でも紹介しています。
ゲームの企画書の作り方、それは、枚数と整理された内容が重要！
ゲームギミックの実装で注意したいこと
落とし穴のようなギミックでは、発動条件だけでなく、プレイヤーの行動や当たり判定も考慮する必要があります。
扉ギミックを例に、コリジョンや進行不能バグを防ぐための考え方についても解説しています。
ゲームの扉ギミックとは？開閉処理・当たり判定・進行不能バグの対策
生成AIを使って仕様書の作成を補助する方法
最近では、生成AIを使って仕様書の構成を整理したり、不足している条件を洗い出したりすることもできます。
例えば、落とし穴ギミックの概要をAIに伝え、「実装する際に不足している条件を指摘してください」と質問する方法があります。
ただし、AIが提案した内容をそのまま採用するのではなく、ゲームの仕様に合っているかを確認する必要があります。
プログラミングやゲーム制作など、生成AIのさまざまな活用方法についてはこちらの記事でも紹介しています。
生成AIでできることとは？仕事・画像・動画・プログラミング・ゲーム制作の活用方法
コメント