Map Division

Map Division

Maps are organized in three levels:

1. Game process — one process per logical map group (diagram: Continent). In data, maps are grouped by a host field. A home Game container (role: "home") loads maps that share its host ID. A cross Game container (role: "cross") loads all maps so match/instance play can run off the home world.
2. Continent — a set of related maps managed by the same Game process (map count varies).
3. Map — each map is divided into a sector grid for spatial queries.

Sectors

Sector cell size is 17 × 15 tiles (MAX_SCREEN_WIDTH × MAX_SCREEN_HEIGHT). The number of sectors depends on map dimensions (the diagram shows an example grid of 20 sectors).

When an object moves, it may change sector. Nearby-sector queries (nears) limit visibility and collision checks to adjacent cells, reducing search cost.

Routing between Game processes

Players are routed to the Game process for their map's host. Moving to a map on a different host triggers a transfer to another Game container. Matchmaking transfers send players to a live cross Game host instead of the map's home host.

Runtime instance maps

A source map (S) is the static map loaded from assets (model.id). Scripts can create independent instance maps (C) that share the same model (tiles, NPC/mob spawn tables, warps by model.id) but have a unique runtime map.id, their own objects, and a per-model slot index.

Topic	Behavior
Create	map:clone() / model:clone() (next free slot), or map:instance(n) / model:instance(n) (fixed slot)
Enter	Move with object:map(instance, …) (or admin /맵이동 <name> [x] [y] [slot])
Thread	Bound by runtime map.id (same modular rule as other maps)
Leave / destroy	Manual map:destroy(), or auto-destroy after the last character leaves once occupied
Save / login	Persist source model.id and restore onto S

See map builtins and model.map builtins.

Related pages

• Architecture
• Thread Model