Note: This blog will be continued over the course of the next few weeks. Although posted by me, it is a combined work from several employees at KinematicSoup. These are our own conclusions based on personal experience in the industry.
This blog is meant to give a very high level and generalized introduction into the workflow behind creating games. It is not meant to be a strict guide as teams will adapt their development methods to suit their needs.
What is a Workflow?
Never bite off more you than you can chew, or at least so my various elders have told me while growing up. In my younger days, building games was in some ways harder and in other ways easier than it is today. Back then there were no AAA titles and every game was an indie game. With some decent pixel art and clever programming you could define, and then redefine, entire gaming categories. Things have changed. We now have a concept of blockbuster games with hundred-million-dollar development budgets and revenues in the billions. This changes a fan’s perception, and should he or she decide to build a game, they may be tempted to set their expectations a little too high.
Before you start, remember, baby steps. Don’t go out thinking you’ll make the next Call of Duty or League of Legends. Start small, do something simple, and get your bearings. Once you have a simple idea that you can imagine yourself putting the work into, you’re ready to get into the nitty gritty of actually building it.
These days, building games is more popular than ever. Tools and services for making them are getting better, cheaper, and more accessible. However, if you are new to the trade it can be very daunting. You need a mix of artistic and technical talents to pull it off. First of all, it requires a mix of disciplines such as audio and visual art, programming, and game design all working together. Many new studios are starting without the benefit of experience, and the various challenges of game development can make that first project difficult to ship. The key is to adopt a series of steps and the discipline to follow them that helps mitigate potential problems. This is called a workflow. In your travels, you will also hear the word “pipeline”, which I will use interchangeably with workflow for the purpose of this blog.
Level Building Production Pipeline. Credit: http://www.skins.abtec.org/skins1.0/?cat=27
So then, where do you start?
Design and Prototyping
The initial stages of game development are design and prototyping, also known as the concept and pre-production phases. Design is where you define the game rules, gameplay, theme, art style, and control schemes. This stage is dominated by activities such as creating concept art, defining pacing and mechanics, story-boarding and level mapping. Design is really meant to give the team an understanding of the project goals, theme, and what gameplay should look and feel like.
Prototyping is where you make a minimal mock-up of the gameplay and game rules to make sure they fundamentally work. Many larger studios use minimal art assets to build the initial prototype. They use stock or previously used models. Very few, if any, textures and placeholder sounds are used as needed. This stage of development has several names: white boxing, grey boxing, blue boxing – they all refer to the same activity: performing a rough sketch of your game. You will spend some time writing rough core mechanic code, seeing if the basics of the game’s design are fun, playing through your prototype, and using what you learn to refine your design.
Greyboxed Level. Credit: http://www.pcgamer.com/building-crown-part-two-layout-design-textures-and-the-hammer-editor/
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.