Unwritten Rules

[Scaredgirl]

There's one huge flaw with the original post, and that is the fact that these "unwritten rules" were not written by Zanz, they were written by a player.

You're not really revealing anything new or interesting to anyone here.  The OP is peppered with terms like "seems", "somtimes", "changes" and "might" for a reason.  If you can honestly read that first post and think that it 'sounds like law', that's an issue you have with your own perceptions.

These are not "tips" or "suggestions" you talk about here, they are "rules". For example adding a card graveyard to Elements is a "no-no" according to you. How should I interpret "no-no"? For me it sounds like "it will never happen". About not having graveyards:

Has Zanz ever said that? No.
Has Zanz ever said anything that could be interpret as anti-graveyard comments? No.
Can it be done technically? Yes.
Would it make the game better? Maybe.

So why is there an unwritten rule against it?

I don't have Zanz's ear any more than anyone else, but I have run gaming forums myself in the past, and I've worked closely with game designers in a "creating more content for my game" role -- and I can tell you, the entire OP is one made from years of experience.  All designers have unwritten rules -- most of them born from limitations on coding, some from their own unvoiced ideas about how the game 'should be' -- and if you anticipate and work within those rules, you've got a much better chance of your ideas catching the dev's attention.  Nothing more, nothing less.

When I post, I don't take into consideration a persons real life job, or what he has done in the past. Whether the person is a janitor, has ran a gaming forum, or was the lead developer of Pong, makes no difference to me. I only reply to what the person is saying.

Yes, all designers have unwritten rules, but the point I'm trying to make here is that you are not the designer of Elements. You might be right about some of those things but you might be wrong about all of them. We don't know. That's why it's not a good idea to tell others what they shouldn't do because that severely limits creativity. The fact that Elements is missing some feature at the moment doesn't mean that this feature will never happen.

For example your first "rule" kills TONS of ideas, and that rule makes no sense, especially when we already have a card like Precognition. No "instant kill cards" is also incorrect because we already have Mutation, etc. These are real life examples that contradict your unwritten rules.

If you want to defend you arguments, please do so by going to specifics, instead of giving the old "I've worked closely with game designers in the past so what I say is true" -defense.

I think brainstorming and freedom to do whatever is the most important part of creative process. If Zanz gives us a list of things that will never happen, or if there are some valid technical reasons why an idea cannot be implemented, then these kind of "unwritten rules" would make more sense. Now they only block creative process.

[Essence]

Straw man.  You are creating something that doesn't exist and then attacking it in lieu of attacking what I actually said.


I never said anything about limiting creativity.  The only thing that I have said is that there are always unwritten rules -- that's completely true. 

Then, I said IF you can figure out what they are, THEN you have a better chance of creating things that the game dev will respond positively to.

Then, I laid out some ideas of what I think some of Elements' unwritten rules were.  Did I lay them out as if they were definitive rules?  Sure, that's how people generally discuss their ideas.  Do I care if you agree with those ideas?  Not particularly. 

I do, however, encourage you to figure out for yourself what YOU think they may be, and take them into account when you design new cards.  Obviously other people figured that out, because they've taken the OP in the spirit in which it was intended, bringing up their own ideas and not treating the OP as though it's any attempt to be absolute.

I'm sorry that you don't get it the way that the other participants in this thread clearly do.

[Scaredgirl]

Straw man.  You are creating something that doesn't exist and then attacking it in lieu of attacking what I actually said.


I never said anything about limiting creativity.  The only thing that I have said is that there are always unwritten rules -- that's completely true. 

Then, I said IF you can figure out what they are, THEN you have a better chance of creating things that the game dev will respond positively to.

Then, I laid out some ideas of what I think some of Elements' unwritten rules were.  Did I lay them out as if they were definitive rules?  Sure, that's how people generally discuss their ideas.  Do I care if you agree with those ideas?  Not particularly. 

I do, however, encourage you to figure out for yourself what YOU think they may be, and take them into account when you design new cards.  Obviously other people figured that out, because they've taken the OP in the spirit in which it was intended, bringing up their own ideas and not treating the OP as though it's any attempt to be absolute.

I'm sorry that you don't get it the way that the other participants in this thread clearly do.

Lol, you did the same thing you did last time You completely dismissed all my questions and arguments. Instead you just talk in generalizations, repeating the same things over and over again.

I'm not saying unwritten rules cannot exist. I'm merely saying that most of the rules you listed don't make sense, and I explained why I think that way (for example the instant-kill by Mutation).

