Add in the Infrastructure for Supporting Different Game Variants

[rameshvarun]

Right now, the game is hard-coded for Feltar Hnefatafl. We should reorganize such that it is possible to add in more game variants. Essentially this boils down to slightly different rules, a different board size, and different starting configurations.

[rameshvarun]

I'm thinking that this will boil down to having a Ruleset interface. Instead of having the Board class implement functions like getActions and step, it will be delegated to the Ruleset class.

[jlwatson]

Hmm you have any links to different variants? It'd be nice to see how much they vary. If the board configuration is completely different from variant to variant, then it might be useful to define an interface on top of the Board (little common code currently present) rather than make a new set of classes

[rameshvarun]

Some board configurations: https://en.wikipedia.org/wiki/Tafl_games#Tafl_variants Some different rulesets: http://aagenielsen.dk/index.html

For the large part, the rules are the same, but some have additional rules about capture (shield-wall capture). Also, the rulesets disagree on whether or not certain end conditions result in a draw or a loss for the defenders.

Eg - http://www.fetlar.org/assets/files/hnefatafl/rules2013visual.pdf (which was used for some tournaments) calls draw for a lot of things, whereas http://aagenielsen.dk/index.html lists those situations as a loss for white.

Ultimately, we might have to take creative license with the rules, since there is poor standardization across sources.

With regards to the ruleset thing, I may not have explained my idea clearly, but my idea is that we essentially make Board just a data class.

Then we could create an interface along the lines of

class Ruleset {
    Board getStartingConfiguration();

    // We need to get the history, in order to start implementing draws in case of perpetual repetition.
    Board step(List<Board> history, Action action, EventHandler eventHandler);

    Set<Action> getActions(List<Board> history);
}

Then, gameState would then get an instance of the Ruleset interface.

[jlwatson]

Alright yeah. I like that - it creates a clear division between the RuleSet, which plays the game according to the rules and the Board which doesn't care about the rules and exists only to move pieces around on.

[rameshvarun]

Added in 7307060622946d9b1f401b43c10176dcfda8e7d2