One revision of the Glob Arena prototype had way too much recoil on the glob launcher. You could push yourself into high orbit with the thing. It was kind of fun, but it broke the game. I’ve taken that and turned it into a game in itself.

This prototype tests using these controls to navigate a 3D space. It’s an interesting set-up for me. I’ve always tended to prefer linear movement (i.e. hit left to move left) over angular steering in fast action games. These controls held the promise of using only 2 control axes to move in 3D (rather than the more traditional 4), yet still retaining the ability to sidestep projectiles.

The controls are reasonably effective, but playtesting this game is giving me a headache! Ceding control over the camera orientation to some dodgy heuristic doesn’t help with motion sickness. Particularly when the camera somersaults if you pass by a Lagrangian Point.

I think this a pretty good indication I should try something different. The Windows executable is here (5MB).
Play it on the web.

How many satellites can you keep in orbit? Click to place satellites in orbit and set them on paths that won’t collide.

This prototype is a bit of a dead-end; it’s too shallow. I’ve put it up here as a headstone to the last few days of effort trying to turn it into something more. I experimented with flinging the satellites with mouse motion, but it was inferior to what you see here. It made it really hard to set a consistent orbital velocity. I also thought about adding an opposing team of bad satellites, but it’s pretty clear that there would be epic collateral damage every time you try to deorbit one.

Still, the randomised news-flash messages are fun. Get the Windows version here (5 MB).
Play it on the web.

Today I was walking along Courtenay Place and caught a scent that I hadn’t smelled in a long time. It brought back the strongest memories of old video arcades, Ghosts ‘n’ Goblins and pinball machines. It was like MAME had come to roost in my head for a moment.

When I tried to figure out what I was smelling, I realised it had come from the pokies machines in a pool hall that’d walked past. I still can’t pin down exactly what it was. Pine chipboard cabinets riddled with borer and marinated in tobacco smoke? Maybe I can just smell the coin-op?

Sticky glob action returns, except this time you can rove around the globe. Globs are fired out from a player character on the surface of the sphere, and the recoil sends the player coasting in the opposite direction. This is the most conventional prototype yet, it’s recognisable as an arena shooter, even though it avoids dual-stick controls in favour of pure mouse control.

The weird physics bugs have been calmed down, so you shouldn’t be seeing any writhing compound structures. There’s still the odd force explosion of course, because my boulder spawning code isn’t very clever about where it puts things.

There’s a Windows executable here (5 MB).

This is the spherical billiards prototype after exposure to hazardous radiation. The mutations are:

• The aim is to prevent balls from falling into the hole.
• You do this by shooting sticky spheres at them.

Now you’re probably thinking there’s some kind of h-game subtext to shooting sticky globs, but I’ve got a different theme in mind.

It’s very chaotic and not calmed down by the charming bug where clusters of spheres start spinning for no apparent reason. Still haven’t tracked down the source of all this mysterious torque. In any case, it keeps it unpredictable. :-)

Get the windows executable here (5 MB).
Play it on the web.

This is a little experiment with pool on the surface of a sphere. You make your shots by dragging a rubber band away from the cue ball. It’s a poor man’s pool cue; you might’ve seen the same thing in minigolf video games.

It’s quite satisfying to break and send the balls flying into low orbit, although judging cut angles is distinctly tougher than in normal pool because of the oddities of spherical geometry. I had some difficulties getting Ageia to do gravitation toward a point without screwing up static friction. As a result the balls coast to a stop much too gradually. I haven’t pursued this concept far enough to give it AI for single player.

There’s a windows executable here (5 MB).
Play it on the web.

One of the things I’ve been screwing around with is Unity 3D. Unity is a heavily data-driven game engine with an integrated level editor.

It’s so heavily data-driven that all the game code is written in script and the native code layer is almost entirely hidden (only in the pro version C++ plug-ins can be created). The engine contains most of the systems you’re likely to need for a game: 3D rendering with shaders, a level editor, a 3D asset pipeline, a physics engine, a rudimentary GUI system, network state synchronisation and RPC.

Unity is the subject of all kinds of hyperbole around the web. Back when I first heard about it, I wondered how much of the praise was down to Mac-heads who were simply delighted that the authoring tools were Mac-only. Since then, they’ve ported the tools to Windows and I’ve discovered that it really is pretty damn nice. It’s extremely quick to learn - I had a playable prototype of the game mechanic that I was trying out on Day 2 of using it.

Unity’s greatest asset is its clean design. It has a beautiful component architecture where you write update methods and event handlers in script, encapsulate them into component objects and then assemble them into game objects via drag ‘n’ drop. Exposing tweakable parameters is merely a case of declaring a component member public.

Unity is my first choice for prototyping, but I’m doubtful it’d be flexible enough to ship a full-scale game based on it. The drawbacks are:

