The Drawing Board

  by Logan Everett (E-mail Me)

#3 - The Basics of 3D Games

Okay, it's time for me to stop rambling about random topics and get back to the focus of this site: Games. This week we look at 3D Games, how they work, and what makes them so great. I will use the terminology from this one a lot in future articles, so listen up!

First off we need to discuss how all games work. A game has two main parts, the engine and the data:

  • Game Engine: This is usually represented by the ".exe" file that runs when you play the game. It contains all the rules that make up the game. For example, it might contain a Function (List of commands that process data) that determines whether or not the player has hit an enemy. The engine also communicates with the hardware. It contains functions that place graphics on the screen and send sound to the speakers. Keep in mind that some functions are stored in ".dll" files. We will discuss the purposes of this later (Next week's editorial).
  • Game Data: This includes all graphics, sounds, levels, save files, etc. These can have any number of different file extensions. Sometimes a small amount of game data is put in the ".exe" file, but this is nearly impossible with large amounts of data. The purpose of storing the game data separately is to allow the computer to load only the portions that the game is currently using. For example, let's say a game has 50 levels, and each level is its own ".lvl" file. When you start on Level 1, the computer copies the file "1.lvl" from the hard drive (permanent storage of the computer) to the RAM (temporary storage of the computer), so that the computer can read this data quickly. After you beat Level 1, the computer dumps all that data out of the RAM, and fills the spot with "2.lvl". On the average computer the RAM does not have enough room to hold all 50 level files, so it only holds one at a time.
In other words, the game engine is like a machine. User input and game data go in, a monitor display and sounds come out. Now we can apply this model to 3D games and discuss what parts are necessary for a 3D engine and 3D data.

Usually, the most complex part of a 3D game engine is used just for graphics. 3D objects are recorded in memory as polygons. One polygon represents a single triangle in 3-dimensional space. Therefore it is always 3 coordinates, each having 3 values (x,y,z). You might be thinking "whoa, slow down tough guy, a co-what?" A coordinate is a single point in space. On a 2-dimensional graph, which I'm sure we've all done in high school, each point is represented by a set of numbers like this: {4, 8}. The first number is the x coordinate. In this case the point is 4 units away from the origin or center. You may be wondering "What units are we using? Where's the center? What's the meaning of life?" Well, all of these things are determined by the game engine.

Getting back to what I was originally saying, this point is 4 units away from the origin on the x-axis, or a horizontal line running through the origin. It is also 8 units away from the origin on the y-axis, or a vertical line running through the origin. So, if we combine these two values we have a point that is 4 units over, and 8 units up from the origin. The direct distance (the distance of a line drawn straight from the origin to the point) could be calculated with all sorts of fancy equations called trigonometry. I won't bore you with that, though.


On the left we have a 2D polygon (pretend it is 3D). On the right we put two together and... tada! a square.

In a 3D environment we need a third axis, called the z-axis which measures depth. NOTE: In most 3D games they orient the axis differently, so that X is length, Z is height, and Y is depth. For this setup, just pretend the graph paper is flat on a table, and the Z axis comes up out of the center of it. This adds a third coordinate to our point. If our point becomes {4, 8, 12} then we know that it is also 12 units away straight in front of us. The direct distance to the origin is now really, really complex to figure out, and because of this there is a lot of work that the engine has to do, especially if it processing 5 million polygons each second. Keep in mind that a polygon is 3 points, so we are processing 15 million points a second. But a point is 3 numbers! We are processing 45 million numbers each second, and that's below average for more recent games. The point of processing all this is to calculate how the 3D polygon would look from a certain viewpoint and draw it that way on screen.

However, polygons alone don't make something look realistic. You may have played older games in which each polygon is filled with one color. This is neat for about a few seconds, and then you realize that it looks horrible. Current 3D games use textures. A texture is a 2D image, like the logo at the top of this page. A part of this image is drawn onto a polygon. I say "a part" because the polygon is triangular and the texture is a rectangle so it can never fit exactly. Then the computer calculates how that piece of the texture would look from a certain viewpoint and warps the image to make it look 3D. The most important thing to know is that a texture is a 2D image drawn on the surface of a 3D object. Textures add detail.


The picture on the left has no textures, just bland colors. This technique is called "flat shading" and looks ugly. The one on the right has textures and looks neat.

Now it is time for me to briefly explain how a 3D card works. The 3D card has special sets of RAM and processors to handle all the graphics tasks. First the 3D card is given all the polygons in one portion of RAM. A second portion of RAM gets the textures. The processors then draw the textures onto the polygons and generates a new 2D image, called a frame, that shows how the scene would look from a certain viewpoint. Each frame is the size of the screen and is copied to RAM on the 3D card or video card (if it is a separate piece of hardware). The frames are drawn on the monitor very quickly to create the illusion that you are moving through 3D space.

Now, what kind of data do 3D games use? While exact formats and file types vary, they all fit into 7 general categories:

  • Maps: Simply put, a map is a level. This contains the solid structures (like walls, floor, ceiling, door, etc. - sometimes called brushes) stored as a list of polygons. It also contains references to the other types of data, so the game knows what else it has to load. Brushes are basic 3D shapes made up of anywhere from 10 to 30 polygons. For example, a cube shaped brush has 6 sides or faces. However, each side is square, and our polygons are triangular. To solve this problem, each square is made up of two polygons that are placed side by side so that they look like one flat surface. We are now using 12 polygons for this brush. A pentagonal (5-edged) face would use 3 polygons, a hexagonal (6-edged) face would use 4 polygons and so on. Textures are then assigned to each face and cut up to fit each polygon.
  • Textures: As mentioned before, these are 2D images that go on 3D surfaces. The game usually loads them in small groups, and only loads the groups used in the current map.
  • Models: These are also made up of polygons, but they are more detailed and have more complex animation. An enemy in a game is an example of a model. It is more detailed than its surroundings and can move almost anywhere in the level if it has to (in order to hunt you down, of course). Also, items and weapons are stored as models.
  • Skins: A special type of texture, a skin is designed for a specific model. It is often wrapped around a model, applying small portions to each polygon. Keep in mind, skins are 2D images.
  • Entities: These tell the game how things should behave. They can be associated with brushes, or load models from another file. For example, you might have an entity called "enemy1". It would tell the game how the enemy behaves (should it attack directly, or sneak around?), how strong it is (a weak little soldier, or a major boss?), and what it looks like (what model do I display for this enemy?). On the other hand, an entity associated with a brush would work something like this: Suppose you have an entity called "breakable" and it is linked to one brush that is shaped and textured like a wooden crate. If the player shoots the crate and does enough damage, it breaks.
  • Music and Sound: These are the data files used for background music and sound effects. Last Week we discussed 2 common sound formats.

This is a skin. Each little piece corresponds to a group of polygons. We see the front and back torso as the main pieces. The black background is just to fill in the space.

Now, for an example that encompasses all of what you have learned. Supposed we want to make a map of a room in a house. The walls, floors, and ceiling are all made up of brushes. The simple furniture, such as dresser, desk, and bed are also brushes. The wallpaper, blankets, and wooden patterns are all saved as textures. Not that we would need a separate texture for each visible side of the furniture, one for the ceiling, one texture that can be tiled across the walls, and one for the floor. When a texture is tiled it is repeated more than once, like a tiled floor. The texture itself only holds the image of one tile, but when we cover a floor with them we see a larger, somewhat repetitive image.

         

On the left we see a normal texture designed to be used a certain size brush. On the right we see a texture that could be tiled infinitely on a large floor.

Let's say that there is also a chair in the room. We could make the chair out of brushes, but this would require a lot of small, detailed brushes (and that is bad). The best way to handle detail is with models. The surfaces of the chair would be held in a skin file that is designed to wrap around that particular model. We could even have 2 similar chairs, one green and one blue, by copying the same model and using 2 different skins.

Now we want to have a door that swings open and creaks. First we create a wall that has a doorway in it (using however many brushes it takes, it can be done in 3), and a separate brush for the door. We texture the brush and associate it with an entity that tells the game engine to rotate the brush in a manner similar to the swinging of a real door. The entity also tells the game engine to load "creak.wav" and play it as the door opens.

Next week I will write about game modifications or "MOD's" and completely blur the line I've drawn between the game engine and game data. I will also explain ".dll" files, as promised.


Page Updated: 1/23/00