Blog #6: Postmortem
|
Hello and welcome to my final blog post concerning the development of our game, “Umibōzu”! I am Léo and the Scrum Master of Team Wendigo. In today’s post, I will talk about the final result of our game. First, I want to provide you with some context of our project and provide some insight to our development processes. About nine weeks ago, we sat in the lecture hall and attended the first lecture of our new course. The course Game Design 2: Game Development was our first big project and our first digital game in the program. Each team was tasked with choosing one of the other teams’ “Shoot ‘em Up” concept documents which we designed last semester. Team Wendigo chose the concept document “Umibōzu”, designed by Team Gnoll. “Umibōzu” is about a Japanese fisherman who sets out on a perilous journey in search for the legendary mythical entity, Umibōzu. After having chosen the document, we held a meeting where we discussed how we interpreted the concept and what we wanted to change. Generally, we stayed pretty close to the original document, only making slight modifications and cutting features. In this pre-developmental stage or pre-project phase, we also laid down the foundations for the project. We devised a group contract and established our means of communication and work flow. We also discussed the team needs, goals, and expectations. The team agreed that this project was not about burning ourselves out and making the best Umibōzu but rather to learn how the various disciplines (project management, programming, art, sound, and design) work collaboratively. With this as our team goal, everyone felt at ease entering the production phase. Working with the Scrum framework was a first for all of us and proved to be a challenge. Nevertheless, the team quickly got the hang of the daily stand up, sprint plan, review, and retrospective meetings and became effective at carrying these out. A predictable issue that came up in the production phase was overscoping. In Scrum, the product backlog contains and breaks down all features one wants implemented in the software being developed (in this case, the game). As a team, we produced this document together at the beginning of the project. Since nobody knew each other’s or even their own skills, it was very difficult to estimate how much we would actually manage to produce and implement. For example, the artists, who had never done animation before, could not properly gauge how much time it would take them to make the “shark movement” asset. This resulted in us having to shorten the backlog and cut a lot of features. As arbitrary as the practice of estimating time taken for producing an asset was at first, I believe it is critical for game development. Having a good idea about how long it will take to make an asset is extremely valuable to attain an effective workflow within the team. Overall, everybody in my team can agree that this project was a tremendous learning experience. Despite having to cut a lot of features, the final version of our game was complete and playable. I do however believe that we should have respected the proposed feature freeze. Since we had cut so many features, it was difficult for the team to halt features completely two weeks before the gold version. I think it would have been better to accept the reality of the state of our game and instead focus only on polishing. At the final playtest session, those games that were polished really stood out to me. Games that had many features but weren’t polished just felt overwhelming and at times confusing. I have really started to embrace the “fail often, fail fast” mantra in this course. There is so much to learn and at first glance, it becomes overwhelming. Diving head first into this unknown ocean of knowledge and realizing every failure is a step to success will slowly, yet steadily bring you to your goal. You can play the final version of our “Umibiōzu” here: Thank you for reading my post! Peace out. ∼ thedudeleo  |