仕様書の書き方-番外編-

 

1245826_89373399.jpg

--------------------------------
saiと申します。質問をさせてください。

『ゲーム仕様書の書き方』を購入させていただきました。
私のような立場や経歴の人間には大助かりなコンテンツです。

というのも、私は今現在ゲーム会社への就職活動中でして、仕様書の課題をもらって
いる最中なのです。

しかし私は、専門学校を出たのはなく、ゲームには関係の無い大学を出ました。
そのため、全くゲーム創作に関しての知識はありません。

2次試験の企画書をパスするコトは出来たのですが、追加課題として仕様書を
提出するよう言われました。
(採用情報には2次の次は面接とあったのですが・・こういうことが普通なのでしょうか?)

しかし仕様書となるとあまりにも専門的なものを要求され、悩んでます。

今回『仕様書の書き方』を読ませていただきました。(読みやすくて何度も
読み返しが可能なのが助かりました)

ゲーム全体の仕様書の書き方は理解できましたが、今回私が出されている課題は
例えば、「必殺技のシステム」や「レーシングゲームのステージ」など
ピンポイントなのです。

この場合(「ステージの仕様書」)、どこからどこまでを書けばよいのか
分かりません。

プログラミングの知識もあまりありません。
会社は新卒のどこを見ているのかも読めません。その辺りも教えていただけると
大変助かります。

私のような立場の方にでも役に立てばよいですが・・・長文で分かりにくいことを
お詫びします。よろしくお願いします。

sai
--------------------------------


 こんにちはsaiさん。

 ゲーム会社への就職活動、おつかされまです。

 こうして質問をくださるくらいだから、saiさんの意欲は高いですよ。

 将来は一人前のプランナーになると思います。

 現場のナマの情報ってあまり得る機会がないですから、どうぞゲームのしくみを
活用してくださいね。


 さて、メインシステムの仕様ではなく、サブシステムの仕様ということですが、
考え方は同じです。


 どの範囲まで書けばいいのか? ということですが、基本的に伝えなければ
いけない部分はすべて伝える必要があります。


 仕様は、それに沿ってプログラマやグラフィッカー、コンポーザーが
作業をしますから、そのスタッフが必要とするであろう情報は、すべて盛り込む
必要があります。


 誰に伝えるのか? これを意識すること、これかなり重要ですよ。

 これを意識すれば、余計な仕様を書かなくて済みますからね。


 プログラマに対しては、例えば戦闘システムの仕様であれば、最初に
そのフロー(流れ)を図で書く。

 ゲームシステムって、まずは流れなんですよね。

 時間軸の概念が必ずある。

 ウィンドウズのアプリみたいに、ボタンが押されたらこういうアクションを
する、という感じのシステムではなく、必ずループ、つまり繰り返される処理が
あり、その中で処理の分岐があるわけです。


 だから、まずは

1・プレイヤーのターン

2・敵のターン

3・1に戻る


みたいな、基本的なループがあります。

 これはプランナーが知っておいたほうがよい、プログラムの基本でもあります。


 これに対して、どういう処理分岐があるのか、というのを網羅していくわけです。

 例えば、プレイヤーのターンであれば、単なる攻撃なのか、魔法攻撃なのか、
防御なのか、みたいな分岐がありますね。

 また、魔法攻撃も、どの魔法を使うのか、みたいな分岐があります。

 で、選ばれた魔法によって、また処理が違う。

 攻撃魔法か、防御魔法か、属性変化か、みたいな。

 それを全部書きます。


 流れで書いた概要を、どんどん詳細にしていくわけです。


 抽象 → 具象

 概要 → 詳細


で書いていくのが基本ですね。


 で、最終的には、全部数値に落とします。

 数値というのはなにかというと、上の例で言えば、

プレイヤーは最高何人なのか、
敵は最高何人なのか、
攻撃力はどう計算するか、
それぞれの武器の攻撃力はいくつか、
防御力はそれぞれの防具についていくつか、

などなど、ですね。

 わかると思いますが、これを全部書くのは相当な作業量です。

 これが仕様書なんですね。


 で、敵の種類とか、武器の種類の数とか、それぞれのパラメータは、
エクセルの表に落とします。

 あと、グラフィッカーへの発注用に、こういう敵を描いて欲しい、
こういう剣を描いて欲しいなどの具体的な指示は、仕様書の添付資料として
発注書を書きます。


 急いでいるときなどは、まずはスタッフが作業に入ることが優先されますから、
フローの詳細や発注表を先に書いたりすることもあります。


 設計ミスがあったりすると作業が無駄になることもあるので、だいぶ
上級者向けですが。

 

 仕様書はMECE(ミーシー:漏れなくダブりなく)であることが