• No script debugger. The editor offers excellent facilities for inspecting and changing object properties in a running game session, but there’s no line-by-line script debugging.
• No load/save framework. In spite of all the network serialisation stuff, you’re on your own when it comes to writing out a save game. There’s Dot-Net’s object serialisation and I/O though, so it’s not completely low level.
• The GUI framework looks to be somewhat bare in places. No modal dialogs for example.
• The physics API is an intelligently chosen 80% solution. It caters to the common uses of physics. If you’re in the weird 20% like Portal or Braid, you’ll probably spend more time fighting Unity than worthwhile.

That said, it’s superb for what it is and it’s been getting more flexible with every release. It’s a taste of the future of game development. Ideally, the only code required for a game should be gameplay-specific. Middleware has been getting steadily more and more comprehensive, and I can see the day when the only folks working on engine-level stuff work at Unity, Autodesk, Epic and Intel.

Yay! Clone Wars is all finished up and I’m on holiday. I’m going to be visiting Italy later on, but until then I’ll be screwing around on personal projects.

I’ve been experimenting with web technologies and it’s a nice contrast to console games. I feel that the immense amount of labour and development time in console games has isolated developers from players. With Flash there’s far simpler technology and a culture of releasing early and releasing often. It’s an inspiration to see the Flash devs getting player feedback weekly rather than annually!

I hope to have some interesting prototypes to show off shortly.

I can finally say what I’m working on! It’s Star Wars: The Clone Wars: Republic Heroes.

Or as I prefer to call it, Craig Timpany’s Star Wars: The Clone Wars: Republic Heroes: Episode 1: Watch Out For Bears. They still let me master submission discs, so who knows, maybe that’ll be the final title.

Here’s the press release.

Naturally I’ve got to be pretty careful about what I say about projects in public (Hi employers! It’s good to see I’m developing some Google pagerank), so if you read this post aloud, you should read it in the manner of someone who has a gun held to their head.

If there’s one thing I hate about working in console games, it’s the bullshit secrecy around projects. You spend 75% of the time unable to say anything about your job, and the remaining 25% unable to say anything candid. There’s really only one reason for it: if you ration out information, you gain control over media coverage. Journalists will do terrible things for an exclusive. Never believe anything you read in a preview. Only pay attention to reviews.

One of the key considerations in designing a shooter is engagement distance. This is the distance between the player and their opponents during combat.

Once upon a time (2001), I wrote an arena shooter called Mojotron as a hobby project. It was somewhat similar to Geometry Wars, except that Geometry Wars hadn’t been written yet (I was inspired by Llamatron instead). After I finished it, I worked on a sequel that would take that fast-paced combat and place it into a top-down maze exploration game. Like a combination of Gauntlet and Geometry Wars.

I took the Mojotron combat model, added scrolling and hooked up a random level generator that would produce networks of rooms (DungeonMaker, very cool).

Suddenly the game became noticeably less fun.

Monsters would shoot you from offscreen. Weapons that were appropriate for short ranges became frustrating to use against distant targets. Fast melee monsters that were easy to react to became very difficult if you were unknowingly scrolling toward them. In some situations, monsters were totally non-threatening, because they were too slow and too distant. The difficulty became very inconsistent.

The old single-screen arena had an important property: it put an upper limit on the distance to the opponents. The engagement distance varied from extremely short ranges (those claustrophobic moments when the player is hemmed in by monsters), up to the dimensions of the screen. By having a rough idea of the distance of the monsters, I was able to easily tune monster speeds so that they gave the player a challenging, but not excessive reaction time test. I was able to tune the speed of the player’s bullets so that they didn’t require the player to lead monsters by insane amounts.

When scrolling levels went in, all of that object speed tuning went out the window.

The most extreme examples of controlling engagement distance are the old 2D forced-scroll shmups (R-Type, 1942, Raptor and so on). Every time an enemy emerges into the screen a quick-draw gunfight starts between the player and the enemy. Neither gets to open fire before the other, the range and the timing are perfectly matched.

Imagine what a shmup would be like without this restriction. Bullets from all the enemies in the level would rain down on the player, and the player would spend most of their time killing enemies that aren’t even visible.

I could’ve applied that to my shooter, freeze everything that’s outside the screen but it seemed cheap, and at the time I didn’t understand what a central design decision it was.

In a modern 3D shooter, the situation is quite different because line-of-sight and facing direction play a key role in visibility. The level designer helps determine the engagement distance by placing walls.

You might imagine that this solves the problem, but amazingly, there was a 3D shooter called Chrome which managed to make the same mistakes my hobby game did. It had very open outdoor levels and no upper limit on how far enemy troops could see. This resulted in every confrontation turning into a sniper battle at extreme distance. This mightn’t have been a total disaster (Far Cry pulled it off), but the weapons frequently weren’t accurate enough to hit things at that range. In the end, it totally destroyed the gameplay.

Shooter designers need to decide on what the ideal distances are for combat. This influences the design of weapons, levels, cameras and movement speeds.