Post mortem: Team Bugbear Umibozu

My previous posts have been detailing the design and production process of a game me and a couple of fellow students have been producing for a course in game design. Now the project is over and it is time to reflect on the experience.

In the end I think most of me group are feeling a bit disappointed with the end result. We ended up having to cut a bunch of features due to time pressure, whilst also having to hastily add features as the deadline got closer and closer. What we ended up with was a game with the the basic components we set out to add, but without much else. Features like a second enemy type, a boss fight, or a story told by the level design, were things we wanted to add but didn’t have time to.

Screenshot of the start of our game

Most of the problems we had could be attributed to inexperience. Starting out we had a concept document which was written by someone else. Instead of sitting down and creating our own more detailed version of that document we went into production quickly using the already made concept document. This meant that we had to make up design decisions on the spot, and when we didn’t write these decisions down it created confusion later when two different people said that it was supposed to work in two different ways. This would’ve been solved by having a master document where all the design decisions were documented, instead of wasting time arguing about what we decided last week.

We also had a hard time adapting to feedback we got during or playtesting sessions. I talked a out in my previous blog post if you want to read about it, but to sum it up: The testers didn’t understand how to play the game, and instead of making changes to address that, we assumed that it would all make sense to them when we fleshed out the game a bit more and improved the tutorial. This lead to the game stagnating due to the basic mechanics and gameplay being flawed. If we addressed it earlier we would have been able make our game play better and more intuitively.

These problems, combined with a lack of time due to all of us having other lectures and assignments, meant that in the end we only managed to build a game with a the basic components. The goal is to go from point A to B without getting sunk by sharks attacking you, if they reach you they slam into your boat and deal damage to you. The sharks are covered in a cloud of mist. There are also items that are covered in the same clouds as the sharks. To tell them apart you have to the spotlight attached to your boat to shine a light on the cloud, revealing what is hiding inside.

As for what I’ve learned personally this project has been pretty beneficial. The things mentioned above are great to have experienced because now I know how important proper planning and listening to your testers are. This project also gave me the opportunity to put some things I’ve learned into practice, the biggest has been animation. This is my first time creating a high quality sprite animation for a game and I’m very happy with how my process worked, and the resulting animation. I’ve talked about animation for the enemy shark in previous blog posts if you’re looking for the process.

The finished animation of the enemy shark.

With this project being over, that is all for now, Esbjörn out!