tuxkart-devel — TuxKart Developers.

Re: [TuxKart-devel] configure dir

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

Bram Stolk wrote:
> 
> Steve Baker wrote:
> 
> > I have one machine with an nVidia GeForce and another with a Voodoo-3 2000 - and
> > they share a NFS partition on my home fileserver.  Hence, the exact same binaries
> > run on both machines - and I can compile on either one of them and run on the other.
> 
> Wow, even better! Why just share sources, if you can share binaries as well? :-)

That is generally the goal here.  If you have machines with the same CPU, you
should be able to do this...and you can!  With the advent of a working GLX
protocol, it becomes essential that the OpenGL of one machine is compatible
with the other because OpenGL will be running on one machine - being sent
commands from the other.  There are a few sneaky 'gotchas' in there because
of OpenGL runtime extension detection being rather ill-thought-out.  With
the OpenGL ABI for Linux, all that is sorted out.

> Let me try again: How do you fancy a tuxkart against stable plib1.2, and one
> against unstable plib1.3? Or do you use the 'one plib per machine' paradigm
> here as well?

No - I guess that would be useful - although I tend to work with the latest PLIB
all the time and just compile (after a make clean) against the stable release
before I make a release.  Since that's a rare event and I need to 'make clean'
to be really sure everything is going to work OK for the end user - it's not
really that much of a pain.

Anyway, your point is well taken - it's just that I don't have the necessary
skills to make it work.

> > However, I'm pretty much ignorant of the workings of autoconf/automake and
> > the manuals for them are *appaling* to read.  If you can guide me as to what
> > I need to do, I'll be happy to do it just so long as Joe Q Public can still
> > type ./configure;make;make install and have it "just work".
> 
> Quite a challenge.
> I'll see what I can do, although I have only access to gmake here.

OK...well if it's hard to you (who evidently knows this stuff) then it's
impossible for me.  If you feel a burning need to do it - then I'll happily
make use of the results (in all of my projects hopefully) - but it is an
absolute requirement that Joe Public can type './configure ; make ; make install'
to do 'the usual thing'.  That's become a de-facto standard for installing Linux
programs and if I deviate from that I'll get 1000 emails a week from people who
can't get it right and/or don't read the instructions.  That's not an exaggeration
BTW.

I you don't want to do it, I'll understand - I don't feel a huge need for this -
although it would be useful.

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

Re: [TuxKart-devel] configure dir

[Bram S. <br...@ch...>]

Steve Baker wrote:

> I have one machine with an nVidia GeForce and another with a Voodoo-3 2000 - and
> they share a NFS partition on my home fileserver.  Hence, the exact same binaries
> run on both machines - and I can compile on either one of them and run on the other.

Wow, even better! Why just share sources, if you can share binaries as well? :-)

Let me try again: How do you fancy a tuxkart against stable plib1.2, and one
against unstable plib1.3? Or do you use the 'one plib per machine' paradigm
here as well?

> However, I'm pretty much ignorant of the workings of autoconf/automake and
> the manuals for them are *appaling* to read.  If you can guide me as to what
> I need to do, I'll be happy to do it just so long as Joe Q Public can still
> type ./configure;make;make install and have it "just work".

Quite a challenge.
I'll see what I can do, although I have only access to gmake here.

  Bram


-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Bram Stolk               "Linux - Why use windows, if there is a door?"
  work: br...@sa...
  priv: br...@ch...

Re: [TuxKart-devel] configure dir

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

Bram Stolk wrote:
> 
> Steve Baker wrote:
> >
> > Bram Stolk wrote:
> >
> > > A remark:
> > > autocont/automake suggests doing the configure stage in a directory
> > > other than the distrib dir.

Ah!  Now I understand - you just want the binaries somewhere separate
from the sources...and the proposed way to do that is to run the configure
file from the distribution tree in an empty directory heirarchy so that
the object code ends up there instead of all mixed up in the source tree
(something which annoys me no end with autoconf/automake).

> But I think the author forgets the main reason:
> 
> If I want to build for three architectures (intel,alpha,ppc), and for each
> architecture

Yep - I agree 100% - we have this problem all the time at work where we
have to build the same code for three different IRIX varients, a Solaris
machine and a bunch of Linux boxes - some with Alpha's and some with Pentiums.

The problem here is that it requires the GNU version of make to do this - and
MANY systems don't have that installed as the default...or at all for that
matter.  There are also numerous 'pmake', 'smake' and 'NMAKE' varients with
certain advantages to each...pmake and smake can do cool parallel makes on
machines like our big ONYX boxes that have 40+ CPU's. GNU make gives up and/or
crashes when you do that.

What we did was to write a preprocessor for our Makefiles that takes a special
'XMakefile' - runs it through cpp and a number of other tools and spits out a
normal 'Makefile' - which it then passes to whatever underlying make there is.

Then in each source directory, we have daughter directories named after each
machine architecture and the makefile mangler manages to get the '.o' and '.a'
files to disappear into those daughter directories by stuffing '-o' directives
onto compile lines and various other subterfuges.

For our own purposes, this works quite well and with 'make' aliased to 'xmake',
nobody is even very much aware of the intrusion.  Regenerating the Makefile
before each 'make' has the advantage that we can hide the annoying differences
between 'make' implementations.

However, that's clearly not a solution for mass distribution.

> Heck, you could even have a Mesa-build and a nVidia OGL build coexist on your
> system,
> sharing the same sources. Now don't tell me that this does not appeal to you :-)

erm - sorry:

      "That does not appeal to me".   :-)

