



This is the much anticipated web-client. It is probably our most ambitious endeavor yet, and I fully expect that there are some showstopping bugs, but I also think we can iron out most of them within the next week or so. We have tested as much as two guys can, but that doesn't involve major performance situations like games with 20+ people. It is wholly possible that the first time someone hosts a big game, the system will crash & burn. That is OK! There is no reason why this can't work properly but we just need to get some data.



This client uses a much thinner protocol than the existing DD/DS link. It is a protocol we intend to fully open-source alongside the client software (which I think is currently in somewhat obfuscated JavaScript). The client is written primarily in



Speaking of tinkering, the beauty of this client is that it is all about developers getting under the hood. You can build and export your own custom controls that others can then use in their games. The system comes bundled with a handful of controls that Lummox JR ported (among the many, many tasks he burned the midnight oil over to get this to you). These are located in the [BYOND install]/web directory (in fact, every dms or js file in this directory gets auto-imported and relayed from the server when clients connect). If you look them over, you can get an idea of how the control structure works and start making your own. The defaultSkin.dms in particular is a good place to get started, since that shows how to use the existing controls in your game.



I'll give a basic summary of how this all works. When you host a game in DreamDaemon (and enable the default webclient hosting option), DD will invoke a pseudo-webserver on which resources are hosted. The client requests these over http, similar to the old-style rsc cache. DD also relays all of the dms files (defining the interface & macro setup) included in your game, as well as those in the aforementioned [BYOND install]/web dir) over the conventional socket, along with the normal game-data. This part is like DS, but with a thinner protocol. Maybe people can do other ports (like iPad) once this is fully fleshed out. The implementation may (and likely will) change during this beta test, but the gist of it is that EVERYTHING comes from the server. The server outputs an http url that refers to its hosting port, and you can tell your audience to connect to it.



At the moment, you go through byond.com to get to this url. For example, when you host on DD, you'll see a link of the form http://www.byond.com/play/[your ip]:[your port]. If your game doesn't have a hub, that's the only url. If your game does have a hub, a masked url (using the world_id syntax) will automatically show up there as well. We fully expect to change the url syntax in the future, primarily by making it so that you can create your own urls in either mode, eg http://www.byond.com/play/[mycode].



The reason the urls go through the site are twofold (maybe three or four or even five folds but let's just use two here):

1) In order to log you in

2) To play an ad-- so we can justify this development.

BYOND Members can skip the ad by turning off site ads in their account settings. We'd greatly appreciate if you didn't try to otherwise block them-- these are really our main source of revenue. Nevertheless, we are going to try to offer compelling packages for those developers who want to host ad-less games as a more professional presentation. Just stay tuned: we have a lot on the plate.



If you connect to a game locally (localhost or 127.0.0.1), you won't get an ad. Right now you still have to go through byond.com (and hence be online), but we'll remove that restriction in one of the upcoming updates. We'll also release an exe version of the client-server that just embeds the server with a web framework (mainly for single-player games); this should work offline and won't run an ad either.



We're hoping there aren't many catastrophic bugs, but try hosting in 507 DD and connecting to the game and tell us what works and what doesn't work. There are some known issues we're working on, as well as a number of features that just didn't make it into this first release. We recommend using Google Chrome for your test since that browser supports the bulk of the HTML5 stuff we use.



One thing that is slightly annoying about this is that we haven't figured out a good way to share resources across servers, and the web specs are very anal about protecting data by origin. In layman's terms, this means that, at the moment, if you host a game on two different ports, the clients will have to download everything twice. But at least they'll have a fun commercial to watch while they wait.



Lummox JR, among his many, many tasks, has written a



