Touch table Galaxy Trucker

I’ve been working on a touch table conversion of Galaxy Trucker since October. I’ve completed the base game and a few of the expansions (new tech tiles, five players, and side B ship hulls). I’m still planning to do at least some of the Rough Roads expansion.

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