AI round-table of a sort

#1 ...and my own thoughts.

1.
I am most certainly focusing on the game's AI, since I want to go beyond multiplayer and provide a single-player experience. Even if I were going to go for multiplayer-only, I'd be adding bots, since I really loathe games like Halo that don't let me have a decent game offline (especially when said games feature great singleplayer AI that is just fun to fight).
In AI, I respect the STALKER approach: some have called it a philosophy of thrownness, simulating a world and throwing the player into it. I don't like AI concessions that rely on the player, I think the AI should stand on its own merits. I've probably said before that my personal goal is to develop the AI to the level where it can fight the singleplayer campaign on its own.
Judging by the recent explosion of AI stuff in the community, as well as by wider reading on my new favourite haunt AIGameDev.com, AI does seem to be a huge growth area in the industry. But sadly, at least in FPS games, while so much research is being done into new applications of AI and new approaches to old problems, these pointy-headed discussions don't seem to percolate down into making more interesting AI. I wrote a long tract on AIGameDev.com, for those who have access, about AI in modern FPSs. I reckon we're just getting to a point where that has to change, and with such a critical mass of resources out there for anyone who wants to get into AI, this has to happen soon.

2.
I reckon GG's approach to AI has been spot-on in terms of the existing framework. I don't want an FSM built into AIPlayer, because not all games will use an FSM, even a shooter like mine - I'll be going the BT route, and it would mean more labour to rip the FSM code out of AIPlayer and replace it with my own system. AIPlayer includes only the most basic functions, that will probably exist for every AI character in every game - move to a point, aim at a point.
That said, I do believe GG could provide some form of 'AI library'. While AI for many games over many genres does differ greatly, there are some fundamental elements which it might be helpful to have already mplemented in the engine. For example, A* pathfinding, abstracted so that we could plug in a node graph or a navmesh or whatever else we want to use. A FSM implementation, or a BT implementation, separated from any other game classes so that we're not forced to either use it or rip it out, but can use it when and where it's appropriate. Abstraction is probably important here - if GG provided an FSM with 'attack', 'hide' and 'guard' states, it wouldn't be very useful for someone developing a racing game. But if they made a more hands-off framework for FSMs, then individual designers could adapt it to their game.

3.
I'm not using any of the AI solutions available here or elsewhere (though see below...), but I find all of them very interesting. I like to do things myself most of the time, and especially AI, which is an area I'm so personally interested in. But aside from that, nothing I've found at the moment quite satisfies my requirements - that just confirmed my decision to get stuck in and do it myself.
For my game, I'm focusing on the following:

-Abstracted behaviour tree and possibly FSM implementations
-Global path finder/manager
-Cover searching based on collision geometry*
-AI sense manager with memory

*Really quite excited about this, but it might turn out to be another animated collision mesh system... :P
I've probably forgotten something, but that's the core of it.
One thing I might not be doing myself is navmeshes - hopefully I can make some progress towards integrating Recast and Detour with TGE, unless someone else gets to it first. Since that's likely to be one of the most complex things, I'm saving it for last, and will probably work with node-based pathfinding until I, or someone, releases a navmesh-based solution. My ideal goal for that stuff is to basically have the capabilities of the recast demo - open up a level, click a button, and voila! a navmesh - but enhanced with a manual editor. Additionally, grouping navmesh triangles into regions for hierarchical pathfinding to ease the processor load from pathfinding calls. And a bunch of other navmesh information.
(So... basically what Andy Rollins has done ;P.)

And... I guess I've written quite a lot, so I'll open the floor to all you out there.

#2 Interesting post Daniel;

Can you elaborate on this more;

"-AI sense manager with memory", is it anything like this last know position approach described here

http://aigamedev.com/insider/discussion/last-known-position/

#3 Kind of, but in a less 'oh man cool feature' kind of way. Whenever the senses find an entity, they create a 'contact' in their memory. Contacts are regularly updated, if the senses can still see the contact. So if the senses saw a player run across a doorway, the contact would be retained with a last known position and velocity (and time since last seen). Contacts time out if they haven't been detected in a certain amount of time.

