ID:1668062
 
Hello all, it's been a while. Just briefly looking over the forums, I can still see names I recognize, who I presume still recognize me. As for the ones that don't, the brief background is I'm a former BYONDer who used to help out around the forums a lot, though I up-and-left pretty abruptly in 2012.

Continuing onto the reason why I'm posting here: unless things have changed significantly-more than I have expected in the interim--and I don't really see anything suggesting they have--DM is compiled into bytecode (analogous to machine code, for those not in the know) in a format specific to BYOND, and interpreted by a Virtual Machine you all know as Dream Seeker. I, personally, understand why this was once viewed as the best way of going about things, but I think that time has long since passed.

I don't see this as a problem with the bytecode paradigm; there are many languages that use this scheme and have done so very successfully, most notably Java and C#. The difference though is that these languages are typically supported by groups with significant resources, and obviously Oracle and Microsoft both have deeper pockets than Dantom.

The real issue I see is that the strengths of using bytecode and a virtual machine are simply not present. The biggest strength of this scheme, bar none, is that it is inherently multiplatform, provided the virtual machine itself is multiplatform. Because bytecode is specific to the virtual machine and not the processor, Java written on a machine running Ubuntu will run on a machine running Windows XP. But BYOND still won't even run on Linux natively.

Of course, the downside of bytecode-compiled languages is that they do not produce any sort of native executable, and the virtual machine has to be installed an run in order to run any bytecode. As per the model, BYOND does this, and so it has the downsides with none of the benefit. To run BYOND well under its current system, you have to be a Windows user with the BYOND suite installed, and both these things limit its appeal. Obviously, Windows is still the dominant Operating System on PCs, but at the moment BYOND has no access to mobile gaming or browser-based gaming, both of which are becoming more-and-more popular. I don't think anyone can deny how much the mobile gaming market has exploded in recent years.

Another problem with the current model is that, as mentioned, Dantom does not have the resources or backing of companies like Oracle or Microsoft. At the moment, it is mainly two guys working as community mangers, business managers, moderators, web developers, and developing the virtual machine, which has a backend, if I remember correctly, nearing two decades old; at the very least, it's about fifteen years old. This leads to the unfortunate fact that BYOND is effectively trying to re-invent the wheel as a snail's pace. There is a load of functionality in BYOND that is relatively-new, but has been pretty basic elsewhere for more than a decade. The current model is not sustainable, because from the view of a developer outside BYOND we might as well be running backwards.

My suggestion is simply this: discard the current compiler and virtual machine except for legacy support, and either have DM compile into an existing bytecode so it can use an existing VM (for example, JVM or .NET) or have DM be transcompiled into another language.

I personally believe the latter of these two would be better, and in particular have DM transcompile to Javascript. Javascript is a dynamically-typed language, like DM, so this makes such a change much more feasible. It is also garbage collected, meaning memory management translates relatively-directly from DM without much change. It furthermore opens up both the mobile and browser markets almost-immediately, depending on the certain factors of the implementation. Additionally, Javascript has many open source virtual machines to choose from, the most prominent being Spidermonkey, which is used in Firefox, and V8, which is used in Google Chrome. V8 has the added bonus of being the engine that Node.js uses internally, and thus would allow for Javascript to be used for handling both client and server information.

Effectively, transcompiling to Javascript allows for backwards compatibility with old code depending on how such a project is approached.

Transcompilation to Javascript is hardly new. Two well-known projects are CoffeeScript and TypeScript, the latter being a superset of Javascript and backed/developed by Microsoft. Such a project is entirely-feasible, and could be approached as an open source project, potentially with significant community input if people were willing, and with Javascript as an object language bugs in output code could be readily-diagnosed by anyone with Javascript experience.

A DS-style client could still be approached simply by writing a wrapper around whatever Javascript virtual machine is used. Once again, V8 would make a good choice for this, as it was designed with such a possibility in mind. Alternatively, the output could be a .js file, or any number of other possibilities. A game could be embedded directly into its hub page, or thrown onto a given web page.

By removing a focus on adding features to the virtual machine, removing restrictions, or upgrading it, a focus could go back to the language itself, which is something that DM desperately and truly needs, and it would open up possibilities that are quite unfeasible in the current model. For example, the implementation of an optional BYOND standard library. The present classes could be re-implemented in this library, deriving from /datum, written in native DM code, instead of acting as a black box (though some black box-like behavior might be inevitable).

