I thought it was time to update this article and maybe try to finish it. It's been 5 years since I wrote the original and lots of stuff has changed.  In particular it's even more work now than it was then.  Budgets for games are 3 to 5 times what they were then.  So, here is "Making Games Version 1.5"

Do you know what it really takes to make a video game? Do you know why a game costs $60 or even $80. Making a game takes a ton of work.

Sometimes I think I should try to teach a class in it in high school. Creating a game might be something that some students might want to do and having a class about it would allow them to experience what it really takes to make a game. It's not just about having fun, it's about lots and lots of work. It's about reports, schedules, budgets, tradeoffs, teamwork. All the things I wasn't taught in high school or college for that matter.

Pitching

Most people think that a game starts when someone has a great idea for a game. The problem is that almost everyone in the industry and every game player thinks they have a great idea for a game. Someone has to be convinced that your idea is the one idea that should get done. This is done by pitching the game whether you're an internal team (a team that is internal to the game publisher) or an external development team (a team not owned by any publishing company but that does products on contract for a publisher.)

To pitch a game you have to create pitch materials. The better your materials the better your chance of getting your game approved. Usually the minimum materials are a small report 2 or 3 pages describing the game briefly. If you can't describe the game briefly then you are unlikely to be able to keep the attention of the people you are trying to sell the game to. Most of them are not game players. Another common pitch material are storyboards. Storyboards attempt to show the game with pictures. Good looking storyboards definitely make an impression over those teams that don't have them. Even better than storyboards is an actual demo of the game. With technology for making games relatively easy to access many publishers won't even talk to you without a demo these days.

Time and Money

What many people don't realize is that the game they pitch must be able to be done in a certain amount of time within a certain budget. Lets say you wanted to make a 3D Fighting game with 20 different characters and 1 background for each character. An intro video introducing the game and a video ending for each character when that character wins the game.  In other words you want to make Tekken.  How much time and how many people is that going to require.

Lets guess that each character will take 1 month to create in 3D and animate. Each background also takes 1 month. The 3D programming we guess will take 1 year. The intro video will take 4 months and each ending video will take 1 month. Add it up.

• 1 month * 20 characters = 20 months
• 1 month * 20 backgrounds = 20 months
• 1 year of programming = 12 months
• 1 intro video = 4 months
• 1 ending video * 20 characters = 20 months

That's 20+20+12+4+20 = 76 months. In other words, if one person could do all the work by themselves it would take them 6 years to make the game. Of course 6 years is too long to take to make a game. If you started today, in 6 years the video game systems that people have at home would probably have been replaced. Instead of a Sony PS2 they'd have a PS3 or maybe even 4 and your game would have no market anymore.

Most publishers would like a game to take 1 year. So if you wanted to get your game done in a year you're going to need at least 7 people. 76 months / 7 = 10.8 months or almost 1 year.

How much do 7 people cost for a year? Well an artist can cost anywhere from $30,000 a year to $100,000 a year depending on their experience. A programmer from $40,000 to $100,000. Lets just guess and assume you get 6 artists for $45,000 each and one programmer for $65,000. That's $45,000*6 + $65,000 = $335,000. But wait, people need benefits like health insurance, they need supplies like paper and pencils. They need a place to work like an office with a desk, a phone and a chair. You also have to pay certain taxes in addition to the taxes that each person on the team pays. All that adds up to around 30% of their salary. So, $335,000*30% = $100,500. Your total cost is now $335,000+$100,500 = $440,000. Okay, now you need equipment and software. Each artist and programmer needs at least one computer. A reasonable computer with monitor will cost at least $3000. Artists need software and 3D software can be very expensive. Lets say you decide to use 3D Studio Max. That's $3500. They may need a copy of Photoshop or some other painting software which is about $600. Your programmer will need a an editor $200, and a development system, $30,000. So the total for equipment so far is

• 7 machines * $3000 = $21000
• 6 3D Studio Max * $3500 = $21000
• 6 Photoshop * $600 = $3600
• 1 development system = $30000
• 21000+21000+3600+30000 = $75600

Total so far, $516,500.

Now lets say you ask a publisher for $516,500 and they agree to give it to you to make the game. What did you forget? Well some things that come to mind, music and sound effects for one. Also, your schedule probably didn't take into account all the communication that needs to go on between team members so they are all working as a team. Do you need someone to lead the team? Do you need a art director to organize the artists and make sure that all the artwork in the game has a consistent look? You could ask one of your 6 artists to do it but then they will be busy managing the other artists and won't have as much time to get their work done. Who is going to pay the bills, do the payroll, order the equipment and software. Whoever does it will have less time for working on the game. What about a network? Are you going to have a network so that people can share there work with each other without having to use lots of floppy disks?

Lets add one more artist as art director and because they are the art director they command a higher salary of $60,000. You also hire a producer or manager to both organize the team and pay the bills and manage the other money matters. (Maybe you don't like the idea of hiring a manager and instead you want to manage. Now your time is taken up by managing so you are going to need to hire someone else to do the work you no longer have time for. Either way it's going to require another person). You need to contract out for music and sound effects. That can easily cost $60,000 to $80,000.

