Participating In Gmtk

September, 2022

Every summer, Mark Brown from Game Maker’s Toolkit hosts the GMTK Game Jam (Game Jam is a fancy term 🥂 for game development competition). Every year, this jam breaks records - most participants, most games submitted, most ratings, etc… This year was no exception.

This year I teamed up with my friend Jordyn Hamilton!

We had made 1 game in the past together, but we didn’t really know what we were doing so we decided to give it another go with this Jam.

We had 2 goals:

1. Make a game that is fun to play (this may sound obvious but it is surprisingly easy to miss this goal if you are not careful when designing your game)

2. Make a game that is visually appealing

With our 2 goals set, we adapted roles. For the majority of the Jam, Jordyn would be making the code assets, I would be making art assets, and together we’d design the mechanics.

On the day of the Jam, my parents drove me to Jordyn’s house for the weekend and dropped me off - we checked the theme as soon as I arrived.

The next 48 hours would be dedicated to heads down code, art, sound, design, bug fixing, etc…

🧠 Brainstorm

This is step 1 of most game jams, put all your ideas down on a document. Unfortunately for us, ideas were not flowing. We eventually landed on making a top down shooter, where the enemies are dice, and their attack patterns will depend on the number they roll.

🌟 Day 1

For this Jam, we operated on 1 rule - by the end of each day, we MUST have a functioning game. And that’s exactly what we did. Jordyn focused in on adding the core game loop: player moves, player takes damage, player dies - enemies spawn, enemies attack player, enemies take damage, enemies die.

During this time I was working on the main player sprite, originally it was going to be a cloaked figure of some sort, but as I was doodling around trying to get something to work, I drew something that resembled a helmet. I peeked over my shoulder, got Jordyn’s opinion, and the main character was now going to be a knight ⚔

As Jordyn was finishing up the enemy spawning script, I started adding lights to the 2D scene. We were going to theme this game around another game called Dungeons and Dragons (D&D). D&D is a tabletop roleplaying game. As an homage, we were going to make the playing field of our game a table. But man I struggled with this. I added lights, drew a table, redrew a table, redrew a table, redrew a table, and eventually landed on this?

But this was still very ugly. I tried replacing it with a brick floor, and it looked infinitely better. By the end of day 1, the player could move, shoot, take damage, enemies could spawn, move, shoot, take damage, and we had a score counter!

🌟 Day 2

In Day 1 Jordyn implemented the code for a base enemy, and made the behavior for only 1 type of enemy. Now that we had a functioning game from Day 1, it was time to add content. If you play D&D then you know about the different kinds of dice.

Most people are familiar with the D6 (6 sided dice 🎲) but we wanted to add ALL THE DICE!!! D4, D6, D8, D10, D12, D20, D100, D2, you name it!

During the short 48 hour time frame, we managed to implement a D4, D6, D8 and the D20. Going into this, I expected making pixel art dice to be difficult. But oh man, I underestimated the difficulty. Some of the final sprites took me up to 4 hours to complete, just for 1 dice! 😭

It was worth it though, because the final results look sick! Here’s a GIF of the final game!

If you want to try it out, you can play it using this link!

💡 Lessons Learned

Even though this Jam was incredibly smooth sailing, I still learned a lot from it!

1. Be In-Person - I had worked with Jordyn before, but it was online, and to say our results were sub-optimal is an overstatement. Even if working together online technically can do most of what being in-person can do, being in-person does most if not all those things better. Examples:

   1. Asking for help - For some reason, when online, especially if you’re not actively in a call with the other person, asking the other person for an opinion or for help with something is tougher. You end up spending more time banging your head against the wall until you get it working. Whereas when you’re in person, the other person is literally right there, you just turn your head a little and:
      “Hey can you take a look at this, for some reason it looks off and I can’t figure out why“
      “Try straitening the line a little bit?“
      ”Oh! Yep, yep that’s it, great thanks!”
      And done, issue solved.

   2. Spatial Sound - This may not sounds like a big deal, but Jordyn and I (and any other friend I’ve programmed with as well) when working together online, we hop in a voice channel on Discord, and leave our mics open to make it easier to ask and answer questions. Which is great, makes it faster. But, I think out loud (mumbling), so does Jordyn, so does any other of my friends I’ve programmed with. When you’re in person, this isn’t a problem, cause Jordyn can’t hear me mumbling, and I can’t hear Jordyn mumbling.

      When you’re on a discord call and our microphones are right next to our mouths, it picks up the mumbling. It’s such a small detail, but made the experience better.

   3. Analog Tools - Our feature checklist was in a journal I brought, and as we were going through the features, we got up, and checked them off the list. You can do this with virtual tools as well, but analog systems have a different feeling to them (one which I prefer)

2. Reverse Thinking - In one of Mark’s game streams were he plays people’s games in a random order, he stumbled upon our game. When playing it he made a specific remark: “I’m trying to think of how it would impact the game if the enemies weren’t dice“ practically thinking about the game in reverse. His conclusion is that, it wouldn’t change much if the enemies weren’t dice. The theme was not implemented in a strong way when it comes to the gameplay aspect.

   I find this to be an important way to think about the significance of things. If this wasn’t here, what kind of impact would that have. Answering that question shows you how important, or how useless some things really are.

3. Split Up By Types of Work - In our last project, the way we split up work was by task instead of type of work. For example, Jordyn would make the player, I would make the map. This didn’t work very well for us. For GMTK, we played on our strengths. I know how to make pixel art, Jordyn knows how to code, so we split up work that way.
   Jordyn would code the behaviors, and I would come in and add the art assets afterwards.