tuxkart-devel — TuxKart Developers.

Re: [TuxKart-devel] Ideas for AI

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

Charles Goodwin wrote:

> ...so we need a new scheme. ;)

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.

Packed into these 16 bits there would be:

1) The compass direction to steer along in order to reach the best
    racing line in the optimal way from this point.

2) The distance to the nearest powerup that's further down the
    track and 'reasonably' gettable without deviating wildly from
    the racing line.

3) The direction to that powerup.

Armed with this information, the AI can figure out where to go if they
want a powerup, where to go if they want to just drive - and (using the
distance metric and the difference between the two directions) whether
they really want to go out of their way to collect said powerup.

Now - there are some complications.

The map changes when a powerup is collected.  This change is far-reaching
and would result in a ton of complicated realtime calculations.

The good direction is sometimes blocked by another kart.

There is still a problem with bridges, crossovers, and dynamic things.

---------------------------- 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:03 -0500, Steve Baker wrote:
> When I model a track, I build a second model which is just a set of
> points that describe what I believe is a reasonable 'racing line'.
> 
> The AI attempts to follow that line.
> 
> However, there are some serious problems with that right now.
> 
> 2) The waypoints are in 2D - not 3D.  Hence, tracks with crossovers
>     in them (eg Gowns Bow) just flat out don't work.  Head-butting
>     happens all the time in these tracks because the AI's forget
>     whether they are going over or under the bridge.

Well this is addressed by the aforementioned "2 corner" technique
because you can't forget which corner you are heading towards, right?
As for going over/under the bridge, you'd want to put a waypoint both on
and under said bridge.

> 1) Think about a righthand hairpin turn (eg the first corner
>     in Oliver's math class where the 'walls' between the track
>     sections are very thin books and the track sections are very
>     wide).  What happens is that if you are on the entry to that
>     curve and you hug the right-hand wall, you are actually closer
>     to the 'waypoint' on the other side of the wall than you are
>     to the waypoint on your side of the wall.  This causes the AI
>     characters to head-butt the wall endlessly.

Perhaps waypoints should come in multiple forms, where for cases like
hairpins you'd want two vectors (in / out angle) instead of a single
point.

> 3) 3D waypoints don't work when there are jumps and such.  The player
>     can sail over a waypoint at sufficient height that we cause problem
>     (1) but in 3 dimensions instead of 2.

Way points need to become 'only a guide'.  There must be some way by
which Tuxkart establishes whether a human player is a certain portion
around the track to stop the player cutting across the track and missing
out entire sections.  The AI should use that as it's ultimate decision,
then pick the nearest waypoint _ahead_ so that ones left behind are
ignored once they are behind.

> 4) Computer players only hit the powerups by luck.

This is part of the decision making stuff, whether to hug the racing
line or go for a power up.

Again this would probably be done by overloading waypoints, a 'powerup
waypoint' so to speak.

> 5) You can't have tracks with alternative routes through them.  There
>     is a really GREAT track on MarioKart'64 that's almost a maze.  My
>     scheme can't cope with that.
> 
> 6) You can't easily have tracks with dynamically changing routes through them.
>     I'd like stuff like large turntables that you have to hit at just the
>     right time if you want to take the shortcut - otherwise you're stuck
>     with taking the long way around.   Things like in WaveRacer'64 where a
>     shortcut opens up only on the last lap.

...so we need a new scheme. ;)
-- 
- Charlie

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

Re: [TuxKart-devel] Split-screen mode.

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

Charles Goodwin wrote:

> Ruling out custom keyboard settings altogether sounds a bit harsh.

Well, it might seem that way - but a smart key configurator that
seemingly arbitarily disallowed just about every combo you thought
you'd like would be HORRIBLE.

Computer:  "What key to use for FIRE?"
Me:  "F please!"
Computer:  "Sorry - not allowed"
Me:  "SPACE ?"
Computer:  "Sorry - not allowed"
Me:  "How about...erm...Enter ?"
Computer:  "Nope - not as such"
Me:  "Damn... maybe: @" ??
Computer:  "Close...try again!"
Me: RESET

