Production – how are games actually made?
This could well end up being a long post, because this is a pretty intricate and complicated topic. But what the hell, lets have a go:)
Production is generally broken into 4 parts :-
Alpha / Beta
Patch Support / DLC if the product demands it.
Lets look at each section to see what they have in them.
This is the part where there is generally a very small team – this is where the What of the game intended to be made is created. Generally games start with an idea – “I want to do something with Pirates”. So then a real basic design starts to form. This incorporates stuff like Demographic targeting (“Who likes Pirates? Do they buy games? What do they like? What can we sell them on?”), the competition, genre (“Should this be a tactical RTS game, or a 3rp person swash buckler?”) and so on.
Basically the outline of what the team intends to make. Once that’s clear then the team starts to bear down on the actual design of the product – what the game play will be, what the hooks will be, do mock ups of UI and so on.
Note, the scope of the game under consideration may change at this point – it might suddenly become a AAA game, or potentially a smaller game depending on the design decisions.
If the cost and time for the game development process has already been nailed down then design decisions will be tailored to that; if not then it’s more of a back and forth between what design wants to do and what the production team feels comfortable being able to achieve.
Once the design has been settled upon, its time to start building small prototypes for examples of game play – to prove that a) it’s fun and b) the team can actually make it. The idea here is to remove risk down the line so that when full production takes place there will be no going down blind alleys, redoing of content or suddenly realising that something isn’t fun.
Prototypes can be code, card games (to balance units in RTS type games), pre-rendered movies and other ideas – anything that proves out that what the team intends to build is possible and fun.
Something else prototypes are used for is so the team can get a feel for technology requirements they may not have done in the past. If a game design calls for a streaming world system and no one at the company has any experience with building those systems then creating a prototype will help them understand what the issues are and how they might be solved – again about removing potential area’s of risk down the line.
While prototypes are being made, the art team will be concentrating on visual style creating concept art, story boards for any cinematics and so on. Usually some small pre-rendered movie is generated in order for the team to understand what the game will look like once it’s done. This is called the Visual Target.
Story, dialog and cut scenes are constructed at this stage – stories to support the design elements and cut scenes to move it along.
Budgets and milestones are built at this stage and at the end of this stage the team should be in possession of the knowledge of what they are making, what it’ll cost, how many people they will need, how long they will need, have demos of gameplay, a good understanding of what the game will look like and what tools and technology they will require. Basically a complete plan and vision that the entire team shares so everyone is moving in the same direction from hereon out.
This phase can take anywhere from 3 months to a year depending on how tolerant their funding source is.
This is where all the prototypes get thrown together in a framework to see how well they work together. Making prototypes by themselves is one thing and it may well prove out technology and design decisions, but there’s no guaranteeing that these elements will actually work together. The vertical slice is a basic attempt to push them together to see what happens.
A Vertical slice usually contains production quality art and effects but is only a very small slice of what the game contains.
For example, for an FPS game a vertical slice might contain one weapon, one bad guy, one set of effects and one level. It proves out all the systems required to make this work and also proves out the content creation pipeline that is required to get content into the game (in most cases this process really highlights the work that needs to be done on the tools and content creation pipeline).
At the end of this process the team has a pretty comprehensive demo of what they expect the game to look and feel like, even if some parts are missing (some of the lighting might not look right and there might be several AI parts missing).
Once the team knows what it has on it’s plate, it’s time to start buckling down and creating the actual game content and game engine. Usually at this point there is a basic game framework to build upon and engineering starts in on this, providing game and engine features that are required.
They also start producing the tools that content creators will need to make levels, models, particle effects and so on into the game first, since content creators will need these.
Often the team is starting from an established code base so lots of these features might already be there, but usually there is some requirement to extend or change these.
Once the tool pipeline is in place, the work of content creation begins. Models, animations, particle effects, levels, scripts, AI, sounds etc are all constructed. Basically the guts of the game.
Engineering takes all these elements and starts putting them together as a complete product.
Alpha – Beta
Alpha is defined as where the game is ‘content complete’. Basically everything that is supposed to be in the game is now in there. There might be some ‘programmer art’ or weapons that aren’t completely functional, or missing AI or so on, but everything that’s supposed to be there is represented in some way, even if it is temporary.
At this point the team stops creating new content and just bears down on whats there, replacing temporary art and sounds, stop gap animations and also starts polishing what is there.
Engineering now concentrates on fixing obvious bugs and adding in the last of what is hacked together.
Right now is when ‘crunch mode’ usually starts – the late nights and working weekends to get stuff done on time.
This is also the time when QA (Quality Assurance) starts getting involved. QA is basically your testers. They start playing the game and finding the more obvious and egregious bugs.
Beta is defined as when the team thinks “This is done”. It’s content complete, everything that is there is there in it’s final form and now it’s just a question of finding and fixing bugs. This is where QA can _really_ get involved, testing each build religiously.
Eventually the team gets to the stage where there are zero ‘Show Stopper’ bugs in the bug Database and the game “goes gold”, which means it’s ready to be shipped off to the publisher for duplication.
The team then takes a week off to recover from their heroic effort!
Post Ship Support / Downloadable Content
Generally console games don’t have too much of this – in the past it was all cartridges and as such it wasn’t possible to produce a ‘patch’ for a game that might fix bugs or add new content. PC games have always had this, but it’s not been prevalent for console games
These days, which consoles that have HardDrives it’s starting to become more and more The Thing – not a good thing but ultimately necessary given the complexity and scope of todays games. Almost every games ship with known bugs simply to get the game out the door, and there is an increasing “fix it post ship” mentality that’s erupting.
There is another side to post ship support rather than just fixing bugs, and that’s downloadable content. Microsoft and Sony are very hot on this – they call it MicroTransactions. The idea is that the game extends its “legs” by offering extra small items for download over time – it both extends the life of the product and also provides an ongoing revenue stream. The downloadable songs for Guitar Hero and Rock Band are a great example of this.
Lots of games are now building this kind of post ship content creation idea into their designs, and quite honestly it’s a smart move.
Ok, so that’s the average production process. Some games don’t go through this or don’t have pre-production because their funding sources won’t fund it. Generally though this is what most game development is like these days.
I hope you found this interesting – there’s obviously way more depth than I’ve been able to go into in these posts, but hopefully the broad over-view is there.
- February 2015
- January 2015
- August 2014
- July 2014
- May 2014
- April 2014
- February 2013
- January 2013
- December 2012
- March 2010
- February 2010
- May 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- January 2007
- December 2006
- May 2006
- April 2006
- March 2006
- February 2006
- January 2006