GMTK 2025 Experience

For the second year running some of my close friends and I decided to come back and try our hand at the Game Maker's Toolkit Game Jam. It's the biggest game jam every year with a lot of tough competition and it happens every year in August. We did pretty well last year with our game ingredient pursuit, ranked #793 out of 7,725 teams that finished. So with that success lingering in our minds, we thought that with another year of experience under our belts, this year we could blow it out of the water. This is the full story from when my friends and I gathered in my apartment to create a concept to the final score and retrospective of how I really feel it went. Also here's a link to the game if you want to try it before reading this blog.

As team lead/organizer normally, I start in late May or early June with the ocean eleven style phone calls where I ask the guys if they're down to run it back one more time. This year Jacob and Gabe (from Akimb0 studios) returned as participants and one of my friends Ian, who was new to game development, also joined the roster. Then came the prep sessions, we met bi-weekly and decided game engine, game dimension (2d/3d), packages, and what work we wanted to get done prior to the jam.

I had several goals prior to this jam:

• I wanted to help Ian get a basic understanding of Unity and if he had time to get him use to using some of our larger packages (Mainly MoreMountain's Top Down Engine).
• I wanted to have everyone have all the dependencies and Github repository installed and working ahead of time.
• I personally wanted to finish developing the graph based random generation engine I've been working on (expect another blog post on that).
• Since this was the first time I was hosting everyone at my place, I wanted to make sure that I had the necessary furniture, cleanliness and food for a game jam. (My apartment had no table for instance in June, when I started planning this).

So I worked on accomplishing those goals and as August approached, I felt really encouraged as my team felt excited, engaged and prepared. Even my apartment began to take shape. Everything felt like it was much easier than last year and Jacob especially as he's so much more experienced helped a lot with the small details and Ian was picking up unity at a breakneck pace. Then just as July ended I had a breakthrough with the random generator and on August 2nd, the day before the jam somehow it was working inside a WebGL test build. I then spent that night and the morning of August 3rd cooking curry, chili and slow cook barbecue chicken, so we wouldn't have to waste time sourcing food, then quickly threw the generator package into the repository for everyone to pull down.

Everything that I wanted to do, I had accomplished and was in place. Then Ian showed up, we hopped in the car picked up Jacob from the train station, drove back to my place then 30 minutes later the theme released.

Now a game jam is a feverish experience, a lot of planning goes into it, but something happens when the theme is released and as an ex-track runner it feels like the gun of a race. The silence of anticipation gets erased and now there's just this loud mashing of shoes and cleats, the sounds of a cheering crowd and the heavy breathing of everyone around you. But your brain at that moment does its best to drown it all out and focuses simply on one thing: the finish line. Every other thought leaves your brain. Jams lack that physical component, but mentally its incredibly similar. All the sudden the mind comes to an insane focus as the pressure hits. We have 96 hours, now a little less, to turn that word into a game. We all just start drafting ideas, separately then occasionally together. We do this for two hours some ideas fall flat instantly, some get iterated on, with everyone providing their own take, then eventually a vote takes place.

The winning concept was dubbed "Generational Trauma," a play on words about a game where you play as a bloodline of characters where once a player dies, his son become the next player and the stage ages with the next generation coming to fruition. Also it was a double entendre as we wanted to leverage random generation for the stage and the aging mechanic.

Side note: some of the reject ideas were: Hell's Cereal which was game about making a cereal factory to produce loop-o's. Another was "Cycle of Violence" an auto-battler where different units would clash on randomly generated stages. Also "Night Cycle" a game where the player would turn into a werewolf at night and you'd try to do certain tasks in the morning to make sure you didn't kill your family at night.

We then wrote a quick game design doc and assigned starting roles and tasks to everyone. I of course took on stage generation and art mainly. Jacob was given basic player controller, enemies, and 'inheritance' mechanics. Ian handled odd jobs like sign dialogues, handling animation controllers for enemies. Gabe was in charge of the sound track.

Now began real development where code starts to hit the game engine and it was also when the problems with our concept started to rear its head. Now instead of chronologically retelling how we developed 'Traumagic,' the final name of the game, I think it might be more interesting to retell the development through the lens of how this concept snowballed into a product that didn't accomplish what we wanted or hoped.

The first problem was something that should be known instinctively, but that I had forgotten; the main mechanic must be fun. And unfortunately, ours was not intrinsically fun. The concept of dying then having the map change is very interesting and cool. BUT, strip a game down and have that be its core and only mechanic, that is not a good game. A good game could have this 'death inheritance' mechanic (see Rogue Legacy 2), but it would need to have a world that was engaging so that people would stick around long enough to die and discover the mechanic.

I at some level noticed this instinctively and decided that first we needed to create a world for which that mechanic could live in. We couldn't just implement the core mechanic first, as the game wouldn't be worth playing with that alone. So, we decided to make a massive randomly generated world with six different zones each with their own distinct enemies. This caused the second big problem.

Scoping, this is one of the biggest and most common issue with game design in my mind. A clean concept has a clean definition of what is in a what is out of scope, its easy to tell what you need to do. Now vague concepts with shifting scopes can make good games, they're probably more examples of this than clean concept games in my opinion, but when you're making a game in 96 hours, cleaner is not only better, it's essential. If you have a clean concept, you can quickly determine if something should be in the game, or out of the game. When I realized the game needed an intriguing world for our 'core' mechanic to live in, we started making it on the fly, vague concepts on top of vague concepts. Which ended in us spending a majority of our development time on features never planned or scope initially at all. This problem is what totally wrecked the day by day schedule I originally planned around, as the scope was unclear so was when we should stop developing.

Now poor scoping, as I said, it's always an issue, but there are several ways to combat it. One like I said is having a good clean concept, we did not have that. Another is great communication, but that was another point that I found that we were lacking.

The issue of poor communication from my perspective was a big deal, but when we met after the jam and talked about the jam in retrospect, the rest of the team pushed back on this, they felt we had good communication. Now, I don't disagree, this jam we talked a lot and had very little issues with stepping on each other toes with merging. We also did a really good job, staying on our feet and pivoting to different tasks, that was good communication. But I'm making a nuanced point, put that communication aside, that communication around feature effort was specifically lacking.

I think I fell incredibly short on understanding how long specific tasks would take. I don't really code enemy AI much anymore since I started working with Jacob and I just kind of assumed with leveraging TopDownEngine we could reskin and reuse most of the enemies really quickly. My during jam solution to the scope problem was to make some generic enemies and generation then move on quickly so we could get to 'the meat' of the actual death mechanics. So I set a break neck timeline of implementing six to seven unique enemy AIs in about 24 hours. This was the most egregious example, but I just didn't realize that was not possible and if I had just asked Jacob and Ian for time estimates or potentially enacted time-cutoffs, to stop coding such and such after this time, then we could've avoided a lot of the scope issues.

But even with all of those issues Traumagic had a lot of redeeming qualities, at this point in development, we had a cool stage, some cool enemies, and some basic death mechanics, but most importantly we had a minimally viable game loop! There was one last chance to salvage what we had and make it fit for a general audience.

We needed to polish and test, but we didn't. When you barely finish an essay before you hand it in, you know it's gonna be full of errors. Games are no different. The reviews of our game were filled with complaints specifically about crashing, audio problems, flashing lights, clunky controls, etc. It would've taken 4 hours to fix all of these problems, but we were so frantic that we missed all of them. I've decided that next time, I'm going to get some friends that if they do not develop they will have the role specifically of a tester and giving builds to our testers will be a critical fixture in the next schedule. So even if we have some of these issues arise again, which I'm sure they will, we will have a built-in points to reflect and re-direct into the schedule.

In the end Traumagic was submitted with three minutes to spare, not on the original deadline of 1PM est, but three minutes before the extended deadline of 2PM. So after 97 hours, we finally submitted the game.

A week later I held a retrospective with the team and walked them through the same narrative I just laid out about how the project fell apart and why the reviews were not very good, you can see for yourself.

But as some time had past and we were chatting about the project, looking back at Traumagic, despite the tragic development cycle (har har), I felt incredibly proud of my team and what we accomplished. Whilst trashing on our lack of polish, comments couldn't deny how much work we put in. Our score for narrative was in the top 500, or top 5% of the jam. The random generator actually worked and generated 147,000 tiles in less than 3 seconds in browser with a graph of 70+ nodes. We had a randomly generated name and character system. We made unique enemies for all zones in the game. We made an inventory system with several different equip-able armor pieces and weapons. We even managed to implement that 'death inheritance' mechanic, even if not fully fleshed out. Not to mention that Ian went from knowing no unity to developing dialogue system and working on Enemy AI projectiles. All that said I finished the jam feeling disappointed, but at the time of the retrospective and even now I feel that we really bit off a lot, then finished a game and learned a ton. You learn more from your mistakes than successes.

So after the jam, I went ahead and did the polish, fixing crashes, visual glitches, and lag. Now the game is a bit more definitive although it still has issues. So try it out! Let me know if you think if I was on the money or misses the mark with my analysis. And if you were disappointed this post was not a technical blog about how we made the game, as it was more about the pitfalls of organizing and leading a team in a game jam, do not worry! I will be making a post about the random generator and the cosmetic system used in Traumagic and hopefully that will give a little more insight into the technical side if you're interested.

Thanks for reading!