ダガズ：革命ではなく進化

私たちが望むもののこの世界では！

彼を変える力はイエスだと信じています！



ユーリ・シェフチュク







私の記事を読んだ人たちは、私がZillions of Gamesのメタゲームシステムをかなり長い間研究していることを知っているはずです。 この間ずっと、私は50を少し下回るゲームを開発し、このプラットフォームをずっと調べてきました。 私の目標は、同様の（できればより機能的な）オープンソースシステムを開発することです。 この作業の進捗についてお伝えしたいと思います。

画像で

私が言ったように、Zillions of Gamesの仕組みをよく理解しています。 この製品の移植に対処するつもりはないので、ソースコードの欠如に邪魔されません。 私が現在知っているすべてのメタゲーミングプラットフォームの利点（およびさらに大きな欠点）を考慮して、ゼロから新しいシステムを開発することです。 それらをリストします。

• Zillions of Gamesは、私がよく書いた最も有名なメタゲームシステムです。
• Axiom Development Kitはかなり興味深いプロジェクトであり、Zillions of Gamesの拡張モジュールとして実装されていますが、自律的に動作することもできます。
• LUDÆプロジェクト -新しいボードゲームの自動開発用に設計された楽しいシステム
• Jocly-モダンで非常に興味深い開発（残念ながら、実装されたゲームの品質には多くの要望が残されています）

これらの製品はすべて機能し、意図したとおりに機能します。多少の労力を費やして、さまざまなボードゲームのコンピューター実装を作成するのに役立ちます。 チェッカーとチェスだけではありません！ 既に作成されたゲームの数と（最も重要なことですが）多様性は、すべての期待を超えています。 これはメタゲームシステムの主な利点です。新しい、かなり複雑なボードゲームのプロトタイプをわずか数時間で作成できます。





Joclyと知り合ったため、いくつかの決定を再考するようになりました。 さらなる開発のために、JavaScriptを使用することを固く決めました。これは明らかに、最新のインターフェースを備えた拡張可能なクロスプラットフォームシステムを作成する最も簡単な方法だからです。 シングルスレッドは少し怖いですが、実際、この瞬間はAIにとってのみ重要です（そして、その中で、マルチスレッドを使用することは本当に簡単ではありません）、そして私たちはすでに（自分自身にとって）AIがメタゲームシステムの最強の側面ではないことを発見しました。



一方、ボードゲームの最も日常的な側面を記述するためのDSLの必要性は、私にとって非常に明白です。 JavaScriptを直接使用してゲームモデル全体を開発すると、プロセスに前例のない柔軟性が与えられますが、勤勉さと集中力が必要です（そして、実践が示しているように、それらの存在はあまり役に立ちません）。 理想的には、新しいシステムで実行できるようにするために、ベースZRFとの互換性を確保したいと考えています。 Jocly開発者がそれについて書いているのは次のとおりです。

ZoGでは、ゲームはZRFと呼ばれるLispベースの言語で記述されます。 これにより、ゲームルールに優れた正式なフレームワークが提供されますが、ZRFに特定の機能に対する事前定義された指示がない場合、いくつかの制限が導入されます。 ゲームはJavascriptで開発され、APIを使用してルールとユーザーインターフェイスを定義するため、Joclyアプローチはまったく異なります。 Joclyの良い点は、開発者が望むことはほとんど何でもできることです。悪い点は、より多くのコードを書かなければならないことです。



理論的には、JoclyがZoGゲームを実行できるように、JavascriptでZRFインタープリターを作成することが可能です。 そのようなツールを開発したい場合は、お知らせください。

しかし、解釈ではなく、Joclyのゲームの説明にZRFファイルを一種の「コンパイル」することに焦点を当てて、この道を取ることにしました。 Lispを連想させる言語で、ゲームの非常に単純な説明が含まれている場合でも、テキストファイルを常に解析します。これは、JavaScriptでやりたいことではありません。





Joclyは、古典的なMVCスキームに基づいています。 新しいゲームを開発するには、そのモデルとプレゼンテーションを作成する必要があります。 モデルはゲームのルールを定義し、プレゼンテーションはゲームがユーザーにどのように表示されるかです。 開発者によって作成されたコントローラーが、残りの部分（コントローラーに接続されたボットを含む）を処理します。









