Once again, i head to the forum to get my questions answered.
Im facing an issue regarding processing some CPU intense work on the server. Im developing a server for an MMORPG, and im trying to figure out how nakamas framwork works regarding this area.
The server handles all players actions, but it also handles a lot of logic using timers (Timers is just a struct that has fires an event once finished - ticked by match loop). For instance NPCs movement. The server processes an npc movement along a path and updates it every x ms depending on npcs movement speed. The path is calculated with a*star and is updated every second if the player is moving.
This works great, with a few npcs. But when the player activates more than lets say 10 NPC and makes them following the player, the server servers seems to not be able to catch up. This results in some weird results, the mobs are moving moving to a tile - waits for a second or so - and moves to the next tile etc. This is an indicator for me that the server having trouble to handle multiple a*stars at the same time.
So my question here is:
What does happend if the running logic takes more time than one tickrate? This logic is not triggered by a player per say, this is just the server that fires a path event if a player is within a certain area of the NPC.
Follow up question:
How would one handle such cases in the nakama framework? If 100 players are targeted by 2 NPCs at the same time. This is 200 paths that needs to be calculated.
All events processing and future match loop calls get delayed. If it itakes too long, then server reaction delay to new inputs becomes too noticeable for players. You’d want to avoid spending too much time in match loop function to avoid that.
As usual with any time sensitive calculations it boils down to computing faster or computing less.
In case of NPC pathfinding you could try to compute path less frequent than every tick, for instance computing it more often the closer NPC is to the player. It might be possible to switch from path finding algorithm to direct approach along line of sight once NPC is close enough.
Ok, thanks for the reply. So there is no general rule how to approach such cases i guess. I noticed i wasnt clear in my question earlier. Im calculating the path once and then the mob moves along that path. The path gets recalculated if player move one tile or debounces it one second if the player is faster than one tile per second. So the path is not calculated every tick, minimum 1 second between calculations.
One would think this would work and not be to heavy on the performance. Might have a look and see if there is some optimizations that could be done in the path finding code. Else im screwed
So i did some more investigations and found that one path calculation took between 1-5ms.
Assuming i have a tickrate of 10 this gives each tick 1000/10=100 ms to execute.
So theoretically the server could handle a maximum of 100 mobs searching for a path each tick. More realistic around 30-40 mobs.
Maybe this is not so bad after all because the odds of each mob hitting this event on the same tick is not that high.
Does anyone know if 1-5ms for an a*star search if good enough, or can this be optimizaed even further? @yamlcoder
You can calculate the path in another goroutine and add the result in a object. Matchloop just read the object and update match status. Make sure you use locker
@tunglt1810 Maybe im wrong here but I’ve read on some places that its not recommended to use goroutines in the nakama framework. Maybe someone can confirm this?
