Goto (creator-ml ML) HTML Log homepage
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/