Game Development Workflow Part 2: Production and Post-Production
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.
It’s because of these issues that we created Scene Fusion. Scene Fusion allows a team to work within a single level in real-time. This enables a far more efficient and creative workflow as feedback is instantaneous between the different disciplines of world builders. For example, people doing scene lighting can make adjustments in real-time with people doing architecture and level design, while the creative director interacts with world builders in real-time to provide feedback on level layout and aesthetics.
The Importance of Testing
One of the key activities that is often overlooked or left to the last minute is testing. When we refer to testing, we’re not just talking about play testing, we’re talking about code-level tests. If you write some type of AI, you will want to write some code accompanying it that tests it and reports on if there were any problems. This is called Unit Testing. It’s one form of testing that’s very helpful, and saves you time over the course of your project.
There are several frameworks you can use to make unit testing very easy. These frameworks will run your test code and generate a graphical report so you can see what is passing or failing. Writing your code to be testable also helps you generate better code that you can often reuse in other projects. If you are using Unity3D or Monogame, you’ll probably look to use nUnit. C++-based games will often use CppUnit. Some engines will also have built-in automation tools, such as Unreal Engine 4’s UnrealFrontend (UFE) tool.
Although playtesting is not the only type of testing you should do, it is still very important. There are typically two parts to playtesting: 1. Quality Assurance (QA) testing and 2. User Acceptance testing (UAT). QA is typically an internal process involving testing the current state of the game for bugs, problems, or features that do not function as intended. UAT on the other hand involves a mix of internal and external tests that are geared towards discovering what players like about the game and how well it’s received.
The critical thing to remember with testing is that it needs to occur early and it needs to happen often. Waiting until the end of development to test your game for bugs or to find out if your target audience enjoys playing it is not a good idea. This can lead to major refactors at the end of game development or worse, releasing a buggy game that no one wants to play.
The End of Production
If you block out what activities you perform over the course of your development schedule, it can look something like this:
Generalized Gamedev Workflow Timeline
Keep in mind that the game development process needs to remain fluid and that this is just a very general visualization of what it can look like. In reality, many of these tasks are overlapping and occur at various times during development. That said, most ‘pieces’ of the game will go through an order similar to this. Clearly there are a lot of things going on at the same time, and choosing tools that allow you to transition from one activity to the next is going to make the process much smoother.
As production reaches its later stages, you will enter post-production. This is where you are focusing on the final polishing for your game and solving any outstanding bugs. Much of this stage involves small tweaks to the design or aesthetic of the game such as adding clutter or non-critical props, final lighting passes, performance optimization, and non-critical bug fixes.
This blog will continue in part 3, where we will cover how to manage your project as well as practices and methodologies that can help your team succeed.
For more information on KinematicSoup and our latest tool that helps game developers create richer content faster and more collaboratively, visit KinematicSoup.com/scene-fusion.