ID:1643547
 
Keywords: software, website
A few months ago, I made a post describing how we were finally moving forward with the BYOND web port. This is almost ready for primetime (testing) so I wanted to whet your appetite with a glimpse into both the past and the possible future of this project.

A history of the web client


As many of you know, we initially attempted to create this client in AS3/Flash quite a few years ago. Some even pointed out that this was not the best direction, since even then Flash was being given the death sentence as a technology. However, the alternative HTML5 option wasn't looking too hot back then, as a number of things we wanted to do were only supported with different degrees of difficulty on the different popular browsers. So we ended up going with the Flash and had a bare-bones client basically working, but I was never very happy with it. The client wasn't extensible, was limited to only the map and a hard-coded interface, and didn't have a future among the wide world of apps that have taken the Internet by storm. Introducing a web client would bring about a new wave of feature creep and headaches and I didn't want to go forward with this unless what we had was worth supporting. So that's why all but a few users ever saw that client.

When I revisited the notion of the web client early this year, I saw that HTML5 was indeed in much better shape. Although support isn't ubiquitous, it is acceptable, particularly since Google Chrome has become the dominant browser. So we opted to give it a shot. Porting the existing Flash code was fairly easy since we already had a good chunk of the project-- a simplified protocol to relay the data from the server to the client-- developed from the prior effort. So within a short time we had our basic client written in javascript (courtesy of Google Dart), complete with hard-coded interface, macro, and map support. But this is where we were with the Flash client that left me unfulfilled. So what next?

This-- not the somewhat premature reports of Flash's demise-- is where the HTML5 option really shines. Because, by doing things in javascript, we realized that we could open up the interface to the developers in a manner that is not only more powerful than the previous web client, but far superior to the existing software client. When we successfully tested this approach, the moment was revolutionary... like Edison and his lightbulb, or Graham and his phone, or Reese and his peanut-butter cup. We are in the big time now, ladies & gents!

How does it work?


Just like the BYOND icon format is "PNG+", the new BYOND interface format is "HTML5+". You write the interface in HTML/javascript, but can take advantage of a predefined template system to use existing controls and function calls to the BYOND infrastructure. Theoretically, you should even be able to track and query BYOND elements via javascript to implement client-side effects-- a long desired feature. The idea is to make this as powerful as you need. Novices or people who only need a basic interface (the vast majority), need only write a simple wrapper to define their layout, and even a rudimentary knowledge of HTML will suffice. Power-users can write their own controls using javascript. They can even export those to a library so other users can reuse these controls.

For example, here is a very simple interface that displays the map and output controls.

<body>
<div id="map" byondclass="map" style="width:352px;height:352px"></div>
<div id="output" byondclass="output" isdefault=1></div>
</body>


The 'id' is used to reference the control from within the winset, output, etc. statements in your code, as well as from within the HTML for style properties and javascript access. The 'byondclass' is to point to a template that defines what the control does and how it interfaces with the server. We have provided a number of default controls to mimic most of the existing DMF system. As mentioned, power-users can create their own-- and we're really looking forward to see how people use (and abuse) this! An explanation of the control format is beyond the scope of this preview, but we'll cover that in more ground with the beta release, and, of course, the code of the existing controls will be available to peruse and modify.

You define these interfaces, as well as supporting styles and macros, in DMS files. You oldbies may recall DMS being used primarily for macros prior to BYOND 4.0, and we are going back to that system. You may define as many DMS files as you need, since each new or imported component requires one.

To try to preserve backwards-compatibility, the DMF system also works-- to a degree. We've ported many of the components and properties over to the HTML5 system so that old games will work, but we encourage users not to use this for future projects since it limits the flexibility of the system and won't be supported down the line. Also, some existing DMF components (such as the grid control) do not exist as of this writing, but perhaps one of you geniuses out there can port them for us!

Next steps


