Feature - CodeCubes or "ModVoxes"

[kumavis]

-Special voxels that have an associated hash of event handlers -Various game events trigger calls to the corresponding handlers:

• game tick
• collision
• activate (from a click-to-activate interaction)
• player proximity

[kumavis]

So how to handle responsibility, location (server/client) of code evaluation: "the Creator Model": have the code only run on the client that created it. Continuing on to advanced functionality, it can register with the server and get remote events from other users (proximitys, activations clicks, collisions) and have them forwarded to the player.

[kumavis]

Other models might be: "Server Model" - all code is run on the server. "Every Client Model" - all code is run on every client, depending on the event. If you activate it, it runs on your client. For things like game tick, this could be crazy. It also expects code to be deterministic, which is crazy, though not impossible.

[kumavis]

There are also "Hybrid Models" that could solve the problem by running the code in different places depending on the nature of the event. Game tick on server, collision, activation on associated client.

[kumavis]

"The Creator Model": scales well (supposedly) "Server Model": scales poorly (supposedly), more security risks. "Every Client Model": likely just chaos. "Hybrid Model": Oh my god its full of stars.

[danfinlay]

Long term I think privileged users, like mods or members should be able to change the code of their server instance itself from within the game, and that would definitely require server-side code running.

In the short term, or for lower privileged users (long term), why not expose a higher-security API that is less about code evaluation and more about allowed behaviors?

Once we have a permissions model, mods could add their own user hooks to their server, so a user permissions system is definitely a clutch feature.

Small-scale block manipulation changes: Probably the creator model, to minimize processing load on the server over trivial bit pushing.

The ability to send out code for all other users to run seems like a pretty administrative ability, I don't think most servers will choose to make that a public power.

Coming back to the short term, the act of just creating/destroying blocks to start, what is the fastest way to propagate the changes? First I'd come up with SOME variable to throttle the change rate or quantity, like no more than x blocks created/destroyed per user in y milliseconds. Below that threshold anyone is allowed to make changes, and that lays the groundwork to add more privileged users right off the bat.

From there I'd also be instantly interested in chunk compression methods that we might employ. I know this essential algorithm is being used in voxel-engine already, and I bet @mikolalysenko could help us set that up. In that case you could have a client test run their own code on firing, then have the changes they made compressed and sent up to the server for propagation.

To make this smooth even with longer looping or intervaled scripts of changes, we would probably want a client tick on which frames of that user's changes are compressed and sent to the server. It could be packaged with their movement data. On the client you'd just have to id changes so they can be reverted on server rejection.

Ok this is getting long and you sent between paragraphs, I'm going to send this so you know I didn't sign off, I think I have more to say...

[danfinlay]

Meh, that's it for now, this is a really exciting project.

[kumavis]

as it is, there is only one voxel-modifying method exposed, setBlock this could be used in order to cap the volume/rate of voxel changes

[kumavis]

Code-cubes currently run on the client's machine. This is fine, but should be sandboxed.