undo Back to Articles Index

MS501 Post-Mortem

By: John Kidd Jr on 10/29/2024 06:29 PM

What went right?

The first thing that went really well with this project is how quickly I was able to transition from my original plan, working with the studio class, to working solo. I started the class thinking that 20 hours per week on a project I'm creating from scratch would just not be doable within the time frame and that I would just fall behind in the class. However, near the end of the first week having not heard back on possible studio teams I could join, I made the decision to see if I could cancel working with them since it was starting to feel like I would fall further behind waiting for everything to be decided. Luckily, my proposal was accepted, and I was able to switch over to working on my own idea over the weekend, giving me enough time to get half my hours in still!

The next thing I would consider having gone well, is the sheer volume of feedback I got for my initial pitch. I was expecting a few small and simple things but ended up with a large wealth of additional information. This really helped me correct a problem that I hadn’t even noticed yet by that point; the game was simply going to be too expensive to make. I was able to use this information, and the suggestions made to me to come up with a better way to design the story elements, such that they are easily reusable and can be swapped in and out in real time.

Coming up with art assets also gave me a lot of time to play around with AI and experiment to get the style and look that I wanted. I was worried about the prospect of adding visuals to the presentation and the design since I do not possess an ability to draw, but with the assistance of AI I was able to get very close to what I actually want and use it as a stand-in.

What went wrong?

The first thing that went wrong was essentially wasting an entire week waiting for the studio to get back to me with projects. All the time I could have spent that week getting things moving and thinking things out better were completely wasted. Luckily, I evaluated my options and gave myself a deadline to either gotten contacted by them or to move onto my own project. I also started brainstorming and writing down ideas in the half day leading up to my self-imposed deadline which made the transition a little faster and easier than it would have if I had truly done nothing until switching to a solo project.

On the same sort of thread, is that I would rather have completed the assignments as part of a team. As much fun as it was to come up with my own game and design, I think the experience of working with a team and people that may not always agree with you would be significantly more beneficial than working solo.

Likely one of the biggest issues I had was that I had to break up the time I was working on the project quite a bit at times. Sometimes I would only have an hour or two at a time to work on it, which meant I was constantly paying the cost of context switching. To try to combat the cost of context switching, I started trying to schedule out my time so that large chunks were carved out Friday night and over the weekend, and that seemed to help with my efficiency quite a bit.

Most important takeaway?

The biggest takeaway I have from this experience is that documentation is hard; there is a lot of it, a lot of research has to go into every little thing, and because of that there's a good reason it takes several specialized producers to write it all up. Using Agile definitely helps quite a bit with this, since you would no longer need to write out exhaustive documentation for the entire game, but can instead focus on documenting the features and lore that are needed by the development team in the short term. Even with Agile though, the process is definitely improved by splitting up the responsibilities to multiple producers specializing in different fields.

undo Back to Articles Index