GenCon is one of the largest gaming conventions, drawing about 50,000 people this year. It uses the whole convention center and much of the conference space in the nine adjacent hotels. Most of that space is taken up by people playing board and card games. There were an overwhelming number of games being played at any one time. The event catalog had hundreds of events each hour and there were over 9000 events that they didn’t list because the program book was already 350 pages. The convention ran around the clock with games scheduled even between 2 and 5 am. There were huge rooms dedicated to D&D, Pathfinder and Magic. The largest board game companies had big areas in the exhibit hall with tables for people to play their games. But even that wasn’t enough; there were pick-up games on any free table and even on the floor in the hallways.

It is hard to convey the shear number of people playing games. In this photo you can see maybe 1/4th of the exhibit hall. The exhibit hall had maybe 1/3rd of the total games being played at the convention.

The main focus of the convention is probably role playing games – both table top and live action. Also popular are the highly themed (Ameritrash) games and games with miniatures:

At PAX, we spent most of our time in the Mesa Mundi booth playing our short and simple games with people who walked up and describing the technology. At GenCon, we spent very little time in the booth and the majority of our time in the gaming room. Due to some technical difficulties, we had twice as many time slots to cover as we had expected; and since it was a last minute change, those time slots hadn’t been advertised to the attendees and were lightly attended. So GenCon ended up being less intense and busy than PAX was.

GenCon also had a different atmosphere than PAX. The audience at GenCon is older and seemed more serious. There seemed to be less excitement and energy, but more focus and planning. Many of the attendees had pre-scheduled their time and signed up for the games they wanted to play. PAX seemed more free form and less regimented. I would also say that PAX was better run. There seemed to be fewer problems and a lot more volunteers/staff at PAX. The GenCon audience is probably a bit more likely to buy a touch table, and we spoke to several people who owned one already.

Like at PAX, having a big marketing budget makes a huge difference. The big companies were using space in the vendor room to demo their latest games and Mayfair brought in huge versions of their classic Catan games. On the other end of the spectrum, Hansa Teutonica, still ranked #56 on BoardGameGeek.com, was only being played at our table.

There were some interesting attractions at GenCon. They had 15 battletech virtual reality pods setup in one of the main hallways with a screen where you could watch the battle. There was also an area where attendees could build elaborate card houses called Cardhalla. They used donated Magic the Gathering cards, and raised money by letting people knock it down by throwing change at the cards. There was also a Cthulhu and Ninja Turtle made of balloons.

We came away from PAX with lots of ideas to improve our existing games and ideas for brand new games. We were energized and motivated by the excitement of the people who came to the booth. GenCon didn’t provide nearly as many new ideas/feedback and we ended up mentally exhausted. I don’t know if it was because of the different atmosphere, not being in the main booth as much, or just because it was our second convention. On the plus side, at GenCon we got to meet a lot more people who shared our vision of table-top games on the touch screen. Most of our Hansa players immediately saw the benefits to having a computer version where you could still sit around the table, face to face, with your friends.

There are lots more pictures in the gallery.

Machine code games was assigned one of the touch tables at the booth and we ran demos of our software. The booth was very busy and people were playing our games almost all the time. We were very happy with the reactions that we got from people. They seemed to really like the games and were always impressed with the touch hardware. You can see more pictures of the booth during PAX here.

All the vendors are in 1/2 of the 516,000 square foot expo hall. Even with all that space, the floor was crowded with a large portion of the 90,000 PAX attendees. Another 1/4 of the hall is used by the board game vendors and game tables and the PC free play area. The final 1/4 is for lines and a food court.

We arrived Thursday afternoon to help with the setup of the booth and to get our software running. This was the first time that we had seen Mesa Mundi’s new Monolith table. It is a very nice piece of hardware that combines a high end Samsung TV with a narrow IR touch sensor in a steel frame. It feels very solid and looks great. The picture is very good and the tempered glass means that touching the screen (even pressing firmly) doesn’t create any distortion in the picture.

Setup was fairly simple for the Mesa Mundi booth, but some of the larger vendors had large crews and rigging to assemble miniature buildings for their booths. We also saw the Intel people setting up the PC free-play area. This was a bank of 360 computers where attendees could play a wide variety of games.

When the expo hall opened on Friday, the line of people waiting to get in was huge. It was about 15 people wide and stretched back 500 feet. When the hall opened there was a mad rush of people to the big name games and vendors. They aren’t allowed to run so there was a lot of fast walking. During this rush to beat the lines, our booth was all but ignored. But it wasn’t long before the hall was full of people, and for the rest of the day the booth always had about 15 people checking out the tables.

We attracted people to our table with “Pair Soup“. It is a quick and easy cooperative game that made it less intimidating for people to come over and play. If they liked the game and seemed interested in seeing more, we would play “Fas Jack” or “Got It“. These games are competitive, but still pretty easy to learn. For most people, this was enough. They were ready to move on or to hear about the hardware itself. But some people wanted to keep playing. Over the course of the weekend we played all the games that were for sale (except Hansa Teutonica) many times. We even played a bunch of our incomplete games.

