So I had this possibly ill-advised idea of creating an application that allows for multiple instances of games to be run within it, with a portal with multiple rooms from which to launch a game instance. So far so good but the thought has occurred to me that running on a single thread there is always the potential for the server take too long running code for one game which ends up causing stalls on the others.
My knowledge is limited on multi-threading but what would be the best option to avoid this. I could find potential long-running functions and put them in their own thread, or would it be better to have each game instance in its own thread?
Another question is are multiplayer solutions usually tolerant to multi-threading, I’ve created the application using Netcode for GameObjects.
In case it helps the game is turn-based and mainly event driven so not time critical.
Multi threading has to be done right to not potentially affect the players experience.
Realistically the socket can be on a different thread no problem. Most networking solutions already thread the socket, I imagine …
The tricky part is deciding what can be threaded. You cannot easily thread serialization of datas for example over multiple threads without risking one finishing before the other. In such a scenario you will have out of order data which would be pretty bad. You could wait for all threads to finish then process them in the expected order but if you’re using a tick based stack there’s a fair chance the threading will finish after the tick, and that could cause some gross de-synchronizations.
Things which do not have to be in order and can be received late should be safe to thread. Eg: let’s say the server has a timer to update which players are targeted by enemies. You probably don’t need to run this on the main thread, slop in this area should be completely okay.
1 Like
Thanks Punfish, I’m hoping I can lean on the latter as the former sounds a bit complicated for my liking.
The part in the game that stands out as a potential issue is that after the players take their turns the computer players get to move and this could take some time to complete. I guess I’m just going to have to do some research to decide whether just multi-threading bottlenecks or the whole game instance is the best way to go.
I should probably check that NGO is okay with multi-threading while I’m at it.
It sounds like your game won’t be fast paced, and the potential of having something run a few ms slower on the server won’t matter. Honestly, seems to be a perfect opportunity to thread.
1 Like
The more I think about it the more having each game on its own thread does make sense.
Thinking about the computer turns something that’s crossed my mind and that’s getting more appealing is that due to the human players taking their turns simultaneously I could have the computer players take their turns at the same time. If nothing else it would be interesting to implement and a good way of keeping my brain engaged.
Based on your title, the easiest way to multi thread multiple instances it to launch one MyServer.exe per instance.
Unity is not thread safe, attempting to access / modify entity data from other threads is unsafe.
1 Like
I’m already a long way down the road but I will keep your advice in mind if I ever try this again (or fail abysmally with this one).
I know we talked about this more privately but I wanted to put this information out for anyone else that may stumble upon this thread(pun intended) later.
You can safely thread in Unity. Certain components might be locked from threading, eg transform properties, but there is absolutely nothing stopping you from accessing data types or custom logic on another thread.
Eg: if you want to calculate something intensive you can thread the calculation and just access the result on the main thread.
I’m not going to go into details on how to thread because there’s an extensive amount of information available for this on the web. But the take away is, yes you can thread in Unity and it’s very much the same as threading in any other application.
1 Like