Why would people play your game?

/in /by

This may sound like an easy question, but the better you understand your game, the better you can improve it.

Answers like ‘just because it’s hard’, or ‘because it has cool weapons’ only skim the surface. In this case, you’ll get closer if you say it’s because players like the challenge in your game. Better said, they like to feel competent, effective in what they are doing. Both in our work lives and our leisure we are intrinsically motivated to seek out opportunities to experience competence and the satisfaction that accompanies it. So naturally, this also leads to games and the challenges they offer.

According to research of Richard Ryan we have three innate psychological needs: competence, autonomy and relatedness. When these are satisfied, we are motivated, productive and happy. To see how this applies to games, defnitely read the article Rethinking Carrots on Gamasutra.

Earlier I gave the tip find your intrinsic motivation, you can find the answer somewhere in these 3 needs. And in the same way, you can better understand the intrinsic motivation of you players when they’re playing your game. Find which ones work best for your game and your players.

The first prototype for Circles had something fun about it, but it took some time find exactly what that was. I thought an aspect of it was in its puzzle challenge or its navigational challenge. I tried out tricky levels with narrow spaces, switches that would open areas up and in general more complicated levels. But it seemed focusing on more challenge and satisfying a need for competence did not work out well for the game. Instead, I switched and tried to focus more on letting the players experiment and discover how circles behave. This meant simpler levels consisting of just one or a few circles and made making it clear to show off their behavior and interactions. This focus on autonomy worked a lot better for the game and was a lot more engaging for players.

The quality of a level is largely dependent on its relative placement

/in /by

Depending on where a level stands compared to the rest, decides for a big portion how well that level works. It may be too difficult at an earlier point, or to easy at a later one. If you find yourself tweaking a level to no end to make it easier or more understandable, the problem may lie in the level itself. Changing it’s level placement can have a huge impact and make the level achieve its desired result. For more, here’s an interesting article on the puzzle placement in Metrico.

You can also try to divide up the steps in the a particular level to multiple levels, making it easier to understand. Nintendo likes to do this, you can see a really good breakdown on this youtube video Super Mario 3D World’s 4 Step Level Design by Mark Brown. Essentially, they introduce an concept, develop it, twist it and bring it to a final conclusion. This is a structure is inspired by a narrative structure called Kishōtenketsu. You see this often in Chinese, Korean or Japanese stories, but can just as well be applied to games. You can find it in one level, a series of levels or even in the structure of the overarching stages.

Fix a game’s content rather than its systems

/in /by

This is obviously not true for every case, but most of the time designing you’re working on systems and refining them. So when you see one case where there’s a problem, it’s easy to fix that by tweaking the system. But then there’s a big chance it would ripple out and create new problems elsewhere. See design should not only be judged by the problems it solves, but by the problems it creates. It’s often useful to try and see if the root of the problem is actually related to a system. If it can be fixed by changing the content (e.g. level design), it’s usually an easier and safer fix. Especially later in development.

For Circles, there were many cases where a specific hitch in a level created the problem. It was easy to see a solution to the system to counter-act it, but it turned out to be way more effective to change the given level and prevent the problem altogether.

 

Prevent a problem rather than fixing it

/in /by

This applies also when the problem is already there. You can ask yourself ‘How can I fix it?’ but it’s a lot more useful to ask ‘How can I prevent it?’. In the latter, you’re more likely to look at the cause of the problem, instead of its effect and you’re able to solve it much more effectively.

I encountered this in the example described at form follows function, where a circle would be perceived as a coin. I tried many things to counter-act this: bigger negative feedback on touch, distinctive sounds, longer restart time and some more. But in the end these didn’t do much to solve the problem. Later, I found the problem originated from the fact that the circle was often on its own and therefore seen as something to collect. Putting more in a row, even surrounding the player, is what solved the problem.

Create a feedback function

/in /by

Usually in the prototyping stage you don’t have all the nice art to guide the player’s attention. That’s why it’s super useful to a quick and dirty function to make some simple feedback pop up. It could be a little ring, an explosion, some particles, anything really. Or if you’re using gamemaker just: ‘effect_create_above‘.

With this kind of feedback you can quickly draw attention to something and make it feel more responsive. Say the player just picked up a power up, collided with an enemy or reached a new level, for all of these you could pop up some feedback. Maybe just some with some different colors or effects. The point is that you make an event clearer for the player (if needed). Over time, you’ll want to replace the feedback with some proper art, some actual explosions or hit-stun animations, so it’s more in line with the game.

For Circles it started out as a simple feedback function that popped up a ring or a circle. And since the whole game is just rings and circles anyway, it stayed all the way. It just got more refined in timing and tween properties.