Recently, I read some analysis of game design by Owen over at Streaming Colour Studios. Owen made a neat little game named Dapple for the iPhone. It’s a puzzle game which he says combines the familiar match-3 mechanic with some more thoughtful color-based mechanics. While his game has been well received he hasn’t managed to find his audience yet, and in a recent post he describes some of the problems of game design Dapple has run into. Personally, as I work on my next game I am running into a lot of the same problems, so I thought I would draw attention to Owen’s analysis and lend my two cents.
Owen is pretty upfront about what he wanted and what he got with Dapple. To use his own words:
Dapple is a game that plays like a hardcore puzzle game, but that looks like a light casual game. I think one of the problems I’m having with the game is
one of perception. Hardcore puzzle game players dismiss it immediately because it looks like a casual game. Casual gamers download the Lite version and when they don’t “get it” immediately, they stop playing out of
frustration.
So Owen’s intent was to sell his game to two segments of the market — hardcore and casual gamers. That makes a lot of sense, I think for an indie developer like Owen it’s critical to hit as many parts of the market as possible. Aiming for just one segment amounts to putting all your eggs in one basket which is a huge risk. Still, how can we avoid Owen’s problem and satisfy both types of gamers?
Personally, I think one of the key things is to make the experience accessible. Basically, I think the mechanics should start off relatively simple so that a player can quickly pick up and play. Once you’ve hooked the player on the gameplay you can start to introduce new elements. Ideally your mechanics can be layered in such a way that it rewards the hardcore for going the extra mile while still engaging the casual player.
At a conceptual level what I am talking about is layers of gameplay. In Owen’s case he added new layers of gameplay too quickly which intimidated casual gamers. Furthermore, I’d argue that in doing so he didn’t give people enough time to appreciate each individual layer. Of course, there’s a danger in going too slowly, too. Unfortunately, I think that finding the right balance is more art than science.
That said you can look for signals that you’re falling into this problem. In software development there is a notion of a “code smell”, I think something similar exists for game design, let’s call it a “gameplay smell” for now.
One instance of a gameplay smell is a tutorial, optional tutorial modes especially. If your game is so complex that the player needs to be explicitly walked through mechanics then I think you’re most likely trying to introduce too many layers at once. Why is it the player cannot learn how to play and what the objectives are as he plays the game?
Another example of a gamplay smell is overly complex controls. In my last demo I had a run and jump key. Still whenever I or friends played the game we would constantly hold the run key down. That’s a smell, what is the extra complexity associated with the second button adding? In the case of my game it turned out that not only was the run key adding nothing it was actually making it more difficult to add other controls to the game — it’s just too difficult to coordinate three buttons at once.
It’s difficult to spot these smells as you play your game. Especially as you develop the game and pour more time into it it’s increasingly easy to overlook problems with design. Things like pacing and difficulty may seem totally appropriate after you’ve played the game for dozens of hours but be totally off for the newcomer. At the same time it’s critical to identify these weaknesses and cut them from the product. What sort techniques do you use to separate the good from that bad in your games?
Hello, my name is Alex Schearer. I grew up in New York and currently live in Seattle.
4 Comments
testing :D seriusly, let test to someone else your game and hear they suggestions :D it’s the only hope!
You’re right, but at the same time there are a few problems with testing by itself:
All of this points to the need for some sort of common approach to weasel out problems for the game. Some type of common language akin to a pattern language might be a good first step.
Hi, just started reading your blog a few weeks ago. I think the poster above was right about testing, you just need to get a good group of testers together that you can rotate through.
I think one mistake that many game designers make, and people in general, is not networking. To be successful, you must have not only a network of people who are interested in your game, but at least a few who are willing to download a demo and test it for you. Heck, get family involved. If they can understand it, you often can tell if you’ve got a game that would appeal to casual gamers out there.
You could even offer free versions of your game to testers, or some other kind of incentive. Starbucks gift cards, etc. Building that group of testers is hard, but without it you can easily miss flaws in your game that can sink it.
Also, I think adding a single new, significant gameplay mechanism/characteristic in stages, for example in successive levels, is the way to go. That way, “hardcore” gamers begin to quickly see that there is strategic depth to your game but casual players won’t be overwhelmed.
Hey Ceric thanks for taking the time to share your insights! I think you’re spot on, networking is an essential component to success. As you say it plays an important role in finding people who are willing to thoroughly test your game and give feedback. It’s also useful when it comes time to release your game — hopefully your network can be tapped to spread the word about its release. As for adding gameplay mechanics in stages I agree completely. I think you hit the nail on the head as to why, too.