Game Cartography

September 11th, 2009

I spent an evening recently looking at old computer game maps. Sounds dull, but if you can find a game you played, you get a huge sense of nostalgia and see the game from a different perspective. Take a look at this site to see what I'm talking about:

The bit about different perspective got me thinking. For some of the games I've built, there's no overview map. Not in the game, or in the source files. The levels are generated dynamically at runtime from data, not stored as a big image. Would I get an interesting new perspective building maps of my own games?

Well, you decide:
Iron Maiden: A Matter of Life and Death

Wall Street Journal Interview

August 1st, 2009

A few weeks ago, out of the blue, the Wall Street Journal interviewed me about my game Hanna in a Choppa. I'm still not entirely sure why, but you can read their edited article here.

The article is quite cut down from the responses I gave, and modified to make little sense in a couple of places, so here's the full unedited text, for the terminally bored:

WSJ: Do you have a minute to talk about your game? Thanks!

I think I could manage a minute for you, yes.

I saw your tweet about Hanna in a Choppa by the way - you're too kind!

WSJ: When did you make this game and why?

Hanna in a Choppa begun life as a short experiment in physics, about 2 years ago. An idea for a fast-running physics engine just kind of sprung into my mind, and after a few hours was a basic working demo on the screen. That engine wasn't really for anything other than play at first, but it found its way into loads of projects I was working on. Each project would need something a bit different from the engine, so it slowly got upgraded over time. It grew more features, became easier to deploy and performed better and better.

One day I had inspiration for a feature that allowed flat surfaces in the physics world. After adding it, my test code included a sort of one-screen room with surfaces at all sorts of angles, and you could control a basic losenge shape to try out collisions against all the different angles, corner conditions and so on. It struck me as being a bit like being on a space hopper, which would be an interesting basis for a game. Being on a space hopper is clearly quite a silly way to spend time, so it would be have a quirky comedy angle. It's name would be Hannah on a Hopper, because it sounds silly and intreguing enough to draw people in.

Unfortunately, whilst it was a fun sounding concept, the gameplay prototypes just didn't play all that well. It seemed that whatever I tried there were big flaws in the way the hopper moved about and bounced that just didn't feel all that good to control. I shelved the idea, until inspiration struck again...

WSJ: Why choppers?

I was reminiscing about old games with a couple of friends, and brought up Zeewolf on the Amiga. It was a 3D helicopter game where you controlled the chopper with the mouse, and flew about completing wartime missions. I was wondering how you'd go about implementing such a thing in code (as all programmers do), when it struck me that the Hannah on a Hopper engine would actually cope with it really well. I put a prototype together that night, and it worked beautifully. Hanna was suddenly in a chopper. The quirky humour element remained in my mind, and persisted through to the final game. Likewise, the forgiving gameplay I was looking for in the space hopper game remained, and I was determined to build a helicopter game where you don't have to be careful of the walls and where you can make mistakes without penalty. For example, the helecopter is only destroyable due to a technical limit in the physics engine.

WSJ: Who's Hanna?

Back at the start, it struck my rather cynical mind that a girl on a space hopper would likely generate more clicks on the game than a boy. Hannah on a Hopper reads with a certain rythem and bounce that prepares you for the sillyness to follow. Dropping the 'h' and modifying the 'er' to 'a' helps emphasise the wordplay: Hanna on a Hoppa. And thus Hanna was invoked into the world.

If you look into the cabin of the chopper, you can see Hanna made up of very primative shapes. This is partly because the game as a whole deliberately uses that style for the graphics, but also because one of the gameplay prototypes of Hoppa portrayed Hanna as a sort of ragdoll with primative shapes for limbs. The idea was that she'd bounce around in a pretty silly way on top of the space hopper as you moved about the screen, but it didn't really work that well. I did like the way she looked there though, so transferred the style into Hanna in a Choppa.

WSJ: Have you ever ridden a helicopter before?

I have apparently ridden in a helicopter, but I honestly can't remember it at all. I was pretty young, although I'm told I was old enough that I should remember it. Plus it's something you'd expect to remember. I'm suspiscious that my mother made it all up. After all, she seems to invent new relatives I've never heard of quite frequently.

