-- Originally published at http://blog.epic-owl.com/
For my first blog we looked into the general setting of designing a game. This time we’ll go a bit more in depth to iterating the designs. I will use our upcoming game as an example… omitting just enough specifics to avoid revealing anything too early.
This is a story about designing something, loving it, becoming blind to its faults, and eventually remaking it.
Our game has always been built on the concept of empowering the player with a huge freedom of choices. It’s a competitive game where these choices ultimately determine the success of the player, so designing the framework to support this gameplay has been a key focus. Once this framework was in place and the design realized, I loved it and believed it to be the beating core of the game.
As you might realize, this was already a misconception. I had focused so intently on building the framework that in my mind it had become synonymous with the core idea. When the original idea was to create a game centered around choices, this newly built layout (while perfectly functional) did so at the expense of the diversity of said choices. The design was pretty, efficient, it communicated well, yet it clipped the wings of the founding idea.
When our programmer prodigy Juho (who also happens to be a master of competitive games) brought this to my attention, I was naturally taken aback. I felt that my design guided player choices just as intended, and that it created an interesting landscape for two-edged decisions all across the board. But herein was the problem: by guiding the players to a certain predetermined route I had deemed enjoyable, I was actually fighting the core design of the game. To cut a long story short, I removed a big portion of the framework, and although I was sceptical at first, it proved to be the right call. The player had more control, and the implications of their choices grew exponentially. This was what it was always supposed to be about.
The lesson learned, if put into more general terms, was a reminder of how we sometimes become so attached to our ideas or solutions that we fail to see their negative impact – especially the sort that clashes against the original purpose of their existence. In game design we come across moments when we need to accept that our designs, no matter how polished and cool, do not always serve the benefit of the bigger picture. This is when we have to go back to the core (and actually remember what that is) and make tough judgment calls on if this thing we’ve built is worthwhile after all. It can be difficult, especially when everyone’s already put a lot of work into it.
Unfortunately the story didn’t end there. Not long after, we came to realize there’s another problem. All of these choices we’ve been talking about come with a pricetag. This has been a central feature in the game’s economy: you make money, you spend it on experimenting with the endless options you have. Thing is, when all the choices have a cost, it will become a deterrent in many cases. People will shy away from the core gameplay out of reluctance to spend their earnings.
The decision was a quick one. The cost has to go. But this time around the fix wasn’t as simple as just removing a fringe feature. As they are deeply connected, the designs of the entire economy, and hence the progression as well, would take massive hits. Tough luck. It was going to be a lot of work to be redone, but nothing can compromise the core gameplay.
When designing a new feature, or evaluating an old one, be sure to go through a mental checklist. It can save you a lot of time.
1. Does it chime perfectly with your core gameplay?
2. Is it a frictionless solution?
3. Is it necessary?
If you get a “yes” to all the questions above, you’re all set to go. When unsure, always fall back to the core. What is your game, and what makes it tick. Do not compromise the core.
That’s it for this time! Stay tuned for the 3rd part — in which some light may already be shed on what this Epic game is all about!