Prologに触発された商用ソリューションは10年以上運用されています

Prologのことを聞いたことがあるほとんどのプログラマーにとって、これはコンピューターが恐竜のサイズであった時代からの奇妙なアーティファクトです。研究所を通過して忘れた人もいました。そして、A4の葉のように狭い専門家だけが、現代の世界で同様の何かに遭遇しました。 2003年に私が商用FlashゲームでPrologのいくつかのソリューションを使用し、10年以上の間、彼らはフランス人を喜ばせたのはまさに偶然でした。さらに、私はブラトコの本を読んだからではなく、この半宣言的な決定を適用しました感動しましたが、私たちのプロジェクトが本当にそれを必要としていたからです。現代のゲーム業界で非常に役立つので、私は今でも定期的にそのソリューションを現代レベルで再現しようとしていますが、残念ながら、やるべきことがもっと重要になるたびに...一般的に、これについてすべてお話しします。





同じフラッシュゲームのスクリーンショットはまだtoox.com/jeux/jeux-de-cartes/coincheにあなたを歓迎します

問題の記述とその関連性

Quosh、Belote、Tarotはフランス国内のゲームです。ルールによれば、これはプライベートでの好みのゲームとほぼ同じであり、ペアはペアでプレイされるので、パートナーが交渉中にゲームを発表するために提案する賄賂の数と切り札で、彼が持っているカードを大まかに理解できます。ゲームは長く、どういうわけかゲームを終わらせることができるAIの存在は、プレイヤーの1人が絶望的に​​負けていると判断してテーブルを離れることができ、勝者は当然スコアボードの最終スコアにプッシュしたいので、非常に重要です。この場合、AIは失われたプレーヤーのゲームを終了します。しかし、私たちはAIを持っているので、空きスペースでAI-shkiを悩ませてゲームを開始できるようにしてみませんか。そこで私たちはこれらの素晴らしいゲームを大衆に向けて立ち上げ、フランス人がどのようにプレイするかについて基本的に2つのオプションがあることにすぐに気付きました。上のスクリーンショットのように、すべてのテーブルの約半分が勝利するまで生きている人々で満たされるのを待っており、半分が下に来て3つのAIとのゲームを開始します。



原則として、ゲームは終了しているので、人々は小さな誤算や代替の才能のためにロボットを許す準備ができています。主な理由は、ロボットのカードが見えないためです。 「シマックを持ったプレイヤーの下で」、「エースを持ったヴィストゥザの下で」、そして私がフランスの顧客から振り払った同様の簡単なルールにより、私たちは最小限の許容可能なスローアーを作ることができました。それはifsのすぐ上で一週間でnafigchedされました。一方、ゲームは「2対2」でプレイされ、ポイントはペアにカウントされます。当然のことながら、プレーヤーは愚かなパートナーが「2番目の王から」入ることを望んでいません。つまり、王を手に持ち、他の小さなカードをこのスーツは、対戦相手にエースをプレイさせる代わりに、小さなカードでパスさせ、キングと一緒にこのスーツで次の動きをします。 （実際、これらのゲームでは、2番目に古いカードは10です。しかし、以下、私はロシア語で話します）。しかし、何らかの理由でエースがゲームを離れ、クイーンと他の小さなものがある場合、それはほとんど2番目のキングのようです。特にトランプカードを事前注文した場合。たとえば、32枚のカードが使用されているBeloteではなく、78枚のカード（一部の人が推測しているものと同じ）のデッキでゲームがプレイされているTarotをプレイしています。そして、場合によっては、3番目の女王ではなく4番目のジャックが賄賂を受け取ることができます。一般に、これはすべて、ifsの愚かなダミーがどういうわけか完全に容認できないほど複雑になるような多くのエッジケースを引き起こします。そしてこの時点で私はこう言いました。たくさん読んだたとえば、32枚のカードが使用されるBeloteをプレイするのではなく、78枚のカード（一部の人が推測するものと同じ）のデッキでゲームをプレイするTarotをプレイします。そして、場合によっては、3番目の女王ではなく4番目のジャックが賄賂を受け取ることができます。一般に、これはすべて、ifsの愚かなダミーがどういうわけか完全に容認できないほど複雑になるような多くのエッジケースを引き起こします。そしてこの時点で私はこう言いました。たくさん読んだたとえば、32枚のカードが使用されるBeloteをプレイするのではなく、78枚のカード（一部の人が推測するものと同じ）のデッキでゲームをプレイするTarotをプレイします。そして、場合によっては、3番目の女王ではなく4番目のジャックが賄賂を受け取ることができます。一般に、これはすべて、ifsの愚かなダミーがどういうわけか完全に容認できないほど複雑になるような多くのエッジケースを引き起こします。そしてこの時点で私はこう言いました。たくさん読んだ簡潔にそして感銘を受けました！」それから私は数日間オフィスから逃げ出し、カフェでラップトップを持って座って、数日後に何かを生み出しました。

