Only send moves for P2P 2 player LAN game?

Question

I am making a 2D network game. The concept is simple, a player have to shoot the other player to win. I'd like to improve this game ( add a map, items, monsters, w/e ), but later.

This is my first network programming experience. I have little theorical knowledges about packets, sockets, client/server side, what is dangerous to do client sided, but I've never really used them.

Goals set :

• This is a 2 players LAN game, no more no less.
• No server. Player 1 starts the game waiting for player 2...
• ... which leads the game open for reverse engineering or packet editing, but w/e, for this kind of game I prefer simplicity over security.

Pretty basic. For a first network game that will never be shared, I take off problems and will see later.

This is where I am : each player is a square that can move in four directions. The approach :

• TCP Packets.
• Each movement ( each frame a key is pressed to be accurate ), a packet is sent to the other player with his position.
• Packets are received each frames before drawing and updating game elements, in the same thread, with a non-blocking receive() function.

And that's it.

My questions :

• Is sending a packet for each moves overkill? Will I have problems with this later?
• What kind of problem can I meet? mono-thread + non blocking function will be a problem later, assuming the goals I've set?

Answer 1

Let me answer your question with another question. Assuming your game is checking for input every frame, you'll be reading input from the user about 30-60 times a second; which means you would be sending about 30-60 packets every second. That's a fair amount of packets to send every second, you might want to consider something more like 1 every 10 frames.

Realistically, the player isn't going to move very far every frame, so its ok to have some room for buffer. Usually games get around this by doing some predictions of where the player will end up based on where they were last and their general direction/velocity. Then they simply compensate for the actual position with every new packet.

Since you're doing TCP, there's a stronger focus on ensuring high reliability of packets. This means things are going to take a bit longer when transporting. I would suggest looking into doing UDP instead, as it has more of a fire-and-forget mentality. Not every packet will make it to the other end, but this goes back to the point that most games just help compensate for this by making approximations and correcting them.

I'm not very experienced with networked games, but this is just knowledge that I've acquired over the years when talking to people. Hopefully others can go into more detail, if needed.

Answer 2

It appears what you are going after is called the Peer-to-Peer Lockstep model, according to the relevant article in Gaffer on Games. That is:

• Each peer runs a separate game simulation
• Peers share their own player's moves to all other peers (that's the peer-to-peer part)
• Peers simulate the same game using the same set of inputs, and don't proceed until being acknowledged by all other peers (that's the lockstep part)

This is a very simple model which suits LAN play very well, and is used by Doom and many RTS games since it's the cheapest way to share the state of many thousands of game entities. For reasons that don't apply to you, most games that require network play over the internet have moved on to client-server and other advanced models.

It does come with some hefty requirements, so beware:

• You need to judiciously remove all non-determinism in your game. If you use an RNG, you'll need to make sure that it's the same RNG, all clients seed it the same way, and then you can't allow mid-game joins. Also watch out for the effect of non-standard floating point numbers on non-determinism. But really, as long as you are running on the same CPU architecture and compiled using the same compiler, you'll be ok.
• A suitable game loop. Variable-length game loops are out, since your peers will drift out of sync rather quickly if the length of their (game) frames are different.

To answer your question, yes this is feasible, and is probably the simplest way to bolt networking on to an existing game that wasn't architected for it.

Answer 3

Maps, items, monsters, etc. gives you many factors that can be tipped out of balance by 1 small difference in a floating point operation. A character moves a little bit more to the right, he bumps into another character 1 frame early, then suddenly the whole world implodes and monsters die on some clients but not others.

You'll have a much easier life replicating properties. If you don't care about hackers (and why should you?), let players simulate their character's movement, rotation, and bullets then distribute that information to everyone. Note that, as SaviorXTanren mentioned, 30-60 packets per second is a lot for a video game, even a lockstep one that doesn't pack much into the packets. I mean, 30p/s over TCP results in 3,120 bytes of overhead. This issue is made even worse because with p2p, each client has to have a line of communication with every other client. Players can't influence the world at such a high frequency so much of the data sent will be useless.

Instead, shoot for 10-20. Planetside 2 does it with 5. And replicate properties unless your game is big enough and designed to generate a large community of hardcore players. With p2p replication, 2-4 players should be fine. If you're replicating properties, UDP would be better than TCP because data quickly becomes outdated after a new update arrives so there's no need to guarantee that data arrives.