おまいら最強の麻雀プ ..
[2ch|▼Menu]
566:デフォルトの名無しさん
08/08/29 00:35:55
>>565
玉ねぎが主役か?

567:デフォルトの名無しさん
08/08/29 01:41:51
最強の脱衣って、あれだろ

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

相手が天和

そしてゲームオーバー

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

568:デフォルトの名無しさん
08/08/29 06:28:02
>>565 裸身活殺拳でおk?

569:デフォルトの名無しさん
08/08/30 11:50:17
URLリンク(doranizm.hp.infoseek.co.jp)
これってRでいうとどの程度のものなの?

570:デフォルトの名無しさん
08/08/31 01:29:01
時はこの数年ソースが一度も上げられたことが無い謙について

571:デフォルトの名無しさん
08/08/31 01:51:20
制作物はともかくソースはいらんだろ

572:デフォルトの名無しさん
08/08/31 01:55:23
まず、その製作物はDLLレベルですら上がってきていない

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

573:デフォルトの名無しさん
08/08/31 02:01:59
ニーズがあるのはゴミグラマの間でだけ。

574:デフォルトの名無しさん
08/08/31 02:07:20
ゴミグラマでない>>573は何か製作物を上げてくだされwww

575:デフォルトの名無しさん
08/08/31 13:15:12
他人に要求する前にまず自ら差し出しましょう

576:デフォルトの名無しさん
08/08/31 13:20:48
お!?
気前のいい>>575ですね
期待してるので早急に上げろよ。

期限は今日中

577:デフォルトの名無しさん
08/08/31 13:29:06
↑ゴミは黙っとけ

578:デフォルトの名無しさん
08/08/31 13:29:16
以下スルーで

579:デフォルトの名無しさん
08/09/03 00:34:13
結局のところ、対戦システムから自分で作るしかなさそうですね…

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

580:デフォルトの名無しさん
08/09/03 00:43:10
俺は興味あるよ

581:デフォルトの名無しさん
08/09/03 01:38:42
います
需要あり

582:デフォルトの名無しさん
08/09/04 00:31:42
>>579


583:デフォルトの名無しさん
08/09/04 00:39:02
>>579
参加はしてみたいが、特技「三日坊主」が発動するので
ほぼ乱数打ちで参加するでしょう

584:デフォルトの名無しさん
08/09/04 00:40:03
今のところ俺も入れて5人以上は居るみたいだな


585:デフォルトの名無しさん
08/09/05 00:44:37
でも5人しかいねえみたいだなwww

586:デフォルトの名無しさん
08/09/05 00:45:18
しかし麻雀はできるだろ

587:デフォルトの名無しさん
08/09/05 00:54:40
5人かよ〜ラス抜け?

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

589:デフォルトの名無しさん
08/09/05 01:07:24
>>579
で、作るの?作らないの?

590:デフォルトの名無しさん
08/09/05 01:10:28
なんでもいいからはやくあげてくれ

591:デフォルトの名無しさん
08/09/05 08:36:21
チートイツアルゴリズム作ってみるわ

592:デフォルトの名無しさん
08/09/05 22:03:16
チートイの立直、和了判定アルゴリズムなら30秒で書けるだろ
チートイを狙うアルゴリズムなら戦局に与える影響なんて皆無だから
もっと他に書く必要のある処理を考えた方がいい

593:デフォルトの名無しさん
08/09/05 22:42:44
>>592
30秒は無理w

594:デフォルトの名無しさん
08/09/05 22:46:40
頭の中でなら書けそうだがタイプ的な問題で無理だ

595:デフォルトの名無しさん
08/09/05 23:11:54
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!!

596:デフォルトの名無しさん
08/09/05 23:52:58
三十秒かどうかはさておいても、大概の役判定は結構短時間で組めるよね
んで、全ての役の中で一番面倒臭いのが平和という罠

597:デフォルトの名無しさん
08/09/07 00:33:24
符を数えて、20符という判定

598:デフォルトの名無しさん
08/09/07 00:38:17
フリテン回避とか難しそうだ

599:デフォルトの名無しさん
08/09/07 04:46:43
符計算も鳴き多発時の同順振り聴回避も0.5人日くらいでしょ。日曜だしできるさ

600:デフォルトの名無しさん
08/09/07 11:14:54
しかし符計算自体を理解するのにまず半日かかるw

601:デフォルトの名無しさん
08/09/07 14:05:38
上がった時に何通りかの面子と頭を取れる場合どの組み合わせで取れば一番点が高くなるか
これを速度を考慮しつつ綺麗に実装するのが難しい
符を高く取るが平和があれば優先するみたいなのとか

602:デフォルトの名無しさん
08/09/07 19:52:45
そうか?あがった後なら頭取って4回再帰で終わりじゃん
和了判定+α程度の計算量だから大したこと無い

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

603:デフォルトの名無しさん
08/09/09 00:27:55
>>537
>一番得になる役の組み合わせを探す辺りか

 11122233388899

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

 111 222 333 888 99
 123 123 123 888 99

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

604:デフォルトの名無しさん
08/09/09 00:33:07
リーチ
ツモ
トイトイ
www

605:デフォルトの名無しさん
08/09/11 09:56:15
Javaで作ってみようかな対戦用システム

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

606:デフォルトの名無しさん
08/09/12 02:22:20
URLリンク(www.amy.hi-ho.ne.jp)
URLリンク(www.amy.hi-ho.ne.jp)
URLリンク(www.amy.hi-ho.ne.jp)

607:デフォルトの名無しさん
08/09/12 06:46:28
いや、そういう意味で無くて
どうやって外部にあるクラスを認識させるかがよくわからないというわけで。
フォルダの位置とか。

608:デフォルトの名無しさん
08/09/12 07:31:24
Javaはだめだ。 やるならC++にしないと人気でない

609:デフォルトの名無しさん
08/09/12 08:12:30
…そ、そうなのか?
カズタマイズとかも楽かと思ったんだが…
C++はDLLの作り方全然わからん

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

