TCP Project - AI - Discussion

#1 What exactly is the purpose of the disscusion thread? Is this where we post questions, or where we talk about the project and what everyone is doing in general? Does the team leader assign us stuff to work on, or do we just make stuff and contribute it..?

Just curious. :)

#2 wth's a tcp project?

#3 We're an organization dedicated to the demise of UDP. As you well know, UDP has broadcast it's evil for years now and we are going to put a stop to it. First, Torque, then the world!

No actually, TCP stands for "Torque Core Project" we're working on the engine itself. Fixing bugs, implimenting new features, all that sort of thing.

#4 Josh, the discussion thread is here so that the admin thread doesnt get swamped with off topic chat :))

No, seriously, its here for project members and non-members to chat about issues involving the project.

Lets just get a feel for the kind of discussion first. As long as its not too far off topic thats fine.

Phil.

#5 Ahhh, thanks for the clarification phil. :)

So, where do we start? Does anyone have some new, expanded AI code already? Where do we want to go? Maybe we should make a list of what we have, and what we want? I cant exactly do that though, because I dont know what everyone has already. Maybe our leader could step in here... :)

#6 ok, ipersonly think the ai should, consist of more then just loading up bots that have to follow certain paths in amap.

ther should basicly be four types of ai

bots
water
ground
air

the bots i could care less about , however it does seem to be the rave with alot of ppl.

if we could set up a defaut structure that would cover the basics ,such as stand ,walk,run,detect,track,attack,ect.

then have include's for specific types ,(mentioned above) and then even more includes for each specific one from there ,then we would have them all covered and would probably be less confusing in the long run.

#7 Rodrigo Furlan with the help of Joel Baxter, is making some great strides with our AI code. You may have seen Rodrigo's development screenshot of a handful of bots following a spline.

The bots are succesfully avoiding obstacles now, and we have just one significant hurdle between us and being able to teach them our game. Our movement system uses Quaternions for the Player, and we've been attempting to reliably convert the quaternions to euler's for sake of our bots. Without this conversion the bots pirouette ad nausea as they navigate our test level. Not exactly AI related, but that's what our AI programmers were doing this week.

Once we clear this hurdle, Rodrigo intends to put together some useable code, and I'll be helping put together the related documentation.

This AI is largely particular to the game we have in mind, but at the very least could be helpful as a point of departure. It might be exceedingly useful for a flying game, or any game that needs intelligent airborne vehicles.

Phil mentioned at one point an interface for adding nodes. while we haven't made any progress there, I have been developing a feature request for an editor that will interact with the 'psychological profile' attribute of our bots, to help us and eventually the player rapidly develop relatively unique teams of bots.

Are there other things people would like to see? Directions that the core component here should take? If these were known and understood, we'd be in a better position to target any convenient points of overlap.

#8 Ahh, the splines, that was it. Thanks. :)

I just need the bots to walk intelligently on the ground. An easy to use interface to set way points and facings, and basic commands like "Follow", "Avoid", etc, could be useful for alot of games.

I look forward to seeing your code. :)

#9 We currently have some basic AI worked out for our game. Essentially the AI for Myrmidon is going to differ from a standard FPS style game, ours leans more towards an RPG. The enemies have a handfull of core commands implemented. Based on these commands, we've defined a few "modes":
Wander/Target Hunt, Attack (melee and ranged), Intercept, Pursue

There are different AI classes that perform these behaviors differently, but still sharing all of the base functionality.

Has anyone made any progress with interior pathfinding??

Ryan Mette
21-6 Productions

#10 There are loads of basic issues that need to be addressed, here is a short list from me:

1) Pathing (ala waypoint following, spline paths, etc.
2) Steering behaviors (search for craig reynolds and flocking) basic "behaviours" that can lead to complex looking bahaviours of grouped entities.
3) Some simple interfaces for creating AI state machines (gui interface?)
4) Threat recognition - assesing threats and reacting in a realistic manner
5) Some form of higher level planning system (plan selection)
6) Squad level behaviours and plan generation and execution etc.

those are pretty fundamental issues. AI tends to be across many different levels, from the low level pathing, sensor input etc, to the high level planning and strategy selection.

for now, we need to concentrate on making a nice low level API with execution of specific things (run to target, attack target etc).

Also,we need to look at making the AI scalable by breaking up AI calls into little subtasks and having the ability to split those tasks up over time.

Phil.

#11 Hey guys,
thanks Phil for showing me this thread... :-)
Seems like all my questions (some of them here: www.garagegames.com/index.php?sec=mg&mod=forums&page=result.thread&qt=3638 ;-) could be answered here, sometime ...! Cool!
So is there already anybody working on the various pathfinding / AI stuff or is it basically a collection of ideas?

#12 Well, there SHOULD be people working on it.. :)

Ryan Mette: Would you be willing to share what you have so far with us? :)

Mychal: You guys seem to be making some nice progress there, and I look forward to seeing the code.

Um. What should I do? :) It seems like we have two groups already working on the lower level stuff we need, and I dont want to step on their toes.. Is there something you guys want me to do? Anything? :)

#13 am i right ??? this thread should just be a brainstorming to get the ideas together ???
To declare all things we need to make a good bot :D ??

ok in this case, some of my ideas.

two classes with have effect of all AI features:
Attitude: to declare how does my bots interact with the world.
for example:
Attitude_Hate // Hates the Enemy
Attitude_Fear // try to run away
Attitude_crazzy // Attacks all, no Friends
Attitude_wait // waits, friendly till anyone shoot him
Attitude_friend // will be friendly
Attitude_follow // take commands
Attitude_public // unconcerned civilian (for something like shoot him and lost the game)
etc.

or
Intelligence:
Brain_none // Stupid like straw, react only if you hit him
Brain_Reptil // Follow you, if he see's you
Brain_Mammal // Simple Navigation, but doesn't use triggers, etc.
Brain_Human // a reall enemy, uses all the navigation network, all trigger and all other stuff.


ok, tell me please if i get the meaning of this threat wrong :D

#14 Yep, I'm thinking in the same direction...
maybe we could implement a set of Finite State Machine (FSM) classes, each one responsible for a specific area, e.g.
- MovementSM (defines and switches between different states, for example MOVEMENT_STATE_WALK, MOVEMENT_STATE_RUN, MOVEMENT_STATE_JUMP, etc.)
- PathfindingSM (e.g. PATHFINDING_STATE_CALCULATING, PATHFINDING_STATE_SMOOTHING, PATHFINDING_STATE_CORRECTING, ...)
- PatrollingSM (PATROLLING_STATE_OBSERVING, PATROLLING_STATE_SPOTTED_ENEMY, PATROLLING_STATE_ALARMING, ...)
- SearchingSM(SEARCHING_STATE_SET_TARGET, SEARCHING_STATE_SCANNING_AREA, SEARCHING_STATE_TARGET_FOUND, ...)
- AttackingSM (ATTACKING_STATE_OFFEND, ATTACKING_STATE_DEFEND, ATTACKING_STATE_IGNORE, ATTACKING_STATE_RUN_AWAY, ATTACKING_STATE_GO_MAD, ...)
- ConversationSM (CONVERSATION_STATE_TELL_STORY, CONVERSATION_STATE_GIVE_HINTS, CONVERSATION_STATE_OFFEND, CONVERSATION_STATE_DISPLAY_ANSWERS, etc.)
- etc. etc.

The engine would then be able to switch seamlessly between these states, choosing the appropriate FSM and then the fitting state.
It could cycle the FSMs and/or states (maybe put them in different queues, e.g. ("SearchingSM", "PatrollingSM", ...), then, triggered by some input (player in sight, ...) switch the FSM to AttackingSM, etc.
The big advantage is, you could always extend this net of FSMs, depending on the type of game you write.

There's a pretty cool article in "Game Programming Gems Vol. I" (by Steve Rabin) describing these technique, designing an "Event-Driven State Machine Using Messages" - is anybody developing in this direction right now?

#15 We got over the Pirouette hurdle I described above shortly after my last post here. This brought us quickly to a couple of new ones: once the bots started to move they were reluctant to stop, and TGE really wanted to treat the player as a bot.

I expect Rodrigo will get past these today, as we were pretty close last night.

Josh, the interface part is going to be the most prickly for us. Without a tools programmer the interface has been a low level priority, but as the Personality Generation tool will find it's way into our eventual game I'm confident I can get some programmer time for that one. ;]

