This DevBlog is mainly about our management model for "Bite Me, Boss". In short, we just wanted to do game jams, have fun developing, and bring these game jams together in a small, Mario Party-like game collection.

What did our model look like in theory?

Our plan was to create a cycle of game jams and polish phases. We planned three days for a game jam, one week for polishing and one additional week for the so-called “engine update”. This means that the week after the polish, we would spend a week adding scripts and functions to the project to make future work easier. We tried to build a framework that would make work easier for future game jams.

After all this work, we would take a week off, and with the start of the next month, we could begin a new game jam. In between, there would be planning, review, and retrospective meetings to stay up to date.

This monthly restart makes the whole concept very dynamic and allows for major adjustments at least once a month. Not only to the framework but also to the team. On one hand, we could invite new people to join a game without them having to commit to the project for too long. On the other hand, roles within the team could also change. Our planned main roles for each game were: Audio, Art, Code, Game Design, and Vision Keeper. These roles were mainly there to ensure that at least one person was responsible for each area and made sure their area was not forgotten. We called these roles Badges, and they could be reassigned at any phase of the game.

In the end, we also created a "Metagame". This gave us guidelines for the game jams. In short, it was just a rough setting and a framework in which we made our games. This was to ensure that all games had a common theme and fit together overall.

What did we expect from it?

Mainly, we hoped for fun and variety. In our previous project "The Wuseling", we eventually got stuck, things didn’t progress much, and we had to end the project with the motto "Kill your Darlings". With this new project, we wanted to challenge ourselves differently, give ourselves the freedom to explore and create different games and mechanics.

We also wanted to build a framework and focus on the basic building blocks of games and where to start to create a generic framework tailored for game jams.

And of course, we just wanted to have more fun making games again and reconnect as a team with the relaxed game jam mentality. We also wanted to offer the possibility for others to join the team for a certain time and for us to work with new people, but without being dependent on their work.

What did it actually look like?

Well, right at the first game jam, we encountered a lot of obstacles. Somehow, we didn’t have a proper flow. We achieved very little, and polishing didn’t go any better. One by one, everyone got sick, and our schedule kept slipping. The polish ended up being the bare minimum instead of a finished product we were happy with.

But we still went ahead with the next game jam as soon as we were somewhat back on our feet. We worked more quick and dirty, as is typical for a game jam. It went better, but not as smoothly as we were used to from game jams. Despite the illnesses, we managed to get back on schedule.

After polishing the second game, we felt the consequences. Everyone was slightly burnt out, had little energy, and realized how we had sprinted through the last two months. So, we took a mandatory week off for everyone.

Then came the big decision: Are we satisfied with what we have? Do we want to do another game jam in the last two months before the deadline, or invest the time to properly polish our first two games? We decided on the polish. This extended polish went much better, with Scrum-like management we incorporated all possible feedback, improved mechanics, fixed bugs, and refined the gameplay.

What did I learn from all this?

A brief info about me: I was the team lead, coder, and manager for this project, so I will speak from this perspective.

Agile management is great, but it needs to be used well

Working agile on a project has many good aspects. Various meetings offer many opportunities to adjust the project, team dynamics, and structures, and to learn together. But it also requires a lot of open communication and not just the willingness to improve things but also the initiative and energy to do so. You also need to accept if you’ve led the project in the wrong direction and change course as soon as possible.

Studying ≠ 40-hour job

A very important thing we didn’t really consider in our model is that we are all still students. In the end, we had much less time to actually work on the project than expected and had to learn to adapt for our own health.

Game jam ≠ Polish

One problem that ran through our whole project was that while we wanted to do cool, relaxed game jams, the importance of the project for our graduation sometimes got in the way. Too often, the focus was not on fun and experimentation, but rather on the question "Can it be finished and does it have enough potential to be part of our master’s project?"