This game was a bit simpler than Puerto Rico and Le Havre and I was able to re-use a lot of code and conventions from those games. It still took about about 80 hours to complete. I’d guess that I spent more time making graphics in Photoshop than I did for the last two games, but I am happy with the look of the game. I wrote the game in torque script and ended up with 4200 “raw” lines of code. Here is a comparison of this project to some of our other games

I haven’t contacted the publisher to see if I can distribute this game. They had an online version of Vegas Showdown linked from the official page, but that link no longer works. Vegas Showdown is an older game that isn’t as well ranked as some of the other games that I have converted, but I still don’t have high hopes for getting permissions.

This is probably the last game that I will create with the Torque game engine since we are migrating to the Unity engine. It is going to take some time to learn Unity and to replace some of the capabilities that we have built up over time in the Torque engine. But I am looking forward to writing code in C# instead of torque script and using the Unity game builder.

Unfortunately the owners of Puerto Rico (Alea), aren’t willing to give me permission to distribute the game. I have also talked to the creator of Tropic Euro, and they have given me permission to make a version of their game. It would take a little work to convert Puerto Rico into Tropic Euro, but then I could release the game.

I have spent about 90 hours working on this game. I wrote the whole project in torque script and ended up with 6682 “raw” lines of code. Here is a comparison of this project to some of our other games

I was able to re-use quite a bit of my Le Havre conventions and some of the code. The Puerto Rico code was easier to write (per-line) than Le Havre was because Puerto Rico needed a lot of code to layout the graphics while Le Havre had more game logic.

There were several things that went well in this project.

• Writing exclusively in script saved time and effort. I missed C++ at times, and I spent some time debugging problems that would never have happened in a strongly typed language. But being able to quickly add data to objects and not having to keep two versions of the game model save a lot of time.
• The dialog system for player interaction worked well. I particularly like how the dialog system allows all the players to think about and play their action at the same time. More about this below.
• 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.

One of the lessons from Le Havre was to encapsulate the member data with access functions. I didn’t follow my own advice in this game, but it didn’t end up biting me too often. I was a bit more careful about always defining the variables in the same place so that I could quickly look up the correct names.

Puerto Rico ended up being a mostly dialog driven game. In the game, one player selects a role and then all the players take the ‘action’ associated with that role. In my version, when a player selects a role, a dialog comes up for all the players to perform their action. Here is what the captain dialog looks like:

The dialog has a ready button that you click after choosing your action. If the first player isn’t done yet, a check appears in the box. If your selection is still valid when it is your turn to act, your pre-selected action is executed and your dialog closes. If an earlier player takes an action that invalidates your selection, your check mark goes away and you have to select a new action.

I think that this dialog system is a big part of why the game plays so much faster than the board game. Even if players wait till their turn to act, they have at least looked at their options and started thinking about it. Having the invalid options grayed out also saves time.

Another time saving feature is that the game summarizes all the information that affects each role in a table next to that role. So instead of having to look around at what all the players have on their boards, the relevant information is collected in one place.

This is the captain table and it shows the state of all the boats, how many of each type of good the players have, how much warehouse space the players have, who has a harbor and wharf.

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.

To get OGG support back, I started by downloading the latest OGG and vorbis (1.3.4) libraries. I added them as sub-projects in VC2013 and set them to build static libraries with the /MT runtime library. Vorbis depends on OGG, so you will need to add your OGG directory to the include dependency for vorbis.

Once you have the libraries built, you need to setup Torque to use it. The easiest place to add the capability is in audio/audioBuffer. I set it up to look for a .ogg file if the .wav doesn’t exist. That way you can develop your game with .wav files and replace them with .ogg files before delivery.

//Add the following functions to audioBuffer.h
   bool readOgg(ResourceObject *obj);
   long oggRead(struct OggVorbis_File* vf, char *buffer,int length,
		    int bigendianp,int *bitstream);

// Add the following functions to audioBuffer.cc
#include "vorbis/vorbisfile.h"
static size_t _ov_read_func( void *ptr, size_t size, size_t nmemb, void *datasource )
{
   Stream *stream = reinterpret_cast<Stream*>( datasource );

   // Stream::read() returns true if any data was
   // read, so we must track the read bytes ourselves.
   U32 startByte = stream->getPosition();
   stream->read( size * nmemb, ptr );
   U32 endByte = stream->getPosition();

   // How many did we actually read?
   U32 readBytes = ( endByte - startByte );
   U32 readItems = readBytes / size;

   return readItems;
}

