tuxkart-devel — TuxKart Developers.

Re: [TuxKart-devel] New Wiki created

[Steve B. <sjb...@ai...>]

Matze Braun wrote:
> Okay, I've setup another wiki on my berlios page:
> 
> http://netpanzer.berlios.de/tuxkart/index.php/HomePage

Good work!

I'm stuffing in as much content as I can from our discussions and elsewhere.

When writing WIKI pages, please try not to express only your own viewpoint
if something is still in debate.  People will read this and see it as fact,
so if you only present your side of the story, you are doing everyone a
mis-service.

---------------------------- 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-----

Re: [TuxKart-devel] GUI

[Oliver J. <ol...@po...>]

On Wed, Jun 30, 2004 at 07:23:41AM -0500, Steve Baker wrote:
> Because the mouse is a really nice pointing device (and a joystick
> sucks for accurate pointing because it's a relative motion device
> not an absolute position device) - so if you have a mouse, you can
> dispense with all those layer-upon-layer menu's with easily forgotten
> options.   It's much simpler IMHO to just lay out all the options
> on a single page and let the person see all of them.  They can verify
> that everything is how they want it - and when it is, click the "GO"
> button.

I think in this case, it's best not to think of Linux as purely a desktop 
operating system - think of those people who are putting together media 
computers for their living rooms etc. (admitedly, I wouldn't think there are 
too many of these). After sitting around with some friends playing some 
TuxKart, it seems a shame to force them to get up and find the mouse 
inbetween games as opposed to staying where they are and setting up the next 
game with whatever input device they happen to be holding at the time.

Obviously a joystick sucks as a pointing device, so joystick control should
just cycle through options - controling a pointer with a joystick is a bad
idea.

Re: [TuxKart-devel] Ideas for AI

[Flash <fl...@da...>]

<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

Re: [TuxKart-devel] Ideas for AI

[Jacob P. <st...@ap...>]

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/

Re: [TuxKart-devel] GUI

[Steve B. <sjb...@ai...>]

Ingo Ruhnke wrote:

> I hope so, constantly switching controlling devices just isn't
> something that will improve the experience, but just something that
> will annoy the player.

But on a PC, you were holding the mouse when you clicked the icon/menu
item to start the game running.  You'll have the mouse in your hand
still when it starts up.  Whether you switch to the joystick after
launching the program - or after setting the options within the
program is no different.

(The other reason game consoles like this approach is that the TV
has *crappy* resolution - about 640 horizontal by 512 vertically - but
since 1 pixel vertical features flicker, that's really only 256 vertically.
On such a low resolution screen, the graphical widgets have to be HUGE
in order to be legible.  Most of our users will be running anything from
1024x800 to 2048x1600 - so we don't have that problem).

> Beside that having the computer additionally attached to a TV is
> getting more an more popular, so having the game 'TV-ready', like a
> console game, would be strongly prefered, mice just don't navigate all
> that good on a couch.

Yeah - but people who do that have mouse-emulating devices on their
IR-connected keyboards.  (I have one for my Linux PVR PC which connects
to the TV so I know this for a fact).

>>We don't regard a joystick as a good GUI device for other
>>applications, why would we use if here?
> 
> Because there is only a rather limited number of options that the
> player has, just which game-mode (gp, time trial), which track, which
> character...

What?  No way!

Difficulty level?  (Easy, Medium, Hard)
How long should the race be?  (5 laps, 10, whatever)
How many players? (1, 2, 3, 4)
Player's name? (for high-score and game save options)
Network play? (and then someplace to enter the servername)
Mirror the track?  (Yes/No)
Reverse the track? (Yes/No)   [ie race anticlockwise instead of clockwise]
Music volume
Sound Effects volume

I'm sure we'll come up with others as time progresses.

With an all-in-one GUI, these are trivial things to add and maintain.

If it's separated out into separate questions then getting into the
game becomes tedious because you have to step through each screen
even if you are happy with the default.

The whole thing balloons from a real simple single-screen GUI to a major
programming exercise.  GoTM is a TWO MONTH TASK - we can't afford to waste
effort in areas that aren't buying us anything.

Adding new options to a single-screen menu is easy.

...all of this to support an unnecessary feature that many people don't
have (joysticks are dying out fast).

> The joystick/keyboard should be considered the primary input device
> for all of the GUI and so it should make sure that it works good and
> well and doesn't feel emulated or whatever (moving a pointer with the
> joystick and such). Mouse is something that is nice-to-have, but not
> something that anybody would miss if the game itself is 100% joystick
> controlled.