A key configuratore that let you create combo's that don't work
would produce stacks of bug reports of keys seemingly randomly
not working.  (eg Your opponent is holding down 'Accellerate'
and 'Left turn' - and that blocks out your 'Fire' button - but
you don't know he's holding those down - it just seems like your
Fire button only works half the time...so you bitch that the game
sucks).

Pre-selecting keys ourselves is decidedly tricky because the
nature of what happens when you hold down two keys and try to
strike a third varies between keyboard controller chip manufacturers
and between keyboards of different nationalities.

Automating that is HARD.

I'm happy to hear good ideas though.

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

Jacob Persson wrote:
> Let's get a bit more specific on how the ai are supposed find it's way around
> the track. I think some kind of waypoint system would be nice to keep 
> calculations down.

Well, that's pretty much what I have in TuxKart right now.

When I model a track, I build a second model which is just a set of
points that describe what I believe is a reasonable 'racing line'.

The AI attempts to follow that line.

However, there are some serious problems with that right now.

1) Think about a righthand hairpin turn (eg the first corner
    in Oliver's math class where the 'walls' between the track
    sections are very thin books and the track sections are very
    wide).  What happens is that if you are on the entry to that
    curve and you hug the right-hand wall, you are actually closer
    to the 'waypoint' on the other side of the wall than you are
    to the waypoint on your side of the wall.  This causes the AI
    characters to head-butt the wall endlessly.

2) The waypoints are in 2D - not 3D.  Hence, tracks with crossovers
    in them (eg Gowns Bow) just flat out don't work.  Head-butting
    happens all the time in these tracks because the AI's forget
    whether they are going over or under the bridge.

3) 3D waypoints don't work when there are jumps and such.  The player
    can sail over a waypoint at sufficient height that we cause problem
    (1) but in 3 dimensions instead of 2.

4) Computer players only hit the powerups by luck.

5) You can't have tracks with alternative routes through them.  There
    is a really GREAT track on MarioKart'64 that's almost a maze.  My
    scheme can't cope with that.

6) You can't easily have tracks with dynamically changing routes through them.
    I'd like stuff like large turntables that you have to hit at just the
    right time if you want to take the shortcut - otherwise you're stuck
    with taking the long way around.   Things like in WaveRacer'64 where a
    shortcut opens up only on the last lap.

So waypoints have their problems...maybe not insurmountable...but
certainly problems that you need to think through in the light of
my sad experience!

---------------------------- 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] Split-screen mode.

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

On Tue, 2004-06-29 at 21:22 -0500, Steve Baker wrote:
> > How does limiting to only 2 keyboard characters sound? I think that's
> > what most games do. Of course we'd still have to make sure users
> > didn't pick bad key combinations.
> 
> Yep.  We could certainly offer them some choices - you know:
> 
>     "Which key combo would you like to use?
>       Setting A:  this set of keys
>       Setting B:  some other set of keys
> 
> ...but not:  "What key would you like to use for Accellerate?"
> 
> It's possible we could get three players - but maybe with only
> one choice for key commands.  The fourth player could be using
> the mouse.   If they have a joystick or two, we can cope with
> that too.

Rather than have two hardcoded settings, why not just have a default
setting and then let the player define their own set of keyboard
controls as a _complete_ alternative?  ie a "Configure New Control
Settings" dialogue; that way you can force an inability to create
arbitrary settings that conflict.

Ruling out custom keyboard settings altogether sounds a bit harsh.
-- 
- Charlie

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

Re: [TuxKart-devel] Ideas for AI

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

Charles Goodwin wrote:

> I really don't like the idea of relative speeds according to how well or
> not somebody is playing.  Not only does that cause problems for players
> (they approach the same corner at full speed in two parts of the race,
> only full speed has changed), it's also a challenge for the AI (same
> corner problem).

The problem is that with no dynamic handicapping, the karts get spread
out all around the track and you just never see any of them after about
30 seconds into the race.  The track is about a mile around - if everyone
is well spread out, the nearest kart is a quarter mile away - which puts
it somewhere two corners away.  You'll never see it.

