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:

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.

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.

Subscribe

Auspex: Enormous vents in games don't bother me but one the thing I enjoyed most about your earlier version (argh! I never sent you feedback...) was the leaping about.

Climbing about in vents is kind of boring compared to leaping!

David: AI is a tricky business. I like the way that the Unreal engine handles it, which is with state-based programming. That allows you to compartmentalize the AI's behaviour and makes it easier to add new states without having to re-write all your existing code.

On the topic of air-vents: As you're doing a side-scroller, you could have the vents be pretty damn narrow. Just enough for the player to be able to lie down in and move very slowly along on their belly. I would not complain if they were included.

Cult of Jared: Out of curiosity, how much coding experience did you have before this game?

Tom Francis: I did some Computing at A-level ten years ago, which covered making a simple interface in VisualBasic. I don't remember any of it, but I think the first object-oriented language you learn is the only potentially tricky one, really. When I've dabbled with JavaScript and PHP to make this site, and now GML for the game, they're more like different dialects than different languages.

What I'm lacking is any knowledge of good practice, or established shortcuts - I have to derive everything from first principles. It's not hard, and quite fun, but I'm always aware there must be spectacularly more efficient ways to approach some of this stuff.

Fede: Vents are a nice tool, as could be emergency stairs and the things skyscrapers' window washers use: anything that adds possibilities is welcome. So another vote for having them in.

Oh, and the link to your GalCiv2 War Diary seems to be broken. :(

Devenger: I think vents are worth including. They are a plausible way of giving the player a way of sneaking past something. In a sidescroller, to go horizontally past something without hitting it, you must be on a different vertical level; vents give you an opportunity for this (as does multiple floors, but that has its limitations).

More generally, for an example of the 'making multiple routes in a sidescroller' problem being solved, see Yahtzee's game Art of Theft. Even if you've played it before, it might be worth a look at again for specific level design tricks. It really is quite lovely.

DanPryce: If it's good enough for Batman, it's good enough for everyone else. The cool thing about Gunpoints' movement system (assuming it hasn't changed dramatically from the Alpha build I played) is that you could follow vent to the edge of the building, get outside, and reach exterior vents on other levels by bouncing off the adjacent buildings.

Dr. ROCKZO: 2 Cents on Air vents. As long as there's no Headcrabs around the corners, I'll be fine.

Nano: "But you don’t really know what you want until you’ve tried to explain it to a very, very stupid person."

I can't help but feel that this arose from when you tried to explain your AI coding to me the other day. In my defense, I was jetlagged. *runs off crying*

But at the time I wrote it, it didn't have the www in. So old links will be broken, but I don't know where.

Nano: no, don't worry. You're so smart that explaining it to you didn't help at all - you understood it.

SimonC: It looks like you're using a variation on a production system, or "teleo-reactive program" if you want to show off :-). The idea is that you have a set of priority-ordered condition/action rules, where all of the conditions are being continuously evaluated, and the highest-priority rule whose condition is true gets its action executed. By the looks of things you can have multiple rules fire if their conditions are true, but it's certainly similar.

Anyway, good choice - it's a sound scheme for writing robust goal-oriented behaviours (and, like you say, much more comprehensible when written down than some of the alternatives). A robotics prof at Stanford, Nils Nilsson, described TR programs first, at least as they relate to AI. So you've bypassed about 25 years of AI community dithering; SkyNet to be done by, say, Thursday week?

verendus: Firstly, I am awed by your handling of this. Secondly, I'm fine with vents, so long as they come with noticeable detriments, such that using them is a trade-off: for instance, you could be noisier inside a vent, or it could be so thin that you had to crawl along slowly - and if a guard sees you in one through any of the vent covers, you're essentially dead.

