Thread: [tuxracer-devel] Designing a level - and other questions.
Status: Beta
Brought to you by:
jfpatry
From: Steve B. <sjb...@ai...> - 2000-03-02 04:37:04
|
I decided to have a go at designing a level - it's pretty easy but I have a couple of questions: 1) I change the 'tux_start_pt' to the beginning of my course - but what happens is that Tux appears somewhere completely *wrong*, lies down - and then teleports to the position I told him to start at. I'm guessing that I need to edit the keyframe animation at the bottom of the tcl file - but that looks like being a real pain to do. Would it be possible for that set of keyframes to work in a coordinate system that's relative to 'tux_start_pt' - it would make it much easier to steal the initial animation from another level. 2) It's *REALLY* hard to avoid getting small hollows in the track that Tux can get stuck in. If the track is more or less straight (as with all the existing levels) - that's OK - you just crank up the overall track slope and he'll slide out of the more subtle "traps". However, I'm trying to build a really winding 'S' shaped track - and increasing the tilt of the track doesn't help because you just get even more stuck in the east/west sections of the 'S' curve. There really needs to be a key on the keyboard to make Tux either paddle his arms to get a little thrust so he can go S-L-O-W-L-Y uphill - or he needs to be able to stand up and walk out! 3) At the bottom end of the track, the large 'snow' polygon at the end of the track comes out way too high - so we disappear under the snow when there is still a LOT of track left - eventually the camera pops under that polygon also - and you can see clearly to the end of the track - where it ends abruptly with blue sky. 4) With the friction values stolen from level 1, Tux tends to get 'stuck' on the edges of rock patches - he slides onto the rock, flips around 180 degrees - then slowly moves back onto snow - flips back and so on - sometimes forever. Reducing the friction on the rocks seems to help this a lot - but there are still some strangenesses. 5) Are you culling the scene polygons to the view frustum? I think the speed of the game depends pretty critically on the overall size of the track. 6) It would be cool to be able to set the fog range - so that in some levels things would 'emerge' from the mist unexpectedly. That should be a pretty low cost feature. 7) It would be nice to put those large background.rgb files into the 'common' area...I don't think many people will be painting their own - so it would be better to be able to share them nicely. Anyway, I have a track of sorts done - where would you like me to post it? -- Steve Baker http://web2.airmail.net/sjbaker1 sjb...@ai... (home) http://www.woodsoup.org/~sbaker sj...@ht... (work) |
From: Jasmin P. <jf...@mu...> - 2000-03-02 04:52:36
|
On Wed, 1 Mar 2000, Steve Baker wrote: > I decided to have a go at designing a level - it's pretty easy but > I have a couple of questions: Great! I'll have a go at your questions tomorrow (sleep beckons)... > Anyway, I have a track of sorts done - where would you like me to > post it? Email to my account is fine if it's not too large (under ~1 MB, say). Otherwise, can you post it to a publicly accessible website and send me the URL? Eventually I'll have to figure out a better way for people to submit courses; I don't think SourceForge allows for anon ftp uploads anywhere... Cheers, Jasmin |
From: Steve B. <sjb...@ai...> - 2000-03-02 05:17:35
|
Jasmin Patry wrote: > > Anyway, I have a track of sorts done - where would you like me to > > post it? > > Email to my account is fine if it's not too large (under ~1 MB, say). It's pretty small...so I'll attach it here. > Eventually I'll have to figure out a better way for people to submit > courses; I don't think SourceForge allows for anon ftp uploads > anywhere... You could set up a CVS archive for the levels and give access to selected (ie TRUSTED) users to write to it. That would allow anyone to whom you granted permission the ability to write to any of the levels - which is a little dubious - but with CVS, you can always 'back out' changes if someone does something inappropriate. It might be possible to do the same thing with FTP - they won't allow anonymous access - but they might allow someone with a sourceforge account who has been granted permission by the project owner (ie you). -- Steve Baker http://web2.airmail.net/sjbaker1 sjb...@ai... (home) http://www.woodsoup.org/~sbaker sj...@ht... (work) |
From: Jasmin P. <jf...@mu...> - 2000-03-03 04:04:42
|
On Wed, 1 Mar 2000, Steve Baker wrote: > 1) I change the 'tux_start_pt' to the beginning of my course - but > what happens is that Tux appears somewhere completely *wrong*, > lies down - and then teleports to the position I told him to > start at. > > I'm guessing that I need to edit the keyframe animation at the > bottom of the tcl file - but that looks like being a real pain > to do. Would it be possible for that set of keyframes to work > in a coordinate system that's relative to 'tux_start_pt' - it would > make it much easier to steal the initial animation from another level. Yes, good idea. > 2) It's *REALLY* hard to avoid getting small hollows in the track that > Tux can get stuck in. If the track is more or less straight (as with > all the existing levels) - that's OK - you just crank up the overall > track slope and he'll slide out of the more subtle "traps". However, > I'm trying to build a really winding 'S' shaped track - and increasing > the tilt of the track doesn't help because you just get even more > stuck in the east/west sections of the 'S' curve. > > There really needs to be a key on the keyboard to make Tux either > paddle his arms to get a little thrust so he can go S-L-O-W-L-Y > uphill - or he needs to be able to stand up and walk out! I've been meaning on adding the paddling for a while now. I like the walking idea -- I'll give that some thought. I'd also like to build a simple 3D track editor. I don't think this would be hard to do, and would make fixing hollows and the like much easier. > 3) At the bottom end of the track, the large 'snow' polygon at the > end of the track comes out way too high - so we disappear under > the snow when there is still a LOT of track left - eventually the > camera pops under that polygon also - and you can see clearly to > the end of the track - where it ends abruptly with blue sky. End your track at a grey value of 50% to avoid this. > 4) With the friction values stolen from level 1, Tux tends to get > 'stuck' on the edges of rock patches - he slides onto the rock, > flips around 180 degrees - then slowly moves back onto snow - flips > back and so on - sometimes forever. Reducing the friction on the > rocks seems to help this a lot - but there are still some strangenesses. This is because of the way turning works. In calc_net_force() in phys_sim.c, I rotate the frictional force about the surface normal to implement steering (CW to turn left, CCW to turn right). This seemed to me like a pretty good approximation, and given the Tux is modelled as a particle for physics purposes (though not for collision detection), I have to resort to some sort of hack. But it does result in weirdness on surfaces with large friction coefficients -- like rock. (Tux really should try to avoid sliding on rock -- it does nasty things to his backside. :-) > 5) Are you culling the scene polygons to the view frustum? I think the > speed of the game depends pretty critically on the overall size of the > track. I only do simple culling: I cull everything 100m or further in front of Tux, and 20m or further behind him. I also do some very simple LOD with the trees. This is why your course, which is much wider than the courses we've had up until now, is quite slow. I'll add real VFC to my TODO list. > 6) It would be cool to be able to set the fog range - so that in some > levels things would 'emerge' from the mist unexpectedly. That > should be a pretty low cost feature. Yes, absolutely. I want be able to set the course lighting and the wind velocity, too. > 7) It would be nice to put those large background.rgb files into > the 'common' area...I don't think many people will be painting > their own - so it would be better to be able to share them nicely. Yet another good idea. Thanks, Jasmin |
From: Steve B. <sjb...@ai...> - 2000-03-03 05:58:04
|
Jasmin Patry wrote: > > 3) At the bottom end of the track, the large 'snow' polygon at the > > end of the track comes out way too high - so we disappear under > > the snow when there is still a LOT of track left - eventually the > > camera pops under that polygon also - and you can see clearly to > > the end of the track - where it ends abruptly with blue sky. > > End your track at a grey value of 50% to avoid this. Wouldn't it be better to end at black? ...Hmmm - perhaps a settable end-height is needed. Ultimately, you'll probably want to draw a 'finish line' or something so you can see where to aim for. I'd like to be able to set that to be someplace inside the course itself and do away with the big snow polygon at the bottom altogether. These are things that need to be decided *soon* before you have too many levels built to change it. -- Steve Baker http://web2.airmail.net/sjbaker1 sjb...@ai... (home) http://www.woodsoup.org/~sbaker sj...@ht... (work) |
From: Jasmin P. <jf...@mu...> - 2000-03-03 15:26:56
|
On Fri, 3 Mar 2000, Steve Baker wrote: > Jasmin Patry wrote: > > > End your track at a grey value of 50% to avoid this. > > Wouldn't it be better to end at black? ...Hmmm - perhaps a settable > end-height is needed. Ultimately, you'll probably want to draw a > 'finish line' or something so you can see where to aim for. I'd > like to be able to set that to be someplace inside the course itself > and do away with the big snow polygon at the bottom altogether. 50% was chosen for maximum flexibility; if courses were supposed to end at black then it would be impossible to have a chasm immediately before the end of the course (sort of like the ones at the end of Ingo's level). It wouldn't be hard to make that settable, though. Cheers, Jasmin |