Conversation: Recent Activity
| Conversation: Cardlist | Visual spoiler | Export | Booster | Comments | Search | Recent activity |
| Mechanics |
Recent updates to Conversation: (Generated at 2024-04-18 22:40:22)
| Conversation: Cardlist | Visual spoiler | Export | Booster | Comments | Search | Recent activity |
| Mechanics |
Recent updates to Conversation: (Generated at 2024-04-18 22:40:22)
SecretInfiltrator said: >
, Spot three artifacts you control: Tap target creature.
Common Activated Abilities requirements could be put in the cost part, before the colon :
Metalcraft -- Control three artifacts: ~some effect~
Threshold -- Have seven cards in your graveyard: ~some effect~
Including a new keyword "Sorcerous", to denote an ability only activated as sorcery.
, Sorcerous: ~some effect~
"Field" instead of "battlefield" seem good to me; not all permanents will be engaged in combat, anyways.
One concern that I have is, would there be the rules for them written out fully, in order to know exactly their working? Having read some things about Hearthstone (although I didn't play, I know some people who do), it seems to be more difficult to understand than Magic: the Gathering due to some rules being less clear, more confusing, some cards having text differently describing than their actual effect, etc. When making up a game, you should write the rules, so that you can read so that you will know how to play this game.
I like Perpetually- it's the kind of feature that can fit well into a card game digitally while not changing the feel of the game.
Seek is something that I'm a bit more wary of, though that's more for deckbuilding to eliminate the random aspect of Seek rather than Seek itself.
Conjure is the one I'm hesitant with, because rng was something Hearthstone was heavily criticized over.
Not to mention Magic already did this once. It's called the Astral set, and I don't think those cards cheapened the old Microprose game...
This has a lot to do with restraint. As long as they don't make Arena unrecognizable from paper Magic, then it shouldn't be a big problem. It will admittedly feel weird, however, if the Digital Historic format deviates considerably from Historic.
Every other format has cards that are only available or only playable in that format. I don't see a problem with Digital Historic joining that group. It's not like Un-cards or Commander precons broke the game.
How long before we can call Arena Magic-in-name-only? Before or after they stop bothering with the actual card game?
See Announcement
I saw it and posted a followup on his set, over here. It sounds like he's all set for now :)
Messing with Forge, several phrases I use.
"withdraw" for "return from field to hand"
whole bunch of evergreen keywords (my project to provide all color pairs with balanced evergreen keywords. Each color pair gets 3 positive and 1 negative evergreen keyword)
Have you tried Forge? Am confident it is the best way to play Magic (on electronic device).
Card physical dimensions necessitates terse rules text. Am not convinced computer language can be more terse than natural human language. Human language may consists of unwritten implications and suppositions. Otoh every detail must be spelled out in order for computers to calculate accurately, according to intended purpose. Humans can (usually) understand despite (some) omissions.
Sorry, fishMaster. The site was down for a bit. I bet nobody has seen your comment.
Perhaps if I bump this someone who's here more often will come along and help you out.
Hey, I just got here, and am trying to work on making a set. The layout and workings of the page are really confusing to me though. I can't seem to generate a set skeleton, and none of my cards show up in the card list. Is there any kind of tutorial resource for getting to know the site?
I kinda like the idea of writing a program that would present the "true" state-engine that magic is. However, if you think it would be more consistent that reading and interpreting those rules from a rulebook, I think I might have some bad news for new - software programs of this complexity are often riddled with bugs. Basically we're talking about a more nuanced MTGO (not arena since that's simplified) and you might know that MTGO isn't exactly the paragon of, well, anything really.
So I would imagine that what would ideally act as a constant/standard to which compare results of specific rules interactions, might just become a long list of legacy bugs that takes forever to ever become addressed - especially knowing the track record of WotC digital/software/online departments.
I would call it a "nice exercise" but dunno about relying on it.
Yes, it is mostly from computer programming, although mathematical structure has something to do with it as well (especially if you are programming in Haskell, which isn't a programming language I really use much to write actual programs (I prefer C), although I do sometimes use it).
You can't say they are equal to each other because they are not value of the same type ("type" here in the sense used in Haskell, not the sense it has in Magic: the Gathering, which is different), so you can't compare them for equality. So, if the name of an object can be based on the subtype that a token is created with, then it must be embedded in the possibility of names. While using the spelling in English of the individual words would be a possible way to do that, that violates the AST principle that I mentioned, doesn't seem very nice mathematically, and also is potentially confusing for players of foreign cards. (Actually, it is how I thought it worked before I found out otherwise.)
An example of a "mana step" is rule 601.2g. There are some other rules that allow mana steps too, but mainly it is rule 601.2g.
"And, at least to me, what makes sense mathematically is that the two objects don't "have the same name"; the names just happen to have the same spelling.
To me, you're saying that when the values (spelling and words) of two things exactly equal one another, that in some world it makes sense that those things... wouldn't actually equal one another? That just doesn't say "mathematically sensical" to me. Maybe you have a different perspective on what constitutes "mathematical" to me. You definitely have a deeper background in programming, which is where it sounds like you're actually coming from.
A one-shot property is a property of an object or player which is affected by one-shot effects and not by continuous effects (although some of them may have continuous effects, such as counters). A persistent property is a one-shot property that persists across zone-changes (such as ownership and initial text).
Maybe it's just how tired I am, but this didn't clarify anything for me.
A mana step is when you get a step inside of some procedure to activate mana abilities (currently, the rules don't seem to call this step anything, and that makes it difficult to discuss).
Could you give an example of this?
It isn't an entirely different game (nearly everything is the same; the effective rule changes are less than Wizards of the Coast did actually).
And, at least to me, what makes sense mathematically is that the two objects don't "have the same name"; the names just happen to have the same spelling. It is an enumeration, like I said, and they are two separate enumerations. The rest of the rules seem to support this use, but the interpretation of rule 612.2a seems to be different.
A one-shot property is a property of an object or player which is affected by one-shot effects and not by continuous effects (although some of them may have continuous effects, such as counters). A persistent property is a one-shot property that persists across zone-changes (such as ownership and initial text). A mana step is when you get a step inside of some procedure to activate mana abilities (currently, the rules don't seem to call this step anything, and that makes it difficult to discuss).
I feel like zzo38 is trying to create an entirely new game that happens to use Magic cards as the pieces
You realize that in many ways it's more confusing if two objects with the same name don't have the same name, right? Also... That's an incredibly niche situation. Linking the cards you mentioned for later readers: Artificial Evolution, Giant Slug
DFCs can be face-down, though, I think? They can be placed onto the battlefield face-down. They just can't be turned face-down later.
What is a one-shot or persistent property? What is a mana step??
Different tokens created with the same set of subtypes would have the same name as each other (unless the name is overridden). If "create an 3/3 Illusion Slug creature token" as modified by Artificial Evolution can create a token with the same name as the card Giant Slug, then rule 612.2a is messy. That is why I am suggesting making the names not the same unless the token is given an explicit name (e.g. "create ... named Giant Slug"), in which case the name will be the same as the card name with the same spelling.
(PS: Also, I would not prohibit meld permanents and double-faced permanents from being face-down. Maybe they prohibited it due to being difficult to represent, but I think it isn't difficult to represent. Represent it by placing the substitute card face-down on top of the other card; or, if you are using opaque card sleeves instead, by placing it so that the opaque back is visible.)
(More PS: Also, I would define more terminology, including "one-shot property", "persistent property", "initial text", "effective initial text", "kind", "mana step", etc. When discussing Magic: the Gathering (including the rules, custom cards, puzzles, and more), I find such terminology to sometimes be useful. This (probably) does not actually change the rules of the game at all; it is merely descriptive.)
(Even more PS: Rule 116.2e should be unnecessary; the card ought to explicitly say that it is a special action, so that it would not be needed. This should also be the case for 116.2c, and on my own custom cards (e.g. Evil Barber, which is card 120498 on this site) I did explicitly say that the effect can be ended as a special action, because I think that is clearer.)
(Even more even more PS: "Flip a coin" should be a keyword action: choose heads or tails at random. Actually, it is effectively two different keyword actions; in one case, you can also win or lose the coin flip too, and in the other case, you can't.)
(Even more even more even more PS: What happens to objects whose owner has changed once the top-level (i.e. not a subgame) game has ended should properly be beyond the scope of the game rules (it belongs in the match rules instead); once the game ends, all objects and effects cease to exist, so there is no "owner".)
Enumerated types are just a bunch of unique constant labels, typically ordered/enumerated. I think what zzo38 wants to express is that they want names to be separate from any other characteristic, but feels token names are composites of their types, though technically since there is a finite number of tokens produced in the game there is no reason they cannot be enumerated with cards.
I would have to look up their suggested changes to recall how they want to handle different tokens with equivalent types.
Which game principles do the current rules governing token names go against, and why do you think they're mathematically bad? I'm unfamiliar with enumerated types. Would such familiarity help me understand your complaint?
I'm struggling to understand you and your desires. It's like we're speaking a different language most of the time. Sorry for asking so many questions.
The AST that it might already have is not useful if it isn't open source. About text-changing effects relying on it, usually the rules and printed text would usually make it clear what is meant, so you usually would not need to refer to the AST in most circumstances (and text-changing effects are uncommon anyways). But, the AST would make the rules more mathematically precise, and would be available in case something is unclear. (Just a few minutes ago, I noticed the custom card 108436 on this website. It mentions "spells that reference artifacts"; this would be simple to define with the AST; if my RDF-based format is used, then simply if
:artifactis referenced as part of the object's AST (the rules would clearly define which edges of the graph cannot be traversed in this way).) (There are some open source implementations of Magic: the Gathering, but none that I have seen implement text-changing effects, and they are rather limited in other ways too. Maybe something like my ideas would allow them to be implemented better; I don't know.)For the namespacing of card names, as I said (perhaps I was unclear), no change is needed unless I was somehow head of WotC and made everything public domain. Therefore, that part can be ignored. (Maybe I should not have mentioned it, because it is just causing confusion.) But, for custom cards, you can already do something like this; even if the spelling of the name is the same, they compare unequal if they are two different cards. (For Un-cards, use the spelling instead.)
For token names, I do find it mathematically messy; I wrote some rules that I think are better. (The existing rules are mathematically bad, goes against the other principles of the game, doesn't work well with the AST, and depends on spelling, which it shouldn't. Consider the data type of the creature types and other subtypes as an enumeration type; it is clearly a different enumeration than the names are.)
I am not forcing anyone to change anything; I am making suggestions because that is the question that was asked. Many things are already good how they are, and some are changed in some custom card sets (and/or as an optional setting in an open source program which implements Magic: the Gathering) even if they are not changed officially is OK.
IIRC the digital cards are already using a scheme that probably can be plotted to/from the AST, so the "extra work" may to great parts have happened already.
I'm also wondering what the point of namespaces is when silver-bordered already violates the reason we care about unique names - at least as something featured in the canon rules. For custom creation databases namespaces obviously make sense, but so does allowing name collisions. Just look at this site! Imagine how silly it would be to use the names of cards as their key!
I don't understand how the current token naming rules are messy. They're pretty smooth: if the text that creates a token doesn't assign it a name, the name mirrors the subtype. That's simple, easy to understand, and requires little extra work from either the card creators or the players.
Your AST/RDF desires sounds like it would create a lot of extra work that would result in little to no gain for anyone involved. You say that the average player doesn't need to understand it, but you also mentioned that text-changing effects would rely on it; you can't have both, right?
It sounds rather more like you should be designing your own game than trying to retroactively apply the changes you desire to this one. I don't mean that as an attack of any kind; I'm just wondering whether you realize that yourself.
Subtypes are separate from card names. The existing rules cause them to use the ones with the same spelling in English, which is rather messy way to do it. Making them separate namespaces would be better, that spelling does not matter.
"AST" stands for abstract syntax tree. The average player should not need to be able to interpret the AST; this has no effect on the way cards are printed, and it would not be mentioned on the card (it would just be called an object's text, in the rules as well as printed on the cards). Rather, it is a mathematical abstraction. It could be included in Oracle text though; the RDF representation can be included in addition to the English text (only the English text (or text in some other language, such as Japanese) would be printed on the cards). (Example: "Counter target spell" has RDF representation is
[:counter [:target :spell]]; "This object deals 3 damage to any target" has RDF representation[:damage 3; :to [:target :damageable]].)How is the way token names function mathematically inelegant?
What does "AST-based" mean, in this context, and how would it alert the functionality of the cards? Do you think the average player would be able to interpret it?
If you do not want to read the computer code, you can ignore it. The text would be much like the existing Comprehensive Rules, but with each rule would be the computer code that implements it after the text. It can then be compiled and executed on a computer. See "Literate Programming" on Wikipedia. Many computer programs have been written in this style, such as TeX. This specific use is somewhat different from ordinary literate programming, but I think that it might be able to do.
One way that it is mathematically inelegant is how implicit token names work. (My own rules for my custom cards fixes that.) There are some others too, although some have already been fixed (e.g. they removed the planeswalker redirection rule, which is good, because I didn't like that rule; they also removed the Legend creature type, which is also good because the rules related to it was really messy) (although also some might have been made worse). I think the rules that creatures can't be attached to stuff, and that "legendary" means something entirely different for instants/sorceries, are rather klugy, too. I would also make all text-changing effects to be AST-based (except where silver-bordered cards are involved).
I also wrote rules for banding that I think are somewhat clearer than the existing rules (see my "Ziveruskex and Strixan" set for this and other rules), although as far as I know, with all official cards they will usually do the same thing (except in some uncommon circumstances, I think).
Okay. You might be perfectly clear, and it's just that your desires are so far from what I would expect from anyone that my perspective made you seem unclear. That's an issue with me, though, not you.
Including computer code would clarify things only for a very small subset of players, right? Code is gibberish to me, personally. But maybe that's just my perspective.
What would you do to make Magic more mathematically elegant? In what ways do you think it's mathematically inelegant?
I am not trying to be trolling; sorry if I am unclear.
The rules as a literate computer program would, I think, make the rules clearer than the existing Comprehensive Rules. (A literate computer program means that it is also a book, so it interleaves the text of the book with the code of the program (which is also printed in the book); since these are the rules of the game, implementing it this way (using the Comprehensive Rules mostly as they are, as the text of the book) is helpful, since it should be readable by the player; the computer code included with it can help to clarify a few things which might be unclear, since you can then just execute the program to determine the effect.) More mathematically elegant and precise is, in my opinion, just a good idea in general. When possible, the rules of most things (not only this game) will just work better that way.
Namespacing would ensure there are no namespace collisions with custom cards. (This is only something I would consider if I had the rights to the game, in which case it would then be public domain, anyways. If I were simply to make suggestions to Wizards of the Coast, this wouldn't be one of them, although the other things I mentioned still would be.)
About the card frames, well, I am also one of the minority that likes the old card frames too, I suppose. It isn't that important, I suppose.
For puzzles, I mean Magic: the Puzzling. I have an interest in it, more than in the actual game. (For this reason, I rarely spend any money on Magic: the Gathering cards. Composing and solving puzzles doesn't cost anything, but if Wizards of the Coast were to publish more books with the puzzles, then I might pay for them.)