For some kinds of game, that's realistic - but the trouble for a MarioKart
clone is that most of the fun is not in driving really well - most of it
is in the powerups and collectables.  Blowing people away with missiles
and bombs and things that shrink the enemy do half size...stuff like that.

But if the enemy karts aren't somewhere nearby, none of that interesting
stuff happens and we are left with "just another race game".

The trick is to do it subtly enough so it's not really noticable - and
make it such that good driving will let you beat them despite their
tendancy to speed up behind you.

MarioKart certainly does this...so do most other 'fighting-with-racing'
games that I've played.

> It needs thinking through by somebody, but if we can add a couple of
> categories for classifying actions then we can really give AI characters
> a bit of *character*... the Octopus and Killer Whale could be really
> agressive, for instance, whilst Tux and Gown could be really defensive.

Yes.  Some kind of noticable character 'personality' could add a lot of
play depth.

If you know in advance how your opponent tends to react then you can
strategize about how to beat them.  Some might require good driving,
others need to be blown to bits with exploding herring...whatever.

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

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?

---------------------------- 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 Tue, Jun 29, 2004 at 06:11:22PM +0000, Charles Goodwin wrote:
> 
>>I also don't believe we should make each driver in the race be of
>>increased difficulty so it is hard to get to #1.  Some people aren't
>>game wizards and they'll find it frustrating if they can't win on easy.
> 
> 
> I'm not exactly sure what you mean here,

He's saying that you have some number of AI players - graded from
easy to beat to very hard to beat.  Then, if you are a beginner, you'll
come in close to last - and as you get better, you'll come in higher
and higher up the ratings until *FINALLY* you can win a race.

If I've interpreted it right - I think this sucks as a game concept.

Probably I don't understand either!

 > but I think there should be an
> approach similar to Mario Kart - where the AI ahead of you becomes weaker, 
> and the AI behind you becomes stronger (or maybe just adjust the speed).

Yeah - that's what Tuxkart's AI does now - and people who figure it out
*hate* it.  No matter how hard or well you drive, you just can't get far
enough ahead to guarantee a victory.  The way to win is to drive around badly
(it doesn't matter - the AI will slow down to let you keep up) - then just
before the finish line, work hard - and before the AI players notice, you'll
win almost every time.

Clearly that sucks.

I don't see the problem with doing this to a *mild* degree - because it does
make the game more interesting...but that can't be the mechanism for keeping
the game interesting.

In the end, the tried-and-tested way is to have some number of levels of
difficulty.   Since we don't want to design too many characters (it's a LOT
of work), it makes sense to allow each character to play at different skill
levels and with differently powerful kart physics so they play at the skill
level the player asks for.

> But how do you define good choices? Is it better to take the corner in the 
> fastest possible way, or to take it in a slower way that leads to collecting 
> a powerup?

That's what puts the 'I' in AI!

Probably what you do is to build these preferences into the AI's "Character".

You know - the suave sophisticated Penguin drives as best he can, the maniac
Octopus goes for the powerups every time.  The other guys pick randomly with
variously skewed probabilities.

This possibly leads to 'richer' game play.  If you know the Octopus is behind
you, maybe you make more effort to nab the goodies before he does.  If you
know the Penguin is going to ignore them, maybe you take the best racing line
and drop a bananaskin there because you guess he'll go that way.

> Basically, what you're saying is that we need to define some heuristics to 
> determine what actions to take. It's not as simple as good/bad/normal 
> decisions. For example, taking a slower route to collect a powerup makes less 
> sense if you are in the lead.

Yep.

---------------------------- 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] Split-screen mode.

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

Ryan Flegel wrote:

> I now see what you are saying.

Nasty isn't it!

> How does limiting to only 2 keyboard characters sound? I think that's
> what most games do. Of course we'd still have to make sure users
> didn't pick bad key combinations.

Yep.  We could certainly offer them some choices - you know:

    "Which key combo would you like to use?
      Setting A:  this set of keys
      Setting B:  some other set of keys

