Design Tips

Keep focus

People have different opinions about what's central in a game.

An example is persons that read a whole ruleset or play a game and then comment on something that is irrelevant for gameplay, like for instance that something is "unreal". Are CGG:s designed to be simulations and represent reality? No. They're not. For that task one would usually rather use a simulator instead of a CCG.

Another example is players that play a game and judge it on the grounds of it's artwork or chosen theme/setting only. This is common among the young audience and people that are seldom in contact with games.

What's central in the rule development process, balancing of old cards and creation of new are the matters at hand: Rules, numbers.

As game designers we should make a distinction between a game's production value and it's gameplay. We need not deal with issues that come at a later stage in the design process, or with subjects better handled by other people within the project (i.e. artists).

When developing rules we should not think much about what style the art will be, or if our elves will be blue or brown eyed. All such things will stack up in the end and potentially have an effect on the production value, on how the game is perceived as a whole. Simultaneously, they have no effect at all on the flow of the game, on what mechanics are in it, how combat is conducted, what happens with variables, the values of the constants, what the win conditions are etc etc.

In WTactics we want to promote rulesets that put focus on the gameplay, leaving all other things outside of them while the rules are being created. There need not be a good background story, or cool sounding names, or pretty graphics. When developing rules all of that is secondary in that process and for the rule developers. This is fully comparable with us not bothering the artist to tell him/her that a Wose hase 50 HP, or that a player can mulligan cards after a bad card draw. The artists don't care, nor should they, as it seldom will have any bearing on what they're doing.

These things are typically added or tweaked around later on, as the different types of developers and teams catch up with each other. We will eventually add all fluff and put the rules within a context that make them more likable and easier to understand and remember than if we'd just stick to a strictly scientific or abstract language. We will aim at having a high production value. Trying to achieve that and integrate it in the ruleset is could, despite of us wanting it there in the end, be time consuming and hindering what needs to be done with the rules in that stage of development.