Synchronization in multiplayer


#41

The game is not easy to write.
To make cheats you need to have: knowledge, spend time, bypass protection.

Any protection can be bypassed.

But why is it unnecessary waste of time


#42

Ah. Just saying that unless you’re doing a turn based game you’d want fast communication. The easiest way to do that is to have a central server (or a client that is “the server”). All clients send 1 piece of data to the server, the server updates it’s local state, also validating the moves to avoid cheating, and it broadcasts back to each client with an updated “map state”. That’s essentially just 2 transactions per update.

The alternative in doing it P2P is that 1 client must transmit it’s movement update to all clients. Which then each validate if the move was valid while transmitting the “map state” they got to each other. Then when validated they’d reply back with the result to each other. And then fire off the final map state.

Just to give you an idea of the amount of traffic needed for 1 move in either scenario.

Central server method: 2 network transactions (essentially) per move per client.
P2P with 4 clients: 21 network transactions per move per client.


#43

Note: there is a user that made an MMO style space game with Sim-Ethereal and has some thousands of players login at once… in a pure client->server style game.

To distribute over a P2P network larger than that you will end up implementing some kind of complicated meshing scheme.

Given that your first thought was “let’s send this with JSON”… you are already in the wrong mindset as you are still thinking “enterprise applications” instead of “real time game”.


#44

Lineage: client-serve
click -> send to server -> 10 seconds client calculate click.

Counter strike, quake: more real time…

Yes complicated but better productivity.

This is the question: What to use instead of json?


#45

Binary. Duh. You completely ignored everything.

Client server games, both of them.

Good articles:
https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
https://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization

P2P games with cheating compensation are very hard and even those games were for small P2P sessions of just a few players but with the cheating compensation distributed over the entire mesh.

…but you don’t want to hear any of this really… so just keep doing your own thing of using Strings to send your data and stuff. Let us know in 20 years when you have that all working.


#46

Quake and Counter Strike both use client server models.
Quake: http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking
Counter Strike: https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

P2P only increases productivity with things that are static. Such as file sharing. The way that works is that every person in the P2P network offers up a part of the file simultaneously. The issue with P2P in games is that what’s being “shared” is changing all the time. So for every update, everyone needs to be updated while other people are also updating and sending out updates.


#47

You talk about torrent architecture…

if i use client server: 100 player send message. server receive 100 messages and resend 100 messages.

100 players need to send 100 messages about other players = 100 * 99 messages

9900 messages in queue which must be executed (sended) in order

p2p + partial (level location):
3clients send to 3 clients message about yourself


#48

Sorry to disagree but you’re a bit confused. Let’s got over the process of server side communications step by step.

  1. Client sends an update to the server (1 message)
  2. Server receives it and updates it’s world state
  3. On a “tick” the server sends to every user an update to the world state which includes a compiled version of all state updates.(1 message per client [100])

Math in this case for 100 clients would be
100 updates inbound for every client per update.
100 updates outbound once every “tick”.

P2P method walk through.

  1. Client 1 sends update to 100 clients. (100 messages)
  2. Client 2 through 100 receives it updates its world state.
  3. Client 2 through 100 sends update to each client so they can validate that it’s a legal move (100^2 = 10,000)
  4. Client 2 through 100 sends back if the move was valid or not (100^2 = 10,000)
  5. Client 2 through 100 agrees move is valid and done.(100^2 = 10,000)

There are LOOOOOOOOADS more transactions happening per client.
The P2P method works out to roughtly 30,000 updates for 100 clients for 1 players movement.
You could cut that down by not validating moves, but boom, right there, cheating can happen. Especially if you’re using straight up JSON to transmit this stuff in plain text hacking it could be done by even the lowliest of hackers.

If you need more convincing though…

EVE Online: https://community.eveonline.com/news/dev-blogs/tranquility-tech-3/
World of Warcraft: http://electronics.howstuffworks.com/world-of-warcraft.htm <-- Recommend reading this as it explains how they handle transactions.


#49

H@H@H@H@ =))))))))))

good idea send the general state of the world in one message…

You think in lineage accept this strategy?
When we spend time analyzing a large package. )

I think is simple better and faster. Thanks


#50

So just to give you some background into what my day to day job is I deal with handling of real time security information for large enterprise networks and aid in designing the networking and systems that deal with data rates that would saturate any home network connection. I’ve been doing this for 10+ years.

Soooo ya.

Enjoy sorting out your mesh.


#51

And this is exactly what kills most games before they launch - spending time trying to improve technology (that many people before you have tinkered with and shared efficient solutions for), when you could be spending that time creating the game you want. In all of this, you are not in any way improving the gaming experience - and thus not making any headway to keep players entertained in your game :slight_smile: Best of luck in this endeavor.


#52

а здесь по другому никак :wink:


#53

Yes. I use general solutions.

But this does not save me from drawing 3d
And writing game logic


#54

https://youtu.be/uPFTDR4qlMY


#55

Bug
https://www.youtube.com/watch?v=7eRVFAFYU-Y

  if(!characterControl.getPhysicsLocation().equals(startLocation)){
                 characterControl.setPhysicsLocation(startLocation);                 
   }

sync physicsLocation


#56

Small tip: pspeed is nearly always right.

For what it’s worth when I said a board game I meant with a cardboard board and a real plastic dice.

Anyway good luck, worst case scenario is you learn a lot :slight_smile:


#57

H@H@H@ =))


#58

synch physical position between character and bot if capsule not move and on ground

  if(!Down & !Right & !Up & !Left & characterControl.onGround()){
            if(!characterControl.getPhysicsLocation().equals(startLocation)){
                characterControl.setPhysicsLocation(startLocation);
            }
 }

work better and best.


#59

It does not make sense to post more on this topic as you ignore all advices. or is this thread your diary?!


#60

I’m not ignore advice’s. I read I took all.

But i use my server. I spent a lot of time writing my server. It’s easier to transfer your own than. Put a new one.

The benefits of this topic:

  1. Don’t use json - but what use for send arrays and variables - It should work faster. -
  2. It is better to synchronize with one large packet (Which contains all users). +
  3. To reduce the number of packets from the client to the server - send the data only if the model has changed. +
  4. Synchronization of the physical position must be done when the object does not move and when the packet has been changed+

  1. There was not an resolved question how to transfer data faster than json?
  2. Is it worth it to spend time on compression and encryption?

PS: I think this topic will be useful to those who solve the same issues.
Thank’s