A lot of people were pleasantly surprised that the tables were for sale now, that they were running on windows PCs, and that most TVs can be converted to a multi touch table. I think that some people’s initial impression was that the table just ran MCG’s games. There was a lot of interest in the tables for both business and personal use. Some of the best reactions we saw were from people who had played our games for a while and said “I’d love to be able to run my D&D games on one of these.” When we pointed them to the next screen, which was running d20pro, they were so excited!

We were really happy to see how much people enjoyed and liked our games. We even gave an interview and signed autographs for someone collecting autographs from game developers. Several people commented about how great it was to be able to sit around a table and play games and a couple people said that it was the coolest thing at PAX. Considering that we were sharing the expo hall with huge game companies featuring their multi-million dollar titles, it was nice to see people interested in such a low budget production.

There were a couple of disappointments: We had hoped to demonstrate our system for transferring game controls to a phone, but we couldn’t get a WiFi network setup. We brought a wireless router along, but we couldn’t get a good connection even though we were just feet from it. I had also hoped that there would be more interest from board game players. I had expected some people to have heard of “Hansa Teutonica” and want to see the computer version, but that didn’t happen.

Overall it was a very good experience. We came back with a lot of ideas for improving our existing games and making new ones. We made contact with some interesting people and learned a lot about the state of the game industry.

What went wrong:

• Duplicating the model: We started this project by creating a C++ model of the game logic. Then we built a GUI using the Torque 2D game engine and its scripting language. There is some overhead in passing data and calling functions between the two. In our first design the GUI had knowledge about the state of the game. It seemed like we needed the game state for the GUI to behave correctly. This was a big mistake. As we built the GUI, we realized that we were re-writing a bunch of the model and game logic code in torque script and the two models would get out of sync with each other. And since one person was writing the C++ model, and another writing the script model, they behaved differently too. We ended up re-designing and making the GUI dumb. See the first bullet in “What worked”.
• Enums: We used C++ style enums throughout the model, but we didn’t bother to make them available on the GUI side. This was a mistake. We ended up spending more time translating back and forth between strings and enums and debugging problems than it would have taken to do it right from the beginning. On our next project, we will export all C++ enums to the script code as global variables like: $PIECE_TYPE::MERCHANT
• “Action” buttons on the GUI: Our GUI design has a set of buttons for each of the actions that the player can take during their turn. This seemed like a good idea, and may still work OK for brand new players. But experienced players quickly find the buttons to be a burden. They want to skip the step of clicking the action button and just take the action. For example, it is easier to just click on the piece or on the board instead of first clicking the “Place Piece” button. There are a lot of cases where we wouldn’t need the action buttons at all. You can almost always figure out what the user wants to do when they click on the game piece they need to manipulate. In the next game, we will only have “action” buttons for cases where it is required.
• Accidental touches: On the multitouch surface, accidental touches occasionally happen. The most common is to accidentally click with your sleeve. But people sometimes just touch the wrong spot, or are just trying to point and accidentally click. In a game as long as Hansa Teutonica, an accidental touch has to be undo-able.
• GUI <-> Model translator class. We made one C++ class that does all the interaction between the GUI and the Model. Isolating the interaction was a good design, but the function signatures in this class used GUI friendly variable types. In the future, we will perform the translation from model types to GUI types in this same class and make the functions called by the model take model friendly types.

What Worked

• Dumb GUI: See “duplicating the model” above for a description of the problem this solved. Instead of the GUI keeping track of the state of the game and updating the model, the GUI simply passes all the user actions back to the model and the model tells the GUI what to display and what dialog to show. When the model needs input from the players, it tells the GUI to request that input and provides a function to call when the player makes their selection. In the end, this ended up being extremely helpful. We were able to re-use a lot of GUI code for different parts of the game. More on that in the next section.
• Callback system: Once we decided that the GUI would be dumb, we needed to tell the GUI how to call back into the model with the player’s actions. For example: If the player is clicking on a house on the board, it may be because they are placing a new piece, moving a piece, displacing an opponent, claiming a road or placing a bonus tile. The model know what state the game is in and what to do with the clicked house, but the GUI just knows that the user needs to click on a house and needs to pass that back to the model. To do this, the model passes a function pointer to the GUI for the GUI to call when the user makes a selection. The new C++ lambda functions made this very clean. Here is an example from the model where the user is placing a piece and we need to ask them which house to place it on:

  GameGUI::highlightLocations(validMoves);
  GameGUI::openSelectHouseDialog( [this](House *dest) { placePiece_House(dest); } );

  The first line tells the GUI to highlight the valid houses. The second tell the GUI to ask the player to click on a house and then to call a function with the clicked house. Since placePiece_House is a member function, we use an anonymous function that has access to the <this> pointer. Compared to member function pointers, this is very clean. Here is another, more complex example:

  GameGUI::openSelectTypeDialog(data->displacedPlayer->name(), true,
          [this, validHouses](Player::PieceType type) {
            GameModel* model = this;
            // Ask the GUI where they want to put the piece
            GameGUI::highlightLocations(validHouses);
            GameGUI::openSelectHouseDialog([model, type](House* dest) {
              model->addBonusPiece(true, type, nullptr, dest);
            });
        });

  Here I needed access to some of the local variables within my callback. This would have required new member data or a data passing structure without lambdas.

