Post Mortem GMTK 2025 Jam

The GMTK GameJam of 2025 was... huge. In entries, in ratings, in the quality of a lot of the games, in the team sizes. For me, it was huge because it was the first time I was the team lead of (in the end) seven mostly strangers, and because it the first time I was determined to finish a game fully and publish it somewhere. Also my first GMTK Jam!

So, naturally, a lot of unexpected, not-great things happened. I (Project Manager & Artist) will summarize first what major problems my team and I encountered, and then move on to the good things and learnings. 

Team members going MIA or not available on short notice. [The Ugly]

The biggest problem I encountered managing this project was, that in total two-and-a-half members went MIA without any communication, and two planned members said they don't have time after all, a day or two before the jam started - at least they were vocal about it and I was able to find replacements. Those that went MIA didn't communicate at all, which meant we lost up to two days realizing they are gone for good, and me trying to quickly get another programmer or artist on board. But let's do it in order. 

After our possibly SFX designer and a second seasoned programmer said they don't have time, I went to the "find a team" channel, and prayed. Thankfully, I got our amazing SFX designer right off the bat, and another two programmers as well - thinks were looking good. After we had our second meeting the next morning, I noticed something was off with a member as they did not participate at all, and, after I checked in with them, were very non-caring about anything, but I explained our final idea and what the next steps are gonna be, alright. Problems arouse the next day, when one of the programmers I got on board did not take part in the morning meeting and did not respond to anything else - oh no. I decided to give them till next morning, but no luck - gone without a word.
The other member that was off? They had a very different idea on how teamwork and jams worked (despite being in multiple ones, somehow) and were not very communicative about it all, except the occasional accusation towards me for not knowing what they need - when they don't communicate. After long discussions, I was able to give them the infos that they needed, they did contribute a bit - but were not up for doing anything more, despite there being more work, which was clearly stated and discussed. Very frustrating experience, sadly. 

Anyway, back to the programmers, I got two new ones on Friday, nice. One of them contacted me twice before, said that they want to join, so I gave them the chance this time - after I checked in with them if they are certain they can complete the tasks, of course, to which they agreed. So, I walked them through the project, all the tools, gave them access. Never heard again from them after the introduction call ended, despite me begging them to not just go MIA if they don't have time. Oh well, thankfully, the second programmer stayed with us and is an important member of the team now!

Schedule delays and not setting proper deadlines [The Bad]

While I would say that the prior part was mostly about problems with other people, this part falls mainly onto me as the project manager/team lead. Despite trying my best with having an ordered, clear, and easily accessible documentation (Trello, Google Docs, Miro Board), and keeping the apparent scope small (Rings on hooks with score + shop with minimal upgrades), we ran into extreme delays leading to us not being able to test and polish the game before uploading - leading to major bugs and QoL features missing, tanking our overall rating most likely. When I talked with my team about this afterwards, one mentioned that it could have been a good idea to set clear and proper deadlines for tasks, as they were often unsure how much time is still left for other stuff. This was an oversight on my part, while I was trying to be check in about the status and keep my team in-the-know about remaining times, I was not super strict with time, leading to us having major issues. The team-changings throughout the jam and getting members on-board mid-project definitely were fueling this problem to the max, and maybe I couldn't have done much to change the outcome, but I could have tried more things. We uploaded our final build 58 seconds before the extended time ended! An hour before barely anything worked in the shop, so, the extensions saved us to fix the roughest problems - lucky. 

Daily team meetings [The Good]

It was a goal of mine to have at least one team meeting a day, to talk about the current status, next steps, and check in generally with the members. This was partially a bit difficult as we had a member in Australia, Palestine, and other Europe-based timezones, or members had work, but thankfully it usually worked out somehow and was always a good kick-off for the day (or evening, for Australia). Generally, I think these meetings were good to keep everyone motivated, clear out miscommunications, and set priorities. 

Met all scope goals [The Great]

Despite all the problems, in the end, we met all our planned out goals for features, feel, and sound! Yeah, we had some major bugs, but we still managed to achieve our original goal - I am very proud of my team for pulling that off, surely some sacrificed a few hours of sleep for that (including me). This shows again: Keeping the scope minimal from the beginning is a benefit in the long run for a jam.  Using Trello as a task-tracking tool helped organize workloads and keep track of to-dos, while the GDD I updated when needed was a good reference for newcomers and general guide for the game. Sometimes I had to decide on team members moving on to different tasks as they were either spending too much time on one, or working on something less crucial while other things needed work/members needed help. Thanks to all of this, and the enthusiasm, the engagement, and skills my team had, we managed to meet our scope-goal, albeit it was two days after my planned schedule. 

The Learnings / TL;DR Insights

• Scope small - and then smaller. We first had the idea of something somewhat bigger and entirely different, but I decided in the end to go for the loops-in-water idea, as this was our smallest-scope idea (presumably). 
• Use a task-tracking tool - improves efficiency, helps to keep workload in check for each member, motivational boost when something is done - and generally gives a good oversight of the status and trajectory of the project.
• Keep everyone updated about time remaining, current status, next steps, changes - easily done by a daily meeting, or a structured written message that pings everyone. Nobody wants to work on something that they lost the connection to or can't see/understand the end-goal anymore. This also enables the individual member to be independent and pro-active with ideas and implementations.
• Set deadlines for crucial tasks/features - Something I missed to do, which most likely is part of the reason why we went so off-schedule. If the deadline is not met or seems to not being able to be met, check up on why and what can be done. Maybe add another team-member to the task, or down-scope the task. 
• Stay flexible, react quickly - With all the changes and problems we encountered, it was crucial to not stay too fixed on plans (or team members lol). When it's clear that something is going awry, quickly getting to it and not letting it cook until it becomes a fatal problem is key in the dynamic and fast paced world of a game jam - and other highly dynamic projects. Me reacting and dealing swiftly and confidently/certainly with member drop-outs, task-problems, and others, helped to keep the team and project alive and/or achievable in the time we were given. Naturally, my members as well quickly tackled problems in their areas to keep the wheels moving, the loops floating - programming issues, sfx-memory problems, dealing with the limitations of the web-browser.
• Finally, trust in (the expertise of) your team - if you got their backs, they got yours. Ask for help, provide help, and trust that tasks will be dealt with by others. You might have not known each other before the jam, but that just even more means that trust is all we can provide. If problems arise, they can be dealt with. If someone feels pressured, not trusted, or anything else negative, that is something that can hardly be fixed and that can be detrimental to the project. Just be good people and treat others how you want to be treated, a'ight?

Final words

Well, that was a whole lot of text. Never written a post-mortem or any kind of blog - hope this was insightful, or helpful, and the correct way to do it! I had a whole bunch of fun in this jam as PM and Artist, and my team and I are working on polishing and properly publishing this little nostalgic trip of ours. While we didn't place where we hoped we would in the final ratings, for the first big game jam some of us participated in and a bunch of strangers working together, we are happy to be where we are.  On to the next jam, bye!