Our group started playing this game at the beginning of the year and we’ve been surprised both by how much we’ve played it and that we are still enjoying it. The game has a fair amount of setup and piece moving so it is a good candidate for conversion. Converting it also allows it to play six players.

We have a couple house rules that I implemented as options in the game. The first is to make the game more interesting for more players. It seems like the “right” number of players is three. That means that players can add a card to their board every third roll. With four, five, and six players, I feel like I don’t have enough control and the “active” card powers are very weak. So we have an option for multiple players to be active and buy. In a four player game, we allow two players to use their active powers and buy and in a six player we allow either two or three.

The other house rule is a simplification of the game for kids. In this mode, all cards with abilities that need to be charged are removed.

There were a couple things that made the game difficult to convert. One was fitting all the cards onto the screen. For a six player game, I need to display 36 cards along the long edge of the screen. This means that each card gets 100 pixels. A lot of the cards have abilities spelled out in text and when I put that text into a 100 pixel card, it was too small to read. So I needed to create iconography for all of the abilities. I think that the icons and graphics came out pretty well. Players that already know the game like the icons better than the text. I haven’t had new players learn the game on the touch table yet, so hopefully it isn’t too confusing to them. The icons, and particularly the charge counters are still pretty small and can be hard to see on a standard monitor

The other difficulty for this game was making sure that all the players could take their rewards at the same time. This is how it works in the physical game (you just have to trust the other players to do it right) and I didn’t want the touch table version to slow that down. There are very rare situations where the order that the players perform actions matters and the computer version leaves it up to the players to act in the correct order in those cases. Normally I like to have the computer enforce all the rules, but I didn’t want to cause delays for something that happens less than once in five games.

I tried to use a new animation system for this game. My idea was to have a separate thread that does animations and the main event thread that is doing model updates would add animations to the animation thread. This worked great until I needed multiple animations running at the same time. When I ran into that problem (which is pretty common in this game since all the players can act at once), I backed out my new animation thread code and have the main thread kick off each animation in its own little thread.

There are a few problems with this system. The worst is that I still have timing issues caused by two events creating conflicting animations. I’ve reduced this issue by making the animations as small as possible, but it still caused problems during development. The other issue is that by combining animation code and model update code I’ve made all the code a little more complex.

I’m not sure what I’ll try for animation in my next project. If the game is linear (one player acts at a time), I’ll probably give the animation thread another try. But if it is more like this game I’ll probably just use this system again.

This game took 64 hours to create. I took a shortcut on the graphics and re-used a lot of my work from Galaxy Trucker. I spent more time testing this game, but the actual implementation went surprisingly smoothly.

I expected this to be a moderately large project, but it ended up being a little easier than I expected. I spent three weeks on it, putting in fairly long days because it was a fun project. This is the second Martin Wallace game that I’ve converted, and like Automobile, the game is complex, but doesn’t have hidden/unexpected complexity and was it fun to program because progress was constant. It ended up taking 70 hours which is really quick for a game that is considered as complex as Caverna or Terra Mystica – two of my longest projects.

One thing that saved me a lot of time was having done other games with similar mechanics. I was able to take a lot of the map and connection code from Concordia, and the web interface is a stripped down version of the Settlers interface.

Unfortunately Brass is only four player. It is also not very popular in my gaming group, so I don’t expect to get to play this conversion many times. Its probably going to be one of the games where I spend more man-hours converting it than it will have man-hours of play.

Board space was a big consideration for this project. The physical game takes a lot of space on a table:

To save space, I collapsed the player board down to display just the lowest level of each building. Players can touch their board to open up the stack of higher level buildings:

This saves a lot of table space and makes it possible to keep everything big enough to be legible on a 2K display. One thing that is still easier to see on the physical board are the resources on the built industry tiles. In the physical board game, the resources are cubes that sit on the otherwise flat map. Nothing on a screen will stand out like a real 3D cube, especially since I’m not using 3D effects like shadows.

The game has a web client where players connect to the game with their phone. The web interface shows the player’s their current cards and lets them pick one to play. In other games I’ve put game controls on the web interface, and players do like that system. However, it makes it harder for the rest of the players to see what the current player is doing. In games with web controls I end up having slower animations and a lot of voice saying what the current player is doing. To avoid that problem in this game, all the game controls are on the touch table, so players pick their card on their phone and then do everything else on the table.