This is not without its downsides, the most obvious being re-implementing a compiler, even if its object language is not bytecode, is no small task, but I feel if approached it would be well worth the potential downsides. At the very least, it would open up a path that is simply not possible in BYOND as it currently is. Thoughts? Discussion?
I definitely agree with what you have to say on the matter. A full port of the existing engine to Javascript would be the most ideal scenario. We already have a (lite) Javascript port of the client set to launch this week.

Unfortunately, I can't help but wonder if this is something the current development team has the resources or energy to handle. It all falls down to what Tom/Lummox feel equipped to handle.
In response to Ter13
Ter13 wrote:
A full port of the existing engine to Javascript would be the most ideal scenario.

Well, I'm not really discussing a port, but a rewrite of the compiler so that the object code is Javascript instead of DS bytecode. What you're saying would be akin to suggesting the current engine is written in DS bytecode, which is not a correct statement. What I'm suggesting is that the engine would, effectively, be written in DM itself (through standard libraries re-implementing the current default functionality).
I'm not following what you just said. I understand what you are suggesting, but I think we're talking past each other a bit.
In response to Ter13
Ter13 wrote:
I understand what you are suggesting, but I think we're talking past each other a bit.

I suspect you might not be, unless you have a misconception about what a port constitutes. If Dream Seeker were simply ported to Javscript, as an example, then it would be re-implemented in Javascript but still interpret the current bytecode. I'm suggesting the change that the object code of the DM compiler be changed to Javascript rather than bytecode, effectively turning Javascript interpreters into BYOND's virtual machine rather than Dream Seeker.

In fact, I've been running under the assumption that the Javascript client in production, apparently nearly in release, is a port. Am I mistaken?
I guess I should have been more clear: "A port of the current engine minus the DM bytecode, plus a new compiler that converts DM as a language to Javascript", would be ideal.

Though, that's quite a mouthful.

And yes, the new client is essentially a partial port of Dreamseeker intended to run in the browser. It's a lite port, though, as it doesn't include all of the functionality of DS. It only contains a limited subset of the interface foo. It's a bit of a tradeoff, though, as it supports a whole lot more in terms of native HTML/JS embedded alongside the client.
It seems to me that the main advantage of this would just be able to support single-player games, since I'm not even sure if it's feasible to provide server-based networking via the browser, given the limitations of the sandbox.

As I believe BYOND's true advantage is in multiplayer, I don't really see the point of devoting so many resources to accomplishing this. With the webclient, you'll be able to use javascript (full javascript-- not a "lite" version) client-side, which gets rid of one of the bigger issues we've had.

The big question to me is whether this learning curve will be worth it for users. And this applies to your project as well. At some point, you have to say, if we're expecting users to write a lot of javascript code anyway, at what point do they just decide to do the whole thing in javascript (or whatever) themselves? Especially if the server-side features that DM's "native" VM allow could be ported.
"The big question to me is whether this learning curve will be worth it for users."

70% of people can't/refuse learn DM. now there going to get javascript at them.
JS isn't as isolated as DM is. Tons of people know JS, tons of people would love to integrate their JS frameworks they use with BYOND somehow if they could I am sure.

It's unfortunate some cannot into DM, but there is less of an excuse to not into JS.
In response to Tom
Tom wrote:
It seems to me that the main advantage of this would just be able to support single-player games, since I'm not even sure if it's feasible to provide server-based networking via the browser, given the limitations of the sandbox.

Well, I'm not really suggesting that. While it would probably be possible to some extent, especially for games that are extremely resource-light, it probably would not be feasible in general. Instead, I'm suggesting that programs running as a client act as a wrapper around something like V8 with the potential for a compiler to output a .js file to allow for a purely in-browser experience. For the purposes of hosting a server, the client could either come packed with Node.js, or perhaps enforce the use of an analog of Dream Daemon for hosting, which has Node.js pre-installed.

Obviously, client-to-server and, possibly, client-to-client connections can be done through WebSockets, and server-to-client can be done the same way. Node.js would basically allow for the 'usual' server setup, and all of this could be done in plain Javascript. If Javascript were to serve as an object language for DM, then that means it could all be done in DM as well, without the (DM) programmer writing any Javascript.

At some point, you have to say, if we're expecting users to write a lot of javascript code anyway, at what point do they just decide to do the whole thing in javascript (or whatever) themselves?

