Mimicing Byond Hub Behavior... any ideas?

ID:266670
 
May 15 2002, 4:59 pm
I have a Byond world which I would like to run as a daemon process, and have users connect to remotely. From that world, I would like them to be able to spawn off a completely different world to run locally.

The sort of behavior I'm looking for is modelled exactly in the hub when you click on a game entry, and then click on the 'Run' link. The game's zip file downloads, unzips itself automatically, and then launches in the client.

Any ideas on how this is accomplished in the hub? Dantom? You out there? :)

Regards,
Corporate Dog
May 16 2002, 4:29 am
For the world you want to run locally, setup a normal hub entry for it under Your Hub. In the daemon world, when you want to send the user to the local world, use the link() proc. For example:
    usr << link("byond://CorporateDog.LocalWorldName")
May 16 2002, 5:11 am
Corporate Dog wrote:
I have a Byond world which I would like to run as a daemon process, and have users connect to remotely. From that world, I would like them to be able to spawn off a completely different world to run locally.

The sort of behavior I'm looking for is modelled exactly in the hub when you click on a game entry, and then click on the 'Run' link. The game's zip file downloads, unzips itself automatically, and then launches in the client.

Any ideas on how this is accomplished in the hub? Dantom? You out there? :)

It sounds to me more like you're looking for a way to log into an always-running game (using a Login link, like the one for DMT), and have that do the spawning off. Either that, or you'd like the game, when run via the Run link, to automatically connect up to the main world and get information. Is that the gist of it?

The former I'm not sure how to do, but the latter would involve the use of world.Export(), which I've never played around with.

Lummox JR
May 16 2002, 5:21 am
In response to Air Mapster
Air Mapster wrote:
For the world you want to run locally, setup a normal hub
entry for it under Your Hub.

Which is fine if I want to use the hub in the first place, but I really just want to mimic it's functionality without using it. Even a high-level sketch of what the CGI script behind the 'Run' link does would help (though I'm guessing only Dantom knows about such things). Maybe I'll fire off an e-mail to them instead.

You did give me a plausible Plan B though, Mapster. Thanks.

Regards,
Corporate Dog
May 16 2002, 5:44 am
In response to Lummox JR
Lummox JR wrote:
It sounds to me more like you're looking for a way to log
into an always-running game (using a Login link, like the
one for DMT), and have that do the spawning off.

That's about the size of it. If you're at all familiar with the DirectPlay/DirectLobby paradigm, that's what I'm aiming for. The always-running "game" is the Lobby, where you can chat with others, setup game options, and create or enter staging areas for the actual game. Then there's the actual game, which would be downloaded/updated from the server, and played locally with one player as the host, and the handful of people who joined him in the game's staging area as players. It's a great way to take the burden of running a game off your server when you really DON'T need a massively multiplayer world.

Yeah, it's probably a little bit repetitious if you take into account the Byond client in combination with the Byond hub (which effectively serve as a Lobby)... but I'm doing it for aesthetic/UI reasons more than anything else.

Regards,
Corporate Dog
May 16 2002, 6:14 am
In response to Corporate Dog
Corporate Dog wrote:
That's about the size of it. If you're at all familiar with the DirectPlay/DirectLobby paradigm, that's what I'm aiming for. The always-running "game" is the Lobby, where you can chat with others, setup game options, and create or enter staging areas for the actual game. Then there's the actual game, which would be downloaded/updated from the server, and played locally with one player as the host, and the handful of people who joined him in the game's staging area as players. It's a great way to take the burden of running a game off your server when you really DON'T need a massively multiplayer world.

I haven't heard of that terminology before, but I think I see what you're after. You want something for a game like Laser Wars or Incursion where instead of there being a few hosted games and you look for a good one, you just hang out in a main staging area until a new game is ready for you to join?

You'd definitely need one game always running on the hub to be your centrai server. Beyond that I haven't even pondered the specifics.

Lummox JR
May 16 2002, 7:15 am
In response to Lummox JR
Lummox JR wrote:

I haven't heard of that terminology before,

It's from Microsoft's DirectX API. Pretty neat stuff. Even if you hate the company, you have to admit that their programming tools and libraries are amazing.

but I think I see what you're after. You want something
for a game like Laser Wars or Incursion where instead of
there being a few hosted games and you look for a good
one, you just hang out in a main staging area until a new
game is ready for you to join?

Haven't played either of those, but it sounds like the same thing, yeah.

You'd definitely need one game always running on the hub
to be your centrai server. Beyond that I haven't even
pondered the specifics.