Brass is a long game taking about 30 minutes per player to play. The table doesn’t change this a lot. There is just a lot of thinking time in this game, especially for inexperienced players. The touch version does save a lot of time, it’s just not a big percentage of the total. Having all the money and board setup/cleanup taken care of probably saves 15 minutes.

From a technical point of view, the big change for this game was the animation system. I’d tried it out in King Domino, but this was the first big game to use the new stand-alone animation system. I’d say the new system is an improvement, but is still not perfect. This game really stressed the animation system because it has a lot of the most difficult kinds of animation: where multiple model updates are happening at the same time and pieces are moving both to/from a location at the same time.

For example: A player builds an Iron mine. The player pays some money for the building, and buys some coal from the global market. Then the mine produces some iron which is sold back to the global market. In the model this all happens at once and causes three updates to the player’s money, two to the global market and adds the new building to the board with some of its iron sold. But it needs to animate one step at a time: Pay for the building, move the building to the board, pay for and animate the coal to the building, move the iron to the global market and animate gaining money from it. The new animation system means that I can push on each animation as it happens during the model update, but it doesn’t solve the other big problem of wanting to use the draw code during animations. When animating the first coal from the global market I’d like to use the market’s draw function to remove the bought coal. But if the global market does a re-draw, it will draw the newly sold iron before the animation has gotten to that step. So I end up writing extra code to incrementally re-draw the market for the animation and save the full redraw till all the animation is done. This causes duplicate code, so I don’t do it till I have to. But that causes its own problems as I have to re-visit old animation code that breaks as I add new animations and remove full re-draw calls.

I don’t think there is a perfect solution to the animation problem. In the next big game, I’m going to try to break up my draw functions into much smaller parts that can be called separately during animations and I’m going to be more aggressive about pausing model updates to allow animations to complete. I like to do all the model updates at once so that the player doesn’t have to wait for animations before doing their next action, but I’m going to move more towards making players wait.

This was a fairly short project, taking a couple weeks to do both games. I was able to use some of the code for tile placement and growing boards from Between two Cities. My main goal with this conversion was to make this four player game support six.

King Domino comes with enough tiles for 2-4 players. Queen domino is also 2-4 players with its own set of tiles. The games can be combined into a 5-6 player Queen Domino, but in my opinion, combining the games this way makes for a very long game with under-powered city tiles. So instead, I created extra tiles sets for each game to support up to six players. A six player game of Queen Domino is still a little to long, but it is faster on the touch table so it is still fun.

Another advantage of the touch table version is the scoring. It takes a while at the end of the game to score the board – especially in Queen Domino. Not only does the computer do this for us, but it displays the running score during the game so that you can see who is winning and get a feel for how much each tile/action helps you.

The conversion ended up being harder than I’d expected. Part of that was my expectations were unrealistic, but I also spent quite a bit of time on board layout and animations.

Board layout took a while because I was trying to maximize the size of the tiles. It didn’t really matter for King Domino, but in Queen domino there can be quite a bit of information displayed on a tile, so it needed to be as big as possible.

I tried out a new animation system for this game. I had a separate thread that handled all animation. The main thread would add animation routines/calls to the animation thread as things happened. This had the advantage of allowing me to created animations as the model was changed instead of isolating animation code in its own function. However, the actual animations still ran after all model updates, so the animation code didn’t have access to the old state of the model. This only became a problem when the model was updated multiple times before the animation got to run.

Overall I liked the new animation system well enough to continue to use it for my next game. This game had fairly simple animations, so I want to test the new system with a bigger game.

Galaxy trucker was fairly fun to implement. I’d expected the ship building part of the game to be difficult, but it came together quite quickly. Conversely, I underestimated the difficulty of everything else. The adventure cards were more difficult that I expected them to be. Most of the “new tech” tiles were OK, but hyperspace added a lot of complexity. I haven’t done a line of code count, but I’m up to 160 hours on the game.

I’m pretty happy with how the game turned out. I think that the ship building works well; I feel like the graphics are some of my best; and the computer version saves a lot of time in setup.

