---
# System prepended metadata

title: NUGGETS SERVER DESIGN

---

# NUGGETS SERVER DESIGN 
## SERVER DESIGN SPEC

This document will describe the design of the nuggets server. The spec will cover the following decompositions:

- User interface;
- Inputs and outputs; 
- Functional decomposition into functions/modules;
- Major data structures;
- High-level pseudo code for logic and algorithmic flow;
- Testing plan, including unit tests, integration tests, system tests.

### User Interface
As described in the [Requirements Spec](REQUIREMENTS.md), the server's only interface with the user is on the command-line; it must always have an argument for the map file and an optional argument for the seed (for the random number integer)

```bash
$ server map.txt [seed]
```

For example, to load a file called mapOne.txt as the map, and to have a random number generator seed of value 5, use this command line:

``` bash
$ ./server mapOne.txt 5
```

### Inputs & Outputs

#### Inputs from Files
Server takes in a map.txt file and potentially a seed (random number generator) from the command-line. Additionally, the server will also be continually listening for inputs from the clients (ex. player vs. spectator).

#### Outputs to Files
The server outputs information to clients (ex. QUIT command to spectator if another joins).

### Functional Decomposition
We anticipate the following modules or functions:

 1. *main*, which is respnsible for calling the other modules, and initializing the port (to listen to inputs from clients) 
 2. *parseArg*, which will interpret and validate the command-line arguments
 3. *grid_new*, which will initialize a new grid with the inputted map file as the argument
 4. *update_grid*, which will update the grid according to the information received from the clients and monitor if all gold nuggets have been aquired (i.e GAME OVER)
 5. *update_player*, which will update the relevant player according to the information received from a client

And some helper modules that provide data structures:

  1. *grid*, which will store the state of the game (starting from the initial map)
  2. *player*, which will store information about each player


    
### Major Data Structures
- *grid*, containing information about the current state of the game
- *set*, of the *players* in the game
- *player*, to store information about each of the players in the game


### Pseudo Code 
The nuggets-server will run as follows:

    Parse the command-line and validate paramenters using parseArgs
    Initialize a new grid, passing in the inputed map file to grid_new
        Initialize the game by dropping at least GoldMinNumPiles and at most GoldMaxNumPiles gold piles on random room spots
    Initiate network and wait for information to come in from clients
    For each piece of information from a client
        If it is a new client
            If new client is a player
                Initialize a new player and add it to the set of players
                Update_grid to account for new player
            Else if the new client is a spectator
                Set the spectator to this new spectator
        Else
            Identify who the client is in the context of the existing set of players
            Update the relevant player using update_player and the grid using update_grid to account for the new information received from client
        For all players in the set of players, and the spectator (if any)
            Send the updated information about the game to the associated client

### Testing Plan

#### Unit Tests
1. We propose to first test for the command-line with various forms of incorrect command-line arguments to ensure that the  command-line parsing and validation of those parameters, works correctly.
2. Next, we print out the port numbers to ensure that the networking units are working correctly

#### Integration Tests
1. We propose using the provided client and server in conjunction with our implementations to test communication between the two modules
2. Next, we will test out client initializing and testing against our server implementation

#### System Tests
We run a wide variety of tests using the compiled client and server aspects of our project, explicitly focusing on edge cases to ensure that our program is working. Essentially, we play the game!


### Design Addendum
For the division of work, we expect to have two individuals (Eve and Itish) working on the design and implementation of the data structures. Eve will work primarily on the grid module while Itish will work on the player and game modules. Hermilla will be working largely exclusively on the client design and Chahak will be working on the server implementation. Since the client module is relatively simple, Hermilla will join Chahak in integrating the server, client and game modules.


