I was reading this article? Agile Game Development: Dealing with Chaos in the Real World. Unfortunately it's a set of powerpoint slides instead of an actual talk or article so a ton of details are missing. Even reading all the books on the reading list at the end won't answer most questions because the questions we want answered are about game development and those books generally about business custom solution development.

Slam mentioned Clickteam on my Virtools Review page so I checked it out. They are a company that makes various game creation programs. I didn't download any of them but the part I was most impressed with was this detailed tutorial on how to make a boulderdash type of game. It looks like a great tutorial to get started with making games.

I recently decided to try Virtools to prototype my team’s next game and it was one day it hit me: I was actually having fun making games again. Several of my programmer friends have mentioned to me before about how tedious making a game can be. There can easily be 5 to 10 man years of work involved in getting an entire game engine, tools, pipeline, etc, ready. Many of them also played around with web programming, generally for their personal webpage and they mentioned how much fun it was since feedback was immediate. You’d edit a few lines of code, press refresh on the browser and see if the result was what you expected.

Well, that is how I felt while using Virtools. What makes it so cool, so fun, is you are editing the game WHILE IT IS RUNNING! Some companies and middleware have systems were you can edit a few things while the game is running, tweak a few variables, adjust a few links but that’s about as far as they get. In Virtools you can adjust everything INCLUDING THE CODE while the game is running!

The time it really donned on me how cool Virtools is was while I was running the game I added an entire radar system and edited the code for computing the positions of the dots on the radar in real time. My formulas were a little bit off at first so I adjusted them, pressed compile and that function was recompiled WHILE THE GAME WAS RUNNING and the dots on my radar responded immediately until I got it right. This is the power of Virtools!

Testing it out

I’m hoping by now you are thinking about giving Virtools a try. If so I want to give you one piece of advice. Virtools, like Maya, 3D Studio Max and Flash, is a very large very complicated program. You will not install it and be making a game in an hour. For me I decided on the type of game I wanted to make and then I read the entire manual. I’d say all in all it took about 2 weeks for me to get comfortable with it, about the same amount of time as it took me for Max and Maya. Please keep that in mind. Pick a goal, set some time aside and expect it to take a couple of weeks to really get it.

Another issue is that even after that 2 weeks, to make my prototype would probably have taken less than a 1 week but there was time spent in learning the Virtools way of doing things and also its current limitations and workarounds. In other words, expect that it will take a little bit of time for you to grasp how to go about implementing particular ideas in Virtools.

Virtools, what is it?

Virtools is an “Interactive 3D software” editor. In other words is an editor for making interactive 3D software. Think of it as a 3D program like 3D Studio Max or Maya except that as you put objects in the scene you can give them behaviors to follow and that unlike Maya or Max, Virtools is designed to run in real time.

I’ll be honest, in the past I would generally dismiss this kind of software. There have been other products that tried to do this, some over 10 years old that ran on SGI Onyx machines back in the day. Even then they were not very impressive.

What made me sit up and look at Virtools was one of my co−workers, a non−technical game designer had managed to get hold of an evaluation copy of Virtools and convinced management to give him a month to play with it. In that month with no prior programming experience he was able to basically create an entire level for a character action game on his own including making his own graphics (He had previously learned Lightwave).

I’m not just talking about your typical “make a guy walk around a level” demo. There are lots of engines that will let you pop in a walking character and have it walking around in a short amount of time and it will look like you’ve made a lot of progress when in fact you’ve done nothing. No, this designer had his character walking around, he had animals you could hop on and ride, he had 3 or 4 kinds of enemies you could interact with, he had non player characters you could recruit and you could command them to do various things. He had several game setups, cliffs you could climb, moving platforms, all kinds of stuff and he had done all of this without any programming experience in a single month. He even had a PS2 controller connected to his PC and had it displayed on the TV so it felt like a console game and not a PC game.

It was his example that made me want to seriously take a look. Here is what I found

The Interface

Virtools, like many 3D programs, has a paned and tabbed interface that makes it generally easy to get around as there are so many different parts of the program that you’d need a 10 foot by 10 foot screen to display them all at once. Fortunately if you happen to have multiple monitors you can detach any individual display and then drag it to another monitor.

