青天井ルールのお話し。

  • トゥィッターで言及(トゥィート)
  • パウーで共有
  • はてなブックマークに登録
  • フェイスブックで共有
  • タンブラーで共有
  • ラインで送る

麻雀に於いて、満貫の概念がない青天井ルールについて、プログラマの立場からお話しします。

青天井ルールとは?

麻雀に於ける青天井ルールとは、満貫の概念がないルールの事です。

通常、場に両翻が付くリーチ麻雀の場合、散家和了時の散家一人分の点数が二千点を越えると満貫とみなし、これ以上の点数にはしない事としております。

  • 但し、散家一人分の点数が千九百二十点(三十符六翻)でも、便宜上満貫とする場合が多いようです。これは、散家の摸和時に散家の払い分が満貫と同じ二千点となる事から区別する意味が無いと判断されたものと考えられます。

青天井ルールでは、二千点を越えようが何億点になろうが(実際には億どころではない場合もある)点数を一翻毎に倍にするルールです。

青天井ルールの細則。

青天井ルール自体がローカルルールの範疇なので、細則は場所に拠って異なります。

役満貫とされる役の扱い

大きく分けて、以下の二種があるようです。

例外的に満貫とする

具体的には、例えば散家和了時の散家一人分の点数を二百五十万点に固定し、他の役は加味しないものです。

役満貫が重複する場合は、成立した役満貫の数だけ増えます。

具体的な翻数を与える

多くの場合十五翻とするようですが、最近では数え役満の概念もあって十三翻とする場合も多いようです。

この場合、二つの問題が生じるため、それらについても明確にする必要があります。

一つは他の役の重複をどう扱うかと言う問題です。

大きく分けて、以下の二つが考えられます。

必然的に重複する役は加算しない

例えば、清老頭, 四暗刻或いは四槓子は必ず対々和の形になるので、対々和は付けないと言うものです。

四喜和は字一色にもなり、必ずしも混一色にはならないので混一色になれば加算されます。

緑一色は緑発無しを認めないルールでは必ず混一色になるので混一色は付けませんが、緑発なしでも成立するルールでは必ずしも混一色とは限らないので、混一色か清一色のどちらかが加算されます。

天和と人和には門前摸和が必ず付くため加算されません。

概念的に下位となる役は重複させない

例えば、清老頭の下位役となる純全帯幺や混老頭は加算せず、清老頭の概念(手が全部老頭牌)と無関係の対々和は加算を認めると言うものです。

同様に四暗刻や四槓子にも対々和が付く事となります。

四喜和は字一色にもなり、必ずしも混一色にはならないので混一色になれば加算されます。

緑一色は概念的に混一色や清一色の上位役と見なせるため、混一色も清一色も加算しません。

天和と人和はそれぞれ荘家の配牌十四枚での和了散家の第一摸牌での和了となり、門前摸和とは別の概念であるため加算されます。

もう一つの問題として、国士無双の扱いもあります。

国士無双も七対子同様符の概念を適用出来ないため、便宜上三十符とするのが一般的なようです。

蛇足:準青天井ルール。

平成一桁の頃、ある麻雀劇画誌に連載されていたマイナーなギャグマンガに、準青天井ルールと言うのがありました。

準青天井ルールとは、従来数満貫は十五翻で最大(四倍満貫)となるのを、更に両翻加わる毎に無制限に満貫を加算すると言うルールです。

つまり、十七翻で五倍満貫、十九翻で六倍満貫となります。

但し、役満貫は通常通り四倍満貫となります。

  • この辺りは高点法の原則を考慮するとおかしな気もします。役満貫は十三翻役扱いなどとしてやれば良かったのではないでしょうか。

件の漫画でこのルールが採用される場合、概ね"超"が付くくらいの"どインフレルール"が併用されました。

出自が余りにもマイナーだったせいか、今日でも準青天井ルールは余り知られておりませんが、青天井ならこちらの方が遙かに実践し易いものです。

コンピュータ麻雀に青天井ルールを実装する際の問題点。

コンピュータ麻雀に青天井ルールを実装しようとすると、幾つかの問題にぶつかります。

変数や演算の精度の問題。

  • この項目は読者にプログラミングの知識がある事を前提とします。

先ず第一に、点数計算やスコア管理を行う変数及び点数計算の精度の問題があります。

しらぎく麻雀の場合、フラッシュ上で動作するアクションスクリプト 1.0/2.0を用いてプログラムを行う事となりますが、アクションスクリプト 1.0/2.0での整数演算の精度は32ビットとなります。

従って、32ビットを超える場合は浮動小数点演算となります。

しかし、浮動小数点演算も当然精度の問題があり、値が大きくなると下の桁の値が不正確になってしまいます。

ちなみに、アクションスクリプト 1.0/2.0の場合、240くらいまでは問題なく扱えるようです。

しかし、ドラなどがあるリーチ麻雀では四十翻を越える事例はいくらでも想定出来ますし、更に符自体が 2ビットから 4ビットまであるので(符は十点単位で扱う事でビット数を節約する)、せいぜい三十六翻くらいまでしか扱えない事となります。

結局、青天井とは言いつつも、かなり高いところとは言え上限を設けざるを得なくなります

  • ウルトラCとして、複数の変数を組み合わせる方法も考えられます。C言語など細かい処理が書ける言語でなら、実現はそれ程難しくはないでしょう。

実際、青天井対応を謳っているコンピュータ麻雀の中には、青天井とは言いつつも実際に起こる確率が極めて低いところ(数十億点単位)で打ち切るようにしている作品もあります。

持点表示の問題。

当たり前ですが、青天井で巨大な数値になった場合、それをどう表示させるかも問題になります。

桁の数が増えると、レイアウト上表示が困難になる事も充分予想出来ます。

加えて、桁数が増えると、プレイヤが一目で理解する事が困難になるため、1,234,567,890,100点 などと三桁毎にカンマを加えたり、1兆2345億6789万0100点 などと文字を加えるなどする必要があり、そうすると表示領域はますます大きくなってしまいます。

考えられる方策としては、普段は 123万点 1024億点 などと概数で表示するものです。

  • 正確な点数も分かるようにするには、表示箇所をポイントすると正確な数値がポップアップするようにすれば良いでしょう。

本記事を書いた契機。

制作者はポンリーを実験的に実装する事としました。

ポンリーの点数計算は青天井となります。

このため、ポンリーを実装するに際して、上記の問題に直面する事となりました。

結局、

事で解決させました。

実はポンリーの実装の際に問題点を一通り出し切ったので、リーチ麻雀でも青天井が撰べるようにしようかと検討しております。