When considering this game for conversion, my main concern was the ship building. In the physical game, players pull face-down square tiles from the center, flip them over to reveal the tile, then add them to their ship by orienting them and matching existing connectors, or return them to the center. This is a very physical experience and is done quickly because the players are racing against each other to build their ships. I implemented this with a button for each player to draw a new tile, dragging the tile into position, and tapping to rotate it. The button to draw a new tile can only be pressed every couple seconds to simulate the time it takes to reach out, get a tile and put it back. Drawing or grabbing a new tiles returns the old one. When a tile is put back in the center, any player can drag it over to their board. All this works pretty well and it still feels like you are building a ship.

A couple things make this game better to play on the table. One is how quick it is to setup and tear down. There are a lot of tiles, astronauts, cargo, battery markers, etc. The tiles all need shuffled and arranged face down between each round and setting up the adventure deck isn’t trivial. The second big advantage is that the strength of each aspect of player’s ships is always displayed. There is an adventure card called the “combat zone” where players compare an aspect of their ship with each other. This involves a lot of counting to find the base strength and the maximum strength with batteries for each ship.

The part of this conversion that I am least happy with is the animation. I’ve been unhappy with how I do animations for the past year. The system that I use has significant advantages:

• animations are separate from the game logic so that during loading/undo I can easily skip all animation
• the draw functions are easy because they just draw the game state as it is.

But there are problems too.

• I have to be very careful about when things get drawn. Because the game logic is all separate from animation, when the player does something, the game model is updated immediately. And since the draw functions just draw the model as-is, if I call draw too soon, the GUI will be updated to new values/state before the animation is complete.
• To do animation separate from model updates, I often have to store a bunch of information so that I can animate what happened.
• I’ve been using a state machine for most of the game logic, while the animation code is part of the event system. So the event system will ask the state to animate what just happened, but that means that I need to keep track of all the states that were pushed/popped to the state stack during an event so that they can each animate.

I’m not sure what the solution is, but I think that in my next game I’m going to try creating a separate animation timeline. Currently, I have an event timeline. When players act, events are added to the timeline and executed in order. Events do the animation when they are done and can force a delay before the next event will be processed. I’ll use the same code for an animation timeline. As events (or the states) update the model, they will add little animations to the animation timeline which will get executed in order. During a reload/undo I’ll skip processing the animation timeline. I’m hoping that by formalizing animations as a time sequence I’ll have less trouble with the timing of draw calls and that by adding the animations during the model update I can avoid storing extra data needed for animation

But I’m glad that I finished it. The conversion plays well and it adds another relatively easy 7 player game to the touch table.

In the board game, players cooperate with their neighbors to build a city between each set of two players. Each round the players pick two tiles and add one to each adjacent city. You want the best cities, but your score is the lower of the two cities you worked on, so you need to keep your cities balanced.

Each type of tile has unique effects and is scored differently. Shops want to be in a line, offices want to be near entertainment, houses want a variety of tile types and don’t want to be next to a factory, etc.

All the tiles are 1×1 except in the middle round where the tiles are 2×1 or 1×2. It can be difficult to find a good tile and position in the second round.

The Capitals expansion adds a “Civics” tile that wants to be near two types and wants to avoid a third type. It also adds points for having the city with the largest “districts”. A district is made up of adjacent tiles of two types. This adds several new considerations for which tiles to pick and where to place them.

There is hidden information in this game (the tiles are hidden while you are selecting the two you want to place) so I created a web interface. I’m still happy using the React framework for building web pages.

There were two things that made this project difficult. The first was the non-standard board. A player interacts with the cities that are between the players instead of with their own pieces and a central board. The second was how the cities are built. Tiles can be placed anywhere adjacent to existing tiles. The only limit is that the city needs to end up being 5×5. So the play area grows out from the initial tile. I ended up creating an 8×8 model where the player only fills in part of the area. The display shows just the part of the city that has tiles. I also had a hard time with the wide/tall tiles. I think that the source of the trouble was not spending enough time thinking through and designing the way tiles would be modeled and moved before I started writing code. I wrote code for the first round where tiles are 1×1 and then forced the wide/tall tiles to fit into that pattern.