Generally the top left is your 3D view. Here you can place, orient and position objects, cameras, lights etc. The top right is your list of pieces, parts, 2D assets, 3D assets, sounds, logic items, etc. Virtools has resource folders similar to Maya’s scene folders. They represent a tree of folders on your hard drive and are updated in real time. The folders are for your convenience. One for 2D images, one for 3D objects, one for characters, etc. If you put some more assets into your resource folders they will automatically show up in Virtools interface ready to drag and drop into your scene.

The bottom pane is where most detailed editing happens. It is here you can set specific attributes on the various types of items you can put in your scene as well as edit scripts and code. See figure 7 for a short glimpse of some of the various editors.

One step at a time

Virtools has what they call “Building Blocks” or BBs for short. These generally represent small functions or systems that you can insert in your scene.

To give you a simple example if you have a character with animations you can drag it from your resources and drop it in your scene. Then you can go over to the building blocks and find the Character Controller BB, drag and drop it on your character. A dialog will pop up asking you what your walk, run, walk backward, and stand animations are. You select them and click OK. Then drag a Keyboard Controller BB on your character. Press play and you can now walk your character around using the numeric keypad keys.

If you know the interface and you already have your assets you can have a character walking around a level in approximately 30 seconds.

Schematic

Of course that is an extremely simple example designed to get you started. The real power of Virtools lies in its schematic system which is Virtools’ visual scripting language

If you go over to the schematic pane for the last scene you’d see something like figure 2.

Figure 3 is the same thing with the inputs pulled out so you can see them.

When you drop a BB into your scene Virtools automatically generates a schematic for them. Of course you can also directly drag and drop BBs into your schematics.

Each BB is represented by a box, on the top of that box you will see inputs or pIns (parameter In) as Virtools calls them. In the example above the 4 inputs are the 4 animations that represent walk, run, walk backward and stand. A loop BB might have start value, number of iterations and step. You can hover the mouse over any input to see what it is. You can also generally double click on the BB and a dialog letting you edit all the inputs will appear.

Those input values can come from static constants as they do in the above example or they can come from variables. (called local parameters by Virtools) They can also come from the outputs of other BBs.

Some BBs have outputs. Outputs appear on the bottom of the BB’s box. For example the Timer BB has 2 outputs or pOuts as Virtools calls them. One is the elapsed time, the other is the delta time or amount of time since the last loop iteration.  A Timer BB loops for a specified amount of time. Figure 4 is an example of fading the background color from black to yellow over time. The duration of the time is set to 3 seconds.

The dashed lines represent the flow of data. The solid lines represent the flow of execution. The Timer BB loops through the Set Background Color BB which takes a color as its input. The color is computed by dividing the elapsed time output of the Timer BB by the duration giving a value from 0.0 to 1.0, the color we want is then multiplied by that result and finally fed into the Set Background Color BB.

Each BB also has Behavior Ins (bIns) on the left and possibly optional Behavior Outs (bOuts) on the right. For example the timer has 2 bIns and 2 bOuts. One bIn called “In” starts the loop”, One bOut “Loop Out” and one bIn “Loop In” represent the execution flow for the loop of the timer. Finally there is an “Out” bOut that represents the execution flow after the loop has finished

The bIns and bOuts are connected by solid lines and above them are numbers. In the above example they are 0 going from the Timer BB to the Set Background Color BB and 1 from the Set Background Color BB back to the Timer BB. Those numbers represent link delays. For each iteration of the Virtools game engine your schematics will run until each one hits a link delay greater than 0. For any particular script Virtools will check for infinite loops. I think the default is 8000 BBs executed without a link delay although you and adjust that value.

Now, if you are a non programmer, this might all make more sense to you. There is no such thing as variables. There are just inputs and outputs representing how data flows. This is probably one thing that makes a system like this easier for non programmers as they can visually see what is happening. But, for you programmers out there, I’m sure the math in that last example might be making you nuts, putting division and multiplication boxes out there, any slightly complex calculation and it could get really hairy.

VSL: Virtools Scripting Language

