Hey there!

So recently I've participated in the annual GMTK Game Jam. Well, not exactly recently - it's already been a week after the jam ended, but the voting period ended not too long ago. So I thought I'd make this post to share my experience of creating a game for this year's jam. You can also think of this as a piece of advice for future self - or really anybody taking part in a game jam, for that matter.

Short summary: I made a game! You can check it out at https://shadowlt.itch.io/away-from-keyboard, or just by clicking the link at the top (or bottom) of this page. Anyways, let's get a bit more serious now. On with the long summary.

Long summary

---------------------

Opening Thoughts

First of all, to fully understand this devlog, it is highly advised to play the game linked above.

Secondly, parts of this devlog were written in suboptimal times of the day and/or suboptimal weather conditions (we have a heatwave in Europe at the moment), so excuse me if I've made any grammar mistakes (I didn't bother to double-check the entire text).

With that out of the way, let's get to the main story.

---------------------

Day 1 - Brainstorming

On July 7th, 2023, the theme of this year's jam was announced: Roles Reversed. I wasn't expecting this to be the theme of this year's jam, but hey - the theme is supposed to be creative and unpredictable after all. Anyways, the theme was definitely better than last year's Roll of the Dice. Just after hearing it, it was clear that we weren't going to see a lot of repetitive games using the same concepts like last year.

