of creating a game? Probably sounds like a stupid question but heres my story in a nutshell, I've been working on pc's for about 15 yrs, customizing, building etc etc..but I'm mainly a hardware guy and I never really messed with software until recently. I just started learning python, C# and C++, downloaded XNA and did the 2d and started the 3d tutorials. I kind of understand the basic concept of how everything works together but i'm wondering if someone could explain a little more. for instance take a game like WoW, I know it takes a huge team to create something like that but stripped down to basics what is the process of developing something like that? I'm just not really sure how the constant changing backgrounds, other chars, enemys etc...work from the code. Does that make sense? then on top of that you have music, sound fx and everything else going on in the game. would someone care to elaborate kind of like if you were explaining it to someone who has never built a game before. I'm honestly blown away by some of the things I've seen done in games in recent years, I go way back to the days of pong and atari 2600.

You are opening a huge can of worms. =)

I am by no means an expert, but I did work as a programmer for a game developer (not a very good one) for a little over two and a half years. I can tell you what I've gleaned from that experience, but keep in mind that it's just one outlook from a newbie programmer.

A team that makes a game will be divided into a few different disciplines, which include programmers, artists, designers, QA testers, sound effects & composition, and management. Most of these disciplines are self-explanatory, but I'll give a quick rundown anyway.

Artists include concept artists, level artists, character artists, and animators. Sometimes, you have artists that do nothing but textures. You also often have technical artists, which sort of act as liaisons between the programming staff and the art staff. They may also write some small scripts and programs to help the artists streamline their work flow.

Designers are the idea people. However, they usually don't just sit in a room coming up with ideas. They also have to help implement those ideas by writing scripts. More on that later.

The sound guys do all of the sound work, of course.

Managers decide what games get made, and how the projects are scheduled.

The programming team is responsible for tying everything together and make it all work in the form of a functioning game. Just as there are many jobs within the art discipline, there are many functions that programmers need to carry out. Usually, the game is divided into at least two layers: the game-specific code, and the underlying game engine or common libraries (i.e., the reusable code for basic stuff like rendering and audio, that all games use). There is also a suite of tools that need to be programmed: tools for exporting art data from programs like Maya and Max, for exporting sound data, and for designers to use for scripting.

I'm going to talk a lot more about the programming of it, because it sounds like you are interested in how a large game is coded.

Typically, from what I can tell with my limited experience, the game is not hard-coded to know what levels are going to be in the game, or what game objects (players, enemies, power-ups, lights, cameras, etc.) are going to be in those levels, or what assets (meshes, textures, animations, sound effects, etc.) those game objects will need. All of this information comes from external data files.

For instance, you usually have some sort of level description file, one per level, that has a lot of the above information in it. The game reads the level description file, loads all of the necessary art and sound assets, and loads the game objects, and then lets the level run.

The game objects themselves are often created, using some sort of scripting language, by the level designers. It could by Python, it could by Lua, or it could be some custom thing. At our company, we created a point-and-click interface in order to do this. There was a build of the game that they could play on the PC, and at any time during the playing of the game, they could hit a certain button, and the game would pause, and a whole bunch of dialog windows would pop up, allowing them to create new objects, drop them into the scene, move them around, and set their attributes. For instance, if they wanted to make a new enemy (call it a "Destroyer"), there would be a button for that, and when they clicked on the new enemy, they'd see a widget that they could use to move and rotate the enemy and place him in position. Then, there'd be a property sheet that they could use to set attributes like HP, ammo, etc. Then, they'd hit "Save", and the object itself would write out to a file, and that file would basically just contain information saying, "I'm a Destroyer. I am at this position, and I am oriented thusly, and my HP is this, and my ammo is that, and I'm using this mesh, and this animation library, etc." Of course, it wouldn't be in plain English like this, but you get the idea.

The game code itself is responsible for the low-level behavior of these objects. For instance, with the above example, there would typically have to be a Destroyer class of some kind. It will contain all the code defining how a Destroyer enemy behaves. When the game is loading the objects, it will come across the above file we created, it will see that it is for a Destroyer, and so it will instantiate an object of the Destroyer class, passing in all the info about its HP and stuff.

Now, as you are probably aware, games run in a loop. Input is taken & processed, objects are updated, and then a frame is rendered, and then the loop starts all over again.

Well, here's what happens. The scene that is currently loaded has a list of it's objects, right? Well, each object will have an update method, and so the first step is to call the update method of each of the objects in the scene. During this step, you can do pretty much anything you want, depending on the object. If it's an object that is controlled by the player, for instance, then it will check to see if any buttons have been pressed. It may respond to those button pressed by changing its state or its velocity. If the object has velocity, it will update its position. If the object is collidible, it may check to see if it has collided with any other objects in the scene. If it has, it may respond to that collision (for instance, if it collided with a bullet, it may respond by reducing its own HP). This is called the "Update Step" or the "Update Loop".

After that is done, and all of the objects are updated and in their new positions and in their new states and all that, its time to draw the frame. However, before anything is actually drawn to the screen, the game will typically compile a huge list of everything that needs to be drawn. This is often called a Render List. It does this because often times it is efficient to sort the list a certain way and render the items in that order. For example, its often expensive to change what texture you are using, so if you sort the list by texture, you'll get more efficient results. Because of z-buffering, there is no need to sort by distance. However, an exception to this is with objects that have transparency -- those objects must be drawn from back to front. So, you can see why it is important to compile a list of objects to be drawn first, and then sort them how you need to, and THEN draw them.

Also, keep in mind that there may be more than one list. If you are playing a 4-player split-screen game, then there will be 4 view ports on the screen, each of which could be displaying the same object. So, typically, you will create a separate render list for each of these view ports (one per active camera is a good rule of thumb).

So there is this pre-render step, which I'll just call the "Render List" step. Each game object class will typically have an AddToList method, or something like that. So, you call this method for each object once per list, passing the correct list to the function, so that the game object can decide if it needs to add anything to that list or not (it may decide not to if the object is not a visual object, or if the object isn't in the view of the camera associated with that list).

So, once all of the objects have had an opportunity to add stuff (meshes, or whatever) to each of the Render Lists, the Render Lists are sorted like I mentioned, and then they are actually rendered to the screen.

Hope this helps.

Wow, that was a great response. thanks, that helps. I was really curious as to how everything works together. just the thought of having a character being able to moves pretty much anywhere in a 360 degree ares and see all those areas from a dozen different angles is just mind blowing to me. I was playing God of war on the PS2 last night and started really thinking about how everything works together
and it just amazes me for some reason

I guess things will start to make more sense as I get more into it, thanks again for the reply

writing up a few games with python and say pygame would be a great idea. its such a clean little setup for developing games. you would gain tons of experience just fooling around with it.

Quote:Original post by Myforumnamewastaken I feel like i'm pointed in the right direction but the idea of me leading teams(even if the teams consist of 1 person each) end in the teams laughing at me due to my lack of know-how amongst other things.

I think there's a common misconception that designers "make the game", and hence are in charge. As far as I'm aware designers work alongside artists and programmers, and have no authority over them. I think part of this stems from the "My Idea -> My Game" mentality.

If you're not the producer (sitting above tech, art, and design directors), and you're not bankrolling the game, you don't really have any authority.

I've seen a few projects ruined by megalomaniac designers being completley inflexible and demanding that programmers and artists do what the designer wants.