利用者アンケートへの協力のお願い

まったり麻雀を利用されている方にアンケートをご協力をお願いします。

アンケートサイトはこちらです。

アンケートの集計結果は、次の次の次あたりのメジャーバージョンアップのとき、参考にさせてもらいます。

追記：2012/2/6 10:99～20:00位の間、アンケートサーバがダウンしてましたすいません。

今後の予定とかメトロＵＩとか

Windows 8では、メトロＵＩという今までとは全く違ったＵＩと実行環境がサポートされます。既存のアプリも動くようですが、今後は、メトロＵＩが主流になる可能性もあり、Windows用のソフトウェアを作ってる人は既存のアプリをメトロＵＩへの対応を迫られることになるかもしれません。

私としても、将来的には、メトロ対応を迫られることもあるでしょうが、当面はまだ、オールドスタイルで行くつもりです。

大きな理由は２つあります。一つは、各解像度にあわせたサイズ変更可能な牌画を書くスキルが私にはないこと。もう一つは、そもそも、麻雀ゲームを作って公開したいわけではなくて、自分が納得のいく強い麻雀思考ルーチンを作りたい目的で開発しているので、これ以上、少ない作業時間を、実行環境やＵＩの修正に時間を割きたくない思いが強いこと、です。

性能面の問題やメトロＵＩが大コケする可能性も心配です。

そんなわけで、まずは納得のいく、思考アルゴリズムを作ることに当面は力を入れて作業をしていく方針です。

目標的には来年の暮れごろを一つの目安にして、思考ルーチンをメジャーアップデートしたバージョンを出したいと思っていますが、早くも躓いていて暗雲が垂れ込めてます

次の版の予定

次のバージョンは、思考アルゴリズムの刷新をメインの更新内容と考えています。

より深く、より広く、より正確に、先を読むアルゴリズムにするために、手牌のデータ構造の改良から作業をすすめていきます。そのアルゴリズムの改良によって、鳴き、点数状況判断、立直判断の改良につなげていきたいと考えています。また、ブログやぷちカンパを通してコメントをいただいた機能についても実装を検討し可能であれば反映していきたいと考えています。

新思考アルゴリズムの開発も、またかなりの手間と期間がかかる見込みであり、大きなアップデートはまたずいぶん先になるかもしれませんが、バグについては、できるだけ速やかに対処していくつもりです。

牌譜データ解析とか

　というわけで、いずれ、牌譜のデータを取り直すことになりそう。

　最近似たようなデータ公開してくれている人は多くなってきたのだけれど、残念ながらそのまま流用はできない。麻雀ゲームの場合、ある程度、具体的な場況がわかっているので、もっと、条件分けをして集計する必要があるからだ。

　例えば、立直ロン和了の平均点数も、今このシーンで振り込んだ場合、一発や海底撈月がつく/つかないが判っているので、そういった条件分けをしたうえで集計する必要がある。一発/海底撈月以外にも、場に見えているドラの枚数などで平均和了点数は変わってくるので、そういった条件分けも必要となる。また、順位戦での点数状況判断のためには、平均点数だけをスカラーなデータで持つのではなく、各点数毎の確率分布をベクトルデータで持つようにする必要もある。

赤ナシデータの採取はそれほど大変ではない。既に東風荘用の解析ツールは作ってあるので、数時間程度の作業時間を割いて作業を進めればよいだけの話である。

ただ、赤ドラ対応用に天鳳用の解析ツールを別途作る必要があって、これが結構面倒くさそうな気がしている。

天鳳の牌譜の解析のやり方には、大きくは３通りのやり方が考えられる。

その１
Windowsの有償版天鳳ソフトについてくる牌譜解析ツールlogana.exeで動作するjavascriptで作る方法。

その２
天鳳の牌譜ファイル（mjlogファイル）を直接読み込むプログラムを作成する方法

その３
有償版Windowsの牌譜解析ツールで、天鳳の牌譜ファイルを東風荘ライクなテキスト形式のフォーマットに変換し、変換した牌譜ファイルを解析するプログラムを作成する方法。

　一番スジが良いのは１だと思う。logana.exeには、向聴チェックや、グラフ作成、牌画表示などをJavaScriptから利用できる機能もあるようだ。また、牌譜フォーマットの変更も、logana.exe本体が対応してくれるので、個別のプログラマが作成するJavaScriptで対応する手間が少ない。 開発者間でソースを流用したり、一般ユーザにアプリを公開するとしたら、この方法が一番楽だろう。つの氏もそうしてほしいと思って今のような仕組みの牌譜解析ツールを作ったのだろうと思う。（ただ、そうならば、有志作ったツールのURLを記録するためのブックマーク機能や、ＳＤＫ的なドキュメントも欲しかった。）
　天鳳界隈のプログラマが皆logana.exeで動作するJavaScriptでツールを作っているならば、オープンソース的なコミュニティが出来て、いろいろ便利なのだけれど、残念ながら、現実的にはそういった方向で牌譜解析を作るような雰囲気になってないようだ。
　また、まったり麻雀の開発という意味では、赤あり/赤なしの両方のルールに対応するために、東風荘のデータ解析と天鳳用のデータ解析でまったく別々にツールを作る必要が出てきて、２倍の手間がかかってしまう問題もある。