Z2Jによって実装されるユニバーサルモデルのアーキテクチャもそれほど複雑ではありません。 基本は、ゲームのルールの変更されていない説明を含むデザインコンポーネントです。 ゲームの状態（ボード上のピースの配置）は、 Boardクラスのインスタンスに保存されます。 これらのコンポーネントのデータも変更されません。 移動を実行する（ MoveオブジェクトをBoardに適用する）ことにより、新しい状態を作成します。 古いものは変わりません！









移動を生成する（ Moveオブジェクトを作成する）には、 ボードの現在の状態が使用されますが、ZRFのすべての機能を実現するには不十分です。 動きを生成するプロセスで、ZRFはゲーム状態の一部ではない変数（フラグと位置フラグ）を使用できます。 このすべてとスタックマシンのコマンドを実行するロジックは、 Move Generatorによって処理されます。 要するに、これはzrf-model.jsモジュールのアーキテクチャです 。

悪魔の詳細

そこで、Jocly モデルの代わりに、 トルコのドラフトを コンパイルして構成されたモデル（zrf-model.js）をJoclyに埋め込み、ゲームのプレゼンテーションを変更せずにこれらすべてを実行しようとしました。 振り返ってみると、このアイデアは冒険的なものだったことがわかります（理由-以下で説明します）が、それが私が始めた理由です。 モデルには少し必要でした：

1. ゲームの現在の状態の保存
2. ゲームの現在の状態に有効なすべての動きの生成
3. 生成された動きの1つを適用してゲームの状態を変更する

難しかったのは、常にその動きがボード上のピースの1つを単純に動かすことになるということではありませんでした。 最も一般的な形式では、移動は次の基本アクションのシーケンスで構成されます。

• move-シェイプをある位置から別の位置に移動します
• キャプチャ -ボード上のいずれかの位置からピースを削除します
• ドロップ -ボードに新しいピースを追加（リセット）します

たとえば、チェッカーで駒を取ることは、駒の1つの動きと相手の駒を取ることで構成されます（この場合、キャプチャは駒の動きの最終位置と一致しないため、キャプチャは「チェス」ではありません）。 連珠は 「ボード上の数字を1回捨てる。 移動中に移動できるのは1個だけだと考えてはいけません！ そのため、チェスでキャスリングするとき、ルークとキングは、1つの不可分な動きの中で同時に動きます。





しかし、これはすべて問題の一部にすぎません！ チェッカーでは、ピースは「チェーンに沿って」いくつかのキャプチャを実行できます（さらに義務付けられています）。 すべてのキャプチャが完了するまで、移動は別のプレイヤーに転送されません。 モデルの観点から、およびAIの場合、これは1つの動きです。 コントローラーとプレゼンテーションでは、事態はもう少し複雑です。 ゲームのユーザーインターフェイスでは、各チェッカーキャプチャ（部分移動）を個別に実行する必要があります。 ユーザー（プレイヤー）は、長い複合移動の各段階で1つまたは別の部分移動を選択できる必要があります。





複合ストロークの生成は、ZrfMoveGeneratorの最も単純なアプリケーションです。 ジェネレーターの各インスタンスは独自の部分ストロークを形成し、部分ストローク自体は複合ストロークの「チェーン」にリンクされます。 残念ながら、これはZRFが移動を決定するために使用できる唯一の方法ではありません。 チェスの 象 、 ルーク 、 クイーンなど、空のフィールドを一方向に移動するピースを説明する非常に単純なケースを考えてみましょう。





移動の形成を完了するaddコマンドがループの本体で使用されていることがわかります。 これは、敵の駒へのルートに沿って、駒が空のフィールドで停止できることを意味します（これは正しい動きと見なされます）。 もちろん、定義を書き直すことでそのようなサイクルを取り除くことができます：





ループの本体で実行されるaddコマンドは、非決定的な動きの形成につながります。 図が停止するか、先に進む場合があります。 ZrfMoveGeneratorの場合、これはクローニングの必要性を意味します。 ジェネレーターはその状態の完全なコピーを作成し、後続の生成のためにスタックに配置します。その後、現在のコピーが移動の形成を完了します。 これは次のようなものです。







FORKコマンドは、すべての現在の状態とともに移動ジェネレーターを複製し、条件付きジャンプとして機能します。 生成されたジェネレーターでは、制御は次のコマンドに進み、親はパラメーターで指定されたステップ数に制御を移します（はい、Linuxでのプロセスの作成に非常に似ています）。





これらの2つの方法（ムーブジェネレーターをチェーンに配置してクローンを作成する）を使用すると、ZRF言語構造を実装できます。 もちろん、実装は簡単ではなく、ZRFセマンティクスとの互換性を確保する必要があるため、かなり混乱します。 コードが機能する場合、これは大きな問題ではありません。 問題は、ZRF自体が完璧とはほど遠いことです！

