Touch Table Medici and a discussion of project complexity

I’ve completed a touch-table version of Medici

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:

Task	Time	Percent
Asset creation	3 hr	17%
GUI layout	5 hr	28%
Coding	8 hr	44%
Testing	2 hr	11%

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:

Task	Lines	Percent
GUI layout	525	32%
Graphics/Animation	439	27%
Game model	99	6%
Game flow	236	14%
Full reuse	193	12%
Partial reuse	139	9%

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.