I'd say in gaming, multi-threading would only make sense for when you are NOT reading or modifying live game objects. So

* Pathfinding
* Map generation
* Dabatase
* Packet statistic analysis
* Logging

I am taking out ConcurrentDictionary as it's weight we don't really need.... Trying to avoid locking mechanisms overall.

I use multithreading for things like login (accounts are global and not per-server, so it's a remote call), and for loading maps quickly, and at some point I will use it for pathfinding, but I would never use multithreading for the main server loop.

People may disagree, but to me, multithreading in the main server loop would be a source of endless problems for minimal gain.

CPUs are quite fast, and in an RPG, most actions are very simple:
- "Move item from A to B" is memory copy + zero the old memory.
- "Attack monster A" is just a bit of math (and perhaps a script call).
- etc
Multithreading makes sense where actions are heavyweight, and I don't know what actions those would be.

Hard to say. We basically never run into the monster limit. You can only fight so many monsters. My interest is mostly so I can have more/smaller maps.

Yeah the "running out of IDs" on other server predictably led to not targetable monsters, disappearing NPCs and so forth in early woes on the other one.

I believe the fix was to use a better data structure (ConcurrentDictionary<int, NPCMonster> vs an ArrayList<MonsterId (int)> and confirm existence per map when necessary. The issue was IDs were being reused when not necessary (spawned monster should just always use their database NPCID serial) and summons/tamed can use the flexible list, when they die, player logs out or leave map rehydrate the map list accordingly.

That and to use Lock/SemaphoreSlim in the Map class' GetFreeNPCId() function...

The server keeps track of monsters in a static two-dimensional array (map, monster number).
It does this because when I first started it, I didn't know you could allocate memory in Visual Basic. Still at this point, it uses fairly little memory allocation.
It's specific to the server. The client does not use it.

Yeah ours did much the same. Each map had a dictionary with key = npc_id (1 to 8192 client id and DB serial for spawn mobs) and data of mob data. On leave or die remove, on spawn/enter add. Runs into issues early on when summons ate up a lot of IDs since 8192 seems client max. It is sorta smart to just have a global collection for monsters disassociated from a map tbh.

You shouldn't notice this unless there I introduced any bugs with this, but if you see any quest bugs, etc., definitely let me know. Thank you!

God bless.

James