ダガズ：途中

斜面の少し右-それは落ちます、それは消えます！

スロープの左側-まだ保存できません！

しかし、冷静に、彼は行かなければならない

道のたった2/4です！



ウラジミール・ヴィソツキー「 ロープを締めた 」



作品の前面が完全に無限に見えるとき、それは意図的に小さな断片に分割されることを余儀なくされます。 最初の反復では、非常に小さなものを選択しました：





女性がいなくても！ 通常の「 チェッカー 」ルール（駒を飛び越える）に従って、駒は前進し、敵を「倒す」ことができます。 ボードの最後の行に達したとき、彼らは何にも変わりませんが、引き取りが許可されているので、彼らは敵の一部を引き取ることができます。 この点で、開発中のゲームは、以前の記事の 1つで説明されている「オセチアのチェッカー」に似ています。 キャプチャは必須であり、可能なすべての動きのうち、プレーヤーは最大数の駒を取る動きを選択する必要があります。 プレーヤーの1人が次の移動を完了できない（ロックされているか、すべてのピースを失った）と、ゲームは終了します。



もちろん、「次のチェッカーのコーディング」については話していません（これはより少ない労力で行うことができます）。 シンプルなDSLを使用して、理想的には高度なプログラミングスキルを使用せずに（つまり、 Zillions of Gamesが完全にオープンでクロスプラットフォームなプロジェクトで）かなり複雑なロジックゲームを記述することができる「メタゲーム」システムを開発したいと思います。

クレイジーロシアンスタックマシン

私は非常に長い間1つの質問について考えました。 実際、ゲームの説明をできるだけ宣言的にするために、 非決定的プログラミングが必要です！ 次のコードを見てください：

 (move (check (any nw ne)) (check is-empty?) )
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、作品の「サイレント」ムーブの説明です。 また、ターゲットセルが空である限り、図は「北西」 または 「北東」に移動できると言われています。 並列実行については話していません（この種の「最適化」は、開発の現在の段階では時期尚早です）。 簡単に言えば、それぞれの数字には（少なくとも）2つの移動の選択肢があり、それぞれを考慮する必要があります。



方向を選択する瞬間（非決定性のポイントと呼びましょう）が、コースの正確性の後続のチェックに先行することが非常に重要です。 チェックのいずれかが実行されない場合（たとえば、ボードを超えて）、選択したオプションの分析はすぐに停止します。 「非決定性のポイント」に戻り、次のオプションを選択します。 実際、これは最も宣言的な形式で表現された「 リターン付き検索 」のためのよく知られたアルゴリズムです。 同様に、たとえば、 正規表現を解釈できます。



any形式は、ゲームの説明における非決定性の唯一のソースではありません。 チェッカーでは、複数のキャプチャを「チェーンで」実行できます（さらに、キャプチャの継続が可能であれば、実行する必要があります）。 コードでは次のようになります。

 (move (while true (let dir (any nw ne sw se)) (check dir) (check is-enemy?) (capture) (check dir) (check is-empty?) (end-move) ) )
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

「無限の」サイクルに悩まされないでください！ 関連する条件に違反した場合、（対応するコースオプションの分析とともに）チェックチェックのいずれかによって中断されます。 このコードは前のコードよりも少し複雑ですが、理解することはかなり可能です。 ループの各反復で行われる処理は次のとおりです（ステップバイステップ）。

1. 4つの方向のいずれか （使い慣れた演算子any ）を選択し、変数に保存します
2. 選択した方向に移動します（可能な場合）
3. 私たちが移動したフィールドには、敵のフィギュアがあるはずです（そうでなければ、すべてを中断します）！
4. 私たちは数字を取ります（現在、 トルコのストライキに対抗するための措置を検討していません）
5. そして、同じ方向に移動し続けます（移動する場所があることを確認します）
6. ターゲットセルは空でなければなりません！
7. ...

その後、魔法が始まります。 移動終了フォームは、この時点で移動を完了できることを示しており、（無限）ループでは先に進む必要があります！ 実際、これは次の擬似コードを実行することに相当します。すでにおなじみのものが再びアリーナに入ります。

 (if (any true false) (execute post-actions) (generate-move) )
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さらに、 どれも非常に普遍的であるため、その助けを借りて、パフォーマンスのもう1つの参加者を書き換えることができます。これはこれまで日陰に残っていました。 checkステートメントに相当する擬似コードは次のようになります。

 (if (not <condition>) (any) )
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

選択なしでオプションを選択することは、ソートを完了するための優れたメタファーです。 もちろん、これはチェックがこの方法で実装されることを意味しませんが、そのように実装できます！





