Game Design Documentation:
This document demonstrates my ability to communicate abstract, creative concepts. I took inspiration from Monaco and DOOM’s design docs, and credit Tvzi Freeman’s comprehensive Creating A Great Design Document. Accessibility, clarity, and readability was a priority. This was a living document, being updated as the project changed. With each version, I printed out individual copies for the entire team and pinned it in the development Slack. On a more experienced team I would have left more of the details up to the developers to fine-tune, but as they were all first-timers it was best to have my team focus instead on learning Unity as well as developing team-based skills such as code comments and good Github practices.  

Project Management Lessons:
Lesson: How to lead a project meant to grow a team rather than deliver a product.
This was my first experience with structuring a project around promoting long term practices rather than creating a final deliverable and it taught me a lot. Upon being hired, I interviewed my superiors to determine this project’s success criteria. Due to limiting school policy associated with recruiting members from other student organizations, the game itself could only be for promotional purposes and therefore I learned how to use the project as an opportunity to train an inexperienced team in the technology and processes used for a more comprehensive project. I assigned training exercises as I would typically deliverables, paired more experienced members with less experienced ones, and included them in the game design process to teach rudimentary game theory.
Lesson: How to cooperate with a business subunit.
I have never had any executive oversight on my creativity. Answering to a business subunit was something that I had never done before, but after some teachable moments it proved very rewarding. When the alpha deadline rolled around, I was surprised to find them upset despite us being on schedule. Where I saw a game with all of its core back-end systems in place, they only saw a front end experience riddled with programmer art. This taught me how important it is to convey your own domain specific knowledge in order to have effective communication between different professional backgrounds. Moreover, a week to beta I got a list of features they requested I implement. This led me to realize I needed to include them in the creative process so that they didn’t feel blindsided, and in return, I didn’t have uninformed requirements forced onto the project.
Back to Top