🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Non-physics vehicle movement

Started by
5 comments, last by SyncViews 5 years, 3 months ago

Hello!

Could someone help me out with what is the best way for a vehicle movement without physics?

I'm trying to do something like a top down shooter and currently have come to a wall with non physics vehicle movement. Surprisingly I can't find anything really helpful online. I don't want to use physics as I need a pixel perfect movement and physics can be unpredictable.

I have a basic idea involving line tracing from corners of the vehicle, but I may actually need more points than four for the movement to look right, and the computation in that case is starting to seem little bit too complex for just one vehicle.

Is there some obvious routine how to do that that I'm overlooking?

Also I'm working in unreal engine if that's any help, but this is supposed to be more general question.

Thanks!

Advertisement

Check out this post by Livio De La Cruz (https://superheroesinracecars.com/2016/08/11/implementing-racing-games-an-intro-to-different-approaches-and-their-game-design-trade-offs/). You may be underestimating the ability of a physics simulation to do what you want though. You can have a physics simulation without an opaque physics engine, and you can have an opaque physics engine that you can force to do exactly what you want, as long as you know just enough about how it works.

You can adjust the output of the physics engine to compute less exact but pixel-perfect movements.

For example. if the physics engine has floating-point outputs but you can draw your vehicle in 16 different facings (0, pi/8, ... 15 pi/8) and at whole pixel coordinates, you can round off facing (i.e. draw the vehicle facing right if it is actually facing between -pi/16 and +pi/16, facing towards pi/8 for the interval between pi/16 and 3 pi/16, and so on) and position (e.g. draw the sprite at x=5 if the physics engine says x is between 4.5 and 5.5). 

Depending on specific game mechanisms, rounding the actual physical data, frame by frame, to match the displayed values might or might not be a good idea: for example shooting in the direction of the displayed facing instead of the "real" facing and testing collisions against the displayed position of the vehicle should improve consistency, while rounding positions might cause random speed inconsistencies between maneuvers.

Omae Wa Mou Shindeiru

The basic physics for a top-down 2D vehicle are fairly straightforward if you just want to add them to say a shooter or RTS where they don't need to be physically correct but just look about right.

 

For tracked vehicles like tanks it is really simple, as they can rotate on the spot about an origin point both when moving and when still. Rotate the velocity along with the vehicle.

 

Wheeled vehicles are a little more complex because the steering wheels don't rotate the vehicle directly, it needs to also be moving forwards/backwards.Still for basic pre-made vehicles you can approximate the amount to rotate based on the angle of the steering wheel, the wheel base length and its forwards/backwards speed to rotate the vehicle appropriately. I don't see the need for any "line tracing" for basic functionality.

 

You can then add some math to for example reduce speed when turning, and for keyboard input make the steering more gradual over a half second or so (the tap repeatedly for less sharp turns, hold for sharp turns type thing you get). If you start wanting to simulate friction, crashing and sliding into barriers, locked wheels, user created verhicles/wheel arrangements, etc. though you probably want a full physics engine.

Thank you for the replies! I should have been more specific. My main concern now is collision with the ground, how to make the vehicle correctly copy the ground. Thats why I was writing about line tracing..

Anyway the article is interesting. I also watched the talk about Rocket League, very good small ideas in that one. Maybe simplifed physics is the right approach.

Still I would be interested to know, how is the movement done in 3D RTS games, when the units are going up and down hills or over obstacles. For example Company of Heroes.

A lot of RTS games almost ignore the 3D aspect, at least when it comes to movement and handling the map (ai/pathfinding/etc.). Steep slopes/cliffs are marked as unpassable tiles in some way (similar to water).

 

In that case, you might do movement as I described. Then just get the height for the units location, and the pitch and roll according to the slope (e.g. by taking the angle between the heights in tiles ahead, behind, and each side of the vehicle). If your using a heightmap, well then that is exactly the data you need, if it is a free form mesh/model, see what the engine provides. But it should be similar to how people, trees, buildings, etc. determine their height on the map / "collision detect".

This topic is closed to new replies.

Advertisement