重要なアイデア

宣言に基づいたプロローグとは何ですか？事実について、例えば：

('', '').
('', '').

そして、条件または規則では、たとえば、Aが母親Bの場合、Aは女の子です。

() :- (, ).

もちろん、私たちの時代にはすべてがそれほど単純ではなく、一般的にこれを言うのは少し卑劣なことですが、人々が形式的な論理を信じていた当時、そのような例では非難できるものは何もありませんでした。許容範囲について考えてみましょう：

(A, B) :- (A, B).
(, ) :- (, ), (, ).

そして、あなたはこのように尋ねます：

?-  (X, '')

そして、ひどく論理的なプロローグはあなたに答えます：

X = ''
X = ''

アイデアは、プロローグシステムが答えに到達するために事実にルールを適用する順序と量でユーザーが頭を温めなかったというものでした。しかし、もちろん、それはそれほど単純ではありません。プロローグは、クラッチ、機能の追加、推論のさまざまなブランチのカッターなどで大きくなりすぎていますが、それでも定期的に無限の再帰に逃げます。



その非常に刺激的なBratkoの本では、プロローグマシンが内部でどのように実現されるかについて章全体が捧げられました。つまり、すべてのルールのツリーを詳細に調べ、各ルールを既知のすべてのファクトと変数のセットに順番に適用して新しい状態を取得しようとします。ルールを適用できない場合は、前の手順にロールバックして別のオプションを試行します。



さらに、何か便利なものをまとめることができた場合、マシンはルールのリストを取得し、リストの最初から次のステップで適用するルールの検索を開始します。さらに、ルールに変数が発生した場合、マシンは、すでに適用されているルールを考慮して、これらの変数のどの状態になり得るかを記憶します。これは肉付けと呼ばれます。質問を真にする変数のインスタンス化を見つけることができる場合、そのインスタンス化を出力します。その後、彼女は次の具体化を探しに行くことができます。上記の人工的な例では、システムは条件を満たす2つの具体化を見つけました。



どういうわけか同じようにゲームのルールを定式化したいと思いますが、もちろん文字通りではありません。Prologでプログラムをデバッグした経験があるので、私はこのデバッグと製品のこれらのオーバーヘッドコストに直面することにまったく熱心ではありませんでした。

まず、これはすべて、散在する事実の束ではなく、ゲームの状態ツリー（モデル）で機能し、その作業の結果を同じツリーにも適用する必要があります。次に、特定の値、変数、および算術式が同じ位置にあるようにルールを記述します。システムは、プログラマーに追加の質問をしたり、追加の構文を必要とせずに、これを適切に処理する必要があります。第三に、もちろん、無限の再帰を放棄することは非常に重要ですが、ルールを適用するための繰り返しを残す必要があります。第4に、ルールのシステムは、人間が読み取れる非常に便利な形式で作成する必要があります。これにより、作成者が何を言いたかったかが一目でわかります。そして最後に、第五に、このすべては、このシステムの推論に従い、特定のルールが期待に反して機能しない理由を理解するのが簡単になるように、いくつかの便利なロギングおよびデバッグツールに関連付ける必要があります。



もちろん、これは普遍的な一次述語論理ソルバーではなく、単にゲームルールの便利な宣言システムです。実用的な意味でもとても良いです。このために、私は次のプロジェクトの1つでずっと後にLogrusという名前を思いついた。エンジン開発のすべての中間段階をバイパスして、最終バージョンを一度に説明します。

Logrusライブラリの結果の構文

たくさんの構文があります。



