ID:1927578
 
(See the best response by Ter13.)
Hey
Considering a return to BYOND, I've glanced over the changelog, but not sure I've answered all my concerns and questions - so here I am! Hopefully you guys can help...

* Does BYOND support client-side input yet? If not, is there any information on whether or not future releases will support it? (This would be primarily so that players could navigate a GUI with ease, not having to wait half a second per action).

* Whats the progress towards multi-platform releases? I understand that a while ago, porting to things like Android and standalone clients were in the works. I see NEStalgia is on Steam now, so there has clearly been progress. Where do we stand?

* How viable would it be to make a game on BYOND where spells are cast by left clicking the map? Not sure if this should be a separate question - but what about mouse-based player movement? (In a competitive MMORPG/MMO combat environment).

* What are the most notable features or improvements made to the client in the last 3-4 years?

And lastly, other than familiarity - why should I choose BYOND over other game dev platforms (the only one of which I'm aware of is Unity)? Alternately - are there any other ones I should look into?

Thank you to those who reply; and sorry if this isn't strictly the right forum for 100% of this content, but a) I couldn't think of a more suitable one, and b) places like "Off Topic" don't see a lot of users...
Best response
Does BYOND support client-side input yet

Yes. The webclient allows client-side interface-foo, and DreamSeeker now allows you to use javascript to perform winset/winget calls, so a lot of interface business can be done on the client-side.

Whats the progress towards multi-platform releases?

The webclient runs in the browser, and can therefore be used on Linux, Mac, Android, and possibly IOS. Standalone is still windows only.

How viable would it be to make a game on BYOND where spells are cast by left clicking the map?

Entirely and has been for over a decade.

(This is recorded at 20fps, but runs at 40fps)


but what about mouse-based player movement?




What are the most notable features or improvements made to the client in the last 3-4 years?

Client-side visual effects via Animate(), a huge number of bugfixes and performance improvements. Pixel movement natively built-in, the ability to rotate objects using matrix transformations, the ability to dynamically change the color and blending modes of objects without generating new icon objects, the ability to change the transparency of objects on the fly, better mouse tracking and mouse wheel support, and a metric boatload more.


And lastly, other than familiarity - why should I choose BYOND over other game dev platform

Ease of use. Unity's nice and all, but BYOND gives you quite a bit right out of the box that you'd have to spend a lot of time writing yourself in just about any other engine.
In response to Ter13
I really like the second picture with mouse-based player movement, I'd be cool if you turn it into a library.
The webclient is the big news, because it's based on the old Flash client, but updated and brought to fruition. It will run on pretty much any modern browser including on tablets, and it can do almost anything Dream Seeker can do (plus a few things it can't).
In response to Zasif
Zasif wrote:
I really like the second picture with mouse-based player movement, I'd be cool if you turn it into a library.

Just code it man. It's not difficult.
It's not difficult.

Took me maybe 45 minutes.
In response to Ter13
So... is that a nod to turning it into a library at some point? =D.
In response to Ter13
Ter13 wrote:
What are the most notable features or improvements made to the client in the last 3-4 years?

Client-side visual effects via Animate(), a huge number of bugfixes and performance improvements. Pixel movement natively built-in, the ability to rotate objects using matrix transformations, the ability to dynamically change the color and blending modes of objects without generating new icon objects, the ability to change the transparency of objects on the fly, better mouse tracking and mouse wheel support, and a metric boatload more.

Huh? I checked the Ref and there's nothing in there saying that animate() is client sided? Is this true? That's huge news! :O
I checked the Ref and there's nothing in there saying that animate() is client sided? Is this true?

Basically, how it works is that it breaks up the animation into a series of appearances. The server then communicates that series of appearances to the client, and the client flips through them over the specified duration.

It's still pretty intense on the server compared to doing the animation manually, but it does take quite the load off the scheduler and it ensures that the animation will not be delayed by network hiccups for a smoother end product.
So the server still does the calculating?

Damn.
So the server still does the calculating?

Think of it like a flipbook. The server makes the flipbook and ships it off to the client, the client then thumbs through the flipbook once, throws it away and adds to the pile of useless commodities that our society is slowly destroying the planet with.
In response to Turboskill
Turboskill wrote:
So... is that a nod to turning it into a library at some point? =D.

... =(.
The server does not do the interpolation. (It used to for the webclient, but it doesn't do that anymore. There is however some leftover cruft regarding transitions that I need to pull out.) When you call animate(), the server basically sets the vars for the object you're animating, and keeps track of the before and after appearances. Subsequent calls without specifying an object will create new animation "stages" (equivalent to keyframes).

The only real drag on the server is basically that it has to set those vars and create the keyframe appearances, but that's it. The client does all of the interpolation work.
In response to Ter13
Ter13 wrote:
Think of it like a flipbook. The server makes the flipbook and ships it off to the client, the client then thumbs through the flipbook once, throws it away and adds to the pile of useless commodities that our society is slowly destroying the planet with.

I understand, but I thought what you meant was that the client does all the actual calculating of differences and icon operations, taking the huge bulk of that load off the server's hands. Instead the server still does it, and then hands the client a big list of states/frames/modified icons and says "Play them in this order, no matter what".

That's still an improvement, but when will be the day I can freely spam particles in large scale games without worry :(
In response to Lummox JR
Lummox JR wrote:
...

Oh or not! That's fantastic news! You should mention that in the reference somewhere, since as far as I recall runtime heavy icon operations was always a large drawback of BYOND due to the server strain it would cause.
The only real drag on the server is basically that it has to set those vars and create the keyframe appearances, but that's it. The client does all of the interpolation work.

Okay, good to know.
In response to Rushnut
Rushnut wrote:
Oh or not! That's fantastic news! You should mention that in the reference somewhere, since as far as I recall runtime heavy icon operations was always a large drawback of BYOND due to the server strain it would cause.

I'll take a look at the reference.

Regarding icon operations, a lot of those are also color-based. Client-sided color multiplication is actually entirely possible right now thanks to the atom.color var, and I'm working on expanding atom.color to handle full color matrices.