As the title hints, I am currently trying to create a little multiplayer game as a project, just to learn more about all the skills required.
All of this jappens in Java: I am not sure on how to handle the server communication. Currently my world objects are saved as an ArrayList containing a self written class "Entity". It is displayed through painting every image from an entity to a frame according to its coordinates. All of that works just fine. Here comes the Question:
With every change of the world, e.g. movement of any entity, should I transfer the whole ArrayList of entitys to every player, should I just send the changes and then only update the changed entity, or should save the world on the server instead of the local mashine and send the input that causes the change, e.g. WASD for player movement?
I think I read something about outsourcing as much as possible to a local mashine, but on the other hand I assume the transfer of the world information would be faster if everything happens on a server instead of the client.
Thanks in advance
In a multiplayer game speed is the number 1 priority. Everything that somehow adds overhead, slows down, needs loading or permanently transferres big data chunks is to avoid at any cost.
I would definately save the world coordinates and stuff on a server, while textures and models and the like should stay on the client. Now the client can load the world and inject all the stuff there, build a nice gui, all this stuff. This won't draw network connectivity. The server, however, must know the quarternion of every 3d object (assuming you use 3d), so f.e. :
PLAYER_A:
posX : 3,
posY : 3,
posZ : 4,
rotX : 30°,
rotY : 60°,
rotZ : 10°
To avoid having to send 6 messages to the server (who then broadcasts it to the other players), we invented quarternions (6-dimensional objects). But I doubt that java can use this out of the box, so you have to come up with a solution yourself. You should think about stuff like "forwardspeed" and "jumpvelocity" too, since it is easier to have this computed on the client's mashine.
Now, grab an object, however you call it, and send it to the server.
The server now knows "player a is at xyz, facing abc".
The server then relais this to the other players, who get the information hopefully in time (so always try using UDP and ignore data package loss) and will compute and animate this on their side.
If the delay is small enough (aka 20ms f.e.), the players will experiance this in "real time" (although there is no real real-time)
Tl;dr : Always try sending as little as possible to the server, and have the server broadcast it to the clients. They can then "recalculate" the animations on their own.
EDIT: Of course you would need kind of an update() routine that periodically sends world object information to the server, too, so f.e. the location of trees etc. While the client can despawn these entities when they are out of sight (and i REALLY encourage you to do so), the server still needs to know the complete map layout (that is, without textures and stuff, this would soon get really big)