...but not:  "What key would you like to use for Accellerate?"

It's possible we could get three players - but maybe with only
one choice for key commands.  The fourth player could be using
the mouse.   If they have a joystick or two, we can cope with
that too.

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

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

Robert Kooima wrote:

> I do feel that joystick control of the GUI is a significant thing,
> especially since joystick control is the primary mode of game
> interaction.  It seems hackish to have to reach for the mouse to
> select a level.  Is this an issue we can address within PUI?

Yes - easily - although I've never seen a game that did that.

PUI doesn't read input devices itself - it relies on the
application to pass on mouse or keystrokes.  PLIB's Joystick
routines are entirely separate - so it would be a snap to
pass joystick events and positions into the PUI widget tree
in order to make it run.

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.

> Certainly a great deal of GUI work needs to be done, yes? 
> Configuration, high score lists, etc?  Are these on the ToDo list?

Yes.  'A great deal of GUI work' would be something like the application
that our principle PUI maintainer wrote - I havn't seen it - but I'm
told it has over 150 'pages' of GUI widgets!

> Great, as I'd like to help  I offered to take on GUIs because GUI work
> is mundane and boring and I expected it to fall by the wayside as
> people clambered to do sexy stuff like physics, graphics, and AI. 
> Where would you like me to contribute?

Well, I think we have a couple of AI volunteers.  Graphics is mostly
to do with:

1) 3D model building - if you can handle Blender or have AC3D - then
    there is an endless pit of 3D models for karts, tracks, decoration
    (trees, carniverous plants, squirrels in trees, dancing mushrooms,
    *ANYTHING* that you could imagine in a 'cute' game).

    Anyone who can model needs to model.

2) Special effects - smoke, flame, animation, sparks, rocket trails,
    ...anything we can add in the realm of eye-candy.  This is programming
    PLIB/SSG's particle systems - plus putting together some textures to
    stick onto the particles.

3) *PERHAPS* we need a better way to get models from Blender into the game.

We kinda sorta have a physics volunteer - I think we'll need two physics
people - one for dynamics and one for collision detection.

There will be a big pile of integration bits to glue everything
together.  I kinda suspect that should be my job (because I know
the software better than anyone - I'd rather be doing some of the
fun stuff).

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

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

Let's get a bit more specific on how the ai are supposed find it's way around
the track. I think some kind of waypoint system would be nice to keep 
calculations down.

-- 
Name: Jacob Persson
Homepage: www.apollo.nu/~straver/

Re: [TuxKart-devel] Ideas for AI

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

Charles Goodwin <ch...@ve...> writes:

> I really don't like the idea of relative speeds according to how
> well or not somebody is playing. Not only does that cause problems
> for players (they approach the same corner at full speed in two
> parts of the race, only full speed has changed), it's also a
> challenge for the AI (same corner problem).

I consider automatic handicap adjustment basically the best invention
since sliced bread in game development and its really the only way to
get interesting gameplay. Without it you either end up far behind
everybody else or far ahead of everybody else, none of this is any
fun. With automatic handicap adjustment however you get quite exciting
races and very often races where the last few meters matter. 

It doesn't cause any problems for the player, since the player drives
always the same (unless you do multiplayer with enabled auto-handicap
of course), only the AI changes its speed and the number of bonuses it
uses. The only thing that one needs to keep care of are upper and
lower bounds for how much the AI gets slow down or speed up, else you
get easily unrealistic situations where the AI almost halts or drives
insanly fast (this bug is currently triggerable in Tuxkart). So
handicap ranges might look like this:

Speed:   0...........100%
Easy:         [----]
Medium:          [---]
Hard:                [-]

Thus ensuring that easy always stays easy and adopts to any kind of
weak player, medium always provides a good chalange for the average
player and on hard people are really forced to not make much mistakes,
since the hanticap won't get adjusted much at all.

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

Re: [TuxKart-devel] Ideas for AI

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

