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

めざせ最強の麻雀プログラム！
層の薄いこのカテゴリーなら、将棋やオセロよりも
ずっと簡単にその地位を手にいれられるぞ！

>>1
乙なんだが、せめて前ｽﾚくらい貼って欲しかった…
あと、Part2よりも2本場とかのほうが麻雀らしかったかも。

まぁとにかく乙

前スレ最後のほうでルールはまうじゃん準拠でって声があがったよ

前スレ　おまいら最強の麻雀プログラムしてみろよ
http://pc11.2ch.net/test/read.cgi/tech/1169642436/l50

まうじゃん的空間
http://www.amy.hi-ho.ne.jp/ishihata/maujong/

前ｽﾚ

おまいら最強の麻雀プログラムしてみろよ
http://pc11.2ch.net/test/read.cgi/tech/1169642436/

すまんこれから貼ろうと思ってたんだ。

＜参考サイト＞
とつげき東北HP
http://www.interq.or.jp/snake/totugeki/
まったりプログラミング日誌
http://kmo2.cocolog-nifty.com/prog/
あらのHP
http://ara.moo.jp/
デジタル麻雀論
http://www.jan-x.jp/

おれもまうじゃんdll作ってみようと思う。

C#で作りたいのだが型がどう対応するのかさっぱり分からん。
でもC#の生産性に慣れるとC++で組む気にはならんね。
調べてみるしかないか。もしやり方わかったら報告するよ。

> GUI表示で一局にかかる時間が多すぎるんですよ
> 一手一秒だとしても画面で動かして終局まで1分程度かかります
> 1000局の統計を取ろうとしたら、17時間かかるんです
だから、それが画面有り無しでどう関係するの?と聞いているのですが。

各自作成DLLが 一手一秒なら、画面なくてもそれなりに時間、かかるよね?

>>6
まうじゃんDLL作っても試行する部分がなきゃ駄目なんだって・・・
まうじゃんルールで、もっと簡単にDLL作れるメイン部分を頼む・・・

結局自分じゃ何もできない厨房だったわけだwwwwwwwwww

>>7
例えば一手100ms以内としても
まうじゃんだと画面で動く部分で時間がかかるんですよ
制限時間はある程度統計がとれる程度に制限した方がいいので１秒とは限らないです

> 「ノーウェイト」のモードあるじゃん。
> 一局数秒で終わる。
って書いたの読んだ?
それを試して、それでも問題だと言っている?

