Images of old games and stuff that I never finished, in a vaguely chronological order.
This program loaded a custom "rag-doll description" file and used it to construct a jointed physics object in ODE. A skeletal mesh (stored as a MilkShape3D .MS3D file) could then be used to draw the physics object using OpenGL.
The rag-doll code from this project will eventually be used by Conqore.
SWGL (Spess Gaem)
The original aim of this project was to create a PlayStation 3 game using GNU/Linux via the OtherOS feature. This unfortunately meant that the RSX graphics chip would not be accessible, so I decided to explore exactly how much speed could be obtained from OpenGL when using the Mesa software renderer.
Sadly, the answer to this question is "not a lot" - even with all OpenGL hints set to GL_FASTEST and all textures rendered as GL_NEAREST, my gNewSense PC (Intel Dual Core 1.8GHz CPU and 2GB RAM) took a fair while to draw anything at 640x480 in software mode.
I therefore decided that the best course of action would be to design a game that required very little in the way of graphics and set the game in space, where there would be no walls or floors to render.
Since the PlayStation 3 OtherOS feature is no longer available, there didn't seem to be much point in continuing with this project - though the SIXAXIS controller works fine with standard desktop PC variants of GNU/Linux when plugged into a USB port.
The XGP Project
Similar to Conqore in that it was supposed to be a "proper" game engine. Various mesh types were supported, including Quake .MDL, Quake II .MD2 and Quake III .MD3 "morph" meshes in addition to Doom 3 .MD5mesh "skeletal" meshes. Audio files were stored either as OGG or WAV.
The automatic rag-doll physics generation code for skeletal meshes didn't work very well, which is why my later projects usually define rag-doll information explicitly in a "skeleton description" file. I originally wanted to avoid this, with the idea that a mesh should "just work" when loaded into the game engine. However, the auto-generation code would need to be fairly complex and would often produce suboptimal results.
Some of my earlier game engines (such as Tidal and Surge) attempted to use a custom-made scripting language, which I quickly realised was not a good idea for a project as large and difficult as an FPS engine. Instead, XGP used Lua as a scripting language - mostly because Lua is what Crysis uses. However, I soon realised that this only lead to a different kind of difficulty - I had no real knowledge of Lua, and therefore did not know how best to utilise it for my engine.
This is one of the reasons that Conqore uses Python instead - although I knew nothing about Python when I first decided to try using it, it is a very easy language to pick up for someone who has any previous programming experience.
(I'll write more about this later)
Whilst studying at University, one of my lecturers showed me a simple OpenGL program he'd written in which the user could steer a small car around the world. The program included real-time shadows, which he informed me were implemented via the stencil buffer. Interested, I decided to look up some information on how the stencil buffer worked and how it could be used for shadowing effects in my own projects.
My search eventually lead me to a PDF document entitled "Improving Shadows and Reflections via the Stencil Buffer" by Mark J. Kilgard. It is available here if you are interested in reading it yourself.
Aside from shadows, I discovered that the stencil buffer can be used to achieve a range of different graphical effects, including reflective surfaces. Since implementing stencilled reflections seemed a good deal simpler than stencilled shadow volumes, I decided to work towards those first. The results are illustrated by the image above.
Note: For those who didn't already know, stencilled shadow volumes are used by id Tech 4 games such as Doom 3, Quake 4 and Prey to create the real-time shadowing effects.
The original Areana was written several years ago in Blitz BASIC by a friend of mine called Edd Biddulph. This program was simply a quick demonstration of how the game would look if it were to be reimplemented in C using SDL and OpenGL.
Whilst Areana was an actual, playable game, this demo program was little more than a test map with a player craft to fly around.
A game I started to create in collaboration with a friend. It was based on a local band and each of the three band members could be controlled using either the keyboard and mouse or a joypad. It was never finished because the band in question split up shortly after we began the project.
I was responsible for the programming side of things, with some work on the music, sound effects, modelling and textures. Most of the modelling/skinning work was done by John "Shrek" Stancliffe. Both of us are capable musicians, but we didn't really get far enough to make more than a couple of tracks or so...
The models were fully animated MD2 meshes, capable of running and jumping. The Emo character we used to test enemy AI moved by randomly choosing whether to stand still, walk forward, turn left/right or a combination of these. As a result, they quite often killed themselves by walking off platforms into bottomless pits.
Another one of my many attempts to make a First person Shooter engine. This one featured reflective water, a sort-of-okayish inventory system, animated MD2 meshes and a drop-down console like Quake.
It was ultimately abandoned because (A) the engine coding was suboptimal and (B) I wanted to try using ODE for realistic physics, which would have required restructuring 90% of the existing engine code.
It was sort of cool to be able to build a staircase out of skeletons, AK47 rifles and spinning metal fans, in a Physics Does Not Work That Way kind of way...
Yet another FPS. This one was notable for being the first one in which I was able to load Quake 2 MD2 and Quake 1 MDL meshes. It was also the first project in which I used mip-mapping, by using gluBuild2DMipmaps() rather than the standard OpenGL glTexImage2D() function.
The world was represented by a series of AABB (Box) regions of arbitrary size, similar to Bio Enhanced and Source9 (see below). Actors were also represented as AABB regions, in order to keep collision detection simple.
Aside from the coding being awful (I was still not completely familiar with how "real" C and C++ code should work at the time), I will never release this because it consisted almost entirely of media from other games. Specifically Quake, Quake 2, Deus Ex and a remix of the Hangar music from Doom (which you can find here).
The design plan for HellSphere called for a massive, fully-interactive and explorable world on a similar scale to Morrowind. Unfortunately, I wasn't nearly good enough at programming to accomplish this.
Planatis: World Walker II
A proof of concept, in which you roll a ball around a planet, pressing a button to jump upwards, floating through space until another planet is hit. The "Player" in this was a ball, specifically the MagnaBall sprite from MagnaBall, a Blitz BASIC game written by Edd Biddulph.
The idea was to add time limits and collectable objects. The player would attempt to collect all items before the time limit ran out, being careful not to accidentally jump off into space when aiming for the next planet.
Some people have commented that I must have got the idea for this game from Super Mario Galaxy. The truth is that Super Mario galaxy came out in 2007, and I made this in 2005.
I have no idea why I didn't finish this. The proof-of-concept showed that the game was viable and the addition of timers and bonuses wouldn't have taken very long. Perhaps I'll pick this up again at some point...
Note: There never was a World Walker 1 - I wanted to call the game Planatis, Edd suggested World Walker II, so I called it Planatis: World Walker II.
BACKTRAX was a QBASIC game written by Edd Biddulph a few years ago. This was my attempt at recreating it using SDL and OpenGL.
The goal of BACKTRAX is simple: You must collect all of the gems scattered about the level, but the tile you are standing on turns into a wall every time you move to another square.
I seem to recall that this game was actually finished. I may still have it lying around somewhere. I doubt that the code was very well written, though, so perhaps it's best if it stays buried...
Once again, MagnaBall was a Blitz BASIC game written by Edd Biddulph. However, unlike the other games mentioned above, this game was not actually supposed to be a C remake of Magnaball. Rather, it was just a platform game engine that allowed rotating sprites. I borrowed the MagnaBall image as a placeholder for the player character but never finished the game, so the last version I worked on still uses it.
The last thing I ever did in Dark BASIC Classic before moving on to learn C and C++. Source9 was a simple FPS engine that allowed the player to run, jump and pick up objects in a manner similar to Thief or Deus Ex.
The test level consists of a small "beach" area with a cliff in front of the player and a small cave to their left. In order to climb on to the top of the cliff, the player needs to use the crates found in the cave to construct a small "staircase" and jump their way up.
Notable features included 3D audio (with panning and distance-based volume) and, for the first time in any of my projects, frame-skipping.
Despite the image above showing a gun, there was no code for inflicting damage on enemies. Not that this mattered - there weren't any enemies either.
Bio Enhanced was another, slightly older FPS game that I made in Dark BASIC Classic before moving on to other programming languages. Unlike Source9, which used frame-skipping to keep the overall playing speed consistent, Bio Enhanced had no real way of controlling game speed. Instead, it was capped at 30hz, based on the assumption that the FPS rate was unlikely to drop below this boundary too often.
Despite lacking any levels aside from the "training" area used to test the game, this was probably the most complete Dark BASIC game I made. It included multiple types of enemy, multiple types of gun, moving level objects (platforms, doors, etc) and pushable buttons that activated various things.
Completing the test level simply restarted the test level again, as that was the only possible level that could be warped to for testing purposes. Since this caused all enemies and weapons to reappear, a friend of mine told me that he enjoyed playing Bio Enhanced as a sort of "endurance" game, trying to conserve health and ammo whilst killing enemies to complete the level as many times as possible before dying.
Multi-Player Blast Arena
The original Blast Arena games were created by Edd Biddulph. Later, Matt re-created the Blast Arena Experience in Java and on the Game Boy Advance. This was my contribution to the series, in which I attempted to alter the game-play mechanics so that it would work with two players.
It became a competitive points-scoring race, in which lives were gained for collecting fruit and lives were lost if either player collided with bullet-explosions or the yellow "drones" which bounced around the screen.
You can download Edd's Ultimate Blast Arena here and read the history here.
You can see Matt's Javarena here and Blast Arena Advance here.
An attempt to make a 3D version of Polysquares (by Edd Biddulph) in Dark BASIC Classic. Turned out to be a not very good game
Man With Backpack
The spiritual successor to TwinZ (see below). You play as Man. He has Backpack. You can shoot a ball of unspecified type at slime blobs, ghosts and "evil generators", with the goal being to destroy all generators in the area in order to progress to the next stage.
Both slimes and ghosts could kill the player if they touched them. Slimes could be killed, but ghosts could not. And they moved faster. And they could move through "evil generators" (which acted as walls until they were destroyed).
This was one of my Make-A-Dark-BASIC-Game-In-One-Day projects. While it was actually finished, it wasn't very good.
See the Twinz II page.
There are many other projects not mentioned here, but most of them are either too old/incomplete to be of any interest or just not very exciting to write about.
I sometimes add things to this page, though, if I feel like doing so. Perhaps one day this page will actually be a complete history of my programming career...