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.

For both being touch-table conversions of board games, they were very different projects. Medici was small and took less time than I expected it to. Age of Discovery was a large project, and it ended up being even longer than expected.

Age of Discovery is a worker placement game set in the colonial period. Players take on the role of a colonial power trying to establish the best empire by discovering and settling the new world.

Age of Discovery is a recent re-print of a game that we own called Age of Empires III: Age of Discovery. We’ve played our version regularly (though not frequently for many years). The new version includes pieces for a sixth player, new buildings and a new worker type.

I’ve been hesitant to computerize this game because it is fairly large and we don’t play it that often. However, it does play six and doesn’t have any hidden information. It also takes quite a while to setup and it can be hard to quickly see the state of the new world and how each player is doing.

Complexity

Unlike Medici, this conversion took quite a bit longer than I expected. Part of the difficulty was that the buildings in the expansion ended up being more complex than I was expecting. But there were also a lot more graphics to collect than I thought, and the game flow ended up being messier than I expected.

Art assets

Medici had fifteen new images that I pulled from asset packs or the internet. Age of discovery had 48. It also had three times as much audio. All the audio in Medici was pulled from old projects, while Age of Discovery has seven new sound effects. I am not an artist or good with creating audio effects, so I use thenounproject.com and a variety of free audio websites to find art and sounds that I can use in my games.

Unique buildings

I underestimated how many of the buildings in Age of Discovery would need special code. A common feature of some board games are assets that you can acquire during the game that grant a benefit or let you break the normal rules in some way. My previous conversion of Le Havre is another example of a game with lots of buildings the players can acquire. When I started this project, I assumed there would be about ten “types” of buildings and there ended up being 20. What was worse; 13 of those needed a dialog for player interaction (more on that later).

Something that can be non-intuitive is that the number of buildings doesn’t really matter. Age of Discovery has a bunch of buildings that all provide a benefit (a type of worker, some money, etc) each turn. All those buildings use the same code and count as one “type” or “class” of building. It took less time to write the code to handle those 15 or so buildings than it did to handle a single building that gives the player a one-time choice of two specialists.

Game flow and state

Another factor that makes a game difficult to computerize is complex game flow. In a simple game like Medici or most card games, players take turns doing something and then there is some end of round or end of hand cleanup. Age of Discovery has many stages of action. First, players take turns placing their workers in the action areas. Then each action area is executed for each worker in that area. These actions usually involve player input. Then there are end of round and end of age actions.

Here is a much simplified view of the game flow in Age of Discovery. The details aren’t really important, what I want to show is the number of loops:

for three ages
  for two or three rounds
    Place workers in turn order skipping players who are out of workers
    Execute actions
      for each colonist slot with a worker
         ask the player where to send the worker
           possibly give player a trade good
      for each trade slot with a worker
         ask the player which trade good
      for each building slot with a worker
         ask the player which building
            perform the building ability (showing Papal Edict)
              ask player which other player will place workers
                ask first player for territory
                ask second player for territory
      for each warfare slot with a worker
         ask the player if war or battle
           if war declared
             for each territory
               ask attacker for casualties
               ask defender for casualties
           else pick territory
              pick casualties
    Trade Income
    Buildings
  Score regions

At the inner-most levels of the nesting, the game is holding lots of state to keep track of where we are in all the higher level loops. All of these levels and loops adds complexity, but the real problems happen when the game needs to ask the player something. Then the software has to break out of all these loops, get the player input and then resume where it left off.

I used our standard event system to perform the actions in this game. The event system is still great, but doesn’t really help with managing game state. The next time I do a game with this level of complexity, I’m going to add a state machine, or at least a state class and a stack of states, to the model of the game. Without a formal state model, I ended up adding a lot of member variables to the player and game classes to hold state. This is frowned upon in object oriented programming, but more importantly, it creates a lot of opportunities for error. Either by forgetting to reset these variables at the right times or by making it hard for the GUI code to tell what state the game is in and therefore what to draw on the screen.

At 93 hours, Age of Discovery took about five times as long as Medici. The following table compares the relative time that I spent on each type of task in the two projects.

To get an estimate for the lines of code created by Unity for GUI layout, I estimated that each hour of coding created 90 lines of new code (15 less than in Medici). At that rate, the time I spent on the GUI would be 1982 lines of code. So the GUI layout and Coding tasks are further broken down by what type of code they create:

