BYOND isn't very efficient - even a moderate amount of players on a fast server with decent bandwidth can slow it down. However, if you design your game cleverly, you can split it across several servers.

For your information here is a very interesting fact about MMORPG's (if you wan to call them RPG's :P ) .
Most if not all like UO have a LOT of servers per shard. I read that Britain has its very own server. (I think the bank area needs one itself :P) This helps to spread the workload. This would be especially useful in BYOND as Crispy stated because of a) the object limit and b) its not as efficient as C++ which most others are written. (some parts like the mouse are very processor intensive and the fact that the server handles EVERYTHING you can't rely on the client to calculate things for you.)

Edit: I reversed something =]

Depends on the game. I'm sure a game that uses a minimalist approach, like a text MUD, could easily support hundreds of simultaneous users on a server that isn't just a mere desktop PC connecting to the internet via a cable modem.

(If you find any graphical massive multiplayer online game that doesn't have substantial lag, feel free to tell me. =))

In short, it's not inefficiency -- it's the lack of client-side prediction and processing. Half-Life & CounterStrike still runs like a slideshow on modern residential internet connections; however, because it is does client-side prediction, the effect is not nearly as noticable to the end-user. In BYOND's case, client-side prediction is not a likely possibility, because we would have to define what the client is expecting to see, and the rate at which it is done. As for client-side processing, that is something that we'll have to wait for.

Additionally, the designer's architecture plays a substantial role. For example, in one of my projects I created a system for shooting projectiles at a certain turf to a certain distance, calculated on the fly, based on the angle in which the user clicked. After 1000 shots on my 1.4GHz CPU, I haven't seen a single microsecond of slowdown from the procedures -- and the weapon fires in bursts of three individually-tracked projectiles.


In short, the problem is basically trying to find the ideal compromise. If you want ultimate control over the whole client-server model, then you'd have to rely on C++ or another industry-standard programming language. If you want less difficulty in creating a game, then you'll have to rely on DM. DM will eventually have to grow to be capable of meeting the gap in the middle -- more optional difficulty but more optional control.

In the long future, I do imagine BYOND will be capable of sending data to the client that the client should use on its own to perform its own calculations on what it notices in the world. The client already does this with the standard view(), oview(), hearers(), viewers(), etc. procs, but allowing it to understand other procedures is the major issue.