Running a game system in a different thread [SiO2]

General Discussion
1

Hi

I am using SiO2 GameSystem and GameSystemManager to simulate game systems server side. I am planning to move my pathfinding system into its own thread.

For this purpose am I supposed to create a separate GameSystemManager and GameLoop instance for running the pathfinding system on its own thread or should I do the threading stuff inside the pathfinding system itself?
Thanks in advance

2

Without knowing more about how your pathfinding system will interact with the rest of your systems, I’m guessing it will be a system in the main GameSystemManager that manages its own threading.

For example, if it has a pool of threads it could start those threads up during init/start and make sure to shut them down in terminate/stop. Each update() it could process any results from a concurrent linked queue and do whatever processing to decide new requests… or perhaps other systems submit pathfinding jobs to it and get called back later.

…perhaps it’s just a thin wrapper around a WorkerPool (I actually thought I’d already made WorkerPool a GameSystem so that was a surprise but the principle is the same). Other systems could submit path finding requests with a callback and then the path finding system would spin off jobs where the runOnUpdate would run the callback with the found path.

1 Like
3

I see, thanks so much for the help. :slightly_smiling_face:

I assume a WorkerPool with size 1 will create just one thread and will always use that same thread for running all background jobs, right?

4

Correct.

Is the thing your pathfinding will be querying thread safe?

Depending on whether it is/isn’t and how complicated syncing will be, perhaps the pathfinding could be done on the update thread but just a fixed number of iterations at a time.

1 Like
5

I am using a third-party pathfinding library so I am not sure if it is safe to call the findPath() method asynchronously from multiple threads. There is a NavigationSpace that I can dynamically add obstacles to it and it will generate the nav mesh internally. So to be safe I want to have just one worker thread that is supposed to call the navSpace.findPath() method on it.

6

vs

An entity with PathRequest(startLocation, endLocation) component and after the path is found, then the pathfinding system would add a PathInfo(waypointList) component.

Isn’t the latter more appropriate in ES terminology because it cuts the direct connection between other systems and the pathfinding system? I am interested to know your opinion.

7

It just depends on whether a path is a game object or not. It could go either way depending on need.

…but a “path request” component still feels kind of weird to me. Some game logic code decided it needed a path as part of its logic. It seems no different to me to call another system to request the path (which might later come as an entity or whatever) than it would be to call some utility to create the path request entity.

I could see arguments for even the request being a game object. It just depends.

Edit: put another way, what if you had a method somewhere to create a path entity. It would create that entity and other systems would see it. Whether that method is creating that path right then or creating it later as a result of a background thread call, doesn’t seem to make much difference to the calling code to me.

1 Like