How to model unit movement in RTS game?

[secondwtq]

Hello,

I'm working on a RTS game engine, for what I want to achieve, I could say that it's just like Red Alert or C&C.

There would be a number of units with different types, infantrys, tanks, trucks, aircrafts, ships etc. At the beginning let's deal with land vehicles only. And as a modern engine I integrated Bullet physics deeply inside.

I heard that most RTS engines does not employ any physics engine, while few ones like Company of Heroes (personally I donot recognize it as a "RTS", but I really like it and it's physics is very nice) and World in Conflict (which I only have few experience yet) being some exceptions. But I think just do it and it would be OK. C&C series has no physics and things looks very unnatural: large units overlapping each other, some projectiles also have weird trajector, and so on and so on. I also heard that StarCraft 2 uses Havok, but anyway, I'm very satisfied with SC2 experience.

Back to the topic: I'm stucked on unit movement. I'm done with global path planning(A*) months ago. But I found it's pretty hard to make unit(vehicles, specifically) follow my path with physics measures. I rewrote its code for several times but all failed. That's what I have now:

* Graphics is 2D, isometric.
* So pretty much CPU time for physics simulation, and does not require much detail.
* Every vehicle is just a Box.
* Every obstacle (buildings, stones, trees) is just a Box, too.
* Terrain is btBvhTriangleMeshShape, somewhere is explicitly unreachable (mountains), but may have slopes and pits.
* For parameters, each vehicle just has a maximum speed (aka. stable speed when marching), an acceleration rate, and a turn rate. Doesnot need accurate simulation, just to distinguish between different units (eg. motorcycle is very flexible, while heavy tanks slow and cumbersome). If possible, I wish its turn radius also controllable.

For what I have tried:

Approach 1: I just used a box for units, place it upon the terrain, and apply it a
traction force, and a rotation force.

One of the biggest defects of this approach is that, it works on plane, but fails to deal with terrain bumps. Say we have the following situations:



Both case it would just be stucked, but I want it able to handle small bumps, climbing small slopes.

Approach 2: Then I tried "real" vehicle, specifically the btRaycastVehicle and vehicles with btHinge2Constraint and cylinders as wheels.

I found that car physics behind the vehicle module is pretty complex and not exactly what I want. I donot need suspension, accurate control on wheels, etc., just too many unnecessary mechanics for me, and they finally became a heavy burden. And it's very very hard to control a car smoothly and intelligently with engine force, wheel steering and braking.

Moreover, turing is particularly a serious problem. Sometimes it turns too slow, sometimes the turn radius is too large for the map. Ideally if a unit takes approximately one 'cell' area, then for it to turn 180 degree it should just go through 2-3 cells. But it actually travels half of the entire map. (For btRaycastVehicle, higher wheel friction helps a little, while you got the car completely turned over after turing).



I also searched about character controllers, but I don't know much about what it is exactly for, and most physics engines only provides kinematic character controllers while I want a dynamic one. It is interesting that vehicles and character controllers are all good for manually controling inside FPS as the player, but maybe not very good for automatic control. So now I have no idea about it.

Do you have some ideas? I'm sorry for the post being so long, but any help is appreciated.

[Basroil]

For planar RTS, I don't think bullet would be the easiest approach. Even if your camera is 3d, the unit movement is essentially 2D, and you might as well ignore physics entirely. Instead focus on unit-unit collisions (maybe box2d for really simple experiments or bullet if you want 3d shape based overlaps), unit-wall collisions (a wall is anything that impedes movement in a direction), and general animation. That is of course, if you don't already have a cost function for your unit's next action. If you already have your cost function (from A*/D*/ other), you shouldn't really need additional physics for motion, since a cost map should invalidate areas in collision.

[secondwtq]

For planar RTS, I don't think bullet would be the easiest approach. Even if your camera is 3d, the unit movement is essentially 2D, and you might as well ignore physics entirely. Instead focus on unit-unit collisions (maybe box2d for really simple experiments or bullet if you want 3d shape based overlaps), unit-wall collisions (a wall is anything that impedes movement in a direction), and general animation. That is of course, if you don't already have a cost function for your unit's next action. If you already have your cost function (from A*/D*/ other), you shouldn't really need additional physics for motion, since a cost map should invalidate areas in collision.

Thanks for your concern.

For my case, it's not 'planar'. On the contrary, it's only the rendering of units is mostly done with 2D. But the game world is modelled as a 3D space. There are hovercrafts, different type of projectiles, aircrafts of various heights, and the terrain is 3D model too. If the world is roughly planar, maybe I could just use JavaScript with Box2D on browser, it's far more simpler that doing everything from scratch.

You're right, for RTS, Bullet would not be as useful as that in other games, and also requires lots of work. Also however for most units, their movement is basically planar, too, but the cost heuristic is just something for "global" path planning, that is, work out a potential path according to terrain and building placement, it doesn't and can't resolve it once for all.

I'm not a pro in physics (that's why I'm looking for help here) and I prefer to delegate as much work to Bullet as possible, it's fast, reliable, and the result is natural. However it's also hard to be in control, but once you succeed its benefit is remarkable, the whole world state is consistent, entirely physical. That's what I think initially. Being 3D is not the reason why utilizing physics, RTS games could work without any physics, but I want to make some small difference .

[Basroil]

For my case, it's not 'planar'. On the contrary, it's only the rendering of units is mostly done with 2D. But the game world is modelled as a 3D space. There are hovercrafts, different type of projectiles, aircrafts of various heights, and the terrain is 3D model too.

Just trying to clarify for others (and myself), are you actually using true 3D movement (3 axis of motion, 3 axis of rotation), "2.5D" movement (only one axis of rotation planar with the ground plane, and collisions include z factor), or multiple stacked 2D motion (discrete separation of units by Z axis)?

You mentioned starcraft before, and just for comparison, that game is actually just 2D motion with collisions based on a discrete z component (air can collide with air, ground can collide with ground, and some units can span both like the colossus, but collision shapes and animation shapes are completely unlinked outside position and orientation). Collisions are kept as simple as possible within each component, since with good pathing you shouldn't be seeing too many collisions (you'll have to ask someone more knowledgeable in SCII engine for specifics, but http://gdcvault.com/play/1014514/AI-Navigation-It-s-Not is a great start). Physics on the other hand is non-existant, and everything is controlled kinematic (though emulating physical reactions is certainly possible)

[secondwtq]

Just trying to clarify for others (and myself), are you actually using true 3D movement (3 axis of motion, 3 axis of rotation), "2.5D" movement (only one axis of rotation planar with the ground plane, and collisions include z factor), or multiple stacked 2D motion (discrete separation of units by Z axis)?

For the question, it's about the positioning of a certain project. To fully describe the scenario it will be lots of things to say, but I'll try to keep it short:

I'm always concerning about flexibility and extensibility. It's not something dedicated for some game(s), but a toy framework in which one can create everything he can imagine (maybe just for fun ). Obviously it's not a practical idea, such a software just doesn't exist. I'll also not going to seeking my own doom, but I try my best to make it more flexible.

So there is no answer to "what it exactly is". We can only cover most of use cases and for this, it's basically just like Starcraft 2, and in this thread I'm mainly talking about ground vehicles. Though maybe someday I suddenly want to simulate a space war with ships moving and rotating freely, for now, just ignore it.

You mentioned starcraft before, and just for comparison, that game is actually just 2D motion with collisions based on a discrete z component (air can collide with air, ground can collide with ground, and some units can span both like the colossus, but collision shapes and animation shapes are completely unlinked outside position and orientation).

Now I have realized that, movement of RTS can't be perfect, but Starcraft 2 did do it very nice and smoothly (still not perfect). However, there is some difference. For details: AFAIK the terrain of Starcraft is just like a "platformer", that is, terrain is made up with some "plane"s, with several "slopes" connecting them like tunnel. Most of the terrain is just planar, no any up and down.

And most of units seems like circles with different radius, that's fine in SC2 because the models (or design of unit appearance) just fit it (most of buildings is nearly square, or round). But problems arise for more general cases such as train, large trucks, battleships. However, I'm still going to use this "circle model" for pathfinding, since it's easy to implement, debug, and long obstacles can be simulated by multiple circles. For collision, I think box is pretty good. Just like this:

Collisions are kept as simple as possible within each component, since with good pathing you shouldn't be seeing too many collisions (you'll have to ask someone more knowledgeable in SCII engine for specifics, but http://gdcvault.com/play/1014514/AI-Navigation-It-s-Not is a great start). Physics on the other hand is non-existant, and everything is controlled kinematic (though emulating physical reactions is certainly possible)

Great video! I'll watch it in detail later.

"Good pathing" is not easier than automatic movement with physics at all. I believe the team of Starcraft (as well as some other great RTS games) must had been tweaking around it for a looong time. For a crowd of units of different speed, walking inside environment with trees, buildings scattered around, is it possible to keep them no collision? Not really. And for real time path planning of lots of objects, performance is as important as quality of result.

Also, since the terrain has up and downs, units must be able to handle them. So the heading vector of units would not always be parallel with the sea level, ground is not always a plane, rotation is not exactly limited. And 3D support for units is very likely to be added, and then transform can be fully bound with physics shape.

In a word, kinematic control has no problem in Starcraft because SC2 has a clear range for what it would do and does not enforce flexibility. Say I want a rocket hitting a driving pickup truck blow it to the sky then fall to ground upside down (like what you'll see in some FPS), also shaking light vehicles around, and do it kinematically? Why? Bullet can do it for me