言語指向プログラミングの使用例

言語指向プログラミング（LOP）の考え方は、プログラムの開発中にミニ言語が絶えず作成されるということです。 これらは、メインの開発言語を拡張することも、別々の言語にすることもできます。 LOPの最適な言語はマクロを備えたCommon Lispですが、これはそれについてではありません。 Common LispでLOPを使用する例については、Peter Seibel Practical Common Lispによる素晴らしい本をご覧になることをお勧めします。 LOPは最も簡単で効果的なプログラミング方法の1つであると考えています。 これに最も適切な言語でタスクとサブジェクト領域を説明し、それを実装しようとします。

私はブラウザーゲームをRubyで開発しているため、言語の拡張と組み込みDSL（Rubyを使用するとこれを非常にうまく行うことができます）、および複雑なゲームメカニクスに関連するミニ言語の作成の両方にLOPをよく使用します。 この記事では、メイン言語の単純な拡張機能である組み込みmini-DSLと、2つの非組み込み言語について説明します。 私は自分に近いトピックで例を挙げます。それらがかなり理解できることを願っています。



この記事はCrazyPit habrayuzerによって書かれましたが、彼には公開するカルマがありません。

シンプルな言語拡張

オブジェクトを操作しながら特定のアルゴリズムを実行するクラスが必要になることがよくあります。 もちろん、すべてのメソッドをメインクラスに入力できますが、これは不必要な目詰まりになります。 さらに、アルゴリズムは、メインクラスではまったく不要ないくつかのメソッドと例外を使用できます。

プレイヤーは、彼が編集したいくつかのデッキ（プレイヤーが収集可能なカードゲームで使用するカードのセット）を持っています。 いずれかのデッキを選択する必要があります-有効にします。 これを行うには、アクティベーションアルゴリズムを実装する別のクラスを作成します。

デッキ::アクティベーター= Struct.new（：デッキ）
クラスデッキ::アクティベーター

    def activate！
      ......
   終わり 

   プライベート
    <一部のヘルパーメソッドと例外>
終わり

このモジュールは次のように使用できます。

デッキ:: Activator.new（some_deck）.activate！

しかし、はるかに美しい：

 deck.activator.activate！

 ＃またはそのような

 deck.activate！

これを行うには、Deckクラスにメソッドを追加します。

クラスデッキ

   def activate！
     デッキ:: Activator.new（some_deck）.activate！
  終わり

終わり

しかし、このようなアルゴリズムがたくさんあるので、私はわずかな改善を行いました。これは戦略クラスのメソッドです（同じ名前のパターンに直接関係していません）。 今、私はこれを行います：

クラスデッキ<ActiveRecord :: Base
  戦略：アクティベーター
終わり

 Deck.find（：最初）.activator.activate！

または：

クラスデッキ<ActiveRecord :: Base
  戦略：アクティベーター、：デリゲート=> [：アクティベート！]
終わり

 Deck.find（：最初）.activate！

デフォルトのアルゴリズムクラス名は、<メソッドが呼び出されるクラス名> :: <戦略で指定された名前>です。 ただし、手動で設定できます（：クラス=> BrainDestructor）。

Ruby自体とRoRの両方に、このような拡張機能が多数あります。 Rubyで多くのプログラミングを行った人は誰でも似たようなことをしたと思います。

制限を示す組み込みDSL

ゲームにはさまざまな部屋があり、すべての人が許可されているわけではありませんが、プレーヤーが特定の規則を順守している場合のみです。 たとえば、レベルが10を超えているか、デッキ内のカードの数が8を超えていません。このような制限は組み合わされています。 たとえば、「プレイヤーレベル> = N」などの制限の種類があり、「プレイヤーレベル> = 13」という特定の制限があります。

DSL define_constraintを使用して制約のタイプを指定し、制約とその組み合わせをデータベースに保存できます。

   define_constraint "deck_sum_between"、 "％Nと％Mの間のカードレベルの合計" do
     （引数['N']。to_i..arguments ['M']。to_i）.include？（context.deck.sum_of_card_levels）
  終わり


   define_constraint "deck_without_duplicates"、 "テイクのないデッキ"は
     ！context.deck.has_duplicates？
  終わり

   define_constraint "user_level_ge"、 "プレイヤーレベル％X以上"
     context.level> =引数['X']。to_i
  終わり