一般に、 何をすべきかは理解できましたが、 どうすればいいのでしょうか？ any演算子（およびそれ以上）は、 拡張機能を使用して実装できますが、Javaには拡張機能がありません！ しばらくの間、カーネルの開発をSchemeに切り替えることを真剣に考えました（ Schemeでは、継続だけでなく、すべてがその上に構築されています）。 （「拡張」を式の構文木にねじ込んだ長い実験の後）私はすでに絶望の最大の深さにあり、 Lispを力とメインで小さな断片で読んでいた（おかげで、 ilammy ）、私は別の方法があることに気づいた。





一般的に、秘密は簡単です。 プログラムを一連のコマンドと見なすと（コマンドが任意に制御される可能性がある）、継続の実装が明らかになります。 実際、継続はコマンドのアドレスと、すべての変数の保存された状態にすぎません。 これは、 AST式を使用するときに対処する必要があるものよりもはるかに簡単です。



「プロセッサ」自体については、疑問は生じませんでした。 スタックされたマシンは、その有用性を複数回証明しています。さらに、私はそれらに対処しなければなりませんでした。 唯一の欠点は、スタック上のオペランドの正しい順序を常に監視するために、プログラマーの非常に高い資格が必要なことです。 私にとっては、DSLレベルでコマンドへのアクセスを開くつもりはないので、これは問題ではありません。 スタックマシンコマンドは、 内部表示のみに使用されます。





その後、すべてが簡単です。 コマンドチェーンの実行は、ほとんどの場合、 AbstractPorocessorでの一連のコマンドの実行です。 IfおよびJumpコマンドは、分岐機能とループ機能を提供します。 Anyは魔法に満ちていますが、 Checkの実装は非常に簡単です。 CommandFactoryは、名前でコマンドを作成するための便利なインターフェイスを提供します。 1つだけが気分を暗くすることができます。 「非決定性のポイント」へのロールバックを実装するには、プログラムの実行中に変化するすべての変数の状態を覚えて復元することを学ぶ必要があります。 やりましょう！

ACIDではない

先に進む前に、何に留意するかを決定します。 リストは長いですが、本当にこれがすべて必要です！ 括弧内には、データストレージの符号が示されており、その値は後で解読します。

1. 数字の配置（州の一部）
2. 図の属性値（状態の一部）
3. 位置属性値（状態の一部）
4. 位置値（一時）
5. ローカル変数の値（一時的）

形状配置情報は値ではありません（複数の関連するスカラー値で構成されています）。 他の値は入力されますが、それらの名前は特定のタイプに永続的に関連付けられません。 さらに、可能な場合は暗黙的な型変換が適用されます。 現在、3種類の値がサポートされています。

• ひも
• 整数
• ブール値

ほとんどの場合、リストタイプのサポートを追加します（これらは OrdoやGoなどのゲームを実装するために必要になります ）。 さらに、現時点では、パフォーマンスの最適化とRAMの使用に関連する問題を検討していません。 プロトタイプが計画どおりに機能する場合、たとえば、ビットマスクを使用して多数のブール値を格納することを考えることが可能になります。















この図は、コースの計算に使用されるすべてのタイプのストレージを示しています。 ロードされたゲームのデータ（ボードトポロジなど）は対象外です。 それらは非常に複雑になる可能性がありますが、移動ジェネレーターの観点からは、一定です。 図の配置に関するすべての情報、およびローカル変数を除く前述のすべての値は、 Stateに保存されます。 状態オブジェクトは複製できますが、複製されたオブジェクトには状態要素に関する情報のみが入ります（位置の値は破棄されます）。



LocalEnvironmentの主なタスクは、ローカル変数を管理することです。 IEnvironmentインターフェイスは、これに必要なすべてのメソッドを提供します。 さらに、変数名の代わりに定数（数値、引用符付き文字列、リテラルtrueおよびfalse ）が渡された場合、 getメソッドは対応する値を返します。 これらの行に対応する値は、 セットでは変更できません！ またはletでオーバーライドされます。



DSLの観点からは、むき出しの名前（引用符なしの文字列）に言及すると、 getコマンドが実行されます。 このコマンドを実行した結果は、コマンドが処理される環境によって異なります。 すべての環境は「チェーンで」接続されており、 LocalEnvironmentが名前を知らない場合は、 StateEnvironmentに変わります。 ここから楽しみが始まります。 このモジュールは、ナビゲーションを制御し、ボード上のピースの配置に関する情報へのアクセスを提供する「疑似変数」へのアクセスを提供します。



