Re: [tuxracer-devel] Course precisions

[Jasmin P. <jf...@mu...>]

On Sat, 15 Apr 2000, Steve Baker wrote:

> Jasmin Patry wrote:
> > 
> > [Sorry for the delay in responding, I've had to devote 100% of my time
> > over the last few days to finishing a term project...]
> 
> Tsk, tsk, tsk - get your priorities right!!  :-)

:-) 

> > There's a first cut at a damage system in 0.12, but you won't see the
> > health display unless you include "health" in the debug variable in
> > ~/.tuxracer.  It still needs work.  Paddling saps Tux's health, he takes
> > damage when he hits a tree, and damage is also incurred based on the
> > magnitude of the force exerted on him by the terrain.
> 
> In my first cut of my Tux game, I had the concept of "strength" or
> "energy" and the concept of "health" or "damage" rolled into a single
> variable.
[snip excellent explanation]
> So, in short, I think it would be A Bad Thing for paddling to damage
> Tux.  You would get to a point where you'd slipped into a hollow and
> needed to paddle to get out - but had so much damage that you couldn't
> afford to paddle.

Yeah, I can buy this.

> I think you need to do what I did and split 'energy' (which gets drained
> by frantic paddling - and which recharges either gradually over time -
> or suddenly if you eat a really common silver herring)...and 'damage'
> (which gets drained by hitting trees and such - and which cannot be
> recharged over time - although there might also be a bonus thing that'll
> repair damage).
> 
> This seems rather like real life.  If you get tired from running, you
> can stop and rest - or drink a Gatorade (or so the manufacturers would
> have you believe).  If you cut yourself, it takes a week to heal.

Ok, you've convinced me (thanks for the great explanation).  So there
will be an 'energy' meter and a 'damage' (or 'health') meter.  Damage
will be caused by banging into terrain, hitting trees, etc. and energy
will be drained by paddling (and regenerate slowly).  

> > Well, paddling at the start of a race gives you a nice speed boost.  But
> > I like the idea that paddling saps your health.  Comments?
> 
> Energy - not Health.

Right.

> Dunno - I'd suggest that once Tux reaches a speed higher than his
> flippers can move, paddling would slow him down rather than speeding
> him up - which happens to be a useful thing from a game play
> perspective.  

Yup, that's how it works now. (The magnitude of the force exterted on
Tux when paddling is proportional to (MAX_PADDLING_SPEED - speed), so
at speeds above MAX_PADDLING_SPEED, paddling slows Tux down.

> Also, having paddling slow you down when sliding fast will be a
> useful thing.  Not good for your time - but maybe needed by poor
> players who are trying to reach a bonus item or avoid a tree.

Sure.

> That may mean that you don't need a penalty for paddling.  This
> seems more natural to me.

No penalty at all, not even energy?  That would elminate the need for
energy altogether... which would simplify things, I guess.  We could
think up of other uses for energy -- perhaps paddling has a greater
effect when Tux's energy is above a certain level, etc.  I dunno.
Comments?

> > > For example, I have 'spinning herrings' in different colours
> > > (Silver for a points bonus, Gold for a major prize, Red for
> > > a random-ish special effect, Green for bad things you'd want
> > > to avoid.  I use small spinning Tux icons for 'extra lives')
> > 
> > I like the idea of herring for health (I would use silver for small
> > health boost, gold for big health boost)...
> 
> Yep.  Perfect.  I also use little spinning Tux icons for extra 'lives'.
> 
> Presumably, once you have health - and a need to score certain points
> to get onto the next level, you need to decide what to do when Tux
> 'dies'.   Typically, this will simply force you to retry that course -
> but if you choose to have a finite number of 'lives' - then if you run
> out of lives then you also lose all your current points and have to
> start the whole game over from scratch.
> 
> That's a pretty serious thing to happen - and in Tux_AQFH, I provide
> plenty of free-life tokens to ensure that any player who is paying
> attention will never run out of lives...but it does add another thing
> that you have to collect and not run out of - which adds some more
> richness to the game experience.

One racing game I know of works like this (f-zero x for the N64): races
are divided into groups ("cups") of ~5.  Initially, only one group is
unlocked; to unlock the next one you have to "beat" the previous group
(by finishing first overall in a circuit of all the races in the group).
You are given a certain set of lives to do this in (when you die during
a race you must restart that race).  If you run out of lives during a
circuit you have to start it over again from the beginning (but you
*don't* have to start the whole game from the beginning).  Once you
unlock everything you get to do it again at the next level of difficulty
(tougher opponents).

This actually works pretty well, and makes the game fun to play (even
though the graphics are *terrible*).  Extending this to Tux Racer
(even without computer opponents) wouldn't be too hard -- instead of
finishing first overall, you have to get a total score of X (or beat a
total time of Y, etc.)  However, having computer opponents makes it a
lot more fun, since you know who you're trying to beat in the standings.
Someday Tux Racer will have Gown and Beasdie and others to race
against...

Another option is to do what many car racing games do when your car
blows up -- you reanimate somewhere close to where you died, but that
process takes a few valuable seconds.  This would be much easier to
implement (though the game would have to know where the 'safe'
reanimation spots are on the course -- reanimating where you died
wouldn't work well if you died in a deep pit that was impossible to
paddle out of).

> The thing I *don't* like about that is that the graphic chevron implies
> a direction.  In games like DiddyKong Racing (also N64), hitting a
> chevron from one side not only boosts your speed - but also sends
> you off in the direction that the chevron is pointing...Newtonian
> Mechanics not withstanding.
>
> I don't like that behaviour - and probably won't reproduce it in
> TuxKart.

Yeah, I would implement it as a force field pointing in the direction of
the chevron, so that it will tend to push you in the direction of
the chevron, but not in a way that violates physical laws.

> I'd use a floating number (so you can see how many points it's worth
> and you can decide whether it's worth blowing 10 seconds of time to
> collect a measly 10 point bonus)...an alternative would be to use
> coins of various colours - bonus points are kindof analogous to money
> I suppose.

Numbers are a good idea.  Coins would be very mario-kartish.

> Anyway, you should probably download Tux_AQFH if you havn't already - then
> you can steal my transporter and herring textures if you so desire.

Ok, thanks (I downloaded it long ago).

Cheers,
Jasmin

-- 
Jasmin Patry               Master's Student, Dept. of Computer Science
jf...@cg...         http://www.cgl.uwaterloo.ca/~jfpatry/