It's probably important to note that you'd be giving responsibility for Z levels to different servers, and then using already known transition fading tricks to make it seem more like one big map.

Alathon explored this concept in general, with some support from me. Your main issue is the interface, as when you link() people between worlds it starts up the interface from scratch, basically setting up the default position, size, slider positions etc. I think he passed the information through on the link(), but it wasn't pretty and his test interface wasn't exactly complex either. In his tests, that tended to flicker quite a bit even if you could preserve the positional information.

There are other concerns, mostly about visibility of players across servers (global chat over Export() with hundreds of players isn't very appealing) for any function you need it for. Essentially you'd probably end up making dummy relay datums for players in other servers, to hide the logic of needing to Export() a message or request on. You can get around this quite well with a DLL, but it complicates the hosting environment.

I know there are some differing opinions on this, but our conclusion is that distributing a world semi-seamlessly is not currently feasible on BYOND.

I think he meant 3000x3000 total space, ie. 9,000,000 tiles

Actually, you can use world.maxx and world.maxy to set the world dimensions higher than 1000x1000. Beware, though! Setting this to a high number will bloat the memory usage of Dream Maker and Dream Seeker greatly!

Example:

Necro time!

This could be mitigated by a topic string and some interface wizardry.

When the user is linked(), it saves the interface elements' positions and what-not, then uses a topic that tells the world to pop up a full screen loading splash screen. There'd be some flicker, but the only other way I could think to handle this would be to somehow open another BYOND world in a new window, and porgrammatically bring it to the top. I'm not sure the second method could be done.

[edit] I put two requests in the feature request tracker on the subject. This would be convenient if the developer were able to open a second seeker in the background, then setting one of the servers to the master server, and the rest to the slaves (within the same hub entry ONLY! And with some sort of session authentication), would combine the online user data of the four live games in the hub entry into the master server's listing, and redirect initial logins (I.E. anything without a specific internal topic) to the master server only.