Project Management for Game Development
Project Managing
Guides
Our CMS continued to grow and grow. Often times with features that were important, but only needed using a handful of times.
In most cases, the CMS had descriptions and self-explanatory field names that would guide Jenn's work. And then there were a few that needed a bit more explaining. I realized we needed Documentation.
I wrote a handful of guides with images and gifs to serve as reference for those less used features. I would write them out as I finished a feature, then hop on a call with Jenn to talk walk down the guide. I would screen share my own computer working through an example so there was a clear picture of how it worked in Sanity, and how it would end up looking in our main application.
Communicating Trade Offs and Keeping an Eye on the Big Picture
Towards the end of the project, feature creep continued. We had to continue discussing what an end product looked like.
At the start of the project, I was here to serve. Anything we could dream up, I wanted to implement. I didn't mind diving deep into small bugs and rise with excellent solutions.
Nearing the end of the project, I was excited to release, and saw the beginnings of perfection robbing us of a "good enough" application.
My role towards the end of the project shifted towards a more informed leader in the technical domain. I saw myself switch from "I think we can do all of that!" to "Ok, let's talk about what value that feature would add to the game in conjunction with the time and trade offs adding that in presents."
I was able to help us come to some hard calls, asking for creativity on Jenn's side to find story solutions to issues that were not so easily solved through the tech.
Technical Debt
In many ways, I'm happy with how the code has stayed modular and organized. Additions were easy to add in many portions of the code, including the schemas, inventory menus, and at a page level.
And still, the project acquired it's fair share of technical debt.
My time and resources for the project began to shrink as we neared the end, and I became less and less able to maintain it in the way that I would like. Getting the application done and out in the world took precedence over a pristine, DRY codebase.
This has been a big lesson for me. Ultimately, I stand by the choice to focus on implementation over maintenance for this project — neither of us are planning to return to it. I also don't intend on releasing the code as any sort of basis for other people to use this as a game engine anytime soon.
At the same time, I now deeply understand what technical debt looks and feels like, how it can come about gradually, and that for a project that's meant to be sustained and continually iterated on, it's invaluable to take the time to maintain, refactor, and plan for the future.
Wrapping Up
This was my greatest area of growth. I picked up some great technical skills, certainly. Actually managing the project, triaging feature requests, sticking to an MVP, and communicating to a non-technical collaborator — that's a whole suite of juicy soft skills.
My experience with teaching music came in handy here! Lots of overlap from planning out the next step in a beginner saxophonist's education. And, some interesting new ways of adapting when it came to shipping an entire application!
I hope you check out AC: New Murder!
If you're interested in reading more about the nitty gritty of developing the tech or how I managed the project, you can read my deep dive on each below:
You can also follow Jenn's art and work from her site or twitter.