On Tue, 2004-06-29 at 23:24 +0100, Oliver Jeeves wrote:
> > I also don't believe we should make each driver in the race be of
> > increased difficulty so it is hard to get to #1.  Some people aren't
> > game wizards and they'll find it frustrating if they can't win on easy.
> 
> I'm not exactly sure what you mean here, but I think there should be an 
> approach similar to Mario Kart - where the AI ahead of you becomes weaker, 
> and the AI behind you becomes stronger (or maybe just adjust the speed). This 
> causes the karts to bunch a bit more and means that a good player always has 
> a threat of being overtaken, and a weak player always has a chance to 
> overtake.

No, I meant that 'easy' should be really easy (ie a young kid should be
able to win after a big of practise), 'medium' should be a mild
challenge but nothing for experienced gamers, 'hard' should be a
challenge for most people, and 'invincible' should be damn near
unbeatable.

I really don't like the idea of relative speeds according to how well or
not somebody is playing.  Not only does that cause problems for players
(they approach the same corner at full speed in two parts of the race,
only full speed has changed), it's also a challenge for the AI (same
corner problem).

> Basically, what you're saying is that we need to define some heuristics to 
> determine what actions to take. It's not as simple as good/bad/normal 
> decisions. For example, taking a slower route to collect a powerup makes less 
> sense if you are in the lead.

No, it wouldn't be that simple.  But that was an example of classifying
actions.  You would probably add 'attacking', 'defensive', and 'neutral'
so that you would have aggressive AI, defensive AI, and AI that just
races as fast as possible.

It needs thinking through by somebody, but if we can add a couple of
categories for classifying actions then we can really give AI characters
a bit of *character*... the Octopus and Killer Whale could be really
agressive, for instance, whilst Tux and Gown could be really defensive.
-- 
- Charlie

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

Re: [TuxKart-devel] Ideas for AI

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

On Tue, 2004-06-29 at 17:44 -0500, Steve Baker wrote:
> The ideal thing would be for the outputs of the AI to be identical
> to the inputs that the player provides via his controls.  That way
> the same physics apply to AI and players.

Ooo yes, I like that approach.

> However, it may be that we can make life easier for the AI code by
> providing a different interface - or even allowing it to cheat by
> going in at a lower level than the player's inputs.

The notion of the AI cheating isn't the greatest feeling for a player.
But it is a common approach in many games to add more challenge - to let
the AI cheat rather than play well.  Personally, I feel that it takes
away from the game.  I hate, for example, in Civ2 (and most likely
Freeciv) on the harder difficulties the AI makes more money and gets
more resources than you.  It's not good, it makes decisions as bad as on
lesser difficulties settings, it just gets to cheat.

> >   Value map:
> >   All points of interest on the map have a value associated with them,
> >   these values radiate outwards and overlay on top of each other.
> 
> We'd need to write a tool to prepare that map.
> 
> RAM storage for it might be a problem if it has to be held at high
> resolution for a large track.
> 
> If you'd like a 5 lap race to last 5 minutes with average speeds of
> 60mph (reasonable for a GoKart) - then the course has to be a mile
> long.  That could mean that the 'interest map' could easily need to
> be (say) 1000 meters on a side...I'd guess your map would need to be
> about 1 meter resolution?  So we'll be eating about a megabyte
> for every byte we store in the map.  On lower end systems, that
> could become a problem.
> 
> If you only need a couple of bytes per location on the map, that
> might not matter - but if you needed a dozen bytes per location,
> the storage could kill us.

Each location would surely just be a point on the map.  Scale and size
really shouldn't matter.  Put your thinking cap on Steve. ;)  That was a
very knee-jerk bit of reasoning on how you'd approach it.
-- 
- Charlie

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

Re: [TuxKart-devel] Re: Tuxkart-devel digest, Vol 1 #39 - 13 msgs

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

Charles Goodwin wrote:
> On Tue, 2004-06-29 at 16:44 -0500, Steve Baker wrote:
> 
>>Penguins natural enemies are: Skua's (who eat their eggs), Leopard Seals and
>>Killer-Whales.
> 
> 
> I think a Killer Whale character would rock.
> 
> Later on this evening I'll draw up a summary of contributed character
> ideas thus far and post it to the list.