static int _ov_seek_func( void *datasource, ogg_int64_t offset, int whence )
{
   Stream *stream = reinterpret_cast<Stream*>( datasource );

   U32 newPos = 0;
   if ( whence == SEEK_CUR )
      newPos = stream->getPosition() + (U32)offset;
   else if ( whence == SEEK_END )
      newPos = stream->getStreamSize() - (U32)offset;
   else
      newPos = (U32)offset;

   return stream->setPosition( newPos ) ? 0 : -1;
}

static long _ov_tell_func( void *datasource )
{
   Stream *stream = reinterpret_cast<Stream*>( datasource );
   return stream->getPosition();
}

/*!   The Read an Ogg Vorbis file from the given ResourceObject and initialize
      an alBuffer with it.
*/
bool AudioBuffer::readOgg(ResourceObject *obj)
{
   ALenum  format = AL_FORMAT_MONO16;
   char   *data   = NULL;
   ALsizei size   = 0;
   ALsizei freq   = 22050;
   ALboolean loop = AL_FALSE;
   int current_section = 0;

#if defined(TORQUE_BIG_ENDIAN)
      int endian = 1;
#else
      int endian = 0;
#endif

   int eof = 0;

   Stream *stream = ResourceManager->openStream(obj);
   if (!stream)
      return false;

   OggVorbis_File vf;
   dMemset( &vf, 0, sizeof( OggVorbis_File ) );

   const bool canSeek = stream->hasCapability( Stream::StreamPosition );

   ov_callbacks cb;
   cb.read_func = _ov_read_func;
   cb.seek_func = canSeek ? _ov_seek_func : NULL;
   cb.close_func = NULL;
   cb.tell_func = canSeek ? _ov_tell_func : NULL;

   // Open it.
   int ovResult = ov_open_callbacks( stream, &vf, NULL, 0, cb );
   if( ovResult != 0 )
   {
      ResourceManager->closeStream( stream );
      return false;
   }

   const vorbis_info *vi = ov_info( &vf, -1 );
   freq = vi->rate;

   long samples = (long)ov_pcm_total( &vf, -1 );

   if(vi->channels == 1) {
      format = AL_FORMAT_MONO16;
      size = 2 * samples;
   } else {
      format = AL_FORMAT_STEREO16;
      size = 4 * samples;
   }

   data=new char[ size ];
   if (data)
   {
      long ret = oggRead( &vf, data, size, endian, &current_section );
   }

   /* cleanup */
   ov_clear( &vf );

   ResourceManager->closeStream(stream);
   if( data )
   {
      alBufferData(malBuffer, format, data, size, freq);
      delete [] data;
      return (alGetError() == AL_NO_ERROR);
   }

   return false;
}

// ov_read() only returns a maximum of one page worth of data
// this helper function will repeat the read until buffer is full
long AudioBuffer::oggRead(OggVorbis_File* vf, char *buffer,int length,
          int bigendianp,int *bitstream)
{
   long bytesRead = 0;
   long totalBytes = 0;
   long offset = 0;
   long bytesToRead = 0;
   //while((offset + CHUNKSIZE) < length) {
   while((offset) < length)
   {
      if((length - offset) < CHUNKSIZE)
         bytesToRead = length - offset;
      else
         bytesToRead = CHUNKSIZE;

      bytesRead = ov_read(vf, buffer, bytesToRead, bigendianp, 2, 1, bitstream);
      if(bytesRead <= 0)
         break;
      offset += bytesRead;
      buffer += bytesRead;
   }
   return offset;
}

// Finally add the following code to the AudioBuffer::getALBuffer() function right after the
// if(len > 3 && !dStricmp(mFilename + len - 4, ".caf")) block
// The code is basically going through file types. It checks .wav, then .caf and finally
// .ogg
      else if(len > 3 && !dStricmp(mFilename + len - 4, ".ogg"))
      {
#  ifdef LOG_SOUND_LOADS
         Con::printf("Reading Ogg: %s\n", mFilename);
#  endif
         readSuccess = readOgg(obj);
      }

Edit: Thanks to Frogger on the garagegames.com forum for pointing out another code change that should probably be done.

