Is there a best practice to persist changes to scene on the server?

[ghost]

The minecraft demo is impressive for multiplayer games. But how would you implement a server feature to store the changes made by the users in a session on the server and loading them when a new user connects?

Currently the changes on the scene are sent via datachannels directly to the other users, am I right? So there is no way for the server to protocol those changes because the server does not see what happens in the scene, correct?

How should one implement such a persistence feature? Should the server "join" the room as a client to get the changes via a data channel? Or should one client forward the changes to the server via an easyrtc event message?

The websocket adapter sends the messages via websockets which the server can react to. That would be a place to start but with this adapter I cannot use audio.
In NetworkConnection.js:36 the adapter is forced to use datachannels if available. Would it be possible to define the use of datachannels as an option at initialization? So that I can use audio chats AND server side persistence?

btw.: Great work. Looking forward to use it in different projects.

[haydenjameslee]

Yes that's correct re: datachannels.

There are many ways to do state persistence. You could use a service like firebase, or write your own server to manage it, or use the same signalling server. There's certainly no best practice.

I would start with firebase personally.

[haydenjameslee]

I think it'd be really cool to make a persistence framework on top of NAF (if anybody is looking for project ideas).

[HeadClot]

I would recommend looking into apatite.js opposed to reinventing the wheel so to speak. I would try to get that to work with networked A-Frame. It already works with Nodejs and a bunch of various databases already.

[vincentfretin]

In the janus adapter you can specify for reliableTransport and unreliableTransport "datachannel", "websocket" or a function to use another server. It would be great to have this option on the easyrtc adapter too.

[vincentfretin]

There was a discussion about that on this twitter thread https://twitter.com/vincentfretin/status/1502322662571487236 where I wrote some comments.

[vincentfretin]

With websocket transport you can do whatever you want on the server side to handle um (list of entity updates), u (entity update), r (entity removed) messages with persistent: true (isFirstSync: true when spawning, then false if the entity is moved) to persist the spawned entities in the room. Each entity has a random networkId.

[vincentfretin]

You'll probably want to keep a Map of persistent entities with networkId key in memory, with a dirty flag when you modify it and throttle saving that Map in a postgres json field. This is what I would do.

To load this json and create the entities when you join a room, see #265

[vincentfretin]

To persist in postgres, we can use the open source https://supabase.com that has a similar api than firebase, probably with a docker-compose file to setup the needed containers. But having a full example with it may be out of scope for this repo.