Drive a car to a certain destination

Started by
5 comments, last by ferrous 8 years, 4 months ago

I was wondering how to calculate a car to drive to a certain position in space.

While a tank or a person can turn around their own axis a standard car cannot, it needs to turn around until it is facing the destination point in space and then start driving into it's direction.

My first thought was calculating the angle between the desired direction and the current direction of the car every cycle

IMG00053.gif

and let the car turn step by step until delta angle is zero.

However I think this might be overkill to do for lots of cars in my Android racing game.

I always try to avoid sin and cos because I was told they are very expensive to compute on CPU and I wanted to ask if there is a better faster easier way to calculate this?

Or if this is a good way to go.

Thanks

Best Regards

Advertisement

You could pre-generate turning circles based on the type of car.

The turning circle will only vary based upon speed (the slower you go, the tighter the turning circle... to a point). So, you could just scale it up or down based on speed, it wouldn't need to be 100% accurate unless you're aiming to write a simulation, so long as it's believable.

Try plotting circles in advance, storing them along with the details for the car (e.g. its speed and number of gears etc) and using them for turning.

Let me know if this helps!

Use a fixed number of directions, for explaining, assume 4 (N/E/S/W), but in reality you'd use 16 24 or even more.

Every turn/tick, a car may rotate one direction N -> E for example, or N -> W, but not N -> S. It may also drive forward in that direction. The limited amount of rotation gives a turning circle, lower speed gives turns closer to each other, so you can turn "faster".

Since directions are fixed, you can pre-compute angles.

My first thought was calculating the angle between the desired direction and the current direction of the car every cycle,

did that too my tank was circling around waypoints

:P

However I think this might be overkill to do for lots of cars in my Android racing game.

how many? those cpus ain't that bad.

I always try to avoid sin and cos because I was told they are very expensive to compute on CPU and I wanted to ask if there is a better faster easier way to calculate this?

either produce your own lookup table with lerping between values like:

http://www.gamedev.net/topic/673818-time-to-angle/?view=findpost&p=5266109

or search through internet, about faster sin cos, there are lots of examples how to speed up that.

but i higly doubt that calulating (2x sin + 3x cos) * 1000 cars per every frame slow that much.

There is an article on gamasutra, Towards More Realistic Pathfinding, that has a method for doing this. I'm not sure how many cars you have, but you might use that. Though honestly, for a racing game, you might want to look around for a different approach, most use more of a reactionary approach over pathfinding.

Also, as a sidenote, most tanks can't actually turn in place, they can get pretty tight turning radiuses though.

However I think this might be overkill to do for lots of cars in my Android racing game.
I always try to avoid sin and cos because I was told they are very expensive to compute on CPU and I wanted to ask if there is a better faster easier way to calculate this?
Or if this is a good way to go.

Thanks
Best Regards


Unit vectors are excellent at this kind of thing and the best part is that when used correctly don't have many sin/cos calls. Avoiding sin/cos is a good call but don't think you can't use it.

I was about to post a solution of rotating a vector towards another without the need of any sin/cos but then I decided against it since it would be untested code. Let me know if you want to see it but know what you want can be done without sin/cos.
My current game project Platform RPG

I also don't think it's all that expensive, even on android phones, to call sin/cos. I've done windows phone development (Which often have same hardware), and done some fairly expensive calculations every frame, and still had a rock solid 60 fps.

This topic is closed to new replies.

Advertisement