Add following documentation:

• usage guide
• developer overview (extending storage)
• developer overview (implementing a game)

System must be able to:

• register arbitrary game engines that implement callbacks in nuk_game_engine behavior defined in #5
• unregister a registered game
• list registered games (and subsequently allow users to initialize/start a game from that list)

gen_fsm might be better suited for nuk_game_server since it relies on small number of states. These states could be:

• initialized
• in progress, or awaiting turn
• completed

After a successful login server keeps a nuk_user_server process for each user. However, after an unsuccessful login that process should stop normally.

Steps to repro:

> nuk_users:put(nuk_user:new("User1", "")).
ok
> supervisor:which_children(nuk_user_sup).
[]
> nuk_users:login("BadUser", "").
{error,user_not_found,"BadUser"}
> supervisor:which_children(nuk_user_sup).
[{undefined,<0.53.0>,worker,[nuk_user_server]}]

Currently with nuk_game_engine behavior callbacks game engines get their own arbitrary state that they themselves had previously set. However, nuk tracks general game state which game engines will find useful; so game engines should also be able to access it also.

Currently, when players want to get an update for the game they've joined they must call nuk_games:get_game_session. This gives them a current snapshot of:

• the game being played
• the nuk state
• the game engine specific state

From this information they have to make decisions.

I'd like to investigate whether it's more useful to provide incremental updates, such as queuing messages for individual player clients, in addition to having this functionality.

Requirements

• user storage must be a behavior
• session storage must be a behavior
• user and session storage functionality must have common simple interface

Desired client interface

%% create/modify, get and delete user
ok = nuk_users:put(nuk_user:new("User1", "Pass1")).
ok = nuk_users:delete("User1").
{ok, User} = nuk_users:get("User1").

%% login/logout
{ok, SessionId} = nuk_users:login(Username, Password).
ok = nuk_user_sessions:delete(SessionId).

%% get an active session
nuk_user_sessions:get(SessionId).

%% list all active users and sessions
[User1|OtherUsers] = nuk_users:list().
[Session1|OtherSessions] = nuk_user_sessions:list().

Currently all game tests are run against the nuk_game_coinflip sample game, which is limited to 1 player. In order to more fully test multilayer conditions (e.g. successful join with another player), implement a 2+ player game and write corresponding tests.

Currently to register a game the nuk_game:game() data type must be created which takes min_players and max_players arguments.

Instead of specifying those hardcoded options there, would it make more sense to have a behavior callback where the game module gives the default general and arbitrary options which may (or may not) be overridden during nuk_game_engine:initialize/2 callback?

Currently nuk provides following behaviors and their corresponding default implementations:

• nuk_user_storage: implemented by nuk_user_store_server
• nuk_user_session_storage: implemented by nuk_user_session_store_server
• nuk_game_storage: implemented by nuk_game_store_server
• nuk_game_session_storage: implemented by nuk_game_session_store_server

The implementing modules are hardcoded in nuk. They should be configurable and the configured module should be called instead.

Plan

• isolate dynamic module usage to: nuk_users, nuk_user_sessions, nuk_games, nuk_game_sessions
• store default values in above modules
• use appication:set_env to override defaults
• look up via application:get_env and call the configured module

Similar to user sessions, we need to have an implementation that maps game session IDs to game servers. This would allow:

• us to return the game session ID upon starting a new game
• clients to use the game session ID which will get translated to the correct nuk_game_server pid on the server

Per dialyzer:

nuk_user_session.erl:30: Invalid type specification for function nuk_user_session:new/0. The success typing is () -> #{'user':=#{}, 'username':='anonymous'}

Indeed, the opaque session() type defines username => string(), and we are setting an atom.

In a multiplayer environment it is necessary for game engines to keep the following 3 buckets of data:

• private: this data stays private to game engine and is never shared with any players
• public: this data is always shared with all players
• user-specific: this data is only shared with a specific user, e.g. something related to a specific user's state that other users aren't allowed to know

Currently, there's only one public bucket described as term() type. This needs to be split in 3, allowing:

• nuk_game_engine behavior to return them separately as callback results
• nuk_game_server to return the appropriate data to each player, and keep private data
• nuk_game_session to extract them

In nuk_game_server:handle_info/2 when we receive the finish message we invoke the game engine for final cleanup and stop the game server process. We should also clean up the game session storage - i.e. delete the pid to session mapping by invoking the nuk_game_sessions deletion, which in turn invokes the nuk_game_session_storage:delete/1 behavior call.

Also look at nuk_user_sessions:delete/1 calling nuk_user_session_store_server:delete/1 which should probably have a similar solution.

Create different tests suites for user tests and game tests.

Exported functions in modules such as nuk_games, nuk_users, nuk_game_sessions, etc. must have reference documentation that is automatically generated with make.

Requirements

Game

• game functions
• game engine behavior

Desired client interface

%% returns list of available games (game engines)
[Game1|OtherGames] = nuk_games:list().

%% returns list of active games
[GameSession2|OtherGameSessions] = nuk_game_sessions:list().

%% start a new game
{ok, GameSession1} = nuk_games:start(Session, Game1).

%% join an existing game
nuk_games:join(Session, GameSession2).

nuk_games:get_state(Session, GameSession1).

nuk_games:move(Session, GameSession1, Move).

nuk_games:leave(Session, GameSession1).

nuk_games:end(Session, GameSession1).

Desired game engine interface

nuk_games:initialize ------> nuk_game_engine:initialize ------> {ok, GameState}

nuk_games:join       ------> nuk_game_engine:join       ------> {ok, GameState}

nuk_games:start      ------> nuk_game_engine:start      ------> {ok, GameState}

nuk_games:move       ------> nuk_game_engine:move       ------> {ok, GameState}

Game actions and external status

• initialize: initialized
• start: active

Game state

#{
    status => Status, % see above
    players => [User1, User2, User3, User4],
    waiting_turn => [User2, User4],
    state => #{
        %% other internal state specific to game engine
    }
}

There should be a way for users to log out which would also delete their session. This would also be helpful for #2.

Currently prior to starting a game nuk checks that the user and game sessions are valid and that user is a member of the game session. nuk should also check that the minimum number of players has been met, per game registration.

Before (or after) each test case, delete all logged in user sessions so they don't affect tests that haven't run yet.