Postmortem of our first game

Titlescreen of our verion of Umibozu

This blog post will summarize how I felt that our development process went and what I as a game designer have learned. And what our final product looked and felt like.

The game itself featured a boat as the player-controlled avatar. With the objective to locate four different landmarks that the player had to navigate to advance the game. And to find these landmarks you must sail through portals that steadied your compass to point in the way of the next landmark in the mazelike map the game consists of. It’s also not a traditional shoot-em-up game where you as the player shoot everything on sight. But instead try to avoid the kraken’s tentacles that attack you in three different ways on your journey through the mysterious waters of a feudal Asian setting.
And since you couldn’t attack the tentacles, we gave the player the power up ability to put down a lure, so when the player where about to get overwhelmed they could put it out to make the tentacles move towards the lure instead of the player.

I felt a lot of things didn’t go as I thought, especially since everything we learned as game designers in previous courses was basically discarded. Our development process was more of an ‘waterfall’ method rather than an ‘Agile’ method.  Where we sat up an back log and let every ‘lead” go of in their way and do what they felt and thought was the next step. Instead of doing the agile method with making the game step by step to see what we needed to make the game fun, what didn’t work and what should be scrapped or put in.
So, we never had iterations of the game really. Maybe one or two at maximum. And since we never had a process were I as the designer had something to say about anything really, I felt my part was diminished and not useful. Because the art-lead decided on everything that had with graphics, the coder chose what to implement and when. So, my job as the game designer to bring the group together and making the game together with meetings and discussions about user stories and choosing backlog elements that related to the user stories was not implemented. My job was then to be QA for the other roles and level designer.

I also learned that sitting together in the same physical space creates a way better pipeline and development process. You can directly show when something feels of or wrong on your screen to another person, you can play sound files for them to share opinions on and so on. Making the process of waiting for responses or for another team member to download and try out what the bug/glitch was. The process becomes much quicker, you also get a lot more done because there are less distractions in that kind of environment.

Our final product missed the deadline, both the programmer and graphic artist wanted to change a lot the last couple of hours before the deadline. So when things should already be wrapped up and done, new bugs was found that was game breaking. Causing us to play with the fire until the very last minute, which in the end burned us hard. This could be avoided easily with better planning and not letting anything be done at the last possible time. It was already to late to do these things.

I have also learned to care more about the product myself. To stand up to things that will not work and that will screw us over in the long run. I need to voice my opinions lauder and not hoping everyone will do their part and what’s asked of them. That I should work closer with everyone on the team and ask them if they need help or if we should redesign something that is confusing.

So in the end I have mostly learned what not to do, but that is equally good as to learn things I should do.

About Tim Wergeni Johansson

2017 Game Design

View all posts by Tim Wergeni Johansson →