Don't forget the Octopus...I want to see 8 animated tentacles and
the ability to hold up to 8 different powerups at once as his special
power.  :-)

"Graphically interesting".

---------------------------- 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] Re: Tuxkart-devel digest, Vol 1 #39 - 13 msgs

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

Ryan Flegel wrote:
> 
> Yeah, I think seals, albatrosses and whales are pretty much the only
> other antarctic creatures in addition to penguins :)

It can't be nice to be at the bottom of the food chain...aside
from the fish, krill and plankton that is.    :-(

Killer whales make good game characters.  Leopard seals are really
interesting (graphically speaking) because of their markings - but
people wouldn't recognise them for what they are I think.

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

Aly Merchant wrote:

>   Basic behaviours:
>   The AI would have a list of higher level actions to choose from,
>   something like "visit point of interest", "make wide turn", "make
>   sharp turn" as opposed to something like "go left", "go right",
>   "fire".

The ideal thing would be for the outputs of the AI to be identical
to the inputs that the player provides via his controls.  That way
the same physics apply to AI and players.

However, it may be that we can make life easier for the AI code by
providing a different interface - or even allowing it to cheat by
going in at a lower level than the player's inputs.

>   Value map:
>   All points of interest on the map have a value associated with them,
>   these values radiate outwards and overlay on top of each other.

We'd need to write a tool to prepare that map.

RAM storage for it might be a problem if it has to be held at high
resolution for a large track.

If you'd like a 5 lap race to last 5 minutes with average speeds of
60mph (reasonable for a GoKart) - then the course has to be a mile
long.  That could mean that the 'interest map' could easily need to
be (say) 1000 meters on a side...I'd guess your map would need to be
about 1 meter resolution?  So we'll be eating about a megabyte
for every byte we store in the map.  On lower end systems, that
could become a problem.

If you only need a couple of bytes per location on the map, that
might not matter - but if you needed a dozen bytes per location,
the storage could kill us.

>   And
>   the car just follows the path of optimal value.  Modeling certain
>   things might be tricky, e.g. getting the car to fire at another car
>   might involve modeling the other car as a good point of interest if
>   it is moving faster than you and you have missiles, otherwise they are
>   to be avoided.

Things like collectibles (which might go away when someone collects them)
and missiles make the map somewhat dynamic though.   There are certain to
be ways around that - but it has to be concidered.

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

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

On Tue, 29 Jun 2004, Steve Baker wrote:

> Matze Braun wrote:
> > I could setup something similar for tuxkart (or someone else could do it, 
> > installing phpwiki is relatively easy).
> 
> That's a great idea.  I don't *think* SourceForge can host a Wiki though.
> Does anyone have a suitable host we could run this on?
sourceforge can, however it tends to be very slow these days. I can easily 
setup another one at berlios if you want.

Greetings,
	Matze

Re: [TuxKart-devel] hi there...

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

Jacob Persson wrote:

> My account name is 'straver'

Welcome to the team!

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

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

On Tue, 29 Jun 2004 17:20:46 -0500, Steve Baker <sjb...@ai...> wrote:
> 
> Matze Braun wrote:
> > I could setup something similar for tuxkart (or someone else could do it,
> > installing phpwiki is relatively easy).
> 
> That's a great idea.  I don't *think* SourceForge can host a Wiki though.
> Does anyone have a suitable host we could run this on?

Well, PhpWiki's website is a setup of PhpWiki on SF, so I think it
should be possible somehow :)

-- 
Ryan

Re: [TuxKart-devel] Ideas for AI

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

Aly Merchant wrote:

> What I mean is how much knowledge it actually requires to do whatever it
> needs to do.  The way I see it the AI will probably only care about the
> track it will reach in the next 5 seconds, or maybe it will track up to
> the next 2 turns in the road.  It's not going to be doing a full search
> on the entire course -- so what does it need to know about to be a
> decent AI?