Lets add that in.

• 1 art director = $60,000 + 30% for rent, insurance, taxes, supplies, ... = $78,000
• 1 producer = $40,000 + 30% for overhead = $52000
• Music and sound fx = $70,000
• 2 more machines = $3000 * 2 = $6000
• 1 more 3D Studio Max = $3500
• 1 peer to peer network = $4000

New total = $4000+3500+6000+70000+52000+78000+516500 = $730,000

Lets say you ask for $730,000 from a publisher and they give it to you. You now have enough money to pay your team for exactly one year and no more. If you forgot something tough luck. If it takes 16 months instead of 12 you're going to go hungry for 4 of those months or your going to have to re-negotiate with your publisher and they are going to want something in return for your failure to deliver your game within the time and budget you originally promised. They might for example lower your royalties or they might demand a part of your company. They might ask you all to take a 50% pay cut until you finish.

Lets take a look at royalties. Most games by external developers are done on an advance against royalties arrangement. That means that the $730,000 they gave you is an advance against your royalties. Maybe you got 15% royalties and the game sells for a suggested list price of $49.95. You don't get 15% of $49.95. You get 15% of net so if the list price is $49.95 the wholesale price is probably 45% of that or $22.48. If this is a Sony PS2 or XBox game I think they both charge around $8.00 per disc sold as a licensing fee so the net price is $14.48. 15% of that is $2.17. Your team gets $2.17 per unit sold. You got an advance of $730,000. $730,000 / $2.17 = 336,406 units. You must sell 336,406 units before your team will see any more money than they already got. Not very many games sell 336,406 units. Maybe only the top 10 games on any platform.

Another issue that comes up here is the feeling that the publisher is being greedy.   The typical point of view of the developer, you, is that you are going to do all the work and they are getting 85% of that $14.48.  You feel like you should get more.   I know I often felt this way.  Here's the other point of view.  From the view of the publisher they put in $730,000 and probably several $100,000 more on marketing and plus they also need to pay sales people and marketing people and producers etc.   Lets say they spent a total of $1,500,000 on your game.  What have you spent?   You've spent $0.  They are risking $1.5 million dollars on you.  If you or your team fails they are out $1.5 million dollars.  On the other hand you risk nothing.  If you fail you already made $730,000 dollars.  That hardly seems fair.  The reason they get all the money is that they are the people taking all the risk.  That actually brings up another point, if you want a better deal, lower their risk.  For example if you develop the game entirely on your own and then once it's finished you go to them and they decide to publish it you can usually get a much better deal.  The reason is that they don't have to risk as much money.  Of course they still have to risk all the money they will spend of advertising and duplication and distribution and sales.  Unfortunately most people can't make a product on their own.  It takes too long and too many people.

Design

Design is going to be different for different types of games.  For the type of game I like to make, action games or action adventure games, I personally believe the best way to design is by storyboard and sketches.  I've seen teams make huge documents 300 to 400 pages long for their games and I personally don't think it works.  Nobody wants to read a 300 page document.  Instead you probably need some kind of outline just so you can make sure you've got everything listed.  Then you need to design each world and each character and each object.  Each item will need two basic things, a visual design and a behavioral design.  The visual design would be designed by the artists.   This is one way to get your artists involved in the game.  Give them a basic idea of what you want to do with the game and then give them a couple of days to go off and sketch settings or characters or objects.  Then have a big meeting and decide together which of their ideas the team wants to actually use in the game.  Once the team has chosen the artists can make much more detailed color version of those items.  You see this type of thing in movie production.  The #1 reason you need this is you need to make sure everybody understands what everybody is trying to make and a visual picture is your blueprint.  In other words, "make what you see in the picture".

The perfect example of this is the original Star Wars.  If you look in to the making of Star Wars you will see lots of paintings by a guy named Ralph McQuarrie.  I used to think those painting were made after the movies since they looks so close to scenes in the movies but actually the opposite is true.  Mr. McQuarrie drew those paintings and then from those paintings people made the movie.  If you think about it you can see why this is so important.  It takes lots of people to make movies and video games and without images like these nobody will have the same idea for how to make their particular piece of a level or scene.

Secondly you need behavioral design.  This is best done with sketches.  In the movies this would be the black and white sketches that show each scene and camera angle.  In a game these would be sketches that show each item and character and all their moves and behaviors with notes giving details for things like timing, speed, distance, power etc.  While working on Zombie Revenge at Sega I saw hundreds of these sketches.  Every motion needed for every character had a sketch describing the motion BEFORE the motion was created.

Levels also need to be sketched.  These should look like blueprints or top down maps that show where each item/door/character etc should be.  Having worked both ways I personally believe levels should be laid out on paper by game designers and THEN those designs should be handed off to artists so the artist can build the level based on the game designers blue print.  This lets the game designer make sure the level is designed to be fun, fair, not frustrating, etc and lets the artist make it look beautiful.   Some of you are going to think you can just jump into a map editor or 3d program and start creating a level.  It could happen but I've never seen a really good level come out this way on time.  The problem is without a blueprint you have no idea where you are going or when you're done.  You'll just keep noodling and noodling until you get bored and start working on something else.  If you have a blueprint you'll have a specific goal in mind.  You'll know when you are finished and when you are not.   You'll know what other things need to be created for the level before the level is even built.

The successful companies where great products are made on time the designer is at the top of the heap. From the designers the game is made.  That means they must be good people capable of leading, of creating designs that are possible, of not creating frivolous un-thought-through designs that the team implements and then have to be thrown away.  They need to be aware that from their designs, thousands of dollars will be spent implementing them and that bad decisions from them will cost lots of money and possibly the entire project.

Another issue with design is keeping your design within your allotted budget and time.  Money and time are not unlimited and you can't have every feature you think you want.  One approach is to design with the ability to cut things in mind.  Maybe you are making an RPG and there are 10 side quests.  You should leave implementing the side quests the main quest is finished.  Then you start making the side quests.  That way, if you run out of money you can ship the game with only some or none of the side quests.  Sure, to you and the team you'll be frustrated and sad that your great ideas for side quests did not make it in the game and you'll feel the game is less than it should be but the player may not.  The don't have a vision of the game with all your side quests in it.  There vision of the game is what they see when they first play it and so they will not be missing these things.

In that vein, as you design you should design from most important elements to least.  If you are making a character action game then the main character is #1.  What can he do?  What are his moves?  Next you should design a couple of levels.  You need to flesh those levels out.  Finish them before you move on to other levels.  Another suggestion, don't start with the first level.  You and your team will not be doing your best work when you are just starting and don't have a feeling for the game and all the processes and tools used to make it but you want what the player sees first to grab their attention so pick some middle level or area to do first and then after you've done a couple of stages then go and do the first level.  This way your first level will be better than if you had done it first.

Also, in the same way is saving the side quests for last, get your game shippable as soon as possible.  Get 2 or 3 levels running and then get all that other stuff in, glue screens, options screens, inventor screens, memory card or saved game stuff, network play, whatever it is.  Put the sounds, the voice, a cutscene, music, everything.  Until you've done it all you don't really know how much work you have ahead of you.

Programming

Programming is getting both harder and easier than ever.  Easier because today's systems are powerful enough that you can buy an engine for them.  Rendeware, Alchemy, etc.  Harder because now there are so many more parts then their used to be.  Physics, shaders, networking, hard drives, encryption, multiplayer modes, rumble paks, gameboy advanced options, co-processors, AI, etc etc etc.  It used to be that a couple of programmers could do the entire game.  Now if you look at the job listings each position is specialized.  Server side network programmer, client side network programmer, physics programmer, sound programmer, sound tools programmer, 3d engine programmer, game programmer, AI programmer, 3D tools programmer, content management programmer.

As another example here is an incomplete list of some of the programming tasks that have to be done

• I/O system
  • Bigfile:

    putting all data into one big file so the OS doesn't waste any memory and access is faster

  • asynchronous I/O

    so that parts of the game can be loaded as the game plays.  Jak & Daxter, GTA3, Metroid Prime and Zelda: Wind Waker do this well

  • Compact file format tools

    PC games often put each texture, model, map and sound in separate files and load them one at a time.  They may make the game load faster by putting all those files into a bigfile but they still load each piece of data separately.  Console games generally write tools that take all the data for one area or stage and put it all into one file that can be loaded all at once and be ready to use the second it is loaded.

• 2D graphics
  • displaying bitmaps with transparency

    you need code to load and deal with lots of bitmaps or 2d images including handling various levels of transparency and drawing them at a 1 pixel in the original to 1 pixel on the display mode and possibly scaling and rotating them.

  • drawing primitives (lines, rectangles circles)

    some projects need a way to draw lines, rectangles, circles, ovals etc in 2D.  For example Ridge Racer 4's glue screens.

  • fonts

    nearly all projects need a way to draw text.  This is not as simple as it sounds.  Drawing a lot of text 1 character at a time can really slow down a game so sometimes text needs to be drawn to an off screen buffer and then that buffer drawn as a 2D image.  Managing these 2D buffers is more work on top of all the rest.  Also, normal windowing systems use fonts that are rendered on the fly at any size.  That style is great for an application but is usually considered too slow for a game.

    worse, vram and memory are scarce on console systems and although English may have only 26 letters, other languages have far more like Japanese which has about 2100.  Did you save enough memory to be able to make a Japanese version of your game?

• 3D graphics
  • background engines

    most game engines separate they way the draw background graphics from graphics for moving objects or characters.  This is because in most games the background rarely changes and there is so much of it so various optimizations and methods need to be considered to be able to draw it all.  One of the problems in drawing the level graphics in a 3D game is there is too much of it and if you draw it all the game would run way too slow.  You need a way to find out as quickly as possible which parts of your level are actually visible so you can draw only those pieces.  Then you often need a way to simplify them in the distance. Each game is different but most games will use one or more engine or technique to deal with the background

    • terrain engines

      this is where the level is represented by a height map.  One way to imaging a height map is as a 2D grayscale image where dark pixels represent lower areas than light pixels.  terrain engines are relatively easy to optimize though they generally make pretty boring backgrounds.  I believe the ATV Offroad Fury series uses a terrain engine

    • portal engines

      portal engines were first made popular by Descent.  The basic idea is each area of a level is considered a room or box.  The system knows which room you are in and which rooms connect to this room and where the doors and windows are that see into those other rooms (the portals to those other rooms).  So, from the room you are in they can look at each portal to the other rooms and first see if that portal is visible.  If it's not then obviously you can't see into that room.  If they are then they can look into that room clipping to the size of the portal and figure out what inside the other room you can see and also if there are any portals in that room that allow you to see into other rooms.  Portal engines probably work best on indoor levels since outdoor levels would have no portals.

    • bsp engines

      bsp engines were first introduced by Doom.  A BSP based engine basically divides the world into 2 pieces, then each of those into 2 pieces, and each of those into 2 pieces etc until there is only 1 item in each *piece*.  This makes it relatively easy to quickly figure out what you can and can't see.

      I believe, although I could be wrong, that BSP based engines really only worked back in the Doom days when levels were only 10000 to 40000 polygons.  On current games were a level can be more than a million polygons they just don't work.

    • instance engines

      this is where you make a model of say a tree and you repeat it all over the place by just storing the position and orientation of each tree.  Some engines go will instance the models and textures but keep the vertex color information separate for each instance.

    • plain old 3d drawing

      some engines just basically use lots of individual models.  You could almost call this an instancing engine except no model is used more than once.  With both the instance and plain old 3d engines there are various ways to organize them or store data we call the PVS (potential visible set) so that from any place in the world we can quickly figure out which things are potentially visible.

      For example if you are standing by a house and on the opposite side of the house is a large rock, the PVS might say that from that side of the house you can't see the rock.  Actually it would be the other way around.  The rock would not be in the set of things you can see from that side of the house.

      Computing a PVS can take a lot of power.  I've heard of games where the tools take up to 3 days to compute that information for one level.

  • static models

    most games need a way to draw just normal non-animated models like a crate. This is usually separate from some of the other methods below since each of the methods below is slower to implement.

  • morph targets

    many modern games use a system called morph targets where 2 or more models are blended.  The facial animations in Jak & Daxter are supposedly using the morph target technique.

  • skinned models

    skinned models is how most characters are done now-a-days where a character model is made from polygons an then set of *bones* are put inside.  Each of the vertices of the polygons are attached to from 1 to 4 bones.  The bones can then be animated and the position of the vertices computed to adjust the model to match.

  • translucent polygons

    on most systems dealing with translucent polygons, like the glass in a window, is a huge issue and ends up requiring lots of work that would not be needed if there were no translucent polygons.  The only system I know of that required no special work for transparent polygons was the Dreamcast.  The hardware handled all that for you automatically.

  • vertex shaders and co-processors

    modern systems have vertex shaders (xbox) or co-processors (ps2) to deal with some of these 3D computations.  Someone has to learn how to use these systems and program them and they can be extremely complex (ps2)

  • pixel shaders

    recently the newest systems (XBox, PC) have pixel shaders which allow complex effects.  Again, someone has to program this stuff.  In movies there are many shader programmers for each movie.  When PS3 and XBox2 come out it's likely we might need the same types of specialists for games.

  • effects

    as the power of our machines gets bigger and bigger we start demanding more and more effects but those effects don't come for free.  Someone has to program them, adjust the engine to handle them, and artists have to provide art for them.  More and more work

    • bump or normal mapping

      this requires a special texture map that represents the height of an area of a texture or the angle which that area faces like a rivet on a crate.  Someone has to create that texture on top of the color textures they used to create and the programmers have to find memory to store these, ways to reference them in the game, get them to the graphics hardware, etc.

    • environment mapping

      this is how you get things that look like they have reflections.  Again requiring more textures, the textures that get reflected, and on current hardware you could even have yet another texture that specifies per pixel how reflective that area is so like a dirty car hood might have just a few spots that are still reflective.

    • glows

      glows are now the big thing.  Tron 2.0 and Half Life 2 have lots of glowing.  This requires a programmer to implement glow and it requires the artists to tag what parts of their artwork glow and in what color.

    • blurs / focus

      many games are now featuring blurring and out of focus effects.

    • refraction mapping

      the technique that lets you see into water and have it warp the stuff under the water.

    • water

      water itself often requires it's own special renderer.  This will probably change to just another pixel shader in next gen hardware

    • fog

      fog could be a simple as just a setting in the hardware or it could be as complex as the fog in GTA3 where there is simulated mist in the air that is actually lit by the street lights

    • realtime shadows

      realtime shadows are a pain in the behind to compute and still have a fast game.

    • volumetric lighting

      this is the effect that makes it look like light is streaming though a crack in the roof of a dark house and lighting up all the dust in the air creating a beam of light or the effect that comes off the flashlights in X-Files.  The next-gen of  hardware is getting to the point that we can actually start the compute this.  In current hardware we mostly fake it with models.

    • fur

      fur shaders are a new technique that was used pretty effectively in Star Fox Adventures.

  • particle systems

    Almost all games require particle systems.  Some are used just to throw up dirt and smoke.  Others are used for all the special magic effects you see in games like Final Fantasy X. Unless you are going to get your programmers to make all your effects you might need to make tools for the artists so they can design these effects.

  • real time scene playback

    in most modern games some programmer has to deal with realtime 3d scene playback.  That includes getting all the data in to memory, compressing it, playing it back, tools to get all the data, etc.

  • texture caching or swapping

    most console systems have limited texture memory and on PCs they have unknown texture memory.  This means someone has to deal with the issue of how to draw all those textures with a limited amount of memory and get them in and out of texture memory as fast as possible

  • camera

    dealing with a 3D camera is one of the hardest problems in some 3D games.  Especially any game where the character is in front of the camera (ie, Mario) vs a game where the character IS the camera (Quake).  To get it not to go inside things it shouldn't. Getting it to not get stuck on things.  Getting it to always show the player like when he walks around something so that a crate or building is between him and the camera. As an example it was reported that there was one programmer that did nothing but camera programming for the entire project on Mario 64.