So lets forget about the big picture for a moment and concentrate on the actual things you list there. I have given some valid feedback which you have yet to respond. Care to comment?

Do I care if you agree with those ideas?  Not particularly.

This is not about opinions.

Think about it. You say there is an unwritten rule against "instant-kill" cards (because HP has to be taken into consideration) but there IS a card like that, Mutation. So how can there be be an unwritten rule against it, when it's already in the game? What you say there isn't an opinion, it's simply false. And if you too stubborn to admit it, this discussion is pointless.

Bloodshadow had an awesome idea for a instant kill Darkness card which would be a great addition to the game. Should he follow these "unwritten rules" and discard that idea?

Instead of having unwritten rules, have a sort of rough set of guidelines...

What Lanidrak says here is what I'm trying to say. Using a "set of guidelines" is so much better than "unwritten rules".

And only replacing those words don't fix everything because most of the things on that list make no sense or are simply false.



I could add a couple of things to the original list. Let see..

1. Cards that have 2 or more active abilities
This is technically difficult to achieve because in Elements when you click a creature once, it activates the ability. Having 2 or more active abilities would mean that there would be some kind of pop-up menu where you choose which ability to activate. This will most likely never happen because it requires extra coding, extra clicking, and makes the game more complex.

2. Cards with humans
So far there have been no humans in Elements. It's safe to assume that Zanz's vision of Elements doesn't involve Warriors and  Clerics. This is why it's probably a better idea to choose some mythical creature or an animal, although who knows, maybe humans appear at some point.

3. Cards that have an old ability, only with a new name
This is something I've seen a lot. Abilities that do exactly the same as old ones, only with a different name. Elements doesn't really need 4 different versions of "Devour", all with different names. Just use the ability already in the game. It's more simple that way.

etc.

[assassim]

4. Cards should not contain names eg. Sword of Xanthos

[Essence]

Want to talk specifics?  Let's do it.

Mutation is absolutley not an instant-kill card.  It's only 40% of an instant-kill card under the best of circumstances.   It has a greater chance of turning the creature into an Abomination or a mutant than it does to kill them, and those potential consequences are not something you can simply ignore when it suits your argument. 

I know for a fact that there's an unwritten rule against instant-kill cards because I've actually had a conversation with Zanzarino about it (which resulted in the current version of Aflatoxin, as mentioned above).  Shockwave has been added to the game since then, which means Zanz may have changed his mind to a degree, but I would still avoid any kind of creation that said "Target creature dies" unless it had strict consequences or conditions behind it.

Now, let's see...yup, that's the only specific card you've mentioned.


But let's address your general misunderstanding by looking at some other questions you asked:

About not having graveyards:

Has Zanz ever said that? No.
Has Zanz ever said anything that could be interpret as anti-graveyard comments? No.
Can it be done technically? Yes.
Would it make the game better? Maybe.

So why is there an unwritten rule against it?

Because there is currently, to all appearances, no code that involves tracking the existance of cards that have left play.  That means that in order to implement any card that involves such tracking, Zanz would have to put together an entirely new pile of code, which is something that he's just not likely to get excited about.  Stuff like that is notoriously buggy and time-consuming, so you have to step into Zanz's shoes and ask yourself: "Is it worth the pain in the ass that this coding would require just to have this card idea in my game?"

That is the fundamental source of a majority of the unwritten rules I listed.  If your idea is hard to code, it's less likely to make it into the game, period.   The stuff that seems not-so-difficult to code (like targeting quanta pools), I mentioned as particularly flexible rules. 

The fact that Elements is missing some feature at the moment doesn't mean that this feature will never happen.

Of course that's the case -- but it doesn't change the fact that hard-to-code cards will always be discarded more often than easy-to-code cards, so I don't particularly care.



Now, there are a couple of rules up there that aren't coding issues, but are still things we all recognize.  No humans, for example, and no "Control Magic"-type cards for another.  Those are things that either don't fit flavor-wise into the game (no humans) or are such painfully ovbious ideas their very nonexistance is a clear inidcator that Zanz doesn't want them in the game (Control Magic). 


So, to go over my original list for your own satisfaction:

No cards that affect your opponents hand directly

This falls into the "too obvious to have not been done already" AND potentially the "pain in the ass to code" categories.

No cards that modify either players deck directly (except to put a card directly into a specific position in the deck, thus far only on top).

PITA to code.

No cards that take control of an opponent's creature.

 
Obvious.

No cards that have multiple non-"all", non-"random" targets.  The targeting mechanism clearly is designed to handle one chosen target at a time.

PITA to code.

