Things Seldom Go as Planned

I participated in a Game Jam held by a club in my college. This is what happened.

By Ice_Kube | 2026-03-01

The Beginning

Several days ago, the Game Dev Club in my school hosted a seven-day Game Jam with no set theme, aimed mostly at freshmen without prior experience in large projects. I had planned to lead a team, as I considered myself experienced when it comes to managing large projects.

But things seldom go as planned.

As people assembled their teams, I was too sick to even get online, let alone putting a team together.

By the time I recovered, the vast majority of participants had already found a team.

So I kind of got thrown into a team that was planning to make a tower defence game.

Well, beggars can’t be choosers.

The Preparation

Before the Jam formally began, the main designer, the main artist, the team leader and I had a little meeting to go over the project. The team leader considered me the most skilled man in programming and put me in charge of leading the programmers. Nothing groundbreaking, just laying the groundwork.

Then came a bigger meeting, where I laid out the rules for using Git.

For those unfamiliar: Git is a version control tool that lets teams collaborate on code. Without clear rules around how to use it, the codebase — or “Git repository” — quickly turns into a mess, which becomes a serious obstacle as development goes on. I later learned this happened to another team.

Not ideal under normal circumstances. In a rush project like a Game Jam, where efficiency is everything, it’s simply not acceptable.

On top of that, using Git effectively — avoiding conflicts, keeping history clean — requires some learning. Asking everyone to spend days getting up to speed wasn’t an option in a seven-day sprint.

So I made a call: I would take full control of the main branch. No one else, except for our artists, who would be only pushing assets rather than code, was allowed to push to it directly. Any programmer who wanted to merge their development branch into main had to go through me.

Kind of like a dictatorship, they said after the project ended. They probably weren’t wrong.

The Progress

On the first day of the project, I implemented an EventBus system for different scripts to communicate with each other.

Normally when a script A needs to communicate with another script B, A would need to know the existence of B to communicate with it, otherwise the program would fail, like how you would need to have someone’s phone number to be able to make a phone call to them. However, with EventBus, A would not need to know B’s “phone number”, it just gives the data to the EventBus system and the system routes the message to any script that’s listening for this specific kind of data. Similar to asking a company to “Call everyone that’s named Mr.Smith” without needing to know if there is any Mr.Smith.

The system was implemented for decoupling. We would need to make the scripts talk with each other without creating a tangled web of dependencies and to keep the codebase easy to extend. The advantages will become more obvious as the project grows bigger.

Since I have introduced a system that would be frequently used and nobody in the team had used before, I quickly wrote down a document about how to use the system, with some generic code that they can just copy-paste into the actual project.

Day 1 to day 5 went well.

The git history was pretty crammed, in the busiest hours it even somehow looked like a metro map.

The git history in the busiest hours

Not that it was “smooth”: bugs emerging every now and then, git conflicts resulting in someone having to write their code again, unclear code comments or no comments, wrong file encodings…

But they learn pretty fast. When I tell them what to do and what not to do in group chat, they fix it quickly.

Except for one guy.

The Collapse

On the fifth night of our seven-day development sprint, everything broke.

One of the core gameplay systems, the building system — a subsystem that most of the team had been waiting on — was finally marked “complete” and merged into the main branch.

This system was developed by a guy who rarely spoke anything in the group chat.

Well, being silent doesn’t necessarily mean being bad. As long as they can produce usable code in time.

I pulled the code and started reading through the logic, expecting integration work. Instead, what I found was a structural collapse.

The code technically ran, but nothing about it was stable. Control flow was tangled, responsibilities were mixed, and large portions of the logic were internally inconsistent — the kind of contradictions you only see when AI-generated code is never actually reviewed. Some functions appeared reasonable until you traced their state transitions and realized they could never produce correct results. Other parts silently violated assumptions the rest of the architecture depended on. Debugging it would have meant reverse-engineering intent that likely never existed.

Moreover, the problems I mentioned in group chat over and over - file encoding problems and unclear comments - are all over his code

Also, when using my EventBus, just copy-paste the generic code I put in the document and everything will be fine. But I found meaningless comments inside that generic code - clear evidence that he blindly used AI without even reviewing a single line.

There were two days left until submission.

So sometime late that night, I stopped trying to salvage it and made the call to replace the system entirely.

Day six became a day of emergency re-architecture. I redefined the data flow, restructured the interaction boundaries, and reimplemented the system around maintainable logic and predictable state transitions.

Or, to put it simply, I made a new building system with some logic recycled from the remains of his code.

The goal wasn’t elegance — it was clarity under pressure. By the time the new version was wired back into the project, the testers were already preparing for a full-day stress testing.

Day seven was pure compression.

Two testers ran continuous test cycles from morning to night. The rest of us stayed online the entire time, fixing issues as they surfaced. The first full test pass produced around twenty bugs with less than ten hours remaining. Every fix risked introducing new regressions. Every change had to be merged, verified, and retested immediately. The commit history for that day reads like a heartbeat spike.

No one really left their chair.

We submitted the final build thirty minutes before the deadline.

The system that had been unusable forty-eight hours earlier was now running in the release version.

Hooray.

Screenshot of the finished game

The Aftermath

After submitting the final build, everyone became relaxed and started casually talking in the group chat. One of the programmers mentioned that if not for my EventBus system, we couldn’t have finished before deadline. The system helped a lot by reducing potential bugs and the overhead of inter-script communications, which means it saved a lot of work.

The EventBus also allowed people to implement functionalities without the risk of breaking others’ logic.

But my work is not everything. It was never a one-man show.

I didn’t know how to make UI in Unity - the team leader handled that in the project, and built a fairly complicated system I’m not sure if I could have done better.

The other programmer took care of one of the most complicated systems: The enemy system and the archer NPC that would go behind a wall and shoot the enemies.

I had reserved an interface for him in the NPC systems. But he didn’t use it, instead he made an NPC system again and used his own.

Well… it worked anyway. It was my fault for not communicating with him well.

And, with our designer’s detailed document, we didn’t rewrite a function over and over again to fit the designer’s expectation like the other teams did. He also made the map for the game.

The same goes for our artists - we wouldn’t have the assets needed without their hard work. The sprites they delivered were clean enough that we never had to ask for a redo.

Also, credit goes to our two testers for their hard work on the final day, otherwise the game would absolutely be buggy and unable to play. In between the test runs, they also refined the map, making the game noticeably more enjoyable.

Except…

What happened to the guy who made the building system?

After day 5, I, as the actual man in charge, told him that I would now be taking control of the maintenance work of the building system.

I didn’t tell him that the code was “unusable”, I only told him that he wouldn’t need to write code anymore, just wait until testing started and join the testers.

He didn’t.

For the rest of the jam, he went completely silent.

After we submitted the game, during the casual chat that followed, he DM’d the team leader and had an emotional breakdown, flooded the DM with self-pitying messages that left the leader completely at a loss.

And then, he quit the group and probably blocked the leader as well.

For the record: I never explicitly said anything about his bad code, and I never brought up his name in the group chat. The only thing I did was to let off some steam in DM with the leader, as I was utterly stressed.

And I never said anything bad about him in group chat or in his DM.

About telling him that he wouldn’t write code anymore:

To be fair, he didn’t actually break the project. He just didn’t finish his work.

But with only 48 hours left, I simply couldn’t afford to find that out again - I had to reassign him.

It wasn’t personal.

What have I learnt?

Communicating is important

I had made a base NPC system that was both efficient and highly extensible. But the other programmer implemented a base NPC system of his own.

Basically it was because I failed to communicate, which added extra work - he implemented the base system again, and the others will have to deal with compatibility issues as there were two NPC systems.

Also, If I had communicated more with the programmer who made the original building system, I might have a chance to avoid The Collapse.

Or, at least I can catch the problem earlier and make it less catastrophic.

AI doesn’t write code, people do.

In The Collapse, AI wasn’t the problem. Using it without reviewing its output - that’s the problem.

I used AI extensively when rebuilding the system - I couldn’t have written something that size in one day otherwise. But I read every line it generated, and understood every function before accepting the generated code.

AI is just a tool, it always depends on the one using it.

I have more to say about this in The Pilot And The Copilot

This article is not yet finished.

Architecture is productivity

In a sprint project like this, you would want as few reworks as possible.

The EventBus meant that people could work in parallel without stepping on each other.

The Git policy meant merges didn’t become a total chaos.

The designer’s detailed document meant nobody had to guess what “done” looked like.

None of them were expensive to set up. All of them paid for themselves.

Side notes

I didn’t design the EventBus system. I got it from Github but then modified it a bit, added two functions that weren’t previously available in the original code : priority queues and cancellation.
The game needed a loading screen. And I made a simple dissolve shader with unity shader graph

Just for fun, I like Computer Graphics.

And it looked cool too.