ゲーム会社のスマホアプリ開発日誌 12 ~基本ルールの作成~

モンハン買いました。

がんばりますが、みんなに追いつくのは無理なんだろうと思うとモチベーション維持を何ししたらよいのか悩みます。

「4はあんまり遊んでなかったから300時間くらいかな」

とかそんな話がゾロゾロでるゲームって何なんですか?と思います(半泣

大作RPGだってプレイ時間二桁ですよ?

仕様の共通ルールを作る

仕様書を作る上で、最初に共通ルールを作ります。

今回作っている仕様書の中からボタン表示の例をあげます。

201410160.jpg

ボタンの表示、挙動ルール

基本ルールを作る理由

  • 仕様を書く分量が減る
  • 実制作担当者が楽になる
  • 根本的なルール変更があった時に修正が楽
  • ゲーム全体の統一感がもてる
  • ユーザーフレンドリーになる

とかそんな所です。

仕様を書く分量が減る

各仕様の挙動をいちいち1から10まで書くとすごい分量になりますし、実制作担当者も全部読まなければならないので工数が結構な量になってしまいます。

最初に基本的な所を設定する事で7から10くらいを書けば良いとなれば、随分楽になります。

実制作担当者が楽になる

各仕様で書いてない所は基本ルールに準拠すればいいので、ある程度不明な点についてはルールに基づいて作れば良いとするので制作が楽になります。

プランナーに質問する時も「基本ルールでOK?」とか「基本ルールとの違いは何?」とかそんな感じで質問のよりどころからあるので質問もしやすいです。

もし仮に全てのボタンの仕様について1から10まで書いてある仕様書があったとして、仮に一部仕様書いてないものがあった場合は、その都度プランナーに質問をしなければならなくなりますので、大変面倒です。

それに同じ内容が随所に重複して書かれているので、分量は多いし読むのも大変だし、違いを探さなければならないしで、手間は増えるわミスは増えるわですったもんだになります。

根本的なルール変更があった時に修正が楽

作業担当者は最初に基本ルールに基づいた仕様の作業環境を作ります。

グラフィッカーさんはレイヤー設計やパレット、テクスチャーの設定とかをしておけます。

プログラマーさんはクラス設計やネーミング、具体的なデータ処理について設計しておけます。

根本的な仕様変更がもしあったとしても、最初に設定した箇所を修正する事で各仕様箇所を再帰的に修正する事が可能になります。大方ね。

ゲーム全体の統一感がもてる

グラフィックだけでなく、プログラムの挙動についても全体的な統一感をもたせる事ができるので細かい所での修正がより具体的に行う事ができるようになります。

グラフィックを描く際も新たにデザインする時に基本ルールに準拠して描けば良いので、描く方としては「多分こんなんでいいんだろう」とざっくりとスケッチしても通りやすくなります。ここらへんは世界観設定の効能と同じですね。

ユーザーフレンドリーになる

未だ触った事のない新しいステージにプレイヤーが入っても、プレイヤーは今までのプレイ経験から「多分こうすれば良いんだろう」と推測し、その通りに勧められる事でストレスフリーなプレイが可能になります。

プレイの仕方を試行錯誤する「脱出ゲーム状態」はそれ自体をゲーム性にする場合以外はとてもすすめられたものではないと思います。

基本設定→差分の設計

どんなものでもそうなんですが、基本(デフォルト)設定を作り、各仕様で例外措置や差分仕様の指定をするような作り方を心掛けると良いですね。

「ものによって違う」と言って共通項目の割出を怠ると、ほぼ全員が中身を把握できずにダウンする事になるですね。

例えばバニラアイスとストロベリーアイス、チョコミント

基本レシピは

「卵黄と生クリームと砂糖を凍らせてかき混ぜる」(乱暴)

で、ここから

バニラ「バニラビーンズを入れる」

ストロベリー「いちごシロップ的な何かを入れる」

チョコミント「ミントリキュール的な何かを入れる。あとチョコチップを入れる」

と記述するようになりますです。

201410161.jpg

みたいな形で仕様を構造化するように心がければ、アイス作る時も楽だし新しいもの挑戦する時も

「ああ、うどん入れればOKか」

と想像がつく訳ですよきっと。

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

カテゴリ: