GMTK jam 2020 postmortem: Mid jam crisis, Level Design and misc. Insights.

Hello, GMTK jam 2020 jam happened and went in the blink of an eye. I will try to outline my thoughts on how it went for me below.

The game and theme:

The theme this time around was Out of control. I ended up making a puzzle platformer where each Control is a powerup you need to pick up. Ex: pick up a left powerup to be able to go left. You can also inject those controls into inanimate objects. The idea’s simple but it allowed for a variety of interesting puzzles.

The mid jam crisis:

I started the jam as a programmer in a pretty large team (including 2 artists, 1 Composer, 1 Sound Designer and 1 other programmer). The GMTK jam had > 15k participants and it was a huge collaboration opportunity for a nobody dev like me. Everybody in the team was super talented. And yet I quit the team one day into the jam to work on a different game by myself. What went wrong?

Well, a lot of things. We spent an hour brainstorming ideas after the jam started. The idea we had settled on as a team was a game with a narrator that encouraged you to stick to a predetermined path and you can ignore his instructions to escape his control. We iterated on this further but we could not make the level design any good and we had lots of scope creep. It was obvious that we wouldn’t make it in 1 more day.

We had to give up and start another brainstorming session. The team was clearly worn out at this point. We couldn’t come up with a decent idea we could agree on (My control injection idea was still WIP). So, they wanted to make a “safe” game that we could complete.

I understand why. With all the art and music talent involved, even if we made a safe game, the resulting game would still be a decent portfolio piece. On the other hand, I was confident that my idea was something I could even finish alone. It might not garner that much attention but at least it would be something I’m proud of. I made my choice and parted with the team with 24 hours remaining.

Did I burn bridges I couldn’t afford to burn? Yes, I did. Do I regret it? Not one bit. I would love to collaborate with everyone on the team again even though things got awkward between us. But making a good game was and still is my priority.

But the clock was still ticking. I had no game. Just a vague idea, some badly drawn level layouts on paper and functional platformer code from the first day. I had to cut scope. I originally had more mechanics planned than just being able to move platforms. I cut out all things except that. The core mechanic was good enough to make levels out of just that. I set up Trello for each feature I needed to implement. Finally, with the alarm set to 6 AM, I went to sleep at 11 PM; I fell asleep at 1 AM.

I woke up at 8AM. I took some coffee and jumped back into code. Moving platforms was done within an hour. Then I implemented the control injection mechanic. The base game was done within 2 PM. Now, it was time for level design.

I spent 1.5 hours drawing pen and paper levels. I picked 10 from there. I had to adjust some things and rework some code to allow for some things. It was all done at 7 AM. The game was done. But I still had to polish the visuals. The jam would end at 1 AM for me. I polished the game up to 1AM, made a desktop and webGL build, submitted and went to sleep.

That’s all for how the jam went. Now I’ll try to elaborate on how I approached specific parts of the game’s design.

Level Design:

I had made a bunch of jam games before. But all of the levels in them were essentially hallways. A puzzle platformer was a nice chance to focus on the level design for once. This is how I approached it:

1. Nobody playing your game will look at the description page for instructions unless they are stuck. And if they are, then you’ve already lost. So I made a point to design levels so that they taught controls. The first three levels were dedicated to this. I teach players what keys to press, how to aim etc in these levels.
2. Tutorial text pop-ups take you out of the experience. I tried to limit the amount of text to only control descriptions and teach the mechanics through simple levels. NO levels other than the first 3 have text. Not all games can get away with this. But this sort of elegant design is possible in a puzzle platformer.
3. In general, use less text. Show Let the player figure it out himself, don’t tell them outright.
4. Introduce new concepts in a safe environment. I always make those levels short and easy to complete so that the player can feel good about learning new things. Then I introduce twists.
5. There were a lot of bugs that would have taken time to fix. Instead of wasting precious time on that, I embraced them and made levels utilizing them. Ex: The goal of each level is to reach the flag. The moving platforms don’t adjust movement to account for passengers’(stuff sitting on the moving platform) collision. This means that , if I attached a flag to a moving platform, the flag would pass through blocks. After noticing this, I just made a level where you HAD to move a flag through a block.
6. Don’t be afraid to make “joke” levels. I have a level that is shaped like a skull with controllable platforms for jaws. And you basically had to get “eaten” to complete the level. It is a lame joke but it is one the player participates in.
7. With puzzles, you can have red herrings that mislead the player. For example, I have a level where the player will immediately want to go right. I taunt them with a cheeky powerup that would have let them do just that but it is out of range. And the level is actually completable without the powerup.
8. In general, if you have a starting theme for a level(even if it is something as stupid as not being able to go right), level design becomes easier.
9. I think most of the levels in the game are too heavily “designed”. There is often one way to solve things and that makes things straightforward if you figure it out but frustrating if you don’t. This is something I need to work on.

Thoughts on presentation and polish:

In general, it’s recommended to dedicate the last few hours of a jam to polish. I had 5 hours to polish the game. On that front I think I failed. I’m using some post-processing effects but I should have tweaked the visuals more.

Having good visual communication also corresponds to having a polished game. One thing I wanted to ensure was that information was always clearly visible to the player. Ex: The player always knows what direction when he can move in because the powerup shows up on his sprite. Similarly, “injected” platforms also show visually how they can move.

I originally had WASD keys as the powerup icon but I changed it to directional arrows since it was more intuitive.

The color theme and bloom is where I think I sort of messed up. The current color scheme works but the bloom is a bit too much. I had an issue where I had to redo the colors after switching to webGL so that wasted some time as well.

I think the other problem is that I should have used reference images from other games that have already pulled off an aesthetic like this. Like this one.

That looks far better than mine and yet there is nothing there I couldn’t have implemented.

Misc insights:

1. I said that nobody will look at your description page. However, that doesn’t mean that you should ignore it. One thing I noticed when someone was streaming my game was that she wanted to reset the level when she was stuck. You can hold R to Reset the level in my game. But I forgot to include that information in the game. She quickly glanced through the description page. The control information was there but she didn’t notice it in that quick glance. So I changed the page and made it so that the Control section text has a large size to attract attention. I also bolded the text to make it noticeable. You can see the new version here. In general, make sure that the vital information in the description page is easily legible.
2. You could make the control information text more easily noticeable by using images for buttons. That will quickly grab the attention of any viewer. Especially if you use gifs for the buttons.
3. The description page is also the thing the player sees when checking out your game page. So make it look good unless you have crappy art skills like me.
4. When making puzzle games, the solution will always be obvious to you. So watch other people stream your game so that you can see where they mess up. The GDC level design talk by Celeste devs is also a good suggestion to handle those cases.
5. No one is obligated to like or play your game. If you want feedback, contact streamers, Ask other devs to review your game in exchange for you reviewing theirs.
6. I had a huge timezone gap between everyone else in my team. On the first day, this meant that I had to sit around for the others to wake up once I had finished my allotted work. When building teams with a timezone divide, I recommend that there should be a “glue” member who is awake during the when the divide happens.
7. Having a team with timezone divides can also be helpful. If you allocate tasks correctly there is always someone working on the game even when you are asleep.
8. There will always be “grunt work” in game jams such as setting up SFX triggers and what not. You don’t need a lot of technical skill to do that. If everyone on the team is comfortable with the engine, people who are waiting for new tasks can jump in to handle the grunt work and help out.

That’s all. Thank you for reading that wall of text.

You can play the game: here.

You can rate the game: here.

This is my 6th game jam. I avoided discussing old topics that I had addressed previously. If you want to see advice from a first/second timer’s perspective, I’ve got you covered.

Postmortem of my first game jam.

Postmortem of my second game jam.