Fortunately, Virtools has a solution called VSL or Virtools Scripting Language with which you can make your very own BBs. Let’s change the above example to fade from one color to another. That might be a little too involved using lots of boxes for calculations so we’ll use a Run VSL BB.

First you drop a Run VSL BB into your schematic and rename it to something that makes sense like “Fade Between Colors”. Select it, right click and pick “Edit VSL Script”. Up pops a text editor, on the right is a list of all the bIns, bOuts, pIns and pOuts for your script and you can define more. I’m going to define 4 pIns. duration (float), elapsedTime (float), startColor (color), endColor (color) and one pOut called resultColor (color). Once I’ve done this I can reference those in the code. See figure 5

Now if I go back to the schematic you will see my new BB has 4 inputs and 1 output. All I need to do is connect them as in figure 6. I connected the duration and elapsed time from the Timer BB and I’ve set the startColor and endColors to yellow and cyan respectively. Then I’ve linked the resultColor output of my new BB to the color input of the Set Background Color BB and wala!, I’m fading from yellow to cyan. I can change and edit any of those values while it’s happening as well, the 2 colors and the duration.

If my BB needed to be able to branch or have multiple paths into it I could also add more bIns and bOuts as well.

Those 2 features, the schematic and VSL are what really make Virtools shine. They can be edited in real time while the game is running and that makes it extremely quick to work up some new idea.

C++ plugins

Sometimes you need something more, like maybe you have a physics system you want to implement or a complex character animation system. In that case you can make BBs in C++. Virtools comes with an SDK and you can make whole sets of BBs that fit into a DLL and appear as part of Virtools. In that case the sky is the limit.

In fact, Virtools themselves sell a few of these. One is a Havok based physics integrator. Another is an A.I. pack that gives you access to various A.I. algorithms. There’s also a mutli−player pack for online networked games.

Behavior Graphs

Virtools also allows you to build BBs with other BBs.  You can select any part of a schematic and turn it into what they call a Behavior Graph or BG. They are basically the same as a BB except built out of schematic. You can add pIns and pOuts as well as bIns and bOuts so if you make some particularly useful function or behavior out of BBs you can turn it into a BG and start using it in other places.

Tips

If you are just starting out there are a few things you should know. The biggest issue with Virtools is knowing all the BBs. Think of BBs as your library. Like Perl and Java the libraries are so large it seems impossible to know them all but if you at least skim through them you’re more likely to find a solution than make one up.

One of the coolest and well thought out things about Virtools is that they went through and made all the BBs connect to their corresponding help so you can double click almost any BB in the Building Blocks pane and the help for it will appear. This is especially great if you have two monitors. Just move the help window to your second monitor and you can read the help while you use the BB.

On top of that, almost every BB has a sample scene to show how to use it. The help has a link to the scene which if you click on it will run the scene in the Virtools player. The scene’s source is included so you can load it into Virtools and go inspect the schematics and see how it all works.

Arrays

Virtools has something called Arrays. When I hear the word array I think of an array of integers or an array of characters. But, Virtools arrays are arrays of structures. You can have pretty much any Virtools data type as a column in your array.  For example: animations, cameras, 3D entities, meshes, materials. Remember that, if you need a table of something you can use a Virtools Array. For example an array of monsters: The first column might be a column of strings, the name of each monster. The second column could be the 3D character data needed to display the monster. The 3^rd might be hit points, etc.

Virtools arrays can also be built on the fly and you can add columns on the fly as well so if you need a way to store stuff at runtime that’s one way.

The only disappointing thing about arrays is the columns are referenced by index, not by name. There is a little bit of help with the Get Row BB and Set Row BB which give you inputs or outputs for every column by name but setting or getting individual cells is unfortunately by index. That means adjusting an array can break your scripts and schematics, something that wouldn’t happen in a standard higher level language.

Attributes

Virtools allows you to a ttach attributes to various objects. While Virtools uses this for various options you can use it as a way to pass information to spawned objects. For example if you have an enemy generator when you generate the enemy you could attach some attributes to it and fill them with values that are specific to that enemy.

System BBs vs Functional BBs

