gaigresearch/tabletopgames

tabletopgames's Issues

Specific *Game classes needed?

They don't actually have any functionality or anything (other than the main method to run the game). We could remove main game classes, make AbstractGame class not abstract and just use that directly to initialise games (with the specific parameters, game states and forward models).

Concepts consistency: cards vs actions, similar to game state vs FM (container vs logic)

Cards shouldn't have logic attached, only containers for properties.

Action classes shouldn't hold references to other classes (or we'd require all those references to be updated in the game state copied objects)

PartialObservableDeck needed?

In the game state the game runs with, we need full observability (GUI display etc).
For players, decks should be altered so that the players see what they need to see only when the game state is copied.

So this class might not be needed?

Implement partial observability

The game state implementations of copy(int playerId) should return a copy where only the components visible by the player are included.

Games to do:

• Uno
• Virus

Games to check/do:

• Exploding kittens
• Love letter
• Colt express

Score & Distance to terminal state in feature space? (interfaces for game states)

Occlude GameParameters in GameState

Is boolean return of AbstractAction.execute() needed?

I thought it was used, but unsure and needs double checking.

Component Interfaces

If we define interfaces for components (i.e. IDeck -> Deck), then GameState should have collections of interfaces (List instead of List). This is done for decks, but we probably wanted to do the same for the other components.

Also, this creates many errors (fixed with castings) in the pandemic classes.

TurnOrder.nextPlayer() can get stuck in infinite loops

If this function is called accidentally after the game has finished and the results are set, it will keep iterating through players looking for someone still playing (when there's nobody).

MovePlayer action has too many checks, which make it very specific

Action forcing: we need a way to deal with actions triggered by other actions

See PandemicForwardModel (L: 193)

Test game and compare against original rules

Debug prints should be wrapped in on/off flag to be able to turn them off

Deck<T> should be Deck<Component> and rename its methods

The deck has been templated, but a lot of methods keep names of "cards" in them, that should be updated.

Also, this should probably be restricted to Components and not just any object type to make sense in the context of the framework.

All actions forced to implement toString, equals and potentially hashCode

Maybe use lowercase conversion for hashing? it would be less confusing to work with. Tried to get researchStations, but did not know how it was written

Game-specific actions don't need to be templated

I'm not sure why there are many actions in game packages that use a templated version for the decks, when they know the types of objects going in (cards most of the time) and even name variables as such. Related to issue #63

Implement game parameters copy

All game parameters classes should make a proper copy of themselves (so that agents don't ever get the actual objects to mess up the games).

To do:

• Pandemic
• Exploding Kittens
• Love letter
• Tic Tac Toe
• Uno
• Virus
• Colt express

Clean up framework code (core + all games)

The games being implemented sometimes use different systems and duplicate information in various places. I've started cleaning some of it up, but this is going to continue causing merge issues. Should be doing a hard stop on development and do a thorough clean-up across all games, to make sure we extract as much general logic as possible out of the specific implementations and simplify implementations of future games - as well as keeping all of this consistent, modular and well documented.

Further things to consider:

• All actions should have .equals, .hash and .toString implemented
• Actions in the core package should not have any specific assumptions (i.e. particular deck used for an action)
• Are interfaces for components actually needed? (only 1 class is likely to ever use that interface, seems to complicate things more)
• APIs for agents:
  • what information do they currently have access to?
  • what information should they never have access to?
  • what other information should they have access to?
• APIs for games:
  • what are new games required to implement?
  • what further logic could be extracted into the abstract classes?
  • final vs overwrittable (with/without content) vs abstract methods in all classes to clarify usability.
• Is the game rule system from Pandemic useful for other (complex) games so as to be extracted to the core package?

Next game: ... ?

How to deal with Observations vs GameState?

• allow agents to modify information in game state (the PO parts especially)

Diego: go through code

Generic GamePhase enum switch

Currently can't do switch statements with the game phase anymore. Any better way to extend the game phases available?

Components that are collections of other components (i.e. Deck) can be templated T (i.e. ArrayList<T>)

GameState.copy() shouldn't return decks in their order, shuffle? Probabilistic?

Consistency & documentation

There are still some differences in how games are implemented / using constructors or setup methods. Proposed:

• default constructors only, no other initialisation
• AbstractGameState.setComponents() -> used for initializing all components for the game, reading data from files etc.
• ForwardModel.setup() -> performs initial setup for the game (dealing cards to players, shuffling decks etc.)

Also, we should start writing proper documentation on using the framework with step-by-step for setting up a new game, game state, forward model, actions, GUI etc.

FM.next function clarification / breakdown

Something still missing is for an easier way for games implemented to remember all the things they need to add in FM.next() method to make a game work, i.e.:

• execute player action
• execute any game rules applicable
• check game over conditions, and if any trigger, set the gameStatus and playerResults variables appropriately (and return from next() function without changing player)
• move to the next player where applicable

We should either add more abstract functions in the FM to remind of this, or more easily add all of this information in documentation (both in code & in wiki).

GUI: human player

PCG considerations

Add types that could distinguish Event cards from City cards. Could be useful in other games.

AbstractAction.toString() methods not informative after removal of object references

toString() methods in actions often need context if they don't have objects as references. Adding a game state object would allow for retrieval of said objects so that printed messages are informative again.

Alternatively, more primitive parameters can be added to actions according to their print needs (i.e. deck names, current player etc.), but these would be more troublesome and cluttering.

History of actions

Use human GUI player functionality to debug and fix Pandemic logic

Player cards, specific rules per player

Pandemic observations

Main issue: actions have references to objects, copying those would mess everything up. Recalculating actions for every copy might be time-consuming. Potentially waiting for issue #46 to be resolved first, and also #38

Win conditions

Investigate feasibility of generating the list of actions, as well as checking viability of actions returned by agents? (if not index)

General Run class to play multiple games with agents

Clean-up Pandemic specific components

Actions moved to Pandemic, package separated from core

MovePlayer action has too many checks, which make it very specific

Actions cleanup

There are actions in games packages that are general (or could be made so) and should be moved to the general actions package.

For example, there is no need to have a DrawCard action for each game, when they do the same thing. Check for a lot of code duplication.

Investigate Event system

Prototyping GUI?

Default view for all Components, provided from the engine based on contents in the game state provided + raw list of actions, for testing.

Implement all actions (+ equals)

Add simple AI using forward model (OSLA)

Factored action spaces?

Reading a paper on this, and considering this as a future development.

We could additionally provide the option to get from the game state a list of action "shells", i.e. all the action types available with no variables assigned (if there are more than 1 option for variables in an action). Then, each action shell would provide:

• a list of valid options for each variable
• a way to correctly construct the action from one value per variable (generic, without need to know the types of the variables, but normal constructors still public as well)

Example: a "Move token" action would provide:

• options for variables:
  • token id: {57, 65, 80}
  • direction: {up, down, left, right}
• constructor with 2 integers representing indeces in the variable options arrays, and assigns the correct values
• can check if the resulting action is valid if it exists in the full list of actions provided normally by the game state

This could allow more granular/hierarchical planning.

Event cards are not fully implemented as they require more complex checks

Implement game-specific score heuristics

The game state implementations of getScore(int playerId) should return a numerical value of the game state (the bigger the better).

Games to do:

• Exploding kittens
• Colt express
• Love letter
• Uno
• Virus
• Tic Tac Toe

Refactor hashes into Constants class and use the same everywhere

Maybe use lowercase conversion for hashing? it would be less confusing to work with. Tried to get researchStations, but did not know how it was written

FM.next() called from GameState to allow FM usage to agents