堕天使の煉獄

相変わらず麻雀ＰＧ。

思考回りを作り始めたところでそのあたりの情報あさってると、でてくるサイトでは基本的には対戦相手として人間らしい打ち方をするＡＩを目指してる方向な感じで、いま自分が作ろうと思ってるものからすると、ちょっと方向がちがうなと思ったりして。

いちおう、目指してるのは麻雀が戦闘シーンなＲＰＧ的なのを考えてるのだけども、それだと、人間らしい打ち方よりも、敵レベルとかタイプで出現場所や種類を変えるようなのが好ましい。

そこから導き出される答えとしては、「雀風設定しての役の決め打ち」というのが都合が良さそうだなと。

雀風：国士無双　レベル:100

だと、配牌時に一九字牌が一枚もなかたっとして国士を狙う国士キ○ガイにｗ　
レベル90とかだと九種九牌からじゃないと狙わないレベル50だと一九字牌が5枚以上あったら……みたいな。
レベル100を越えてると配牌時に積み込みで国士狙いやすくなってるとか。配牌時積み込みも別でなんかレベル的なの持たせる方がいいかな。
んで、自摸回数と向聴数の減り具合とかで、たまに他の役を狙う転換判定なんかいれるかんじで。

そんな感じで設定レベルの高い順に役を選択して、その役固定で打っていく感じにして、配牌時（または目指す役変更時）にだけ手牌を走査して不要牌と必要な牌をリストアップ。そこから自摸してきた牌を捨てるか入れるか判断するだけだとかなり楽ぽ。

人間らしい打ち方を追求する前者のやり方の場合、毎回自摸って来るたびに牌効率とか完成系の点数期待値とか出すために毎回手牌を解析したりと結構なコストがかかるし、努力のわりにちゃんとした打ち手になるのか、といえばかなり難しい。

なので、作りたい物の性質上からもこの役の決め打ちパターンのが良さそうだなーと。

でもまあ、作るの楽かといえば……牌効率とか得点期待とか算出するやり方に比べればかなり楽ではあるものの……。

例の国士とか、七対子あたりはまだ楽なんですけども。
派生条件とかも単純だし。

国士崩れだと、字一色、清老頭、混老頭、七対子、ポンして役つけとか、全帯、純全帯三色（ちと遠い）あたりとかぐらいだし
七対子なら、四暗刻、対々とか役牌あればポンして役のみのぐだぐだとか。

元の役が特殊な形だと派生も限られてくるので楽なんですけども、いわゆる基本形となると、結構選択肢がもりもり増えちゃうんですよね。

雀風：平和

なんつっても、平和だけ狙うバカは居ないし。
基本的には順子系なので、一盃口、三色、一気通貫あたりが派生で、いわゆる手が伸びる状態になることがあるので、単純に平和系といっても選択肢がかなり多い。
雀風レベル的な物で、レベルが低いと派生系は一切無視して、ひたすら平和に向かって向聴数減らす打ち手をするだけ。っての作ったとして。
それに対して一盃口、三色、一気通貫あたりにリニアに対応する思考ルーチンつくった場合、なんか意外にも前者の方が最終的な得点率上になっちゃいそうな気がするんですよね。
派生無視といっても偶然役がつくこともあるわけで。
むしろふらふら狙いを変える打ち手の方が単純な和了率では下がったりすることもあるんじゃないのかなーとか。どうなんだろう？　いずれ検証はしてみるつもりですが。
あとは待ちの形の変更とかも考えないといけないか。
両面系とか三面待ち目指せる良形とか、そいいうセオリー的なのもあるし。

そして断ヤオ系もまた幅が広い。んでも断ヤオは一九字牌を持っとくかどうかの判定基準オンリーで使用するサブ属性みたいなのにするほうがいいのかなーとか。

そんなかんじで、思考ルーチンまわりの設計がちょっと楽しくなってきてたり。


それとは別に……。
とりあえずテスト用にと大まかな麻雀ゲームの流れを作ってみたところで。
この辺は昔作ったやつを大まかになぞってリライトしたものなんだけども。

メインループの中で自摸順でプレイヤ*4のループ回して……なんて作りは失敗だったなと。

単純にいろいろなルール吹っ飛ばして、ひたすら正しく自摸順どおりに進行する場合ならこれでいいんだけど。
実際のルールをキチンと盛り込んでいくと、こりゃダメだわと。麻雀て結構複雑なルールなんだなーと改めておもたり。

まずポン、槓で自摸順が変わる。
天和、十三不塔など、初回一順目だけ有効なルール。そこに途中ポン、チー来たら一巡目定義崩れるルールで和了見逃しの一巡ルールなんてもの。
さらには一巡ルール内で一巡目、それぞれ同じ風牌をすてたら流局の四風連打というのもあるし。
結構いろんなルールがあって、それを単純なループで処理すると、どんどん状態設定とか条件式がふえてカオスになりがち。

