Devlog #5 Reviews at Flamebait

Hello to anyone reading this, my name’s Viktor and I’m the producer and audio-person at Flamebait. Today I’m going to tell you about how we review our own work during development. To explain how we review our work, I feel like I first have to explain how we plan our work.

Planning our work

During our years of working together, we have tried out a whole bunch of different ways of planning our work and defining what needs to get done. There has been a lot written and said on the topic of planning game development projects and we’ve tried to follow the recommendations of plenty of different sources but in the end, we’ve had to figure out ourselves what works best for us based on what we and others have done before.

When we had decided to develop Forge and Fight into a full game, we got started by sitting down and figuring out (based on the game vision) what we wanted the player to be able to do in the game (i.e. spin shotguns, play with friends, chat with emotes) and then we clumped those things together to figure out what major features we should be focusing on implementing (multiplayer, forging, stimuli). We prioritize those features according to what we consider to be most important to achieving our vision and then we break them down into smaller manageable and time-estimable chunks that we can get to work on.

Example of idea generation

We’ve called those smaller chunks a lot of things over the years, we’ve called them user stories, we’ve called them tasks and at this point, we just call them cards. Our team is full of creative people and they all have slight differences in how they want their work to be structured. I’ve found that when using cards, I can make sure that each team member can plan their work out in a way that works for them but that is also manageable for me, as the guy who’s trying to keep it all together.

Cards are pretty loosely defined but in general, it only needs to contain three things.

  1. A definition/name
  2. One or more assignees
  3. A deadline
  1. The definition tells the developer who is assigned to the card roughly what needs to get done. It can be as loosely defined as “Appealing Forging Environment”, or as specific as “Ragdoll body parts should float in the water”. 
  2. The assignee is the person who is responsible for making sure that the card gets reviewed and accepted before the deadline.
  3. A set date on which the work that the card defines must be done if we are to meet our development milestones.

These loose criteria make it simple for us to adapt cards to many different types of work (bugs, features, releases, research) that needs to get done while still prioritizing our work in a clear and structured way. Cards can be customized by the assignee to fit their work process using checklists, comments, labels and so on.

Example of a card

Throughout our work week, I make sure that everyone on the team knows what cards are waiting for them to get to work on. When the work defined in the card has been finished, the assignee marks it as “ready for review”.

Reviewing our work

At the end of each Thursday, we all take some time to sit down together and play the very latest internal build of the game together. After we have done so, we have a look at the list of cards that have been marked as “ready for review” and discuss them, one by one. The assignee tells the rest of the team about the work that has been done and then everyone gets a chance to share their feedback/thoughts on the results before we decide if the card is actually finished or not.

Example of a review

Defining whether a card is finished or not can be more or less complicated depending on what type of card we are discussing. Some cards, like “Ragdoll body parts should float in water” are easy to review if the person who is assigned the card says that they float if we were able to verify in the playtest that they float and if their floating didn’t cause the game to crash, it’s pretty easy to say that the work has been done. Other cards, like “Appealing Forging Environment”, can be harder to review, since they by nature have a lot of room for design, iteration and subjectivity.

I try to encourage our team members to create checklists or in some other way define subtasks in each card to not only make the work process a bit easier for themselves but also to make it easier to judge whether or not the work is finished. In the end, though, I’ve found that when I leave as much responsibility on the developer themselves to make up their own definition of done, it:

  1. Forces them to consider what the card means in ways that we couldn’t foresee during the initial planning stages.
  2. Encourages discussions with me and other team members about the card that often leads to a more unified vision and more efficient work.
  3. Makes sure that developers that feel stifled by bureaucratic planning processes aren’t choked.

In some cases, a loosely defined card might be impossible to handle, and it can lead to frustration. Then we simply have to step back, have a look at it and try to find a new definition that makes more sense, a process which also often leads to fun and creative solutions.

It may sound weird and inefficient to some, planning things work in such a way that its “doneness” can sometimes be hard to pinpoint, but that flexibility in the cards makes sure that discussion and iteration is a natural part of the process. It’s a way of working that I don’t think would fit every team, but it’s what I’ve found work best for us, probably because in such a small team communication is simple and discussions are always welcome.

Thanks for reading, I hope it was interesting! I tried to keep this quite concise so if you have questions like “why do you not do user stories anymore?” or “but scrum?” or “which brand of sticky notes is the best?” then please reach out to me (maybe in our Discord) and I’d love to discuss it further with you 🙂

Latest Posts