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!
