Rails で作る AI vs AI Reversi - ストーリー の続きです。勉強会のメンバーからの案を踏まえ、API仕様書0.1版を作りました。ひとまず公開します。
コメント等々いただければと思います。
モデルを再設計しなければぁ。
Rails で作る AI vs AI Reversi - ストーリー の続きです。勉強会のメンバーからの案を踏まえ、API仕様書0.1版を作りました。ひとまず公開します。
コメント等々いただければと思います。
モデルを再設計しなければぁ。
昨日(Rails で作る AI vs AI Reversi - モデル設計)の続きです。今日はストーリー(ユースケース)について。
クライアントにあたる Reversi AI は、 おそらくバッチ的なプログラムになるでしょう。その場合、実際のリバーシのアルゴリズム以外に、どうやって対戦相手を見つけるか・前述の Game をどうやって生成するか、などが問題になります。プレイヤーにはアルゴリズムのプログラミングに集中してもらいたいため、「ゲームの生成・対戦相手を見つける・対戦結果を見る」などは、Webサイト上で提供しようと考えています。
それを踏まえた上で考えたストーリーです。
前準備
Web サイトにて
自分の PC にて
Web サイトにて
いかがでしょうか。最後に見たのは数年前だけど、「対戦相手を待つ」あたりは、ハンゲっぽいのをイメージしてます。
自分の PC にて
どうしよっかなぁ。(結構楽しんでる
)
昨日(Rails で作る AI vs AI Reversi - 経緯とコンセプト)の続きです。今日はモデル設計について。

いろいろ悩んだんですが今日時点では、こんな感じで考えてます。こんな感じと言っても、わけわかんないかもしれないので簡単に説明します。
2008/7/22 更新: 詳細に書いても変更になった時に困るのでポイントだけ書きます。
Board モデルが盤上の石の座標を二次元配列で持っています。
Log モデルが1手目から status(パスか黒が打ったか白が打ったか)と、打たれた座標、ひっくり返った石の座標の配列を持っています。
Log モデルは、Webサイト上でFlash などで視覚的に対戦状況を見ることができる、Reversiビューアのために作ったモデルです。
Logモデルを現在の手数+1をポーリングで監視して、更新があれば描画する、みたいな AS を書けばビューアは簡単に作れるんじゃないかなぁと思ってます。
以上。
OSC2008Nagoya に、我らが勉強会 CSNagoya が参加するのは決まってたんだけど、出し物として「Haskell で作る Twitter」って考えてたんですが、どうも「ふーん」で終わってしまいそうなので、「雑談で話していた AI Reversi をやりたいっす><」と自己主張したところ、「いいんじゃない、頑張って!」ということで、草案(発案者の方のアイデアをそのまま)投下。なんだか「gabu ちゃん一人で頑張ってw」的な空気が漂ってるんですが、いじめですかねw
というようなコンセプトです。
クライアントとゲームサーバは http 通信を基本として、できるだけ RESTful な API を公開することを考えています。(Restful な API って日本語あやしいな・・・)
つまり! http 通信できるなら、どんなプログラミング言語でも参加 OK!
その点が、OSC のオープンソースに引っかかるという名目で進みます。いいですよね?勉強会の皆様。
モデルとか必要そうなアクションとか考えてたんですが、眠いので、また明日。おやすみなさいませ。。。
PS. 「たまには普通の話とか子供の話とか書いてくださいよー」と言われてたのに、こんな話でごめんなさい><
いつか必ず書きます><
Recent Comments