必要なので、最初の設計にミスがないことが要求されます。


 なので、ちゃんとそのシステムが実現可能なのか? 規模的に運用可能か?
この期間、このスタッフで作ることができるか? という現実的な面も
常に考える必要があります。


 で、単に「設計」だけを書けばいいのか、というとそうではなく、
その「設計の意図」をスタッフに伝えることも大事です。


 「この魔法の数、分類は、こういう意図で、こういう効果を狙っている」


などという意図ですね。


 今のゲームはほとんどこういう「意図」が感じられないものが多いですが...。


 例えば攻撃の爽快さを魔法で表現したいのであれば、攻撃魔法の数が
多くなるだろうし、テクニカルな魔法戦闘を実現したいという意図があれば、
それぞれの魔法の組み合わせを考慮して、分類が多くなったりします。


 ただ漫然とゲームを作る材料を用意するのではなく、その材料によって
どうプレイヤーの感情を実現するのか? というところが大事です。


 仕様にはスタッフへの気配りだけでなく、プレイヤーへの気配りも
反映しなければダメです。


 レーシングゲームのコースの仕様であれば、例えば、初心者用のコースは
90度以上のカーブがないとか、コースの指示看板が観客席にあるとか、
最初プレイで爽快感を味わってもらうために、スピードアップのフィーチャーを
多めに用意するとか、そういう「意図」があるといいですよね。


 大雑把に書きましたが、あとは「仕様書の書き方」通りにやってみて
くださいね。


 まともな、MECEな仕様書が書けるということは、実戦投入できる
人材ということになり、ほかのプランナーと比べて大きなアドバンテージ、
優位を持つことができます。


 ですので、企画が通って、仕様書を要求されたということは、
即現場に入れる人材なのか、ということを試していると思います。


 だから、その会社はよっぽど人手不足なのかもしれません(笑)。

 まあ、今ゲーム業界は慢性的な人手不足なのですが。


 会社は、新卒がいかに素早く現場に入れるか、いかに現場でスムーズに
仕事ができるようになってくれるか、というところを見ています。


 だから、もちろん仕事上のスキルも見ていますが、社会常識とか、
人に対する気遣い、言葉の使い方を重要視しているところが多いんです。


 スタッフをカチンとさせたり、怒らせたりしたら、仕事がスムーズに
進まないということになりますからね。


 あとはやる気ですね。


 「私は素早くプランナーのスキルを習得して、現場と仕事になじんで
いくことに意欲があります! 必ずやってみせますので、ぜひ私を採用
してください!」


 みたいなということをウソでもいいので言えれば買ってもらえます。

 ウソでも、というのは、ウソでも言えないわけですよ。

 普通は。

 そんな大きな期待をされたら困る、みたいな人が多いので(笑)。


 その期待を持ってもらおう、それだけのことをする意欲があるのだ!
という意志を表明をできただけでも、すごいです。


 決意ですね、これは。

 オレはゲーム業界でバリバリやるんだ! という。

 ゲーム業界に墓をうずめるんだ! という。

 ウソでも、そういうことを言って欲しいんです(笑)。

 もちろん、その後の行動の責任は生まれますけど。


 それを背負えるだけの意欲があるのか、ということなんです。

 

 ということで、仕様書については以上のような感じです。


 仕様書を要求されたということは、それだけ期待されているのも
確かです。


 saiさん、頑張ってくださいね。

このエントリーをはてなブックマークに追加


期間限定企画「中毒ゲームデザイン・トレーニング」
■中毒になるゲームの秘訣はあなたがド変態であること?
現在1927名の方が登録中。
期間限定でゲームデザインについての講座を特別プレゼント。

■音声1:粘りについて
ゲームにハマりを生み出す要素「粘り」を入れる方法とは?
あなたの作るゲームにも「粘り」を取り入れよう。

■音声2:インパクトについて
 ヒットゲームのトリガーとなっている「インパクト」の作り方とは?
「インパクト」を取り入れて、あなたのゲームにヒットの可能性を埋め込もう。

■ほかにもこんな内容を音声でお届けします
・練り上げられたゲームデザインをする秘訣
・間違いのない面白さのコアを盛り込む方法
・ゲームがヒットする原因を盛り込む方法
etc.

■サンプル音声、登録はこちらから。



トラックバック(0)

このブログ記事を参照しているブログ一覧: 仕様書の書き方-番外編-

このブログ記事に対するトラックバックURL: http://n2-interactive.com/mt/mt-tb.cgi/159

コメントする

[[img(http://x8.mikosi.com/bin/ll?095447901)]] [http://x8.mikosi.com/bin/gg?095447901 アクセス解析]