棒テン即リーアルゴリズムと向聴数計算方法

手牌を探索するとき、受け入れ牌、捨て牌候補のリストアップをする必要があるけれど、そのために、まずは向聴数をベースにリストアップするのがひとつの現実解となる。

１３枚状態の手牌と１４枚状態の手牌の向聴数が調査できるアルゴリズムが作れれば、１４枚状態から向聴数を落とさずに１３枚状態にできる牌をリストアップすることも簡単にできる。
そして、打牌をして１３枚状態になった手牌で、個別に牌を追加して１４状態にしたとき向聴数が向上する牌の種類と枚数をカウントし、最も多くなるような、打牌を選択すれば、棒テン即リーのアルゴリズムは出来る。
　東風荘でR1400以下程度のあまり真剣に麻雀に取り組んでない人相手なら、単純にこれだけのアルゴリズムでもそこそこ相手になる麻雀プログラムになる。

向聴数を調査するアルゴリズムには、おおむね２通りのやり方がある。ひとつは手牌をバックトラック法で、面子、塔子、対子、孤立牌に分割する全パターンをリストアップし、そこから、面子数、塔子数、対子数から向聴数を計算する方法。

もうひとつは、あらさんのホームページに載ってるような１スーツ分のハッシュテーブルを持つ方法。
１スーツ分（例えば、萬子）の考えうる全てのパターンと、
手牌を面子数×１０＋（塔子＋対子）の数が最大となる面子の数と（塔子＋対子）の数と、
、面子数×２＋（塔子＋対子）が最大となる、面子の数と（塔子＋対子）の数を
構造体メンバとしてもつハッシュテーブルを作ってそこから向聴数を計算する。

　単純に向聴数をカウントするだけだと、ハッシュ方式の方が５０倍近く早い。
あらさんの一人麻雀練習機はこちらを採用している模様。

　ただ、ハッシュ方式だと、死に塔子の判定がしにくい。死に塔子とは、例えば１－３のカンチャン塔子を持ってるとき、他者に２を槓されて面子に変化しなくなってしまった塔子のこと。このときは実質向聴数が＋１になるけれど、ハッシュ方式だとこういった死に塔子をバックトラックで探索していかないと見つけられない。
それに、アルゴリズムによっては打牌せず、ツモだけして、多牌状態にしてから評価したりする場合もあり、そういった方式に応用しにくいし、事前に無駄だと分かる打牌を前方枝刈りするのも難しい。
　また、単純に速度面から言っても、向聴数の計算は速いものの受け入れ牌のカウントや、打牌候補の選定は手牌分割方式より遅いという欠点もある。（これはそれ専用のテーブルを作れば解決できるが）

　鳴きなし、相手なしの一人麻雀だとハッシュ方式でなんら問題ないんだけれど、点数状況による和了点の制限や鳴き、他家の捨て牌等がからむ４人麻雀ではたとえ５０倍遅くても手牌分割方式のメリットは捨てがたい。

なので、私は今まで手牌を面子塔子対子孤立と分割状態にした状態のままコンテナに入れておく手牌クラスをつくり、、探索中は、分割状態を持ちまわって手牌のツモ＆打牌が出来るようにしている。
そのことで、速度的に遅い手牌分割を最初の１回だけしかやらずに済ましている。

　今回Ver0.9用に作り直すにあたり、両方の方式を実装してみたけれど、トータル的に、手牌分割方式のほうが便利そう。
　ただ、Ver0.9用につくっている最中に発見したんだけど、Ver0.8では同じ手牌を何度も評価する無駄な処理があり、結構時間がかかってしまっている。私がVer0.8で採用しているアルゴリズムはあらさんのものより遅いのだが、どうもここの無駄な処理が原因だったようだ。てっきりハッシュ方式の向聴数チェックをしていないためだと思い込んでいた。

　ちなみに、麻雀ゲーム作ってるときはパターンが多くてテストが大変なんで、確実に動くが遅いバージョンと高速化バージョンの２パターン（以上）を実装してアウトプットが同じになるか比較して検証している。
そのため、オブジェクト指向型の言語で個々のパーツの入れ替えが簡単に効くように作ったほうが何かと便利だと思う。