tuxracer-devel Mailing List for Tux Racer (Page 2)
Status: Beta
Brought to you by:
jfpatry
Menu
▾
▴
tuxracer-devel — Mailing list for Tux Racer developers
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
(7) |
Mar
(90) |
Apr
(39) |
May
(9) |
Jun
(2) |
Jul
(3) |
Aug
(10) |
Sep
|
Oct
(8) |
Nov
(2) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Steve B. <sjb...@ai...> - 2000-06-11 22:04:09
|
Steve Kirkendall wrote: > > A year or so ago, I was working on a simple racing game for Linux systems > without 3D acceleration. I got busy with paying projects at about the > point where my game was becoming playable. The sound support is fairly > complete though. I'd like to offer it to this project. > > The sound server is a separate program named "unixsnd", and it reads sound > requests from stdin. The typical interface style is very simple: When the CPU is *really* busy running the graphics and other parts of the game, how do you guarantee that your sound server will not get delayed in execution to the point where the sound breaks up? I've found that I need to keep the sound in the same thread as everything else (at least on single CPU machines) in order to be able control when it gets called. The alternative seems to be to crank the priority of the sound task up above the graphics - but to do that you have to run as root - or reduce the priority of the graphics...neither seems a very attractive option. -- Steve Baker http://web2.airmail.net/sjbaker1 sjb...@ai... (home) http://www.woodsoup.org/~sbaker sj...@ht... (work) |
|
From: Steve K. <ski...@us...> - 2000-06-11 21:54:49
|
A year or so ago, I was working on a simple racing game for Linux systems
without 3D acceleration. I got busy with paying projects at about the
point where my game was becoming playable. The sound support is fairly
complete though. I'd like to offer it to this project.
The sound server is a separate program named "unixsnd", and it reads sound
requests from stdin. The typical interface style is very simple:
During initialization:
soundfp = popen("unixsnd", "w");
To play a sound:
fprintf(soundfp, "%s volume=%d\n", soundname, volume);
fflush(soundfp);
During termination:
pclose(soundfp);
Here are a some of the more important features:
* It can play *.wav and *.au sounds equally well.
* Left & right volume can be controlled independently, for stereo positioning.
* Each sound's playback rate can be adjusted independently. This allows you
to implement both doppler-shifting and speed-dependent engine sounds (or
rumble/whoosh sounds if your penguin has no engine).
* Multiple sounds can be played simultaneously, each with its own volume
settings and playback speed. The sounds are mixed. If necessary, unixsnd
will clip the mixed signal to prevent overflow; it does this in a way that
minimizes "fuzz" effects.
* An overall reverb effect can be employed, which gives a nice sense of
presense when you're traveling through a tunnel.
* Sounds can be looped endlessly. You assign each looped sound a unique
name; later, you can use that name to adjust the looped sound, or stop it.
I looped engine sounds and environmental sounds such as rain.
* Macros and script files are supported. They provide an easy way to make
the sounds be configurable -- During initialization you invoke a unixsnd
script which defines a macro for each possible event. Later, whenever
that event occurs, you invoke the macro.
* You can give a list of sounds, and let unixsnd choose one at random.
For example, you could define macro such as "impact:ouch|oof|thump|crash"
and then every time you invoked the "$impact" macro, unixsnd would play
the "ouch.wav", "oof.wav", "thump.wav", or "crash.wav" sound.
The two most distinctive features are looped sounds, and the ability to
adjust the playback speed. Both are critical to a racing game.
Currently, it just writes sound data to /dev/dsp. I have also written,
but not tested, a module for Solaris that writes to /dev/audio. I wish
I could say it supports ESD, but it doesn't.
I don't really have time to devote to this. If I had that much spare time,
I'd be working on my own game. Also, I've never run tuxracer because I
don't have a 3dfx card. Someday soon though...
If you're interested, please write to me at <kir...@cs...>. I'm
not a subscriber to this mailing list.
|
|
From: Jasmin P. <jf...@mu...> - 2000-05-29 17:15:38
|
On Sun, May 28, 2000 at 04:25:13PM +0100, Peter Allen wrote: > I am not sure on the physics yet (I've only done first year 'A' level > physics so far...) (Please comment and say thats not going to work etc) > 1. Tux could stick a leg hard into the snow, and use it a as a pivot. > For practical reasons I think the pivot would need to be a lot further > out that tux's leg, so this wouldn't look 100% realistic. The physics > of this are fine, but I was planning on making it so the pivot could > only take a certain force, so if tux was going faster than that > the pivot would slip, and tux would lose velocity (due to friction). > I can't quite work out the physics of this, despite my best efforts > with the ascii art. It's not easy to do this "correctly" because of the model that's being used. For physics purposes, Tux is modelled as a single particle. This means that torsion on Tux can't be modelled, since the particle is infinitesimally small. A better model would take into account the fact that when Tux's left arm (or foot) is sticking into the ground, the drag on his left side is greater than on his right side; as a result he would turn in that direction. As I see it, there are a couple of options. You could just copy and modify the current turning code so that the magnitude of the frictional force was increased when doing a sharp turn; this probably won't do exactly what you want, but with sufficient tweaking it might come close. The other would be to forgot about implementing this with forces and manually manipulate Tux's velocity and/or position (instead of having it automatically updated by the ODE solver). There might be some gotchas there, though -- I haven't looked at that code in a while so I'm not sure what problems might crop up. (There is also a third option -- implement a better physical model that takes into account angular momentum, etc. -- but that's probably more work than you had in mind. :) Hope this helps, Jasmin -- Jasmin Patry Master's Student, Dept. of Computer Science jf...@cg... http://www.cgl.uwaterloo.ca/~jfpatry/ |
|
From: Peter A. <P....@bi...> - 2000-05-28 15:27:26
|
Jasmin Patry wrote: <snip> > > ^ velocity > | > | > + Tux > / > / > L frictional force > > The magnitude of the frictional force is also increased to reflect the > fact that drag is increased when Tux puts his hand down (so turning does > slow him down, a little bit). Thats neat.... > For sharp turns, you have a few options. You can play with > calc_net_force and change how the steering part works when a sharp turn > is being performed, I am not sure on the physics yet (I've only done first year 'A' level physics so far...) (Please comment and say thats not going to work etc) 1. Tux could stick a leg hard into the snow, and use it a as a pivot. For practical reasons I think the pivot would need to be a lot further out that tux's leg, so this wouldn't look 100% realistic. The physics of this are fine, but I was planning on making it so the pivot could only take a certain force, so if tux was going faster than that the pivot would slip, and tux would lose velocity (due to friction). I can't quite work out the physics of this, despite my best efforts with the ascii art. <snip> The keyboard stuff seems niceley set out so it shouldn't present any difficulties. Thanks for the explanation. Peter Allen |
|
From: Steve B. <sjb...@ai...> - 2000-05-18 20:30:00
|
Jules Bean wrote: > > > Btw, earlier this week I received a copy of "Linux Magazine" from Japan, > > which features a piece on Tux Racer (as part of a Linux game survey). > > I can't read Japanese, but the screenshots looked nice! :) > > Cool. Kudos for all the exposure you're getting! I wouldn't get too excited. That magazine appear to have fired off near-identical queries to just about every Linux game developer. I even got one as developer of TuxKart - which so far is nothing but an empty web site as far as released code goes! It looks like the guy just fired them off to everyone on SourceForge with 'game' in their project description. Still, any publicity is good publicity! -- Steve Baker http://web2.airmail.net/sjbaker1 sjb...@ai... (home) http://www.woodsoup.org/~sbaker sj...@ht... (work) |
|
From: Jules B. <jm...@he...> - 2000-05-18 15:00:55
|
On Thu, May 18, 2000 at 09:21:25AM -0400, Jasmin Patry wrote:
>
> I was also going to post to the list to point out that Satoshi isn't
> subscribed to the list (so he didn't get your message); I approved his
> message because it was important and I didn't want to risk losing it.
It did occur to me that he mightn't be subscribed. If I was really
bright, I might have deduced the whole sequence of events.
>
> > tuxracer is under the GNU General Public License. This means that you
> > are absolutely welcome to put it on your CD (encouraged, even!),
> > however, you should also include the source code, which is either the
> > tuxracer-0.12.1.tar.gz or the tuxracer-0.12.1-1.src.rpm.
>
> I told him that it would be nice to include the source. However, he
> isn't obligated to do so, as long as users are told where to get the
> source (and it could be argued that the README includes that
> information).
True enough. I did only say 'should'.
>
> Btw, earlier this week I received a copy of "Linux Magazine" from Japan,
> which features a piece on Tux Racer (as part of a Linux game survey).
> I can't read Japanese, but the screenshots looked nice! :)
Cool. Kudos for all the exposure you're getting!
--
Jules Bean | Any sufficiently advanced
jules@{debian.org,jellybean.co.uk} | technology is indistinguishable
jm...@he... | from a perl script
|
|
From: Jasmin P. <jf...@mu...> - 2000-05-18 13:22:35
|
On Thu, May 18, 2000 at 01:51:34PM +0100, Jules Bean wrote:
> Hi there! I'm not an official tuxracer developer, but in case they
> are busy, I believe I can answer some of your questions.
Thanks Jules. I've already replied in private email (I included my
mailing address which I didn't want in the archives) -- of course, I
told him that he was free to include Tux Racer on the CD.
I was also going to post to the list to point out that Satoshi isn't
subscribed to the list (so he didn't get your message); I approved his
message because it was important and I didn't want to risk losing it.
> tuxracer is under the GNU General Public License. This means that you
> are absolutely welcome to put it on your CD (encouraged, even!),
> however, you should also include the source code, which is either the
> tuxracer-0.12.1.tar.gz or the tuxracer-0.12.1-1.src.rpm.
I told him that it would be nice to include the source. However, he
isn't obligated to do so, as long as users are told where to get the
source (and it could be argued that the README includes that
information).
> You don't seem to have listed the tuxracer-data file above! This is
> rather important, since without it your readers won't have the levels
> to play! tuxracer-data-0.12.1-1.noarch.rpm is also available from the
> website.
Yup, I pointed that out too.
Btw, earlier this week I received a copy of "Linux Magazine" from Japan,
which features a piece on Tux Racer (as part of a Linux game survey).
I can't read Japanese, but the screenshots looked nice! :)
Here's a link for anyone that's interested (and can read Japanese :) :
http://www.linux24.com/linux/linuxmag/
(I wasn't able to track down an on-line version of the article.)
Cheers,
Jasmin
--
Jasmin Patry Master's Student, Dept. of Computer Science
jf...@cg... http://www.cgl.uwaterloo.ca/~jfpatry/
|
|
From: Jules B. <jm...@he...> - 2000-05-18 12:52:50
|
On Thu, May 18, 2000 at 02:25:01PM +0900, Satoshi Turuo wrote:
> Hi,
>
Hi there! I'm not an official tuxracer developer, but in case they
are busy, I believe I can answer some of your questions.
> Right now, we are working on a particular project
> with which we would like to ask you for your cooperation.
> The title of this project is;
> "The COOL Softwares for Linux".
>
> We would like your permissions to accomodate the given
> materials to the CD-ROM of our magazine.
> (Linux client and server files for Tuxracer and plug-ins.
> [tuxracer-0.12.1-1.i386.rpm, tuxracer-create-level.scm
> tuxracer-save-as-rgbs-1.0.scm, tuxracer-load-level-1.1.scm
> tuxracer-save-as-rgbs-1.1.scm])
tuxracer is under the GNU General Public License. This means that you
are absolutely welcome to put it on your CD (encouraged, even!),
however, you should also include the source code, which is either the
tuxracer-0.12.1.tar.gz or the tuxracer-0.12.1-1.src.rpm.
You don't seem to have listed the tuxracer-data file above! This is
rather important, since without it your readers won't have the levels
to play! tuxracer-data-0.12.1-1.noarch.rpm is also available from the
website.
The .scm files are GIMP scripts, copyrighted by Ingo Ruhnke, but they
are also under the GPL, and since they are their own source
files, there are no other requirements there.
I wish you luck with your article!
Jules Bean
--
Jules Bean | Any sufficiently advanced
jules@{debian.org,jellybean.co.uk} | technology is indistinguishable
jm...@he... | from a perl script
|
|
From: Satoshi T. <sat...@as...> - 2000-05-18 05:25:24
|
Hi, My name is Satoshi Turuo, and I'm an editor of Linux information magazine, called "TECH Linux", ASCII Corp in Japan. "TECH Linux" is Linux Magazine for Japanese LINUX Gamers, Newbie LINUX Game Programmers. Newest issue comes with 2 CD-ROMs that loaded with Playabledemos, FreeSoftwares, Sharewares, product advertisements. Right now, we are working on a particular project with which we would like to ask you for your cooperation. The title of this project is; "The COOL Softwares for Linux". We would like your permissions to accomodate the given materials to the CD-ROM of our magazine. (Linux client and server files for Tuxracer and plug-ins. [tuxracer-0.12.1-1.i386.rpm, tuxracer-create-level.scm tuxracer-save-as-rgbs-1.0.scm, tuxracer-load-level-1.1.scm tuxracer-save-as-rgbs-1.1.scm]) If you are interested in the project, please contact me as soon as possible. Actually, deadline of this project is staring us in the face, so I am desperately waiting for you to give the answer back. Thank you very much. If you have any question about TECH Linux or if you send your reply, please contact : Satoshi Turuo sat...@as... TECH Linux ASCII CORPORATION. TOKYO, JAPAN. |
|
From: Jasmin P. <jf...@mu...> - 2000-05-06 17:22:32
|
On Tue, May 02, 2000 at 02:05:14PM -0400, Joseph Toscano wrote: > Allo. The tunes will keep rolling in, of course. ;) Here are two I came > up with recently. > > http://www.zeal-music.com/tuxracer-music.tar.gz -- (that's the entire > archive of tunes, 355k) > > tuxrce-4.it is an in-game song, and tuxrce-5.it is to be played when you > win/finish the race. Very cool! Thanks a lot. > Also, if any "specific" music is needed, do tell. Even if you'd prefer a > certain style of music, I'd be willing to integrate it into my upcoming > tunes. And by "specific" I mean, do you need more tunes for winning the > race/losing the race, etc? Just let me know. Hmm, perhaps it would be nice to have a song to play when you "lose" a race -- i.e., don't get a good enough time/score to go to the next race. That's all I can think of for now, though. Cheers, Jasmin -- Jasmin Patry Master's Student, Dept. of Computer Science jf...@cg... http://www.cgl.uwaterloo.ca/~jfpatry/ |
|
From: Joseph T. <sc...@pc...> - 2000-05-02 18:14:35
|
Allo. The tunes will keep rolling in, of course. ;) Here are two I came up with recently. http://www.zeal-music.com/tuxracer-music.tar.gz -- (that's the entire archive of tunes, 355k) tuxrce-4.it is an in-game song, and tuxrce-5.it is to be played when you win/finish the race. Also, if any "specific" music is needed, do tell. Even if you'd prefer a certain style of music, I'd be willing to integrate it into my upcoming tunes. And by "specific" I mean, do you need more tunes for winning the race/losing the race, etc? Just let me know. --JT (www.lionking.org/~scarjt) . . . . . . . . . . . . . . you and me, we're in this together now none of them can stop us now we will make it through somehow you and me; if the world should break in two until the very end of me. . . until the very end of you. |
|
From: Jules B. <jm...@he...> - 2000-04-23 18:53:50
|
On Wed, 19 Apr 2000, Jasmin Patry wrote: > On Wed, 19 Apr 2000, Steve Baker wrote: > > > Yep - exactly. Wave Racer (another N64 game - with JetSki's this time) > > also opens up secret short-cuts when you play against the more serious > > opponents...that's nice. > > Right... potentially we could do this with teleporters. Actually, I > think each course should be designed at three levels of difficulty > (easy, medium, hard) -- the terrain/trees (or perhaps just the terrain) > would be the same but the placement of herring, lives, teleporters would > change (more power-ups at easier difficulty). > I think definitely different tree-maps on the harder levels. It's easy to imagine a course which on 'Easy' can be done in a smooth S-bend in 25 seconds, but on 'Hard' there's a clump of trees *exactly* where you naturally want to go. Jules /----------------+-------------------------------+---------------------\ | Jelibean aka | ju...@je... | 6 Evelyn Rd | | Jules aka | ju...@de... | Richmond, Surrey | | Julian Bean | jm...@he... | TW9 2TF *UK* | +----------------+-------------------------------+---------------------+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \----------------------------------------------------------------------/ |
|
From: Steve B. <sjb...@ai...> - 2000-04-20 03:27:28
|
Jasmin Patry wrote: > > On Wed, 19 Apr 2000, Steve Baker wrote: > > > Jasmin Patry wrote: > > > > > I was thinking of doing a Tomb Raider-style camera update, using > > > quaternions, but your idea would also work. > > > > I've never played Tomb Raider. What does it do? > > The camera basically follows behind Lara (the main character), except > that when she turns, the camera smoothly "orbits" around her until it's > behind her again. Yep - that's exactly what happens in TuxKart. All you need to do is to store up the coordinates of the player in a 30 element (or so) FIFO - taking the coordinate that's 30 frames old and using that as the place to point the camera. When you are driving in a straight line, the camera is exactly behind Tux. When he turns right, you see him head towards the right hand edge of the screen and see him rotate - but only for a half second or so before the camera starts to turn too. So long as Tux turns, so he stays on the right side of the screen. Another thing I liked (but hadn't *planned* to happen) is that when you hit the accellerator button, Tux shoots away from the camera so you see him speed up - then a moment later the camera does the same thing. It gives you a much better feeling of speed. Also, when Tux is driving fast, the camera hangs back further than when he's going slowly and carefully. For something that was just experimental, it worked out really nicely. > I assume they use spherical linear interpolation of > the quaternions, and a formula similar to this: > > new_orientation = slerp( alpha, old_orientation, final_orientation ) > > where alpha is some constant between 0 and 1 (larger values result in > faster camera movements). > > I was thinking of doing this in camera mode two (where the camera is > behind Tux and looks in the direction he's moving). Yes - I think it would help. Sudden jerky camera moves are always rather unpleasant. > As an aside, I already use quaternions to smooth out Tux's orientation, > using that exact formula above -- it makes a *big* improvement. Yep. > > > I'm pretty sure that there are coins in MarioKart too -- you lose them > > > when you bang into other people, and you "die" (run out of gas?) when > > > you run out, I think. It's been a long time since I've played, though. > > > > Oliver (my son) says "No Way!" - and he's an expert. :-) > > Well, perhaps I'm hallucinating. But to be sure I'll pull out the old > SNES when I go visit my parents this weekend. :) Oh...that explains it! You are talking about the SNES version - that could very well be different from the N64 game - which is what we have. As for 'health'...oh...Oliver wants to type... O> Mario-cart has health in the battle game but not in the race. O> In the battle you both have 3 balloons tied on to your O> car and every time you crash or get hit by a missile or run into O> a bomb one of your baloons floats away. O> If you lose them all, you lose the battle. (Me again) Yep - I forgot - it has race levels AND a 'battle mode' where you just drive around shooting stuff at each other. I don't think that translates over to a downhill snowboarding kind of a game. -- Steve Baker http://web2.airmail.net/sjbaker1 sjb...@ai... (home) http://www.woodsoup.org/~sbaker sj...@ht... (work) |
|
From: Jasmin P. <jf...@mu...> - 2000-04-20 01:16:34
|
On Wed, 19 Apr 2000, Steve Baker wrote: > Jasmin Patry wrote: > > > I was thinking of doing a Tomb Raider-style camera update, using > > quaternions, but your idea would also work. > > I've never played Tomb Raider. What does it do? The camera basically follows behind Lara (the main character), except that when she turns, the camera smoothly "orbits" around her until it's behind her again. I assume they use spherical linear interpolation of the quaternions, and a formula similar to this: new_orientation = slerp( alpha, old_orientation, final_orientation ) where alpha is some constant between 0 and 1 (larger values result in faster camera movements). I was thinking of doing this in camera mode two (where the camera is behind Tux and looks in the direction he's moving). As an aside, I already use quaternions to smooth out Tux's orientation, using that exact formula above -- it makes a *big* improvement. > > I'm pretty sure that there are coins in MarioKart too -- you lose them > > when you bang into other people, and you "die" (run out of gas?) when > > you run out, I think. It's been a long time since I've played, though. > > Oliver (my son) says "No Way!" - and he's an expert. :-) Well, perhaps I'm hallucinating. But to be sure I'll pull out the old SNES when I go visit my parents this weekend. :) Cheers, Jasmin -- Jasmin Patry Master's Student, Dept. of Computer Science jf...@cg... http://www.cgl.uwaterloo.ca/~jfpatry/ |
|
From: Steve B. <sjb...@ai...> - 2000-04-20 00:48:02
|
Jasmin Patry wrote: > > TuxKart is *running* now BTW. You can drive the kart round and round > > a wiggly track that looks a lot like the 'urban' track in MarioKart. > > The brakes work - steering is good, etc *AND* it works over the network! > > Cool!! When do we get to see? Well, I don't like to commit to deadlines with stuff I do for free - "when I feel like it" is about the best I can do!...I'd like to: * Fixup the collision detection. * Have something like the little guy on the cloud in MarioKart that comes and rescues you when you go too far off the track (that solves a LOT of level design issue BTW - no need to worry about Tux falling off the edge of the model anymore!) * Add basic Speedups and collectables. * Lap timer and counter. > I was thinking of doing a Tomb Raider-style camera update, using > quaternions, but your idea would also work. I've never played Tomb Raider. What does it do? > > MarioKart doesn't have "points" - and no coins either. It uses spinning > > cubes for 'bonus' items like speedups, koopah shells that you can > > shoot and bananas for your opponents to slip on. > > I'm pretty sure that there are coins in MarioKart too -- you lose them > when you bang into other people, and you "die" (run out of gas?) when > you run out, I think. It's been a long time since I've played, though. Oliver (my son) says "No Way!" - and he's an expert. :-) ...but there are *SO* many racing games out there - you can be sure that there is at least one example of anything you could come up with! -- Steve Baker http://web2.airmail.net/sjbaker1 sjb...@ai... (home) http://www.woodsoup.org/~sbaker sj...@ht... (work) |
|
From: Jasmin P. <jf...@mu...> - 2000-04-19 18:59:01
|
On Wed, 19 Apr 2000, Steve Baker wrote:
> Jasmin Patry wrote:
>
> > > 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?
>
> I don't think I have strong opinions either way.
>
> Since paddling at high speed doesn't enable you to "cheat", you
> already need to be careful how and when you use it. Adding an
> additional limitation seems rather harsh. You are hurtling towards
> a tree - and you find yourself too tired to paddle and slow down?
That's what the brakes are for :) (space bar by default).
> You are stuck in a hollow and you have to wait around until you
> recharge enough energy to get out? Nah - that's no fun.
>
> I guess I come down marginally on the "don't bother with energy"
> side of the fence...but if there was ever a good reason to use
> energy for something else, I think I might come down on the other
> side.
I tend to agree. It wouldn't be hard to add later if we need it (course
modifications shouldn't be needed unless we decide we need energy
power-ups, which we won't if we make energy recharge quickly enough).
> <...lives...>
>
> > 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).
>
> Yes - I think a few do that - MarioKart certainly does it.
>
> > 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).
>
> Yep - exactly. Wave Racer (another N64 game - with JetSki's this time)
> also opens up secret short-cuts when you play against the more serious
> opponents...that's nice.
Right... potentially we could do this with teleporters. Actually, I
think each course should be designed at three levels of difficulty
(easy, medium, hard) -- the terrain/trees (or perhaps just the terrain)
would be the same but the placement of herring, lives, teleporters would
change (more power-ups at easier difficulty).
> > 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.
>
> Yep. Computer opponents are going to be "interesting" to program!
The easy way (I think) would be to have the course designers specify
"good" paths through the course. The AI would then try to follow the
closest path. This way if one player bumps another off course, they can
resume on another path, and with some care mutliple computer opponents
would select different paths to take instead of all taking the exact
same route.
> > Someday Tux Racer will have Gown and Beasdie and others to race
> > against...
>
> Yep - although the Daemon is going to need some kind of a snow-board
> or something. He doesn't look like a snow-loving kind of a guy.
>
> We have some other characters to play with too - Susie, the SuSE
> Camelion and Wilbur the GIMP come to mind also. Unfortunately,
> nobody has ever painted a body for Wilbur - so some imagination
> is called for.
Yes, Beasdie definitely belongs on a snowboard; maybe Wilbur could go on
skiis. I'm not sure about Susie... a toboggan?
> > 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).
>
> Well, I firmly believe that there shouldn't EVER be pits that you can't
> paddle out of eventually. That's really contrary to good game design
> criteria...but the issue of where to reset to is an interesting one.
>
> One option is to remember the position of Tux every second or so
> into a big array somewhere. When you crash, you get backed up
> (say) 5 seconds the first time, 10 seconds the next and so on.
> Ultimately, you'll be backed far enough up the course to let
> you go a different direction and escape.
Yes, that could work.
> Personally, I think 'death' should restart the race from the top.
> It's not as though the player will lose an hour of gaming - races
> can only last a couple of minutes at most.
Yes, I agree; as you can see in my reply to Lee Anderson, that's the
tenative plan I've decided on.
> > > 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.
>
> Right. The one in DiddyKong racing *definitely* violates physical laws!
>
> I guess another way would be to have the effect of the speedup diminish
> greatly if you don't hit it straight on. That would work pretty nicely
> I think.
Yes, I like that idea.
> Hmmm - I think that's what TuxKart will do. If you enter the chevron
> within about +/- 30 degrees of the centerline, you'll get 100% of the
> speedup - but as you get further off-center, the effect will reduce
> more and more until if you cross it at 90 degrees to the centerline,
> it'll have no effect at all.
>
> TuxKart is *running* now BTW. You can drive the kart round and round
> a wiggly track that looks a lot like the 'urban' track in MarioKart.
> The brakes work - steering is good, etc *AND* it works over the network!
Cool!! When do we get to see?
> One thing I've been playing with is camera control. I didn't like the
> way that the camera followed Tux such that he stayed more or less glued
> to the center of the screen - with us only seeing a strictly rear view.
> I found that if I record the last 1/2 second or so of motion into a
> circular buffer and always have the camera use a 1/2 second out-of-date
> position for the place to look at, you get a much more exciting view
> of things because as Tux turns, you get a brief side-view until the
> camera 'catches up'. It also makes jumps and falls much more 'dynamic'.
>
> I think Tux-Racer would benefit from that also.
I was thinking of doing a Tomb Raider-style camera update, using
quaternions, but your idea would also work.
> > > 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.
>
> You are thinking of Mario64 not MarioKart I suspect.
>
> MarioKart doesn't have "points" - and no coins either. It uses spinning
> cubes for 'bonus' items like speedups, koopah shells that you can
> shoot and bananas for your opponents to slip on.
I'm pretty sure that there are coins in MarioKart too -- you lose them
when you bang into other people, and you "die" (run out of gas?) when
you run out, I think. It's been a long time since I've played, though.
> I was playing a few if the racing games my son has for N64 and PlayStation,
> (erm - "research" - honest!) One thing I saw that I REALLY liked was in the
> StarWars Episode 1 pod racing game. There is a button you can push as you
> come close to an opponent that makes your character swear and hurl insults
> at the other player...it doesn't *DO* anything from a game perspective
> - but it's a LOT of fun :-)
>
> All of the characters swear in their own languages - so the only one
> you can understand is Aniken and what he shouts is pretty tame.
And lame, IIRC. :)
Cheers,
Jasmin
--
Jasmin Patry Master's Student, Dept. of Computer Science
jf...@cg... http://www.cgl.uwaterloo.ca/~jfpatry/
|
|
From: Jasmin P. <jf...@mu...> - 2000-04-19 17:30:11
|
On Wed, 19 Apr 2000, Lee Anderson wrote: > Hi Jasmin Hi! > I'd like to introduce myself first off. My name is Lee Anderson, and I > write articles, in particular gaming articles, for LinuxWorld. I have > happened to take an interest in Tux Racer, and will be doing a review of > the game due for publication in June. The story proposal has already > been accepted by LinuxWorld and had a deadline on the 5th of May, but > was pushed back due to a backlog of work on their end. That's great -- thanks for deciding to write an article about Tux Racer! > Anyway, enough of the formalities. I will begin writing my article this > week, but would like to ask a few questions that will hopefully help me > with the direction of you project. > > First off, what was the inspiration for creating Tux Racer? I realize > that it was a project for a graphics course you took, but is there any > particular reason for using Linux and the Linux mascot in your game? Did > the course center on using Linux for development of such graphics? Initially, Tux Racer evolved somewhat haphazardly. One of the assignments in the course was to create a 3D "puppet" that could be positioned by selecting and moving parts of the puppet (the purpose was to teach us hierarchical modelling, among other things). We were only required to do a very basic "stick-man" type of puppet, but were encouraged to be more creative, and I thought it would be cool to create a puppet of Tux. Why Tux? I'm (obviously) a big fan of Linux -- I've been using it full time since 1997, and off-and-on before that -- and it just seemed like an obvious choice. The final project in the course was open -- we were required to submit a proposal for approval, and -- once the instructors and TAs approved it -- implement and demonstrate it. I thought it would be fun to use my Tux model in some kind of game, and having recently played 1080 Snowboarding (a N64 game) at a friend's place, I came up with the basic idea of Tux sliding down a snow-covered mountain. The machines used in the course were SGI Octanes -- there is a lab full of them at the school, but there were more students than machines so I sought a way to do my work at home under Linux. I did some research on the web, and a week later I had a new Celeron 366@550 w/ Voodoo3 2000 that I could use for working on Tux Racer (my old P90 w/o 3D acceleration just wouldn't have cut it :). The development went very smoothly, and the port from Linux/Mesa to Irix/OpenGL was as easy as changing the Makefile (and I had the pleasant realization that my home machine outperformed the SGI workstations!). > Secondly, where would you like Tux Racer to head. Are you aiming for > something like "Coolboarders" or 'Tony Hawk's Skateboarding" on the Sony > Playstation, or are you just looking for a downhill racer? What about > tricks for tux? Multiplayer? What I am looking for is what features are > planned to be added and what would like to be added. Because the game originated as a graphics project, it's still very bare-bones in terms of gameplay. I hope to correct that soon. There's a development plan posted at http://tuxracer.sourceforge.net/plan.html , and it lists some of the gameplay-type things that we hope to add. There's currently a good discussion about this on the tuxracer-devel mailing list, and many of the details are being hammered out. Here's the tentative plan: the courses will be divided into groups ("cups" like in MarioKart), and to advance to the next group you'll have to beat a certain total score in the current group. You'll be given a certain amount of lives to do this in -- "dying" during a race means you'll have to start that race over, and losing all of your lives means you have to start the group from the beginning. Points will be awarded based on completion time, tricks performed in mid-air, a health bonus (based on how much health you complete the course with), bonus points scattered throughout the course, etc. There will also be MarioKart-style accelerator chevrons on the course, teleporters (which teleport you to somewhere else on the course -- not always a shortcut), as well as strategically-placed "extra-life" tokens. It's been suggested that we add a Coolboarders-style chairlift so that a race can consist of multiple laps; I'm reserving judgement until I actually play Coolboarders, though it sounds like a good idea. Other things in the works: music (Joseph Toscano is working on that, and has already contributed some excellent tunes) and sound effects; we've decided to use SDL and the SDL_mixer library for that. We also would like to allow course designers to place 3D models on the courses, and for that we'll go with Steve Baker's PLIB library (which will also be used for the UI and joystick support). James Barnard has done some promising work on sound effects and 3D models for use in the game. One more thing that I should mention: Steve Baker (author of Tux: A Quest for Herring) has suggested that we aim for a consistent "style" for our Tux games, similar to the consistency that exists between all of the Mario games. To do that Tux Racer will use silver and gold herring for health bonuses, spinning Tuxes for extra lives, etc. > Thirdly, is there any intention of additional controls? By this I > basically mean joysticks. Yes, once we have the ability to do tricks a joystick/gamepad will definitely come in handy, and support for them is planned. I suppose I'll have to go buy one. :) > That's all I have to ask at this stage - I can assure you I will have a > few more questions when writing commences. I look forward to hearing and > working with you/your team. (I intend on *trying* to make a few levels > to contribute, to demonstrate the level-creation process to readers.) Ok, feel free to ask away. I hope you don't mind that I'm CC'ing this to the tuxracer-devel list; other developers might have things to add (tuxracer-devel'ers: make sure you CC: Lee in your reply). Creating new courses is actually quite easy (there's a short primer in the README); all you need is the Gimp, and it becomes even easier if you use Ingo Ruhnke's script-fu scripts (on the Tux Racer webpage). Again, don't hesitate to ask if you have questions. Cheers, Jasmin -- Jasmin Patry Master's Student, Dept. of Computer Science jf...@cg... http://www.cgl.uwaterloo.ca/~jfpatry/ |
|
From: Steve B. <sjb...@ai...> - 2000-04-19 06:53:22
|
Jasmin Patry wrote:
> > 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?
I don't think I have strong opinions either way.
Since paddling at high speed doesn't enable you to "cheat", you
already need to be careful how and when you use it. Adding an
additional limitation seems rather harsh. You are hurtling towards
a tree - and you find yourself too tired to paddle and slow down?
You are stuck in a hollow and you have to wait around until you
recharge enough energy to get out? Nah - that's no fun.
I guess I come down marginally on the "don't bother with energy"
side of the fence...but if there was ever a good reason to use
energy for something else, I think I might come down on the other
side.
<...lives...>
> 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).
Yes - I think a few do that - MarioKart certainly does it.
> 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).
Yep - exactly. Wave Racer (another N64 game - with JetSki's this time)
also opens up secret short-cuts when you play against the more serious
opponents...that's nice.
> 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.
Yep. Computer opponents are going to be "interesting" to program!
> Someday Tux Racer will have Gown and Beasdie and others to race
> against...
Yep - although the Daemon is going to need some kind of a snow-board
or something. He doesn't look like a snow-loving kind of a guy.
We have some other characters to play with too - Susie, the SuSE
Camelion and Wilbur the GIMP come to mind also. Unfortunately,
nobody has ever painted a body for Wilbur - so some imagination
is called for.
> 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).
Well, I firmly believe that there shouldn't EVER be pits that you can't
paddle out of eventually. That's really contrary to good game design
criteria...but the issue of where to reset to is an interesting one.
One option is to remember the position of Tux every second or so
into a big array somewhere. When you crash, you get backed up
(say) 5 seconds the first time, 10 seconds the next and so on.
Ultimately, you'll be backed far enough up the course to let
you go a different direction and escape.
Personally, I think 'death' should restart the race from the top.
It's not as though the player will lose an hour of gaming - races
can only last a couple of minutes at most.
> > 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.
Right. The one in DiddyKong racing *definitely* violates physical laws!
I guess another way would be to have the effect of the speedup diminish
greatly if you don't hit it straight on. That would work pretty nicely
I think.
Hmmm - I think that's what TuxKart will do. If you enter the chevron
within about +/- 30 degrees of the centerline, you'll get 100% of the
speedup - but as you get further off-center, the effect will reduce
more and more until if you cross it at 90 degrees to the centerline,
it'll have no effect at all.
TuxKart is *running* now BTW. You can drive the kart round and round
a wiggly track that looks a lot like the 'urban' track in MarioKart.
The brakes work - steering is good, etc *AND* it works over the network!
One thing I've been playing with is camera control. I didn't like the
way that the camera followed Tux such that he stayed more or less glued
to the center of the screen - with us only seeing a strictly rear view.
I found that if I record the last 1/2 second or so of motion into a
circular buffer and always have the camera use a 1/2 second out-of-date
position for the place to look at, you get a much more exciting view
of things because as Tux turns, you get a brief side-view until the
camera 'catches up'. It also makes jumps and falls much more 'dynamic'.
I think Tux-Racer would benefit from that also.
> > 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.
You are thinking of Mario64 not MarioKart I suspect.
MarioKart doesn't have "points" - and no coins either. It uses spinning
cubes for 'bonus' items like speedups, koopah shells that you can
shoot and bananas for your opponents to slip on.
I was playing a few if the racing games my son has for N64 and PlayStation,
(erm - "research" - honest!) One thing I saw that I REALLY liked was in the
StarWars Episode 1 pod racing game. There is a button you can push as you
come close to an opponent that makes your character swear and hurl insults
at the other player...it doesn't *DO* anything from a game perspective
- but it's a LOT of fun :-)
All of the characters swear in their own languages - so the only one
you can understand is Aniken and what he shouts is pretty tame.
--
Steve Baker http://web2.airmail.net/sjbaker1
sjb...@ai... (home) http://www.woodsoup.org/~sbaker
sj...@ht... (work)
|
|
From: Jasmin P. <jf...@mu...> - 2000-04-19 03:37:17
|
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/
|
|
From: Steve B. <sjb...@ai...> - 2000-04-16 01:26:12
|
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. This had some serious problems - and I eventually split them up into two separate concepts. Why? Well, it's rather complex - but I think it's profound and applies to Tux Racer as much as it does to Tux - A Quest for Herring: 1) I needed 'strength/energy' to limit the amount of 'flying' that Tux could do. Being a Penguin, Tux can't exactly fly in my game, but flapping frantically does slow his falls and increase his jump distances. However, if Tux was close to death due to damage, it seemed very wrong that a jump/flap should kill him. Even worse, excessive jump/flapping would kill him and that's just plain silly. 2) It's almost a cardinal rule of games design that you shouldn't let the player get themselves in a position where you are wandering around in a level with no possibility of being able to complete it due to an earlier mistake. That just leads to frustration - and the goal of a game is NOT to frustrate people unduly. With energy that you can just 'run out of', you might have a place in a level where you need to 'flap' to extend a jump in order to complete the level. If you can run out of energy then you can't possibly make the jump and you are frustrated. I could (and did) fix that by providing 'Silver Herring' that Tux could eat to give him more energy. But that wasn't enough. You could still get to the point where you'd eaten all the herring you could ever reach and then run out of energy and THEN want to make that jump. The fix was to allow Tux's energy to gradually recharge. Slowly enough to prevent you leaping and flapping all the time - but fast enough to allow you to complete a level come-what-may. The trouble with *THAT* is that if 'energy' and 'damage' are the same thing then damage gradually recharges. This makes it unnecessary to avoid hurting Tux because no matter how often he gets hit over the head or bitten by Killer Whales, you only have to find a safe place and wait around for a while and you'll be OK again. That makes it really hard to design levels where the player has to be careful. He could always play recklessly and then wait for a recharge. 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. 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. > > > 100? points for never using the paddle key > > > > I don't think you need to do that - if you have to resort to paddling, > > you've already lost so much time that you'll get a bad time score. > > No need for a double penalty. > > 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. 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. When you are going slowly (or stuck in a hollow), paddling can somewhat speed you up - but you have to know when to stop paddling if you want a really good speed. That's kindof analogous to Olympic bobsledders who have to know when to stop pushing and jump into the sled. 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. That may mean that you don't need a penalty for paddling. This seems more natural to me. > > 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. > ...but for speed boosts I favour > some kind of symbol on the terrin itself -- chevrons have been used in > so many racing games that they're instantly recognizable (which I think > is a good thing). Yes - I agree. I havn't come up with a 'speed boost' thing for Tux_AQFH because it isn't that kind of a game. I agree that the red and yellow chevrons used in so many games have become a 'culturally obvious' icon and to choose anything else would be silly. I'm starting to write a 'TuxKart' game (al'la Mario-Kart) in odd moments (I've opened a SourceForge project for it to kindof reserve the name), I'll certainly be using red and yellow chevrons for that. 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. > Bonus points should be represented by something other than herring, > IMHO, though off the top of my head I can't think of anything good > (bowtie? CD? 3-D /. ?) 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. > I would make the teleporters look like portals of some sort -- say a > (translucent?) polygon with an animated perlin-type texture, or something > similar. Yep. That's what I did for Tux_AQFH. I have a texture map that looks like a 'sparkle'. It uses an animation technique that allows the texture to twinkle in an interesting manner by just translating the map sideways by a carefully specified distance each frame. In Tux_AQFH, I map that onto a billboarded circle. It sortof looks like a sphere (because the circle turns to face you - so it appears spherical) but the fact that the texture is mapped onto a dead flat surface means that it looks like a 'portal' or something. Children have no trouble recognising it as a teleporter without me ever telling them....which is amazing! 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. For *displaying* current lives, health and energy, I use a row of tiny Tuxes for lives, a row of 'life sparks' to show health and a herring that gradually turns into herring bones as Tux 'consumes' his energy. I had a lot of fun programming that status bar. I also have a pile of snowballs that depletes as Tux throws them and a row of bubbles that show how much air he has left when swimming or wearing his space helmet. I wanted to avoid having numerical displays where possible - but I think Tux Racer will need numerical timers (and perhaps bonus point counters). > > You'd want to make it EASY to 'open up' the first few levels - but > > make things increasingly hard right up to the end. > > Right, that makes sense to me. (I can't remeber what 1080 does... > doesn't it have a few open at the start, and then they're opened up one > at a time?) Yes - exactly. -- Steve Baker http://web2.airmail.net/sjbaker1 sjb...@ai... (home) http://www.woodsoup.org/~sbaker sj...@ht... (work) |
|
From: Jasmin P. <jf...@mu...> - 2000-04-15 15:54:10
|
On Thu, 13 Apr 2000, Steve Baker wrote: > However we might decide that you need to paddle like mad just before > touchdown or something...to add more skill to those long leaps. Hence, > a beginner who can't get that timing right might have to take a jump > more slowly in order not to fly quite so high and hence risk damage. A (fairly) easy way to add skill to landings would be to allow the player to have some control over Tux's orientation in mid air. The best landings would be those where he lands "flat", while really bad landings could (say) result in a crash where he goes spinning out of control. Damage could be reduced in good landings and increased in bad ones, too. > BTW: Now Tux slides on his ample belly, he could dig his toes into > the snow to slow down.... Good idea... > > Rocks and trees, definitely. > > When I said rocks, I didn't mean large boulders - I meant the existing > patches of rock-texture. Sliding over that would be pretty uncomfortable! Yup! I haven't added that to the health system yet, but I plan to. > > But, in the current version at least, you can shave seconds of your > > time by holding down the paddle key all time. The idea was to give an > > incentive to doing the race 'pure'. Maybe the incentive should be > > even bigger, given that on some tracks it might be *very* hard to beat > > par without paddling. > > Paddling should slow you down if you do it beyond a certain speed... > a useful way to slow down - and a definite incentive not to do it when > you don't need to. Yes, paddling does slow you down above a certain speed. > > graphics/effects. Which is funny since I'm not really into graphics > > (my most-played game of all time is the text 'roguelike' angband). > > But when I kept coming back to the Loki Heroes of Might and Magic > > demo, it was because I wanted to see what a 'monk' looked like in > > battle, etc. > > Certainly that's the number one motive for my 9yr old son...getting on > to the next level takes on 100% importance - and having to collect 'things' > to do that is the only reason to collect stuff at all. Yup, I think much of the motivation of going to the next level has to do with the novelty that comes with each new level -- getting to see new monsters, power-ups, terrain, obstacles, etc. is a very powerful motivating factor. Jasmin -- Jasmin Patry Master's Student, Dept. of Computer Science jf...@cg... http://www.cgl.uwaterloo.ca/~jfpatry/ |
|
From: Jasmin P. <jf...@mu...> - 2000-04-15 15:22:09
|
On Thu, 13 Apr 2000, Jules Bean wrote: > On Wed, Apr 12, 2000 at 11:09:30PM -0500, Steve Baker wrote: > > Jules Bean wrote: > > > > > > Points for *long* periods of being airborn - perhaps for each period > > > of being airborn for longer than 0.5 seconds. > > > > Well don't we have to have 'damage' scored on Tux for hard landings, > > hitting trees and stuff - and perhaps for scooting over rocks at high > > speed? (That's hard on your feathers you know!) That makes for somewhat > > contradictory requirements...I think a better way to reward long 'air > > time' is using tricks (see my comments below). A "big air" bonus for tricks is common and would make sense. > Contradictory requirements aren't a bad thing, necessarily. They force > you to try to make the right trade-off, which makes for an interesting > game. > > As a (relevant) aside I don't think we should damage tux *too* much > for hard landings --- I've landed (on skis) whilst moving pretty > fast. Rocks and trees, definitely. Well, currently landing damage isn't based on how fast you're moving when you land, but (roughly) on the component of your velocity perpendicular to the ground (i.e, how fast you hit the ground). > However, I agree with you about the tricks, definitely. That'd be cool. Yeah. Tux Racer was actually inspired by 1080 snowboarding, way back when, and I've always intended to add a trick mode (and it's also on the list). > > > 100? points for never using the paddle key > > > > I don't think you need to do that - if you have to resort to paddling, > > you've already lost so much time that you'll get a bad time score. > > No need for a double penalty. > > But, in the current version at least, you can shave seconds of your > time by holding down the paddle key all time. Actually, paddling slows you down if you're moving quickly enough. > The idea was to give an incentive to doing the race 'pure'. Maybe the > incentive should be even bigger, given that on some tracks it might be > *very* hard to beat par without paddling. I see your point. I think that it could be a useful bonus if the bonus amount is appropriate. Jasmin -- Jasmin Patry Master's Student, Dept. of Computer Science jf...@cg... http://www.cgl.uwaterloo.ca/~jfpatry/ |
|
From: Jasmin P. <jf...@mu...> - 2000-04-15 15:12:54
|
[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...] On Wed, 12 Apr 2000, Steve Baker wrote: > Jules Bean wrote: > > > Points for *long* periods of being airborn - perhaps for each period > > of being airborn for longer than 0.5 seconds. > > Well don't we have to have 'damage' scored on Tux for hard landings, > hitting trees and stuff - and perhaps for scooting over rocks at high > speed? (That's hard on your feathers you know!) That makes for somewhat > contradictory requirements...I think a better way to reward long 'air > time' is using tricks (see my comments below). 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. > > 100? points for never using the paddle key > > I don't think you need to do that - if you have to resort to paddling, > you've already lost so much time that you'll get a bad time score. > No need for a double penalty. 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? > > Other bonuses might have to wait until we have 'special trick' keys. > > Yep! The (excellent) 1080 snowboard game on Nintendo 64 has that - > and it's nice because they reward small numbers of points for doing > basic tricks - but MUCH more points for doing them in combinations in > quick succession while in the air. I guess that's incentive for > getting long 'air time' - you can fit in more tricks in one 'combo'. > > Doing the same trick twice in a row doesn't constitute a combo in > 1080...and if you fall off the board on landing, your score for > that set of tricks is zeroed. > > We might also want to consider 'bonuses' on the track: > > * Goodies you can hit to get a temporary boost of speed. > * Things that repair your 'damage'. > * Things that score bonus points. > * Perhaps things like teleporters that take you to some other > place on the track (better *or* worse). The first two are already on the list. The latter two seem like they might be good additions too. > This may be controversial - but I would like to propose that > we aim for a common 'style' for such things between Tux Racer > and my Quest for Herring game. (And "Tux-Kart" which may be my > next effort). It would help the world of Tux-based games to > establish a set of common themes like that. Sure, I'm open to something like that. > 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), but for speed boosts I favour some kind of symbol on the terrin itself -- chevrons have been used in so many racing games that they're instantly recognizable (which I think is a good thing). Bonus points should be represented by something other than herring, IMHO, though off the top of my head I can't think of anything good (bowtie? CD? 3-D /. ?) I would make the teleporters look like portals of some sort -- say a (translucent?) polygon with an animated perlin-type texture, or something similar. > > Personally, I'm not too bothered about needing to 'finish' one track > > before going on to the next, although perhaps this should be at the > > course designer's option --- so some tracks are grouped into > > sequences, and some aren't. > > I think it's important to give players a REASON to beat the game. > We aren't offering cash prizes - but the ability to 'get onto the > next level' is a powerful force to get people to keep playing until > they beat the 'par' time. If all the courses are instantly accessible, > people will visit each one quickly and have seen all that the game > has to offer before they've even mastered one level. > > You'd want to make it EASY to 'open up' the first few levels - but > make things increasingly hard right up to the end. Right, that makes sense to me. (I can't remeber what 1080 does... doesn't it have a few open at the start, and then they're opened up one at a time?) Jasmin -- Jasmin Patry Master's Student, Dept. of Computer Science jf...@cg... http://www.cgl.uwaterloo.ca/~jfpatry/ |
|
From: Steve B. <sjb...@ai...> - 2000-04-13 23:31:59
|
Jules Bean wrote: > As a (relevant) aside I don't think we should damage tux *too* much > for hard landings --- I've landed (on skis) whilst moving pretty > fast. Yes - but you have to know how to land - in 1080 (the N64 snowboard game) you have to bend you knees on impact with good timing or you'll wipe-out on landing. Obviously penguins don't do that - heck, it's not even clear that Tux *has* knees :-) However we might decide that you need to paddle like mad just before touchdown or something...to add more skill to those long leaps. Hence, a beginner who can't get that timing right might have to take a jump more slowly in order not to fly quite so high and hence risk damage. BTW: Now Tux slides on his ample belly, he could dig his toes into the snow to slow down.... > Rocks and trees, definitely. When I said rocks, I didn't mean large boulders - I meant the existing patches of rock-texture. Sliding over that would be pretty uncomfortable! > But, in the current version at least, you can shave seconds of your > time by holding down the paddle key all time. The idea was to give an > incentive to doing the race 'pure'. Maybe the incentive should be > even bigger, given that on some tracks it might be *very* hard to beat > par without paddling. Paddling should slow you down if you do it beyond a certain speed... a useful way to slow down - and a definite incentive not to do it when you don't need to. > > This may be controversial - but I would like to propose that > > we aim for a common 'style' for such things between Tux Racer > > and my Quest for Herring game. (And "Tux-Kart" which may be my > > next effort). It would help the world of Tux-based games to > > establish a set of common themes like that. > > I'd be very much in favour of that kind of consistency. But care > needs to be taken not to create an unofficial tux 'cartel' ;-) Sure - that's why I said that it might be controversial. I wouldn't want to even try to impose 'design rules' on authors (as if you could!) but I'd want to try to persuade authors to be consistant where it doesn't impact the game much to do so. One case where this fell down was in the case of 'Gown' - who the authors of XTux decided was Tux's girlfriend. I liked the idea - and I needed a female character so you could play as either the boy hero rescuing the girl - or the grrrl penguin rescuing the boy. Unfortunately, the XTux guys chose to make their 'Gown' be just a pink version of Tux. That looked OK-ish in 2D but in 3D it looked *terrible*. I tried to reach agreement with them on an alternative - but that never happened. It's a shame that the XTux 'Gown' looks nothing like the Tux_AQFH 'Gown' - I'd like little kids to point at the screen of some new game and say "Oh! That's Gown!" ..that won't happen - but that's life. (XTux sucks anyway - and I'd hope that *small* kids wouldn't be playing it - so who cares!) > We could even produce a semi-spoof semi-serious 'tux interface guidelines'! Yes - that could be pretty funny! Any takers? I'd *love* to contribute to it. > You're right. I'm thinking of writing a net.essay on this very issue > - 'satisfaction' in games. Why do we go back to games, and what > should a game designed do to make sure we do? Obviously it's actually > much *easier* for competitive multiplayer games, since the incentive > is 'this time I'm going to beat him...'. Yes. It's a subtle and important issue. > Often I keep playing games because I want to see the cool > graphics/effects. Which is funny since I'm not really into graphics > (my most-played game of all time is the text 'roguelike' angband). > But when I kept coming back to the Loki Heroes of Might and Magic > demo, it was because I wanted to see what a 'monk' looked like in > battle, etc. Certainly that's the number one motive for my 9yr old son...getting on to the next level takes on 100% importance - and having to collect 'things' to do that is the only reason to collect stuff at all. The smash hit N64 game (Donkey Kong 64) has an insane number of things to collect - at least five different items - some of which come in six different colours - one for each of the characters you can play. But in the end, the game isn't about collecting them for their own value - each set of things is used to buy new powers, or new weapons (or new musical instruments!) - OR to get you into new levels. -- Steve Baker http://web2.airmail.net/sjbaker1 sjb...@ai... (home) http://www.woodsoup.org/~sbaker sj...@ht... (work) |
|
From: Jules B. <jm...@he...> - 2000-04-13 12:38:23
|
On Thu, Apr 13, 2000 at 01:21:58PM +0100, Jules Bean wrote:
> You're right. I'm thinking of writing a net.essay on this very issue
> - 'satisfaction' in games. Why do we go back to games, and what
> should a game designed do to make sure we do? Obviously it's actually
^^^^^^^^
designer
;-)
--
Jules Bean | Any sufficiently advanced
jules@{debian.org,jellybean.co.uk} | technology is indistinguishable
jm...@he... | from a perl script
|
2 messages has been excluded from this view by a project administrator.