I’m a games designer – I’ve been doing it all my adult life and I still find it a fascinating, but sometimes little understood subject. So as well as giving some insight into the specific design behind Combat Cards, I’d like these diaries to also cover general design practice. Of course, I’m open to feedback, so let me know if you’re not keen on this design theory nonsense.
I thought it might be interesting to look at the way Combat Cards changed as we iterated on its design. Turns out there’s a lot to cover, so I’m going to split the topic between this and next week’s post.
Iteration
When you play Combat Cards – or pretty much any video, board, war or roleplaying game (or sport) – the product you’re experiencing probably isn’t the first version the developers created.
Almost all games go through a long process of iteration, changing in all sorts of subtle (or sometimes drastic) ways throughout development. Features and rules may be added or removed, the way you interact with the game may change, or even its goal.
This is why, when developers say they plan to include a feature in their game, but then later change their mind – they’re not ‘trolling’ their players (what would be the point?).
Instead, through the process of creating the game, the devs learn that the feature might be impossible – or at least extremely expensive – to implement, or it turns out most players just aren’t interested in that aspect of the game.
Fun
But why does this iteration need to happen? At its most basic, it’s because we want to make the game as fun and engaging to play as possible.
Back in the dark old days of videogame design, the game’s designers would get together and decide exactly what features and ‘systems’ (more on these in a bit) the game would include. We’d detail every part of the game, write it in a huge document, and then the team would work to make the game as it was written.
The problem was that, because game designers can’t see into the future, sometimes the game you ended up with wasn’t much fun, and by that point you’d run out of time or money and had to ship it anyway. So we changed the way we work.
Prototypes
Now, designers work out only as much of each game feature as is needed for the team to build a quick prototype of it, then we test and refine that feature, hopefully making it more interesting, fun and clear to use (or dropping it if it’s unsalvageable).
This process of iteration often throws up surprises, with areas we originally thought key to the game falling away, or seemingly minor systems evolving to give really fun, ‘crunchy’ decisions for players.
Systems
Getting back to Combat Cards; playing the game means you’re interacting with a whole suite of ‘systems’, and in turn, triggering those systems to interact with each other.
But what do I mean by a ‘system’? They’re parts of the game that are ‘run by the game’s rules’, as opposed to being scripted by us.
What?
For example, if we hand author something then we’re saying ‘this thing happens exactly like we say’. This is helpful for giving us absolute control, but it means it will happen in that same way every time.
Systems are us telling the game the ‘rules’ and then letting what happens come out of those rules. This gives us less fine control, but means the player can try different options and approaches, and will get different outcomes each time.
And because each system’s rules interact with the rules for other systems, those outcomes can be obvious and predictable, or surprising and ‘emergent’ (but I’m not going to get into emergence in this post, as that’s a huge area of its own).
Pause
Okay, this post is long enough – I’ll wrap up the subject in next week’s post, covering specific examples of how all this applies to Combat Cards, and some of the changes we made to it. If you have any questions then get in touch via [email protected] or through the Combat Cards Facebook page.
Thanks,
Stu
Recent Comments