tuxkart-devel — TuxKart Developers.

Re: [TuxKart-devel] Some crude Kart sketches

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

On Mon, 28 Jun 2004 16:20:28 +0200, Ingo Ruhnke <gr...@gm...> wrote:
> 
> 
> Some crude Kart sketches:
> 
> http://pingus.seul.org/~grumbel/tmp/tuxkarts.jpg

They look great. It'd be nice if we could see some of the back of the
bottom left one's (is it Nolok) head though. Also, Evil Tux's exhaust
seems to stick out a little too far from the side view.

-- 
Ryan

[TuxKart-devel] Re: Tuxkart-devel digest, Vol 1 #38 - 9 msgs

[Ricardo C. <ri...@ae...>]

 Direct link (since I guess there aren't that many Portuguese speakers 
around :) ):
http://paginas.fe.up.pt/freefeup/img/banner-pslf-web-transp-3508x2439.png

 Here you can see a few gnu-world characters that could be used.

 Other characters suggestions: Hypothamus, Shark, Octupus, Girafe, Crocodile.

> Message: 9
> From: Ricardo Cruz <ri...@ae...>
> To: tux...@li...
> Date: Mon, 28 Jun 2004 13:11:59 +0100
> Subject: [TuxKart-devel] Re: Tuxkart-devel digest, Vol 1 #36 - 8 msgs
> Reply-To: tux...@li...
>
>
>  Let me contribute with my 2 cents.
>
>  I agree with most of what Ingo said. The game should be designed for
> ordinary gamers, and such bonuses/maluses should be intuitive.
>
>  About characters, designers should have in mind that characters should be
> made so that when a player looks at it, he will feel like driving it.
>  Anyway, I think that if some Gnu-world character fits in the game, why not
> using it? I believe that the Mozilla dragon would fit very well in the
> game. Have a look at a few gnu characters here:
> http://www.fe.up.pt/freefeup/
>
> Cheers,
>  Ricardo
>

-- 
A father doesn't destroy his children.
		-- Lt. Carolyn Palamas, "Who Mourns for Adonais?",
		   stardate 3468.1.

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

Re: [TuxKart-devel] Some crude Kart sketches

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

Ingo Ruhnke wrote:
> Some crude Kart sketches:
> 
> http://pingus.seul.org/~grumbel/tmp/tuxkarts.jpg
> 

Wilder!!  More over-the-top!

Look at our competition:

http://www.sjbaker.org/tmp/tuxkart/

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

[TuxKart-devel] Some crude Kart sketches

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

Some crude Kart sketches:

http://pingus.seul.org/~grumbel/tmp/tuxkarts.jpg

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

Re: [TuxKart-devel] Re: Tuxkart-devel digest, Vol 1 #36 - 8 msgs

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

Ricardo Cruz wrote:
>  I don't agree with this.
>  Why not making it like any other Karts game? Each characters has its level of 
> difficulty.

They don't *all* work that way.  MarioKart'64 has an 'engine size' selection
(50cc, 100cc, 150cc IIRC) - what this changes is the game difficulty - in
a number of subtle ways...however, all of the characters are present in all
of those 'difficulty' levels.

As I recall, the Crash Bandicoot kart game has difficulty too (I'll have to
dust off our aging Playstation to find out).

Anyway - this is our game - and we get to choose how to do it.

The problem with each character having a hard-wired difficulty level is that
we'd have to make a LOT more characters.  If you want 'easy' 'medium' and
'hard', you'd need (at a minimum) four characters at each level otherwise
the beginner doesn't have four easy characters to race with - and the
experienced guy doesn't have four difficult characters to choose from.

That would force us to build at least 12 characters - but even having done
that, we still gave the player very little choice about who to race at
any given level of challenge.

If we put 'difficulty' factors into the game in other ways that don't
require us to change the Kart graphics each time - then there can be
more characters available at each stage (although we might want to make
some of them 'unlockable' so you have to work in order to play them).

We can change the abilities of the karts at different levels by changing
some constants in the code - speed, accelleration, cornering ability, etc.
We can also (in principle) change the skill level in the AI to do that.

This isn't unreasonable - after all, our human player's abilities
improve with practice - why shouldn't our game characters get better as
time goes on?

I strongly suspect that it's going to be hard to make even 12 character/kart
models that look good...so as a purely practical matter, I think difficulty
has to lie outside of character selection.

---------------------------- 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 #36 - 8 msgs

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

Ricardo Cruz wrote:

> http://www.fe.up.pt/freefeup/

Wow! That's the first time I've seen Wilbur with a body.  When I was writing
this game the first time around, I emailed the GIMP people to ask whether they
had a picture of Wilbur's body and they said he didn't have one...which makes
it a bit hard to use him in a game!  I think they guessed!

Which project uses the elephant?

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

[TuxKart-devel] Re: Tuxkart-devel digest, Vol 1 #36 - 8 msgs

[Ricardo C. <ri...@ae...>]

 Let me contribute with my 2 cents.

 I agree with most of what Ingo said. The game should be designed for ordinary 
gamers, and such bonuses/maluses should be intuitive.

 About characters, designers should have in mind that characters should be 
