ども、皆川＠豆蔵と申します。面白そうな話題なので加わらせてください。
# タイトルを変えさせていただきました。ちょっと長くなってしまいました。
On Mon, 27 May 2002 01:19:21 +0900
Kazuya Maebashi <********@*****.**.**> wrote:
(前略)
> 昔、オブジェクト指向の勉強会みたいなのがありまして、
>
> ・例題として、オセロゲームをオブジェクト指向で実装しよう
> ・どうせやるなら、単にOOPL(このときはJavaだった)で実装するん
> じゃなくて、ちゃんとオブジェクト指向で設計しよう
>
> という方針でやってたようです。
(中略)
ウチでも以前同じような勉強会をやったことがあります(題材もオセロゲーム
そのものでした)。オセロ(を含む各種ゲーム)は一見単純そうに見えますが(実際、
単に動くモノを作ればよいのであれば簡単なんですが)、「どんな事が求められ
るか」によってはどんどん奥が深くなってきます(気を付けないと底なしのモデ
リング地獄(極楽!?)にハマって抜け出られなくなってしまいます)。
オセロを含む一般的な対戦ゲームの場合、それを表現・実現しようとする時に
はいくつか悩ましいところが出てきますね。それらを渾然一体ごちゃ混ぜな状態
でモデリング(分析・設計)しようとすると、その複雑さに振り回されて上手く表
現できなくなってしまいがちです。「悩ましいところ」のいくつかを挙げると…
(1) ゲームの「場」(オセロの場合は盤面)をどのように表現するか？
(2) ゲームが進行していく際のある特定時点での局面をどのように表現するか？
(3) ゲーム固有のルールをどのように表現・適用させるか？
(4) プレイヤとゲームの関係をどう捉え表現するか？
… etc. …
これらのデシジョン・ポイントに対する判断(決定)は「どんなレベルの事まで
要求されているか？」に大きく左右されます(特に再利用・拡張可能性に対する
要求の度合いに影響されます)。
昨年の「OBJECT DAY 2001」でのワークショップ『体験UMLモデリング(※1)』
では "GREED" というサイコロ・ゲームを対象にモデリングを行っていました。
弊社有志チーム(通称「モデ豆」)もこの時参加させていただいたのですが、その
際の参加報告のようなものが『モデ豆奮闘記(※2)』として公開されています(こ
のページには当日発表されたモデルの内容やそれに従って実際にJavaでコーディ
ングされた簡単なプロトタイプなども含まれています)。
※1: 『体験UMLモデリング』
http://www.ogis-ri.co.jp/otc/objday2001/category6.html#W1
※2: 『モデ豆奮闘記』
http://www.mamezou.com/tec/Tips/modeMame/index.html
この時のモデルでは「対象ドメインの{一般化|抽象化|フレームワーク化}によ
る{再利用性|拡張性}の向上」をウリ文句として、そういった側面がいくらか強
調されたようなものになっています。つまり、「対戦型ゲームのためのある程度
一般化されたフレームワーク」を考えて提案しています。このフレームワークは
(おそらく)オセロ・ゲームにもそれほど問題なく適用できるものと思います。
もちろん、この枠組みだけではオセロ・ゲームを実現するには足りないところ
(オセロ固有の部分)がありますが、仮にこのような枠組みが既に存在していてそ
れが広く利用できるのであれば、モデリングや実装は随分楽になりそうです(半
分くらいの労力で済む?)。
# その代わり、この枠組みを最初に創る時には苦労しますが… (-_-;
> 「オセロの盤面を表現したいわけでしょ? だったら、「盤」のクラ
> スを作って、列挙型の2次元配列を持たせりゃいいじゃん」
> (もちろんJavaだから列挙はintで代用する)
(中略)
「普通の」オセロだけを対象とするのであればこれで十分ですね。ですが、深
読みして「三次元オセロ」や「六角オセロ」みたいな「変な」オセロ・ゲームを
作る場合には…なんて事に発想が及んでしまうと、物理的なマス目の配置構造と
論理的なマス目間の隣接関係とを別々に扱う…なんていうアイデアが出てきます。
「石」をクラスにするか否かも、それがマス目の単純な状況を表すためだけに使
われるならば列挙型で十分ですが、ゲームのルールに影響を及ぼすような特殊な
「石」が導入される可能性を考えるとすると状況が変わってきます。
要は、「どこまで一般化・抽象化を進めるともっとも合理的なのか？」という
判断にかかってくるのだと思うのですが、これは本当に難しいことですね。
> オブジェクト指向の入門書などを見ていると、現実世界の「モノ」
> がオブジェクトだとか、要求仕様から名詞を拾えとか書いてあります。
>
> 普通、オセロの「石」をクラスにすることはないと思うのですが、
> これはどう見たって『現実世界の「モノ」』です。要求仕様の名詞
> です。石のクラスを作って途方にくれてた人を笑うことはできません。
>
> もちろん、理屈を言えば、「石」はあくまで盤面のひとつのマスの
> 状態を表現するための道具に過ぎません。五目並べなら私も方眼紙で
> やったことありますし、オセロだって消しゴムがあればできるでしょう
> (大変だけど)。だから「石」はオブジェクトじゃない、と言うこと
> はできますが、果たしてそれが自然かどうか。
{入門書|教科書}的な本には(良いところもありますが)機械的にできるかのよ
うな誤解を招いてしまいがちな記述も結構多いですね。現実世界の「モノ」と似
通った概念をオブジェクトに割り当てるとそこからの類推が効いてモデルが扱い
易くなるのは確かですが、現実世界の「モノ」が必ずオブジェクトの世界の中に
無くてはならないかというと、そうとは限りません。オブジェクトはあくまで仮
想世界の中の「モノ」で、決して現実世界の「モノ」そのものではないという点
に注意しないと大変な混乱状態に陥ってしまうことがあります。
この辺りは 磯田 定宏 さんの論文(※3)など、非常に興味深く読ませていただ
きました。
※3: 「実世界モデル化有害論 - オブジェクト指向モデル化技法の解明」
磯田 定宏, 電子情報通信学会論文誌 D-I Vol.J83-D-I No.9 pp.946-959, 2000年9月
> 「先手プレイヤー」「後手プレイヤー」は、私なら同一クラスの
> 別インスタンスにします。ただし、思考ルーチン付きオセロなら、
> 「プレイヤー」を継承して「人間プレイヤー」「コンピュータプレ
> イヤー」を作ります。でも、オブジェクト指向をかじりかけの人が、
> 「プレイヤー」を継承して「先手プレイヤー」「後手プレイヤー」
> を作るのは、やってしまいがちな話だと思います。
> # 高度な思考ルーチンなら、先手と後手で違うアルゴリズムを使う
> # かもしれませんが... だとしても、継承を使うか?
これは「あるプレイヤーのある特定のゲームに参加する際のロール(役割)」と
して見ることもできそうですね。ロールによって動作が変化するのであれば、そ
のロール部分だけを別階層のクラスとして分離して扱う…などという捉え方もで
きるかもしれません。
> また、「盤」のクラスを作って2次元配列を持たせたとして、その
> 2次元配列は、「現実世界を自然に表現する」のなら、publicでなけ
> ればなりません。現実世界のオセロの盤では、プレイヤーは、
> どこでも好きなところに石を置けるからです。もちろんオセロの
> ルールではダメですが、ルールを知ってる「盤」なんて、現実世界
> では見たことありません。
>
> 「奇妙なクラスと実世界」
> http://www.ogis-ri.co.jp/otc/hiroba/technical/StrangeClass/
>
> は非常に勉強になりますね。
はい、まったく仰るとおりですね。オブジェクトの世界ではモノが自発的にい
ろいろやってくれるような変な(!?)世界観で構成されていますよね。
# 映画「ハリー・ポッター」に出てきた「魔法使いのチェス」がオブジェクト指
# 向の世界観の中の「チェス盤」にすごく近いように思えます。
> 結局、現実世界の「モノ」がオブジェクトだとか、要求仕様から
> 名詞を拾えとか言われても、混乱するばかりで設計の妨げになる
> 例は多いと思います。
御意。ただ、混乱する事も多いですが、「取っ掛かり」程度の意味付けでやる
には悪くないかもしれません。何にしても利点・欠点があるということでしょう。
--
／|／| ▲ 皆川 誠 ＠ 株式会社 豆蔵
/ ノ / } 「きつねはコンと鳴く」
|// ノ / | 会社用: *******@*******.***
=o=|＼| / 自宅用: ***********@*****.***
く | / 携帯用: ********@******.**.**
■■■■