今日、Zillions of Gamesで使用されているZRFゲーム記述言語の可能性についての話を続けたいと思います。 シリーズの以前の記事で、作品の動きがどのように記述されるかを示しましたが、考えられていない動きの別の重要なバリエーションがあります。 ボード上のピースを移動する（対戦相手のピースを取得する可能性がある）ことに加えて、プレーヤーは（許可されている場合）フィールドに新しいピースを追加できます。 この種の動きはドロップと呼ばれます 。
さらに、本日の記事では、ZoGでランダムな動きがどのように生成されるかについて説明します。 この機能は、たとえば、サイコロを使用してゲームを実装し、 LudoやChaturangaなどの動きを完了する場合に必要です。
例として、古典的なチェスに基づいて、 バトルvsチェスストーリーキャンペーンのミッションの1つに基づいてゲームを実現することを提案します。 キャンペーンのほとんどのミッションは、変更されたルールに従ってプレイされます。 ミッションの複雑さはさまざまで、勝つにはクイーンズでポーンを保持するだけで十分で、限られた数の動きをチェックメイトするだけで十分です。 私は、無秩序のポイントと呼ばれるカオスキャンペーンの4番目のミッションを検討することを提案します。
このミッションでは、取締役会の中心分野の一部が「採掘」されます。 そのようなフィールドで停止した図は（鉱山とともに）消えます。 同時に、「地雷」は黒人のためにプレーしているプレイヤーにのみ表示されます。 Belykhでプレイしているコンピューターは、彼が通常のルールでプレイしていると「考えている」ため、自分の作品を「採掘された」位置に誘い込むことができます。 私は、ほとんどのキャンペーンミッションで同様のアプローチが使用されていると言わなければなりません。 それらのプレーヤーの1人に不完全な情報があります。 場合によっては（たとえば、検討中のミッションで）、これは一種の「ハンディキャップ」であり、それほど強くないチェスプレーヤーでさえ、バトルvsチェスで使用されるかなり強いチェス「エンジン」に勝つことができます。
もちろん、記載されている形式では、ZoGでゲームを実装することはできません。 汎用性があるため、ZoGゲームコアは、移動の実行時に地雷の存在を考慮します。 「採掘された」セルへの移動は、数字の損失につながるため、明らかに有益ではありません。 フィギュアの損失を考慮に入れて、「地雷」の爆発が利益を上げるようにルールを変更してみましょう。
爆発中に、採掘されたセルの上に立っている人物だけでなく、その隣にあるすべての人物も失われたとします。 また、ゲームをより組み合わせやすくするために、オリジナルに近い地雷を爆発させ、それらに近い地雷をフィールドから除去します。 これはいくつかの技術的な問題が原因であるため、爆発の連鎖をこれ以上配信しません。 さらに、ボード上にあるほとんどのピースの「鉱山」チェーンが弱体化する可能性があるため、ゲームにチャンスの要素が多くかかりすぎて、面白くないかもしれません。
ZoGパッケージに含まれる従来のチェス（ Chess.zrf ）の記述を基礎として開発を開始します。 それから、チェス盤の説明とチェスの駒の動きを取ります。 「爆弾」に適したグラフィックリソースは、たとえば、ゲームボンバロットから取得できます。
爆風から始めましょう。
(define bomb-capture (if (not (piece? Bomb $1)) (capture $1) ) ) (define check-bomb-direction mark $1 (if (piece? Bomb) (bomb-capture n) (bomb-capture nw) (bomb-capture s) (bomb-capture sw) (bomb-capture e) (bomb-capture ne) (bomb-capture w) (bomb-capture se) ) capture back ) (define check-bomb (if (piece? Bomb) (check-bomb-direction n) (check-bomb-direction nw) (check-bomb-direction s) (check-bomb-direction sw) (check-bomb-direction e) (check-bomb-direction ne) (check-bomb-direction w) (check-bomb-direction se) capture ) )
ここではすべてがおなじみです。 図が爆弾の上に立っていた場合、私たちは周りのすべてを爆発させます。 別の爆弾が近くにあった場合、私たちもそれを爆発させます（その隣人には触れません）。 使用方法は次のとおりです。
(define leap1 ($1 (verify not-friend?) + (check-bomb) add ) )
各移動を完了する前にマクロを追加してください。 さて、王に自殺でゲームを終わらせましょう：
+(define check_safe + (verify (not (piece? Bomb) ) ) +) (define king-shift ($1 + (check_safe) (verify not-friend?) (set-attribute never-moved? false) add ) )
ここでは、爆弾の上に立っていないことを具体的に確認するため、 check-bombマクロを省略できます。
爆弾を配置する
+(define drop-bomb + ( (verify (and empty? (empty? n) (empty? s) (empty? w) (empty? e) ) ) + add + ) +) (game (title "Chess") ... - (players White Black) + (players White Black ?Init) - (turn-order White Black) + (turn-order ?Init ?Init White Black) (board (Board-Definitions)) (board-setup + (?Init + (Bomb off 8) + ) (White (Pawn a2 b2 c2 d2 e2 f2 g2 h2) (Knight b1 g1) (Bishop c1 f1) (Rook a1 h1) (Queen d1) (King e1) ) (Black (Pawn a7 b7 c7 d7 e7 f7 g7 h7) (Knight b8 g8) (Bishop c8 f8) (Rook a8 h8) (Queen d8) (King e8) ) ) + (piece + (name Bomb) + (image ?Init "images\Bombalot\BlackBomb.bmp" "images\Bombalot\BlackBomb.bmp") + (drops + (drop-bomb) + ) + ) ... )
Initという名前の3番目のプレーヤーが追加されたことにお気づきかもしれません 。 プレーヤーの名前の先頭にある疑問符は、彼がランダムな動きをすることを意味します（許可されていることに従って）。 さらに、このプレーヤーはプレーヤーのリストに表示されません（これは、彼のためにプレーすることが不可能になることを意味します）。 新しいプレイヤーは、ホワイトの移動の前に毎回2回移動します。 彼はどんな動きができますか？
ボードのセットアップで、彼は8個の爆弾を与えられ、それをフィールドに置くことができました。 この説明のoffキーワードに注意を払いたいです。 これは、フィールドでのリセットに使用できる数値を説明する方法です。 空のボードで始まるゲームの数字は、たとえばTic-Tac-Toeの実装でも説明されています。
爆弾の図の説明では、移動の1つのバリエーションのみが許可されています-垂直および水平に隣接するフィールドも空であるという条件で、図を空のボードフィールドにリセットします。 爆弾は他の人物（爆弾を含む）の対角線上に隣接している可能性があり、これは私の意見ではゲームをより面白くしています。
ご注意
ボードのグラフィックリソースとすべての図形が2回記述されていることに気付くかもしれません。 このアプローチにより、ゲーム中に切り替えることができるいくつかのデザインオプションを使用できます。 爆弾はすべての場合で同じように見えるため、同じファイルへのパスを2回指定するだけです。
表面的な変更を2、3するだけです。 ゲームの説明に次のオプションを追加します。
(option "pass turn" forced) (option "animate captures" false)
最初のルールは、プレーヤー（ ？Init ）がルールに従って移動できない場合、移動をスキップできることを意味します（このオプションを有効にしない場合、ゲームは終了できます？Initが爆弾を投下する場所を見つけられない場合） 。 2番目はシェイプテイキングアニメーションを無効にします（不自然に見えました）。 Zillions of Gamesのドキュメントで利用可能なすべてのオプションのリストを参照してください。
ゲームの準備ができました 。 あなたはそれがどのように見えるか見ることができます：
一般的に、ZoGは新しいルールに従って非常に適切に動作すると言うことができますが、時々その動きは私を混乱させます。 たとえば、彼は孤独な爆弾で女王を弱体化させます。 説明できません。 どうやらZoGコアは、爆弾がそのような女王との「交換」が有益になるほど危険な数字であると考えています。
次のビデオで見ることができる別の興味深い効果を見つけました（白い王は手動で3番目の水平に移動しました）：
王の過程で野原を強調することで、敵の人物がそれらを「弱体化させる」ことができない限り、隣接する野原に爆弾が存在すること（王が爆弾を持って野原を歩くことはできないことを思い出します）は王に対する脅威とは見なされません。 爆弾が攻撃されるとすぐに、王はあたかもシャーを離れたかのように爆弾から遠ざかる義務があります。 一般に、小さなニュアンスを考慮しない場合、これは完全に論理的な動作です。
この位置はマットと見なされます。 王様は爆弾に近づくことができないため、王様は女王を食べることができません。 残念ながら、王様が小切手を離れる要件は損失条件に「釘付け」にされているため、この動作は修正できません。
(loss-condition (White Black) (checkmated King) )
キングを食べることを許可し、損失条件をキングの損失に置き換える場合：
(loss-condition (White Black) (pieces-remaining 0 King) )
...その後、女王は安全に食べられます。 しかし、このモードでは、ZoGのエンドゲームでのプレイがはるかに悪いことに気付きました。 特に、ルークと孤独な王の王との古典的な仲間を待つことができませんでした。 チェックメイト状態を使用する場合、マットは非常に迅速に立てられます。