Game Server Architecture

Bots and Players

Bots are special gen_server that acts similar to connection handlers. They also owns game_session instance and loop bot logic for games. Same the conn_handler acts just like a bots it is relying on network connection for user actions and also own game_session.

User Session

Session gen_server for every logged user that holds the references to game relays and chat relays.

Game FSMs

Game events in gen_fsm module for particular games implementations that hold the board information, link to game relay and users sessions pids.

Relays

Relay for routing messages from/to user session instances and/or clients within game instances that hold link to game module.

This picture describes the structural organization of modules and run-time connections of instances. As you can see Game Relay is tightly coupled with particular board implementation and Session connected with Bot implementations and Connection Handler (for real users). All four blocks are gen_servers and just board game implementation is gen_fsm.

             +---------------+
             | Game Manager  |
             +---------------+
             | TOURNAMENT    |
             +---------------+
                     |
                     V
             +---------------+
             | RELAY         |
             +---------------+
             | GAME FSM      |
             +---------------+
                |         |
  +----------------+   +----------------+
  | USER SESSION   |   | USER SESSION   |
  +----------------+   +----------------+
  | BOT            |   | PLAYER         |
  +----------------+   +----------------+

Bots and Players

Each instance of game_session holds the state of each player in system. Once created by connection handler or by bot modules game session responds to requests from game clients (bots and players).

send_message { }

Sends async message down to the bot logic or directly to connection socket.

call_rpc { }

Process the request to underlying game_session.

get_session { }

Return underlying game_session.

init_state { }

Override

join_game { }

Create

User Session

state { user,rpc,rpc_mon,games,chats,match_request }

The state hold user info, rpc for pid of self session instance and its erlang:monitor. Also holds all games participations (relay pids) and chats relays for given user.

session_attach { token }

Used for authenticate the client by the registered token by the authentication server. If the user is not found, then terminate send to client pid. Also you can check for session_attach_debug for authentication by token and username. It replaces the user in state of game_session from unknown to authorized user info #'PlayerInfo'. This is the first message sent by Flex client. Reply with #'PlayerInfo', if not found invalid_token returns.

logout { }

Send termination to client pid uncoditionally. Please use this function for correct consumer behavior at the end of gaming session. Reply is ok.

chat { chat_id, message }

Used for talking through publishing messages to relay. chat_id is actually the game id to which message should be relayed. Result not valuable, in case of failure returns chat_not_registered.

get_player_info { player_id = 0 }

Reply with current #'PlayerInfo' stored in State. Other player_id parameters replies with not_implemented.

match_me { game_type }

Asynchronous match the current user in state along with game type. Replies with generated request ref integer that will be answered in match_found API.

match_found { ref,game_id,is_replacing,pid }

Answer to matching request ref with relay as pid, and running game_id.

join_game { game }

Join current user in state for a particular game instance by its id. This is the second message send by Flex client. Returns #'TableInfo' for success. In case of failure returns: game_not_found, already_joined, this_game_is_private.

game_event { game, event, args }

This is both info and cast async API for handling game events. Send async notification message from SERVER to PLAYER.

game_action { game, action, msg }

This is just like game_event but being sent from PLAYERS to SERVER.

pause_game { game, action }

Action could be pause or resume. Then message downstreams to FSM by signaling.

rematch { game }

Rematching request for current player in USER SESSION for existing game instance. Message forwarded to FSM module by signaling.

Game Server Architecture

Bots and Players

User Session

Game FSMs

Relays

Bots and Players

send_message { }

call_rpc { }

get_session { }

init_state { }

join_game { }

User Session

state { user,rpc,rpc_mon,games,chats,match_request }

session_attach { token }

logout { }

chat { chat_id, message }

get_player_info { player_id = 0 }

match_me { game_type }

match_found { ref,game_id,is_replacing,pid }

join_game { game }

game_event { game, event, args }

game_action { game, action, msg }

pause_game { game, action }

rematch { game }

game_crashed { game }

game_rematched { game }

chat_msg { game }

social_action { game, type, initiator, recepient }

social_action_msg { type, initiator, recepient }