I’ve finished my touch table conversion of the Settlers of Catan board game. I also converted the expansions: Seafarers of Catan and Cities and Knights
It ended up being a larger project than I expected, but I’m pretty happy with the game.
Why Settlers
Settlers is a game that we played many, many times when we were just getting into board games. We really enjoyed the game and bought the Seafarers and Cities and Knights expansions along with the 5/6 player expansions for all three games.
I’ve made a “Settlers Helper” app at least three times in different languages. The app would help to build a random but fair board and to reduce the randomness of the dice.
But as we got new games and different players in our game group, we’ve played Settlers less and less. So it has never been a high priority for conversion – especially because it has hidden information and is fairly complex.
But we’ve converted all the low hanging fruit and I’ve been running out of things that I really want on the table. When I picked Settlers, the other games I was considering were Brass and Age of Steam. These are both relatively complex/difficult games that are also not played very often. Brass is only four player and Age of Steam has had two new version released since we bought our copy making it tough to know what rule set to implement.
Issues
Settlers ended up being more complex than I imagined and has turned out to be one of the largest games that I’ve converted. Settlers and Seafarers took 100 hours and Cities and Knights took another 100+. Part of the complexity is the board. I’ve done hexes before, most recently in Terra Mystica. But Setters has an especially complex map because the model has to include the hexes, the vertices and the edges. All three parts can be selected and have elements and state. There are also somewhat complex rules for building and the calculation of the “longest road” is a bit messy. Along with the map, the other complexity is all the progress cards in Cities and Knights.
So one issue was underestimating the complexity. This lead to one re-factoring to fix some classes that were getting too big. I also had to do some re-work and re-testing of base Settlers and Seafarers when I implemented Cities and Knights. I also spent too long manually creating maps before writing a map editor.
Another issue was animation. I still haven’t found a pattern/system that I am 100% happy with. It is getting better, but on my next game I might try some event/listener driven GUI updates for things like the scoreboard, status icons and buttons.
What worked
Settlers has been implemented by several different companies – mostly for online play. So I had several places to look for interface ideas. Most useful was the Xbox trading implementation.
The state machine system that I used in Notre Dame worked quite well. With the state machine pattern, I still use the Timeline and Events to handle player interaction, but those classes mostly just tell the state machine what the players did. The state machine then updates the game and player models and the state of the game.
Settlers, and particularly Cities and Knights, has fairly complex state and I was able to re-use states for multiple scenarios.
Another part of states that worked really well was for highlighting possible actions on the map. In Terra Mystica, my MapGUI class had a huge if/then/else tree for detecting what parts of the map to draw and highlight. In Settlers, there was still some special code, but in general, the state could tell the map what hex/vertex/edge was clickable or highlighted.
The react based web page continues to work well. The react class system kept the different pages manageable and let me re-use some code for drawing resources and resource up/down dials. On the server side, I re-used the WebState system that I’ve used for the last few web games. The timeline events and game state can send a WebState to a particular client. This WebState is sent out over the web socket and also stored. If the player refreshes their page or disconnects and reconnects, the server can re-send the last state. The web clients hold almost no state/logic of their own and can be re-built from the WebState data.
Finally, making a map editor was a good decision. It took a little time to write, but saved me a lot of tedious and error prone data entry. Looking back on it, I probably should have made a map editor for Concordia.