　その２は作るのが一番面倒くさそう。天鳳のフォーマットは、ＸＭＬ的な面と、ビット操作的な面が混合したフォーマットで、東風荘と比較すると、可読性が悪くて、なにかと煩わしい。それに天鳳はフォーマットをコロコロ変えるのでいちいち対応する手間を取られそう。 ただ、これを作ってしまえば、別の天鳳ツールをつくるときに、色々と流用ができるメリットがあるのも事実。また、処理速度的にもこの方法が一番早いだろう。

　その３のやり方は、東風荘の牌譜解析ツールを既に作ってあるならば、それを少し改造して対応できそうなのがメリット。プログラム作成の手間自体は一番楽そうだけれど、一度牌譜を変換する手間をかける必要があるし、データ解析以外の別の天鳳ツールへの流用がやりにくいデメリットもある。また、一般公開も実質無理だろう。

単純にまったり麻雀の開発に必要なデータを取るツールを手間をかけずにつくるなら、その３が一番楽なのだろうけれど、まだどの方法でやるか決めかねている。

点数状況判断を修正したいけど

点数状況判断を修正したいけど、その前に、鳴き判断の再調整が必要。
鳴き判断の再調整をするためには、卓上の情報を扱うクラスの再構成が必要になりそう。
卓上の情報を扱うクラスの再構成をするとプログラムあちこちを直す必要がありそう。

もうちょっと最初から考えて作ればよかった。どうするかなあ……
最初から作り直してるVer0.9に完全移行するべきか……

おぼろげに新しいアイディアが浮かんだ

ちょっと試してみたい評価関数のアイディアが浮かんでいる。
2005年頃に一度ためしてあまりうまくいかなかった多牌型の評価関数の欠点を緩和できるかもしれない。

まずは一人麻雀で試してみるかな。

しかし、やりたいことが多くてなかなか大変だな。ネト麻やる回数減らして時間ひねり出すしかないか。

デュプリケート麻雀実現の問題点

麻雀はやたら運に左右されるため実力を比較するためにはどうしても大量にゲームを行う必要があります。この問題を解決するために、ブリッジの大会などでつかわれている同一の手札で競技することで運の要素を軽減するデュプリケートルールを麻雀に採用できないか？という考えを持つ人は多いようです。

私もまったり麻雀にデュプリケート機能を実装することにより少ない試合数で実力を比較することができないだろうか考えたことがあります。

思うに、問題は３つあります。

１）鳴きによるツモのずれをどうするか
デュプリケートが良く採用されるブリッジの場合、運に左右される箇所は麻雀でいうところの配牌のみでツモがないのですが、麻雀にはツモがあるという問題があります。ツモは鳴きによって簡単にずれてしまいます。厳密にデータとったわけではありませんが、感覚的に、配牌による運不運より、ツモによる運不運のほうが成績に与える影響が大きいように思えます。

そのため、単に、乱数のシードだけ指定可能にすればデュプリケートを麻雀で実現したとは言えないと思います。さらに、何らかの工夫が必要でしょう。

例えば、対策として、ツモがずれないようにルールを変更すると言う手はあります。
つまり、通常の麻雀のようにツモ山の開門位置から全員が時計回りに取るのではなくて、皆自分の前に積まれている山からツモをとるような感じにするということです。
このことで、ツモが鳴きによってずれが生じないようにすることはできるかと思います。

２）連荘による局のずれをどうするか
１）の問題はツモの方法を変えることで解決するとしても問題になるのが、この連荘の扱いです。

「なまじ親で連荘したばっかりに、次の１本場で倍満ツモられて親かぶり食らった。」などのケースをどのように扱うのか。ツモのように連荘しても少なくとも０本場のときの配牌とツモは固定とするように扱うのか等考えなければいけない問題があります。

対策として、ゲーム開始の段階で東１局から南４局までの０本場から１０本場までの配牌とツモを固定してしまうのが良いのかなと考えています。

