Currently I am working on a real time strategy game with a lot of units and I was thinking and googling about packet design for a lockstep networking model.
As I understand the lockstep networking model is based on capturing input and sending it to other players, who will confirm it and then execute it (in time). But "input" is a wide concept, what is input? Mouse position? Keystrokes? Or more abstract "I want to do this with unit x", or, "I want to do this with unit x on position y".
"Proven" solution
I googled a lot, and found a solution that is used in classic RTS games:
Command packets have a structure like:
- command type
- player id
- x
- y
- target
Player 456 wants to move unit 123 to coordinate 5,6:
- Player first selects the unit:
- Command packet: COMMAND_SELECT,456,0,0,123
- Then clicks on a location:
- Command packet: COMMAND_MOVE_TO,456,5,6,0
- The other side knows the selection for that player and moves the unit.
In this case, all selection changes have to be communicated via the network and every client stores the selection per player. I was wondering if there is no other solution for this, because also unuseful selections are communicated every time:
Player 456 selects 100 units, and then deselects them in the next tick. This will result in 200 packets just wasted.
Alternative solution
I was thinking more like a packet that has the structure:
- command type
- player id (or maybe even not, as the client knows the sender when it receives a packet and knows what unit the command is about)
- subject
- x
- y
- target
Player 456 wants to move unit 123 to coordinate 5,6:
- Player first selects the unit
- Then clicks on a location:
- Command packet: COMMAND_MOVE_TO,456,123,5,6,0
- The other side knows what unit to move where and does that.
Selections are not communicated, only the move commands. This, however, results in a slightly bigger packet and also more data in the following situation:
Player 456 selects 100 units and commands them to go to a coordinate -> 100 packets. The player doesn't change the selection and in the next tick commands the units to go to a new coordinate -> another 100 packets, etc.
Both could win
Player selects two units, moves them, selects another two, moves them, etc -> Alternative solution wins, two packets per movement (and no packets for selection/deselection)
Player selects two units, moves them, then moves them again, then again, etc -> Proven solution wins, as there is only one packet per movement and one for the selection (and maybe one for deselecting)
Conclusion?
I really don't know which one is better, as both solutions seem to have drawbacks. Does anyone know how to handle a situation like this?
