Alright, so I've been working with Java for quite some time and I'm trying to branch of into sockets now. I know the basics of them you could say, I built a working multi client chat on my own with the help of the Java docs on their site, not copy and pasting from some tutorial on the net. So I have potiential I would say. Anyways enough with the rambling. I'm trying to socket player movement now, and I'm a little bit stumped.
I was thinking about sending the x,y value of player to the server when a corresponding key is pressed and then have it send it back to the clients and add an image to those coords. Then I thought how unsufficiant that would be because everyone would have the same image and would not be able to implement a paperdoll system. I'm not too sure, all the help is appreciated. Thanks.
--------Long story short---------
I need some help on implementing a networked movement system.
[Java]Socketing Player Movement[Help]
Have you read the Multiplayer & Networking Forum FAQ? In particular Q12.
As for your current suggestion, one problem is that it can be trivially hacked because the client can specify it's position. Generally, the server should be authoritative, the client should only request changes. Your suggestion also appears to treat the clients as dumb rendering terminals, which can work but latency can quickly become an issue.
There is no general solution to this. It depends on many factors of your game, such as the number of players, how many objects will be simulated, the latency sensitivity of the game (e.g. turn based games can tolerate lots of lag, action games tend to become unplayable under even moderate lag). Again, I refer you to the forum FAQ linked above.
As for your current suggestion, one problem is that it can be trivially hacked because the client can specify it's position. Generally, the server should be authoritative, the client should only request changes. Your suggestion also appears to treat the clients as dumb rendering terminals, which can work but latency can quickly become an issue.
There is no general solution to this. It depends on many factors of your game, such as the number of players, how many objects will be simulated, the latency sensitivity of the game (e.g. turn based games can tolerate lots of lag, action games tend to become unplayable under even moderate lag). Again, I refer you to the forum FAQ linked above.
Author
Yeah, I understand. I'm not really making a game. I am practising right at this moment. So I don't care about lag and so forth. I'm looking for some examples on how to this. Then I'll go from there.
Have you read the linked FAQ yet? It contains examples of how actual games which you may have heard of and/or played handled these problems.
Author
I read over it. It didn't really give me the information needed. It would be great if someone could just give me a simple example really quick.
There is no general answer. The kinds of solutions that work are linked to the game you are writing. Hence the FAQ answer has the form "For a <whatever> style game...". If you are not writing a game yet, pick a specific example game to write and then you can discuss the network architecture that such a game would require.
For most reasonably basic action games that don't need to handle large numbers of entities, you might have something like the following:
For most reasonably basic action games that don't need to handle large numbers of entities, you might have something like the following:
- An authoritative server simulation
- Server sends updates at a fixed rate (e.g. 15 times a second, needs to be tuned to the game)
- Clients have a (shallow) copy of the most recent physical simulation data.
- Clients simulate between state updates to the best of their knowledge
- Input on the clients is relayed to the server A.S.A.P.
- Clients assume input is accepted (i.e. client side prediction)
- When updates are received from the server, the client interpolates between their predicted and actual position over a number of frames (to prevent snapping)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