I’m not sure why it took me so long to complete this project. I did take a vacation in the middle of the project, but there was also a 10 day period where I was home but didn’t work on it at all, and even when I was working I was only putting in 2-3 hours a day. I definitely felt less excited about this project. I suspect that it was a mix of feeling lukewarm about the game itself and feeling like it should be easier than it was.

The best part of the converted version is how much time is saved scoring the cities. The scoring rules are fairly complex (especially with the Capitals expansion) and it is nice to have the score calculated quickly and correctly. I also display the score of the cities during the game to help the players to balance their cities:

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.

As you can see from the screenshot above, there is a lot going on in this game. Here is what the original board game looks like:

I put more text on the screen than I usually do in a board game conversion because we don’t play this game very frequently and I expect to need more rule reminders than usual. The three colored boxes on the lower right corner of the screen (bronze/silver/gold with hearts) are where the supply/demand helper lives. The computer is displaying how many cars of each of the three types have been produced, how many dealers and dealer slots there are and how much public demand there is expected to be.

The center area of the board shows the different models of cars and replaces the ring of car models in the original board game. The ring arrangement is actually a bit more intuitive, but this layout made it much easier to arrange the rest of the elements. In the computer version, the display changes depending if the model is currently under production, closed or yet to be opened. If a model is still available, I show a summary of the costs of that square and a quick comparison of the present supply and future demand for that model. When a factory is in operation, I display the built factories, cars and what the player would get if they closed the plant. Once a plant is closed, I show a “balance sheet” for that model.

I am very happy with how this conversion turned out. I think that the computer version plays well and displays a lot of information for the players without obfuscating the underlying mechanics of the game. It is too bad that we probably wont play it very often, because it does improve the game play and cuts the play time by nearly half.

This is the first big game that I’ve made after upgrading to a 4K TV to play the games on. I put more elements on the screen and probably made the text a little smaller than I would have if I’d been designing primarily for 1080p. I still want to be able to play the games on a 1080p screen, and all the text can still be read at 1080, but it is significantly nicer at 4K.

This project was also a lot of fun to work on. It took quite a bit of time (70 hours), but a lot of that time was making player aids, summary charts and optimizing the graphics/layout/animations. I went back to a simple state model for this game after the complex state of Notre Dame. But I’ll probably go back to the state machine implementation for my next large game.

I made a slight improvement to the event engine for this game. When the player takes an action it creates an event which updates the model and then does any animation needed. The animation function returns a number of seconds that the game should “wait” before accepting any more player actions. Usually that wait time is either zero or a constant. But other times it depends on how much animation is needed. This game had some complex animations and so I added a new capability to the event system itself. The old system looked like this:

IEnumerator mainLoop()
{
  while (true)
  {
    wait for an event
    event.do();
    yield return new WaitForSeconds(event.act());
  }
}

This would pause processing events till the animation was complete, but required event.act() to return the animation duration. The new system allows the animation to perform its own wait calls:
IEnumerator mainLoop()
{
  while (true)
  {
    wait for an event
    event.do();
    for (var iter = event.actCoroutine(); iter.HasNext())
      yield return new iter.Current();
  }
}
IEnumerator Event::actCoroutine()
{
  // do animation with interspersed yield return Wait calls
}

In the real code, I kept both act() and actCoroutine() as options by using reflection to detect which function the event implemented.
]]>
					
					https://blog.chadweisshaar.com/2018/03/20/touch-table-automobile/feed/
			1
		
		
			
		
		
		https://blog.chadweisshaar.com/2018/02/25/touch-table-azul-and-medici-card-game/
					https://blog.chadweisshaar.com/2018/02/25/touch-table-azul-and-medici-card-game/#comments
		
		
		Sun, 25 Feb 2018 15:25:03 +0000
				
		
		
		
		
		
		http://gator3305.temp.domains/~cweissha/blog/?p=1452

					Continue reading "Touch table Azul and Medici card game"]]>
										I made two small games for the touch table: Azul and the Medici Card Game. Azul is a tile placement game that was published recently and that I played at our last game day. The Medici card game is a variant of Medici that makes the game a bit simpler by removing the auction aspect. This does introduce a bit more luck, but Medici was already a bit random and the new version plays much faster.