The way I guess I'm going to approach it is like this: the host-to-be picks a port number to run the "spawned game" on (among other game settings) and creates a new staging area for the game. Other players enter the staging area, and are given the host's address and selected port number. The host clicks a button to actually start the game, at which point he leaves the lobby world, and enters the game world (which will be running locally on his machine... as per Air Mapster's suggestion later on in this thread, I could setup the game world as a .zip package under my hub; the link() proc would allow the host to update/download the game world and run it locally). The players would then try to link to that game world as well (they have the address and port; just have to account for timing issues in regards to the host downloading the game world, and getting it started).

But, like I said, if I can divorce this process from the hub at all, I'd like to do that. No offense meant to Dantom, the Byond community, or Byond's sponsors (the letters Z & Q, and the number 2) but I dislike the idea of my program being so intricately tied to an external web site. I wish nothing but long years of success for Byond (and I hope to spread the gospel with my game, once it's completed) but what happens if Dan & Tom get sick of the whole thing, and decide to shut down the website/hub (not that THAT'S likely to happen, but still)?

Regards,
Corporate Dog
May 16 2002, 10:33 am
In response to Corporate Dog
Corporate Dog wrote:
Air Mapster wrote:
For the world you want to run locally, setup a normal hub
entry for it under Your Hub.

Which is fine if I want to use the hub in the first place, but I really just want to mimic it's functionality without using it.

I think I have a better idea of what you want to do after reading the other posts in the thread. You should be able to avoid the BYOND hub entirely, but the user experience may not be as "clean" as if you went through the hub. It also needlessly downloads the local game every time someone starts a new game, which is certainly less than ideal.

I'll go over a way you can do this without the hub, but let me summarize the pros and cons of each method:

With hub
  • Pro: Seamless - the user goes from lobby to game in the same instance of DreamSeeker, without any extra fuss
  • Pro: Once the user has downloaded the local game, it doesn't need to be downloaded again
  • Con: You're out of luck when Tom's "no computers by 2005" ultimatum hits

    Without hub
  • Pro: Doesn't go away if byond.com blows up
  • Con: user must download the entire local game each time
  • Con: users might be confused about extra steps or questions (new DreamSeeker, have to login again, etc)

    A good feature request may be for Dantom to add the capability to do this more seamlessly, just like the hub, but without relying on it. I'll bet most of the plumbing is already there for this.

    It sounds like you want to look into the run() proc instead of link. On your Lobby server, you'll need to store a copy of the local game's dmb file - this file will be the argument to run():
mob/verb/startgame()
    src << run("localgame.dmb")

Something like that. Now, this transfers the localgame.dmb file to the player's local machine and runs it locally. The player will be asked "Run file localgame.dmb?" and if ok, a new instance of DreamSeeker will pop up with the local game. The old one (Lobby) will still be there.

This also doesn't address the problem of resources for the local game. Yes, you could send the whole package zip in the run statement, but then the result would be that Winzip or something would open that up. I suppose you could fool around with packaging the game as an exe file and see if that works better. But either way, it's probably not terribly clean.

The best way to handle resources in this case would be to use client/preload_rsc to specify a web address where you have the resource file available for download. You can package up resources separately from within DreamMaker.

Now, finally, how to notify the Lobby when a new local game is ready to accept players? Here's where you want world.Export() and world.Topic().

In the lobby world, set world.Topic() to receive information about newly started local games.
world/Topic(T)
    var/list/params = params2list(T)
    if (params["url"])
        world << "New game hosted at [params["url"]]"


And then world.Export() in the newly spawned local game:
world/New()
    world.OpenPort()
    var/list/params[0]
    params["url"] = world.url
    world.Export("byond://remoteserver:remoteport?[list2params(params)]")

Of course you can get much more elaborate with this, maybe giving users to specify hosting parameters (which port to use with OpenPort, etc). And it's up to you what to do in the lobby world when you get new information in Topic().

Even a high-level sketch of what the CGI script behind the 'Run' link does would help (though I'm guessing only Dantom knows about such things). Maybe I'll fire off an e-mail to them instead.

The Run link in a game's hub entry doesn't do anything terribly mysterious. It simply generates .dms file which is downloaded by the browser, and if properly configured, passed along to a new instance of DreamSeeker. The .dms file simply points DreamSeeker to the BYOND url of whatever game it is. For example, clicking on Run for one of my games produces this .dms file:
/*
This is a DM Script file.  You need to install BYOND (for free!)
and possibly configure your browser to open this file with
Dream Seeker.  For more information, go to: http://www.byond.com/script.
*/
#define URL "byond://AirMapster.ShapeShifter##version=10"
#include <byond.dms>

DreamSeeker then goes to the url byond://AirMapster.ShapeShifter##version=10. How exactly it gets there, and how it knows what to download, is the mystery. Presumably it contacts Dantom's server and gets more specifics on what to do.

The only real problem in your scheme is getting DreamSeeker to download and run locally a new game. Any byond address not of the form above must by definition be the address of a persistent (and therefore, remote) world: byond://remotehost:remoteport.
May 16 2002, 10:48 am
In response to Air Mapster
Heh... hate to let the wind out of your sails after you typed all that, but I already played with the run() proc last night (it wasn't a particularly satisfying solution).

I also know about the DM script that gets run (guess I should've clarified that)... I just don't know what happens behind the scenes (how does the client recognize the fact that a file is being sent which should be run locally; how does the hub CGI software make this distinction).

I think until Dantom incorporates something like this in mainstream DM (or at least tells us how they do it) I'll be using the hub to serve up the local world files.

Regards,
Corporate Dog

PS: What's this "No computers by 2005" ultimatum of which you speak? Is this for real (they don't want to be in the business of hosting files) or is this a hypothetical situation?
May 16 2002, 10:58 am
In response to Corporate Dog
Corporate Dog wrote:
Heh... hate to let the wind out of your sails after you typed all that, but I already played with the run() proc last night (it wasn't a particularly satisfying solution).

I figured as much. It was an interesting enough problem that I tried it out just to see if it could be done. ;-)

PS: What's this "No computers by 2005" ultimatum of which you speak? Is this for real (they don't want to be in the business of hosting files) or is this a hypothetical situation?

Heh. Tom has told me personally, on many occasions, that his goal is to be computer free by 2005 (or thereabouts). The assumption is that BYOND will be entirely self-maintaining at that point, so Dan and Tom will be able to sit back and watch the money roll in.