そこで、自摸とかポンとか、そういうアクションをイベントとして発行するイベントドリブン形式にするべきだったなーと。

イベント単位なら、そのイベントに対するリアクションだけ書けばいいので。
たとえば「捨て牌」イベントなら、他家は和了判定、鳴き判定とか。イベント単位で完結できるので、その方がわかりやすいぽ。

またこの方式だと、いまはQTで途中経過とか表示しないで終局後にレポートだす感じだけども、最終的にはゲームにするので、描画処理と内部処理が分かれる作りのばあいにもイベント駆動はその辺の分離がやりやすいなと。描画ループとイベント処理を別にするだけで済むので。

そんなかんじで、ちょいと仕切り直しぽ。


あとは小ネタとして。
QTのバグというかQt Creatorのバグ？　というより単に未対応な感じなのか。

using Player_ptr = std::unique_ptr<Player>;
std::array<Player_ptr, mj::kPlayer_Max> m_list;

こんな感じのリストがあって。

m_list[id]->

IDE上で候補でなーい。

const Player_ptr& get(int id) const { return m_list[id]; }
get(id)->last_捨て牌();

こうすると出るー

なにげに
using Player_ptr = std::shared_ptr<Player>;

とunique_ptrからshaerd_ptrにかえると出るー

QTではいまいちｃ++11対応が微妙なんだよなーと。
いやでもこれって、unique_ptrは配列対応あったけっかと。(std::shared_ptrにはない)

std::unique_ptr<Player[]>　みたいにするとoperator[]でunique_ptrの配列アクセスできる。
これがstd::arrayのoperator[]とおかしな事になってインテリセンスきかなくなってるのかなーとか。配列のないshared_ptrだと出来るので。

でもまあ、いまさら入力補完無しとかやってられないし･･…とはいえ、unique_ptrで済んでるところを必要も無いのにshared_ptrにするのもなにか負けた気がする……。
むぐぐ……。

ちなみにclangコードモデルのプラグインＯＮにすると、この問題は解消されるんですけど……
QT Creator4.1までの段階では、うちの環境だとなぜかこのプラグインがソースコードのファイルをロックしてしまい、ソースコードの上書き保存が出来なくなると言う不具合がでるため使用不可……
QT Creator4.2が出てたのでｖｅｒ上げてみたけど、どうなんだろう。
これって常に起るわけでなく、しばらく使ってると起るようになるので。
起ってしまうと未保存のソースコード全部保存不可になってかなりファッキンな状態になるので怖くて使えないｗ

そしてうちのＰＣが貧弱なのかclangコードモデルＯＮにすると、かなり重くなる。
体感的には、WinXPでのvc++2010よりもさらにちょっともっさりした感じ（わかりにく）

で、こりゃそろそろほんとＰＣ新調も考えないとなとか。いまだにcore2duoだもの。

あ、あとこんなネタもあったっけか


基本的には、普段は識別子に日本語使うのは否定派。ギリで仮引数は影響少ないので有りかもねぐらいの感じなんですけども。

でも麻雀ＰＧのような、英語に簡単に置き換えられない固有名詞が多い物を作る場合、ローマ字でKokusimusouなんてかくよりは国士無双と日本語で書いた方が可読性的にもマシ。もとの呼称とちがう英語に置き換えるのも混乱の元だし。
ということで、麻雀ＰＧに関しては日本語解禁してるのだけども。

なんかコードの色がおかしくなってますねｗ
実行には問題無いものの、QT Creatorのコード解析当りでは二バイト文字がなんかしでかしてる気がしないでもない……。

日本語識別子の問題の一つは、ワード先頭から日本語だと、日本語変換ＯＮにして打たないとインテリセンス効かないってのがあったりして。
なので、tumo_自摸 get_自摸とか言う具合に、先頭三文字程度は英数字にして候補出しやすくするみたいな感じにしてるんですけど……うーん。

あと、英語オンリーだとある程度関数とかの命名方法は慣例がある程度固まってるのでそれほど単語の選択に迷いはすくないのだけども、先頭から日本語ＯＫだと、その命名規約的なのがまた一気に幅がふえて面倒になりそうだなとか。

int 取得(){...}
int 受け取る(){...}

とか。こりゃ極端な例だけど。
でもこの場合はやっぱ先頭はget_とかつけた方マシだよなぁ。
すべてを日本語にってのはやっぱ無理がある気がするｗ

あくまで可読性を上げるために……今回のは固有名詞をローマ字で書くよりはマシってことでそこを置き換えるだけ…という用途で限定的に日本語解禁。
っていうスタンスなのがやはり無難かなーと。

うーんでもやっぱ、日本語混じったソースコードっていまいち馴染めないな……。