CODEWITHSUNDEEP
javaandroidsocketsreal-timemultiplayer
nemocean
nemocean

Reputation: 179

Real-time sockets in java

I'm trying to write multiplayer game for Android with java back-end using sockets, but I don't know how to do some things.

For example, I have to players. First player pushed "UP" button and his avatar moving up. How can I tell about it to all other players?

I can send message, that user with some ID changed his coordinates to new X and Y, but I will need to do that for every millisecond while he moving. Is that right?

Or I can send message that user with some ID pushed UP button and after that new message that user released UP button. Using time difference between this two events and movement speed I can calculate new coordinates of user, but in this case will be problems with latency (time difference calculation will be not enough accurate) How I can do that?

Upvotes: 1

Views: 1869

Answers (1)

zapl
zapl

Reputation: 63945

You can do it in lot of ways and all will have drawbacks like you already found. I guess there is no "best" way to do that.

A common way for games is to have a "game server". The server recieves input from all clients and decides about the resulting state.

Clients could for example just transmit the keypresses and the server tells them about their location and location of other clients that need to be drawn. Clients do the same math locally and display this state while waiting for confirmation from the server. But that's just a prediction.

When it lags you can observe yourself jumping between positions in a lot of games because actual server calculated position and your prediction got out of sync.

The other advantage of server-side state decisions is that clients can't cheat that easily. It's no foolproof way to prevent every cheat. Aim-bots for example simply simulate a perfectly aiming user by moving the mouse for them and that's basically not detectable. Map hacks / wall hacks (anything where you can see things that you would not see) on the other hand can be prevented by simply not telling the client about currently invisible things. Only the server needs to know the full state.

The server approach can also be used without a dedicated game server. Instead, one of the clients will have the role of the server and decide about the game state. That responsibility can in some games even switch between clients if the original host drops out. A smooth handover if that happens is rather tricky though.

If there is no server and all clients are equally responsible you will have to think about schema which defines which client is responsible for validating which action. For example in a shooter, A shoots in a certain direction, and thinks B is still there but B already moved a bit further and now A thinks "B was hit" and B thinks "shot missed" -> Either the one shooting or the one being hit should decide what happens.

A schema with multiple decision making parties might not work for every game and it is a very complicated task. Not just for games but distributed computing in general

Java and Sockets are just tools here. The actual problem is one where you should take pen and paper and think about a schema that works for your scenario.

Regarding coordinates every milisecond: you could also send messages like "I will be at point X,Y at time Z" and other clients interpolate the path of that player so you don't have to transmit every position.

Upvotes: 5

Related Questions