After watching the theme announcement video, I got to brainstorming. After a quick not-so-serious deviation to explore what could be done with the shmoover genre this year, I went on to explore another idea I had (admittedly, I did find some fairly interesting shoot-to-move mechanics, but they weren't fun enough, so I moved on).

I wanted to make either a platformer, a puzzle game, or a metroidvania this year, ideally borrowing mechanics from all three genres. Then, I experimented with taking away the core mechanic of almost any game - movement. What if the player couldn't influence how the main character moved? Surely, that'd make an interesting game to play through. And that's how the core idea behind what would become Away From Keyboard was born.

At first, however, it was a vastly different concept. I imagined the player going through levels on a preset path indicated by a dashed line, and you, as the creator of the game, had the power to alter the level in order to make the player complete it. Ultimately, I didn't go down this path for two main reasons:

1. It would have been to difficult to code. What if a player suddenly placed a block that interrupted the preset path? In that case, the player would have too much freedom, and we'd need to make some sort of AI to fix it. However, good AI usually takes a lot of time to develop - precious time which there's not a lot of in a game jam.
2. Although I was not 100% sure, I had probably seen this concept somewhere before the jam.

Because of those two reasons, I slightly altered the concept of the main character's movement: it would always move straight ahead. Instead of the player, you would move the mouse cursor and objects in the level. That was much easier to implement, and I'm glad I chose these movement mechanics instead of the ones mentioned before.

When I had the concept and main idea nailed down, the rest of the mechanics came naturally. I needed to find a way to make the character actually move where the player wanted, and that's how bricks and bouncy blocks came to be. Mini spikes added a bit of challenge, and stop signs gave time to think in critical moments and important sections of gameplay. Gravity blocks were the idea that really brought the entire game concept to life: they made the gameplay feel interesting and dynamic. I even had the time to make some of the tile sprites in paint.net.

Before finishing up for the day, I also made a quick sketch of the game map, and thought about the lore of the game for some time. In addition, I decided to make each area have a collectible: a slider which would allow you to alter the physics of the world around you. I was pretty pleased with these ideas, and went to bed 2.5-3 hours into the jam (if you're confused at this point, here's a friendly reminder that timezones exist!).

---------------------

Summary of Day 1:

• What went right: the theme. It was really creative and thought-provoking compared to last year's. The game idea didn't come to me as fast as in the previous two jams I've participated in though - perhaps that's something to note for the next year's jam.
• What went right: the brainstorming session. I came up with a pretty solid concept for a game in a relatively short amount of time, and then prototyped some cool mechanics I could use in level design.
• What went OK: the sleep schedule. I woke up earlier than usual and had a sufficient amount of energy to work on day 1. To save me from commenting on this again, sleep on other days was fine too (I mean, I could have got a couple more hours in, but I just wanted to make this point in order to accentuate the importance of being well-rested, hydrated and energised during a game jam).
• What went wrong-ish: not making a game prototype on day 1. I mean, it's not the end of the world or anything, but it usually helps to have at least a few mechanics working by the end of the first day. I did have the main mechanics written down on paper (and on a whiteboard), so that probably helped to implement them on day two.
• What went wrong: not making a detailed plan of actions for day 2. In fact, as you're about to see, bad time management is going to be a common theme across most of the What went wrong sections in the summaries. Usually, when participating in a jam, I make a detailed plan of actions for each day. To give an example, it might start like this: 8:00 – 9:00 – implement player movement/camera controls/jump mechanics. Basically, this schedule makes me push myself through and get more things done than I usually would have. There are a few reasons for this.
  • First of all, you might get tunnel vision. If you're stuck doing something for a long time, perhaps a change of perspective is needed in order to understand the problem better. So the next entry in the schedule could be for doing something completely different, i. e. 9:00 – 9:30 – sprite design. When you do finally return to finish the thing you were supposed to complete at 9:00, you might catch the missing semicolon or weird calculation in your code that's been messing everything up.
  • Moreover, you tend to do things faster if you're late on schedule due to the increased pressure you're experiencing. Well, at least, that's true for me – I can't speak for everyone.

---------------------

Day 2 – Implementing the Mechanics

In the morning, I started working on the actual game. At this point, I also had to think of a name for the game, which took about 15 minutes, until I finally decided on Away From Keyboard, which fit in with the story I was going for. Actually, this idea for the name was from Day 1, along with The Long Way Back Home. Ultimately, I ended up merging these two names and ended up with Away From Keyboard (a. k. a. The Long Way Back).

Side note: I had plans to make an intro cutscene on day 3. However, that was obviously very unrealistic, so I ended up replacing the cutscene with a large textbox of lore. Nevertheless, I will include a short retelling of the cutscene here to make sense of the full title of the game. Basically, the starting screen of the game originally only displayed the title Away From Keyboard. Upon pressing the Start button, you would enter a cutscene where the hired playtester starts playing a new platformer titled The Long Way Back. However, for some mysterious reason, the game would crash, and after that the player would enter the sequence described in the lore textbox.

Anyways, most of the day was spent implementing the main mechanics. Write some code, try to see how it works in play mode, do some bugfixing until everything works, rinse and repeat. Overall, I had more experience in dealing with Unity and physics issues, so I'd say that was definitely one of the better things this year (i. e. I didn't feel completely hopeless when something didn't work the way I intended it to). Over the course of the day, I wrote the following scripts:

• Camera Controls: camera follows the player, level restarting, tile resetting, checkpoint system.
• Player/"main character" movement script: apply constant movement/acceleration based on speed/gravity modifiers (I had to code the physics from scratch since Unity didn't do exactly what I wanted), check collision with floor/tiles/walls/spikes
• Tile movement script: limit to set number of tiles, reset position, limit to set radius.
• Set tile active script: using OnMouseOver() to do stuff.
• … and probably more.

On this day, I also created most of the game sprites, and made a few platforms I could playtest on.

What really screwed me over this day was the physics. At first, I tried using built-in Unity physics, but that caused collisions to be handled really poorly. The main character would usually just get stuck in walls and not move. After implementing what I thought was a pretty decent gravity system, the main character still got stuck in walls, but this time constantly gaining downwards acceleration. My solution to this was writing some code to check for wall collision.

In hindsight, this was all tunnel vision, and I just needed to write some code to detect floor collision. Upon realising that the wall collision detection code was completely unnecessary, I quickly fixed the gravity system, and it was now working properly. Well, not exactly quickly – it took like 3 hours to fix the issue. And the gravity was still kind of broken due to another bit of tunnel vision spaghetti code.

To fully eradicate this glitch, I needed to use some Unity gizmos (meaning: learn what Unity gizmos actually are and what they do) in order to render the bounding box that I was using to test for floor collision, and it turned out to be offset by roughly 7 Unity units of distance measurement (for scale, the main character is smaller than 1 square unit). And the ground tag I was using to test for floor collision turned out to be assigned to wrong GameObjects.

Anyways, this time I made a plan of actions for the next day and went to sleep.

---------------------

Summary of Day 2:

• What went right: experience with the Unity engine.
• What went right: finishing the main mechanics and sprites.
• What went right: installing Visual Studio Code was a big improvement from Notepad++.
• What went wrong: no plan for the day, hence less progress overall.
• What went wrong: tunnel vision when getting the physics to work properly.
• What went wrong: trying to rely on the preset Unity physics system.
• What went wrong: not remembering to take proper breaks.

As you can see, there's lots of lessons to be learned from this. Come to think of it, I can think of another one off the top of my head:

• What went wrong: leaving the postmortem for a week after the jam. It's easier to write about fresh experiences, after all.

---------------------

Day 3 – Finishing Up

This time, I had a plan. I knew the exact order of the things I was going to do that day. And I stuck to the plan… mostly.

Implementing the stop sign and bouncy tile mechanics turned out to be a little bit more complicated than I initially thought it would be. The gravity switching code from the previous day was working fine, however, after testing different directions of gravity, I realized that the player rotation wasn't being set properly. Some other scripts were also a bit broken when the direction of gravity was changed, so I fixed those too. I think I used up roughly 30 minutes more than I had planned on this section of development.

My next decision was a really bad one: I tried composing some music tracks for the game. I tried doing something with a cool synth and pitch-bending on LMMS, however I couldn't come up with anything that sounded even remotely decent in half an hour. After that, I just gave up and searched for copyright-free tracks online and generated some sound effects on jsfxr.

Then, I also made the slider sprites on paint.net. Originally, there were going to be two more sliders: a time slider and a bounciness slider. I might revisit those ideas if I decide to continue developing this game in the future.

At this point, the idea of a tutorial/story cutscene was off the table, but the game still needed a starting scene. That's where I spent roughly the next two hours. I did the title screen picture, configured some project/build settings, did some scripts for the buttons, and made sure the UI looked good enough.

After that, I needed to actually implement the sliders and their mechanics into the game. That wasn't too difficult, and took less than an hour.

Finally, before starting work on the level design, I wanted to do some final polishing. Some animations, making the music and sound effects work properly, fixing annoying bugs, things like that.

When I finally got to the level design, there was only 3-3.5 hours left until the end of the jam (I don't recommend anyone participating in a jam to do the same). Nevertheless, I pushed through and set a hard line for myself: when there's only 30 minutes left, I have to have a working build that I'll then try to submit to itch before the servers crash.

Anyways, in roughly 2.5 hours, I managed to create and playtest the tutorial section (grassland cave) and quickly put together (but didn't playtest) a cloud section for getting the speed slider orb and a sandy wasteland cave section for getting the gravity slider orb. Obviously, I needed the game to have an actual ending, so I decided to just spam some spikes and bouncy blocks and make the ending all the way in the top-left corner of the map, which would be reachable after reversing gravity and collecting at least one of the two orbs.

After adding an ending screen and a final bugfixing session, the game was "complete" in the sense that it had a start screen, some gameplay, and an ending. Of course, ideally, I would have done some more level design (the game ended up being a bit shorter than I wanted it to be) and polishing to eradicate some more bugs (most notably – the ending sprite and background tilemap were in the same sorting layer as the skybox, so they were invisible in the final build).

After a successful build and some last-minute changes due to UI not working properly, there were only 30 minutes left for submissions. The time had come to submit, so I created a new itch project, filled out the necessary details, uploaded the file, and… it didn't work. Not on the first try, at least. I had to try uploading on multiple tabs because time was running low. Of course, like every year, the itch servers crashed. Because of that, a time extension of one hour was announced. After seeing my file safely uploaded and making sure the download works properly, I breathed a sigh of relief and polished up the game page. Then, I finally submitted the game to the jam, and it was all over.

---------------------

Summary of Day 3:

• What went right: I made a working game and submitted it to the jam in time!
• What went wrong: underestimating the amount of time to do certain tasks.
• What went wrong: trying to compose music.
• What went wrong: not leaving enough time for level design, playtesting and polishing.
• What went wrong: uploading the game at the last minute.

---------------------

Voting, results, statistics

I won't comment much on this (at least yet; I might write more once the ratings go public). I played and rated some great games, got some nice feedback for my own game. Overall, although there were some recurring themes, all the games I've played had a unique identity and style. In total, I've rated 26 entries, and my own game got rated 21 times. I also wrote 519 lines of spaghetti code in C#.

---------------------

Closing Thoughts

Like in the previous years, the GMTK Game Jam was really fun to participate in. I learned some new things, enhanced my gamedev skills, and got valuable feedback. It was an awesome experience, and I hope to return with another game at next year's jam!

---------------------

Game Update Stuff (post-closing thoughts)

…and don't worry, I've noticed the bugs in the current AFK build too. The post-jam version will come out very soon and fix them. After that, there will be a post-post-jam/"reimagined" version, which is basically what I was originally planning to do in the jam (same mechanics, but more content). I don't know if I'll update the game after that, but we'll see.

And I also haven't forgotten about my other game jam games. I will probably have more time for gamedev soon, so I might release v1.1 of Magnetic Linking. But no promises because they backfire very quickly if your schedule gets messed up with (un)expected events.

Anyways, there's pretty to look forward to in the future. With that said, I'm out for now.

Thanks for reading this devlog to the very end!

~ShadowLT

(oh wow there's more than 3000 words in this devlog! no wonder writing is so tiring.)