TCP Project - AI - Discussion
by Phil Carlisle · in Torque Game Engine · 02/14/2002 (3:08 pm) · 93 replies
Discussion thread for TCP project on AI.
About the author
Recent Threads
#22
Pat, not sure I follow you with regard to wasteful and cumbersome node-based navigation. In this scheme is it the server or the player that is assigning way points and/or objectives or both - and if it is the player, might not some greater degree of autonomy be more desireable? Also the obstacle avoidance procedure you suggest seems to be based on, well, nodes. ;]
Stefan, our environments will be, very basically, either a large enclosed cylinder or city streets. Some rare instances of interior navigation take place, and there are no fly zones, but otherwise players and bots will be free to move along X, Y, and Z anywhere on the playing field. This is not really the case for most TGE games, but we intend to make some of this code available as soon as we can.
Gary, this will really depend on your map maker and the requirements of your game. Something that is rapidly becoming clear on our team is that everyone has their hands in everything as we try to collectively figure things out. We have assigned roles, but no pre-conceptions. Over large areas of the sort that TGE enables a developer to represent, an AI that waits to be triggered would almost necessarily be a defensive entity.
I think what the community wants most is to be able to fire up the SDK and have some bots that perform about as well as bots in a single player FPS. They run toward you and maybe evade some while eagerly trying to kill you but ultimately they die - allowing you to move on.
We aren't really in a position to help with this in particular, but we do have ideas that might be helpful to everyone as they generate game AI's. Here's a feature request for an AI Personality (State Machine) Editor I submitted to our team a while back (heavy sports emphasis so feel free to gloss):
***
goal
create an AI editor which will allow us to easily generate bots with unique AI Profiles from within tge, or as a stand alone app. then, leverage this code to provide an interface for team customization within our game. parameters the ai profile will consist of a default profile block containing things like the ability to follow orders, the ability to avoid players, and basic onfield decision making. this information will be stored in a file, one file per bot, which will be loaded by the server.
default values will be class specific, for instance here is the goal oriented basic profile that rodrigo has developed as a test case:
// Goal Codes
$GoalHunt = 61; //For testing $GoalScore = 50; //Score a goal
$GoalFindShootingPosition = 51; //Find a good position to try a scoring shot
$GoalFindSupportPosition = 52; //Find a good position to recieve a pass
$GoalScortBallCarrier = 53; //Stay close to the ball carrier protect him
$GoalGetBall = 54; //Get the ball if loose
$GoalHitPlayer = 55; //Try to hit or hurt a specific player
$GoalCauseHavoc = 56; //Try to hit and hurt any opposing player
$GoalInterceptBallCarrier = 57; //Intercept the opposing team ball carrier
$GoalPositionInAttackField = 58; //Find a good position to attck $GoalPositionInDefendMidField = 59; //Find a good position to defend midfield
$GoalPositionInLowerField = 60; //Find a good defensive position near goal
These and other entries will be present in the eventual default class. the value associated with each entry is on a scale of 0 to 100, with 0 meaning the bot has no inclination toward a behavior and 100 meaning the bot has an almost exclusive interest in performing associated behaviors.
The available fields will be drawn from a list of characteristics which were described in a previous blog:
C
index_captain
index_littlethings
index_m2sbr
index_sporting
M
index_sporting
index_bruiser
index_thug
index_vengeance
Y
index_courtsense
index_inthezone
index_pwned!
index_stylin
K
index_cheatz
index_fear
index_offday
index_wrongsideofbed
This list will change as play testing establishes the need or lack of need for particular entries.
reference
some real world sports psychology, and team profiles - teams will generally have a number of personalities, which contrast and compliment.
in the case of the san francisco 49'ers, during there most recent period of high level title contending, we can draw on a number of examples:
the william flloyd or deion sanders phenomenon - the 49'ers are a very business like operation that prides itself on perceived intleligence, and various notions of 'class'. with the arrival of william flloyd, a fullback, certain forms of self expression began to appear throughout the team: a willingness to do endzone dances, hip-hop cultural forms like do-rags and the like, and more pronounced ego expression in the form of players like flloyd, or ricky watters (a running back) demanding the ball. this brought a certain swagger to the team, and placed the team at odds with it's more 'old school' coaches and players.
This generational attitude shift within the 49'er organization came only after similar shifts in the rest of the nfl. deion sanders (a defensive back) was able to cement these changes into place by virtue of his considerable talent other players emulated him because he was successful and made the team successful. d.sanders, one year later, had a similar effect on the dallas cowboys after michael irvin (wide receiver) got the ball rolling.
At the same time the 49'ers continued to draw on the character of players like steve young (quarterback) who drew on an almost reckless disregard for his own safety to inspire his teammates, and jerry rice a living legend of football who has an an almost fanatical commitment to training and technical accuracy that younger players remained deeply respectful of.
some easy conclusions about our stylin, sporting, and captain values can be drawn here. also, these players were all individuals who got to handle the ball as part of their responsibilities at the 'talent' or 'skill' positions.
another point of reference is dennis rodman's presence during the chicago bulls last championship runs.
d.rodman's unique profile entires might look something like this:
index_littlethings: 78 //high willingness to the dirty work
index_bruiser: 80 //loved to mix it up
index_courtsense: 80 //uncanny ability to be in the right place
index_sporting: 30 //was a hugh jass type pain
he was the leagues leading rebounder for an extended perid of time. rebounding draws on court sense and a very developed sense of a few technical elements, it also requires a willingness to be banged into and to bang into people. these, coupled with the requisite physical build, d.rodman had in abundance. he was also a kook. the chicago bulls had an 'all business' demeanor akin to the san francisco 49'ers, and rodman was held in check by michael jordan whose AI profile might look something like this:
index_captain: 90 //made his team better, by demanding a lot from them
index_m2sbr: 90 //earned alot, demanded alot, slow to give it back
index_courtsense: 85 //knew the gamne inside and out
index_inthezone: 85 //played at a very high level, almost always
index_pwned!: 85 //dominated a lot, and liked it
that's right folks, actually takes 5 variables to even come close to describing what m.jordan brought to the game psychologically, and all of these values were necessary to offset (rein in) the eccentric behavior of d.rodman.
We'll want to try lots of combinations to flesh out the 18 to 24 teams we'll be building and editor with an intuitive interface that allows for easy experimentation will help immensely. it will also provide the starting point for our extensibility model.
the editor
using one of the standard color selection interfaces available in many applications, a familiar interface to computer savvy types, we'll be able to select ai profiles for a bot on a by color basis.
a player selecting in the green range would the be operating in the range between yellow and blue. feedback for these values must occur in real time to reveal the logic of the organization to the user. our own hierarchical organization and default clustering of values will require some definition prior to final implementation.
providing a color wheel interface for tge could allow us to expand the implementation to other areas, such as sky, fog and so on.
further refinement would be available through the use of a 'curves' like interface. this is present in some forms already within the tge terrain editor. using this curves interface the user would be able to effect teh values associated with each profile entry, higher or lower.
rhetorical questions
do the values associated with unique entries in a bots ai profile modify other values, do they express themselves independently, or are both at issue?
My to do list
1. screenshots of existing apps for reference
2. composites of ui
***
The sort of editor described here could allow map makers or scripters to intuitively add flavor to the bots that Justin described above when used in conjunction with his pathfinding code.
until someone volunteers to help me build such a thing though, look for some presentation of our Pathfinding Code ASAP - probably toward the end of this week.
02/19/2002 (1:27 pm)
Our 3d world, the playing field for our game, is broken up into large volumetric areaswhich the bots understand to be more or less desireable based on contextual input. Our game is a sports game, so this input is of the sort: does my team have the ball, does the opposing team have the ball, do I have the ball? Rodrigo has implemented a preliminary spline based navigation system, with which our bots can use beziers to generate obstacle avoidance paths.Pat, not sure I follow you with regard to wasteful and cumbersome node-based navigation. In this scheme is it the server or the player that is assigning way points and/or objectives or both - and if it is the player, might not some greater degree of autonomy be more desireable? Also the obstacle avoidance procedure you suggest seems to be based on, well, nodes. ;]
Stefan, our environments will be, very basically, either a large enclosed cylinder or city streets. Some rare instances of interior navigation take place, and there are no fly zones, but otherwise players and bots will be free to move along X, Y, and Z anywhere on the playing field. This is not really the case for most TGE games, but we intend to make some of this code available as soon as we can.
Gary, this will really depend on your map maker and the requirements of your game. Something that is rapidly becoming clear on our team is that everyone has their hands in everything as we try to collectively figure things out. We have assigned roles, but no pre-conceptions. Over large areas of the sort that TGE enables a developer to represent, an AI that waits to be triggered would almost necessarily be a defensive entity.
I think what the community wants most is to be able to fire up the SDK and have some bots that perform about as well as bots in a single player FPS. They run toward you and maybe evade some while eagerly trying to kill you but ultimately they die - allowing you to move on.
We aren't really in a position to help with this in particular, but we do have ideas that might be helpful to everyone as they generate game AI's. Here's a feature request for an AI Personality (State Machine) Editor I submitted to our team a while back (heavy sports emphasis so feel free to gloss):
***
goal
create an AI editor which will allow us to easily generate bots with unique AI Profiles from within tge, or as a stand alone app. then, leverage this code to provide an interface for team customization within our game. parameters the ai profile will consist of a default profile block containing things like the ability to follow orders, the ability to avoid players, and basic onfield decision making. this information will be stored in a file, one file per bot, which will be loaded by the server.
default values will be class specific, for instance here is the goal oriented basic profile that rodrigo has developed as a test case:
// Goal Codes
$GoalHunt = 61; //For testing $GoalScore = 50; //Score a goal
$GoalFindShootingPosition = 51; //Find a good position to try a scoring shot
$GoalFindSupportPosition = 52; //Find a good position to recieve a pass
$GoalScortBallCarrier = 53; //Stay close to the ball carrier protect him
$GoalGetBall = 54; //Get the ball if loose
$GoalHitPlayer = 55; //Try to hit or hurt a specific player
$GoalCauseHavoc = 56; //Try to hit and hurt any opposing player
$GoalInterceptBallCarrier = 57; //Intercept the opposing team ball carrier
$GoalPositionInAttackField = 58; //Find a good position to attck $GoalPositionInDefendMidField = 59; //Find a good position to defend midfield
$GoalPositionInLowerField = 60; //Find a good defensive position near goal
These and other entries will be present in the eventual default class. the value associated with each entry is on a scale of 0 to 100, with 0 meaning the bot has no inclination toward a behavior and 100 meaning the bot has an almost exclusive interest in performing associated behaviors.
The available fields will be drawn from a list of characteristics which were described in a previous blog:
C
index_captain
index_littlethings
index_m2sbr
index_sporting
M
index_sporting
index_bruiser
index_thug
index_vengeance
Y
index_courtsense
index_inthezone
index_pwned!
index_stylin
K
index_cheatz
index_fear
index_offday
index_wrongsideofbed
This list will change as play testing establishes the need or lack of need for particular entries.
reference
some real world sports psychology, and team profiles - teams will generally have a number of personalities, which contrast and compliment.
in the case of the san francisco 49'ers, during there most recent period of high level title contending, we can draw on a number of examples:
the william flloyd or deion sanders phenomenon - the 49'ers are a very business like operation that prides itself on perceived intleligence, and various notions of 'class'. with the arrival of william flloyd, a fullback, certain forms of self expression began to appear throughout the team: a willingness to do endzone dances, hip-hop cultural forms like do-rags and the like, and more pronounced ego expression in the form of players like flloyd, or ricky watters (a running back) demanding the ball. this brought a certain swagger to the team, and placed the team at odds with it's more 'old school' coaches and players.
This generational attitude shift within the 49'er organization came only after similar shifts in the rest of the nfl. deion sanders (a defensive back) was able to cement these changes into place by virtue of his considerable talent other players emulated him because he was successful and made the team successful. d.sanders, one year later, had a similar effect on the dallas cowboys after michael irvin (wide receiver) got the ball rolling.
At the same time the 49'ers continued to draw on the character of players like steve young (quarterback) who drew on an almost reckless disregard for his own safety to inspire his teammates, and jerry rice a living legend of football who has an an almost fanatical commitment to training and technical accuracy that younger players remained deeply respectful of.
some easy conclusions about our stylin, sporting, and captain values can be drawn here. also, these players were all individuals who got to handle the ball as part of their responsibilities at the 'talent' or 'skill' positions.
another point of reference is dennis rodman's presence during the chicago bulls last championship runs.
d.rodman's unique profile entires might look something like this:
index_littlethings: 78 //high willingness to the dirty work
index_bruiser: 80 //loved to mix it up
index_courtsense: 80 //uncanny ability to be in the right place
index_sporting: 30 //was a hugh jass type pain
he was the leagues leading rebounder for an extended perid of time. rebounding draws on court sense and a very developed sense of a few technical elements, it also requires a willingness to be banged into and to bang into people. these, coupled with the requisite physical build, d.rodman had in abundance. he was also a kook. the chicago bulls had an 'all business' demeanor akin to the san francisco 49'ers, and rodman was held in check by michael jordan whose AI profile might look something like this:
index_captain: 90 //made his team better, by demanding a lot from them
index_m2sbr: 90 //earned alot, demanded alot, slow to give it back
index_courtsense: 85 //knew the gamne inside and out
index_inthezone: 85 //played at a very high level, almost always
index_pwned!: 85 //dominated a lot, and liked it
that's right folks, actually takes 5 variables to even come close to describing what m.jordan brought to the game psychologically, and all of these values were necessary to offset (rein in) the eccentric behavior of d.rodman.
We'll want to try lots of combinations to flesh out the 18 to 24 teams we'll be building and editor with an intuitive interface that allows for easy experimentation will help immensely. it will also provide the starting point for our extensibility model.
the editor
using one of the standard color selection interfaces available in many applications, a familiar interface to computer savvy types, we'll be able to select ai profiles for a bot on a by color basis.
a player selecting in the green range would the be operating in the range between yellow and blue. feedback for these values must occur in real time to reveal the logic of the organization to the user. our own hierarchical organization and default clustering of values will require some definition prior to final implementation.
providing a color wheel interface for tge could allow us to expand the implementation to other areas, such as sky, fog and so on.
further refinement would be available through the use of a 'curves' like interface. this is present in some forms already within the tge terrain editor. using this curves interface the user would be able to effect teh values associated with each profile entry, higher or lower.
rhetorical questions
do the values associated with unique entries in a bots ai profile modify other values, do they express themselves independently, or are both at issue?
My to do list
1. screenshots of existing apps for reference
2. composites of ui
***
The sort of editor described here could allow map makers or scripters to intuitively add flavor to the bots that Justin described above when used in conjunction with his pathfinding code.
until someone volunteers to help me build such a thing though, look for some presentation of our Pathfinding Code ASAP - probably toward the end of this week.
#23
Terrain Reasoning for 3D Action Games
That's what I mean by nodes and doing graph navigation. Now covering a Torque map with nodes like that is unnecessassary. I think shortest path graph navigation is O(n^2) (something tells me is O( log something )) In any case, doing that kind of an algorithm, and also factoring in the possibility of changing it's destination, or following something...that's really not an idea solution at all.
02/19/2002 (2:38 pm)
By nodebased navigation, I meant the typical blanketing the navigatable area with nodes, then when you get a command to go to a coordinate (or area) you find the node closest to that coordinate, and then navigate to that node via a shortest path algorithm. For an example of what I mean:Terrain Reasoning for 3D Action Games
That's what I mean by nodes and doing graph navigation. Now covering a Torque map with nodes like that is unnecessassary. I think shortest path graph navigation is O(n^2) (something tells me is O( log something )) In any case, doing that kind of an algorithm, and also factoring in the possibility of changing it's destination, or following something...that's really not an idea solution at all.
#24
I'm really looking forward to see some of your code or a short tutorial of you guys (especially for pathfinding)!
Your game sounds like fun, any ideas when there will be a playable demo??
Such an AI editor would be an enourmous help for everyone here, I think - I bet there are many people in this community willing to help with such an AI system... if I can do anything, let me know!
Would be great to have a configurable editor which can easily be ported to other games/genres...
Like you and Pat said, it probably wouldn't be the best solution to work with hundreds of nodes spread in the level by a level designer (I think I'm going to read this gamasutra article today, sounds very interesting) - just think of outdoor enviroments that get changed with the terrain editor - how would you set your navigation nodes for that? Could be a big overhead and probably generates more problems than it solves...
Although I don't have much better ideas at the moment... :-(
(By the way, can the TGE waypoints be used for setting the path of a bot? How can I use them?)
But I'm sure it will help to see some of your ideas and code and to dig deeper into the Torque code - which I really have to to push this AI thing...
So it would be really great if you could share some of your AI and pathfinding know-how with the community! I'm really looking forward to it!
Does anybody know how all this was done in TRIBES 2?? I mean, it HAS bots, and they are not stupid - they find their way through the terrain, they attack you, etc. So there must be a not too complicated solution to re-implement stuff like that...?!
Later, Stefan
02/19/2002 (10:48 pm)
Wow, thanks Mychal, that was quite a lot of stuff!!I'm really looking forward to see some of your code or a short tutorial of you guys (especially for pathfinding)!
Your game sounds like fun, any ideas when there will be a playable demo??
Such an AI editor would be an enourmous help for everyone here, I think - I bet there are many people in this community willing to help with such an AI system... if I can do anything, let me know!
Would be great to have a configurable editor which can easily be ported to other games/genres...
Like you and Pat said, it probably wouldn't be the best solution to work with hundreds of nodes spread in the level by a level designer (I think I'm going to read this gamasutra article today, sounds very interesting) - just think of outdoor enviroments that get changed with the terrain editor - how would you set your navigation nodes for that? Could be a big overhead and probably generates more problems than it solves...
Although I don't have much better ideas at the moment... :-(
(By the way, can the TGE waypoints be used for setting the path of a bot? How can I use them?)
But I'm sure it will help to see some of your ideas and code and to dig deeper into the Torque code - which I really have to to push this AI thing...
So it would be really great if you could share some of your AI and pathfinding know-how with the community! I'm really looking forward to it!
Does anybody know how all this was done in TRIBES 2?? I mean, it HAS bots, and they are not stupid - they find their way through the terrain, they attack you, etc. So there must be a not too complicated solution to re-implement stuff like that...?!
Later, Stefan
#25
Pat, doesn't sound like you have the time to work out your ideas in the path finding arena. I was going to attack the problem similar to how you suggested, blanketing the terrain with navigation nodes or markers. Treating interiors and terrain the same may work. I was going to drop the nodes into our interiors manually for now.
Still need to prove these theories however.
Another important core feature IMHO is tasks. Tribes 2 had an interesting system of assigning tasks and weighting them for AI processing.
WRT sharing what I have done so far, I don't have a problem with that at all. I would be happy to contribute the generic AI features I've built in. Everything is still a work in progress at this point and needs to be play tested and tweaked for sure.
02/20/2002 (7:15 am)
I think we should start at the lowest common denominator and work our way up. For instance, detailed attributes and personality profiles may be too specific for everyones game idea but not necessarily. I'm interested to see what everyone has come up with.Pat, doesn't sound like you have the time to work out your ideas in the path finding arena. I was going to attack the problem similar to how you suggested, blanketing the terrain with navigation nodes or markers. Treating interiors and terrain the same may work. I was going to drop the nodes into our interiors manually for now.
Still need to prove these theories however.
Another important core feature IMHO is tasks. Tribes 2 had an interesting system of assigning tasks and weighting them for AI processing.
WRT sharing what I have done so far, I don't have a problem with that at all. I would be happy to contribute the generic AI features I've built in. Everything is still a work in progress at this point and needs to be play tested and tweaked for sure.
#26
So why not start with some "universal pathfinding" stuff based on the node/waypoint idea (I think this Gamasutra article could be really helpful - I will read it soon, I promise ;-) And I'm desperately waiting for this "AI Game Prog. Wisdom" book by Steve Rabin (who wrote some cool articles for Game Prog. Gems, too)... So let's get ready ;)
02/20/2002 (11:39 am)
Ryan, sounds good to me! Maybe you could post the stuff you guys developed somewhere (maybe in a little "ressource" article :-) and we could take that as a start. I'm sure there are issues everybody WILL need as far as AI is concerned - we should try to make it as modular as possible, to be able to use it in almost every type of game, be it a sports game, a RPG, FPS or whatever...So why not start with some "universal pathfinding" stuff based on the node/waypoint idea (I think this Gamasutra article could be really helpful - I will read it soon, I promise ;-) And I'm desperately waiting for this "AI Game Prog. Wisdom" book by Steve Rabin (who wrote some cool articles for Game Prog. Gems, too)... So let's get ready ;)
#27
02/20/2002 (12:09 pm)
Re-read my previous posts in this thread please. I was *not* supporting 100% graph based pathing, quite the opposite.
#28
Well, here's something to start with:
- Overview/links at www.red3d.com/breese/navigation.html
- Different algorithms (mainly A*), with considerations of terrain (hills, forests, roads, etc.), looks pretty cool: theory.stanford.edu/~amitp/GameProgramming/
- Smart Unit Navigation (A* again...): home.sol.no/~johncl/shorpath.htm
- robots navigation through unknown terrain, D* algorithm
www.frc.ri.cmu.edu/~axs/
- different algorithms, mainly A*, with sourcecode, examples and tuts: gslconcept.virtualave.net./
- "An optimal pathfinder for vehicles in real-world digital terrain maps" - with doc file for download: www.student.nada.kth.se/~f93-maj/pathfinder/index.html
Or you could simply go here: www-cs-students.stanford.edu/~amitp/gameprog.html, there you can find almost all these links :-8
Two more to add ;-)
- www.red3d.com/cwr/steer/ deals with "Steering Behaviors For Autonomous Characters" and looks very interesting!
- great algorithms collection, including pathfinding of course gpp.netfirms.com/cgi-bin/index.cgi?algorithms
That's it for now, maybe there's something we can use to start with - I will scan through these docs tomorrow, maybe I'm a bit wiser then...
02/20/2002 (12:50 pm)
Yep, I got you... I'm currently searching for alternatives, and I already came about some cool sites... think I will post some links later on so that you guys can have a look at them, too... But doesn't the Gamasutra article come up with some cool ideas about some kind of "automated" pathfinding ... they're not only talking about manually set waypoints, do they? I really should read it now... ;-) Later!Well, here's something to start with:
- Overview/links at www.red3d.com/breese/navigation.html
- Different algorithms (mainly A*), with considerations of terrain (hills, forests, roads, etc.), looks pretty cool: theory.stanford.edu/~amitp/GameProgramming/
- Smart Unit Navigation (A* again...): home.sol.no/~johncl/shorpath.htm
- robots navigation through unknown terrain, D* algorithm
www.frc.ri.cmu.edu/~axs/
- different algorithms, mainly A*, with sourcecode, examples and tuts: gslconcept.virtualave.net./
- "An optimal pathfinder for vehicles in real-world digital terrain maps" - with doc file for download: www.student.nada.kth.se/~f93-maj/pathfinder/index.html
Or you could simply go here: www-cs-students.stanford.edu/~amitp/gameprog.html, there you can find almost all these links :-8
Two more to add ;-)
- www.red3d.com/cwr/steer/ deals with "Steering Behaviors For Autonomous Characters" and looks very interesting!
- great algorithms collection, including pathfinding of course gpp.netfirms.com/cgi-bin/index.cgi?algorithms
That's it for now, maybe there's something we can use to start with - I will scan through these docs tomorrow, maybe I'm a bit wiser then...
#29
R
index_aggression // self explanatory
index_vengeance // reacts to fallen comrade
...
G
index_fear // likelihood of retreating
index_erratic // likelihood of going berzerk
...
B
index_leadership // bolstering influence over high fear expressers
index_loyalty // protects injured comrades
...
I think most games will struggle with representing these very basic ideas, and that an interface to generate them would be worth while.
The sticky wicket here is agreeing on expression of these ideas. A basic set of values regardless of the associated behaviour could be instructive though. After Rodrigo and i get our code presentable, I'll shift our team's efforts in this direction.
Any assistance or pointers that someone could provide w/ re: to the interface development end of this would be a great help.
I'm in complete agreement w/ re: to assigning tasks. I'm not sure when we'd be getting to this but as our roadmap becomes more clear I'll keep the group posted.
PS - Got my AI-Implant Beta today, they are still being coy about the price point but I'll keep you posted. ;]
02/21/2002 (8:55 am)
The example of a Personality Profile Range I provided above was awfully specific. Let's look at it with the following values though:R
index_aggression // self explanatory
index_vengeance // reacts to fallen comrade
...
G
index_fear // likelihood of retreating
index_erratic // likelihood of going berzerk
...
B
index_leadership // bolstering influence over high fear expressers
index_loyalty // protects injured comrades
...
I think most games will struggle with representing these very basic ideas, and that an interface to generate them would be worth while.
The sticky wicket here is agreeing on expression of these ideas. A basic set of values regardless of the associated behaviour could be instructive though. After Rodrigo and i get our code presentable, I'll shift our team's efforts in this direction.
Any assistance or pointers that someone could provide w/ re: to the interface development end of this would be a great help.
I'm in complete agreement w/ re: to assigning tasks. I'm not sure when we'd be getting to this but as our roadmap becomes more clear I'll keep the group posted.
PS - Got my AI-Implant Beta today, they are still being coy about the price point but I'll keep you posted. ;]
#30
Ryan, I'm going to work up a few initial idea's this weekend.
Specifically.. I'm adding spline and linear paths to the Pathmanager AND an editing interface into the world editor.
So I'll have that done by this weekend hopefully. Which will be at least a starting point (in that we can then add paths, which is already partially in the engine).
From there, what else do we need? get the bot to follow a path, or scan for paths local to it?
That should get us underway at least.
Phil.
02/21/2002 (2:47 pm)
Guys, we need to sort out the "basics" as Ryan said.Ryan, I'm going to work up a few initial idea's this weekend.
Specifically.. I'm adding spline and linear paths to the Pathmanager AND an editing interface into the world editor.
So I'll have that done by this weekend hopefully. Which will be at least a starting point (in that we can then add paths, which is already partially in the engine).
From there, what else do we need? get the bot to follow a path, or scan for paths local to it?
That should get us underway at least.
Phil.
#31
I totally agree that we need to sort out the basics and I'm currently searching for inputs how to get a basic AI concept, mainly for pathfinding - this Word document is really good, everyone interested in that area should check it out: www.student.nada.kth.se/~f93-maj/pathfinder/PathFinder.zip.
I think, waypoints (or whatever we call them) are a good start to bring some intelligence into our levels and bots - scanning for nearby points to "attach" to the next path in a desired direction and follow it in a somewhat realistic movement would be a first "milestone", I think... Maybe we can do a little brainstorming at the beginning of next week and then go for it? I won't have much time though, gotta move into a new apartment with my girlfriend...
02/21/2002 (3:09 pm)
Phil, sounds like a good start to me!I totally agree that we need to sort out the basics and I'm currently searching for inputs how to get a basic AI concept, mainly for pathfinding - this Word document is really good, everyone interested in that area should check it out: www.student.nada.kth.se/~f93-maj/pathfinder/PathFinder.zip.
I think, waypoints (or whatever we call them) are a good start to bring some intelligence into our levels and bots - scanning for nearby points to "attach" to the next path in a desired direction and follow it in a somewhat realistic movement would be a first "milestone", I think... Maybe we can do a little brainstorming at the beginning of next week and then go for it? I won't have much time though, gotta move into a new apartment with my girlfriend...
#32
Pat: i agree that the blanket use of nodes all over a map wouldnt be useful, however I think that if you look at a map, most of it is passable, so some form of helper node which weights a specific path through a problem area would be useful.
Perhaps we could use a quadtree approach to the AI as well as the terrain (basically, localise any pathing searches to help optimise).
One thing that Ive been thinking, is that in most cases, AI wouldnt want to traverse the whole map in one path. Or if they did, it could be broken into sub paths.
Essentially, pathing in these terms, to my mind, mean reducing the map space into "usable" paths, i.e. reasonable terrain with reasonable safety (i.e. not along a ridge line). Perhaps we need to add some kind of quadtree based terrain weighting system, where instead of painting textures, we paint a weight of how "passable" or "desirable" an area of terrain is.
Anyway, barring the theory, we need to make some solid steps. Ryan, perhaps you could do the honours and try and do us a rough breakdown of required functionality, then we can make a start on implementation. Start with pathfinding and work up i guess. Pats already gotten the spawn code in. I believe someone already worked out how to make the current AI move a player along a predefined path. So its a matter of working from there outwards.
Perhaps whilst some of us look at that, another group can take a look at actually adding behavior to the AI bot (apart from pathfinding).
Phil.
02/21/2002 (3:36 pm)
Stefan: I should hope the AI wisdom book is good, I'm a co-author :)Pat: i agree that the blanket use of nodes all over a map wouldnt be useful, however I think that if you look at a map, most of it is passable, so some form of helper node which weights a specific path through a problem area would be useful.
Perhaps we could use a quadtree approach to the AI as well as the terrain (basically, localise any pathing searches to help optimise).
One thing that Ive been thinking, is that in most cases, AI wouldnt want to traverse the whole map in one path. Or if they did, it could be broken into sub paths.
Essentially, pathing in these terms, to my mind, mean reducing the map space into "usable" paths, i.e. reasonable terrain with reasonable safety (i.e. not along a ridge line). Perhaps we need to add some kind of quadtree based terrain weighting system, where instead of painting textures, we paint a weight of how "passable" or "desirable" an area of terrain is.
Anyway, barring the theory, we need to make some solid steps. Ryan, perhaps you could do the honours and try and do us a rough breakdown of required functionality, then we can make a start on implementation. Start with pathfinding and work up i guess. Pats already gotten the spawn code in. I believe someone already worked out how to make the current AI move a player along a predefined path. So its a matter of working from there outwards.
Perhaps whilst some of us look at that, another group can take a look at actually adding behavior to the AI bot (apart from pathfinding).
Phil.
#33
It seems that Ryan, yourself, and myself will all have some sort of path code to throw into the mix by weeks end give or take.
Looking forward to it...
02/21/2002 (4:37 pm)
Phil, just to reiterate... my first priority is making my team's spline code clean and available, my second priority will be to do the same with the squad-based interaction code as I mentioned above.It seems that Ryan, yourself, and myself will all have some sort of path code to throw into the mix by weeks end give or take.
Looking forward to it...
#34
Yes, I'd like to get us working on a core codebase to support the higher level layers.
If we start out be making available our path creation tools and see what we can make out of each (perhaps there are some good and bad points of each where we can make a single codebase that incorporates all the best points).
Once we have a toolkit for adding paths, then there are two goals, 1) is having the current "bot" follow the paths, I'd like to suggest that we extend that concept to the creation of point and click interface that allows a "bot" or "unit" to navigate from wherever they are on the map, to another coordinate (somewhere clicked on the map, ala an RTS) this will give us a reasonably good test of the pathing system.
Second objective I see, is to start adding some form of weighting system to the paths, or even a path generation system, so that we dont have to manually place waypoints or paths for the AI. Some kind of cost analysis on the terrain (that would be game specific) should be evaluated per map grid space, so that the terrain can be evaluated for suitability. We then add some weighted information into the generated paths to allow the bots a choice of path. Finally, we extend that system to allow dynamic obstacles and attractions (for instance, spawn in health and have the bot go for it).
Can anyone think of anything else for basic navigation?
I see it as:
1) Fixed path following
2) Following generated paths
3) Allow weightings of paths depending on circumstances
4) Allow overriding of paths based on dynamic entities
The "proof" of this system, is to have a bot traverse from one point on the map to another with complex terrain in between, avoiding threats whilst collecting rewards. I think that should be our first major milestone effort.
Any thoughts?
Phil.
02/22/2002 (10:39 am)
Mychal,Yes, I'd like to get us working on a core codebase to support the higher level layers.
If we start out be making available our path creation tools and see what we can make out of each (perhaps there are some good and bad points of each where we can make a single codebase that incorporates all the best points).
Once we have a toolkit for adding paths, then there are two goals, 1) is having the current "bot" follow the paths, I'd like to suggest that we extend that concept to the creation of point and click interface that allows a "bot" or "unit" to navigate from wherever they are on the map, to another coordinate (somewhere clicked on the map, ala an RTS) this will give us a reasonably good test of the pathing system.
Second objective I see, is to start adding some form of weighting system to the paths, or even a path generation system, so that we dont have to manually place waypoints or paths for the AI. Some kind of cost analysis on the terrain (that would be game specific) should be evaluated per map grid space, so that the terrain can be evaluated for suitability. We then add some weighted information into the generated paths to allow the bots a choice of path. Finally, we extend that system to allow dynamic obstacles and attractions (for instance, spawn in health and have the bot go for it).
Can anyone think of anything else for basic navigation?
I see it as:
1) Fixed path following
2) Following generated paths
3) Allow weightings of paths depending on circumstances
4) Allow overriding of paths based on dynamic entities
The "proof" of this system, is to have a bot traverse from one point on the map to another with complex terrain in between, avoiding threats whilst collecting rewards. I think that should be our first major milestone effort.
Any thoughts?
Phil.
#35
i basicly got a monster.dts that can be used fro a reference and dose get ingame through f11 and static shapes as seen in this ss ,,,coverted from a q2 monster,any one is welcome to use for testing.
itll be next week be fore i get back into this (when i get back to my reg hours)
02/22/2002 (12:45 pm)
heh, start at the very beginning, like adding bot spawnpoints and an option for how many bots to spwan in the options menu, this is a must and is somthing i am looking into for my monster ai (once i get back to my regular schedule (been hell for me the last 2 weeks)).i basicly got a monster.dts that can be used fro a reference and dose get ingame through f11 and static shapes as seen in this ss ,,,coverted from a q2 monster,any one is welcome to use for testing.
itll be next week be fore i get back into this (when i get back to my reg hours)
#36
Sounds like a reasonable plan, though...
It would be cool if a basic "terrain weighting" function could be implemented like the terrain texturing tool in TGE - you could simply add "terrain cost" by slope or terrain quality, for example, or assign attributes to static shapes, lakes (e.g. "penalty=70"), etc. and the AI would try to keep away from the highest mountains, search paths across rivers, etc.
In addition - if someone wants to - you could manually place ideal paths/waypoints in your terrain or mark complete parts of your maps as "impassable", etc.
But I think the order and emphasis given in your roadmap should be the way to go - start with the bots simple following given paths, then finding shortest paths to specific places, everything nicely accessible through the GUI... up to path splitting and recalculation for dynamicly moving obstacles etc.
02/22/2002 (2:56 pm)
Phil, you're a co-author of this book? cool!! Now I'm quite confident we can get a hold of this AI stuff in TGE... :-))Sounds like a reasonable plan, though...
It would be cool if a basic "terrain weighting" function could be implemented like the terrain texturing tool in TGE - you could simply add "terrain cost" by slope or terrain quality, for example, or assign attributes to static shapes, lakes (e.g. "penalty=70"), etc. and the AI would try to keep away from the highest mountains, search paths across rivers, etc.
In addition - if someone wants to - you could manually place ideal paths/waypoints in your terrain or mark complete parts of your maps as "impassable", etc.
But I think the order and emphasis given in your roadmap should be the way to go - start with the bots simple following given paths, then finding shortest paths to specific places, everything nicely accessible through the GUI... up to path splitting and recalculation for dynamicly moving obstacles etc.
#37
02/22/2002 (3:26 pm)
If you guys do in-editor path editing, could you do me a favor and make the actual spline types as derived classes? I have my own 'spline' code I am working on, and there are several types of splines and curve algorithms that may be attractive to other teams. By using inheritance etc, new interpolation techniques could be dropped in.
#38
The pathmanager thats already in there is a funny beast, obviously at some point someone had the intention of adding more than just linear paths, but it got thrown out i guess (there is a pathnode defined, but its not used).
I keep getting the feeling that the pathmanager should be derived from simgroup, as its a group of nodes (much like waypoints or markers).
Phil.
02/24/2002 (2:56 am)
Tim, Yes, no problem, all the pathing code should do is define the knot points, although it will have to store some other information (stuff like TCB info).The pathmanager thats already in there is a funny beast, obviously at some point someone had the intention of adding more than just linear paths, but it got thrown out i guess (there is a pathnode defined, but its not used).
I keep getting the feeling that the pathmanager should be derived from simgroup, as its a group of nodes (much like waypoints or markers).
Phil.
#39
simpath is basically a simgroup with markers as nodes. As far as i can tell, this is used as the editing interface for paths, as the actual path is stored in pathmanager.
So essentially, first task is to get simpath editing into the interface. Shouldnt be too tricky.
Then again, how does this get created from the missions.. ahh, there is a onLoadMissionPaths or something..
Phil.
02/24/2002 (3:08 am)
Well bugger me, it IS a simgroup!simpath is basically a simgroup with markers as nodes. As far as i can tell, this is used as the editing interface for paths, as the actual path is stored in pathmanager.
So essentially, first task is to get simpath editing into the interface. Shouldnt be too tricky.
Then again, how does this get created from the missions.. ahh, there is a onLoadMissionPaths or something..
Phil.
#40
Any news at the AI / pathing front? Any useable stuff in the simPath / pathManager code?
I'm still busy with moving into a new apartment, so I don't even have time to read through the code... :-(
Mychal, how is it going with your AI stuff?
Hopefully I've got some more time next week ... it's really hard to live without my daily "torquing"... ;-)
Later!
02/26/2002 (12:27 pm)
Hi Phil et al!Any news at the AI / pathing front? Any useable stuff in the simPath / pathManager code?
I'm still busy with moving into a new apartment, so I don't even have time to read through the code... :-(
Mychal, how is it going with your AI stuff?
Hopefully I've got some more time next week ... it's really hard to live without my daily "torquing"... ;-)
Later!
Associate Stefan Beffy Moises
So maybe Ryan and Mychal have something for us... or is anybody else working on these "basic" (they're not really basic, I fear...) AI issues at the moment?
If not, how could we organize the work on that? I guess, 99% of the Torque users are interested in getting AI stuff, so it should be a major concern...
Any volunteers out there ;)? I'm a volunteer, though... but I started working with Torque two weeks ago, so I'm not THAT much into the code yet... any help appreciated!