MartinJ: Crawling through a vent - or taking any other alternative route - should never be detrimental. It was already slightly annoying that in Deus Ex, you get less EXP for sneaking through a level than shooting everyone (Shifter mod fixed that) and the only reason it worked was that EXP wasn't really important in the game. Vents / alternative routes should simply be harder to find or access. In your case, Tom, the vents should perhaps only be visible once you actually crawl into them or open the lid, with the entrances either disguised or simply hidden among other background art. That way, you're rewarding the player for taking extra time in enjoying and exploring your game - instead of punishing them for taking an alternative route by making it slow, unnecessarily hard or annoying. If crawling through ducts and canals and vents punishes the player instead, it becomes just a lazy crutch and not a gameplay mechanic. Why would anyone want to crawl bored through a vent when they can beat up a few guards (which you said you want to make it a fun experience)?

MartinJ: Retrospectively, I should have probably broken that down into two paragraphs so that reading my post isn't a punishment by a reward.

verendus: I probably phrased that badly - it should be a trade-off of sorts, is what I meant. In taking the vents, you need to move slower, but you can avoid potentially difficult gunmen groups, locked doors, and the like. That way, neither route is clearly better - each one comes with advantages and drawbacks.

UberSprode: Speaking of Batman. If you had only downward facing directional lights that left the ceiling in darkness, you could jump from light to light, staying above them, hidden in darkness. That could give the same awesome feeling you have when you jump down on someone in Arkham Asylum, and provide an alternate route for you to take that would involve more platforming skill than just crawling through a vent.

Aaron: I've never met a man-sized air vent I didn't like. They are always fun for me.

EGTF: So to code AI I just have to engage them in elenchus till we end up in a state of mutal aporia?

I'm not sick of air vents, it's a nice change of pace to running and can make the player feel enfeebled unannoyingly (so long as it's not overdone). I think you could also add purpose for them beyond point a to b movement. Say you're in an above room vent; as you crawl along you can't see outside unless you pause over a grill, adding possiblities of tension and spying on enemies in the room underneath.

Though I can't imagine a great coat and hat is comfortable vent attire.

Mike: Excellent stuff! I didn't know you'd done a Computing A-Level - what you've managed to do is still blindingly great. I'm struggling to get anywhere near that with my own stuff.

These are really excellent posts, and really important reading too. I can't believe PCG aren't interested in paying you to do this - mixing journalist and programmer is a great idea. You multi-talented rogue, you.

The issue of 'adding a new event every time I want to change this' leads into the extremely dull world of Software Engineering. People have developed templates for how to best lay out and organise code for when you have problems like that. It's very boring, but effective.

"What really is the point of trying to teach anything to anybody?"
This question seemed to provoke a murmur of sympathetic approval from up and down the table.
Richard continued, "What I mean is that if you really want to understand something, the best way is to try and explain it to someone else. That forces you to sort it out in your mind. And the more slow and dim-witted your pupil, the more you have to break things down into more and more simple ideas. And that's really the essence of programming. By the time you've sorted out a complicated idea into little steps that even a stupid machine can deal with, you've learned something about it yourself.

Florian: Your blog seems to be optimized for some screen resolution, therefore the 'last comment', 'features' etc. sections overlap with the text. Even after disabling pop-up blockers etc.
I don't know how but there should be a way to fix it?!

Kind regards.

LeSwordfish: why not have a between floors crawlspace, as a slight visual difference to a vent.

Also, after seeing the comment about a hat being uncomfortable in a vent, i want my hat to occasionally fall off. Or to be so i can throw it to distract guards. Though, you lose if you leave it behind.

Tom Francis: Mike: we did talk about it, but I'm very keen for Gunpoint to be entirely my thing. I only want to work on it when I feel like it, and if I ever finish, I don't want to feel like it was done partly for PCG.

Dave: yeah, I remembered that line as I was realising some of this stuff, and was struck again by how right Douglas Adams was about everything.

Florian: what browser and OS are you on? It's true my site isn't friendly to resolution widths below 1024, but on most browsers, you should see a scrollbar rather than anything overlapping.

Devenger: LeSwordfish: and maybe the hat is like that of Notch's Metagun game - if you lose your hat, you're vulnerable to damage until you retrieve it. (By extension, as long as you keep replacing your hat on your head, YOU ARE INVINCIBLE.) On the other hand, we'd then see the Gunpoint-man's head without a hat. I'm guessing he's bald. Hm.

xTRUMANx: Hi there. As I was reading this post, I got reminded of this paper by Jeff Orkin from Monolith about the A.I. of F.E.A.R.

I think it might be a great resource for you when trying to write A.I. code. Some googling and wiki-walking may be needed depending on your background on certain topics like the A* algorithm. You may not use the ideas presented in the paper, but it's certainly inspiring.

Also, is Gunpoint open-source? Some commentators have mentioned playing an alpha build; is it publicly available?

Jim: My take on the vent issue is that the growing disrespect for sneaking around in vents isn't due to the age of the cliche; it's due to increasing realism in games. When you make one aspect of a game more realistic, you have to be careful not to leave other aspects behind or they'll look terrible by comparison.

Warren Spector calls this "unity of effect." Increase polygon count on a character model, and suddenly you notice that the animation is terrible, or that their eyes are always pointing straight forward like a zombie. Increase the visual fidelity of the world and suddenly you notice that the physical simulation doesn't allow objects to tip over. Increase the realism of the world simulation, and suddenly you realize that vents large enough to crouch in are ridiculous.

Deus Ex was attempting to be realistic, but there was a minimum level of abstraction that was necessary just to get it working on PCs of the time, so it allowed a similar level of abstraction in gameplay. A Deus Ex made on current hardware could probably still barely get away with vent crawling. I suspect the next generation is out of luck. But a cartoony platformer? No problem at all. I bet you could put a double jump in there and nobody would think twice.

Tom Francis: Ooh, cheers. Nope, Gunpoint isn't open source yet. I invite anyone who wants to play it in an ultra early prototype stage to drop me an e-mail, and every couple of months I send out a new build and ask for feedback.

Making it public, to me, is releasing it - even if you put an alpha tag on it. I won't do that until it's a fun, fully formed game with proper guidance, an objective, and all of the basic systems I have planned. Realistically, I'm still about six months away from that.

Ursa Major: //right now all you can do in Gunpoint is jump on people and whale on them. //

JohnyTex: Very interesting post, hope your future work on this game goes well :)

