Blog #6 – Postmortem of our first digital game: Aetherial

What We Made

Archon, the group I was a part of for the past 6 months, recently wrapped up our production of a small 2D side-scrolling shooter game. This game was based on a design produced bu another team during the previous semester. The game was produced as part of the course Game Design 2: Game Production here at Uppsala University, Campus Gotland and the production of our game has been this semester’s most extensive assignment. The game was delivered on time and now the time has come to look back on the project and identify what lessons we learned and what to continue or avoid in our future gamedev adventures.

The Good

I feel that it is as important to note what has gone well in a project as it is to revisit what mistakes where done. The positives of a project indicates best-practices found and often proves as valuable a resource as a list compiling all errors in a project. For me it also serves as a good exercise in identifying positive actions, keeping my morale high for upcoming projects.

Workflow decisions that actually improved our workflow

Early on I had the good fortune of getting in touch with second- and third year students to chat about good practices for the first year courses and how to successfully run a project. The first thing they all told me was to work in the same location, as often as humanly possible. So naturally, we did not do that. Instead we started out the project more in line with how many of the team members were used to:

1. Get assigned a task.
2. Work on task until completion.
3. Keep communication to a minimum in between item 1 and 2.

Cue a lot of work not being done in time, being done without other’s input and feedback, and being put on hold because of dependencies on other tasks that ran into aforementioned issues. This naturally did not work out very well. In the final weeks of the project however, the team turned this practice around and we begun working in the same location. The shift in productivity was quickly noticeable. We had less miscommunications and the team grew closer through the constant conversations had during group work sessions.

Lesson learned: Like the good-willing students before me, I cannot stress the importance of working as a team, together and in a way where communication can occur spontaneously and often between all team members. In a sense I am glad that I got to see the detrimental effects of not following this advice tight of the bat, but the bottom-line price of this mistake was quite high indeed.

Second-half of team communication

Similarly to the above mentioned point of workflow, our initial communication was found lacking and miscommunications were often occurring. As the project moved on, communication improved greatly, mostly thanks to the decision to work together in the same physical space. We also addressed the lack of communication in the team’s Slack channel, and soon the posts made by members started to get comments and feedback reliably. I also felt that the group grew closer and less formal by the end of the project, with a more relaxed environment growing around us during the final weeks.

Additionally, I felt that my feedback to the team’s artists was lacking in the beginning of the project. By using non-violent communication (NVC) and applying a lot of the lessons from this (Maximizing Artistic Critique: Improving Communication for Everyone Involved in Critical Feedback) great GDC talk by Jeff Hessner, I felt that I could communicate my feedback reliably without stepping on the toes of the team’s hard-working artists.

Lesson learned: Again, work together as often as possible. Motivating why communication matters is also an important factor to improving communication.
Bonus lesson: Using tools to communicate is not only good if you are aspiring to become a sleazy pick-up artist, it can actually help you in your professional life as well.

 

The Bad

(Not?) Working in Scrum

When the project started it was communicated to us that we would be using the Scrum methodology throughout the project. There was however, one small (BIG) issue that made itself apparent from day one. I as a project manager student and recently crowned producer had zero hand-on experience with Scrum, along with a near zero-level amount of knowledge about Scrum. Cue a frantic initial weeks where I scrambled through available resources and tried my best to apply new knowledge on the fly. The end result was sub optimal and looking back, I can see that we never succeeded to implement Scrum as it was intended.

The use of User Stories was also limited, partly due to the low quality of the user stories handed down to us from the team that produced the game’s concept. We as a team failed to re-imagine these user stories in a good way and never successfully implemented them into our workflow and sprint planning session. The team’s Lead Designer and I thus failed in our work to ensure a proper workflow and implement the Scrum methodology.

As a final side note on this; the sprint reviews, sprint planning sessions, and daily stand-ups were well liked by the team and helped us become more productive.

Lesson learned: As the team’s producer and de facto Scrum master this was a big personal failure as I see it. In order to avoid this issue in future I have made it my goal to research whatever work method we will be using beforehand so that I am ready to guide and coach my fellow team members in the area. It is also important to make sure all team members understand how and why we are working in a specified method.        

Lack of documentation

Looking back on the project, we have almost no written documentation of design decisions, meeting protocols, or mood boards available. Much of the design work was done orally without any person taking notes of what was decided upon. This worked during development, as humans are gifted with a type of short term memory, but in a few years time I will surely become saddened that back tracking details of our work will become nigh impossible.

