Collectible Card Game Headquarters

As you know, one of the things on my to-do list is to make Incantus parse oracle text directly. As a necessary first step for that, we need to define a formal grammar for Magic (for those of you wondering what a formal grammar is, read this). Since trying to define a formal grammar with all the possibilities in Magic by yourself is *ahem* difficult, I thought I'd ask if anyone was interested in helping.

I've already written the first line for you:

Code: Select all

<ability> ::= <activated-ability> | <triggered-ability> | <static-ability> | <spell-ability> | <keyword>

Anyone care to contribute some more ideas?

EDIT: Actually, this would be better:

Code: Select all

<ability> ::= <activated-ability> | <triggered-ability> | <static-ability> | <spell-ability> | <keyword-line>
<keyword-line> ::= <keyword> <EOL> | <keyword> ", " <keyword-line>

As MageKing is already aware, I am slowly developing a grammar. At this point it's able to do very basic things, including parsing some static and activated abilities.

Hopefully I'll have something to show by the middle of July.

proud wrote:As MageKing is already aware, I am slowly developing a grammar. At this point it's able to do very basic things, including parsing some static and activated abilities.

Hopefully I'll have something to show by the middle of July.

Hell, you've got interesting stuff to show now.

Seriously, folks, I fully intend to see if I can somehow incorporate his grammar into Incantus at some point, it's pretty cool. Also, it saves me the effort of having to do it myself.

I wonder if a card-code-less Incantus should be v0.8.0... Of course, there'll obviously have to be a lot of testing before we cut out card code entirely. I'm thinking more of bringing back the editor and having it generate code based on the grammar, so we can see how accurate its results are.

And, of course, even if we integrate oracle parsing into the main Incantus program, I'll probably still allow card code for wacky shenanigans ("We demand wacky shenanigans!"). In fact, speaking of wacky shenanigans, I should make sure v0.7.1b has some sort of rulemods example...

Ha!
We are moving in the same direction
We started implementing oracle parser grammar in MagicWars about 1-2 months ago. We use ANTLR for that, parsing oracle text with lexer and parser, and then building cards with commands. Though we are at the very beginning, the steps to add new cards become easier day after day:

1. run perl script that will generate card from gatherer and type card name
card name> Thorn-Thrash Viashino
it will generate Thorn-Thrash Viashino.groovy

Code: Select all

name = "Thorn-Thrash Viashino"
manacost = "3 R"
types = [ "Creature", "Viashino", "Warrior" ]
power = 2
toughness = 2
text = ["Devour 2","{G}: Thorn-Thrash Viashino gains trample until end of turn."]

prints = [
   ["ALA", "C", 175064, 116]
]

2. copy this file to cards folder and voila! you may play with it, no additional scripting is needed

sad you're coding on python, we may combine our efforts

~regards

I can tell you right away that putting subtypes into the types list is a mistake unless you're very carefully maintaining lists of what's a type and what's a subtype.

As of the last time I saw it, proud's grammar was also being written in ANTLR. Of course, it doesn't matter how the grammar is written; the logic can be duplicated in any language you choose.

Making the user generate the cards outside of the program is ultimately a mistake, in my opinion. My/our eventual goal for Incantus is run-time ability parsing, as this would make implementing text-changing effects incredibly easy. Of course, I'd still allow card files to be made if you want to do something the parser can't figure out, although I suspect rulemods are probably going to be the best way to do that (augment the parser at run-time).

What happens when (not if) Oracle/Gatherer changes syntax?

Huggybaby wrote:What happens when (not if) Oracle/Gatherer changes syntax?

You update the grammar to accommodate it.

The idea is really awesome. The engine can try to load the card text from whatever location you have cards hardcoded. If the card isn't found in this location then the next step is parse oracle text at run-time. If parsing fails then produce some kind of sane error (the 0 mana artifact in-game with Incantus for example). That kind of implementation sounds REALLY sweet.

One thing confuses me though (well, at least one thing ). Wouldn't the primary function for rules mods be "allow you to play different types of magic games"? For example EDH, or two-headed giant variants would be mods for starting life totals, sharing partially hidden information (cards in hand), having the separate command zone, and so on?

Huggybaby,

