[TuxKart-devel] Fwd: Note to Willian.

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

(I'm forwarding part of my communication with
Willian to this list since it contains useful
information for other potential TuxKart level
designers...although nobody else is subscribed
to the list - it'll be handy to have it archived.)

Willian expressed interest in helping with TuxKart
track designs...

Willian Padovani Germano wrote:

> Some years ago (before Mario Kart 64 was launched) I had the idea for a game
> on that line -- with some twists, but didn't know the technology would make
> its original design possible. The MK 64 engine was exactly what I'd need for
> that. By that time I enjoyed the idea I had because its basic gameplay was
> as simple as Space Invaders, Tetris or Pac-man. We can talk about that idea
> if you want. One thing: my ideas are "open source", I have absolutely no
> problem in talking about them, even if someone else ends up using them.

That would be interesting.  TuxKart can already do most of what MarioKart64
does.  There is no 'battle mode' - but it will be easy to add that once I
have networked play for multiplayer stuff, if you fall off the edge of the track,
there isn't yet the little guy who sits on the cloud with a fishing rod to
put you back on again.  I was thinking of using are really tiny Tux with
angel-like wings who flutters down and picks you up with a magnet or
something.

I've played a bit with a networked play mode - but the game is badly
suited to the long 'ping times' you get over the Internet.  Between
two machines sitting in the same room though - it's *great*.  I havn't
finished that mode though - there are lots of strange contradictory
situations that can come up that I need to resolve first.

Hence, multiplayer will come AFTER the first beta release.

> The gnu would make a nice character, too...

Yes - also:

  * The BSD Daemon (although I heard that there might be some copyright
    issues there).
  * I have permission to use "Wilbur" - who is the GIMP mascot - but the
    GIMP guys told me that he has never had a body designed for him...there
    is a challenge.
  * There is a group of women who got together a "Linux for Girls" organization
    (I forget their actual title) - they have a great Fox mascot.

> The way I see, a game like TuxKart must have tight design for powerups and
> overall look and feel, from characters to all colors in the game. Some
> variation in objectives during the race would fit nicely, too.

Hmmm - that's an interesting idea.  Right now it's like MarioKart64 - first
past the post after N laps wins.
 
> > I'm not getting into the darker themes of Quake and Unreal...although
> > having the occasional dark and scarey level could be reasonable.
> 
> A well done, tight where possible, spooky train level could be very funny.

Oooh!  Yes.

> While I go on learning and begin
> practicing with gimp, blender, etc, we could discuss about one of your games
> in particular, design level. QfH or TuxKart, you choose.

Well, TuxKart has the simplest requirements.

A TuxKart 'level' (a race track) is just a bunch of static models (perhaps
just one if it's simple enough).

There is a "xxx.loc" file that contains the location of each model (x,y,z,
h,p,r) - and allows you to leave off the height, the pitch and or the roll
so that the object will be automatically glued onto the highest 3D object
at that location.  That's pretty useful for sticking objects onto the track.
 
There are some models that are 'built-in' to the game engine - notably the
'Zippers' (Go-faster chevrons like in DiddyKong Raceing or Crash Team Racing),
and the various colours of 'Herring'.  That makes life easier on me because
I need to know that they are 'special' - and in any case, their design should
be consistant from one level to the next IMHO - otherwise the player won't
recognise what they are.

The race always starts at the origin - with the players facing due north.

The second file you need is an ordered list of 2D points that lie along the
centerline of the track - starting at the start line and ending again at
the start line.  That's used to tell the computer players where to steer
and to let me figure out how far around the 'lap' each player is.  I also
use it to generate a 'plan view' of the track with coloured dots for the
players - just as in TuxKart.

The model files can be in any format that PLIB's "SSG" library can load -
there are quite a few loaders now for a range of common formats.  I havn't
tested many of them though and I suspect that some of them are 'patchy'
in implementation.

I've been using AC3D to model stuff for TuxKart - and the AC3D file format
is pretty well supported.

I've had to 'extend' the AC3D format a little by using the "Object Data" field
to contain the additional parameters.  The TuxKart engine knows how to do
simple repetitive motion on either whole objects or texture maps based on
that data...eg, I have moving water and lava streams by setting up a moving
texture in the AC3D Object Data field.  There are various other similar
extensions for 'model switched' animations and such like.

It would be easy to add other kinds of effects into the model in that way.

Since most model formats allow for some kind of text field to be attached
to nodes in the database, this same technique should work for other model
formats - although we may need to get the authors of those loaders to
support the callback function that the AC3D loader uses to tell the
application program that this happened.

A second kind of effect comes from which texture map you use...I find
that model file formats don't tell me all I need to know about a polygon...
for example - do you crash if you hit it?  Yes - if it's a brick wall,
No - if it's a cloud of smoke.  What is the coefficient of friction?
Different for Ice than for Concrete.

These things will eventually be listed in a 'Material Reference File'
for the level - but for now, it's hard-compiled into the game.  Hence,
if you need an icy surface, you apply the texture "ice.rgb" and when
the model loads, I check that filename against my list of materials
and note that "ice.rgb" is a slippery material.  This means that you
can't re-use the ice texture map for anything that isn't supposed to
be slippery - but what the heck...that's a really easy solution.  It
also allows me to add new material properties without going back into
every single model adding that property into every single polygon.

Right now, the Karts in TuxKart are pretty simple - just a plain rigid
model.   That's going to have to change so the characters do stuff like
leaning into the corners, turning their heads, waving their fists (oh - wait,
none of them *have* fists :-)  ...however, remarkably little of that happens
in MarioKart - and my first goal is just to be AS GOOD AS MK64 - being better
than it can come later!

The Karts also need 2D icons for use in various parts of the game.

The filenames for the four Kart models and icons and the model files and
icons for the various collectibles are hard-coded into the game.  The
herrings and zippers plus sundry other things like the shadows of the
karts, missiles and herrings are also hard-coded into the game with
no model files to change.

All 2D icons and texture maps have to be in either BMP or SGI 'RGB'
format.  I greatly prefer the latter because BMP changes often
and my loader can't keep up.

One 'unit' in the database is nominally one meter in the real world - but
since we don't really know how big Tux and his friends are, this is
pretty arbitary.  Another way to think of this is that Tux is one meter
tall (that's just how big I think of him as being) - so one 'unit' is
one 'tux' high!  Real world penguins do get as big as a meter tall - but
Tux is a 'Jackass Penguin' and they only grow to about 30cm...however,
if he was that small, it would be hard to make levels because he ends
up being too short to reach furniture, door knobs, etc convincingly.

I come from a flight-simulation background where we use the convention
that Z-is-up - so all my software works like that.  However, the
PLIB loaders know that some modellers use Y-is-up and do the axis
swap as needed.  Hence, in AC3D, Y-is-up - but in the game, your
models will be converted to Z-is-up.  If you find this confusing,
forget I mentioned it - everything comes out OK automagically.

I know that some of these things are less configurable than you might
want them to be - but bear in mind that MarioKart was written by 23
people over two years.  Right now, TuxKart has been just me and my
son for about six weeks...you have to expect some corners to be cut!

> For example, I'd consider things like: the engine, what can/will it do ? No
> need to push the limits, I just need to know what can be done.

This is one area we need to think about...if you were designing Quake levels,
you'd want to push the limits of the existing engine in new and creative
ways.  If you are designing TuxKart levels then you can do better
than that because you can either tell me what your level NEEDS and the code
will magically appear to handle it...or you can modify it yourself.

> After that,
> overall design: the atmosphere of the game, its colors (at this level this
> is generic, to set the mood about the project), directions, etc. We don't
> need to make a clone...

No - we certainly don't.  Especially, I don't want to get prosecuted!

The artistic style of Crash Team Racing is MUCH nicer (to my mind)
than MarioKart - but it consumes a TON of texture map memory - and
that might be an issue for the more ancient graphics cards like
Voodoo-1.

So, if you like that plan, I'll bundle up TuxKart 0.0.0 onto
my web site and you'll have the dubious pleasure of being the
first person outside of my household to see it run!

I expect to release a beta of TuxKart to the world in just
a few weeks - the tracks I've already built are "adequate"
for a beta release - it would sure be nice to have one of
yours working as well - but I realise that's an awfully
short time frame.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net