CS2D 
Using settile in mass - reasonable?
1 
Offline
One of the pivotal features of this map would be that every area with monsters in it is dynamic and instanced, akin to PoE areas:
Dynamic: each area should have the ability to be procedurally generated or loaded from a file, independently from each other. Instanced: for every base area, multiple instances of it can exist simultaneously. Each instance would belong to the player that created it, and would contain its own monsters/items/modifiers, independently from other instances. Players would be given the ability to join an older instance or create a new one when accessing a different area.Town areas would NOT be instance-able, and are shared by everyone. From these you would be able to enter instance-able area with monsters.
The main issue is the instances system, given that map space is limited and hopping around different servers for each instance sounds completely unreasonable.
The idea I had is to have a dedicated region for each potential player (say, a 40x40 tiles square for each), so, if the server can have up to 20 players, then 20 of these regions would be distributed around the map area.
When an instance gets created for a certain player, the region associated to them would create the area they're about to enter (via proc. gen or file loading), then every tile in this region would change to whatever has been generated in the script, through the use of settile. Once the area has been set and monsters dropped, the player would then get teleported to this area.
EDIT: here's an explanation of PoE's instances system, which I think is more clear (most, if not all, of the functionality described here would also be implemented in this map):
From a performance and bandwidth perspective, is it reasonable to use settile massively this way? (Considering up to 1600 tiles might get changed at a time, going with 40x40 regions). Would it become a problem if a player went back and forth, re-creating areas and spamming settile calls? (Measures such as a cooldown could prevent this).
Pagyra