610:デフォルトの名無しさん
08/09/12 08:41:03
GUI面倒くさいけど、諦めてC++でやるわ。
DLLは頑張って勉強する。

611:デフォルトの名無しさん
08/09/12 08:45:53
GUIは別の人がやって良いから、点数計算がちゃんと出来て対戦結果を出力できれば
良いと思います

612:デフォルトの名無しさん
08/09/12 09:57:56
ルールを決めてから作った方が良いよな。 変更があれば随時変えていって。
ドラをどうするとか。

613:0.0.0.0
08/09/12 10:41:34
じゃあ自分GUI作るね。

614:デフォルトの名無しさん
08/09/12 12:50:37
GUI作ってくれるんならいいけどなぁ
今、wxWidgetいじってたら
wxWidgetのLibとdll作る過程でもう躓いてる…
SDlなら余裕なんだが。AI用に色々リアルタイム出力しないといけないと思うし…

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

ルールはとりあえず、
237にある
URLリンク(mj.giganet.net)
でいいんでないかと思う。

615:デフォルトの名無しさん
08/09/12 13:19:45
こっちがいい。
日本プロ麻雀連盟競技ルール|日本プロ麻雀連盟
URLリンク(www.ma-jan.or.jp)

616:デフォルトの名無しさん
08/09/12 15:31:56
>>614
wxWidgetは入らないですからunixでもmacでもwindowsでもコンパイルできる
コマンドラインの判定ルーチンをお願いします。
DLLやGUIはわかる人がやります


617:デフォルトの名無しさん
08/09/12 15:38:33
東風荘ギャンブル性が高く実力を測るのに向いてないと思います。
プロルールお願いします。

618:デフォルトの名無しさん
08/09/12 15:47:48
wxWidgetもう諦めるわ
これだけの時間やっていまだにどうしようもない
コマンドラインも全然わからんから(たぶん文字列だよな)
とりあえずSDLで組むわ。
でも、もう今日は力尽きた…

619:デフォルトの名無しさん
08/09/12 15:52:02
>>618
コマンドライン = 標準C/C++ という意味です。 
役と得点計算が標準C/C++で書いてあれば発展すると思います。

620:デフォルトの名無しさん
08/09/12 23:04:15
誰かまったり麻雀の中の人にこのこと教えてあげて
URLリンク(diary.jp.aol.com)
>当社の麻雀は、プログラム上、配牌の操作を行っておりますが、
>より楽しい演出とご理解頂ければ幸いです。
>今後とも天鳳を宜しくお願い致します。


621:デフォルトの名無しさん
08/09/13 06:50:50
誰も聞いてないのにいきなり配牌操作がどうとか言い出すキ○ガイ開発者はいないだろ

622:デフォルトの名無しさん
08/09/14 19:32:24
URLリンク(mahjong.ara3.net)

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

623:デフォルトの名無しさん
08/09/14 22:04:25
>>622
一人麻雀練習機で延々遊んでしまったぜw
判定部分は十分じゃね?

624:デフォルトの名無しさん
08/09/14 22:33:44
>>622
一日で進みすぎワラタ
GJ

625:デフォルトの名無しさん
08/09/15 01:38:23
作ってたのあらさんだったのか。これは期待できる

626:デフォルトの名無しさん
08/09/15 09:25:27
お、あらさん久しぶりだねえ

627:デフォルトの名無しさん
08/09/15 23:24:05
>>626
あ、久しぶり。ってどこかでお会いしました?

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

628:デフォルトの名無しさん
08/09/15 23:30:45
まずは、このルールで点数が一致するものを作る

日本プロ麻雀連盟競技ルール|日本プロ麻雀連盟
URLリンク(www.ma-jan.or.jp)

629:デフォルトの名無しさん
08/09/16 01:08:20
>>628
がんばってね

630:デフォルトの名無しさん
08/09/20 14:06:47
GUIはフラッシュにしてください><

