Grava Hal
=========

This is a web app in the Play Framework for a game of Grava Hal. 

The app runs (by default) on port 9000 of localhost by invoking the command 'activator run'. 
This automatically downloads the dependencies (if necessary) and compiles and runs the application.

After the server is started, the in-memory persistence database (a mock for a real DB) needs to be updated with
the model structure by clicking on 'Apply this script now!'

The web page index allows starting a two player game by giving player names. It automatically redirects to the game, which remains available on that URL as long as the server is running.

- The game allows playing a turn by clicking on any non-empty, non-Grava Hal pit. Afterwards, the turn switches to the other player, who can play 'hot-seat' (on the same browser) or in a different browser. Currently, the game does not force player sessions or accounts, and the board is also not dynamically refreshed using a server-push technique. Both would be nice to have.


Some notes on the implementation:

- I used basic Play MVC, with all code in app/*/*.java written by hand. The structure of the project is generated by Play's tools.
The code is exercised by the tests in test/*.java . 
I focussed unit tests on the model code (where all the game logic is), developing the code in a test-driven way,
and have some integration tests that test browser-based interaction that were written in tandem with linking up the frontend code. 
The controller Application.java is not under test, as the code is rather straightforward and would fall apart in the integration test.
- app/views/formdata/GravaHalFormData.java contains a public-field class that is used to get the data of the
create game form, which is then fed to the constructor. This is a work around, because the form-binding uses reflection on public fields, but I want to prevent as much 'unauthorized' access as possible (so, private fields and getters).
- Routing is automatically generated from conf/routes
- The database is in-memory for development purposes. It can be mapped to a running ebean database server, but I didn't want to investigate how to set that up for the purpose of this assignment.
- The frontend generates a board view directly in HTML, based on the data the server has. 
The alternative would be to serve the board state as a JSON object, but this would cause more logic to be handled in Javascript/JQuery, which isn't statically checked. 
The benefit of that approach would be to have more flexibility in (different) frontends.