The idea behind prototyping is not to make a polished product, to have every game feature, or to have something shippable. Its purpose is to ‘find the fun’ as Clinton Keith would say in his book “Agile Game Development with Scrum”. You want to make sure that concepts set out in the design phase make sense and come together to make a truly fun and playable game. You want to discover this early on in development so that you can iterate early rather than being forced to refactor major pieces of your game to fix fundamental design issues.

There are tools that can speed up the prototyping phase. We mentioned several of these in our other blog. However, in a lot of cases you may not need to use extra paid tools. Often the basic shapes and default assets that ship with game engines suffice. Again, at this point it is more about identifying the core aspects of the game than making something polished.

It’s likely your team will want to continue to use and refine some of the code generated during the prototyping phase. Source code tools such as Git and Perforce are critical to tracking these changes and ensuring you keep a historical account of all your changes as they are made. These tools allow you to try different algorithms and implementations with the safety of being able to roll back to previous working versions should you decide that a change does not work out. It is a good idea to start using these tools as soon as you start programming in your project. In game development, tools like Perforce have a distinct advantage in that they have the capability of storing and versioning game assets as well as source code. More on why that is important later.

Prototyping is a task primarily left to programmers and game designers but communication with the art team is also very important. As prototyping progresses, the design team will start to gather critical prerequisites for specific gameplay mechanics and level design features. It is critical to involve the art team in the process early so that look-and-feel can be discussed and an understanding of the scope of art can begin to form. While the look-and-feel is fine-tuned, artists will continue to create concept art and work with level designers to understand the visual flow of the game. Sound and music artists may be involved at this point, though often sound can come in at a later stage of development.

Just like in programming, it is good to have a record of art assets and a good system to track revisions. The team will likely generate a lot of concept art and you will want to experiment with different looks, compositions, and color palettes. Many larger studios will use digital asset management tools (DAM) like Shotgun to track these assets. The creative director and lead artists use facilities within DAMs to provide feedback on which art should be pursued, changed, or cut. Full-feature DAM software can be expensive, and many small studios will opt for a cheaper solution. Free, open-source alternatives such as ResourceSpace could be adapted to your needs, though they often require some set-up and maintenance, and would likely be lacking in features.

As prototyping progresses, you will eventually reach a point where you are happy with gameplay and your current level designs. In many cases this doesn’t occur on a game-wide scale, but instead for chunks of your game such as a few of the first levels or your core gameplay mechanics. Once you reach this point you can now enter production and the main phase of your project: Building your game.

The Vertical Slice

Sometimes when nearing the mid to end point of pre-production, something called a ‘vertical slice’ will be created. The vertical slice is essentially a small part of the game that is taken through an accelerated development cycle from beginning to end. The purpose of building a vertical slice is to have a better grasp of everything that needs to be considered throughout the entire production pipeline. It helps identify potential technical issues up front, gives the team and potential stakeholders a preview into what their final game will look like, and also greatly helps with task estimation. A later part of this blog will cover task estimation in more depth, but for now just remember that because the vertical slice is more or less representative of the ongoing production process, it gives producers and project managers a way to understand how long things will take.

Creating a vertical slice doesn’t always make sense, but for games with a high level of complexity and scope, it can make a lot of sense. Ideally the vertical slice should be a piece of the game that will be repeatedly created throughout production. This could mean it’s a level, or a location, or some other small piece of the game that there will be many of. If it’s not a part of the game that will need to be repeatedly created throughout production, then the vertical slice will not provide as much useful information. In this case it becomes more of a rush to complete a feature than it is to understand the production process further.

This blog will continue in part 2, where we will cover production and post-production workflows.

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.