ITC320 Programming in DirectX

This subject was run for the first half of 2002. It combined our previous experience in programming Windows with C/C++ with using DirectX to create high-performance graphical applications, as you would do for games. DirectX is designed to take care of the nitty-gritty of communicating with computer hardware, allowing the programmer to confidently write applications, safe in the knowledge that the finished program be compatible with practically any system.
At least, that's how it's supposed to work. In practice, DirectX is an absolute mongrel to program, though I say that without knowing how difficult it is to program at the actual hardware level, so I suppose it has it's good points... and you can do some darned pretty stuff with it too :)

'SplatMaze' game

Our first assignment for this subject was to write an actual game with DirectX (talk about being thrown in at the deep end!). The game of 'Splatt' was conceived by our lecturers, and we were issued a set of specifications and criteria to follow in writing the game, but were given free reign in regard to the precise details and appearance of the game.

'Splatt' was to be a 2D game. The game world was a maze environment, made up of walls and open ground, and littered with good items ('food'), bad items ('poison'), and kill-you-dead items ('holes'). The maze was to scroll randomly of its own accord, and the player had to navigate a sprite (which became dubbed 'Zippy') through the environment while avoiding getting squashed between the outside border of the screen and a wall, falling down a hole, or dying from eating too much poison; in which case they are 'splatted'. We had to implement such things as having an animated player sprite, indicating death to the player, providing a way to leave the maze, etcetera. AND it was due on the first day back from our mid-term holidays - too bad if I wanted to spend my holidays actually on holiday!

What follows is my interpretation of the 'Splatt' game, named 'SplatMaze' (harking back to the 'Rat Maze' type games I used to play on the Amiga in my childhood). It has some good points and some foibles, but overall I'm quite proud of it and consider it quite an accomplished bit of work.

Click for full-screen image

SplatMaze was programmed during the last two weeks of my holiday period. I spent almost every waking moment of those two weeks working on it, yet even so it still wasn't completely finished come the Monday morning of the due date (in fact it was only finished and submitted electronically about 10 minutes before the midnight deadline!). Still I must've done something right, because I earned 100% in the assignment for it :)

My SplatMaze game has a strong Australian theme to it. You take control of a green-and-gold frill-necked lizard, whom I eventually named 'Rush' (however you can call him whatever you want - I actually have several names for him, although most of those are unprintable here...). Your task is to navigate through the randomly-generated maze environment, collecting the good items while avoiding coming a cropper on any of the hazards, to open the exit and proceed to the next level.

More SplatMaze!
My documention for SplatMaze is quite lengthy, so I've put it all on its own seperate page here. There you'll find notes on installation, playing, and known bugs. There's also a bonus download in the form of a custom level pack, and instructions on how to customise the game with your own levels, animated sprites and other graphics!

SplatMaze - The Early Days

I developed my 'SplatMaze' game over a period of two weeks virtual full-time work. The first week was spent getting something that actually worked - the game engine - while the second was spent implementing all the items and features I needed, drawing new graphics and generally polishing the game.

For those who are interested in how the game looked and played in it's early stages, here is what I had at the end of that first week. This is using the bitmaps provided my lecturers - the sprite is a platypus that had been christened with the name 'Zippy', and the maze is populated with red-and-yellow walls, cans of beans for food, skull-and-crossbones representing poison, and the green things are meant to be holes. Overall it's a toal eyesore, but good for a laugh.

Click for full-screen image

The game 'features' such things as dodgy collision detection, really weird bitmaps (not only do they look funny, some of them are strange sizes to boot!), no maximum limit on the amount of health you can get, no victory conditions (you can't win!), no way to restart (short of quitting and running the program again), and probably a few other quirks that I've forgotten. The maze is generated randomly (as it is in the finished product), but the generator hadn't been tuned at that point so you tend to get mazes that are very difficult to navigate. Collecting the beans gives you a little health (ie more speed), collecting the poison takes a little health off (ie less speed), and the holes slow you down to half your move rate (I felt there were too many of them for it to be fair if each one could insta-kill you).

Overall it's shocking compared to the finished game, but you have to remember that it was still work-in-progress at this point, and I suppose it's not a bad bit of work for being written from the ground up inside of one week.

'Cityscape' 3D-scene

For our second assignment, we delved into the third dimension with Direct3D. The task was to create a 3D city, with features such as different shaped and textured buildings, day/night lighting cycle, a moving vehicle, an imported model file, and so on. A lot of us came up with some very interesting cities - what follows is my interpretation of it.

Click for full-screen image

When the program starts, you will be greeted by a dialog box that lists the keyboard commands and allows you to pick the screen resolution it will run under (yes, I copied this out of my SplatMaze project - gotta love reusable code). If you have a powerful enough system with at least some form of 3D graphics acceleration, you can run the program at very high resolutions with little drop in performance - I tried it at 1600x1200 with 32-bit colour on the uni machines (Pentium 4 1.5GHz with GeForce3 graphics cards) and it ran smoothly without dropping any frames.

My Cityscape program presents a flat world plane some 2000x2000 units in size, with a small, four-block city in the middle. The front two blocks have smallish buildings of different shapes and types, plus a carpark; while the rear two have larger office block type buildings. Parked in the carpark is a model of a 2000 Ford Falcon AU XR8 ute, while roaming around the streets is a rough model of my real-life car, a 1971 Holden HG Monaro coupe. The streets have streetlights along the sides of them, and the whole scene undergoes a day/night lighting cycle - each hour of real time condensed down to one second.

All the models in the program, excluding the Falcon ute, were defined programmatically using DirectX model structures - that means that the texture mapping and vertex coordinates and indices were all typed. For the car, this took me quite some time - it has hundreds of vertices(!), although the task is not as hard as it might sound because it is a symmetrical model, so I only had to define one side and then mirror it for the other. We also had to export a model created in some 3D modelling program as a DirectX .X file, and then load it into our DirectX program. In my case, this was the Falcon ute model, which I'd also created myself using a program called BINedit for the game Monster Truck Madness 2, a few months earlier. So it started out as an MTM2 .bin model, that was exported as a .3ds file using the modelling program Zmodeller, and that was then converted into an .x file with a utility called CONV3DS.

The scene goes through a day/night lighting cycle approximately every 24 seconds. The lighting changes to represent the different times of day, from sunrise to midday to sunset, and then for night as the moon travels over. The streetlights and car's headlights switch on in the evening as the light decreases, and off again in the morning when the light has returned. On slower systems you may experience some slowdown during the night cycle - this is because I used a lot of Direct3D 'spotlights' for my streetlights and for the car's headlight, and these are the most computationally intensive form of lights you can have (as opposed to the other two D3D lights, 'directional' lights [which I used for my sun and moon] and 'point' lights). A decently fast system shouldn't have any problems though. You can turn all the lighting effects off by pressing L.

I'm particularly proud of my car - the pathfinding methods that I developed here were instrumental for my ITC330 assignment. The car wanders around the streets of the city by the use of vector waypoints at all the corners and intersections (pressing M will toggle the display of triangular markers at each waypoint). Initially it follows a preset path around the streets of the city, visiting a series of waypoints in turn. If you don't want it to follow the same route, you can press R to toggle random pathfinding - now it will pick the waypoints it drives to randomly. If you press R again, it will revert back to the preset path and endeavour to get back on that track. I had a little too much fun with this program, even implementing Car Cam! You can press C to be taken on a chaffeur-driven tour around the city streets - to return to the normal world-view, press C again or the Spacebar.