New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Client/Server Replication: How? #254

Closed
PJB3005 opened this Issue Jun 26, 2017 · 4 comments

Comments

Projects
None yet
3 participants
@PJB3005
Member

PJB3005 commented Jun 26, 2017

Currently, Shared has no good way to send things over the network, and Client and Server are a mess about it. We need a sane API to be able to replicate things over the network.

First let's think about what needs replication:

  • RPCs (Remote Procedure Calls), basically calling a function on the other end of the connection.
  • Property Replication: making properties or fields on objects be replicated. Right now components and entities do this via a state system, the states are in shared and the component implementation are on the client and server. This is cool but we need a more generic framework that's easier to work with.

There's a few things to consider here:

  • To what extend should this go? Should it be just entities, components, etc...? Should it be on most managed objects like system managers (chat manager for example?)
  • How do we ensure security, preventing people from cheating? Ownership?
  • Client prediction?
  • Performance?
@psykzz

This comment has been minimized.

Contributor

psykzz commented Jul 3, 2017

How about just setting replication flag to true.
Items are then automatically synced between client and server.
Any function called on server, should call on client, they regularly check in to ensure this is happening.

Update frequency and priority should also be some definable settings.

@PJB3005

This comment has been minimized.

Member

PJB3005 commented Jul 3, 2017

@psykzz it's not that simple.

For things like the chat manager you would want both a client and server version (some level of replication) but you wouldn't send everything by a long shot.

@PJB3005

This comment has been minimized.

Member

PJB3005 commented Jul 9, 2017

Ok so I'm thinking this is a good model for how to do networking as an API.

We already have shared, client and server. The primary part of the content communication between client and server happens through shared, and the client and server specific code are obvious.

Let's make an example.

  • Client A clicks on a door.
  • Client side code checks where the click happened and determines what object got clicked.
  • The client calls a clicked event on the mob or client it has "I clicked this". This click event exists in both client and shared.
  • The client and shared code for the click event. The client does nothing yet. For shared this event gets relayed to the server.
  • Server acknowledges that client A clicked door. Verifies that A is conscious, in range of door, has access, etc...
  • Server multicasts an RPC "Open()" to all clients that should be aware (close enough to the door to see the effect, etc...)
  • Clients receive the open function, and all play the animation (including A who triggered the event). They all change the icon, but this change is local to the client.
  • Meanwhile on server land it does everything the server does I guess. Once it's done it sets the icon to the open state of the door.
  • This icon change is replicated to all clients again, even ones that got the open event. This ensure that even if a glitch happens, the worst that happens is a glitched animation and no desynchronization.
  • That's about it and everybody is happy.

Actual netcode transfers are in bold. Note that there's only two types of transfers: replication and RPCs (remote procedure calls).

This chain of events is inspired by how UE does net code, too. The advantage is that you can write all code on server without issue and the icon changes are replicated like BYOND, or you can do animations on the client and be more responsive.

@PJB3005 PJB3005 added the W: Design label Jul 10, 2017

@Acruid

This comment has been minimized.

Contributor

Acruid commented Oct 25, 2018

We have this figured out, if you need some specific network thing implemented open a new issue.

@Acruid Acruid closed this Oct 25, 2018

@wafflebot wafflebot bot removed the W: Design label Oct 25, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment