It's amazing how difficult is it to find a clear and simple general-concepts tutorial on creating an internet-ready networked game.
All too often searches lead to socket theory etc, when all a beginner really wants to know is "the big picture" - i.e. how to ensure your game states stay synchronised, without sacrificing playability.
This is probably the best place to start, but even there it's hard to find the basics minus the lingo.
Anyway, that's just my (lack of) experience. This is such a key topic it'd be great if an expert would step in to clearly and simply fill in the blanks. Until someone does, my guess (blind-leading-blind) is:
1 Apart from init, only ever send state-change information. If it's not in the packet then it hasn't moved/done anything
2 Sync only 10 times a second
3 Use a static frame rate for game logic
4 Use fixed-step movement, rather than delta time
5 Client and server use same randomise seed
6 Run the full game logic from the client as well. So when the client player wants to move, they move instantly, just as if it was a single player game. If and when a server sync packet arrives, then client checks and updates positions as necessary.
7 Server knows best. Client always bows to server when game state discrepancies arise.
Such is the state of my ignorance! I've numbered the points for easy correction. Hint hint...
- David
PS - Will, are you using point 6?
All too often searches lead to socket theory etc, when all a beginner really wants to know is "the big picture" - i.e. how to ensure your game states stay synchronised, without sacrificing playability.
This is probably the best place to start, but even there it's hard to find the basics minus the lingo.
Anyway, that's just my (lack of) experience. This is such a key topic it'd be great if an expert would step in to clearly and simply fill in the blanks. Until someone does, my guess (blind-leading-blind) is:
1 Apart from init, only ever send state-change information. If it's not in the packet then it hasn't moved/done anything
2 Sync only 10 times a second
3 Use a static frame rate for game logic
4 Use fixed-step movement, rather than delta time
5 Client and server use same randomise seed
6 Run the full game logic from the client as well. So when the client player wants to move, they move instantly, just as if it was a single player game. If and when a server sync packet arrives, then client checks and updates positions as necessary.
7 Server knows best. Client always bows to server when game state discrepancies arise.
Such is the state of my ignorance! I've numbered the points for easy correction. Hint hint...
- David
PS - Will, are you using point 6?