I made this video to demonstrate how to get a score near 400 without using special buildings. On boardgamegeek.com people discuss and debate the expected scores for a single player game. Players have posted demo games before, but only as saves from a computer implementation. Mine will be the first video.

After making Le Havre, one of the pleasant surprises was how much fun the single player game is. I’ve played a lot of games and improved my score quite a bit. Before computerizing the game, I played the single player version on the physical board once. But the setup/tear-down and piece twiddling was just too much for a solo game.

I also made this video to draw attention to the touch table implementation. I’d like for other players to ask the publisher for permission to release my version. I’d also like to make boardgamegeek players more aware of gaming on the touch table.

Unfortunately the owners of Le Havre (lookout-games), aren’t willing to give me permission to distribute the game. I had hoped that they would since there is already a free Java version available online. But it sounds like they may have given an exclusive electronic license to someone else.

Read on for a comparison of this project to some of our other games and a bit of a postmortem.

I have spent a bit more than 150 hours working on this game. I wrote the whole project in torque script and ended up with 5120 “raw” lines of code and 1160 lines of XML to define the buildings and ships. Here is a comparison of this project to some of our other games

Le Havre was a large project, but not as large as our other “big” games. Part of the reason is that Le Havre turned out to be simpler than I expected. Another part is that I didn’t write the game in C++. C++ is naturally a bit bigger than script code due to all the headers. Writing in a mix of C++ and script also has some overhead because there is code to pass data back and forth.

There were several things that went well in this project.

• Writing exclusively in script saved time and effort. I certainly missed C++ at times, and I spent some time debugging problems that would never have happened in a strongly typed language.
• The dialog system for player interaction worked well. The “standard” resource in/out dialog worked for 90% of the buildings and players don’t seem to have issues with using a dialog instead of elements on the table.
• The Save/load/undo capability saved a lot of testing by allowing me to get the game into the state I needed to develop or test, add or test the new feature, fix code and get right back to that state.
• I added functionality to our common GUI element grouping code that made it easier to make groups of elements move, hide/show, and be deleted together.

My only real failure when writing this game was not being strict enough about encapsulating code. The script language doesn’t protect member data, and I was too lazy about accessing that member data directly. By the end of the project, it would have saved me time to write the access functions.

I’ll be taking a break before I start my next project. I am leaning toward Puerto Rico as my next conversion, and I think that it will be fairly straight forward. More like Le Havre than Hansa Teutonica. I want to take a break to get the conventions I used in Le Havre out of my head. If I wrote Puerto Rico right now, I would end up doing a lot of things like I did in Le Havre, even if that isn’t really the best answer for Puerto Rico.

Main progress this week:

• All the building actions for the normal and special buildings
• End game

I am still expecting another 40 hours or so of work on this game. I’d like to have quite a few more sound effects and player prompts and some better animation for resources being paid/received. And once beta testing starts, I’ll have usability improvements to make too.

There were very few graphics changes this week. I had to change the reference cards to include the value of the goods when shipped. Here is a screenshot of the game near the start of a five player game.

This week I spent 90% of my time putting in the building actions. The majority of buildings in Le Havre fit a pattern:

1. Activate the building.
2. Pay some set of resources.
3. Get some set of resources.
4. Repeat steps 2 and 3 1, N or unlimited times.

The rest of the buildings either provide some bonus to the player (end game points, or extra resources/energy), or have special text that describe how they work.

I wrote a set of classes to handle this standard case. A building has an activation cost and list of actions that the player can perform. Each action has a set of resources to pay, a set of resources to get and a number of times it can be done. The get/pay resources can be combined with AND or OR logic (only a couple cards use OR logic – the business office is one example). And the get/pay resources can include symbols like hammers and fishermen. There are also rules for “Energy” and “Food” which are really a collection of resources. Another complication is that you can use brick for clay and steel for iron. This makes the code and dialogs messier. The “easy” case ended up being 500 lines of code, which was more than I expected.

The buildings that provided bonuses were mostly special code, but they are all fairly straightforward.

That left the cards with special text. There were 18 buildings in this category (out of 62). I made the default classes easily extendable with lots of virtual functions, so adding these special buildings was easier than I expected. These buildings took 650 lines of code. The worst ones were the Wharf, Haulage firm and Shipping line. These required extra dialog boxes and significant code changes.

The most annoying buildings to add to the game were the Football stadium and the Luxury yacht. These are both special buildings (so they only come up once every seven games) that have a modest impact on the game but take a disproportionate amount of code. At one of my prior jobs, we had engineers who would design how the system was going to work and pass the requirements off to the developers. Sometimes the developers were told that a certain situation was uncommon or would “almost never happen”; as though that would make it easier to implement. That doesn’t make it easier to implement, that just makes it harder to test.

As of now, the raw line of code count is at 6100 plus the original 1200 lines of XML. After next week’s update most of the code should be written and I’ll include code counts for Hansa Teutonica and Power Grid for comparison.

Here are the progress highlights:

• Created graphics for player areas, offers, supply tiles and added animation of buildings and resources.
• Incorporated the timeline engine and added save/load and undo to the engine.
• Built the main menu: players can join, choose their color, pick options and start the game.
• Player area replication code.
• Added the “take offer”, “end turn”, “end round”, “buy building”, “repay loan” moves.
• Added the scoreboard and scoring logic (except end game bonuses).
• Created “feed workers” and “pay interest” dialogs.