Ryan, no interior pathfinding for us as yet, although one or two of our playing fields will require this.

Phil, the area we'll be addressing soonest and next will be squad level interaction. rodrigo has basic pathfinding, and spline support in place and we are both eager to get at game specific intelligence like squad level interaction.

Sven, we have a similiar list of attributes under development - and then a pile of game specific intelligence. Repurposing the basic list should be fairly easy.

Stefan, we currently have two separate FSMs each with their own batch of classes putting our botst hrough their paces. I believe Rodrigo drew on the article you are describing, and a bunch of people on our team are looking forward to AI Wisdom (due out March 02, and available for preorder at Amazon for 21.00 off the cover price).

I've also been looking at AI Implant. I suspect that this will be ghastly expensive, but even looking at their feature map has been a useful excercise.

At our current rate of progress we might have something worth sharing with the group by the end of next week.

#16 Sounds great :-)
A general question: how do you represent the 3d world for pathfinding? That is, how do you organize and classify it (do you lay a grid over it, classifying each sector with a certain cost, flag if it is walkable at all, etc.)?
Or do you have other methods?
I just read an article (once again, Game Prog. Gems...) about using a "navigation mesh". In short, the concept is to represent the whole environment as a rough net of triangle meshes and to "flatten" everything to 2D space - like a carpet - by throwing away the Up(Y)-direction, then using a traditional algorithm for path finding (A* as an example) and then go back to 3D and move the object to the destination.
It's a bit rough and estimated, though, but it seems to work quite well...

But I still wonder how to scale everything down to 2D in Torque to get this "navigation mesh / carpet" ...
What do you guys think of it?

Could I use some BSP tree or LOS information to detect if a certain space is occupied by some object? What does Torque offer in this area which could easily be used for pathfinding etc.?

#17 Ok, I thought I'd jump in here since I did a little work on the AI before not having time to work on Torque much at all.

Outdoor pathfinding is going to be cumbersome and very wasteful if any kind of node-based navigation is used. I still think the best way to go about the whole thing is this:

Bot gets order to move to x, y,[z]. Each iteration of the getMove() (if I remember right) function the bot should poll around it for obsticals (in a conical area in front of it, probably). If it "sees" something it will run into it asks that object for pathing nodes. In this way, objects such as the pyramids can be run over, where big rocks cannot, or the big rocks can be, but only in certain places. Same with bodies of water. These nodes would be defined during map making. Then, all the bot does each getMove is take it's current location, and attempt to walk a line between itself and it's final destination, if anything is in the way, it follows the nav nodes, the next iteration, does the line, and either keeps following the nav nodes, or it has a clear shot and iterates until it gets to it's destination.

With respects to indoor pathfinding, we already have nav nodes implimented from the outdoor code...so basically the bot doesn't care if it's indoors or outdoors, it'll do the same node thing. The nodes for indoors would be able to be very sparse except where the bot may need help like going up stairs or something. The bots could drop their own nav nodes indoors as they ran.

#18 Hi Pat,
so what's the current status of your AI stuff?
Do you already have some code to share and discuss?

What about Ryan and Mychal? How did you implement these issues of indoor and outdoor pathing? Some inputs / theories/code to discuss? Maybe we can work together on these issues, or at least discuss/decide what would be good/needed to implement in the Torque to use for any kind of game (such core stuff as pathfinding or flocking etc.).

Pat, how would these pathing nodes be defined during map making? Do you plan to change the modelling plugins or just find some naming convention for e.g. dummy objects?
Or is there already a convention for defining path nodes?

Sorry for these basic questions ... ;-)

#19 well i dnt know a whole lot about pathing codes, but i do know we shouldnot leave it up to map makers,to make them, isnt there a way to incorperate some kind of dynamic code into the core,that would change depending on the amount of players,objects,ect or even map size,,,,personaly i like the old style best where ai just stands and waits for something to get in its radious/los then haves its routine/s to hadel .

#20 Currently I'm not working on the AI code or any code at all. It's crunch time with final projects do, finals in a week, tests out the wazoo (because they simply have to squeeze one more test in before the final...) and I'm trying to get some songs ready for the next open mic night :-P

My code is a) not working and b) ugly.