Lesson learned: Document appropriately fitting your purposes, but do document decisions regularly for future reference. Keep the documentation relevant, meaning that recordings of meetings are not usually necessary, but decisions taken during meetings should be noted down and stored in a way that it is easily accessible and readable by all team members at any time.

First half of team communication

For the first half of the project the team’s communication was poor, neighboring on abysmal. Messages posted in our Slack channel rarely received any feedback and the writer was often left wondering if anyone saw what they wrote at all. We also suffered from some interpersonal conflicts that had arisen during the previous semester. These conflicts were not dealt with and thus continued to decline during the course of the project. This is a situation where I as the producer/Scrum master of the team should have stepped in sooner and facilitated meetings or other actions to directly adress the issues at hand. I never did, and so the situation was never improved.

We were also working very individually at this time, decreasing the amount of spontaneous communication happening between team members. We usually worked from home, only meeting up for the daily stand-up meeting required by the Scrum methodology. As game development is a process that relies heavily on different people working in unison on assets and features, the lack of communication cost us greatly. Most noticeably in miscommunication about design decisions and art direction.

Lesson learned: As a producer/Scrum master you should always try to deal with interpersonal relationship conflicts as soon as they are noticed. Inaction leads to decline, and a third party can prevent the situation from turning sour, beyond salvation.
AGAIN, working together and sharing physical space can effectively combat a lack of communication and should therefore always be a priority to set up for any project manager or similar role.

End Result

As the project came to an end, the team struggled to complete a functional build of our game. We had not adhered to the recommended feature freeze, instead focusing on finishing planned throughout the final week. Big features were implemented the day of the final presentation that broke the build of the game. As a result the team was late to the presentation and had an untested build to show. The lack of dedicated time to polish and balance the game revealed that the Aetherial’s levels were much too difficult to new Players. Most Players were not be able to finish the game until they discovered the dominant strategy of using a rocket launcher ability that could be used indefinitely throughout the game without any drawbacks. Dominant strategies are widely regarded as being very detrimental to a game as it forces Players to use the most powerful strategy and not necessarily the most enjoyable one. This mistake in design was especially devastating to the end product.

More internal testing would have revealed this issue, and the level could then have been balanced more appropriately for a new Player’s experience. Another flaw to the end product was that the Leviathan boss character’s animation was never added to the game due to the team’s programmers being otherwise occupied with attempting to solve a number of game-breaking bugs. This was coupled with an art pipeline that relied on a programmer to implement animations into the game. So even though the art asset was created, it never entered the build as the artist was unable to add the animation to the game single-handed.

To summarize, the end product was very flawed and lacked basic balance regarding difficulty. Not being able to show artwork that had been worked on for many hours was another setback, especially for the artist that created the asset.

Lessons learned: 

The main takeaway for me is to ensure that the team has time to polish a game for a minimum of two weeks (in a 10-week project) or roughly 20%-30% of the project’s lifetime. In this stage it would seem that most quality is added. Things like minor Player feedback additions, game balance, bug hunting, and level design tweaks can be done during this period. To clear this period however, a line has to be drawn where no new features are worked on. Instead pivoting the entire production and team to polish what exists in the game. Ensuring that the game early on fills the so-called MVP (Minimum Viable Product) requirements is essential to allow the team to cut planned features as the feature freeze closes in. The polish stage is seemingly a period of the project life cycle that is easy to down-prioritize, until you see the destructive effects of doing so.

I blame myself a lot for not adhering the feature freeze and allowing myself and the team to work on features until the very end of the project. I also underestimated the value of regular internal playtesting session as many of the flaws in our game should have been detectable by the team, should we have found the time to do it more often.

Conclusion

Working on this project has made me learn a heap of lessons on what to avoid the hard way. I have also seen the blossoming results of what happens when good decisions are made and will bring that with me as well. While our game might not be the best game we will produce during our time here in Gotland, it is the first time we bloodied our teeth together on digital game development and it will therefore always have a special importance to me.

Finally, with no further ado, I want to thank the members of Archon for taking part in this with me.

Thank you, Marcus.
Thank you, Chris.
Thank you, David.
Thank you, Petrut.
Thank you, Oskar.

I wish you all the very best in your upcoming adventures.

/Anton Berglund