ID:132566
 
I don't know if i posted this in the correct section but im wondering if there are solutions on the way or ones set in motion for BYOND to handle games with larger resources so it doesn't bog down the server too much.

any help on the matter would be greatly appreciated

ps-Im just curious as to how much exactly BYOND is able to handle
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?
In response to Schnitzelnagler (#1)
yes you have an idea of what im talking about,im wondering.. are there methods of reducing said lagg caused by players downloading them.and how smooth the game runs after said resources have finished downloading.

what im basically trying to figure out is if a game with a massive content build,are there methods of reducing the lagg the client receives.reason im asking is the art for my game ranges from 100kb-1000kb in file size.and these are making the resource file downloaded by the client quite large for a game in early stages of development.
In response to Zane444 (#2)
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.
In response to DivineTraveller (#3)
mind giving abit more info on this?
In response to Zane444 (#2)
You can offload non-dynamic resources to a website using the preload_rsc variable.
In response to Nadrew (#5)
yeah i was informed about this,but i wasn't sure exactly how it worked,thanks you all for the help
In response to DivineTraveller (#3)
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.
In response to Alathon (#7)
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?
In response to Tom (#8)
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.
In response to Alathon (#9)
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.
In response to Tom (#10)
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.
In response to Tom (#10)
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).

To a developer who's never used link() before or a player who hasn't come across a game that does it, it'll look like a connection failure to which they'll close Dream Seeker, try again or leave the game entirely.
In response to Tiberath (#12)
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.