　　　　/::::i::::､:::ヽ､:::::＼:ヽ:＼::::::ヽ:::､::ヽ::､:',
　 　　/::i|::l::ﾄ､ヽ::､:::ヽ:､::::::＼::ヽ::::l::::ヽ::i:::i:::!
　　　/:/:!:::!:|::ヽ:＼ヽ::::､:＼::::ヽ:::ヽ!::::::i::|:::!::!
　　　!ﾊ::|::::i::l:|心､:ヽ::＼:ヽ_＼､＼:::ヽ:::|!::|:|i　駄目だ　こいつ・・・
　　　　i､:!:|:､N{､ﾋjヽゝ＼ヾｲ ﾋｊ　>､ヽi:､|!:|:l
　　　　　ヽ:!::ﾄヽ￣　l! `　　｀￣´　|::l::|:|j:,!:!　　早くなんとかしないと・・・
　　　　　　ﾄ､::! u　　　　　　　　　ｊ |::/lj:::!ﾘ
　　　　　　　 ヾ、　 丶 -　　　　u　ﾘｲ:|ﾘ
　　　　　　　　ﾘヽ　‐､ｰ- ､_　　 ／ｲ:::i
　　　　　　 rｰ'"ﾄ:lﾞ､ 　￣ 　 .／　 , |::!
　　　　　　/ ﾍ　ヾ　ヽ､ _,.　'　　 /　|:'

いままでこのAAがこれほどぴったり来るやつは見たことなかったぜ

>>11
どこにノーウェイトモードの設定があるんだよ?いずれにしても画面表示がある限り鈍いんだ

とりあえず>>8=>>10はﾄﾘｯﾌﾟでもつけてもらわんと、叩けんじゃないか!!wwwww

>>8
「試行」と「思考」を勘違いしてないっすか?
思考する部分のDLLを作るんじゃないの?

ageがトリップみたいなもんだなｗ

思考DLLを試行するメイン部分の作成が先だと思うんでけど・・・
まうじゃん本体で思考DLLを動かすと鈍いってことです

なめた口調と雰囲気でも丸分かりだがな

じゃ今後は>>8=>>10=>>11=>>17以外はsage&丁寧な言葉づかいを心がけていただけるよう、お願い申しあげます。ww

>>17
ホストプログラムができたらまたどうぞ。
ルールは、非常識なものでなければ（もしくは多少の変更が効けば）、
何でもいいよ。

では、さようなら。

げ、私は、乱暴な言葉、使わんといけんのけぇ?

>>13
「まうじゃん」GUI画面の「オプション」→「進行速度」→「ノーウェイト」って
違うのか？
これデフォルトは、「速い」なんだけど。
「オプション」で「自動了解」もチェックすれば、自動対局するし、
「ログ出力」すれば結果も見れるけど。

>>19
11は別人だろ

オプションって上にあるんだな　わからなかった

で、判定結果は?
#別人でしょ?、ってことじゃなくてね。
#使えそうでしょう?

うん
使えそうだね

>>11と>>13を間違えた…
ﾕﾙｾ!!(・∀・)

どのルールがいいんだ?

まうじゃんルール
http://kansai2channeler.hp.infoseek.co.jp/cgi-bin/joyful/img/4777.txt

ルール(仮)
http://kansai2channeler.hp.infoseek.co.jp/cgi-bin/joyful/img/4765.txt

大会系しかやってなかったせいで、標準入出力のexeファイルしか作れない件。俺ﾖﾜｽ
テンパイチェックと点数出力だけはもうすぐできそうだけど

句点「。」がないのも特徴。

>>27
ホストプログラムがある方。

>>28
どういうルールに基づくんでしょうか??

あと、
・日本語の読解力が無い
・まうじゃんのﾉｰｳｪｲﾄﾓｰﾄﾞすら見つけられない程の低ｽｷﾙ
も特徴に加えてくれ。

>>31
あー、自分のAI用のだよ。紛らわしくってごめんね
>>28の書き込み見ればわかると思うけど、ホストプログラム作れるほどの能力ないや、dllとかわかんないし
一応、東風荘第一ルールに基づいて組んでる。クイタンありなしと裏ドラありなしはdefineの部分で変更可能
別に可変にすればいいだけだからとりあえず組んじゃってる

>>32
・麻雀をまったく知らない
も追加

>>33
C/C++の場合、他者と対戦しようと思ったらDLLがいちばん簡単、それ以外はもっと複雑になると思われ。

形になってきている>>33さんにならって東風荘第一に統一しますか?
これなら相互比較することで点数計算の間違え等を発見できますから・・・

>>34
・牌ではなく駒と呼ぶ
も追加ね!

>>36
お前が>>33を見習わなきゃいけないのは
＞別に可変にすればいいだけだからとりあえず組んじゃってる
↑ここだ

ぁぅ、C#で組んでる。C++とかのがいいのかな
そこらへんはよくわからないからちょっと聞くかも。できるだけ自分で調べるけど
とりあえずこういう企画は一人が組みだせばみんな始めてくれるような気がしたから、
自分プログラミング全然だけど組み始めてみた。続いてくれる人いるならうれしい

役判定が作業過ぎて入力が面倒だよぉorz

あう、beはずし忘れたorz

お前ら弱いものいじめはやめろよｗ

ところで、麻雀の確率とかからの検証とかの論文とかを
いっぱい紹介したサイトがあったと思うんだけど
どこだったっけ？
誰かブクマしてない？

>>39
C#でも、DLLは作製可能

ちょっと趣旨が違うんだけど、
麻雀牌にICチップ埋め込んだらいろいろできそうだね。

これをフリーで悪用されるデメリットはあるけど、
　・自動点数計算　　..　　　おすすめ★★★★★
　・自動牌譜記録　　..　　　おすすめ★★★
　・牌効率分析画面　　.　　おすすめ★★★★
　・待ち牌画面表示　　.　　おすすめ★★★★★
　・向聴数画面表示　　.　　おすすめ★★★
　・ツモ切りLED点灯　　　　おすすめ★★★★
　・ツモ予告演出　.　.　.　　おすすめ★★★★★

wktkしてきた。

>>33
beの紹介文にいろいろ突っ込みどころがあるのは置いとくとして…

>とりあえずこういう企画は一人が組みだせばみんな始めてくれるような気がしたから、
>自分プログラミング全然だけど組み始めてみた。続いてくれる人いるならうれしい

その意気だ!!宇宙麻雀みたいにｸﾞﾀﾞｸﾞﾀﾞ言ってるやつよか1億倍上!!ｶﾞﾝｶﾞﾚ!!

>>43
画像認識で十分いけると思うんだよね
これならイカサマ無いし今の全自動卓にも
アドオン可能だし
伏せ牌がコンピュータにわかるってのは
やっぱりイヤだな

>>42
ならこのまま組み続けていいのかな、ありがと

>>44
beは突っ込んじゃだめっ
とりあえずがんがる、できたらソースうｐしたほうがいいのかな

>>46
うｐｷﾎﾞﾝ

http://sns.atfb.jp/show_profile.php?no=5
(・∀・)ﾍｰ

まうじゃんで、数千回試合の統計はどうやって取るんだ?

>>45
なるほど。コストかからなそうだね。

43は需要なさそうだから世界に１台だと億いきそうだなぁ。

それはもっと形になってきてからでいんじゃない？
誰かのdllにそういうのを出力する機能をつければおｋ

また、他力本願なレスだな。　可能かどうかもわからないのに。

全スレですべてのメンツ分解を求めるソースうpしたぞ

http://kansai2channeler.hp.infoseek.co.jp/cgi-bin/joyful/img/4771.txt

間違えた　
一種の数牌のみ0枚から14枚までのあがりの可能性のあるやつだ

＞＞５３
で？
ゴミはｲﾗﾅｲから

ううう。
>>21で、
> 「ログ出力」すれば結果も見れるけど。
と書いたのに・・・

「ゲーム開始」でgrepするとこんな感じ。
mm.log(1): 07/27/07 22:08:46 ゲーム開始
mm.log(827): 07/27/07 22:09:06 ゲーム開始
mm.log(1524): 07/27/07 22:09:22 ゲーム開始
mm.log(2496): 07/27/07 22:10:19 ゲーム開始

終わりはこんな感じ。
<ゲーム終了>
1位 なきのりう 34400点
2位 面対子 31600点
3位 ぴこたん 23000点
4位 Dummy K.I. 19000点

集計が大変とか、ログが大きそうとか、そういう問題?

あがりはこんな感じ。

・・・
・・・
Dummy K.I. : <捨て牌 : 発>
なきのりう : <捨て牌 : 白>
ぴこたん : <捨て牌 : 二索>
面対子 : <捨て牌 : 東>
Dummy K.I. : <ロン>
　　　　　　　　　　　　　
四五六七八九�C�D�E�V�V東東
ドラ : 四索
裏ドラ : 九筒
<役>
リーチ 1飜

40符 3飜 1300点
<点数>
ぴこたん : 23000 + 0 = 23000点
面対子 : 32900 - 1300 = 31600点
Dummy K.I. : 15700 + 2300 = 18000点
なきのりう : 35400 + 0 = 35400点

>>53
そのテーブルの価値は、砂粒1つぐらいの意味しかない。
俺はそのテーブルの必要性を感じていない。

>>58
>砂粒1つぐらい

すげー過大評価しすぎｗｗｗｗｗ

こんな糞テーブルの存在意義なんて
砂粒すら満たないよ

>>56
せめて東風荘形式でログだせよ

それ以上にはやくソースだせよ

なんだかまうじゃんのDLL作りになりそうだな。既存のもので他にある？俺は思いつかないな。
受けるデータは個々の点数と捨て牌、ドラ、自分の手牌、ツモでOK？
で出力は捨て牌とリーチ、鳴き(ロン)でOK?

MJSimが有る、説得すればきっと出してくれる。　たぶんな

>>60
言っている意味が分からないのだが?
もっと詳しく説明してくれるかい?

>>56、>>57は、「まうじゃん」の設定で、「まうじゃん」がログを出力してくれる、という話だよ?
既に「まうじゃん」にそういう機能がありますよ、と私は言いたいのだが、
なにがご不満ですか?

ネット麻雀に接続させて対局するとかどうなんだろうね？
場所によっては規約にかかりそうだけど

なんか>>53への反応見てるとうｐする気なくなるな、なんか厳しそう
それでもすると思うけど

うｐしたのが53じゃなかったらこんな冷たい反応じゃなかったよきっと

>>64
コンピュータも参加できるネット麻雀インフラを整えて
公開すればいいじゃないか

>>53みたいなウンコプログラムなら
反応は冷たいよ

>>62
前スレでアップされたやつ落とせた？
すぐに落とせなくなっていた。どうしたのだろうか。

>>63
おれは>>60ではないのだが、東風荘形式であれば、すでにたくさん存在する東風荘のツールが使えるのがいいと思う。
牌譜の再生、成績統計、分析ツールの作成が必要ない。
MJSimのAIを作る人が出てきたのは、そのためじゃないかな。

>>33
>>6とは別人？
ホストも新規にC#（.NET）で作るの？

（>>6と同じ人なら）C#でDLLを作れるけど、例えば、まうじゃんのDLLを直接は作れないと思うので、その場合は、
まうじゃん本体→ブリッジ的なDLL（これはC++で作る）→C#のDLL
みたいにする必要はあるな。

C#でホスト作ったらどうかな？
.NetのDLLもネイティブDLLも読み込む形にしやすいと思う。

冷静に考えたら、手牌パターンって あんまり数が多くないよね
せいぜい数万パターンにしかならないんじゃないか？
色違いや字牌を同一視したり上下逆にすれば

前スレで書いたよ


数字19、2〜8、白発中、東南西北のコーツトイツは同一視し
トイツ　8通り、　順子　21通り、コーツ8通りで全部登録しても5Mバイトしか食わない

国士無双、緑一色、四槓子の判定をまずやって、
三槓子、チートイツ、三色同刻、場自風の加算を求めてから
データベースを引けばいいんだ

>>72
上がり形のみの組み合わせじゃなくて

>>73
一種の数牌だけで40万あるぞ


849 名前：287[sage] 投稿日：2007/07/25(水) 10:56:42
>>846
やってみたけど、微妙に結果が違うな。なんだろ。
面子の組み合わせは保持してないが、こういう結果になった。

a) 一種類の数牌で、ルール上出現する(各4枚以下、計14枚以下)組み合わせの数
405350

>>74
たとえば数牌が2枚のときは 意味の上での組み合わせは
2つの牌の距離分、つまり8パターンしか種類は無いよね。
アルゴリズム上、1,8 も 2,9 もほぼ同一視できるという考え。

牌の組み合わせ数ではなく、牌同士の距離のパターンで
考えればパターン数はぐっと減る

距離が0なら対子、1なら塔子、2ならカンチャン、3ならスジ、・・・
って感じでパターン分けすれば 思考ルーチンにもそのまま使える情報に
なる。多分なると思う。なるんじゃないかな。

冷静に考えたら、これ ただの微分情報のDB化だな。
パターン認識の初歩だた。 何も目新しくなかった・・・orz

>>前スレ349氏
今朝はじめてこのスレに来た者です。
当方、AI作成中でして、氏のソースをぜひ参考にさせていただきたいのですが
再アップお願いできないでしょうか？

>>69
別人です。

今アルゴリズム考えているのでまだ全然ソース書いてないけど。

自分以外にC#使ってる人がいるのは心強いです。

AI書く上でC#がC++より生産性高いってどのあたりの話？
GUIとかならC#のうまみは理解できるんだけど。

deleteの存在だけで十分だろ。

>>78
349のうpしたやつ持ってるけど
オリジナルの部分は、↓これだけかと


//ひたすらツモ切り
case MJMSG_TSUMO:
//ツモ切りする
Player->Action.Type = MJACTION_SUTEHAI;
Player->Action.Sutehai = 0;
break;

他者が指したとき、ツモったときにそれぞれロンとポンとチーとカン、カンのフラグと
牌番号0-33を渡せば麻雀プログラムって出来るよね?

自ツモ　0-33　、　ロン(カン)出来る牌　34-67　、　チー出来る牌　68-101

と番号づければツモとそうでない状態が統一的に扱えるぞ

マンズ：1〜9
ピンズ：11〜19
ソーズ：21〜29
のように10とか20欠番にして数字と1の位そろえた方がプログラム組む上で直感的でわかりやすくないか？

それも16進数でやれば違った種類の牌はつながらないから、
メンツの分解を統一的なアルゴリズムでやれてプログラムが簡単になると思うのだが。
マンズ：0x11〜0x19
ピンズ：0x21〜0x29
ソーズ：0x31〜0x39
東南西北：0x41,0x51,0x61,0x71
白発中：0x81,0x91,0xA1
みたいなかんじで。
（字牌がとびとびなのはメンツ分解のときに順子を作らないって判定をプログラムに組み込まないようにしたいから）

>>85
そんな事は各人がやればいいことで、管理元からの情報を変換してやればいいだけだな
内部の情報まで統一する必要は無い

>>86

>>84にレスしただけだ。偉そうに分かり切ったことを。

前スレ349氏は消えたのかな。消える宣言してたからな。
MJSimは落とせたんだが、作者は今どうしてるのだろうか。349氏によれば信頼のおける人とのことだけど。
まとめサイトみたいなの作って、そこにこういう実行ファイルなりソースなりを置くようにしたいんだけど作者の許可を得る方法がないからなあ。

でもとりあえず同じような処理はライブラリ化してみんなで使えるようにしたほうがいいよね

>>87
すまんね。だれが宇宙麻雀論の人なのか分からんので

宇宙麻雀論の人ってリバーシ１の事？

>>91
リバーシ１の事は知らないけど。「＝」なの？

>>92
リバーシ１はコードにforeを使う奴

>>93
あぃ、了解。
話戻すけど、MJSimはCOMが鳴きたい牌があるときは捨て牌を知らせる時に同時に知らせてるの？
捨て牌毎にメッセージ受け取って帰す形？←こっちが一般的？

自分がツモった牌　0
右が捨てた牌　1
対面が捨てた牌　2
左が捨てた牌　3
と駒番号を渡して、思考プログラムの応答を待てばいいと思うぞ
ツモも捨て牌も番号の違いしか無くなる

ポンやチーやドラや牌列の得点は尋ねると教えてくれるようにする

　 　 　 ｨ";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;ﾞt,
　　 　 彡;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;ヽ
　　 　 ｲ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;r''ｿ~ヾ:;;;;;;ﾞi,
　　 　 t;;;;;;;ﾘ~｀ﾞヾ､;;;;;;;;;;;;;;;;;;;;ノ　　　　i,;;;;;;!
　　 　 ﾞi,;;;;t　　　　ヾ-‐''"~´_,,.ィ"ﾞ　　ヾ;;f^!　　　／￣￣￣￣￣￣￣￣￣￣￣￣
　　 　　ﾄ.;;;;;》　　＝ニｰ-彡ﾆ''"~´,,...,,.　 ﾚ')l.　＜　おまえは何を言っているんだ
　　 　　tﾞヾ;l　　 __,, .. ,,_　　　,.ﾃ:ro=r''"ﾞ !.f'l. 　　＼＿＿＿＿＿＿＿＿＿＿＿＿
　　　 　 ヽ.ヽ　ｰ=rtσﾌ= ;　 ('"^'=''′　 ﾘﾉ 　
　 　 ,,.. -‐ゝ.>、　｀ﾞﾞﾞﾞ´　,'　　ヽ　　　. : :! /
　~´ : : : : : ｀ヽ:.　　　 ,rf :. .　:.: j ､　. : : ト､.、
　: : : : : : : : : : ヽ、　 /. .ﾞｰ:､_,.r'ﾞ: :ヽ. : :/　ヽ＼、　
　 :f: r: : : : : : : : !丶　 r-､=一=''ﾁ^　 ,/　　 !:: : :｀丶､_
　 : /: : : : : : : : :!　ヽ、　 ﾞ ''' ''¨´　 ／　　 ,i: : : l!: : : : :｀ヽ､
　〃: :j: : : : : : : ﾞi　　 ｀ヽ､..,,__,, :ィ"::　　　,ﾉ:: : : : : : : : : : : :＼
　ﾉ: : : : : : : : : : :丶　　　: : ::::::::: : : :　　 /: : : : : : : : : : : : : : : :＼

よし、今から、サンプルAIのソースつきMJSim公開してしまうぞ。
初歩的なAIだけど、それなりに強いと思う。

みんなGETしてくれ！

何故かって？、ここ数日で新しい方法論のAIアイデアが出てきて
作りたくなったから、尚且つ、対戦相手がいるといいから。
問題は時間だが・・・、今度は最速＋戦略を目指そう。
MJSim自体のメンテは出来ないので、あるがままで使うしかない。
それで文句があるやつは無視。
点数計算のミスは極僅かだろう、その僅かが気になるAIなど当面
誰も作れないと思われ。私も無理だ。

MJSimの作者さん。もし見ていたら許してくださいませ。

MJSimのDLLインターフェースは簡単である。
詳細はAIInterfaceV1.txtを参照。
インターフェースは簡単だが、渡されるデータ構造はそれなりに複雑である。
単純にいって、
１．コール簡単、データー複雑
２．コールが複雑、個々に渡されるデーターは簡単
の2種類だが、結局複雑さはどちらも同じ麻雀の処理は複雑なもの。

作製はMJSimAI.cpp内のＣＡＳＥ：部分を書くだけ。

case MJMSG_TSUMO:
　がツモった時の処理。
case MJMSG_REACTION:
　が他家が棄てた時の処理

自分が南家の時。
　親が棄てたら　case MJMSG_REACTION:　が呼ばれ。
　ツモが来たら　case MJMSG_TSUMO:　が呼ばれ
　自分のス棄て　case MJMSG_REACTION:　が呼ばれる。
　西が棄てたら　case MJMSG_REACTION:　が呼ばれ。
　北が棄てたら　case MJMSG_REACTION:　が呼ばれ。

この繰り返しです。

case MJMSG_GAMESTART:break; //東風戦開始時
case MJMSG_GAMEEND:break;
case MJMSG_KYOKUSTART:break; //局開始時
case MJMSG_KYOKUEND:break;

は試合の開始や終りです。

いろいろ入ったMJSim　　サンプルAI付き
↓
http://uproda11.2ch-library.com/src/1118241.zip.shtml

MJSimを実行すれば、東風荘の麻譜データーが出力される。

PW　=　MJSimEXE　入れ忘れ。

このサンプルAIは、C++コードだが、OOPしていない。
OOPしたい場合は多少のテクニックが必要。
ネット上でも探せば見つかるだろう。
私は、CASE:文から先をOOPとして作製している。

上のはミス・・・・・・
ソース見たら、特別テクニックなど必要なかった。すまぬ。
（何かと思い違いをしたようだ・・・・）

キタワ*･゜ﾟ･*（n‘∀‘）η*･゜ﾟ･*ァ !!!!!

あの頃の議論ができるなんて久し振りで、
ウレしすぎる！！！！！！！！！！

>>349
うｐありがとうございます。
私も全力を挙げて作成いたしますので、できあがったらぜひ対戦しましょう！

>>99 = 前スレ349
ありがたくいただきますた。

>>90
やつは今のところ100%ageているぜ。

そろそろ逃げ出す気がするけどね。

やつは厚顔無恥だからそれはない

昨日おれはゾンビを相手にするような感覚を覚えたぜｗ
どんなに攻撃してもダメージを感じてないような。

>>99
MJSim自体のソースはないですか？

「全部登録しても5Mバイトしか食わない」をNG登録すればよい

誰か、やってみてもいいアイデアその1

自分の手から可能な役の点数と可能性を計算して期待値をだし、最良を選ぶ。
リャンシャンテン以下が可能ならば、リャンシャンテン以前と以下で
ロジックを変える方法。
オセロで言う所の完全読みに入る前と後のようなもの。
（完全読みとは性格が違いますが）

>>109
他者のソースが入っているので、私には絶対に無理です。許可取れないし。
もうHPも何もなくなっていますし。

誰か、やってほしいアイデアその２

・モンテカルロ法による危険牌の割り出し
・モンテカルロ法による山牌の予測。

今度組み込みたいかも。

まずはなにより役の点数を求めることだ
期待値が出せん

やってみたいアイデアは秘密でつ。
うう〜〜仕事が忙しくて寝ます。おやすみ〜

>>113
モンテカルロによる当たり牌や山牌予想は大筋でできてますよ。
比較対象が少ないので評価は曖昧になりますが
山牌読みは少なくとも「見えてる枚数での予想」より高精度で読めます。
危険牌読みは、麻雀打ちの直感の範囲内では、そこそこ的を得た
予想ができているように見えます。

現在は乱数に擬似乱数を用いているのですが、この乱数に工夫を加えることで
さらに高精度予想ができるのでは？とも考えております。
精度向上に＋αでもっともっとネタがあるのですが、それは出し惜しみということでｗ

>>99落としました。Cは暫くやってないので時間掛かりそう・・・
>>105再び了解ｗ

とりあえずは見えている牌をカウントしてやる＆勝手読みで相手の手持ち牌を求める
位しか浮かばないなあ。自分と似た思考になるのは間違いない
不明の牌から得点の高くなる可能性のある牌を見つける、とか？(速度が・・・)

>>98
>１．コール簡単、データー複雑
>２．コールが複雑、個々に渡されるデーターは簡単

まうじゃんだと、誰が何をしたかのみをパラメータにセットした状態で呼び出され、わかりやすいのだが。

MJsimの場合は、常に卓全体とプレイヤー全員の状態がそのまんま送られてきて、
誰が何を捨てたか知るにも、牌を捨てたAIの河の配列を見に行かないといけないみたい。

・・・まあ、それもある意味わかりやすいとい言えんこともないか。

>>118
ソースに目も通さずにこんなこと聞くのはどうかと思うけど時間がないので
その方式だと、誰かがリーチしたときにどれが安全牌なのかを確かめるときに、途中で鳴きが入ると厳しくない？

>>119
>鳴かれた牌はマイナスの値になる。
>-19は19（9ピン）が鳴かれた。

だってさ。
MJSim.hより。

誰に鳴かれたのかはわからんみたいね。

おまいらMJSim開発前に点数計算しろよ最低二人は一致しないと使い物にならない

ｷﾀﾖｷﾀﾖｰ

誰が鳴いたか分からないってことは、効率重視で行く事になりそうかなぁ
ブンブン丸は好みじゃないんだけどな。

「最低二人は一致しないと使い物にならない」はNGワード

この板もIDあればいいのに
あぼんしやすい

おまいら簡単明瞭な設計したよ　これでやってみるか

ホストから送られるデータ　
(a, b)の二つのペア
a=0 ツモ　、a=1右側　a=2 中央　a=3左側　a>=4 他者のあがりなど、bは牌番号をセットされる
例えば、対面が1を捨てたならば、(2, 1)が送信される

ホストへ返却するデータ
(a, b)の二つのペア
a=0 手牌を捨てる　、a=1　ロン　a=2 ポン　a=3　カン　a=4　チー 　a>=5 オプションを尋ねる(ドラなど)、bは牌番号をセットされる

ホストが聞かれると答えるもの　ドラ表示牌、自風、場風、他者のポン、チー状態、得点など

確かにそのとおりだな。
「宇宙麻雀理論」とか「リバーシ１」とかいう奴のカキコミは
完全に消し去りたい。
実力もないくせにスレをどんどん汚していく。

「(a, b)の二つのペア」もNGワードしておく

飽きるか成果が出るまで好きにやらせとけ。どうせ元々過疎スレなんだし。

入出力が単純な方がいいと思うんだよ　126のようにやれば、入出力はフラグと一変数のみですむ

点数計算が出来れば、ホスト部分は簡単に作れると思うよ・・・

>>131
入出力が単純でもルールを自分で定義してもいいから、早く作ってくれ。

NGワードと聞くと某クイズ番組を思い出す俺はどうしたら・・ｗ

高速化のために、連続ポンなどで手番が回ってこなければ、ホストからの送信は無しにして
自分が動かせる(捨て牌やポンなど)ときのみデータを送信するようにした方がいいな
オプションで残り牌数や、他者の状態を聞けるようにすればいいので

>>134
賛成だ。早く作ってくれ。
書き込むのは出来上がってからでいいよ。

今日、国士無双１３面待ちを達成した俺様が見学にきましたよ。

>>136
待ちを達成したってことはアガれなかったのね

じゃあ国士だけ狙うDLL書くとするかｗ(ウソですすいません)

マンガン縛り(7700は8000で)DLL
なんて作ったら面白そうだな

山と手牌を入れ替えるDLLはなしだろうか・・・

それなら爆弾DLLとか千鳥DLLとかできるじゃないかｗ

天和仕込んだらちゃんと天気の話題を振るんだぞ

賽の目は２の２でｗ(そろそろ止めようｗ

いつのまにここは哲也ｽﾚになったのか…
２の２失敗したら自主的に引退するAIｷﾎﾞﾝﾇ

>>138(俺)、>>139は使い道は有りそうなんだけどな

>>144
PC「ﾎﾞｳﾔ　ｵﾚﾊ　ｼﾞｭｸｶﾗ　ｷｴﾙｾﾞ」
そのAI最高なんだけどｗ

九蓮上がったらマイドキュメントとデスクトップのファイルを全て
nyに放流してからHDDフォーマットしないと駄目だろ

>>123
遅レス、他家のフーロが見えて、誰から鳴いたか見えるようになっている。
これで分かる。

MJSimはジャン卓そのものがデーターとなっている感じ。

>>116
いいね〜〜、ぜひ実装して検証してみたい。AI作るのが先だけどね。

>>118
データーアクセスのための、基本ルーチン出来ると思う、と言うかあります。
公開してみようかな。

おまいら基礎が大事だ　役、基本点がもとめられずに思考できるかよ
共通ルーチンを上げてくれ

>>150
>おまいら基礎が大事だ　役、基本点がもとめられずに思考できるかよ
私なら出来るぞ、できないのか？

>共通ルーチンを上げてくれ
君の望むルーチンは皆無だ、諦めろ。

>>150
ストレートに言おう。
何かが出来なければXXができないと、いいわけを言う人間は、もっとも無能な人間が言う言い訳だ。
他のせいにして自分がさも出来るのに、他のせいで出来ないという見苦しい言い訳だ。
他人のせいにすると楽だからな。

世のAIの殆どは、役も基本点も全然無いか、極一部だけ持っているに過ぎない。
それでも、立派にAIは作製可能である。

>>151
ツモ切りとか、ランダム打ちは出来るけどさ・・・
点数出せなきゃ最強のやつは作れんよ　
動くやつは誰でも作れるが

>>150
アドバイスをやろう。
役はリーチ、ピンフ、タンヨウだけでやれ。
ついでに役牌を考慮しただけで、立派なAIが作製できる。
もちろん符も計算するな。
もしこれで、君のAIが出来れば、立派に動作する。
みんなも感心するAIになる可能性が有る、すぐ作れ。

MJSimのAIより、東風荘第一の点数を正確にもとめることが先決

>>153
言いから動くやつを作れ！
最強はそれから考えろ！！！！！！
これ以上、最強を言い訳にするな！！！！！見苦しい！

>>155
一歩も踏み出せない君は、何をやっても人生の負け組み確定だ。

>>152>>156>>157
無駄

おまいらここみてくれるか?
メンゼンでの役の確率が計算してあるがそれぞれ一致してない・・・
役を正確に求めることと、その確率を求める事は困難であるといえると思う
複数人での一致を確かめて進めるべきだと思う


http://www.ix3.jp/hiii/02mahken/1-02yaku.htm

http://majanjan.com/4/45/

http://homepage2.nifty.com/rally_tate/mj/3-9.htm

アドバイスにもう一つ。
正確な点数計算はとても複雑で計算時間も掛かる、君が望むような速度は不可能だ。
もちろん、魔法のテーブルなど現在の環境では不可能だ。
結局は限定した内容で最良を考えるしかない。
この、限定された環境で最良を考えるのが楽しい。

君はテーブルをガンガンスペックダウンしたではないか。
何故、点数計算はスペックダウンしないのだ？
最強など誰も作れない、でも、作ってみる事がいい。
MJSimのサンプルAIを理解して、改良が出来れば。
それで立派に麻雀AIが作れるようになる。
必要ならアドバイスもしよう、説明もしよう。

・・・・うぐ、上で349って出てしまった、バレバレ　orz

例えば、こんなに違う

七対子
３．２％　 (ひいいの麻雀研究)
２．４％ (勝ち組の麻雀　理想雀士をめざして)
１１．７％ (麻雀を科学する　数理と確率による麻雀の必勝法)

ジュンチャン　
０．３５％　 (ひいいの麻雀研究)
０．４％ (勝ち組の麻雀　理想雀士をめざして)
０．０５％ (麻雀を科学する　数理と確率による麻雀の必勝法)

>>159
まったく思わん。
違ってて当然、理由も有る。理解できないだろ?

>>159
で、だから何？お前が指摘すれば

つーか、ウンコな指摘しかできないウンコさんが
いなくていいから出て行ってもらえる

麻雀知らない奴に言われてもねぇ…寝言は寝てから言えとしかアドバイスできないな〜

ちなみに>>159は今後コテとトリップ付けろよ、NG指定しやすいから。

>>160
でも、テーブル方式は爆発しない方法で作れるよ

>>161
データーを取る環境と母体が違うから、違ってて当たり前。

>>165
理解してまつ。

コテは「宇宙麻雀雀士」ってしろよ、馬鹿にしやすいから

数字19、2〜8、白発中、東南西北のコーツとトイツは同一視して
データベースを作れば5Mバイトしか食わない

例外として、国士無双、緑一色、四槓子の判定をやって
三槓子、チートイツ、三色同刻、場自風の役の加算を求めてデータベースを引けばいい

宇宙麻雀雀士さん（君？）、君のテーブル議論は、みんなにいい刺激になったんだよ。
本人は理解していないかもだが、分かる人には分かっていた。ありがとう。

>>169
もういいよ、ウザイだけだから。

ソースも出さずに、使えもしないウンコ仕様だけ
書かれても、スレが汚くなるだけだから

MJSimだって正確な点数を計算しているかどうか分からないじゃないか
もし間違っていたら、強くないのに強いと判定されてしまう
確認のために複数人の一致は必要

　　　〃∩ ∧＿∧
　　　⊂⌒（ 　・ω・）　　うん　そうだね
　　　　 ｀ヽ_っ⌒/⌒ｃ 　　　　
　　　　　　　 ⌒ ⌒

>>172
ついに他人の悪口を言い始めた。

だから、おまえもMJSimを動作させて、お前が言う
「複数人の一致」のために点数計算の確認して
やれって言ってるんだよ。

それが出来ないなら、このスレに2度と来るな

>>169
もっと効率いい方法があるだろ。

そもそも、>>169の方法だと
大して多くは無いが無駄だらけで気分が悪い

>>175
俺、役確定や上がり確定じゃなくて、手分析でテーブル使うぞ。

>>176
オレもそうだよ。ていうか役判定にだけテーブル使うなんて
もったいなさすぎ

>>173
かわいいな

>>177
やっぱりそうか、考える事は同じだな。
しかしだ、実装で差がつくと思う。　どんな実装になるか興味があるな。

数牌のメンツ分解と役判定を高速に出来れば、次のように手が求められます

14枚の牌を調べ、役が出来ていたらbreakして、
役が出来ていないなら見えていない牌の中から、ランダムに一枚加えて
どれか一枚を捨てたら、役が出来るならその駒に役の得点を加算する

さらに、もう一枚ランダムに加えて、どれか二枚を捨てたら
役が出来るなら、その駒たちに役の得点/2を加算する
これを終局まで試行する

そして制限時間がある限り、はじめからやり直して得点の加算を続ける
すると、役が揃いやすい捨て牌に得点が集まります

>>180
糞仕様の話はいらないから早くソースあげてね。
それに、早くMJsimに実装してくれないか？

ところで、みんなのとこのルールでは ダブ東の頭は4符？2符？

実は、プログラミングが苦手なんだ
数牌のメンツ分解数も、単独では正解にたどり付けなかったかもしれない
自分の解答よりも、他人の解答の正解率が高いだろうから
だれか飜数計算を上げてくれないかと思っているところである

苦手があるのはいい事だ。克服する喜びがある

>>183

ついにお前の本音が出たな。
俺もそう思ったよ。

つまり、お前がプログラム出来ないから、お前の糞仕様に
付き合ってくれる奴を探して、このスレを荒らしていたんだろう

つか、プログラミング苦手なら、このスレに来るなよ

ルールは知らん。プログラムは苦手。なんでこのスレにいる？

>>154 >>160
言いますね〜（笑）アドバイス的確すぎやしませんか。
相当麻雀ＡＩ作成に熟知しているようにお見受けします。
私もアドバイス欲しいくらいですよ。

私もＡＩを組みましたので、牌譜あげてみます。
まだ鳴きも降りも教えてないのでドヘタゼンツ君ですがね･･･
ttp://uproda11.2ch-library.com/src/1118570.zip.shtml

>>187
ＤＬパスは　mjscore です･･･

1118570.zip DLKeyが一致しませんでした

>>185
いや、飜数計算は基礎なんだよ
ここをおろそかにしたまま、各自が独自のMJSimの思考エンジンを作り出すようになっては
たまたま、MJSimで計ったら強かった弱かったってなってしまうんだよ

DLできたよ

>>187
見ました、ずいぶんまともなAIですね。素晴らしいです。
聞いちゃうけど、オリジナル？　サンプルの改変ですか?
答えたくなければ答えないでOKです。
もし私で、答えられる事が有ったら何でも聞いて下さい。

>>190
は？なんだそのウンコな反論は。

誰も、飜数計算をおろそかにしてないい。

お前の力で早くMJSimの飜数計算が正しいor
間違っていることを証明しろって言ってるの

出来ないなら何も書くな、糞野郎

ん〜、極端に間違っていない限り、同じコードで採点するんだから問題ないだろ？
それとも、それで差が付くほどの立派なものを組んだのか？
後々問題になるだろうが、それほどのものは出てないな

ちなみに、サンプルを強くするための一番簡単な方法論に。
もう1段検索を深くすることです。
それと、見えている牌から、見えない牌を割り出し、それの確率を入れると
もっと強くなります。

サンプルで疑問点があれば、短文でなら説明します。
時間が少ないので、すぐ庭答えられないかも。（出来る範囲で）
AIの性格付けも、単純であれば比較的楽に出来るかも。
明日休みだけど、フラフラでもう寝まつ・・・Zzzzzzzz

>>192
完全オリジナルですね。いくらか下積みがあって、牌譜化環境等もできあがってて、
最近ここが盛り上がってきたので、作ってたプログラムをいくらか形整えて
打たせたのが>>187です。

＞答えられる事が有ったら何でも聞いて下さい。
ではお言葉に甘えて。
>>187のＡＩは、14枚の牌形から、
打牌候補を切り、1枚ツモり、打牌候補を切った時点で、評価関数を呼び出して
元の14枚牌形から打牌を選択しています。所謂一手先読み、になります。
これをＮ手先読みにすることが可能なのですが、現状の処理スペックだと
一手先読み･･･一回の打牌選択あたり0.001秒
二手先読み･･･一回の打牌選択あたり約2秒
となってしまい、現実的な処理時間では二手先読みが限界となっています。

そこで、単刀直入に申し上げますと、>>192氏のＡＩの性能（できればその手法も）
断片的でもいいので教えていただきたい。
サンプルでは、ターツ毎の評価をしていたようですが、今作成中のＡＩの路線も
その方針でいくのでしょうか？

>>197さんへ、>>180のようにやれば、最終手までの読みが出来ます
捨て牌を選んで、それごとに残っている牌からまたツモるとやっては分岐数が多すぎます
>>180なら分岐は無いです　すぐに終盤になります

>>198
まだ、お前の糞仕様を薦めてるのか。
お前の糞仕様の方が分岐が多いぞ。
それも気付かないのか、糞野郎

もし分岐で読むのならば、手の優先順位を決めておき、MTD法がいいと思いますよ

概要としては、
f=予測値を決めておき、それより評価が良ければ、その枝はそこで読むのをやめ上位ルートへ戻ります

fを超えるのが無かったら、もっとも評価の高い手の得点を上位ルートへ戻します

>>200
だからその分岐にどれだけ負荷かける気だよ。
「麻雀」と「プログラム」知らない奴が思いつきで書くなよ、糞野郎が

別人ですが、参考になれば
ネックは４シャンテン前後なので塔子で分割してなら、それ用の評価関数を用意。
(例：単騎<辺塔子<間塔子<両塔子<対子<刻子<順子)
で、面子候補それぞれに対して加算して求めてましたね。４シャンテンで最大100通り行くかどうか位
(※ただし、面子候補に単騎が二つ以上ある場合は別の方法にしてました。)
これだけだと不満なので、残り枚数や色、三色などの評価もしたい所ですけど

４シャンテン以上なら枝もクソも無いだろｗ
普通に聴牌目指してひたすら不要牌切るだけ
相手の聴牌気配とか感じるのはそこまで出来た後の話だ

>>203
麻雀知ってる？

>>204
４シャンテン以上、ということはほとんどの状態で
孤立牌・不要牌が複数あるので、場風と手牌の偏り具合から
機械的に（＝別の評価関数で）捨て牌選択が可能です。

というか、まずそれなりのものを作ってから順に次に取り組めよ

とりあえず何でも作って
土台を完成させろよ。 話はそれからだろ。

七対狙いオンリーの思考ルーチンでも
対戦用ライブラリのAPIに必要なエッセンスが
半分以上つまってんだからさー

作ってあるけど？
これのメリットは手役の嗜好を作りやすい事。最強かと言われると・・・
汚いソースだし書き換えるの面倒だから作り直してるさ〜

>>197　まずは、下のクラスを見て欲しい。

//========================================================================
// 手牌分析クラス
//========================================================================
class CTatsu : public CBase
{
public:
//
// 評価用データ　Analyze(void);　で設定される
//
bool m_FuritennF; // フリテンフラグ
int m_TenpaiNo; // 後幾つでテンパイ
YAKU m_YakuType; // 現在の役タイプ
int m_YakuNo; // 役の藩数
int m_YakuNotoN; // 役まで後N枚の役の藩数
int m_TurtuNo; // ターツの数
int m_MachiNo; // 牌の待ち数
int m_TotalPoint; // 合計ポイント
int m_outHai; // 評価するときに排除した牌
int m_AtamaNo; // 頭の数
int m_AtamaHai; // 頭の牌番号
UCHAR m_MachiHai[PTBLMAX]; // 待ち牌データ
int m_tehaiP[PTBLMAX]; // 手牌のポイント
private:
//
// ターツ評価用データ
//
CMentu *m_pMD; // 親メンツデータポインタ
int * m_ptehaiNAnko; // 元の手牌　　　コーツを取り除いてる
int * m_ptehai; // 評価する手牌、面子と頭を取り除いてる

public:
void init(); // 初期化する。
int Analyze(CMentu *pmentu,int ahai); // ターツ評価
void AnalyzeNoHai(int no); // 数字牌の分析
bool tehaiCompar(CTatsu *pTD); // 手牌の優劣を比較、自分が低い:true, 以外:false
bool tehaiComparTenpai(CTatsu *pTD); // テンパイ時の手牌の優劣を比較
void TenpaiMachiHai(); // テンパイの時の待ち牌作成
bool chkFuriten(); // フリテン試験
virtual bool chkThis(); // 自己オブジェクトの試験
virtual void DispData(); // データ表示
//
// 役の分析
//
void AnalyzeYaku(void); // 役の分析
bool AnalyzeYakuHai(void); // 役牌　場風、自風、白発中
bool AnalyzePinfu(void); // ピンフの分析
bool AnalyzeTanyou(void); // タンヨウの分析
bool Analyze34Anko(void); // ３アンコ４アンコの分析
bool AnalyzeToitoi(void); // トイトイの分析
bool Analyze112233(void); // イーペーコ
bool chk123(int hno); // イーペーコイーシャンテン試験
bool AnalyzeChitoi(void); // チイトイの分析
bool AnalyzeKokushi(void); // 国士の分析

private:
int getTenpaiNoAnalyze(); // テンパイまでの必要牌計算
int getKey(int * st); // キーの作成
};

class CMData : public CBase　　　 このクラスは大きいのでパブリックデーターのみ出します
public:
char m_BlockNo; // ブロック番号　−１：空き　０〜：ブロックNO
CHai m_tehaiw; // 面子頭引き後の手牌
int m_TotalPointAll; // 合計ポイント
int m_TotalPoint; // 合計ポイント
int m_TotalPoint3; // 合計ポイント
int m_TotalPoint2; // 合計ポイント
char m_MachiHaiNo3; // 面子牌の待ち種類数
char m_MachiNo3; // 面子牌の待ち枚数
char m_MachiHaiNo2; // 面子牌の待ち種類数
char m_MachiNo2; // 面子牌の待ち枚数
char m_AtamaHai; // 頭牌が有る時の牌NO
// 解析結果データ
char m_outhai; // 排除された牌
int m_AType; // 分析タイプ
char m_TenpaiNo; // 後幾つでテンパイ
char m_TenpaiTsNo; // ｼｬﾝﾃﾝに対する余分のターツ数
bool m_FuritennF; // フリテンフラグ
YAKU m_YakuType; // 現在の役タイプ
YAKU m_YakuTypetoN; // 役まで後N枚の役タイプ
char m_YakuNo; // 役の藩数
char m_YakuNotoN; // 役まで後N枚の役の藩数
char m_TurtuNo; // ターツの数
char m_T_XX_n; // リャンメンの数
char m_TX_X_Xn; // ２カンチャンの数
char m_TX_Xn; // カンチャンの数
char m_TXX_n; // ペンチャンの数
int m_AtamaNo; // 頭の数
int m_tehaiP[PTBLMAX]; // 手牌のポイント
UCHAR m_MachiHai3[PTBLMAX]; // 面子待ち牌データ
UCHAR m_MachiHai2[PTBLMAX]; // ターツ待ち牌データ

上のクラスを見れば、どのような分析をしていたか想像がつくと思います。
見れば分かる通り、分析のし過ぎではないかと思うほど分析しています。
これは当初、初めてAIを作る上で人間の考える通りに動くAIが目標でしたから。

探索ツリーは
14枚の牌
↓
↓-----------------------↓
構造1・・・・・・・・・・・・・・・・・・・構造N
↓
捨てるパターンの数
↓-----------------------↓
A牌捨て・・・・・・・・・・・・・・・・・N牌捨て
↓
仮定のツモ牌
↓-----------------------↓
14枚の手牌１・・・・・・・・・・・・・14枚の手牌N
↓
↓-----------------------↓
構造1・・・・・・・・・・・・・・・・・・・構造N
↓
捨てるパターンの数
↓-----------------------↓
A牌捨て・・・・・・・・・・・・・・・・・N牌捨て

これでようやく一手先読み。

のような探索ツリーです。非常に込み入った構造で尚且つ、分析結果がけた違いに増えます
1つの手配の分析は、総てのターツパターンを出します、その数は数十から200を越える時も。
例えば　２３３４　は　２３４と３　２３と３４　２４と３３　の3種類に分類。（とても簡単な例）

添付のDummy1.dllは1手先読みだけのAIです、サンプルソースAIと同じ読みの深さしか有りません。
先読みが浅いのでスピードが速いく、それなりに強いのではないかと思います。

初めて作ったため、いろいろな試みをしています。初盤にペンちゃんや１３のようなカンちゃんを
嫌うようにしてたり。私が思うような牌の切り方に近いようにしています。
その結果、ソースは膨大となり各所にバグがゴロゴロしているのではないかと思います。
雀譜を見れば分かると思いますが、面白い切り方をしたり、とんでもない牌を切ったりします。
まだまだ未完成です。

本ちゃんは二手先まで読んでいました、3手先までも作ったのですが、二手先とほぼ同じ感じです。

手の役について
役は、上にあるように、ピンフ、タンヨウ、３アンコ、トイトイ、イーペーコ、チイトイ、国士
までしか分析していません。しかし、後幾つで役が確定するかも分析しています。
難しい所の一つに、役を目指すとフリテンが増えてしまうのが悩みどころでした。
最終的な手の評価関数はそれなりなのですが、最適化までには至らず、残念でした。

先読みについて
　先読みが深いほど強いと思っている方もいるかもしれませんが。それは間違いだと
私の直感が宣言しています。それなりに理由もあるのですが、まだ、説得力があるほどの
論理的構築ができていません。参考程度に検討してください。
何処までの先読みがベストなのかは検討の余地が有ります。妄想では3手先も有れば
十分ではないかと思っています。

分析と評価式
サンプルソースの様な手牌構造を理解せずに、評価関数で優劣を決める方法は
過去の物です。いろいろ欠点が有ります。
例えば、１２２３３４　の場合1が来たら4を捨てるのですが、中の数字を好む式だと
1を捨ててしまうかもしれません。（サンプルAIは4を捨てる）
例えば　２３３４は２３４の面子を優先して３を捨ててしまうかもしれません。
２３と３４の2ターツと考えた方がいい場合もあります。
例えば１２のペンちゃんでテンパった時、有効牌が1枚しかなかったら、場合によっては
12を捨ててシャンテン数を下げても持ちを変えたほうが上がりには速いはずでしょう。
（簡単な例）

等々いろいろ有りますが、手配の構造を理解していないと解析が出来ません。
次世代AIには、手牌構造を分析するのが必要ではないかと言えます。

作ろうとしているAI
　問題は時間なのですが・・・、過去のAIは>>197のご指摘のターツ毎の評価（分析）が
主であるかもしれません。
　次回は、人間の様にではなく、最速に速く上がれるAIを目指します。これは
最高に早くテンパルとは意味が違います。分析方法ですが、前はターツが主では
あったかもしれませんが、今回は牌の構造に焦点を当てたいと思っています。
あいまいな表現で申し訳ありません。以前のAIの分析内容を見て分かる通り
またも、複雑な事をやろうと画策しています。
　作った結果、過去のAIに負けるかもしれませんが　（大汗
振り返ってみて、過去のAIはいい経験になっています。いや、あの時はとても苦労した
のですが、結果に落胆した・・・・orz、　　今度は己に勝つ！

>>349
詳細な解説ありがとうございます。参考になることは数多いですが、その中でも
＞先読みが深いほど強いというわけでもない
という示唆は非常に興味深い。

http://ara.moo.jp/mjhmr/statall.htm
あら氏のシミュレーション結果（↑）を見ると
先読みが深いほど好結果がでていますよね。
すると、349氏のＡＩにおいて、先読みがさほど影響を及ぼさない原因に
評価関数の指向が関与しているのではないでしょうか。

というのはたとえば
56m2367p3488s東南西北
という手牌があったとして、これをターツ毎評価にぶち込んだ場合
「役に平和がつく（有力だ）」という評価ができると思います。
でも実際、平和がつくと確定するのは、和了形にして４手先、
テンパイ形にして３手先になります。
つまり手牌自体は１手先までの形しか予想していないけれど、
ターツ毎評価によって、部分的にはもっと先の形まで予想している、ということになります。
その結果、手構造自体の先読みの意義が薄れているのではないでしょうか？
もちろん、そうなるのは評価関数が優れているためでしょう。

ちなみに、>>211の一手先読みでは一回の打牌決定あたり何秒くらいで打てます？
私の場合一打0.01秒程度なのですが、これだけ込み入った分析をした場合、やはり
いくらか時間をくってしまうのでしょうか？

>>134、>>135
たいして高速化にもならんとは思うが、一応賛成。ｌ

で、MJexeIO.DLLという東風荘をプログラムから操作するDLLと同じ関数にしたらどうかな。
東風荘でも動かせるしね。

関数仕様はこれ。
ttp://www.interq.or.jp/snake/totugeki/MJexeIODLLfunc.htm
まずは、全部は必要ない。

MJSimのデータ仕様は、無駄が多いし、わかりづらいと思う。
例えば、対戦相手の手牌のフーロしていない部分とかも見えるが（当然無効だが）、そんなの必要ない。

>>218
相手の手牌等のデーター領域はあっても中身は0で見えないようになってる。
卓で見える物しか見えない。

>>218
インターフェース用DLLを誰かが作ればいいんだけどね。私は時間がとても・・・

MJSimで、1つのAIに、2つのAIを繋げて動作を比較するツールを作ってる。
これ公開するから、参考に誰か作ってくれないかな?　と期待。

MJSim
　↓
動作比較DLL
　↓　↓
AI1　 AI2　（読み込まれた2つのAI

ルールは「まうじゃん」
ホストも「まうじゃん」
じゃなかったんだけ？

>>217
時間については計算したことがありません。どの様に算出しましたか?
ダミーなら多分0．01以下ではないかと思います。
MJSimの実行が1秒間に100回以上しているので。
また、本ちゃんの二手先でも、けっこう速いのです。
手が染まっている時は遅いのですが、そうでない時は
ダミー並とは言いませんが、早いです。
分析する必要があるのか無いかは、事前にチェックされ枝狩りされています。
手配の状況でスピードは数十倍以上違い産ます。

分析の種類が20-30以内の時と、200近くの時のその先の枝の数を想像してみてください。
極端に解析時間が違います。

読みについては後でまた。

>>222
切り番時、１４枚の手牌＋周辺情報（場に見えている枚数、ドラ等）を与えて
打牌選択関数を呼び出してから、その結果が出るまでにかかった時間を計ってます。
実質1手打つのにかかる時間ですね。ただしリーチ後のものは除いています。
ちなみに今計った所、一手あたり平均0.0087秒でした。

2手先で十分早いとなると相当なものですね。私の場合平均2秒ほどかかってしまいますから･･･
枝かりが甘いのかなぁ･･･

>>222
には、説明不十分でした。
>分析の種類が20-30以内の時と、200近くの時のその先の枝の数を想像してみてください。
>極端に解析時間が違います。
データ数がそのまま時間ではないです。
データー数が多いと言う事は、不必要な分析がどんどん増えてくるのです。
説明は難しいのですが、同じ構造を何度も見つけてしまうのです。
そのため、重複排除やその他の時間がかかります。

おっと、>>223の時間はダミーのですか?
計測ありがとう。

AI作りの基本は自分と同じ打ち方させたい、ってのがあって・・・
そうするとどうしてもメンツ構成(塔子や単騎を含む)の分析が必要になるんだよなぁ
でも、もしかすると牌効率最優先の方が強いかも分からないので、今それをどうしようか
考え中・・・

>>216
>あら氏のシミュレーション結果（↑）を見ると
シミュレーションの０−３の違いはなんでしょう?
探したのですが見当たりません。

>>223
失礼、計測した平均時間は私のやつです。

０〜３は、それぞれそのシャンテン数未満のときに和了形まで予想して
点数計算を行う。それ以上の場合は簡易計算で済ますというものらしいです。

詳細は
http://ara.moo.jp/mjhmr/simulation.htm

>>216
質問です。
>先読みが深いほど好結果がでていますよね.。
先読みが深いほど好結とは、どの部分を指しているのでしょう?
期待値の値ですか?

私はきた位置の計算自体に疑問を感じているのです。
もし意見が違うのであれば、話してみたいです。

×きた位置
○期待値

太らない程度の正しい食事と 適度な有酸素運動、そしてマッサージ
これを毎日徹底した自己管理で行えば Bカップ程度なら３年で育つ

乳について語ってるのは誰だ!!

俺はCもあれば十分だと思ってる。Fなんざぁただの脂肪の塊としか思えん。

>>228
好結果の指し示すのは期待値の話です。
ただし、期待値が高いことが、好結果である必要十分条件ではないことに、
私も同意します。あくまで、期待値を一つの指標として挙げたまでです。
あら氏の期待値の重要性が実戦で崩れる要因として重大だと考えられる
ものを挙げてみます。

１．18順の到達順目（＝猶予順目）が保証されていること
あら氏の期待値は、あくまで局が１８順完了できる（かつテンパイ料を考慮しない）
条件下でのものでした。しかし実際は18順完了できることは
それほど多くなく、全体の８５％程度は和了による終了（自家和了含む）になります。
となると、実際では条件下等によって、到達可能な順目は変わってくるはずです。
たとえば、「ダブリーがかかった1順目」という条件下では、そうでない1順目よりも
平均到達順目が小さくなり、守備を考慮しないとしても戦略が変わってきます。
仮に100順分ツモ打牌が許されるなら、全局ヤクマン狙いが正着（＝期待値高）になるでしょう。
しかし、18順で全局ヤクマン狙いの戦略では期待値は高くならないでしょう。
同様に、猶予順目が違うならば、戦略も変わってくるはずです。

２．喰い仕掛け変化を意識していないこと
あら氏の期待値はあくまで、面前のみを対象としたものでした。
この条件では、喰い仕掛けを考慮しないため、「役をつけるためにシャンテンを落とす」
ということは少なくなります。
しかし喰い仕掛けを考慮すれば
123368m246p22688s　ドラ2s
というような場面から、打1mとしてクイタン狙いは有力手です。
当然、これはフーロを想定するからこそ有力手なのであり、フーロを考慮しない
期待値評価で打1mが選択されることはないでしょう。
フーロを想定するならば、喰い仕掛け可能な役を狙う意味が大きくなります。

３．守備を考慮していない
守備を考慮しなければ、ちょっとでも効率アップが考えられる牌は残すべきです。
しかし中終盤で、ほとんど効率が変化せず、かつ将来危険になるような牌は
残すべきではないでしょう。また、相手から攻撃が入った場合、各牌に失点指標
を導入しなければなりませんが、それも考慮されておりません。

とりあえず組んでみて思ったこと
・攻撃は何もなくても組みやすい
・守備は何かないと組みにくい
・俺よえぇ
こんなとこか

おまいら基礎が大事っていってるだろ　まずは複数人で役計算を確定させようぜ
ルールは東風荘(第一)またはまうじゃんまたは今回作成したオリジナルルール

>>234
守備を組むとっかかりには、結構各人の判断基準で強弱つくと思いますよ。
そういう面で、麻雀打ちとして強い人は有利になるでしょう。

<テーブル>は私の中に･･･

プログラムくみやすいようにルールまとめたよ

単純化したオリジナルルール
http://kansai2channeler.hp.infoseek.co.jp/cgi-bin/joyful/img/4765.txt

トンプウ荘ルール
http://mj.giganet.net/yaku.htm

>>232-233
詳しい説明ありがとうございます。

私は特に、次の点が実際と合わないと考えています。
あら氏の一人麻雀では、相手がいません。
したがって4人いる場合明らかに計算式が違います。
あら氏
期待値＝自分の牌を見ただけの期待値。
4人麻雀
期待値＝自分の期待値　ー　遅れた上がり順目分の他人の上がり期待値。
こらが本当の期待値です。あら氏のは一人麻雀での数値です。

いわゆる、０と３では、平均テンパイ順目が　０＝11.56　３＝11.76
3の方がテンパイが遅い、そして何より平均和了順目が　13.82　14.46と
０．６４順ほど遅いのです。これは私にとっては大きなマイナス要員です。

コンピューター麻雀の場合、手の雰囲気が似てきます。だからこそ
こちらが上がりそうなら、他の3人もあがりそうだと考えるのが普通でしょう。
その場合の０．６４順遅れは、最強を作る上でマイナスだと考えます。

AI対戦の場合、他より少しでも速く和了する事が重要だと考えているからです。
その考えからすると、和了が速い０の方がいいのかもしれません。

まずは、
数字19、2〜8、白発中、東南西北のコーツとトイツは同一視したときに
正しい飜数を返すプログラムを作ろうぜ

これで多くは判定できるよ
なぜならば、2のコーツと3のコーツを同一視しても、
それは別物であることは枚数から明らかだからだ

自牌だけ見ても駄目だぞ
なぜならば、敵は3人いるからだ
自分のあがる確率より、他人のあがる確率は3倍も多い
防御は重要

その上がりの早いAIは、上記のような塔子分解で有効牌が多いものを選んでいく方法で
とりあえず形になるのですが、理想とするシャンテン数には届かないです。
(理想←手牌＋ツモる予定の１６牌(17牌)でのシャンテン数)
理想が高すぎるのもあるのですが平均１シャンテン位は低いです(中盤12〜14巡目辺り)

自分のプログラム、ひたすら上がり判定と先読みを枝切り高速化しまくって
３シャンテンくらいから期待値計算で考える子にしてみたんだけど、
２シャンテンから考える子は正常に動いたのに、３シャンテンまでがんばらせてみたら
なんか動かなくなっちゃった。これだからバグはいくないorz

>>235=>>237=>>239=>>240の無視られっぷりにﾜﾗた

>>243
だってもう飽きたんだもんww

>>242
2手先まで読めてて、さらに1シャンテン下げるのは流石にムリでは･･･
鳴いてもなんでもいいから形だけシャンテン下げるだけならなんとか。

>>235=>>237=>>239=>>240

犬のフンは無視するのが一番

>>245
あれ？自分なんか間違えてるかな？
２シャンテンから考える子は大体10ms以内とかだった気がするんだけど

アンカーミスった･･･ｽﾏｿ
>>241ね

>>241ん？俺かｗ
いや、これは一手先読みだけですね。１牌切った状態でのシャンテン数が良くなる
候補の牌枚数をカウントして(有効牌数)、枚数が一番優秀な時の牌を切っていくだけ。
理想のシャンテン数というか究極が、引く予定の牌を含めた30枚でのシャンテン数として考えてます。
当たり前ですが究極には近づけませんｗ(エスパー能力があれば・・ｗ)
有効牌数がそのまま塔子構成にも関わるので、そっちの評価は入れてないですね

おぉ、そっちかｗ

役牌って英語でなんて言うのかな？

ちなみに、>>249はそのまま積めません、遅すぎて。(面子候補で爆発します)

ttp://www.excite.co.jp/world/english/
役→Post
牌→Tile
役牌→Yacpai

ううむ・・

数牌のときはスートとシーケンスでいいと思うよ。
あと、役牌よりは字牌だろうね。

自分で分からない言葉を使うよりは、ローマ字表記にした方がマシな場合が
多々あります。辞書を引きながら決めるなら↑の表記にした方が楽です。

自分だけならな。
人が書いたソースでTaitoruとか使ってたら、そいつのコードは1行たりとも信用しない。

上の役牌なら(翻牌？字牌？)ならYakuHaiでも良いとは思うが>>253を使って
PostTileなんて変にやられると逆に可読性が落ちそう。命名規則だけは保って欲しいな
>>256
それは流石に同意ｗ

>>256
奴の事か

大体ローマ字表記で統一してるなぁ・・・
なんか幼稚っぽく見えるかもだがorz

サンレンコが一般的な役じゃないことが非常に美しくないということについ最近気づいた

半端英語とローマ字混ざるのが一番辛くないか？

私の場合変数名は　変数型１字+ローマ字に統一してる

あがりの際の翻数を入れるint型変数なら　IAgariHon

自分の場合ある程度の長さの変数名にして、後々気になったら置換してしまうｗ
この時にある程度の整合性を考える。ソースは上げるまでは自分だけのもんだしｗ

つhttp://pc11.2ch.net/test/read.cgi/tech/1180146315/

Hon・・・？

>>265
今気づいた正しくするなら IAgariHan　だな
翻を変換するときに「はん」ではなく「ほん」で変換してるから
間違えてしまったみたい

>>264らじゃｗ
今実際に組んでる人どれ位いるのかな？
自分は今忙しくて凍結中　orz。ネタだけが増えていく・・・

一応組んでるけどあんまり強いのできないかも

調べてみたところ、「役牌」は英語で value honros と表記するようです。
（ちなみに、 honors は「字牌」のことです）

あと、プログラムを作成する上でわからない用語が、「捨て牌」です。
Table が真っ先に浮かんだのですが、なんかしっくりこないし・・・

たしか国によってルールが違うし、専門用語だし無理に訳す必要はないと思うんだけど、
ローマ字はなんか抵抗があるんだよなあ

もうある程度特別なケースは無視しても問題ない気しかしなくなってきた

今ごろが帰宅時間だ・・・orz
ゆっくり作ってるが何時出来る事か、完成したら面白い話が出来るかもしれない。
誰かAIをUPしませんか?　７８さんAIをUPしませんか?
過去のAIならUP出来るけど、何処まで何を修正していたか、全然覚えて無い。
最終ビルドしたDLLならUP可能。

お疲れ様です。
個人的に燃料投下(DLLUP)して欲しいです。

では、明日にでもUPしよう。
>>72さん　>>211の構造間違えてます。調べて最UPしまつ、申し訳ない。数年前の話なので。
ネタ投下してみる。
構造の分析について
正確な点数計算は総ての手牌構造を出す必要が有る。
ちょっとだけめんどう。
テンパイして無い手をターツまで含めた手牌構造の総てのパターンで出そうと試みる。
とても大変。
手が染まっている手では、爆発的にパターンが増え、同じ構造を何度も検出する。
私のAIでは、考えられる総ての切り口で構造を取り出しているため、同じ構造を
何度も検出していまう。これの重複を検出するため、構造のキーデータを計算し
ソートして有効な構造のみ取り出している。
>>209に有る　int getKey(int * st); // キーの作成 　　これがそう
一種の枝狩りかな。
また、まじめにプログラムでターツを取り出すと、多分とても大変。
したがって、パターンデーターを持って、高速化している。
高速のために極一部の構造までは検出できない欠点ももっている。
事実上問題はないと判断したため、省いた。

私のAIの実装内容その1　でした。

追記
・パターンデーターでの分析は、とても高速だった。（参考までに）
その実装方法は説明せず。皆さんに疑問を投げつけて、もっといい方法が出るのを期待。
実は欠点があってね、あの時はそれしかなかった。

パターンデータの実証は自分もしましたけど、なかなか有効でした
ただ、塔子などを考えるとまだまだ隙の多い気がしますね。自分のものは

>>273
パターンデーターはいい方法論だと思うね、もっともっと良くなると思う。
標準化するほど一般化するかも。まあ、実装方法はいろいろ出てきていいと思う。
その中で、色々なアイデアが出たほうがいい。

ネタ投下その２
高速化の一つとして実装したのが。前分析データーの再利用。
私の分析ツリーは総てデーターでツーリー構造のまま残っている。
したがって、次のツモの先の分析データーが存在している。
それを再利用している。毎回既に広がったツリーの一手先を読むだけで
数手先を詠む事と等しい。しかし、多少スピードUP程度かな。

そうそう
明らかに関係しない牌をツモった場合は、前分析ツリーで簡単に意味が
無いと判断できるので、ツモ捨てしている。この方が高速化にはとても効いている。
単発の字牌とか、手牌より意味も無く離れたパイとかね。
手の重みでその辺も固まってくるし、前の分析データが利用可能なので。
この枝狩りは大きいかも。

今話しているのは過去のAIの話で、方法論のひとつにすぎません。
もちろん、もっといい方法は多々あるでしょう。無ければ新しいAIを作ろうとは思わないし。
ネタになるか参考にだしているにすぎない。ウザかったら言って、辞めるから。

追記。
物凄いメモリーの確保と廃棄が行われているのが理解できると思う。
オブジェクトの生成と廃棄では遅いと思い。高速メモリー管理ツール
を最初は使用していたが、それでも遅いかと思い、完全にそれ専用の
メモリー管理を実装した。これ以上の速さは無理なほど速くなったと思う。
メモリーの廃棄は１ステップ、確保は最短で確保。
どんなに良い物でも、専用にガリガリにチュンナップしたものが早いのは
当たり前と言う事で。
この辺は正直、趣味に走ってます、あははははは・・・・暇人だ・・・・
データーツリー構造の管理も趣味だよな〜・・・・orz
趣味が理解できる人だけ読んでちょ。

注意！
しかしだ、そんなに強くないAIであった（泣き
（実はもっと色々組み込んであるんだよ、戦術の話一言も触れて無いし・・・・・・orz）
私の落ち込みは、想像できるだろうか・・・・・・・・・
だって、結果が最速が強そうだったから。今度は最速でGOだ。

×戦術
○戦略

ゴタクはいらんから早くあげろ

正直、こんなに話したAIをUPするのは恥ずかしい。失敗作としてみてちょ
↓
ttp://uproda11.2ch-library.com/src/1119634.zip.shtml
PW=MJSimAI

>>282
うざかったか、じゃもう解説は止める。

ウザイ
手短に3行でまとめろ

他にネタもなく何か有益な事書くわけでもないのに止めるなよ

>>284
いや、自分は面白いと思って読んでる。
だらだらでも何でもいいから好きなように書いてくれ。

で、落とせません orz
それぞれの牌種は独立なので牌種ごとに捨て候補の牌と評価値を保持(上位２つずつ位)させて
引いた牌の種類の所だけ更新する。
と言う方法も浮かんだが、手役を絡むと面倒かも。
捨て牌を選ぶ時に有効牌のリストを用意させてしまうと言う手もあるかな？(それ以外は計算せずに、
もしくは切り上げた計算をして、ツモ切りとか。←自分の思考に近い方法)

麻雀英語に関するいいHPを見つけた。

http://reachmahjong.com/

>>349
落とせません＞＜

>>349
2chのような平均的に「できの悪い」人間が多く集まる空間では
著しくできの良い人間を貶めようと働くことがしばしばあります。
>>282や>>285のような者がそうです。彼らは「できの良さ」を披露されると
怨恨感情を発火させて反発し、呪詛を垂らします。
このような連中の発言を真に受けることは愚行に他なりません。
いったい氏の書き込みと>>282のウザいとの感情に、なんの関係がありましょう。

〜>>280で語ってきたことは、我々にとって役に立つ・おもしろいものだと
判断されたからこそ書き込んでくださったのでしょう。
その判断は正しい。この水準での具体的なコーディング上の工夫を
詳細に説明した記載はいったいどこにあるというのでしょうか。
かのまったり麻雀のブログですら無かったことです。

氏は麻雀ＡＩの分野について現時点で世界一「ためになる」レスをしてくれていた。
これは自覚されてもよいことかと。

そしてＡＩをＤＬしそこねた･･･再ＵＰを！（泣）

全く同感だ

ためにはなるかもしれんが、
2chで自分語りする奴ほどうざいのもいないぞ。

>>292
確かに、君のような無能な人間が際限なく自分語りを繰り返してきたのが
君にとっての2ｃｈ像なら、この類ほどうざいものはないだろうね。

ところで、君が抱く個人的心情（＝2ｃｈで自分語りする奴はうざい）を吐露する
ことそれ自体が、「無能の自分語り」に帰着してしまっていることに自覚的かな？
君は「自分語りはうざい」という見地から見てうざいし、ためにならない発言をする
奴はうざいという見地からも輪をかけてうざいし、識者に対する怨恨が垣間見られて
醜くうざいね。

349氏のような優秀な人材が、君のような無能の心情や能力水準に合わせる必要が
どこにあるというのだね？むしろ、2chや君にしてはいささかレベルが高くなった
このスレにおいて、『うざい』と形容されがちなのは君のような立場だということを自覚したまえ。

どうでもいいが、確かにうざい。

78がこんなに痛い子だとは思いませんでした。

349の書き込みは歓迎だが、
>>277-280の連投に関しては、どうかと思う。
これからは少し熟考して簡潔に纏めてみては？

なんだこの流れ（　＾ω＾）・・・

349はえらいけど78はバカだ

レベルの低い人物→>>78>>349　より低いアホ→他大勢　

>>295
どうかと思う、だけでは難癖のように取られてしまうかも
内容のある長文もあれば、内容のないものもあるわけで
内容がないと思うなら、どこを、なぜ纏めたほうがいいかも添えてあげなよ

どうかと思うから、ではなく、こう思うから、のほうが意図が伝わるかと

>>298
目糞鼻糞

平凡な人間はできる人間を貶めて、自分らと平等化しておかないと悔しくてしょうがないのだ

「議論しましょうよ〜」by１２人の優しい日本人

ジンジャエール！

>>301
自己紹介ですか？

正直、こんなに話したAIをUPするのは恥ずかしい。失敗作としてみてちょ
↓
ttp://uproda11.2ch-library.com/src/1119634.zip.shtml
PW=MJSimAI

MJSimの実行環境及びサンプルAIを再度UP
↓
http://uproda11.2ch-library.com/src/1119738.zip.shtml
PW=MJSimEXE

昔の話ですが、MJSim作者宛に。
　私はMJSim作者さんに恩義が有ります。２ｃｈはそんなに見ないのですが。
たまたま見た時、麻雀ホストを作る話が出ていて、気軽な気持ちで参加したわけです。
当時、私からの話は曖昧な事が多く、もっと具体的な話を期待されているのが分かっていましたが、
作ってる状態の時はなかなか出来ませんでした。
　いや、理解はしていたけど、なかなか出来ませんでした。MJSimの出来は素晴らしく
何らかの形で恩をお返しで着ればと思っていました。
いま昔できなかった事を、解説と言う形で公開して、お返しが少しでもできれば嬉しいです。
公開私信失礼しました。

上のAIUP先ミスです。
↓
http://uproda11.2ch-library.com/src/1119740.zip.shtml

色々意見はあるようですが継続しま。

ネタその3　　評価関数について。
>>209の
>bool tehaiCompar(CTatsu *pTD); // 手牌の優劣を比較、自分が低い:true, 以外:false
>bool tehaiComparTenpai(CTatsu *pTD); // テンパイ時の手牌の優劣を比較
　評価関数は2つ持っている。それはテンパイになるまでの評価関数と
テンパイになった時の評価関数である。簡単に言うと、テンパイになった時
何を捨てれば一番いいかとそれ以前では違うと考えたからです。
麻雀をやっていれば分かりますが、テンパイの時何を捨てればいいのか考えるでしょう。
それ以前と明らかに性格が違うと考えたからです。

テンパイ時の評価式は
１．役が多い方を選ぶ
２．待ちが多い方を選ぶ
３．ポイントが多い方を選ぶ

上の順番の優先順位です。今思うと1，2逆の方が良かったかも・・・

テンパイ以前の評価式は、ずいぶん悩みました。分析データーが9種類も評価してた、
何をどのような優先順位でやるのかを。今見ると役が優先ぽいですね〜
これじゃテンパイ率が低くなってしまう、残念。
　スピード有利の確信は徐々に育っていきましたから。
それに、戦略追加作業がけっこう大変で、そちらに頭が切り替わってたし。

今思うと、平均上がり点はそんなに高くなかったような・・・・・

>>303
知ってるのかｗ

>>309
ﾋﾟｻﾞの出前ｷﾎﾞﾝﾇ

ネタその４

戦略について、今までの話が戦術とすると、これからの話が戦略になります。
戦略として､分析していた物
１．見える牌から、見えない牌の算出。
　（これは、戦術時点で計算していた、待ち有効牌の算出に）
２．相手の河や場の状況から、他家おきの牌安全度計算。
　（当時のAIはテンパイ即リーですから、他者のリーチがあって、
自分の戦略モードに従い、降りや回しで使用していた。）
場の分析
１．局目
２．親、子、場風自風
３．自分の順位
４．各順位との点差
５．順目
６．各家のリーチ一発の時
７．各家のテンパイ（リーチ）状況
８．もっと有ったような気もするけど忘れました。（見るの大変だし）
等のデータから、戦略を決定しそれにしたがって動作する。
AIの戦略動作モードの公開↓。
NON = 0, // 全つっぱ
OGO = 1, // 全つっぱ
OM1 = 2, // 面子以外から危険度最小の降り牌を探す。TYPE１
OM2 = 3, // 面子以外から危険度最小の降り牌を探す。TYPE２
OM3 = 4, // 面子以外から危険度最小の降り牌を探す。TYPE３
OMB = 5, // ターツからAN_Bランク以上の降り牌を探す、なければ全牌検索で最安全牌を切る
OMA = 6, // ターツからAN_Aランク以上の降り牌を探す、なければ全牌検索で最安全牌を切る
OS = 7, // ターツからAN_Sランク以上の降り牌を探す、なければ全牌検索で最安全牌を切る
ORA = 8, // べた降り
ORB = 9, // 安牌を作成してべた降り
戦略については、試作的な意味合いが強く、研究や最適化までには達していなかった。
以前書いたように途中で終わったし。

以上で終りかな、前レスに枝狩りの疑問が上がっていたので。
枝狩りについて多少詳しく話しています。
もし何か疑問が有ったら、話せる範囲で話しますので、お聞きください。

補足
>>311の途中で終わっていたのは研究や最適化です。
目的の機能の実装は全部終わっていました。

※麻雀ロジック研究会※
http://pc11.2ch.net/test/read.cgi/gamedev/1105332492/

http://www.nicovideo.jp/watch/sm542655

過疎化すげｗ

元の姿に戻っただけ。ちょっと前が異常。読み飛ばしてたのでだれか三行でまとめて。

ぐだぐだ書き込んでないで
手を
動かせ

>>317
リバーシ１

ほんと、見事な過疎っぷりだな

皆言いたいことだけ言って、まともなソース
も挙げずに逃げたか？

まともかどうかはともかく、ソースはいくつか挙がってる
検証する気は無い

　　
　　　「　ま　と　も　な　」

　　　　　　ソースは一つも上がっていない

349氏のあげたソースはまともだと思うけどな

みんな帰省しているのかな

他のことに忙しいので放置中

ぶっちゃけるとやる気は無いけど参加者のふりしてた
もう飽きた

過疎がｽｺﾞｽｗｗｗｗ

なんなんだろう
この熱しやすさと冷めやすさは

IDがないから、実質何人が書いてたかｻﾊﾟｰﾘ。
結局、前スレの途中から、ここまでで、何か進んだのかな？
誰か3行でまとめてくれ。

口
だ
け

まず俺が麻雀弱いから無理
母親にも勝てない

このスレに関係なく麻雀ＡＩ組んでるけど…

テンパイしてくれませんorz
ごく稀にテンパイする程度なのでまだまだ要改良

そもそも麻雀のアルゴリズムなんて難しくない。
深さ優先探索が理解できるなら、一人麻雀で２０％の和了率を超えるのなんて簡単。
この程度ができないんじゃあプログラマとは呼べん。
誰かがココにソースをＵＰしてくれるのを待ってないで自分で作れよ。

>>333
証拠を見せろよ

全員互角なら２５％、で、全部食いタン狙いなら、２０％は取れるんでない？
トップを取れるかどうかはともかくとして。

>>333にプログラマと呼ばれたい人なんているの？

とりあえず>>333はスレタイ読んでくればいいんじゃないかな

問題は一人麻雀でって事さ

なぜ最近の犬学生は麻雀できない奴が多いの？
http://ex23.2ch.net/test/read.cgi/campus/1191128147/l10

★★★ 学校で麻雀を教えるべきだ ♪♪♪
http://school7.2ch.net/test/read.cgi/edu/1190440186/l10

なんで最近の若者は麻雀できない奴が多いの？
http://money6.2ch.net/test/read.cgi/mj/1159088315/l10

過疎化ﾜﾛｽｗｗｗｗ

麻雀は受け技が極められた競技ゆえ

俺は一つもまともにソフトと言える物は作ったことなく
だからもちろん深さ優先探索なんてさっぱり知らないけど
麻雀のAIってどんなんなん？
他家テンパイでまもりに入ってる状態なら、カベ、スジ、リーチ牌付近、ドラ筋付近
等を把握しなきゃなんないんだろ？
ゲーム開始時点なら、まぁ無難に、他風牌、浮いてる端牌から切ってそんで・・・
って、言っても他風牌と端牌が大けりゃチャンタもあるしジュンチャンあるし
三色見れそうなら浮いててもおいとく事もあるし・・・・・・
こういう模索をプログラム化するのがアルゴリズムを作るって事なんだろうな〜
挑戦してみようかな・・・
とりあえずAIがメンタンピンのみを模索するアルゴリズム
めんどくせーな

テンパイチェックからやれや

他家がいつ聴牌したかなんてわかるの？
人間が切るのが遅くなったら聴牌疑うとか
自莫切りばっかり繰り返してたら聴牌疑うとか
あとwebカメラつけて目線追うとかしなくて大丈夫？

麻雀勉強してくれば

>>344
牌効率極めてから言えや

個人的メモ

最強麻雀プログラムに必要なレシピ
・線形計画法および動的計画法の知識
・集合、郡、環の知識
・統計確立

そんなのいらねーよｗｗｗ
大きいところから入りすぎるから先に進まないｗｗｗｗ

群の字が違うしな

確率も違うし
>>347が完成させる雰囲気ゼロ

けっきょく運の強い香具師には勝てない

http://www.kohgakusha.co.jp/books/detail/978-4-7775-1331-4

買ってみたいがこれ系の将棋の本が糞だったからなー

買わなくてもWebにAPIが公開されてる

API使うようなやつは買うべきじゃないか？解説書として。

つーかこれ「まうじゃん for Java」の人で収録されてるのもそれそのものらしいじゃん。
ならインターフェースのレフェレンスだけ欲しい人はいらんだろ。

ttp://members.jcom.home.ne.jp/hennano/maujong/java/

カードゲームでのアルゴリズムとかでいいのないかな
とりあえずルールが比較的少ない 「単細胞遊戯 マイクロ王！」
とかあたりを対象にしたAPIがあるとうれしい

いろいろAI作っている人はいるけど将棋や囲碁みたいに同じ土俵で勝負しないのは自信がないからかね
http://kmo2.cocolog-nifty.com/prog/
http://doranizm.hp.infoseek.co.jp/
http://kmkz.jp/mtm/?load=mahjong

個人的な感想だが，方向性が違う様な気がする
将棋や囲碁は神の領域（最善手）を目指しているが
麻雀の場合は実際の人間の真似をしようとしている感じ

同じ土俵って？

>>359
麻雀の場合、神は人に勝てないからな

それ神じゃないよ

神はサイコロを振らない。

>>358
完全情報ゲームとそうでないものを同列に扱ってどうする

でも最近の囲碁ソフトはモンテカルロ法の確率的なアプローチで成功してる
バックギャモンやポーカーなんかでは以前から使われてるそうだから
同列に扱ってもいいかも

将棋なら世界コンピュータ将棋選手権とかやってるじゃん
麻雀はしてない

そればかりかAI同士で勝負できないように作っておきながら自分のが最強と主張してる

共通仕様が欲しいよね

最強とかいいからヴィジュアルに力を入れてください。
咲マージャンﾏﾀﾞｰ?

>>368
ロンよりショーコ
P�Uでいいだろ

俺、今凄くいいこと考えついた！！

脱衣マージャンを全自動化すれば良くね！？

つまり、ユーザーインターフェース作らなくて、
APIだけしか公開しないの
そーすれば、最強のプログラム麻雀を作らないと
女の子を脱がせられない

これよくね？ｗｗｗｗｗ

そう思うんなら作れよ
それとも口だけ？

>>371
プログラムできても
萌え絵が描けないｗｗｗｗｗ

書いてくれるなら作ってもいいよｗｗｗ

いやそこははいはいワロスワロスだろ

スマン
ローカルルールは知らないｗｗｗ

プログラム板ってここしか見てないからなｗｗｗｗ

女の子の画像も自分で作らせれば良くね？

そんな面倒なことするくらいならリソース抽出

女の子は全部LINE命令で描きます

萌え絵は当然暗号化

いいだろう　ならば猫飯

>>379
そっちに力いれずに
普通にプログラム作れよｗｗｗ

 ワッフル ワッフル

東風荘／ハンゲー のインターフェース作ってるが、
とつげき東北のDLL使用条件に、「麻雀ゲームの重要な技術に
かかわる機能を持つソフトウェアに利用することはできません」
とある。
この文って、とつげき東北がDLLの利用条件としてあるだけで、
東風荘のルールとしては無いですよね？

東風は特にないと思う
ハンゲは禁止

素材作るのクソめんどい

このスレっていつが最盛期なの？

 ワッフル ワッフル

スーパーリアル麻雀のAIが最凶だろ

違う

あげ

まうじゃんのAI欲しいなと思ったが過疎化と言うかもうスレ終わってるのな
条件付けしたりとかで気楽にAI組める”プログラム”無いのかな、と思ったら無いのな
天鳳とか対人のが充実してるから不要なのかな、そうだよな
公式で紹介してるようなサンプルAIじゃ物足りないなぁ・・・orz

上げるの忘れた、意味無いか

共通ＡＩ作ってみんなで対戦してみたい

＼(^o^)／ｵﾜﾀ

じゃんがりあんのOPが最強

囲碁のMC法使って麻雀ソフト作れないかな？

MC法って何？

モンテカルロ
確定情報がないのにそこからの試行をどういう条件で行うかを考えなきゃいかんな。
やっぱり無理っぽいと思うな。

これから来る牌の確率分布は分かってる
どういう手牌でどう打つかというアルゴリズム（モデル）は何にせよ必要
このモデルに（不完全な）確定的なヒューリスティクスを使うより
良さそうな打ち方（複数）に適当に確率割り当てるだけにして
後はランダムシミュレーションで最終的な期待値が最大になる手を
選ぶ方が良いかも知れない
ゲームの長さは100のオーダーだから9路の囲碁と大差ないし

川から相手が所持してるであろう牌姿を読むモデルが難しいんじゃ。

相手の牌もMCで

>>399
自分用のをそのまま使う

モンテカルロは、どの程度、前方枝狩りするかによりますね。
全く枝狩りをしないと結局天和と同じ程度の確率でしか上がれないから、
時間がかかってしまってゲームとしてはほとんど意味をなさないです。
かといって思いっきり枝狩りしてしまうと、
あらさんの一人麻雀練習機とか私が作った奴とほぼ同じで
単純に遅いだけになってしまう。

囲碁で使っているUCTを使って、UCB1に新たにノード追加する一手目の部分は
全幅探索で以降枝狩り強化っててはありそうです。
やってみたいですが、それでも、ゲームに組み込めるほどの実用に耐える速度は出ないでしょうね。

蛇足気味ですが補足。

モンテカルロ囲碁がうまくいくけど
モンテカルロ麻雀がうまくいかないのは、
適当に打っていてもゲームが終わるかどうかが大きな要素です。

麻雀は混乱から秩序を作り出すゲームなのです。
囲碁みたいに適当に打っていても盤面が埋れば勝ち負けが決まるゲームとは違います。

なのでかなり強度に前方枝狩りをしてやらねばならないのですが、
そこまで強く枝狩りするくらいなら、
モンテカルロなんか使わずに統計データから確率計算したほうが
計算量が少なくて実用的です。

いわゆる「決め打ち」のアルゴリズムなら効果を発揮するかも。
「決め打ち」が格好いい漫画といえば、

ノーマーク爆牌党

>>403
ランダム打ちはやめた方が良い。　
ランダム牌杯でやった方が良い。
たとえば、残り牌からランダムで20枚の牌列を生成して、最も速い手数であがれる捨て牌をカウントしていく。

どの捨て牌があがりやすいか調べるのにモンテカルロを使うのが最善だろうという事。上がり得点を考慮するとなお良い。

けれど、
打牌選択についてはMCがあまり実用的でないとは思いますが、
私は相手のリーチ時のアタリ牌読み、
鳴き仕掛けの点数の高さや役の読みには使えるかもしれません。
やり方はとつげき東北さんが山読みテストをしたときのアルゴリズムと
同様になるでしょう、

問題は人間はある程度意思を持って役を狙ってくるので、
染め手など人間プレイヤーなら注意する相手の挙動を認識しにくいこと。

私はここら辺は、スパムメールフィルタのアルゴリズムに使われる、
ベイジアンフィルタと似たようなやり方で対処しています。

捨てパイの特徴的なパターンを洗い出し、それを単語に見立て、
スパムメールか否かを判断するのと同様に、
相手の手牌が危険かどうか判断しています。

>>408
牌勢を読むのか。面白い試みだなぁ。

>>408
相手の手を読むのは、効果低いと思うよ。
鈍くなるし、相手が変則的な打ち手かどうかは、
経験的にはわかっても一局程度では不明だろうし。

＞相手の手を読むのは、効果低いと思うよ。

思うとかではなくて実際やってみれば、
どんなときに効果があって、
どんなときの効果がないのかが良くわかります。

鳴き仕掛けについては結構使えますよ。

>>411
相手がテンパイかどうかすら捨て牌から認識することは困難と思う。
ややランダムになるかもしれないが。
リーチ後や、単騎待ちとか危険牌が確実にある場合のみ判定した方が
総合的には強くなると思う。　
確定的でない事に時間を掛けるより、確実な事の方が良いだろうって事。

>４１１
自分で読み直して意味不明でした。すいません。

>鈍くなるし、相手が変則的な打ち手かどうかは、
>経験的にはわかっても一局程度では不明だろうし

打ち方が、いわゆる「鈍くなる」というのは確かにあります。

実際最初に作った奴は無駄に警戒しすぎになってしまい没にしました。
なので、予想点数の危険度で、閾値を決めて、対処してます。

相手の変則的ってのも確かに対処しずらいです。

ただ、実際問題、プロリーグのようなものがあって、
同じ相手と打っているなら別ですが、
ネットやフリー雀で打ってる場合、
超一流の人間雀士でもそこまで個別に対処してないようです。

それに、麻雀は、乱数に支配されるからそれほど自由に打てず、
将棋などと比較して、気風が出にくいので、
割とあまり考えなくても、ソコソコうまくいってしまう感じはします。

実際問題、相手の特徴がわかるだけのデータも集まりませんしね。
特徴がわかるほど何度も遊んでくれるゲームを作った後に考えることにしてます。

全くしないよりは強くなります。
＞確定的でない事に時間を掛けるより、確実な事の方が良いだろうって事。
これもご意見後もっともで、
初期のバージョンは実際そのようにしていましたが、

その後、408で書いたアルゴリズムを組み入れました。
そして、実際やって強くなりました。

ちなみに、
聴牌しているかどうかを0,1で判断して対処すると色々まずいので、
0〜１の間で確率として推定して、自分の手牌と比較して期待値で打牌を
選択しています。

失礼,414は412への返事です。

>>414
最初からテンパイかもしれないし、どうやっても役になりそうに無い場合もあるし
始めに配られた牌によって上がりは左右されると思う。
それは捨て牌からはわからないけど…　
0手目既にテンパイとは認識出来ない。

ですから確率的に対処すればよいんだと思います。
麻雀で全勝するプログラムなんてありえないんで、
１０００試合やって平均がよければそれでよしとするしかないですね。

>>417
相手三人の最初のテンパイの確率が判らないのが困る所。
まともな打ち手ならば、手が進むごとに確率は上がっていくけれど
初めが1%だったのか95%なのかでずいぶん違う。
これは捨て牌からは読み取れないと思う。

テンパイの確率よりも、あがり期待値を求める方がよさそう。　
テンパイしていて一周以内にあがれる確率が50%だとしても役で1000点や3万点と幅がある為。
安い手でロンされても大したことがない。

＞相手三人の最初のテンパイの確率が判らないのが困る所。

最初の聴牌の確率ってのが何のことかわかりませんが、
牌譜から巡目毎の聴牌率のデータが求められるので、
私は、そこから色々割り出しています。

個別のケースはそりゃわかりませんが、それがわかったら、
麻雀というゲームが成立しないんで、余計に困ってしまいます。
そのための確率でしょう。

捨てパイの特徴も確率的に処理してます。

どうしてもわからない部分は無視して自分の都合で上がりを目指しますが、
それはコンピュータでも人間でも一緒だと思います。

>>420
配られた牌によっては、既にあがっていたり、テンパイしている可能性もあるって事。
捨て牌が多くなってきた終盤ならば、捨て牌を解析する意味はあるかもしれないとは思うけど。

テンパイ後は、捨て牌がランダムになりやすいとは思うけど、その確率がわかった後
あがり牌と役の得点も予測しないといけないとは思う。不確定な要素が多すぎると感じる。

＞捨て牌が多くなってきた終盤ならば、捨て牌を解析する意味はあるかもしれないとは思うけど。

序盤は無視しても良いのかもしれませんね。
ただ、データとってみると、
序盤の捨てパイの方が役や点数との関連が強くでる傾向はあります。

純粋に牌効率から捨てた、という限定条件の下に
捨て牌から待ち牌を予測する研究というのは
無駄にはならないから

意味がないわけではないとしても、強くなるかは微妙と思う。
例えば一手2秒以内だとして捨て牌予測に500m秒使ったら、それだけで1.5秒も使ってしまう。
捨て牌を決めるより圧倒的に計算時間がかかると思う。

まうじゃんのＡＩまだー

ＡＩ作成ツールまだー

>>425
それが時間の問題だけなら、大した問題じゃないよ
アルゴリズムか実装をグツグツ煮詰めて速くするか
計算機が速くなるのを待てばいいだけ

もちろんすごいオーダーの計算になるなら話は別だけど

あと、時間制限を設けていっぱいまで考えるってのは
一般的な思考ルーチンでもやってる。
その場合、常に候補を検証し続けて 候補をソートしといて
時間切れ時に一番有効そうだったやつを採用する

幾らでも時間掛けて良いなら、相手の捨て牌を考慮した方が強いだろうけど
でも大した効果でも無いと思う。時間が限られているなら自分の役に専念した方が強いと思う。

まあ最初のうちは捨て牌なんざ ざっとスジと裏スジと色気配だけ読んで
あとは役作りに専念した方が効率はいいな。 どうせ読みきれるもんでもなし。
その先のことは 行き詰ってから考えた方がよさそうだ

>>430
リーチ一発目はそれなりに長考したほうがよさそう
あのディープブルーもパニックタイム用意してたし

リーチや、鳴きして単騎待ちなどテンパイ確定なら当然読むが
そもそもの始まりは、テンパイ不明のときに捨て牌を読むかどうかだったはず。

これまでの（実際の麻雀の）個人的な経験からは
できるだけ早い上がりを目指すのが結局一番いい様な気がする
ある程度確率が計算できるならという条件で
ただ先読みなしで打牌を一つだけ選ぶというアルゴリズムで
良いのを作るのはかなり大変なんじゃないかと思う
だから確率だけ決める様にして後はUCTに任せる方が強いプログラムが
作れるんじゃないかと思うのだが
計算時間を心配している人がいるけど一局100手以下なんだから問題ない
全てのシミュレーションが流れちゃう様だと問題だけど
あ，手（捨て牌）は高々14通りだから前向き枝刈りは（多分）要りません
長文スマソ

単純に強いだけで、思考時間は考えないのか
強くても1手に10秒とか掛かってたら

10秒なら十分だよ
並列化でもすればいいじゃない

>>435
思考時間なぞどうとでもなる

相手が思考している時間も使えるしな

そもそもパニックタイムが10秒程度なら十分許容範囲だから例えにならない

得点を正確にもとめるだけで難しい。
牌と、親と風渡したら点が高速に求まれば開発は楽なのだが。
紙はいないものか?　まうじゃんは使いこなすのが難しい。

ここでソース配布されてるけど使い方難しい
ラッパー作って下さい


http://www.geocities.co.jp/SiliconValley-PaloAlto/4984/knetmaj/index.html
http://www.vector.co.jp/soft/win95/game/se316229.html

シュミレータとしてまともに動作して現在入手可能なのはまうじゃんだけとおもうから
これにあわせるのが一番かな　グラフィックONで対戦になるから速度は遅いけど

点計算ならこないだ作ったけどあんま実用性に適う速さは出せなかった
単純に役判定するだけなら速いけど、全ての役とか符の数え方を試して
比較っていう風にしたら遅くなってしまった。
俺の力不足なだけﾀﾞｹﾄﾞ

ほとんどは、役無しを渡されるはずだからそれが速くなればいいはず。
点がつくとき役と符計算に時間掛けても正確な方が良い。

13枚手持ちにあり、配られる牌がわかっているとすると
何手目で上がりかどうやって調べたらいい?　
これら次と同じ事だが。
例えば20枚の牌でいずれか6枚取り除いたら上がりかどうか
高速に判定する方法ある?

>>443
先に面子出来てるかどうか判定してからやれば速いね。そういえば。
でもAIとか作る事考えると「どう打てば高い点数になるか」ってのを考えるときに
やっぱり何回も呼んじゃわないかな？

なんども判定したとしても、98%が役無しでそれが例えば10msで
役ありの時500ms　(50倍かかるとした)　なら、平均約10msのパフォーマンスになる。

平均（期待値）は 20ms だろ
正確には 10 * 0.98 + 500 * 0.02 = 19.8 ms

AIが心持長考しだしたらテンパイだと分かるのか

テンパイ時と同じ時間waitを入れておく

モンテカルロで例えば1万回試行したら、１秒以内に指すには、
0.1ミリ秒=100ナノ秒で判定しなければいけない。

イーシャンテン、リャンシャンテンの判定は何秒くらいだっけ

このスレから出たものだと思うけど
http://jamong.s285.xrea.com/
ここに向聴数求めるプログラム置いてあった。
かなり速い

しかしこのスレ潜在的に読んでたやつがこんなにいたんだなあ。
それとも最近の勢いに引きつけられてきただけか。

正直作る気満々だったくせに、いざ作ってみたらあんまり強くなくって
出るに出れないのは俺だけじゃないはず

おまいら最強の〜系スレはどれも読んでる

どなたか代わりにソース打ってくれないですか?
アイデアはあるんですけどプログラム、デバックが苦手なんです
他人にあがられる確率は自分より3倍程度高いので
自分があがりにくい場合は安全牌を切った方が良いのですが
それは後回しにして自分の牌を揃える方法について記載します

13枚持っていて、一つ牌が配られて14枚持っているとします　ここで上がっていれば勝ちです
残りの出てくる可能性のある牌をランダムに生成して、
15枚持っているとしていずれか一枚捨てたときに上がりになるならばその牌に1をカウントします
上がりにならないなら16枚目をランダム生成していずれか2枚捨てたら上がるならばその牌に1/2をカウントします
これを繰り返すと、上がりやすい牌にカウントが集まります

ここで牌を捨てたときにあがりがあるか判定する方法は、特殊な役満は除外(起こりえないとします)すれば
チートイと通常の役だけになります　チートイは直ぐに判定出来るので通常役について説明します

でもお前どうせリバーシ１だろ

あがり判定の部分なんですけど、一手目でテンパイに出来るとき、した方がいいとは限らないんです
テンパイにせず別のあがりを狙った方があがりやすい事があります
テンパイにならない捨て牌も考えると総当たりになって膨大な計算が必要になってしまいます
20枚のうち6枚捨てる場合の数は、単純計算で、38760通りになります　
これでは何度も試行出来なくなります
実は簡単に求める方法が見つかっていません

ランダムに牌を配っているので、確実に起こりえることではないので、厳密でなくても良いとすれば
例えば、小さい順にジュンツが見つかれば確定し、次にコーツ確定し、残りでトイツが作れるか調べてみる方法、
大きい順のジュンツ、次にコーツ、最後にトイツと調べる方法など
判定方法を限定しておけば処理は速いですが・・・

>>456
99%努力しろよ

誰か共通AI仕様作って（ﾊｧﾄ）

「まうじゃん」対戦相手プラグイン　インターフェース仕様

http://www.amy.hi-ho.ne.jp/ishihata/maujong/iface.html

>434
前向き枝狩りいれないと、
本当に単なる天和シミュレータになってしまいます。

数億回の試行回数でも足りません。
UCT以前に最初の１回を上がるだけで大変。

マアジャンは混沌から秩序を作り出すゲームだからランダムにやってると
ぜんぜん上がれないんですよ。

>>463
探索のときに指し手を選択しないで、ランダムに牌が配られたときに、
役がそろいやすい牌を選べばいいと思う

>>463
せっかくコンピューターつかうんだから全部の手を調べて絶対上がれる手
とか調べれば？

>>465
配牌時に一九字牌が無い状態で国士無双が上がれる
確率を求めることに意味が無いことくらいは理解してるよな？

>>466
まーじゃんやったことないし。

>>463
ある程度のパターンはDBに入れちゃえばよくね？

序盤のグッダグダな分は字牌整理ルーチンに任せるとかして
ある程度先の見えた牌勢を適当に数億パターンくらいにしぼって。

ツモの流れとか無視することになるけど、そのあたりの改造は
モノが出来てからのお楽しみにとっとくのがいい

まうじやんがこのスレの基本システムなんでよろしく

いくら強いのを作っても需要は無く自己満足にしかならないよな

賭け麻雀の代打ちに使えるくらい強かったら需要あるかもよ

人間相手にはそれほど強くないと思う。統計的には何万局とかすれば強さはわかるだろうけど
相手が固定だと、相手の待ちや役わ予測しやすい人間の方が有利かもしれない。

まうじゃん使えば、勝手に動かせて1000局ぐらいはやれると思う。うpしてくれる人いれば活発になるかもしれない。

AIが気軽にサクサク生み出せるプログラムできたら活気づくだろうな

>>474 それだ。まずは条件を一意に表せる表記を作るんだ。
それからコンパイラの実装というフェイズでなら、君ならやれる。
(と、最後は他力本願

GUIでパラメータを設定すると、Cのソースが出てきてコンパイラに通すだけのやつ

でも相当細かく設定できるようにしないと、強さが似かよるというか
打ち方がワンパみたいなジレンマが
難しい話だな

カブロボの設定のみでいいやつみたいなやつｷﾎﾞﾝﾇ

専用言語を作るってのが一番確実だろうな

※麻雀ロジック研究会※
http://pc11.2ch.net/test/read.cgi/gamedev/1105332492/

で、今のところ最強の麻雀ソフトは何なの？

芹沢未来かな・・・

ゲーセンのやつはインチキなんじゃ？

イカサマが最強だって哲也も言ってただろ？

インチキなしのアルゴリズム最強を知りたいよ

インチキ無しだと単に確率を見ればいい。
効率の良い打ち方を超えるのは神でも不可能と
市川も言ってただろ？

確率を分りやすく出力するプログラム
作ってよ（はぁと）

>>484
そんなことは言っていない。
イカサマはあくまで手段だって言ってる。

とりあえず、まうじゃんのAIよろ

何この他力本願スレ

元々、それで誕生したスレです

他力本願ゆえにソースが一個もあがりません＞＜

おまいら最強のシストレFXプログラムをしてみろよ
http://pc11.2ch.net/test/read.cgi/tech/1211790540/

役の複合って

立直
一発
自摸
海底摸打
翻牌
混老頭
混一色
対々和
三暗刻
三槓子
ドラ

の１１個が最高？

はいはいトイトイツモトイトイツモ

>>494
立直 + 混老頭 + 対々和 の条件だけで
四暗刻になってしまう気がするｗ

立直はリンシャンにチェンジできる？

http://cocoa.2ch.net/mj/kako/981/981695407.html

１１１１東東東東白白白白中中發發　ロン發
ダブルOPENリーチ、ハイテイ、ダブ東、白、發、小三元、対々和、
三暗刻、三槓子、混一色、混老頭、ドラ３２。
（リーチ一発とハイテイは複合しないように思われるのでダブルリーチに変えました）
１４０符５５翻、約３京点かな・・・


符と役満
http://www.geocities.co.jp/SiliconValley-PaloAlto/8370/majan/majantalk.html

>>498
その点数、場ゾロ忘れてないか？

ロンならハイテイじゃなくてホーテイだろ

>>500
大した指摘ではないな

符点にも翻数にも影響ない罠

>>498
カンしてダブリーは無しのところの方が多い。

C#使いのおれに何か数時間でできそうな仕事ある？
簡単なDLLぐらいなら作れるけど、もちオープンソースで

>>504
DLLの作り方をまとめて解説サイトを作成する

ViasulStudioなら設定ひとつじゃねーか・・・

>>504
他の言語での思考ルーチンとの橋渡しをするインターフェイスを作って

>>504
C/C++/C#/Java/VB/Delphi使いの俺が居る
お前不要

>>504
>>508

お前らにお願い

・手牌のシャンテン測定
・テンパイの可否
・役判定

これらのプログラム書いてよ

まず牌データの構造を決めろよ

>>510
この辺の仕様はいかがでしょうか？
これでも使いにくいというなら牌データ構造はお任せします。


まうじゃん」対戦相手プラグイン　インターフェース仕様
http://www.amy.hi-ho.ne.jp/ishihata/maujong/iface.html

MJexeIO.DLL（東風荘画面入出力用ダイナミックリンクライブラリ）　開発者マニュアル
http://www.interq.or.jp/snake/totugeki/MJexeIODLLfunc.htm

第10回　麻雀の役を判定す

http://itpro.nikkeibp.co.jp/article/COLUMN/20070516/271225/?P=2&ST=develop
http://itpro.nikkeibp.co.jp/article/COLUMN/20070516/271225/

つかむしろ>>510には

　「誰も手軽に使える牌データ構造」

を考えてよｗｗｗ

面子判定とかは牌自身にやらせればいいんじゃないか？

>牌自身にやらせれば
意味不明。ちゃんとした日本語で書いてよ

能書きだけ垂れて結局>>508は逃げ出すけどな

こんなDLL作って下さい

引数
牌:'M1M1M1M2M3M4M5M6M7M8M9M9M9',上がり牌:'M1',属性:(自莫/嶺上/嵌貫/ロン),親:True/False
戻り値
符点,翻数,点数

それだけの引数じゃ足りない

足りないのは、天宝地宝、ハイテイ、ドラ・裏ドラ、ポン・チー・明暗カンの状態。
まだ足りないかもしれない。あった自風・場風・場の点棒、場の1000点棒の数。
まだ有るか?

>>518
チョンボしてるかどうか

リーチ状況とか

属性の嵌張はいらない
こっち側で判断させる方が良い

ツモロン嶺上搶槓で分ければ良いんじゃないかな

多牌少牌の有無と、他のメンツがそれを指摘したかどうか

>多牌少牌の有無
wwww
なんでコンピューターマージャンで多牌すんだよ
どんなバグだらけのプログラムなんだよｗｗｗｗ

3枚一度にツモるコマンド、切り忘れコマンド他ｗ

でも、ノーテンリーチが出来る機能は必要かもね。

注文はいいから早く>>516のＤＬＬ作れよｗｗｗ

てめーで作れ

基本的過ぎるアホな能書きばかりで
前に進まないしプログラムも上がる気配も無い

本当にここはプログラム板か？
少なくとも>>508は何かリアクションしろよｗｗｗ

>>516

つhttp://itpro.nikkeibp.co.jp/article/COLUMN/20070516/271225/

保守age

暇つぶしに麻雀ゲームでも作ってみようかと思ったけど
実装を考えてみるといろいろとめんどくさそうだなあ

意外とそうでもない
手牌、河をしっかり定義しておけば
そんなに手間は掛からない

>>531
ほう

「まうじゃん」対戦相手プラグイン インターフェース　
http://www.amy.hi-ho.ne.jp/ishihata/maujong/iface.html

面倒なのは，可能な上がり方を列挙して待ち牌を調べるとか
一番得になる役の組み合わせを探す辺りか

今日このスレ見つけて、AI評価用の対戦システム作ろうかと一瞬思ったんだが、
まうじゃんとか、http://www.jan-x.jp/とか見ると、
やっぱ需要がないんだろうなー

>>532
1局をざっくりと

(処理概要)
-----

1. 洗牌・配牌

2. 任意のプレーヤーのツモ処理

3.ツモ後の動作
3-1. ツモアガリならばアガリ処理→局終了
3-2. 任意のプレーヤーの捨牌
3-3. 任意のプレーヤーのカン処理→「リンシャンツモ」として、2の処理にもどる

4. 捨牌後の他プレーヤーからのリアクション（チー・ポン・カン）確認
5. リアクションがあれば、そのリアクション処理
6. 流局していないか確認→流局ならば局終了
7. 2のツモ処理にもどる

-----

という流れで処理すれば、若干特殊な処理もあるが、
ほぼほぼ実装は終了している。
意外と難しいのは、AI処理の方。

>>534
>可能な上がり方を列挙して待ち牌を調べる。

全ての牌に対してしらみ潰しに調べた方が早い
テンパイチェック・待ちチェックは下記ページを参照
http://www.interq.or.jp/snake/totugeki/mjcom_p0.htm

>一番得になる役の組み合わせを探す辺りか

　１１１２２２３３３８８８９９

という組み合わせならば、

　１１１　２２２　３３３　８８８　９９
　１２３　１２３　１２３　８８８　９９

という順子と見るか、暗子として見るかを比較して
高い方を採用すれば良いはず

>>535
数年前「MJsim」なるもので、麻雀のAI対戦を行ったことがある

MJsim実行環境
http://www.rupan.net/uploader/download/1219482153.zip

需要が無いことも無いと思うがな…

>>538
ID が不正です．って言われちゃいました。

再アップしました。もっといいローダーがあれば教えてください

MJsim実行環境
http://uproda11.2ch-library.com/src/11112772.zip.shtml

>>540
どうもありがとうございます。
無事ダウンロード出来ました。
動かして見ましたが、きちんと動いているようです。

前スレは見れないのですが、>>97によるとバグがあるのでしょうか？
どちらにしても、機能を追加したい場面も出てくるでしょうから
ソースが使えないのは痛いですね。

対戦システムはオープンソースとして開発するのが一番だと思います。

(っ´▽｀)っ
「最強の麻雀」「プログラム」？
「最強の」「麻雀プログラム」？
どっちだろ？
「最強の麻雀」なら宇宙麻雀だけどね。

>>541
そのあたりは話がややこしいので

実は、

「製作した人」
「前にzipにまとめてアップしてくれた人(>>97)」
「私」

がそれぞれ別人なんです。

公開当時はちゃんとソースも公開されていたのですが、役判定部分ソースが
別で公開されていたソース（現在は非公開）を使用して、
著作権がグレーな状態で、今回もソース公開していません。（私も持っていません）

「製作した人」が今はいないので、今後は「一から作り直す」方が早いでしょうね

>>543
なるほど、了解です
車輪の再発明になってしまうので、出来ればやりたくないものですね

まったり麻雀やまうじゃんの人にお願いして
オープンソース化してもらうという手もあるかと思いますが、どうでしょう？

To まったり麻雀やまうじゃんの人

オープンソース化してください　＞＜

すみません、お断りします。（ソースが汚くて恥ずかしい）

そんなに難しいものではないので自分で作った方がいいですよ。

>>541
>前スレは見れないのですが、>>97によるとバグがあるのでしょうか？

得点計算で100点単位で切り上げられないバグは既知。
それ以外にもバグはあるはず

>>546
即答ありがとうございますｗ
私の同意見です。

「車輪を再生産」する気負いがあれば、「AI評価用の対戦システム」の
製作はそんな難しくないはず。
wikiとか使って、みんなで分担して開発すれば、そんなに大した
仕事量ではないと思いますよ

>>546
まったり麻雀の人？まうじゃんの人？

>>544
こういう奴ほど決まってゴミを生産するんだよな

>>544
ひとつくらいは自分で車輪以外の部品を作ってみろ
話はそれからだ

8月中に何か作りたかったのに牌の表示しかできなかった＞＜

役判定とか得点計算とか根幹のシステムは作れたけどGUI部分を作るのに断念した

C#でも使えばいいじゃん

>>552と>>553が一緒にやればいい

作るなら「脱衣まーじゃん」にしてください＞＜

じゃ、俺脱ぐ係ね。

じゃ俺脱がす係

じゃ俺見る係

じゃ俺撮る係

>>557,558
麻雀いらなくね？

　ヽ('A`)ノ
　　(　 ) ゛ さぁ麻雀しようぜ
　゛/ω＼　

