This is part two of our game development workflow series. For part one, click here. Our previous blog covered the prototyping and pre-production stage of game development. There usually isn’t a clear-cut line when you transition from prototyping to game building (also commonly referred to as production) and you will likely still prototype new levels and features as game development progresses.

Production

During production, teams start to move towards a more standardized workflow. Prototyping and conceptualization still happen as lower priority items are addressed, but most of your high priority and critical items will have already completed those stages by this point. Production is primarily about teams producing enough content to make an entire game. Art teams are developing digital assets, developers are implementing code that will be representative of final gameplay, and level designers start to transform their greyboxed levels into something closer to what is seen in the final game.

As more digital assets are completed, they need to be added to the game so that programmers and level designers can use them. This is where Perforce (www.perforce.com), PlasticSCM (www.plasticscm.com), and similar source control management (SCM) tools that can version game assets are very helpful as digital assets cannot be versioned in the same way as source code. Digital assets are usually modified in their entirety, whereas code can be modified and merged together. To add a deeper level of granularity and review, digital asset management (DAM) tools can be integrated with SCM tools to version assets at a very early stage. This gives your entire team of programmers and level designers easy access to the digital assets so that they can be imported into the game engine and set up with code, physics, and other components. As discussed in the last blog, DAM tools also give creative directors and art leads a place to review assets at various stages of production.

As time goes on, your art assets start to replace the placeholders used in the original prototype, and the game begins to take shape. At this point, you have begun what is often a very time-consuming task of game development: World building.

World building is where you bring your level design to life. You build your virtual play areas using the assets you created. Programmers are constantly testing these areas to ensure that edge cases are identified and that the game meets its performance targets. Play testers play the levels to ensure they work as intended, and don’t contain impassable areas, holes, or other undesired side-effects. Game designers and creative directors review the level as it is created to ensure it conforms to their vision in terms of gameplay and aesthetics.

World building is a time-consuming activity that requires multiple disciplines working together. Keeping these disciplines coordinated and organized is critical to avoid delays in production times. There are many times however, when coordination is not enough to keep teams working efficiently. In many situations bottlenecks occur due to tools and processes that don’t support working in parallel. Often, attempts at pseudo-parallelization like level merging cause more harm than good by introducing problems like asset and file corruption, resulting in lost work. Game engines such as Unreal and Unity provide methods to break levels up into sections that can be worked on independently with the purpose of mitigating these types of problems. However, this approach does not fully solve the issue, and doesn’t introduce sufficient parallelization to drastically improve world building time. In many cases these solutions can also hurt creativity and efficiency as they are not conducive to teamwork or collaboration.