About us

Learning about production in pre-production Have you every been on a project with a date scheduled that says "Start production"? This is the date when the team transitions from pre-production to production and a ton of people (internal or outsourced) join the team to create the 10+ hours of gameplay to ship? The idea is that the team knows what's fun about the game and can build a ton of assets in parallel. Did that deadline really work out? Was the team really ready to "go into production"? Most aren't! The main goal of pre-production is to build knowledge, or learn about the game. We want to know how fun our game is, how we are going to make it and how much it is going to cost. Building this knowledge requires iterating on the areas where we lack knowledge. We choose what to work on based on a priority of the knowledge we want to build. For example, we¡¯ll iterate on the core mechanics first because the provide the greatest knowledge of the value they provide to the game. We¡¯ll also iterate on building characters and levels to learn how much effort and cost is required to make many more of them in production. We often focus more on learning about the core mechanics, or the fun of the game, and not enough on how we are going to make it. This results in many projects exceeding their production budgets or schedules. What we need to do is to learn the cost of building assets during pre-production as well as learning about how fun the game is going to be. Both of these go hand-in-hand since we can¡¯t determine the cost of production assets until we know what makes levels fun. Let¡¯s look at level production. Level production can easily require 50%-75% of the production budget. We need to refine our understanding of the effort to build levels during pre-production so that we do not build mechanics which inflate production costs beyond our budget. For example, a fantastic feature for the consumer would be a mechanic that allowed every object in the environment to be destructible. However implementing this may also double the effort to create levels since building destructible geometry everywhere requires far more effort. By knowing these cost implications, the Product Owner (PO) can better judge the value of adding this feature or not.