Ok so I'm making pretty good progress with an RTS style game, even though some of the coding is a tad (ahem) inefficient. Found Sketchy's RTS movement example (the one with all the crazy calcs and neat coding) and would like to know if this could be expanded on with some pathfinding - preferably without using any of the PF extensions.
Also played the Terminal Orbit demo and noticed that the pathfinding in that used some kind of collision detection + angle/direction rotation. How is this done for so many units and so smoothly??
Best I can figure is (roughly):
+Always
--> set angle (calc for angle) of unit to target
+Always
--> (clickteam movement object) set direction to angle(unit)
+Collision with obstacle
--> set angle(unit) to angle(unit)+?
Alternatively, if anyone could please upload the Terminal Orbit source I would be most grateful, I'm dying for a chance to analyze the bejeezus out of this game! Otherwise I'll buy the Klikdisc with it but I'd rather not as I'm not really interested in the other stuff on it and I'm not even sure it still exists.
I know nothing about Terminal Orbit or how it was made, so can't really help with that.
The method you suggested could work for navigating around very simple obstacles, like an individual tree/rock for example - but you really need something far more sophisticated (probably an extension) to navigate around more complex obstacles, without getting stuck or taking a stupidly indirect route.
That's an interesting article, and he has some very nice example files there too.
In terms of simply getting units from A to B, it's not going to be any better than just using detectors to avoid obstacles - it's still not going to be able to handle anything more complex than small individual obstacles, and it will require a lot more calculations too (could get very slow with large numbers of units and obstacles).
The advantage is that units could seem to have greater awareness of their surroundings, and so might appear to behave more intelligently / realistically.
I'd say if in doubt, go with the simpler option first...
If you just want dumb AI, where the player has to babysit his units (this was actually pretty common with early RTS games) or if you're prepared to make your map design *very* simple, then either method would be okay (maybe just add waypoints as well).
If you want smart AI, where the player just has to tell units where to go, and they get there by themselves, then I think you absolutely must use a pathfinding extension - no other method will allow units to plan far enough ahead to avoid getting stuck.
Scenario:
1. Units are placed on one side of a mountain.
2. Player selects units and clicks (places target) on the other side of the mountain, exactly west of the units.
3. Units move to the target, and on collision with the mountain set their angle/direction + or - (still don't know how to pick) their current angle/direction. Having navigated around the mountain they set their heading towards the target.
Units don't have to plan, they just have to avoid the obstacle. Also, my map is too big for even the APF extension to handle (I think).
Using the method in my first post I've managed to get units to go around objects of 256x256 relatively well in a test, but still no dice when put into the actual game. Detectors are at this stage unfortunately not an option.
If you look at the TO demo this is done very well and it doesn't look like PF to me. Also in the tank example from my second post I can see how it could work for large obstacles - I've tried to simplify my code using those example files but the complexity of these (at least to me) is doing my head in.
If a simplified version of this to suit my needs could be done I would be ecstatic.
Great job, if this project ever sees the light of day you'll be the first credited. However now I have a problem - sometimes the units get stuck in a loop going around and around the obstacle until they receive another target, even if they are close to the one that was set. Any fixes?
(PS: got a copy of the Terminal Orbit source... looks like a similar method to Cameron's. Not complaining, this is more than perfect for what I have right now.)
not sure what your unit is doing, walking in a circle around the same obstacle? Some pics with info of the situation would help. But if the unit is walking a certain position over and over it might have something to do with the number pixels it's walking with. Because it can step over the target and then step back and step over the target once more while going back.
However I've no knowledge of your engine's internals, so I am just guessing what could be going on.
Pretty much the same internals as Sketchy's example above, same issue there so grab that. In the game, select a bunch of units and click on a point in between or just below some obstacles (make a block of them as a good test). You'll see one or two of the units just go round and round. Move target is computed based on angle/distance stored in alts, seems to work perfect unless the collision events are running (it seems).
@Sketchy,
Just want to mention I had to move the distance calc below the collision calcs in order to set a separate 'moving' animation as opposed to just the 'selected' one.
Units only stop when they get within 10 pixels of their destination. If there's an obstacle stopping them getting within 10 pixels, they will just keep walking.
You could always add a line to check if the unit is within 40(?) pixels, and getting further away - and if so, stop walking.
Units will also start walking around in circles if they encounter a concave obstacle, but that would require proper pathfinding to fix.
Set a flag for when the distance is first <40, then checked if flag was on and distance was >40. Unit goes merrily around ignoring his destination until another is set. Also, there can't be an obstacle other than the backdrop stopping him since he goes through them. Could it be the arrangement formula? Also could it be the stop calc is ignored if he's overlapping the obstacle? Check out your egx and let me know.
I'm starting to think this might not be the way forward though - it's going to be hard to stop units overlapping each other.
Maybe try moving them one at a time, in order of proximity to the destination, using ForEach loops?
Argh loops, well I had to do them anyway in my engine as I'm just using the base units as dummy objects (I need my actual units to keep their angle). Still weary of PF objects, my map is 6000x4000 so that might not be feasible just now
There are a couple of issues with that:
* Units always turn to face East after moving.
* Even on a wide open map, the units stop a long way short of where you tell them to go.
* Sometimes units just become unresponsive, and you have to click three or four times to get them to move.
I hope by "dummy objects" you don't mean that they're invisible, and you have another object set to their position? That's not only incredibly inefficient, but it also makes the coding far more complicated than it needs to be.
Re: pathfinding extensions -
6000 x 4000 isn't huge. It just depends on the number of units and the level of precision you need. You could base your map on a 100 x 100 pixel grid, which would be a very manageable 60 x 40 squares - you'd use a pathfinding extension to navigate between squares (moving from the centre of one square to the centre of the next), and then when they reach the destination square, you give them precise destination coordinates within it.
Ok, since you say it's more efficient than the current option I may give pathfinding a go, but still not giving up on this quite yet.
What would be better than invisible dummies? I want directions instead of angles - units have separate direction animations. I'm going to try the 'convert angle to direction' option, hopefully it doesn't tamper with the collision detection...
I'm not saying it would be more efficient - it would probably be slower. But, it would just work reliably, whatever the map design.
Instead of invisible dummies, just use the same object for both, but store current heading in an alterable value - then you can set the angle to that while checking for collisions, and back to 0 afterwards.
Advertisement
Post Reply
jenswa.neocities.org
