差分表示


最適な発火のタイミングを検討する.
//parent=連鎖アルゴリズムの設計

発火のタイミングを改良して,
[[階段積み2>アルゴリズム(KaidanTumi2)]]以降で導入している「危機」の概念を置き換えることをもくろんでいる.

#contents
----

* 検討編
** (1) 基本原則
発火のタイミングは,戦略(*1)によって考え方が変わるが,とりあえず簡単のために以下の原則を採用する.~
(*1)具体的には,先打ち潰し,先打ち発火催促,後打ち本線,単なるゴミ処理などの種類.

- (A) 可能な限り大きい連鎖を発火すること
- (B) 自分が窒息してはならない

AとBの両方を満たすように考える.発火するなら,とにかく大きいのを発火してやろうということ.

窒息には,以下の2種類の過程がある.
:自分の積みによる窒息:単なる積みすぎ
:相手からのオジャマによる窒息:オジャマで埋められる状況

両方の組み合わせも考えられるが,その時は片方(より危険な方)を考慮することになる.

それぞれについて,以下で検討する.

** (2) 自分の積みによる窒息
考慮すべき要素は,以下の通り.
- 自フィールドの空き領域サイズ
- 現在存在する発火候補点のうち,最大の連鎖数である点が要求する色とその個数
- ツモ予告(NEXT〜NEXT3)に存在する色

これらを用いて,
+ 自フィールドが埋まる前に最大の連鎖を発火する
+ もし埋まる前に発火できないなら,2番目以降の連鎖を発火する

積んでいくうちに,成り行きで連鎖が伸びる可能性があるが,この状況は,特に意識しなくても良い.(多分.何となく) -->あとで詳細な検討要


** (3) 相手からのオジャマによる窒息
考慮すべき要素は,以下の通り.
- 相手の連鎖が終了するまでに,自分が引くことのできるツモ数
- 相手の攻撃力.相手の連鎖終了&相殺後に,自分が受ける予定のオジャマ数

これらを用いて考えるべきことは,
+ 相手が攻撃中であっても相殺しきれずにこっちに降らないなら,無視して良い.
+ 相手の連鎖が終了するまでに引くことのできるツモ数で,オジャマが降ってくるまでに発火できる最大の連鎖を発火する

----
* 実装編
具体的な実装仕様について記述する.

** 危険度
「発火する必要があるかどうか」を示す指標として,"危険度"を導入する.

そして,各危険度における発火ルールを,以下のように定める.
,''危険度'',''発火する手の選定基準''
,Normal,発火しない
,Red 3,NEXT〜''NEXT3''まで視野に入れた最大連鎖で発火する
,Red 2,NEXT〜''NEXT2''まで視野に入れた最大連鎖で発火する
,Red 1,''NEXT''による最大連鎖で発火する

例えばRed 2の場合,着目している手(NEXT)で発火すれば7連鎖が発動するとしても,NEXT2で発火すると8連鎖以上になる手がもし他に''1手以上存在するならば,その手では発火しない''.

さらに,Red 3の場合は,8連鎖以上になる手がNEXT3で見つかった場合も,発火しない.

要は,危険度が低いなら先のツモを待てるが,危険度が高いなら先のツモまで待てませんということ.

** 危険度の決定

*** 危険度の決定(1) 〜自フィールドの考慮〜
今,自フィールドがどのような状況かを判断して,発火するタイミングを決める.
[[RensaYomi6>アルゴリズム(RensaYomi6)]]で導入したもの.

#img(http://kamoland.com/wiki/image/hakka_01.png,l)
左図の色分けで,自フィールドの埋まり具合を評価する.

赤くなっている箇所に玉があれば,その箇所の危険度であるとする.
#img(,c)

''危険度=Red2の例''
#img(http://kamoland.com/wiki/image/hakka_02.png,l)
#img(,c)

*** 危険度の決定(2) 〜相手フィールドの考慮〜
これは,相手の連鎖によって埋められることを防ぎつつ,できるだけ自分の連鎖は伸ばす,ということを実現しようとしたものである.
[[RensaYomi7>アルゴリズム(RensaYomi7)]]で導入した.

相手のフィールドで連鎖が発動している場合,その連鎖があと何連鎖続くかによって危険度を決定する.

続く連鎖数が少ない場合,オジャマが降ってくるまでの時間に余裕がないので,急いで発火する必要がある(Red1)が,逆に連鎖数が多い場合は,発火するまで余裕があるので,できるだけ発火を延長しても構わない(Red3).

,''相手の残り連鎖数'',''危険度''
,相手は連鎖中ではない,Normal
,1〜3連鎖,Red1
,4〜5連鎖,Red2
,6連鎖以上,Red3

