おまいら最強の麻雀プログラムしてみろよ Part2

1 名前：デフォルトの名無しさん mailto:sage [2007/07/27(金) 21:47:50 ] めざせ最強の麻雀プログラム！ 層の薄いこのカテゴリーなら、将棋やオセロよりも ずっと簡単にその地位を手にいれられるぞ！ 685 名前：632 mailto:sage [2008/09/24(水) 23:12:45 ] ドラはそのものじゃなくて、表示牌を送らないと、 赤牌が表示牌の場合に対応できなかった。 686 名前：デフォルトの名無しさん mailto:sage [2008/09/24(水) 23:23:08 ] リンシャンの通知は？ 687 名前：デフォルトの名無しさん mailto:sage [2008/09/24(水) 23:24:15 ] だから、多牌と少牌の処理についてちゃんと最初に決めておかないとダメだってば 688 名前：デフォルトの名無しさん mailto:sage [2008/09/24(水) 23:26:54 ] >>687 職場にこんなこと言いだす奴がいたら絶対殴ってるわｗ 689 名前：デフォルトの名無しさん mailto:sage [2008/09/24(水) 23:27:14 ] >>687 それは無しって事になってるのでは？ 690 名前：632 mailto:sage [2008/09/24(水) 23:39:00 ] >>686 リンシャンというか、和了役の通知でしょうか？ 今のところ入ってません。さすがにマズいかな？ とりあえずkyokuendで点数の増減だけで済ませようかなと 甘く考えていたんですが、ちょっともう一度考えてみます。 >>687 手牌はサーバ側で管理するので多牌、少牌は不可能です。 691 名前：デフォルトの名無しさん mailto:sage [2008/09/24(水) 23:48:13 ] カンしたときのリンシャン牌の通知はツモコマンド？ 692 名前：632 mailto:sage [2008/09/24(水) 23:51:13 ] >>691 そのつもりです。 リンシャンツモを特別扱いする必要ってあるでしょうか？ 693 名前：デフォルトの名無しさん mailto:sage [2008/09/24(水) 23:58:43 ] クライアントでも計算できるけどサーバに通知してもらえた方が 楽になることってどういう扱い？ツモったときの山牌の残り枚数とか 今はkyokustartで親を通知してもらってるけど、これなんかも gamestartを作って最初に誰が親かを通知してもらえればいらない気が 694 名前：デフォルトの名無しさん mailto:sage [2008/09/25(木) 00:07:49 ] sute<プレイヤー><牌>にツモ切りなのか 手牌から出したのかのフラグがあるといいかも 695 名前：691 mailto:sage [2008/09/25(木) 00:10:41 ] >>692 いえ、設計者の趣味の範囲なので、とくにどっちがいいという訳では無いです。 もし必要ならカンしたプレーヤーの直後のツモはリンシャンって処理するだけだし。 ただ、仕様としては、どっかに明記してあった方がいいかなと。 696 名前：632 mailto:sage [2008/09/25(木) 00:11:37 ] >>693 特に指針は決めてないんですが、基本的にはセッションは１局単位で 完結するようにしようと思ってます。 途中接続が切れた場合も、局の途中では戻れないが、次の局から 戻れる、みたいな。 なので、局が始まるときには、クライアントがその局の処理をするのに 必要な情報は渡すという感じです。 で、同じ面子で複数のセッションを繰り返すことで、半荘が成立すると。 ただこの辺はこれから実装して行くにつれて、色々変わって行く予感が します(^^; 697 名前：デフォルトの名無しさん mailto:sage [2008/09/25(木) 00:13:12 ] それぞれの牌にユニークなID振っていればツモハイ提供側で判別つくと思う 同じ種類の牌で手出しすることもあるけど、それはツモ切りではなくなるよね 698 名前：632 mailto:sage [2008/09/25(木) 00:20:18 ] >>695 ちょっと現状では必要性が感じられないので、 いったん保留とさせて下さい。 >>694 ああ、そうですね。それはあった方が良いな。 ありがとうございます。 個人的には空切りはキライなので、ツモ牌と同じものを 切ったらサーバ側でツモ切り扱いしたいんだけど、さすがに それはマズいですよね(^^; オカルトシステムNo.65「空切りは勢いを消す！」やw 699 名前：632 mailto:sage [2008/09/25(木) 00:23:18 ] >>697 なるほど！それは考えつかなかった。 ちょっとプロトコルを通す情報が(人間から見て)わかりにくくなるけど、 そうすれば確かにツモ切り判定はわかりやすいですね。 700 名前：デフォルトの名無しさん mailto:sage [2008/09/25(木) 00:42:33 ] 強いプログラム(AI)を目指してるのにいきなりネットワーク対戦プログラムなんて目的を見失ってないか？ 701 名前：デフォルトの名無しさん mailto:sage [2008/09/25(木) 00:46:19 ] >>698 ベタオリ処理で手出しから筋見てる部分があるので 空切りはツモ切り扱いでも構わなかったり(汗 それだと自分と同じベタオリ処理してる相手がいる場合のみ 立直側になったときにちょっと有利になるくらいかな？ ま、どっちでもいいです 702 名前：632 mailto:sage [2008/09/25(木) 01:13:40 ] >>700 自分としては、強いAIを作るための環境でもあるつもりです。 ただ、無駄に遠回りしているとは思います(^^; もしスレ違いだという声が多ければ移動しますが、せっかく 何人かの方には反響を頂いているので、できればここで 話を続けさせてもらいたいです。 >>701 普通の麻雀でも、空切りを禁止した方が知的なヨミの要素が 増えて面白くなると思います。 ただまあプロトコルでできなくするのはマズいので、何か考えます。 703 名前：デフォルトの名無しさん mailto:sage [2008/09/25(木) 02:20:35 ] >>702 プロトコルの策定は、プログラマ魂が湧き上がってくる話題で楽しいし、別に良いと思うのだが、あまり意味が無いかもしれないな。 というのも、実際はクライアント側にも共通基盤を作るはずで、 ネットワーク　--->　クライアント共通基盤　--->　ユーザAI 結局プロトコルは共通基盤の開発者だけがわかっていれば良く、どちらかといえば共通基盤のIFを決めたほうがいいかもね。 704 名前：デフォルトの名無しさん mailto:sage [2008/09/25(木) 02:22:11 ] プロトコル＝IF 705 名前：デフォルトの名無しさん mailto:sage [2008/09/25(木) 02:28:42 ] >>703のつづき そういう意味では、とりあえずローカルで動くものを作っておいて、後でネットワーク対応にしても良いかと。 麻雀はルールや点数計算が複雑なため、これらを全員が作るのは明らかに無駄で、 クライアント側にもどうせサーバと同等以上のライブラリが必要でしょう。 706 名前：デフォルトの名無しさん mailto:sage [2008/09/25(木) 02:31:39 ] >>704 それは現実的じゃないと思うって事を言いたいのだが・・・ 707 名前：デフォルトの名無しさん mailto:sage [2008/09/25(木) 02:44:24 ] いまの時点でのプロトコルはどう考えても、ネットワークプロトコルを指してないだろ。 管理プログラムとAIの通信方法。 708 名前：デフォルトの名無しさん mailto:sage [2008/09/25(木) 02:54:39 ] >>707 ？ 話がかみ合ってないかな？ wikiには、「オープンなネットワーク麻雀のプロトコルを策定し」、「TCPを介した通信」って書いてあるけど・・・ それと管理プログラムって何？ 709 名前：632 mailto:sage [2008/09/25(木) 02:55:20 ] >>703 まさにおっしゃる通りで、プロトコルの策定とか、わざわざ遠回りな ことをしているのは「好きでやってる」というのが一番です(^^ そして、プロトコルを策定したとしても、クライアント共通基板(SDK的なもの) が必要になるだろうというのは自分もそう思います。 ただ、色々なプログラムを対戦させたり、サーバ側でちょっと特殊な集計を したいと思ったときに、共通プロトコルで動いているというのは価値が あるのではないでしょうか。 とりあえず、前述した通り個人的に好きでやっているので、 生暖かい目で見守って、ときには意見やコードなんか頂けると 嬉しいです。 710 名前：デフォルトの名無しさん mailto:sage [2008/09/25(木) 04:38:09 ] >>709 >共通プロトコルで動いているというのは価値があるのではないでしょうか。 あってもいいと思うのだが、コース料理でいえばデザートの部類ではないかと。 実際に動くAIが出てくるかどうか。 まずは、簡単にローカルで動く環境の提供が必要と考える。 要は、まずSDKから作ってみては？という意見でした。 711 名前：デフォルトの名無しさん mailto:sage [2008/09/25(木) 09:53:11 ] オレはAIよりも、こういったシステムを作るほうが好きなので こっちの話のほうが参加しやすいんだよなあ 712 名前：デフォルトの名無しさん mailto:sage [2008/09/25(木) 11:07:21 ] システム作ったあと、AIはGP組み込んで、あとはぶん回しておけば 勝手に最強になるんじゃね？ 713 名前：デフォルトの名無しさん mailto:sage [2008/09/25(木) 20:20:54 ] SourceForgeの中の人はどこのルールで作ってるの？ 714 名前：デフォルトの名無しさん mailto:sage [2008/09/25(木) 20:28:27 ] ルールはこれで　コンピュータ対戦向けのオリジナル プロルールに基づく act0.net/cgi-bin/source/up0280.txt 715 名前：デフォルトの名無しさん mailto:sage [2008/09/25(木) 23:27:41 ] 101競技連盟、最高位戦日本プロ麻雀協会、日本プロ麻雀協会 日本プロ麻雀連盟、日本プロ麻雀棋士会、麻将連合 どれもルール違うだろ。「プロルール」なんてものは無い 716 名前：632 mailto:sage [2008/09/25(木) 23:39:10 ] ルールについては、今のところそんなに深く考えていません(^^; まず、プロトコル(UMP)ではルールを規定しません。 それどころか、UMPではサンマでも青天井でも可能にする 想定です。 # ぶんぶんレジデンスの100人麻雀もできるようにしたかったけど、 # 現状だとプレイヤーをアルファベット１文字で表すので無理 ルールはサーバの実装次第なので、実際に動き始めてからでも 問題ないかと。 クライアント(UI)も、UMPにきちんと対応すれば、どんなルールで あったとしても動作するハズです。 ただし、このスレの本旨であるAIを作るとなると、ルールによって 考えなければいけないことが変わるので、そのステップまできたら ちゃんと考えないといけないと思います。 717 名前：デフォルトの名無しさん mailto:sage [2008/09/26(金) 00:38:08 ] ふむふむ、だったらオープンリーチの対応もおねがいします。 718 名前：デフォルトの名無しさん mailto:sage [2008/09/26(金) 00:38:32 ] >>711 あーそうか。 全員がAI作成を最終目標にしてると思い込んでたから、>>710とか書いてしまったが、 例えばプロトコルだけ考える人ってのがいてもいいわけか。 >>632さんはどこまで自分で実装する予定なんかな？ 719 名前：デフォルトの名無しさん mailto:sage [2008/09/26(金) 01:21:11 ] 確かに棒聴即立で立直にベタオリだと立直時ツモ和了率六割越すけどプンリー有りは微妙・・・ 720 名前：632 mailto:sage [2008/09/26(金) 01:30:50 ] >>717 オープンリーチ好きな人が多いなw 同じ人？ とりあえず仕様に追加しました。 >>718 自分としては、プロトコルの策定＆サーバプロセスの実装、 テスト用クライアントの作成まではやるつもりです。 できればWindows版のクライアントを作ってくれる人が 現れてくれると、すごく嬉しいです(^^ 721 名前：デフォルトの名無しさん mailto:sage [2008/09/26(金) 01:49:13 ] 確かに棒聴即立で立直にベタオリだと立直時ツモ和了率六割越すけどプンリー有りは微妙・・・ 722 名前：デフォルトの名無しさん mailto:sage [2008/09/26(金) 02:32:33 ] >>720 オープンリーチは待ちのわかる牌だけ晒すルールもあるので、 晒す牌の選択はクライアント側ではないかと。 プロトコルが対応してないから採用出来ないルール、ってのは 出来るだけ無い方がいいでしょ？ 723 名前：デフォルトの名無しさん mailto:sage [2008/09/26(金) 02:37:48 ] >>722 サーバーは待ちのわかる牌を自動判別出来るはずだから、サーバーが決めるんでいいじゃん。 724 名前：632 mailto:sage [2008/09/26(金) 02:38:05 ] >>722 んにゃ、全部晒すかどうかもサーバ側で決定します。 どうせサーバ側では不正をチェックしなければいけないので。 一部だけ晒せばOK、というルールのサーバのときに、 すべての手牌を晒したい、というときには問題になりますが、 それに対応する必要性は感じないんですが、どうでしょうか。 725 名前：デフォルトの名無しさん mailto:sage [2008/09/26(金) 02:54:15 ] たとえば、２３４５６と持っていて５６を晒してオープンリーチ、ってのが許されるルールはありか？ とかいう話かな。 もちろん、４，７のツモ上がり前提で。 726 名前：デフォルトの名無しさん mailto:sage [2008/09/26(金) 03:31:50 ] >>724 >それに対応する必要性は感じないんですが、どうでしょうか。 プレーヤーにとって意味ある事かどうかは、 プロトコル側では関知しないっていうポリシー だと思ってたけど、違った？ 727 名前：デフォルトの名無しさん mailto:sage [2008/09/26(金) 07:28:21 ] まずはルールはこれでいいだろう act0.net/cgi-bin/source/up0280.txt 728 名前：デフォルトの名無しさん mailto:sage [2008/09/26(金) 22:13:05 ] >>632 open<プレイヤー><手牌>で手牌全部見せたときと 鳴いた面子だけ見せたときのコマンドが一緒になると クライアント側で牌の数チェックする手間がでるんで 手牌か面子(ポン･チー/カン)かのフラグが欲しいです 729 名前：デフォルトの名無しさん mailto:sage [2008/09/26(金) 22:23:48 ] 情報にはノイズ乗せないの？ 730 名前：デフォルトの名無しさん mailto:sage [2008/09/26(金) 22:52:12 ] 打牌に制限時間設けないとひたすらぶん回し続けるAIが出てくる予感 一秒制限の早差し勝負とかもやってみたい 731 名前：デフォルトの名無しさん mailto:sage [2008/09/26(金) 23:36:33 ] 通信が遅れる可能性は十分考えられるので サーバ・クライアント共に何回目のackかを示す情報も必要かも 732 名前：632 mailto:sage [2008/09/27(土) 15:12:38 ] >>725 さすがにそんなルールは聞いたことないですが、もしかしたら 1が枯れている場合はOKとかはあるかもしれません。 >>726 おっしゃる通りです(^^; ということで、とりあえずopenrichiコマンドに晒したい部分の手牌も 指定できるよう仕様に追加しました。 733 名前：632 mailto:sage [2008/09/27(土) 15:13:04 ] >>728 openの手牌は、手牌の表記に則るので、 和了ったときは open A 1m2m3m4p5p6p7s8s9s1z1z1z2z2z ポンのときは open A <3m3m3m> チーのときは open A <1p2p3p> 暗槓は open A (8s8s8s8s) となるので、クライアントでも容易に区別できると思います。 >>729 ノイズって、どういうことでしょうか？ 734 名前：632 mailto:sage [2008/09/27(土) 15:17:57 ] >>730 実際に運用するとなると、時間制限は必要になると思いますが、 実験段階では、ひたすらぶん回して、それこそ1打1時間とかかけたとしても 本当に強いAIが出てくるなら、それはそれで面白いんじゃないでしょうか。 >>731 コマンド形式のところにある<センテンスID>というのがそれです。 ちなみに、最初はサーバから1コマンド送るごとに必ずクライアントの ack(okコマンド)を待っていたのですが、実装してるうちに不要な気が してきたので、必要なとき以外はクライアントからの返答を待たない ようにしました。 735 名前：デフォルトの名無しさん mailto:sage [2008/09/27(土) 15:21:19 ] 1打1時間掛かったら強いことが調べられない 736 名前：デフォルトの名無しさん mailto:sage [2008/09/27(土) 15:33:13 ] >>632 をを、プロトコルが強化されてる、乙かれ。 737 名前：632 mailto:sage [2008/09/27(土) 15:37:46 ] >>735 人間相手だと、さすがに人間の方が耐えられないだろうけど、 AI同士なら別に1打1時間かかるのもアリじゃない？ まあでも実際、将棋や囲碁に比べれば、麻雀はプレイヤーの できることが少ないから、さすがに1打1時間はないと思うけど。 >>736 実装しながらなので、随時変更してってます(^^; 738 名前：632 mailto:sage [2008/09/27(土) 15:39:46 ] ちなみに、開発途中ではありますが、ソースコードをSourceForgeの SVNに随時commitしているので、興味のある方は svn.sourceforge.jp/cgi-bin/viewcvs.cgi/?root=openmj から拾って下さい。 739 名前：デフォルトの名無しさん mailto:sage [2008/09/27(土) 15:47:07 ] AIどおしでも1時間は無いよ。　たとえば一手3秒以内で1日中動かして統計を取ったとする。 これを一手1時間以内でやったら、同じ回数をこなすには1200日掛かることになる。 3年以上掛けてパソコンを動かさなければ強さが判らない。 740 名前：デフォルトの名無しさん mailto:sage [2008/09/27(土) 15:51:03 ] PC1台で検証するならそうだな 741 名前：デフォルトの名無しさん mailto:sage [2008/09/27(土) 15:51:27 ] PCの性能で応答時間は異なるけど、一つが遅ければ全体に影響するから 平均応答時間程度にするとかにして、時間切れはツモぎりとかのほうがいいとはおもう。 742 名前：632 mailto:sage [2008/09/27(土) 15:58:26 ] 実際に色々なAI同士を戦わせてみよう！となったら、 麻雀のルールの他にも決めなければいけないことは あると思います。 それこそ制限時間とか、あるいは鳴くかどうかのラグを 情報として使うのはアリか、とか、相手のAIの傾向を 「最初から」入れておくのはアリか…等々。 いうなれば大会のルールみたいなものですね。 743 名前：デフォルトの名無しさん mailto:sage [2008/09/27(土) 16:06:22 ] 一手に３秒もかかったら、まともな統計は取れないですね 744 名前：デフォルトの名無しさん mailto:sage [2008/09/27(土) 18:55:36 ] >>729 733のいうノイズは、おそらく意図的な情報伝達ミスだろう 麻雀でいうなら見間違いとか切り間違いとか ゲーム理論の研究ならノイズも必要だけど、麻雀サーバには無用な仕様だよね 745 名前：デフォルトの名無しさん mailto:sage [2008/09/27(土) 19:06:32 ] ルールは実在ルールの中でもＡＩにとって処理しやすいものが良いと思う。 746 名前：デフォルトの名無しさん mailto:sage [2008/09/27(土) 20:24:35 ] >744 エラー処理あるいはテスト仕様としては必要かも知れないよ。 つまりクライアントやサーバーが全く期待していない 矛盾した情報を受け取った時に何を返すべきか？ 意味不明だと単にエラーを返すか、通信にリトライを要求するか？ そこまで仕様として決めておくのは面倒ではあるが、 下手をすると一回の通信エラーで全体が一気に倒れかねない。 747 名前：デフォルトの名無しさん mailto:sage [2008/09/27(土) 21:00:00 ] 今の仕様だと誤ポンも誤ロンもサーバが無視なのか・・・ クライアントが矛盾したロンやリーチしたら それはそういうときの処理をした方がいいのでは？ 748 名前：デフォルトの名無しさん mailto:sage [2008/09/27(土) 21:28:36 ] ルールとプロトコルが直行するように決めるなら ダブロンとかの扱いもちゃんとしておかないと 749 名前：デフォルトの名無しさん mailto:sage [2008/09/27(土) 21:50:04 ] 「コンピュータ麻雀のアルゴリズム」なんて本が出てるんですね。 Amazonのおすすめに出てきて驚きました。 750 名前：デフォルトの名無しさん mailto:sage [2008/09/27(土) 22:44:26 ] >>747 誤ロン誤ツモはチョンボだろ ノーテンリーチはかけられるようにしとかないと 戦略の幅が狭まる 751 名前：632 mailto:sage [2008/09/27(土) 23:31:05 ] >>747 自分の考えでは、誤ポンや誤ロンは、麻雀とってはまったく 不要な要素だと思っています。 極端な話、山を崩すのとたいして変わらないくらいで、 コンピュータ上で麻雀を打つなら、発生させないように するのがベストではないでしょうか。 ただ、>>750の言う通り、ノーテンリーチについては戦術として 考えることもできるので、それは悩ましいところです。 >>748 一応現状のプロトコルの仕様でもダブロンは発生させることが できると思います。 ただ、自分が作るサーバの実装では入れるつもりはありません。 752 名前：デフォルトの名無しさん mailto:sage [2008/09/28(日) 00:57:59 ] チョンボはありだろ。　役満がほぼ出るならチョンボして流すという手もあり得る 753 名前：デフォルトの名無しさん mailto:sage [2008/09/28(日) 09:53:14 ] なら、>>752 がチョンボあり版を作ればいいじゃない 754 名前：デフォルトの名無しさん mailto:sage [2008/09/28(日) 15:00:06 ] >>751 極端な話、その仕様だとクライアント制作者は和了判定を素っ飛ばして とりあえず毎回サーバに和了コマンド送信する処理でもいいことになる まあ毎回でなくとも形聴取ったなら海底河底で一応和了っておけみたいな 錯和が不要という考えは分かるけど何かしら対策はした方が良さ気 755 名前：デフォルトの名無しさん mailto:sage [2008/09/29(月) 02:02:32 ] そもそもサーバにそういった情報も問い合わせられるようにするなら そんな心配は無用 756 名前：デフォルトの名無しさん mailto:sage [2008/09/29(月) 14:42:31 ] ouc.daishodai.ac.jp/facilities/ams_labo/publication_bulletin.html これの麻雀研究特集号を読んだ人いますか？　どんな内容でしたか？ 「麻雀のベストプレイは存在するか」が気になる 757 名前：デフォルトの名無しさん mailto:sage [2008/09/29(月) 20:24:53 ] 鳴きのアルゴリズムって、基本的に 鳴いた場合の期待値　＞　鳴かない場合の期待値 の時に鳴くって考え方でおk？ 758 名前：デフォルトの名無しさん mailto:sage [2008/09/29(月) 20:28:24 ] >>757 一発消しだったり、自分が上がれる確率まで含めての期待値だったり 759 名前：デフォルトの名無しさん mailto:sage [2008/09/29(月) 21:13:42 ] >>757 ま、どんなときでも期待値の高い選択をすればそれでいいわけで、 期待値が計算出来ないってのが問題ということです。 www.ara3.net/hmr/expect.htm 760 名前：632 mailto:sage [2008/09/29(月) 23:46:31 ] >>754 > その仕様だとクライアント制作者は和了判定を素っ飛ばして > とりあえず毎回サーバに和了コマンド送信する処理でもいいことになる 別にそれでも全然構わないと思ってるんですが、問題あるでしょうか？ 761 名前：デフォルトの名無しさん mailto:sage [2008/09/30(火) 01:27:00 ] ある そんなのは麻雀AIじゃない 762 名前：デフォルトの名無しさん mailto:sage [2008/09/30(火) 01:31:02 ] 二歩を指した将棋AIが負けを宣言されるとするならば 誤ロンした麻雀AIはチョンボを取られるべきだ なぜなら、それが麻雀というゲームのルールだから 763 名前：632 mailto:sage [2008/09/30(火) 01:48:11 ] >>762 将棋の場合は二人なので、片方に対するペナルティは、 必ず対戦相手の利益になりますが、4人で打つ麻雀の場合、 あるプレイヤーに対するペナルティが、他の3人に対して公平で ないのが問題です。 そう考えると、可能な限りペナルティが発生しないというのが 理想だと自分は思います。 764 名前：デフォルトの名無しさん mailto:sage [2008/09/30(火) 01:56:28 ] >>760 抜け道があると「UMPでは最強かも知れないけれど〜」みたいな グタグタな流れになるので、できれば対策して頂きたいです 錯和してるのに続行は問題なんで、和了放棄とか特別ルールはどうですか？ 765 名前：デフォルトの名無しさん mailto:sage [2008/09/30(火) 02:04:15 ] >あるプレイヤーに対するペナルティが、他の3人に対して公平でないのが問題です。 チョンボは親子関係なく3000オールって雀荘もありますけど、それでどうですか？ 766 名前：デフォルトの名無しさん mailto:sage [2008/09/30(火) 02:10:18 ] 標的が和了するのを阻止するためだけに わざとチョンボされるかもしれない問題ってのも 考えられるからルール設定の扱いにしては？ 有効、無効はサーバ側で決定 局or半荘開始時にサーバからクライアントに送信される形で 767 名前：デフォルトの名無しさん mailto:sage [2008/09/30(火) 02:16:02 ] 補足しておく ハコテンで半荘終了であるとする ある局で特定のクライアントがトップ目であるとき チョンボクライアントが常にチョンボすることで 半荘のトップ目をとらせるという戦略が考えられるなぁと 768 名前：632 mailto:sage [2008/09/30(火) 03:29:23 ] チョンボについて意見が多く、それに対して自分の見解をまとめて みたんですが、あまりに長文になってしまったので sourceforge.jp/projects/openmj/wiki/chombo に書いておきました。 769 名前：632 mailto:sage [2008/09/30(火) 03:37:16 ] ちょっと書き逃げみたいになっちゃいましたが、自分としてはまず、 UMPでのサーバ/クライアントで麻雀を打てるようにする、というのが 第一にあります。 その次に、チョンボも含めたルールとか、あるいは実際にどこかにサーバを 立てるのか、どう運用するのかということを考えなければいけないと 思いますが、現状その段階についてはあまり具体的に考えていません。 # 正直、チョンボ云々より、実際サーバプログラムを作ったとして、どこで # 動かしたら良いかの方が悩みです(^^; もちろん議論自体は活発に行われるのは良いことだと思いますが、 とりあえず自分の現状のスタンスを表明しておきたかったのです。 770 名前：デフォルトの名無しさん mailto:sage [2008/09/30(火) 18:59:55 ] まあテスト用のサーバとしてうちで提供してもいいよ。 RDBMSを積極的に使ったシステムがいいなあ。 771 名前：デフォルトの名無しさん [2008/10/01(水) 00:31:11 ] つかさ、 チョンボの有無 ハコテンの有無 ノーテンリーチ、オープンリーチの有無 パオの有無 等など、、、 そんなのパーラメータ化して、サーバごとで管理できるようしろよｗ 2chだって"SETTING.TXT"で、板ごとの要求に合わせて 設定されてるんだし、ちゃんと参考にしとけよ kobe.cool.ne.jp/r_030/2ch_jikken/SETTING.htm sourceforge.jpで新しいプロトコルの作成を目指すなら、 それくらいの気のきいた仕様をちゃんと考えてからにしとけ 772 名前：デフォルトの名無しさん mailto:sage [2008/10/01(水) 00:38:37 ] >>771 基本姿勢が決まってないととりあえず動かすためのクライアントを作るのが難しいぞ 773 名前：デフォルトの名無しさん [2008/10/01(水) 01:11:34 ] 一番言いたいことは、個人で採用したいルールはサーバー側では 簡単に定義できるような柔軟なプロトコル仕様であって欲しいということ。 基本段階で決定するような、麻雀のルール決めはサーバ管理者の 裁量に任せればいいが、プロトコルの仕様という話ならば、 どんな特殊なルールであっても、単純に組み込めるようになってないと、 そもそもプロトコルとしての意味が無い 東風荘や麻雀ファイトクラブで採用してないような オープンリーチやフリテンリーチが固定で組み込 まれているようなプロトコルになるなら、絶対に使わないし、いらねえ 774 名前：632 mailto:sage [2008/10/01(水) 01:29:12 ] 何度も繰り返しになりますが、UMPでは麻雀自体のルールは定義する つもりはありません。つまり、「クイタンあり」みたいな情報をUMPでは 流さないで済むように考えています。 クイタンありかなしかはサーバの実装次第で、クライアントの実装では、 クイタンで和了ろうとして、サーバにコマンドを送って初めてわかります。 これだと問題だ！と考える方もいると思いますが、クライアントが人間で あれば、例えばサーバのHPとかに書いておけば良いし、AIだとしても、 どんなルールにも自動で対応するAIというのは、手間がかかるわりに 難しいので、それを考慮する必要はないと思います。 それこそAIを動かす際のオプションで指定すれば済む話です。 >>771のように、パラメータを受け渡しする方法だと、そのパラメータを 策定しなくてはならず、無数にある麻雀のルールの洗い出しとまとめが 必要になり、それこそ気の利かない仕様だと思います。 775 名前：632 mailto:sage [2008/10/01(水) 01:31:20 ] >>770 そう言って下さる方が現れるのを期待していました(^^ もしよろしければ、SourceForgeの方に自分のメアドが ありますので、そちらにメールを頂けますでしょうか？ 776 名前：デフォルトの名無しさん [2008/10/01(水) 01:39:01 ] >>774 了解です。それでいいと思います。 　クライアント→サーバ 　サーバ→クライアント で、やり取りされるアクションや情報が全て網羅されることを期待しています。 個人的な要望としては、誰かがロン・ツモで上がったときや流局のときに 手牌を倒したプレーヤの手牌情報は取得できるようにして欲しい。 この手の仕様では、サーバ側が必要とする情報だけしか定義されていなくて、 クライアントからでは情報が取ってこれないということがよくある。 ランダムに吐くログを整形して自分で作りこみをしないといけなかったりする。 それは単純化して欲しい。 777 名前：デフォルトの名無しさん [2008/10/01(水) 01:46:22 ] 何度も繰り返しになりますが、UMPでは麻雀自体のルールは定義する つもりはありません。つまり、「クイタンあり」みたいな情報をUMPでは 流さないで済むように考えています。 クイタンありかなしかはサーバの実装次第で、クライアントの実装では、 クイタンで和了ろうとして、サーバにコマンドを送って初めてわかります。 ↑　↑　↑ この文章を整形して、フロントページの前提に書いた方がいいんじゃね？ このプロトコルのコンセプトがはっきりして、初めて来た人にも分りやすい sourceforge.jp/projects/openmj/wiki/FrontPage 778 名前：デフォルトの名無しさん mailto:sage [2008/10/01(水) 01:55:46 ] 実装無ければ無意味。　まずは実装(サンプル)をうpしてほすい 779 名前：632 mailto:sage [2008/10/01(水) 02:43:52 ] >>777 FrontPageに>>776さんの「アクションや情報が〜」の言葉も頂いて 追加しておきました。 >>776 現状の仕様では、和了ったときには say <プレイヤー> ron または tsumo open <プレイヤー> <手牌> agari <プレイヤー> の順にクライアントに送られます。 流局のときには、 ryukyoku の後に親から順に open <プレイヤー> <手牌> もしくは close <プレイヤー> が送られてきます。 手牌の公開をすべてopenコマンドに統一したので、逆にわかりにくくなって しまったかもしれません。 コマンドの定義とは別に、本来はこういうフローも定義しないといけないんですが、 まだまとめきれていません(^^; 780 名前：632 mailto:sage [2008/10/01(水) 02:46:58 ] >>778 まさにその通りで、実際に動作する実装があれば、もうちょっと 具体的な話もできるようになるんですが、現在鋭意制作中で ございます(^^; 前にも書きましたが、ソースは随時SourceForgeのリポジトリに commitしているので、興味のある方は参照して下さい。 でもできるだけ早く、ある程度のものをリリースしたいとは思っています。 781 名前：デフォルトの名無しさん mailto:sage [2008/10/01(水) 12:48:43 ] ちょっと見たけど、牌は全てユニークなIDでやり取りしたいなあ、16進で2桁で済むでしょ？ あと、進行は全て実際と同じようにサイコロ2回振って山のどこから切り出すとか、 サイコロの出目も含めて記録したい。 山を提供するだけ、サイコロを提供するだけ、それらのやり取りを全て記録し、牌譜が出せるやつまで 別に持っていたいのだけど。（ここでDB使う） 782 名前：デフォルトの名無しさん mailto:sage [2008/10/01(水) 17:21:30 ] 第三者から見ると有る程度動く物が出来てからじゃないと無意味な議論を重ねてるようにしか見えないのだが？ どうせ鋭意制作中とか言っても完成まじかで「本業or学校or卒論等が忙しくなり・・・」で結局完成しない良くあるパターンに陥るのがみえみえ。 少しは完成させてからでも遅くは無いと思うんですが、どうなんでしょうかそんへん？ 783 名前：デフォルトの名無しさん mailto:sage [2008/10/01(水) 17:24:05 ] SourceForgeにあがったコード見ながら、サーバで試しに動かしながらレスしてるのだけど。 784 名前：デフォルトの名無しさん mailto:sage [2008/10/01(水) 18:45:22 ] >>774 >クイタンありかなしかはサーバの実装次第で、クライアントの実装では、 >クイタンで和了ろうとして、サーバにコマンドを送って初めてわかります。 え、事前にサーバーにルールを問い合わせたりできないの？ 785 名前：デフォルトの名無しさん mailto:sage [2008/10/01(水) 18:56:16 ] ルールのすり合わせの方法とかは必要なら追加になるだろうね。 AI前提だと、先にルールがある気がしないでもないが。

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef