UFO Cleanup was made in 48 hours for the Civis Game Jam 2024 by a team of 4 people, two artists and two programmers.

In TTRPGs  (like Dungeons and Dragons) is common knowledge before starting a campaign or any kind of play, to make a session 0. This is a structured session in which the group talks about what are they going to play, what are the expectation from the campaign and from the players, the tone, the do's and don't s, the red lines... any information to ensure the cohesion of the game and the comfort of the players. We didn't do anything like that for this project.

We mention we didn't want to try-hard, some people said they didn't want to make anything too narrative, one member said he wanted to make a multiplayer, and a couple post-it notes more. But those were comments that came up while we were thinking for an idea for the game. What we needed was a session 0, a structured discussion to ensure we were all in the same page, what kind of game we wanted to make. That would have, for instance, narrowed the space of possibilities when searching for ideas, and channel the later stages for discussing the game design. We were all throwing ideas, none of them sounding good enough, waiting for the million dollar idea to appear before us. All this led to having to make a somewhat forced decision for picking the game's idea, because we needed something to work the next day.

The bad

The main problem in this jam was the lack of structured processes, iteration, and specially validation.

Structure

If we take the cascade model as a reference, we jumped from one step to another, without real order, and without conscience of what stage of the process we were in any given moment. At some point we started talking about possible endings, bosses, enemy tipes, etc, without even knowing what structure would have the game. The art responsibles worked at a different speed that the programming ones, which result in investing time in assets that didn't made it to the final game.

Iteration

We didn't develop an MVP on which to iterate. We described some tasks which were realized monolithically and incrementally. We had luck that the Sunday every piece came together fine. In programming for example, we did not start with the basic enemy until every final player functionality were implemented. In art, every animation released in its final version first.

Verification

As a direct consequence of not working in increments, I didn't feel like we really validated anything, as we did not make any substantial correction or change to the main ideas. As I said, everything came to be on the Sunday, and we had to work with that to build the level.

The good

The first day we made a good list of priorities that, even if approached monolithically, gave us some wiggle room to play with how we restructured and closed the game.

The code was made in its majority with mob programming, which was very productive. The code was clean, structured, and understood by both programmers. The last day we split up and started doing dirtier code, but it was a choice for working faster and knowing that the code will not be visited again.

I only have good words for the art team, who were very effective, always asked the rest for feedback, and are the major responsible for the good impression the game makes. In general, there was a very good ambience in the team, even with the fact that we were working with new people. We did not crunch at any stage, and were constantly giving and receiving feedback from each other.

Conclusions

This was my third jam, and the first time that happens that we don't get any good idea with the brainstorming. It made me comprehend better the value of the process from the very beginning, and what could I do to improve on it.