# CS50 Nuggets
#### Claire Draeger, Camden Hao, Nicholas Irwin, Giorgiana McCombe - May 2021

## Design Spec

According to the [Nuggets Requirements Spec](REQUIREMENTS.md), Nuggets is a multiplayer exploration game run by a game server. The *server* is a program which runs and initializes the game, allows players to connect and quit, and keeps clients updated on the progress of the game. The *player* is a program which handles clients who wish to participate in the game, and is in charge of initializing the display and network.

### User interface

The nuggets's first interface with the user is on the command-line. The user first needs to set up a server which can have either one or two command line arguments. Then, a user can initialize play or spectate the game with a separate set of either two or three command line arguments and subsequent keystroke commands.

### Inputs and outputs

**Input**:
In the command line the Player can input various key strokes for different purposes, see [Requirements Spec](REQUIREMENTS.md) for more detailed command line inputs.

*Key Strokes*:

Player
`Q` quit the game.
`h` move left, if possible
`l` move right, if possible
`j` move down, if possible
`k` move up , if possible
`y` move diagonally up and left, if possible
`u` move diagonally up and right, if possible
`b` move diagonally down and left, if possible
`n` move diagonally down and right, if possible
where possible means the adjacent gridpoint in the given direction is an empty spot, a pile of gold, or another player.
for each move key, the corresponding Capitalized character will move as far as possible automatically and repeatedly in that direction, until it is no longer possible.

Spectator
`Q` quit the game.

**Output**:

The server is responsible for outputting a `quit` messages when a player quits or the spectator quits/is replaced. See [Requirements Spec](REQUIREMENTS.md) for detailed quit messages.

When all the gold is collected the game is done and the server will send the ending message to the players

QUIT GAME OVER:
A		4 Alice
B		16 Bob
C		230 Carol

### Functional decomposition into modules

We anticipate the following modules or functions:

Server - keeps track of the current map and where the players are
- Player - retrieves map from server and displays to player
- holds player leter, full name, gold score, and address
handleVis() - calculates what parts of the grid the player can see
- Grid
- gridpoint struct, for each character in the string
- function to load the map file into grid struct
- setters and getters for gold and player

Client - handles the player/spectator, utilizes grid and player structures as well

And some helper modules that provide data structures:
1. *grid*, a module providing the data structure to represent the grid for the game of NR rows and NC columns, functions to call on grid;
2. *game*, a module providing the data structure to represent the game, stores current map, players positions and scores.
3. *messages*, a module provided to send messages between server and players (provided)
4. *log*, a module provided to log messages to an output file (provided)
5. *player* struct to hold player info(address, gold score)

Functions to handle messages (needed by message_loop in message.c)
- handleMessage - takes the address from which the message was provided and a string containing the contents of the message.
- handleTimeout - called when time passes without input or message.
- handleInput - handles the input from stdin, reads once from stdin and processes it

### Pseudo code for logic/algorithmic flow

The nuggets will run as follows:

Server:
- Parse the command line, validate parameters, and Initialize the game when prompted
- Load map into grid data structure and drop gold nuggets into random spots
- Initialize the network and wait for clients to join
- Accepts players and one spectator to the game
- Sends updated grid messages to player each time a player moves (keystroke) or gold is collected
- Handles inbound messages from player
- handles keystrokes or moves / when gold is picked up
- handles quit messages from client
- everytime server gets a message, it will update the map
- update visibilitys for each player with updateVis(), then sends the grid string to cleint
- the spectator alwayshas perfect visibility
- If player quits, remove player’s symbol from the grid
- Constantly monitors gold number, when all gold is collected, prints a tabular summary and sends a quit message to all players and exits

Client:
- Verify its arguments
- Join as either a player (name provided) or spectator (no name provided)
- Initialize the display and the network
- Waits for grid message from server and upon receiving ensures display is large enough for grid
- Shows the status line on the first line of display and grid on subsequent lines
- Updates the display when prompted with messages from the server
- If quit key is pressed, sends quit message to the server
- Quits when told to do by the server
- After game ends or quit, print a game over summary and exit

### Major data structures

The server will implement a `hashtable` structure to store the players who are connected to the game. The player struct will contain information such as the playerID, gold score, full name, and address.The grid struct will be a 2D array of chars, each char is a point of the map (gridpoint struct) and the grid module will have different functions to allow the game to access the grid and the players at each gridpoint. The client will utilize the grid and player structs as well.

### Testing plan

*Unit testing*

test each module
- grid
- test loading grid
- test creating all the gridpoints
- setters and getters
- use `#IFDEF` directive for testing at points such as loadMap and the getters/setters
- player
- test creating a player and moving it
- test setters and getters
- testing gold
- is it at the expected value after a player picks up
- messageHandler
- verify messages are parsed correctly

*Integration testing*
- play the game a variety of different ways
- use a human script to test, which is a script containing instructions for how to launch different types of games
- ex) launch game, join with 20 players with 3 of them having invalid names
- ex) test spectator - join with a spectator then join as spectator again to make sure the new spectator replaces the old one

*System testing*
1a. Test `server` with various invalid arguments.
1. no arguments
2. three or more arguments
3. invalid `map` (non-existent path)
4. invalid `map` (not a valid grid or txt file?)
5. invalid `seed` (zero or negative integer)
6. invalid `seed` (non-integer)

1b. Test `client` with various invalid arguments
1. no arguments
2. four or more arguments
3. invalid `hostname` or IP address (not a host)
4. invalid
0. Run *nuggets* on a variety of maps.
0. Run *valgrind* on both *nuggets* and *indextest* to ensure no memory leaks or errors.
### Individual Team Member Roles

Server
- main = Giorgie
- players = Camden
- grid = Claire

Client = Nick