Explicit Client-Side Leveraging

Jul 9 2016, 2:38 pm (Edited on Jul 9 2016, 2:45 pm)

In all honesty, BYOND's networking and server-client setup were designed around pre-2000's architecture if I'm not mistaken, so if anything, an update to the client-server handling would do nothing but good for the engine's life expectancy.

Okay, you aren't hearing what I'm saying. Or understanding what I'm typing, as it were. I'm not shooting down your idea or saying it's not possible. I'm challenging you to flesh the idea out. I'm including myself in the discussion because I've been down this road a few times with Tom. I'm interested in the feature. Let's flesh out the request into a workable idea, ok?

I'm asking how do we semantically include it in the language?

Jul 9 2016, 3:32 pm (Edited on Jul 9 2016, 3:56 pm)

In response to Ter13

Kats

That's the tricky part. I would think that the solution that would be the simplest for developers to use would literally be something like a set value, but the backend on that would be an absolute nightmare, more than likely. If all you'd have to add to a proc to have it recompile into something usable client-side was using something like set client_side = 1, that would be a dream-come-true. I wouldn't hold my breath for that, though.

I think that, honestly, the easiest solution to make it doable for everyone would be to open up BYOND's networking systems and make it more transparent and actually alterable. If we had direct access to BYOND's networking, then we could just set out and write our own game clients with ease.

Some people are going to argue that that would completely ruin BYOND's ease-of-use, but that's just ridiculous. Pixel movement didn't ruin BYOND's native tile-movement. It wasn't a complete change, it was an add-on. If you left the code alone, then you get the default tile-movement. It's not until you explicitly start working with the pixel movement do you actually have to worry about handling the pixel movement. Networking would and should be on the exact same footing. Default of totally server-side until you started to mess with it.

The key issue that I would foresee with that, though, is that there's a lot of backend networking that isn't just sending and receiving commands. I think having a default "render" packet would be key to keeping it relatively simple to use.

Say you write both your server and your client. You could send the "render" update every tick by default to whichever client you want. The client receiving that could then take that render data and plug it into the map, giving you the view of how things should look. That way the developers don't actually have to worry about sending each individual packet of data necessary to know where to draw everything on the client's screen. BYOND already has this "screen update" communication. The developer realistically shouldn't ever have to mess with it, in all honesty. It would be essentially plug-and-play.

Going even further, I think it would be even easier to just default to having a one-time socket and listening function between the server and the client. The connection would be continued on the backend.

Client setup might be something like

game_client
   var/DM_Socket/socket //DM_Socket being a built-in class for handling connections.
   connect2server() //custom function
      ConnectRenderSocket(target_address, target_port, credentials, other_data) //built-in BYOND function to receive rendering data
      socket.Connect(target_address, target_port, credentials) //sends a connection request to the server

The server wouldn't need an explicit response to the ConnectRenderSocket() function. That would be something just automatically handled on BYOND's backend. It would require the server to have an explicit listening port for the client, though.

The credentials essentially being just extra data being sent in the connection request. It could help you determine server-side whether it's a client-server connection in the case of a player trying to connect to your game or if it's a server-server connection, where you're managing a larger cluster.

I know the discussion turned more into a "open up networking functions", but honestly, I think that's where the vast majority of the improvement could be. We can do whatever we want with clients and servers, it's just the fact that we don't currently have a reliable way of communicating between them is the main problem.

Jul 9 2016, 10:52 pm

MisterPerson

Zoinks, that's more than I was thinking. Ultimately all we really need is just mitigation of latency. If we could have certain rendering-related things happen instantly for the client, that's really about all I personally would want anyway.

This page and especially the video at the bottom demonstrates the problem and this one game studio's solution, although there's obviously many more: http://www.factorio.com/blog/post/fff-83

That solution wouldn't work in BYOND because BYOND clients are thin and don't actually know anything about the game state though. As for solutions that work in the BYONDverse, I was mulling over being able to set input callbacks that would create temporary images or something, but that screams workaround.

Jul 9 2016, 11:10 pm
Lavenblade	I don't know why we'd want to open up networking functions... We already have networking done for us, and any server to server stuff we need to do can be done with world.Topic()... What we need is the ability to write client side code- As for world.Export() being slow, we need a speed-up for performance there and ssl support.

Jul 9 2016, 11:20 pm

MrStonedOne

Ya. This basically starts by looking at how much game state we can get away with pushing to the client side code.

(tldr at the bottom)

First up, is adding a client side gatekeeper to client initiated actions. Things like macros, key presses, gotos, mouse positions, browser window state. all of those could be manipulated in client side procs with no regard to server side state.

