おまいら最強の麻雀プ ..
717:デフォルトの名無しさん
08/09/26 00:38:08
ふむふむ、だったらオープンリーチの対応もおねがいします。
718:デフォルトの名無しさん
08/09/26 00:38:32
>>711
あーそうか。
全員がAI作成を最終目標にしてると思い込んでたから、>>710とか書いてしまったが、
例えばプロトコルだけ考える人ってのがいてもいいわけか。
>>632さんはどこまで自分で実装する予定なんかな？
719:デフォルトの名無しさん
08/09/26 01:21:11
確かに棒聴即立で立直にベタオリだと立直時ツモ和了率六割越すけどプンリー有りは微妙・・・
720:632
08/09/26 01:30:50
>>717
オープンリーチ好きな人が多いなw
同じ人？
とりあえず仕様に追加しました。
>>718
自分としては、プロトコルの策定＆サーバプロセスの実装、
テスト用クライアントの作成まではやるつもりです。
できればWindows版のクライアントを作ってくれる人が
現れてくれると、すごく嬉しいです(^^
721:デフォルトの名無しさん
08/09/26 01:49:13
確かに棒聴即立で立直にベタオリだと立直時ツモ和了率六割越すけどプンリー有りは微妙・・・
722:デフォルトの名無しさん
08/09/26 02:32:33
>>720
オープンリーチは待ちのわかる牌だけ晒すルールもあるので、
晒す牌の選択はクライアント側ではないかと。
プロトコルが対応してないから採用出来ないルール、ってのは
出来るだけ無い方がいいでしょ？
723:デフォルトの名無しさん
08/09/26 02:37:48
>>722
サーバーは待ちのわかる牌を自動判別出来るはずだから、サーバーが決めるんでいいじゃん。
724:632
08/09/26 02:38:05
>>722
んにゃ、全部晒すかどうかもサーバ側で決定します。
どうせサーバ側では不正をチェックしなければいけないので。
一部だけ晒せばOK、というルールのサーバのときに、
すべての手牌を晒したい、というときには問題になりますが、
それに対応する必要性は感じないんですが、どうでしょうか。
725:デフォルトの名無しさん
08/09/26 02:54:15
たとえば、２３４５６と持っていて５６を晒してオープンリーチ、ってのが許されるルールはありか？
とかいう話かな。
もちろん、４，７のツモ上がり前提で。
726:デフォルトの名無しさん
08/09/26 03:31:50
>>724
>それに対応する必要性は感じないんですが、どうでしょうか。
プレーヤーにとって意味ある事かどうかは、
プロトコル側では関知しないっていうポリシー
だと思ってたけど、違った？
727:デフォルトの名無しさん
08/09/26 07:28:21
まずはルールはこれでいいだろう
URLﾘﾝｸ(act0.net)
728:デフォルトの名無しさん
08/09/26 22:13:05
>>632
open<プレイヤー><手牌>で手牌全部見せたときと
鳴いた面子だけ見せたときのコマンドが一緒になると
クライアント側で牌の数チェックする手間がでるんで
手牌か面子(ポン･チー/カン)かのフラグが欲しいです
729:デフォルトの名無しさん
08/09/26 22:23:48
情報にはノイズ乗せないの？
730:デフォルトの名無しさん
08/09/26 22:52:12
打牌に制限時間設けないとひたすらぶん回し続けるAIが出てくる予感
一秒制限の早差し勝負とかもやってみたい
731:デフォルトの名無しさん
08/09/26 23:36:33
通信が遅れる可能性は十分考えられるので
サーバ・クライアント共に何回目のackかを示す情報も必要かも
732:632
08/09/27 15:12:38
>>725
さすがにそんなルールは聞いたことないですが、もしかしたら
1が枯れている場合はOKとかはあるかもしれません。
>>726
おっしゃる通りです(^^;
ということで、とりあえずopenrichiコマンドに晒したい部分の手牌も
指定できるよう仕様に追加しました。
733:632
08/09/27 15:13:04
>>728
openの手牌は、手牌の表記に則るので、
和了ったときは open A 1m2m3m4p5p6p7s8s9s1z1z1z2z2z
ポンのときは open A <3m3m3m>
チーのときは open A <1p2p3p>
暗槓は open A (8s8s8s8s)
となるので、クライアントでも容易に区別できると思います。
>>729
ノイズって、どういうことでしょうか？
734:632
08/09/27 15:17:57
>>730
実際に運用するとなると、時間制限は必要になると思いますが、
実験段階では、ひたすらぶん回して、それこそ1打1時間とかかけたとしても
本当に強いAIが出てくるなら、それはそれで面白いんじゃないでしょうか。
>>731
コマンド形式のところにある<センテンスID>というのがそれです。
ちなみに、最初はサーバから1コマンド送るごとに必ずクライアントの
ack(okコマンド)を待っていたのですが、実装してるうちに不要な気が
してきたので、必要なとき以外はクライアントからの返答を待たない
ようにしました。
735:デフォルトの名無しさん
08/09/27 15:21:19
1打1時間掛かったら強いことが調べられない
736:デフォルトの名無しさん
08/09/27 15:33:13
>>632
をを、プロトコルが強化されてる、乙かれ。
737:632
08/09/27 15:37:46
>>735
人間相手だと、さすがに人間の方が耐えられないだろうけど、
AI同士なら別に1打1時間かかるのもアリじゃない？
まあでも実際、将棋や囲碁に比べれば、麻雀はプレイヤーの
できることが少ないから、さすがに1打1時間はないと思うけど。
>>736
実装しながらなので、随時変更してってます(^^;
738:632
08/09/27 15:39:46
ちなみに、開発途中ではありますが、ソースコードをSourceForgeの
SVNに随時commitしているので、興味のある方は
URLﾘﾝｸ(svn.sourceforge.jp)
から拾って下さい。
739:デフォルトの名無しさん
08/09/27 15:47:07
AIどおしでも1時間は無いよ。 たとえば一手3秒以内で1日中動かして統計を取ったとする。
これを一手1時間以内でやったら、同じ回数をこなすには1200日掛かることになる。
3年以上掛けてパソコンを動かさなければ強さが判らない。
740:デフォルトの名無しさん
08/09/27 15:51:03
PC1台で検証するならそうだな
741:デフォルトの名無しさん
08/09/27 15:51:27
PCの性能で応答時間は異なるけど、一つが遅ければ全体に影響するから
平均応答時間程度にするとかにして、時間切れはツモぎりとかのほうがいいとはおもう。
742:632
08/09/27 15:58:26
実際に色々なAI同士を戦わせてみよう！となったら、
麻雀のルールの他にも決めなければいけないことは
あると思います。
それこそ制限時間とか、あるいは鳴くかどうかのラグを
情報として使うのはアリか、とか、相手のAIの傾向を
「最初から」入れておくのはアリか…等々。
いうなれば大会のルールみたいなものですね。
743:デフォルトの名無しさん
08/09/27 16:06:22
一手に３秒もかかったら、まともな統計は取れないですね
744:デフォルトの名無しさん
08/09/27 18:55:36
>>729
733のいうノイズは、おそらく意図的な情報伝達ミスだろう
麻雀でいうなら見間違いとか切り間違いとか
ゲーム理論の研究ならノイズも必要だけど、麻雀サーバには無用な仕様だよね
745:デフォルトの名無しさん
08/09/27 19:06:32
ルールは実在ルールの中でもＡＩにとって処理しやすいものが良いと思う。
746:デフォルトの名無しさん
08/09/27 20:24:35
>744
エラー処理あるいはテスト仕様としては必要かも知れないよ。
つまりクライアントやサーバーが全く期待していない
矛盾した情報を受け取った時に何を返すべきか？
意味不明だと単にエラーを返すか、通信にリトライを要求するか？
そこまで仕様として決めておくのは面倒ではあるが、
下手をすると一回の通信エラーで全体が一気に倒れかねない。
747:デフォルトの名無しさん
08/09/27 21:00:00
今の仕様だと誤ポンも誤ロンもサーバが無視なのか・・・
クライアントが矛盾したロンやリーチしたら
それはそういうときの処理をした方がいいのでは？
748:デフォルトの名無しさん
08/09/27 21:28:36
ルールとプロトコルが直行するように決めるなら
ダブロンとかの扱いもちゃんとしておかないと
749:デフォルトの名無しさん
08/09/27 21:50:04
「コンピュータ麻雀のアルゴリズム」なんて本が出てるんですね。
Amazonのおすすめに出てきて驚きました。
750:デフォルトの名無しさん
08/09/27 22:44:26
>>747
誤ロン誤ツモはチョンボだろ
ノーテンリーチはかけられるようにしとかないと
戦略の幅が狭まる
751:632
08/09/27 23:31:05
>>747
自分の考えでは、誤ポンや誤ロンは、麻雀とってはまったく
不要な要素だと思っています。
極端な話、山を崩すのとたいして変わらないくらいで、
コンピュータ上で麻雀を打つなら、発生させないように
するのがベストではないでしょうか。
ただ、>>750の言う通り、ノーテンリーチについては戦術として
考えることもできるので、それは悩ましいところです。
>>748
一応現状のプロトコルの仕様でもダブロンは発生させることが
できると思います。
ただ、自分が作るサーバの実装では入れるつもりはありません。
752:デフォルトの名無しさん
08/09/28 00:57:59
チョンボはありだろ。 役満がほぼ出るならチョンボして流すという手もあり得る
753:デフォルトの名無しさん
08/09/28 09:53:14
なら、>>752 がチョンボあり版を作ればいいじゃない
754:デフォルトの名無しさん
08/09/28 15:00:06
>>751
極端な話、その仕様だとクライアント制作者は和了判定を素っ飛ばして
とりあえず毎回サーバに和了コマンド送信する処理でもいいことになる
まあ毎回でなくとも形聴取ったなら海底河底で一応和了っておけみたいな
錯和が不要という考えは分かるけど何かしら対策はした方が良さ気
755:デフォルトの名無しさん
08/09/29 02:02:32
そもそもサーバにそういった情報も問い合わせられるようにするなら
そんな心配は無用
756:デフォルトの名無しさん
08/09/29 14:42:31
URLﾘﾝｸ(ouc.daishodai.ac.jp)
これの麻雀研究特集号を読んだ人いますか？ どんな内容でしたか？
「麻雀のベストプレイは存在するか」が気になる
757:デフォルトの名無しさん
08/09/29 20:24:53
鳴きのアルゴリズムって、基本的に
鳴いた場合の期待値 ＞ 鳴かない場合の期待値
の時に鳴くって考え方でおk？
758:デフォルトの名無しさん
08/09/29 20:28:24
>>757
一発消しだったり、自分が上がれる確率まで含めての期待値だったり
759:デフォルトの名無しさん
08/09/29 21:13:42
>>757
ま、どんなときでも期待値の高い選択をすればそれでいいわけで、
期待値が計算出来ないってのが問題ということです。
URLﾘﾝｸ(www.ara3.net)
760:632
08/09/29 23:46:31
>>754
> その仕様だとクライアント制作者は和了判定を素っ飛ばして
> とりあえず毎回サーバに和了コマンド送信する処理でもいいことになる
別にそれでも全然構わないと思ってるんですが、問題あるでしょうか？
761:デフォルトの名無しさん
08/09/30 01:27:00
ある
そんなのは麻雀AIじゃない
762:デフォルトの名無しさん
08/09/30 01:31:02
二歩を指した将棋AIが負けを宣言されるとするならば
誤ロンした麻雀AIはチョンボを取られるべきだ
なぜなら、それが麻雀というゲームのルールだから
763:632
08/09/30 01:48:11
>>762
将棋の場合は二人なので、片方に対するペナルティは、
必ず対戦相手の利益になりますが、4人で打つ麻雀の場合、
あるプレイヤーに対するペナルティが、他の3人に対して公平で
ないのが問題です。
そう考えると、可能な限りペナルティが発生しないというのが
理想だと自分は思います。
764:デフォルトの名無しさん
08/09/30 01:56:28
>>760
抜け道があると「UMPでは最強かも知れないけれど〜」みたいな
グタグタな流れになるので、できれば対策して頂きたいです
錯和してるのに続行は問題なんで、和了放棄とか特別ルールはどうですか？
765:デフォルトの名無しさん
08/09/30 02:04:15
>あるプレイヤーに対するペナルティが、他の3人に対して公平でないのが問題です。
チョンボは親子関係なく3000オールって雀荘もありますけど、それでどうですか？
766:デフォルトの名無しさん
08/09/30 02:10:18
標的が和了するのを阻止するためだけに
わざとチョンボされるかもしれない問題ってのも
考えられるからルール設定の扱いにしては？
有効、無効はサーバ側で決定
局or半荘開始時にサーバからクライアントに送信される形で
767:デフォルトの名無しさん
08/09/30 02:16:02
補足しておく
ハコテンで半荘終了であるとする
ある局で特定のクライアントがトップ目であるとき
チョンボクライアントが常にチョンボすることで
半荘のトップ目をとらせるという戦略が考えられるなぁと
768:632
08/09/30 03:29:23
チョンボについて意見が多く、それに対して自分の見解をまとめて
みたんですが、あまりに長文になってしまったので
URLﾘﾝｸ(sourceforge.jp)
に書いておきました。
769:632
08/09/30 03:37:16
ちょっと書き逃げみたいになっちゃいましたが、自分としてはまず、
UMPでのサーバ/クライアントで麻雀を打てるようにする、というのが
第一にあります。
その次に、チョンボも含めたルールとか、あるいは実際にどこかにサーバを
立てるのか、どう運用するのかということを考えなければいけないと
思いますが、現状その段階についてはあまり具体的に考えていません。
# 正直、チョンボ云々より、実際サーバプログラムを作ったとして、どこで
# 動かしたら良いかの方が悩みです(^^;
もちろん議論自体は活発に行われるのは良いことだと思いますが、
とりあえず自分の現状のスタンスを表明しておきたかったのです。
770:デフォルトの名無しさん
08/09/30 18:59:55
まあテスト用のサーバとしてうちで提供してもいいよ。
RDBMSを積極的に使ったシステムがいいなあ。
771:デフォルトの名無しさん
08/10/01 00:31:11
つかさ、
チョンボの有無
ハコテンの有無
ノーテンリーチ、オープンリーチの有無
パオの有無
等など、、、
そんなのパーラメータ化して、サーバごとで管理できるようしろよｗ
2chだって"SETTING.TXT"で、板ごとの要求に合わせて
設定されてるんだし、ちゃんと参考にしとけよ
URLﾘﾝｸ(kobe.cool.ne.jp)
sourceforge.jpで新しいプロトコルの作成を目指すなら、
それくらいの気のきいた仕様をちゃんと考えてからにしとけ
772:デフォルトの名無しさん
08/10/01 00:38:37
>>771
基本姿勢が決まってないととりあえず動かすためのクライアントを作るのが難しいぞ
773:デフォルトの名無しさん
08/10/01 01:11:34
一番言いたいことは、個人で採用したいルールはサーバー側では
簡単に定義できるような柔軟なプロトコル仕様であって欲しいということ。
基本段階で決定するような、麻雀のルール決めはサーバ管理者の
裁量に任せればいいが、プロトコルの仕様という話ならば、
どんな特殊なルールであっても、単純に組み込めるようになってないと、
そもそもプロトコルとしての意味が無い
東風荘や麻雀ファイトクラブで採用してないような
オープンリーチやフリテンリーチが固定で組み込
まれているようなプロトコルになるなら、絶対に使わないし、いらねえ
774:632
08/10/01 01:29:12
何度も繰り返しになりますが、UMPでは麻雀自体のルールは定義する
つもりはありません。つまり、「クイタンあり」みたいな情報をUMPでは
流さないで済むように考えています。
クイタンありかなしかはサーバの実装次第で、クライアントの実装では、
クイタンで和了ろうとして、サーバにコマンドを送って初めてわかります。
これだと問題だ！と考える方もいると思いますが、クライアントが人間で
あれば、例えばサーバのHPとかに書いておけば良いし、AIだとしても、
どんなルールにも自動で対応するAIというのは、手間がかかるわりに
難しいので、それを考慮する必要はないと思います。
それこそAIを動かす際のオプションで指定すれば済む話です。
>>771のように、パラメータを受け渡しする方法だと、そのパラメータを
策定しなくてはならず、無数にある麻雀のルールの洗い出しとまとめが
必要になり、それこそ気の利かない仕様だと思います。
775:632
08/10/01 01:31:20
>>770
そう言って下さる方が現れるのを期待していました(^^
もしよろしければ、SourceForgeの方に自分のメアドが
ありますので、そちらにメールを頂けますでしょうか？
776:デフォルトの名無しさん
08/10/01 01:39:01
>>774
了解です。それでいいと思います。
クライアント→サーバ
サーバ→クライアント
で、やり取りされるアクションや情報が全て網羅されることを期待しています。
個人的な要望としては、誰かがロン・ツモで上がったときや流局のときに
手牌を倒したプレーヤの手牌情報は取得できるようにして欲しい。
この手の仕様では、サーバ側が必要とする情報だけしか定義されていなくて、
クライアントからでは情報が取ってこれないということがよくある。
ランダムに吐くログを整形して自分で作りこみをしないといけなかったりする。
それは単純化して欲しい。
777:デフォルトの名無しさん
08/10/01 01:46:22
何度も繰り返しになりますが、UMPでは麻雀自体のルールは定義する
つもりはありません。つまり、「クイタンあり」みたいな情報をUMPでは
流さないで済むように考えています。
クイタンありかなしかはサーバの実装次第で、クライアントの実装では、
クイタンで和了ろうとして、サーバにコマンドを送って初めてわかります。
↑ ↑ ↑
この文章を整形して、フロントページの前提に書いた方がいいんじゃね？
このプロトコルのコンセプトがはっきりして、初めて来た人にも分りやすい
URLﾘﾝｸ(sourceforge.jp)
778:デフォルトの名無しさん
08/10/01 01:55:46
実装無ければ無意味。 まずは実装(サンプル)をうpしてほすい
779:632
08/10/01 02:43:52
>>777
FrontPageに>>776さんの「アクションや情報が〜」の言葉も頂いて
追加しておきました。
>>776
現状の仕様では、和了ったときには
say <プレイヤー> ron または tsumo
open <プレイヤー> <手牌>
agari <プレイヤー>
の順にクライアントに送られます。
流局のときには、
ryukyoku
の後に親から順に
open <プレイヤー> <手牌> もしくは
close <プレイヤー>
が送られてきます。
手牌の公開をすべてopenコマンドに統一したので、逆にわかりにくくなって
しまったかもしれません。
コマンドの定義とは別に、本来はこういうフローも定義しないといけないんですが、
まだまとめきれていません(^^;
780:632
08/10/01 02:46:58
>>778
まさにその通りで、実際に動作する実装があれば、もうちょっと
具体的な話もできるようになるんですが、現在鋭意制作中で
ございます(^^;
前にも書きましたが、ソースは随時SourceForgeのリポジトリに
commitしているので、興味のある方は参照して下さい。
でもできるだけ早く、ある程度のものをリリースしたいとは思っています。
781:デフォルトの名無しさん
08/10/01 12:48:43
ちょっと見たけど、牌は全てユニークなIDでやり取りしたいなあ、16進で2桁で済むでしょ？
あと、進行は全て実際と同じようにサイコロ2回振って山のどこから切り出すとか、
サイコロの出目も含めて記録したい。
山を提供するだけ、サイコロを提供するだけ、それらのやり取りを全て記録し、牌譜が出せるやつまで
別に持っていたいのだけど。（ここでDB使う）
782:デフォルトの名無しさん
08/10/01 17:21:30
第三者から見ると有る程度動く物が出来てからじゃないと無意味な議論を重ねてるようにしか見えないのだが？
どうせ鋭意制作中とか言っても完成まじかで「本業or学校or卒論等が忙しくなり・・・」で結局完成しない良くあるパターンに陥るのがみえみえ。
少しは完成させてからでも遅くは無いと思うんですが、どうなんでしょうかそんへん？
783:デフォルトの名無しさん
08/10/01 17:24:05
SourceForgeにあがったコード見ながら、サーバで試しに動かしながらレスしてるのだけど。
784:デフォルトの名無しさん
08/10/01 18:45:22
>>774
>クイタンありかなしかはサーバの実装次第で、クライアントの実装では、
>クイタンで和了ろうとして、サーバにコマンドを送って初めてわかります。
え、事前にサーバーにルールを問い合わせたりできないの？
785:デフォルトの名無しさん
08/10/01 18:56:16
ルールのすり合わせの方法とかは必要なら追加になるだろうね。
AI前提だと、先にルールがある気がしないでもないが。
786:デフォルトの名無しさん
08/10/01 23:04:37
ルールはその卓に固有のものなんだから
HELLOコマンドに乗せて最初に通達されるもんじゃないだろうか
実際の卓でも初めて打つ人とはレートとか先付けとか確認しておくよね
787:632
08/10/02 00:07:47
>>784-786
自分の考えは>>774に書いた通りで、ルールをサーバとクライントで
通信に乗せてやりとりする必要はないと思っています。
もしそれで問題だと思うのであれば、具体的な例を示して頂けると
助かります。
ただし、>>786の言うように、helloコマンドである程度の情報を渡すのは
アリかなと思っています。しかし、それに依存したクライアントを作るのは
推奨しません。
788:632
08/10/02 00:13:31
>>781
それぞれの牌にユニークなIDを振るのは、前にスレで提案頂いてから
検討してみましたが、結局止めました。
一番大きな理由は、牌の表記を現状の'1m'とかから変更するのに
良い案が浮かばなかったからです。
別に可読性は気にする必要はないのかもしれませんが、一応telnetでも
クライアントと成り得るのを目指していたので(^^;
サイの目に関しては、まったく意味がないので外していたんですが、
割れ目などを実装する際に必要になるのでUMPに追加しました。
それ以外のDBを使うという部分は、ちょっとイメージが良くわかなかったの
ですが、UMPというよりサーバの実装の話であれば、どうとでも対応できる
と思います。
789:デフォルトの名無しさん
08/10/02 00:31:21
コマンド一覧を眺めて、何点か気になる点があったので、
指摘事項を記載。
■「naku?」アクション後のリアクションについて
あるプレーヤーが捨牌後、残りのプレーヤーに対して
「naku?」コマンドが送信されるが、仮に3人とも「no」だった
場合に、現行の仕様では何もコマンドが返されない。
一応、3人とも「no」だった場合は、例えば
say 0 noact
みたいなコマンドは発行した方が良いのでは？
すると、クライアント側では以下のような動きになるが
どうだろうか？
sutehai?→自家捨牌(sute)→リアクション無し(say no)→下家捨牌(sutehai)→naku?
→鳴かない(no)→リアクション無し(say no)→対面捨牌(sutehai)→naku?
790:632
08/10/02 00:35:59
>>789
具体的な指摘、嬉しいです！
その状況では、noactの代わりに、他家のtsumoコマンドが送られる想定です。
つまり、tsumoコマンドは自分がツモった場合でも、他家がツモった場合でも
全員に送られます。
ちなみに鳴きの処理はまだ全く手つかずなので、実装していくうちに変更に
なる可能性もあります。
791:デフォルトの名無しさん
08/10/02 00:37:05
■他家の長考時について
「naku?」コマンド発行したタイミングで、2人はリプライが
あったが、残る1人からのリプライが無かったときに、
リプライを返した2人はサーバからの応答が無いまま
ずっと待っていることになる。
サーバは長考しているプレーヤーに対して、再度「naku?」
コマンドを発行して催促すると同時に、残りのプレーヤーには、
wait <プレイヤー>
というコマンドを発行して、今1人長考に入っていますと、
知らせてみてはどうだろうか？
792:デフォルトの名無しさん
08/10/02 00:46:45
「コマンド一覧」を眺めていて、自分の中で仕様を考えてるうちに、
単純化されたシステムを構築したいなら、CGIで十分だなと思えてきた。
とりあえず、サーバー内でタイマーを持たせて、
「10秒以内に返信が無いと、強制ツモ切り」という粗い感じの
仕様なら、そんなに難しくないと思う。
サーバ側から「もしもし捨牌が遅いですよ」と返信が来る様な
優しい仕様としたいなら、サーバとクライアントの双方向で通信
できるようなsocketのサンプルが無いと開発は難しい気がする
793:デフォルトの名無しさん
08/10/02 00:54:44
>>790
了解です。
[鳴き無し]
tsumo <自分> <残り枚数> <牌> →sutehai?→自家捨牌(sute)→tsumo <下家> <残り枚数>→下家捨牌(sutehai)→naku?
→鳴かない(no)→tsumo <下家> <残り枚数>→対面捨牌(sutehai)→naku?
[鳴き有り]
tsumo <自分> <残り枚数> <牌>→sutehai?→自家捨牌(sute)→tsumo <下家> <残り枚数>→下家捨牌(sutehai)→naku?
→鳴かない(no)→say <上家> pon →上家捨牌(sutehai)→naku?
という流れを理解しました。
794:632
08/10/02 01:22:38
>>791
タイムアウトについては大変悩ましいところです。
とりあえず、クライアントから(サーバ時間で)一定時間、返答がなければ
サーバが勝手に進行してしまうというものを考えています。
また、現状の仕様だと誰の返答が遅いのかを、他のクライアントは知る
ことができませんが、これはこれで良いかなと考えています。
795:デフォルトの名無しさん
08/10/02 05:42:54
同じ牌が4枚あるのは気持ち悪いな、、なんとかならないかな。
まあ内部で持つだけでやってみるか。
まったく同じ山でAIだけ差し替えて対戦とかも可能な様にやってるけど、それでいいかな。
すべての対局の山とダイスを記録してるけど、短時間に膨大な量の対戦をやると意味がなくなるかなあ。
796:デフォルトの名無しさん
08/10/02 05:45:18
ネット対戦にするなら、トンプウ荘と繋ぐやつつれば十分では?
あとローカルで高速に動くやつ
797:デフォルトの名無しさん
08/10/02 11:03:37
URLﾘﾝｸ(www.interq.or.jp)
798:デフォルトの名無しさん
08/10/02 11:08:06
人間が混ざる環境だと迷惑では？
あと>>797の利用規約見たけど、AIで使うのは明らかに規約違反だな。
799:デフォルトの名無しさん
08/10/02 11:28:32
個人で強いAIを作ってもそれを公開しなければいい。
>以上は、個人的な研究程度の範疇なら問題ありません
800:デフォルトの名無しさん
08/10/02 11:32:11
MJexeIO.DLLを簡単に利用するためのラッパーを作るだけならいいだろう。
801:デフォルトの名無しさん
08/10/02 11:34:53
公開しないAIをこのスレで議論する意味あんの？
802:デフォルトの名無しさん
08/10/02 11:38:10
Rと名前でわかる
803:デフォルトの名無しさん
08/10/02 17:26:27
カスだな
804:デフォルトの名無しさん
08/10/03 00:18:39
>>787
例に出てるけど、クイタンがあるかどうかは終盤の打ち筋に大きく影響するから、
アガッたときにはじめてわかる、なんて仕様はあり得ないと思う。
予めＡＩはクイタンが認められるかどうかを知っていないと。
それならクイタンありＡＩとクイタンなしＡＩの２つを分けて作れ、って考え方なんだろうけど
初めっから多態性を切り捨てたＡＩなんて面白くないよね。特にム板的には。
というわけで、「採用されている」ルールだけでも通達すべきだと思うんだ。
無数にある「採用されていない」ルールは無視してね。
805:デフォルトの名無しさん
08/10/03 00:20:33
>>788
牌のユニークＩＤがないと赤には対応できないな
'5m'を'5M'にするとかか
806:632
08/10/03 00:28:15
>>804
AIクライアントを起動するときに、オプションで指定すればそれで済むと
思っているんですが、サーバに問い合わせて自動で判別する必要が
あるんでしょうか？
>>805
赤牌は、おっしゃる通りの表記で既に仕様に入ってます。
807:デフォルトの名無しさん
08/10/03 01:39:05
俺が一人で作ってるのとは微妙に仕様が違ってきてるな
いろんな考え方があって面白い
808:デフォルトの名無しさん
08/10/03 02:07:34
>>806
いちいちオプション指定なんて面倒
809:デフォルトの名無しさん
08/10/03 02:11:18
>>806
うっかり１人だけ設定間違えた、ってこともあるはず。
こういうことはしっかり確認を取れるようにしないとトラブルの元。
810:632
08/10/03 02:29:18
>>809
自分はサーバとクライアントでルールをやりとりする方が
トラブルの元だと思っています。
例えば、クイタンありの場合は、サーバからhelloコマンドで
kuitan=1というオプションを渡すようにしましょう。
そしてクライアントはそれに対応しました。
ところが、他のサーバの実装ではkuitan=yesと送ってきました。
これは、サーバが悪いのでしょうか？それともクライアントが対応
すべきでしょうか？
このトラブルを回避するには、ルールを通達する場合の仕様を
決めなければなりません。
そうなると今度は麻雀のルールの多様さが問題になってきます。
ツモっても平和つくの？赤牌は何枚入ってるの？聴牌連荘？
裏ドラはあり？ダブロンは？etc...
「どうせUMPのサーバなんてお前しか作んねーよ。そんな先の
こと考えてんじゃねーよ」
という意見もあるでしょうし、おそらくそれはその通りです(^^;
が、だからこそ自分の正しいと思うように作りたいのです。
811:632
08/10/03 02:50:55
>>807
どこらへんが違うのか、すごく興味があります(^^
812:デフォルトの名無しさん
08/10/03 10:07:24
なんか東風荘の焼きなおしみたいな感じで独自にやる意味が薄くなっちゃったんだよね
813:デフォルトの名無しさん
08/10/03 10:10:23
東風荘のつなぐやつ作ってくれよ
814:デフォルトの名無しさん
08/10/03 11:19:56
>ルールを通達する場合の仕様を
>決めなければなりません。
実装とルールを切り離してるんだから、なにかしらルール定義ファイルがあるんじゃないのかな・・・
それ送っちゃえばいいのに。
マッチメイクサーバーとかが面倒見るのがいい気もするけど。
815:デフォルトの名無しさん
08/10/03 13:44:53
IDE/ATAのIdentifyコマンドみたいに512byteとか
1024byteのパラメータの固まりをやりとりできる
コマンドを準備しておけば良いんでね？
フォーマットの中身は追々、考えるとして。
麻雀のルールは1000パラメータ以上もは無いだろう？
有りそうなら後々、長さを拡張できるようにしておく。
で、サーバーは一方的にルールを通知するだけ。
対応する、しない（できる、できない）は
クライアントの責任とする。
ルールの摺り合わせをするのはさすがに大変そうなので。
816:デフォルトの名無しさん
08/10/03 13:52:13
あとで再現のために、誰がどのバージョンで参加したかのやり取りは必要だからね。
817:デフォルトの名無しさん
08/10/03 14:25:31
じゃ、このルールで参加する、あるいは対応できないから
参加しない、の返事だけはクライアントから返すようにするとか。
その後、参加しているかどうかログ見れば分かるから
あまり意味ないけど。
818:デフォルトの名無しさん
08/10/03 19:52:46
サーバに接続してからhelloでルール確認するって違和感あるんだけど
東風荘みたいに「○○ルールのサーバに接続しに行く」ってのはできんのかね
819:デフォルトの名無しさん
08/10/04 23:37:26
>>664
期待して待ってるんですが、その後どうですか？
820:632
08/10/05 02:39:38
赤牌のことを考えると、チーとかポンで晒す牌を明示的に
指定しないといけないのか…地味に面倒だな(^^;
821:デフォルトの名無しさん
08/10/05 02:47:35
別に赤牌が無くてもチーは明示的に指定する必要がある
822:632
08/10/05 03:55:54
>>821
いや、もちろん最初からチーのときは牌を指定させてたよw
823:デフォルトの名無しさん
08/10/05 10:55:11
経過をたどればプロトコル関係ないだろ。
クライアントだけで晒す牌は自明。
824:デフォルトの名無しさん
08/10/05 12:46:31
>>823
お前は相手の牌が読めるのかよｗｗ
825:デフォルトの名無しさん
08/10/05 13:03:43
>>824
sutehai
と
chi
pon
kan
の経過があれば可能
826:デフォルトの名無しさん
08/10/05 13:16:58
記述内容が荒くて答えになっていない
まず、それではあがった時や流局時にプレーヤーがどんな手牌
であるのか不明
つか、sutehaiとかchiとかのメッセージをサーバ間で
やりとりして、言語依存せずに麻雀のゲームを成立させることが、
このプロトコルが意図してるところだろ？
827:デフォルトの名無しさん
08/10/05 13:23:24
>>826
これを読んでから言ってるの？
URLﾘﾝｸ(sourceforge.jp)
828:デフォルトの名無しさん
08/10/05 13:58:48
ここまで読んできて非常に面白いと思った
麻雀は将棋やチェスと違ってプレイヤー間の意思疎通および時間経過の概念があるから
適当な考えで簡単に策定したら後で破綻しやすそうだね
個人的には錯和もチョンボも無いゲームは麻雀とは呼ばずに
麻雀モドキもしくはコンピュータ麻雀とか呼んで欲しいと思うけど
829:デフォルトの名無しさん
08/10/05 14:15:20
他人の作るものにケチつけるくらいなら自分で作ればいい
830:デフォルトの名無しさん
08/10/05 14:26:31
他人にケチ付けられて拗ねるぐらいなら公開掲示板などに書かなければいい
831:632
08/10/05 14:36:42
>>828
> 個人的には錯和もチョンボも無いゲームは麻雀とは呼ばずに
> 麻雀モドキもしくはコンピュータ麻雀とか呼んで欲しいと思うけど
そういう意味では、自分はリアル(人間同士)の麻雀を再現したいとは
カケラも考えていません。だいたい、表情や仕草も見えない時点で全然
別物なのは皆わかってるものだと思いますが。
むしろ、そういう情報をなくすことで、より麻雀の「ゲーム」としての要素が
際立ち、そしてそこにコンピュータを使って最強のAIを作るという新たな
試みが生まれているのではないでしょうか。
その上で、チョンボは「コンピュータ麻雀」として意味があるのか、という
議論であれば、それは面白いと思います。
832:デフォルトの名無しさん
08/10/05 14:40:59
チョンボが勝率に絡んでくることもあるだろ
833:632
08/10/05 14:43:27
ちなみに、現状自分が作っているシステムではツモ切りかどうかを
誤魔化すことができません。
これは、本来の麻雀では小手返しのうまい人なら可能なことが
不可能になっているという意味で、チョンボを認めるかどうかなんか
よりよほど大きな問題だと思いますが、これについて一切ツッコミは
ありません。
というか、小手返しを使ってツモ切りかどうかを誤魔化せる麻雀ゲームって
存在するんですかね？
834:デフォルトの名無しさん
08/10/05 18:27:54
意図的にチョンボしたい時用に、満貫払って降りる
チョンボコマンドでも定義しとけば？
835:デフォルトの名無しさん
08/10/05 22:09:26
>>831
表情が見えないからこそ、牌で語るんじゃないの？
とりあえずノーテンリーチを認めない理由がわからない
836:デフォルトの名無しさん
08/10/05 22:37:02
とりあえず動くクライアントを作らないか？
837:デフォルトの名無しさん
08/10/06 00:25:59
ちゃんと動くサーバが出てソースが公開されたら、
俺がチョンボとかノーテンリーチとか対応するから問題なす。
838:デフォルトの名無しさん
08/10/06 00:41:27
>>835
つかノーテンリーチ認めてるところが
あるかよ
おまえ自身が異端だって気付けよ
839:デフォルトの名無しさん
08/10/06 13:40:49
＞これについて一切ツッコミはありません。
自分が考えたことに対する異論は片っぱしから拒否しといてつっこみがないとかあるかよ。
もう付き合ってられんわ。
840:デフォルトの名無しさん
08/10/06 19:29:03
AI同士の勝負でバグを出すことがデメリットにならないなんて設計ミスだろ
ノーテンリーチやチョンボ判定せずにサーバの救済措置で勝つAIがあるとして
それは強いAIとは言わないし、そのプロトコルはAIの強さを保証できない
841:デフォルトの名無しさん
08/10/06 21:05:16
本質がわかってないね
きみには強いAIは無理だからどうでもいいや
842:632
08/10/07 00:11:21
>>839
チョンボとルールの伝達の件でしょうか？
それについては採用しない理由(デメリット)を説明しているつもりです。
ただルール伝達については、自分は必要がないと考えているんですが、
それを証明(？)するためにも、その仕組みでの実装を見せる必要が
あるかと思い、とりあえず議論よりも実装を頑張っている状態です。
その後、自分以外にもクライアントやAIを作ってくれる人が現れて、
やはりルール伝達があった方が問題が少なくなると思えば、仕様に
採り入れることもあります。
チョンボについては、極論すれば>>834の意見に行き着いてしまうと
思うのですが、やはりこれには抵抗を感じます。
843:632
08/10/07 00:15:32
>>840
AIでチョンボというのは、それはもはやバグであり、強い弱いという
レベルとはかけ離れていると思います。
逆に、チョンボをサーバに救済してもらうことで勝てるAIなら、それは
バグを直せば強いのだから、強いAIなんじゃないでしょうか？
844:デフォルトの名無しさん
08/10/07 00:20:19
チョンボで流れるルールだったら、チョンボで流して１位確定とかやれるんだよ・・・？
ルールによってはだけどね、流局連荘だけどチョンボだと流れるとか、どっかであったはず
普通ないけどね、一応こういうのもあるよっていう情報提供って意味でｗ
845:632
08/10/07 00:30:37
また、人間が操作するタイプのクライアントの場合、クライアントで
チョンボを発生させないようにする(サーバに送らない)ことも可能です。
これは、オープンなプロトコルで、クライアントを自由に実装できる以上、
防ぎようがありません。
その上で、チョンボが発生するクライアントと、チョンボを発生させない
ようにしたクライアントで対戦するというのは、どうなんでしょうか。
「コンピュータに手助けしてもらって打つなんて麻雀じゃない」という
意見もあるかもしれません。
でも、一昔前は他家の点数を覚えておくのは技術でしたが、今どきの
自動卓ならボタンを押せば表示されます。
またゲームであれば、ツモ切りかどうかを捨て牌にわかりやすく表示して
くれるものもあります。
自分としては、そういうことを総合して、リアルの麻雀とコンピュータの
麻雀は違うのだから、リアルの麻雀のすべての要素を入れる必要はなく、
そしてチョンボはコンピュータ麻雀には不要だと考えたわけです。
846:632
08/10/07 00:34:32
>>844
わかります。
ですから結局>>834を認めるかどうかなんですが、実際、自分は
今までに勝とうとしてわざとチョンボするヤツを見たことがありません。
暗黙の了解で、チョンボはわざとやらない、つまり戦術ではないと
いうものだと思ってたんですが、そんなこともないんでしょうか？
847:デフォルトの名無しさん
08/10/07 00:39:49
っと、ごめん、すでに書いてあったのね
まぁ明記してくれればどっちでも自分はかまわないかな？お好きなようにっ
そこは設定できるようにしてあるしっ
848:デフォルトの名無しさん
08/10/07 00:42:43
じゃあチョンボはサーバ側で勝手に弾いていいから
弾いたログだけは絶対に牌譜に残る仕様にしてくれよ
849:632
08/10/07 00:48:26
>>848
今作ってるサーバをそういう仕様にするのは全然構わないですが、
すべてのサーバの実装はそうすべき、とするほどの意味が感じられません。
どういう用途で必要なんでしょうか？
850:デフォルトの名無しさん
08/10/07 01:27:43
>>849
デバッグに有用な情報ではあるんじゃないかな。
チョンボするってのが、単にチョンボするだけの問題ってことはおそらくあまりなくて、
推論ロジック全体に影響する問題がある可能性が高いだろうし。
その一種の症候として検出するに値するものであると思うよ。
まあ、それだと全てのサーバがそうすべき、というほど強く必要なものでもないだろうけど。
851:632
08/10/07 01:36:00
>>850
それは自分も考えました。
でもそうだとすると、サーバのログよりも、クライアントから不正な
返答があった場合には、サーバからerrorとかを返した上で続行
した方がクライアントのデバッグはやりやすいんじゃないでしょうか。
852:デフォルトの名無しさん
08/10/07 01:43:53
>>846
>暗黙の了解で、チョンボはわざとやらない、つまり戦術ではないというものだと思ってたんですが
同意だ。
麻雀の戦術として、「この場合はチョンボしよう」というのも見たこと無いな。
チョンボは麻雀の中で、明らかに「例外」だ。
無しにできるのなら無しで良いものだと思う。
現在あるコンピュータ上の麻雀ゲームで、チョンボがあるものは多数あるため、なんとなく無いと変な気がするだけで、
無いからといって麻雀のゲーム性が損なわれることはまったく無いと考えられる。
リアルの麻雀では、山を手で崩してしまったら、なんらかの罰とかもあるわけだが、それは実装しなくて良いのだろうか。
その場合、ＡＩが手のカーソルを牌を倒さないように避けるアルゴリズムが必要だな。
853:デフォルトの名無しさん
08/10/07 02:16:03
>>851
それもそうか。
854:デフォルトの名無しさん
08/10/07 02:22:11
たまにフリーでそういうプログラム欲しくなるな
んで、出来た？
855:デフォルトの名無しさん
08/10/07 02:49:21
>>849
「完全にバグの無いプログラムの存在は証明し得ないから(悪魔の証明)」
言語が違うコンパイラが違うOSが違う加えて通信上の問題も多々ある
これ普通のマならみんな最大限警戒することだと思うけど
あなたが許したバグの責任はあなたが負うことを明示してねっ、てこと
チョンボを弾いたログは牌譜に残してね。お願いします
856:632
08/10/07 02:59:34
>>854
進捗はSourceForgeのソースを動かしてもらうのが一番わかりやすいんですが、
とりあえず残る大物作業としては鳴きの処理くらいで、あとはGUIをもうちょっと
ちゃんとするのとか、バグとか、そんな感じです。
現在でも鳴けないけどツモ切り3人相手に一人打ちくらいならできます。
>>855
クライアントのバグの検出ということであれば、>>851の方法ではいかがでしょう？
牌符は東風荘と互換にしようと思ってるので、独自情報は追加できないかも。
それはそれとして、サーバのログは残すつもりですが。
857:デフォルトの名無しさん
08/10/07 03:51:37
牌符を「東風荘と互換」にするなら錯和は必ず牌符に残ことになるはずでは
「それはそれとして、サーバのログは残す」ってどういうことなのでしょうか？
「独自情報の追加(削減？)」は不要なので普通に牌譜に記録して頂きたい
858:デフォルトの名無しさん
08/10/07 04:03:52
サーバのログって言ったら通信履歴のことじゃないの？
通信記録＝牌譜ではないでしょ。
859:デフォルトの名無しさん
08/10/07 09:16:04
通信記録は全て残す
牌譜はその記録から抜き出す
これで好きな形式で牌譜も取り出せる
860:デフォルトの名無しさん
08/10/07 09:22:47
AI対戦が根本にあるんだから、短時間で数百回勝手に対戦させといて
後で集計を確認したり、気になった局の牌譜を再現したりできるようにしたいじゃない？
せっかくサーバー使うんだし、DB使うってのはそういうことに使えるからなんだけどね。
人間に見やすいプロトコルのために機能を削るのはナンセンスだと思ってる。
861:デフォルトの名無しさん
08/10/07 20:09:37
だから、チョンボは無しでノーテンリーチだけ認めればいいじゃん。
チョンボはルールの破壊だがノーテンリーチは戦術だろう
862:デフォルトの名無しさん
08/10/07 20:17:05
ノーテンリーチで流局になったらチョンボだべや
863:デフォルトの名無しさん
08/10/07 20:49:33
ノーテンリーチが戦術とか漫画の読みすぎじゃねーのｗ
馬鹿がいると話が進まないな
チョンボ厨は完全スルーでいいだろ
今更こんな質問をするのもなんだけど、ＡＩ同士の優劣を判定するには多数の対局をこなさないといけない麻雀というゲームの性質上、
対局のたびにネットワークを介する方法は効率が悪いのでは？
864:デフォルトの名無しさん
08/10/07 21:51:03
ネットワーク用のプロトコルを作っておけば、
別にlocalhostでも使えるでしょ。
865:632
08/10/08 00:37:58
>>857
牌譜を東風荘と互換にすることと、東風荘と同じ仕様(ルール)にするのは
イコールではないです。
ログについては>>858の言うように、いわゆる普通のログです。
通信だけには限りませんが。
クライアントのデバッグが目的であれば>>851の方法を提案しています。
これについてはどうでしょうか？
そういう目的のためではない、というのであれば、どうしろ、という形ではなく、
目的を教えて下さい。でないと対応できません。
866:632
08/10/08 00:41:24
>>859
それも考えましたが、とりあえず東風荘形式で牌譜を出した方が
何かと便利な気がします。
で、東風荘の牌譜について調べてたんですが、どこかに仕様って
上がってます？
ざっと見た感じだと、鳴いたときに晒すメンツの情報が足りないような
気がするんですが…
867:デフォルトの名無しさん
08/10/08 00:44:29
URLﾘﾝｸ(mj.giganet.net)
868:632
08/10/08 00:54:34
>>860
> 人間に見やすいプロトコルのために機能を削るのはナンセンスだと思ってる
どの部分を指摘しているかわかりません。牌を個別IDにしなかったことでしょうか？
もしそうなら、それは機能を削ったという認識はないんですが、何かこれで失った
ものがあるんでしょうか？
869:632
08/10/08 00:55:43
>>867
うわ、思いっきり本家にw
ググっても引っかからなかったのに。ありがとうございます(^^
870:632
08/10/08 01:00:10
>>861-863
自分もノーテンリーチだけはアリかなと思ってます(^^;
理由は、
* 流局までチョンボにならない
* 途中で上がることで防げる
という部分で、他家同士の損得に影響が少なく、またゲーム性としても
いわゆる「ブラフ」としての価値はあるかと。
もちろん、罰符は親子で同じ点数、局は流れないという条件は付きますが。
871:632
08/10/08 01:05:18
>>863
>>864の言うように、ローカルでサーバも動かせば、それほどロスはないと
考えています。
ただ効率とか速度はそれほど重視していないので、それこそ何万局も打たせて
集計をとりたいという目的には向いてないかもしれません。
ちなみに、自分はAI同士ももちろんですが、AI対人間も考えてこの仕組みを
作っています。
だって、強いAIなら自分で相手したいじゃないですか？(^^
872:デフォルトの名無しさん
08/10/08 01:06:57
人間が打てるなら３Dにしてください＞＜
873:デフォルトの名無しさん
08/10/08 01:10:04
>>872
大丈夫か？
874:デフォルトの名無しさん
08/10/08 01:10:11
AIと人間が対戦するのにサーバ介してロビー用意してチャットシステム組んでやんの？
いつまでたってもできそうもないな。
875:632
08/10/08 01:15:47
>>874
別にロビーもチャットも用意するつもりはありませんが？
そんなんなくても麻雀はできるでしょ。
876:デフォルトの名無しさん
08/10/08 01:16:17
そもそも文字だけでやる気にはならないな
GUI作ってしまえばプロトコルなんてバイナリーでもかまわないわけで
877:632
08/10/08 01:17:22
>>872
クライアントのクオリティは…優先順位は低いですが、頑張ります(^^;
878:デフォルトの名無しさん
08/10/08 01:18:59
どうでもいいけど、自分と違う人の意見は絶対に聞かない態度はどうにかならないのか
879:632
08/10/08 01:19:08
>>876
GUIクライアントも一応作ってます(^^;
さすがに人間が打つのにtelnet使えとかは言えないです。
880:デフォルトの名無しさん
08/10/08 01:20:06
>>878
お前がか？
自己紹介
乙
881:632
08/10/08 01:23:09
>>878
意見を聞くということが、言われたことをホイホイやるというのであれば
そんなつもりはカケラもありません。
リクエストについてはそれなりに理由をつけて反論しているつもりです。
ただ好き嫌いに関しては、当然ですが自分の好きを選びます。
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
5389日前に更新/253 KB
担当:undef