＿[警]
　 (　 ) ('A`)>>562
　 (　 )Ｖノ ）
　　| |　　| |

徹まん明けでタイーホかｗ

次スレ

おまいら最強の脱衣プログラムしてみろよ

>>565
玉ねぎが主役か？

最強の脱衣って、あれだろ

ゲーセンに行って、筐体の前に座って、100円入れて、スタートボタンを押す
配パイが終わって、さあ、と思ったところで

相手が天和

そしてゲームオーバー

さすがスーパーリアルなだけはあるよね

>>565 裸身活殺拳でおｋ？

http://doranizm.hp.infoseek.co.jp/
これってRでいうとどの程度のものなの？

時はこの数年ソースが一度も上げられたことが無い謙について

制作物はともかくソースはいらんだろ

まず、その製作物はDLLレベルですら上がってきていない

また、>>544にもあるようにソースに対してのニーズは非常に高い

ニーズがあるのはゴミグラマの間でだけ。

ゴミグラマでない>>573は何か製作物を上げてくだされｗｗｗ

他人に要求する前にまず自ら差し出しましょう

お！？
気前のいい>>575ですね
期待してるので早急に上げろよ。

期限は今日中

↑ゴミは黙っとけ

以下スルーで

結局のところ、対戦システムから自分で作るしかなさそうですね…

あまり需要のないものは作りたくないんですが、
もし対戦システムがあって、大会みたいなことをやるとしたら
参加してみたいっていう人はいます？

俺は興味あるよ

います
需要あり

>>579
ノ

>>579
参加はしてみたいが、特技「三日坊主」が発動するので
ほぼ乱数打ちで参加するでしょう

今のところ俺も入れて5人以上は居るみたいだな

でも5人しかいねえみたいだなｗｗｗ

しかし麻雀はできるだろ

5人かよ〜ラス抜け？

需要が無いなら作らないだと・・・ライト兄弟が動力飛行を成し遂げたその瞬間に飛行機の
需要はあったか？産業革命以前に生産機械の需要はあったか？文字すらなかった先史
時代に書籍の需要はあったか？答えはNON NON。真のイノベーションは誕生するまで
誰もその重要性に気がつかない。

>>579
で、作るの？作らないの？

なんでもいいからはやくあげてくれ

チートイツアルゴリズム作ってみるわ

チートイの立直、和了判定アルゴリズムなら30秒で書けるだろ
チートイを狙うアルゴリズムなら戦局に与える影響なんて皆無だから
もっと他に書く必要のある処理を考えた方がいい

>>592
30秒は無理ｗ

頭の中でなら書けそうだがタイプ的な問題で無理だ

int ChkChitoi(int tehai[4][9]){
int tmp[3] = {0, 0, 0, };
for(int i = 0; i < 34; i++){
switch(tehai[0][i]){
case 1: ++tmp[0]; break;
case 2: ++tmp[1]; break;
case 3: ++tmp[2]; break;
case 4: return 0;
}
if((tmp[0] > 2)||(tmp[2] > 1)){ return 0; }
}
if(tmp[1] == 7){ return 1; } //ho
return 2; //reach
}

30byooooooooooooo!!

三十秒かどうかはさておいても、大概の役判定は結構短時間で組めるよね
んで、全ての役の中で一番面倒臭いのが平和という罠

符を数えて、20符という判定

フリテン回避とか難しそうだ

符計算も鳴き多発時の同順振り聴回避も0.5人日くらいでしょ。日曜だしできるさ

しかし符計算自体を理解するのにまず半日かかるw

上がった時に何通りかの面子と頭を取れる場合どの組み合わせで取れば一番点が高くなるか
これを速度を考慮しつつ綺麗に実装するのが難しい
符を高く取るが平和があれば優先するみたいなのとか

そうか？あがった後なら頭取って４回再帰で終わりじゃん
和了判定＋α程度の計算量だから大したこと無い

それより３〜２シャンテンぐらいからの手牌の選び方がムズいだろ
その点数計算と和了確率計算を同時にしなきゃいけないんだぞ

>>537
>一番得になる役の組み合わせを探す辺りか

　１１１２２２３３３８８８９９

という組み合わせならば、

　１１１　２２２　３３３　８８８　９９
　１２３　１２３　１２３　８８８　９９

という順子と見るか、暗子として見るかを比較して
高い方を採用すれば良いはず

リーチ
ツモ
トイトイ
ｗｗｗ

Javaで作ってみようかな対戦用システム

っていっても、どうやって外部のAIクラスを読ませるのかがよく分かって無いんだけど

http://www.amy.hi-ho.ne.jp/ishihata/maujong/java/
http://www.amy.hi-ho.ne.jp/ishihata/maujong/java/mjai_iface.html
http://www.amy.hi-ho.ne.jp/ishihata/maujong/java/javadoc/current/jp/gr/java_conf/ishihata/mj_ai/package-summary.html

いや、そういう意味で無くて
どうやって外部にあるクラスを認識させるかがよくわからないというわけで。
フォルダの位置とか。

Javaはだめだ。　やるならC++にしないと人気でない

…そ、そうなのか？
カズタマイズとかも楽かと思ったんだが…
C++はDLLの作り方全然わからん

どっちがいいんだろ？JavaとC++。

ＧＵＩ面倒くさいけど、諦めてC++でやるわ。
DLLは頑張って勉強する。

GUIは別の人がやって良いから、点数計算がちゃんと出来て対戦結果を出力できれば
良いと思います

ルールを決めてから作った方が良いよな。　変更があれば随時変えていって。
ドラをどうするとか。

じゃあ自分GUI作るね。

GUI作ってくれるんならいいけどなぁ
今、wxWidgetいじってたら
wxWidgetのLibとdll作る過程でもう躓いてる…
SDlなら余裕なんだが。AI用に色々リアルタイム出力しないといけないと思うし…

ほんと、この辺は弱い、弱すぎる。

ルールはとりあえず、
237にある
ttp://mj.giganet.net/yaku.htm
でいいんでないかと思う。

こっちがいい。
日本プロ麻雀連盟競技ルール｜日本プロ麻雀連盟
http://www.ma-jan.or.jp/guide/game_rule.php

>>614
wxWidgetは入らないですからunixでもmacでもwindowsでもコンパイルできる
コマンドラインの判定ルーチンをお願いします。
DLLやGUIはわかる人がやります

東風荘ギャンブル性が高く実力を測るのに向いてないと思います。
プロルールお願いします。

wxWidgetもう諦めるわ
これだけの時間やっていまだにどうしようもない
コマンドラインも全然わからんから(たぶん文字列だよな)
とりあえずSDLで組むわ。
でも、もう今日は力尽きた…

>>618
コマンドライン = 標準C/C++　という意味です。　
役と得点計算が標準C/C++で書いてあれば発展すると思います。

誰かまったり麻雀の中の人にこのこと教えてあげて
ttp://diary.jp.aol.com/eddwgcfnr/451.html
>当社の麻雀は、プログラム上、配牌の操作を行っておりますが、
>より楽しい演出とご理解頂ければ幸いです。
>今後とも天鳳を宜しくお願い致します。

誰も聞いてないのにいきなり配牌操作がどうとか言い出すキ○ガイ開発者はいないだろ

http://mahjong.ara3.net/ymt/diary/index.htm

とりあえずこんなの書いて見ました

>>622
一人麻雀練習機で延々遊んでしまったぜｗ
判定部分は十分じゃね？

>>622
一日で進みすぎワラタ
ＧＪ

作ってたのあらさんだったのか。これは期待できる

お、あらさん久しぶりだねえ

>>626
あ、久しぶり。ってどこかでお会いしました？

>>623-625
ま、あんまり期待しないでいて下さい

まずは、このルールで点数が一致するものを作る

日本プロ麻雀連盟競技ルール｜日本プロ麻雀連盟
http://www.ma-jan.or.jp/guide/game_rule.php

>>628
がんばってね

GUIはフラッシュにしてください＞＜

　　　　　　ﾊ,,ﾊ
　　　　　（ ﾟωﾟ )　　お断りします
　　　　／　　 　＼
　 ((⊂ 　） 　 ﾉ＼つ))
　　　　　（＿⌒ヽ
　　　　　　ヽ　ﾍ　}
　ε≡Ξ　ﾉノ ｀J