I didn’t track the amount of time it took to make either of these games. Azul was about 20 hours and Medici was about 12. Medici was so quick because I re-used almost all of the original Medici.
Azul took a little more time than I expected it to. I had to redo the player interface a couple of times and the logic for handling situations where tiles can’t be placed onto the grid were more complex than I expected. The root of the problem was that I wrote the game without really thinking through the option of playing on a free board. When I went back to include that option, I had to make a lot of changes.
]]>
					
					https://blog.chadweisshaar.com/2018/02/25/touch-table-azul-and-medici-card-game/feed/
			1
		
		
			
		
		
		https://blog.chadweisshaar.com/2018/01/31/touch-table-notre-dame/
					https://blog.chadweisshaar.com/2018/01/31/touch-table-notre-dame/#comments
		
		
		Thu, 01 Feb 2018 03:34:14 +0000
				
		
		
		
		
		
		
		http://gator3305.temp.domains/~cweissha/blog/?p=1446

					Continue reading "Touch table Notre Dame"]]>
										I’ve completed a touch table version of the board game Notre Dame. In Notre Dame, players add influence to different sections of their city by playing action cards. Some sections give the player additional influence or money which can be used later while others are better for generating the prestige needed to win the game.

Implementation
There were several interesting things about implementing this game that may be useful in future projects.
Web interface
The action cards are private, and while I probably could have just put them on the touch table, I used React to build a web page to display them and other decisions. I didn’t do anything new with the web interface for this game.
I also kept the “State” design pattern from Broom Service. When the game sends something to a web client, it keeps track of that message to easily handle client disconnects and other errors.
By reusing a lot of the web code and design from Broom Service I saved quite a bit of effort.
Simultaneous play
In Notre Dame, it is common for players to act semi-simultaneously. The game is technically turn based, and each player is supposed to act in order; but in practice there is not a lot of interaction between the players and people take advantage of that to speed up the game by overlapping their turns.
I didn’t want the touch table version to slow down play by making everyone wait for their turn, so I allow players to act out of turn when possible. The game still keeps track of the real turn order and enforces it when the player’s actions might affect others.
Accepting actions out of order didn’t really make the game logic more complex, but it did complicate undo. Our normal event system uses a global stack of events (actions and game flow events). Undo removes the last action and re-executes the whole stack. But with player’s acting out of order, a player may want to undo their action, possibly without even noticing that another player or players have taken actions. To allow this, I created a per-player undo button. I implemented it in a similar way to Caverna. The player undo finds the last action taken by the player and removes it from the list of events, then re-executes all the events. The difficult part was separating the cases where that would cause problems and turning off the undo button in those situations.
State Machine
In the last few games, I’ve been experimenting with different ways to model the game state. In this game I went all-in on state modeling and implemented a per-player state machine. The player model has a stack of PlayerState classes to track what state the player is in (ie: played action card, selecting new district for friend. Or hired personality, selected garage, moving car). Each state class in the stack knows which know which parts of the player interface to enable/disable and can handle player input. The state classes update the game model when the players take actions and tell the GUI what to animate.
The state classes basically replace the functionality that used to live in the events. Now the events just ask the current state to handle the input. So all game logic is still done within an event execution, but it is the state doing the work instead of the event.
This design worked quite well for this game. In Notre Dame, the state is fairly complex: like Broom Service, actions can trigger other actions. The stack never gets quite as deep as Broom service, but there are a much wider variety of actions. Another thing that made this design work well is that there are very few distinct player actions. Most of the time players are either selecting a worker or a region. The effect of that selection depends on the current state of the game, but having very few actions means that the states only have to have a couple functions for handling player actions.
Complexity
Notre Dame ended up taking about 90 hours. The game doesn’t seem that complicated when you are playing it and I originally thought that it would be a 40 hour game. But when I read the rules with conversion in mind I realized that it was going to be a large project.
Adding to the complexity, I implemented two expansions for the game that add more “personality cards”. Many of these cards end up being special cases with custom code.
Final thoughts
I’m pretty happy with this conversion. The simultaneous play keeps the game moving, and I don’t have to worry about other players making a mistake on their turn when I’m not paying attention.
I’m also happy with the web interface and state machine designs that I used in this game and hope that they will be useful in the future.
]]>
					
					https://blog.chadweisshaar.com/2018/01/31/touch-table-notre-dame/feed/
			1
		
		
			
		
		
		https://blog.chadweisshaar.com/2017/07/25/touch-table-broom-servce/
					https://blog.chadweisshaar.com/2017/07/25/touch-table-broom-servce/#comments
		
		
		Tue, 25 Jul 2017 23:39:23 +0000
				
		
		
		
		
		
		http://gator3305.temp.domains/~cweissha/blog/?p=1262

					Continue reading "Touch table Broom Servce"]]>
										I’ve completed my touch table conversion of the game Broom Service. We were introduced to Broom Service at Essen. One of the many good games that we learned about on that trip.

