❎ 📸 🚓 行く以上 🔀 🤚🏻 🤛🏾

水の中に小石を投げ、それらが形成する円を見てください。
そうでなければ、そのようなスローは空の楽しみになります。

コズマ・プルトコフ「瞑想の果実」

このゲームは本当に未完成の建物です。 6月に作業を開始しました。私は毎日破れたとは言えませんが、彼女は私に多くの血をだめにしました。今日、これはAxiomでの私の最も難しいプロジェクトです。（非常に重要な）コードに関しては、 MarGoはおそらくRhythm Machiaに匹敵します。

このゲームの特別なところは何ですか？彼女のためにそんなに苦しむことは価値がありましたか？私はあなたに言います、そしてあなたは判断します。

表面の類似性

「完璧な」 Guoの試みは繰り返し行われていますが、成功することはめったにありません。私の意見では、MarGoは非常にまれです！このゲームで魅了される主なものは、Go のセットの上にあるという事実です。一見シンプルなGoのルールが、予想外に複雑な戦術的構成にどのようにつながるかについてはすでに書きました。繰り返しはしませんが、Goについて書いたすべてがMarGoにも当てはまるとだけ言います（飛行機を超えない限り）。そのため、たとえば、有名な「ラッチ」は次のようになります-3つを取得するための1つの石の最も単純な犠牲者：

ところで、言う

上記の位置での「ラッチ」の使用は完全に冗長です！黒人はすでに運命にあります;それらを「食べる」必要はありません。しかし、なぜMarGoはこのような小さなボードを使用しているのでしょうか？主な理由は、ゲームが飛行機ではなく、ボリュームであるということです。プレイヤーはピラミッドを構築し、誰もが19x19ボードでこれを行う忍耐を持つことはほとんどありません。 MarGoの標準9x9ボードGoは、主に初心者のトレーニングに使用されます！

すでに9x9ボードを使用しているときに、メモリ不足の問題に遭遇したため、これは大きな安心でした。配列から余分な行を削除して、その使用を最適化する必要がありました。この点は非常に明白です。ピラミッドを構築すると、3次元ボードのほとんどのフィールドに図形を配置できません。

グループのステータスを決定するとき、ボードのプレーンにある空のアイテムのみが重要です。「生きている」グループの各石は、これらのポイントの少なくとも1つ（「ダメ」と呼ばれる）と接続されている必要があります（直接または他の石を介して）。最後のダムが閉じられるとすぐに、グループは死んでしまい、ボードから削除されます。

どのように機能しますか？

Go機能の基礎は、環境に落ちた石を除去するメカニズムです。とても簡単に機能します。そもそも、無条件に生きている石を識別する必要があります（ボード上の空のアイテムに隣接しています）。次に、「生きている」石のグループに、以前に追加した石に隣接するすべての石（同じ色の石）を追加する必要があります。

ZoG / Axiomでのムーブの実行の愚かなセマンティクスがなければ、すべてがうまくいくでしょう。移動の構築全体を通して、ボードの内容は計算が開始された時点と同じに見えます（移動によって行われたすべての変更は、その完了時にのみ表示されます）。簡単なケースでは、これと戦うことができますが、私たちのゲームは決して簡単ではありませんでした！ 3次元の錯覚を作成するという事実により、ボードに1つのピースだけを追加すると、多数のタイルフィギュアが移動する可能性があります。これらすべての「特殊なケース」を特別な方法で処理することは完全に非現実的です！ボードへの新しいピースの追加と、その後の「殺された」ピースの削除を分割する必要がありました。

{players {player} W {player} B {player} ?C {random} players} {turn-order {turn} W {of-type} normal {turn} ?C {for-player} W {of-type} clean {turn} B {of-type} normal {turn} ?C {for-player} B {of-type} clean turn-order}