made so that when a player looks at it, he will feel like driving it.
 Anyway, I think that if some Gnu-world character fits in the game, why not 
using it? I believe that the Mozilla dragon would fit very well in the game.
 Have a look at a few gnu characters here:
http://www.fe.up.pt/freefeup/

Cheers,
 Ricardo

>
> Message: 2
> To: tux...@li...
> Subject: Re: [TuxKart-devel] Thoughts on Kart Models.
> From: Ingo Ruhnke <gr...@gm...>
> Date: Mon, 28 Jun 2004 02:59:30 +0200
> Reply-To: tux...@li...
>
> Steve Baker <sjb...@ai...> writes:
> > Pretty much every game has highly ad-hoc things. MarioKart uses
> > Cubes with '?' on them for good things and cubes with an upside-down
> > '?' for bad things. The confusion-until-the-last-minute thing is
> > absolutely crucial for game play. Ditto with herring colours.
>
> Well, that red is good and green is bad isn't obvious, traffic lights
> actually do it reverse. Beside that collecting herring and getting
> 'random item' is also not intuitive, a ?-box however is (they contain
> something, herring don't). So herring should if at all only be used as
> coin-like things, bonuses should just be stored in boxes like in
> Mario. I would remove the evil-?-blocks completly as standard map
> items and make them placeable by other players only.
>
> > I don't see how choosing an ice cube over a computer monitor changes
> > how things 'hang together'.
>
> It removes the pointless microsoft bashing element.
>
> > That's a ludicrous position. Change absolutely everything except
> > what we can't change? I don't know *ANY* commercial games of the
> > 'cute' genre that do that.
>
> Commercial games in general are the successors of good or even great
> games, thats something that isn't true for Open Source games, which
> are often just half finished, unplayable or worse. And starting from a
> half-finished not even really playable game under the premise to keep
> most stuff is just not moving you very must away from that
> half-finished thing and you will just end up with another incomplete
> looking patchwork.
>
> > BSOD is on the very skinnymost end of that curve...I couldn't
> > imagine a more subtle dig at one of the most truly evil companys on
> > the planet.
>
> BSOD is rather close to having Clippy driving around in a kart, its
> just Microsoft-bashing put down into shape, not something I want to
> have as a playable character or else we could start with creating
> Mr-Kernel-Oops and Mr-XFree-just-locked-up.
>
> > It's just an icon.
>
> Herring is not just an icon, its already closly related to Tux being a
> penguin, too closly already in case there are other non-penguin
> characters that should also consume that item.
>
> > What does a toadstool need coins for?
>
> Coin is a rather generic item.
>
> > Banana's are not in fact part of the natural diet of a gorilla.
>
> In Donkeykong games its used as coin-like item, in MarioKart it works
> only to make other Karts slip.
>
> > Herrings only swim in the Northern Hemisphere but Penguins only live
> > south of the equator.
> >
> > Who cares?  It's an icon.
>
> It either has to be generic enough so that one doesn't care about why
> its there (coin) or it has to be close enough related to what its
> meant to be (Herring->Penguin eating it). If BSOD starts eating
> herring things start looking wrong.
>
> >> SuperTux had a golden herring for invulnurability, got replaced
> >> with a 'classic' star.
> >
> > ...and that helped the game how exactly?
>
> It replaced the 'heck what should this ugly item do' with something
> more familiar and better regonizable.
>
> >> In SuperTux we have this little IceBlock as BSOD replacement: *
> >> http://pingus.seul.org/~grumbel/tmp/iceblock.gif
> >
> > Yeah - it's OK - but it's going to look silly in a lava-themed level.
>
> Could get a refrigerator on his back or something to keep him cool.
>
> >> And while, since BSOD is just the most obvious Microsoft bashing, I
> >> really would prefer to get rid of it.
> >
> > Sorry - I just can't agree with you on this one.
> >
> > So what's the solution to such impasses? Put both in there is my
> > recommendation.
>
> Make it a bonus-character that you have to unlock or whatever.
>
> >> As replacement for the butterfly-Tux we could use this little guy:
> >> http://super-tux.sourceforge.net/milestone1/images/flyingsnow.png
> >
> > Change for change's sake again...why change?
>
> Aehm, because butterfly-Tux is one of the ugliest things ever. It
> looks like big fat Tux with some wings stuck on him, well, it *is* big
> fat Tux with some wings stuck on him, so no wonder that it looks that
> way. I just can't stand characters that where only done the way there
> are due to technical limitaions and to easy modeling (why create
> something new, when one can reuse Tux over and over again), nothing
> wrong with doing it that back then, but I see little reason to keep it
> that way.
>
> > What is the reason that snow is so good and a butterfly Tux is so
> > bad? I can give the reasons why butterfly Tux is good:
> >
> > The butterfly Tux was originally an angel-tux...your guardian angel
> > coming to help you...but then we decided to make it
> > religion-neutral, hence the butterfly - a sign of peace of sorts.
>
> I don't care much about what it was meant to be, if it looks like
> big-fat Tux with wings, it just has to be dropped.
>
> >> Some other (not yet used) SuperTux characters:
> >> http://pingus.seul.org/~grumbel/tmp/eviltux.png
> >> http://pingus.seul.org/~grumbel/tmp/yeti2.jpg
> >
> > So your basic view is that any character you designed is good - and
> > anything the original 'consortium' of designers put together is bad?
>
> No, my work isn't necesarrily good, but since most of the original
> consortium evolves around character reuse with little changes,
> word-plays (Gown), logo-recycling, Microsoft bashing (BSOD) or geek
> stuff, yep, I consider it all rather bad and ugly.
>
> > Those are OK - I like the evilTux - but the Yeti is a DISASTER
> > because he has fur and doing good fur is a BIG no-no for anything
> > but the VERY latest of hardware...and even then, you have to want it
> > pretty badly to take the performance hit for it.
>
> It doesn't need to have real 3d-fur, after all its most of the time
> only seen from quite a bit behind. The fur should be fakable without
> too much throuble with some simple texture mapping.
>
> > The idea of a dinoasur in the abstract is surely a good idea -
> > painting it red and calling it Mozilla doesn't make much difference
> > to much - and some people will doubtless like the reference.
>
> And some other people would surly hate the reference. I don't mind it
> being a dino, I don't mind it being red, but calling it Mozilla just
> spoils the fun, Mozilla is a browser, not a game character the
> reference just doesn't make 'click', there is just not much that this
> red-dino-game character would have in common with some piece of
> browser software.

-- 
Eat right, stay fit, and die anyway.

[TuxKart-devel] Re: Tuxkart-devel digest, Vol 1 #36 - 8 msgs

[Ricardo C. <ri...@ae...>]

 I don't agree with this.
 Why not making it like any other Karts game? Each characters has its level=
 of=20
difficulty. This way, it is adds more challenge to the game, the more you a=
re=20
top ranked, the hardest it is to keep it/to pass through others.

 If the player is ranked before the num_of_karts/2, it will win. This way, =
it=20
will add replay value, since the players will won't to do better next time,=
=20
and play until they get into 1st.

Cheers,
 Ricardo

Em Segunda, 28 de Junho de 2004 03:57, o=20
tux...@li... escreveu:
>
> IMHO, the major programming tasks are:
>
> 1) AI - The karts that are not being driven by the player(s) need to
> =A0 =A0 know how to drive around the track without crashing into stuff and
> =A0 =A0 to drive agressively enough to be a challenge at the highest level
> =A0 =A0 of difficulty - and passively enough to let the player win in the
> =A0 =A0 easier levels. =A0They have to know when to shoot their weapons,
> =A0 =A0 how to dodge player-launched weapons, when to go for collectibles
> =A0 =A0 and when it's not worth it.
>

=2D-=20
The difficult we do today; the impossible takes a little longer.

Re: [TuxKart-devel] Developer privilages.

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

Caleb Sawtell wrote:

> mine is 'gaminggeek'..

You should have CVS privilages now.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

Re: [TuxKart-devel] Getting Started.

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

Caleb Sawtell wrote:

> would md2 be an option?
> or is that to hidden and closed source?

The file formats that PLIB currently supports (to a varying
degree of fidelity/quality) are:

  M   Strip  3ds    MD2       TGA
  AC  MDL    TRI    ASE       MDL_BGLTexture
  ATG OBJ    VRML1  BMP       OFF
  X   DOF    PCX    XPlaneObj DXF
  PNG FLT    SGI    IV        SSG

...some of those are texture image formats.

In addition, it can write out (again with varying
degrees of success/fidelity):

  3ds   ATG   OBJ   VRML1
  AC    DXF   OFF   X
  ASC   FLT   QHI   ASE
  M     TRI

...so we can (at least in theory) convert any of the
loadable files into any of the saveable formats using
a simple command-line or interactive tool.

However, as I've pointed out, some people have tossed in
file loaders that they wrote for very specific tasks that
only understand a small fraction of what can be expressed
in the underlying file format - so be prepared for some
of these to work poorly.

---------------------------- 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] A BSOD Kart.

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

Caleb Sawtell wrote:

> he could be sitting on a laptop instead of a seat

Yeah - that could work - but:

1) You really can't tell from the back.
2) The seat is an opportunity to get some much needed
    colour into an otherwise very monochromatic model.

I'll talk to Oliver...actually, he should probably be
subscribed here.

> the wheels could be thicker maybe 2 or 3 Cd's per wheel

Good idea!

I'd like them to be bigger - but he measured a real CD and
the PC he works on and they are "correct".  I pointed out
that they needn't be correct - but they do need to look right.

> and what did your son model it in?

AC3D (the Linux version).

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

[Caleb S. <gam...@gm...>]