No cards that kill a creature without taking it's HP into account on some level.

Obvious.  And, of course, I talked to Zanz about it.

No cards that require you to target a quanta pool.

PITA to code.

No cards that affect the "graveyard" (to borrow a M:tG term).

HUGE PITA to code.


And there you go.  Disagree if you please.

[BluePriest]

I actually agree with Scaredgirl here. I mean, before Shockwave was added, I have a feeling that a card that has a different effect when X is true, would have been considered hard to code, and an unwritten rule.

Because there is currently, to all appearances, no code that involves tracking the existance of cards that have left play.  That means that in order to implement any card that involves such tracking, Zanz would have to put together an entirely new pile of code, which is something that he's just not likely to get excited about.  Stuff like that is notoriously buggy and time-consuming, so you have to step into Zanz's shoes and ask yourself: "Is it worth the pain in the ass that this coding would require just to have this card idea in my game?"

I never would have guessed Zanzario was tracking the card usage statistics until he actually posted them. Just because it doesnt look like soemthing is being tracked, doesnt mean it isnt. For all we know, Zanzario has a new board design hes working on that has a space for field cards, and a graveyard, but he is doing extensive testing on it first before releasing it.

Of course that's the case -- but it doesn't change the fact that hard-to-code cards will always be discarded more often than easy-to-code cards, so I don't particularly care.

I am still very new at coding, only made 1 game so far, and that game has massive slowdown issues, however, I have a feeling I could make a simple program that randomly selected 3 things. And im no where NEAR as good of a developer as Zanzario (I actually stink lol)

And we already know Zanzario has cards that will effect creatures solely based off of their placement (inundation, an instant kill card), so why wouldnt he be able to randomize it?

To me it seems like a lot of the things that you considered a pain to code, could actually be done pretty easily. That being 1, and the effecting the deck, be another one.

Also, Fractal effects the hand, no less than precognition does.

[Scaredgirl]

I actually agree with Scaredgirl here.

Yay, support


Essence, your "pain in the ass to code" is a weak reasoning. Correct me if I'm wrong, but it's my understanding that you are not actually a "coder" and have no experience in Flash what so ever? So my question is, how can you with no experience in flash coding, tell others how difficult or easy something is to code? Flash is very flexible and everything listed there can be done. Especially by someone as skilled as Zanz.

I don't consider myself as a "coder" either but I do have a lot of experience in web designing, html, flash, etc. What we talk about here are not that difficult to code really. Sure some of them might be PITA to code (like all coding imo) but not any more PITA than other aspects of Elements. Elements already has some advanced coding that makes coding these things look like a piece of cake.

Also it's not really the "card idea guys" job to think about how difficult something is to code. We just throw in ideas, and the developers decide what to do with them.

[Essence]

I have nothing to fall back upon except my previous experience dealing with Flash game developers and discussing coding difficulties first-hand.  If you choose to discard that as irrelevant, then I have nothing.

Of course, I think it's a stupid choice to make, but it is your choice in the end. 

I am still very new at coding, only made 1 game so far, and that game has massive slowdown issues, however, I have a feeling I could make a simple program that randomly selected 3 things.

I specifically said "non-Random". 

[jmizzle7]

I don't have any Flash-specific coding experience, but I have seen code and it looks familiar enough that I can say that I understand how it works. The most time-consuming addition to the game of the options posted would be a graveyard feature, as right now there is no such feature at all. A discard pile would need to be created, kept track of, seen in the game interface, and able to be manipulated before any cards that interact with a graveyard could be possible. That's not to say that any of these cards are impossible or improbable. On the contrary, Phoenix made its way into the game in such a way that it behaves like a card would if it were to come from the graveyard directly into play.

If people want to create cards that recur like this, it is definitely possible. All they need to do is integrate the new card idea with existing game mechanics. The main reason card ideas like this are shot down is not because they are bad ideas, but rather because they require the game interface and rules to change in order to accommodate their card. Instead of begging for a change to the game, change the card to fit within the frame of Elements' rules.

[verity_blues]

I personaly like the idea of a no graveyard-like pile. This is elements, to manipulate the graveyard would be akin to "something from nothing," doesn't seem to fit into the quantum-physicality of the Elements universe.


Man, I feel like a genius now!

[Lanidrak]

Regardless of how you feel. A grave-yard feature will add a whole new dynamic to the game.