The big things left to do are: all the buildings, end game. I feel like I am about half done with this project. We will see how accurate that estimate is. When estimating for a client, I always double my gut feel (and that is usually still too short). So I probably have another 3-5 weeks of work to go.

Graphics

After the first week, there were still some graphics to be created: supply tiles, offer squares, the player area, the scoreboard and some reference images. Here is what those areas look like now:

Timeline Engine

The last couple of games that we have created use our “timeline engine”. This is a system for scheduling actions or moves in a game. It allows do/undo and save/load of all the actions or moves added to the timeline. I’m using the timeline engine for LeHavre, so everything that happens in the game will be timeline events. This system requires some up-front work: all the events need to be able to undo themselves and return the game to its state before that event; and all the events need to be able to save themselves – which means they can’t use pointers since those values will be different when the game is loaded.

One mistake that I made when writing Hansa Teutonica was doing some things outside of the move system. This resulted in some bad behavior when a game is loaded: player positions could be different and the game played back all the animations that happened in the game. For Le Harve, I am making ALL actions into an event and I am building in an animation speed from the beginning.

While this timeline and move system adds some work, it also helps immeasurably during development. When I am building a new capability, I can have a saved game right before the new action will happen. I can try the new action, fix a bug, re-compile the scripts (within the game), reload the game and try again.

Main Menu

I setup the main menu with our standard conventions for joining the game and picking colors. When the “Start Game” button is clicked, the game generates a “new player” move for each person who joined which saves their color and position. Then it creates a “start game” move that builds the game with the options and number of players selected. This moves saves off the random seed used to shuffle the decks and pick the starting player. Finally, a special “no undo” move is added to the timeline to prevent players from undoing any of these setup moves.

Player area replication

This is the first game that we have created in the MIT version of Torque 2D that have player controls on the touch table. We don’t create the full player area for all the players. Instead, we build one player area and “replicate” it for all the other positions. The advantage of this method is that you can create the player area centered at 0,0 and oriented “up”, then replicate those GUI elements to other positions and orientations. I added some of our code from older games to the new engine for replication and kept most of our old conventions for determining what gets replicated and how the replicated GUI elements are accessed.

Moves

The majority of my time this week was spent on some of the easy moves. The game will now start up, move the first player boat to the supply tiles, reveal the tiles, and move the resources to the offer squares. The player can pick an offer, buy a building, repay a loan and end their turn. When the last supply tile is visited, the game handles end-of-round actions: the town builds a building, the ship card is revealed, the players get their harvest and feed their workers.

Getting the game model and GUI updated for each of these moves, and being able to save/load, do/undo the moves was probably 50-60% of my time this week.

Dialogs

I created two dialogs for player interaction. The first was the feeding dialog. This allows the player to decide which resources they will use to feed their workers. If the player doesn’t have enough food to feed all their people, the dialog shows the loans they are going to have to take. The second dialog is for paying interest. This could happen automatically, but I wanted to have a dialog to show what is going to happen and provide a pause for the players to consider paying back loans (which they can do at any time) before paying the interest.

The raw line of code count is up to 3767 plus the same 1200 lines of XML to define the buildings and ships.

Even with that idea, the space is still quite tight. I’ve had to create a different view of the buildings and ships for each “mode” that they are going to be displayed in to limit their size.

My main accomplishment this week has been coming up with a screen layout that will be able to display everything that the players need to see, and a design of the ships and buildings that will fit into that layout. I am now fairly confident that it will be possible to play this game on the touch table.

Here is the basic layout: The player areas aren’t started yet and will be drawn around the outer edge. In the top left are the three “building proposals” which are buildings that can be built. Below that are the special buildings that could come up. The middle column is a summary of what will happen in each round of the game and the right is filled with all the “built” buildings. The “built” buildings and ships will be colored by the player who built them.

There is space in the middle left for the supply tiles and offers and space to the right of the special building pile for the ships that haven’t been built yet.

A building or ships has three ways that it can be displayed: proposed, proposed summary and built:

To get these graphics, I scanned the resource tiles from the board game and used thenounproject.com to get icons for building types, ship, hammer and fisherman.

I started this project by copying the existing Blockers project. The Blockers project is based on the MIT license Torque 2D engine and implements our “timeline” engine.

The code that I wrote this week loads the buildings and ships in from XML files and draws the buildings and ships from the data. I’ve also written code to layout the regions and code that allows you to click on a “short proposed” building to see the full sized building.

In the game, a ship card also defines what will happen in each round (how much food is required, whether there will be a harvest, and what kind of building the town will build). One of the things that makes the board game difficult to setup is that which ships, which buildings, and the order of the ships depends on both the number of players and whether you are playing a short or long game. I have that information loading from the XML and the correct buildings and ships are added to the game.

The current raw line of code count is 1670. I also have ~1200 lines of XML to define the buildings and ships.

There are two issues with Le Harve that might make it difficult. One is the amount of stuff that needs to be displayed on the screen: During the game, players build quite a few buildings and ships and all of those need to be on the screen. But it is also possible that they wont built anything, so the “building proposal” area also needs to be able to hold all the buildings. The other issue is that there are quite a few buildings that have special rules. In the base game, I count 18 buildings that will need some special code.

I don’t expect to be able to get rights to sell this game. Le Havre is very popular (currently #11) and the amount of money that we could offer wouldn’t be significant to the creator of the board game. However, there is a Java implementation available online already, so I hope to be able to give away the game.

To get a feel for the time involved in making a board game conversion, I am going to make a blog post for every 40 hours that I spend on the game. I’ll describe what I’ve done during that week and the current state of the game.