• Glue Screens

  Teams often give these little thought until it's too late but there is a ton of work to do here on many games for both artists and programmers.

  • Title Screen

    This screen often has a few special effects or animations running as well as a menu allowing you to start a new game, load an old game or pick the options screen

  • Option Screen

    The user needs to be able to adjust the sound levels, pick a difficulty, turn subtitles on or off, etc

  • Configuration screen

    the user might be able to configure their controller, 4:3 vs 16:9 video, and host of graphics options.  These in fact might be several screens

  • Name Entry Screen

    Especially on consoles you need the tried and true name entry screen.  If you are supporting Japanese you'll likely need to support 3 alphabets as well.

  • Load / Save Screens

    Loading and Saving games, checking if memory cards are in, full, if something is already one them, making sure there are no errors, that the saved game has not been hacked or corrupted.  There's more than just this screen as well.  A system often needs to be designed to separate data that is saved from data that is not so that it's easy to save and it's in a compact form that will fit on a memory card.

  • Character Creation

    many games have a character creation screen or screens.  Armored Core has 8 or 9, one for each body part.  I suppose you could also consider all the screens for editing your car parameters in Gran Tursimo to be character creation screens.

  • Network Setup

    If your game has network support then often you need a network setup screen where you can enter things like username, password and other network related stuff

  • Network Game Setup

    Often you need a screen to choose the type of network game you are going to play.  Which level, which options, CTF?  Deathmatch? etc.

  • Network Game Selection

    If you are able to join a game already in progress you need a screen to be able to select them

  • Inventory

    Many games have an inventory screen.  Some games have several.

  • Interior Map Screen

    Some games have a Map screen and often the map screen for the interior of some building or dungeon is different that the Exterior version.  It's not just a matter of displaying a simple screen either.  Maybe your game requires that each area the player as been is marked or that map be in 3D and the player can rotate and zoom it.  Maybe hints are given her including animations showing how to get from where the player is to where the game wants him to go.

  • Exterior Map Screen

    Are you going to need to spool parts of the map because it's too big?

  • Dialog System (RPG)

    Many games have a dialog system, especially RPGs where a small window pops up and text appears.  This is a whole other can of worms.  You need formatting code so you can display some words in different colors or have inventory items or button images appear in the dialog.  Sometimes for dramatic effect you want the dialog to speed up or slow down.  There are sometimes menus that appear allowing you to select an option.  Sometimes you want the dialog synced with some animation in a cutscene.  On top of all that are international issues as well.

  • Console

    many PC games have a *console* made popular by Doom.  They are great for debugging and entering options etc but someone still has to make it.

  • Loading screens (if you need them)

    If you didn't design and code your game so there are little to no load times then you probably need some kind of loading screen.  Sony for example requires that if you have a loading screen it must not be static.

• AI
  • Collisions

    Collisions are another huge element of games especially with so many polygons in the worlds often an entire separate database is needed for collisions.

    • Collisions with background

      just like the graphics, collisions with the background require optimizations to quickly figure out which parts of the background you need to check.

    • Collisions with other objects

      Object need to check for collisions too and checking all objects against all other objects is usually too slow again requiring a system

  • Physics

    The latest games are starting to require physic engines.  This is hard math and it is extremely hard to get it all to run fast and still not mess up.  For example the physics and collisions in Halo are great but there are bugs.  Play 16 player Oddball and watch as the ball sometimes falls through the floor.  In fact if you want to find the physics and collision bugs in most games put a bunch of objects or creature into some corner of a room and then try shove them all into the corner.

  • Path finding

    This used to be something only Realtime Strategy games used like C&C or Warcraft but now even platform and FPS games use path finding so that the monsters don't get stuck on walls, rocks, trees and crates.

  • Event Systems

    Many games use an event based system to allow objects to communicate with each other.  For example a switch telling a door to open or a light to come on.  The event system itself is not hard to write but often tools need to be written to make it easy for designers to setup the events.

  • Object System

    Most games have an object system.  A system that tracks all the things that move in the game.  This can be as simple as just a list of things with pointers to a "processMe()" function or as complex as generic objects that have all kinds of attributes like weight, size, position, etc and a complex system that runs them all.

  • Non Player Character Code

    If your game has lots of characters there can be lots to do here.  Gex for example had over 350 separately programmed objects.  But even if your objects are few like Halo you may make each object extremely flexible and interesting which is a whole other bunch of work.

  • Scripting

    Many games use a scripting language.  Someone has to make that language, integrate it into the game, provide debugging functions, make a compiler, check for errors, and teach everyone else how to use it.

