ID:1668480
 
Keywords: software, website
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 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 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!
Absolutely incredible, I can't wait to try the web-client stuff out.
The Tom.test didn't work for me, but it's not appearing after refreshing the page. I'll be sure to test this and report any bugs.
That wasn't a real url. We don't have anything hosted yet, but anyone can try it themselves.
*CAME*
How does computer IDs work in this environment?

Also, the document at the end with details you listed, has a stray . in the url meaning we get a 404 when we click it.
Oh, haha, I thought it was a test to see if it was working.
Just to tack on a couple of cents here:

One of the major hopes is that people will get inspired and start developing new controls alongside ours. I never had a chance to get to grid/tab/bar controls--there was too much to do--but the structure is perfectly capable of supporting all of them. Tabifying the info control is something that can be done too.

I've played a little with working up some grid control code, but haven't had time to take it too far. I also have an idea in the works for a nice D-pad control that could be used for easier tablet support by reading the existing macro set--yes, we have routines that can do that. Play!

Custom prompts could be a little better covered in the docs, but yes, you can customize those pretty nicely too. There's actually quite a lot you can do with those. Think the color prompt could use a palette? Feel free to experiment with adding one.

This setup is really extremely open and customizable, so it should be possible for developers to run wild on the interface in ways that were never possible in DS. Transparent labels over the map? Have at it! They're easy in this venue.

I'll be working to get to bug reports and suggestions as I can, and I'll answer whatever questions I can. (It's entirely likely I forgot something in the docs here and there.) I'm really looking forward to seeing what people do with this.
In response to MrStonedOne
MrStonedOne wrote:
How does computer IDs work in this environment?

There is no computer id on the browser, but we could fill it with something "unique" like a hash of the ip. Right now it will be null for weblclients.

Also, the document at the end with details you listed, has a stray . in the url meaning we get a 404 when we click it.

Thanks, will fix.
PS: one thing that we should be able to accomplish with this server is multithreading, which was the bane of our existence for a good part of this year (or maybe it was last year). It was ultimately too much of a beast to handle in the old code, but the simpler protocol of this one should allow us to effectively thread client connections, which should theoretically give a good performance gain. We'll look into that once the other stuff is stable.
Hmm. Looks interesting.
I realized that doing http://[ip]:[port]/play will allow you to have the same result except it breaks the connection and doesn't even show in the DreamDaemon. My guess is that there is no BYOND account to access it. I got this information from page's sources. Would we have to use CGI to get that to work in its current state?
That doesn't work because the server requires a key (even a guest key), and that comes from our site. One could probably hack it but we ask that you don't. We will make localhost games playable in that manner in the future, and we will provide options for those that don't want to go through us (although if we don't run the ad, it shouldn't make a difference).
PPS: I forgot to mention one of the big things, which is that in the future, you'll be able to easily embed the web client url into your webpages (like how youtube provides embed links). We'll want to wrap the login/signup process in there if you choose to use it.
*Claps his hands.* I think this deserves a round of applause. The only downside is that external windows that you drag around (are popped out) do not show up. But, that's no biggy. I only need it for debugging anyways. I'll make good use of this baby...



Not only that, this pretty much solves my Feature Request for a better UI for input and stuff.
Well every UI element in the game is visible in that web/ dir, so you can always fix any bugs yourself!

Glad it is somewhat working at least!
In response to Tom
When I join using "[full ip]:[port]": "Connection broken by server (error code 9)."

When I join using "localhost:[port]": map displays, but the tab freezes.

:(

However, in both cases, the interface successfully loaded.

Also, it looks like the transform effects are flipped in the y-axis.
In response to Kaiochao
Kaiochao wrote:
When I join using "[full ip]:[port]": "Connection broken by server (error code 9)."

When I join using "localhost:[port]": map displays, but the tab freezes.

:(

However, in both cases, the interface successfully loaded.

Also, it looks like the transform effects are flipped in the y-axis.

Join by http://byond.com/play/ip:port
In response to Kaiochao
Kaiochao wrote:
When I join using "[full ip]:[port]": "Connection broken by server (error code 9)."

When I join using "localhost:[port]": map displays, but the tab freezes.

:(

However, in both cases, the interface successfully loaded.

Also, it looks like the transform effects are flipped in the y-axis.

Please post individual bug reports to the Beta Bugs forum. In particular, we need to know what browser you are using. Also, if you can give us the url, we can try it as that will reveal if it is a problem on the client or server end (or, alternatively, you could try joining someone else's url that is known to work for them).

Generally this means that the server isn't making a proper connection to the hub, but I'm not sure why you would have that going on. I'm assuming you are using the byond.com/play format of the url.

Finally >:D!

PS: Tom double posted twice he deserves a ban. =o
Page: 1 2 3 4 5