That's nonsense - probably more than half of our users don't even own
a joystick.  100% of people have a mouse (or a mouse emulated with a
trackball or something if they have a laptop or a 'TV controller').

You have it completely the wrong way around - the Mouse is *essential*,
the joystick is something that's nice to have.   There are MANY (if not
most) Linux games that don't support a joystick at all.

> The current GUI might be more or less functional, but it neither looks
> good nor feels 'right', just extending it with more widgets and stuff
> just isn't doing the game any justice.

You're right about that.  It needs to be prettied up with more graphics
and better layout.  But a full-scale redesign isn't needed IMHO.


---------------------------- 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-----

Re: [TuxKart-devel] GUI

[Robert K. <rob...@gm...>]

On Wed, 30 Jun 2004 07:23:41 -0500, Steve Baker <sjb...@ai...> wrote:

> Yeah - but we aren't as horribly limited as they are on a GameCube.
> 
> But do you think they'd still do it that way if they had a mouse
> attached to the system?

Yes they would, because players can't use a mouse when they're sitting
on the couch.  A gamepad is a device that fits in your hands and
affords full control of the game without the need for a desk and a
chair.

> We don't regard a joystick as a good GUI device for other applications,
> why would we use if here?

A game doesn't require a GUI of the same density as, say, a word
processor.  You shouldn't look at a simplified GUI as a limitation,
you should see it as a liberation.

> The main things it needs (IMHO) is a pictorial indication of the
> tracks rather than the present list of text names and a pictorial
> (preferable 3D, rotating slowly) image of the kart you have selected.

Exactly.  You don't have to have 100 widget types because you don't
need them.  What you've described here can be implemented with 1 type
of widget, in such a way that is easily controlled with only a D-pad
and a single button, in a style which has already been well
established by hundreds of games.

-- 
Robert Kooima

Re: [TuxKart-devel] Ideas for AI

[Charles G. <ch...@ve...>]

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

Re: [TuxKart-devel] GUI

[Ingo R. <gr...@gm...>]

Steve Baker <sjb...@ai...> writes:

>> Would a GameCube game use tiny scrollbars and radio buttons? No, it
>> would use big bold simple obvious widgets with gamepad control.
>
> Yeah - but we aren't as horribly limited as they are on a GameCube.
>
> But do you think they'd still do it that way if they had a mouse
> attached to the system?

I hope so, constantly switching controlling devices just isn't
something that will improve the experience, but just something that
will annoy the player.

Beside that having the computer additionally attached to a TV is
getting more an more popular, so having the game 'TV-ready', like a
console game, would be strongly prefered, mice just don't navigate all
that good on a couch.

> Because the mouse is a really nice pointing device (and a joystick
> sucks for accurate pointing because it's a relative motion device
> not an absolute position device)

Thats why you don't use a joystick as pointing device, but just have
widets to which you switch via up/down/left/right instead of
navigating a pointer to them manually.

> - so if you have a mouse, you can dispense with all those
> layer-upon-layer menu's with easily forgotten options. It's much
> simpler IMHO to just lay out all the options on a single page and
> let the person see all of them. They can verify that everything is
> how they want it - and when it is, click the "GO" button.

Having everything layed out on a single page is really a bad idea, it
will just lead to people forgetting to turn some option and such and
so having to quit go back to the menu again. Seperating all options
(track-select, player-select and such) to different screens will do a
much better job here.

> We don't regard a joystick as a good GUI device for other
> applications, why would we use if here?

Because there is only a rather limited number of options that the
player has, just which game-mode (gp, time trial), which track, which
character, rest is driving in game. The GUI should be keept as simple
as possible, there is no need to have screenfulls of buttons and
stuff.

> Well - it doesn't really matter. We can certainly make the joystick
> work the GUI if that's what everyone wants.

The joystick/keyboard should be considered the primary input device
for all of the GUI and so it should make sure that it works good and
well and doesn't feel emulated or whatever (moving a pointer with the
joystick and such). Mouse is something that is nice-to-have, but not
something that anybody would miss if the game itself is 100% joystick
controlled.

> Aside from improving the general look and layout of the GUI widgets
> (which is easily done) - I'm not sure I'd want to spend a lot of
> additional effort on it.

The current GUI might be more or less functional, but it neither looks
good nor feels 'right', just extending it with more widgets and stuff
just isn't doing the game any justice.

-- 
WWW:      http://pingus.seul.org/~grumbel/ 
JabberID: gr...@ja... 
ICQ:      59461927

[TuxKart-devel] New Wiki created

[Matze B. <ma...@br...>]

Okay, I've setup another wiki on my berlios page:

http://netpanzer.berlios.de/tuxkart/index.php/HomePage

I tried to setup some hirarchical strucure for the page and filled in some 
example texts about how the race shoudl starts and some TCP vs. UDP 
discussions. If you want to edit stuff then you have to login to the wiki 
(no registartation per e-mail stuff, just leave your name). Take a look 
at the "How To" page for details.

Greetings,
	Matze

Re: [TuxKart-devel] Ideas for AI

[Flash <fl...@da...>]

Looks like a damned good idea, the pictures really make it clear to, this
is what I tried to say with my picture to. I would just suggest on top of
your pictures add points of interest and points of non interest which wil=
l
be  the form of 'good' and 'bad' herrings so the AI can either try to go
around them or try to catch them on top of just following the arrows.

<quote who=3D"Oliver Jeeves">

> This is basically how I would have tried to tackle the problem, althoug=
h I
> don't think you've explained it as well as you could have (either that,=
 or
> you're describing something completely different, and I've misunderstoo=
d).
>
> Firstly, let me say that the 'array of arrows' type approach would work
> relativly well - it's the approach using in Micromachines, so it's prov=
en
> to
> work, although even Micromachines had its bugs. And I think this would
> have
> exactly the same problems on as figure-8 as there are currently.
>
> But anyway...
>
> I think having vectors as way points is a good idea. It can (and should=
)
> still be thought of in 2D; you have your line through the centre of the
> track, and crossing this line you have many waypoint lines [see attache=
d
> picture]. Rather then having the AI aim for particular points then, the
> best
> route (not taking into account powerups) is to find the shortest path
> through the next few way points.


=3D=3D=3D=3D
http://www.daaw.org - webhosting
http://www.gamesleague.com - Games, servers, leagues and more

Re: [TuxKart-devel] GUI

[Steve B. <sjb...@ai...>]

Robert Kooima wrote:

> Here's the distinction in our thinking: you're looking at it from an
> application GUI point of view.  I'm advocating looking at from a game
> GUI point of view.  Think of it as if you were programming for a
> console.  Would a GameCube game use tiny scrollbars and radio buttons?
>  No, it would use big bold simple obvious widgets with gamepad
> control.

Yeah - but we aren't as horribly limited as they are on a GameCube.

But do you think they'd still do it that way if they had a mouse
attached to the system?

Because the mouse is a really nice pointing device (and a joystick
sucks for accurate pointing because it's a relative motion device
not an absolute position device) - so if you have a mouse, you can
dispense with all those layer-upon-layer menu's with easily forgotten
options.   It's much simpler IMHO to just lay out all the options
on a single page and let the person see all of them.  They can verify
that everything is how they want it - and when it is, click the "GO"
button.

We don't regard a joystick as a good GUI device for other applications,
why would we use if here?

Well - it doesn't really matter.  We can certainly make the joystick
work the GUI if that's what everyone wants.

Aside from improving the general look and layout of the GUI widgets
(which is easily done) - I'm not sure I'd want to spend a lot of
additional effort on it.

The main things it needs (IMHO) is a pictorial indication of the
tracks rather than the present list of text names and a pictorial
(preferable 3D, rotating slowly) image of the kart you have selected.

---------------------------- 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-----

Re: [TuxKart-devel] Ideas for AI

[Steve B. <sjb...@ai...>]

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-----

Re: [TuxKart-devel] GUI

[Robert K. <rob...@gm...>]

On Tue, 29 Jun 2004 21:15:30 -0500, Steve Baker <sjb...@ai...> wrote:

> We could even make it so that either joystick *or* mouse
> would work - or both together.
> 
> But I'm still suprised you'd think that was important.

Here's the distinction in our thinking: you're looking at it from an
application GUI point of view.  I'm advocating looking at from a game
GUI point of view.  Think of it as if you were programming for a
console.  Would a GameCube game use tiny scrollbars and radio buttons?
 No, it would use big bold simple obvious widgets with gamepad
control.

-- 
Robert Kooima

Re: [TuxKart-devel] Ideas for AI

[Steve B. <sjb...@ai...>]

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-----

Re: [TuxKart-devel] Wiki for development plans