制限の各タイプでは、名前（deck_sum_between）、「％Nと％Mの間のカードレベルの合計」という説明を設定します。この説明から、パラメーターに基づいて、特定の制限の説明が取得されます。 そしてもちろん、プレーヤーまたは他のオブジェクトが制約に適合する場合にtrueを返す制約の実装。 したがって、システムは普遍的であり、ユーザーではなくコンテキストです。
結果として、deck_sum_between（N => 10、M => 20）のように制限を記述したり、オブジェクトのさまざまなプロパティに名前とパラメーターを保存したりできます。

言語は制約の論理式です

ゲーム開発では、多くの場合、アルゴリズムの形成に基づいたいくつかのルールをデータベースなどに動的に保存する必要があるため、ゲームアルゴリズムは管理フォームから文字通り変更できます。 この例と次の例では、このような2つの言語について説明します。

基本的な制約のリストで実装できる単純な制約ではなく、より複雑な論理式が必要な場合があります。

例：プレイヤーレベル> 10 ANDデッキサイズ<= 8 ANDカード（クラン1、2、3のカードまたはクラン4、5のカード）。
これを設定する式言語が作成されています（ここでは、前のセクションとは少し異なる種類の基本的な制限が使用されています）。

 （およびuser_level_ge（12） 
      deck_size_le（8）
      （またはdeck_has_only_clans（1,2,3） 
          deck_has_only_clans（4,5,6）））

Iの大規模なリストを含む制限のリストでそれをより便利にするために、少しlispスタイルを使用しました。

次に、この行を部屋モデル（room.restrictions_string）に保存します。 parsim文字列の制限を計算する必要があるときに、すべての基本的な制限と全体の結果を計算して、クライアントに渡します。 プレーヤーは、必要な条件と、合格しなかった条件を確認します。

ブースタールール記述言語

ブースターは、収集可能なカードゲームで販売される一連のカードで、特定のルールに従ってランダムなカードがいくつか含まれています。 たとえば、沼地住民の5つの中規模マップと1つの良好なマップ。

カードを生成するための各ルールは、テキストで説明できます。

希少性（1）-不正なカード（番号はルールに設定されています。詳細は後ほど）
希少性（1）|氏族（6,7,8）-氏族6,7,8の不良カード1枚。 「|」 ここでは、論理ORではなく、UNIXパイプラインを象徴しています。

確率でルールも可能です：

クラン（1,2,3）|期待（1,60,2,38,3,2）-クラン1、2または3のカード。 60％の確率で-悪い、38％の確率で-中、3％の確率で-良い。

各ルールは、次のようなActiveRecordスコープメカニズムに基づいて実装されます。

   def rule_clans（スコープ、ID）
     scope.scoped_by_clan_id（ids）
  終わり
  
   def rule_expectance（スコープ、パラメーター）
     scope.scoped_by_rarity（Expectance.for_expectance（ハッシュ[* params.map（＆：to_i）]）））
  終わり

ところで、ここでも、言語を拡張し、説明をもう少し簡潔にすることができました。

ルールは組み合わされて削減されます：

   def generate_card_original
     rules_scope = rules.reduce（カード::オリジナル）do | scope、rule |
       rule.add_scope（スコープ）
    終わり
     rules_scope.randomly.find（：最初）
  終わり

その結果、ルールの複雑さに関係なく、カードごとに1つのリクエストを受け取ります。

問題は、あるルールに従って5枚のカードを生成し、別のルールに従って2枚のカードを生成する方法です。 いくつかのオプションがありますが、このクラスのBooster has_manyジェネレーターを使用しました。 Generatorクラスのオブジェクトには、カードの数と、各カードが生成されるルールが格納されます。 しかし、ベース言語を複雑にし、すべてのブースタールールを1行で書き留めることができます。

  5 [希少性（1,2）]、2 [クラン（1,2）|期待（1,60,2,40）] 

おわりに

私は日常の練習でLOPを使用する例を示しました。 多くの場合、DSLを実現することなく使用します（XMLを指定するインターフェイスなど）。 ただし、DSLを作成する開発者はごく少数です。 この記事があなたに問題の詳細な研究を促すことを願っています。