Article 55 at 98/06/11 08:41:33 <br>From: naruhiko@dino.spdd.ricoh.co.jp<br> Subject: [creator-ml:00055] Re: How to make a "ROBUST" system

Index [Article Count Order], [Thread]
Date:  Thu, 11 Jun 1998 08:41:33 +0900
From:  Naruhiko Ogasawara <naruhiko@dino.spdd.ricoh.co.jp>
Subject:  [creator-ml:00055] Re: How to make a "ROBUST" system
To:  creator-ml@trpg.net
Message-Id:  <199806102339.AA00706@naruhiko.spdd.ricoh.co.jp>
In-Reply-To:  <9806102244.AA18214@aladdin.cs.inf.shizuoka.ac.jp>
Posted:  Wed, 10 Jun 1998 16:39:58 -0700
X-Mail-Count: 00055

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

>	小林＠静大です。

こんにちは。

>    ちょっと疑問に思うことが有ります。
>ソフトウェアの場合、関数などの入出力関係がきっちりしているか、
>ロジックに問題が無いかというあたりに問題が集約できると思うんですが、
>RPGの場合は大丈夫なんでしょうか?

はは、ばれてしまいましたか。
実はそこのところがケッコウ問題なわけで、書いてるうちに
困ってしまったのですがえいやと投げてしまいました。


>    仮に一種の機能単位ということで、技能をソフトウェアの関数に
>対応させて考えてみますが、ソフトウェアの場合だと、その関数なり
>なんなりが処理できる範囲の数値など以外のものが与えられた場合は、
>そのチェックをすれば良いわけです。ですから、通常処理 (もちろん、
>こちらのロジックに問題が無いことが前提となりますが)と例外処理と
>いう2分類で考えられるものと思います。
>しかし「シチュエーション」に関してそれが可能でしょうか?
>可能であれば良いんですが、可能でないとかあるいは難しいとなると、
>個々のシチュエーションを数え挙げていくことになると思いますが、
>それは可能でしょうか?

ちょっと引用長くてゴメンナサイ。
うーん、そこまで厳密な応用は正直言って考えていませんでした。
私が 00051 で主張した：
---------------------------------------------------------
ゲームデザインについてもこのような基準があれば、デザイナーの才能
に頼らなくても堅牢なシステムは作れると思いますし、そのほうが健全
だと思います。
---------------------------------------------------------
の「このような」は、じつのところ具体的なアイディアがあったわけ
ではなくて、実際の制作工程を標準で規定することによって品質の
一定化を図る、という方法論を、ゲームデザインでも応用できないかな？
という程度のものだったわけです。

その主眼は、デザイナーの才能にすべてを依存するのは (プロダクツ
として) 不健全だという考えなんですけどね。

でも、RPG システムをモデル化してプログラムのモジュールのように
検証するというのも面白いですね。ちょっと時間が取れたら考えを
まとめてみたいと思います。


>    あぁ、こうなると A.I. が出ていてくれれば、何かヒントになった
>かもしれませんねぇ。ほら、ファジーでOOなRPGシステムって言ってた
>から、OOな設計手法あたりをRPGに適用する参考になったかも...
>見たかったなぁ...

確かに。期待してたのに。残念ですねぇ……。
しかし、対象とするドメインの Object Oriented Analysis を
もとに RPG システムを構築するとか、OOA のいい題材になるよう
な気がします。整理していけば面白い RPG システムデザイン論に
なるカモ。

んで、それを仕様記述言語で記述して自動仕様チェッカにかけて
検証するとか、いい卒業研究の題材になりそうですね (^^)


>    結局のところはテストプレイしか、現状では無いと思います。
>簡単なミスなどは読んでもらうだけで見付かることも有りますけども。
>で、テストプレイに関しては回数もさることながら、環境というか
>条件も大事ではないかということを X-Mail-Count: 00053 に書きました。

そうですね。テストプレイが一番であることは私も認めます。
でも、テストプレイといっても、ただ漫然とプレイしている
だけでは何度やっても堅牢性は得られるか疑問です。
テストプレイヤーの質に頼っているようではやはり原始的ですよね。

そいで、ルールの読み込みやテストプレイに、レビュー (この
「レビュー」という言葉は下記に述べる通りです) 標準みたいな
ものを使えたらなぁというのが私のアイディアなわけで。


>    ただ仕様記述のやつでいけるでしょうか? 仮にRPGの作成時の検証には
>使えたとしても、いわゆるクリーン・ルームであることを保証するのと
>レビューとではかなり目的が違うような気がするのですが。

あー、レビューという言葉が誤解を生んだかな？  すみません。
ここでいうレビューはいわゆるデザインレビューという奴で、
設計の分野で言う機能仕様や設計仕様の正当性をチェックする
ためのものです。

んで、レビュー標準という奴は大体：

・レビューに呼ぶべき人   (企画・設計・販売など)
・レビューを監督すべき人 (設計者本人はダメ)
・チェックポイントと指摘事項のランク規定
  (致命的な欠陥はＡランク、誤字脱字はＣランクなど)
・レビューの合否判定基準
  (指摘事項ｘ件以上、うちＡランクは０であること、など)

みたいなことが決まってるわけです。


だから RPG の場合は次のようなプロセスを踏むことにして、

+-+->デザイン作業
| |       V
| |   [レビュー]       レビュー標準
| |       V
| +-----判定
|         V
|    [テストプレイ]    テストプレイ標準
|         V
+-------判定
          V
        完成

んで、たとえばテストプレイ標準では：

・テストプレイに呼ぶべき人 (なるべく広く)
・テストプレイのゲームマスター (たとえばデザイナー以外とか)
・チェックポイントと指摘事項のランク規定
・テストの合否判定基準

などを決めて、そのテストプレイが果たして有効なものであるか
点数を付けて評価する、なんてのはどうでしょう？


あとメーカーの商品テストの場合は：

・設計者テスト   (作った本人)
・設計部門テスト (作った本人が所属する部門のテストスタッフ)
・商品テスト     (テスト専門のスタッフ)

の三段階に分けて行います (少なくとも ISO の標準では)。
だからテストプレイも：

・デザイン集団内でのプレイ
・GM はデザイン集団から出すがプレイヤーは部外者
・全員 (GM も含めて) 部外者

までやった方がいいんでしょうけど、三番目まではなかなか
難しいですね (^^;)


それでは。

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