まず、サーバとクライアントのプロトコルの仕様を決めて、
それから好きな言語で実装するのが良いと思う。

プロトコルの仕様はSMTPやPOP3みたいな感じで、
将来的にはRFCに登録。

なんでメール用のプロトコル使うんだ？
もっと使えそうなのがあるだろ

>>633
そういう意味じゃなくて、SMTPやPOP3のようなASCIIベースの
プロトコルが良いってこと。

だったら参考にするのはコーヒーポットプロトコルだな。

>>633
理解力なさ過ぎて吹いたｗ

Javaで作りたいので共通プロトコルを作ってください＞＜

XMLでいいよ

こーいうの作ってください＞＜

USI(Universal Shogi Interface)プロトコルとは、将棋GUIソフトと思考エンジンが通信するために、
Tord Romstad氏によって考案された通信プロトコルです。USIの原案は、以下で読むことができます。

http://www.geocities.jp/shogidokoro/usi.html

すげー久しぶりに来たけど、まだやってたんだな。
言語に依存しないようにプロトコルの策定からやるの？
inetd形式で棋譜つき雀卓サーバでも提供しようかと思ったけど
4人で1卓じゃそのままじゃむりか。人間も参加できるようにするなら観戦もいる？

単純なのでいいからなんか作ってくれ
スレは長いが口だけ野郎が多いから

