Hey everyone! This post will hopefully be the first in a new series looking at game design lessons that I learn as I experiment with making more games. Here, we’re looking at my most recent project: a tiny platformer called Uproot that I made for the 2023 Global Game Jam.

What was Uproot?

The Global Game Jam’s theme for this year was “roots”. At first I had a hard time deciding what to make, but I remembered a tool I had been working on earlier - a kind of “template” platformer, with all the features of a regular platformer but no special mechanics (more on this later). This led me to think that the game I make based on roots should be a kind of platformer, which eventually became Uproot.

The main mechanic of Uproot was based around changing the level. Each of the 8 levels began with a few “seeds” in the ground, and every time the player jumped the seeds grew a “root” upwards, increasing by 1 tile with every jump. I like to think that these simple rules enabled some interesting level designs - like a level where you have to cross a gap not by jumping, but by falling and climbing up the wall on the other side. But they also had many issues and the way they worked wasn’t always consistent or clear to the player, meaning that (in my opinion) Uproot ultimately failed at being a good puzzle platformer. That’s not to say it was a bad project - Uproot was definitely worth it and I learned a lot from making it.

The Template Game

Long (about 2 weeks) before I had thought about Uproot or the Global Game Jam, I was working on a different idea - template games. Game ideas and game jams come and go, but they usually have some major similarities or shared pieces. Platforming is a great example of this, and caused me to think - if I could make a game with just the parts that all platformers had in common, it would be way easier to make platformers with unique parts in the future. Not just for platformers, but all kinds of features could be made this way: top-down movement systems, weapon systems, level generation systems, and more. This idea eventually became a list of a few sets of features which I started calling template games.

Uproot was based on the first template game I made, which was a platformer. Of course it’s common for games to use premade assets, especially in game jams, but this was more like adding features to a premade game - which resulted in some interesting design influences. For example, the template platformer featured wall-climbing and jumping, so this became part of Uproot too and a critical part of a few levels. What I think is interesting is that I designed these levels around part of the player’s movement system that wasn’t originally made with the growing-root mechanic in mind - I still think these are good levels, but this raises some questions about how well they fit into the overall design of the game.

Another place where template platformer mechanics determined the structure of an Uproot level was with the specialized platforms I had made, specifically the moving and bouncing platforms (I also made a disintegrating platform but didn’t use it, I did consider using it though). I think that the use of moving platforms was really worthwhile and made some interesting levels possible, but I’m not so convinced about the bouncing platform - it was only used in one level and didn’t add much to the game.

The use of these premade assets helped me finish Uproot more quickly, but I wasn’t really considering how I was using them. Not only did this lead to some decisions that I thought were against the central idea of the game, but it also resulted in some puzzles that confused players. What I realized from this (maybe a bit too late) was that one of the most important things to consider in making a game is the expectations of the people playing it.

Managing Player Expectations

When playing a game, players usually don't notice the specifics of the game's mechanics. They expect everything in-game to act the way they anticipate, and places where their expectations are broken by specifics of the game's code or mechanics can be awkward and immersion-breaking. Unfortunately, I learned this the hard way after making Uproot in a way that tended to ignore the player's perspective and expectations.

It was hard for me to realize this, since I couldn't see things from a player's perspective, only a designer's. But I was able to write this section of the post thanks to help from my friend Tigran, who closely reviewed Uproot after the jam ended. He provided me with some incredible advice about the experience of playing as a new player, and I owe this section to his responses.

For this post, I asked Tigran about where Uproot went wrong with player expectations. We also talk a bit about when challenging expectations goes right, which I’ll come back to slightly later. Please note that I edited his answers slightly to shorten their length, but tried to be as close to the original meaning as possible.

When starting Uproot, did you have any expectations from other sources, such as other similar games?

I was expecting, as it was a game jam game, for it to be really short, to the bone, and was almost wondering if there was going to be some sort of spin to make it very replayable. Knowing the nature of growing, and how it was not tied to a timer, I felt that this would be the environment for a puzzle game.

Did you develop any expectations of how the levels work, or notice any pattern to them?

I began to learn the slight traps of the system, where I understood “oh I can’t go through here, I can’t jump over that” where I expected to. I also didn’t really understand that there even was a climb option, I thought it was just hang, and I didn’t know if [the root] was sticky or not. My expectation was totally void, and I just learned through experimentation.

The one interesting pattern I saw was with careful coordination, where coordinating became not only needed to solve the levels but a kind of optimization. What I thought could work didn’t work, and the best route came through even better optimization that I anticipated in the game.

Did you develop expectations of how to solve the levels? What levels caused these expectations?

