Mind to define the term 'resources'?
Are you talking about the initial transfer of graphic and sound data from the server to the client, which might take up a good deal of your server's bandwidth, or are you trying to refer to BYOND's processing of your commands?

Cluster servers for BYOND worlds, all managed by SQL, is a good place to start.
Alathon is a good guy to talk to for this sort of thing.

You can offload non-dynamic resources to a website using the preload_rsc variable.

DivineTraveller wrote:

Alathon is a good guy to talk to for this sort of thing.

I'm not. Besides not being around anymore, link() is useless (You lose control of the client) and so clustering is not an option. Best bet is to get people to download the game before they ever enter it.

Tom wrote:

Alathon wrote:

link() is useless (You lose control of the client) and so clustering is not an option.

I thought we fixed that. What's the issue exactly?

Granted I haven't tested this in a long time now, but I filed several reports on the issue and provided demonstration code and other such things. I'm afraid the exact details elude me now, but as I recall there were 2 primary issues:

1) Since you can only connect to one world at a time, or even download one set of resources at a time, someone clicking a link (any BYOND link) while being transferred by link() is interrupted and may not arrive at the other end. If I recall correctly, it depends on whether the link() resolves first or the download completes first. This is confusing and counter-intuitive for the user. Sometimes it works, sometimes it doesn't - And as soon as a developer calls client << link(), they lose all control over them. There are also no fallback mechanisms to link(), meaning the client doesn't try multiple times to connect and they don't resort to going back to the origin world if they can't connect in the end.

2) Sometimes link() fails. This may be related to 1, if something else takes control of where the client is going even for a brief second.

The end result is that link() is unreliable and can't be controlled deterministically - Hence my statement that it is useless.

You most likely want to do two things:

1) Allow clients to do multiple things at the same time, allowing someone to connect to two worlds simultaneously. Alternately, put them in a priority queue weighted after the size of the actions (Thus weighting resource downloads lowest) and make sure they all get tried.

2) Provide a fallback mechanism to link() where, if a client is linked to somewhere that doesn't exist, they try for a while to connect back to the original world.

There were also interface-related issues with link(), where, as soon as you are link()'ed your interface returns to the default state of an interface for that world. You also get red error-messages that are sent to the Default output element no matter what - Forcing you to create and minimize a default output element in, say, a corner. This puts some annoying limits on interfaces - I had to create a black interface element that covered everything with the text 'Loading' to simulate something like a 'Loading...' status, as the default look of the interface.

Tom wrote:

Alathon wrote:

Granted I haven't tested this in a long time now, but I filed several reports on the issue and provided demonstration code and other such things.

Ok, thanks for the info. We'll take a look at your older bug reports and investigate this again. Even though you may no longer be active in BYOND, someone else might make a similar foray into multi-server worlds so I'd like to support it to our best ability. It could certainly be a useful application for this software if we could get it working right.

To sketch out the use-case in question, the idea was to split the game up into many daemons with each area (Similar to the MUD term for an area) running in its own daemon. These daemons then communicated via a shared SQL database and sent players back and forth. This provided the skeleton for a world that supported 'instances' similar to how many games do now-adays, where a party has their own version of a world/area. It worked fine, except for the issues described.

Its a nice idea for a BYOND game because there are no options to tune network performance; and as network performance has a tendancy to worsen exponentially with an increased amount of clients, reducing those has a direct, noticable effect on lag and playability.

Tiberath wrote:

One other issue I noticed with link() a while back was just as the transfer began, the message "connection failed" would appear in the original Dream Seeker instance (and/or O&M window).

This is what I meant with the red error messages sent to default output.