631:デフォルトの名無しさん
08/09/20 15:12:22
      ハ,,ハ
     ( ゚ω゚ )  お断りします
    /    \
  ((⊂  )   ノ\つ))
     (_⌒ヽ
      ヽ ヘ }
 ε≡Ξ ノノ `J


632:デフォルトの名無しさん
08/09/20 16:17:44
まず、サーバとクライアントのプロトコルの仕様を決めて、
それから好きな言語で実装するのが良いと思う。

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

633:デフォルトの名無しさん
08/09/21 00:18:27
なんでメール用のプロトコル使うんだ?
もっと使えそうなのがあるだろ

634:632
08/09/21 01:35:17
>>633
そういう意味じゃなくて、SMTPやPOP3のようなASCIIベースの
プロトコルが良いってこと。

635:デフォルトの名無しさん
08/09/21 03:23:53
だったら参考にするのはコーヒーポットプロトコルだな。

636:デフォルトの名無しさん
08/09/21 05:49:01
>>633
理解力なさ過ぎて吹いたw

637:デフォルトの名無しさん
08/09/22 00:12:42
Javaで作りたいので共通プロトコルを作ってください><

638:デフォルトの名無しさん
08/09/22 00:39:28
XMLでいいよ

639:デフォルトの名無しさん
08/09/22 01:07:10
こーいうの作ってください><

USI(Universal Shogi Interface)プロトコルとは、将棋GUIソフトと思考エンジンが通信するために、
Tord Romstad氏によって考案された通信プロトコルです。USIの原案は、以下で読むことができます。

URLリンク(www.geocities.jp)

640:デフォルトの名無しさん
08/09/22 09:20:38
すげー久しぶりに来たけど、まだやってたんだな。
言語に依存しないようにプロトコルの策定からやるの?
inetd形式で棋譜つき雀卓サーバでも提供しようかと思ったけど
4人で1卓じゃそのままじゃむりか。人間も参加できるようにするなら観戦もいる?

641:デフォルトの名無しさん
08/09/23 00:48:19
単純なのでいいからなんか作ってくれ
スレは長いが口だけ野郎が多いから

642:デフォルトの名無しさん
08/09/23 00:53:19
こんなんでいいんで作ってください?><

URLリンク(bon4714.0web.cjb.net)

643:デフォルトの名無しさん
08/09/23 01:22:37
ソース公開したらいかさまし放題じゃん

644:632
08/09/23 01:36:31
>>643
サーバとクライアントを別プロセスで動かせば問題ないでしょ。
最初はセキュリティホール的なものもできちゃうかもしれないけど。

645:デフォルトの名無しさん
08/09/23 01:51:12
俺用メモ
>570 == >572 == >574 == >576 == >630 ==>637 == >639 == >641-642

646:デフォルトの名無しさん
08/09/23 12:48:51
ストーカー行為はやめてください><

647:デフォルトの名無しさん
08/09/23 15:18:11
何も決まってないなら、とりあえず思いつくままコマンドあたりから書き出してけば?

コマンド
【名前】自模牌要求
【コマンド名】PaiReq
【方向】cl - > sv
【コマンド概要】プレイヤーからサーバへの自模牌要求

みたいなな感じであげていって、あとはそれぞれシーケンス描いてみてダメな部分・足りない部分を要らない部分の
追加修正削除をわいわいやってみたらなんとかでっちあげられるんじゃね

648:デフォルトの名無しさん
08/09/23 17:51:15
MJSimのC#版みたいなの作ってるんだけど、こんなのどう?

仕様
・AI同士のみでひたすら対戦。
・東風荘のログを出す。
・AIは、.NETのDLLとして製作する。

ルール
・東風荘ルールがベースで、一部変更。
・カンなし。アンカン、ミンカン両方できない。
・チートイツなし。
・役満なし。
・親のノーテンで流れる。


649:デフォルトの名無しさん
08/09/23 18:36:35
ルールは後でも良いから
プロトコルの策定をしてほしい
そうすればクライアントに取り掛かれるから

サーバサイドとしては

1.開始時にクライアントからの接続待ち
2.卓の配置、親の決定
3.河および山の情報が変わるたびにクライアントに通知
4.4つ(固定よりも可変のほうがいいかも?)のクライアントからの返信を待つ
くらいかな?補足ヨロ

他に
風牌とかドラ(表示?)牌のリクエストは不定期で受け付ける?
他家の点数リクエストは不定期で受け付ける?
河の情報はすべて再送信する?差分だけにする?
待ち時間は最大何秒(何ステップ?)にする?
途中でクライアントが放棄または接続が切れた場合はどうする?
一局終了ごとに譜(なんて呼ぶんだ?)を送信する?
ノーテンリーチは可能?
リーチ後の見逃しは可能?(高目をツモるため)
フリテンリーチは可能?

650:632
08/09/23 19:12:37
昔一人でプロトコル策定してw、サーバプロセスとか作ってたんだけど、
意外に興味ある人もいるのかな?

SourceForgeにプロジェクトでも立てようかと思ったけど、SFって
Wikiは使える?

651:デフォルトの名無しさん
08/09/23 19:15:11
このスレで反応をみてからにしろ
SFは早まるな

652:デフォルトの名無しさん
08/09/23 19:19:47
オープンリーチの有無は決めておかないと
クライアントの作り直しになる可能性があるな

653:デフォルトの名無しさん
08/09/23 19:22:50
>>649
もうちょっとほぐしてみた。

こんな感じで叩き台になりますかね。

・マッチメイク
 別途

・対戦サーバ
 すでにマッチメイクが済んでいることとする。
 各クライアントは対戦に必要なキーを含む情報をサーバに送る事で参加する。

1、開始時にクライアントからの接続待ち
2、席順、親の決定
3、配牌、自摸/打牌、チー、ポン、カン、和了などのアクションを必要なクライアントに通知
5、クライアントからのACKを待って次に進む
4、ACKにはチー、ポン、カン、ロン、チャンカン、チョンボアピール※などを乗せる
6、和了まで繰り返す
7、和了時、点数の計算、終局判定
8、配牌に戻る

※他のクライアントのアクションについてチョンボであるとサーバーに告げるコマンド

・不定期なりクエストに応じてサーバーからクライアントに通知される情報
 クライアント情報、風牌、ドラ表示牌、他家の点数、河の情報

・ルールで決定、または選択ルールとしてマッチメイク時に対戦希望クライアントに通知
選択ルール、ローカルルール
待ち時間、クライアントが放棄または接続が切れた場合の処理(チョンボ扱い、ツモきりモード、ランダムきりモード)
ノーテンリーリなど、クライアントが指摘できないものについて、サーバーでは判定しない(流局時に露呈するものは除く)。


654:632
08/09/23 19:32:32
>>651
スマン、早まってプロジェクト申請しちまったw

>>652
個人的にはオープンリーチは無しが良いかと。

>>653
チョンボは面倒が多いので、不可にしてしまう方が良いと思います。
ノーテンリーチに関しては、クライアントからリーチのコマンドがきても
サーバが認めない等。
確かにノーテンリーチは戦術として使えなくもないので、禁止するのは
微妙かもしれませんが、チョンボってのは色々問題を孕んでいるので
起きないに越したことはないかと。

655:デフォルトの名無しさん
08/09/23 21:01:01
最強を目指すんならプロトコルだとか何だとか言う前にどのルールを採用するかが重要だろ、
競技麻雀路線で行くにしてもプロ団体でも採用するルールが異なってるし、雀荘路線で行くなら赤の使い方が当然絡んできるし。

どうでもいい三文プログラム書くより、本気ならまず統計的分析から開始するのが本筋だと思うけど?

656:デフォルトの名無しさん
08/09/23 21:06:38
>>655
まずは麻雀を打てることが大事だ

657:デフォルトの名無しさん
08/09/23 21:16:08
>>655
現段階では板違い
URLリンク(money6.2ch.net)
ここで思う存分統計的分析してきてくれ

658:632
08/09/23 21:28:09
>>655
統計を取るためにも、三文プログラムが必要だと思うけど?

659:デフォルトの名無しさん
08/09/23 21:35:35
>>649
wikipedia より
牌譜(ぱいふ、はいふ)とは、麻雀の自摸や打牌などの動作(摸打)、点数の得失などを記録したもの。野球のスコア、囲碁・将棋の棋譜などに相当する。
Wikipedia項目リンク

660:デフォルトの名無しさん
08/09/23 22:14:50
>>657
自分で勝手な妄想で判断するなよ、統計的な裏付けの有る読み、打ちをするプログラムが最強に最も近いのは当たり前だろ?
逆に言えば、理論的な根拠の無い打ち方をするプログラムになにか意味が有るのか?

661:デフォルトの名無しさん
08/09/23 22:25:24
動かないよりは意味がある

662:デフォルトの名無しさん
08/09/23 22:32:17
下を見てもしょうがない
上を見るんだ

663:デフォルトの名無しさん
08/09/23 23:28:26
下がなければ、上には行けないんだが

664:648
08/09/24 01:05:01
反応なしで寂しすぎるが、とりあえずうpする。
URLリンク(migumi94.nobody.jp)

まだ作ってないところも多く、バグバグだがこんなもんということで。


665:デフォルトの名無しさん
08/09/24 01:20:20
まずは点数計算が正しくできるところから確認して作るべき

666:デフォルトの名無しさん
08/09/24 09:48:06
ルールはこれで

URLリンク(act0.net)

667:デフォルトの名無しさん
08/09/24 09:51:03
点数計算はサーバのサービスでいいと思うけどな。
ルールによっても変わってくるし。
でもいちいち可能性のある手の点数をサーバに問い合わせるのは無駄か?

668:デフォルトの名無しさん
08/09/24 10:10:52
そのサーバーの点数計算が間違えていたら、ルールが通じないことになる。
慎重に作るべきところで最も重要なところといえる。

669:デフォルトの名無しさん
08/09/24 10:25:34
>>665>>668

じゃぁそこのロジックはオマエらに任せた。
手牌を渡すから、得点と役を返すファンクションでもクラスでもいいから作ってくれ

頼んだぞ

670:デフォルトの名無しさん
08/09/24 10:31:20
渡すのって単に手牌を渡すだけじゃないよね。
風と局、ツモやロンの区別とその牌、晒してるかとか海底とかリーチとかどういう風に渡せばいいものか・・

671:デフォルトの名無しさん
08/09/24 11:13:16
手牌(上がり牌)
鳴き
ツモorロンorチャンカンorリンシャン
局・風
リーチorWリーチ・一発
天・地・人和
海底or河底
(八連荘)

こんだけあれば役得点計算できるかね

672:デフォルトの名無しさん
08/09/24 12:20:22
何か知らんがインターフェースを決めるだけでも
大変そうだな。

>667
まず、ゲーム開始前に手と得点の一覧表を
サーバーに問い合わせると言うのはどうかね?

673:デフォルトの名無しさん
08/09/24 18:40:02
ていうかまずやることリストアップしたほうがいいんでね
目次うp

674:デフォルトの名無しさん
08/09/24 19:54:34
>>666のルールで作ってみるか

675:632
08/09/24 21:15:15
とりあえずSourceForgeでプロジェクトが立てられたので、
Wikiにざっとコマンド案とかを書いてみた
URLリンク(sourceforge.jp)

実装は今から頑張ります(^^;
とりあえずRubyで麻雀ライブラリを書いてから、サーバプロセスを作る予定

676:デフォルトの名無しさん
08/09/24 22:07:27
>>675
字牌の表記が東風荘と違うんだけど、天鳳か何かだとそうなの?

677:632
08/09/24 22:23:21
>>676
いや、別に他のに合わせる必要もないかと思って気にもしなかった。
ということで、中途半端に似てるくらいなら、東風荘に合わせようかと
思って調べてみたけど、東風荘は字牌は漢字表記?
だとしたら、それはイヤだな。

678:デフォルトの名無しさん
08/09/24 22:33:01
>>675
自分の下家がチーで鳴いたのか
ツモなのか判別できない気がするのですが…

679:デフォルトの名無しさん
08/09/24 22:47:42
>>677
動作確認で牌譜再生ツールを使うと思うんだけど、nz表記用のを一から作るのも手間だし
現段階で安定したものがあるんだから、それで再生できるよう合わせた方がいいのでは?
・・・まあnz⇔漢字の変換ツールを作ればいいだけの話か。字牌の表記はお任せします

680:デフォルトの名無しさん
08/09/24 22:52:28
漢字は極力避けて欲しい
いわゆるASCIIコードの範囲内の方がいい

681:632
08/09/24 22:59:57
>>678
どういうケースでしょうか?
Wikiにも書いた通り、サーバから送られてくるのが
「実際に起きたこと」なので、サーバから下家がツモった
(tsumoコマンドがきた)ならツモ、chiコマンドがきたなら
チーとなる想定なんですが。

>>679
牌符は別にプロトコルに合わせる必要はないので、
東風荘フォーマットとかで出力するのは問題ないです。

>>680も言っている通り、ネットワークを通すプロトコルでは
漢字は問題を起こしやすいので、できれば避けたいです。

682:678
08/09/24 23:02:07
>>681
ごめん、勘違いしてた

683:デフォルトの名無しさん
08/09/24 23:02:13
kyokustartの説明が「一局が〜」になってますけど「n局n本場が〜」ですよね?
それとryukyokuでクライアントにtenpaiかnotenかを返させてますけど、
不正申告がないようサーバ側でチェックするなら不必要な気がします

684:632
08/09/24 23:09:04
>>682
いえいえ、色々抜けはあると思うので指摘して頂けるのは
嬉しいです(^^

>>683
「局」という言葉が正しくは何を指すのかが良くわからないのですが、
いわゆるサイコロ振って配牌取って、誰かが上がるまでを1局と呼んでます。
なので、言葉が混在してわかりにくくなってますがkyokustartについては
683さんの理解している通りです。

流局時にテンパイ/ノーテン宣言をクライアントに返させているのは、
テンパイしててもノーテンと宣言したい場合があるからです。
上がり止めなしのオーラストップ目とか。
当然、ノーテンなのにテンパイと宣言してもサーバ側では認めません。

685:632
08/09/24 23:12:45
ドラはそのものじゃなくて、表示牌を送らないと、
赤牌が表示牌の場合に対応できなかった。

686:デフォルトの名無しさん
08/09/24 23:23:08
リンシャンの通知は?

687:デフォルトの名無しさん
08/09/24 23:24:15
だから、多牌と少牌の処理についてちゃんと最初に決めておかないとダメだってば

688:デフォルトの名無しさん
08/09/24 23:26:54
>>687
職場にこんなこと言いだす奴がいたら絶対殴ってるわw

689:デフォルトの名無しさん
08/09/24 23:27:14
>>687
それは無しって事になってるのでは?

690:632
08/09/24 23:39:00
>>686
リンシャンというか、和了役の通知でしょうか?
今のところ入ってません。さすがにマズいかな?
とりあえずkyokuendで点数の増減だけで済ませようかなと
甘く考えていたんですが、ちょっともう一度考えてみます。

>>687
手牌はサーバ側で管理するので多牌、少牌は不可能です。

691:デフォルトの名無しさん
08/09/24 23:48:13
カンしたときのリンシャン牌の通知はツモコマンド?


692:632
08/09/24 23:51:13
>>691
そのつもりです。
リンシャンツモを特別扱いする必要ってあるでしょうか?

693:デフォルトの名無しさん
08/09/24 23:58:43
クライアントでも計算できるけどサーバに通知してもらえた方が
楽になることってどういう扱い?ツモったときの山牌の残り枚数とか
今はkyokustartで親を通知してもらってるけど、これなんかも
gamestartを作って最初に誰が親かを通知してもらえればいらない気が

694:デフォルトの名無しさん
08/09/25 00:07:49
sute<プレイヤー><牌>にツモ切りなのか
手牌から出したのかのフラグがあるといいかも

695:691
08/09/25 00:10:41
>>692
いえ、設計者の趣味の範囲なので、とくにどっちがいいという訳では無いです。
もし必要ならカンしたプレーヤーの直後のツモはリンシャンって処理するだけだし。

ただ、仕様としては、どっかに明記してあった方がいいかなと。

696:632
08/09/25 00:11:37
>>693
特に指針は決めてないんですが、基本的にはセッションは1局単位で
完結するようにしようと思ってます。

途中接続が切れた場合も、局の途中では戻れないが、次の局から
戻れる、みたいな。

なので、局が始まるときには、クライアントがその局の処理をするのに
必要な情報は渡すという感じです。

で、同じ面子で複数のセッションを繰り返すことで、半荘が成立すると。

ただこの辺はこれから実装して行くにつれて、色々変わって行く予感が
します(^^;

697:デフォルトの名無しさん
08/09/25 00:13:12
それぞれの牌にユニークなID振っていればツモハイ提供側で判別つくと思う
同じ種類の牌で手出しすることもあるけど、それはツモ切りではなくなるよね

698:632
08/09/25 00:20:18
>>695
ちょっと現状では必要性が感じられないので、
いったん保留とさせて下さい。

>>694
ああ、そうですね。それはあった方が良いな。
ありがとうございます。

個人的には空切りはキライなので、ツモ牌と同じものを
切ったらサーバ側でツモ切り扱いしたいんだけど、さすがに
それはマズいですよね(^^;

オカルトシステムNo.65「空切りは勢いを消す!」やw

699:632
08/09/25 00:23:18
>>697
なるほど!それは考えつかなかった。
ちょっとプロトコルを通す情報が(人間から見て)わかりにくくなるけど、
そうすれば確かにツモ切り判定はわかりやすいですね。

700:デフォルトの名無しさん
08/09/25 00:42:33
強いプログラム(AI)を目指してるのにいきなりネットワーク対戦プログラムなんて目的を見失ってないか?

701:デフォルトの名無しさん
08/09/25 00:46:19
>>698
ベタオリ処理で手出しから筋見てる部分があるので
空切りはツモ切り扱いでも構わなかったり(汗
それだと自分と同じベタオリ処理してる相手がいる場合のみ
立直側になったときにちょっと有利になるくらいかな?
ま、どっちでもいいです

702:632
08/09/25 01:13:40
>>700
自分としては、強いAIを作るための環境でもあるつもりです。
ただ、無駄に遠回りしているとは思います(^^;

もしスレ違いだという声が多ければ移動しますが、せっかく
何人かの方には反響を頂いているので、できればここで
話を続けさせてもらいたいです。

>>701
普通の麻雀でも、空切りを禁止した方が知的なヨミの要素が
増えて面白くなると思います。
ただまあプロトコルでできなくするのはマズいので、何か考えます。

703:デフォルトの名無しさん
08/09/25 02:20:35
>>702
プロトコルの策定は、プログラマ魂が湧き上がってくる話題で楽しいし、別に良いと思うのだが、あまり意味が無いかもしれないな。

というのも、実際はクライアント側にも共通基盤を作るはずで、
ネットワーク ---> クライアント共通基盤 ---> ユーザAI
結局プロトコルは共通基盤の開発者だけがわかっていれば良く、どちらかといえば共通基盤のIFを決めたほうがいいかもね。


704:デフォルトの名無しさん
08/09/25 02:22:11
プロトコル=IF

705:デフォルトの名無しさん
08/09/25 02:28:42
>>703のつづき
そういう意味では、とりあえずローカルで動くものを作っておいて、後でネットワーク対応にしても良いかと。

麻雀はルールや点数計算が複雑なため、これらを全員が作るのは明らかに無駄で、
クライアント側にもどうせサーバと同等以上のライブラリが必要でしょう。


706:デフォルトの名無しさん
08/09/25 02:31:39
>>704
それは現実的じゃないと思うって事を言いたいのだが・・・

707:デフォルトの名無しさん
08/09/25 02:44:24
いまの時点でのプロトコルはどう考えても、ネットワークプロトコルを指してないだろ。
管理プログラムとAIの通信方法。

708:デフォルトの名無しさん
08/09/25 02:54:39
>>707

話がかみ合ってないかな?
wikiには、「オープンなネットワーク麻雀のプロトコルを策定し」、「TCPを介した通信」って書いてあるけど・・・
それと管理プログラムって何?


709:632
08/09/25 02:55:20
>>703
まさにおっしゃる通りで、プロトコルの策定とか、わざわざ遠回りな
ことをしているのは「好きでやってる」というのが一番です(^^

そして、プロトコルを策定したとしても、クライアント共通基板(SDK的なもの)
が必要になるだろうというのは自分もそう思います。

ただ、色々なプログラムを対戦させたり、サーバ側でちょっと特殊な集計を
したいと思ったときに、共通プロトコルで動いているというのは価値が
あるのではないでしょうか。

とりあえず、前述した通り個人的に好きでやっているので、
生暖かい目で見守って、ときには意見やコードなんか頂けると
嬉しいです。

710:デフォルトの名無しさん
08/09/25 04:38:09
>>709
>共通プロトコルで動いているというのは価値があるのではないでしょうか。

あってもいいと思うのだが、コース料理でいえばデザートの部類ではないかと。

実際に動くAIが出てくるかどうか。
まずは、簡単にローカルで動く環境の提供が必要と考える。
要は、まずSDKから作ってみては?という意見でした。


711:デフォルトの名無しさん
08/09/25 09:53:11
オレはAIよりも、こういったシステムを作るほうが好きなので
こっちの話のほうが参加しやすいんだよなあ

712:デフォルトの名無しさん
08/09/25 11:07:21
システム作ったあと、AIはGP組み込んで、あとはぶん回しておけば
勝手に最強になるんじゃね?

713:デフォルトの名無しさん
08/09/25 20:20:54
SourceForgeの中の人はどこのルールで作ってるの?

714:デフォルトの名無しさん
08/09/25 20:28:27
ルールはこれで コンピュータ対戦向けのオリジナル
プロルールに基づく


URLリンク(act0.net)

715:デフォルトの名無しさん
08/09/25 23:27:41
101競技連盟、最高位戦日本プロ麻雀協会、日本プロ麻雀協会
日本プロ麻雀連盟、日本プロ麻雀棋士会、麻将連合

どれもルール違うだろ。「プロルール」なんてものは無い

716:632
08/09/25 23:39:10
ルールについては、今のところそんなに深く考えていません(^^;

まず、プロトコル(UMP)ではルールを規定しません。
それどころか、UMPではサンマでも青天井でも可能にする
想定です。
# ぶんぶんレジデンスの100人麻雀もできるようにしたかったけど、
# 現状だとプレイヤーをアルファベット1文字で表すので無理

ルールはサーバの実装次第なので、実際に動き始めてからでも
問題ないかと。
クライアント(UI)も、UMPにきちんと対応すれば、どんなルールで
あったとしても動作するハズです。

ただし、このスレの本旨であるAIを作るとなると、ルールによって
考えなければいけないことが変わるので、そのステップまできたら
ちゃんと考えないといけないと思います。

717:デフォルトの名無しさん
08/09/26 00:38:08
ふむふむ、だったらオープンリーチの対応もおねがいします。

718:デフォルトの名無しさん
08/09/26 00:38:32
>>711
あーそうか。
全員がAI作成を最終目標にしてると思い込んでたから、>>710とか書いてしまったが、
例えばプロトコルだけ考える人ってのがいてもいいわけか。
>>632さんはどこまで自分で実装する予定なんかな?


719:デフォルトの名無しさん
08/09/26 01:21:11
確かに棒聴即立で立直にベタオリだと立直時ツモ和了率六割越すけどプンリー有りは微妙・・・


720:632
08/09/26 01:30:50
>>717
オープンリーチ好きな人が多いなw
同じ人?
とりあえず仕様に追加しました。

>>718
自分としては、プロトコルの策定&サーバプロセスの実装、
テスト用クライアントの作成まではやるつもりです。
できればWindows版のクライアントを作ってくれる人が
現れてくれると、すごく嬉しいです(^^

721:デフォルトの名無しさん
08/09/26 01:49:13
確かに棒聴即立で立直にベタオリだと立直時ツモ和了率六割越すけどプンリー有りは微妙・・・

722:デフォルトの名無しさん
08/09/26 02:32:33
>>720
オープンリーチは待ちのわかる牌だけ晒すルールもあるので、
晒す牌の選択はクライアント側ではないかと。

プロトコルが対応してないから採用出来ないルール、ってのは
出来るだけ無い方がいいでしょ?

723:デフォルトの名無しさん
08/09/26 02:37:48
>>722
サーバーは待ちのわかる牌を自動判別出来るはずだから、サーバーが決めるんでいいじゃん。


724:632
08/09/26 02:38:05
>>722
んにゃ、全部晒すかどうかもサーバ側で決定します。
どうせサーバ側では不正をチェックしなければいけないので。

一部だけ晒せばOK、というルールのサーバのときに、
すべての手牌を晒したい、というときには問題になりますが、
それに対応する必要性は感じないんですが、どうでしょうか。

725:デフォルトの名無しさん
08/09/26 02:54:15
たとえば、23456と持っていて56を晒してオープンリーチ、ってのが許されるルールはありか?
とかいう話かな。
もちろん、4,7のツモ上がり前提で。

726:デフォルトの名無しさん
08/09/26 03:31:50
>>724
>それに対応する必要性は感じないんですが、どうでしょうか。
プレーヤーにとって意味ある事かどうかは、
プロトコル側では関知しないっていうポリシー
だと思ってたけど、違った?

727:デフォルトの名無しさん
08/09/26 07:28:21
まずはルールはこれでいいだろう
URLリンク(act0.net)

728:デフォルトの名無しさん
08/09/26 22:13:05
>>632
open<プレイヤー><手牌>で手牌全部見せたときと
鳴いた面子だけ見せたときのコマンドが一緒になると
クライアント側で牌の数チェックする手間がでるんで
手牌か面子(ポン・チー/カン)かのフラグが欲しいです


729:デフォルトの名無しさん
08/09/26 22:23:48
情報にはノイズ乗せないの?

730:デフォルトの名無しさん
08/09/26 22:52:12
打牌に制限時間設けないとひたすらぶん回し続けるAIが出てくる予感
一秒制限の早差し勝負とかもやってみたい

731:デフォルトの名無しさん
08/09/26 23:36:33
通信が遅れる可能性は十分考えられるので
サーバ・クライアント共に何回目のackかを示す情報も必要かも

732:632
08/09/27 15:12:38
>>725
さすがにそんなルールは聞いたことないですが、もしかしたら
1が枯れている場合はOKとかはあるかもしれません。

>>726
おっしゃる通りです(^^;
ということで、とりあえずopenrichiコマンドに晒したい部分の手牌も
指定できるよう仕様に追加しました。

733:632
08/09/27 15:13:04
>>728
openの手牌は、手牌の表記に則るので、
和了ったときは open A 1m2m3m4p5p6p7s8s9s1z1z1z2z2z
ポンのときは open A <3m3m3m>
チーのときは open A <1p2p3p>
暗槓は open A (8s8s8s8s)
となるので、クライアントでも容易に区別できると思います。

>>729
ノイズって、どういうことでしょうか?

734:632
08/09/27 15:17:57
>>730
実際に運用するとなると、時間制限は必要になると思いますが、
実験段階では、ひたすらぶん回して、それこそ1打1時間とかかけたとしても
本当に強いAIが出てくるなら、それはそれで面白いんじゃないでしょうか。

>>731
コマンド形式のところにある<センテンスID>というのがそれです。

ちなみに、最初はサーバから1コマンド送るごとに必ずクライアントの
ack(okコマンド)を待っていたのですが、実装してるうちに不要な気が
してきたので、必要なとき以外はクライアントからの返答を待たない
ようにしました。

735:デフォルトの名無しさん
08/09/27 15:21:19
1打1時間掛かったら強いことが調べられない

736:デフォルトの名無しさん
08/09/27 15:33:13
>>632
をを、プロトコルが強化されてる、乙かれ。

737:632
08/09/27 15:37:46
>>735
人間相手だと、さすがに人間の方が耐えられないだろうけど、
AI同士なら別に1打1時間かかるのもアリじゃない?
まあでも実際、将棋や囲碁に比べれば、麻雀はプレイヤーの
できることが少ないから、さすがに1打1時間はないと思うけど。

>>736
実装しながらなので、随時変更してってます(^^;

738:632
08/09/27 15:39:46
ちなみに、開発途中ではありますが、ソースコードをSourceForgeの
SVNに随時commitしているので、興味のある方は
URLリンク(svn.sourceforge.jp)
から拾って下さい。

739:デフォルトの名無しさん
08/09/27 15:47:07
AIどおしでも1時間は無いよ。 たとえば一手3秒以内で1日中動かして統計を取ったとする。
これを一手1時間以内でやったら、同じ回数をこなすには1200日掛かることになる。
3年以上掛けてパソコンを動かさなければ強さが判らない。

740:デフォルトの名無しさん
08/09/27 15:51:03
PC1台で検証するならそうだな

741:デフォルトの名無しさん
08/09/27 15:51:27
PCの性能で応答時間は異なるけど、一つが遅ければ全体に影響するから
平均応答時間程度にするとかにして、時間切れはツモぎりとかのほうがいいとはおもう。

742:632
08/09/27 15:58:26
実際に色々なAI同士を戦わせてみよう!となったら、
麻雀のルールの他にも決めなければいけないことは
あると思います。
それこそ制限時間とか、あるいは鳴くかどうかのラグを
情報として使うのはアリか、とか、相手のAIの傾向を
「最初から」入れておくのはアリか…等々。
いうなれば大会のルールみたいなものですね。

743:デフォルトの名無しさん
08/09/27 16:06:22
一手に3秒もかかったら、まともな統計は取れないですね

744:デフォルトの名無しさん
08/09/27 18:55:36
>>729
733のいうノイズは、おそらく意図的な情報伝達ミスだろう
麻雀でいうなら見間違いとか切り間違いとか

ゲーム理論の研究ならノイズも必要だけど、麻雀サーバには無用な仕様だよね

745:デフォルトの名無しさん
08/09/27 19:06:32
ルールは実在ルールの中でもAIにとって処理しやすいものが良いと思う。

746:デフォルトの名無しさん
08/09/27 20:24:35
>744
エラー処理あるいはテスト仕様としては必要かも知れないよ。

つまりクライアントやサーバーが全く期待していない
矛盾した情報を受け取った時に何を返すべきか?
意味不明だと単にエラーを返すか、通信にリトライを要求するか?

そこまで仕様として決めておくのは面倒ではあるが、
下手をすると一回の通信エラーで全体が一気に倒れかねない。

747:デフォルトの名無しさん
08/09/27 21:00:00
今の仕様だと誤ポンも誤ロンもサーバが無視なのか・・・
クライアントが矛盾したロンやリーチしたら
それはそういうときの処理をした方がいいのでは?

748:デフォルトの名無しさん
08/09/27 21:28:36
ルールとプロトコルが直行するように決めるなら
ダブロンとかの扱いもちゃんとしておかないと

749:デフォルトの名無しさん
08/09/27 21:50:04
「コンピュータ麻雀のアルゴリズム」なんて本が出てるんですね。
Amazonのおすすめに出てきて驚きました。

750:デフォルトの名無しさん
08/09/27 22:44:26
>>747
誤ロン誤ツモはチョンボだろ
ノーテンリーチはかけられるようにしとかないと
戦略の幅が狭まる

751:632
08/09/27 23:31:05
>>747
自分の考えでは、誤ポンや誤ロンは、麻雀とってはまったく
不要な要素だと思っています。
極端な話、山を崩すのとたいして変わらないくらいで、
コンピュータ上で麻雀を打つなら、発生させないように
するのがベストではないでしょうか。

ただ、>>750の言う通り、ノーテンリーチについては戦術として
考えることもできるので、それは悩ましいところです。

>>748
一応現状のプロトコルの仕様でもダブロンは発生させることが
できると思います。
ただ、自分が作るサーバの実装では入れるつもりはありません。

752:デフォルトの名無しさん
08/09/28 00:57:59
チョンボはありだろ。 役満がほぼ出るならチョンボして流すという手もあり得る

753:デフォルトの名無しさん
08/09/28 09:53:14
なら、>>752 がチョンボあり版を作ればいいじゃない

754:デフォルトの名無しさん
08/09/28 15:00:06
>>751
極端な話、その仕様だとクライアント制作者は和了判定を素っ飛ばして
とりあえず毎回サーバに和了コマンド送信する処理でもいいことになる
まあ毎回でなくとも形聴取ったなら海底河底で一応和了っておけみたいな
錯和が不要という考えは分かるけど何かしら対策はした方が良さ気

755:デフォルトの名無しさん
08/09/29 02:02:32
そもそもサーバにそういった情報も問い合わせられるようにするなら
そんな心配は無用

756:デフォルトの名無しさん
08/09/29 14:42:31
URLリンク(ouc.daishodai.ac.jp)

これの麻雀研究特集号を読んだ人いますか? どんな内容でしたか?
「麻雀のベストプレイは存在するか」が気になる

757:デフォルトの名無しさん
08/09/29 20:24:53
鳴きのアルゴリズムって、基本的に

鳴いた場合の期待値 > 鳴かない場合の期待値

の時に鳴くって考え方でおk?

758:デフォルトの名無しさん
08/09/29 20:28:24
>>757
一発消しだったり、自分が上がれる確率まで含めての期待値だったり

759:デフォルトの名無しさん
08/09/29 21:13:42
>>757
ま、どんなときでも期待値の高い選択をすればそれでいいわけで、
期待値が計算出来ないってのが問題ということです。
URLリンク(www.ara3.net)

760:632
08/09/29 23:46:31
>>754
> その仕様だとクライアント制作者は和了判定を素っ飛ばして
> とりあえず毎回サーバに和了コマンド送信する処理でもいいことになる

別にそれでも全然構わないと思ってるんですが、問題あるでしょうか?

761:デフォルトの名無しさん
08/09/30 01:27:00
ある

そんなのは麻雀AIじゃない

762:デフォルトの名無しさん
08/09/30 01:31:02
二歩を指した将棋AIが負けを宣言されるとするならば
誤ロンした麻雀AIはチョンボを取られるべきだ
なぜなら、それが麻雀というゲームのルールだから

763:632
08/09/30 01:48:11
>>762
将棋の場合は二人なので、片方に対するペナルティは、
必ず対戦相手の利益になりますが、4人で打つ麻雀の場合、
あるプレイヤーに対するペナルティが、他の3人に対して公平で
ないのが問題です。

そう考えると、可能な限りペナルティが発生しないというのが
理想だと自分は思います。

764:デフォルトの名無しさん
08/09/30 01:56:28
>>760
抜け道があると「UMPでは最強かも知れないけれど〜」みたいな
グタグタな流れになるので、できれば対策して頂きたいです
錯和してるのに続行は問題なんで、和了放棄とか特別ルールはどうですか?

765:デフォルトの名無しさん
08/09/30 02:04:15
>あるプレイヤーに対するペナルティが、他の3人に対して公平でないのが問題です。
チョンボは親子関係なく3000オールって雀荘もありますけど、それでどうですか?

766:デフォルトの名無しさん
08/09/30 02:10:18
標的が和了するのを阻止するためだけに
わざとチョンボされるかもしれない問題ってのも
考えられるからルール設定の扱いにしては?

有効、無効はサーバ側で決定
局or半荘開始時にサーバからクライアントに送信される形で


767:デフォルトの名無しさん
08/09/30 02:16:02
補足しておく
ハコテンで半荘終了であるとする

ある局で特定のクライアントがトップ目であるとき
チョンボクライアントが常にチョンボすることで
半荘のトップ目をとらせるという戦略が考えられるなぁと

768:632
08/09/30 03:29:23
チョンボについて意見が多く、それに対して自分の見解をまとめて
みたんですが、あまりに長文になってしまったので
URLリンク(sourceforge.jp)
に書いておきました。

769:632
08/09/30 03:37:16
ちょっと書き逃げみたいになっちゃいましたが、自分としてはまず、
UMPでのサーバ/クライアントで麻雀を打てるようにする、というのが
第一にあります。

その次に、チョンボも含めたルールとか、あるいは実際にどこかにサーバを
立てるのか、どう運用するのかということを考えなければいけないと
思いますが、現状その段階についてはあまり具体的に考えていません。

# 正直、チョンボ云々より、実際サーバプログラムを作ったとして、どこで
# 動かしたら良いかの方が悩みです(^^;

もちろん議論自体は活発に行われるのは良いことだと思いますが、
とりあえず自分の現状のスタンスを表明しておきたかったのです。

770:デフォルトの名無しさん
08/09/30 18:59:55
まあテスト用のサーバとしてうちで提供してもいいよ。
RDBMSを積極的に使ったシステムがいいなあ。


次ページ
最新レス表示
スレッドの検索
類似スレ一覧
話題のニュース
おまかせリスト
▼オプションを表示
暇つぶし2ch

5392日前に更新/253 KB
担当:undef