On Sun, 27 Jun 2004 19:42:59 -0500, Steve Baker <sjb...@ai...> wrote:
> 
> Ryan Flegel wrote:
> 
> > Maybe some of these effects (that are in the comments) should be
> > stored into separate config files, instead of loading a model straight
> > up, load the config file which will include these comments, plus the
> > path to the model.
> 
> Actually, some of them are.  The '.loc' file does some of that.  The
> problem is that some effects need to be attached to a specific node
> in the database tree for the 3D model.  If you have something like
> a volcano model with lava running down the sides, you want moving
> texturemaps on the lava polygons but not on the rocky mountainside.
> 
> It's hard to locate those specific nodes from an external config
> file - so you tend to need to use some kind of ASCII string attached
> to the node to identify it.  Well, if you can do *that* then you
> might as well put the config data right into that ASCII string in
> the model file.
> 
> This is a much easier way to work - and somewhat guarantees that when
> you rearrange the model's heirarchy for some reason, that the config
> data stays attached to the correct parts.
> 
> The '.loc' file tends to have things of a more 'global' scope that
> affect the whole model file.
> 
> > Also, since AC3D seems to be missing some useful features, is there
> > any other format blender can export to that might suit our needs a lot
> > better?
> 
> That would be a useful experiment to try.
> 
> The PLIB library (which is what is actually doing the file loading) supports
> about 20 different file formats.  Some of these are well supported (AC3D
> is a good one - because I maintain it!) - others are flakey because someone
> implemented just enough of the format to get some job done - and then
> contributed a half-baked solution.
> 
> All format are ALWAYS missing some teeny-tiny detail though.  Doing
> utterly generic and *complete* 3D loaders is extremely difficult.

would md2 be an option?
or is that to hidden and closed source?


> 
> 
> 
> ---------------------------- 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-----
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Tuxkart-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxkart-devel
>

Re: [TuxKart-devel] A BSOD Kart.

[Caleb S. <gam...@gm...>]

On Sun, 27 Jun 2004 21:39:59 -0400, pmb <phi...@vi...> wrote:
> 
> 
> Steve Baker wrote:
> 
> > Attached is my son's first effort at a BSOD kart.  It needs lots of
> > work yet and
> > would need some animation effort to produce little electrical
> > discharges from
> > dangling cables, a spinning power supply fan, rotating wheels
> > (possibly wobbly),
> > and flashing LED's where appropriate.
> >
> > Comments?

he could be sitting on a laptop instead of a seat
the wheels could be thicker maybe 2 or 3 Cd's per wheel
and what did your son model it in?

> >
> > ---------------------------- 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-----
> >
> > ------------------------------------------------------------------------
> >
> I like it so much.
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Tuxkart-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxkart-devel
>

Re: [TuxKart-devel] Thoughts on Kart Models.

[Caleb S. <gam...@gm...>]

