Important Note: The current working version of D-Zone can be found at the official page: D-Zone II

Destruction Zone, or D-Zone, is a tank battle game that allows up to three players and up to six robots to fight through rounds and accumulate money and points. The players each shop for new weapons and tools every three rounds. The enormous number of weapons and tools with well balanced prices and properties made the game very addictive. D-Zone became very popular in the early 1990s, back when the fastest PC machine was the Intel 486.

I received over five hundred registrations, mostly from the USA, from enthusiastic D-Zone players. I received an even larger number of letters with wonderful suggestions about what should be included in the next version. I stopped working on the game in 1993.

As computers increased ten-fold and eventually one-hundred-fold in speed, the time came when the game began to run too fast. I could not correct this simple problem because the source code was believed to have been lost for many years.

As I was packing up things in my house to move from Adelaide to Melbourne, I went through all of my old 3.5" diskettes in untouched corners of my cupboards and to my surprise one of the many disks contained a file - s_dzone.zip. A wonderful feeling passed through me, and then as I unzipped the file I found that it was indeed the entire source code (version 1.3 of the game).

- Julian Cochran

A much better approach is to load only one copy of each polygon model and then re-use that model as many times as required within the same scene. This involves having a ModerlLoader that makes sure only one copy of each model is used at a time, and models that are not used are removed from memory. A language like Java will typically do that for you even if you don't try, however I like to create a ModelLoader class through which all references to the 3D objects are made.

I added a data structure layer called ModelPosition which is light-weight class that only hold a reference to a Model and the Model's orientation and position. Thus the asteroid scene may involve only one Model object but 50 different ModelPosition objects.

While the ModelPosition objects take up almost no memory, the Model objects contain all the polygon information and require a great deal of memory. While the game player may see hundreds of models out there in space there may only be a few models in memory and they are just re-applied with various rotations and transpositions.

The rendering process involves (1) looping through all of the ModelPosition objectsm, (2) for each ModelPosition, calculating an orientation matrix M by multiplying the inverse of the camera's orientation by the ModelPosition's orientation, (3) calculating the transposition vector T by subtracting the camera's transposition by the ModelPosition's transposition, (4) looping through all polygons in the ModelPosition's Model and performing the rotation M and transposition T on the polygon, (5) rendering the polygon to the screen by ignoring the z co-ordinate (orthogonal projection) or dividing by the z co-ordinate (perspective projection).

If you want to make a game addictive you are going to have to make sure the way objects collide is very accurate. A game could be absolutely brilliant in all respects except collision detection, and the end result is that the game is almost guaranteed to be a complete failure. Likewise, the most simple game such as ping-pong could still be somewhat addictive if the collision detection is very accurate. I think that part of the reason that the original D-Zone was popular was because the collision detection was done at the pixel level. It was very much as case of what you see is what you get.

We will assume that we know how to take two 3D polygons and calculate whether they cross over each other in 3D space. In theory we simple want to look at all polygons in our scene and compare them with all other polygons to see if they intersect. If any polygon collision is detected then the object that the polygon belongs to has it's collision method called, which may destroy the object or cause it to stop, or whatever is appropriate.

In practice this approach is far too slow. If there are 10,000 polygons involved in the scene then there are 10,000 ^2 = 100 million polygon collision calculations to perform.

The first thing to do that is fairly obvious, is to make sure polygons are not checked with polygons that belong to the same object. In other words, only compare polygons if they belong to different objects.

The second thing to do is to only compare polygons across objects A and B if these objects are very close to each other. This produces a radical decrease in the number of polygon collision checks that are involved, and the process can be implemented reliably. When the model is loaded into memory for the first time, a calculation is done for each vertex to determine the distance to the object's center, and the longest distance is recorded as 'maximumRadius'. The collision detection then begins by chosing only pairs of objects that have their centers separated by less than the sum of the two maximumRadius values of each object. In a typical scene involving objects floating around space, this means that absolutely no polygon intersection calculations are generally performed. If two objects become very close then the polygon intersection calculations begin.

I would be satisfied to end here, however if you have models that involve more than a few thousand polygons then you can speed the collision detection process to any further extent you wish by simply creating 'Ghost Models' for each model that are as close as possible to the original model but involving much fewer polygons. This could be anything from box-like ghosts that give poor but extremely fast collision detection, to almost identical copies of the model with minor detail removed that doesn't relate at all to the model's shape.

