Production Planning

Happy new year, everyone!

We’ve started off 2022 with some housekeeping, organization, planning for pitching and formulating our pipeline and deadlines for the first quarter.

We’ve managed to plot out a rough overview of a production schedule with tentative deadlines. For the next few months we will be focusing on building the Steam page, pitching the game to publishers and seeking private and public funding opportunities for the studio.

Update

The prototype is complete, which means we can submit it to publishers and showcase events for the next year! Code-wise, we will be cleaning up the code from the prototype and moving over all the elements we want to keep for the demo, as well as expanding on some ideas we didn’t have time to include but want to have in the demo. As of now, there is no definitive date for the demo release, but we want to keep it within the first quarter of this year.

For the production schedule, we are keeping a loose, high-level plan in mind. We are also creating a timeline for a larger scale game as well as a minimum viable product timeline in case our funding goals aren’t reached by the first quarter of this year. After a bit of research, we’ve concluded that having a flexible scale/production plan will help us mitigate the risk of going over budget and/or losing a lot of work halfway through production.

We are keeping all of our deadlines rough for now because we don’t want to put ourselves under too much pressure this early in development. We’ve also discovered an interesting method to achieving milestones, called the agile method. This method puts an emphasis on achieving short-term goals and breaking up the overall development into small, achievable “sprints”, that usually last from 2 weeks to a month.

After each “sprint”, we take some time to celebrate the achievement, then regroup to assess how well everything went and whether we need to focus on certain problems or move on. Our hope with using this method is to avoid dependencies, or “bottle-necking”, a common scenario in which one of us is waiting on the work of another to continue their own work. This can be the source of a lot of frustration, conflict and stress during development, and something we have become very familiar with while working on Raptor Boyfriend. It can also cause unnecessary delays in development. With the agile method, we would be able to leap frog to the finish line of each milestone, hopefully avoiding a lot of bottle-necking situations.

Another helpful strategy we’ve used is creating a schematic for what we imagine the different scales of the game would look like. Before on Raptor Boyfriend, we would think about the scale of the game in terms of length and word count. Now however, we would like to approach scale more flexibly, and consider expansion that includes more gameplay elements like puzzles and repeatable minigames rather than story length. Being able to add features without affecting the overall story will be key to determining how to cut things if and when we don’t have time to develop them.

To help us visualize the different scales of our project, Titus created rough schematics of how the project looks from 4 different levels of scale.

These schematics are very helpful in determining a rough estimate for how much more work each level would require, and therefore the budget we would need for each one. we can also now use these to illustrate our funding needs more clearly to potential investors and publishers.

Other than planning the next few months of production, we have been building funding proposals, pitch decks and gathering contacts of publishers we want to work with. We will be drafting emails to them within the next couple of weeks so hopefully we will have all our pitches ready and sent by February. When we are finished, we will be planning on sharing a sample version of it on here and on Notion.so for everyone to see!

Thanks for reading this, as always we hope you’ve found this interesting or insightful!