I am very proud of the work that my team accomplished during the development of Gaze of the Abyss. However, in hindsight, the game was over scoped in regard to level design and balancing the asymmetric gameplay for a 10-week project which lead to stress, frustration and crunch. This is a breakdown of what the team did well, what went wrong, and what we learned as a team. These are the notes from a full team discussion. Please read Gaze of the Abyss Postmortem - Part 2: Personal Postmortem for my individual thoughts.
What Went Well
1. We have a final product.
We made it work with the time and resources we had.
The final game is huge.
2. We became a solid team in less than a week after the cuts.
Communication was strong.
The artists' skills complimented each other.
The designers were good at working together and bouncing ideas off of each other.
3. Mid-mortem additions worked really well.
The team gained a much needed environment artist.
4. We grew as developers.
We worked with various programmers, artists, designers, and producers for the first time.
We got to work on our own specializations and with developers with other specializations.
5. All of us learned a lot.
We really dove into Unity and gained a deeper understanding about the engine itself and what it is capable of.
We got to use a lot of small tools that we normally do not use.
6. Even though the project was bizarre at the beginning, we are happy that the singular vision blossomed and grew into a fantastic-functioning project.
7. Everyone took feedback well and provided valuable critique.
Everyone was responsible for their work.
Everyone worked hard in their respective documentation and tasks.
People were ready to pick up other people’s work as a backup (supporter).
We always had a plan B.
8. The art looked good.
The tasks were separated well based on their skills.
The communication about how to do animations was effective and helpful.
9. The meetings were beneficial.
Lots of topics were covered during each meeting.
10. First time working with two producers was a good experience.
They balanced each other skills wise and covered each others' weaknesses.
11. The team was flexible at adjusting to the schedule for the RPI Games Fest.
What Went Wrong
1. There were a lot of bugs and errors with the work pipeline.
2. There needed to be an art pipeline meeting at the beginning of development.
The artists were unfamiliar with Unity and were not taught how to use it.
3. The game was generally over-scoped.
There were too many levels planned considering the amount of work that went into the levels and the other work that designers had to do.
For the environments to be detailed and unique, there were too many props that needed to be made.
We did not have enough time to create balanced mechanics for the asymmetric gameplay.
4. Prefabs were not used enough.
Prefabs were already made for a lot of things, but instead, a lot of the interactable objects were made multiple times, making it difficult to change or fix something efficiently.
5. There were errors for proper naming and organize of stuff (imported meshes, unorganized hierarchies in some levels) which caused a lot of issues and delayed production.
6. Last minute planning and event popping up (RPI Games Fest) was stressful but out of our hands.
The last minute adding caused a lot of people a lot of stress and anxiety
The Champlain organizer of RPI had a lack of communication and knowing what we needed which left us confused and ill-informed.
We had to crunch to be ready for the Games Fest.
7. There was a difference in programming styles that was never discussed which led to inconsistencies in the code and development of mechanics.
What Did We Learn
1. There should be a programming meeting at the beginning of development to establish naming conventions, consistencies, and learn everyone's style and work flow.
2. Do not brush off issues like we did with the diver's texture.
Instead of constantly saying “that is easy and can be done in a short period of time," actually show work on it.
3. The bug log needs to be checked, updated, and discussed frequently.
Better communication can solve a lot of current issues with the game, prevent future problems, and avoid repeating work.
4. The timing of meetings in general needs to be more thought out.
Having a carefully thought out meeting plan can help to convey information immediately to the team in-person which can help avoid delays and misunderstandings.
5. The daily scrum needs to be brought to people's attention better to avoid missing it.
Maybe use a ping on Discord to get people's attention.
6. The communication platform needs to be carefully considered.
Messages on Discord can get lost quickly in large team settings and with multiple channels.
Using Champlain's Mattermost or Slack, which have threads, would be helpful and not clogs the channels.
7. Documentation needs to be "finalized" at the beginning of the project.
Documentation is necessary for on-boarding and should always be kept up to date and referenced frequently.
Documents need to be clear, easy to access, and looked at by everyone.
8. QA feedback needs to be discussed and implemented immediately to prevent from testing the same thing multiple times and to constantly improve the project.
9. Stories need to be better prioritized and assigned to a single person to complete instead of passing it off.
10. Artists need to work more directly with the engine.
The work should not be passed off to programmers or designers.
The artists need to work with their art directly in the engine more so that they always know how the game looks, how the materials and such are made, and what is lacking.
11. The build needs to be tested more on multiple different computers.
This will help stabilize the build and catch issues before QA or large events.
12. We learned new aspects of Unity and how the engine processes different aspects.
13. There needs to be more direct contact among the other disciplines.
Small interdisciplinary work groups work will help to alleviate the time constraint on large group meetings, keep everyone on the same page, and allows for unique collaboration.