• Move system: We knew that in a long and complex game like Hansa Teutonica, we would need to be able to save/load and undo moves. In our shorter games, we often don’t forgive mistakes. The game goes on and there is no way to undo. But in an hour plus game, you don’t want to lose because of a mistaken click. To implement this in the model, we used a standard pattern of keeping a stack of Moves. The Move class has the functions ‘do’ and ‘undo’ along with the ability to save and load itself from a file. Each move type is derived off the base move and adds the functionality that it needs to execute itself. This system ended up working well. Even though there was a lot of save/load code to write for all the moves, loading a game is just re-executing all the moves. And, once loaded, the undo stack is still available. There were a couple cases where the moves were multipart and we wanted the GUI to update after each part. So the do/undo paradigm had to be broken for those moves. As the model executes and the move is built, the GUI is updated. When the move is completed, doMove is never called. This is a bit dangerous because the doMove function is still used when the game is loaded.
• No const: In my ‘professional’ career and on previous personal projects I always used const member functions and parameters. I ignored const on this project and haven’t regretted it. For a project of this size, using const adds effort for almost no benefit. It is nice to know that a function wont change an input, but the cost of maintaining it is too high.
• Board generation in the GUI: The GUI needed to know more about the board than the model since it needed the on screen location of all the elements. So we put board building in the GUI. As the GUI builds the board, it makes calls into the Model to add cities/roads/etc. And, by keeping the board building in the GUI, it is easier to move a city or road.

Here is a small portion of the board. The cites, offices, roads and houses are all on. The roads are being built programatically based on a source and destination city and a source and destination direction vector. The board still needs to show the upgrades that can be gotten at some of the cities.

Here is the player board. This is for the active player. Inactive players wont have the buttons at the bottom. It still needs to show the cubes covering the non-upgraded ability levels.

Here is a code snippet of two functions that I wrote to try out the new C++ 11 features. They are both doing the same basic thing: Given the value of a member variable, find the object in a vector that matches that value. First, here is what it would have looked like before:

Item* Object::findItem(const string& itemAttribute)
{
  for ( vector<Object*>::iterator oIter = myItems.begin();
        oIter != myItems.end(); ++oIter )
  {
    if ( (*oIter)->attribute() == itemAttribute )
      return *oIter;
  }
  return nullptr;
}

Here is the same basic idea using the new “for each” syntax. Notice that it is much cleaner. And I don’t have to create the iterator variable at all. There are certainly cases where you are going to need the iterator, but this isn’t one of them.

City* Board::findCity(const string& name)
{
  for each ( City* city in myCities )
    if ( city->name() == name ) return city;
  return nullptr;
}

Finally, here is the version using lambda functions. I’d had high hopes for this approach and was a bit disappointed with the results. There are certainly cases for using lambda functions, but this isn’t really one of them. Though, if this were in a performance critical part of the code, the lambda function might be a bit faster. Also notice the use of the “auto” keyword to declare the iterator. This is another new feature, and is a great benefit. Using either of the two new approaches, I don’t have to know what kind of collection I have to use the collection.

Player* Board::findPlayer(const string& name)
{
  auto pIter =
    find_if(myPlayers.begin(), myPlayers.end(),
            [&name](Player* p){ return p->name() == name; });
  if ( pIter == myPlayers.end() ) return nullptr;
  else return *pIter;
}

William has already written GemHoarder and we have decided that the next game will be Hansa Teutonica.  It is a relatively new game that we really enjoy. The game doesn’t have a lot of different cards or exceptions that make a conversion difficult.

We are going to write the game with the Torque 2D game engine. William has already incorporated TUIO events into the engine. It is a C++ engine and I will be creating the back-end game model. The game is turn based, and on each player’s turn they can perform 2-5 actions. We know that we will need to be able to undo actions because the player may click in the wrong place, or just change their mind. The later happens regularly in the physical version. So I am going to create a model of the players and the board and then a move system that modifies the model. Finally, there will be some kind of game-runner that interfaces with the GUI to find out what the player wants to do, constructs the move, has the move apply itself, and then saves the move so that it can be undone.

I am also looking forward to trying out some of the new features in C++ 11. My previous C++ application was written with Visual Studio 2008 because the CLI/.NET intellisense is broken in VS 2010. Since I wont be using any of the managed code for this project, I can use VS 10 which supports most of C++ 11. The features that I am planning to try out are the “for each” statement and the Lambda functions.