3k-dome / catan-engine Goto Github PK

Harbors are currently assigned to the whole tile, which in turn gives all neighboring settlements (up to three) access to the harbor, while they should only be accessible by two specific settlements.

Irrelevant for now, but very important once trade makes its way into this sim.

Implement a cube coordinate system for our hex tiles.

The user manual describes a specific order in which rims, tiles, and chips are placed. This needs to be recreated.

The edges of the map consist of six pieces made out of three tiles in a distinct order. These pieces build the edge of the map. None of the tiles have any specific terrain and therefore do not produce any resources, but some of them allow trading. Trading may be available as a universal trade or a discounted trade for a specific resource.

The player with the longest consecutive road is assigned two victory points. Therefore, the length of each player's longest road needs to be calculated.

Since each road network might contain cycles, a full search seems to be required. Given that the longest road can at most be as long as the total number of roads in a given road network, we can order them by size and start the search with the first, stopping early if a road is found that is longer or as long as the next network would be in total size.

We could run this search over all players combined, but upcoming features may require not only identifying which player has the longest road, but also the length of each player's longest road.

Implement a bank component.

The bank would then be used as a central interchange during resource generation and, later on, also for development cards. Currently, all resources are infinite, but there are actually only 19 cards of each resource, which are distributed by the bank.

Needed changes for now:

• Use the bank during resource generation.
• Add a constraint to check whether the bank can satisfy the whole production of one tile.
• Since building pieces are currently just resources, we might need to move them into their own enum and interface, which would be quite similar to the resource one.

All currently implemented player encodings are destined to fail.

The current encoding does not accommodate for any games in which the AI agent is not player one since all encodings are in player order, i.e., player one, player two, and so on. And since there is no way for the agent to know which player it represents, the agent would likely fail to understand the encoding.

Therefore, a new encoding system is proposed, which always puts the player whose turn it is in the first position of the encoding. Additionally, other players are simply referred to as opponent one to three, in order.

The new encoding would, therefore, keep the player the AI represents always in the same position in the vectorized state for each agent, whether it is player one or any of the others. This, in turn, would provide a more generalized and streamlined model input.

The simulation already provides an interface to serialize its whole state into a vector and an optional interface to provide a descriptive vector for the first one. We could use these to serialize the game state to other formats, like CSV, which could then be easily processed and analyzed using other tools.

For now, this should include CSV generation using the descriptive vector as the header and the other one as value rows for each unique game state (i.e. a snapshot is taken after each agent made a move).

Since this simulator is going to be used as a training environment for ai agents, the whole game state should be able to be written into a plain vector. This vector could then be used as input for a neural network.

Most of the implementations in Road or Settlement, and so on, could be moved into their interfaces as default implementations. Derived classes that need to change those may then override or extend them.

Observable variants of those classes could then call the default method and simply send update notifications on properties that don't send them automatically. For example, an obserable Player class would only need to send property changed events after any resource changes since dictionaries are not observable.

Production Circles are placed on each tile in Settlers of Catan to indicate which dice roll will produce resources for players who have settlements or cities adjacent to the corresponding tile.

I don't know what these tokens are actually called.

Catan is made up of a board of many different hex tiles. Each of these tiles belongs to one specific terrain type.

We need to make a small fix that requires us to change the type of the player collection to a static sequence, such as a plain array. Otherwise, LINQ queries like the one inside the Catan constructor will just stack on top of each other, resulting in the players being shuffled every time the player collection is queried.

Some objects currently serialize redundant or unnecessary information. We should remove those to simplify our observation space.