In Broom Service, the players compete to gather resources, move around the map and deliver potions. The interesting mechanic is that in each round, players select four of ten cards to play. When you play a card you can play it bravely, betting that other players haven’t selected that same card, and get a bonus. Or you can play it cowardly.

Broom Service was a fairly typical conversion. I used the event system to do all the moves and provide save and undo. I built the UI with the Unity 2D UI system, getting most of the art from thenounproject.com.
One thing that was tricky in Broom Service was keeping track of the game state. I had to re-work the state system twice while making this game. I started with a simple enumeration to hold the state after deciding that the class system that I’d used in Village was overkill for this game. But I fairly quickly ran into states that needed to store quite a bit of data, so I switched back to state classes. Later, when I was adding the “advanced” tiles (mountain bonuses, teleporters and storm clouds) I found that a single state – even one with lots of data wasn’t enough. I needed to re-design and go to a stack of states, so that I could keep track of the history of states that a player gets into executing their move.
The most complex scenario that I found was: a player uses a brave witch to move to a mountain tile with a bonus that gives two free moves. They use the first free move to move their second witch to another mountain that gives a free weather fairy. They clear a storm that allows a free move. They use the free move to travel to a hill with teleporter. They use their second free move from the first mountain to move onto the third mountain and get the free deliver. They deliver that potion. Then, if their first witch is still in the first mountain tile, they could use their brave delivery.
The other difficult part of this game was making the web interface for the player’s hand of cards. Which role cards a player picks has to stay secret. For some games, we can put secret information on the table and have players use their hand to cover the data when it is shown. But the whole point of this game is guessing what other player’s have picked, and even a quick accidental glance could give away critical information.
I am using the same system that I created for 7 Wonders and the card games where the game runs a web server that serves up static websocket enabled pages to phone/tablet based clients over the local wifi. The game keeps track of the last page sent to each player to seamlessly handle disconnect/reconnect.
In the past, I have used react to create the client web pages. When I went to get the latest version of react, I was disappointed to find that react now requires a full node.js build environment. It probably wouldn’t really take that long to get everything setup, but I’d need to install npm, node, webpack, and Babel. And if I come back to this project to make an update a year from now, I’d have to hope that I could get my javascript build environment working again. And, this process would create would create a webpage that wouldn’t work without an internet connection to download all the javascript library dependencies (including react).
After some research into building a truly standalone react app, I found that I could go back to version 15.4.2 (only a few months out of date) to get a standalone version of the react.js and react-dom.js files. Since I had a lot of react code that I could reuse from the card game project, I went ahead and used this version. In the future, I’ll probably need to switch to a lighter weight javascript library like vue.js.
This project took a bit longer than I expected it to. I spent 78 hours working on the game. 10 hours of that was working on the web interface, which is actually shorter than I expected. The web code from the card game app was very reusable. I converted the playing cards into the role cards and was able to re-use the page to select a bid as well.
Otherwise the project was pretty normal in terms of how long I spent on each activity and how many lines of code I created per hour.
One of my favorite parts of this project was the brave/coward art and sounds. I went with a lion to represent the brave action and a chicken for the cowardly.
I then found a few versions of a lion roaring and a chicken squawk. Friends of ours had chickens at the time, so I was able to use a recording of their chicken as one of the chicken sounds.


There is a point in each round when someone is the last person with cards left to play. They play those cards “brave” because they know everyone else is out. When that I happens, instead of an real lion roar, I play the sound of a child roaring.

]]>
					
					https://blog.chadweisshaar.com/2017/07/25/touch-table-broom-servce/feed/
			2