WSJ: And could you explain the color scheme?

There's not a lot to explain! There's a generous helping of black, and everything else is orange. Except the wonky border, which is meant to blend in with the site so the game window doesn't look square. The illusion is rather broken by Kongregate's big gray frame they put round it, but the idea was there. The simplicity of the colours came from trying to find something that would stand out and beg to be played, whilst also hiding my inability to draw properly. It's also quicker to produce monochrome graphics, and they render faster in Flash so everything plays smoother. One final bonus of monochrome graphics is that they help hide any overlapping objects when the physics engine throws a wobbly. Like a lot of physics engines, it doesn't deal with tall piles of things very well and items at the bottom can get crushed into the scenery.

Plus it's fun to think I've made over a million people see orange spots all day long! To anyone I've given eyestrain, erm, sorry.

WSJ: Also, I'd need your age, location, and occupation.

I'm 32ish (it's so easy to lose count), live near Bristol in the UK and am a freelance programmer. I specialise in games, but also do websites and other webby things.

If you liked Hanna in a Choppa, you might like it's spiritual successor developed in conjunction with Aardman Online: Invention Suspension.

WSJ: How far do you live from Aardman?

I'm really close to Aardman - their online department is in a studio in Bristol, and I live just on the outskirts of Bristol. It's maybe a quarter of an hour on the motorbike, tops. I've done a few games with them now, they're a brilliant bunch of people to work with.

Long overdue makeover

June 6th, 2009

Finally, I've got round to giving its much needed makeover. The new site is geared towards touting my freelance abilities instead of the random malarkey of the previous site. All the old content is still available, should you find yourself in desperate need of random malarkey.

The new site runs on WordPress (ooh, shiny), with a custom theme (ooh, pretty) and has just about all my previous webby-work in it (ooh, um, contenty). There's lots of tags and categories to help you find stuff you might like too, so take a look!

If you spot something broken, comment here or on the site, and I'll fix it. Probably.

A Brief History of Chris

May 6th, 2009

I wrote this for a forum entry. It wasn't meant to be this big, but since it is, I thought I could post it here too. Here we go then, with A Brief History of Chris. It was a programming forum, so it's focussed on my professional life rather than personal, if you see what I mean:

1. Faffed about with Amstrad CPCs waaaay back. Started by typing in listings from magazines. I remember typing the first one in without knowing that the enter key gave me a new line, so padded them out with spaces to look like it did in the mag. Needless to say my listing didn't work. I learned fast though, and could code a mean pile of spaghetti in Basic before too long.

2. Got into AMOS Basic on the Amiga. Suddenly there was actual power at my fingertips, which was just great. AMOS Basic was easy to use and gave
you all the hardware's power to do things like overscan scrolling, sprite manipulation, sound and so on really fast (for the time at least).

3. Went to uni doing Computer Science. It didn't teach me much about programming, but was did get me a string of really dull programming jobs afterwards. I'm the guy who programmed that little box of hardware that nobody ever sees that sits in a field reporting water levels. Fear my awesome fame! Ok, so it wasn't glamorous, but it did pay the bills.

4. Got intensely bored of writing code that I didn't care about, and learned Flash 6 then MX over about a few months of evenings. The intention was to make a dramatic career swerve into things I enjoyed doing, in a location that I liked. I got a job with Hyperlaunch (a digital marketing agency in Bristol). It was a sizeable drop in pay, but a massive hike in fun. It was also bloody hard work, but I ended up producing many many creative things (very often games) for big names that I'm pretty proud of.

5. Hyperlaunch's "way of the project" was to get things done as quick as possible. It was liberating in a way, but also often led to a feeling of not having given a good idea enough of a chance. It was also high pressure and low pay. I figured I could do high pressure and low pay all by myself and jacked it in to go freelance.

6. Freelance worked out pretty good so far! I had a couple of contracts right off the bat as I left Hyperlaunch, which gave me an encouraging kickstart. Then I sold my first private game, Hanna in a Choppa, to Kong for a decent chunk of money and it's been all go from there.