The reason it doesn't is that now that we have the "OpenGL ABI for Linux" stuff
nailed down, I don't *need* separate binaries for nVidia and Mesa.  Here at home,
I have one machine with an nVidia GeForce and another with a Voodoo-3 2000 - and
they share a NFS partition on my home fileserver.  Hence, the exact same binaries
run on both machines - and I can compile on either one of them and run on the other.

> It really must.

Nope!

> But as I've said, the numbers tell you it's not worth the effort. So please
> ignore my pedantic ramblings, and enjoy the success of yet another steve
> and oliver baker tux game :-)
> I just hope you agree with me now, that the illicit reasons do exist.

Actually, I do want to do things right - just so long as it doesn't screw
things up for the majority of users - and now I understand what you are
talking about, I whole-heartedly agree as to the need.

However, I'm pretty much ignorant of the workings of autoconf/automake and
the manuals for them are *appaling* to read.  If you can guide me as to what
I need to do, I'll be happy to do it just so long as Joe Q Public can still
type ./configure;make;make install and have it "just work".

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

[TuxKart-devel] Latest News.

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

Progress Today:

 * All of Norman's patches are now installed under CVS, so if you
   have CVS running and CygWin installed, you can do the highly
   perverse thing of running a game based on the Linux mascot under
   windoze.

   Hmmm - on the other hand, the 'Blue Screen of Death' guy is someone
   who is pretty familiar to those Windoze users - so perhaps it's not
   so bad.   :-)

 * I've written a guide to generating your own tracks - that's up on
   the website.

 * I've split up the *huge* 'index.html' into a bunch of smaller pages
   so the web site is a little more 'navigable'.

Questions:

  Does anyone know what it is about an HTML document that makes some
  of them load all the text first - and fill in the images only when
  all of the text is up?

  All the pages I write seem to sit there loading images for an eternity,
  then pop up the text only when all the images are there.

  This isn't just a browser settings thing - some pages work one way,
  and some work the other.

  Since all my images are just eye candy - it would be nice if the
  text always appeared first so you could be reading it while you
  are waiting for the pretty pictures.

  I've never been taught HTML - or even read a book about it - I've
  always just copied the HTML I've seen in other people's web pages.

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

Re: [TuxKart-devel] configure dir

[Bram S. <br...@ch...>]

