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 personal breakdown of the project--a mix of what went well, what went wrong, and what I learned. These are the notes from my personal reflection. Please read Gaze of the Abyss Postmortem - Part 1: Team Postmortem for the full team discussion.
1. On-boarding definitely could have been a lot smoother.
While I joined the team, it took everyone a full week to understand the game and the artists had no clue how to use Unity even at the end of the project.
The documentation that was provided to us was an out of date design document that did not provide a clear vision for the game, only talked about what was implemented.
Getting a clear pipeline helps to avoid a lot of issues in the future too and keeps most repo issues from happening.
2. Every time something went wrong, other people tried to find someone to blame.
It is important to take responsibility for your mistakes, but it doesn’t necessarily make it your fault. If an issue is there, oh well, move on and fix it.
As a team, we don’t need to find blame, but instead join together and work to fix any issues.
3. Meeting timing definitely needs to be better.
Class/sprints began on Mondays, wed have a team meeting that night for tasks and such, and then the design meeting the next day where sometimes things pertaining to stories would be changed. While this wasn’t fully in our control, there could have been ways to work around it better.
4. There needs to be more work sessions.
As a team we would have 2 in-person meetings a week. The Saturday meeting was supposed to be a work session, but turned into a full on meeting every time. Which turned into a lot of repetitive discussions for the next in-person meeting.
I met with Grace once a week and we were able to ask each other questions and get a good answer/explanation immediately. Helped us both tremendously.
Work session help keep people accountable and the game on track.
5. Everyone needs to read the stand-ups.
It’s important to keep up to date on what your team is working on, even if you don’t necessarily have a hand in what they are doing because it may affect you eventually.
Also, keep the stand up contained to what you are doing related to the project. While it is important to let your team know what else is going on as far as class work or personal issues, keeping it related to the project keeps the stand-up streamlined, easy to read, and keeps you accountable for your tasks.
6. Finish the tasks you assigned yourself.
It comes with scope and learning your own abilities, but try to finish all of the tasks you committed yourself to.
It keeps the game on track, prevents you from holding anyone else up, and gets it in the game right away to be tested.
7. Implement QA feedback immediately.
The first tasks accomplished after QA should be implementing the feedback. Otherwise the same issues will keep taking center focus and you won’t be able to effectively test everything you want to without the solid base.
8. Keep documentation up-to-date.
I always took notes in the design meetings that we had and made sure to write down major changes in the meeting summaries channel we had in our team’s discord, mentioning people that it would directly affect. This system worked, but a much better thing to do would just be to keep the documentation up-to-date.
Current documentation is like a one-stop shop. Is a place everyone can go and get the answers they need immediately.
I also think that the official documentation should have its own folder instead of being hidden away in each discipline’s folder--keeps it easy to find.
9. Have more to-the-team presentations.
The team should always see your work, even as you are working on it. By presenting it to the team, we can give immediate feedback to prevent people from having to redo things.
Plus it keeps people up-to-date on the status of the project, helps keep the vision coherent, and keeps you accountable for your work.
10. Be open with the team about when you are stressed but don’t complain about it all the time.
You have a lot of work--I get it, we all do. That’s not to discredit any one, especially if they are having a particularly bad day/week/whatever, but don’t spend every conversation I have with you talking about how tired you are and how you stayed up all night working.
11. STAYING UP ALL NIGHT IS NOT WORTH IT.
This is the first year of college (yes full year!!) that I did not pull an all nighter. After a particularly rough spring semester sophomore year, I decided to call it quits with all nighters. While i still occasionally came close, I will never go back to pulling all nighters.
You burn out faster, can’t focus, become more emotionally unstable and irritable--IT'S NOT WORTH IT.
GO TO BED--that is the only way you’ll stay excited about the project and working with the team.
12. Always have a plan b.
Designs should be flexible. If something doesn’t work out when you play the game, or you run out of time to implement something how you designed, be prepared to work around it.
It will require creativity and quick decision making, but will be good for the game in the long run.
13. Keep an up-to-date bug log that everyone can contribute to, not just programmers.