On Mon, 28 Jun 2004 02:59:30 +0200, Ingo Ruhnke <gr...@gm...> wrote:
> 
> Steve Baker <sjb...@ai...> writes:
> 
> > Pretty much every game has highly ad-hoc things. MarioKart uses
> > Cubes with '?' on them for good things and cubes with an upside-down
> > '?' for bad things. The confusion-until-the-last-minute thing is
> > absolutely crucial for game play. Ditto with herring colours.
> 
> Well, that red is good and green is bad isn't obvious, traffic lights
> actually do it reverse. Beside that collecting herring and getting
> 'random item' is also not intuitive, a ?-box however is (they contain
> something, herring don't). So herring should if at all only be used as
> coin-like things, bonuses should just be stored in boxes like in
> Mario. I would remove the evil-?-blocks completly as standard map
> items and make them placeable by other players only.
> 
> > I don't see how choosing an ice cube over a computer monitor changes
> > how things 'hang together'.
> 
> It removes the pointless microsoft bashing element.
> 
> > That's a ludicrous position. Change absolutely everything except
> > what we can't change? I don't know *ANY* commercial games of the
> > 'cute' genre that do that.
> 
> Commercial games in general are the successors of good or even great
> games, thats something that isn't true for Open Source games, which
> are often just half finished, unplayable or worse. And starting from a
> half-finished not even really playable game under the premise to keep
> most stuff is just not moving you very must away from that
> half-finished thing and you will just end up with another incomplete
> looking patchwork.
> 
> > BSOD is on the very skinnymost end of that curve...I couldn't
> > imagine a more subtle dig at one of the most truly evil companys on
> > the planet.
> 
> BSOD is rather close to having Clippy driving around in a kart, its
> just Microsoft-bashing put down into shape, not something I want to
> have as a playable character or else we could start with creating
> Mr-Kernel-Oops and Mr-XFree-just-locked-up.
> 
> > It's just an icon.
> 
> Herring is not just an icon, its already closly related to Tux being a
> penguin, too closly already in case there are other non-penguin
> characters that should also consume that item.
> 
> > What does a toadstool need coins for?
> 
> Coin is a rather generic item.
> 
> > Banana's are not in fact part of the natural diet of a gorilla.
> 
> In Donkeykong games its used as coin-like item, in MarioKart it works
> only to make other Karts slip.
> 
> > Herrings only swim in the Northern Hemisphere but Penguins only live
> > south of the equator.
> >
> > Who cares?  It's an icon.
> 
> It either has to be generic enough so that one doesn't care about why
> its there (coin) or it has to be close enough related to what its
> meant to be (Herring->Penguin eating it). If BSOD starts eating
> herring things start looking wrong.
> 
> >> SuperTux had a golden herring for invulnurability, got replaced
> >> with a 'classic' star.
> >
> > ...and that helped the game how exactly?
> 
> It replaced the 'heck what should this ugly item do' with something
> more familiar and better regonizable.
> 
> >> In SuperTux we have this little IceBlock as BSOD replacement: *
> >> http://pingus.seul.org/~grumbel/tmp/iceblock.gif
> >
> > Yeah - it's OK - but it's going to look silly in a lava-themed level.
> 
> Could get a refrigerator on his back or something to keep him cool.
> 
> >> And while, since BSOD is just the most obvious Microsoft bashing, I
> >> really would prefer to get rid of it.
> > Sorry - I just can't agree with you on this one.
> >
> > So what's the solution to such impasses? Put both in there is my
> > recommendation.
> 
> Make it a bonus-character that you have to unlock or whatever.
> 
> >> As replacement for the butterfly-Tux we could use this little guy:
> >> http://super-tux.sourceforge.net/milestone1/images/flyingsnow.png
> >
> > Change for change's sake again...why change?
> 
> Aehm, because butterfly-Tux is one of the ugliest things ever. It
> looks like big fat Tux with some wings stuck on him, well, it *is* big
> fat Tux with some wings stuck on him, so no wonder that it looks that
> way. I just can't stand characters that where only done the way there
> are due to technical limitaions and to easy modeling (why create
> something new, when one can reuse Tux over and over again), nothing
> wrong with doing it that back then, but I see little reason to keep it
> that way.
> 
> > What is the reason that snow is so good and a butterfly Tux is so
> > bad? I can give the reasons why butterfly Tux is good:
> >
> > The butterfly Tux was originally an angel-tux...your guardian angel
> > coming to help you...but then we decided to make it
> > religion-neutral, hence the butterfly - a sign of peace of sorts.
> 
> I don't care much about what it was meant to be, if it looks like
> big-fat Tux with wings, it just has to be dropped.
> 
> >> Some other (not yet used) SuperTux characters:
> >> http://pingus.seul.org/~grumbel/tmp/eviltux.png
> >> http://pingus.seul.org/~grumbel/tmp/yeti2.jpg
> >
> > So your basic view is that any character you designed is good - and
> > anything the original 'consortium' of designers put together is bad?
> 
> No, my work isn't necesarrily good, but since most of the original
> consortium evolves around character reuse with little changes,
> word-plays (Gown), logo-recycling, Microsoft bashing (BSOD) or geek
> stuff, yep, I consider it all rather bad and ugly.
> 
> > Those are OK - I like the evilTux - but the Yeti is a DISASTER
> > because he has fur and doing good fur is a BIG no-no for anything
> > but the VERY latest of hardware...and even then, you have to want it
> > pretty badly to take the performance hit for it.
> 
> It doesn't need to have real 3d-fur, after all its most of the time
> only seen from quite a bit behind. The fur should be fakable without
> too much throuble with some simple texture mapping.
> 
> > The idea of a dinoasur in the abstract is surely a good idea -
> > painting it red and calling it Mozilla doesn't make much difference
> > to much - and some people will doubtless like the reference.
> 
> And some other people would surly hate the reference. I don't mind it
> being a dino, I don't mind it being red, but calling it Mozilla just
> spoils the fun, Mozilla is a browser, not a game character the
> reference just doesn't make 'click', there is just not much that this
> red-dino-game character would have in common with some piece of
> browser software.
> 


Can we have the kde dragon in there to huh?


> 
> 
> --
> WWW:      http://pingus.seul.org/~grumbel/
> JabberID: gr...@ja...
> ICQ:      59461927
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Tuxkart-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxkart-devel
>

Re: [TuxKart-devel] Developer privilages.

[Caleb S. <gam...@gm...>]

On Sun, 27 Jun 2004 16:57:08 -0500, Steve Baker <sjb...@ai...> wrote:
> 
> Ingo Ruhnke wrote:
> > Steve Baker <sjb...@ai...> writes:
> >
> >>Everyone who wants to work on the GoTM TuxKart effort will need
> >>developer access to CVS. Please let me have your sourceforge account
> >>names so
> > 
> > My account name is 'grumbel'
> 

mine is 'gaminggeek'..

> You should have CVS privilages now.
> 
> 
> 
> ---------------------------- Steve Baker -------------------------
> HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
> HomePage : http://www.sjbaker.org
> Projects : http://plib.sf.net    http://tuxaqfh.sf.net
>             http://tuxkart.sf.net http://prettypoly.sf.net
> -----BEGIN GEEK CODE BLOCK-----
> GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
> V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
> -----END GEEK CODE BLOCK-----
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Tuxkart-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxkart-devel
>

Re: [TuxKart-devel] Work to do.

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

pmb wrote:

> Great job for PLIB, as you said it have everithing in it !!!

Thanks - the plan was to do it right - totally portable, libraries for
each major task that a game needs, works all by itself - or combined
with SDL/Qt/GLUT/GTK - pick and choose which sub-libraries you want - or
just use it all.  The only part that's really missing is Physics - I'd love
to do it, but I don't know how to do that myself - and unless someone donates
it, it can't happen.

> I will do the Network part as I don't know much about physics and have 
> never worked with AI.

Well, maybe it's time to learn.

Read the ODE manual - try some of the examples (especially the three
wheeled vehicle demo).

We really need help on one or other of these things and networking
isn't mission-critical.

---------------------------- 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] Work to do.

[pmb <phi...@vi...>]

Steve Baker wrote:

