Though this could work to an extent with smaller maps, as the player continued walking in any direction, the server would have to load more and more custom map. Each player would need a z level with an entire map.
You could override movement so that it moves the map around the player, instead of the player around the map. (If that makes sense.)
It wouldn't be very fast, though, and you'd have to turn off sliding movement or things would start looking weird.
Exactly. That's why I'm looking into parent/child world relationships. Each client running a child world on their own machine would allow the parent world to send messages to the children for the children to process and render. However, I'm not sure if this is possible at the moment (havn't had much time to read up on the subject). The biggest problem is that child worlds probably have to run on the same machine as the parent world. So much for that idea... but I had you intrigued for a moment, didn't I? XD
Not really, you didn't. =) I've thought about this before... basically you need to have each player "host" their own world. You'd have a "server" world and a "client" world - much like most games do - and use world.Export() and world.Topic() to send messages.
The main problem with this is that currently world.Export() creates a new connection for every message it sends, which is very slow.
Yeah, I've read it multiple times. I don't know that having the object carry around a version of the variable for each client is a viable answer. Perhaps a Display(what,xy_loc,z_layer,alpha) function would work best. (Or, even better: Display(icon,icon_state,dir,xy_loc,z_layer,alpha) and bypass the atomic overhead). By the way, thanks for responding to my other topic I posted a while back conserning a related issue.
Though this could work to an extent with smaller maps, as the player continued walking in any direction, the server would have to load more and more custom map. Each player would need a z level with an entire map. And, to achieve pixel by pixel movement, pixel_x and pixel_y would become a huge problem. All movment systems would still have to be redefined to handle non-32step movment. The benefits don't seem to outweigh the cost in large projects, in my opinion. (However, the same could be said of all such ventures I seem to be taking into byond).
Splitting hairs, eh? :D
Exactly. That's why I'm looking into parent/child world relationships. Each client running a child world on their own machine would allow the parent world to send messages to the children for the children to process and render. However, I'm not sure if this is possible at the moment (havn't had much time to read up on the subject). The biggest problem is that child worlds probably have to run on the same machine as the parent world. So much for that idea... but I had you intrigued for a moment, didn't I? XD
:P
P.S. Sorry to have started such a rant, Spuzzum. Looking back, you caught me on a very bad day.