[Steve B. <sjb...@ai...>]

fl...@da... wrote:
> I can also set up some webspace on my (fast) rackservers, hosted in NL
> with full control to whoever wishes to be wiki admin.

OK - so why don't you and Ryan take this offline and report back when
you have something we can use.

Many thanks!

---------------------------- 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-----

Re: [TuxKart-devel] Ideas for AI

[Oliver J. <ol...@po...>]

On Wed, Jun 30, 2004 at 06:11:51AM +0000, Charles Goodwin wrote:
> 
>       |
>       |
>       |
> ______|_______
> 
> If your vector is (in this case) 'y', then what I refer to as the normal
> plane is that flat bottom line but extending outwards (ie along the 'z'
> axies) as well as across (ie along the 'x' axis).
> 
> If your two way points are roughly in a straight line (ie not too much
> of a difference between vector angles) then it's incredibly difficult to
> be closer to one vector without having cross the NP of said vector.

This is basically how I would have tried to tackle the problem, although I 
don't think you've explained it as well as you could have (either that, or 
you're describing something completely different, and I've misunderstood).

Firstly, let me say that the 'array of arrows' type approach would work 
relativly well - it's the approach using in Micromachines, so it's proven to 
work, although even Micromachines had its bugs. And I think this would have 
exactly the same problems on as figure-8 as there are currently.

But anyway...

I think having vectors as way points is a good idea. It can (and should)
still be thought of in 2D; you have your line through the centre of the
track, and crossing this line you have many waypoint lines [see attached
picture]. Rather then having the AI aim for particular points then, the best
route (not taking into account powerups) is to find the shortest path
through the next few way points.

This allows for the AI to use heuristics like 'going for a powerup is ok as 
long as I'm still heading towards the next waypoint'.

This will work with tracks that cross, as the waypoints are in order and the
AI can always head for the next one, and this method can also be extended to
take into account shortcuts.

Waypoints would have to be positioned so that any line between two adjacent 
waypoints does not hit any obsticle, and the waypoints need to go close 
enough to the edge of the track so that the AI can't 'miss' the waypoint and 
end up circling back.

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...

Re: [TuxKart-devel] Ideas for AI

[Flash <fl...@da...>]

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

Re: [TuxKart-devel] Wiki for development plans

[<fl...@da...>]

I can also set up some webspace on my (fast) rackservers, hosted in NL
with full control to whoever wishes to be wiki admin.

> On Tue, 29 Jun 2004 21:39:55 -0500, Steve Baker <sjb...@ai...>
> wrote:
>>
>> Ryan Flegel wrote:
>>
>> > Well, PhpWiki's website is a setup of PhpWiki on SF, so I think it
>> > should be possible somehow :)
>>
>> Do I hear a volunteer?
>
> Well, I can give it a shot if you like :) Or we can set it up on
> berlios as Matze suggested (faster  server).
>
> --
> 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
>

Re: [TuxKart-devel] Wiki for development plans

[Ryan F. <rf...@gm...>]

On Tue, 29 Jun 2004 21:39:55 -0500, Steve Baker <sjb...@ai...> wrote:
> 
> Ryan Flegel wrote:
> 
> > Well, PhpWiki's website is a setup of PhpWiki on SF, so I think it
> > should be possible somehow :)
> 
> Do I hear a volunteer?

Well, I can give it a shot if you like :) Or we can set it up on
berlios as Matze suggested (faster  server).

-- 
Ryan

Re: [TuxKart-devel] Ideas for AI

[Ryan F. <rf...@gm...>]

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

Re: [TuxKart-devel] Ideas for AI

[Aly M. <mer...@ac...>]