I hope you have more fun using this than we did creating it! I'm not sure about the title, as I am a bit loopy right now. We intended to get this release out a couple weeks ago, then last week, then Monday, then this morning, and finally it is here. Hopefully it works. You can give the latest software a try at our usual download location . It is the link at the bottom. We'll get the linux/BSD build out pretty soon (I am testing), and I will attempt a Mac build sometime in the near future as well, for all of you oddballs who host games on Apple.This is the much anticipated web-client. It is probably our most ambitious endeavor yet, and I fully expect that there are some showstopping bugs, but I also think we can iron out most of them within the next week or so. We have tested as much as two guys can, but that doesn't involve major performance situations like games with 20+ people. It is wholly possible that the first time someone hosts a big game, the system will crash & burn. That is OK! There is no reason why this can't work properly but we just need to get some data.This client uses a much thinner protocol than the existing DD/DS link. It is a protocol we intend to fully open-source alongside the client software (which I think is currently in somewhat obfuscated JavaScript). The client is written primarily in Google Dart and the amazing StageXL library (whose author, Bernhard Pichler has been personally helpful to us in suggesting code and fixing bugs). Rather than peruse the obfuscated JS, I suggest you wait until the beta test is over and we can just release the Dart code. Eventually we'll probably open-source the server too, but there are just too many headaches to deal with that right now (since it ties into our central services, authentication, and so forth). So those keen on tinkering with BYOND may accomplish their "Net Dream" one day, although I think it's a pretty painful dream!Speaking of tinkering, the beauty of this client is that it is all about developers getting under the hood. You can build and export your own custom controls that others can then use in their games. The system comes bundled with a handful of controls that Lummox JR ported (among the many, many tasks he burned the midnight oil over to get this to you). These are located in the [BYOND install]/web directory (in fact, every dms or js file in this directory gets auto-imported and relayed from the server when clients connect). If you look them over, you can get an idea of how the control structure works and start making your own. The defaultSkin.dms in particular is a good place to get started, since that shows how to use the existing controls in your game.I'll give a basic summary of how this all works. When you host a game in DreamDaemon (and enable the default webclient hosting option), DD will invoke a pseudo-webserver on which resources are hosted. The client requests these over http, similar to the old-style rsc cache. DD also relays all of the dms files (defining the interface & macro setup) included in your game, as well as those in the aforementioned [BYOND install]/web dir) over the conventional socket, along with the normal game-data. This part is like DS, but with a thinner protocol. Maybe people can do other ports (like iPad) once this is fully fleshed out. The implementation may (and likely will) change during this beta test, but the gist of it is that EVERYTHING comes from the server. The server outputs an http url that refers to its hosting port, and you can tell your audience to connect to it.At the moment, you go through byond.com to get to this url. For example, when you host on DD, you'll see a link of the form http://www.byond.com/play/[your ip]:[your port]. If your game doesn't have a hub, that's the only url. If your game does have a hub, a masked url (using the world_id syntax) will automatically show up there as well. We fully expect to change the url syntax in the future, primarily by making it so that you can create your own urls in either mode, eg http://www.byond.com/play/[mycode].The reason the urls go through the site are twofold (maybe three or four or even five folds but let's just use two here):1) In order to log you in2) To play an ad-- so we can justify this development.BYOND Members can skip the ad by turning off site ads in their account settings. We'd greatly appreciate if you didn't try to otherwise block them-- these are really our main source of revenue. Nevertheless, we are going to try to offer compelling packages for those developers who want to host ad-less games as a more professional presentation. Just stay tuned: we have a lot on the plate.If you connect to a game locally (localhost or 127.0.0.1), you won't get an ad. Right now you still have to go through byond.com (and hence be online), but we'll remove that restriction in one of the upcoming updates. We'll also release an exe version of the client-server that just embeds the server with a web framework (mainly for single-player games); this should work offline and won't run an ad either.We're hoping there aren't many catastrophic bugs, but try hosting in 507 DD and connecting to the game and tell us what works and what doesn't work. There are some known issues we're working on, as well as a number of features that just didn't make it into this first release. We recommend using Google Chrome for your test since that browser supports the bulk of the HTML5 stuff we use.One thing that is slightly annoying about this is that we haven't figured out a good way to share resources across servers, and the web specs are very anal about protecting data by origin. In layman's terms, this means that, at the moment, if you host a game on two different ports, the clients will have to download everything twice. But at least they'll have a fun commercial to watch while they wait.Lummox JR, among his many, many tasks, has written a document discussing the control format as well as compatibility with the existing software client. It will be updated throughout this cycle (where I hope we or other community members can fully port the BYOND 4.0 control set that Lummox has given a good push).I hope you have more fun using this than we did creating it!