4
\$\begingroup\$

I'm thinking about writing my own RTS game and while I'm more or less clear about how the game engine should work, I need some directions as to how to implement physics and collision detection.

Now, I am an experienced programmer but I have never ever done game dev before, so please excuse me my poor/incorrect terminology.

There will be a large 3D (i.e. planes, hills, valley, etc) world with lots of units, moving and/or fighting simultaneously and lots of projectiles flying around. So the most important thing is, physics and collision computation must be very fast.

Could you please point me in the right direction? Idea I'm elaborating on is some kind of 3D tiles, with every unit's position being x,y index of tile + elevation (e.g unit staning on the hill or on the fortress wall). the smallest unit will occupy for examle one tile horizonally and 5 vertically. With every tile having 3x3x1 aspect ratio (e.g. 15x15 horizontally and 5 pixels height).

How realistic is this? How would you approach this? Are there any 3d physics/collision engines which are fast enough for such application?

Hope for your help Alex

\$\endgroup\$
4
  • \$\begingroup\$ Is this game targeted at mobile consumers? Practically, the Bullet Physics Engine is good enough if you use it efficiently (no complicated physics meshes). \$\endgroup\$
    – teodron
    Commented Jul 20, 2012 at 16:42
  • \$\begingroup\$ No, it's for desktop computers (Windows, MacOS X, Linux). I read about Bullet, but it seems a bit of overkill? How efficient it will be with say 10000 units and yet more projectiles? \$\endgroup\$
    – aleguna
    Commented Jul 20, 2012 at 16:43
  • \$\begingroup\$ @aleguna: In general, projectiles don't need collisions. A projectile, once fired, is going to hit its target. It's simply a matter of when it gets close enough. \$\endgroup\$ Commented Jul 20, 2012 at 17:13
  • \$\begingroup\$ @NicolBolas That's up to him though, isn't it? If something else moves in front of the projectile, personally I would prefer the projectile to hit that instead of just passing through. aleguna: nvidia's physx SDK (binary, no source) is free for use on windows, linux, mac and ps3. It runs just fine on the CPU, some of the nvidia demos have ~40.000 debris particles colliding with a non-trivial ground and bouncing. So simple projectile collisions, if you use built-in optimized primitive collision shapes(say capsules for projectiles, boxes for units), should work fine on the CPU. \$\endgroup\$
    – user13213
    Commented Jul 20, 2012 at 17:34

1 Answer 1

8
\$\begingroup\$

The main thing to remember when dealing with an RTS game is that collision detection isn’t the same kind of animal it is in a FPS. The game, not the player, determines if a unit actually hits its target, so you’re not worrying about things like "If a shot goes between his legs, how do we know it didn’t hit him?" but rather "we decided that he hit him, so make the shot look like it hit him." Units attacking one another usually amounts to "Is the unit in range? Does it have line of sight? Okay, animate the attack and calculate damage." Most RTS games don’t even taken into account a "chance to hit" all attacks hit, and damage is random within some range which expresses the idea of "how on target" the shot was. This means that for combat you’re usually just considering ray-polygon intersections to check that the units have line of sight. This can be performed against a very simplified version of the map geometry using bounding boxes (A single box for each unit if you want them to be included, rough outline of the terrain and map elements). There are a huge number of tutorials on this, just search for Ray-Box Intersection, Ray-Polygon Intersection and Bounding Box Collision Detection to find out more.

Movement in RTS is generally the more complicated bit, for the same reason combat is simpler. The game, not the player, has to navigate the terrain. Generally this is accomplished by creating a kind of "map of the map" which defines areas as passable, impassable, (and possibly shoot-through-able or not which can be used to further simplify line of site determinations). This map is then used to plot paths for the units. Google Navigation Mesh for details on how the “map of the map” is constructed. Google Pathfinding for more details on how to calculate and plot paths. Dijkstra's Algorithm and A* are two common pathfinding algorithms. Pathfinding is a part of the mathematics field known as Graph Theory if you’re interesting in reading up on the topic more broadly.

As for physics, except in AAA titles there usually isn’t much real physics implemented beyond basic velocity/acceleration calculations for movement. You can store values in the passable areas of the map to indicate high and slow the unit’s velocity when they are moving from low to high terrain, or through special terrain. When units are damaged they are playing a hard-coded animation of “being flung through the air” or “tossed aside” etc, based on the outcomes of the combat calculations.

If you have any specific questions just let me know.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .