Index [Article Count Order], [Thread]

Date:  Thu, 11 Jun 1998 02:03:21 +0900
From:  Naruhiko Ogasawara <naruhiko@dino.spdd.ricoh.co.jp>
Subject:  [creator-ml:00051] How to make a "ROBUST" system (Re:  TRPG
 のシステムは作品か)
To:  creator-ml@trpg.net
Message-Id:  <199806101701.AA00702@naruhiko.spdd.ricoh.co.jp>
In-Reply-To:  <199806101450.XAA22101@ro.bekkoame.or.jp>
Posted:  Wed, 10 Jun 1998 10:01:50 -0700
X-Mail-Count: 00051

おがさわら＠火盗改メです。

>　神尾です。

ふたたびこんにちは。


>　しかし、その前にゲームデザイナーとしては自分の考えたことを正確
>に表現できるだけのデザイン能力が要求される、という点で職人的な技
>量もかなり重要だと思っています。
[snip]
>　こういうことはいろんなシステムで起こっていると思いますが、これ
>はプレイヤーの責任と言うよりも、その様になることを制限しなかった、
>制限するためのルールを構築しなかったデザイナーの責任という面が大
>きいと思っています。また、それをプレイヤーの責任として押しつける
>のもデザイナーの甘えだと思っています。

ルールのバグというか限界領域って、現状ではどうしてもあるでしょう。
というか、デザインして一発穴も限界領域もなにもないシステムを作れ
る人がいたら、その人は天才とかそういうのではなくて宇宙人でしょう。

ということで、大事なのは職人的な才能ではなく、バグを作らない、残
さない、という仕組みの方ではないかと思います。


ここのところを、職人的なところがゲームデザインと似てる (と思う)
プログラミングと比べてみようかと。

メーカーにおいてプログラミングした成果物を出荷する際には、バグが
ないことを保証する必要があります。そのための方法として、開発前に
は仕様に抜けが無いか、設計に誤りがないかのレビューを行い、開発後
には仕様に基づいたテストを行います。これらは社内で決まっている標
準 (ISO などの国際標準をローカルにしたもの) に基づいて行われます。

レビューの場合は指摘項目が規定件数以上でなければならず、そのなか
で致命的な指摘があった場合はやり直しになります。そうでない場合は
指摘事項を修整し、他者が修整を確認して初めて OK となります。レビ
ュー通過前にコーディングに着手してはいけません (タテマエは ^^;)。

テストの場合は規定時間以上を行って、その間の障害発生率が何％以下
で、すべての障害が除去されるか、残っているものがシリアスでないと
判断されて、初めて出荷されます。

ソフト開発は職人的だといわれますし、実際、現場にいる私もそう思い
ます。しかし、職人的な技量がそのまま表に出ないような工夫がされて
いるわけです。商品なんですから当然ですよね。


ゲームデザインについてもこのような基準があれば、デザイナーの才能
に頼らなくても堅牢なシステムは作れると思いますし、そのほうが健全
だと思います。

ということで、皆さんはルールシステムの堅牢性を高めるための工夫を
なにかされているでしょうか？

かくいう私のところは：

・(いわゆる) テストプレイ……回数が不足気味 (--;)
・ローカル ML に流してのレビュー
  ……明確な基準が無いので漫然と読んでしまいがち
・キャラクターメイキングの簡単な計算機シミュレーション
  ……テストできる項目が非常にかぎられる

程度のことしかやっていないのですが。
レビューの標準みたいなものはできれば作りたいなぁと思ってるんです
けどね。前述のソフト仕様の標準のパクリで行けそうだし、あると便利
そうだし。

それでは。

-- 
おがさわらなるひこ＠火盗改メ
ネットワーク広報係
http://hiden.cup.com/