• Main Character or Player code

  Someone has to program the player, reading the controller and making him go through all his moves.  That alone can be a 6-9 month job especially if he has lots of moves.

• Controllers
  • reading the controller

    reading the controller is generally easy but not always.  For example on the PS2 the PS1 inside reads the controller and sends the data across to the PS2.  On top of that there is the issues of forcing the controller into Dual Shock 2 mode.  There's also remapping options that have to be written, etc.

  • recording input for playback

    Sometimes you record input so you can play it back in the game.  Sometimes you record it so you can play it back for finding a bug.  If it's for in game playback you might need to compress it on the fly in order to save memory.

  • dealing with rumble issues

    modern consoles all have vibration built into the controllers.  Here's another set of routines you need to write.

  • calibration

    Some games allow calibration, especially for things like light guns.

• Sound

  Sound can often require a programmer doing nothing but sound programming for an entire project not just because there is programming to do but often there is lots of data.  Crash Team Racing had character sounds for 6 different languages all on the same disc and they were played off the CD as the game was playing.

  • Sound effects

    You need to be able to get lots of sounds into the game and play them back in a variety of ways.  Although many sounds are easy like explosions, other sounds require more direct control like an engine sound.

  • Structured Music

    By structured music I mean midi or mod music, music that is generated on the fly.  More and more people are finally realizing that streamed music doesn't really work well for many genres since it's not instantly available and it makes it hard to load stuff during a level.

  • Streamed Music

    Streamed music is like playing a song off a CD or an MP3.  Dealing with streaming music and still allowing data to load can be another big issue.  Gex did this as does GTA3.

• Video

  Many games use video now and there are issues here as well

  • Basic playback

    For many games this is all they need.  Just the ability to play a full screen video cutscene

  • Ingame playback

    Other games require in game playback which has other issues.  Amplitude does this for it's billboards.

  • Special options

    And there are a host of other things that might come up.  Just like when playing video over the internet there is a wait while it's "buffering".  The same thing happens on video in games.  On some games that buffering was not considered and so when there is a cut from gameplay to a video scene there is a 2 or 3 second pause while it buffers the video.  On a more thought out game the buffering would happen when the player gets close to that part of the level so that when it was time to play the video there would be an instant switch into the video with no delay.  Space Channel 5 Part 2 did this in several spots like when you come out of the space station in level 4 at the end there is a seamless cut from real time 3D to video.

• Networking

  Many current games have a network component which is yet another entire job

  • basic communication

    someone has to design and program the low-level networking system

  • reliable communication

    someone also has to design and deal with the high level data that the game needs to communicate.  Keeping things in sync, not crashing if the server goes down or one of the clients, etc.

  • client setup

    the client (your home machine) has to deal with all the different ways it might need to connect.  Through modem, through DSL, PPPoE, directly, behind NAT, through a proxy, etc.

  • server setup

    some games like Everquest or Final Fantasy XI require a server which could easily be yet another entire team team of programmers

• Tools

  Lots of teams have over looked tools and how much work there is here as well.  Some large companies have entire tools departments although that's often only a starting point.  Someone technical still has to interface and tweak the tools to match a specific game.

  • 3D Export Tools (from Maya or 3D Studio Max)

    Most companies use either Maya, 3D Studio Max or Softimage to make 3D graphics but then some programmer has to create either an exporter or some tool that will take the data from those tools and turn it into something useful in the game.  Those tools have to support all of those effects listed in the graphics section including skinned characters, morph targets, instances, vertex colors, normal maps and more.  A good tool set would also allow the exporting of entire scenes for real time cutscenes.

  • 2D Export Tools (from Photoshop or TGA or PNG)

    Some how you've got to get those graphics from Photoshop, your digital camera or Painter into the game and into a format your target hardware can use.  The might include things like compression for those systems that support it or palette based textures to save memory.

  • Data path creation

    Generally someone has to setup a bunch of tools that are run that take *all* the original data and make it ready to load into the game that includes:

    • 2D graphics

      getting all the textures and bitmaps in, making sure none of them are larger than can be handled and that they fit in memory

    • 3D graphics

      pulling all the polygons and other animation data in, connecting it to the textures

    • Level Data

      all your data for where things are in the world, paths for enemies to follow, triggers the start things going, etc.

    • Sounds

      Getting all those sounds into the game in a fast way, handling the fact the most likely all the sounds won't fit in some levels. Writing tools or scripts to convert all those sounds into bundles or put them on the CD in special formats or knowing where they will be on the CD so you can queue them up.

    • Music

      tools to convert to your structured formats and pull in all the samples to make the music.  Some teams have special tools for the musicians and sound guys so they can actually make and test the sounds on the target systems

    • Video

      getting all that video in your custom format and adding whatever extra data you need in their like subtitles or alternate soundtracks.

  • Event Editing

    Some games have an event editing system for designing puzzles and other events.  It's easiest for the designers if there is a tool that shows the relationships between objects, the events they are sending or listening for etc and makes it easy for the designers to edit those connections.

  • Interface Editor

    Some games have a 2D interface editor to help make it easier to make all the 2D glue screens.  A few games have used Flash for this.

  • Outdoor Map Editor

    If your game has a special way of making the levels you might need to program a custom outdoor level editor.  Warcraft comes to mind.

  • Level Compiler

    Most games need some kind of level compiler to do major processing on all the data to make BSP information or PSV information or arrange the data for spooling.

  • Indoor Map Editor

    If you are using a custom system you might also have an indoor editor like Worldcraft.

  • International Systems

    With 1/3 of your market in Japan, 1/3 in the USA and 1/3 in Europe it would be best if you considered internationalization upfront.  It could be as simple as putting all your text in Excel with macros to get it all out and put it in the game.  Excel supports all languages but you need to do all this upfront and someone needs to write those macros and any other tools or systems that take that data and get it read for the game.