1）実行時に、決定ツリーはいくつかのクラスの形式で保存されますが、それが機能するとすぐに最初に添付したのは、JSONでのインポートとエクスポートでした。データ構造があまり変更されていない場合は、再コンパイルせずにファイルからルールを更新できるので便利であることがわかりました。 JSONの形式で書くことは非常に便利であることが判明したので、次のプロジェクトの1つで、プログラマーが急いでいるときに、通常のコマンドを書く代わりに、単にstate.AplayJSON("...");その中に、必要なアクションがJSON文字列として挿入されました。もちろん、これはパフォーマンスにあまり良い影響を与えませんでしたが、定期的ではなく、ユーザーのクリックに応答するだけであれば、怖いことではありません...残りはすべてJSONですぐに説明します。長い間地獄だったので、私はほぼメモリからJSONを再現します。厳密に言えば、JSONはオブジェクト内のノードの順序を保証しませんが、ほとんどのライブラリはそれを尊重し、こことその下のノードの順序がアクティブに使用されます。



2）ルールがエンジンの主要な構造単位になりました。ルールは、条件とアクションで構成されます。通常、ルールは配列で提供され、1つずつ適用されます。

[{"condition":{}, "action":{}},
 {"condition":{}, "action":{}}]

3）各ルールには条件が含まれています-これはツリーテンプレートであり、変数が含まれている可能性があります。システムは、状態ツリーが変数の任意の値のテンプレートと一致するかどうかを確認します。そして、そのような仕様が見つかると、アクションがトリガーされます。例えば：

{"condition":{
    "player":{
        "$X":{"gold" : "<20", "name":"$NAME"}
    }},
    "action":{}}

このような構成は、ツリーでアクションをトリガーするために、トップレベルに「プレーヤー」ノードが必要であることを意味します。このノードには、それぞれ20未満の値の「ゴールド」フィールドと「名前」フィールドを持つ1つまたは複数の子ノードがあります。このような条件が満たされると、アクションが呼び出され、入力として、ノードのキーであるX変数と、プレーヤーの名前であるNAME変数に渡されます。適切なノードがいくつかあり、それに応じていくつかの可能なインスタンス化がある場合、アクションは、入力で見つかったインスタンス化のそれぞれで数回呼び出されます。



4）当初、すべてが少し柔軟性が低かったが、Unityに関する会議での多数の講演で多くの人が知っているValyardが、算術式をスマートな決定ツリーに解析するパーサーを台無しにし、柔軟性が最終的に暴力的な色で開花した。



5）C $変数名が始まります。これらは$ Xなどのキーとして表示でき、$ NAMEなどのシート値を算術式に挿入できるため、いくつかのインスタンス化が選択されます。例：{"gold"： "<$ X * 10" }そして、条件をチェックするために使用できます。通常の数に10を掛けた数よりも多くのゴールドを持っているプレーヤーのみがテストに合格し、最後に、次のような式で直接計算できます。{"gold"： "$ X = 3 + $ this "}ここで、$ thisは、計算が呼び出された現在のポイントの値です。このノードの通過により、変数$ Xの値が3+プレーヤーが持っている金の量として具体化されます。可能性の頭に浮かんだのは実装されておらず、1つしかありませんでした-変数は最初に算術式の右側に表示できません。これはエラーになります。引数として使用されるまでに、他のいくつかの方法のいずれかですでに具体化されている必要があります。



6）式の変数は、最初の言及で指定されている間は何度でも発生する可能性があり、次の変数は同等性のテストになります。たとえば、そのような構造では、最初のプレーヤーを取得し、彼のお金をチェックしてから、最初のプレーヤーがターゲットになる別のプレーヤーを探します。見つからない場合は、具体化のポイントにロールバックします。Xは次のプレーヤーを選択し、お金をチェックし、すべての可能なオプションXとYを通過するまで続きます。行を入れ替えることにより、プログラマーはチェックの順序を変更しますが、最終結果は変更しません。

{ "player":{
    "$X":{"gold":">20"},
    "$Y":{"target":"$X"}
}}

7）アクションは、変数と算術式を含むことができるツリーテンプレートでもあり、ゲーム状態ツリーはそれに一致するように変更されます。たとえば、このテンプレートは、プレーヤーXをプレーヤーYの形式で対戦相手に割り当てますが、何らかの理由でプレーヤーYが存在しなかった場合は、作成されます。そして、余分なプレーヤーは完全に削除されます。スクリーンショットからゲームを作成した時点では、削除記号はnullでしたが、誰かがキーで空白の値を挿入する必要がある場合に備えて、予約済みの単語に置き換えました。一般的に、原則は明確であり、ゲームで実行されるアクションの意味は基本的に同じだと思います。

{
    "condition":{
    "player":{
        "$X":{"gold":">20"},
        "$Y":{"target":"$X"}}},
    "action":{
        "$X":{"target":"$Y"},
        "superfluous":"@remove"}
}

