I’ve finished converting Caverna for the touch table and PC. This was the second game that I’ve made using the Unity engine. It is also my first Unity game that used touch for input and it is probably the largest game that I’ve ever converted. Space was very tight and I spent a lot of time laying out the graphics:
Caverna is a game for one to seven players by Uwe Rosenberg. It is a worker placement game where you manage the farm and cave dwelling for a family of dwarfs. The game is similar to Agricola where the occupations and improvements are replaced with rooms which are available to everyone and there is a new expedition mechanic.
The game is a lot of fun to play, but it takes 30-45 minutes per player and there are lots of pieces to move around. My goal for this conversion was to speed up the play time as much as possible. I’m also hoping that the single player is as much fun as the single player version of Le Havre.
To achieve my main goal of speeding up the game, I wanted more than one player to be able to play at the same time. In Caverna, players take turns placing one of their dwarfs on an action space, then doing the action on that space. Sometimes doing the action is just taking resources. Other times it requires placing tiles, picking a room or arranging animals. The slowest actions are the expeditions where the player needs to pick up to four rewards from a list. In the computer version, I allow a player to pick their action as soon as the prior player picks their action. This means several players can be resolving their actions at the same time.
To allow players to undo and save/load games, I am using our “Timeline and Events” system of game development. All player and game actions are an “Event” that can be executed, undone, saved and loaded. The timeline keeps track of all the events and executes them in the right order.
For multiple players to resolve an action at the same time, each player’s action are still added to the timeline in the order they happen. But when a player wants to undo, they want to undo the last thing THEY did, not the last thing that happened. This is fine as long as the event they are undoing doesn’t affect any other players. I handled this by allowing the player to use an undo button in their player area if they are undoing an action that only affects them. If other players depend on the action about to be undone, you have to click a different undo button in the shared table area. This lets the other players know that they may be affected by the undo.
Along with the added complexity of multiple players acting at once, the players can arrange animals and make trades (goods for food or rubies for goods and tiles) at any time. When the player decides to make a trade, they can be in the middle of any of the other actions in the game. To handle these cases, I ended up keeping the state of each player as a stack. So a player might be in the state WAIT/PERFORM_ACTION/BUILD_ROOM/TRADE which means that they took an action that let them build a room, but the decided to perform a trade to get the resources they needed.
The three player games that I’ve played have taken about an hour instead of 1:30 plus setup/teardown. My first test of a six player game included one brand new player and two players who hadn’t played for a year. The game took a full 3 hours after rules explanation. I am disappointed that the computer version didn’t save much time for that game. It is hard to judge from one learning game, but it seemed like the main problem was that most of the player’s thinking time was immediately before they picked their action, so the parallel action resolving didn’t help. I’ve added code to the game to keep track of how much time multiple players are resolving an action at the same time so that I can see exactly how much time is being saved.
Caverna takes up a lot of physical space and I spent a lot of time laying out the game so that it fit on a 1920×1080 screen. Here is a nicely setup game for one player:
and a full table needed for the seven player game:
Fitting all this onto a computer screen required that I make every action card as small as possible, keep the player areas as small as they can be while still being big enough to click on, and (unfortunately) making the room display a scroll region in some cases. I used Unity’s new UI system which has very good layout management. This allowed me to split the main part of the screen between the action cards and rooms. As the game progresses, action cards are added, but rooms are built and removed. In most games, the room area never has to scroll.
To help the players plan their turn, I included a help panel that shows all the expedition rewards, the action cards that haven’t been revealed yet, and all the bonus point rooms (with the number of points they would be worth to that player):
I’ve also added a couple of options to the game to fit the play style of my gaming group: Revealing the action card order and harvest type early, and a different way to do turn order. In Caverna, there is a action a player can take to become first next round. That is fine, but for simplicity, turn order is always clockwise. So the new second player has a better turn order position without having done anything to earn it. We prefer a turn order track where taking the “first player” action just bumps that player to the front and leaves the rest of the order unchanged. This is a bit cumbersome to keep track of, but when the computer handles it for you it is easy.
Caverna ended up being the largest game that I have converted, both in terms of hours and lines of code.
Game | Script | C++ | Other | Total | Hours |
---|---|---|---|---|---|
Yacht | 2218 | 0 | 0 | 2218 | ? |
Fire Platoon | 4027 | 4697 | 1115 | 9839 | ? |
Hansa Teutonica | 4891 | 7107 | 0 | 11998 | ? |
Le Havre | 5117 | 0 | 1161 | 6278 | 150 |
Vegas Showdown | 4209 | 0 | 110 | 4319 | 80 |
Caverna | 9544 | 0 | 1298 | 10842 (plus scenes) |
200 |
Unity hides quite a few lines of code in it’s scenes and prefabs. These hold the GUI positions, sizes, settings, colors, layout rules, etc. To get an estimate of the amount of code that would be, I look at the number of hours I spent writing the script code compared to the hours spent in Unity. For this game, I spent 95 hours writing the scripts, 77 hours in Unity (includes testing time), 18 hours in Photoshop and 8 hours doing pen and paper design.
So I estimate an effective 16000 lines of code.