If it’s not working in preproduction it won’t get fixed in production.
In class the other day I learned something that really stuck with me that I wanted to share. Carl Schnurr, one of our professors for our Thesis Prep Class said:
“If something isn’t working in preproduction it won’t get fixed in production”
He was talking about our thesis concepts and talking from experience. Preproduction is like the sketching phase of creating a painting, or the outlining or first draft phase of writing a paper. You take the idea that is in your head and try to put it onto paper and work out prototypes to get your idea into existence. Preproduction is all about figuring out what is working and what the “core” of your game is. What is the main thing you’re going to be doing in your game and what is interesting about it.
Preproduction is a really important phase of development, it could arguably be the most important phase of development considering the above quote. But for some reason people, myself included, sometimes don’t take preproduction as seriously as they should. Using the age old “I’ll worry about that tomorrow” type logic to push difficult problems off into the unknown future.
There’s this thought that problems can always be solved later, that if you have a problem now don’t worry about it, focus on the things you can make better, and leave the rest until later. But remembering this quote, it makes that pushing off phase more of a problem.
The reason this is true is because while preproduction is the time to put all your ideas on the table and tinker and tweak all of your ideas, production is time to grind all your work out. Production is more like an assembly line in the sense that you are trying to push out content in an organized way instead of being given weeks to test ideas and see what works and what doesn’t. Once production rolls around you’re going to be too busy pushing out content to take the time to fix the problems that you’ve put off in preproduction.
I think this idea has farther reaching lessons than just the game design realm. Not only being able to recognize where your week spots are, but also being able to address them in a timely manner is a really important skill. The longer you put off a problem and the more you try and shield yourself from it, the harder of a problem it will be to deal with and the less likely it will be that you can fix problems in a manageable way.
I think it totally makes sense too, if you don’t address problem areas, why would putting them off change the underlying problem? If you aren’t thinking about how your decisions are impacting that problem area then the probability that it is going to improve is not going to get any better.
For example, in my HARDSCOPE playtests so far I have been focusing on adding as many features and mechanics I can think of now so I can go back later and pick and choose the ones that I think are working and remove the ones I think are not. And while adding in these features and mechanics make the game more functional, most of my players seem to have problems understanding the basic mechanics of how to score points and why normally shooting the enemy players doesn’t give them points, and doesn’t kill the other players.
In this instance, because I am doing something unconventional and counter intuitive to players, they become confused when their expectations are not met. Further, because I don’t give enough feedback on when a player is shot but don’t get any points, and why the player is not getting shot it creates confusion for players. They become unhinged from the game because they no longer understand the rules of the game.
Getting to the point, I have been so focused on getting mechanics functional that I have neglected to properly teach players the rules of the game. I tell myself I will make a tutorial later or I will make all the UI later. However, if I don’t specifically dig into this problem and take the time to think about how to adequately teach players the rules of the game, they will continue to be confused and the problem will never get solved.
If its not working in preproduction it won’t get fixed in production.
This is another reason why player feedback is really important, and should be taken really seriously! Even when explaining your game to people, if they don’t understand your concept there is something fundamentally wrong with what you are pitching. Try not to think about that as people being dumb or just not understanding you, but think about what you can do to improve players readability of your game. Ideally, you wont be around to explain the intricacies of your game to every single person who plays it, so you need to think about how players can totally understand your game without you saying a word!
This is starting to get into other areas about how to take feedback so I’m going to stop here and write about how to take feedback soon.
I guess the point I’m trying to make is it’s one thing to note down where problem areas are for you, but it’s a different and equally important skill not only to be able to tackle those problems directly, but also to tackle them in a way that the problem goes away all together.
I hope this was helpful for people! If you have examples of these types of problems that you have recognized feel free to share!
Thanks for reading and have a great day!