MMORPG Entitiy handling on different maps

Question

Is this a good approach for a MMORPG entity handling on different maps?

---

Map Structure and entity existece:

A map is basically a parent node in a scene graph. There's one map for each town, room etc. In each of these maps the entities or actors (split up into localplayer/NPC/remoteplayer) exist with their own coordinates in respect to map size. Each map has it's own position in worldmap, it's id and it's own update() method which calls update() on each entity.

---

Server:

Server has 2 Hashmaps with key being map_Id and value being according map reference. One is a pool for every map possible, the other one is currently active (or populated) maps. Also an eventqueue is available containing 2 queues, one for current events and one for new events resulting from current event processing. Events are collected in between ticks by a event fetcher thread accepting incoming events from remote (inbox) and are distributed by a extra event distributor thread (outbox).

Each tick/render server processes the eventqueue and given a actorupdate event calls update() on each affected map (calling update() on every entity). Before/while this processing happens each relevant event in inbox is being distributed to each relevant client. Relevant means the event is of interest to the particular client (e.g. events concerning actors on map1, each client on map1 is then relevant) and the event was not sent by receiver client itself. Each n-ticks sanity check is sent to all clients.

---

Client

Client stores current map and possible new map preloaded in reference (if player is in transition zone). Events are processed similar to server but include local only events like AnimationStarted and a event fetcher thread saves all incoming events from server in an inbox.

Each tick the inbox is being put in local current eventqueue, local built server relevant events like ActorMove are being send to the server and all events are being processed just like server does with 2 queues putting new queue into current queue etc. Regardless of own latency client will at some point in time have the sanity check in inbox and must process it.

---

Answer 1

TLDR: To answer your question, if implemented properly, this does work to a certain degree.

I'm using almost exactly the same system for my multiplayer rpg. Entities are part of a hashmap of objects contained within the "World" and each is also in a hashmap within each "Zone." I can call zone.getEntity(ID) or world.getEntity(ID) or zone.sendToAllEntities or world.sendToAllEntities.

This allows for relative locations within the world and zones are relative to each other. Zones could overlap or have large amounts of space between their "locations" but the players would never know this because zones are connected to other zones and not the world.

In each update tick on the server, the world calls foreach zone.update, which calls foreach entity.update, and on the client side, the client will call myzone.update -> foreach entity.update (for client prediction) and myzone.render -> foreach entity.render

As "zones" are needed, they are loaded from file and stored in a hashmap if they aren't used within 20-30 minutes, the zone is unloaded (and saved, along with all of the zone's objects).

I'm not so sure this would work in a "massive" situation, as I've only tested with ~50 clients, but I'm sure batches of zones could be run in their own server instance with the proper implementation.

Please excuse my long-drawn out rambling, as I'm sure it seems I've done and feel free to ask any further questions you might have.