Hopefully you've gotten some idea that there is actually lots of programming to do on a video game.  This is one reason why it can be a great idea to buy an engine and have some percent of this already done for you.  Sadly, at least on consoles, none of the engines are setup to give you a shipping game without lots of work on your part first.

Art

Art creation for games has totally changed over the years as well.  When I started in games in the late 70s, early 80s there was no Photoshop or Maya.  To get graphics into a game we would sketch the graphics on graph paper and then write down all the positions of the pixels on the paper and type that information into the computer by hand.  Now we have tools like Photoshop for 2D graphics, Premiere, After Effects and Vegas for video production, Maya and 3D Studio Max for 3D graphics, digital cameras, scanners, etc.

At the same time, Pac-Man was 16x16 pixels and would take only a few minutes to make today but today's games have levels consisting of thousands to millions of polygons.  A 3D character is 2000 to 20000 polygons and has a bone system from 15 to 80 bones.  Each vertex on the character has 1 to 4 hand set weights for how much each bone influences it and the bones often have to have constraint systems or functions applied to them so they don't bend the wrong way.  Textures have to be drawn to cover a character, often separate textures for different parts.  And, as opposed to just a couple of years ago when we only had to make a color texture, we now have to make bump map textures, reflection map textures, glow textures, and a host of others.

Making a character like Pac-Man took just a few minutes including animation.  Making a character like Solid Snake takes months.  A few days to make the model, then all the textures, setting up the bones, connecting and weighting all the vertices and then animating. Pac-Man just opened and closed his mouth.  Maybe 4 frames total.  Today's characters have thousands of frames of animation and even though the computer tweens for us we demand so many moves that it takes months to make them all.

And that's just the in game characters.  We need artists for the levels.  Artists for all the glue, the title, our logo, the score bar or hud, particle effects.  We have video scenes in most games today that often require a whole separate art team.

Another issue is that for some systems the artists need to create LODs (Level Of Detail) models.  In other words they might create a character out of 3000 polygons for looking at when she's up close to the camera and another out of 300 polygons when she's far away and only 1 inch high on your screen.  This saves processing time and allows the game to run smoothly but requires the artists to make more models and textures.  There also MIPs which are textures that are smaller in resolution used when an object is being drawn far from the camera.  Without them things would be slow and also flicker a lot.  Often they are generated automatically but sometimes they need to be hand edited if the auto-generation doesn't do a good job or if you want special effects.

On top of that, many systems require the artists or designers to make separate models for collisions for the entire level.  These models are similar to the 3D models used in the level but are much simpler with no details and no textures.  Still, it's lots of work and often they have to be tagged with all kinds of attributes like "this thing is deadly" or "this thing is sticky".  And it's not just collision geometry marking what's solid.  Trigger boxes need to be added that mark things like when the player steps inside this area have the boss appear or start a dialog or cutscene or blowup something.  Others might be there only to help direct the camera.

And then, often the AI in the system requires lots of data that we ask the artists to put in.  In the simplest case it's just to put an object in the 3D program to mark where a game object will start but it can go up from there from having to draw the paths the objects will follow or having to add special AI geometry that marks where an AI character can walk, where he can't, where he should jump or step down, etc.

Just like programming art has started to get specialized.  In the past a couple of artists did it all.  Now we have specialty artists.  Storyboard artists, 3D modeling artists, texture artists, lighting artists, animators, 2d artists.  I'm sure like the movies we may even have camera artists soon.

With all that art some companies have even gotten to the point that they have special software to try to keep track of it all.

And it's only going to get worse with the next generation.  Today to make a belt buckle on a character an artist just draws it into the texture by hand.  On the next generation games, for example Doom 3, the artist actually models the belt buckle in 3D, textures it with a metal like texture and then tools take over and extract a color texture and a normal map so that in the game it still looks like a 3D belt buckle complete with highlights, reflections and shadows.

Another thing is you are not going to be able to just hire any old art student or buddy that draws cool pictures of anime characters.  Making good art for games is not the same as making good paper art or even movie CG art.  We've got serious limits.  In a CG movie some artist might use procedural hair and skin for a character and might use a 1024x1024 texture just for the character's eyeball.  They might use nurbs or subdivision surfaces, something the current consoles are not really up to.  They might have a million polygons in their model and all 202 human bones were as a game might have 3000 polygons and 15-30 bones and a limit of 1 256x256 texture for an entire character.

Finding artists that can make good stuff with those limits is very difficult.  As an example of some artists that can, the Gran Turismo 3 artists and the Metal Gear Solid 2 and 3 artists.  All of those games have relatively low-tech graphics engines but the artists are so good those games look incredible.

Sound and Music

In the past sound and music in games were pretty much a last minute thing.  Once the game got 1 or 2 months from shipping the company would hire a sound or music person or both to quickly fill the game with beeps, buzzes and background music.  As games get bigger and bigger this is no longer the case.  Now, many games have almost full orchestral scores and thousands of sounds and we still have extremely limited memory so getting all those sounds and music to fit requires more than just musical skill.

To give you an example my friend on the Jak II team said for one language they had 4000 files of dialog!  They did 9 languages so that's 36,000 files!!!!  Someone has to go through all 36,000 and make sure they are all correct, all finished, all in place.  And that is just the dialog.  They still had music and sound effects.

And, speaking of memory, there is never enough room so you'll need programmers to make up systems to get you all those sounds.  In Gex, Gex has like 400 quips or more.  I don't remember how long the actual list was but we only had memory for 1 quip at a time and so I had to write a system that would try to load a relevant quip, while we were spooling music off the CD at the same time.  You can not play the sound until it's loaded and a relevant quip is one that Gex would say when he attacks a particular enemy or sees one or gets hit by one.  In other words, you can't wait until Gex does his move and then load the sound and play it.  It might be 1 or 2 seconds before that sound is read to play.

Another example.  In Crash Team Racing there were tons of quips as well.  Those quips were played directly off the CD as CD-XA audio so the sound programmer had to make a system to put all those sounds on the CD and queue them up so they could be played quickly when they were needed.

For a while in the mid 90s musicians thought Redbook audio, playing music directly off the CD, was going to be the end all be all for game music.  They could use all the tools at their disposal to make the highest production value music ever.  The industry quickly figured out that red-book or streamed music only fits a very small, very limited set of games.  For one that's because that kind of music takes time to switch and time to queue up so it's not easy to change the music instantly during game play in response to a power up or to the mood going from safe to dangerous.  For another many of today's games need to spool data off the disc while the game is playing.  That's impossible if you are using Redbook audio and can be problematic if you are using streamed music.

So, most games use a some kind of structured music format.  The problem or issue is that just like it's hard to find a good artist that can make good art for your game within the limits of the game system, it's just as hard to find a good musician that can make good music within the limits of your music system.  They might get only 512K or 1Meg in which they have to fit all the instruments for the music that will be played during the current stage AND all the sound effects used in that level.  Try taking a look at the average size of a music sample or instrument and you'll see 512K is not very much memory.

Video

I'm sure you've noticed but today's video games often have video that rivals movies.  The stories may mostly suck but the CG quality is up there and that kind of CG does not come for free.  The opening movies you see can take teams of 5 to 10 people 3 or more months.  One small movie like that could take $100k to $200k or more.  And then you get into games like the Final Fantasy series which has tons of CG movies.

Some people think they will get away cheaper by using real time CG cutscenes.  If they are kept extremely simple that might be true but if they are detailed like MSG 2 or Jak &Daxter they are hardly less work at all.  In fact they might even be more since with fully pre-rendered cutscenes there are no programmers needed to make tools and engines to play them back.  And, it's only going to get worse as the power of each new generation of hardware makes it possible to make real time scenes look like movie CG.  But, movie CG requires huge teams.  You don't get all those details until someone makes them

And all the rest

What else can I add in here.  Well, there's a month or 2 of bug testing.  If you are doing an international game you will have people testing in all languages from all over the world and you will need to give them each a version.  Many of you probably have DVD burners so you are probably aware that making a DVD takes time as just transferring 5 gigs of data over your network to the machines with the burners.

Having versions for playtesting as well.  Playtesting is testing to see if the game is playable.  Maybe you test it and find that no one can figure out how to open that door or that the green key is under the 3rd box on the left and so you have to go back and redesign your game so that people don't get stuck and frustrated.

There's also often a huge hit to your schedule for things like a version to take to E3 or other industry trade shows.  You might need to make versions for the press so they can have their reviews appear the same time your game hits the store shelves.

Now-a-days you might also have to deal with pre-piracy, having the press for example, leak your game to the internet.  Having all that work you see above taken for free by some thieves and so you have to spend more work trying to prevent them.

I'm sure I've forgotten quite a few things but hopefully this gives you some idea of why games take lots of people, years to make, and millions of dollars.