Jump to content
  • Advertisement
Sign in to follow this  
polyfrag

RTS lockstep multithreaded pathfinding

This topic is 2264 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Advertisement
If the synchronous, predictable, single threaded version looks like:
Path* result = FindPath(data);
ai->UsePath( result );
Then the asynchronous, predictable, multi-core version usually looks like:
Future<Path*> result = FindPath(data);
... Do as much other work as possible ...
result->WaitUntilComplete();
ai->UsePath( result->GetData() );
The fact that multiple threads are used is an irrelevant detail from an external point of view. You can't have different clients returning results on different frames, because the wait statement synchronizes the threads within a single frame.

Internally, the FindPath function is pushing work into a queue that a thread pool consumes, the wait function stalls until that particular work item has been completed, and the get function fetches the return. Alive that was produced by the worker thread.

Well designed multi-core code of this kind should always behave exactly the same as the single-threaded implementation, with the only difference being that you get better performance if the user has more cores.

Share this post


Link to post
Share on other sites

I'll move/update all the units before assigning pathfinding jobs to worker threads because the paths depend on unit positions (avoidance of other units). Then when all the worker threads are finished game state can be advanced one frame. While worker threads work, main thread will render and listen to events.

 

How would I do physics though? The result of physics for one object depends on other objects and the overall result depends on the order of processing of objects, so it has to be the same order for all clients. And physics is heavy.

 

I'd still make the path finding operation predictable (will find a result in exactly n frames) in a multi-core implementation.

 

I don't know how I could predict that or what for except to divide up the work evenly.

Edited by polyfrag

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!