Data Structures

There will be an array of game_t structures on the server. This array will be initialized at startup, and may be changed when dynamic loading of new game modules occurs. The index into this array is referred to as the game type index.

    game_t {
    str: short string for name of game (16 chars?)
    str: long string for description (256 chars?)
    fnc: pointer to function for launching game
    chr: allowable player numbers (2^num)
    chr: allow computer players (1 for yes)
    int: sizeof options struct in bytes
    chr: enabled flag (1 if playing this game is enabled)
    }
  

There will be an array of game_run_t structures representing running games, This array will be dynamic since as games are started and finished, entries in the array are created and destroyed. The index into this array is referred to as the game index.

    game_run_t {
    int: game type index
    int: number of player slots
    *int: array of player codes for registered players
    chr: play/wait flag (0 if waiting for players, 1 if playing)
    int: process or thread ID
    *void: pointer to options struct for this game
    *int: array of player codes for reservations
    int: number of open player slots
    int: file descriptor for communication
    chr: computer players (2^num)
    }
  

There will also be a large array of user_t structures, representing connected users. As soon as a user connects, an entry is created and the file descriptor filled in. When the user completes the login process, the user code and name are filled in. When the user launches, or joins a game, the game index is filled in.

    user_t {
    int: user code (unique user id number)
    str: user name
    int: file descriptor for communication
    int: game index
    }
  

An array of reservation_t structures holds all of the reservations requested. These are created when a game is launched with reservation requests. They may be altered once the game has been launched. They are deleted when a user accepts a reservation or declines it.

    reservation_t {
    int: game index
    int: user code
    }
  

The server options are stored in a Options structure. This holds many run-time configurable options. Note: Not all of these options are implemented at this current time.

    Options {
    str: Name of configuration file specified in --file
    chr: remove_users
    int: User inactivity time
    chr: clear_stats
    int: stat_clr_time
    int: TCP/IP port to use for communications
    str: Directory in which game description files are found
    str: tmp_dir
    str: The base configuration directory
    str: The server admin's name
    str: The server admin's email address
    int: Whether to perform hostname lookups for log files
    }
  

A chat room is implemented internally in a RoomStruct. These are stored in a run-time allocated array as needed. Hopefully this will allow on-the-fly room creation in the future.

    RoomStruct {
    str: Short room name
    str: Long room description
    int: Number of players in room
    int: Maximum number of players allowed in this room
    int: Number of active tables in room
    int: Maximum number of active tables in room
    int: The game type this room hosts
    time_t: A timestamp when the player list last changed
    time_t: A timestamp when the table list last changed
    *int: An array of player indices (players in room)
    *int: An array of table indices
    *ChatItemStruct: The tail of a linked list of chat for this room
    }
  

Chat messages are implemented as a set of linked lists, one per chat room. The chat room itself points to the tail of the linked list so that chats may easily be tacked onto the end. Each player has a pointer to their head of the chain, which is the next message they expect to receive. A ChatItem is stored as follows:

    ChatItem {
    int: Number of players who have not read this chat
    str: The name of the sender of this chat
    str: The message itself
    *ChatItem: The next message in the linked list
    }
  

The message of the day is stored internally in a MOTDInfo structure. It is read at system initialization and will not change dynamically (at least yet).

    MOTDInfo {
    str: Filename where MOTD is found
    chr: Whether to utilize the MOTD (bool)
    ulong: Time the server started up (used to calc uptime)
    int: Number of lines in MOTD file
    *str: An array of MOTD text lines
    str: The server's hostname
    str: The server's system name (eg: Linux)
    str: The server's CPU identifier - this is not strictly accurate
    and depends on who compiled the kernel
    str: The port number the server is using
    }
  

Logfile options are stored separately from the main server options in a LogInfo structure:

    LogInfo {
    int: Have log files been initialized?  If no, we emit to stdout/err
    int: Which syslog facility to use
    uint: A bitmap of options (see err_func.h)
    str: Filename for logfile (if not syslog)
    *FILE: Stream for logfile
    uint: Log types to include in logs (see err_func.h)
    ** The following are only included if debug is on **
    chr: A flag to note that debug level was set on command line
    str: Filename for debug file (if not syslog)
    *FILE: Stream for debug file
    uint: Debug types to include in logs (see err_func.h)
    }