3 ms·

You might enjoy this official article on a bug in Arena rules engine that goes into how they designed their systems. https://magic.wizards.com/en/news/mtg-aren

You might enjoy this official article on a bug in Arena rules engine that goes into how they designed their systems. https://magic.wizards.com/en/news/mtg-arena/on-whiteboards-naps-and-living-breakthrough https://magic.wizards.com/en/news/mtg-arena/on-whiteboards-n...

mdaniel 3y ago
That's interesting, thank you. It seems what's old is new again: I had a lot of contact with CLIPS early in my career but I found that most of the programming tasks weren't heavy rules based as much as CRUD and reporting apps. Given that Forge is in Java, they may enjoy Drools <https://github.com/apache/incubator-kie-drools#readme https://github.com/apache/incubator-kie-drools#readme> (which used to be a JBoss project but I guess has been donated to the Apache Foundation)
LelouBil 3y ago
> Now we come to the other program that we rules engineers spend our time working on, along with the GRE, which is the Game Rules Parser (GRP). This program (written in Python) takes raw English rules text of Magic cards and converts them into one or more CLIPS rules. It's what allows 80% or so of newly written Magic cards to just work in MTG Arena automatically. Wow, didn't even think about this being a possibility! But I guess if they have a very strict dictionary and grammar rules for card effects this kind of thing can work !
- moate 3y ago
  Tons of creatures with only evergreen/deciduous abilities would probably be super easy to template for something to parse, as would most lands. 80% feels “right” as someone who’s done some game design in the tabletop space.
  - OskarS 3y ago
    Yeah, obviously a creature with Haste or Trample or whatever is very easy to make a simple parser for. But I can imagine because WotC is so strict on how they word text on cards, even more advanced interactions would be pretty straight-forward to parse. Like, if a card says: "When <card name> enters the battlefield, return target non-land card from your graveyard to your hand". Both parts of that sentence is always worded the same, so it's probably quite straight-forward to make a parser for this: just have a parse rule for "When <card name> enters the battlefield, <triggered ability X>", with a database of triggered abilities (and their implementation) that include all the ones that have already been printed.

mdaniel 3y ago

That's interesting, thank you. It seems what's old is new again: I had a lot of contact with CLIPS early in my career but I found that most of the programming tasks weren't heavy rules based as much as CRUD and reporting apps. Given that Forge is in Java, they may enjoy Drools <https://github.com/apache/incubator-kie-drools#readme https://github.com/apache/incubator-kie-drools#readme> (which used to be a JBoss project but I guess has been donated to the Apache Foundation)

LelouBil 3y ago

> Now we come to the other program that we rules engineers spend our time working on, along with the GRE, which is the Game Rules Parser (GRP). This program (written in Python) takes raw English rules text of Magic cards and converts them into one or more CLIPS rules. It's what allows 80% or so of newly written Magic cards to just work in MTG Arena automatically. Wow, didn't even think about this being a possibility! But I guess if they have a very strict dictionary and grammar rules for card effects this kind of thing can work !

moate 3y ago
Tons of creatures with only evergreen/deciduous abilities would probably be super easy to template for something to parse, as would most lands. 80% feels “right” as someone who’s done some game design in the tabletop space.
- OskarS 3y ago
  Yeah, obviously a creature with Haste or Trample or whatever is very easy to make a simple parser for. But I can imagine because WotC is so strict on how they word text on cards, even more advanced interactions would be pretty straight-forward to parse. Like, if a card says: "When <card name> enters the battlefield, return target non-land card from your graveyard to your hand". Both parts of that sentence is always worded the same, so it's probably quite straight-forward to make a parser for this: just have a parse rule for "When <card name> enters the battlefield, <triggered ability X>", with a database of triggered abilities (and their implementation) that include all the ones that have already been printed.