Thread: [tuxracer-devel] Course precisions
Status: Beta
Brought to you by:
jfpatry
From: Julien C. <jo...@fr...> - 2000-04-11 22:38:15
|
Hi, I'm working on a 3600*120 course (it works with the latest versions but not the older ones) and i would like to know: -Can i change the difference between the white and black for elev.rgb : i mean i would like white pixels to make higher mountains? -Can i change the maximum_trees? in a big course i need to put a lot of trees and i can say that there are good performances during the course (nearly as a normal (smaller) course) but it takes a lot of time to load and have the 3d-preview. Tuxracer is so cool!!! Julien |
From: Jasmin P. <jf...@mu...> - 2000-04-11 23:37:57
|
On Wed, 12 Apr 2000, Julien Canet wrote: > Hi, > I'm working on a 3600*120 course (it works with the latest versions but > not the older ones) and i would like to know: > > -Can i change the difference between the white and black for elev.rgb : > i mean i would like white pixels to make higher mountains? Increasing tux_elev_scale in course.tcl will do what you want, I think. That value specifies the height in metres between white pixels and black pixels. > -Can i change the maximum_trees? in a big course i need to put a lot of > trees Unfortunately, the only way to do that is to increase the value of MAX_TREES in course_load.c. I'll increase it for the next release -- is 8192 enough? :-) > and i can say that there are good performances during the course (nearly > as a normal (smaller) course) but it takes a lot of time to load and > have the 3d-preview. *nod* Unfortunately, I don't think there's very much I can do about that. > Tuxracer is so cool!!! Glad you (still!) think so! 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-12 03:14:35
|
Jasmin Patry wrote: > > and i can say that there are good performances during the course (nearly > > as a normal (smaller) course) but it takes a lot of time to load and > > have the 3d-preview. > > *nod* Unfortunately, I don't think there's very much I can do about that. Well, for the load time, possibly nothing can be done (well, you could optimise - or perhaps do some of the work off-line) - but for the previews the game could create snapshots of the course previews as PNG's or something and display those instead of the fully rendered versions. You could also render them at smaller size so you can see all of the courses (or at least - say - nine of them at a time) and pick them like that. This would have one interesting side-effect - which is that the course designer could hide parts of the course that are supposed to be a suprise by simply painting out the "suprise" section. The thing TuxRacer *urgently* needs IMHO is a goal to beat - something as simple as a 'par' time stored in the level's config file with code to prevent you choosing level 'N' until you've beaten the par time for level N-1. That would be enough to make the program cross the boundary from 'cool demo' to 'playable game'. It would then be necessary to grade the existing levels according to difficulty so things start off easy and get progressively harder. -- 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-12 10:13:20
|
On Tue, Apr 11, 2000 at 10:11:23PM -0500, Steve Baker wrote: > The thing TuxRacer *urgently* needs IMHO is a goal to beat - something > as simple as a 'par' time stored in the level's config file with code > to prevent you choosing level 'N' until you've beaten the par time for > level N-1. That would be enough to make the program cross the boundary > from 'cool demo' to 'playable game'. *nods* I've been thinking about scoring, too. Here's some vague ideas: Have a 'par' time, as Steve says. Score 1000 points for completing the level 'on par'. Otherwise, score 1000*[par/actual time], so 'half par' (which probably shouldn't be possible) gives 2000 points. Alternatively, square or cube the [] portion to give slightly more reward for speed. Then, the bonus points. It's not clear to me all the things we'd want, but some ideas: 100 points for finishing the level in the air ('cos it looks cool) Points for *long* periods of being airborn - perhaps for each period of being airborn for longer than 0.5 seconds. 100? points for never using the paddle key Other bonuses might have to wait until we have 'special trick' keys. Then we could have two high-score tables per track - a pure speed one, and a points one. 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. Comments? Jules -- 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-04-13 02:58:46
|
On Wed, 12 Apr 2000, Jules Bean wrote: > I've been thinking about scoring, too. Here's some vague ideas: > > Have a 'par' time, as Steve says. Score 1000 points for completing > the level 'on par'. Otherwise, score 1000*[par/actual time], so 'half > par' (which probably shouldn't be possible) gives 2000 > points. Alternatively, square or cube the [] portion to give slightly > more reward for speed. Makes sense. > Then, the bonus points. It's not clear to me all the things we'd > want, but some ideas: > > 100 points for finishing the level in the air ('cos it looks cool) > > Points for *long* periods of being airborn - perhaps for each period > of being airborn for longer than 0.5 seconds. > > 100? points for never using the paddle key > > Other bonuses might have to wait until we have 'special trick' keys. I was also planning on giving a bonus based on how much health remained at the end of the track. > Then we could have two high-score tables per track - a pure speed > one, and a points one. Sure, that would be neat. > 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. A lot of games require you to get a minimum score/placing on a circuit of tracks before the next set is unlocked. That would be another way of doing it. 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 04:34:45
|
Jules Bean wrote: > Have a 'par' time, as Steve says. Score 1000 points for completing > the level 'on par'. Otherwise, score 1000*[par/actual time], so 'half > par' (which probably shouldn't be possible) gives 2000 > points. Alternatively, square or cube the [] portion to give slightly > more reward for speed. > > Then, the bonus points. It's not clear to me all the things we'd > want, but some ideas: > > 100 points for finishing the level in the air ('cos it looks cool) > > 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). > 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. > 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). 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. 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') This is a common thing to do in video games. The Nintendo 'Mario' games are like this - in ALL Mario games, a spinning coin is for points, a mushroom is an extra life and so on. This makes it easier for a player to pick up a new game and get instant satisfaction without needing to consult a manual. > 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. If we end up with a LOT of levels (as seems likely), then grouping them obviously makes sense. Obviously there needs to be an undocumented 'backdoor' for developers to be able to skip on to whatever level they want to test. My Tux_AQFH game uses a password you can type in during the game to enter 'cheat' mode in which you don't take damage and can skip on to any level without meeting the prerequisites of that level. -- 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:29:05
|
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). 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. However, I agree with you about the tricks, definitely. That'd be cool. > > > 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. 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. > > > 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'. That sounds great to me. > 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). Definitely. I think Jasmin's already mentioned that in his todo. > 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' ;-) We could even produce a semi-spoof semi-serious 'tux interface guidelines'! > > > 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'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...'. 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. In terms of scoring, I find it a tremendous motivator if you get those corny little floating numbers which mean "you've just scored 10,000" points. The instant gratification is somehow more important than the score you get at the end of the level. It's nice to know immediately how well the trick went. [You can then cancel the points dramatically if tux lands badly] > > You'd want to make it EASY to 'open up' the first few levels - but > make things increasingly hard right up to the end. Mais naturellement... Jules -- Jules Bean | Any sufficiently advanced jules@{debian.org,jellybean.co.uk} | technology is indistinguishable jm...@he... | from a perl script |
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 |
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-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-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-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 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: 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-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 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: 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: Jasmin P. <jf...@mu...> - 2000-04-13 02:54:55
|
On Tue, 11 Apr 2000, Steve Baker wrote: > Well, for the load time, possibly nothing can be done (well, you > could optimise - or perhaps do some of the work off-line) - but for > the previews the game could create snapshots of the course previews > as PNG's or something and display those instead of the fully rendered > versions. You could also render them at smaller size so you can see > all of the courses (or at least - say - nine of them at a time) and > pick them like that. > > This would have one interesting side-effect - which is that the > course designer could hide parts of the course that are supposed > to be a suprise by simply painting out the "suprise" section. Yup, that sounds like a pretty good idea. > The thing TuxRacer *urgently* needs IMHO is a goal to beat - something > as simple as a 'par' time stored in the level's config file with code > to prevent you choosing level 'N' until you've beaten the par time for > level N-1. That would be enough to make the program cross the boundary > from 'cool demo' to 'playable game'. I definitely plan on doing something like this. (Probably not as quickly as you'd like, though :-). Jasmin -- Jasmin Patry Master's Student, Dept. of Computer Science jf...@cg... http://www.cgl.uwaterloo.ca/~jfpatry/ |
From: Ingo R. <gr...@gm...> - 2000-04-12 15:42:41
|
Julien Canet <jo...@fr...> writes: > -Can i change the difference between the white and black for elev.rgb : > i mean i would like white pixels to make higher mountains? Something like: tux_elev_scale 12 -- ICQ: 59461927 http://pingus.seul.org | Ingo Ruhnke <gr...@gm...> http://home.pages.de/~grumbel/ | ------------------------------------------------------------------------' |