This is my biggest and longest running personal project. It is probably too big. It's a cross platform (Windows and Linux)
game about semi-autonomous programmable spaceships. Most of the game logic is done, but building the interface around the game is proving difficult.
The game is written from scratch using C++ / OpenGL / OpenAL / CMake / Lua.
I would prefer a distribution model where apps were available directly from the developer or vendor, without having to inform Google everytime I wanted to install or try an app. Why do I need to login to Google to download an app? I am shocked at how little respect the public has for its own privacy.
My first animation is a simple walk-cycle, and it was harder than I expected.
I could not remove the flickering from the scene. I monitored the graphs in the Camera software: the lighting fluctuations seem to be caused by the camera itself. I controlled for everything I could think of but could not get rid of them :-(
I was contacted by a friend (ex UK Royal Marines / ex UK Police) and asked if I could quickly write an encryption application for his company, one that could be used by operatives with little understanding of software or computers. I was flown to London and over the course of a weekend wrote an application which had some interesting specifications. I don't really want to write much about it: there was nothing malicious about the application but it was interesting and thought provoking. The encryption was implemented using PGP. If you know me personally, and are interested, I am happy to chat about it.
I enjoy writing software. I enjoy the process of coding. Often its just experimenting with technology. In 2003+ I was spending time after work developing my own little 'game engine' - although really its just a window / rendering system with the math and the other bits and pieces associated with this.
It was a time when shaders were still written in assembly, and Microsoft released it's first X-Box. In terms of functionality there isn't much to see: I was mostly focused on the code.
Looking back at the code now I am still quite proud: it is neat and readable and contains many good ideas and approaches such as it's use of factories, and it being scripted, well logged and data-driven. It has a console too but it seems to not be rendering properly anymore. The console was toggled using the ` key (top left key on many keyboards). The console allowed you direct access to the Lua state, if I remember correctly.
The code still looks neater than code in many places I have worked. I know that much of the software I was writing at home exceeded the quality at some games companies I worked at: I was able to do side-by-side functional comparisons.
If I had a regret it is that my scope ambition is always too large. I think for a single developer, employed and badly balancing a relationship, it is better to be disciplined with your time and pick a project with a more realistic scope.
This is a simple but nice Windows program that I wrote to simplify setting up OpenGL fixed function pipeline material attributes.
Modern OpenGL has no real fixed function stuff anymore, but once upon a time almost all of it was fixed, with the programmer only able to
vary settings. OpenGL once had built-in matrices, and the concept of a surface's material, and how that surface interacted with the lights (which were also
fixed). Drawing objects was about drawing primitives and telling OpenGL that this primitive (e.g. a set of triangles) was to be drawn with
this type of material properties, and that lights 1, 2 and 3 etc should light the surface.
This program allows you to select the material properties on a variety of different classic objects, and see how it looks, and then you can export these settings to the clipboard, ready to paste into your OpenGL program. Here is an example of its output:
/* Data from OpenGL Material Viewer */
float ambient[4] = { 0.8065f, 0.2000f, 0.2000f, 0.7419f };
float diffuse[4] = { 1.0000f, 0.5161f, 0.5226f, 1.0000f };
float specular[4] = { 0.5097f, 0.5097f, 0.0000f, 1.0000f };
float emission[4] = { 0.0645f, 0.0000f, 0.0000f, 1.0000f };
float shininess[4] = { 51.1744f };
glMaterialfv( GL_FRONT, GL_AMBIENT, ambient );
glMaterialfv( GL_FRONT, GL_DIFFUSE, diffuse );
glMaterialfv( GL_FRONT, GL_SPECULAR, specular );
glMaterialfv( GL_FRONT, GL_EMISSION, emission );
glMaterialfv( GL_FRONT, GL_SHININESS, &shininess );
It appears I lost the source code to this one too.
Download materialviewer.zip (zipped Windows application)
MD5 : 5de9d8209a7859512c2abe8ceb227014
SHA-1 : 5a37ce26a0742b5201ebdfd96bbd303f7a4fb5c5
ASEtoT3D is an application for converting from Discreet's Ascii Scene Exporter file format (ASE) to Epic's Unreal Editor T3D format. It is written to enable importation of textured 'brushes' into the editor.
(Yeah, SourceForge...).The application was written over the period of six weeks sometime around 2001 by me in response to a request by an Unreal modder named Daniel Patton. Daniel needed a convertor to T3D which preserved the texture co-ordinates. Daniel was creating mods for the (very popular) Unreal Game Engine using the Unreal Editor. The Unreal Editor supports several file formats, including the autocad DXF format, however only the T3D format contained texture descriptions. Daniel had identified the ASE format as being a suitable format for conversion, as it was exportable from '3ds max', contained the necessary data, and was a human readable Ascii format. He contacted me because I had previous experience with the ASE format and had documented my findings online.
ASEtoT3D was a huge success. I received thank-you emails from around the world from people creating content for Unreal. Several bugs were reported, and I made two bugfix releases to fix them (the current version is 1.0.2).
It is also mentioned in one academic paper (pdf download) :-)
When it was first released there were many more links, but the usefulness of ASEtoT3d has diminished. Shortly after I released this, Epic released a version of their game editor with native support for the ASE format, including the much sought after texture coordinate conversion. Thus my app was no longer a 'must have' for modders.
I no longer have the source code to 'Monsters' ;-(
Monsters is a 'game' I wrote in my spare time as a student (at the University of Aberdeen). Like many of my projects/games, there is very little user participation. The 'game' is really about emergence and population dynamics.
The game is a 2D DirectX 7 application for Windows. It uses cel animations I created and pre-rendered by scripting POV-Ray. Its one of the most feature complete projects I have worked on: and it got finished :-) It has background music, context menu, path-finding, pause, speed-up game time, credits and essentially most of the features that a game should have, and that a released application should have.
The game environment is composed of different types of plants, which the monsters eat, pools of water they drink from, and rocks which form barriers to the monsters movement. The monsters can die from starvation and dehydration. You can edit the terrain during the game, adding or removing plants, water and rocks. The plants have several stages of growth, and provide nutrition to the monsters. I think I implemented some version of Conway's 'Game of Life' to decide how the terrain foliage grows and changes.
Visually there are three types of Monsters, although there is no difference in behaviour associated with their appearance. The monsters have a simple DNA code which can be inspected in-game. This DNA encodes some characteristics of the monster, including it's appearance (which type it is). I can't remember what else is encoded, but probably some aspect of their nutritional needs or movement or AI.
There are male and female monsters, and they reproduce. When a female monster is well fed and content, she may lay an egg. Content males are attracted to these eggs and fertilize them. Baby monsters are born smaller than adult monsters. The current world population is displayed onscreen.
As the 'game' is really a population sim, you can track the relationship between the available food and the monster population. In the screenshot shown here, I have been manually upping the available food supply: these are the very high white peaks. You can see that the population rises before later crashing as the food is used up. When I first wrote this I would leave it running overnight to see how the population handles various terrains.
Download monsters.zip (zipped Windows executable with Windows Help file)
MD5 : 16e0a694c55db9632673be7a076c00df
SHA-1 : cd2cc35425f09f6eca39ac58cfe307fb45330388
If you are a programmer, I bet this was the first project you clicked on :-)
A very early influence on me was 'Chaos' by James Gleik. I read and re-read that book many times, years before I began studying to become a programmer. When I first began to write my own applications, I wanted to explore fractals myself, so I wrote my own application based on the information in his book. This was 1999. Computers and the internet were not what you are familiar with now, and if the internet has always been around for you, then you probably can't imagine what the technology of 1999 (and before!) was like.
It had been a long time since I last looked at this program, before writing about it here. It is certainly nowhere near as fast as can be done now (they can be done on the GPU of a phone now) but the application is still pleasant and pretty. The lack of a nice way to select the zoom-in area is annoying, but I think it annoyed me back in 1999 when I wrote it: but I simply didn't know how to make it work as I wanted.
I think it's pretty neat given that it's one of the first applications I ever wrote.
Download MANDLEBR.zip (zipped Windows application)
MD5 : abdc5edbf151cb9fca3f604df9e5cc7b
SHA-1 : 9cf35063783cd15301536fdf86f95a91e98e62b3