おまいら最強の麻雀プ ..
666:デフォルトの名無しさん
08/09/24 09:48:06
ルールはこれで
URLﾘﾝｸ(act0.net)
667:デフォルトの名無しさん
08/09/24 09:51:03
点数計算はサーバのサービスでいいと思うけどな。
ルールによっても変わってくるし。
でもいちいち可能性のある手の点数をサーバに問い合わせるのは無駄か？
668:デフォルトの名無しさん
08/09/24 10:10:52
そのサーバーの点数計算が間違えていたら、ルールが通じないことになる。
慎重に作るべきところで最も重要なところといえる。
669:デフォルトの名無しさん
08/09/24 10:25:34
>>665、>>668
じゃぁそこのロジックはオマエらに任せた。
手牌を渡すから、得点と役を返すファンクションでもクラスでもいいから作ってくれ
頼んだぞ
670:デフォルトの名無しさん
08/09/24 10:31:20
渡すのって単に手牌を渡すだけじゃないよね。
風と局、ツモやロンの区別とその牌、晒してるかとか海底とかリーチとかどういう風に渡せばいいものか・・
671:デフォルトの名無しさん
08/09/24 11:13:16
手牌(上がり牌)
鳴き
ツモorロンorﾁｬﾝｶﾝorﾘﾝｼｬﾝ
局・風
リーチorWリーチ・一発
天・地・人和
海底or河底
(八連荘)
こんだけあれば役得点計算できるかね
672:デフォルトの名無しさん
08/09/24 12:20:22
何か知らんがインターフェースを決めるだけでも
大変そうだな。
>667
まず、ゲーム開始前に手と得点の一覧表を
サーバーに問い合わせると言うのはどうかね？
673:デフォルトの名無しさん
08/09/24 18:40:02
ていうかまずやることリストアップしたほうがいいんでね
目次うp
674:デフォルトの名無しさん
08/09/24 19:54:34
>>666のルールで作ってみるか
675:632
08/09/24 21:15:15
とりあえずSourceForgeでプロジェクトが立てられたので、
Wikiにざっとコマンド案とかを書いてみた
URLﾘﾝｸ(sourceforge.jp)
実装は今から頑張ります(^^;
とりあえずRubyで麻雀ライブラリを書いてから、サーバプロセスを作る予定
676:デフォルトの名無しさん
08/09/24 22:07:27
>>675
字牌の表記が東風荘と違うんだけど、天鳳か何かだとそうなの？
677:632
08/09/24 22:23:21
>>676
いや、別に他のに合わせる必要もないかと思って気にもしなかった。
ということで、中途半端に似てるくらいなら、東風荘に合わせようかと
思って調べてみたけど、東風荘は字牌は漢字表記？
だとしたら、それはイヤだな。
678:デフォルトの名無しさん
08/09/24 22:33:01
>>675
自分の下家がチーで鳴いたのか
ツモなのか判別できない気がするのですが…
679:デフォルトの名無しさん
08/09/24 22:47:42
>>677
動作確認で牌譜再生ツールを使うと思うんだけど、nz表記用のを一から作るのも手間だし
現段階で安定したものがあるんだから、それで再生できるよう合わせた方がいいのでは？
・・・まあnz⇔漢字の変換ツールを作ればいいだけの話か。字牌の表記はお任せします
680:デフォルトの名無しさん
08/09/24 22:52:28
漢字は極力避けて欲しい
いわゆるASCIIコードの範囲内の方がいい
681:632
08/09/24 22:59:57
>>678
どういうケースでしょうか？
Wikiにも書いた通り、サーバから送られてくるのが
「実際に起きたこと」なので、サーバから下家がツモった
(tsumoコマンドがきた)ならツモ、chiコマンドがきたなら
チーとなる想定なんですが。
>>679
牌符は別にプロトコルに合わせる必要はないので、
東風荘フォーマットとかで出力するのは問題ないです。
>>680も言っている通り、ネットワークを通すプロトコルでは
漢字は問題を起こしやすいので、できれば避けたいです。
682:678
08/09/24 23:02:07
>>681
ごめん、勘違いしてた
683:デフォルトの名無しさん
08/09/24 23:02:13
kyokustartの説明が「一局が〜」になってますけど「n局n本場が〜」ですよね？
それとryukyokuでクライアントにtenpaiかnotenかを返させてますけど、
不正申告がないようサーバ側でチェックするなら不必要な気がします
684:632
08/09/24 23:09:04
>>682
いえいえ、色々抜けはあると思うので指摘して頂けるのは
嬉しいです(^^
>>683
「局」という言葉が正しくは何を指すのかが良くわからないのですが、
いわゆるサイコロ振って配牌取って、誰かが上がるまでを1局と呼んでます。
なので、言葉が混在してわかりにくくなってますがkyokustartについては
683さんの理解している通りです。
流局時にテンパイ/ノーテン宣言をクライアントに返させているのは、
テンパイしててもノーテンと宣言したい場合があるからです。
上がり止めなしのオーラストップ目とか。
当然、ノーテンなのにテンパイと宣言してもサーバ側では認めません。
685:632
08/09/24 23:12:45
ドラはそのものじゃなくて、表示牌を送らないと、
赤牌が表示牌の場合に対応できなかった。
686:デフォルトの名無しさん
08/09/24 23:23:08
リンシャンの通知は？
687:デフォルトの名無しさん
08/09/24 23:24:15
だから、多牌と少牌の処理についてちゃんと最初に決めておかないとダメだってば
688:デフォルトの名無しさん
08/09/24 23:26:54
>>687
職場にこんなこと言いだす奴がいたら絶対殴ってるわｗ
689:デフォルトの名無しさん
08/09/24 23:27:14
>>687
それは無しって事になってるのでは？
690:632
08/09/24 23:39:00
>>686
リンシャンというか、和了役の通知でしょうか？
今のところ入ってません。さすがにマズいかな？
とりあえずkyokuendで点数の増減だけで済ませようかなと
甘く考えていたんですが、ちょっともう一度考えてみます。
>>687
手牌はサーバ側で管理するので多牌、少牌は不可能です。
691:デフォルトの名無しさん
08/09/24 23:48:13
カンしたときのリンシャン牌の通知はツモコマンド？
692:632
08/09/24 23:51:13
>>691
そのつもりです。
リンシャンツモを特別扱いする必要ってあるでしょうか？
693:デフォルトの名無しさん
08/09/24 23:58:43
クライアントでも計算できるけどサーバに通知してもらえた方が
楽になることってどういう扱い？ツモったときの山牌の残り枚数とか
今はkyokustartで親を通知してもらってるけど、これなんかも
gamestartを作って最初に誰が親かを通知してもらえればいらない気が
694:デフォルトの名無しさん
08/09/25 00:07:49
sute<プレイヤー><牌>にツモ切りなのか
手牌から出したのかのフラグがあるといいかも
695:691
08/09/25 00:10:41
>>692
いえ、設計者の趣味の範囲なので、とくにどっちがいいという訳では無いです。
もし必要ならカンしたプレーヤーの直後のツモはリンシャンって処理するだけだし。
ただ、仕様としては、どっかに明記してあった方がいいかなと。
696:632
08/09/25 00:11:37
>>693
特に指針は決めてないんですが、基本的にはセッションは１局単位で
完結するようにしようと思ってます。
途中接続が切れた場合も、局の途中では戻れないが、次の局から
戻れる、みたいな。
なので、局が始まるときには、クライアントがその局の処理をするのに
必要な情報は渡すという感じです。
で、同じ面子で複数のセッションを繰り返すことで、半荘が成立すると。
ただこの辺はこれから実装して行くにつれて、色々変わって行く予感が
します(^^;
697:デフォルトの名無しさん
08/09/25 00:13:12
それぞれの牌にユニークなID振っていればツモハイ提供側で判別つくと思う
同じ種類の牌で手出しすることもあるけど、それはツモ切りではなくなるよね
698:632
08/09/25 00:20:18
>>695
ちょっと現状では必要性が感じられないので、
いったん保留とさせて下さい。
>>694
ああ、そうですね。それはあった方が良いな。
ありがとうございます。
個人的には空切りはキライなので、ツモ牌と同じものを
切ったらサーバ側でツモ切り扱いしたいんだけど、さすがに
それはマズいですよね(^^;
オカルトシステムNo.65「空切りは勢いを消す！」やw
699:632
08/09/25 00:23:18
>>697
なるほど！それは考えつかなかった。
ちょっとプロトコルを通す情報が(人間から見て)わかりにくくなるけど、
そうすれば確かにツモ切り判定はわかりやすいですね。
700:デフォルトの名無しさん
08/09/25 00:42:33
強いプログラム(AI)を目指してるのにいきなりネットワーク対戦プログラムなんて目的を見失ってないか？
701:デフォルトの名無しさん
08/09/25 00:46:19
>>698
ベタオリ処理で手出しから筋見てる部分があるので
空切りはツモ切り扱いでも構わなかったり(汗
それだと自分と同じベタオリ処理してる相手がいる場合のみ
立直側になったときにちょっと有利になるくらいかな？
ま、どっちでもいいです
702:632
08/09/25 01:13:40
>>700
自分としては、強いAIを作るための環境でもあるつもりです。
ただ、無駄に遠回りしているとは思います(^^;
もしスレ違いだという声が多ければ移動しますが、せっかく
何人かの方には反響を頂いているので、できればここで
話を続けさせてもらいたいです。
>>701
普通の麻雀でも、空切りを禁止した方が知的なヨミの要素が
増えて面白くなると思います。
ただまあプロトコルでできなくするのはマズいので、何か考えます。
703:デフォルトの名無しさん
08/09/25 02:20:35
>>702
プロトコルの策定は、プログラマ魂が湧き上がってくる話題で楽しいし、別に良いと思うのだが、あまり意味が無いかもしれないな。
というのも、実際はクライアント側にも共通基盤を作るはずで、
ネットワーク ---> クライアント共通基盤 ---> ユーザAI
結局プロトコルは共通基盤の開発者だけがわかっていれば良く、どちらかといえば共通基盤のIFを決めたほうがいいかもね。
704:デフォルトの名無しさん
08/09/25 02:22:11
プロトコル＝IF
705:デフォルトの名無しさん
08/09/25 02:28:42
>>703のつづき
そういう意味では、とりあえずローカルで動くものを作っておいて、後でネットワーク対応にしても良いかと。
麻雀はルールや点数計算が複雑なため、これらを全員が作るのは明らかに無駄で、
クライアント側にもどうせサーバと同等以上のライブラリが必要でしょう。
706:デフォルトの名無しさん
08/09/25 02:31:39
>>704
それは現実的じゃないと思うって事を言いたいのだが・・・
707:デフォルトの名無しさん
08/09/25 02:44:24
いまの時点でのプロトコルはどう考えても、ネットワークプロトコルを指してないだろ。
管理プログラムとAIの通信方法。
708:デフォルトの名無しさん
08/09/25 02:54:39
>>707
？
話がかみ合ってないかな？
wikiには、「オープンなネットワーク麻雀のプロトコルを策定し」、「TCPを介した通信」って書いてあるけど・・・
それと管理プログラムって何？
709:632
08/09/25 02:55:20
>>703
まさにおっしゃる通りで、プロトコルの策定とか、わざわざ遠回りな
ことをしているのは「好きでやってる」というのが一番です(^^
そして、プロトコルを策定したとしても、クライアント共通基板(SDK的なもの)
が必要になるだろうというのは自分もそう思います。
ただ、色々なプログラムを対戦させたり、サーバ側でちょっと特殊な集計を
したいと思ったときに、共通プロトコルで動いているというのは価値が
あるのではないでしょうか。
とりあえず、前述した通り個人的に好きでやっているので、
生暖かい目で見守って、ときには意見やコードなんか頂けると
嬉しいです。
710:デフォルトの名無しさん
08/09/25 04:38:09
>>709
>共通プロトコルで動いているというのは価値があるのではないでしょうか。
あってもいいと思うのだが、コース料理でいえばデザートの部類ではないかと。
実際に動くAIが出てくるかどうか。
まずは、簡単にローカルで動く環境の提供が必要と考える。
要は、まずSDKから作ってみては？という意見でした。
711:デフォルトの名無しさん
08/09/25 09:53:11
オレはAIよりも、こういったシステムを作るほうが好きなので
こっちの話のほうが参加しやすいんだよなあ
712:デフォルトの名無しさん
08/09/25 11:07:21
システム作ったあと、AIはGP組み込んで、あとはぶん回しておけば
勝手に最強になるんじゃね？
713:デフォルトの名無しさん
08/09/25 20:20:54
SourceForgeの中の人はどこのルールで作ってるの？
714:デフォルトの名無しさん
08/09/25 20:28:27
ルールはこれで コンピュータ対戦向けのオリジナル
プロルールに基づく
URLﾘﾝｸ(act0.net)
715:デフォルトの名無しさん
08/09/25 23:27:41
101競技連盟、最高位戦日本プロ麻雀協会、日本プロ麻雀協会
日本プロ麻雀連盟、日本プロ麻雀棋士会、麻将連合
どれもルール違うだろ。「プロルール」なんてものは無い
716:632
08/09/25 23:39:10
ルールについては、今のところそんなに深く考えていません(^^;
まず、プロトコル(UMP)ではルールを規定しません。
それどころか、UMPではサンマでも青天井でも可能にする
想定です。
# ぶんぶんレジデンスの100人麻雀もできるようにしたかったけど、
# 現状だとプレイヤーをアルファベット１文字で表すので無理
ルールはサーバの実装次第なので、実際に動き始めてからでも
問題ないかと。
クライアント(UI)も、UMPにきちんと対応すれば、どんなルールで
あったとしても動作するハズです。
ただし、このスレの本旨であるAIを作るとなると、ルールによって
考えなければいけないことが変わるので、そのステップまできたら
ちゃんと考えないといけないと思います。
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
ちなみに、現状自分が作っているシステムではツモ切りかどうかを
誤魔化すことができません。
これは、本来の麻雀では小手返しのうまい人なら可能なことが
不可能になっているという意味で、チョンボを認めるかどうかなんか
よりよほど大きな問題だと思いますが、これについて一切ツッコミは
ありません。
というか、小手返しを使ってツモ切りかどうかを誤魔化せる麻雀ゲームって
存在するんですかね？
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
5385日前に更新/253 KB
担当:undef