Re: [TuxKart-devel] Getting Started.

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

Hello Steve and Tuxkart People:

I've been working on an AI project using tuxkart for a few months.  It's
a long term project using reinforcement learning to make an adaptive AI.

The project is not too far along yet, and will probably involve linking
with OCaml code so I'm not suggesting it for the GoTM development
burst.  However, I might be able to help out in one or two areas.

Comments in-line, I'm not volunteering for all the areas I comment :),
just providing background so you have some idea where I might be
useful.

On Sun, Jun 27, 2004 at 02:52:23PM -0500, Steve Baker wrote:
> Here is the ToDo from the TuxKart thread over on HP GoTM with more
> of my comments.   Please chip in with suggestions (and volunteering):
>=20
>=20
> 1) Better kart dynamics (skidding, etc). I didn't think I needed that
>    at the time - but enough people tell me it sucks without it that I
>    have to agree.
>=20
> We talked some about using ODE physics for this...that seems possible.
> This is a concrete decision we have to take - we can't start off on
> one route and change our minds.
>=20
> Does anyone have much ODE experience?   I've played with it (with mixed
> success).
>=20
> Either way, we want some variety in the Kart's handling - so we can vary
> the power, the tyre grip, etc, etc.

Although I only have a background in the theory side of math and physics
I believe I could help out if you end up doing custom physics.  As far
as ODE goes, I have heard some good things about it, but I've never used
it.  It would be something fun to learn, but I'm not sure how fast I
would be with development.

> 3) Improved collision detection (sometimes a kart will fall through a hol=
e=20
>    in the terrain)
>=20
> Two choices:
>=20
>    If we go with ODE, it has it's own collision detection - although you
>    can supply your own.  Dunno if it's fast enough though.
>=20
>    If we don't go with ODE - or if we don't want to use ODE's collision
>    library - we can just try to fix whatever the bug is in the present
>    system.
>=20
> I guess we need to work the ODE decision first.

Same as 1) pretty much.  I could help with fixing and adding to the
current code.

> 5) Better enemy AI (OK - *some* enemy AI!) - at present, the enemy karts=
=20
>    just steer to try to follow a curve laid down through the
>    approximate center of the track..
>=20
> Um - yes.  Help!  Who does good AI?

I might be able to help here.  I'm not suggesting the adaptive AI (which
is probably on the order of several months), but I will need something
other than the line-tracker to measure my AI against anyways.

I am thinking of something with a few heuristics for picking a decent
racing line (just picking the widest radius turn unless another turn is
coming up fast), and some other heuristics for when to use items and
abilities.

This is probably where I could contribute the most.  I've had experience
with finding good racing lines on clear tracks, and I have a
reinforcement learning background which maybe will carry over a bit to
this sort of work.

> 10) Considering getting network play working.
>=20
> I checked the TuxKart code - and there is very minimal network code
> there, it'll need a complete rewrite I suspect.   Probably we should
> leave this until/unless someone passionately wants to do it.

This is something I can definitely help with whenever it happens.
Certainly with the low level network stuff (if needed -- haven't
checked) whether it's UDP flooding or TCP is used.  I could also work on
the interpolation code.  So if this feature becomes active I can help
with it.

Aly

--=20
Aly Merchant   mer...@ac...   http://cobe.dyndns.org