8）アクションは、ツリーテンプレートではなく、ルールの配列にすることもできます。それらのそれぞれは、最初からではなく、アクションが呼び出された最初のインスタンス化でチェックされます。つまり、ルールのグループ全体が存在する可能性があり、それらはすべてX変数を使用します。

{
    "condition":{
        "player":{
            "$X":{}, "$Y":{"target":"$X"}}},
    "action":[
        {"condition":{}, "action":{}},
        {"condition":{}, "action":{}}]
}

9）子ルールは、状態ツリーのルートからではなく、アクションの適用中に到達したある時点から適用できます。この場合、すべての条件とすべてのアクションは、このポイントをルートとして使用します。次のようになります。

{
    "condition":{
        "player":{
            "$X":{}, "$Y":{"target":"$X"}}},
    "action":{
        "$X":{"@rules":[
            {"condition":{}, "action":{}},
            {"condition":{}, "action":{}}]}
}

10）ルールの繰り返しを別のノードとして指定できます。これにより、必要に応じて、制限された深さの再帰が実現されます。しかし実際には、そのような決定は通常必要ありませんでした。また、アクションに配置することで、必要に応じて一連のルールを繰り返すために使用することもできます。

{
    "condition":{},
    "action":{},
    "repeat":5
}

11）ルールツリーは複数のJSONファイルからロードでき、それらのツリー構造は単純に互いに重ね合わされていました。ルールを別々の意味のあるブロックに分割すると便利でした。おそらくいくつかのインクルードも役立つでしょうが、今ではそれがどのようにアレンジされたか覚えていません。



12）ロギング！どのルールにも「@log」：trueノードが含まれている可能性があります。これにより、このルールがソリューションプロセスを説明するログに詳細に記録され始めました。私たちが試みる具体化、推論のどの枝が抑制されるか、そしてその理由。ロギングは階層的でした。つまり、ネストされたルールは「@log」である可能性があります。falseであり、そのルール以下で発生するすべてのルールはログに記録されません。理想的には、このノードを条件ツリーのどこにでも残して、テンプレートの1つのレベルで何が起こっているかだけを確認できるようにしたいのですが、そのような拡張は完了していないようです。おそらくそれがなくてもデバッグはうまくいったので、「いつか」まで延期されました。



13）入力します。おもちゃはとても古く、今日のプログラマーの何人かは生まれさえしませんでした。これはActionScript2で記述されており、動的な型指定と、実行時に利用可能なプロトタイプによる継承がありました。聞いている現代の言語のうち、Pythonだけがこのように機能します。ただし、このアイデアに結び付けることは特に難しいことではありません。 「$ X：int」のような「：」キー記号を使用してこれを行いますが、変数の最初の出現に指定されたタイプがない場合は注意が必要です。また、3値演算子と混同される可能性があります。



彼らが言うように、それは紙の上では滑らかでしたが、実際の使用には多くの異なるクラッチが必要でした。これが私が覚えているものです：



14）1つの同じノードを、1つではなく、いくつかの条件でチェックできます。たとえば、このような条件では、最初に20を超える金額があることを確認してから、この金額が表される変数を指定しました。サービス記号「@」が行の先頭にない場合は、ノードへの再入力を意味し、さらに進んだ再入力識別子はまったく役に立ちませんでした。おそらくサービスシンボルと他のシンボルが使用されましたが、私の意見では、これを使用することを妨げるものは何もありません。

{
    "player":{
        "$X":{"gold":"<20", "gold@cnt":"$COUNT"}
    }
}

15）ノードをまったく使用せずに実行できる算術演算が必要でした。プロローグの伝統によれば、それらは「_」と指定されており、それらの多くが存在する可能性があります。

{
    "_":"$SUM=$A+$B",
    "_@check":"@SUM <20"
}

16）ツリーの上に検証パスがあるため、「@ parent」キーワードを介して下向きに降下しました。もちろん、これは読みやすさを向上させるものではありませんでしたが、それなしでは機能しませんでした。ここでは、もちろん、path関数の類似物がそれ自体を直接示唆しており、ツリー内の指定された場所にリダイレクトされますが、最終的に実装できたかどうかは覚えていません。

{
    "condition":{
        "player":{
            "$X":{}, "$Y":{"target":"$X"}}},
    "action":{
        "$X":{"rules":[
            {
                "condition":{
                    "@parent":{"@parent":{"…":"…"}}
            }
        ]},
    }
}

17）アクションに、クラスメソッドを直接プルする機能が追加されました。これは読みやすさの息吹のようなキックであり、私は#includeのある種の類似物を好むでしょうが、それがそうであるように、あなたは歌から言葉を捨てることができません。今C＃でライブラリを復活させたら、実際にはこれなしでできるのだろうか？



18）ルールには、見つかったすべてのコンクリートに対してではなく、最初のコンクリートに対してのみアクションを繰り返すための追加設定があります。今は何と呼ばれていたのか覚えていませんが、なぜかこのクラッチはいくつかのルールに役立ちました。

使用結果

ライブラリが積極的に使用されるようになるとすぐに、すべてのAI-shkiがすぐにライブラリに転送されました。これにより、3分の1のプログラミングリソースで、2倍のスマートAIを実現できました。 AIスケールの中間データがツリーに直接保存されているという事実は大いに役立ちました。特に、ルール自体は、ゲームの状態ツリーでゲームを右に残した各スーツのカードに関する情報を記述しました。



すでに次のプロジェクトでは、ゲームのルールを確認し、各位置から同じエンジンに移動できるようにします。そして、一般的に、迅速なプロトタイピングだけでなく、単純に多くのルールがあるゲームにとっても、これは非常に便利なことです。結局、ロジックを備えたダウンロード可能なJSONは、プログラマーがコードで行うことの半分を置き換えることができ、柔軟性も向上します。



もちろん、実行速度の点では、これはすべてifの混乱よりも著しく劣っていました。特に、プロトタイプと動的オブジェクトを使用したAS2での実装では、それほどではありませんでしたが、本番環境に展開できませんでした。



次のステップは、ルールチェックを転送し、AIのアクションをクライアントコンピューターに決定することでした。プレイヤーがお互いをチェックするために。そして、敵のカードの値が私たちに知られていないという事実にもかかわらず、私はこれを行うためのそのようなアルゴリズムを思いついたが、それは完全に別の話でした。



何年も経ち、転職を十数回行い、履歴書を更新するたびにtoox.comにアクセスして、仕事がまだ続いていることに驚きました。私は別のゲームをするために立ち寄った。そして、ベロットに入ると、私は偶然、可能な限り最大のポイントを与えるカードのセットに出くわしました。そのようなセットを取得する確率は300万分の1です。



いつか私は一握りで私の意志を集めて、例えば、私が夢見ている六角形の戦略家のために、C＃とUnity3dのためにLogrusの現代的なリメイクを作ります。しかし、それは今日ではないでしょう、今日私は寝ます。広める価値のあるアイデアを広める義務は首尾よく果たされました。

結論として、いくつかの逸話

私たちはNovosibirskAcademgorodokにありました。研究所に事務所を借りました。そして、顧客はフランス人で、地元の習慣にまったく慣れていません。そして、共同作業の3〜4か月目に、彼は私たちを訪ねてきて、知り合いになります。私は週末に地元のホテル「ZolotayaDolina」にチェックインし、月曜日に彼はマネージャーに、午前10時にタクシーで私に会いましょうと言いました。私たちはプログラマーと知り合いに行きます。そして、Vovchikを連れて10に来てください。一般的に、彼らは研究所まで車で行き、ドアをノックします、そして反対側から警備員の祖母が来て、鍵のかかったドアの後ろから理解することなく彼らを完全に見ます。そのような早い時期には、建物内に事務所を借りている科学者やプログラマーはいませんでした。彼らは文字通り彼女を起こした。



そして、ここに別のケースがあります。どういうわけか私たちのセバスチャンペレイラはマネージャーに電話し、彼らは奇跡的にテレビに侵入することができたと言います、そしてすぐに私たちは私たちのウェブサイトでテレビに表示されます。約8時間後。それで、それをより確実に機能させるためにそこで何をしますか... 1月2日の時間...いつでも構いません...そして、Vovchikはタクシーに乗り、完全にスマットな状態の寮やアパートにプログラマーを集め始め、彼らをオフィスに連れて行きます。その日、私は生まれて初めてシステム管理者に会いました。この時点まで、彼はすべてをリモートで排他的に実行していました。そして、私たちはできる人一人一人をねじりました。特に、私はこのシステム全体を元の場所に戻すことで壊しました。ここでは、出席グラフを見ると、突然上昇し始めていることがわかります。 x15マークのどこかで、サーバーがクラッシュしました。しかし、管理者は、すべてが順調で、穏やかに落ちたと言いました、今、彼は立ち上がるでしょう。その日、サーバーはさらに3回クラッシュしました。