３）成績の評価をどうするか
さらに問題なのが、デュプリケートを実装したとしてどのように成績を比較するか？です。
皆が同一条件の乱数値で打った成績を比較するようなネットのサイトを設けるのがベストかと思うのですが、この手のサイトを作るとどうしてもズルをする人や、他者がズルをしてると勘違いして、処罰を管理人に求める人などが現れるでしょう。このようなサイトを開設すると、ネット上のケンカの仲裁役をやるハメになりそうで考えただけでうんざりします。
もうひとつ、そもそも根本的な問題として、デュプリケートを実装してネットの成績比較サイトを立ち上げたとして、本当に人が集まるだろうかという問題もあります。
私が最近ブログで投票アンケートをとっているのも実はどの程度人が集まりそうかを計測してみたい思いがありました。見てのとおりでして１クリックするだけのアンケートですが、１００人程度しか集まりません。
まして、まったり麻雀で、ある程度（１００試合以上？）打って成績を他者と比較してみたい人なんて本当に集まるのか疑問です。

対策としてはCOMと比較してみるという手が考えられるとは思います。
最初にプレイヤーが打った後、COMが同一条件で打ってみて成績を比較してみるという手はありそうです。ただこれを実装したとしてもCOMより強いかどうか程度しか結局判別できないのであまり意味が無いかもしれません。

＊　＊　＊
単に乱数値のシードを指定してゲームを開始するだけだと単なる「たら・れば」機能にしかならないのではないかと思います。

これら３つの問題にもっと良い解決策があるのならデュプリケート麻雀は実装してみたい機能ではあります。何か良い案があればぜひ教えてください。

ごちゃごちゃ言ってないで、まずは簡単に実現できる単に乱数シード指定だけやってみて、その上でさらに改良案を提示してもらうという手もありかもしれませんか……

いったん凍結

主力のアルゴリズムに使うためには、まだ練りこみが足りないので、次期バージョンの主力アルゴリズムには採用できないだろう。新アルゴリズムはいったん凍結する。

ただ、完全に没にする気は無い。今後復活させることも十分ありえる。
たとえば、大差をつけられた4位の場合などには今のままでも使えるだろし、また、評価値に補正値を掛ければ使えるようにはできると思う。
けれど、安易に補正値を入れるのは美しくないし、点数状況判断が必要なケースで使うにはほかに修正しなければいけない箇所が多数あるのですぐにはできない。

一人麻雀で有効でも四人麻雀でも有効とは限らないというケースが実際に見つかっただけでもやった価値はあった。
とりあえず、そう思うことにする。

全体レイアウト案

画面のレイアウト案いくつか考えてるけれど……ホント、センス無いな私。

公開できるのは相当先になりそうです。あしからず。
画像をクリックすると実物大で表示されます。
プランA

でもこれ、捨てパイの表面の長方形を横にしただけだから見え方が変。
河に捨ててある縦になってる牌は細長く見えて、横になってる牌は幅広く見えちゃう。
そこらへんを考慮して牌画を画像しないといけないだけど……
画面スカスカ感は幾分マシかもしれないけれど、牌の大きさ自体は今と一緒。
あとテーブルの緑一色は、フリーの壁紙か何かに置き換えたいところ。

もう一個。プランB

真上からの視点で手牌だけは大きくするパターン。これで800x640のサイズがある。下部に鳴きボタンを配置して、上部のメニューやウインドウバーがあるから1024x768ギリギリになる。これだと、手牌だけは今より大きくなるけれど、テーブルのスカスカ感は解消されないだろうな。
それに、大きなサイズの牌画をどうするのかって問題もある。今使わせてもらっているマツセンパイの牌画を単純に２倍するか、自分で書き直すか両方やってるけれどいまいちしっくりこない。

反復深化法もどきで、もっと手広く読むように

　まったり麻雀がメインで利用している捨てパイ選択のアルゴリズムは、かなり棒テンに近い打ち方をする。そのため、愚形のターツを大事にしすぎて、愚形リーチが多くなる問題を抱えている。また、2345や2334のような形の有効性を認識できないし、順子をドラ側に寄せるようなうち方もしないという問題もある。
　そのような問題を改善するため、もっと手広く読むように評価関数のアルゴリズムを改造したいと思う。けれど、ただ単純に手広く読むようにしてしまうと、古いＰＣでは遊べないほど遅くなってしまうのは目に見えている。
　そこで、将棋などで用いられている反復深化法のようなやり方を取り入れてみる予定。具体的には、棒テン気味の期待値型評価関数での評価順に捨てパイ候補をソートし、ソートした順により深く読む期待値型評価関数で評価。制限時間がきたらその段階で打ち切るようにする。
　恐らく、利用しているアルゴリズムをほとんど改造しないまま使いまわすことが可能だろう。まずは一人麻雀の方でプログラムを組み込んでみて、効果を計測してみる予定。

　……ということで、一人麻雀を起動。久々にみると懐かしいなこの画面。