Only a few expectations emerged, [like] needing to jump a few times and coordinate to reach the end. I came to expect that there would be a gradual increase in complexity, but I didn’t expect the sometimes sudden new mechanics that felt like a natural addition.

For your understanding of what the player can do, how much came from Uproot itself and how much came from something else?

Admittedly very little came from Uproot, my previous understandings of platformers and just noticing that stuff grows when I press space paved the way. It was through the exploration of Uproot that I discovered the climbing mechanic, which initially was almost me trying to force my way through the game, but evolved into an appreciation for this newfound mechanic.

Were there any places were your expectations were broken? Or to put it another way, were there any places where you felt that a rule that was established earlier in Uproot or from another source was broken unexpectedly?

From another source definitely. Due to the grid-based nature of the game and my previous experience with grid-based games, I was taken aback by how the player did not fit the grid, although this could be just a minor technical thing.

As I mentioned in previous questions, I had believed there was, like in other platforming games, a wall-hanging ability. [But] the expectation was less “presented” and more “lightly referenced”, and I had to explore more to find it. I wouldn’t say it was broken, but it felt occluded.

Were there any places where your expectations were challenged, but in a way that contributed to the game rather than just being frustrating?

One such experience that I previously explored was how previously I had assumed that most of the puzzles were around jumping to the exact route going to the exact platform, and one level challenged my understanding by making it seem very possible for one “answer”, but later I found out through optimization of jumps and not taking the expected path the real, true answer to the level. It broke my expectations of clearly understanding where to go, and just brute force until I get the answer.

On a second playthrough, I found that, having understood the answers, I could approach the levels in a new way. I wanted to see if there was gratification to replaying the game, or if the puzzle solutions still being in my brain would be a detriment to me. But as I played through it, I found a lot of joy in not just knowing the solution, but now being confident in my skills, and that on my first or second try I could truthfully go through the puzzles knowing the solution.

This isn’t to say that the game should always go as the player expects. I think that with many games, especially puzzle games, it can be important to set up the player’s expectations at one point to challenge them later on. This can be a great “aha” moment in puzzle levels, and can feature in other types of games too in different ways, like realizing the key to defeating a boss or difficult area. However I think there’s a major difference between challenging expectations in this way and “breaking” expectations with unanticipated bugs: the first way is only an issue of player skill and knowledge which they can overcome through learning, while the second way is an issue with the game itself.

In my opinion, this interview demonstrates where both of these challenges to the player’s expectations are present in Uproot. With some levels, the player’s assumptions are challenged in a way that the player needs to adapt their thinking to reach the end, and this can be an interesting way of puzzle-solving that the player can feel interested in and proud of once they find the answer. But examples like the player’s collider not fitting through the height of a single grid square show that there are many points in the game where the player encounters an obstacle which I unintentionally led them to as the designer - the player’s sprite is 1 grid square tall, and so the player assumes they can fit through a gap of that height, and discovering that they can’t is more frustrating than interesting. There’s no lateral-thinking solution to that issue, it’s just that the player’s collider doesn’t line up with its sprite, and that’s the kind of failing which Uproot should move beyond.

The Next Route

I definitely feel that Uproot was a worthwhile project and I don’t regret making it at all, but its creation and revisiting it after the jam ended demonstrated to me how many mistakes and assumptions I had made when creating it. For me, one of the most important lessons was about using assets from previous projects, since this is something I’ll almost definitely be doing in the future.

In my game dev experience it’s almost impossible to avoid using assets you’ve made before, and it’s not a bad thing at all, but I think that using the template platformer in Uproot has made me think a bit more about how to use premade assets. In my opinion, it’s best to use assets in a conscious way, thinking about how they change the game and if they’re in line with the game’s central idea. I still have more template games to make, but when creating them I’ll be thinking more about how I might actually use what I’m making in future projects.

And if every game dev person there is didn’t talk about it enough, I now know the importance of playtesting a game with an audience other than yourself, and being conscious of how players will understand aspects of the game you’re making. To narrowly avoid a satisfying ending to this post, I’m not completely sure how to use this knowledge going forward, but I’m planning on approaching every new game project with a set of rules that the player implicitly understands. By following these guidelines, I hope that the player is more able to understand the game as a whole and that I can use that to create some interesting scenarios by bending (but not completely breaking) these rules.

After Uproot, I'm thinking of working on a template grid-based RPG with some basic exploration and inventory mechanics, inspired by games like The Ensign. I hope to make some games for future jams based on this template and I'll keep thinking about and revisiting what I've learned here. If everything goes well I should be hopefully writing about that soon - see you next time

Special thanks to Tigran Bleyan! (Twitter, Itch)