Post Mortem: Toolin’ Around, Doom
Introduction
As part of our practice to make user friendly tooling at SAE Qantm, we were required us to make a fully modifiable version of doom. Which has got to be one of the better projects to work on (any excuse to play doom and I’m there). This project was a group project
The requirements were to recreated doom entirely but in unity, considering User stories (i.e. Things that users of different professions and backgrounds would want to do with or to the tooling)
Some examples of this includes:
- As an AI Developer, I want to be able to make the game run at an accelerated rate so I can more quickly test my AIs for effectiveness.
- As a Game Modder, I want to be able to change all damage outputs
Our main goal apart from making the base version of doom was trying to accommodate as many of these as possible.
What went right
1. Scheduling and task assigning
We were given five weeks to get this done, which sounds longer than it actually is, however from day one we were on the ball, organizing scrum method and channels to communicate on. Tasks were assigned on a weekly basis and split between us. These were followed up by weekly meetings to confirm and assign new work.
2. Learning new skills
Speaking from my personal experience with this project (I’m not so sure about Dan), this was an opportunity to brush up on patterns and learn new skills. This included;
· The use of Scriptable Objects, both for containing data out of runtime and ease of use for interfacing.
· Improving coding patterns, Using the case, commenting and summarizing code
· Using Events.
3. User Testing
Through hosting successful player testing, we were able to see how are tools were being used and more importantly interfacing issues that they had. Spoiler alert, there was a few issues.. however, players managed to turn our errors into fun.
If you have never rode a tornado of enemies while traversing doom, you’re doing it wrong.
The way we worked
As mentioned previously, this was a group project, however we really didn’t really treat it that way. We would meet twice and week and would rarely message each other outside of that time. Just focusing on our assigned tasks and then showcasing when we would meet up again.
This proved to be problematic
What went wrong
1. Communication
Even though we did have regular meetings weekly, this wasn’t enough to be effect in the timeframe we were given for the project. Sometimes going as long as not talking to each other for three days. This caused issues both with the speed and which things were completed and ultimately the collaboration between our separate systems.
2. Combining designs
Considering our systems were split and created in their own sections, we had many issues trying to get things working together, normally hacking them together in the times we were meeting. This cut into our design time and generally left us with a lot of unresolved issues.
What to do in the future
1. Communication
Even though we did set up channels to talk to each other, in future using those channels more effectively by working together on technical design, assigning of tasks and completion of tasks in beneficial to the project.
2. Technical design
By working together and creating shared documentation and diagrams, by having a greater understanding of each other designs, issues can be spotted before they are in production and then addressed.
Having some sort of waterfall method or at least a version similar to that would prevent design and game logic from being changed at a later date. Minimizing the issues related to poor or conflicting design.
Conclusion
Overall, I had mix feelings about the project, the outcome of it was kind of disappointing. But if I reflect on what the experience taught me instead then it was quite successful. I learned new systems and new skills as both a developer and programmer.
Development stats
· Developer: Ben Walker, Dan Ackroyd
· Length of development: 5 weeks
· Number of developers: 2
· Development tools: Photoshop, Magicavoxel, Visual studio, Unity