こんなんでいいんで作ってください？＞＜

http://bon4714.0web.cjb.net/BQjara/

ソース公開したらいかさまし放題じゃん

>>643
サーバとクライアントを別プロセスで動かせば問題ないでしょ。
最初はセキュリティホール的なものもできちゃうかもしれないけど。

俺用メモ
>570 == >572 == >574 == >576 == >630 ==>637 == >639 == >641-642

ストーカー行為はやめてください＞＜

何も決まってないなら、とりあえず思いつくままコマンドあたりから書き出してけば？

コマンド
【名前】自模牌要求
【コマンド名】PaiReq
【方向】cl - > sv
【コマンド概要】プレイヤーからサーバへの自模牌要求

みたいなな感じであげていって、あとはそれぞれシーケンス描いてみてダメな部分・足りない部分を要らない部分の
追加修正削除をわいわいやってみたらなんとかでっちあげられるんじゃね

MJSimのC#版みたいなの作ってるんだけど、こんなのどう？

仕様
・AI同士のみでひたすら対戦。
・東風荘のログを出す。
・AIは、.NETのDLLとして製作する。

ルール
・東風荘ルールがベースで、一部変更。
・カンなし。アンカン、ミンカン両方できない。
・チートイツなし。
・役満なし。
・親のノーテンで流れる。