In D-Zone II, I am using three levels of collision detection. I wrote a very useful method that takes two models and says whether or not they are intersecting, and that method is used for every collision detection test within the game, because I am only dealing with models. If I want to test whether a single polygon is intersecting another model then I will still convert that polygon to a formal model and then use the same method because it is the fastest way. The method begins by performing the first 'maximum radius' test described above. If this test succeeds then we know that the models are not intersecting, so we end here. If it fails then we go onto the next level which is to actually project the polygons in the model into physical space and calculate the xMin, xMax, yMin, yMax, zMin, zMan values and perform six 'if' statements to see if the models lie outside of each other. If this tests succeeds then the models are not intersecting and we can end here, otherwise we have to go onto the third test which is to perform polygon collision detection tests between each polygon. The models have to be very close to each other for this to actually happen - generally the first two very fast test always succeed and then the polygon level detection kicks in when objects are scraping past each other. Avoiding long shaped objects also reduces the number of polygon collision tests.

When saving each model, I am saving multiple detail versions of itself and when the model is rendered the appropriate level of detail is automatically selected based on the ideal average polygon area that should be rendered. The ideal average polygon area is whatever polygon area takes up just a few pixels on the screen based on the camera and the model's position space. You should finally save a 'ghost' version of the model that is the version used for collision detection.

This summarizes a simple and practical approach for dealing with collision detection in 3D games and simulations. The approach works well for any sort of game set in 3D space, from flight simulators to first person combat games to sports simulations, and the method is intuitive and quite easy to implement. Please contact me if you would like to have code that performs these various tests.

In D-Zone 1.0 I just used simple lines to represent each tank. The lines were not even anti-aliased, but it didn't matter because it was enough to inform the player about where the tank was and the shape of the tank. It was also very easy to tell which direction the tank was facing. As far as game-play is concerned that is all you really need, and the real-life appearance of the tank is left to the imagination. of the player.

For D-Zone 2.0 I built a polygon modeler called JCad to handle all of the graphics which is now available for download at www.digitalscores.com/jcsoftware. The reason I built a polygon modeler from scratch was because I wanted to support various features such as spacial-antialiasing and semi-transparent polygons. I also wanted to use the same lighting model that I would use in the game. I wanted to create the graphics with the same tools that would view the game, thus making everything look as inspiring as possible.

These models can be created very easily using JCad. The Geometry window allows you to create the three spheres (superellipsoids) and then three cyclinders can be created and rotated and moved into the correct positions between the three spheres. You can then select rows of polygons by holding CTRL and dragging the mouse across the polygons you want to select, and then use the Polygon Properties window to adjust the color and alpha transparancy of various rows.

JCad produces high quality scenes because true anti-aliasing with gamma correction is a standard feature. The D-Zone game will use exactly the same rendering code. This code can also be licensed if you want to have a jump start with your own projects.

The images above show one of many D-Zone 2.0 battle scenes. The scene in which the tanks battle will vary and as with the original D-Zone the obstacles will be randomly generated. Other scenes will include a space stations, enormous asteroids with embedded playfields and more futuristic playfields such as the one shown above. I am certain that the tanks are going to change considerably from these images, but as with my very original vision the top half of the tanks will glow slightly depending on how much weapon fuel they have remaining.

The images above show the camera directly above the tanks with base platform variations. I would like the camera to float inwards and outwards such that all of the tanks remain within the scene. None of these scenes show any obstacles within the playfield. Obstacles will be created on the fly within the application so that they can be constructed randomly, and walls can be joined together properly. The background scene can involve a relatively large number of polygons because it is not involved in any of the collision detection calculations.

Designing a game by yourself involves distinct skills, or modes of thinking, and you need to be good at all of them:

Vision        Design       Coding Attack Plan       Coding

These descriptions do not describe phases, but modes of thinking. If it was a typical business project then the 'Vision' mode of thinking would be replaced with 'Requirements Phase' and would generally be entered only at the start of the project before the contract is signed. But you are creating our own requirements and you will continuously revisit your 'Vision' mode of thinking and this is most likely the most inspiring part of building your computer game.

If you are not inspired by your Vision, then forget about it. The project is already over. If you have a very inspiring vision then this will continue to be a powerful driving force for all other aspects of the project further down the chain.

While everyone works a bit differently, these four modes of development can be summarized with the following table. The have not been put forward as a theory but are simply the report of how I have worked the most successfully and what actually happened.

             Look-ahead Period    Proportion  Work With              Iterate With
                                  of Total
                                  Time  
_______________________________________________________________________________________

Vision       Entire Project       25%         Grand Plan document    Design
                                              Outline of Phases

Design       About one week       25%         Diagrams and notes     Vision,
                                              Order Of Events        Coding Attack Plan
      
Coding       About two days       15%         To-do list (Pen and    Design, Coding
Attack Plan                                   paper or text file)

Coding       A few minutes        35%         Programming language   Coding Attack Plan
                                              Testing
_______________________________________________________________________________________