Umibōzu – Post Mortem
|
My name is Hampus Bergström and I was the game designer for team Wendigo. For our course “Game Design 2: Game Development” here at the university we were instructed to create a 2D Shoot ‘em up game in small teams while working within the Scrum workflow. We had to choose a game concept that other students had come up with during our last course, we chose the game concept of Umibōzu. Umibōzu is a game set 18th century Japan were the game controls a boat and tries to navigate the seas without getting killed by dangerous sea creatures.
As the designer on my team I was a little more familiar with Scrum and agile than the rest of the team because what I had learnt in my minor courses. This was not a major issue, but it took a couple of weeks for us to really get a good workflow and for everyone in the team to understand everything about Scrum and especially user stories. But after those first weeks, communication has been great within the team and I believe that this was the most important part during our development. Rarely were there any misunderstandings within the team and everyone was always on the same page when it came to design and what everyone was doing. We managed to create a relative bug-free and working game and that still managed to keep the aesthetic of mystery as was stated in the concept document. The game was however far from a perfect game and the two biggest flaws with the game were my responsibility within the team.
The first flaw was the level design of the 2 first levels (there is 4 levels in total), as our game used a system to randomly spawn enemies and obstacles the first 2 levels that just had 1 enemy and one obstacle (in the second level) felt very slow and rather boring to play. This is something I struggle with a lot during development, I could not just add the enemies and obstacles from later levels as then all levels would feel the same. A solution to this could have been not to have the enemies and obstacles randomly spawn during at least the first levels and manually place them. Also, this problem could have been noticed earlier with more external playtesting and prototyping I believe. The Second big flaw of the game was that there was a dominant strategy that I didn’t know was there until the final build. A dominant strategy that completely ruined the whole game for the player if the discovered it, as it completely went against the aesthetic of mystery and discovery. Luckily, not many people discovered this dominant strategy but just one is one to much. This could have been solved by conducting more external testing and when testing internally really focus on trying to “break the game”. This course and project has taught me a lot as a designer and how to work with people from other disciples to create digital games. It might not have been the greatest game with the best design, but it was a great learning experience for me. I now have a better understanding of writing design documentation and getting my design ideas from the paper to the screen. Also, I now have a better understanding of the limitations of both the technology, time and team members skill level and what effects that can have on the project.  |