「クリーニング」を自動的に実行するには、フィギュアの所有者に代わって行動する別のプレーヤーを作成する必要がありました。その動きは、ボードの未使用フィールドの1つに特別な（見えない）図形を配置することです（最適化にもかかわらず、そのようなフィールドは多数あります）。「死んだ」グループを削除するすべてのアクションは、この移動の「副作用」として実行されます。

 : drop-m ( -- ) here a1 = verify (   ? ) drop (   ) ['] my-enemy? (    ) init-alive (       ) proceed-alive (     ) capture-all (         ) captured-tiles @ 0= IF (       ) ['] my-friend? (        ) init-alive proceed-alive capture-all ENDIF add-move (    ) ;

このコードは、2つの問題を同時に解決します。

最後の移動で殺されたすべての敵グループを削除する
移動が自殺であり、敵を殺すことができない場合、友好グループの自殺

詳細

 TOTAL [] alive[] (    ) VARIABLE alive-count (    ) : not-alive? ( -- ? ) (    ) TRUE 0 BEGIN DUP alive-count @ < IF DUP alive[] @ here = IF SWAP DROP FALSE SWAP TRUE ELSE 1+ FALSE ENDIF ELSE TRUE ENDIF UNTIL DROP ; : add-alive ( -- ) (    ) not-alive? alive-count @ TOTAL < AND IF (    ! ) here alive-count @ alive[] ! alive-count ++ ENDIF ; : check-alive ( 'op 'dir -- ) (     ) EXECUTE IF EXECUTE IF add-alive ENDIF ELSE DROP ENDIF ; : init-alive ( 'op -- 'op ) (   ) 0 alive-count ! 0 BEGIN (       ! ) DUP empty-at? IF DUP to OVER ['] n check-alive DUP to OVER ['] s check-alive DUP to OVER ['] w check-alive DUP to OVER ['] e check-alive ENDIF 1+ DUP PLANE >= UNTIL DROP ; : proceed-alive ( 'op -- 'op ) (   ""  ) 0 BEGIN (     ) DUP alive-count @ < IF DUP alive[] @ to OVER ['] n check-alive DUP alive[] @ to OVER ['] s check-alive DUP alive[] @ to OVER ['] w check-alive DUP alive[] @ to OVER ['] e check-alive 1+ FALSE ELSE TRUE ENDIF UNTIL DROP ;

ボードのサイズが小さいために貴女の競争が激しくなります。 Goをプレイする人は、小さなボード（9x9）での戦いが標準的なボード（19x19）での戦いよりもはるかに激しいことを知っている必要があります。最初の動きから、プレイヤーは密接に接触し、「生と死」の問題を継続的に解決することを余儀なくされます。これはMarGoのゲームですが、もしそうなら、私はそれについて話さないでしょう。

主な違い

ゲームの名前は、「マーブル」（ボール）と「ゴー」の2つの単語で構成されています。一緒にそれが判明-「囲ballsボールをプレイ」。従来のゲームとの違いは何ですか？三次元で！ 3次元のボードでGoをプレイする試みは繰り返し行われています（任意のグラフでプレイできるプログラムについて書いています）が、これらのケースのほとんどで、ゲームのバランスがひどく苦しんでいました。おそらく、例外はダイヤモンド結晶格子を模倣したボードだけです。これは、古典的なフラットボードによく似ています。各ノードには2〜4個のネイバーがあります。

MarGoのアプローチはまったく異なります。ボールはただ「宙に浮かぶ」ことはできません。「ボードの上に立つ」ためには、彼は他の4つのボール（彼または彼の対戦相手）に頼らなければなりません。もちろん、このボールが生き続けるためには、少なくとも1つのダムにアクセスできるグループと接触している必要があります。ボードの平面にある直交ジョイントに垂直方向が追加され、ピラミッドの基部にあるボールを頂点で接続します。

この接続は両方の方法で機能します。ダムへのアクセスは、ピラミッドの「上部」に命を吹き込むだけでなく、ボードの平面に横たわっている敵の破片を包み込むように、さらに下の層に移動することもできます。これだけでもゲームをより面白くすることができますが、もう1つ、それほど明白でない点があります。ピラミッドの最上部にある石が「生きている」限り、その基部の石は「死んだ」グループに属していても取り除くことはできません！

