10 replies to this topic

[The Scorpion]

Ok, I'm making a 3d RTS game and when it comes to collision I use p3dc (v 2.0 , the only version bug free )

My problems is units movement :
How to make them reach the destination, considering other solid entities (buildings,trees, other units)
I am currntly using p3dc collision system demonstrated in its examples!
But you can imagine it gets heavyyy !

and I am trying to ovoid paths and 2D collision, cause paths, once generated are static, but the world is not! so it can pass throught new created buildings or moving units! and I am already using P3DC; I dont want to use an other collsion system.

So it must be step by step movement and 3d.
Help needed! So far the unit move straight to target, and collide smoothly with walls, but that does not guarantie reaching the destination,
and units do not look for alternative paths.

What about water ? How to surround it ? I am really stuck ! Help needed

[Gamer3D]

and I am trying to ovoid paths and 2D collision, cause paths, once generated are static, but the world is not! so it can pass throught new created buildings or moving units! and I am already using P3DC; I dont want to use an other collsion system.

The big question here is whether you're doing a full 3D RTS (Homeworld is a good example of this) or a 2D RTS with 3D graphics.

If you're making a 2D RTS with 3D graphics, it's best (But not necessary) to use 2D collisions. Dropping an unused dimension can GREATLY decrease the cost of testing collisions.
For pathfinding in 2D, I'd recommend using the built-in motion planning functions; if a unit following the path encounters a static obstacle (building), re-calculate the path. If it encounters a moving obstacle (Unit), move to the right, then back to the path when possible.

What about water ? How to surround it ? I am really stuck ! Help needed

You are must learning to English.
But in all seriousness, I have no idea what you're asking for here. Surround it with what?

[slayer 64]

rts games are hard to make

[The Scorpion]

The big question here is whether you're doing a full 3D RTS (Homeworld is a good example of this) or a 2D RTS with 3D graphics.

If you're making a 2D RTS with 3D graphics, it's best (But not necessary) to use 2D collisions. Dropping an unused dimension can GREATLY decrease the cost of testing collisions.
For pathfinding in 2D, I'd recommend using the built-in motion planning functions; if a unit following the path encounters a static obstacle (building), re-calculate the path. If it encounters a moving obstacle (Unit), move to the right, then back to the path when possible.

I guess I'll stick with 2D collision then :D You jumped directly on the solution, thx

You are must learning to English.
But in all seriousness, I have no idea what you're asking for here. Surround it with what?

LOL sorry, I meant how to walk around the water (sea) to reach the other side.
I think I'll pass the water idea, and stick with Terrestrial map and sea map!
I am having great Ideas with this game I want to achieve. But with this work, it will take eternity to end !

Any way, I think I'll use

mp_potential_step(...)

It's the most appropriate function for this

rts games are hard to make

Thank you for the tip ! I haven't notice you are totally correct! Why can't I stick with simple TETRIS game



EDIT :

Ok, mp_potential_step() is not that efficient! It does not guarantie reaching the target. Same with mp_potential_path().

What should I do ?

Edited by The Scorpion, 28 June 2012 - 11:48 AM.

[Gamer3D]

Use the mp_grid system. It's GM's default A* implementation, so it'll find a path if one exists.

[The Scorpion]

Use the mp_grid system. It's GM's default A* implementation, so it'll find a path if one exists.

Works like a charm ^^ thank you

[Terrified Virus]

rts games are hard to make

Was there any point to this comment? lol

[slayer 64]

Was there any point to this comment? lol

Was there any point to this comment? lol

[The Scorpion]

Ok, I rejected the mp_grid* system and used mp_potential* system; for reasons explained above, (and most of all, path should be updated each step, so the system will recalculate it again and again each step, and I can't bare fps fall )

I've set

mp_potential_settings(70,15,8,0)

Here is the function explained to save your time (just copy/past from the help file ) :

mp_potential_settings(maxrot,rotstep,ahead,onspot) The previous function does its work using a number of parameters that can be changed using this function. Globally the method works as follows. It first tries to move straight towards the goal. It looks a number of steps ahead which can be set with the parameter ahead (default 3). Reducing this value means that the instance will start changing direction later. Increasing it means it will start changing direction earlier. If this check leads to a collision it starts looking at directions more to the left and to the right of the best direction. It does this in steps of size rotstep (default 10). Reducing this gives the instance more movement possibilities but will be slower. The parameter maxrot is a bit more difficult to explain. The instance has a current direction. maxrot (default 30) indicates how much it is allowed to change its current direction in a step. So even if it can move e.g. straight to the goal it will only do so if it does not violate this maximal change of direction. If you make maxrot large the instance can change a lot in each step. This will make it easier to find a short path but the path will be uglier. If you make the value smaller the path will be smoother but it might take longer detours (and sometimes even fail to find the goal). When no step can be made the behavior depends on the value of the parameter onspot. If onspot is true (the default value), the instance will rotate on its spot by the amount indicated with maxrot. If it is false it will not move at all. Setting it to false is useful for e.g. cars but reduces the chance of finding a path.

It works just fine, and the unit can go up to 100 pixels away, looking for alternative path (units size 2*2)
But, sometimes it get stuck when it faces a wall in front of it and to its right.

Can someone figurate out the best combination for this function. Help appreciated.

Edit : typo

Edited by The Scorpion, 02 July 2012 - 12:37 AM.

[Gamer3D]

Ok, I rejected the mp_grid* system and used mp_potential* system; for reasons explained above, (and most of all, path should be updated each step, so the system will recalculate it again and again each step, and I can't bare fps fall )
-SNIP-
Can someone figurate out the best combination for this function. Help appreciated.

Clearly, you have misinterpreted my suggestion. Calculate the main path ONCE. If the main path is blocked by an immobile object, recalculate it (This recalculation can be done on building placement, or only when a unit hits a building). If the path is blocked by a MOVING object, then you use local pathfinding techniques (eg mp_potential_step) to move around it and back to the main path.

For speed, you can calculate main paths for groups of units, or calculate just one path per step (no matter how many objects request a path).

[The Scorpion]

....

Ok, I now understand your solution. Thank you for everything Gamer3D ^^