#4 "Kind of, but in a less 'oh man cool feature' kind of way."


Yeah, I didn't care how ubisoft implemented that as gameplay feature either. But in theory, it's an interesting tech to locate/chase player.

So how do you plan to implement this so that ai doesn't cheat? I.e ai doesn't always know exactly where the player is. I mean will the ai go the last known position only and remain there to search for player or there is some other approach you are planning?

In most games sense/perception always seems to result in 100% accurate ai, making it a bit dumb seems difficult and only in few games I've seen this.

#5 Well, a certain amount of cheating is bound to happen, but I'm just trying to restrict it to common-sense stuff. Like I said, if the AI can't see a contact at any point in time, then it won't update the contact's position, and will start counting time since it was last seen. All the AI reasoning and logic I'm going to deal with only deals with contacts, instead of the objects themselves. So the AI will be forced to make imperfect decisions based on the sensory input it has, or remembers.

Quote:I mean will the ai go the last known position only and remain there to search for player or there is some other approach you are planning?

That would probably depend on the concrete details of the AI design. I'm just aiming at a framework where the AI will have the information: 'player was in doorway three seconds ago heading right', and it will be the designer's responsibility to tell the AI entity what to do with that information. In most cases this will probably mean moving to the doorway and looking around.

Quote:In most games sense/perception always seems to result in 100% accurate ai, making it a bit dumb seems difficult and only in few games I've seen this.

