In this post we’ll be giving you advice on some important considerations you’ll have to account for when designing or tweaking your game’s core mechanic. Our game, Standpoint, is almost entirely designed around its gravity-shifting mechanic, and the following advice is based on our experiences in developing it.
If you’re anything like me, you tend to design your games with some kind of interesting mechanic in mind first. Even if you’re nothing like me, if you get into designing games there’s bound to be a point where you think “Hey, wouldn’t this mechanic be cool!” , and try to make a game out of it. Your core mechanic is an integral part of your game, so it’s bound to need much more thought than you originally expect. Even if you expect to put a lot of thought into your mechanic, you’re probably underestimating the work needed (I’ve found that out the hard way).
Make sure it’s not too limited
For the original Standpoint proof of concept, the player could only rotate the world about the world’s Z-axis, by 90 or 180-degrees in either direction. This felt fine in straight-corridor obstacle based puzzles, but designing the whole game to take place in a straight corridor environment was extremely restrictive with respect to the kinds of challenges we could introduce. We briefly attempted to add bends to the corridor with this old mechanic to expand our options, but since the gravity change no longer rotated the corridor around you in a predictable fashion, it became disorientating.
The mechanic needed to be less restrictive of the kinds of environments we could design around it without disorienting the player. A mechanic that’s too restrictive will cause you or your level/environment designer to have trouble creating a good variety of interesting areas for your player. If your core mechanic couldn’t be shifted to a different environment with a few tweaks, without it breaking/not being fun, it’s possible that it’s too restrictive. But remember, if you’re confident you can make a game under those restrictions nonetheless, there’s nothing stopping you
Make sure it’s restrictive enough
The opposite issue is one that once again affects the ease of designing levels around your mechanic. The post-proof of concept Standpoint mechanic involved the ability to make most surfaces become the new “down”-vector for the world by looking at it and pressing a button, or press another button to inverse the world’s gravity. A design problem we encountered is that when the player has that much control over gravity, navigating most obstacles becomes trivial. While this could be solved by adding special surfaces that you can’t make the floor, or special areas that lock the gravity direction those solutions fix the symptom rather than the cause.
The true problem here is that in a game which is mainly about navigating the environment, being able to shift to any surface at any time is overpowered. It’s important to add restrictions on how much power your mechanic gives to the player, to ensure that they will still find some challenge in your game. In our case, removing the invert gravity button and only allowing the player to change gravity once between periods of “grounded” adds the necessary amount of limits to bring the mechanic back down to interesting from overpowered.
Make sure it’s fun!
If your core mechanic is fun as a toy in of itself, then you’re going to have a much easier time designing a game around it. Players will be interacting with your mechanic a lot during the course of the game, so try to make sure that it’s somewhat fun in of itself, or you’ll run the risk of the mechanic seeming tedious, clunky or gimmicky. While running early play-tests of Standpoint, people reacted positively to the game-play despite the lack of any obstacles or challenges, purely because navigating the environment felt good. Other examples of ‘toy’ like core mechanics are moving fast in Sonic games, firing things out of catapults in Angry Birds and, of course, portals in Portal.
As soon as you can, you should be testing to see if other people find your core mechanic fun. Get a working prototype with a basic proof of concept that demonstrates the mechanic, then get people to play it right away, as rough around the edges as possible. If they see the potential, you might be on to a winner.
In conclusion, by adding and removing restrictions to your mechanic, you either increase or decrease the amount of options the player has to traverse obstacles you design. Too few options and the game risks becoming boring through a lack of options, too many and it risks becomes boring due to ease. A key factor in a fun mechanic is balancing freedom and restriction.