Im working on a top-down multiplayer shooter game. Right now im working on the network code (using kryonet). This is my first multiplayer project so my networking knowledge is limited.

The first version of the networking code consisted of the server sending a packet containing information about the world every frame. I quickly realised that sending 60 big packets every second to every player is too much, so i set a limit on how often the server would send packets. Now, since the clients were no longer getting an update every frame, the game started to lag and stutter. I solved this by adding interpolation and now the problem is gone. Well, except that now I have input delay to deal with.

If I get it right, I understand that I must implement client side prediction. I don't know how to do it thought, and thats why I made this thread. It would be much appriceated if you could explain how I should implement prediction.

The best solution is to reduce the amount of data you send to the server each frame. Depending on how interactive your game world is (physics, dynamic objects) it might be enough for each player to simply send their current position and velocity and you simply extrapolate from those values. That's only 4 floats -> 16 bytes per frame -> about a kilobyte of data per second. EDIT: Okay, you would also need the direction the player is facing at and possibly other values, but it's still way below what most Internet connections can handle...

- Are you using a server-client model or a peer-to-peer model? - Are you using TCP or UDP?

- Are you using a server-client model or a peer-to-peer model? - Are you using TCP or UDP?

Server/Client model. Currently using UDP, which I believe is the best choise for this project since I want to reduce latency as much as possible. But like I said, my experience is limited. If some thinks using TCP instead would be better, then I can change.

The best solution is to reduce the amount of data you send to the server each frame. Depending on how interactive your game world is (physics, dynamic objects) it might be enough for each player to simply send their current position and velocity and you simply extrapolate from those values. That's only 4 floats -> 16 bytes per frame -> about a kilobyte of data per second. EDIT: Okay, you would also need the direction the player is facing at and possibly other values, but it's still way below what most Internet connections can handle...

- Are you using a server-client model or a peer-to-peer model? - Are you using TCP or UDP?

you aren't counting the TCP or UPD(and alla the ISO/OSI below) header!!! that will be very much more than your data!

- Are you using a server-client model or a peer-to-peer model? - Are you using TCP or UDP?

Server/Client model. Currently using UDP, which I believe is the best choise for this project since I want to reduce latency as much as possible. But like I said, my experience is limited. If some thinks using TCP instead would be better, then I can change.

if you paln to base the thiongs on interpolation, then TCPO is better because you cannot lose action ar apply them in the wrong order

Quote

Insert QuoteAlmost all action games use a peer-to-peer network model. This is to avoid the latency of having to communicate with a server which then broadcasts the changes. I believe this is your main problem...

- Are you using a server-client model or a peer-to-peer model? - Are you using TCP or UDP?

Server/Client model. Currently using UDP, which I believe is the best choise for this project since I want to reduce latency as much as possible. But like I said, my experience is limited. If some thinks using TCP instead would be better, then I can change.

if you paln to base the thiongs on interpolation, then TCPO is better because you cannot lose action ar apply them in the wrong order

... at the cost of throughput. For the lowest delay use UDP, a peer-to-peer model and send as little as possible. There's a reason all (yes, all) major shooters out there today use this.

Almost all action games either designates one of the peers as "server" (games with matchmaking) or has a dedicated "server" (most PC games). However these "servers" only keep track of the game score, maybe some basic game state, ban-lists, e.t.c. All clients are still connected to each other, and the data does not pass through the server as that would essentially double the latency. The server might also act like a tie-breaker, for example if two people shoot each other which in this example is impossible the server could decide who actually died and who survived (because you can't shoot when you're dead).

I'm no pro here,I've only done basic networking), but I do play lots of shooter games and I'm interested in the theory. xd

All clients are still connected to each other, and the data does not pass through the server as that would essentially double the latency.

True for latency, but false the sentence. never had to open door on NAT to play TF2 or any other shooter game. MAYBE if your door are open the game will use it for doing p2p, but I think this is a secondary improvement, the real communication system relay on client/server architecture

If by shooters you mean first person shooters, then Im pretty sure alot of them only use client/server. For example all games made with the Source Engine. Sorry if it seems like Im trying to disprove you or something. I've always thought most action games used client/server so when someone tells me the complete opposite I have the right to sceptical.

Edit:

Heres a link that I found interesting, it describes the networking that the source engine use:

- The Source engine is pretty old. - It supports advanced physics (Havok). I said that peer-to-peer is better when you have very little data to transmit, and physics also needs to be synchronized between computers. Having a server and using determinism is kind of necessary in this case. - There's UPNP for opening ports in routers. There's also some tricks you can use to get through routers and NATs using a 3rd server host.

determinism help a lot, jbox2d's source can be modded to be deterministic, but this mod limit the power of float calculation, because it use an old standard.also UPD+determinism is not a good idea, because if you lose an action or (in some case) apply action in wrong order you will break it. So you have to implement a sort of TCP over UDP... and it's hard to do.so, if you want use determinism, you lose some CPU but you gain bandwidth (no need to sync all entity position sometime)

UPNP it's a pain. many router doesn't support it, and many times support it in a buggy way (take a look at some UPNP project to get an idea of what i'm talking about). I support the idea of p2p, with the server action only as "controller", but I think you should have a fall-back system that relay on server-client

Using a 3th part host is not a good solution: is just like use client-server architecture. Yes you can use the server as 3th host.

Actually i'm writing a game witch use deterministic jbox2d and TCP(nio package), hope you will soon test out how it work

Using a 3th part host is not a good solution: is just like use client-server architecture. Yes you can use the server as 3th host.

This is what I meant. The clients just connect to the server so that your router starts forwarding packets on the random port generated for outgoing connections. You can then disconnect that connection and use it to accept new connections.

Using a 3th part host is not a good solution: is just like use client-server architecture. Yes you can use the server as 3th host.

This is what I meant. The clients just connect to the server so that your router starts forwarding packets on the random port generated for outgoing connections. You can then disconnect that connection and use it to accept new connections.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org