そのような石は、女神へのアクセスを奪われ、異なる色の人物によって押しつぶされ、「ゾンビ」と呼ばれ、「殺された」グループの残りがそれを去るとき、ボードに残ります。ゾンビは捕獲された石と同等と見なされます（ボードから削除されます）が、ボードに残っている限り、他の石へのアクセスを「転送」できます（突然表示された場合）。さらに、ピラミッドの上部を削除することにより、ゾンビを蘇らせることができます。

3D侵略

3次元効果を作成するには、各図を4つのタイルに分割する必要があることを既に書きました。それは機能しますが、問題は、タイルの数字を非常に奇妙な方法で「立体」ボードに配置する必要があることです。これは避けられません。「上から」見えるすべてのタイルは同じ平面になければなりません。このレイアウトスキームには独自の利点がありますが、ナビゲーションは非常に複雑です。まず、瞑想のためにマンダラが必要でした。

 4 AA 3 8 8|9 9 2 5 5|6 6|7 7 1 1 1|2 2|3 3|4 4 + ABCDEFGH 1 1|5|8|AA|9|7|4 2 1|2 2|3 3|4 3 5|6 6|7 4 8|9

私は同意します、写真はまあまあですが、どうにかしてオリエンテーションをすることができました。このパターン内の自然な動きの方向性が必要でした。幸いなことに、Axiomの観点から見ると、方向とは、呼び出しの副作用として現在の位置の位置マーカーを変更する関数にすぎません（このような関数を呼び出すことの主な結果は、ブール値を返すことで、移動が成功したことを意味します）。一般に、方向は再定義でき、すぐに、それらの階層全体ができました。

この図は、厳密に「北」につながる関数のみを示しています（ある意味）。私はすでにそれらのいくつかを以前に使用しました。たとえば、方向 ' n 'は、メモリ使用量を最適化するために、ボードアレイから余分な行を捨てたときに入力する必要がありました。「ロケット科学」の主要な部分は、ボードの平面に平行な平面内を移動できる機能です。

