On some level, my game is going to be about fucking with people. When you get down to it, the reason I like Deus Ex isn’t because I have the choice of using a multitool or shooting a guy. It’s that I can trick the guy into doing what I want. If I don’t have the key to a door with a guard on the other side, I can just shoot a wall, and he’ll unlock it for me when he comes to investigate the noise.

People coming to investigate, in fact, seems to be the core rule in the most enjoyable deceptive play – whether it’s in Deus Ex, Thief or Hitman. So that was my one requirement for Gunpoint AI: you must be able to knowingly misdirect the AI. The fact that investigating suspicious noises is also semi convincing, semi effective behaviour for a guard is just a nice bonus.

I had a feeling this would be hard, and I knew it was probably a little too involved for a first project. But I was looking forward to trying, because AI is one of those nice juicy problems that’s too big to tackle. You have to break it down, and breaking things down in ways that make sense is one of my favourite things to do. I took philosophy and maths at university, so it’s about the only common thread in my voluntary education.

I wanted guards in office blocks to head to the source of suspicious noises, like gunshots or glass breaking, even if they weren’t on the same floor. It sounds dangerously like pathfinding, a famously sticky area, but I didn’t think it would come to anything like that. I can just break it down into a) how do I get to somewhere on my floor? and b) am I going to the sound itself or the stairs?

What I’m learning, increasingly, is that conceptual stuff is not the hard bit. Every high-level idea you have for how to translate a design concept into chunks of algorithmic code will probably work, and in fact is pretty easy to write. The hard part is a part I didn’t even realise was a part: order.

“I wanted guards in office blocks to head to the source of suspicious noises” – really? Did I want dead guards to respond to suspicious noises? Did I want guards to walk right past the player himself on his way back from breaking a window, in order to investigate the breaking of the window? Did I want guards who are being blown out of a window by the force of an explosion to stop, mid-air, and tell the others: “Oh hey, I’m closest to that broken window I was just flung through, I’ll go check out what caused it”? Did I want the guard who just shot you to run to your dead body and try to solve your murder?

Actually I kind of do, but that’s probably another game.

It’s easy to code what you want. But you don’t really know what you want until you’ve tried to explain it to a very, very stupid person. That was Socrates’ thing, in fact: he acted like an idiot to make people explain themselves to him on the most basic level, which usually revealed they didn’t truly understand their own beliefs. These days we have silicon hyperidiots to explain things to. They’re able to be much more stupid, many more times a second, than Socrates ever was. Coding is the Socratic method as an extreme sport.

Because the concept behind my AI system was simple, scripting it was getting increasingly complex. Every time I said something like, “Set this guard’s state to ‘alert’,” I had to first check that he wasn’t dead, or stuck, or in a lift, or being punched. And it wasn’t going to get any less fiddly: every time I added a new situation, I’d had to go back and add new exceptions to every line of code it could influence.

The only way I could make it simpler to code was to make it more complex to think about. It turns out that the nitty gritty of how an idea works in practice is a much more unwieldy beast than the high concept of what you want it to achieve, and it’s the former you really need to simplify.

So now I have an intricate system of connected timers, tracking five or so independent properties of the AI’s mental and physical state, and it’s a mess to think about. But in code, it’s remarkably straightforward. I’ve turned every sub-problem into a separate function with a human-readable name, replacing stuff like:

if ((sprite_index=sGunman && oPlayer.x > x) or (sprite_index=sGunmanLeft && x > oPlayer.x))

With: if HesInFrontOfUs

The top level code is now just this – the pink things are functions I’ve written that call in other chunks of code:

And after a lot of tinkering, and a few maddening variable-definition errors I never really got to the bottom of, it actually works. You can lure guards from their posts, hide the other side of the stairs and jump them when they come out. Or you can make a noise on one floor, then travel to another while the guard there runs to the one you just left. It’ll get more interesting once you have more of a toolset: right now all you can do in Gunpoint is jump on people and whale on them. But it’s already actual fun to screw with the AI, so I’m pretty excited about what I can do with it from here.

By the way, Spelunky creator Derek Yu put up a great guide about what stops people finishing games, and how to avoid it. Since he inspired me to start this, it’s nice of him to also inspire me to try and finish it.

Lastly, I need opinions: man-sized air vents are a cliche. But are they an annoying one, or just a tool that ultimately makes a game more fun? In some ways they’d fit with Gunpoint’s movement system, since they wouldn’t have to be floor-level for you to get to them. But I don’t know how sigh-worthy people find them these days.