From my experience, the problem you are talking about - figuring out what your code should ACTUALLY do as opposed to what you THINK it should do - is a pretty common problem in software engineering. The best way I've found to combat this problem is to write requirements for yourself.

As a programming novice I always thought "Why should I write a spec when I'm the one implementing the software? I already know what I want to do, so I'll just start coding it!". The problem with this approach is that, more often than not, there is some aspect to the problem that you have overlooked. Eventually you will discover it and go back to the drawing board, but if you're unfortunate this might result in a lot of code ending up in the trash.

A better solution (in my experience at least) is to start by writing down, in plain english, exactly what it is you want your program to do. Start with the bigger picture stuff and work your way down to the smaller details.

What usually happens then is that you start finding flaws in your initial assumptions; what you thought you wanted your program to do might, in fact, not be what you actually wanted it to do at all!

This is pretty natural because it's hard to examine a concept in your head so thouroughly that you discover all these tiny exceptions and special cases. When it's laid out on paper though, it's much easier to analyze and make an informed decision on wheter it's a valid solution or not.

As an additional bonus, if you break your whole program down into tasks which can be measured in hours then you have a decent attempt at a schedule as well! (Just don't forget to multiply all time estimates by 2 ;))

If you write your requirements on the computer or with quill and ink doesn't really matter, but I recommend using TeX (the package MikTeX + LEd is nice if you're using Windows) to get some structure into your document.

Hope somebody found this helpful!

Tom Francis: Cheers Johny! After my first method proved too messy, I did step back and write out what I wanted the AI to do in plain English. I hadn't thought of treating it like writing a spec for a contractor or something, though - that's a smart way to force yourself to be clear and rigorous.

This Week In Video Game Criticism: Socrates, Cyborgs, And Game Worlds « Games News and Updates: [...] weeks in a row someone?s mentioned Point Lookout. Elsewhere, Francis has been reflecting upon what his efforts with programming his Gunpoint AI game have taught [...]

How to finish a game | Seattle Interactive Fiction: [...] via another blog a funny excerpt on the joys (and otherwise) of coding AI. References Socrates. The best part, after [...]