Some BBs act like a C++ function. The Set Background Color BB above is an example of this. All it does is set the background color of the scene and exit. Other BBs actually start up parallel processes or systems. An example of one of these is the Character Controller BB. You’ll notice in the schematic above it’s started and then that’s it, there is no program flow following it and no loop to execute it each frame. That’s because that BB represents a system that is running in parallel with your other schematics.

What’s important to know is that that one Character Controller BB represents one and only one instance of a Character Controller system. If you wanted to control 2 characters you’d need two of those boxes, one for each character.

The particle systems are also similar so you could not make a loop that started 6 particle systems using only one particle system BB. The BB represents one and only one particle system.

Initial Conditions

Virtools has this concept of initial conditions. By default, most items don’t have them.  That means if you drop 3d object in your scene, position it, orient it and align it and then run your game and your game logic moves the object, if you did not set initial conditions the position and orientation of the object when you save is the value that’s saved as well as the value used when you restart the game again. To prevent this you select any objects which need initial conditions and select “Set Initial Conditions”.

You can set initial conditions on almost anything, for example a 3D mesh. You wouldn’t normally need initial conditions (IC) on a 3D mesh since most likely you would not adjust the mesh at runtime but if you do adjust it at runtime you’d better save IC on it.

Another example is Arrays. If your arrays are just static data then you don’t need IC on them. If on the other hand, some cells get updated during runtime you might need to save IC on the array. Once you’ve saved IC on an array though, that is the state that will be saved to the file. If you adjust a value and forget to Set the IC again the new values will not be saved.

Saving Pieces

You can save almost anything. For example if you setup an Array, select it, right click it in the Level Manager and pick Save As… and you can save it to a file which can then be loaded into another scene. If some things are used together select all of them together before you save.

Flexibility

Take a look at all the sample BBs. Virtools has examples of using pixel shaders and other technical examples as well has physics examples with the Havok physics pack including the standard simulations and also car simulations making it easy to get started on a vehicle based prototype. Their A. I. pack has a small 3D RTS game where you can drag select multiple characters in 3D and command them around. It’s a great place to get started with an RTS prototype.

In the real world

If I discount the learning curve, I was able to make a prototype for our game in about 8 days. I think that is far faster than I could have done it most other ways.

There were some issues. Virtools’ current character animation system is fairly simplified. I needed to be able to apply multiple animations to a character with full control over the specific frame of each animation I want applied. Virtools didn’t support this yet. I found a kind of hacked workaround but it has serious limitations. If I start prototyping a new game I will have to seriously consider whether or not I should spend the time to write a new character animation system BB. I’m not sure how much time would be involved in that so I hope they will provide a new one soon. They do provide the source code to the current one so it might be a simple matter of going in and adding some pIns for inputs that are not currently exposed.

Another issue is one of updating. Virtools allows you to manually re−import your assets but unfortunately it’s that manual bit that needs to go. In real development most of us are used to putting the new assets into the build and having them just get used, no manual intervention required. I’m sure they are working on that issue. Some of it may have been solved with their Alienbrain integration. Unfortunately I don't have Alienbrain so I didn’t get a chance to check that part out.

The 3D exporters for Max, Maya and Lightwave, while capable have some serious limits to there usefulness for a full production product. For example there is no automated re−export so if you add a node to a character you’ll have to manually re−export each and every animation. As well there is only linear function curve animation (no curves there) or sampled animation. The ideal would be something more like Granny3D that samples first and then generates function curves from the sampled data. Also, there is no way to specify which nodes/joints in a character need animation on a per joint / per animation basis so small secondary animations have to have all that kind of information applied at runtime. I could go on as I have a particular personal button with exporters. See my article on 3D exporters. Fortunately Virtools provides the source code for their exporters so if they don’t step up and provide production ready exporters there is the possibility you can write your own.