開いた指

今年は失望から始まりました。 そもそも、私が知っているすべてのボードゲームの簡単な説明に適したユニバーサルDSL を作成しようとして 、私は立ち止まっています。 普遍的に、原則として、「理解できる」ことが判明しました-いいえ。 Fanoronaなどの比較的単純なゲームでさえ、何らかの恐怖で自分自身を表現しようと努力しました。







C Joclyもどういうわけか、尋ねなかった。私はそのアーキテクチャが好きではありませんでした。まず、可変Model.Boardシングルトンを使用して、ボードの状態を保存します。このAIボットの使用方法-想像できません。しかし、主なことはそれでさえありません。その中の1つのモデルは、他のモデルとはまったく異なります（単に共通点はありません）。同時に、mWhoやmMovesのように「マジック」メンバーが積極的に使用され、ビューはモデルがコントローラーと同等に使用されるため、モデルがどのように構成されているかを「知っている」必要があります。



モデルを「置き換える」という私の希望は、事前に失敗する運命にありました！つまり、私にはそれはかなり可能であると置き換えることができるのモデル「トルコチェッカーを「対応するパフォーマンスが彼女と連動するようになりましたが、他のゲーム（「英語ドラフト」でも）では、「トルコドラフト」のモデルが非常に異なるため、最初からやり直す必要があります。準備ができていないことに気付きました。モデルに加えて、ますます発展プレゼンテーションに従事し、深い不況にあった。そして、その後、仕事が関与ジョニックと地平線上に少し明るく。



我々はJoclyと統合し、不足しているネットワークとローカルゲーム用コントローラ（だけでなく、ユーティリティの自動再生を詳しく説明しようとしてあきらめることにしました）、pred tavleniya（2Dおよび3D）だけでなく、自分自身に（在庫あり）ボット。そして、このすべての作業が行うことに合意したジョニックモデルに取り組むことに集中できるように。私が最初にしたことは、Joclyの継承された愚かな制限を取り除くことでした。はい、現在このモデルは3人以上のプレーヤーのゲームをサポートしています！そして、私は味を得ました...





私もZRFの制限が気に入らないと言いましたか？これらのオプションのごく一部は、維持する必要があるレガシーの無数のゲーム設定です。残りは、ZRFではこれまで見られなかった拡張機能です。したがって、すべてのzrf-advancedオプション（1つのコマンドでそれらをすべて有効にすることができます）-ZRFセマンティクスを拡張してより便利にし（Zillions of Games ユーザーの希望 を考慮しようとしました）、ボードモデルオプションは新しいタイプのボードを導入します。





オプション自体は、ロード可能なJavaScriptモジュールとして実装されます。たとえば、ゲーム内（「国際ドラフト」など）で最大数のピースを取得する必要がある場合、zrf-modelをロードした後、対応するモジュールをロードする必要があります。モジュールは、checkVersion関数を使用して接続されます。







モデルは、要求されたモジュールのバージョンの互換性をチェックし、適切なオプションを接続します。この拡張可能なメカニズムは、私に興味深い考えを与えました。一部のゲームでは、ZRFを使用して実装するのが非常に難しいルールがあります。ほとんどの場合、これらのルールは、1つまたは別の移動を完了する機能に影響する追加のチェックになります。ロードされたオプションにチェックを入れると、実装のためにベース言語を拡張する必要がなくなります（簡単ではありません）。





例で説明します。いろいろな「トルコの草案」があり、最近学んだ。「バーレーンチェッカー」とトルコのチェッカーの唯一の違いは、敵の攻撃を仕掛けることによる対応が禁止されていることです。攻撃しているフィギュアを食べたり、打撃から逃げることはできますが、それに応じて別のフィギュアを攻撃することはできません！このルールは女性にも適用されることを考慮すると、ZRFでのこのゲームの実装はかなり複雑であり、最も重要なこととして、非常に「透明」ではありませんでした。しかし、拡張可能なオプションを使用すれば、ZRFのコードを複雑にする必要はありません！





「トルコのチェッカー」を取り、必要なチェックを実行するオプションを接続できます。ロード可能なモジュールは、ストロークの後処理メソッドを置き換え、必要に応じて、以前に生成された動きを禁止する場合があります！検証ロジック自体は任意に複雑になる可能性がありますが、ZRFでの同様の実装よりも明確です！問題は、すでに生成された移動の追加検証に限定されません。オプションで動きを「豊かにする」ことができます！たとえば、Goで移動を実行するときは、次を実行する必要があります。

