The first game design that I seriously wrestled with was called
The Space Cannibal Game (working title, obviously). It was meant to be a "Take that!" card game, where players would play cards from their hands to attack other players, defend themselves, and maintain their health.
So this game was set in a spaceship, where all the food had been ejected into space. The players took the role of astronauts who were forced to attack and eat each other to survive.
The design threw up a bunch of problems and these problems were exacerbated by my desire to make a game that offered lots of variety and unique ideas.
The first problem the game faced was that players would hoard their food and just play defensive cards - I wanted players to be more interactive. To force interactivity, I started implementing a bunch of ideas to encourage players to attack one-another. I introduced game events each round that would do things like cancelling defensive cards, cause food to decay, and a variety of other unexpected things.
I then wanted a way to track how the cannibalism was affecting players physically. So I built player characters with modular parts that could be taken out as various body parts were eaten. It then made sense that this would affect your abilities, so then I threw in another aspect where you wouldn't be able to use certain cards and abilities if certain limbs were missing. Later, I became concerned about runaway leaders, so as a catch-up mechanic I added the ability to attach robotic limbs to your body if you had suffered an injury and had the resources to hand.
|
As each body part is attacked or eaten, you can flip it to show your skeleton. |
As long as you had a head on your body, you could still take actions, but what was to stop you from just chopping off your opponent's head and knocking them straight out of the game? I created a madness-meter which would track your sanity and would decrease if you performed inhumane actions. If it reached zero, you were out of the game yourself - and lopping off someone's head sent your madness immediately to zero. So rather than fix the root of the problem, I applied a patch to the problem.
But then, I didn't want player elimination - because it sucks to be that eliminated player. So I created two more decks of cards. One was for players who had gone mad - they couldn't win the game, but they could somewhat affect the outcome. Another was for players who had been killed, who could then float around the ship as ghosts and drive other people mad.
|
The dead-player deck, floating around causing madness. |
After another brief playtest, the win condition was called into question. It was just to be the last player surviving, but players didn't like that. So I threw in the idea that you were flying towards rescue and that whoever was alive when rescue came would be joint winners. So among the game event deck, I created a timeline element which could be sped up and slowed down - all the while players are still fighting for odd limbs. When a certain amount of in-game time had passed, the game would end.
Later, trying to take advantage of the game event deck, I started throwing in other resources that each event could effect -- oxygen levels, damage to the ship, etc etc. If your ship became too damaged, for example, you would never reach rescue and everyone would lose. This was a huge change, and the game became semi-cooperative, where you would be working together to maintain the ship and then killing each other for food.
And then there were player classes. Pilots, doctors, engineers, and so on. And then there was going to be a modular spaceship board, which, thankfully, didn't get made because playtests were already saying that something had gone horribly wrong.
By this point the game involved almost 150 heavy-card tokens, 200 playing cards, and tons of rules. To fix problems, I had added an event deck, madness meters, two decks to counter player elimination, additional resources, a cooperative element, and modular character cut-outs, with more rules and a modular board on the way.
|
Another prototype, this time with player classes. This is the doctor/medic. |
The Space Cannibal Game had the dreaded feature bloat.
Feature bloat is when the creator of a game (or any creative endeavour really) is distracted from which elements are important to the core of a game. More and more features get added to the product, which distracts from the core elements. It could be that the designer is:
- excited by lots of ideas and possibilities without seeing their implications on gameplay
- aspiring to create something epic in scale, while not having the resources or expertise
- applying patches to problems rather than fixing the root of the problems
In my case, I was doing all three of these things.
The problem with feature bloat is manifold. Obviously, it confuses your players, who are constantly struggling with rules. Particularly when you apply new features as patches to problems, you will find players attempting to do something first before they spot that patch-rule. The case of
Space Cannibals, every player would say, "Aha - I chop off your head with this surgical saw!" before being informed that they would go mad and be effectively out of the game. It's frustrating to have a rule turn on you like that.
When a game starts to become bloated with superflous mechanics and rules - when too many playtesters are confused or frustrated and your game ceases to be fun - it's time to reign your game in and realise what was meant to be fundamental in your game.
This Eurogamer article about the designer of
Ticket to Ride, Alan R Moon, pretty much sums up my position on feature bloat:
"My rule for designing a game is that anything I can take out of the game, I take out, as long as it doesn't undermine the base part," states Moon. "When I worked at Avalon Hill on gamers' wargames, I learned a lot about making complex rules and coating a game with a lot of 'chrome', to dress up the game. For me as a designer I really want to do the opposite with my designs. I want to take everything out that's possible, and have a really elegant design."
The rest of Moon's rules for design are fairly simple. The player, he insists, should be limited to two or three simple choices per turn, and learn fairly quickly if decisions made were the right ones. Moon has no time for what he calls 'game salad', where the player can juggle myriad ways to claim victory. Instead, the same limited decisions should also continue to impact the rest of the game. [...] Play should be quick too, and systems taken back to their most refined form.
"Within those rules Ticket to Ride is stripped back as far as I think is possible," says Moon. "I don't think there's anything left in there that you could take out without effecting the game's most base level."
Moon, here, is talking about a certain kind of game, and not all games need that level of simplicity all the time, but if too many things are going wrong, then cut out the excess and fix or refine your core mechanic.
The Space Cannibal Game was abandoned ages ago, as a boring and unwieldy prototype. I do like the theme - the grotesque body-horror has some potential, I believe - and I'll probably resurrect that when I find some better mechanics that are more fitting towards it.