And that's pretty much it. When I went freelance my main concern was that I'd never find enough work to fill my time and pay the bills. Somehow though, I have even less free time. I have endless ideas I want to try out, but am struggling to find time for. Really must rebuild my ancient website too, and update my blog, and, and...

Skulduggery Quest Postmortem

September 15th, 2007

At work we recently built an RPG game promoting the children's book Skulduggery Pleasant. It is a bad game. You can play it if you like on the link below. Register and complete the game, and you might win a Wii even (chances are pretty good as not many people are going to qualify for it).

Since the book is based around a character who is dead, it seems appropriate to do a project postmortem. The company has spent a considerable amount of time making the game compared to how long most projects take for us at least. Overall it is a much larger undertaking than we normally attempt and it has multiple mini-games built in, each of which could be a typical game project in its own right:

Hub: Walk around in a vaguely Zelda-like fashion, exploring and picking stuff up. This is intended as a sort of story-led role-playing-game section that takes you through the other mini games.

Spot the difference: Just the basic spot the difference game transferred to a computer. You get a different puzzle made up each time so it doesn't become completely trivial to solve if you replay.

Magic Levitation: A physicsy lift 'em up. Not sure I've played anything quite like it before - you have a magical levitation ability that you have to train up until you can chuck the item you need out of the window.

Cave Exploration: A bit like the old Amiga game Commandos. You have to find the final important game item whilst evading the sight of the guards.

Individually, each mini game is amusing for a bit. The big problem with the game as a whole however is the lack of cohesion. I think this stemmed from a lack of adequate planning in the early stages, leading to a fair bit of making-it-up-as-we-go as the deadline encroached. What we ended up with was a nice enough game engine for an RPG, but with no story or other characters to interact with. For a story driven game, having no story sounds like a bit of a deal breaker to me. And if there were a story, having no characters also sounds like a problem!

There's some neat code running under some of this, despite the lackadaisical gameplay experience.

Hub: Whilst walking around, you can pass both in front and behind most objects. I came up with a method to do this that doesn't require constantly swapping the depths of everything. There are two copies of the clip that contains all the scenery objects positioned directly at the same spot on screen, with your character sandwiched between them. Each item's position on screen is compared to the characters. If it is above the character then the back version is set to visible and the front invisible. If below, the other way round. Flash's _visible property works internally by simply skipping the object when rendering to screen, so its very efficient this way.

I wouldn't recommend you build a similar system however! There's a downside (isn't there always). Whilst it works really fast and reliably with one moving object, if you add any more you can't guarantee that its possible to sort things still!

Levitation: I've been developing a lightweight springs and masses engine for a while now. It was last in use on the Rant game, and before that to do a string effect on Paul Steel's site. Each iteration the springs get more stable, the masses collide more realistically and the efficiency of the engine improves. At some point I'll try and do a game purely based around this engine - I have something unusual and interesting in mind!

Anyhow, the physics engine grew a couple of features for this game. Attractor and repulsor masses for a start (to do the actual levitation bit). The game worked beautifully with an attractor mass - it was like trying to pick things up with a weak magnetic ball. It wasn't all that easy to play however so I made it a repulsor following the mouse position instead, and got a lovely floaty feel.

The collision engine got an overhaul too. It now has a concept of collision sets. This is a way of tagging a mass such that it knows not to check for certain types of collision that can't happen, or even that we don't want to compute to help the game effects. There's another major performance enhancement gained from sorting all the masses along the x-axis. The sort routine is built into Flash's runtime engine and hence almost free in terms of execution time. Most of the Flash built in stuff runs really well, but as soon as you try and do something complex and algorithmic in ActionScript (version 2 and below that is) the inherent sloth of the language's dynamic style means everything grinds to a halt. Anyhow, after the x-axis sorting, masses are only compared until one is found on an x-position that cannot collide no matter what. This runs in both directions from the mass in question and the search is culled beyond the discovered limits. This gives an impressive performance boost overall.

I've made pretty heavy use of Flash 8's new-ish bitmap processing for graphical effects. Push the light around with your magic, and watch the shadows. Its a subtle effect but the shadows move around depending where the light is coming from. Shadows get longer, fainter and adjust their position all in realtime. This is all done using the new drop-shadow filter on each of the graphical objects in the scene, and a bit of trivial trigonometry. A simple effect, but powerful, and I haven't seen anyone else doing it yet.

The graphical effect of the magic itself is scripted too, rather than an animation. Particles of magic are placed onto a bitmap each frame, then the bitmap is faded and colour transformed via yet more filter effects. Over multiple frames, moving things leave trails across the screen. Pretty.

Caves: The base engine for the caves section is identical to the hub. I can hear what you're thinking (if you're still awake). You're asking how it can have NPCs wondering around when the system can only cope with depth sorting against one moving object. You weren't asking that? Well you're getting the answer anyway.