Expand via gateways for data, ways to make the client(s) aware (as selectively or not) certain pieces of gamestate if they might need it to act (something that has to ask the server isn't any better then just having the server do it, so this would be push based, not pull/poll based.)

Now you can decide when mouse hover or mouse move events even go to the server, or when key presses or verbs go to the server, and what command they go as, all in a client side proc/verb. (Maybe you want to show a borderless browser control to do fancy tool tips, no need for that to be server side, as almost all state is exclusively client side)

After you add that, you then expand to animation state. This isn't tracked server side that much, but all clients know it. So a proc that could read animation state or appearance vars and act or change that (maybe making a loop'ed animation end or speed up or change to a certain frame), could run client side with almost no issue.

Sounds are another thing, the sounds to play is server side, but once they start playing, their state, position, repeatability, etc, is all tracked client side with the server out of the loop.

So, now comes the fun part: How?

As you can guess, this would be a seperate language, most likely dm in syntax, but 100% new commands.

Then you need to work on how you can pass messages back in forth, you might make it so the client code can see info about what is displayed, but only appearance vars exist on the client, so you might add server side info that is sent with that object (if it exists) so mousehover/click code could look at that if need be. Then a way to send messages to the server (non-blocking 1 way, no return value, just send and forget) as well as a way to get messages from the server.

Add in dm's existing syntax and commands around datums, variables, and what not for client side stored data, and some basic timer and event support (potentially a way to subscribe to certain events like loc changes of the client eye, client ticks, stat updates, etc).

TL;DR: The way to do this, would be to start small and work your way up. A super limited client side scripting engine, most likely DMish, with vars and data structures and proc and all that goodness, then add communication frameworks, binding to events, and on and on and on release by release.

Jul 9 2016, 11:25 pm

MrStonedOne

world.Export() isn't slow, it just sleeps until the game tick following when it gets a reply, and if that server is localhost or on the lan or in the same datacenter, that server reply could come within the same tick, but world.Export()'s code doesn't know that, so it will wait for next byond tick to check.

if you could do send and forget with world.Export, avoid the sleep, and get the reply via world.topic() that would be a step forward.

world.topic() is another thing that i think is tick based, so you would also need a way to make that be the same as an instant verb where it can happen outside of a tick. or maybe thats already the case.

Jul 9 2016, 11:32 pm

In response to Kats

Kaiochao

Since a large number of developers, myself included, strive to use as little of BYOND's .dmf UI as possible,

That UI is irrelevant when it comes to the webclient. The webclient is fully customizable since everything is written in JS/CSS/HTML.

we usually default to HUD objects, which to my knowledge, is still being calculated server-side.

There are plenty of HUD UI effects you can do that are fairly cheap that you can use animate() for, such as sliding around, fading in and out, and resizing. They shouldn't really be a bottleneck since they're not likely to be continuously computing things every frame, or doing a whole lot of calculations in a single frame. The matrix operations that call before animate() are done server-side, but once you call animate(), all the animation from the start to the finish is done by the client.

And, of course, webclient UI (as well .dmf UI in Dream Seeker) is perfectly responsive because all the logic runs on the client until you call server commands. Dream Seeker skins might look bad because they don't conform to stretched pixel art resolution or that they appear to come from the dark ages of Windows, but the webclient doesn't have any of those issues.

Even with the webclient, it's the fact that we wouldn't use these UI features in the first place is why we don't really care that they're there.

The webclient is something you have to design for. If you're planning to (hopefully exclusively) use the webclient, you're gonna have to do some work to get it looking as good as you want it. If you're planning to use Dream Seeker and HUDs, sure, you can put in a lot of work, but no matter how much work you put into it, you're never gonna get something better than what you could get in the webclient. That's what it means for the webclient to be fully customizable; you have control over every single pixel shown to the user, and it runs on the client.

There's absolutely nothing saying that the default setting for a proc or something wouldn't be to be completely server-side, but allow the developer to explicitly make certain operations client-side.

It's definitely not going to be as easy as saying "this proc runs on the client". MSO knows what's up.

Even if it does get added "to the language", it's going to have to be a different (but possibly similar) language, developed as a different language, and interpreted by an entirely new client-side interpreter, so why not just use JavaScript?

Jul 9 2016, 11:47 pm

In response to MrStonedOne

MrStonedOne

The end goal would be to slowly make it so a client could (if the devs wanted to go thru the effort) do the following:

client side macro pre-processing (does the macro go to the server at all? does it trigger multiple verbs server side? maybe loops thru sending them)

client side mouse-event (pre)processing

client side skin control opening/closing/moving.

Tie the previous two in for client side tool tips

client side pre-processing of browse() data.

client side additional decisions on visibility (maybe we don't let certain clients see certain things calculated client side (exploitable, but wall hacks already exist for byond, so that's not opening a new pandora's box))

client side limited manipulation of animations()

client side limited manipulation of appearance vars (it would just convert to a client image with override)

and the grand finale: (tricky, but doable)

Client side pre-moving of atoms in anticipation that the server will move (IE, moving your own mob client side after sending a movement verb event because you were able to check that it would be allowed to move)

Jul 10 2016, 12:29 am

In response to Lavenblade

Kats

Lavenblade wrote:

I don't know why we'd want to open up networking functions... We already have networking done for us, and any server to server stuff we need to do can be done with world.Topic()...

What we need is the ability to write client side code-

As for world.Export() being slow, we need a speed-up for performance there and ssl support.

What I'm saying is that by opening up networking and giving us the ability to run things at full speed without tick waiting, then we could have already worked out client-server models a long time ago. It wouldn't be in the same breath as native client-code support, but making it work wouldn't even be difficult.

Jul 10 2016, 1:01 am
Lavenblade	Wouldn't that take away the ease of use for newbies?

Jul 10 2016, 2:24 am
MisterPerson	That will still be there. Optional features by definition do not take away anything from those who opt out.

Jul 10 2016, 2:28 am

In response to Lavenblade

Kats

Lavenblade wrote:

Wouldn't that take away the ease of use for newbies?

Kats wrote:

Some people are going to argue that that would completely ruin BYOND's ease-of-use, but that's just ridiculous. Pixel movement didn't ruin BYOND's native tile-movement. It wasn't a complete change, it was an add-on. If you left the code alone, then you get the default tile-movement. It's not until you explicitly start working with the pixel movement do you actually have to worry about handling the pixel movement. Networking would and should be on the exact same footing. Default of totally server-side until you started to mess with it.

Jul 10 2016, 5:12 am

Multiverse7

You could make a "DMified" dialect of JavaScript, but JavaScript is interpreted directly, while DM has to be compiled to bytecode that gets interpreted by a virtual machine. Is it even possible to reconcile these entirely different systems?

There might not be a solution to this, unless hosting dmbs directly on the web becomes a thing. With a portable hosting solution, I think there would be a path to integrating the client with the server. This would also allow us to make single-player games for the web.

BYOND's development puts the cart before the horse, but that's part of what makes it so unique and interesting. The problem is that the cart is being pushed by a mouse rather than a horse. It's a miraculous wonder that it even works, and has lasted for so long.

Jul 10 2016, 11:51 am In response to Multiverse7
Kats	Multiverse7 wrote: It's a miraculous wonder that it even works, and has lasted for so long. Technology fortunately doesn't usually run into the same aging problems as other products. Still, fact of the matter is that BYOND is running with technology as old as I am, which probably doesn't help.

Jul 10 2016, 2:38 pm

Lummox JR

Just to toss in my two cents on this, my thoughts are in line with what Ter said: How do we incorporate this into the language, semantically, and how could this be setup in a workable way on the client end?

One important question in all of this is: What would users want to get out of client-side processing that might be a reasonable goal? For instance, setting mouseover text or cursors for an atom? Changing maptext? Responding to certain clicks and mouse commands? Setting off N particles at once that don't exist on the server and therefore don't act as objs for movement purposes?

I think some kind of limited client-side stuff could be done with special temporary objects and with partial appearance overrides (much like how animations work, but wider in scope). The more difficult part would be copying the interpreter to the client end to work with client objects (though I envision it only handling some partial stuff), and then maintaining the interpreter on both ends. And that'd have to have some consideration on the webclient as well.

Jul 10 2016, 2:48 pm

In response to Lummox JR

Kats

That's why I more-or-less through out the idea of just making the networking features more reliable. To my knowledge, it would take a lot of writing and rewriting to just get something as limited as client-side temp objects to be created and handled properly.

I personally have no issues with writing both a custom client and server for a project, it's just the matter of communicating between the two that causes the core of the issue.

I personally just think it would be both easier for you working with the engine and for developers to have access to a broad solution to a lot more issues than just making things explicitly client side.

I know it sort of side-tracked from the original topic, but I honestly do think it's the easiest and arguably best solution we have.

Jul 10 2016, 3:35 pm In response to Kats
Lummox JR	To be honest, I can't make heads or tails out of the network thing you suggested. It doesn't make any sense to me in the context of BYOND's networking.

Jul 10 2016, 3:41 pm In response to Lummox JR
Kats	Well, to be fair, I have no idea how BYOND handles networking on the backend. I just assumed that you had specific data for telling the client what needed to be drawn on their screen and other basic networking stuff.