> pmb wrote:
>
>> In the network area, i'm totally lost. However, I can learn about it 
>> and would happilly to that part.
>
>
> Er - sorry - I lost track of who I was talking to!
>
> IMHO, the major programming tasks are:
>
> 1) AI - The karts that are not being driven by the player(s) need to
>    know how to drive around the track without crashing into stuff and
>    to drive agressively enough to be a challenge at the highest level
>    of difficulty - and passively enough to let the player win in the
>    easier levels.  They have to know when to shoot their weapons,
>    how to dodge player-launched weapons, when to go for collectibles
>    and when it's not worth it.
>
> 2) Physics - The behavior of the kart on the track - the input is the
>    mouse/keyboard/joystick stuff - the output is the position of the
>    kart on the track.  Probably, the enemy kart AI should also drive
>    the karts through the same physics - but that's not necessarily true.
>
> 3) Startup sequence - improve the present startup GUI, allow you to 
> select
>    who you want to play as, which track to drive - hopefully with little
>    screen shots - or spinning 3D models.  Select difficulty level, select
>    play mode (single player, two player, single race, multiple-race, 
> etc).
>
> 4) Split-screen mode for two human players on one computer.  (I've 
> already
>    'claimed' this job - I know exactly where to touch the code - I can do
>    it VERY quickly.
>
> 5) Lots of other 'detail' tasks.  Adding particle system effects to the
>    karts for exhaust smoke, tyre smoke and other eye-candy.
>
> ...I'm sure there are lots of others.
>
>> However, the network play have to use some kind of portable library 
>> witch handle network devices.
>
>
> PLIB has that. (PLIB has *everything*!!  PLIB **RULEZ**!!! All hail 
> PLIB.)
>
> Network play (which we don't *NEED* - but would be cool) entails nasty
> issues like extrapolation for missing data packets, making a version
> of the game that can act as 'server' and stripping out the 'client'
> code so it basically does what it's told.
>
> ---------------------------- 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-----
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital 
> self defense, top technical experts, no vendor pitches, unmatched 
> networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Tuxkart-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxkart-devel
>
Great job for PLIB, as you said it have everithing in it !!!
I will do the Network part as I don't know much about physics and have 
never worked with AI.

- pmb

Re: [TuxKart-devel] Work to do.

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

pmb wrote:
> In the network area, i'm totally lost. However, I can learn about it and 
> would happilly to that part.

Er - sorry - I lost track of who I was talking to!

IMHO, the major programming tasks are:

1) AI - The karts that are not being driven by the player(s) need to
    know how to drive around the track without crashing into stuff and
    to drive agressively enough to be a challenge at the highest level
    of difficulty - and passively enough to let the player win in the
    easier levels.  They have to know when to shoot their weapons,
    how to dodge player-launched weapons, when to go for collectibles
    and when it's not worth it.

2) Physics - The behavior of the kart on the track - the input is the
    mouse/keyboard/joystick stuff - the output is the position of the
    kart on the track.  Probably, the enemy kart AI should also drive
    the karts through the same physics - but that's not necessarily true.

3) Startup sequence - improve the present startup GUI, allow you to select
    who you want to play as, which track to drive - hopefully with little
    screen shots - or spinning 3D models.  Select difficulty level, select
    play mode (single player, two player, single race, multiple-race, etc).

4) Split-screen mode for two human players on one computer.  (I've already
    'claimed' this job - I know exactly where to touch the code - I can do
    it VERY quickly.

5) Lots of other 'detail' tasks.  Adding particle system effects to the
    karts for exhaust smoke, tyre smoke and other eye-candy.

...I'm sure there are lots of others.

> However, the network play have to use some kind of portable library 
> witch handle network devices.

PLIB has that. (PLIB has *everything*!!  PLIB **RULEZ**!!! All hail PLIB.)

Network play (which we don't *NEED* - but would be cool) entails nasty
issues like extrapolation for missing data packets, making a version
of the game that can act as 'server' and stripping out the 'client'
code so it basically does what it's told.

---------------------------- 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] Work to do.

[pmb <phi...@vi...>]

In the network area, i'm totally lost. However, I can learn about it and 
would happilly to that part.

However, the network play have to use some kind of portable library 
witch handle network devices. If not, I would have to write parts for 
linux, windows, whatever.

Re: [TuxKart-devel] Work to do.

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

pmb wrote:

> I'm familiar too with C++.
> I was thinking about that, you need some way to recognise the different 
> players on the track, how about some penguins with linux distributions 
> logos, ex: At the config area I chose a Debian logo, and during the 
> game, it would show that logo on the back of my kart. Just my idea though.

I think we've already agreed that using distro-specific stuff isn't a good
idea.

But have you actually played the game yet?   There are already little
pictorial icons to show who is in the lead, etc.

> I also am interested to port the game to differents oses, I have 3 
> solaris cdrom there that I could use.
> Mayby I could also port it to windows. It would be a great idea to put 
> UDP multiplayer in that.