The NPCs follow a set path. They are at a set depth with respect to the walls etc, and are duplicated in the same way (in fact, they're just objects in the world like any other). If you pick their path and depth in the scene carefully, you can engineer it so that they don't look wrong. It just means you can't have an NPC wander about freely as they can't walk both behind and in front of an object without causing odd glitches. On the final screen the baddies do laps of an island-wall, which seems to break the engine's rules again. The trick is that the baddies don't actually go behind the wall at the top - they just stay above it a little. Look carefully and you might see their shadows glint above the wall rather than behind it.

Visual line of sight 'vision cones' were a challenge too. It isn't all that hard check if a particular point on screen is in sight of another particular point. You just cast a ray between them and see if you hit anything that blocks sight along the way. Or if you have the walls in vector form you can check for collisions mathematically with a line intersection check.

To show a cone of vision however, you have to run the above check for every pixel that might be in sight. That's generally a hulluvalotta pixels, and infeasible for realtime Flash games.

I'm fairly proud of the technique I invented to get sufficient performance here. I first cast a shadow off the back of each of the wall segments to the edge of the screen. This is done by simply projecting the end points of each segment out plenty of distance and joining the dots. This polygon is then drawn to a memory bitmap with the drawing API and clipped to the visible area. Flash is superb at doing this sort of manipulation as long as the shapes are simple, so there's only a minimal performance cost here.

Once the shadow of every wall is drawn (as if the enemy in question is a light source), we have a set of pixels that the baddie cannot see. A little bitmap magic to invert this, and we have a mask we can apply to its vision cone drawn complete. Job done - our baddie can't see through walls anymore.

One nice bonus with this technique is that we get almost free line of sight tests between the baddie and any point on screen. First do a hitTest against the complete vision cone shape. If the test succeeds, do a pixel colour lookup on the mask bitmap at the appropriate point. If that point is within a shadow, we're out of sight. If not, we're visible. HitTest and getPixel32 are both lightening fast.

This technique has a few unavoidable downsides. Firstly it uses two large bitmaps for every baddie. This means lots of memory allocation (bad for old machines) and lots of pixel setting (bad for any machine in Flash). Its setting all these pixels every frame that costs most of the time in this routine, even though those pixels aren't used directly on screen. There is also some kind of bug in the Flash player that leads to rapid memory leakage. Switch screens and you lose a meg or two of memory as the new baddies are generated. You also lose a smaller amount each frame. I eventually traced the leakage to a line that reads;

clip.cacheAsBitmap = true;

Without the line, no memory goes missing. With the line, megs per screen. Doesn't seem to matter if you turn the caching off later, you still lose the memory. This is something that the Flash player is meant to entirely manage internally, rather than it being the programmer's responsibility. The same behavior exists on the Mac player too, curiously.

Final lesson learned: On the PC Flash player, Key.isDown(1) is a fine way to read if the left mouse is pressed. Its a fine way to find out nothing at all on the Mac. That's the first really significant difference I've found cross-platform with Flash. A testament to just how well the player is built and tested!

Still here? How determined of you!

This week I are mostly been reading...

September 15th, 2007

A pretty book about mathematics and programming

An enlightening book about the mechanism of evolution

A beautifully written yet brutally filthy diary of a London call girl

And I can recommend them all!

Robots In Disguise

August 29th, 2007

Everyone my age remembers Transformers from their youth. Everyone young today remembers Transformers from the recent film.

So that's everyone then.

I was quite the fan when young. I had lots of the toys. I saw the films. I watched the TV series. I read the comics. Whenever you fondly remember something from your youth you tend to have a sort of predetermined distaste for any attempt to revive and modernise the concept. Imagine then my horror when I learned they were making a new Transformers film, and that I'd be working on a microsite promoting the line of new toys.

How could the new stuff possibly compare to the nostalgia-enhanced awesomeness of my childhood?

Luckily the new film is pretty damn good. It is pitched at just the right balance between serious, cool and self-deprecating humour.

Even better, the new toys are damn good too. We only had the big Optimus Prime and Megatron toys in, but both are pretty impressive. The Megatron toy is the lesser of the two and only transforms into a sort of alien airplane thing. The Optimus Prime toy changes into a very nice truck model via a really complex series of transforms. You keep spotting new bits about it that are cunning. For example, you split, pull out then twist part of the truck grill to become the feet. As you're doing that internal mechanisms move another part of the feet into position for you. There are similar nice touches all over the model, including hands adjustable fingers and thumb.

Anyhow, that's enough of a free advert for them. Now for the one they paid me to make. Click below to play out the Autobots Vs Decepticons in cool street-fighter stylee action.

I'm fairly pleased with a few aspects of this game. Since we started from the Turtles game we built a while back, we could afford to enhance a few features.

  • AI tuned separately for each character. Each enemy in Turtles was essentially the same AI bashing the keys of the other characters.
  • Mild element of learning in the AI. Use the same special over and over and it'll learn to counter effectively.
  • AI self tuning. If it starts to thrash you it lets up and plays a bit easier for a bit. If you kick its ass it gets more aggressive.
  • Better specials - from projectiles to transformation specials, there's more imagination to enjoy.
  • Matched characters. As part of testing I put both characters on AI mode at quadruple speed and let them slog it out. Over 60 rounds later, the results were too even to call!

Ancient Four Dimensional Software

August 10th, 2007

A very long time ago I made a computer program to draw 4D surfaces via animated 3D projections. Sadly I haven't got any examples of the animations anymore, it was that long ago. It made images like this however:

Frankly, the program wasn't really much good for doing anything other than making pretty stuff like that. You couldn't easily get it to output anything scientifically useful for example. Still, I did hear a rumour once of some Amiga magazine having put it on their coverdisks. I never saw the magazine and never heard anything from anyone else about it, so kinda forgot about it.

Until the other day that is. A project at work requiring isometric projection reminded me of the DGraph program. I wondered if I could find any images it had made anywhere online. A search didn't find what I wanted, but it did turn up an archive with scans of the magazine

I'm not angry that they used my work without permission. I'd have appreciated them contacting me beforehand of course, but I'm just happy the program was seen by someone! Granted I've now built games that have been played by quite literally millions of people, but there's something special about being published in print and immortalised on a coverdisk. The era of homemade software appearing on magazine covers has well and truly passed.

They even used a screenshot from the program on the disk itself. I wonder if anyone bought the magazine expecting to get some amazing free 3D software. Hope they weren't too disappointed.

Full size scan of the coverdisk page.

Popup hell still exists

August 10th, 2007

Cast your mind back to the dark ages of the Internet, if you were involved with it back then. If you weren't, you may struggle to believe just how pure things like email and the web were. They weren't full of adverts, or spam. There were very few malicious tricks being pulled like phishing or 419 scamming.

Eventually the con-men cottoned on to the lucrative potential and wrecked email with spam and scams. Good honest programmers made filters and so on to combat this. Banner adverts appeared on every popular webpage. People began to automatically filter out the distinctive banner shape whilst browsing, so the evildoers invented popup adverts, which leap in front of the page you're reading demanding your attention at least long enough to find the browser-close button.

Of course, the popup ad problem on the web has been mostly solved now. Browsers have popup stoppers built in these days so you don't even have to go and find a 3rd party one for yourself.

But popups aren't dead. Oh no. They're alive and well, albeit in a cunning new disguise. They aren't adverts anymore, but they're just as annoying. I'm talking about the scourge of the automatic update.

What's that you say? You like your programs being updated automatically? Well, I'd happily debate whether automatic updates should happen at all, but that's not what I'm trying to say here. What I want to know is why on Earth do I need to be told about it with a popup dialog? If its automatic, do it silently and behind my back! Don't require a reboot. Don't even require the restarting of the program being updated should it be in use. Just do it without annoying me.

When I start my computer at work, I get pestered for Windows updates, antivirus definition updates, Adobe software updates, backup reminders, Messenger updates and more. All I ever do is acknowledge each dialog until it buggers off. I'm not making any real choices for the software that I need to be involved in. I'm just wading through crap that's getting in the way of work.

Message to Adobe: When I open Acrobat Reader by double-clicking on a PDF, there's a fair chance I want to read the document. Five seconds after I start reading is exactly the wrong time to shove a giant and incomprehensible update box in my face. I just want to read my document. When I open Photoshop or Flash, I have a project to complete and a deadline to meet. I don't need to update some random bit of crap I never use. I just need to get on with what I'm doing. Go away please!

Message to Microsoft: My work computer gets rebooted every day. Please don't make me do it more often than that. Surely the latest update can wait until tomorrow morning? At least give me a "sod off updater popup" button that really does make it go away. As it stands the dialog contains options for reboot now, interrupting everything you were in flow working on, and reboot later which translates as "annoy me in five minutes with another popup when I'm typing something important".

Message to antivirus manufacturers: Your software is important to me and I like being protected by it. I don't however need to be told all the time that it is behaving itself like a good little program. I only care when there's a problem. Bother me when my PC is infected, not when its updating itself happily. Better yet, silently prevent the infections in the first place and don't tell me at all.

And, finally, to anyone who makes software anywhere in the world: Don't steal the system focus when I'm working on something else. If you absolutely must bring something to my attention, pop something up that sits to one side until I've had a chance to react to it. If your dialog is that vital in the first place, why risk the chance that I may be pressing space or enter at the exact time the options appear? All that will happen is I won't see the dialog because I'll accidentally choose the default option with the keyboard shortcut to it.

Infinite precision 3D curves

July 28th, 2007

For an effect for a client, I needed to make things whiz around in 3D space along smooth but unexpected paths. They would be travelling at all kinds of speeds from very slow to pretty rapid, so my curved paths had to be some kind of continuous function rather than a bunch of sampled points. So how do you define a curve? Well, it kinda starts over there, curves this way a bit, then that way, then up a bit and bends the other way.

That's a rubbish definition. We can do better. In fact, a clever chap named Paul de Casteljau already did by inventing what we know today as the Bezier curve. These are fairly remarkable things. You pick a bunch of points in space and the algorithm makes a smooth curve that starts at the first point and ends at the end point, snaking towards all the other points along the way. If you've used Photoshop or similar drawing packages, you've probably used a Bezier curve in its Cubic form (4 control points) before, in 2D.

What I needed was a 3D version, but using as many points as I cared to define. I came up with this simple editor:

You do not have the latest version of Flash installed. Please click here to go and get it

In the editor above, you can use the controls shown bottom right to draw a 3D curve. They're more interesting when you change the depth a bit with A/Z, and you can see their 3D-ness when you move the camera around. You can use page-up and page-down to move in/out a bit, but since there's no screen culling you will see spazzy effects if you move in too far.

You can add as many points as you like, although it can get pretty slow. It isn't optimised at all really, since its just a utility for editing rather than a final piece. The rendering of the curve is ultra-simple too so if you add enough points, you'll just get a mess of straight line segments. The underlying curve is a genuine Nth order curve however, N being the number of points you've added.

So what can you do with these curves? Well, spangly 3D paths, like I said. Weren't you listening!

You do not have the latest version of Flash installed. Please click here to go and get it