Pyrogenesis  trunk
Classes | Variables
TurnManager.h File Reference
#include "ps/CStr.h"
#include "simulation2/helpers/SimulationCommand.h"
#include <list>
#include <map>
#include <vector>
#include <deque>
Include dependency graph for TurnManager.h:
This graph shows which files directly or indirectly include this file:

Go to the source code of this file.

Classes

class  CTurnManager
 Common turn system (used by clients and offline games). More...
 

Variables

constexpr u32 DEFAULT_TURN_LENGTH = 200
 This file defines the base class of the turn managers for clients, local games and replays. More...
 
constexpr u32 COMMAND_DELAY_SP = 1
 In single-player, commands are directly scheduled for the next turn. More...
 
constexpr u32 COMMAND_DELAY_MP = 4
 In multi-player, clients can only compute turn N if all clients have finished sending commands for it, i.e. More...
 

Variable Documentation

◆ COMMAND_DELAY_MP

constexpr u32 COMMAND_DELAY_MP = 4
inline

In multi-player, clients can only compute turn N if all clients have finished sending commands for it, i.e.

N < CurrentTurn + COMMAND_DELAY for all clients. Commands are sent from client to server to client, and both client and network can lag. If a client reaches turn CURRENT_TURN + COMMAND_DELAY - 1, it'll freeze while waiting for commands. To avoid that, we increase the command-delay to make sure that in general players will have received all commands by the time they reach a given turn. Keep in mind the minimum delay is one turn. This value should be as low as possible while avoiding 'freezing' in general usage. TODO:

  • this command-delay could vary based on server-client pings
  • it ought be possible to send commands in a P2P fashion (with server verification), which would lower the ping.

◆ COMMAND_DELAY_SP

constexpr u32 COMMAND_DELAY_SP = 1
inline

In single-player, commands are directly scheduled for the next turn.

◆ DEFAULT_TURN_LENGTH

constexpr u32 DEFAULT_TURN_LENGTH = 200
inline

This file defines the base class of the turn managers for clients, local games and replays.

The basic idea of our turn managing system across a network is as in this article: http://www.gamasutra.com/view/feature/3094/1500_archers_on_a_288_network_.php?print=1

Each player performs the simulation for turn N. User input is translated into commands scheduled for execution in turn N+2 which are distributed to all other clients. After a while, a client wants to perform the simulation for turn N+1, which first requires that it has all the other clients' commands for turn N+1. In that case, it does the simulation and tells all the other clients (via the server) it has finished sending commands for turn N+2, and it starts sending commands for turn N+3.

Commands are redistributed immediately by the server. To ensure a consistent execution of commands, they are each associated with a client session ID (which is globally unique and consistent), which is used to sort them. Default turn length in SP & MP. This value should be as low as possible, while not introducing un-necessary lag.