On Wed, Jun 30, 2004 at 12:35:13AM -0500, Steve Baker wrote:
>=20
> [ I'm playing devils advocate here - I want to discuss this some more
> to elicit deeper thinking without necessarily agreeing with everything
> I'm saying! ]
>=20
> Where a vector field really scores is when the polygonal
> representation of the track is very complex.   With any kind of
> waypoint representation, there is an underlying assumption that you
> can't get stuck behind a wall or something.  Preventing that from
> happening in the absence of other information is really hard.
>=20
> With waypoints, if I somehow get knocked off the road and there is a
> wall between me and the waypoint, I'm completely stuck.
>=20
> Similarly, if I'm somehow pushed off course and ended up somewhere
> where there is a shorter route to the waypoint-after-next than going
> to the next waypoint - then I'm probably going to mindlesslyy turn
> right around, drive to the waypoint that was supposed to be next and
> then take the long way to the waypoint after that.
>=20
> The vector field approach gives you a fast, reliable way to get out of
> any situation.  For any location on the map, you know simply and
> unambiguously how to get back to the racing line via the fastest
> possible route - even if you have to quite literally negotiate a maze
> to do it.

These are some of the problems I think the "optimum value" decision
making algorithm could address.  Walls are not things you want to
encounter so they radiate a negative value, and if the AI finds itself
face to face with a wall, it will notice that turning yields the optimum
value.  Now this probably wouldn't be as good as a fully tweaked vector
map, but I think it would be able to yield a decent racing line.

Also, you only need to calculate the values your possible destinations,
so making a turn, going forward and going backwards put you at a certain
destination and the value of a destination point can be calculated
fairly easily.  Waypoints would probably work their way in by being
points of interest which radiate positive values.

Also, if an algorithm like this is what you had in mind for generating
the vector field in the first place, then using this approach you would
only calculate the vectors you are interested in and you get things like
bonuses and enemy car information added in.  Whether this outweighs the
speed of having a ton of precomputed information available is another
matter.

Aly

Re: [TuxKart-devel] Ideas for AI

[Charles G. <ch...@ve...>]

On Wed, 2004-06-30 at 00:35 -0500, Steve Baker wrote:
> Where a vector field really scores is when the polygonal representation of
> the track is very complex.   With any kind of waypoint representation, there
> is an underlying assumption that you can't get stuck behind a wall or
> something.  Preventing that from happening in the absence of other
> information is really hard.
> 
> With waypoints, if I somehow get knocked off the road and there is a
> wall between me and the waypoint, I'm completely stuck.

Many, many games have AI for 3d path finding.  I refuse to believe it is
that difficult.

> Similarly, if I'm somehow pushed off course and ended up somewhere where
> there is a shorter route to the waypoint-after-next than going to the
> next waypoint - then I'm probably going to mindlesslyy turn right around,
> drive to the waypoint that was supposed to be next and then take the long
> way to the waypoint after that.

I get the feeling you just didn't read properly my comment on how to
avoid this with vector way points.

Use the vector's NORMAL PLANE to negate this.  I could be mixing
terminology here, so I'll do a little diagram:

if 'y' is up, 'x' is across, and 'z is out of the screen:

      |
      |
      |
______|_______

If your vector is (in this case) 'y', then what I refer to as the normal
plane is that flat bottom line but extending outwards (ie along the 'z'
axies) as well as across (ie along the 'x' axis).

If your two way points are roughly in a straight line (ie not too much
of a difference between vector angles) then it's incredibly difficult to
be closer to one vector without having cross the NP of said vector.

But... that's not enough, obviously.  There are tight curves in Tuxkart,
we have to account for those.

We already submitted that we need to think about 2 waypoints at a time,
and this is actually a convenient way of _always_ heading for the right
waypoint.  Consider waypoints w1, w2, w3, and w4.

If you consider both the next waypoint and the waypoint beyond it - w1
and w2 - and if you cross the NP of w1 then you make your secondonday
(w2) waypoint the primary waypoint (ie move from [w1,w2] to [w2,w3]).
If you cross the NP of w2, then the next way point needs to be the
previously unconsidered tertiary waypoint (ie move from [w1,w2] to [w3,
w4]).

So that handles curves.

Next scenario, shortcuts.  Well, we just add extra waypoint here and you
go into decision making mode.

But then you could still have _really_ awkward spots.  Well, the way to
go about them could be an amalgamtion of approaches.  Perhaps waypoints
could be associated with areas rather than just points.  That way you
can switch waypoints when a kart enters an area without having to really
think about it.  It also drops the memory requirements because you can
just have single way points for large areas.

Also, with vector waypoints, the kart doesn't need to head straight for
said waypoint, it can always aim at an angle that puts it on target for
the next waypoint.

Thinking about it, a combination of a scalable vector field and
waypoints is probably the best approach.  The advantage of a 3d vector
field is that it will work well for things like bridges and jumps where
a kart could fall onto a different section of the track.  Making it
scalable is important for ensuring the track isn't difficult to manage.

It all needs thinking through both mathematically and problematically
but I really think we can address this efficiently and relatively simply
without resorting to something as dire as a micro-structured vector
field like you're suggesting - remember that it has to be 3d makes that
an even worse proposition.
-- 
- Charlie

Charles Goodwin <ch...@ve...>
Online @ www.charlietech.com

Re: [TuxKart-devel] Ideas for AI

[Steve B. <sjb...@ai...>]

Charles Goodwin wrote:
> On Tue, 2004-06-29 at 22:41 -0500, Steve Baker wrote:
> 
>>The thing I'd like to consider is something like a 'vector field'.
>>
>>A large array (and as I explained earlier - it would be LOTS of memory)
>>where for every (say) 2meter x 2meter square there would be (say) two bytes.
> 
> 
> I really think this is an unecessary approach.

[ I'm playing devils advocate here - I want to discuss this some more
to elicit deeper thinking without necessarily agreeing with everything
I'm saying! ]

Where a vector field really scores is when the polygonal representation of
the track is very complex.   With any kind of waypoint representation, there
is an underlying assumption that you can't get stuck behind a wall or
something.  Preventing that from happening in the absence of other
information is really hard.

With waypoints, if I somehow get knocked off the road and there is a
wall between me and the waypoint, I'm completely stuck.

Similarly, if I'm somehow pushed off course and ended up somewhere where
there is a shorter route to the waypoint-after-next than going to the
next waypoint - then I'm probably going to mindlesslyy turn right around,
drive to the waypoint that was supposed to be next and then take the long
way to the waypoint after that.

The vector field approach gives you a fast, reliable way to get out of
any situation.  For any location on the map, you know simply and unambiguously
how to get back to the racing line via the fastest possible route - even if
you have to quite literally negotiate a maze to do it.

I agree though that it's going to be hard to generate and that it'll
consume quite a bit of RAM - so your way may be more practical (I believed
that waypoints were the right thing to do when I first wrote TuxKart - but
practical experience with trying to kludge around various practical
problems leads me to wonder whether something different would help.

We can attempt to fix the problems with waypoints by restricting the
kinds of tracks we generate - but all of the exciting and interesting
possibilities keep tripping up if you impose too many artificial
design limitations.

---------------------------- 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-----

Re: [TuxKart-devel] Ideas for AI

[Charles G. <ch...@ve...>]

On Tue, 2004-06-29 at 22:41 -0500, Steve Baker wrote:
> The thing I'd like to consider is something like a 'vector field'.
> 
> A large array (and as I explained earlier - it would be LOTS of memory)
> where for every (say) 2meter x 2meter square there would be (say) two bytes.

I really think this is an unecessary approach.

If you model each waypoint as a vector with a direction (or two vectors
in the case of turns) then you can easily work out where to head and
how.  A giant array full of vectors is memory consuming, hard to set up
(imagine doing it manually) and complicated when things change.

That's just doing it the hard way.

Here's an example solution for the 'next waypoint' method.  If you say a
waypoint is a vector, when a kart passes the normal plane to the vector
then it targets the next vector.  This way, even if a kart takes a
really wide birth or jumps over it, the kart cannot miss the waypoint.

To make sure bad behaviour doesn't occur, you can add in extra
conditions for when the angle to the normal is acute.

It can all be done with simple (single or double) vector way points.  A
trackwide grid of vectors is just so overkill and so problematic.  I
would go as far to say that it would be _madness_! ;)
-- 
- Charlie

Charles Goodwin <ch...@ve...>
Online @ www.charlietech.com

[TuxKart-devel] IRC this weekend?

[Steve B. <sjb...@ai...>]

CROSS-POSTED FROM HAPPYPENGUIN:
===============================


Sepht wrote:

 > sbaker ill quote myself, we should have an IRC, and the ideal time for that would be
 > Any irc meeting should be from 18:00 to 22:00 GMT on a weekend. (that would be 10am
 > to 2pm PST, or 1pm to 5pm EST) just so that all timezones cna join.

Yeah - that sounds OK to me.  It'll certainly work for the N.America, S.America, Africa
and Europe.   Do we have anyone from elsewhere on the planet?  Any Aussies maybe?

Saturday or Sunday?  (Actually, for folk here in the USA, this is 4th July weekend - so
they are likely to be neck-deep in relatives on Saturday - maybe Sunday is the best choice.)

I doubt we need 4 hours of formal discussions - let's put an agenda together, do an hour
of optional intro's and chat at 18:00 GMT, and hold a formal meeting at 19:00 GMT and more
informal chat after we get formal business out of the way.

Comments please?

Agenda Items Please?

---------------------------- 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-----