Age of Discovery is a large game, but it isn’t the the largest that I have done. Both Caverna and Terra Mystica are bigger games that I made in the Unity engine. It is harder to compare Unity projects with older Torque projects (especially since I didn’t keep track of hours for my early projects). But I think that Le Havre was about the same size, Fire Platoon, Power Grid and Hansa Teutonica were a bit bigger.

Medici was an interesting project because of how simple it was. It is my first conversion project that has taken significantly less time than I thought it would and is also the quickest that I’ve been able to make a new game.

Medici is a bidding game where players are merchants trying to monopolize trade in five different goods. In each round, players bid on goods to add to their carpet. Once all the carpets are full or there are no more goods, players get points for having the most valuable goods on their carpet. All the goods are then added to the city and players get points for having the most of each type of good. Repeat for three rounds and the game is over.

Medici was a good game to convert because it is simple, plays six people, and doesn’t have hidden information. Another advantage is that players have to spend a relatively large percent of the time moving pieces and adding up scores.

The computer also helps the players by adding up the value of each player’s carpet and shows what would change if you won the bidding for the current set of goods. In the screenshot above, the blue player is bidding on a single 4-point rune. The game is showing the current state of the carpets and city and has dotted pieces for where blue would be if they won the bid.

I expected Medici to take 40 hours to convert. The game ended up being simpler than I expected and I was able to reuse a lot of graphics from prior projects. It only took 18 hours to do the conversion, making it one of the quickest projects I’ve done.

Medici was easy for a couple reasons: The game doesn’t have many distinct parts and it has very simple game flow. The only pieces in the game are the trade goods and the score markers. There aren’t different cards with distinct rules or items that give abilities or change the rules.

Medici also has simple game flow. By that I mean that there aren’t a lot of different stages to the game or things that interrupt the normal flow. In Medici, there is a dealer that rotates. After each deal, all players each get one chance to bid on the goods. The dealing continues till one of two conditions are met and then there is a scoring phase where they players have no input. So there are basically three big loops running:

for each of three rounds
  pick the start player
  while we aren't out of cards or slots
    have the dealer draw cards
    for each player who has space for the goods
      get the player's bid
    award the cards to the high bidder
    rotate dealer clockwise
  score the carpet
  score the city
declare a winner

This is about as simple as a board game ever gets. There are a few things that I’m not including above, but it is still pretty simple.

I’ve counted the lines of code in this project with a code counter and got 1106 lines of code. This includes the C# script code that runs the games and animates the pieces. It doesn’t include the creation and layout of all the graphics on the screen.

The 18 hours I spent on this project are broken down in the following tasks:

To get an estimate for the lines of code created by Unity for GUI layout, I estimated that each hour of coding created 105 lines of new code. At that rate, the time I spent on the GUI would be 525 lines of code. So the GUI layout and Coding tasks are further broken down by what type of code they create:

At my former employer, they would take all the new lines of code (partial reuse counted as 1/2) and divide by the total number of hours worked. They were shooting for ONE line of code per hour. By that formula, I produced 76 lines of code per hour. Of course there are many ways this comparison isn’t valid: Multiple people working together are less efficient because they have to communicate with each other; the projects at my former employer were much, much, larger and many times more complex; the problem they were solving was less well defined than converting a board game. Having created a lot of touch games, we have a lot of conventions and standard ways of accomplishing tasks. The high lines of code per hour is mostly because I already know what I’m going to write when I sit down to code.

While the actual code reuse is pretty small, we have conventions for how to do most of the parts of this game: Getting the players assigned to a spot around the board and a player color picked; how to create the per-player GUI elements once and have them replicated for all the players; how player actions change the state of the game; how undo and save/load works; building the scoreboard and assigning a winner. Even something as simple as having rules for how big touchable buttons need to be on the screen saves time.

For a simple game like Medici, I spent most of my time working on the graphics. That is a bit frustrating, since it is my least favorite part of the project. For me, the best part of creating any game is writing the game model and the game flow. Of the 18 hours spent on this project, the “fun” part was 3 hours and 15 minutes.

My next game Age of Discovery which will be a much larger project. I will do this same analysis for that game to see how it compares.