devtrackers.gg
This feature actually does exist. What you need to do is use the View Battlefield option at the end of the game, then mouse over the facedown cards you want to look at. #wotc_staff
This feature actually does exist. What you need to do is use the View Battlefield option at the end of the game, then mouse over the facedown cards you want to look at. #wotc_staff
Thank you for the report (and thanks /u/Judge_Todd for the ping). The nature of this bug is that while investigate is set up to create the token under your ownership and control, and it does count as a token being created, you aren't credited as being the one who created it, so Mirkwood Bat's "Whenever you create..." isn't triggering. We'll get the fix out as soon as possible. #wotc_staff
Any update on fixing this?
Can you clarify? I believe this was fixed in the SOI Remastered release as I said. Are there still scenarios where it is failing to transform properly? #wotc_staff
Love the article. Got a few questions:
- I’m very curious as to how a team decided to use a language with as notorious a reputation as lisp for a production system. But I’ve heard it’s great for developing sort of DSLs so it seems like a perfect fit, but I have to imagine it was a known risk to build the system in lisp for hiring reasons.
- Are any parts of the system open source?
- Are you using AI/ML internally for anything? Evaluating cards, simulating games, predicting mana costs, etc.
- Does Magic Online have a similar architecture or do they use a different approach?
Arguably the whole concept of "parsing cards" is AI. As are AutoTap and the system that navigates a player to the end of their turn if they run out of time (AutoResponder). And additionally we have a system called RoboQA that nightly plays hundreds of thousands of games against itself looking for ways to crash the game (it's the world's most experienced MTG player!).
After all, AI is a pretty wide term - it's "an artificial system that does stuff that are associated with intelligence". Still, all of our systems are as deterministic as possible - we don't leverage big data or probability distributions or randomization as a matter of course. Well, RoboQA does. #wotc_staff
Read moreBoth effects are type-changing effects that apply in same layer
613.8. Within a layer or sublayer, determining which order effects are applied in is sometimes done using a dependency system. If a dependency exists, it will override the timestamp system.
613.8a An effect is said to “depend on” another if (a) it’s applied in the same layer (and, if applicable, sublayer) as the other effect; (b) applying the other would change the text or the existence of the first effect, what it applies to, or what it does to any of the things it applies to; and (c) neither effect is from a characteristic-defining ability or both effects are from characteristic-defining abilities. Otherwise, the effect is considered to be independent of the other effect.
It appears to be an uncommon case where to find dependency one has to check result of ability, not only if it still exists or what it applies to. Since applying Fog changes what Gro...
Parse-wise, the bug here is that this is the first time I'm aware of for Arena where the dependency exists because of some "distant" clause in the rules text - the parser didn't see the contents of the "as long as" clause when considering what may be relevant for dependencies for the "Grond, the Gatebreaker is an artifact creature" phrase. The sorts of dependencies we've handled in the past are those like [[Ashaya, Soul of the Wild]], where the "required" types (Nontoken creatures you control) are in the same phrase as the "dependent" types (Forest lands).
We hope to get the fix out for this dependency issue soon. #wotc_staff
so why do you refuse to fix Golden Guardian?
Have you checked it this week? The fix was released with Shadows over Innistrad: Remastered. It took so long because the development team wasn't aware of it until somewhat recently; we're working on improving the user bug report pipeline. #wotc_staff
The link to this tweet was the main point (in which he asks where he should report the exploit to).
Thanks. Our team is looking into it. #wotc_staff
Tagging to get an official set of eyes on this.
The post has been deleted. Can you share what it was? #wotc_staff
What was the parsers first response to being fed Emrakul?
A syntax error due to being unfamiliar with the phrase "After that turn". #wotc_staff
Thanks for the info!
Oh, one other great reason is that the whole point of our regression tests is to identify situations where we end up generating wrong code. If we make a change for a future card that would break an old card (in a way that we've tested), we really want the old card's code to change too: our test will fail and we'll notice that the change we're making is the wrong change to make. If the old card's code is frozen, then our regression tests aren't really doing much for us! #wotc_staff
Did anyone else think from the title that "Pierce Flesh" and "Spirit Alike" were actually MTG cards and they had somehow made new card-breaking bugs after fixing Kunai/Crowbar lmao?
Thankfully not, though Pierce Flesh does sound like it would make a great black removal spell.
It's a reference to the flavor text of the Kunai! Thanks to /u/WotC_Megan for the idea. #wotc_staff
Why do you need to regenerate the rules for all cards on each release instead of freezing? Is it because new cards can change behaviors of old ones due to new mechanics?
Ack, sorry I missed this one! There are plenty of reasons to regenerate card code:
The biggest reason is consistency. We do not want to be in a world where two nearly identically worded abilities work totally differently because one was "locked in" years ago and behaves totally out of date. Worse yet would be something like two different printings of the same card behaving differently!
Frequently, updates we do to new cards want to apply to old cards too, particularly for rules-tangential behavior (client communication, autotap, trigger ordering, etc.). If we've identified behavior in an ability we want to treat differently for those tasks, it's good to apply it to all abilities with that behavior.
Rules changes aren't super infrequent in MTG. Having our code be regenerated makes it so that we don't have to manually identify which cards are affected by the rules change - as long as we correctly handle the new requirements ge...
How do you fix those? Do you hardcore fixes for those or can you develop generic solutions?
We almost never make kludges for cards - our normal workflow is to build solutions that would handle variation: what similar designs would have the same issue? Can we preemptively handle those? For example, for [[Muldrotha, the Grave Tide]], our solution made it so we could handle a similarly worded card that allowed you to play different colors of cards, or different land types, etc., even though Muldrotha is one-of-a-kind. #wotc_staff
Here's another instance of a weird "apply this effect to a permanent" occurrence: Urabrask's forge will destroy any available UF-created creature token, ignoring whether or not the token is "THAT token"
Example: Forge makes a token.
Phase the token out; UF finds nothing to sacrifice.
Next turn, a new token is both created and destroyed before the end step.
At this end step, UF will still sacrifice the first token from a turn ago, even though the oracle text does not refer to it.
Haven't yet tested this effect on copies of the token.
We are unable to reproduce this bug, on live or in our dev environments. Are you sure the reproduction steps here are accurate? #wotc_staff
Read moreThe rules have a concept of "printed on", and use it in the definition of characteristic-defining abilities and the rules for linked abilities, and also for the starting point of applying layers, as well as resolving object references by card name. To implement the rules in a way that conceptually matches how they are written, the Arena code should also recognize and use this concept. Copy effects and shenanigans with Vecna and such do complicate it a bit, though.
For reasoning about it, let's define a concept I'll call "effectively printed on", or "EPO". In the simplest case, without copy effects or shenanigans, an ability is effectively printed on the card that it is, in fact, literally physically printed on. Any reference by name to that card should be interpreted as referring to the ability's EPO card.
To determine an ability's EPO card in the presence of copy effects, it is necessary to distinguish between conferred and non-conferred abilities. A conferred abil...
I guess my point I'm trying to make is that we do have such a concept (it is a bit hard to discuss given that "ability" means three separate but tangled concepts in MTG). There absolutely is a relationship between an ability-on-card and the card that possesses it, and that's normally how self-references are interpreted. A large part of the complication here (and complication -> misunderstanding -> bugs) is that self-references mean different things in different contexts in MTG text. Your summary of the correct answer is pretty accurate, and it reflects our current logic, but getting there took some iteration and seeing more examples of abilities that contradicted our understanding. #wotc_staff
Read moreWhat's a "new feature" for us?
In my head I've always separated Arena out into "the actual game of Magic" and then "the bits Arena adds". So I guess new Rules (e.g. Incubate, I think that fits your Rule description), but then also new Arena bits (like the new Codex of the Multiverse)?
What if we have tests for "Draw two cards" already but now a card comes out with "Draw five cards" - is that a new feature?
I guess that depends on how your parser was set up, but I'd wager you've written the parser to be smart enough to say "Draw 2" is the same as "Draw 5" as those are two different tokens1 ("Draw" and
number). But then I guess that raises the question of something like is "Draw 1, then Scry 1" the same as "Draw 1" and "Scry 1" (i.e. combined vs separate)?Our line is "involved developer changes to the parser or engine"
Yeah that m...
Tokenization is a component of our parsing process, one very early in the process. It's true that replacing one token with another similar one is often not worth considering to be a big difference. But what about one sentence structure with another? For example "If you would draw a card, draw two cards instead" vs. "If you would draw a card, instead draw two cards" should behave the same despite being worded differently (and both are in fact valid wordings). If we already handled a phrase like "If CARDNAME would deal damage, it deals twice that much damage instead" as well as "If CARDNAME would deal damage, instead it deals twice that much damage", then we've already handled that syntactical difference. Let's say we wrote tests for the latter two cards; we'd find in ad-hoc testing that once we got either version of the draw replacement working (and wrote tests verifying it), the other one would work too. Given that it worked "out of the box", how much effort should we spend testing...
Read moreHow do you detect the 25% needing individual attention?
Two main ways:
The parser fails to generate code. This is great! It's recognizing that something is outside its current boundaries. We usually have a good idea of what we need to do from the error messaging.
The parser generates wrong code. Less great. Human QA needs to play the card to see that it's doing the wrong thing. The most common type of problem here is with "anaphora resolution" - figuring out what ambiguous phrases like "it" or "that creature" mean. Why, I just estimated the complexity of a few LTR bugs with that issue moments ago... #wotc_staff
How similarly does MTG Arena work compared to how MTG Online works?
Pretty broad question. In one sense, we're somewhat similar: we both make code happen starting from English strings from new cards to make a good MTG play experience. But our engineering is completely different, from code generation to the actual engine design. #wotc_staff
I thought the end of this story would be:
“Thank goodness!” said Bilbo laughing, and handed him the tobacco-jar.
Perhaps for an LTR implementation tale! #wotc_staff
As a noncoder, I found this super interesting. I know it’s more work for you but I’d love more of these posts when it’s relevant.
I'd love to tell more stories about "challenging developments that went smoothly". I think there's a couple challenges to that:
Less of a narrative! With a bug, there's an immediate hook of "how did that happen", then a cool investigation, a eureka of the issue, and often an embarrassingly simple fix (this bug was fixed just by deleting a line of code!). I think that makes for a pretty clear flow. Most implementation stories don't have such a narrative structure to them, which makes them harder to write about.
Scope of background. Even this post had coworkers dozing off with the groundwork I presented to describe the bug. New features are often even less cleanly described.
When? What? It can be hard after-the-fact to decide what would make an interesting story to talk about, or when to talk about it.
Still, the reaction to Ian's post and this has us pretty interested in doing more. Heck, I've always wanted to! I'm...
Read more