Disco Justice
Worklog: Drop Fighter

Ah, Drop Fighter. A sad tale.

I love the very specific genre of futuristic flying 3d shooty games. The first one I really got into was Star Fighter 3000 on the Acorn A3010 (from the Archimedes family of computers used in schools).

At the time, the fast 3d and texture mapped ground, combined with being able to blow up every single item on the map made for a compelling experience. Steady upgrades for your ship and a fun variety of missions kept me playing this for years.

The only game that really equalled it for me was the might Gunmetal on Xbox, about ten years later.

Gunmetal upped the ante by allowing me to transform into a robot and shoot at things with twin machine guns and backpack-mounted rockets. Other notable entries for me around this genre are Freespace 2, Hellbender and, narrowly, Future Cop.

So, I wanted to write my own. I started in late 2003, and a couple of months later I had the basic flying around, landscapes, weapons, collisions and a mothership in place. It grew and grew, and went through several upgrades and partial rewrites as I reacquired all my defunct programming skills from the 90s.

After working on it on and off until around 2006, I began to listen to other people’s opinions about it. The game had reached the stage where it was quite playable: mission structure was in place, allowing objectives to be completed. I took the game to an Indie developers meet, and left it running on a laptop to see what people thought. Everyone seemed to find the controls difficult. After some cornering, a publisher expressed a degree of interest in seeing the finished product. Talking with one of their programmers in the following weeks rammed the point home: I needed to change the controls so the ship righted itself, and couldn’t roll or pitch more than 45 degrees. I dutifully did so, and immediately it became no fun whatsoever to fly this fighter. And there it was: I was writing this game purely for myself, no one was going to enjoy flying this thing as much as I did, because this kind of arcade-y simulator was just too niche.

Part of the problem was keyboards. I was quite happy playing the game on a keyboard, but it’s simply not the kind of thing PC keyboards were used for. And PCs don’t come with a gamepad. Mouse control for these games always seemed horribly woolly.

In the end, I just let the project die, because in everyone’s eyes it just wasn’t much good. For me, swooping low and fast through exploding buildings never gets old, but I can see how it might for other people.

Every now and again, I keep thinking about doing a little bit on it, just for fun, but it needs so much work to bring it up to standard. A few things can slot in fairly easily, like the latest version of my super awesome blowing-thing-up effects, but in other areas the code just needs completely re-organising. I’m a far better programmer and designer now than I was then, but that’s always the way.

For the record, this is Drop Fighter circa 2006:

Worklog: Order and Obliterate

I decided, after many years of umming and ahhing, to sit down and tackle a real-time strategy game. The main reason I steered clear of these was because I’m sort of scared of pathfinding. However, I manned up and looked up some techniques, settling with the A* method to begin with. It… almost works. The screenshot is pretty much all there is so far. There’s also a map editor for tile layout, ingeniously called “Edit and Obliterate”. Which makes no sense, come to think of it.

Worklog: Order and Obliterate

I decided, after many years of umming and ahhing, to sit down and tackle a real-time strategy game. The main reason I steered clear of these was because I’m sort of scared of pathfinding. However, I manned up and looked up some techniques, settling with the A* method to begin with. It… almost works. The screenshot is pretty much all there is so far. There’s also a map editor for tile layout, ingeniously called “Edit and Obliterate”. Which makes no sense, come to think of it.

Worklog: Order and Obliterate

I decided, after many years of umming and ahhing, to sit down and tackle a real-time strategy game. The main reason I steered clear of these was because I’m sort of scared of pathfinding. However, I manned up and looked up some techniques, settling with the A* method to begin with. It… almost works. The screenshot is pretty much all there is so far. There’s also a map editor for tile layout, ingeniously called “Edit and Obliterate”. Which makes no sense, come to think of it.

Worklog: The Frontier

My most recent project, a browser-based game, sort of a cross between the excellent OGame, the also excellent Frontier: Elite II, and enormous second-job simulator EVE Online.

The Frontier

Quite a bit to do on this one, but so far it’s not a particularly tough project. Built a new generic PHP class that everything in the game inherits from. It handles all the database stuff, meaning making a new game object is as simple as making a class with the appropriate variables and an array of table links, and adding the table itself to the database.

Works great for this project, but it’s caused me a few headaches on some others, so I don’t think I’m quite as close to abstracting away the database stuff as I’d hoped I was.

The game itself places you in a spaceship. You can travel around and trade between planets. Eventually, you’ll be able to afford more ships, and pilots for them. Beyond that, you can buy plots of land on planets, build entire stations yourself, and research and trade technology and items with other players, or send your ships to attack them.

The planet side will have a nice square-based editor where you’ll have to arrange your structures yourself. Stations will work a similar way, but will require more funds to keep in operation, and be visit-able by other players if they are set as “public”. Anything you make will be tradeable here. Your planet side facilities will be able to produce resources, factories in stations or on planets will then be able to produce consumables that you can then sell to players through your stations.

Multiplayer games are an absolute bear to set up, since you need a critical mass of players before the game becomes a) fun and b) popular enough for players to spread the word. I’m aiming to de-emphasize the multiplayer aspect by adding in many AI NPCs, and a universe that expands automatically with the number of players. Ultimately, my aim is to make a game that isn’t solely about combat. It’s kind of an ambitious plan, which is why I’m not mad keen on pursuing it much further. The game really needs 80% of the elements in place before it starts to function as something genuinely new and interesting, and that’s a pretty massive feat. Add to that the difficulty involved in attracting and retaining a playerbase, and it becomes a full-time job.