ルールは後でも良いから
プロトコルの策定をしてほしい
そうすればクライアントに取り掛かれるから

サーバサイドとしては

１．開始時にクライアントからの接続待ち
２．卓の配置、親の決定
３．河および山の情報が変わるたびにクライアントに通知
４．４つ（固定よりも可変のほうがいいかも？）のクライアントからの返信を待つ
くらいかな？補足ヨロ

他に
風牌とかドラ（表示？）牌のリクエストは不定期で受け付ける？
他家の点数リクエストは不定期で受け付ける？
河の情報はすべて再送信する？差分だけにする？
待ち時間は最大何秒（何ステップ？）にする？
途中でクライアントが放棄または接続が切れた場合はどうする？
一局終了ごとに譜（なんて呼ぶんだ？）を送信する？
ノーテンリーチは可能？
リーチ後の見逃しは可能？（高目をツモるため）
フリテンリーチは可能？

昔一人でプロトコル策定してw、サーバプロセスとか作ってたんだけど、
意外に興味ある人もいるのかな？

SourceForgeにプロジェクトでも立てようかと思ったけど、SFって
Wikiは使える？

このスレで反応をみてからにしろ
SFは早まるな

オープンリーチの有無は決めておかないと
クライアントの作り直しになる可能性があるな

>>649
もうちょっとほぐしてみた。

こんな感じで叩き台になりますかね。

・マッチメイク
　別途

・対戦サーバ
　すでにマッチメイクが済んでいることとする。
　各クライアントは対戦に必要なキーを含む情報をサーバに送る事で参加する。

１、開始時にクライアントからの接続待ち
２、席順、親の決定
３、配牌、自摸／打牌、チー、ポン、カン、和了などのアクションを必要なクライアントに通知
５、クライアントからのACKを待って次に進む
４、ACKにはチー、ポン、カン、ロン、チャンカン、チョンボアピール※などを乗せる
６、和了まで繰り返す
７、和了時、点数の計算、終局判定
８、配牌に戻る

※他のクライアントのアクションについてチョンボであるとサーバーに告げるコマンド

・不定期なりクエストに応じてサーバーからクライアントに通知される情報
　クライアント情報、風牌、ドラ表示牌、他家の点数、河の情報

・ルールで決定、または選択ルールとしてマッチメイク時に対戦希望クライアントに通知
選択ルール、ローカルルール
待ち時間、クライアントが放棄または接続が切れた場合の処理(チョンボ扱い、ツモきりモード、ランダムきりモード)
ノーテンリーリなど、クライアントが指摘できないものについて、サーバーでは判定しない(流局時に露呈するものは除く)。

>>651
スマン、早まってプロジェクト申請しちまったw

>>652
個人的にはオープンリーチは無しが良いかと。

>>653
チョンボは面倒が多いので、不可にしてしまう方が良いと思います。
ノーテンリーチに関しては、クライアントからリーチのコマンドがきても
サーバが認めない等。
確かにノーテンリーチは戦術として使えなくもないので、禁止するのは
微妙かもしれませんが、チョンボってのは色々問題を孕んでいるので
起きないに越したことはないかと。

最強を目指すんならプロトコルだとか何だとか言う前にどのルールを採用するかが重要だろ、
競技麻雀路線で行くにしてもプロ団体でも採用するルールが異なってるし、雀荘路線で行くなら赤の使い方が当然絡んできるし。

どうでもいい三文プログラム書くより、本気ならまず統計的分析から開始するのが本筋だと思うけど？

>>655
まずは麻雀を打てることが大事だ

>>655
現段階では板違い
http://money6.2ch.net/mj/
ここで思う存分統計的分析してきてくれ

>>655
統計を取るためにも、三文プログラムが必要だと思うけど？

>>649
wikipedia より
牌譜（ぱいふ、はいふ）とは、麻雀の自摸や打牌などの動作（摸打）、点数の得失などを記録したもの。野球のスコア、囲碁・将棋の棋譜などに相当する。
http://ja.wikipedia.org/wiki/%E7%89%8C%E8%AD%9C

>>657
自分で勝手な妄想で判断するなよ、統計的な裏付けの有る読み、打ちをするプログラムが最強に最も近いのは当たり前だろ？
逆に言えば、理論的な根拠の無い打ち方をするプログラムになにか意味が有るのか？

動かないよりは意味がある

下を見てもしょうがない
上を見るんだ

下がなければ、上には行けないんだが

反応なしで寂しすぎるが、とりあえずうｐする。
http://migumi94.nobody.jp/dennoso/

まだ作ってないところも多く、バグバグだがこんなもんということで。

まずは点数計算が正しくできるところから確認して作るべき

ルールはこれで

http://act0.net/cgi-bin/source/up0280.txt

点数計算はサーバのサービスでいいと思うけどな。
ルールによっても変わってくるし。
でもいちいち可能性のある手の点数をサーバに問い合わせるのは無駄か？

そのサーバーの点数計算が間違えていたら、ルールが通じないことになる。
慎重に作るべきところで最も重要なところといえる。

>>665、>>668

じゃぁそこのロジックはオマエらに任せた。
手牌を渡すから、得点と役を返すファンクションでもクラスでもいいから作ってくれ

頼んだぞ

渡すのって単に手牌を渡すだけじゃないよね。
風と局、ツモやロンの区別とその牌、晒してるかとか海底とかリーチとかどういう風に渡せばいいものか・・

手牌(上がり牌)
鳴き
ツモorロンorﾁｬﾝｶﾝorﾘﾝｼｬﾝ
局・風
リーチorWリーチ・一発
天・地・人和
海底or河底
(八連荘)

こんだけあれば役得点計算できるかね

何か知らんがインターフェースを決めるだけでも
大変そうだな。

>667
まず、ゲーム開始前に手と得点の一覧表を
サーバーに問い合わせると言うのはどうかね？

ていうかまずやることリストアップしたほうがいいんでね
目次うp

>>666のルールで作ってみるか

とりあえずSourceForgeでプロジェクトが立てられたので、
Wikiにざっとコマンド案とかを書いてみた
http://sourceforge.jp/projects/openmj/wiki/FrontPage