この表の連鎖数の値に,理論的な根拠はありません.だいたいこんなもんかな,という経験値です.

*** 危険度の決定(2-追加) 〜相手のオジャマ予告の考慮〜
(2)で相手の連鎖数を考慮したが,相手の連鎖が相殺目的のものである可能性を考える必要がある.

相手に残っているオジャマ予告の数と相手が発動している連鎖の総得点を比較し,
もし
-オジャマ予告 > 相手の連鎖の総得点

である場合は,自フィールドには何の影響も与えない(オジャマは降ってこない).
この場合,残り連鎖数に関係なく危険度=Normalの扱いとする.

この処理(相手のオジャマ予告の考慮)は,RensaYomi4系の
[[RensaYomi4-5>アルゴリズム(RensaYomi4-5)]]で導入した.
RensaYomi7系では未実装.
(厳密にはRensaYomi4系には危険度の概念はないが,発火タイミングの制御で考慮するようにしたという程度の意味)

これにより,発火タイミングの精度が向上し,無意味な発火を行うことが少なくなった.

*** 最終的な危険度の決定
危険度の決定(1)(2)の結果のうち,より危険な方を採用する.


** 深読みにおける危険度の考慮
評価関数で使用する最大連鎖数の求め方は,危険度によって切り替える.
危険な場合は目の前のツモのみで判断するが,余裕がある場合は先のツモも見越して判断するというイメージである.

NEXT〜NEXT3で発火したときの最大連鎖数を求めるために,最大3手の[[深読み]]を実施する.

この深読みで使用する発火候補点の条件は,以下の通りとする.
- ''k個''以上連結している 
- 上右左のいずれかが空白である (積みの到達可能位置である) 

そしてkは下表の通りとする.なお,表で「-」が入っている箇所は,読みを行わない組み合わせである.
,''危険度,k(NEXTに適用)'',''k(NEXT2に適用)'',''k(NEXT3に適用)''
,Normal,3,3,-
,Red 3,4,&color(red){''3''};,&color(red){''3''};
,Red 2,4,4,-
,Red 1,4,4,-

このkにあまり根拠はなく,試行錯誤の結果です.

この表で4が入っている箇所は,私が「現実的読み」と呼んでいるもので,3が入っているのは「楽観的読み」になります.

危機に陥った時に確実に発火するためには,目に見えるツモのみを使って現実に発火しうる連鎖を考える必要があるため,現実的読みを使うのが正しいような気はするのですが,&color(red){''太字''};で示した箇所は楽観的読みになっています.

しかしこれには理由があって...これらを現実的読み(4)にしてしまうと,
例えば青発火の7連鎖ができている状態でNormal→Red3に移行したとして,
その時たまたまNEXT〜NEXT3に青がない状態だと,7連鎖の仕掛けはまったく無視されて
平気で発火点が埋められる,という現象が頻発したのである.

NEXT〜NEXT3には発火色はないけど,まだもう少しだけ夢を追いかけよう,という意味合いだろうか.

----
* その他の話題
** カウンター発火
従来は,オジャマを食らって予告が表示されると,とにかく発火せねばと考えてひたすら消しにかかっていた.
しかし,オジャマの落下を防ぐための単発消しよりも,オジャマをあえて食らってその後に発火した方が良い場合があり得る.
(カウンターなど)

そこで[[Sniperロジック>アルゴリズム(Sniper)]]では,オジャマが落下後のフィールド状態も評価に組み込んで,そういう発火も行えるようにした.

オジャマ予告が表示されている場合は,オジャマ落下後をシミュレートしたフィールドを用いてNEXT2の評価を行うようにした.
この結果NEXT2で好手ありと判断できた場合は,NEXTで焦って行おうとしていた発火を取りやめることで,NEXTを積み後にオジャマ落下→NEXT2でその好手を積む,という流れになるようにする.

注意点として,オジャマの落下位置はランダムに決まるので,正確にはシミュレートできないということがあげられる.

----

* 今後の課題
** 追い打ち発火
もし相手のフィールドがある程度埋まっているなら,小さい連鎖であっても発火すれば良い.
無理に時間をかけて大連鎖を作り,相手の掘り起こし,反撃の余地を与えるべきではない.

**ゴミ処理の発火
フィールドに残すことで悪影響を及ぼすツモの場合,1連鎖を発火してゴミとして消すことが考えられる.
ゴミが残ると,長連や同時消しを誘発して,連鎖数を増やす支障になる可能性がある.

...しかし,「ゴミとは何か?」という判断が難しい.
今後の展開によって,ゴミがゴミでなくなることもあり得るだろうし.


© 2020 KMIソフトウェア