Although the bulk of the system works currently, there is a lot left to be done. We will strive to get it into beta testing fairly soon (will the goal of late next week) with the caveat that some stuff won't work and performance likely won't be optimal. That's the point of beta-testing, after all.

Right now, the main limitation of this system is that there is no standalone client-server for testing or single-player mode. However, we are working on a port using the Chrome Embedded Framework (CEF) to support this. We will see if that makes it into the first beta or not.

Surprisingly, most client-side features work or should work by beta-time. You can use the winset/winget/etc system to interact with your interface from the server. Features like maptext and animate() work-- even better in some cases. The rendering uses WebGL and, on my machine at least, doesn't seem to suffer from the same issues we have in DreamSeeker. Audio works well on most browsers, although not all due to different standards, but we can likely come up with a system to load different filetypes as needed. I'm sure that after a few painful weeks of testing, we can get this system into a very complete and stable state.

Distribution of multi- and single-player games


One of the main goals of this project is to provide a way for users to create games which can be competitive with other offerings on the web. While I'm sure many disagree, I've never believed that the BYOND technology (eg the sluggishness of the network) has been the bottleneck from making a good, even a great game. Rather, it is the distribution and, perhaps to a lesser degree, the stigma associated with using BYOND (or any game-making toolkit).

With this in mind, we have two means of distribution in the early pipeline; this will surely adapt as needed.

For multiplayer games, DreamDaemon will output a link and an embed tag that may be used on an outside site. These point to pages on BYOND.com to handle the login/signup, but this is all inline and, with the embed, somewhat transparent to the user. This also allows us to play an infrequent pre-game ad, which is the only way we can make money when games are off-site. I realize that some percentage of you object to this, but I hope you understand that this is the cost of doing business when offering a freeware product (and BYOND will always be free). We will also continue to work with developers should they want to opt-out of ads in return for the commission we'd otherwise earn. We're pretty laid back about this but realize that we have to eat too!

My hope is that several games will really explode in traffic with this opportunity, and we can move BYOND away from being a social network (an exciting but somewhat failed experiment) and rather an engine earning off-site commissions.

For single-player games, our plan is to provide a simple system to allow the user to create their own executable, free of both charge and commission. Ideally, we could do this with very little configuration from the developer-- somewhat like the old "Make EXE" but with a better end result (an actual EXE). We already have the infrastructure to do this on Windows due to our work with BYONDexe, but that project is somewhat complex since it interfaces with the login/key system. A true single-player game need only log the user in as a "Guest" (more complex account management can be handled by the game) since it is intended to work offline anyway; as such, it would have no interaction with the hub and could survive long after BYOND is gone. Essentially, this would just be a wrapper around the CEF technology used to run games from the compiler.

The pitfalls of cross-platform


Of course, one of the biggest benefits of the web-client is that it is cross-platform. No longer do we have to deal with the ten emails a week about people wondering why we can't get our heads out of our asses and make a Mac version!

But, that said, so far, we have only ported the client. If this is successful, this introduces a problem, because many of our tools are Windows-only. The server and compiler both work on unix platforms, but there is no interface. More importantly, there isn't a map-editor, which is actually necessary for most games. So aside from being clunky-- "you have to develop your games on Windows but you can deploy them anywhere"-- this is genuinely inconvenient.

Rather than porting map-editor and other tools, the better tact to me seems to be to redefine our formats in such a way that the tools can themselves be written in DM, using the aforementioned standalone system. So we'd provide native hooks to read/write DMI and DMM, and we open-source this aspect of the code or outsource to our users here to develop editors. Not only would this be cross-platform, but it would be more powerful, since anyone could build in whatever features they've wanted for these things over the years.

Now one problem with this approach-- aside from just the manpower and scope of the project-- is that we wouldn't have a unified system, as we do currently. I think one of the real appeals of BYOND vs other toolkits is that it has a very low introductory learning curve. You can download the toolkit and can immediately dive in since all of the tools are there for you. Under the proposal, you might have to download a separate program like Eclipse to do the code-editing and then integrate it with these third-party editors for everything else. So hopefully there is a middle-ground here where we can provide the flexibility of third-party tools with the convenience of a single, straightforward configuration.