私はそれにコメントしようとさえしません。

 : common-internal ( 'dir -- ? ) here is-plane? IF get-height SWAP EXECUTE IF get-height - DUP 0= IF DROP TRUE ELSE 0> IF FALSE ELSE BEGIN d NOT empty? OR UNTIL empty? IF u verify ENDIF TRUE ENDIF ENDIF ELSE DROP FALSE ENDIF ELSE here OVER EXECUTE NOT empty? OR IF to BEGIN u NOT UNTIL EXECUTE ELSE 2DROP TRUE ENDIF ENDIF ;

その後に発見されたエラーのほとんどは、この特定の機能に関連していました（そして、それらをすべて修正したかどうかはまだわかりません）。それに基づいて、北内部、南内部などの動きが構築されます。

 : north-internal ( -- ? ) ['] n common-internal ; : south-internal ( -- ? ) ['] s common-internal ; : west-internal ( -- ? ) ['] w common-internal ; : east-internal ( -- ? ) ['] e common-internal ;

これらはほぼ完全な移動機能であり、欠点は1つだけです。移動に失敗すると、現在の位置のマーカー位置は未定義になります。これは簡単に修正できます。何らかの理由で移動できなかった場合は、移動する前にマーカーの位置を記憶し、復元するだけで十分です。

 : wrap-direction ( 'dir -- ? ) here (   "" ) SWAP EXECUTE IF (      ) DROP TRUE (    ,    ) ELSE to FALSE (   ,  ""    ) ENDIF ; : north ( -- ? ) ['] north-internal wrap-direction ; : south ( -- ? ) ['] south-internal wrap-direction ; : west ( -- ? ) ['] west-internal wrap-direction ; : east ( -- ? ) ['] east-internal wrap-direction ;

少しだけ残っています。ボードの平面にある「水平」運動に加えて、1つの平面から別の平面に向かう方向（「上」および「下」）が必要です。

コメントのないさらに奇妙なコード

 : up-internal ( -- ? ) here is-plane? IF FALSE ELSE d NOT empty? OR IF BEGIN u NOT UNTIL ENDIF TRUE ENDIF ; : down-internal ( -- ? ) here is-plane? IF d NOT empty? OR IF FALSE ELSE BEGIN d NOT empty? OR UNTIL empty? IF u verify ENDIF TRUE ENDIF ELSE u verify here is-plane? NOT ENDIF ; : up ( -- ? ) ['] up-internal wrap-direction ; : down ( -- ? ) ['] down-internal wrap-direction ;

それだけです！これで、「接続された」グループの検出に必要な方向の完全なセットができました。

ゾンビは、ゲームのシンプルで論理的なルールによって生成される興味深い新しいエンティティです。興味深いが、それだけではありません！ MarGoには他にも驚きがあります。

橋と渓谷

ピラミッドの上部にある石は、周囲の可能性がある友好的な石へのアクセスを「送信」します。環境を回避する別の方法があります！しかし、これがまさに、Goを3次元でプレイすることがあまり面白くない理由です。グループを殺すのは難しいです！修正する方法があります。

Goでは、そのような接続は、それを構築したプレイヤーの起こりうる間違いに関係なく、基本的に切断されないと見なされます。近くに立っている石は生きて一緒に死にます。それらを分離することは不可能ですが、MarGoではできません！このゲームでは、立っている石の上に橋を架けることで、その石を「切る」ことができます。橋の反対側にある下の石は、2つのグループに分かれます。

橋を渡って

「切断」の本質は、選択した方向に移動できないことです。これは、上で書いた方向の階層を拡張する必要があることを意味し、他の人々の「頭の上」の人物から構築された「橋」の存在を制御する新しい方向を追加します。「ブリッジを切断する」というルールはオプションに非常に似ているため（ゲームはそれがなくても面白い場合があります）、操作を制御するフラグ定数を定義します。

 TRUE CONSTANT BRIDGE-CUTTING

その後、すべてが簡単です

 : is-covered? ( -- ? ) player up empty? NOT AND IF player <> ELSE DROP FALSE ENDIF ; : check-bridge? ( 'dir piece-type -- ? ) piece-type SWAP equal-types? IF here is-covered? IF SWAP OVER to EXECUTE IF is-covered? SWAP to ELSE to FALSE ENDIF ELSE to DROP FALSE ENDIF ELSE DROP FALSE ENDIF ; : common-cutting ( 'dir 'dir piece-type 'dir piece-type -- ? ) BRIDGE-CUTTING IF check-bridge? IF 2DROP TRUE ELSE check-bridge? ENDIF ELSE 2DROP 2DROP FALSE ENDIF IF DROP FALSE ELSE EXECUTE ENDIF ; : north-cutting ( -- ) ['] north ['] east nw-piece ['] west ne-piece common-cutting ; : south-cutting ( -- ) ['] south ['] east sw-piece ['] west se-piece common-cutting ; : west-cutting ( -- ) ['] west ['] south nw-piece ['] north sw-piece common-cutting ; : east-cutting ( -- ) ['] east ['] south ne-piece ['] north se-piece common-cutting ;

チェックブリッジにはすべての魔法が隠されていますか？ 。頭の上にある「橋」を特定するには、誰かのタイルを探して「見上げ」ます。隣接するタイルでも同じことを行います。両方のタイルが別の色（異なる）で「覆われている」場合、対応する方向を「切り刻み」、返された値を偽の値に置き換えます。

これは驚きが終わった場所だと思いますか？どんなに！

最も難しいケース

自殺の動きは禁止されています（そしてほとんど役に立たない）。プレーヤーは、相手の石を1つも受け取らないと、「環境に」石を置くことができません。 Goでは、これは簡単です。特定の石のグループを取得する場合、新しく追加された石と接触している必要があり、その「殺害」は生き残るために必要なダムを開きます。しかし、MarGoにはゾンビがいます！

ピラミッドの頂上で石をとっても、白い石は依然として「囲まれ」、それによって受け入れられない位置を作り出します！ 2つの黒い石は、その基部にある「ゾンビ」によって保護された「仮想グループ」を構成します。この防御が非常に短命であることは面白い。白人が何らかの理由で彼に隣接する4つの石のいずれかを奪うと、「仮想グループ」の保護は無効になります。これは単なる人工構造ではありません。仮想グループは、MarGo！の重要な戦術コンポーネントです。たとえば、このポジションのステータスについてどう思いますか？

それは完全に囲まれたグループ（1つの「目」）のように見え、白を食べ始めました。原理的にはそうですが、黒人のグループを「仕上げる」ことはそれほど簡単ではありません。白は、左下隅だけに行くことはできません。 2つの白い石が「ゾンビ」のみを囲むため、このような動きは自殺と見なされます。しかし、黒は侵入する白い石を食べるために急いではいけません：

ブラックは「ゾンビ」ではない石をボードに追加し、それによって「仮想グループ」の保護を破壊します。ホワイトは、彼が食べたばかりの石と同じポイントに行く権利を取得し、5つの黒い石を取ります。黒の最善の解決策は何もしないことです。もちろん、そうではありません。ホワイトにはグループを殺す別の機会があります。

黒人がこの脅威を無視すると、彼のグループは運命づけられます！彼らのグループをつなぐことにより、白人プレイヤーは最後の名誉を安全に取ることができます。このような侵入に対する防御は明らかです。相手の最高の動きはあなたの最高の動きです！

本当に難しい

上記で書いたように、プレーヤーに石を追加し、「デッド」グループを削除すると、2つの連続した動きに分割する必要がありました（そうでなければ、すべてが非常に困難でした）。他の不便さの中でも、これは単にプレイヤーが「自殺的」であるという理由だけで、プレイヤーに動きを禁じることができないことを意味します。原則として、これはそれほど大きな問題ではありません。移動して、追加された石を単純に死なせてみましょう（独自の色の他の石のグループを使用して）が、これは問題の一部にすぎません！このコードのようなものを書いたことを覚えていますか？

 : drop-m ( -- ) here a1 = verify drop ['] my-enemy? init-alive proceed-alive check-zombies capture-all captured-tiles @ 0= IF ['] my-friend? init-alive proceed-alive check-zombies capture-all captured-tiles @ NEGATE update-variables ELSE captured-tiles @ update-variables ENDIF add-move ;

敵の石を取り除こうとしていますが、これが成功しなかった場合は、自分の石を取り除こうとしています（取り込んだ石を同時に数えます）。そのため、このコードは機能しません！実際、トリッキーなケースを見ると、相手の石が取り除かれていることがわかりますが、追加された石はまだ囲まれたままです！これは本当に問題です。すべてが適切に機能するためには、敵の死んだ石を取り除き、それから私たちのものを取り除き、可能であれば敵の石を元の場所に戻さなければなりません。はい。Axiomには、ボードのコピーを作成し、変更を加え、すべてをロールバックできる機能がありますが、ここでは使用しません。幸いなことに、別の適切に機能する変更ロールバックメカニズムがあります。

デッドグループ削除コードを2つの部分に分割する

 {players {player} W {player} B {player} ?C {random} players} {turn-order {turn} W {of-type} high-priority {turn} ?C {for-player} W {turn} B {of-type} high-priority {turn} ?C {for-player} B turn-order} {move-priorities {move-priority} normal-priority {move-priority} low-priority move-priorities} {moves w-drop {move} drop-w {move-type} high-priority {move} drop-nw {move-type} high-priority moves} {moves n-drop {move} drop-n {move-type} high-priority {move} drop-ne {move-type} high-priority moves} {moves e-drop {move} drop-e {move-type} high-priority {move} drop-se {move-type} high-priority moves} {moves s-drop {move} drop-s {move-type} high-priority {move} drop-sw {move-type} high-priority moves} {moves m-drop {move} clear-e {move-type} normal-priority {move} clear-f {move-type} low-priority moves} {pieces {piece} M {drops} m-drop {piece} tw {drops} w-drop {piece} zw {piece} ww {piece} bw {piece} tn {drops} n-drop {piece} zn {piece} wn {piece} bn {piece} te {drops} e-drop {piece} ze {piece} we {piece} be {piece} ts {drops} s-drop {piece} zs {piece} ws {piece} bs pieces}

優先度が高い（通常）場合、コードは敵のデッドグループ（clear-e）を削除し、低い（ low ）-デッドグループを削除します（高レベル、優先リスト外、通常のボードへの石の追加のために予約します）。これですべてが正常に機能するようになりました。まず、ムーブジェネレーターは優先度の高いclear-eを実行しようとし、最後に追加された石が環境に入ったかどうかを確認します（これが発生した場合、ムーブを禁止します）。優先移動がチェックの1つに失敗した場合、移動ジェネレーターはすべての変更をロールバックし、低優先度clear-fを満たします。このコードは常に成功します。実装の副作用として、「自殺」グループが削除されることがあります。

クリーンアップコードも複雑です

 : clear-e ( -- ) 0 captured-count ! here a1 = verify drop ['] my-enemy? init-alive proceed-alive check-zombies capture-all captured-tiles @ 0> verify captured-tiles @ update-variables ['] my-friend? init-alive proceed-alive check-zombies check-not-captured add-move ; : clear-f ( -- ) 0 captured-count ! here a1 = verify drop ['] my-friend? init-alive proceed-alive check-zombies capture-all captured-tiles @ 0> IF captured-tiles @ NEGATE update-variables ELSE DROP ENDIF add-move ;

一般に、少し混乱しますが、動作します。

コノゴなし

さて、もう1つの難しいケースがあります。これは、より伝統的なバージョンのゲームから継承されたものです。すでに述べたように、ボードの面ではGoのすべてのルールが有効なままなので、次のトリックを実行することは非常に可能です。

どうにかこの楽しさをすべて壊さなければ、プレイヤーはお互いの石を無期限に食い尽くす機会を得るでしょう。もちろん、MarGoはこれを許可できず、前の位置の繰り返しにつながる動きを禁止します。ゲームのルールでは、私たちは状況のスーパーコについて話しています。

黒人はすぐに白い石を食べることができず、ボードの別の部分に歩かされます。次は、白が接続できます。

見えない人生

悲しいかな、私は位置的または状況的スーパーコの検出を実現できません。これには以前の位置に関する情報（少なくともハッシュ）が必要ですが、私にはありません！幸いなことに、これらすべての「周期的な子」、「永遠の命」、および他の異国的な地位は天気を悪化させません。実際のKoファイトでは、ほとんどの場合、単純なKoが表示されます。彼を捕まえます。

「空」ポイントへの移動を禁止するには、空にしないようにする必要があります

 : drop-marks ( -- ) 0 BEGIN DUP captured-count @ < IF mark OVER captured[] @ create-piece-type-at 1+ FALSE ELSE TRUE ENDIF UNTIL DROP ; : clear-marks ( -- ) 0 BEGIN DUP empty-at? NOT IF DUP piece-type-at mark = IF DUP capture-at ENDIF ENDIF 1+ DUP PLANE >= UNTIL DROP ;

非表示のタイルをボードに配置して、選択した位置に移動できないようにすることができます。許可されたポイントへの移動を実行する場合、これらの干渉を単に除去します。ここでは、MarGoの重要な特性の1つが私たちの手に渡っています。共同戦闘は常にボードのベースの平面で発生します！追加された「空の」タイルがグループのステータスの決定に干渉しないように、ノードの無効を決定する関数を変更します。

 : my-empty-at? ( pos -- ? ) DUP curr-pos ! - empty-at? IF + DUP empty-at? SWAP piece-type-at mark = OR IF TRUE ELSE ... ENDIF ;

ボードに共同マーキングを追加することは残っています。敵の除去された石の代わりにこれを行います。この石が除去されなかった場合、「自己破壊された」グループは新しく追加されたちょうど1つの石で構成されます。複雑に聞こえますか？一般的には、そうです。

背後には何がありますか？

もちろん、すべてが順調に進んだわけではありません。いくつかのルールを実装できませんでした。たとえば、MarGoでの自殺行為は絶対に禁止されています。これは、プレーヤーがこの動きで敵の石を受け取らない限り、最後のダムのグループ（おそらく追加されたばかりの1つの石だけで構成される）を奪う動きをする権利がないことを意味します。

私は石を追加する動きと取られた石を取り除く動きを分離せざるを得ず、「自殺」の動きを禁止する可能性を奪われました。これは些細なことのように思えるかもしれません。最終的に、Go ルールのほとんどのバリエーションでは「自殺的」な動きは禁止されていますが、Ingaルールでは許可されています。これには十分な理由があります。自分のグループを殺すと、プレイヤーが完全に絶望的な状況で脱出できる（非常にまれな）ポジションがあります。

関はポイントを獲得しませんが、グループの完全な損失と比較すると、敵もポイントを獲得できないため、これは深刻な助けです！残念ながら、一方が他方を引っ張ります。（Goとは異なり）MarGoでは、プレイヤーは移動をスキップできません。しかし、一度絶望的な状況に陥った場合、プレーヤーはほとんどの場合、新しく追加された石の自殺につながる動きをすることができます。パスでない場合、これは何ですか？これも禁止できません

いずれにせよ、これらの違いはそれほど重要ではないので心配する価値がありました。 AIははるかに悪い。現在の実装では、単に存在しません！このアプリケーションは、2人でプレイしたり、スケッチを分析したりするための「インテリジェントな」ボードとして使用できますが、それで遊ぶことはできません。 Go for AIの複雑さでさえありません（ZoG開発者はDLLエンジンを使用する必要があり、あまりうまく機能しません）。 AIについて考える前に、少なくともスコアリングロジックを実装する必要があります。

囲gameゲームの目標は、敵の石を「食い尽くす」ことではなく（最後までカウントされますが）、領土を占領することです（これが中国のルールとどのように異なるかについて、私はここに書きました））プレイヤーの領土はすべて空のポイントと見なされ、自分の色の部分にのみ到達できます。 MarGoはこの概念を拡張します。ボードの平面にある領土の伝統的なポイントに、4つの色の石で構成される「サイト」にポイントが追加されます。考えてみると、これも領土です。これらのポイントでは、石を置くことができ、それらから自分の石だけに「取得」できます。私はそのようなアイテムが名誉ではないことを強調します！ライフグループは、ボードの平面にある無料のアイテムのみを提供します。

このように定義された領域を数えることは複雑ですが、かなり解決可能です。残念ながら、これはこれに限定されません。 MarGoは、プレイヤーが「潜在的に」埋めることができるポイントを領土に追加します。たとえば、プレイヤーが自分の色の16ピースで構成される4x4の正方形を持っている場合、彼の「サイト」に4つの石を配置することができます（別の石のために新しい領域を形成します）。さらに、最初の4x4正方形が塗りつぶされていない場合、その内部ポイントもテリトリーに追加されます。これはすべて理にかなっているように思えますが、これまでのところ、ForthScriptでこのようなタスクに取り組むことさえ恐れています。

捕獲された石を数えることも難しい仕事です。もちろん、ゲーム中にキャプチャされた石に加えて、「ゾンビ」が追加されます（大丈夫、あなたはそれらを数えることができます）。。通常、スコアリングの前に、プレイヤーは「デッド」グループを手動で削除する機会が与えられますが、ZoGではこれはまだ挑戦です！

これらの問題をすべて解決できたとしても、このゲームに少なくとも何らかの形で強力なAIを実装できるというわけではありません。おそらく試してみる価値はありますが

行く以上