• 隣接する4つの石を確認します（ボードの境界に3つ、または角に2つ）。
• 隣接する石が敵のものである場合、「接続された」石のグループを構築し、その中に石を入れて、その数を数えます（グループが接する自由ポイント）。
• 敵グループがフリーポイントに接していない場合は、その石をすべて取り除きます。
• 敵グループがどれも削除されていない場合は、追加したばかりの石を含むグループを作成します
• 構築されたグループに貴婦人がいない場合、移動を禁止します（厳密に言えば、常にではありません。インガのルールは、複数の石で構成されるグループの自殺を許可します）。

これらはすべてJavaScript拡張機能で「非表示」にできます。必要なチェックを実行するだけでなく、敵の石を取り除くことで動きを補完します。ゲームのZRF記述が基本になります！さらに、この拡張機能は他のゲームにも適しています！たとえば、「Multicolor Go」の場合

複数の動き...

拡張可能なオプションにより、プロジェクトを新しい視点から見ることができましたが、1つの小さなタスクに悩まされていました。いくつかのゲームでは、一定の条件の下で、ボードのキャプチャ許可いずれかの対戦相手の駒を。たとえば、「工場」では：

• プレーヤーはボードに置いて自分の駒を動かし、3つの駒を「一列に」並べようとします。
• これが成功した場合、プレーヤーはボードから敵の駒を取り除く権利を獲得します。
• 同時に、「列に並んでいない」数字を優先する必要があります（列を構成する数字は最後に取得されます）。
• プレイヤーに3つのピースが残っている場合、ボード上の任意の場所（マークされたラインに沿ってだけでなく）を移動する機会があります。
• 残り3個未満のプレイヤーは負けています。

これは、これがZRFで実行可能ではないということではありませんが、コードは非常に紛らわしいです。まあ、一般的に、撮影されている数字を除いてほとんどすべてで同一である一連の動きの生成は、かなり退屈な決定です。移動のアクションで位置の配列を使用できれば、はるかに便利だと思いました。

 ZrfMove.prototype.capturePiece = function(pos, part) { - this.actions.push([ pos, null, null, part]); + this.actions.push([ [pos], null, null, part]); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

それはかなりグローバルなコードの再設計でしたが、ユニットテストが再び役立ちました。これまでのところ、ゲームの最も単純なZRF記述によって形成される動きの「強化」の一部として、JavaScript拡張からのみそのような非決定的な動きを形成することが計画されています。「ミル」について話す場合、数字を取る過程への同じ追加について話している。単一のテイクのセットの代わりに、1つの非決定的なテイクが追加されます。





しかし、これはより広い概念です。キャプチャは非決定的であるだけではありません！「ミル」には、プレイヤーの残りの3つのピースが「どこでも」ジャンプできるというルールがあります。実際、これは自由な位置への非決定論的な動きです。





可動形状は配列にすることもできます！チェスの変身のルールによれば、ポーンは最後の水平に到達し、プレイヤーの選択で4つの駒（馬、象、ルーク、クイーン）のいずれかに変わることができます。これは、フィギュアを移動するときに実行される非決定的な変換にすぎません。ZRFコードでは、ポーンを例えばクイーンに、JavaScript拡張で変換できます：





コントローラーについては、ほとんど変更されません。ボードの現在の状態で許容できるモデルからの移動を受け取った後、彼は各アクションでアレイのサイズを確認する必要があります。複数の要素が送信される場合、コントローラーはすべての可能なオプションを通過し、決定的な動きを形成する必要があります。このような非決定論では注意が必要だと言ってはならないと思います。いくつかの独立した位置のデカルト積は、信じられないほどの数の異なる動きを生成できます！

小計

一般的に、私はプロジェクトの開発の方向性が好きだと言えます。私は革命的な新しいものを作成するという考えを放棄し（簡単ではありませんでしたが）、達成可能な目標に焦点を当てましたが、それでもおもしろい目標ではありませんでした。既知の2羽の鳥のうち、「手に鶴」を好むと言えます。プロジェクトに取り組むことで、私は新しい言語を学ぶことができます。また、プロジェクトに経験豊富な新しい開発者が加わることで、作業が引き続き成功することを期待できます。私は「革命」を放棄しましたが、プロジェクトは進化し続けています！