First Steps
This page describes what to implement in all of the classes required for a new game. If you prefer to read about a more dynamic approach to implementing a game (adding functionality incrementally in various classes), check out this page as a complement to this one.
The diagram below is an overview of the classes to be implemented (in blue). The area of each box is a rough guide to the relative amount of effort for an ‘average’ game.
- Game: This is mostly just a container to tie everything else together and despite its name has no game-specific code. All the work is done in the default implementation in the framework. When a Game is run it holds
- The Players (implementations of the Player interface, whether Human or AI, detailed in Implementing an AI
- The Forward Model
- The current Game State
- GameState is the core. It holds all of the data that describes the current state of the game.
- ForwardModel complements GameState. It contains the logic of the game rules, and is used to advance the GameState by applying Actions to it. It is also responsible for generating the list of Actions that can be taken by the current player in a given GameState. This should be kept stateless - with any state information stored in GameState. The game rules are often split between ForwardModel and the individual Actions, with the Actions containing the logic specific to them (this is encouraged to reduce the amount of code in ForwardModel).
- Components are things like a board, playing pieces, cards, decks of cards. Generally the framework-provided Components will suffice, but game-specific ones can be added where needed.
- Parameters are static game settings, such as board size, number of players, rule variants being applied or the cost of buying a Dreadnought. They do not change during a game, but might differ between games.
- Actions are the moves that Players make. When it is a Player’s turn, Game will give them a copy of the current GameState and a list of Actions that can be taken. They pick one, return their choice, and then the ForwardModel will apply this to the master GameState to progress the game.
A list of the games currently implemented, with notable features in their technical implementation can be found here. A good idea is to look through the code of an existing game that most closely reflects the one you want to implement.
There is a very useful template set up with empty java files for each of these classes, with detailed comments on the mandatory methods that need to be implemented, and the optional ones that may be helpful in a subset of games. This is in the gametemplate
package in the github repository.
Use this as a template to create a new package for the game with the same name in the games
package (e.g. "games.foobar"
). Then follow these steps:
Implement core classes
More information can be found here.
Define basic game information and data
More information can be found here.