// Add the .ogg extension to the resource manager in the OpenALInitDriver function in audio_ScriptBinding.cc
ResourceManager->registerExtension(".wav", AudioBuffer::construct);

In computer programming, when you make an application like the PracticeLog. You are using all of the built-in tools of the C# programming language and Windows graphics environment. With a good set of tools, you can build a simple windows program without having to write too much of your own code. This is kind of like buying the crust and can of filling and putting it together.

Game programming traditionally starts with fewer building blocks than application programming. For programmers who haven’t written a game, it can be hard to imagine where to start. But there are a variety of tools available that make game programming easier. Even with these tools, making a game is more like making your own crust and filling. The most popular game engine is Unity, but it is primarily a 3D engine, and it doesn’t provide you with the source code. The game engine that we use is called Torque 2D. It is specialized for making 2D games and the source code is provided. Getting the source code allows us to make changes to the engine at the lowest level which allows us to easily add things like QR Code generators and web servers.

Torque is made by GarageGames and they have been charging $130 for the engine and then also charging for support to companies that need it. Early this year, GarageGames decided to change their business model. Instead of selling the engine, they decided to give away the engine and just sell support. So they changed the license to the MIT open source license and setup a GitHub project. At the same time, they made some big changes to the engine itself to improve performance, incorporate Box2D, and to remove a few features that couldn’t be released as open source.

It took a while for the new version of the engine to stabilize, and we’ve made so many upgrades and modifications to the old engine, that we were hesitant to switch. But shortly after GenCon, William started work on the new engine. He added touch support and fixed a bunch of bugs in their code.

He has now got a playable alpha of a mini-golf game written in the new engine. It takes advantage of the new Box2D physics engine and looks like it will be fun. We have also decided to go to a single executable model. All of our games will run as modules in one executable that we are calling “Table Of Fun”. There are a couple big advantages to this. Having a separate executable for each game was taking up a lot of space and making our builds take a long time. We had written a launcher for the old engine so that we could see all the games and run them. Now we will have the launcher built into the program itself.

In my version of the game for the touch table, you can play more than one game at a time so that lots of people are rolling simultaneously. Here 10 players are playing 12 games:

Since there are so many variations of Zilch, I support a fairly comprehensive set of options:

To avoid clutter on this options screen, I created a new up/down box. In the past I have used left/right or up/down arrow buttons placed next to the text box. This adds a lot of elements to the screen. For this game, the up/down elements are very small and placed within the text box. These are too small to be clickable, but let the user know that the value can be changed. When the user taps on that text field it expands to this element:

The +/- icons are large enough to be touched accurately and when the “x” is pressed, the element shrinks back to its original look.

The other interesting thing about making this game was the large number of on-screen elements. When 10 players are playing 20 games, the center grid is made up of 231 elements and there are another 45 elements on each player’s area for a total of ~680 elements. Even if those were just static sprites the frame rate would drop to ~25 fps on our table. With most of those elements having to draw text, the frame rate dropped to ~10 fps. This frame rate made the dice rolling look very choppy.

To solve this performance problem, I needed to reduce the number of elements on the screen and stop drawing so much text. To reduce the number of elements, I created a new custom GUI element in C++ for the main scoreboard and another custom element for the player’s game board. To keep from drawing so much text, I created a bitmap font at the approximate size that I needed for this game and wrote code to manually draw each character where it needs to be. Both of these changes required code that was more complex than the original, slow, version. But the result is that the game can run at ~80 fps.

The game itself is fun. I am curious what it will be like with more players. But with two players it is more fun that plain zilch.

So far I have the game implemented with the player controls on-screen:

Since there are lots of games with this basic rule set (see the Wikipedia entry for Oh Hell) I have made the game very flexible. The intro/login screen is a bit overwhelming with all the options:

The next step is to start making the HTML interface and to do more testing of the different options. I’d also like to make an AI that can do more than play randomly.

I have also been re-visiting all the old games and updating them with our newest coding conventions and systems. As we have created more touch games, we have created a set of standards and utility functions that make coding faster and easier. Some of the first games that we made used very different systems for things like handling touch input, making a copy of the interface for each player, saving preferences, doing splash screens, etc.

It took almost a week to revisit all my old games and update them with our latest code. Hopefully that work will make it easier to upgrade those games and will allow us to apply more bug fixes to all the games at once.