Iterating mechanics

As a child, I believed that making graphics must have been the most interesting part of game creation. If my brother and I had been playing a new video game and he happened to reach a new area when I was out with friends, my questions to him later were not, “What do you do in the new level?” but instead, “What did it look like?” This interest in visuals is probably why today I make and teach art.

It was not until I began to formally study game design that I discovered the importance of mechanics, how the user participates in and engages with your world. A game can look beautiful but be boring to play because of, say, limited things you can do. Similarly, a game without strong aesthetics can be very compelling. Excellent graphics do not result in excellent mechanics.

When I began developing my first game Schmutznik I knew that each level needed to have something new for the player to discover - nothing necessarily huge that would have fundamentally changed the game but, instead, something varied in each new section so that players would not lose interest in the journey through the game world. This was also a selfish decision because, as a solo developer, I would need to test these levels over and over and wanted novelty (the downside of this was that every new feature required more coding and introduced new bugs, but it was a necessary cost to achieve my vision).

In Schmutznik you play as a robot that can move left and right but cannot jump. Instead, you elevate to higher platforms by telescoping your neck, attaching to the bottoms of platforms, and pulling the rest of your body up. When you disengage from the block that you previously were attached to it will wobble and fall, damaging any enemies below and you, if you do not move out of its destructive path.

From this base mechanic, I was able to add all kinds of gameplay variations. For instance, some blocks would fall and, when they landed, created a dangerous inferno. Other blocks would strike the ground and turn into missiles that you could control, albeit with some limitations. And there were also alternatives such as bouncy blocks that would propel you up like a trampoline.

There were also many kinds of enemies, each with their own behavior, different puzzles, environmental challenges, and so on. To survive each new area, you had to study what was different, understand new behaviors, and then apply existing or new mechanics to safely reach the exit.

Below is the process I used to come up with new challenges for the player. It is in no way definitive but is what worked for me.

(Above) This dragon kite and string of butterflies hung above my daughter's changing table. It inspired a later level in Schmuztnik where you attempted to attack a boss bug that was surrounded by smaller, protective bugs.

2. Record. Make a digital or traditional sketch. I used whatever I had on hand - a sketchbook or the note-taking app on my phone. Regardless of the method, record it in some way. Do not assume you will remember your idea. There will be times ideas flow from your brain. Record these somewhere because you will not remember them. You do not need paragraphs of text but may be fine with a few words or even a quick sketch.

(Above) Very quick room sketches that are records of ideas I had when away from my desktop computer. They were messy and hard to read but their function was purely to save my thoughts until I had an opportunity to build the level later that day. 

3. Test quickly. Test the idea out with simple or quick-to-make graphics. There is absolutely no point in creating final art at this stage because you are only exploring your idea to understand what does and does not work. You may end up changing large parts of this level or even abandoning the entire concept so, for these reasons, put the least amount of effort into your graphics at this stage of development. 

(Above) Testing out a boss level where I used another enemy as a placeholder and existing or simple graphics to populate everything else.

(Above) The final level with background graphics and a fully animated grub boss.

4. Pause and Reflect. Try out the level several times, make tweaks, and then set it aside. Come back to it either the next day or even later so that you can revisit the level fresh. Sometimes I paused at this stage and began creating a new level to change my focus so that when I returned to that area I was not as close to it and could almost see it as a new player would.

5. Let others test your work. When you have a decent collection of levels, let your playtesters try them out. They can be friends, family, fans of your work on social media, etc. Some testers will give you very valuable feedback and some may not. Remember that you do not have to make every change that is suggested. Listen to the feedback, reflect on it, and make the changes if they make sense to what you are trying to achieve. And remember to thank your playtesters!

6. Acting on feedback. Once you feel the level is solid and other people have tried your level you can begin adding final graphics (though, if you are like me, you will go through many art styles before you settle on a final aesthetic). Be prepared to change elements again in the future. Parts of the level might feel clunky and would benefit from being cut or shortened but this can feel painful if you have spent the time making art and code for this new area. When players finally play your game most of them will have no idea how many revisions occurred in an area and what bugs you struggled with. This is fine. Ultimately, players may only notice the flaws you did not correct in your game and that could be their only takeaway from the entire experience.

7. Be ruthless with your creation. After all this, sometimes you may need to scrap a level because it just does not work or the later levels demonstrate the mechanic much more successfully than your early ones. While this can be frustrating it is usually worth the sacrifice of resources so that you can present the best possible version of the world you are sharing with your audience. I do suggest not deleting the rejected levels but archiving them in case you can use or rework parts of them later in development.

While the steps above seem like a lot of work, thinking up and implementing new features was my favorite part of game design. The pleasure of taking something that was an idea in my head and turning it into an interactive creation that could be shared with the world was thrilling and worth every setback I experienced making the game.

To read more about how I created the artwork for Schmutznik, please follow this link. To see the final game, you can view Schmutznik on Steam here and on Itch.io. Avram Dumitrescu can be followed on Twitter here.