Fin


If you've read this far, you can see that there is a lot going on here both in actual development and future project consideration. BYOND is in an exciting place, but the technology is really only half the battle. Sadly, we continue to make very little from month to month and it is the sobering reality that the state of our finances directly affects the future of this project; that is, how many of the proposals will become a reality. Still, I can't help but be touched by the generosity of so many users here, and I thank you for believing in this project and continuing to support it. I hope that those of you who can do the same will keep that in mind as we move forward here.

Thanks for reading!
GG BYOND o how it has Grown
Wow, such dedication from such an old platform, I applaud your work on BYOND, and wish you good luck in keeping this struglling platform online.
Will the current client/server based games still be supported, or are those being faded out? I like the idea of moving on to this web-based client stuff, but I also don't like the idea of re-learning everything again for the purpose of moving on. I don't really have the time to do any of this, and I don't see many other BYONDers that are "oldbies", aside from the big guys, having the same free time that we/they had in their "youth", so to speak.
I don't see this taking so much "re-learning", as growing up and learning a bit of HTML, Javascript, and CSS type stuff that you would otherwise be learning off-site anyway.
I hope my balls helped with stress testing and breaking the client.
In response to Ter13
Ter13 wrote:
I don't see this taking so much "re-learning", as growing up and learning a bit of HTML, Javascript, and CSS type stuff that you would otherwise be learning off-site anyway.

I just mean it's a big step to going back to the basics - again.
In response to Super Saiyan X
Super Saiyan X wrote:
I hope my balls helped with stress testing and breaking the client.

NSFW

Your balls still don't work properly but I'm playing with them!

Nice! Cant wait!
And so begins all of the users who have "Left BYOND" will be returning once again, to see what new interesting features are being introduced in the next generation.
If you know DM, picking up a tiny bit of javascript will be as easy as scratching your sack, honestly.

HTML and CSS is something everybody generally knows, anyways.
Amazing.
Reading what's to come for the web client is making me all giddy inside. You and Lummox JR have definitely been working hard on this next update! Thank you both so much, I can't wait to use these new features. =) And here's to a new era of BYOND!
In response to LordAndrew
LordAndrew wrote:
Reading what's to come for the web client is making me all giddy inside. You and Lummox JR have definitely been working hard on this next update! Thank you both so much, I can't wait to use these new features. =)

I'm piggybacking this comment cause we're a team.
In response to Ernesto5432
Ernesto5432 wrote:
Ter13 wrote:
I don't see this taking so much "re-learning", as growing up and learning a bit of HTML, Javascript, and CSS type stuff that you would otherwise be learning off-site anyway.

I just mean it's a big step to going back to the basics - again.

I'm not sure exactly what you're asking. If you mean whether we plan to support client-server games (like Incursion, where you would always host through DS), then that isn't in the plans at the moment, but I don't think it's a huge deal since there is really no reason you can't just use DD for that (it's way more efficient anyway due to lack of multithreading on the client-server atm). I suspect at some point we will have to tackle this since people are surely going to want to get their games onto Steam and not be limited to single-player. We just need to ensure that it doesn't cut into our revenue stream through the ads.. so maybe it'd have to be a one-off fee to do this kind of thing.

If you are just asking about the interface, you can continue to use the existing system for now. Some stuff isn't supported right now (like the grid control) but anyone can port those controls for us. A basic interface should be really easy to do in HTML though.

I approve this message.
Hurray!
This is fantastic news! Congrats to Tom and Lummox JR!
Been playing BYOND games since 2007 an plan to keep on doing it ;D can't wait too see what BYOND has for us
Sounds great!
Page: 1 2 3 ... 6 7 8