Thread: Re: [TuxKart-devel] Ideas for AI (Page 2)
Status: Alpha
Brought to you by:
sjbaker
Menu
▾
▴
tuxkart-devel
|
From: Ryan F. <rf...@gm...> - 2004-06-30 06:53:53
|
One thing that I think is important is that we should have checkpoints (and visual representation for them). Checkpoints are important for AI because they are subgoals to passing each lap. -- Ryan |
|
From: Flash <fl...@da...> - 2004-06-30 09:40:57
Attachments:
layout.jpg
|
Attached is a graphical layout picture of what it could be, on the map th= e yellow line is the 'perfect line' the green dots on it are waypoints (points of high interest) the darker green dots could represent 'good' herring whereas the red dots represent 'bad' herring or other interruptions on the road, the red lines around the track are ofcourse points of non-interesest just places where you dont wanna be because youl= l hit the side (dont know if thats important but maybe you would like to have something in there if carts bump or so that it watches out for the side, could ofcourse slip in there but the kart will try to make it out a= s soon as possible. The green and black dots are 'non-active' waypoints, eg the AI will ignore those. once the kart reaches the first green waypoint that one could go disabled and the next black dot goes enabled. you could make some sort of collision detection system around the waypoints that when a kart is near the next one becomes active, so the AI doesnt actuall= y have to drive over. <quote who=3D"Ryan Flegel"> > One thing that I think is important is that we should have checkpoints > (and visual representation for them). Checkpoints are important for AI > because they are subgoals to passing each lap. > > -- > Ryan > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > digital self defense, top technical experts, no vendor pitches, > unmatched networking opportunities. Visit www.blackhat.com > _______________________________________________ > Tuxkart-devel mailing list > Tux...@li... > https://lists.sourceforge.net/lists/listinfo/tuxkart-devel > =3D=3D=3D=3D http://www.daaw.org - webhosting http://www.gamesleague.com - Games, servers, leagues and more |
|
From: Steve B. <sjb...@ai...> - 2004-06-30 12:01:49
|
Good - so it sounds like you AI guys are on the right track and you know who you all are. Why don't you take the detailed discussion off-list for a while and come back with a concrete proposal? Then if nobody here can poke any serious holes in it, you guys can start writing code. The AI code should probably be hooked into the KartDriver and Driver classes and generate commands similar to those generated by human players from the PlayerDriver class. The track centerline that we have now is the obvious place to expand out your waypoint stuff - and that is in the Track class. We should probably move the '.drv' file loader out of 'tuxkart.cxx' and into the Track.cxx file. I'll do that now. ---------------------------- Steve Baker ------------------------- HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- |
|
From: Steve B. <sjb...@ai...> - 2004-06-30 12:13:42
|
Oliver Jeeves wrote: > On another note, I think the 'array of arrows' method could _possibly_ be > improved by instead of having a huge array, splitting the map into 'areas' > and having directions assigned to each of these areas. If you had an array, > many adjacent arrows would be pointing in the same direction, and there would > be a lot of duplicate information. I have attached another diagram. The > question is whether using this method, you could cut down the amount of areas > significantly enough so that the extra information used to store the > boundaries of the areas doesn't make it less efficient... WOW! That's an interesting idea because we could create those polygons in a modelling tool using the texture coordinates to represent the 'arrow' direction. You could make up a texture with lots of arrows painted on it and use the texturing tool in the modeller to point the arrows where you think the AI should drive. Then the (u,v) deltas on the polygon could be loaded by TuxKart and converted into a direction number. The existing collision detection code could then figure out which polygon the kart is sitting on each frame (or however often we run the AI decisionmaking). This gets over both the storage issue AND the 'how do I build it' issue for the vector field approach...and it leverages existing tools, existing loaders and existing collision detection stuff. What's better still is that this additional polygon mesh can be fully 3D so that bridges will naturally fall out of the same mechanism. Even more than that, if this is a fully legit 3D model, it could be animated in sync with the 'visual' model so my idea of the track changing as the game progresses is possible. Also, track builders (who may not be programmers) would be able to understand it easily enough. Interesting! I still like this idea better than waypoints because it explicitly tells the AI which direction to head in - so no matter what, he can ALWAYS get out of a jam of any kind...and it's very easy to understand. ---------------------------- Steve Baker ------------------------- HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- |
|
From: Charles G. <ch...@ve...> - 2004-06-30 13:19:23
|
On Wed, 2004-06-30 at 07:15 -0500, Steve Baker wrote: > I still like this idea better than waypoints because it explicitly tells > the AI which direction to head in - so no matter what, he can ALWAYS > get out of a jam of any kind...and it's very easy to understand. Yeah, it's a great compromise. I like it a lot! -- - Charlie Charles Goodwin <ch...@ve...> Online @ www.charlietech.com |
|
From: Jacob P. <st...@ap...> - 2004-06-30 14:28:28
|
On Wednesday 30 June 2004 11:58, Oliver Jeeves wrote: > On another note, I think the 'array of arrows' method could _possibly_ be > improved by instead of having a huge array, splitting the map into 'areas' > and having directions assigned to each of these areas. If you had an array, > many adjacent arrows would be pointing in the same direction, and there > would be a lot of duplicate information. I have attached another diagram. > The question is whether using this method, you could cut down the amount of > areas significantly enough so that the extra information used to store the > boundaries of the areas doesn't make it less efficient... I like that approach, it's very simular to an approach described in an article by Gari Biasillo in 'Game Programming Wisdom'. In that article each sector get values attached to them depending on for example if they have powerups or if the terrain is good or bad (like the mud in mariokart). The AI would then use this information by looking ahead so that it could make good decisions for example when it comes up to a split route. -- Name: Jacob Persson Homepage: www.apollo.nu/~straver/ |
|
From: Flash <fl...@da...> - 2004-06-30 14:39:12
|
<quote who=3D"Jacob Persson"> > On Wednesday 30 June 2004 11:58, Oliver Jeeves wrote: >> On another note, I think the 'array of arrows' method could _possibly_ >> be >> improved by instead of having a huge array, splitting the map into >> 'areas' >> and having directions assigned to each of these areas. If you had an >> array, >> many adjacent arrows would be pointing in the same direction, and ther= e >> would be a lot of duplicate information. I have attached another >> diagram. >> The question is whether using this method, you could cut down the amou= nt >> of >> areas significantly enough so that the extra information used to store >> the >> boundaries of the areas doesn't make it less efficient... > > I like that approach, it's very simular to an approach described in an > article > by Gari Biasillo in 'Game Programming Wisdom'. > > In that article each sector get values attached to them depending on fo= r > example if they have powerups or if the terrain is good or bad (like th= e > mud > in mariokart). The AI would then use this information by looking ahead= so > that it could make good decisions for example when it comes up to a spl= it > route. > > -- > Name: Jacob Persson > Homepage: www.apollo.nu/~straver/ You can probably go a step further into that, by making desitions. if on field 50 (connected to 51, 52, 53 with items 101, 102 and 104 (where 104 is 'bad') deside wether to go for certain items (101, or 102) or move to the next field (51, 52 or 53) and try to avoid the bad item (104) as you go along. =3D=3D=3D=3D http://www.daaw.org - webhosting http://www.gamesleague.com - Games, servers, leagues and more |
|
From: Steve B. <sjb...@ai...> - 2004-06-30 23:40:49
|
Charles Goodwin wrote:
> I was really (in my mind) giving double-meaning to waypoints, not just
> associating them with single points but also with areas. Your diagrams
> are an exact illustration of how I visualised it.
Cool - so it looks like we are all in basic agreement.
Let's flesh it out a little so we're all on the same page:
1) In addition to the 'visual' model of each track, we make a separate
'AI' model. The two will in general cover the same area of ground
- but the AI model will usually be *way* simpler...fewer polygons
that is.
2) For the purposes of visualising this model in blender (or whatever)
and when debugging - we make a texture map with a bunch of arrows
pointing up the map. In ASCI art: [^^^] :-)
3) In the modeller (blender, whatever) our track designers apply the
arrow-map to each polygon to reflect the general direction a Kart
should be driving whilst driving over that polygon. We could also
vary the SCALE of the texture in the S and T directions to provide
additional data (eg: The longer the arrows, the faster the kart
should attempt to go - the fatter the arrows, the more laxity the
kart is allowed in choosing a direction. (eg when crossing a narrow
bridge - short, skinny arrows mean drive slowly and stick closely
to the desired direction. Long skinny arrows make him drive faster
but stay on target, long, fat arrows mean you can drive fast but
you don't have to stay accurately on direction if there are powerups
nearby.) We can probably use the colour of the polygon to store
yet more data, etc, etc.
4) The game loads this AI model at the same time as the visual model.
The (s,t) texture coordinate at each polygon vertex can then be
used to reconstruct the direction that the arrow map was pointing
and turn that into a 'heading' number for each polygon (and a speed
and turn 'laxity'. This should be saved along with the polygon for
future reference.
5) As the game runs collision detection on the visual model, so it'll
also run collision detection on the AI model. PLIB can return the
data for whichever polygons are vertically beneath the kart. The
nearest one of those will provide the 'ideal direction' indication
to the AI software for the following frame.
--
---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net http://tuxaqfh.sf.net
http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----
|
|
From: Charles G. <ch...@ve...> - 2004-07-01 01:10:49
|
On Wed, 2004-06-30 at 18:43 -0500, Steve Baker wrote: > 5) As the game runs collision detection on the visual model, so it'll > also run collision detection on the AI model. PLIB can return the > data for whichever polygons are vertically beneath the kart. The > nearest one of those will provide the 'ideal direction' indication > to the AI software for the following frame. As long as that doesn't confuse carts on jumps - don't want them turning mid-air. Other obstacles (loop-the-loops) also need to be thought of. Definitely on the right track (pun intended) with this one. ;) -- - Charlie Charles Goodwin <ch...@ve...> Online @ www.charlietech.com |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X