外観は次のとおりです。 モデルが通常のチェス盤の位置を決定するとします。 この場合、DSLの任意の位置の名前を変数名であるかのように使用できます。 「変数」の値（たとえば、「 a1 」）がLocalEnvironmentで要求され、次にStateEnvironmentで要求されます 。 この環境はStateに関連付けられており、モデルによって定義されたすべての位置に関する完全な情報があります。 要求された位置が存在する場合、 trueが返され、副作用として、受信した位置の名前がStateの現在の位置を定義する変数に格納されます。 それ以外の場合、 falseが返され、副作用は実行されません。 方向の名前は同じ方法で処理されます（要求の時点で、状態の「現在の位置」を決定する必要がある点が異なります）。 擬似変数ナビゲーションに加えて、 StateEnvironmentは、非常に有用な情報へのアクセスを提供するさらにいくつかの名前を定義します。

• position-現在の位置の名前
• 空ですか？ -現在の位置が空の場合はtrue
• 空ではない？ -現在の位置が空の場合はfalse
• 友達ですか？ -フィールドに友好的な人物がいる場合はtrue
• 友達じゃない？ -友好的な人物がフィールドにいない場合はtrue
• 敵ですか？ -敵対的な人物がフィールドにいる場合はtrue
• 敵じゃない？ -敵対的な人物がフィールドにいない場合はtrue
• player-現在の位置にあるピースを所有しているプレーヤーの名前
• piece-現在の位置にある図のタイプ

StateEnvironment - , , PlayersEnvironment . — . , — , , . , ( ). , , PlayerEnvironment false ( StateEnvironment , is-friend? is-enemy? ). :

• current-player — ,
• next-player — ,
• turn-number — '' ( — )
• turn-order — ''

PlayersEnvironment , , , GlobalEnvironment , ( ). , ACID ? - , ITransactional . , . — . , , LocalEnvironment ( ) State ( ). StateEnvironment — State , PlayersEnvironment . , Processor , .

«»

上記で、ほとんどの種類のドラフトのルールに従って、キャプチャが可能であれば、それを完了する必要があると既に述べました（これをキャプチャの優先順位と呼びます）。ゲームの一部のバージョン、たとえば国際ドラフトでは、さらに厳しいルール（通常は「多数決ルール」と呼ばれます）が適用されます。それに応じて、可能なすべての動きのうち、プレーヤーは最大数の敵の駒を取る動きを選択しなければなりません。チェッカーを位置的で戦略的なゲームに変えるのは、「キャプチャの優先順位」です。それがなければ、ゲームはあまり面白くないでしょう！しかし、このルールはDSLにどのように反映されますか？

 (piece (name Man) (pre ... (let captured 0) ) (post (check (<= max-captured captured)) (set! max-captured captured) ... ) ... (move (while true (let dir (any nw ne sw se)) ... (check is-enemy?) (capture) (inc! captured) ... ) ) )
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ポストのトリッキーなチェックを「壊れた不変式」と呼びます。彼はどのように働いていますか？構文解析の過程で、1つのピースをとる移動が行われたとします。ポストインのチェックは成功し、変数max-capturedに保存されました。これで、チェック中の条件に違反するため、とられないすべての動きが拒否されます。変数max-capturedは非常に特別な場所に保存する必要があることは明らかです。状態のロールバックの影響を受けてはならず、最も重要なことは、計算された動きのすべてのバリアント（ほとんど異なる現実まで）で利用できるはずです。地球環境 — . let , set! get -! attribute let , , .



, , — ! , . - , , , , , , … ! グローバル変数max-capturedが変更されるたびに以前に実行されたすべてのチェック。違反が検出された場合、対応する移動を拒否します。これらの動きの不変式は、それらの生成時に実行されましたが、最大キャプチャされた変更によって破壊されました！これは本当に難しい場所であり、それが機能するかどうかはまだわかりません。MoveGeneratorである必要があるこの「マジック」をすべて管理します。





, « » (, ), ? , , ( — « », ). « » . ( ), , . « », .



( , " "), , ! , " ", . « » ( , « ») . no-moves? . , ( ) . .

unit-

, unit-, , unit- ! , , TDD , unit-, , ! () (, mock- ), . , , — . Unit- , , , , 。このアプローチは本当に効果的です！テストを作成する過程で、すでにいくつかの重大なエラーを見つけて修正しました。プロジェクト全体をデバッグする段階での同様の修正は、はるかに費用がかかります。



, unit- ( , ) , , . , - ( ), unit- , . - , unit- API ( ), , . , , unit- , ( , ). .