Woah there.  Tuxkart ALREADY runs under Solaris and Windows...and every
other OS (that I'm aware of) that has a functional hardware-accellerated
OpenGL implementation.  There isn't really a need to port it...it's *done*.

In fact, I write all of my games to be portable from day #1.  TuxKart
was running under Windows within hours of the release of v0.0.0.  Norman
Vine (who is still subscribed here) took it - IIRC, he found a couple of
places where I'd done stuff like:

    for ( int i = .... )
      whatever ;
    for ( int i = .... )
      whatever_else ;

...which prompts an error under MSVC.  Anyway, we had a Windows version
running within hours of the Linux version.

If you want to try it, just take a copy of PLIB and TuxKart - unpack them
and either build them with MSVC *or* CygWin (the latter is easier because
the configure and Makefile stuff is standard - but if you can throw together
a project file, you *can* build it with MSVC tools).

Under Solaris, you just need the usual './configure ; make' - I believe
it's all been built and tested with GCC - dunno how things would go with
any kind of native Sun-supplied compiler.

> One question: do I  staticaly include PLIB ? does it come with solaris ????

You have to build PLIB for Solaris - in exactly the same way you do in Linux.

> So what do you think about that ?

Sorry - porting is a non-problem.

However, network play would be a useful thing to have.

---------------------------- 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] A BSOD Kart.

[pmb <phi...@vi...>]

Steve Baker wrote:

> Attached is my son's first effort at a BSOD kart.  It needs lots of 
> work yet and
> would need some animation effort to produce little electrical 
> discharges from
> dangling cables, a spinning power supply fan, rotating wheels 
> (possibly wobbly),
> and flashing LED's where appropriate.
>
> Comments?
>
> ---------------------------- 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-----
>
> ------------------------------------------------------------------------
>
I like it so much.

Re: [TuxKart-devel] Work to do.

[pmb <phi...@vi...>]

Steve Baker wrote:

> pmb wrote:
>
>> Maybe Tcp/Ip multiplayer would be cool. I could do that.
>
>
> We said we'd only add that "if someone comes along who
> passionately wants to do it"...so maybe that just happened!
>
> Do you really think TCP is the right way?
>
> I generally use UDP because it's faster and has MUCH lower
> latency.
>
> In UDP, if you lose a packet, it just ignores the loss - which
> for a racing game is fine because another packet is already
> on it's way.   You just have to be careful about bonuses and
> any permenantly changed track or character elements.
>
> In TCP, packets are acknowledged, error checked and resent
> if missing.  This is OK - but in a game like this, by the time
> a missing data packet has been flagged as missing, re-requested,
> and re-transmitted...another packet reflecting a later point in
> time has already been sent.
>
> ---------------------------- 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-----
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital 
> self defense, top technical experts, no vendor pitches, unmatched 
> networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Tuxkart-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxkart-devel
>
I'm familiar too with C++.
I was thinking about that, you need some way to recognise the different 
players on the track, how about some penguins with linux distributions 
logos, ex: At the config area I chose a Debian logo, and during the 
game, it would show that logo on the back of my kart. Just my idea though.

I also am interested to port the game to differents oses, I have 3 
solaris cdrom there that I could use.
Mayby I could also port it to windows. It would be a great idea to put 
UDP multiplayer in that.

I did some programming under windows, started with C and Folowed to C++. 
Until 3 years I didn't use linux/unix at all, but now I work mostly in 
linux.

I could start by porting the software to solaris, then maybe some other 
platforms (windows ?).
One question: do I  staticaly include PLIB ? does it come with solaris ????

No, I'm not really good with The Gimp. :(

So what do you think about that ?

Re: [TuxKart-devel] Thoughts on Kart Models.

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

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

> Pretty much every game has highly ad-hoc things. MarioKart uses
> Cubes with '?' on them for good things and cubes with an upside-down
> '?' for bad things. The confusion-until-the-last-minute thing is
> absolutely crucial for game play. Ditto with herring colours.

