Networked multiplayer about cdogs-sdl HOT 10 CLOSED

Needless to say this is a huge task. All game data will need to be serialisable, which requires refactoring everything into isolated modules, with clear separation of data and code, and no global state (#6). Need a protocol for real time updating of game state, such as object and player state and actions. This protocol will preferably be robust to data loss, be able to self-correct and maintain consistency, and compensate for latency. There needs to be a strong separation between gameplay information and rendering.

from cdogs-sdl.

As an example of rendering and gameplay separation, the game sounds are played as they are updating. Instead the update should push any sound-producing events into a queue, so that the rendering stage can consume it. This has the added benefit of playing the most important sounds, if there are too many sounds to play for the number of sound channels.

from cdogs-sdl.

This task can be broken up into steps:

• Implement a networked input device
• Have the game be able to run as a slave; it performs its own limited simulation but can self-correct off updates from a master/server game
  -- For the local player, simulate everything
  -- For all other players, cache the last movement inputs and repeat them if no updates from server
  -- Simulate motion
  -- Simulate triggers (such as doors)
  -- All collisions, damage from server
  -- Arbitrary position updates from server

from cdogs-sdl.

Definitely check this out: https://github.com/lsalzman/enet

from cdogs-sdl.

We're trying ENet now, much better than rolling our own plus it gives us an option to use reliable (like TCP) or unreliable out of the box. Crossed off some invalid tasks.

Initial client made using ENet, able to pass a few messages between two game instances. It's a bit buggy so far, prone to crashes due to incorrect peer handling.

Reading this: http://www.linuxjournal.com/content/network-programming-enet?page=0,1
There are some things that can be fixed up in this initial version:

• ENetHost already tracks peers, no need to track it ourselves

from cdogs-sdl.

Need to work on a connection sequence. Clients should be able to connect any time, and the server must be able to set up a PlayerData structure to track them.

1. Server opens net connection at the "press fire to join" screen
2. If any net clients join at this stage, they will be assigned a player slot; if they disconnect their slot will be cleared
   • Client connects
   • Server sends map details to client
   • Server sends player data index (i.e. which ordinal they are)
   • Server sends details of any other player present at connection time
   • Server broadcasts new player data index
3. Client chooses a player, sends player details to server
4. Server broadcasts player details
5. Client chooses weapons, sends to server
6. Server broadcasts weapons
7. Client signals that it is ready
8. If all players are ready or the game has already started, server will broadcast start signal

from cdogs-sdl.

Check out https://code.google.com/p/nanopb/
Could make the protocols and endian issues easier

from cdogs-sdl.

Some amendment to the connection protocol:

• Server opens net connection as soon as it knows how many local players it will have; this is at the "press fire to join" screen
  • At this point any client may join
• Client connects, and waits for the initial set of server messages
• Server sends client ID; this is used for broadcasts for the client to know whether the message has special meaning for itself
• Server sends map details to client
• Server sends details of any other player present at connection time
• Client chooses number of local players for itself, sends to server and waits for response
• Server adds the client's players, broadcasts new players to all clients
• Client, on receiving its broadcast responded, adds the new players with the matching player IDs
• When server or client finishes choosing player details (including weapons), sends player details to server and broadcasts to all clients
• When server players have readied, the game is automatically started
• When client players have readied, they signal to server that they are ready
• Clients wait until the game has started, if it has started already the client players automatically join, with the server sending a snapshot of the game state

from cdogs-sdl.

Clients will need to receive mission data from the server. For static maps this is not a problem, but for random maps it is. There are two alternatives:

• Create a new protocol that sends a map as-is, regardless of how it was generated
• Use a consistent PRNG

The second one is less work; here's a source for implementing a PRNG: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

from cdogs-sdl.

Basic low-latency multiplayer implemented; remaining tasks split to #384

from cdogs-sdl.