Also, as cool as the visual language is it can sometimes be cumbersome. Like I showed before, expressing expressions can get large. While there are workarounds, sometimes your schematics and get pretty large and hairy. You can break them down into BGs kind of like breaking down a large C++ function into multiple smaller functions but ultimately visual editing may not be for everyone. One thing that would help is a better auto formatter. I’m sure it’s a hard problem, but if you want to insert some code and you want to keep your BB understandable you need to select all the stuff to the right and move it. That’s not too big a problem, the bigger issue is that if you move only a few pieces Virtools will automatically reformat some of your links and often it will reformat them so that your schematic is no longer readable at a glance forcing you to manually format your links.

To give you an example there is sample with an oscillating fan. It uses the Sequencer BB but looking at the schematic as in figure 8 it is not at all clear how it’s working until you start dragging the links around and you can see that what made no sense is actually overlapping links. Once you un−overlap them as in figure 9 it will make sense but drag any individual BB and the links will snap back to unreadable and overlapping.

I don’t mean to come down in Virtools. Most of the issues above can be resolved either by adding your own plugin or modifying one that comes with it.

Real Production

I’ll be honest, when I first heard about Virtools I was interested in it for real production more than prototyping. While I can 100% recommend it for prototyping, in my opinion it is unfortunately not ready for real production yet mostly due to the issues above. I know they are working on it. Version 3 adds integration with Alienbrain for supposedly better asset m anagement.

Another big issue would be code re−use and sharing. If you were making a character action game ala Mario and you had one person programming the goombas and another person programming the koopas, as it is now, Virtools has no way I know of to share those behaviors across levels. When they figure out an elegant solution for that issue it will go a long way to making Virtools more than just a prototype or small project tool.

I haven’t gone this far yet but Virtools is designed so that you can replace the renderer. This would allow you to adapt it to some specialized system like a location based system for example. I’ve even heard that Virtools has their runtime engine running on a PS2. I’m sure there are several categories of games that could work there.

The Future

The thing is, it’s clear to me that on the next generation of consoles (Xbox2, PS3, Gamecube2) the systems will be powerful enough that the overhead of using a tool like this will not be the difference between your game performing well or not and in fact it might just be the opposite, if you don’t use a tool like this you might not have the time and flexibility to tweak your gameplay and add all the features to the game that you want so, regardless of whether or not you end up using Virtools I think it’s important for you to take some time to evaluate it and learn what development could be like in the future.

We’ve all seen how easy Flash has made 2D development. Games that used to take months can now be made in Flash in days. Virtools or something like it is set to do the same thing for 3D games. It’s in that vain I recommend you take a look.

Just randomly searching the net I found 3D Game Studio. No idea if it's any good but it looks nice, appearently lots of titles have been created with it. The basic version is only $49 and the pro version is only $450 (if you actually get to the point you need it). Might be a great way for you to get started trying out some game development.

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.<ul>

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.<ul>

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 o f 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 som e 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.<ul>

• 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 sc reens.  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.<ul>

• 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.<ul>

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.<ul>

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 vert ex 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.

Speaking of bad licenses, my buddy said the first time he saw Ratchet from the game Ratchet and Clank he thought it was a B−movie license.

I got e−mail from Tootai about how he once stumbled upon a famicom cartridge in Europe called "Mac Donald Mario". Being an NES cartridge collector he picked it up and found out...

Here's a pretty cool game I stumbled on today called Mutant Storm. Very polished. It's almost like Robotron crossed with Asteroids but with modern graphics. It's awesome if you have a controller with 2 analog sticks. I have this PS2 controller adaptor and it worked perfect! Otherwise I managed to get it playable keyboard only by reconfiguring the controls to AWSD for shooting and UpDownLeftRight for moving. Maybe you can get used to some of the other ways of controlling it. Check it out! 😊

So I'm going to Shibuya today to meet some friends and as I get off the train I am greeted by posters saying something about a Space Invaders exhibit at the 109 building. Well, I've got 30 minutes to kill so I think, "sure, let's check it out". As soon as I get out of the station I see something I've never seen before. There are 3 giant TVs in Shibuya, one of them is 5 stories tall and it's playing Space Invaders live!!!!! It turns out they are running Space Invaders battles on the stage in front of the 109 building and they are displaying it live on 2 of the large TVs in front of the station including the live play by play annoucing from a cute Japanese hostess.

If you are a music game fan you need to check out Gitaroo−Man.