Beelonging Post Mortem
If you want to play Beelonging or find out more about it before reading this, you can do that here.If you don’t like clicking on links but still want to read and understand this Post Mortem you should know that Beelonging is a single player space shooter (shoot’em up). You control a swarm of Bees trying to save their hive from a bear attack. But different foes try to stop you on your way through the forest. There are flies, spiders, dragonflies, and hornets that weirdly keep confronting you and your swarm even though you just shot a giant number of their kind out of the skies. Eventually you will reach and save your hive or you will die trying. So, what went right? What went wrong? And what did I learn during the experience? What went right?
The ConceptOne of the biggest factors of success in my opinion was the process of choosing and the choice of the concept we worked on. The day before the group had to officially choose a concept we met (via Discord) and each presented our favourite concepts and most importantly why they were our favourites. We talked about whether we believed the mechanics of the concepts would lead to the intended aesthetic and whether we believed we could pull the concept off. We identified the most complex mechanics in terms of coding and talked about whether we liked the intended art style of the game. This way we narrowed our choice down to three concepts. We then proceeded to take a break and each re-read those three documents. After the brake we discussed the aforementioned criteria again but more in depth. Beelonging was attractive because we believed the mechanics in the document did not have to be fundamentally redesigned to lead to the intended aesthetic, the art style interested our artists and the programmers believed they could figure out how to implement the mechanics. Team CultureAnother big factor in the team’s success was the team’s culture. Since we had previously worked together on a concept of our own, the team’s members were familiar with each other already. Since the team was formed I made a constant effort in creating and fostering a team culture where problems are discussed openly, and everyone is happy to share their doubts about the project with the team. Team members reason “why?” when expressing their opinions and everyone knows that there is no malicious intent behind the criticism one might receive from a team member. Establishing this culture wasn’t easy but I had roughly three months to do so while we were still designing our concept and before we were starting to produce our first game. By the time we were starting with Beelonging the team was on a good way. The team’s members did not only work well together, they pushed each other, motivated each other, taught each other new skills and were sincerely interested in each other and each other’s ideas. AgileHaving an agile mindset and working in an agile work flow was something I introduced early to the group. At the outset of the project none of us had ever produced a digital game with a team of people like we were about to do, therefore no one had a real clue when it came to the question “But how do you do that?”. Having a mindset of trying something out for one sprint (we worked according to the SCRUM framework), then evaluating how it worked and then (if needed) changing the approach helped the team in developing a work flow and production pipeline that was tailored to the wants and needs of the individual team members. What went wrong?
I must preface this by saying I really struggle with writing about this. At the end of the day we delivered a fun, entertaining, working(!) game without hating each other afterwards (we are actually planning on working together on the next project as well). This, by no means, is me saying that everything went perfect and there isn’t anything I would do differently, but there were no risks that endangered the success of the project, just issues that made things more difficult than need be. Version ControlEven though we managed to set up a git-repository for our project within the first weeks, the limited experience we had with git was limited to team members using git as version control for projects they worked on alone. No one knew how to properly use git in a workflow with multiple developers tweaking, tinkering and implementing multiple things at the same time. And I must confess that until today we still haven’t figured out the right way to do so. This is especially frustrating to me since using git for version control in a Unity project has enough specific issues that most use cases we had questions about could not be explained away by a simple google search. I believe the education really should teach version control practices for game development (at least to the programmers so they can pass that knowledge down to their team members). Issue TrackingA lot of issues, especially towards the end of the project when mental fatigue was at it’s highest, came down to not being able to effectively track issues. Updated assets were not implemented for days and bugs were forgotten and only fixed in the very last days. This came down to us not having a standardized method for tracking those issues. Some team members used the available SCRUM-Board tool we used, others wrote messages on Slack. Not tracking all the issues in one place led to confusion and outright forgetting some of them. In the future we need to establish a common place and method for how to report and track issues. What did I learn?I learned a countless number of things during this project, but I have one thing that I want to talk about that might interest fellow producers that undertake this endeavour in the future. The importance of the sociological aspect of a team and a project. It is not the technical issues that will lead your project to fail, it will be the sociological ones. Establishing and fostering a healthy, supportive and productive team culture, mediating conflicts and working together with team members to establish processes and methods that support their way of working should be the priority. If your team can openly address issues within it, it will do so and solve those issues. You should worry more about keeping the morale and motivation of your team high than worrying about the problems your game still faces. Approaching work in the group with a positive attitude where you see the best in your team’s members will tremendously help in not getting demotivated yourself. You have a team of talented and smart people, you “just” have to keep them motivated, keep them engaged and keep them from hating each other. This is easier said than done and requires a lot of observation of your team’s behaviour in meetings and conversations. Is there someone that has it written in their face that they want to say something, but they never do? Is there hostility in the tone with which team members speak? Is there passive-aggressiveness? At the first sign of trouble you need to shut everything down and resolve these issues with your group because if you don’t the whole situation will blow up in your face when the pressure is at it’s highest and time couldn’t be more valuable. I can heartily recommend the book “Peopleware: Productive Projects and Teams” by DeMarco & Lister if the subject interests you. If you didn’t want to click the link to play the game before because you wanted to read my Post Mortem first 1. What are you thinking? Get your priorities straight, have some fun and play some games! 2. Here is the link again, enjoy! And last but certainly not least a big thanks to my team! I enjoyed working with you a lot and I hope that won’t change in the coming project  |
If you want to read their side of the story, here are their blogs: