It's important to realize that this game (actually, any game) does not "need" to be rendered as a fully 3D world. Considering that your monitor is most likely a rectangular flat plane, even your fancy 3D rendered images will be displayed on a 2D plane. It would be entirely possible to create a set of 2D sprites that cover every possible scenario that would need to be displayed in your world, but the art assets required for something like this would be enormous. Look at this experiment as an example.
Assuming you have the DirectX SDK Summer 2004 Update installed, load the DirectX Sample Browser and make sure the Managed option is the only item checked on the left. Click the Direct3D heading, scroll down to find the Empty Project item, and click the Install Project link, following the steps of the wizard (naming the project "Teapot"). Once the project has been created, load it into the IDE.
This will create a new "empty" project. (It actually renders some user interface controls, but for now, those can be ignored.) However, there isn't anything 3D in this project yet, and because the point of this exercise is to show why you'd want to write 3D games, it might be a good idea to add some now.
You'll need to add a few lines to this project to make it render a slowly spinning teapot. You'll be adding a few lines of code to make this application do the rendering, although for this chapter the explanations of what exactly is going on will be skipped. There will be plenty of time throughout the rest of the book for these explanations, but they are not necessary for this demonstration. Assuming you named the project "Teapot," open up the code file teapot.cs and add these two variables to the class file:
private Mesh teapotMesh = null; // Mesh for rendering the teapot
private Material teapotMaterial; // Material for rendering the teapot
Now you'll want to create the teapot and material you'll be using to render the scene, so find the OnCreateDevice method in this class and add the following code to the end of the method:
// Create the teapot mesh and material
teapotMesh = Mesh.Teapot(device);
teapotMaterial = new Material();
teapotMaterial.DiffuseColor = new ColorValue(1.0f, 1.0f, 1.0f, 1.0f);
To make the teapot look better, you'll want to have a light (these will be explained in much greater detail later), so for now, find the OnResetDevice method in your class and add this code to the end of it:
// Setup lights
device.Lights[0].DiffuseColor = new ColorValue(1.0f, 1.0f, 1.0f, 1.0f);
device.Lights[0].Direction = new Vector3(0,-1,0);
device.Lights[0].Type = LightType.Directional;
device.Lights[0].Enabled = true;
You're just about ready now. Find the OnFrameRender method in your class and add this code directly following the BeginScene call:
device.Transform.View = camera.ViewMatrix;
device.Transform.Projection = camera.ProjectionMatrix;
device.Transform.World = Matrix.RotationX((float)appTime);
device.Material = teapotMaterial;
teapotMesh.DrawSubset(0);
Running this application renders a teapot. Teapots have quite a storied history in the world of 3D rendering. One of the first "free" models available for rendering was a teapot, and considering that back then the complex modeling packages that we have today didn't exist, creating an actual 3D model was complicated. Anything free was welcomed. The teapot also has plenty of properties that make it an excellent test model: it has curved surfaces, can shadow itself, and is recognized easily.
As the application runs, watch as the teapot rotates slowly. It's important to realize that the only media required for this application is the teapot model. No media is actually required for this model because you used a method in the Mesh class (which will be discussed in a subsequent chapter) that created the teapot for you. So, you get a nice looking teapot at a minimal media cost.
Now let's compare this to rendering a teapot in the 2D world. Create a new project using the DirectX wizard once more.
If you install the code found on the included CD, you'll notice a media folder that actually contains all the media for every example you will be writing during the course of this book. One of the pieces of media you will notice is the 2dteapot.bmp file, which is an example of what you'd need to render your teapot in a 2D environment. The biggest difference between the 2D and 3D world is the media requirements. The bitmap is currently only showing one view of the teapot, whereas the 3D version can show the teapot from any angle. To show this teapot at any angle in the 2D version, you would need a separate piece of media for each position the teapot can be in. Imagine that you need one image of the teapot for each degree of rotation (360 total images). Now imagine that you want to rotate the teapot around any axis (X, Y, Z). You'll need a whopping 46,656,000 different images of the teapot. Imagine a graphically intensive game such as Unreal Tournament rendered with nothing but 2D sprites. You would need entire DVDs-worth of content, and an army of artists would take years to create something that massive.
If you have an artist capable of creating highly detailed 3D models, you obviously have much more freedom in the scenes you can create with much more "limited" media. A single model can be rendered in so many ways, with various lighting, scaling, positions, rotations, that it is so impractical to create this artwork in 2D, it is essentially impossible to do. This power doesn't come free, though.
The freedom that the 3D applications bring takes quite a bit of processing power, so much so that an entire industry has been formed based on providing it. Although there are quite a few companies in the business, the clear leaders as of this writing are nVidia and ATI. There have been so many innovations in graphics cards recently that they are even evolving quicker and becoming faster than the more generalized CPU.
Modern cards (cards that are DirectX 9-compliant, meaning they have support for at least shader model 2.0) are capable of rendering millions of triangles per second. Don't worry; shaders will be discussed later in this book. If you are wondering where triangles came from, it should be mentioned that they are the basic polygon used to create a 3D model.
So, does this game need to be written in 3D? Of course not, you could write it entirely with sprites and without rendering any 3D content, but what's the fun in that? The majority of "teach yourself"-type game development books always cover rendering 2D content, and very few concentrate on the 3D worlds that make today's games great. Although 2D game development hasn't died yet (and may never completely die), if you are in the market for a development job in the games industry, you must have 3D experience.
The Specification
With much of the busywork out of the way, you can start working on one of the most important sections of the gamethe specification. I cannot stress enough the need for you to spend time thinking about the problems you need to solve before you write a single line of code. Virtually every budding game developer I know has started the first game by jumping in and writing some code. You'll only be making more work for yourself later when you realize your quick working solution doesn't quite work the way you intended.
So for this game, what problems need to be solved?
A common way to display development specifications is with UML (unified modeling language).
Fancy diagrams aside, what really needs to be done for the game? You will obviously need to have a central area where everything is controlled. In this case, it will be the game engine. If you notice in the UML, the game engine will also maintain the graphics rendering device and code as well (which is implied through the InitializeGraphics method). The major things the game engine needs to know are:
* The player object
* The current level
* Is the game over?
* If so, has the player won the level?
* If so, has the player won the game?
The game engine will also need to store other information, such as the rendering device, plus maintain the game's objects, but these will occur in private methods and are not shown in the UML from Figure 2.5. The next object is the player, which is actually quite simple. The only information needed for the player is the position it's currently in, and the capability to render itself in the scene. In our game engine, the player is really more of an abstract concept than a development object. The object here is mainly used to control how the player is shown visually.
Everything else in the game engine comes from the levels object. In reality, this object is quite simple as well, because it just maintains a few other objects, notably the blocks collection. Each block maintains all of the information needed to control itself within the level, including the list of possible colors, and whether the colors will roll over.
With the basic specification out of the way, it's time to start coding. You can rest assured that most likely the specification will change slightly between now and the completion of the game, but this gives you a perfect opportunity to start writing some code.
|