Certainly, when you are racing for real (which is something I've actually
*done*!) you need to consider the entry to the NEXT corner when you plan
your entry to this one.  So certainly two turns ahead would work.

You might find that really good drivers would be looking further ahead -
but in this case, your choice of the perfect racing line becomes more
and more eclipsed by the other people on the track (who may NOT be
following a good line) and by the needs to dodge missiles or collect
items along the way.

I'd be rather suprised if you could usefully plan further than two turns
ahead.

> In my opinion considering the entire track on each decision would be a
> waste of time...

Yes - I agree.

The thing is that a TuxKart track is a dynamic place.  You could possibly
save a few tenths of a second by planning three, four turns ahead - but
by the time you get there, everything will have changed and all that early
planning would be wasted.

With this genre of games, it's MORE about the gadgets and collectibles
than it is about racing perfectly.

---------------------------- 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] Split-screen mode.

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

On Tue, 29 Jun 2004 17:11:07 -0500, Steve Baker <sjb...@ai...> wrote:
> 
> Ryan Flegel wrote:
> 
> > Well, I think we should have all inputs configurable. Have it possible
> > to use the keyboard as much as the user wants (and let them define the
> > keys). If they want to try to use more than two people on the
> > keyboard, good luck to them :) Alternate inputs would be each attached
> > joystick. As for mouse, I think that would be a bitch to use.
> 
> I'm guessing you didn't read the document I pointed you guys at:
> 
>      http://www.sjbaker.org/steve/omniv/keyboards_are_evil.html

I opened it up in a new tab but somehow managed to close it without
reading it. I now see what you are saying.

How does limiting to only 2 keyboard characters sound? I think that's
what most games do. Of course we'd still have to make sure users
didn't pick bad key combinations.

-- 
Ryan

Re: [TuxKart-devel] Wiki for development plans

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

Matze Braun wrote:
> I could setup something similar for tuxkart (or someone else could do it, 
> installing phpwiki is relatively easy).

That's a great idea.  I don't *think* SourceForge can host a Wiki though.
Does anyone have a suitable host we could run this on?

---------------------------- 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 16:59:41 -0500, Steve Baker <sjb...@ai...> wrote:

> I don't see a need.  The present GUI can handle any 'look' I can
> think of - and it's already part of the PLIB library that we use
> for EVERYTHING else.

Ok by me.  Just tossing it out there.

I do feel that joystick control of the GUI is a significant thing,
especially since joystick control is the primary mode of game
interaction.  It seems hackish to have to reach for the mouse to
select a level.  Is this an issue we can address within PUI?

> GUI redesign wasn't on our GoTM 'ToDo' list - but even if it was,
> I can't see any justification in ripping apart something that's
> working OK.

Certainly a great deal of GUI work needs to be done, yes? 
Configuration, high score lists, etc?  Are these on the ToDo list?

> I'd really appreciate some help from an experienced game designer like
> you - but just not in the area of GUI design.

Great, as I'd like to help  I offered to take on GUIs because GUI work
is mundane and boring and I expected it to fall by the wayside as
people clambered to do sexy stuff like physics, graphics, and AI. 
Where would you like me to contribute?

-- 
Robert Kooima

Re: [TuxKart-devel] Ideas for AI

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

Charles Goodwin wrote:

> I also don't believe we should make each driver in the race be of
> increased difficulty so it is hard to get to #1.  Some people aren't
> game wizards and they'll find it frustrating if they can't win on easy.

Yes - I agree.  The game should be challenging - but not so hard that
you have to play it every evening for a month before you can win a race.

> Each driver should have particular strengths suited to particular types
> of level so that they are more prone to success on certain levels.  Of
> course, there should be weak opponents too.

Yes - although we can do that with the karts rather than the AI.  If some
guys have karts with great maximum speed but crappy accelleration then
a course with long straights would favor them over karts with good
accelleration but poor straightline speed.  On a wiggly course, the reverse
might be the case.

It should be more intuitive to juggle those kinds of numbers than it is to
adjust the AI.

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