Well, with what I'm talking about all this could potentially be done in DM, as it would be a 'complete language', though I don't have any rigorous way of defining that right now. As an example, CoffeeScript doesn't require someone to know Javascript to use it. DM with Javascript as an object language wouldn't either.
It's unfortunate some cannot into DM, but there is less of an excuse to not into JS.

The unfortunate bit, is that DM is easier than JS if you ask me. If people can't learn DM, they are already within a group of people that I would argue shouldn't program to begin with.

Honestly, now that the client-side stuff is going to be written in JS, it feels like it's time to ditch DM altogether and allow us to author our games in JS. JS is easily going to be faster than DM, given the facts that pop mentioned.
If you want to author your game in JS (although I'd suggest Dart), then you don't need BYOND at all.
In response to Popisfizzy
Popisfizzy wrote:
Well, I'm not really suggesting that. While it would probably be possible to some extent, especially for games that are extremely resource-light, it probably would not be feasible in general. Instead, I'm suggesting that programs running as a client act as a wrapper around something like V8 with the potential for a compiler to output a .js file to allow for a purely in-browser experience. For the purposes of hosting a server, the client could either come packed with Node.js, or perhaps enforce the use of an analog of Dream Daemon for hosting, which has Node.js pre-installed.

Right, and I'm having trouble seeing the practical advantage of this over the webclient, outside of single-player games in the browser, which just isn't possible in our current model but would work with yours. We can embed our existing server into a program with a CEF frontend (I've confirmed this -- just need more testing), so one could distribute a single- or multi-player game in that way. The more important browser support for multiplayer is basically pure JS already.

I'm not saying your proposal is bad-- all things considered it would be much nicer to use a more supported, modern VM-- but I'm just not seeing the real gains that it would provide in return for the massive, massive workload.

Ultimately, if we want BYOND to appeal to more professional developers, that falls more on replacing the language of DM itself. But at that point, you wonder if we even bring that much to the table. A pro dev working with a modern language and framework is probably going to want to have fine control over the networking, and the need to not have to deal with that is the biggest thing DM/BYOND bring to the table.
if we want BYOND to appeal to more professional developers

I think that's a mistake no matter how you phrase what comes after. We'll never appeal to pro developers.

The trouble, I think, is in appealing to more middle-of-the road developers, and having the language being something that does transfer outside of our little niche would be one of those pluses.

It reminds me of the reddit thread I tried to hawk on r/GameDev, resulting in a lot of people simply seeing no merit to a third-party language at all, and the rest jumping on board the "is shit engine" train.

I've made many attempts to teach DM at a higher level, but I can't help but feel like a lot of what I'm saying is missing the mark.
I don't think there's anything fundamentally wrong with using DM to make a game, regardless of whether you are an experienced or inexperienced developer. It serves the same purpose regardless, in that it simplifies many tasks you might not want to code yourself. But you have to realize that that comes at a price, and that DM is a niche language. When I see people try to make 3D games and such, I'm very impressed, but also thinking that they are sort of wasting their time because it's just not built for that.

The elitists on reddit and elsewhere most likely will never produce anything because once they start, they realize that it's a lot of work. DM reduces that workload a bit, and maybe that's enough to produce something. So far that is more theory than practice, but maybe this update will help.
In response to Tom
Right, and I'm having trouble seeing the practical advantage of this over the webclient

I'm not saying your proposal is bad-- all things considered it would be much nicer to use a more supported, modern VM-- but I'm just not seeing the real gains that it would provide in return for the massive, massive workload.

I suppose it depends entirely on the metric one uses to define 'practical advantage' and 'real gains'. My suggestion is a way to, at the bare minimum, potentially stave off what is currently an inevitability everyone with an ounce of sense sees coming. I wouldn't be surprised if the 'BYOND is dead' posts are still a biweekly occurrence, and I wouldn't count them as right, but they're certainly getting closer to the right diagnosis at a rate of once every two weeks.

While I really can't fathom what the current aims of this project are, they surely are not working, and you must be aware of this. I joined BYOND in January of 2005, and the height of it all seemed to be some time between 2007 and 2010. In that interval, a lot of quality developers have left, or have reduced their contributions drastically, and of the ones I know, basically everyone has the same reason: BYOND is going nowheere at an astonishingly-fast rate.

There doesn't seem to be a real concrete plan at changing this, just a lot of ideas that I'm dumbfounded are taken seriously.

Ultimately, if we want BYOND to appeal to more professional developers, that falls more on replacing the language of DM itself. But at that point, you wonder if we even bring that much to the table. A pro dev working with a modern language and framework is probably going to want to have fine control over the networking, and the need to not have to deal with that is the biggest thing DM/BYOND bring to the table.

This is an instance of where one can have their cake and eat it too, if BYOND re-implements its current default behavior in some sort of standard library, and allows its exclusion to developers who prefer to do such things themselves. Also, the language itself is not the problem. DM is a fine language, it's just that there are massive restrictions on it because of the back end.

I'm not saying such an undertaking wouldn't be massive. It's obvious to anyone it is. But at this point, there isn't any option that isn't going to be a massive undertaking and that will actually succeed in doing good for BYOND in the long term. Furthermore, allowing for input and assistance on such a project from the community could potentially draw back some developers who have left the project. Right now, you and Lummox might as well constitute a cabal, but the most boring and ineffective cabal I can recall.
Popisfizzy: my aim was to make something interesting and hopefully be able to make some minimal income that it could support its development. I think we did succeed in making something interesting. We managed to stay afloat, but didn't bring in enough income to grow. Part of that was never really getting an influx of users, but part was also not having a real business plan. Recently, we started running these commercial ads and they have done well on a CPM basis, and so the idea is that if people can get more game exposure (hundreds of thousands of plays as opposed to hundreds or thousands of plays), we will do pretty well.

What you and many others don't get is that I don't want to work on this forever. People make these huge dramatic proposals and sort of think "oh, they can open source it if it becomes tough", as if that is the answer to everything. The problem is that this requires an infrastructure, organization, and a hell of a lot of preliminary work. We can devote years to something while the "open source developers" drop off the face of the earth. Moreover, we have no idea if anyone would ever use this at all. It's just not a risk I'm willing to take at this point in my life. If you want to go out and write a javascript gaming engine, I think that is a much better approach. Your enthusiasm will be greater than mine, you won't have to operate on a backbone of old code, and, ultimately, all you lose is the small, dwindling community and some libraries that probably already have JS equivalents.


Me, I've taken the approach of trying to be sustainable, to keep the software stable, but legacy, and let users make the choice if they want to move on to brighter pastures. I think this next update is really cool and I hope to see some great things with it, but it is ultimately a wrapper around the existing server on the hopes that what it provides is still something worthwhile, and that what people really need is a better front-end for it and, most importantly, better exposure.
In response to Tom
Tom wrote:
When I see people try to make 3D games and such, I'm very impressed, but also thinking that they are sort of wasting their time because it's just not built for that.

=(

But... Dawncaster works so well!
In response to Tom
Tom wrote:
What you and many others don't get is that I don't want to work on this forever.

Considering you're somewhere in your 30s or 40s, you're content spending roughly a third to half of your life on it? At that point, it seems quite silly to think that in some way was not your goal.

If you want to go out and write a javascript gaming engine, I think that is a much better approach.

I actually, at this point, lost my interest in BYOND as a tool ages ago simply because it is completely unsuitable for far more things than it is suitable for. While I do not program extensively anymore as my interests have shifted from computer science and programming towards a much stronger focus on mathematics, I still do from time to time, and after a roughly two year hiatus from programming I was able to spend a few days brushing up on linear algebra and Javascript to create a basic 3D wireframe mesh, and am continuing on to do more complex 3D rendering.

I only state this to stress that I am already proficient enough in programming in general, and Javascript specifically, that I really have no need for BYOND because I can implement things BYOND does better than it can do. The only reason I brought this up is, because as someone who dealt in the long term with what DM is like, and as someone who has had an outside perspective, BYOND's niche is simply too small. You may call it grand and poorly thought-out, but I want to stress two things,
1) a grand scheme, especially one that involves a lot of hard work, are basically all that will keep this project afloat once goons either get bored of SS13 or develop a port of it, and once your star game developer's sparkling personality shines through and his PR nightmare hits, because this will be populated by anime and animesque games.
2) I already put more effort than it was worth by writing a meager thirteen paragraphs even proposing it. Even you seem plainly aware of the looming death of the software in the face of its irrelevance, which is already the case. So far as I can tell, this software is your largest work, and yet you have chosen defeat and letting it sit rotting in the dust while opportunity, or even an attempt at opportunity, passes by.

You can choose to be sustainable, but sustaining the mud hut in the face of the brick-and-mortar house is not noble, it's foolish. Best of luck to your project, but you've already seem to have come to terms with its passing.
Uh oh. It's turned into one of those threads again. This is why we can't have nice things.
Page: 1 2 3 4