Hi there,

I'm sure that everyone around here has played at least ONE Tony Hawk title in his life so far. So I guess you are all familiar with the basic mechanic of "grinding": You have a long, thin and static object (like a handrail) on the one hand ("long" and "static" do NOT neccessarily mean that the surface describes a straight line, there rail may describe curves and so on) and a object which moves ALONG that rail on the other hand.

So, the big question is: What's the best way to get something like this to work? Creating a path for each rail which describes the "grinding path" would work, I suppose, but creates a LOT of work to create all these paths and to get them in the right place afterwards, because they have to perfectly fit their corresponding rail. An efficient code which tells an object "follow the course of that specific edge of this specific model and the edges the first one is connected to" sounds better to me, but is that possible at all?

Greets,


Alan

Hm, no, you could also(i think so!) use "normal".

If don´t want to explain it now, because i´m want to sleep



If more people want this, i´ll write a Tutorial for it

I want it too.. :-)

Yeah.. me too

K, so I am going to test now, and will write it

hmm, i have been playing a lot of tony hawk wasteland recently, and I honestly think they mark everything, because there are even places to grind in that game that are only textured on (one of them being in "the mall"). That being said, its probably definately possible to automatically recognize it (might be a little buggy though) by taking the normals of the sides of the thin object your grinding on and checking to see if they changed, if they have that means you need to rotate your players pan, and then check the flat part under them and if that changes, then you need to rotate the tilt.

Let's expand a little bit upon this. I don't need the grinding stuff for a Tony Hawk or Skating Game in general but for a Sonic fanfic-game. The basics are the same, however, you also have rail loopings and stuff like that. Check this video to get a better idea of what I would like to do (especially watch closely to the rail looping at 1:12): http://www.youtube.com/watch?v=uHB0y9r-haY

Sorry for the bad quality - I didn't produce this video, just found it on Youtube.


Oh, and about the question of placing paths to mark grinding possiblities: Tony Hawk definitly doesn't do that. Why? Two reasons:

A) Sometimes you may grind upon surfaces you really shouldn't be able to perform a grind/slide on This would definitly not have happened if the programmers had placed paths on every grind-able object.

B) After all, you can create your own level (at least in THPS 2-4, don't know about the others), and the level may include rails to grind on. And you don't place paths there, definitly


Greets,


Alan



PS: Still can't figure out how in the world an automatic grind-possibility-detection-code could look like. Detecting the first spot to start the grind at is not that big of a problem, but as soon as the grind has started, how would you determine the coordinates for the next c_move command? You can't just say "Move ahead and check whether the rail is still beneath your feet, if not, move back" ^^'
Well... you basically COULD do that, at least when using a vector to "simulate" the player's position. But you can't just move that thing "up ahead", because you never know where this "ahead" really is! It could be forward and upwards, it could be forward and downwards or even forward and a step to the left/right when grinding in a curve. And last but not least, every rail ends at some point - we need to keep that in mind when creating the code...

those are definately paths, you can only do them on specific rails.



play T.H.A.W. on ps2, there are places you can grind that are flat objects with an edge texture on them, that means, some programmer had to place something there telling it to be grindable, or it would have been a wall-ride instead. also, do you really think T.H. games are going to make everything simulation like where there are some things that you shouldnt be able to grind on? your encouraged to grind on ropes in that game, you cant do that in real life, where in tony hawk they encourage it on every edge, realistic or not.
again, bad arguement, as the pieces can very well have grindable portions marked in them (internally in the engine)

you do traces, why would you have to move the character to check? you do traces from several different angles, if the angle is too big or another edge cant be found close enough then the grind is done, if there is a nearby edge that fits in some specific parameters, move to that point.


EDITED

As lostclimate said.if the player jumps you make a trace down from the player and check maybe the texture or something like this and then you check the distance . and then if everything is true ,you let the player move over the grinding platform

So, let's say we have our rail done in MED as a .mdl model file. We added it to our level and set its FLAG 2 to ON (let's just assume that we want every object with FLAG 2 set to be grind-able).
In the movement code, we trace down at every frame until a object is hit which has its flag 2 set - there we start the grind.

So far - so good. But now what? We can trace 45° downwards in front of the player. That would let us detect straight rail situations. If the trace hits the same object as the one the grind started on, we move our player there, no problem.
If the rail is going downwards, the 45°-check won't do the trick because if the fall-off of the rail is more than 45°, the trace won't hit anything and the grind would end with no reason visible to the player. In this situation we can add a certain amount of quants to the player position in its current movement direction and trace straight downwards from this new position. This would do the trick for straight rails which go upwards and downwards and would even work for loopings.

But what about rails which describe curves? Checking for a point "straight ahead" is useless. We could use the trick we did with straight rails and do three traces: the original one, one at a position left of the original one and a third one to the right of the original trace. However, if our rail is thin enough, it might go right through these three traces which would be unable to detect it as a result. The problem I see here is that the curve angle may be different at any rail so the sideways-distance of our three traces would have to be able to change accordingly as well.
The alternative would be not to do three traces, but 5, 7, 9 or even more - but doing that many traces every frame might slow down the overall performance and cause the FPS to drop...


Greets,



Alan