During the last three weeks I have not spent too much time on just programming and instead addressed a topic of game development that I’ve just like many other more programmer-oriented game developers tend to postpone because it is quite difficult and needs serious deep mental work in order to turn out well.
Like I mentioned within my previous devlog I have already discovered once that my initial design of the game had flaws and instead of throwing the project away I am determined to interate on it to try make it better. In order to do this I have to put my designer hat on and really think about what makes a puzzle game good.
In this writeup I want to outline some of the things I’ve learned while studying during these weeks. Some of the points will seem very fundamental but I include them anyway in order to emphasize how important they are, and while some of the points are simple they are still not followed in many games.
Core mechanic
Traditionally a puzzle game revolves around a core mechanic, the mechanic is often simple enough to be explained with a single sentence and while simple it should be fully explored it can then be enhanced by several other mechanics if needed.
In the puzzle platformer, Braid the player has the power to rewind time as its core mechanic. Upon progressing the game introduces a new mechanic where some items are “magical” and not affected by the player’s power. Here a new mechanic is used in a way that hinders the player from utilizing their main ability but also opens the game up for a whole new set of states which itself gives more possibilities for interesting puzzles.
In the game Portal, the player is in charge of a gun that can open up portals that the player can walk through. In this game, the developers decided to bring in more mechanics that complement their core mechanics, for example, items in the world can travel through the portals as well as allow the player to experiment with using the portal in new ways with the different items in the world.
I believe the most elegant mechanics are the ones that give you all their power right from the start but are not directly visible and instead slowly present themselves to you as you progress. A good example of what I mean here is how the game Stephen's Sausage Roll does it, in other Sokoban-style games you often see several new mechanics introduced while you progress. Traditionally they start by pushing the box around the level but shortly after you are met with pressure plates, monsters, and many other different creations.
While this is not bad it is something I want to avoid as it gives the player a discovery feeling while stumbling on new unknown elements instead of the revelation that the player feels when reaching a deeper understanding of how the game works. I do not think this is beyond reach within a game that contains many different mechanics but I do believe it is harder to get right and for Brainroll I want to attempt to limit the number of mechanics and focus on the game’s core.
Linear and non-linear
Something I have thought a lot about when investigating other games is the two different forms of puzzle games. Linear puzzles are what you can call Brainroll today, you spawn into a level and once you complete that level you will move into the next. Non-linear, on the other hand, is a game that presents the user with multiple ways of solving the puzzles, the start and end goal may still be static but the tools available to the user gives for enough freedom to solve the puzzle in many ways.
I want to expand on this idea further a bit and also include the games that don’t have a linear set of levels for the user to complete. For example, in open-world style puzzle games the user is free to wander around and solve puzzles in whatever order they want. This is an important observation because this type of design allows the designer to build the game in a way where exploration is also a key part of reaching the revelation I mentioned earlier.
A good example is Jonathan Blow’s game The Witness where once you complete the “tutorial” the first puzzle you stumble upon is designed to be too hard for you to initially solve and the idea is for the player to try it, fail, and then move on and find another area which contains a much simpler subset of the same puzzle that teaches the player how to solve the previous one.
I don’t want to say that non-linear puzzle design is always better than linear but I do believe that if you do have a linear puzzle game such as Brainroll or another Sokoban-style game you can add a lot more depth into the game if you somehow connect the different levels. What I mean with this is for example if you utilize an overworld when the user navigates from level to level, this is a good opportunity for the overworld to also be a puzzle in interesting ways.
No Tutorials
Tutorials are a point of discussion, some games couldn’t be made without them, and many AAA games today wouldn’t survive without having tutorials upon tutorials for all their different systems and subsystems. It is not uncommon for these games to include skill trees, crafting, and perhaps different advanced attack combos. Having the players learn all of this would most likely take up so much of the core game that just learning how everything works would be the entire game, instead, it is just easier to strap short text prompts or messages on the screen with text that explains what you’re doing. One thing we all can agree on however is that text in games are almost always boring and just takes away the fun of playing the game. This is exactly what we want to strive for, letting the players just play the game. A quote often used is “A game with good game design explains itself” and this is also something I want to strive for in my games. The strategy that I apply when removing the need for tutorials is to incrementally introduce new things into the game, for example in Brainroll the first levels are just about movement, there are no real other mechanics to interact with and that allows the levels to be simple enough so that the players can just experiment their way to the goal. Allowing user freedom here is a great benefit to your game because the game will be more interesting if there is room for experimentation.
Level design language
Another advice I got and applied to my game design is that I try to think really hard about what I am asking the player to do in the level. For you who played the latest version of Brainroll there is a mechanic where a sleepy brain would stick to you on collision and you have to move them around in order to aid you reaching the goal. I created a set of levels and analyed them by writing down all the actions the user has to perform in order to complete them and by doing this I learned that the mechanic surounding the sleepy brain had another set of mechanics tied to it, by moving them around you had the oupportunity to arrange them in different patterns, by carefull positioning you can reach new places, they can be used as padding as if you were moving a wall around with you and finally you can sling them around corners.
While all of these mechanics are overlapping they are still distinct enough to have a language to use when describing the designed levels. This allows me to go into the level design with concrete ideas of what I want the level to be about. Instead of experimentation (which also can be very lucrative) I can go into the design mode by specifying for example that I want the player to arrange the sleepy brains to form the letter L for them to trigger a pressure plate that opens the next door. This can of course be achieved without having terms to describe the different actions your player performs but I still believe there is a benefit in making it more formal.
Don’t design backwards
Designing levels I’ve come to believe that it is bad to design backward, what I mean with this is if you choose to design your levels by placing down a start position and an end goal and solely move the level forward by finding ways to block the path between the player and the goal in different ways. I am sure this can yield success sometimes but to further dive into the mechanics you’ve created and learn what they are about you have to try to start from the other end as well, before even creating the level start with an idea, this idea can be very simple like “I want to design a level that looks like a skull” or even better “I want the player to use a sleepy brain as padding to slide between two walls”. All of the best levels I’ve created have come from this way of making them. Why I believe the backward route is bad is also because when I’ve done it that way, later when playing the levels something has always felt a bit off. I later concluded that the reason behind this weird feeling has been the result of artificial complexity being introduced into the level. What I mean by this is that the puzzle I’ve created wasn’t a puzzle with an idea, it was just something preventing you from reaching the goal. This is the same problem that Brainroll had before when the game was oriented around mazes, which just wasn’t interesting or fun. So try to design forwards, start with a good or interesting idea and explore how your game’s mechanics fare against this idea. In some cases, it won't work and then you’re at a crossroads where you have to decide as a game developer if you want to change the game to make it work or just accept that this idea won’t work in the game you’re making and move on.
I hope this was an interesting read, if you enjoyed it please consider checking out my other socials!
Top comments (0)