DZone (a.k.a. Destruction Zone)

0421 832 266 | Email | My résumé | Maths Department, University of Adelaide


About D-Zone

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



Run D-Zone (1992)
D-Zone 1.3. UnZip the game to any directory and run the SETUP.EXE programme before running the file titled "Dzone With Slowdown.bat". This will slow the CPU speed just for D-Zone so that the game is playable. You may also need to run and change the DOS window to full-screen mode by pressing ALT-ENTER.


D-Zone v2.0 (2002)
D-Zone 1.3 was written as much as ten years ago. How should D-Zone v2.0 be written so that it is very impressive today while maintaining the soul and pure fun of the original? My aim is to maintain the original vision of the first game and implement it how I would really have liked to ten years ago if I then had the technology available. I also want to make sure the game is very scalable so I can upgrade the graphics over the years, adding exciting new weapons, robots and playfields, and making sure the game works reliably across the popular systems of tomorrow.

I have received quite a large response from this website with D-Zone enthusiasts asking when the next version of the game will be released.

This alone has encouraged me to significantly upscale the design of the new D-Zone. The same game play and even the same weapons will be there but the graphics, new interfaces and intergalactic scoreboard are going to make the game even more engaging. A positive feature of the original game was how intelligent the robots behaved, or at least that was true back in 1992. Well, actually they were literally very much like insects with invisible feelers and I have some ideas to make them more challenging in D-Zone 2.0.

I will be using the graphics engine that I built within the real-time modeler last year, now presented at D-Zone v2.0 will be available for PC compatibles, Mac OS-X, Linux and Solaris.


The Making of D-Zone II: Dealing with Multiple Objects in 3D
In this section we assume that we have the code that takes a collection of Polygons and renders them to the screen using perspective projection. We will also assume that we ahve tackled the concepts of clipping and anti-aliasing so that we have the level of professionalism.

We must now deal with the problem of working with multiple objects within our game. It is one thing to represent a single asteroid made up of 10,000 polygons, but what if you want to represent 50 such asteroids in front of the camera?

The trivial approach is to simply copy all of polygons of all of the models (in this case asteroids) into the studio to be effectively rendered as a single model. This is an intuitive approach because we are literally laying out all of the polygons involved right in front of us and rendering them on by one. The problem is that it is going to take up far too much memory. 50 asteroids with 10,000 polygons each is going to require a collection of 50 * 10,000 = 500,000 polygons to be held in memory all at once, each with its own position and color. Forget that.

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



The Making of D-Zone II: Simple Collision Detection

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.

With D-Zone v2.0 my philosphy is to favour code simplicity and game-play accuracy over speed optimization, so I'll probably skip the concept of Ghost Models completely, but perform maximumRadius calculations. That way I am again guaranteed that what you see is what you get and the project's production time can be decreased.

Finally, all objects that are being rendered should be marked as either SOLID or PASSABLE such that polygons that belong to a PASSABLE object are excluded from your collision detection algorithm. Only large objects need to be marked in this way because small objects will automatically be ignored owing to the maximumRadius calcaulation. Examples of large objects that should be marked as PASSABLE include the atmosphere for planets in a space simulator or clouds in a flight simulator, large objects that you can look at through the window of a building, or the background scene outside the playing field of a sports game. D-Zone v2.0 will involve space stations on which the game is played, and the entire space station can be marked as a single PASSABLE object.

This summarizes a simple and practical approach for dealing with collision detection in 3D games and simulations. The approach works acceptably 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.



The Making of D-Zone II: Tank Modeling

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



Writing a Game by Yourself
If someone tells you that you can't write a game by yourself because you can never compete with larger groups of programmers working under a budget, then don't even begin to be put off. People write books on their own, and distributing a book is much harder than distributing a game and the competition with book writing is much larger because so many are written each day. But there are always room for books on unique subjects and there are always room for computer games that the larger groups cannot consider there to be a market for, or fail to have the imagination to be the first to support such a game. With this said, the tremendous challenge for the private game developer is to finish something. For every 100 game projects that start, I have not done any statistical tests, but I am pretty sure less than 5 will be finished. The profound consequence is that you maintain your vision as closely as possible but plan for the game to be more well defined and smaller in scale. You can always add to it later.

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

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
There are a few interesting things to point out from this. First of all only about one third of the total time is with coding. This means that the other 65% of the time you are not sitting in front of computer programming but working with pen and paper or typing documents. Along with the Coding Attack Plan, the Coding consumes about half of your project time while the Vision and Design consumes the other half.

The Grand Plan document describes the project from a perspective that any reader would understand - it doesn't focus on technical aspects, although technical notes can be added where appropriate if you worry they may be forgotton or if they are instrumental to your overall goals. The Grand Plan document requires a lot of attention at the start of the project. During the project you should have a lot of paper with diagrams - these are your Coding Attack Plans, and you throw them away when you have implemented the code.