The difficult thing is, real-life senses are quite a lot better than what we'd like to see in games. Realistically, it would probably be pretty reasonable to allow AI to see you from ridiculous distances - human players are likely to do that, in any case. I reckon it'd be interesting to model more than the AI's vision, but also play with its ability to, once it's seen something, identify what it is. It's easy to notice motion - but then you've got to look more carefully and figure out what you're looking at, whether it's a friend or foe, etc.
I'm starting to look at that myself - classifying each contact according to its utility to the sensor (whether it's helpful or harmful), and an uncertainty in that value (the extent to which we're not really sure). I'm actually thinking of making the actual detection rather simplistic, and scaling up the identification side of things. That's a lot more difficult than vision though - to be truly realistic in that regard, you'd have to take into account so much data, as well as non-trivial data, like actions the contact has done (if the contact has fired at you, you can deduce immediately that it's hostile...).
And then you get all sorts of possibilities where the AI can be surprised and make wrong assumptions - you could dress up in an enemy's uniform and they'd all identify you as friendly, but then what if you open fire on them? Turns out their visual identification was imperfect, and they have to deal with the new information.

But I don't want a soapbox for my own AI stuff... I want to hear about everyone else's :P

#6 1.
The problem with the concept of "realism" in AI is that it's very expensive - in everything, and regardless of how much info you give to an AI, left to their own devices they're going to look pretty stupid under some circumstances.

Careful scripting, trying to keep things simple, and cutting down the available opportunities for an AI to screw up and do something jarringly stoopid, seem a good gameplay mechanic to me.

true story for which I site zero sources...
Some boffins built a computer that was half as powerful as the brain of a mouse, which ran 10 times slower for 10 seconds ... and then caught fire. perhaps some sort of cooling fan was in order...

It's not so much how smart an AI is ... but how well it can trick the player into not thinking that it's dumb and thus breaking gameplay immersion.

"-future of AI demand in the community?"
MOAR! More types, more complex ... they're unsatiable beasts gorging from the trough of code and script application ... but more also means more problems.

2.
I suppose some sort of hardcoded precompilable pathfinding out of the box might be nice --- but that's only good for ground based AI objects, not much help in a flight sim or a variety of other games. It'd be more of an extention of current stock AI - but then there are resources and code snippets for that, and teams, and getting it to shoot at stuff.

3.
Custom, based on what I've read in the resources and the forums, dissected, shuffled about, various ideas thrown in from scratch, and said precompileable pathfinding resource.

#7

Quote:It's not so much how smart an AI is ... but how well it can trick the player into not thinking that it's dumb and thus breaking gameplay immersion.

That's definitely something to keep in mind. It makes me think of the stories I've heard about FEAR's AI, which wasn't extremely complex, but they added verbalisations that made players believe they were using all sorts of complicated tactics like flanking or calling for reinforcements. I guess it's handy to remember that the player, ideology aside, is the whole reason the game is created, and literally is the centre of its universe.

Quote:but that's only good for ground based AI objects, not much help in a flight sim or a variety of other games.

Wow, I've never thought about pathfinding for a flight game... does it exist? :P
You're right that there are resources for most things you could want, though there might be something to be said for having GG implement something in a professional way... not dissing any of the resource writers out there by any means, but to be fair to GG, they're probably the best people to write code for their own engine, and would have a good sense of where it would fit in.

Quote:3.

Hope you don't mind my asking, but what sort of AI are you building? Leaning towards tactical or free-for-all? I never did play that demo you released, but I suspect it might have moved on since then. Though maybe not the design goals.

#8

Quote:I never did play that demo you released, but I suspect it might have moved on since then.

Lol, actually not that much difference yet! I've been working on everything else, and am just getting back to the AI.

The alleged .plan is for tactical squad movement based on triggered player locations. original basic explanation with diagram.

I also reckon it's worth splitting AI types up for performance, so I'm planning on a sliding scale of usefulness/performance-expense.

Rough Example of What I'm Thinking:
-----------------------------------
Full/Squad AI(expensive)
Does astar pathfinding (though that's precompiled for performance cheapness), adapts to positional squad goals and hostile targets on the fly. Think() routine gets faster the closer a threat is.

Example of Useage: player squadmates, moving up with the player throughout the level, respawning somewhere behind on death, and then catching up again to be part of the team.

----

Hunter AI(expensive)
Probably best to split this up from Full AI as I want that to concentrate on being squad based, though could be incorporated. Dynamically hunts down opponents either on sight or on order. Think() routine gets faster the closer it gets to it's prey.

Example of Use:
Big Bad Beastie running around, trying to turn the player into steak, bloody as hell (which as every connoiseur of dead moo-cow knows, is the only way to eat steak).

----

Bot (medium expense)
Not too different from the "standard" Torque AI, runs on a path only (no dynamic pathfinding), but shares Full AI's combat routine.

Eample of Use:
The other "useful" allied AI that the player sees around as they head through the level and the average enemy AI - go to waypoint, shoot at good guys.
eg: Bad bots are holding a house. Player hits a trigger, some friendly bots spawn, run down their paths to help player attack bad bot house. Once house is taken, firendly bots don't move up with player, are deleted later when player moves away out of sight.

----

Dummies (Cheap)
AI only in name. No dynamic pathfinding or combat checks. Using Torque standard pathing, they move to position and then shoot at intervals at a pre-determined object. The player probably won't get close to them.

Example Of Use:
Friendly guys who provide support fire for "immersion". They are not really firing at the enemy, it's just going in that direction. They may run a script where they fire at one point in space, pause, then fire at a different point, pause, loop.

----

Fakes (very cheap)
Dummies dumber brother - Fakes are intended to be seen at distance, making the player think that the battle is larger than it is. They might move in the way a Dummy does, but they just play a battle animation, and don't fire projectiles. They exist solely to help further immersion.

Example of Use:
The player spots some friendly guys far away at a point he can't get to, carrying on the battle in their sector ... or at least so it seems.

----------------------------------

At least that's my general idea for AI. Split them into different types to do different jobs, make less appear as more, Keep It Stimple Stoopid.

#9 I'm a big fan of reinforcement learning (http://www.cs.ualberta.ca/~sutton/book/the-book.html if you want to read a free online university textbook written by one of the main researchers in the field) and other such machine learning techniques. They aren't necessarily suitable for all game ai (being that they take a *long* time to learn how to do complex behaviors, and can start doing very non-optimal things).

I wrote once a bot for a racing game ai competition using rlai, and it eventually learned to beat all but the very best hard-coded pathfinding bots. Course it crashed thousands upon thousands of times and took days of learning on a super-computer cluster to get to that point. I think it would be really cool though to build in such a learning ai into a game (as an optional difficulty level) that would collect data about how you play and learn to play against you optimally, and then, also collect that data from everyone online and build another bot out of that.


Scripting is great for controlling specific encounters. But, it would be time-consuming to script every encounter, and if there was no randomness, the game would get repetitive/stale once I figure out how all of the encounters work.

Getting "emergent" (probably better referred to as unexpected/unintentional, as behavior really can't emerge from a program with hardcoded rules) behavior is always fun. In a fighting game that I wrote, my ai discovered a neat trick of using its own deflector shield to accelerate its fireballs at me at ridiculous speeds that totally caught me off guard when I first had it do it to me!


I'm not sure what AI facilities Torque already provides, but, I'd like to see at least the following:
-A path-finding system. Pretty standard fare, a lot of games will use it, and bad path-finding is a good way of ruining any game.
-A basic easily extendable finite state machine bot.

Anything more complex than that, starts getting into game-specific code, which has no place in the base engine.

I had an amusing experience with that though. I came back one morning to discover that it had learned to drive donuts back and forth across the finish line. I had a bug in the code that rewarded it for when it went across the finish line, but, I never checked if it actually went around the entire track, so the optimal strategy was to do donuts on the finish/start line...


But in general, realism for game ai is mostly wasted. It doesn't matter what the ai is doing when you can't see it. If it cleverly sneaks up behind you without you knowing, that is exactly the same game play result as if you just spawned the enemy behind the player when they weren't looking. Course it starts mattering once the player knows the bot is there, as then they might appreciate the advanced tactics.

You also have to draw a line at making the ai too good. A bot that always headshots you, or always blocks and counters all of your attacks is generally no fun either (though it can be satisfying to manage to kill such a beast!).

#10

Quote:Course it starts mattering once the player knows the bot is there, as then they might appreciate the advanced tactics.

That's something I always appreciate in STALKER... it's probably a bug that keeps spawning Wolf's scouts to attack bandits at the vehicle depot, but I'm always intrigued to just sit back with binoculars and watch the bots fight each other. But the benefit of a bot actually figuring out how to get to a player is that it is procedural - like you said, if you always spawn a bot behind the player at the same place each time, it is predictable.

Quote:I had an amusing experience with that though.
...

:D

Quote:I think it would be really cool though to build in such a learning ai into a game (as an optional difficulty level) that would collect data about how you play and learn to play against you optimally, and then, also collect that data from everyone online and build another bot out of that.

It seems like it would be difficult to categorise 'how you play the game' - I guess in something like an RTS players might have more individual styles, but in the context of games where the rules are clear and you can't do much to break them and still be effective, it seems like the most effective bots would be those that just learn to play by the rules very well, no? But I guess pattern learning is an aspect of that, and could be beneficial especially in fighting games or similar.

Steve: I do remember reading that blog. 'Twas a good explanation, and was one of the things I liked to pore over (along with bryce's blogs) when I was still just fantasising about AI.

The idea of different 'classes' of AI thought processing is an interesting one. And certainly a good way to scale the AI in larger battle scenes. when I was still set on making a war game (it's since been downscaled to a more tactical focus), I was thinking of having simple AI going on in the 'background' of levels, that responded to how well you were fighting. If you were making progress, the background soldiers would appear to be pushing their enemies back. So there might seem to be a huge battle going on, but there would really only be a handful of squads doing anything useful.

#11 Hmmm...lots of interesting stuff, thanks... I'm not a coder, but a designer. And I plan on working with coders very soon for a stealth game which will have "heavy ai". It's always good to know what programmers think and how they approach to solve particular problems because it helps designers to implement better game-play specific ideas.

Ai, I can safely say that is the main reason why I'm interested in games/development. Modding thief games for years was a great joy for me. Especially when you have tools(which thief series very blessed with this) as a designer to teach/modify ai behaviors without programming and watching your scripts coming alive during gameplay is very satisfying.