Thoughts on Pre-Production

This is a series of articles I'm writing as an extended postmortem for Stacks On Stacks (on Stacks), a game I've been working on for five years. You can wishlist the game on Steam here.

Artist's Concept of Mars 2020 Rover (source)

Pre-Production: It's for Everyone

If I were to name one thing to change about Stacks' development it would be to have a structured pre-production phase. When I began development on Stacks I was at the tail end of a one-year dev cycle on our first game, the mobile board game of color, Sature. I was proud of what we had created but felt like moving onto bigger and better things.

Stacks' "pre-production" (if you could call it that) looked like this:

1. Build a prototype
2. It's fun? "Ok, cool, let's make this into a full game now!"

Since I was a solo developer making games primarily as a way to express myself a lot of the "create a game design document", "have a production timeline", and other basics struck me as a bad fit.  I enjoyed the process of making games and wasn't looking at games as a way of sustaining myself financially. Since I don't work on games full time, I didn't have a budget to worry about getting exhausted. I felt that as long as I did the work myself and kept at it, I could make whatever game I wanted.

Ignoring production best practices was a critical error because even if you don't wish to make games commercially you still should make games in a sustainable way. Productions practices help with sustainability by providing efficiency that preserves your personal energies so that you can continue making games. Further, production practices help create a better game, not just a more profitable one. Careful planning and management improve a game's quality by focusing your creative energies on transparent end-goals. So regardless of whether your goal is to make a profit, improve your craft, or maintain your well being it is absolutely worth investing time into good pre-production.
 

You Don't Know What You Don't Know

Unfortunately, this is the ultimate problem with doing pre-production. Unless this is your second time releasing a title that is nearly identical to the last one you did, there are so many unknowns in game development. This is the reason sequels are so attractive, you get to redo something you already did once and rebuild on what you already know instead of reinventing the wheel.
In my case, I had just figured out how to launch a 2D game on Android and iOS, but I had decided to move onto a 3D game primarily targetting desktops and consoles in an unfamiliar engine, Unity. Luckily, one of my goals as a game creator is to learn as much as I can about game development. From this perspective, I've knocked it out of the park with the massive amount of information I've learned. But, in terms of completing projects in a reasonable amount of time, I have failed miserably. I've spent thousands of hours becoming competent at tools that I had no prior knowledge of.

What to Address in Pre-Production

Here are some brief thoughts on aspects of your game that you can address as part of pre-production:

Knowledge Gaps

Try to know what you don't know you don't know. Recognize that if you are making a 3D game for the first time there are tons of aspects that you will need to learn: 3D Modelling, 3D physics, lighting, post-processing, etc.

Pipelines

The more your pipelines can be planned or established ahead of time the better.
What will each of your art assets be composed of? A sprite sheet? A 3d model? What resolution of pixels or number of polygons will your models use?
On the code side of things, are there tools or structures that you can plan for that will allow you to generate your content faster? How will you set up tools?

Team Management 

How will your team manage tasks? What about bug tracking? Will you use software like Jira, Trello, or HackNPlan? If you are remote how will you communicate? A skype meeting? Are meetings every two weeks? Will an internal build posted every week? Do your programmers need a code style guide?  While these can be adjusted over time, establishing the need for this structure and getting them in place immediately is a wise decision.

Art Direction

Your game's art style should be prototyped and tested just as much as the mechanics. Having an established art style that you know resonates with people is one of the most useful marketing tools your game can have. Test early vertical slices of your game's art and animation on Twitter. See what gets a positive response.

The Game Design Document

While GDDs should be organic, evolving documents, the most vital issue to address during pre-production is proving that your prototype can evolve into a longer game experience. Transforming an experience that is fun in the short term into one that sustains interest is an unexpected challenge some developers don't prepare for. In some cases, it may not be possible to stretch a prototype into a longer game and it's important you realize this sooner rather than later. The best talk I've heard on this topic was given by Lisa Wertle, titled Design Tips for Long Form Games. You can find a useful questionnaire and a link to the slides for this talk here.

Target Platforms

For info on targetting a platform, check out my other blog post: Picking a Platform: Bottom-up vs Top-down Thinking

The one addendum I'll add is just because an engine supports a platform out of the box that does not mean you should target it. Sure, Unity can build to Linux and Mac, but do you have the resources to be able to test, deploy, and fix bugs for those platforms? Does launching on these platforms even offer you a commercial advantage to make up for those sunk resources? Ben Golus, claimed that Linux users accounted for "[less than] .1% of sales but [greater than] 20% of auto reported crashes and support tickets" for Planetary Annihilation (Twitter).