Elements the Game Forum - Free Online Fantasy Card Game
Elements the Game => Card Ideas and Art => Design Theory => Topic started by: OdinVanguard on October 17, 2013, 08:15:44 pm
-
Having been around for a while, I've noticed that there are a few mechanics that have been explicitly shot down by Zanz, or that are extremely tricky to balance (for any number of reasons) yet continually come up in card idea posts.
I think it would be helpful to have a stickied thread either here or in the smithy for new forum users to go to as a reference.
As a start, here are the first two that come to mind:
-Graveyards
-Casting / activation costs that require more than one type of quanta
-Mechanics that allow a single card / ability to one-shot / auto-kill creature with out any regard to its stats
-Removal of "untargettable" status from permanents
-
Add to the list:
removing Protect Artifact and Quintessence.
this is also a no-go area as I can recall.
-
Add to the list:
removing Protect Artifact and Quintessence.
this is also a no-go area as I can recall.
Ah, should have thought of that one, thanks!
I've added it to OP.
I don't know if Zanz has outright nixed this one, but attempts to do this very often get met with heavy resistance.
Actually, there is a card in armory right now that is a weapon which removes immortal status... Its discussion was quite, animated, but its gotten to level 3.
As far as I can tell, no one seems to support removing immaterial status from permanents though.
-
Hero cards. Basically, anything exceptionally bigger than a dragon, with a powerful ability. Not a mechanic per se, but should be noted.
-
I think the following is also on the list:
- Making a card go into hand with different stats than the original card was
- More than one weapon in an element ( :chroma is not considered an element)
-
I haven't seen the former around much, and the latter has been fairly successful.
-
Casting / activation costs that require more than one type of quanta
as someone that can code I have never really understood why people keep saying this would be troublesome to implement in the game.
-
I think it has been said it has something to do with current code format.
-
I think it has been said it has something to do with current code format.
My opinion is that if things have gotten to the point where Zanz can't make this kind of change in a simple way, then it's way past the time that he considered doing some cleanup on his code :P
-
I wish he would just make his code open source and allow the community to maintain the Meta.
-
I wish he would just make his code open source and allow the community to maintain the Meta.
Do minor balancing tweaks?
-
In any event though, unless the code gets cleaned up in the future, it would be good to keep track of what abilities / mechanics are deemed too troublesome to implement.
-
From what I have been told, hybrids are possible. They would require a narrowed focus randomly selection of quanta ..
Duo costs. would require a rewrite of code to allow for multiple forced quanta amounts.
Edit: Teaching spells have to be done carefully. This is because, not only do these kind of spells teach a creature a new skill, they also lobo old skills.
-
I think it has been said it has something to do with current code format.
My opinion is that if things have gotten to the point where Zanz can't make this kind of change in a simple way, then it's way past the time that he considered doing some cleanup on his code :P
Costs are coded as (Integer)(Type). To simulate a cost of :fire :fire :water the code would have to increase to (Integer)(Type)(Integer)(Type) at minimum and most likely would be upgraded to (Integer[])(Type[])
I'm still gone, just visiting from a library computer.
-
I think it has been said it has something to do with current code format.
My opinion is that if things have gotten to the point where Zanz can't make this kind of change in a simple way, then it's way past the time that he considered doing some cleanup on his code :P
Costs are coded as (Integer)(Type). To simulate a cost of :fire :fire :water the code would have to increase to (Integer)(Type)(Integer)(Type) at minimum and most likely would be upgraded to (Integer[])(Type[])
I'm still gone, just visiting from a library computer.
I don't know the specifics of flash programming, but this shouldn't be too hard to implement without, for example, rewriting the code of every single card (just rewrite the function that takes care of the costs to accept both formats of cost, a cleaner solution would be preferable, but would mean more work).
-
I think it has been said it has something to do with current code format.
My opinion is that if things have gotten to the point where Zanz can't make this kind of change in a simple way, then it's way past the time that he considered doing some cleanup on his code :P
Costs are coded as (Integer)(Type). To simulate a cost of :fire :fire :water the code would have to increase to (Integer)(Type)(Integer)(Type) at minimum and most likely would be upgraded to (Integer[])(Type[])
I'm still gone, just visiting from a library computer.
I don't know the specifics of flash programming, but this shouldn't be too hard to implement without, for example, rewriting the code of every single card (just rewrite the function that takes care of the costs to accept both formats of cost, a cleaner solution would be preferable, but would mean more work).
I don't know the specifics of flash either. I am paraphrasing information from someone else (who did know flash), using my knowledge of Java and Object Orientated Programming.
Yes all it would take is altering the cost function. Either to accept a variable number of inputs or to accept array and non-array inputs.
-
I want to add this unofficial shot down thing on the list:
- spells or abilities which dive other creatures (so attack multiplying)
-
I think it has been said it has something to do with current code format.
My opinion is that if things have gotten to the point where Zanz can't make this kind of change in a simple way, then it's way past the time that he considered doing some cleanup on his code :P
Costs are coded as (Integer)(Type). To simulate a cost of :fire :fire :water the code would have to increase to (Integer)(Type)(Integer)(Type) at minimum and most likely would be upgraded to (Integer[])(Type[])
I'm still gone, just visiting from a library computer.
I don't know the specifics of flash programming, but this shouldn't be too hard to implement without, for example, rewriting the code of every single card (just rewrite the function that takes care of the costs to accept both formats of cost, a cleaner solution would be preferable, but would mean more work).
I don't know the specifics of flash either. I am paraphrasing information from someone else (who did know flash), using my knowledge of Java and Object Orientated Programming.
Yes all it would take is altering the cost function. Either to accept a variable number of inputs or to accept array and non-array inputs.
The best thing I can think of for such a system is this: (written in c++ish syntax)
struct cardcost
{
unsignied int piecenumber;
unsigned int[][] costpieces;
}
// piecenumber specifies how many costpieces are needed to pay for the card
// the costpieces array consist of 13-element arrays that specify how many of each element are needed to pay for each costpiece
Again, this would require a complete rewrite (it's not backwards compatible with the system Zanz is probably using), so don't expect it to pop up in the source code anytime soon.
-
I want to add this unofficial shot down thing on the list:
- spells or abilities which dive other creatures (so attack multiplying)
Isn't that what sky blitz does?
Also:
- cards which let you instantly win regardless of circumstances