And, contrary to what jmiz has said, I think it will be a relatively easy feature to implement. Keep in mind that my knowledge of flash programming is nothing to shout about; we already have a 'stack' for storing a players deck and there is already a routine for what happens when a creature is killed... ie. it is removed from play. So, now when a creature is killed/removed from play - it is added to the top of the new discard pile. The trickiest part (I think) will be categorizing all the cards. This, to me, is something that needs to be done prior to their being a graveyard/discard pile implemented.

What I mean by categorizing, is: Right now we have, Creatures, Permanents and Spells. The categorizing has already taken place among Permanents, in that, we have Pillars, Weapons, Shields and Permanents. For Creatures, we could separate them in such a way, that certain creatures avoid the graveyard (remove from play once killed) and the remaining creatures enter the graveyard. For Spells, the categorizing will be tricky, and I am all out of suggestions for this one. Perhaps a differentiation between Healing, Spells and Enchantments (or Buffs?), so a Firebolt is distinguished from a Blessing, or a Lightning Bolt acts differently to a Improved Miracle...

With proper and adequate categorizing, a card might now contain a new variable, adding a further piece of information to it. The main problem I can think of, is what to call these new categories - obviously Mortal, Immortal, Aetherial are already taken. And finally, we want to avoid borrowing too much from Magic: The Gathering. In which, a card is called 'Creature - Soldier' or 'Creature - Vampire'... Then you get certain cards which affect all 'Soldiers' or all 'Vampires'.

My idea for categorizing, builds slightly upon what verity_blues has said. To me, it seems highly illogical that a Photon or a Spark, or even a Malignant Cell, should be eligible for returning from a 'graveyard' into play. Whereas, a Devonian Dragon or a Graviton Fire-Eater, are perfectly acceptable.

Then we have the issue of one graveyard, shared; or two graveyards, one per player. And then just the issue of useful, balanced and unique cards which will make use of this new 'graveyard feature'.

[jmizzle7]

Regardless of how you feel. A grave-yard feature will add a whole new dynamic to the game.

And, contrary to what jmiz has said, I think it will be a relatively easy feature to implement. Keep in mind that my knowledge of flash programming is nothing to shout about; we already have a 'stack' for storing a players deck and there is already a routine for what happens when a creature is killed... ie. it is removed from play. So, now when a creature is killed/removed from play - it is added to the top of the new discard pile. The trickiest part (I think) will be categorizing all the cards. This, to me, is something that needs to be done prior to their being a graveyard/discard pile implemented.

What I mean by categorizing, is: Right now we have, Creatures, Permanents and Spells. The categorizing has already taken place among Permanents, in that, we have Pillars, Weapons, Shields and Permanents. For Creatures, we could separate them in such a way, that certain creatures avoid the graveyard (remove from play once killed) and the remaining creatures enter the graveyard. For Spells, the categorizing will be tricky, and I am all out of suggestions for this one. Perhaps a differentiation between Healing, Spells and Enchantments (or Buffs?), so a Firebolt is distinguished from a Blessing, or a Lightning Bolt acts differently to a Improved Miracle...

With proper and adequate categorizing, a card might now contain a new variable, adding a further piece of information to it. The main problem I can think of, is what to call these new categories - obviously Mortal, Immortal, Aetherial are already taken. And finally, we want to avoid borrowing too much from Magic: The Gathering. In which, a card is called 'Creature - Soldier' or 'Creature - Vampire'... Then you get certain cards which affect all 'Soldiers' or all 'Vampires'.

My idea for categorizing, builds slightly upon what verity_blues has said. To me, it seems highly illogical that a Photon or a Spark, or even a Malignant Cell, should be eligible for returning from a 'graveyard' into play. Whereas, a Devonian Dragon or a Graviton Fire-Eater, are perfectly acceptable.

Then we have the issue of one graveyard, shared; or two graveyards, one per player. And then just the issue of useful, balanced and unique cards which will make use of this new 'graveyard feature'.

I never said that a graveyard is difficult to create - I said that it is time consuming. My point about the graveyard and Phoenix is that Phoenix illustrates how Zanz plans on getting around the fact that there is no graveyard. Let's say that Phoenix was made a MtG card. It would be akin to Nether Spirit , but it would have card text that reads, "If Phoenix is in your graveyard, you may pay to return it to play. Play this ability as a sorcery." However, because there is no graveyard, another card was made to produce the same effect. The fact that Zanz took the time to create Phoenix like he did means that he obviously intends to preserve a "no graveyard" interface, at least for now.

As I said before, coming up with card ideas that stretch the boundaries of what can be done with the game are always welcome, but card ideas that require an interface overhaul should, at the very least, be reworded/reworked to try to incorporate into the game interface that already exists.