The Look-ahead Period refers to amount of work you are looking at in Coding time and the Iterate With column refers to the modes of thinking that are most closely connected. If you try to jump straight from Vision to Coding then you will be in a mess and looking at the screen while moving the mouse around in circles like an idiot. Likewise you should avoid moving from Design straight to Coding because you will actually lose concentration much more easily if you do not have have a clear 'To-do' list that keeps you focussed.

You want to minimize your time in front of the computer by researching or creating your approaches (solutions and algorithms) and then treating the actual rather like war - that is, making it as short as possible, because by the end of the project you may be extremely exhausted and risk becoming disillusioned from the amount of programming that is required.

While in the Vision mode you will think about all aspects of the project. When you are day-dreaming bored of programming and letting your mind drift but still thinking about the game, then it is likely you are in the Vision mode. All this time counts and is far from time-wasting.

For much of this time you will be writing your 'Grand Plan' for the game. If you do not find this part very interesting then you are probably going to write a boring game and should stop here. While in the Vision mode of thinking you will be reviewing other questions that are broad in scope, such as: What it is the game going to look like? What are the emotions you are going to feel while playing the game? Have you decided upon the language to use to write the game, and what are the pros and cons of this language versus the alternatives? Do you think the game is going to work in 10 years with minimal adjustments? Do you want it to work then? In what way you think you will be rewarded - why are you writing this game anyway? Is the game for your pleasure and satisfaction in seeing others enjoy it, is it a learning exercise, do you have a commercial model involved at some level, or some mixture of these three? Will there be any support materials such as a discussion forum or a website? Will there be documentation? Have you factored the time that it takes to do all of that into your project? Do you really think people are going to want to play your game? Do you care? Are you writing it only for your own enjoyment? How can you make the game more fun to play? Do you have the time to implement your entire 'Grand Plan'? If not then can this plan be broken into smaller deliverable steps? Could you add this or that idea?

These are the sort of questions that you will ask while in the Vision mode of thinking, and the answers will be elaborate and you will always drive back to game design. Your vision should be as exquisite as possible from all angles of game design.

Here you will be working with pen and paper and mapping out how you are going to solve a problem that you have defined. Clearly defining a problem to solve can take just as much time as solving it. You should start by writing many questions down such as "How are the lasers going to be represented?", "Am I going to support shadows in this particular scenario?", "Is this window going to need to have the text contents scrollable?".

As a example, you might have decided that you are going to implement your own graphic user interface from scratch as part of your vision, and you have defined that this is going to be the first major phase of the project. You can then use this interface for future projects also and that was part of your Vision. In order to enter Design mode you need to forget about the big picture and work out how you are going to acheive this goal. Because it is such a large goal you have to break the problem down into smaller and smaller steps. Your pattern of thoughts might be: "First I want to be able to display windows in arbitrary positions, and I will leave the interface controls until later". "To do this the basic technical requirements are to be able to draw a pixel, for which I will extend to draw the entire windows, and to be able to respond to mouse events. I'll have to do some code experimentation to make sure I can do these simple things, and then I can return to the design phase again". By necessity you have broken your design down to a very simple step which will require a Coding Action Plan and some period of Coding.

With more complex problems, the art of breaking the problem down to simpler steps may require research or challenging problem solving within the design work. For example, the problem of rendering a 3D model made of polygons will require you to think about data organization for the model, to understand clearly the concepts involved with perspective projections and possibly to create an algorithm for drawing a triangle on the screen quickly. This research and problem solving takes a lot of time but it has very little to do with coding.

Don't let anything intimidate you. Progrmaming requires a bit of bravery. If you are designing an approach to render a 3D model and you have never done this before then be prepared to do some research over the internet. Also try to work things out yourself and then read about how other people are doing the same thing. There is no better way to learn than try to think of the solution yourself, and this will make reading someone else's explanation much easier to understand, not to mention more enjoyable.

Coding Action Plan
Coding Action Plan is the link between the design and the coding. This takes up as much as 15% of the entire project because it is more than just a to-do list. It involves a clarification via detailed written instructions what you are going to do and how you are going to do it. It will often include pseudo code for algorithms that you actually worked out. But unlike the Coding frame of mind, you are away from the computer and thinking in quite a different, somewhat more imaginative way. You don't care about syntax errors and you are really focussed on clear design. The Design mode of thinking involved almost 100% imagination but when you write the Coding Action Plan you need be very pragmatic and end up with fixed and clear instructions in the specific order that you will code them. At the end of writing a Coding Action Plan you should be bursting with energy to go straight to the computer to actually get something happening.

You might be in your comfort zone while in front of the computer. However if you are driving the whole project yourself then minimize the amount of time you are spending in this phase. If time is passing and you are not getting very much done then it is likely that your brain wishes to be in a different mode. Go back to the Coding Action Plan and work on paper for some time. If you do not have new designs that you are excited to implement then you need to go back to the Design mode, and if you can't find any designs then move into Vision mode. There you will always find something you need to design.

This summarizes the different modes of thinking required to write a computer game entirely by yourself. If you are stuck and you want help then I am available for moral support or technical assistance. I can always be contacted at


Updated 13 October 2002.