実装は今から頑張ります(^^;
とりあえずRubyで麻雀ライブラリを書いてから、サーバプロセスを作る予定

>>675
字牌の表記が東風荘と違うんだけど、天鳳か何かだとそうなの？

>>676
いや、別に他のに合わせる必要もないかと思って気にもしなかった。
ということで、中途半端に似てるくらいなら、東風荘に合わせようかと
思って調べてみたけど、東風荘は字牌は漢字表記？
だとしたら、それはイヤだな。

>>675
自分の下家がチーで鳴いたのか
ツモなのか判別できない気がするのですが…

>>677
動作確認で牌譜再生ツールを使うと思うんだけど、nz表記用のを一から作るのも手間だし
現段階で安定したものがあるんだから、それで再生できるよう合わせた方がいいのでは？
・・・まあnz⇔漢字の変換ツールを作ればいいだけの話か。字牌の表記はお任せします

漢字は極力避けて欲しい
いわゆるASCIIコードの範囲内の方がいい

>>678
どういうケースでしょうか？
Wikiにも書いた通り、サーバから送られてくるのが
「実際に起きたこと」なので、サーバから下家がツモった
(tsumoコマンドがきた)ならツモ、chiコマンドがきたなら
チーとなる想定なんですが。

>>679
牌符は別にプロトコルに合わせる必要はないので、
東風荘フォーマットとかで出力するのは問題ないです。

>>680も言っている通り、ネットワークを通すプロトコルでは
漢字は問題を起こしやすいので、できれば避けたいです。

>>681
ごめん、勘違いしてた

kyokustartの説明が「一局が〜」になってますけど「n局n本場が〜」ですよね？
それとryukyokuでクライアントにtenpaiかnotenかを返させてますけど、
不正申告がないようサーバ側でチェックするなら不必要な気がします

>>682
いえいえ、色々抜けはあると思うので指摘して頂けるのは
嬉しいです(^^

>>683
「局」という言葉が正しくは何を指すのかが良くわからないのですが、
いわゆるサイコロ振って配牌取って、誰かが上がるまでを1局と呼んでます。
なので、言葉が混在してわかりにくくなってますがkyokustartについては
683さんの理解している通りです。

流局時にテンパイ/ノーテン宣言をクライアントに返させているのは、
テンパイしててもノーテンと宣言したい場合があるからです。
上がり止めなしのオーラストップ目とか。
当然、ノーテンなのにテンパイと宣言してもサーバ側では認めません。

ドラはそのものじゃなくて、表示牌を送らないと、
赤牌が表示牌の場合に対応できなかった。

リンシャンの通知は？

だから、多牌と少牌の処理についてちゃんと最初に決めておかないとダメだってば

>>687
職場にこんなこと言いだす奴がいたら絶対殴ってるわｗ

>>687
それは無しって事になってるのでは？

>>686
リンシャンというか、和了役の通知でしょうか？
今のところ入ってません。さすがにマズいかな？
とりあえずkyokuendで点数の増減だけで済ませようかなと
甘く考えていたんですが、ちょっともう一度考えてみます。

>>687
手牌はサーバ側で管理するので多牌、少牌は不可能です。

カンしたときのリンシャン牌の通知はツモコマンド？

>>691
そのつもりです。
リンシャンツモを特別扱いする必要ってあるでしょうか？

クライアントでも計算できるけどサーバに通知してもらえた方が
楽になることってどういう扱い？ツモったときの山牌の残り枚数とか
今はkyokustartで親を通知してもらってるけど、これなんかも
gamestartを作って最初に誰が親かを通知してもらえればいらない気が

sute<プレイヤー><牌>にツモ切りなのか
手牌から出したのかのフラグがあるといいかも

>>692
いえ、設計者の趣味の範囲なので、とくにどっちがいいという訳では無いです。
もし必要ならカンしたプレーヤーの直後のツモはリンシャンって処理するだけだし。

ただ、仕様としては、どっかに明記してあった方がいいかなと。

>>693
特に指針は決めてないんですが、基本的にはセッションは１局単位で
完結するようにしようと思ってます。

途中接続が切れた場合も、局の途中では戻れないが、次の局から
戻れる、みたいな。

なので、局が始まるときには、クライアントがその局の処理をするのに
必要な情報は渡すという感じです。

で、同じ面子で複数のセッションを繰り返すことで、半荘が成立すると。

ただこの辺はこれから実装して行くにつれて、色々変わって行く予感が
します(^^;

それぞれの牌にユニークなID振っていればツモハイ提供側で判別つくと思う
同じ種類の牌で手出しすることもあるけど、それはツモ切りではなくなるよね

>>695
ちょっと現状では必要性が感じられないので、
いったん保留とさせて下さい。

>>694
ああ、そうですね。それはあった方が良いな。
ありがとうございます。

個人的には空切りはキライなので、ツモ牌と同じものを
切ったらサーバ側でツモ切り扱いしたいんだけど、さすがに
それはマズいですよね(^^;

オカルトシステムNo.65「空切りは勢いを消す！」やw

>>697
なるほど！それは考えつかなかった。
ちょっとプロトコルを通す情報が(人間から見て)わかりにくくなるけど、
そうすれば確かにツモ切り判定はわかりやすいですね。

強いプログラム(AI)を目指してるのにいきなりネットワーク対戦プログラムなんて目的を見失ってないか？

>>698
ベタオリ処理で手出しから筋見てる部分があるので
空切りはツモ切り扱いでも構わなかったり(汗
それだと自分と同じベタオリ処理してる相手がいる場合のみ
立直側になったときにちょっと有利になるくらいかな？
ま、どっちでもいいです

>>700
自分としては、強いAIを作るための環境でもあるつもりです。
ただ、無駄に遠回りしているとは思います(^^;

もしスレ違いだという声が多ければ移動しますが、せっかく
何人かの方には反響を頂いているので、できればここで
話を続けさせてもらいたいです。

>>701
普通の麻雀でも、空切りを禁止した方が知的なヨミの要素が
増えて面白くなると思います。
ただまあプロトコルでできなくするのはマズいので、何か考えます。

>>702
プロトコルの策定は、プログラマ魂が湧き上がってくる話題で楽しいし、別に良いと思うのだが、あまり意味が無いかもしれないな。

というのも、実際はクライアント側にも共通基盤を作るはずで、
ネットワーク　--->　クライアント共通基盤　--->　ユーザAI
結局プロトコルは共通基盤の開発者だけがわかっていれば良く、どちらかといえば共通基盤のIFを決めたほうがいいかもね。

プロトコル＝IF

>>703のつづき
そういう意味では、とりあえずローカルで動くものを作っておいて、後でネットワーク対応にしても良いかと。

麻雀はルールや点数計算が複雑なため、これらを全員が作るのは明らかに無駄で、
クライアント側にもどうせサーバと同等以上のライブラリが必要でしょう。

>>704
それは現実的じゃないと思うって事を言いたいのだが・・・

いまの時点でのプロトコルはどう考えても、ネットワークプロトコルを指してないだろ。
管理プログラムとAIの通信方法。

>>707
？
話がかみ合ってないかな？
wikiには、「オープンなネットワーク麻雀のプロトコルを策定し」、「TCPを介した通信」って書いてあるけど・・・
それと管理プログラムって何？

>>703
まさにおっしゃる通りで、プロトコルの策定とか、わざわざ遠回りな
ことをしているのは「好きでやってる」というのが一番です(^^

そして、プロトコルを策定したとしても、クライアント共通基板(SDK的なもの)
が必要になるだろうというのは自分もそう思います。

ただ、色々なプログラムを対戦させたり、サーバ側でちょっと特殊な集計を
したいと思ったときに、共通プロトコルで動いているというのは価値が
あるのではないでしょうか。

とりあえず、前述した通り個人的に好きでやっているので、
生暖かい目で見守って、ときには意見やコードなんか頂けると
嬉しいです。

>>709
>共通プロトコルで動いているというのは価値があるのではないでしょうか。

あってもいいと思うのだが、コース料理でいえばデザートの部類ではないかと。

実際に動くAIが出てくるかどうか。
まずは、簡単にローカルで動く環境の提供が必要と考える。
要は、まずSDKから作ってみては？という意見でした。

オレはAIよりも、こういったシステムを作るほうが好きなので
こっちの話のほうが参加しやすいんだよなあ

システム作ったあと、AIはGP組み込んで、あとはぶん回しておけば
勝手に最強になるんじゃね？

SourceForgeの中の人はどこのルールで作ってるの？

ルールはこれで　コンピュータ対戦向けのオリジナル
プロルールに基づく


http://act0.net/cgi-bin/source/up0280.txt

101競技連盟、最高位戦日本プロ麻雀協会、日本プロ麻雀協会
日本プロ麻雀連盟、日本プロ麻雀棋士会、麻将連合

どれもルール違うだろ。「プロルール」なんてものは無い

ルールについては、今のところそんなに深く考えていません(^^;

まず、プロトコル(UMP)ではルールを規定しません。
それどころか、UMPではサンマでも青天井でも可能にする
想定です。
# ぶんぶんレジデンスの100人麻雀もできるようにしたかったけど、
# 現状だとプレイヤーをアルファベット１文字で表すので無理

ルールはサーバの実装次第なので、実際に動き始めてからでも
問題ないかと。
クライアント(UI)も、UMPにきちんと対応すれば、どんなルールで
あったとしても動作するハズです。

ただし、このスレの本旨であるAIを作るとなると、ルールによって
考えなければいけないことが変わるので、そのステップまできたら
ちゃんと考えないといけないと思います。

ふむふむ、だったらオープンリーチの対応もおねがいします。

>>711
あーそうか。
全員がAI作成を最終目標にしてると思い込んでたから、>>710とか書いてしまったが、
例えばプロトコルだけ考える人ってのがいてもいいわけか。
>>632さんはどこまで自分で実装する予定なんかな？

確かに棒聴即立で立直にベタオリだと立直時ツモ和了率六割越すけどプンリー有りは微妙・・・

>>717
オープンリーチ好きな人が多いなw
同じ人？
とりあえず仕様に追加しました。

>>718
自分としては、プロトコルの策定＆サーバプロセスの実装、
テスト用クライアントの作成まではやるつもりです。
できればWindows版のクライアントを作ってくれる人が
現れてくれると、すごく嬉しいです(^^

確かに棒聴即立で立直にベタオリだと立直時ツモ和了率六割越すけどプンリー有りは微妙・・・

>>720
オープンリーチは待ちのわかる牌だけ晒すルールもあるので、
晒す牌の選択はクライアント側ではないかと。

プロトコルが対応してないから採用出来ないルール、ってのは
出来るだけ無い方がいいでしょ？

>>722
サーバーは待ちのわかる牌を自動判別出来るはずだから、サーバーが決めるんでいいじゃん。

>>722
んにゃ、全部晒すかどうかもサーバ側で決定します。
どうせサーバ側では不正をチェックしなければいけないので。

一部だけ晒せばOK、というルールのサーバのときに、
すべての手牌を晒したい、というときには問題になりますが、
それに対応する必要性は感じないんですが、どうでしょうか。

たとえば、２３４５６と持っていて５６を晒してオープンリーチ、ってのが許されるルールはありか？
とかいう話かな。
もちろん、４，７のツモ上がり前提で。

>>724
>それに対応する必要性は感じないんですが、どうでしょうか。
プレーヤーにとって意味ある事かどうかは、
プロトコル側では関知しないっていうポリシー
だと思ってたけど、違った？

まずはルールはこれでいいだろう
http://act0.net/cgi-bin/source/up0280.txt

>>632
open<プレイヤー><手牌>で手牌全部見せたときと
鳴いた面子だけ見せたときのコマンドが一緒になると
クライアント側で牌の数チェックする手間がでるんで
手牌か面子(ポン･チー/カン)かのフラグが欲しいです

情報にはノイズ乗せないの？

打牌に制限時間設けないとひたすらぶん回し続けるAIが出てくる予感
一秒制限の早差し勝負とかもやってみたい

通信が遅れる可能性は十分考えられるので
サーバ・クライアント共に何回目のackかを示す情報も必要かも

>>725
さすがにそんなルールは聞いたことないですが、もしかしたら
1が枯れている場合はOKとかはあるかもしれません。

>>726
おっしゃる通りです(^^;
ということで、とりあえずopenrichiコマンドに晒したい部分の手牌も
指定できるよう仕様に追加しました。

>>728
openの手牌は、手牌の表記に則るので、
和了ったときは open A 1m2m3m4p5p6p7s8s9s1z1z1z2z2z
ポンのときは open A <3m3m3m>
チーのときは open A <1p2p3p>
暗槓は open A (8s8s8s8s)
となるので、クライアントでも容易に区別できると思います。

>>729
ノイズって、どういうことでしょうか？

>>730
実際に運用するとなると、時間制限は必要になると思いますが、
実験段階では、ひたすらぶん回して、それこそ1打1時間とかかけたとしても
本当に強いAIが出てくるなら、それはそれで面白いんじゃないでしょうか。

>>731
コマンド形式のところにある<センテンスID>というのがそれです。

ちなみに、最初はサーバから1コマンド送るごとに必ずクライアントの
ack(okコマンド)を待っていたのですが、実装してるうちに不要な気が
してきたので、必要なとき以外はクライアントからの返答を待たない
ようにしました。

1打1時間掛かったら強いことが調べられない

>>632
をを、プロトコルが強化されてる、乙かれ。

>>735
人間相手だと、さすがに人間の方が耐えられないだろうけど、
AI同士なら別に1打1時間かかるのもアリじゃない？
まあでも実際、将棋や囲碁に比べれば、麻雀はプレイヤーの
できることが少ないから、さすがに1打1時間はないと思うけど。

>>736
実装しながらなので、随時変更してってます(^^;

ちなみに、開発途中ではありますが、ソースコードをSourceForgeの
SVNに随時commitしているので、興味のある方は
http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/?root=openmj
から拾って下さい。

AIどおしでも1時間は無いよ。　たとえば一手3秒以内で1日中動かして統計を取ったとする。
これを一手1時間以内でやったら、同じ回数をこなすには1200日掛かることになる。
3年以上掛けてパソコンを動かさなければ強さが判らない。

PC1台で検証するならそうだな

PCの性能で応答時間は異なるけど、一つが遅ければ全体に影響するから
平均応答時間程度にするとかにして、時間切れはツモぎりとかのほうがいいとはおもう。

実際に色々なAI同士を戦わせてみよう！となったら、
麻雀のルールの他にも決めなければいけないことは
あると思います。
それこそ制限時間とか、あるいは鳴くかどうかのラグを
情報として使うのはアリか、とか、相手のAIの傾向を
「最初から」入れておくのはアリか…等々。
いうなれば大会のルールみたいなものですね。

一手に３秒もかかったら、まともな統計は取れないですね

>>729
733のいうノイズは、おそらく意図的な情報伝達ミスだろう
麻雀でいうなら見間違いとか切り間違いとか

ゲーム理論の研究ならノイズも必要だけど、麻雀サーバには無用な仕様だよね

ルールは実在ルールの中でもＡＩにとって処理しやすいものが良いと思う。

>744
エラー処理あるいはテスト仕様としては必要かも知れないよ。

つまりクライアントやサーバーが全く期待していない
矛盾した情報を受け取った時に何を返すべきか？
意味不明だと単にエラーを返すか、通信にリトライを要求するか？

そこまで仕様として決めておくのは面倒ではあるが、
下手をすると一回の通信エラーで全体が一気に倒れかねない。

今の仕様だと誤ポンも誤ロンもサーバが無視なのか・・・
クライアントが矛盾したロンやリーチしたら
それはそういうときの処理をした方がいいのでは？

ルールとプロトコルが直行するように決めるなら
ダブロンとかの扱いもちゃんとしておかないと

「コンピュータ麻雀のアルゴリズム」なんて本が出てるんですね。
Amazonのおすすめに出てきて驚きました。

>>747
誤ロン誤ツモはチョンボだろ
ノーテンリーチはかけられるようにしとかないと
戦略の幅が狭まる

>>747
自分の考えでは、誤ポンや誤ロンは、麻雀とってはまったく
不要な要素だと思っています。
極端な話、山を崩すのとたいして変わらないくらいで、
コンピュータ上で麻雀を打つなら、発生させないように
するのがベストではないでしょうか。

ただ、>>750の言う通り、ノーテンリーチについては戦術として
考えることもできるので、それは悩ましいところです。

>>748
一応現状のプロトコルの仕様でもダブロンは発生させることが
できると思います。
ただ、自分が作るサーバの実装では入れるつもりはありません。

チョンボはありだろ。　役満がほぼ出るならチョンボして流すという手もあり得る

なら、>>752 がチョンボあり版を作ればいいじゃない

>>751
極端な話、その仕様だとクライアント制作者は和了判定を素っ飛ばして
とりあえず毎回サーバに和了コマンド送信する処理でもいいことになる
まあ毎回でなくとも形聴取ったなら海底河底で一応和了っておけみたいな
錯和が不要という考えは分かるけど何かしら対策はした方が良さ気

そもそもサーバにそういった情報も問い合わせられるようにするなら
そんな心配は無用

http://ouc.daishodai.ac.jp/facilities/ams_labo/publication_bulletin.html

これの麻雀研究特集号を読んだ人いますか？　どんな内容でしたか？
「麻雀のベストプレイは存在するか」が気になる

鳴きのアルゴリズムって、基本的に

鳴いた場合の期待値　＞　鳴かない場合の期待値

の時に鳴くって考え方でおk？

>>757
一発消しだったり、自分が上がれる確率まで含めての期待値だったり

>>757
ま、どんなときでも期待値の高い選択をすればそれでいいわけで、
期待値が計算出来ないってのが問題ということです。
http://www.ara3.net/hmr/expect.htm

>>754
> その仕様だとクライアント制作者は和了判定を素っ飛ばして
> とりあえず毎回サーバに和了コマンド送信する処理でもいいことになる

別にそれでも全然構わないと思ってるんですが、問題あるでしょうか？

ある

そんなのは麻雀AIじゃない

二歩を指した将棋AIが負けを宣言されるとするならば
誤ロンした麻雀AIはチョンボを取られるべきだ
なぜなら、それが麻雀というゲームのルールだから

>>762
将棋の場合は二人なので、片方に対するペナルティは、
必ず対戦相手の利益になりますが、4人で打つ麻雀の場合、
あるプレイヤーに対するペナルティが、他の3人に対して公平で
ないのが問題です。

そう考えると、可能な限りペナルティが発生しないというのが
理想だと自分は思います。

>>760
抜け道があると「UMPでは最強かも知れないけれど〜」みたいな
グタグタな流れになるので、できれば対策して頂きたいです
錯和してるのに続行は問題なんで、和了放棄とか特別ルールはどうですか？

>あるプレイヤーに対するペナルティが、他の3人に対して公平でないのが問題です。
チョンボは親子関係なく3000オールって雀荘もありますけど、それでどうですか？

標的が和了するのを阻止するためだけに
わざとチョンボされるかもしれない問題ってのも
考えられるからルール設定の扱いにしては？

有効、無効はサーバ側で決定
局or半荘開始時にサーバからクライアントに送信される形で

補足しておく
ハコテンで半荘終了であるとする

ある局で特定のクライアントがトップ目であるとき
チョンボクライアントが常にチョンボすることで
半荘のトップ目をとらせるという戦略が考えられるなぁと

チョンボについて意見が多く、それに対して自分の見解をまとめて
みたんですが、あまりに長文になってしまったので
http://sourceforge.jp/projects/openmj/wiki/chombo
に書いておきました。

ちょっと書き逃げみたいになっちゃいましたが、自分としてはまず、
UMPでのサーバ/クライアントで麻雀を打てるようにする、というのが
第一にあります。

その次に、チョンボも含めたルールとか、あるいは実際にどこかにサーバを
立てるのか、どう運用するのかということを考えなければいけないと
思いますが、現状その段階についてはあまり具体的に考えていません。

# 正直、チョンボ云々より、実際サーバプログラムを作ったとして、どこで
# 動かしたら良いかの方が悩みです(^^;

もちろん議論自体は活発に行われるのは良いことだと思いますが、
とりあえず自分の現状のスタンスを表明しておきたかったのです。

まあテスト用のサーバとしてうちで提供してもいいよ。
RDBMSを積極的に使ったシステムがいいなあ。

つかさ、

チョンボの有無
ハコテンの有無
ノーテンリーチ、オープンリーチの有無
パオの有無
等など、、、

そんなのパーラメータ化して、サーバごとで管理できるようしろよｗ

2chだって"SETTING.TXT"で、板ごとの要求に合わせて
設定されてるんだし、ちゃんと参考にしとけよ

http://kobe.cool.ne.jp/r_030/2ch_jikken/SETTING.htm

sourceforge.jpで新しいプロトコルの作成を目指すなら、
それくらいの気のきいた仕様をちゃんと考えてからにしとけ

>>771
基本姿勢が決まってないととりあえず動かすためのクライアントを作るのが難しいぞ

一番言いたいことは、個人で採用したいルールはサーバー側では
簡単に定義できるような柔軟なプロトコル仕様であって欲しいということ。

基本段階で決定するような、麻雀のルール決めはサーバ管理者の
裁量に任せればいいが、プロトコルの仕様という話ならば、
どんな特殊なルールであっても、単純に組み込めるようになってないと、
そもそもプロトコルとしての意味が無い

東風荘や麻雀ファイトクラブで採用してないような
オープンリーチやフリテンリーチが固定で組み込
まれているようなプロトコルになるなら、絶対に使わないし、いらねえ

何度も繰り返しになりますが、UMPでは麻雀自体のルールは定義する
つもりはありません。つまり、「クイタンあり」みたいな情報をUMPでは
流さないで済むように考えています。

クイタンありかなしかはサーバの実装次第で、クライアントの実装では、
クイタンで和了ろうとして、サーバにコマンドを送って初めてわかります。

これだと問題だ！と考える方もいると思いますが、クライアントが人間で
あれば、例えばサーバのHPとかに書いておけば良いし、AIだとしても、
どんなルールにも自動で対応するAIというのは、手間がかかるわりに
難しいので、それを考慮する必要はないと思います。
それこそAIを動かす際のオプションで指定すれば済む話です。

>>771のように、パラメータを受け渡しする方法だと、そのパラメータを
策定しなくてはならず、無数にある麻雀のルールの洗い出しとまとめが
必要になり、それこそ気の利かない仕様だと思います。

>>770
そう言って下さる方が現れるのを期待していました(^^
もしよろしければ、SourceForgeの方に自分のメアドが
ありますので、そちらにメールを頂けますでしょうか？

>>774
了解です。それでいいと思います。

　クライアント→サーバ
　サーバ→クライアント

で、やり取りされるアクションや情報が全て網羅されることを期待しています。

個人的な要望としては、誰かがロン・ツモで上がったときや流局のときに
手牌を倒したプレーヤの手牌情報は取得できるようにして欲しい。

この手の仕様では、サーバ側が必要とする情報だけしか定義されていなくて、
クライアントからでは情報が取ってこれないということがよくある。
ランダムに吐くログを整形して自分で作りこみをしないといけなかったりする。
それは単純化して欲しい。

何度も繰り返しになりますが、UMPでは麻雀自体のルールは定義する
つもりはありません。つまり、「クイタンあり」みたいな情報をUMPでは
流さないで済むように考えています。

クイタンありかなしかはサーバの実装次第で、クライアントの実装では、
クイタンで和了ろうとして、サーバにコマンドを送って初めてわかります。

↑　↑　↑

この文章を整形して、フロントページの前提に書いた方がいいんじゃね？
このプロトコルのコンセプトがはっきりして、初めて来た人にも分りやすい

http://sourceforge.jp/projects/openmj/wiki/FrontPage

実装無ければ無意味。　まずは実装(サンプル)をうpしてほすい

>>777
FrontPageに>>776さんの「アクションや情報が〜」の言葉も頂いて
追加しておきました。

>>776
現状の仕様では、和了ったときには
say <プレイヤー> ron または tsumo
open <プレイヤー> <手牌>
agari <プレイヤー>
の順にクライアントに送られます。

流局のときには、
ryukyoku
の後に親から順に
open <プレイヤー> <手牌> もしくは
close <プレイヤー>
が送られてきます。

手牌の公開をすべてopenコマンドに統一したので、逆にわかりにくくなって
しまったかもしれません。
コマンドの定義とは別に、本来はこういうフローも定義しないといけないんですが、
まだまとめきれていません(^^;

>>778
まさにその通りで、実際に動作する実装があれば、もうちょっと
具体的な話もできるようになるんですが、現在鋭意制作中で
ございます(^^;

前にも書きましたが、ソースは随時SourceForgeのリポジトリに
commitしているので、興味のある方は参照して下さい。

でもできるだけ早く、ある程度のものをリリースしたいとは思っています。

ちょっと見たけど、牌は全てユニークなIDでやり取りしたいなあ、16進で2桁で済むでしょ？
あと、進行は全て実際と同じようにサイコロ2回振って山のどこから切り出すとか、
サイコロの出目も含めて記録したい。
山を提供するだけ、サイコロを提供するだけ、それらのやり取りを全て記録し、牌譜が出せるやつまで
別に持っていたいのだけど。（ここでDB使う）

第三者から見ると有る程度動く物が出来てからじゃないと無意味な議論を重ねてるようにしか見えないのだが？
どうせ鋭意制作中とか言っても完成まじかで「本業or学校or卒論等が忙しくなり・・・」で結局完成しない良くあるパターンに陥るのがみえみえ。

少しは完成させてからでも遅くは無いと思うんですが、どうなんでしょうかそんへん？

SourceForgeにあがったコード見ながら、サーバで試しに動かしながらレスしてるのだけど。

>>774
>クイタンありかなしかはサーバの実装次第で、クライアントの実装では、
>クイタンで和了ろうとして、サーバにコマンドを送って初めてわかります。

え、事前にサーバーにルールを問い合わせたりできないの？

ルールのすり合わせの方法とかは必要なら追加になるだろうね。
AI前提だと、先にルールがある気がしないでもないが。

ルールはその卓に固有のものなんだから
HELLOコマンドに乗せて最初に通達されるもんじゃないだろうか
実際の卓でも初めて打つ人とはレートとか先付けとか確認しておくよね

>>784-786
自分の考えは>>774に書いた通りで、ルールをサーバとクライントで
通信に乗せてやりとりする必要はないと思っています。
もしそれで問題だと思うのであれば、具体的な例を示して頂けると
助かります。

ただし、>>786の言うように、helloコマンドである程度の情報を渡すのは
アリかなと思っています。しかし、それに依存したクライアントを作るのは
推奨しません。

>>781
それぞれの牌にユニークなIDを振るのは、前にスレで提案頂いてから
検討してみましたが、結局止めました。
一番大きな理由は、牌の表記を現状の'1m'とかから変更するのに
良い案が浮かばなかったからです。
別に可読性は気にする必要はないのかもしれませんが、一応telnetでも
クライアントと成り得るのを目指していたので(^^;

サイの目に関しては、まったく意味がないので外していたんですが、
割れ目などを実装する際に必要になるのでUMPに追加しました。

それ以外のDBを使うという部分は、ちょっとイメージが良くわかなかったの
ですが、UMPというよりサーバの実装の話であれば、どうとでも対応できる
と思います。

コマンド一覧を眺めて、何点か気になる点があったので、
指摘事項を記載。

■「naku?」アクション後のリアクションについて
あるプレーヤーが捨牌後、残りのプレーヤーに対して
「naku?」コマンドが送信されるが、仮に3人とも「no」だった
場合に、現行の仕様では何もコマンドが返されない。

一応、3人とも「no」だった場合は、例えば

　say 0 noact

みたいなコマンドは発行した方が良いのでは？
すると、クライアント側では以下のような動きになるが
どうだろうか？

sutehai?→自家捨牌(sute)→リアクション無し(say no)→下家捨牌(sutehai)→naku?
→鳴かない(no)→リアクション無し(say no)→対面捨牌(sutehai)→naku?

>>789
具体的な指摘、嬉しいです！
その状況では、noactの代わりに、他家のtsumoコマンドが送られる想定です。
つまり、tsumoコマンドは自分がツモった場合でも、他家がツモった場合でも
全員に送られます。

ちなみに鳴きの処理はまだ全く手つかずなので、実装していくうちに変更に
なる可能性もあります。

■他家の長考時について
「naku?」コマンド発行したタイミングで、2人はリプライが
あったが、残る1人からのリプライが無かったときに、
リプライを返した2人はサーバからの応答が無いまま
ずっと待っていることになる。

サーバは長考しているプレーヤーに対して、再度「naku?」
コマンドを発行して催促すると同時に、残りのプレーヤーには、

wait <プレイヤー>

というコマンドを発行して、今1人長考に入っていますと、
知らせてみてはどうだろうか？

「コマンド一覧」を眺めていて、自分の中で仕様を考えてるうちに、
単純化されたシステムを構築したいなら、CGIで十分だなと思えてきた。

とりあえず、サーバー内でタイマーを持たせて、
「10秒以内に返信が無いと、強制ツモ切り」という粗い感じの
仕様なら、そんなに難しくないと思う。

サーバ側から「もしもし捨牌が遅いですよ」と返信が来る様な
優しい仕様としたいなら、サーバとクライアントの双方向で通信
できるようなsocketのサンプルが無いと開発は難しい気がする

>>790
了解です。

[鳴き無し]
tsumo <自分> <残り枚数> <牌> →sutehai?→自家捨牌(sute)→tsumo <下家> <残り枚数>→下家捨牌(sutehai)→naku?
→鳴かない(no)→tsumo <下家> <残り枚数>→対面捨牌(sutehai)→naku?

[鳴き有り]
tsumo <自分> <残り枚数> <牌>→sutehai?→自家捨牌(sute)→tsumo <下家> <残り枚数>→下家捨牌(sutehai)→naku?
→鳴かない(no)→say <上家> pon →上家捨牌(sutehai)→naku?

という流れを理解しました。

>>791
タイムアウトについては大変悩ましいところです。
とりあえず、クライアントから(サーバ時間で)一定時間、返答がなければ
サーバが勝手に進行してしまうというものを考えています。
また、現状の仕様だと誰の返答が遅いのかを、他のクライアントは知る
ことができませんが、これはこれで良いかなと考えています。

同じ牌が4枚あるのは気持ち悪いな、、なんとかならないかな。
まあ内部で持つだけでやってみるか。

まったく同じ山でAIだけ差し替えて対戦とかも可能な様にやってるけど、それでいいかな。
すべての対局の山とダイスを記録してるけど、短時間に膨大な量の対戦をやると意味がなくなるかなあ。

ネット対戦にするなら、トンプウ荘と繋ぐやつつれば十分では?
あとローカルで高速に動くやつ

http://www.interq.or.jp/snake/totugeki/MJexeIODLLman.htm

人間が混ざる環境だと迷惑では？
あと>>797の利用規約見たけど、AIで使うのは明らかに規約違反だな。

個人で強いAIを作ってもそれを公開しなければいい。　

>以上は、個人的な研究程度の範疇なら問題ありません

MJexeIO.DLLを簡単に利用するためのラッパーを作るだけならいいだろう。

公開しないAIをこのスレで議論する意味あんの？

Rと名前でわかる

カスだな

>>787
例に出てるけど、クイタンがあるかどうかは終盤の打ち筋に大きく影響するから、
アガッたときにはじめてわかる、なんて仕様はあり得ないと思う。
予めＡＩはクイタンが認められるかどうかを知っていないと。

それならクイタンありＡＩとクイタンなしＡＩの２つを分けて作れ、って考え方なんだろうけど
初めっから多態性を切り捨てたＡＩなんて面白くないよね。特にム板的には。

というわけで、「採用されている」ルールだけでも通達すべきだと思うんだ。
無数にある「採用されていない」ルールは無視してね。

>>788
牌のユニークＩＤがないと赤には対応できないな
'5m'を'5M'にするとかか

>>804
AIクライアントを起動するときに、オプションで指定すればそれで済むと
思っているんですが、サーバに問い合わせて自動で判別する必要が
あるんでしょうか？

>>805
赤牌は、おっしゃる通りの表記で既に仕様に入ってます。

俺が一人で作ってるのとは微妙に仕様が違ってきてるな
いろんな考え方があって面白い

>>806
いちいちオプション指定なんて面倒

>>806
うっかり１人だけ設定間違えた、ってこともあるはず。
こういうことはしっかり確認を取れるようにしないとトラブルの元。

>>809
自分はサーバとクライアントでルールをやりとりする方が
トラブルの元だと思っています。

例えば、クイタンありの場合は、サーバからhelloコマンドで
kuitan=1というオプションを渡すようにしましょう。
そしてクライアントはそれに対応しました。

ところが、他のサーバの実装ではkuitan=yesと送ってきました。
これは、サーバが悪いのでしょうか？それともクライアントが対応
すべきでしょうか？

このトラブルを回避するには、ルールを通達する場合の仕様を
決めなければなりません。
そうなると今度は麻雀のルールの多様さが問題になってきます。
ツモっても平和つくの？赤牌は何枚入ってるの？聴牌連荘？
裏ドラはあり？ダブロンは？etc...

「どうせUMPのサーバなんてお前しか作んねーよ。そんな先の
こと考えてんじゃねーよ」
という意見もあるでしょうし、おそらくそれはその通りです(^^;

が、だからこそ自分の正しいと思うように作りたいのです。

>>807
どこらへんが違うのか、すごく興味があります(^^

なんか東風荘の焼きなおしみたいな感じで独自にやる意味が薄くなっちゃったんだよね

東風荘のつなぐやつ作ってくれよ

>ルールを通達する場合の仕様を
>決めなければなりません。
実装とルールを切り離してるんだから、なにかしらルール定義ファイルがあるんじゃないのかな・・・
それ送っちゃえばいいのに。
マッチメイクサーバーとかが面倒見るのがいい気もするけど。

IDE/ATAのIdentifyコマンドみたいに512byteとか
1024byteのパラメータの固まりをやりとりできる
コマンドを準備しておけば良いんでね？

フォーマットの中身は追々、考えるとして。
麻雀のルールは1000パラメータ以上もは無いだろう？
有りそうなら後々、長さを拡張できるようにしておく。

で、サーバーは一方的にルールを通知するだけ。
対応する、しない（できる、できない）は
クライアントの責任とする。

ルールの摺り合わせをするのはさすがに大変そうなので。

あとで再現のために、誰がどのバージョンで参加したかのやり取りは必要だからね。

じゃ、このルールで参加する、あるいは対応できないから
参加しない、の返事だけはクライアントから返すようにするとか。

その後、参加しているかどうかログ見れば分かるから
あまり意味ないけど。

サーバに接続してからhelloでルール確認するって違和感あるんだけど
東風荘みたいに「○○ルールのサーバに接続しに行く」ってのはできんのかね

>>664
期待して待ってるんですが、その後どうですか？

赤牌のことを考えると、チーとかポンで晒す牌を明示的に
指定しないといけないのか…地味に面倒だな(^^;

別に赤牌が無くてもチーは明示的に指定する必要がある

>>821
いや、もちろん最初からチーのときは牌を指定させてたよw

経過をたどればプロトコル関係ないだろ。
クライアントだけで晒す牌は自明。

>>823
お前は相手の牌が読めるのかよｗｗ

>>824
sutehai
と
chi
pon
kan
の経過があれば可能

記述内容が荒くて答えになっていない

まず、それではあがった時や流局時にプレーヤーがどんな手牌
であるのか不明

つか、sutehaiとかchiとかのメッセージをサーバ間で
やりとりして、言語依存せずに麻雀のゲームを成立させることが、
このプロトコルが意図してるところだろ？

>>826
これを読んでから言ってるの？
http://sourceforge.jp/projects/openmj/wiki/FrontPage

ここまで読んできて非常に面白いと思った
麻雀は将棋やチェスと違ってプレイヤー間の意思疎通および時間経過の概念があるから
適当な考えで簡単に策定したら後で破綻しやすそうだね

個人的には錯和もチョンボも無いゲームは麻雀とは呼ばずに
麻雀モドキもしくはコンピュータ麻雀とか呼んで欲しいと思うけど

他人の作るものにケチつけるくらいなら自分で作ればいい

他人にケチ付けられて拗ねるぐらいなら公開掲示板などに書かなければいい

>>828
> 個人的には錯和もチョンボも無いゲームは麻雀とは呼ばずに
> 麻雀モドキもしくはコンピュータ麻雀とか呼んで欲しいと思うけど

そういう意味では、自分はリアル(人間同士)の麻雀を再現したいとは
カケラも考えていません。だいたい、表情や仕草も見えない時点で全然
別物なのは皆わかってるものだと思いますが。

むしろ、そういう情報をなくすことで、より麻雀の「ゲーム」としての要素が
際立ち、そしてそこにコンピュータを使って最強のAIを作るという新たな
試みが生まれているのではないでしょうか。

その上で、チョンボは「コンピュータ麻雀」として意味があるのか、という
議論であれば、それは面白いと思います。

チョンボが勝率に絡んでくることもあるだろ

ちなみに、現状自分が作っているシステムではツモ切りかどうかを
誤魔化すことができません。
これは、本来の麻雀では小手返しのうまい人なら可能なことが
不可能になっているという意味で、チョンボを認めるかどうかなんか
よりよほど大きな問題だと思いますが、これについて一切ツッコミは
ありません。

というか、小手返しを使ってツモ切りかどうかを誤魔化せる麻雀ゲームって
存在するんですかね？

意図的にチョンボしたい時用に、満貫払って降りる
チョンボコマンドでも定義しとけば？

>>831
表情が見えないからこそ、牌で語るんじゃないの？
とりあえずノーテンリーチを認めない理由がわからない

とりあえず動くクライアントを作らないか？

ちゃんと動くサーバが出てソースが公開されたら、
俺がチョンボとかノーテンリーチとか対応するから問題なす。

>>835
つかノーテンリーチ認めてるところが
あるかよ
おまえ自身が異端だって気付けよ

＞これについて一切ツッコミはありません。

自分が考えたことに対する異論は片っぱしから拒否しといてつっこみがないとかあるかよ。
もう付き合ってられんわ。

AI同士の勝負でバグを出すことがデメリットにならないなんて設計ミスだろ
ノーテンリーチやチョンボ判定せずにサーバの救済措置で勝つAIがあるとして
それは強いAIとは言わないし、そのプロトコルはAIの強さを保証できない

本質がわかってないね
きみには強いAIは無理だからどうでもいいや

>>839
チョンボとルールの伝達の件でしょうか？
それについては採用しない理由(デメリット)を説明しているつもりです。

ただルール伝達については、自分は必要がないと考えているんですが、
それを証明(？)するためにも、その仕組みでの実装を見せる必要が
あるかと思い、とりあえず議論よりも実装を頑張っている状態です。

その後、自分以外にもクライアントやAIを作ってくれる人が現れて、
やはりルール伝達があった方が問題が少なくなると思えば、仕様に
採り入れることもあります。

チョンボについては、極論すれば>>834の意見に行き着いてしまうと
思うのですが、やはりこれには抵抗を感じます。

>>840
AIでチョンボというのは、それはもはやバグであり、強い弱いという
レベルとはかけ離れていると思います。
逆に、チョンボをサーバに救済してもらうことで勝てるAIなら、それは
バグを直せば強いのだから、強いAIなんじゃないでしょうか？

チョンボで流れるルールだったら、チョンボで流して１位確定とかやれるんだよ・・・？
ルールによってはだけどね、流局連荘だけどチョンボだと流れるとか、どっかであったはず
普通ないけどね、一応こういうのもあるよっていう情報提供って意味でｗ

また、人間が操作するタイプのクライアントの場合、クライアントで
チョンボを発生させないようにする(サーバに送らない)ことも可能です。
これは、オープンなプロトコルで、クライアントを自由に実装できる以上、
防ぎようがありません。

その上で、チョンボが発生するクライアントと、チョンボを発生させない
ようにしたクライアントで対戦するというのは、どうなんでしょうか。

「コンピュータに手助けしてもらって打つなんて麻雀じゃない」という
意見もあるかもしれません。

でも、一昔前は他家の点数を覚えておくのは技術でしたが、今どきの
自動卓ならボタンを押せば表示されます。
またゲームであれば、ツモ切りかどうかを捨て牌にわかりやすく表示して
くれるものもあります。

自分としては、そういうことを総合して、リアルの麻雀とコンピュータの
麻雀は違うのだから、リアルの麻雀のすべての要素を入れる必要はなく、
そしてチョンボはコンピュータ麻雀には不要だと考えたわけです。

>>844
わかります。
ですから結局>>834を認めるかどうかなんですが、実際、自分は
今までに勝とうとしてわざとチョンボするヤツを見たことがありません。
暗黙の了解で、チョンボはわざとやらない、つまり戦術ではないと
いうものだと思ってたんですが、そんなこともないんでしょうか？

っと、ごめん、すでに書いてあったのね
まぁ明記してくれればどっちでも自分はかまわないかな？お好きなようにっ
そこは設定できるようにしてあるしっ

じゃあチョンボはサーバ側で勝手に弾いていいから
弾いたログだけは絶対に牌譜に残る仕様にしてくれよ

>>848
今作ってるサーバをそういう仕様にするのは全然構わないですが、
すべてのサーバの実装はそうすべき、とするほどの意味が感じられません。

どういう用途で必要なんでしょうか？

>>849
デバッグに有用な情報ではあるんじゃないかな。
チョンボするってのが、単にチョンボするだけの問題ってことはおそらくあまりなくて、
推論ロジック全体に影響する問題がある可能性が高いだろうし。
その一種の症候として検出するに値するものであると思うよ。
まあ、それだと全てのサーバがそうすべき、というほど強く必要なものでもないだろうけど。

>>850
それは自分も考えました。
でもそうだとすると、サーバのログよりも、クライアントから不正な
返答があった場合には、サーバからerrorとかを返した上で続行
した方がクライアントのデバッグはやりやすいんじゃないでしょうか。

>>846
>暗黙の了解で、チョンボはわざとやらない、つまり戦術ではないというものだと思ってたんですが

同意だ。
麻雀の戦術として、「この場合はチョンボしよう」というのも見たこと無いな。

チョンボは麻雀の中で、明らかに「例外」だ。
無しにできるのなら無しで良いものだと思う。

現在あるコンピュータ上の麻雀ゲームで、チョンボがあるものは多数あるため、なんとなく無いと変な気がするだけで、
無いからといって麻雀のゲーム性が損なわれることはまったく無いと考えられる。

リアルの麻雀では、山を手で崩してしまったら、なんらかの罰とかもあるわけだが、それは実装しなくて良いのだろうか。
その場合、ＡＩが手のカーソルを牌を倒さないように避けるアルゴリズムが必要だな。

>>851
それもそうか。

たまにフリーでそういうプログラム欲しくなるな


んで、出来た？

>>849
「完全にバグの無いプログラムの存在は証明し得ないから(悪魔の証明)」
言語が違うコンパイラが違うOSが違う加えて通信上の問題も多々ある
これ普通のマならみんな最大限警戒することだと思うけど

あなたが許したバグの責任はあなたが負うことを明示してねっ、てこと
チョンボを弾いたログは牌譜に残してね。お願いします

>>854
進捗はSourceForgeのソースを動かしてもらうのが一番わかりやすいんですが、
とりあえず残る大物作業としては鳴きの処理くらいで、あとはGUIをもうちょっと
ちゃんとするのとか、バグとか、そんな感じです。
現在でも鳴けないけどツモ切り3人相手に一人打ちくらいならできます。

>>855
クライアントのバグの検出ということであれば、>>851の方法ではいかがでしょう？
牌符は東風荘と互換にしようと思ってるので、独自情報は追加できないかも。
それはそれとして、サーバのログは残すつもりですが。

牌符を「東風荘と互換」にするなら錯和は必ず牌符に残ことになるはずでは
「それはそれとして、サーバのログは残す」ってどういうことなのでしょうか？
「独自情報の追加(削減？)」は不要なので普通に牌譜に記録して頂きたい

サーバのログって言ったら通信履歴のことじゃないの？
通信記録＝牌譜ではないでしょ。

通信記録は全て残す
牌譜はその記録から抜き出す

これで好きな形式で牌譜も取り出せる

AI対戦が根本にあるんだから、短時間で数百回勝手に対戦させといて
後で集計を確認したり、気になった局の牌譜を再現したりできるようにしたいじゃない？
せっかくサーバー使うんだし、DB使うってのはそういうことに使えるからなんだけどね。
人間に見やすいプロトコルのために機能を削るのはナンセンスだと思ってる。

だから、チョンボは無しでノーテンリーチだけ認めればいいじゃん。
チョンボはルールの破壊だがノーテンリーチは戦術だろう

ノーテンリーチで流局になったらチョンボだべや

ノーテンリーチが戦術とか漫画の読みすぎじゃねーのｗ

馬鹿がいると話が進まないな
チョンボ厨は完全スルーでいいだろ


今更こんな質問をするのもなんだけど、ＡＩ同士の優劣を判定するには多数の対局をこなさないといけない麻雀というゲームの性質上、
対局のたびにネットワークを介する方法は効率が悪いのでは？

ネットワーク用のプロトコルを作っておけば、
別にlocalhostでも使えるでしょ。

>>857
牌譜を東風荘と互換にすることと、東風荘と同じ仕様(ルール)にするのは
イコールではないです。
ログについては>>858の言うように、いわゆる普通のログです。
通信だけには限りませんが。

クライアントのデバッグが目的であれば>>851の方法を提案しています。
これについてはどうでしょうか？
そういう目的のためではない、というのであれば、どうしろ、という形ではなく、
目的を教えて下さい。でないと対応できません。

>>859
それも考えましたが、とりあえず東風荘形式で牌譜を出した方が
何かと便利な気がします。

で、東風荘の牌譜について調べてたんですが、どこかに仕様って
上がってます？
ざっと見た感じだと、鳴いたときに晒すメンツの情報が足りないような
気がするんですが…

http://mj.giganet.net/mjscore.htm

>>860
> 人間に見やすいプロトコルのために機能を削るのはナンセンスだと思ってる

どの部分を指摘しているかわかりません。牌を個別IDにしなかったことでしょうか？
もしそうなら、それは機能を削ったという認識はないんですが、何かこれで失った
ものがあるんでしょうか？

>>867
うわ、思いっきり本家にw
ググっても引っかからなかったのに。ありがとうございます(^^

>>861-863
自分もノーテンリーチだけはアリかなと思ってます(^^;
理由は、
* 流局までチョンボにならない
* 途中で上がることで防げる
という部分で、他家同士の損得に影響が少なく、またゲーム性としても
いわゆる「ブラフ」としての価値はあるかと。
もちろん、罰符は親子で同じ点数、局は流れないという条件は付きますが。

>>863
>>864の言うように、ローカルでサーバも動かせば、それほどロスはないと
考えています。
ただ効率とか速度はそれほど重視していないので、それこそ何万局も打たせて
集計をとりたいという目的には向いてないかもしれません。

ちなみに、自分はAI同士ももちろんですが、AI対人間も考えてこの仕組みを
作っています。
だって、強いAIなら自分で相手したいじゃないですか？(^^

人間が打てるなら３Dにしてください＞＜

>>872
大丈夫か？

AIと人間が対戦するのにサーバ介してロビー用意してチャットシステム組んでやんの？
いつまでたってもできそうもないな。

>>874
別にロビーもチャットも用意するつもりはありませんが？
そんなんなくても麻雀はできるでしょ。

そもそも文字だけでやる気にはならないな
GUI作ってしまえばプロトコルなんてバイナリーでもかまわないわけで

>>872
クライアントのクオリティは…優先順位は低いですが、頑張ります(^^;

どうでもいいけど、自分と違う人の意見は絶対に聞かない態度はどうにかならないのか

>>876
GUIクライアントも一応作ってます(^^;
さすがに人間が打つのにtelnet使えとかは言えないです。

>>878
お前がか？
自己紹介
乙

>>878
意見を聞くということが、言われたことをホイホイやるというのであれば
そんなつもりはカケラもありません。

リクエストについてはそれなりに理由をつけて反論しているつもりです。
ただ好き嫌いに関しては、当然ですが自分の好きを選びます。

>>891
×リクエストについては〜
○採用しないリクエストについては〜

今まで出た議論は理由を読めば俺も632の判断の方が総じて妥当だと思うけどね

>>871
>ちなみに、自分はAI同士ももちろんですが、AI対人間も考えてこの仕組みを
>作っています。

逆指向なんだと思ってたので驚いた

言っていることがころころかわる

亀レスかもしれませんがチョンボについて少々言わせてくださいｗ

私が以前参加した大会でのことなのですが、初心者が多かったためか
「チョンボは取らず、手牌を立て直してそのままゲーム続行」というルールがあり、
実際に何人かが救われていました。

自動卓のボタン押しちゃったから続行不可能だとか、相手の手牌を故意に倒しやがったとか、そういうのは起こらなかったため対処が不明ですが、
これらがコンピュータ麻雀で起こることはないと思うので、局を中断して点棒をやりとりするのはナンセンスと思います。
「正しくない和了を以下の手牌で宣言した」という情報だけなら、(どうしても必要という根強い意見があるのならば、) 流してもいいかなとは思いますが。

ノーテンリーチは正常な流局の不聴として扱い、リーチ棒は一旦供託したので供託のままだったと思います。たしか101とかでしたっけ? 門前なら聴牌/不聴を問わずリーチできる団体もあったような気がします。(あそこは不聴罰符もなかったかな?)
つまり、ノーテンリーチかけられる場合、流局時の罰符には反対票入れます。

不聴罰符なし→毎局ダブリーする荒らしAI出現
→全ツッパAIが常勝→クライアント参加者消滅
→プロトコル死亡

>>883
ありがとうございます(^^

>>884
人間同士の対局が主で、AIはついで、みたいな？
正直、そういう部分はあると思います(^^;
というか、人間かAIかというより、ネットワーク麻雀というものをもっとオープンに
したいというのが最大の目的です。
イメージ的には、好きなブラウザで、好きなサイトを見に行くような感覚で、
色々ある麻雀サーバに、好きなクライアントやAIで繋ぐ感じです。

>>885
自分のことでしょうか？
どの部分についてそう思われたのですか？
むしろ、どっちかと言えば>>878で言われるように、頑固で自分の意見を
曲げない方なんじゃないかと思いますがw

>>886
結局、ノーテンリーチも、チョンボで罰符を払って局を終わらせるのも麻雀の戦術と
みなすかどうかなんですよね。
101では有効だと判断すれば普通に使うんでしょうか？

ノー爆では爆岡と稲瀬さんが茶柱を追い詰めるためにノーテンリーチを使ってたし、
最近ではリスキーエッジでも吉岡が使ってて面白かったので、ノーテンリーチは
戦術とみなしても良いかなぁと思ってしまいます(^^;

ただ、やっぱり普通はそういう行為をワザとやるのは嫌がる人が多い気もします。

>>887
わざわざ荒らし用のクライアントを書いてくれる人が現れるなら、
それはそれでちょっと嬉しいくらいです(^^

最初にも書いたけど、オープンなプロトコルを作りたいってのは
10年くらい前に考えて、でもそんときは2chとかなかったし、一人で
細々とやってて結局止めちゃったので、今はここで色々意見を
言ってくれる人がいて、それだけでも嬉しいです。
# 完全に構ってちゃんな発言だなw

そもそも今回麻雀のプロトコルは、サーバとクライアント間で
各メンツがどんなアクションや情報を出したかを
互いに伝達しあうことが目的ではないか？

メンツが出したアクション（毎回チョンボリーチをした、
役満でチョンボ流しをした等）がルール違反であるかは
「サーバ側で判断」すればよい。

サーバにメンツのアクションが正しく伝達されれば、
麻雀プロトコルの目的は達成できていると思うが？

ただ、東風荘とかのルールなら、ノーテンでのツモ宣告
は無視でｲｲのではないのか？

>>892
まさにその通りで、現状のプロトコル(UMP)でも、誤ツモのチョンボで
局を流すとかは、
say A tsumo
point A -8000
kyokuend
で再現可能です。
ただ、この場合他のクライアントは「チョンボが発生した」と
いうことを知ることができません。UMPにそれに該当する
コマンドがないからです。

言ってしまえば、とりあえずUMPの仕様にchomboコマンドを
追加してしまえばそれで済むんですが、できれば入れたくないと
いう自分のワガママが問題を大きくしてしまっている気もします(^^;

色々文句言ったこともあるけど
まずは単純でオーソドックスなものを作ってしまうべきなように思う

仕様に問題が出ればそれから対処すれば良いし
ルールもいきなり複雑なのはＡＩがついていけない

お前らがあんまりにもグダグダだから遂にあらさんが立ち上がったぞ
俺はこっちに期待させてもらう

あらさんはこのプロトコルに興味を持たれている件

C++アプリからこのプロトコルって使える？

>>898
ネットワーク対応であれば
使用言語によらない

ひまわり でも なでしこ でも使える

ありがとn
完成したら使わせてもらうかも

保守

営業「ネットワーク対応であれば使用言語によりません。ひまわりでもなでしこでも使えます」
営業「残業代は出すし。家に帰らなくていいから。今月中にできるよね。信頼してるし。お願いしたよ」

ttp://ayamariplus.seesaa.net/article/103324673.html#comment

これワロタ　麻雀ソフトのイカサマについての論争

結局突き詰めると、ツモを操作するよりもヤマをそれっぽく作った方が
ちゃんとしたイカサマになる。
最も簡単といわれる積み込みも、実際の積み方を知らないで仕組むと
イカサマというよりもただ都合がいいだけのゲームになるしね。

河から牌を拾ったり、エレベーターしかけたりというのも
牌の配置（抜きやすいところにあるか、ツモ番ずれてないか、など）で
リアリティが増す

毎回ﾃﾝﾎｰ

コレ最強

まずは親にならなくちゃな

おやややおやにおあやまり