Techinical Game Designer

Blog

Space Berserkrs Postmortem Analysis

Space Berserkrs is a 3D action adventure game mixed with turret shooting sequences and the melee combat sequences, we were trying to recreate a enhanced Disney ride experience for the players. Players will progress the game by following a boat moving along the trail, when they arrive at certain spot in the level, players can jump off the boat to explore and fight the enemies. This game was created as the final project for the Vancouver Film School game design program, it asks a group of students to create and make a game during 12 weeks. A five man team is behind the Space Berserkrs, all from the same class. The goal of the project is let all of us have a chance to experience the whole cycle of the video game production, where we can showcase all the skill we have learned at VFS. At the end of production we did really a good job, we designed a big game considering the time constraint we have, and the whole team worked really hard in order delivered a well executed game with high quality 3D arts and fluent gameplay.


What we did well

1. Really healthy and productive brainstorming sessions

We divided the brainstorming session into three small ones so that everybody has a fresh mind during the sessions. Quick internet search, doodling or mock-ups really help us to visualize the ideas. After the meeting, a structured summary helped us to memorize all the ideas and helped us to compared between them. Another thing we did really well is, after we get enough informations or it took too long to figure out certain elements of one idea, we just stop and move on, it really prevent us stuck on certain ideas for too long.

2.  Get feedback earlier, but filter them with your designer pillar.

Be open and comfortable to show the game and get feedbacks in the early stage of the production really helped us. At early stage lot of things in the game is not set in stone, fresh eye test and feedback really help us to prioritized the elements in the game and adjust the project plan, it stop us to spend a lot of production time on something have lower priority. When the feedbacks come in, not every single one is useful and valid for our project, filter them with our games design pillars to find out the real useful ones.

3.  Let the whole team play as the producer in the team, make sure everybody on the same page for all the design CHANGES.

We did a really good job to let the whole maintain the vision and design of the game throughout the production. Regular meeting and random group discussions keep the design in each teammates up to date. Some quick prototype, AB testing let us have a clear idea about the coming changes in the game. As a result I am confident to let everybody do their jobs, I can even split the team to focus on different things and not worry about if the outcome is not a fit for the game. This really helped me to reassign the resources as the production needed.


What we did wrong

 1. Learn the tools you want to use before you implement them in the game, make sure the people who work with you know the tools.

Using Wwise is kind of the biggest mistake for the whole production. Wwise is really a powerful tool for creating and managing audio assets for the game, its sound a bank is kind independent to the project's source code, so the sound collaborators can work remotely. This required a healthy and productive working process between the production team and the sound designers, which in out case is not, all the sound collaborators are hard to reach, they are late on update their progress, as a result we are always late on audio part in our game. As one of our instructor mention if the problem happen, someone in the team need to take the responsibility to make things work. So one of our teammate started to looking for temporary sound assets and I spent a lot more time on Wwise than i suppose to. It let me simplify and delegate some of our QA tasks to others. During this time we also found out that Wwise has some limitations on different platforms, it does not work well with Unity Version control. At the end it turns out good, the assets are catching up at the end of the production, and I have made most of the sound treatment and implementation for Space Berserkrs. And we have to be really caution when we do the Wwise update in version control, it like everybody should be there and test if there project is not compromised.

2. One big scene in the Unity

According to the level design of our game, we only need one big level in the Unity, but since unity doesn't support multiple user editing the same scene, this decision actually created a lot problem during production. One thing is we have to constantly tell ourselves who has the latest version of the game. For the most of the time level designer has the latest version of the scene, but when other people try to integrate new feature in the game and is cause bugs in the main scene, level designers flow has been break until people fix it, it really causing the late on our level creation. Space Berserkrs is linear game, at certain point when we didn't really implement the checkpoint system and any optimization, testing the game become really inconvenient. What we do is after we locked down the general structure of the game, we copied the main scene one for level designer tweaking the level, one is for artist to decorate, and one is for testing. I have to make sure the level designer and the artist art not working one the same section in the game.And artist put all the new decoration object under one game object, so that we can copy it between the scene. After a major change, we delete the old copies and redo the process.

3. QA and the playtest
I don't think we did the best job of the QA for Space Berserkrs, especially when it close to the end of the production, when we are busy fixing the bugs. What we do in terms of QA is make a build, the whole team plays the game, each person focusing on what they responsible, but note down all the bugs when find, collect them together, fix it and test the new build again. Most of the bugs are noted on paper, thought we tried to use pivotal and fogbugz to help, it really late to add new tool into our work flow at this very stage. Plus the Pivotal can't prioritize the bugs, and Fogbugz only allow 2 free users to access the project, as result we couldn't have a very systematic QA process for Spacer Berserkrs, it leads to a lot overtime and a lot repeating works. As PM should force the work flow for QA and bug fixing earlier in the production, and come up with a clearer and better QA plan would be really helpful next time

Space Berserkrs is a student project where we can showcase the skills we have learnt at Vancouver Film School and experience the video game production for real. All the challenges we had during production are a learning experience, all the best practices we had like the effective brainstorming, and getting early feedbacks will save us a lot time and resources in my future project. As a project manager, the thing we didn't well become a good reference, and i will be prepared when i saw them again.