frwololo wrote:Whatever you do, you can't have a parser that will magically code the rules for you. Whenever a new mechanism comes out (i.e. pretty much every new expansion), you'd have to add additional code somehow. The parsing part is not the difficult part. Actually, most people who help on wagic find it rather fun to find tricky ways to have a card to work and bypass the current limitations of the engine.
You're going to have additional work either way... if your program is set up for parsing oracle text, you have less work to add the new features than to individually add every card with the new features.
frwololo wrote:Imagine a card that says:
{T}: target player has to say "abracadabra" 100 times. If he doesn't want to do it, you draw 3 cards.
Whatever parser you have, I'm pretty sure your engine doesn't handle that...
That's of course a very borderline case but you see my point.
That's not borderline... that's un-set material. There's a reason they don't print cards like
Chaos Orb anymore.
frwololo wrote:Also, NPL fails, as proven by all programming languages that try to look like natural languages. That is also why WotC keep coming with reprints and rewording for their cards, which wouldn't happen if the text on the cards was actually mathematic formulas or code. It means that the text on a card has several possible interpretations (which is why there are judges, too), which makes parsing difficult from a computer's point of view, for "complex" cards...which happen to be exactly the ones that most engines don't handle.
NPL doesn't
fail, especially if your input isn't actually
natural. Magic templating is very artificial, as the game rules have to avoid ambiguity at all costs. Parsing it is far from a pipe dream.
Also,
Inform 7 is a natural-language programming language that works quite well. Naturally a few constructs have to use "unnatural" language, and ambiguous wordings is a no-no, but that's to be expected, and it can fully support a wide variety of language constructs (for instance, you can give it a definition of an adjective (like "powered") and then use it in further sentences (like "all unpowered devices") and Inform knows what you're talking about).
frwololo wrote:Additionally, I strongly believe that there's no difference between handling 50% of the cards and 95% of the cards, as you'll always find people to complain about the missing 5%
There
is a vast difference, though. Saying there's no difference between two things just because people will complain about both is total nonsense, and the difference between an engine that can handle 5000 cards and one that can handle 10000 cards is massive, especially when you get into the terrain of custom cards (my eventual goal, once I have Incantus parsing card text, is to get it to successfully interpret an entire, 200+ card custom set, without errors).
frwololo wrote:THAT BEING SAID, your idea of parsing the initial text is extremely cool, and wagic could definitely use that if a translator "English" -> "Wagic card code" came out.
That's more-or-less what the current work with the card editor is doing (although it is, of course, translating it into
Python code that works with Incantus instead of code that works with Wagic
). My thought is that this is an unnecessary intermediate step; if we can successfully parse text and turn it into card code, we could just have the engine parse the text to begin with.
frwololo wrote:Edit: my point is that Wagic usually handles between 40 and 50% of a new set's cards before the set is even out (this represents roughly 3h of work that anybody with little experience can do, to compare to the dozens hours of work required to add new mechanics to the game), and I'm not sure a different parser would help in any way. The problem is the underlying engine. I'm convinced the issue would be the same for Incantus, even if the figures are different.
Before we broke the card format, thereby losing our thousands of implemented cards (but opening up the possibility of thousands more), we were generally implementing sets as they came out; and around 90% of each set could be done without major engine changes (generally just adding new keywords). Cascade was one of the few exceptions, and now our engine can handle it, too.
frwololo wrote:Having people writing the card's code is also a very nice way to build a community because non-developers can help a lot on this, and it helps them understand they are part of the project, which I think is rewarding. I think that's an extremely important point.
Plus if you want people to be able to create their own cards, good luck teaching them the rules of english so that the parser doesn't make mistakes. It's probably doable to parse the MTG cards, but how do you teach people how to "speak the correct english that the parser will understand" ? Parentheses are much better than words in that case I believe. Not mentionning the parsing nightmare on low resource machines (which, granted, is already the case in WAgic, but for different reasons)
In that case, isn't helping people learn better English an admirable goal?
I honestly don't see this as a problem; you don't see people arguing that we shouldn't use programming languages because people have to learn the grammar and syntax of programming languages for the computer to understand them. It's simply expected. If we decide to do it this way, we shouldn't cater to laziness. I'm not saying
all projects should do direct text parsing, but I don't see any reason not to do it in Incantus.
Even supposing we have to change a few cards to have more rigid and unambiguous wordings (which I would not readily suppose),
so what? Isn't the effort saved on all the thousands of cards that will require no human effort to run in-game worth it? Just imagine the infinite possibilities for custom cards that will require no actual coding to play with!