That's a good point. Perhaps a periodic download of Oracle text is the way to go anyway. I am sure that caching the text would help run-time performance instead of loading Oracle text on every startup, although I don't know what kind of expiration date would be good for the cached files (1 month?). Also without knowing the size of the Oracle text downloads we may need to clean up old ones quickly; say, 1 year old Oracle text.

Another upside to caching data is you can "fool" the engine into using an old Oracle file for the period of time when things are broken by new syntax. Just update the timestamp on the file (or create a new one with the old data) and voila, temporary fix. We know that engine fixes take time and this could be the stopgap solution.

Better than downloading might be using the files put out by Arch... He updates quickly, and it's not that big.

juzamjedi wrote:The idea is really awesome. The engine can try to load the card text from whatever location you have cards hardcoded. If the card isn't found in this location then the next step is parse oracle text at run-time. If parsing fails then produce some kind of sane error (the 0 mana artifact in-game with Incantus for example). That kind of implementation sounds REALLY sweet.

One thing confuses me though (well, at least one thing ). Wouldn't the primary function for rules mods be "allow you to play different types of magic games"? For example EDH, or two-headed giant variants would be mods for starting life totals, sharing partially hidden information (cards in hand), having the separate command zone, and so on?

EDH and two-headed giant might be possible with rulemods, but I'd think those could be coded into the program itself (probably as menu options). As I said in the rulemods thread (at least, I hope I did), the primary purpose of rulemods is to change things related to cards, not the rest of the game, although it can obviously change game-related things as long as they haven't already been finalized before the rulemods have a chance to load (for instance, ManaCosts, as in the rulemods example).

juzamjedi wrote:Huggybaby,

That's a good point. Perhaps a periodic download of Oracle text is the way to go anyway. I am sure that caching the text would help run-time performance instead of loading Oracle text on every startup, although I don't know what kind of expiration date would be good for the cached files (1 month?). Also without knowing the size of the Oracle text downloads we may need to clean up old ones quickly; say, 1 year old Oracle text.

Another upside to caching data is you can "fool" the engine into using an old Oracle file for the period of time when things are broken by new syntax. Just update the timestamp on the file (or create a new one with the old data) and voila, temporary fix. We know that engine fixes take time and this could be the stopgap solution.

I wouldn't recommend automatic oracle updates anyway; we have enough problems as it is when something goes wrong with the image-downloading code. The more pieces of data we do not control, the more likely things are to go wrong, and I don't think there's any big problems with just including an oracle database with the release.

Work has been progressing slower than I'd hoped, mostly from the July 4th holiday weekend, a wedding last weekend, and both finding a new place to live and now moving there at the end of the month.

Anyway, keywords are all done and now it's a matter of reading formats correctly; at first there will still be many cards that will be broken, but this should ease over time.

Obviously, a grammar does little good without a layer to implement abilities and such into the game, though MageKing appears confident this shouldn't be too hard.

Look for another post with a couple of examples from the grammar and its parses in the next couple of weeks, hopefully by early August.

That's great! Can't wait to see the examples.

proud wrote:Obviously, a grammar does little good without a layer to implement abilities and such into the game, though MageKing appears confident this shouldn't be too hard.

Based on my own experience with oracle parsing for the web editor, I have no doubt that proud's grammar should be implementable for Incantus. The tricky part (besides the grammar itself) will no doubt be making it work at run-time. I suppose we'll have to wait for v0.8.0 for that...

Did this go anywhere?

I had a look at doing something like this myself a while back but couldn't find any "easy" way of doing it. Seemed like the only way was to just more or less go over all the rules by hand. (By my count that's about 10k unique rules.) While good abstractions would probably allow for the work to accelerate at some point it's still *a lot* of work.

Arch wrote:Did this go anywhere?

Sort of. Proud ran into a dead end with ANTLR, but I've been working on improving the existing oracle parser, and it can now parse a wide variety of (simple) effects.

Arch wrote:I had a look at doing something like this myself a while back but couldn't find any "easy" way of doing it. Seemed like the only way was to just more or less go over all the rules by hand. (By my count that's about 10k unique rules.) While good abstractions would probably allow for the work to accelerate at some point it's still *a lot* of work.

Basically, that's all you can do. But on the plus side, once you were done, think of the number of cards that would work without any effort directed at them!