Steve Baker wrote:
> 
> Bram Stolk wrote:
> 
> > A remark:
> > autocont/automake suggests doing the configure stage in a directory
> > other than the distrib dir.
> 
> Why?  That's crazy - everyone unpacks the tarball, cd's into
> the newly formed directory and types ./configure;make;make install
> ...which works just fine.
> 
> Why on earth would you want to do any different?
> 
> > If you follow this advice, a make install will fail for tuxkart.
> > (/usr/local/share/* remains empty)
> > Turkart will only install if distrib-dir == configure-dir.
> 
> I guess I don't understand the issue - nobody else of the 1000 or
> so downloads since yesterday has mentioned this. TuxAQFH and PLIB
> both use the same mechanisms - and between those two, that's 200,000
> downloads with no complaints.
> 
> What's the problem?

Eh, you're right about the little impact of the issue, and because
it works for 99.999999% of your users, I understand that it is probably
not worth fixing.

However, if you want to do the "Right Thing" as you call it, I beg you to
read a bit further.

The document "the GNU configure and build system" states that seperation is
'highly recommended',
and gives some arguments at http://www.airs.com/ian/configure/

an excerpt:

* In order to use a object directory which is different from the source
directory, you must be using the GNU version of `make', * which has the
* required `VPATH' support. Despite this restriction, using a different object
directory is highly recommended: 
*
*      It keeps the files generated during the build from cluttering up your
sources. 
*      It permits you to remove the built files by simply removing the entire
build directory. 
*      It permits you to build from the same sources with several sets of
configure options simultaneously. 

But I think the author forgets the main reason:

If I want to build for three architectures (intel,alpha,ppc), and for each
architecture
I want to test the difference between optimized and non-optimized builds, then I
do not
want to have 6 copies of the source. Each target each own build dir, and only 1
src dir
is very clean.

Heck, you could even have a Mesa-build and a nVidia OGL build coexist on your
system,
sharing the same sources. Now don't tell me that this does not appeal to you :-)
It
really must.

Also, making a distribution is easier, you can tar the src dir, without having
to worry
about what's in there: it will be sources only, no configure residue.

But as I've said, the numbers tell you it's not worth the effort. So please
ignore my pedantic ramblings, and enjoy the success of yet another steve
and oliver baker tux game :-)
I just hope you agree with me now, that the illicit reasons do exist.

    Bram Stolk


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Bram Stolk               "Linux - Why use windows, if there is a door?"
  work: br...@sa...
  priv: br...@ch...

Re: [TuxKart-devel] CygWin TuxKart

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

Norman Vine wrote:
> 
> Hi All,
> 
> Attached find patch to change all texture names to relative paths
> and to allow TuxKart to run on WIN32 using Cygwin V1.2.

I'm having trouble applying your patch files because my version
of the code has changed in the meantime.

I figured out most of them.

Could you please send me the literal source files for guNet.cxx
and start_tuxkart.cxx

Thanks.

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

Re: [TuxKart-devel] CygWin TuxKart

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

Norman Vine wrote:

> Attached find patch to change all texture names to relative paths

...that's not actually as useful as you might think - every time I
load one of these models into AC3D and save it out, AC3D puts it
back to an absolute name (grrrrr!).

In tuxkart-0.0.1 (released late yesterday), I fixed the loader
so that it ignores all but the last step of the path - which
fixes the problem completely.  It was always supposed to work
that way - but I had a bug.

> and to allow TuxKart to run on WIN32 using Cygwin V1.2.

...very good!
 
I'll put that into CVS immediately - there's likely to be another
new release in a few days anyway.

> This may also work with earlier versions of Cygwin.

OK.

> FYI
> A little slow but playable on PII-233 with pci bus TNT card.

Yep - that's what I'm finding under Linux also - I know what I need
to do to make it fast - but it's a pain to code so I've been putting
it off until I get some more features in place.

I got about 150 tuxkart-related emails yesterday - it takes a while
to catch up!

> I found the missing flames.rgb in the Tux_AQFH distribution.

Yep - good guess!  That file is also in 0.0.1.

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

Re: [TuxKart-devel] configure dir

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

Bram Stolk wrote:

> A remark:
> autocont/automake suggests doing the configure stage in a directory
> other than the distrib dir.

Why?  That's crazy - everyone unpacks the tarball, cd's into
the newly formed directory and types ./configure;make;make install
...which works just fine.

Why on earth would you want to do any different?
 
> If you follow this advice, a make install will fail for tuxkart.
> (/usr/local/share/* remains empty)
> Turkart will only install if distrib-dir == configure-dir.

I guess I don't understand the issue - nobody else of the 1000 or
so downloads since yesterday has mentioned this. TuxAQFH and PLIB
both use the same mechanisms - and between those two, that's 200,000
downloads with no complaints.

What's the problem?
 
> I cannot comment on the game itself, unfortunately, I do not
> have a joystick. (I guess my forcefeedback wheel is a no-go with linux)

Dunno - the force-feedback part is no-go because Microsoft won't share
the interface details for force-feedback devices.  But as a digital
joystick-like device, it's probably supported.
 
I'm working on a keyboard and/or mouse interface as we speak - so
it shouldn't be long in coming.

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

RE: [TuxKart-devel] CygWin TuxKart

[Norman V. <nh...@ca...>]

Hi All,

Attached find a new guClock.cxx that lets CYGWIN
use Windows' PerformanceCounter

This helps a LOT :-)

Happy Karting !!

Norman

[TuxKart-devel] CygWin TuxKart

[Norman V. <nh...@ca...>]

Hi All,

Attached find patch to change all texture names to relative paths
and to allow TuxKart to run on WIN32 using Cygwin V1.2.

This may also work with earlier versions of Cygwin.

Looks Great !!

FYI
A little slow but playable on PII-233 with pci bus TNT card.

I found the missing flames.rgb in the Tux_AQFH distribution.

Happy Karting :-))

Norman

[TuxKart-devel] configure dir

[Bram S. <br...@ch...>]

Steve Baker wrote:

>FYI:  I just released the first release of TuxKart - which uses PLIB and
>the same characters as my Tux_AQFH game.
>
>     http://tuxkart.sourceforge.net

Nice one! Congrats.

A remark:
autocont/automake suggests doing the configure stage in a directory
other than the distrib dir.

If you follow this advice, a make install will fail for tuxkart.
(/usr/local/share/* remains empty)
Turkart will only install if distrib-dir == configure-dir.

I cannot comment on the game itself, unfortunately, I do not
have a joystick. (I guess my forcefeedback wheel is a no-go with linux)

   Bram


-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Bram Stolk               "Linux - Why use windows, if there is a door?"
  work: br...@sa...
  priv: br...@ch...

[TuxKart-devel] RE: [Plib-devel] TuxKart.

[Norman V. <nh...@ca...>]

Steve Baker wrote:
>
>Norman Vine wrote:
>
>> Congratulations on launching number two !
>
>BTW: There is now a tuxkart-devel mailing list - details on 
>the web site.
>
>We should probably continue this thread over there.
>

OK  -- I'm here

           _\\|//_
          (' O-O ')
-----ooO-(_)-Ooo---- 

[TuxKart-devel] Re: tuxkart

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

> bionix <in...@pe...> wrote:

> do you want to have a graphician at your side? i would like to made some
> levels, models, textures and other gfx stuff.... currently i make some
> models like wipeout for the xracer-team...

Cool!  Yes - I would very much like help.

There is already one guy (Willian) thinking about contributing - but with a game like this, there
is plenty of room for several model builders to work on different levels.

I suggest you sign up to the TuxKart-devel mailing list - info on how to do that is on
the TuxKart web site.  I've exchanged a handful of emails with Willian already -
so I suggest you look at the mailing list archives so you'll know what we've already
talked about.

The mail archives are here:

         http://www.geocrawler.com/lists/3/SourceForge/3037/0/

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

[TuxKart-devel] New tarball.

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

There is a new tarball being downloaded right now that fixes the missing 'level.h' file
problem.

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

[TuxKart-devel] tuxkart's tarball doesnt' compile - Doh!

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

William Kendrick wrote:

> % make

> In file included from tuxkart.cxx:2:
> tuxkart.h:60: level.h: No such file or directory

Huh!  That file exists on my machine...oh - I see, it's not in Makefile.am
so it's in the CVS version but doesn't appear in the tarball...ick!

The file 'src/level.h' is (fortunately) very short.  It just contains:

struct Level
{
} ;

...and that's it.  Please type it in and try again.  I'll make a new
tarball as soon as you confirm that it'll compile OK.

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

[TuxKart-devel] ANNOUNCING TuxKart 0.0.0(alpha)

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

ANNOUNCING TuxKart 0.0.0(alpha)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

TuxKart 0.0.0(alpha) is now available from CVS on SourceForge.

Since the TuxKart homepage isn't written yet, you have to go
to http://sourceforge.net and use the 'Search' tool to find
TuxKart's admin page and go from there...<sigh>

Installation is the usual:

   ./configure
   make
   make install

(As a developer - you may wish to skip the "make install"
since all it does is copy all of the files off into /usr/local
somewhere)

Anyway - be sure to read the 'README' file before proceeding.

I'll try to put up a regular tarball and a simple homepage
later today - if I get that far, I'll post another notice
here.

This is only an alpha release - be gentle with me!

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

Re: [TuxKart-devel] The story

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

Willian Padovani Germano wrote:

> > Hmmm - the code for doing all this may well be twice as complex as the
> > whole of the rest of the game!  (Which is not to say that we shouldn't
> > do it...but keep in mind that every line of sophistication we put into
> > the intro sequence is a line of code that doesn't improve playability,
> > etc during the actual game itself.)
> 
> No, I mean actual gameplay in the story mode, not cut scenes. I have to
> touch powerups and the kart physics to explain this better:

Ah - OK.
 
> We can have powerups that when cast on other players will, f. ex. mess with
> the directions on their joysticks, cut their acceleration or max speed to
> 3/4 or 1/2 of it, mess with the brakes, make the car very heavy, etc. This
> kind of atack *is* a bother when done well, with good sounds, etc. But
> powerups are not being discussed yet (they gotta be well thought out, maybe
> even allowing people to create their own under certain classes). Anyway, if
> we have something like that, we have ways, probably variables on the
> formulas, that may affect speed, weight, etc. without the direct action of
> the player, like in MK 64. So it's easy to start the game (the actual game
> itself) with characters that don't drive well:

Yep - all of that should be do-able.

I currently have 5 'good things' (triggered by eating a Red Herring)
and two 'bad things' (triggered by eating a Green Herring by mistake).

Good things are collectables - just like MarioKart - you pick them
up by driving through the Red Herring (or "?" cubes in MK) and
activate them by pushing the 'C' button on the joystick.

Bad things happen immediately - and last for a few seconds before
'going away' by themselves.

Good Things:

  * Missiles - unguided but fast.  If they hit anything, they
    explode impressively.  The effect on a Kart is to stop it
    dead - so you have to accellerate again.  Not as bad for
    the victim as the shells in MK64.

  * Homing missiles - slower than the regular kind - but they
    track the nearest kart and are quite hard to shake off.

  * Fuzzy blobs - even slower still - a kart can outrun them
    quite easily.  They ricochet around like the shells in
    MK64 and only explode when they hit a Kart.

  * Magnets - if you activate a magnet then it hangs around for
    about 15 seconds. If anyone comes within about 20 meters,
    you'll be pulled towards them and end up glued to their
    tail until the magnet 'expires'.  Great for catching up
    with someone - hopeless for passing them.

  * Portable Zippers - these are just like the zippers on the
    track itself - they give you a sudden accelleration and
    temporarily increase the top speed of your kart.

Bad Things:

  * Parachute - this pops out the back of your kart and slows
    you down a little for a few seconds only.  Enough to drop
    you back one place if it's a close race though.

  * Anvil - gets dragged behind your kart on a rope for an
    even shorter amount of time than the parachute...but the
    drag effect is much stronger - your kart hardly moves at all.


To start with I'm going to put the kart's handling characteristics
on sliders in the startup screen - so you can play with the kart
without restrictions.  Once we are happy with the range of values
that work, we can relegate the sliders to a hidden 'easter egg' mode
activated with a password or something.

(Hmmm - we need to think about Easter Eggs - I *like* those).
 
> a) They don't react well to joystick commands (turn less or more than
> expected, accel too much (done via a boost followed by a sudden brake),
> etc.). As the player progresses, for example by training especific tasks,
> they get more responsive. The randomness in lack of response goes to zero.
> b) The car "dies" now and then, doesn't run smoothly -- typical for newbie
> drivers. Done via unnexpected (not controlled by the player) accel/brake.
> 
> This is just a trick to increase playability time, simpathy for the
> characters, sense of hard work getting results, etc. Done well, the code is
> trivial (I suppose, well possibilities can be cut down to what is trivial)
> and the game gets better.

Yep - MarioKart was sadly lacking in those things...come to think of it,
so are all the other Kart games I can think of.

> Find the hidden *whatever* that suddenly appears on the track, follow the
> leader as close as possible but DON'T touch his/her car, run away, etc. etc.
> Yes, children's games make some nice additions to increase gameplay.

Yes!
 
> > My games allow free movement anywhere in the scenery - collision detection
> > happens on the full geometry - so you can go anywhere and "the right
> thing"
> > will happen.
> 
> Great, that's a playfield :).
> 
> > You can build literally anything in the modeller and load it as a track
> 
> Man, this "anything and load it as a track" got me suddenly smiling :).

Yep - it has to be that easy so that my kid can do it!

We have two PC's setup next to each other - you can tweak the model in
AC3D on one of them - hit the 'SAVE' key and start up TuxKart immediately
on the other machine.  As you playtest, you can go back and tweak the
model on the first computer.

Development time is *short*...immediate gratification!

> > If I have time after that then I'll make a tarball for TuxKart and
> > put it up on sourceforge - I'll email you instructions on how to
> > grab it and install...but maybe not until tomorrow if this PLIB
> > thing gives me any problems.
> 
> Don't worry with the time, I'll never push you. Besides that, I have plenty
> of things to keep me busy here, as you know... Ah, today I played many hours
> with Blender 1.80a. I can already model and transform simple things, apply
> textures like bump maps, wood, metal, put lights and move the camera,
> animate, etc. I'm trying always to reduce as possible the number of
> polygons, of course.

Do you have CVS on your machine?

It would be good if you could use CVS for updates between major versions.
 
> > BTW: Do you have an account on Sourceforge?   If not, go to their
> 
> I got one before I subscribed to this list today, name: Willian.

Good!  I'll go and get you developer access rights on the TuxKart
site - we can add access to the TuxAQFH site when you get a yen to
hack on that game too.

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

Re: [TuxKart-devel] The story

[Willian P. G. <wge...@za...>]

Hi Steve,

> OK - I have to say that I am not a great believer in plots.  On existing
> games they are universally (a) lame and (b) irrelevent.  I can tell you
> that *none* of the kids who I meet who play video games every even look
> at the story.

(a) lame: I agree totally. But they are only irrelevant in games where they
are actually very strongly set, well-rounded, like sports, doom, etc. In
these games your experience of how you'd feel in that situation creates a
background plot. In sports there's up and down, victory and shame, etc. It
drives the game. In doom you are in a bad place and gotta get out fast. They
are ugly and shoot at you. You get guns. Simple. This is not "flat", it
actually uses our own fears and instincts. Clever doom...

Of course puzzles like tetris need no plot at all.

> HOWEVER - I recognise that games designers and developers seem to set
> great store by them...god knows why...but they do. So I guess we have
> to have one too.

The plot models the overall feel and look of a game. Given a good one,
design decisions, art, etc. come up naturally. Besides that, if you like
Star Wars, think about the games made about it. Most are not very good, but
it's Star Wars, there's a whole captivating story behind it, so the games
gain a lot just from being Star Wars. A good story gives the player
motivation. Kids may be motivated by other things, but if you think about
it, there's a story behind:

1) the videogame itself is magical to a kid, the fact that they are playing
with it already sets the mood;
2) there's the challenge part, they want to say they 'finished' that game;
3) usually they know other kids and there's a whole universe around
videogames among them: competition, sharing, vanity, brotherhood, famous
games every gamer must play, etc. This is the motivation behind multiplayer
internet games also, of course.
4) children are much more open to fantasy. If a game has warriors, dragons,
etc., the young player becomes part of that story as he/she (though games
that appeal to most girls is another field, little explored) plays along.
You think they didn't need the plot, but actually they are immersed in their
own plot. That is strong.

> > That's where I'd grab a plot (we could call it a meta-plot): on the fact
> > that every mascot must have his kart game, no matter what. A humorous
twist:
>
> Teehee!  :-)
>
> I *like* that.

Great :).
> > where he is safe and well, warm, and throw him in a kart game.
>                              ^^^^
>                              No! "cool". He *likes* it cold
>                              he lives at the south pole.

Sorry, I used "warm" meaning what a penguin would consider warm (meaning
comfortable), that's why I used "well, warm". So yes, I meant cold, too.

> Hmmm - I'm actually a little reluctant to drag real people into
it...however
> subtly it's done.  I have visions of how this got out of hand in the XTux

I agree with you, actually I don't hate Bill Gates, though I do think that
he could have been really important if he had been generous and smart at the
right time. But what do I know about corporations ? Maybe that would not
even be possible, life is complicate, that's why I try to live mine
according to my principles and rather not criticize others. I mean a spoiled
brat like that rich boy from Tiny Toons, ressembling Gates just slightly,
for fun -- but you are right, maybe even that should be avoided.

> AT ALL!  I'd prefer that we just don't go there.

Ok, agreed :).

> Couldn't we do the awful Windoze dancing paperclip instead?

> I *don't* want the Windoze logo directly used either (lawyers...) - I
think
> BSOD is sufficiently subtle to not be a problem - and a paper clip is just
> that - a paperclip - so no copyrights are infringed there either.

I agree again, we don't have the right to use copyright material and there's
no need for it.

> I'd *really* like to do a parody of the 'fluttering sheet of paper'
animation
> that windoze does when copying files...the sheets flutter across the
screen -

> Finally Tux comes on-screen and quietly places a copy of Samba
> onto the floor - all the mess immediately vaporises and papers once
> again flutter neatly across the screen so it can all happen again.
>
> ...sorry - that was just a vision that popped into my head - I have no
idea
> if it fits in anywhere.  :-)

That's surely a funny animation. But for this game... maybe we could make
powerup attacks out of this.

> ...but hey - you are the artist!  Let's do some sketches.

Yes, I'll do some on paper :).

> > Another point: with Tux unwilling to play, not knowing how, we can have
a
> > first part of the game where all of the characters drive terribly (car
> > "dies" now and then, turns end up on the walls, jumps end badly, motor
> > doesn't start, car runs in "spurts" (my knowledge of English doesn't
help
> > sometimes...). This all independent of the talent of the player, till he
> > practices enough (like raising an rpg character) that Tux or the others
> > actually become good racers. Of course this phase shouldn't take too
long,
> > and should be restricted to a story mode.
>
> Hmmm - the code for doing all this may well be twice as complex as the
> whole of the rest of the game!  (Which is not to say that we shouldn't
> do it...but keep in mind that every line of sophistication we put into
> the intro sequence is a line of code that doesn't improve playability,
> etc during the actual game itself.)

No, I mean actual gameplay in the story mode, not cut scenes. I have to
touch powerups and the kart physics to explain this better:

We can have powerups that when cast on other players will, f. ex. mess with
the directions on their joysticks, cut their acceleration or max speed to
3/4 or 1/2 of it, mess with the brakes, make the car very heavy, etc. This
kind of atack *is* a bother when done well, with good sounds, etc. But
powerups are not being discussed yet (they gotta be well thought out, maybe
even allowing people to create their own under certain classes). Anyway, if
we have something like that, we have ways, probably variables on the
formulas, that may affect speed, weight, etc. without the direct action of
the player, like in MK 64. So it's easy to start the game (the actual game
itself) with characters that don't drive well:

a) They don't react well to joystick commands (turn less or more than
expected, accel too much (done via a boost followed by a sudden brake),
etc.). As the player progresses, for example by training especific tasks,
they get more responsive. The randomness in lack of response goes to zero.
b) The car "dies" now and then, doesn't run smoothly -- typical for newbie
drivers. Done via unnexpected (not controlled by the player) accel/brake.

This is just a trick to increase playability time, simpathy for the
characters, sense of hard work getting results, etc. Done well, the code is
trivial (I suppose, well possibilities can be cut down to what is trivial)
and the game gets better.

> Perhaps adapt some of the classic childrens games.  I wrote (and later
> discarded) a flying game with broomsticks and wizards (we were reading
> the "Harry Potter" books at the time.  Anyway, one fun thing to do with
> that (in multiplayer mode) was to do "Hide and go seek" - where one player
> drives off into the scenery and hides while the other one catches them.
>
> Also games like Tag and Flashlight Tag.

Find the hidden *whatever* that suddenly appears on the track, follow the
leader as close as possible but DON'T touch his/her car, run away, etc. etc.
Yes, children's games make some nice additions to increase gameplay.

> My games allow free movement anywhere in the scenery - collision detection
> happens on the full geometry - so you can go anywhere and "the right
thing"
> will happen.

Great, that's a playfield :).

> You can build literally anything in the modeller and load it as a track

Man, this "anything and load it as a track" got me suddenly smiling :).

> If I have time after that then I'll make a tarball for TuxKart and
> put it up on sourceforge - I'll email you instructions on how to
> grab it and install...but maybe not until tomorrow if this PLIB
> thing gives me any problems.

Don't worry with the time, I'll never push you. Besides that, I have plenty
of things to keep me busy here, as you know... Ah, today I played many hours
with Blender 1.80a. I can already model and transform simple things, apply
textures like bump maps, wood, metal, put lights and move the camera,
animate, etc. I'm trying always to reduce as possible the number of
polygons, of course.

> BTW: Do you have an account on Sourceforge?   If not, go to their

I got one before I subscribed to this list today, name: Willian.

--
Willian, wge...@za...

Re: [TuxKart-devel] The story

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

Willian Padovani Germano wrote:

> I'll make some comments here about what may be a plot for TuxKart or why it
> is good to have one.

OK - I have to say that I am not a great believer in plots.  On existing
games they are universally (a) lame and (b) irrelevent.  I can tell you
that *none* of the kids who I meet who play video games every even look
at the story.

HOWEVER - I recognise that games designers and developers seem to set
great store by them...god knows why...but they do. So I guess we have
to have one too.

You'll notice that there is one for Tux_AQFH - right there on the web
site.
 
> That's where I'd grab a plot (we could call it a meta-plot): on the fact
> that every mascot must have his kart game, no matter what. A humorous twist:

Teehee!  :-)

I *like* that.

> Tux is a penguin, he doesn't want to drive a kart, has no skill or will for
> that. But he is a mascot, he MUST star in a kart game. So we grab him from
> where he is safe and well, warm, and throw him in a kart game.
                             ^^^^
                             No! "cool". He *likes* it cold
                             he lives at the south pole.

                             (Yes, I know there are penguin colonies
                             within 160 miles of the Equator - and no
                             penguins in Antarctica except at the coast
                             which is hundreds of miles from the south
                             pole - but this is a stereotype - so we go
                             with it)

> The other
> characters could be all very excited about the experience, to contrast with
> Tux's initial mood.

Gown:  "Ooh - ooh! Can we Tux?  Can we, can we, can we?  Puleeeze?"
Tux: "But I've just got this last function to debug in the 10baseT
      driver - I promised Linus we'd get the release out in time,"
<cut to start of race>
Narrator: "Can Tux win all the races - end the contest early and
      get back to the South Pole in time to save the 10baseT driver
      in time for the 2.4.1 kernel release?"

Yada, yada, yada...

> That's a start for the game: from the point where it is
> stated that Tux must have a kart game till when he and his friends are
> thrown in the main, central scenery, from where all tracks are accessable
> sooner or later (like that part in Diddy Kong Racing). There are many ways
> to make this intro look good.

Yep.
 
> The enemies that may be used
> 
> ( I'd go for:
> - a kiddie version of Bill Gates ( with a spirit along that boy who owns the
> ball and wants to control how/when/where/if the kids get to play a little ).
> A spoiled brat, without stressing that he represents Gates, in my opinion;

Hmmm - I'm actually a little reluctant to drag real people into it...however
subtly it's done.  I have visions of how this got out of hand in the XTux
game - where Tux goes around smashing the heads of actual Microsoft employees
with a baseball bat!  I can just see some deranged idiot doing it for real
and us getting full press coverage for incitement.  I know it can be done
with style and care - but this is OpenSource and people can modify it to
make it better suit their sense of humor - and some people have NO SENSE
AT ALL!  I'd prefer that we just don't go there.

Couldn't we do the awful Windoze dancing paperclip instead?

I *don't* want the Windoze logo directly used either (lawyers...) - I think
BSOD is sufficiently subtle to not be a problem - and a paper clip is just
that - a paperclip - so no copyrights are infringed there either.

I'd *really* like to do a parody of the 'fluttering sheet of paper' animation
that windoze does when copying files...the sheets flutter across the screen -
in a perfectly orderly manner but every now and again, you notice that
one screws itself into a little ball and falls short of the destination
- sometimes one folds itself into a paper plane and sails off into the
distance.  As you watch, more and more bad things happen to your valuable
documents as they flutter past. Some burst into flames, some are ripped
to shreds by knife blades thrown from off-stage, one gets shot full of
bullet holes...etc, etc.  Eventually, none of your files are making it
across the screen.  This process should take like 10 minutes to build
up to a climax where there are nuclear explosions going off - recognisably
Quake-like rail guns are now being used to trash documents as they go
by - the entire lower half of the screen is now a growing pile of paper
which is burning.  There should now be screaming and stuff.

Finally Tux comes on-screen and quietly places a copy of Samba
onto the floor - all the mess immediately vaporises and papers once
again flutter neatly across the screen so it can all happen again.

...sorry - that was just a vision that popped into my head - I have no idea
if it fits in anywhere.  :-)

I need to write a little stand-alone desktop 'toy' that does that - maybe
a screen saver :-)

...one day.

Phew! OK - now back to regularly scheduled TuxKart discussions... :-)

> - the BSOD, a frightening creature (even for the young boy, of course) --
> maybe a thin silver/light gray body, not short, with a monitor as his head,
> with the Blue Screen of Death on);
> - others we may add later. )

OK.  My BSOD is just a monitor with a blue screen and three white rectangles
representing angry down-turned eyes and straight horizontal mouth.  The
monitor has tiny arms and feet...but no body.

...but hey - you are the artist!  Let's do some sketches.
 
> would enter on their own, to prove that Tux is inapt for a mascot (taken
> from how they try to prove that Linux is not a good OS blah blah...). They
> could now and then make comments (written or spoken, no matter now) like:
> "these karts are hard to configure!", "this interface is ugly", "leave all
> inner detais to us and relax", "we know better", "if we made the karts, Tux
> wouldn't fit on our patented chairs (remember that Gates versus automobile
> industry episode?)), etc., don't know about Microsoft slogans, but maybe we
> can make fun of them too.

:-)

> This is a light plot, not trying to come up with a stupid reason for the
> races or none at all. It ironically makes fun of being another game on the
> genre and settles nicely the place for Tux there. But it also sets the mood
> of the game, frees us to use ANY landscape for each track (there just gotta
> be icy ones, but also other new designs would fit well) without needing to
> explain why/how they ended up on this or that terrain in the story -- think
> about it...

Yep.  Icy tracks are just fun to drive - and I enjoy the Christmas feel you
can give to them - lots of nice bright colours to contrast with the blandness
of the snow.
 
> Another point: with Tux unwilling to play, not knowing how, we can have a
> first part of the game where all of the characters drive terribly (car
> "dies" now and then, turns end up on the walls, jumps end badly, motor
> doesn't start, car runs in "spurts" (my knowledge of English doesn't help
> sometimes...). This all independent of the talent of the player, till he
> practices enough (like raising an rpg character) that Tux or the others
> actually become good racers. Of course this phase shouldn't take too long,
> and should be restricted to a story mode.

Hmmm - the code for doing all this may well be twice as complex as the
whole of the rest of the game!  (Which is not to say that we shouldn't
do it...but keep in mind that every line of sophistication we put into
the intro sequence is a line of code that doesn't improve playability,
etc during the actual game itself.)
 
> This is a way of increasing the gameplay time and fun inside a single track
> (which may be the central place I mentioned before, like in Diddy Kong
> Racing). Since playing Mario 64, finding ways of increasing game time and
> level exposure to the player has been a concern for me. There's so much more
> to see in a 3D game.

Yep - having a central area to drive around is certainly pretty easy to do -
so long as there is a 'cut' when you enter the actual race track to give
us time to dump one model, load another and swap out all the textures.
 
> Having a meta, self-referential story like that allows us to place the game
> in a virtual world that at the same time is aware of our world, the
> internet, the fact that it is a game, etc. Then there may be the possibility
> for other people to add characters and tracks. It all fits nicely, even with
> the plot. The characters 'know' they are videogame mascots of an open source
> project, that people will download their game, make additions, etc. So they
> may enjoy the appearance of new racers, new tracks to try (A character
> says:"What about downloading some new tracks ? That'd be appreciated" or
> whatever), etc. They may comment on their website, have special packs for
> christmas, anything. Got it ?

Yep - I like that.

Tux_AQFH uses the 'central area leading out to the levels' trick - one thing
that this is well suited to is allowing people to add their own levels
fairly easily - just hack the central model to add another door, whatever
and add a new level filename into a config file somewhere.
 
> So what do you say ? That's just one possibility, but as I said, it leaves
> the design more open for different tracks, characters, etc.

Yep.
 
> Ah, one comment about different objectives: during a race, there may be an
> event like: BSOD or the boy got the superuser password! Get him fast or
> he'll become a deadly virus! Then that race is possibly forgotten (in story
> mode) and it becomes a chase the pesky one game.

Perhaps adapt some of the classic childrens games.  I wrote (and later
discarded) a flying game with broomsticks and wizards (we were reading
the "Harry Potter" books at the time.  Anyway, one fun thing to do with
that (in multiplayer mode) was to do "Hide and go seek" - where one player
drives off into the scenery and hides while the other one catches them.

Also games like Tag and Flashlight Tag.
 
> There are also many subgames and different modes that can be easily
> implemented, but that's a topic for some other email. 3D landscapes with
> basic physics laws, no matter how simple, are really playing fields,
> entertainment parks, not 'just' a single game. Mario 64 told me so...

Yes - exactly.

My games allow free movement anywhere in the scenery - collision detection
happens on the full geometry - so you can go anywhere and "the right thing"
will happen.

You can build literally anything in the modeller and load it as a track
and you can drive over it sensibly.  You need to add the '.drv' file
that contains a 'centerline' model in order to get the other drivers
to actually race around it - but if they are reprogrammed to play
Flashlight Tag or something, that's a non-issue.


Anyway - I'm just about to make a final 1.2 release of PLIB (a prior
commitment that I must keep because Mandrake Linux are waiting to
put it into their next distribution CD set - and the cut is made
tomorrow.

If I have time after that then I'll make a tarball for TuxKart and
put it up on sourceforge - I'll email you instructions on how to
grab it and install...but maybe not until tomorrow if this PLIB
thing gives me any problems.

BTW: Do you have an account on Sourceforge?   If not, go to their
main web site and request one (it's free - you just have to provide
some minor details)...once you have that, I can put you down as
a TuxKart developer which will give you access to the CVS archive
so that you can modify models, textures and sourcecode if you
feel the need.

I need to build a web page too...work, work, work!  (Fun, fun, fun too!)

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

[TuxKart-devel] The story

[Willian P. G. <wge...@za...>]

Hi, Steve

I'll make some comments here about what may be a plot for TuxKart or why it
is good to have one.

Every major console mascot since Mario had his kart game (Mario + Donkey
Kong, Sonic, Crash, Diddy Kong + Banjo + that Rare squirrel, etc.). That's
almost a shame that all others copied Nintendo, but hey, that's a great
idea, the games are funny. So it's natural that Tux get his own, too, being
such an important mascot.

That's where I'd grab a plot (we could call it a meta-plot): on the fact
that every mascot must have his kart game, no matter what. A humorous twist:
Tux is a penguin, he doesn't want to drive a kart, has no skill or will for
that. But he is a mascot, he MUST star in a kart game. So we grab him from
where he is safe and well, warm, and throw him in a kart game. The other
characters could be all very excited about the experience, to contrast with
Tux's initial mood. That's a start for the game: from the point where it is
stated that Tux must have a kart game till when he and his friends are
thrown in the main, central scenery, from where all tracks are accessable
sooner or later (like that part in Diddy Kong Racing). There are many ways
to make this intro look good.

The enemies that may be used

( I'd go for:
- a kiddie version of Bill Gates ( with a spirit along that boy who owns the
ball and wants to control how/when/where/if the kids get to play a little ).
A spoiled brat, without stressing that he represents Gates, in my opinion;
- the BSOD, a frightening creature (even for the young boy, of course) --
maybe a thin silver/light gray body, not short, with a monitor as his head,
with the Blue Screen of Death on);
- others we may add later. )

would enter on their own, to prove that Tux is inapt for a mascot (taken
from how they try to prove that Linux is not a good OS blah blah...). They
could now and then make comments (written or spoken, no matter now) like:
"these karts are hard to configure!", "this interface is ugly", "leave all
inner detais to us and relax", "we know better", "if we made the karts, Tux
wouldn't fit on our patented chairs (remember that Gates versus automobile
industry episode?)), etc., don't know about Microsoft slogans, but maybe we
can make fun of them too.

This is a light plot, not trying to come up with a stupid reason for the
races or none at all. It ironically makes fun of being another game on the
genre and settles nicely the place for Tux there. But it also sets the mood
of the game, frees us to use ANY landscape for each track (there just gotta
be icy ones, but also other new designs would fit well) without needing to
explain why/how they ended up on this or that terrain in the story -- think
about it...

Another point: with Tux unwilling to play, not knowing how, we can have a
first part of the game where all of the characters drive terribly (car
"dies" now and then, turns end up on the walls, jumps end badly, motor
doesn't start, car runs in "spurts" (my knowledge of English doesn't help
sometimes...). This all independent of the talent of the player, till he
practices enough (like raising an rpg character) that Tux or the others
actually become good racers. Of course this phase shouldn't take too long,
and should be restricted to a story mode.

This is a way of increasing the gameplay time and fun inside a single track
(which may be the central place I mentioned before, like in Diddy Kong
Racing). Since playing Mario 64, finding ways of increasing game time and
level exposure to the player has been a concern for me. There's so much more
to see in a 3D game.

Having a meta, self-referential story like that allows us to place the game
in a virtual world that at the same time is aware of our world, the
internet, the fact that it is a game, etc. Then there may be the possibility
for other people to add characters and tracks. It all fits nicely, even with
the plot. The characters 'know' they are videogame mascots of an open source
project, that people will download their game, make additions, etc. So they
may enjoy the appearance of new racers, new tracks to try (A character
says:"What about downloading some new tracks ? That'd be appreciated" or
whatever), etc. They may comment on their website, have special packs for
christmas, anything. Got it ?

So what do you say ? That's just one possibility, but as I said, it leaves
the design more open for different tracks, characters, etc.

Ah, one comment about different objectives: during a race, there may be an
event like: BSOD or the boy got the superuser password! Get him fast or
he'll become a deadly virus! Then that race is possibly forgotten (in story
mode) and it becomes a chase the pesky one game.

There are also many subgames and different modes that can be easily
implemented, but that's a topic for some other email. 3D landscapes with
basic physics laws, no matter how simple, are really playing fields,
entertainment parks, not 'just' a single game. Mario 64 told me so...

--
Willian, wge...@za...

[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

[TuxKart-devel] Testing, testing

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

Just a test - please ignore

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

[TuxKart-devel] Testing.

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

Just a test - please ignore.

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)