Preventing players racing the wrong way

Game Engine Game Engine Support and Discussion
#1

Hi all-

I am pondering the problem of stopping players racing the wrong way around a track- the way my race position system works relies on the distance travelled and going backwards would mess this up.

I am thinking about using obj.localOrientation to get the direction of the player, and if it equals between 90 and 270 degrees (which I assume is facing/going backwards) a message will appear and disable the distance calculation. But I have a niggle:

obj.localOrientation returns a 3 x 3 matrix. How do I convert this to show degrees? If for some strange reason this cant be done, how do I read the matrix output?

Cheers

Paul

#2

  1. You can use obj.localOrientation.to_euler() to convert it to a Euler list (X, Y, and Z), which you can then use. However, this method will most likely not work unless your track is straight - if it curves at all, then it will register ‘going backwards’ whenever you turn a certain way, making circuit races impossible.

  2. A solution to this problem may be to use invisible check point objects - if the Player hits checkpoint 3 and then checkpoint 2, then he’s going backwards.

#3

Hi SolarLune

I wondered if non straight tracks would throw this, how annoying! is it possible to have checkpoints that only register in one direction, say, based on a surface normal?

Cheers

Paul

#4

Hi SolarLune

I wondered if non straight tracks would throw this, how annoying! is it possible to have checkpoints that only register in one direction, say, based on a surface normal?

Cheers

Paul

#5

Well, you could do it with surface normals, but if the numbers work backward, then it would work well on curved or non-curved tracks.

#6

Please, could you tell, how it’s possible to do with surface normals?
I mean, the plane object will detect the collision with one side ONLY.

Thanks

#7

I thought this would be possible by having several planes all facing (normal pointing) in the direction of the track. The car object would do a raycast and return the normal- if its negative the normal is pointing the right way and visa versa. The plane would be set to ghost. If the player flies the wrong way the forward motion calculation would change (as it detects the positive normal) so that a repulsive force would push the player back, and a message telling them to turn around.

Thinking about it I could use a logic brick approach-the trick would be to occlude the reverse sensor in forward movement- looking I see there is an occluder visibility logic block, which may be useful. Duplicate this all over the track and its a working idea.

#8

Your ray cast idea sounds incredibly accurate to how I would think the process would work. That should work fine - just be sure to cast the ray forward in the same amount (or more than) the distance the object is moving. I didn’t have an actual idea of how to do it, but your idea sounds very plausible.

#9

Hi

I was testing a simple collision detecting setup.

No matter what logic settings I tried, the cube object is colliding always with plane objects :frowning:

Attachments

Collision_detection.blend (131 KB)

#10

Xjazz> Thats odd, I tried it (I’ve never seen a demo of the toggle property…until now! Very interesting!) and the cube passes plane 1 (toggles TRUE) and then plane 2 (toggles FALSE) without problems.

SolarLune> I’m getting better at breaking problems down into ideas, I just fail on the Python part! As far as the movement script, I imagined an if/ else setup that hinges on detecting the poly normal. On detection of a normal pointing towards you (i.e. you are driving backwards) the forward motion value would change to negative, pushing you back.

I had a look at the raycast in an API index and my mind went dead- its a lot more complex than I thought!

#11

Rubbernuke, the problem with my demo is the plane 2 toggle, even the plane 2 normal is pointing away.

#12

I think the only solution is with python, I’ve tried a few things and I’ve had nothing work.

#13

I haven’t read the whole thread as it is quite lengthy, but from what I know of the problem, if you could fix the problem of the distance calculation, would you not be able to avoid having to restrict the players direction?

If so, see the below, I can help turn this theory into code, though I’m a little fuzzy on the maths you’d use for finding the plane the objects centre lies on (tripped by the simple stuff… :o ).

car tracking.png787×736 18.3 KB

#14

It is pretty complex - I don’t know normals very well, but I’d like to learn.

#15

Basically, your normal is the line that is perpendicular to the tangent of the line/curve/face you’re calculating it for. Because this 3D, a 1D curve can have a normal in 2 dimensions, as in these 2 dimensions you can have a line that is 90º to the tangent. (I’m not sure of the accuracy of this, as it is sort of a conclusion I drew up myself from the logic but: the reason the normal of faces and straight lines is at 90º to itself is because the tangent lies in the same plane?)

In my diagram above, using the linear interpolation model would give a very “blocky” curve which is parallel to the edges, but is a necessary sacrifice for efficiency (if it is made to work, a more complex interpolation model such as polynomial or spline could then be used, but these would add much more logic overhead and would give very little benefit)

If you get a point on the curve, you can use your interpolation model to find the distance to another point on the curve.

In terms of code, this would require a list of all opposite vertex points (the green points in my last diagram) for simplicity - in an array of 2 elements, then all of these in another array. You then generate a list of average points, as a precomputed list. Then put this array of average points into the script (They’d need to be in order for simplicity, as in the starting line will be the 0 element, and the finsh should be the final).

You would then (I have a vague idea how) find the point on the curve directly relating to the objects position (using the plane of the normal was a preliminary idea, but I am considering replacing this with some vector maths for efficiency). Then, you interpolate from your point, to the next average point in the array. and from then to the finish to find the distance, then you could assign this value to a property on the object, and then send a message containing this value to the HUD element that gives out positions.

I’ll look into making a demo of it for you.

#16

Hi

Here is one solution (257b).

In this method, a predefined check-point hits are listed in own[‘go’] property.

Everytime the cube hits another object, script is getting that object name and checking if it’s matching with own[‘go’][0] name.

Attachments

Gate_hit_257b.blend (301 KB)