Well, that red is good and green is bad isn't obvious, traffic lights
actually do it reverse. Beside that collecting herring and getting
'random item' is also not intuitive, a ?-box however is (they contain
something, herring don't). So herring should if at all only be used as
coin-like things, bonuses should just be stored in boxes like in
Mario. I would remove the evil-?-blocks completly as standard map
items and make them placeable by other players only.

> I don't see how choosing an ice cube over a computer monitor changes
> how things 'hang together'.

It removes the pointless microsoft bashing element.

> That's a ludicrous position. Change absolutely everything except
> what we can't change? I don't know *ANY* commercial games of the
> 'cute' genre that do that.

Commercial games in general are the successors of good or even great
games, thats something that isn't true for Open Source games, which
are often just half finished, unplayable or worse. And starting from a
half-finished not even really playable game under the premise to keep
most stuff is just not moving you very must away from that
half-finished thing and you will just end up with another incomplete
looking patchwork.

> BSOD is on the very skinnymost end of that curve...I couldn't
> imagine a more subtle dig at one of the most truly evil companys on
> the planet.

BSOD is rather close to having Clippy driving around in a kart, its
just Microsoft-bashing put down into shape, not something I want to
have as a playable character or else we could start with creating
Mr-Kernel-Oops and Mr-XFree-just-locked-up.

> It's just an icon.

Herring is not just an icon, its already closly related to Tux being a
penguin, too closly already in case there are other non-penguin
characters that should also consume that item.

> What does a toadstool need coins for?

Coin is a rather generic item.

> Banana's are not in fact part of the natural diet of a gorilla.

In Donkeykong games its used as coin-like item, in MarioKart it works
only to make other Karts slip.

> Herrings only swim in the Northern Hemisphere but Penguins only live
> south of the equator.
>
> Who cares?  It's an icon.

It either has to be generic enough so that one doesn't care about why
its there (coin) or it has to be close enough related to what its
meant to be (Herring->Penguin eating it). If BSOD starts eating
herring things start looking wrong.

>> SuperTux had a golden herring for invulnurability, got replaced
>> with a 'classic' star.
>
> ...and that helped the game how exactly?

It replaced the 'heck what should this ugly item do' with something
more familiar and better regonizable.

>> In SuperTux we have this little IceBlock as BSOD replacement: *
>> http://pingus.seul.org/~grumbel/tmp/iceblock.gif
>
> Yeah - it's OK - but it's going to look silly in a lava-themed level.

Could get a refrigerator on his back or something to keep him cool.

>> And while, since BSOD is just the most obvious Microsoft bashing, I
>> really would prefer to get rid of it.
> Sorry - I just can't agree with you on this one.
>
> So what's the solution to such impasses? Put both in there is my
> recommendation.

Make it a bonus-character that you have to unlock or whatever.

>> As replacement for the butterfly-Tux we could use this little guy:
>> http://super-tux.sourceforge.net/milestone1/images/flyingsnow.png
>
> Change for change's sake again...why change?

Aehm, because butterfly-Tux is one of the ugliest things ever. It
looks like big fat Tux with some wings stuck on him, well, it *is* big
fat Tux with some wings stuck on him, so no wonder that it looks that
way. I just can't stand characters that where only done the way there
are due to technical limitaions and to easy modeling (why create
something new, when one can reuse Tux over and over again), nothing
wrong with doing it that back then, but I see little reason to keep it
that way.

> What is the reason that snow is so good and a butterfly Tux is so
> bad? I can give the reasons why butterfly Tux is good:
>
> The butterfly Tux was originally an angel-tux...your guardian angel
> coming to help you...but then we decided to make it
> religion-neutral, hence the butterfly - a sign of peace of sorts.

I don't care much about what it was meant to be, if it looks like
big-fat Tux with wings, it just has to be dropped.

>> Some other (not yet used) SuperTux characters:
>> http://pingus.seul.org/~grumbel/tmp/eviltux.png
>> http://pingus.seul.org/~grumbel/tmp/yeti2.jpg
>
> So your basic view is that any character you designed is good - and
> anything the original 'consortium' of designers put together is bad?

No, my work isn't necesarrily good, but since most of the original
consortium evolves around character reuse with little changes,
word-plays (Gown), logo-recycling, Microsoft bashing (BSOD) or geek
stuff, yep, I consider it all rather bad and ugly.

> Those are OK - I like the evilTux - but the Yeti is a DISASTER
> because he has fur and doing good fur is a BIG no-no for anything
> but the VERY latest of hardware...and even then, you have to want it
> pretty badly to take the performance hit for it.

It doesn't need to have real 3d-fur, after all its most of the time
only seen from quite a bit behind. The fur should be fakable without
too much throuble with some simple texture mapping.

> The idea of a dinoasur in the abstract is surely a good idea -
> painting it red and calling it Mozilla doesn't make much difference
> to much - and some people will doubtless like the reference.

And some other people would surly hate the reference. I don't mind it
being a dino, I don't mind it being red, but calling it Mozilla just
spoils the fun, Mozilla is a browser, not a game character the
reference just doesn't make 'click', there is just not much that this
red-dino-game character would have in common with some piece of
browser software.

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

Re: [TuxKart-devel] Getting Started.

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

Ryan Flegel wrote:

> Maybe some of these effects (that are in the comments) should be
> stored into separate config files, instead of loading a model straight
> up, load the config file which will include these comments, plus the
> path to the model.

Actually, some of them are.  The '.loc' file does some of that.  The
problem is that some effects need to be attached to a specific node
in the database tree for the 3D model.  If you have something like
a volcano model with lava running down the sides, you want moving
texturemaps on the lava polygons but not on the rocky mountainside.

It's hard to locate those specific nodes from an external config
file - so you tend to need to use some kind of ASCII string attached
to the node to identify it.  Well, if you can do *that* then you
might as well put the config data right into that ASCII string in
the model file.

This is a much easier way to work - and somewhat guarantees that when
you rearrange the model's heirarchy for some reason, that the config
data stays attached to the correct parts.

The '.loc' file tends to have things of a more 'global' scope that
affect the whole model file.

> Also, since AC3D seems to be missing some useful features, is there
> any other format blender can export to that might suit our needs a lot
> better?

That would be a useful experiment to try.

The PLIB library (which is what is actually doing the file loading) supports
about 20 different file formats.  Some of these are well supported (AC3D
is a good one - because I maintain it!) - others are flakey because someone
implemented just enough of the format to get some job done - and then
contributed a half-baked solution.

All format are ALWAYS missing some teeny-tiny detail though.  Doing
utterly generic and *complete* 3D loaders is extremely difficult.

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