Mechanics Reuse (part 2)

Hey all! Today I’ll finish as promised this small compendium of ideas behind mechanics reuse and how to implement it on our games. I’ll talk a lot about design before coding so if you struggle with that as we all do, this will give you some hints and support!

PAPER BEATS KEYBOARD

Something you will constantly read in Game Jams advices is to take a good number of the first hours to plan your game to put it down in paper and whiteboard. This is something I try to do always and it has proved to be absolutely invaluable in all kind of projects. The reason is because a good and solid design will give you a wide, clear vision of the experience the player will be guided through, the progression, the points where new mechanics can be introduced, reused or where they also lose sense or become repetitive, giving you the opportunity to improve or revitalize them before any single line of code is written.

For example, in our Office Chair Death Match, I spent around a week putting the main concept together. The movement idea was one of the first things I thought of. I wanted it to feel like an actual chair and I thought it was a “cool idea” having the player to press/release Impulse each time (like pushing with your feet on real life) instead of keeping it pressed most of the time like in a normal Kart game. But just from reading it on paper I noticed I was creating an endless, distracting and frustrating experience. Combining that with the fight mechanic was just painful to imagine. My final confirmation was to sit on the keyboard and imagine myself playing the game with the controls I had in mind at that point: it was a total mess. So, I simplified the movement again—no more press/release—but kept the feeling I was looking for by leaving a few rules of the old mechanic idea to require from the player some skill development. The feedback received indicated it was the right decision; it provides the right balance between challenge and feeling. Thank God!

 

MECHANICS REUSE: HOW TO IMPLEMENT IT (finally)

A Timeline

Something I like to do is to create a timeline of the game for when mechanics are introduced, learned, tested and combined with others. I don’t know if it has a name but I think I kind of stole it from a picture taken by Christopher Nolan of his Inception‘s general plan: who was the dreamer in each level and what was their goal in each level.

You can improve that timeline by combining a diversity of relevant elements to your game. E.g.: scenes you have in mind, dialogues (just remember game are not movies), emotions you want the player to experience in a specific sequence, etc. And of course, more technical stuff like specific level designs, difficulty, mechanics, achievements, equipment and weapon upgrades, enemies’ introduction, etc.

NOTE: If you have created a game before, this timeline thing sound pretty obvious but back when I started I had no idea how to put all my mess in order, so this might hopefully help somebody out there.

 

Wider mechanics concepts

If by any reason you have a specific gameplay moment on your mind that you’re crazy to include, be careful to avoid creating a mechanic only for that moment. Last blog entry I mentioned that mechanic reuse can save you coding time, and this is exactly what I mean: imagine you need to spend the same time coding, testing and tuning two mechanics: one will be used the entire game and the other will be used in a gameplay scene that last 5 to 10 minutes. If it still doesn’t sound already wrong to you it’s because either you have a lot of money and time or you don’t have a deadline and still think that it’s ok to finish the game in 7 years. (PS: I know people who have spent that much time on their games and the results have been awesome but I’ve also seen their struggles and I IMO it’s not healthy).

Let’s also put it this way: even if you are ok with a super long development time, having these flash mechanics will make your game feel inconsistent and unfair: mechanics usually include a learning processa recurrent use and a final test. Now, if you’re in the final scene of your game, fighting the boss, and the player receives this alien weapon that requires the player to check stars and planets position before its activation (which he has never done) instead of using his loyal Can Opener he has mastered using it to defuse bombs, open locks, kill enemies, etc., no matter how cool the alien weapon might look, it will make no sense to the player. It’s not what he knows about the game, his character and his skills.

I would suggest that you do one of two things: either make that mechanic something the player learns and uses before that fight or adjust your scene to the mechanics the player already knows. This is a concept that can be also applied to enemies and levels. That will reduce the amount of mechanics you need in your game and improve the overall experience for your players by getting the best out of the few you include.

 

Octopuses don’t play videogames 

Speaking of which, part of the early design is to figure how the controls will be: how many keys/buttons in total the player will use. So, pick up the controller or put your hands on the keyboard and go over each mechanic (I know, sounds and feels ridiculous…) trying to imagine what the player will have to press in the craziest scenarios. You should already know at this point which is your main audience, so put yourself in their shoes when you grab the controller. Also keep in mind that some players are more experienced than others: what if your game is somebody’s first contact with videogames?

And this is related to mechanics reuse in how the player activate them through the controls. If your plan is to combine 2 or more mechanics in a level, scene or boss fight, how easy will it be to switch between them? You can use different schemes here: a key for each tool/skill (like weapons assigned to 1,2,3… or skills in Dota 2), an inventory system where you have to manually equip some stuff, or some kind of selector (like Link’s tablet in BotW or No Man’s Sky multi-tool). A combination of these are also possible but things can get really messy.

I’m skipping some stuff here about controls because that’s the next thing I want to post about but as a last general thing to remember: mechanics and controls are easy and intuitive for you because you’re the creator. So, test your controls with people that is not familiarized with your game, with controls in general. My wife has been that person for me. She’s not a gamer, she doesn’t code but she’s a great listener and is always able to sit on the pc and test. She’s my “first time playing a game” user. If she can get it, everything is fine. 

 

Well, that’s it for today. This is for sure a larger topic but these 3 steps are a good starting point to evaluate and implement mechanics reuse. If you have something you would like to be covered on the blog feel free to leave it on the comments, twitter, DM, smoke signals or whatever you use to communicate.

 

Thanks for your time and as always, peace! 🙂

Ronald

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

A WordPress.com Website.

Up ↑

%d bloggers like this: