Today let’s talk for a while about a very important element that I mentioned in the last entry: mechanics reuse.
THE MAIN IDEA
The concept is pretty simple: your game should have a set of mechanics that are used more than once in different ways, adding progression to the game and preventing the player to learn a new whole mechanic too frequently. There are some great examples. Last time I mentioned the hook mechanic from Flinthook, which is probably the main tool to move in the game. Later it becomes something more: you use it to explode bubbles that act as shield to certain enemies and as trigger to some objects. And that’s just one example. The slow-mo mechanic is suggested as a tool to deal with situations when you’re surrounded by a lot of enemies but later you will have to activate it to cross some specific kind of laser-time barriers and—my favorite of it uses—to kill an enemy that has a spinning chain around his neck blocking your attacks which can only be defeated during slow-mo use time.
I’ve been playing BotW recently and it has some other great examples. The bombs can be used to attack enemies, blow up secret rock entrances and impulse the mine cart and the cannonballs. Magnet can lift metallic objects but also open metallic doors…etc. Probably I could list more than on use for each of the mechanics on Link’s tablet. The point is that the player uses the same tool he already knows, maybe in a different way or target, to achieve a different goal.
You probably have in mind some other examples from games you’ve played (feel free to share them in the comments and/or twitter) so now let’s talk about its benefits and how to implement it on our games. A lot of this comes from the game design material I’ve learned through awesome YT channels like Extra Credits and Game Maker’s Toolkit, and also, from my own failures and victories in the development of Office Chair Death Match and Foreigners.
WHY TO REUSE
I can think of at least 3 reasons to reuse mechanics in our games:
1. To save coding time
When your mechanics are strongly designed since the beginning to be reused and enjoyed during the entire game it means you have less code to write since… well, less mechanics are needed. As consequence, you can put that extra effort in level and puzzle design. That will for sure, save you a lot of time or at least will help you get a deeper and stronger design.
2. To Increase the progression and mastery feeling
If on every level a new tool (mechanic) is introduced, by the end of the game the player will have a lot of tools that will feel unnecessary to carry around. Imagine each Mario Bros level would have done that! I mean, let’s say you want to keep these N tools in use during the game. Your challenge then would be to design puzzles and levels that requires the player to use them all (!) and assuming the player can keep track of what is each tool for, it would be honestly an absolute pain for both the player and you the designer. Instead, if a simple set of mechanic evolves, the player is rewarded with a sense of mastery for each mechanic, feeling he’s still familiarized with the tool even when he has been giving it different uses. Also, your level and puzzle design are a lot clearer allowing you to create more natural and fluid experiences where switching tools, using inventories or remembering key bindings/combinations don’t become an obstacle.
3. To simplify your controls
To continue with last point, another issue is now more obvious: how many key/buttons will your game require to use your mechanics? Is it comfortable for the players when the game requires them to use multiple tools simultaneously? One of the worst possible ideas is to add new non-originally-planned keys in mid/late development just because a mechanic “suddenly” needs it. That means (speaking from experience here) that either your design was not solid from the beginning or you’re adding new features on the road. Both require you to stop, look the whole picture of your game and make some hard decisions, like going back to your original plan. The problem of adding extra keys is that you will now have more scenarios to consider for specific gameplay situations where some combinations might result literally impossible to achieve or absolutely uncomfortable, which would be nice only if your game is trying to force the player to do that on purpose (sounds like a real risky idea). I have planned to talk more deeply about controls in another post but I think the connection between controls simplicity and mechanic reuse is pretty clear for now.
Well, I need to make a pause here because this turned to be a larger topic than I thought. Already wrote half of the next section, how to implement it, and honestly it now seems fair to give it its own entry on the blog. Hopefully, with the benefits/reasons aforementioned you will have the chance to ask to your game some hard questions.
It’s a promise, the second part on this topic will be here tomorrow!