Implementation

There were several interesting things about implementing this game that may be useful in future projects.

Web interface

The action cards are private, and while I probably could have just put them on the touch table, I used React to build a web page to display them and other decisions. I didn’t do anything new with the web interface for this game.

I also kept the “State” design pattern from Broom Service. When the game sends something to a web client, it keeps track of that message to easily handle client disconnects and other errors.

By reusing a lot of the web code and design from Broom Service I saved quite a bit of effort.

Simultaneous play

In Notre Dame, it is common for players to act semi-simultaneously. The game is technically turn based, and each player is supposed to act in order; but in practice there is not a lot of interaction between the players and people take advantage of that to speed up the game by overlapping their turns.

I didn’t want the touch table version to slow down play by making everyone wait for their turn, so I allow players to act out of turn when possible. The game still keeps track of the real turn order and enforces it when the player’s actions might affect others.

Accepting actions out of order didn’t really make the game logic more complex, but it did complicate undo. Our normal event system uses a global stack of events (actions and game flow events). Undo removes the last action and re-executes the whole stack. But with player’s acting out of order, a player may want to undo their action, possibly without even noticing that another player or players have taken actions. To allow this, I created a per-player undo button. I implemented it in a similar way to Caverna. The player undo finds the last action taken by the player and removes it from the list of events, then re-executes all the events. The difficult part was separating the cases where that would cause problems and turning off the undo button in those situations.

State Machine

In the last few games, I’ve been experimenting with different ways to model the game state. In this game I went all-in on state modeling and implemented a per-player state machine. The player model has a stack of PlayerState classes to track what state the player is in (ie: played action card, selecting new district for friend. Or hired personality, selected garage, moving car). Each state class in the stack knows which know which parts of the player interface to enable/disable and can handle player input. The state classes update the game model when the players take actions and tell the GUI what to animate.

The state classes basically replace the functionality that used to live in the events. Now the events just ask the current state to handle the input. So all game logic is still done within an event execution, but it is the state doing the work instead of the event.

This design worked quite well for this game. In Notre Dame, the state is fairly complex: like Broom Service, actions can trigger other actions. The stack never gets quite as deep as Broom service, but there are a much wider variety of actions. Another thing that made this design work well is that there are very few distinct player actions. Most of the time players are either selecting a worker or a region. The effect of that selection depends on the current state of the game, but having very few actions means that the states only have to have a couple functions for handling player actions.

Complexity

Notre Dame ended up taking about 90 hours. The game doesn’t seem that complicated when you are playing it and I originally thought that it would be a 40 hour game. But when I read the rules with conversion in mind I realized that it was going to be a large project.

Adding to the complexity, I implemented two expansions for the game that add more “personality cards”. Many of these cards end up being special cases with custom code.

Final thoughts

I’m pretty happy with this conversion. The simultaneous play keeps the game moving, and I don’t have to worry about other players making a mistake on their turn when I’m not paying attention.

I’m also happy with the web interface and state machine designs that I used in this game and hope that they will be useful in the future.

In Broom Service, the players compete to gather resources, move around the map and deliver potions. The interesting mechanic is that in each round, players select four of ten cards to play. When you play a card you can play it bravely, betting that other players haven’t selected that same card, and get a bonus. Or you can play it cowardly.

Broom Service was a fairly typical conversion. I used the event system to do all the moves and provide save and undo. I built the UI with the Unity 2D UI system, getting most of the art from thenounproject.com.

One thing that was tricky in Broom Service was keeping track of the game state. I had to re-work the state system twice while making this game. I started with a simple enumeration to hold the state after deciding that the class system that I’d used in Village was overkill for this game. But I fairly quickly ran into states that needed to store quite a bit of data, so I switched back to state classes. Later, when I was adding the “advanced” tiles (mountain bonuses, teleporters and storm clouds) I found that a single state – even one with lots of data wasn’t enough. I needed to re-design and go to a stack of states, so that I could keep track of the history of states that a player gets into executing their move.

The most complex scenario that I found was: a player uses a brave witch to move to a mountain tile with a bonus that gives two free moves. They use the first free move to move their second witch to another mountain that gives a free weather fairy. They clear a storm that allows a free move. They use the free move to travel to a hill with teleporter. They use their second free move from the first mountain to move onto the third mountain and get the free deliver. They deliver that potion. Then, if their first witch is still in the first mountain tile, they could use their brave delivery.

The other difficult part of this game was making the web interface for the player’s hand of cards. Which role cards a player picks has to stay secret. For some games, we can put secret information on the table and have players use their hand to cover the data when it is shown. But the whole point of this game is guessing what other player’s have picked, and even a quick accidental glance could give away critical information.

I am using the same system that I created for 7 Wonders and the card games where the game runs a web server that serves up static websocket enabled pages to phone/tablet based clients over the local wifi. The game keeps track of the last page sent to each player to seamlessly handle disconnect/reconnect.

In the past, I have used react to create the client web pages. When I went to get the latest version of react, I was disappointed to find that react now requires a full node.js build environment. It probably wouldn’t really take that long to get everything setup, but I’d need to install npm, node, webpack, and Babel. And if I come back to this project to make an update a year from now, I’d have to hope that I could get my javascript build environment working again. And, this process would create would create a webpage that wouldn’t work without an internet connection to download all the javascript library dependencies (including react).

After some research into building a truly standalone react app, I found that I could go back to version 15.4.2 (only a few months out of date) to get a standalone version of the react.js and react-dom.js files. Since I had a lot of react code that I could reuse from the card game project, I went ahead and used this version. In the future, I’ll probably need to switch to a lighter weight javascript library like vue.js.

This project took a bit longer than I expected it to. I spent 78 hours working on the game. 10 hours of that was working on the web interface, which is actually shorter than I expected. The web code from the card game app was very reusable. I converted the playing cards into the role cards and was able to re-use the page to select a bid as well.

Otherwise the project was pretty normal in terms of how long I spent on each activity and how many lines of code I created per hour.

One of my favorite parts of this project was the brave/coward art and sounds. I went with a lion to represent the brave action and a chicken for the cowardly.

I then found a few versions of a lion roaring and a chicken squawk. Friends of ours had chickens at the time, so I was able to use a recording of their chicken as one of the chicken sounds.

There is a point in each round when someone is the last person with cards left to play. They play those cards “brave” because they know everyone else is out. When that I happens, instead of an real lion roar, I play the sound of a child roaring.

Village has an interesting mechanic where you manage the life and death of your workers. All your workers start as farmers and can be trained as specialists. Actions take “time” to perform, and when enough “time” has passed, a worker dies. A limited number of each type of worker is rewarded with fame and victory points upon death while the rest get an anonymous grave. The key is making the best use of your workers and their time while  trying to arrange a good death.

This game was similar in size to Age of Discovery. There were two parts of this project that were time consuming. The first was just the number of different actions that a player can take on their turn. There were just lots of (relatively easy) cases to implement. The second difficulty was for the “Inn” expansion. That expansion added a lot of unique cards to the game that the players can buy and use. Each card needed to be coded. So again, a lot of fairly simple cases to implement.

I was able to re-use all the standard code, along with my map code from Concordia.

As you can see, the screen is pretty full. The game takes up a lot of room on the table too. It felt like I spent more time than average laying out the graphics for this game. Honestly though, it always takes a long time to do the graphics for a game. It used to be something that I really disliked, but as I get used to Photoshop and Unity, I’m enjoying it more. Now my least favorite part of the game is audio and animations.

Game state

I used our standard event system to perform the actions in this game. The event system is great, but doesn’t really help with managing game state.

In most games I have an enumeration of game states, and data about the state of the game is stored in either the player or game class. This works well for games with relatively simple state. After doing Age of Discovery, I knew that it would have been better to have a full state machine or at least a set of state classes. I haven’t done that for any of my games, so I decided to try it out for this one.

I didn’t make a full state machine, but I did make a set of classes to store what state the game is in and any data that I need about that state. When I had an enumeration, it was easy to check what state the game was it. I had lots of code that looked like:

if ( Game.theGame.CurrentState == Game.StateType.PickAction &&
     Game.theGame.ActionArea == Game.ActionType.Travel)

Now that I was keeping a stack of classes to represent the state, I was going to have code that looked like

if ( Game.theGame.StateStack.Count > 0 && Game.theGame.StateStack[0] is GS_PickAction &&
     (Game.theGame.StateStack[0] as GS_PickAction).ActionArea == GS_PickAction.ActionType.Travel )

That may not look like a big difference, but I ended up writing a line of code similar to that 125 times in this project. So to save some typing, I added some templated convenience functions and ended up with if checks that looked like:

if ( Game.theGame.isCurrentState<GS_PickAction() &&
     Game.theGame.CurrentState<GS_PickAction>().ActionArea == GS_PickAction.ActionType.Travel )

I think that having state classes is probably a good idea. It keeps the model code cleaner since I don’t have to keep adding member variables for storing state details.

For Village, I made events that were not state dependent but were instead action dependent. So instead of having an event for picking a worker to kill, picking a worker to train, and picking a worker to activate, I had one event called PSelectWorker that then checked the state of the game and did different things.

Unfortunately, that made my events grow larger and larger as I added each part of the game. The event classes ended up being too complex and difficult to maintain. Instead, I should have put a lot of the event functionality into the state classes. So I’d still have a PSelectWorker event, but the event would then ask the current state to handle the selection of a worker.

Next game I will try this method.

Hours and Lines of Code

At 85 hours, Village is a standard “large” project. This is probably my favorite length for a project. It is long enough to feel like a big game and have interesting challenges, but not big enough so that I start forgetting how I implemented things in the middle of the project.

I was able to reuse some art assets from other games and the rest of the assets were fairly easy to find. As usual, I used thenounproject for most of the art and Unity assets for the audio.

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

At 5847 lines of code and 85 hours, this project was very similar in size to Age of Discovery. That makes it a large game – maybe a bit larger than I expected it to be. But not nearly as large as a very complex game like Caverna or Terra Mystica.

It is also really nice to be able to re-use so much from other projects. I started the GUI for this project by copying the layout from Age of Discovery. This gave me a lot of the main menu, camera, canvases and controller setup for free. But I did have to spend a bit of time cleaning up the rest of the GUI.

Trips

We had two week long trips this year. The first was to New York in September to visit my brother. He had a second child this summer and I wanted to meet him.

We did a lot less touring than we did on our first trip. But we did go to see Roosevelt Island where we did some geocaching, and we had a great dinner at Aquavit.

We also went to San Carlos with our friend Doug in October. We have taken both of our parents, but this was the first time a friend came along. We flew into Phoenix and rented a car. It was a fun trip. We did most of the geocaches in town, took a hike in Nacapule canyon, and spent a lot of time on the beach.

We also went to Cheyenne Mountain Zoo in Colorado Springs with friends for an after hours tour. And I went to Grand Junctions for my cousin Brenda’s wedding.

Violin

I’m still not taking violin lessons, but I am still practicing violin. After stopping lessons, I’ve been going back through the Suzuki material, trying to play the pieces with more accuracy and at the correct speed. The first few books went quick, but books 4 and 5 took longer and at the beginning of 2016 I was in the middle of book 5.

I got 354 hours of practice in 2017, so I am falling a bit behind my goal of an hour per day. I’m currently in the middle of book 7. The next song that I will work on is the song that I played for my first violin recital in 2012. That was the first time that I made a recording of myself playing, so I’m looking forward to comparing with my past self. That first recital happened after playing for three years.

In June I bought the Yamaha YEV-105; a five string electric violin. I’m using that as my main practice violin and have been teaching myself viola. That has gone a little better than I expected. I started with the book “From Violin to Viola” and then Suzuki viola book 4. Learning the alto clef wasn’t too bad, and getting used to an extra string (above when playing viola music, and below when playing violin) didn’t take too long either. I’m still not as comfortable in the alto clef as I am in the treble clef.

When I read about learning viola after violin, several people said that the easiest way to play was to pretend that the music is in the treble clef and that you are playing violin in third position. That sounded crazy, but is actually very natural. Unfortunately, you don’t have to learn the alto clef to play like that, and once the viola music has higher positions and/or lots of accidentals, it’s better to know what the notes are.

Touch Games

This was a very productive year for Dark Infinity. We made 13 new games, including 7 board game conversion. We didn’t do any conventions with Mesa Mundi this year, but we did take the table to the Conclave of Gamers here in Denver where we were interviewed by Distract-O-Vision. They made a nice video of us and our table.

In roughly chronological order, we wrote: Terra Mystica, Starship Factory, Card Games(Linko, Karma, Turn the Tide, Oh Hell, Sequence), Concordia, Tzolkin, Castles of Burgundy, Can’t Stop, Qwixx, Spin Mummy, Gem Thieves, Medici, and Age of Discovery.

Other

We continued our tradition of hosting a bi-weekly game night and also enjoyed quite a few off-week game nights hosted by our friends.

My brother’s family came to Colorado for Christmas this year and it was fun to see them and to have our whole family together in Loveland.

Plans

We don’t have any big plans for 2017. Mostly more of the same – making touch table games, violin, etc. We will go to San Carlos again for a longer visit this spring, but we don’t have any other trips planned.

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.

I’d done one card game (Wizard) in the Torque engine and I used the web interface to keep player’s card’s on their device. I wanted this implementation to be more generic and support multiple card games.

I planned to use Unity’s built in networking and have the server run on the touch table with an Android application that players would download to their phone to show their hand of cards.

Unity has a nice networking API with three layers of increasing abstraction. The bottom layer lets you do everything yourself. The middle layer keeps the raw sockets hidden and lets you send your own messages between server and clients. It also has a local network discovery system. The top level provides a system for sharing unity’s game objects between the server and client, keeping track of players, etc. I felt like the top level API was intended for games where the player controlled an avatar in the scene. It is also limited to communication between two instances of the same application. Because Unity can’t have the same project open twice, I’d planned to develop this game as a separate client and server application, so I chose the middle networking API.

This may have been the wrong choice. About half the way through the project I did a test with six or seven players and we had a lot of trouble with getting everyone connected and with connections dropping. The higher level API may have better error handling code than I wrote, so we may have not had these issues. I also ended up making a single application for both client and server after finding a work-around that allowed me to have the same project loaded in unity twice.

I decided to make a web version of the client due to the network issues, the difficulties in getting a large group of players to download an Android app, and the lack of an iPhone app. I followed the same pattern that I used for the 7 Wonders web client. It took quite a bit of time to write the web client, but I still really like the React javascript library. The web client is probably not any more reliable than the Unity network based Android client, but it is quicker to re-connect when things go wrong and doesn’t need to be installed.

This is the game lobby where players connect. The Unity android clients use the Unity local discovery system, or players can type in the IP and port manually. The web clients can scan the QR code or type in the web address.

I ended up creating five card games: Linko, Karma, Turn the Tide, Sequence, and Oh Hell. Once I had the basic system in place, adding new games was pretty quick. It took 14 hours to write the framework, the unity networking and to write the first game (Karma). Turn the Tide took 7 hours and Sequence took 9. Then I did the web client which took 26 hours. This included time to make the networking layer more generic so that it could handle different connection types. This also included the time to combine the game into one application instead of a server and a client. Then I added Oh Hell which took 10 hours. Finally I spent 6 hours testing and putting in fixes for all the games.

The games themselves are pretty simple, especially compared to the last couple board games that I converted.

To reuse code between games, I created a system for generically rendering a card and for determining which card(s) can be played from a hand. All the games also use the timeline and event system, so moves can be undone and the games can be saved.

My networking code is broken into two layers. The bottom layer handles the Unity network and/or websocket connections and knows how to send the actual messages. The top layer interfaces with the game logic and keeps a copy of the setup messages and the last game message so that the network layer can handle a client re-connecting.

I plan to continue to add card games to this system as I find games I’d like to convert.

This year we stayed with the rest of the Mesa Mundi team in Norwood (about 25 miles out of town) and rode with them to and from the convention. We got to spend a lot more time with them this year and even met Toby and Rebecca’s kids. It felt more like we were members of the team.

See all the pictures of the Mesa Mundi booth.

As usual, we had one touch table and 1/4 of the booth to use to run our games. We were busy all the time. Convention goers were always quick to step up to play a game though lines were rare. It is hard to describe how big this convention is. The expo hall was expanded this year and there are 255 exhibitors. When the convention is running it takes 5-10 minutes just to walk from one end to the other and there are always people walking by or checking out the booth.

We mostly played Pair Soup and Dungeon Raiders along with quite a bit of Fas Jack and Got It. But we played most of our quick games at some point during the weekend. The new games – 20 Questions Wrong and Egyptian Ratslap, were popular among the competitive groups. We also had some very competitive Pair Soup groups. One group from 2014 came back to set a high score. They set a great score, but they were blown away by a new group that stopped by a couple times on Sunday.

This year we had a new game launcher that was full screen and looked more professional. A combination of that and having eight new games changed people’s reaction to our table. After finishing an intro game and dropping back to the launcher, people often commented at the quantity of games available. I don’t know if that will turn into any touch table sales but it did seem to help people’s opinion of spending $4000 on a gaming system.

We didn’t get out to see much of the rest of the convention. Bill got a ring from CritSuccess. Also nearby was a board game booth selling Pixel Glory. Bill bought the game and talked to the creator about making a touch conversion. He was familiar with Mesa Mundi and our other board game conversions from Gen Con, and was excited to see his game converted. I guess it wasn’t new this year, but this was the first time we saw the “Condom against Humanity” from the “Cards against Humanity” booth.

While it didn’t snow much at while we were in town, Boston was still recovering from the blizzards. The parking lot at PAX had a 20-30 ft mountain of snow, but more impressive was the ubiquitous hedge of snow next to the roads. It was around 6 feet tall all along every road we saw. There were cut outs for the driveways and parking lot entrances. It was difficult to spot the entrances to stores and to see traffic when pulling out onto the roads.

I always feel a little out of place in the exhibit hall at PAX. The exhibit space is not cheap and the exhibitors, including Mesa Mundi, have spent a lot of money to be there. While we are selling games, we aren’t really expecting/needing to make a living from it. So there is a dissonance between how the other exhibitors are behaving/feeling, what the convention goers are expecting, and what we are doing. This year, one of the other exhibitors openly expressed confusion about why we had created so many games – many of them freeware or not for sale – for such a small market. We are excited to just get some positive feedback from attendees and one or two sales, while other booths are trying to sell some number of units to break even, and other booths are just staffed by employees of a big company.

The game came together pretty quickly. I spent a day or so learning Photoshop and creating graphics. Another couple of days building the game logic and integrating the C++ AI. Another day adding “simultaneous” mode. And a final day to add animations and work out bugs. Here is a screenshot of the final product.

The board game supports 2-7 players, but my version allows 1-8 to play. In the screenshot above, there are five players in “simultaneous” mode. Four players are done and ready to take another tile while the player in the lower left is selecting a die to keep.

My main complaint with the physical game of Pickomino is that it can last too long as players swap tiles with each other. You also spend a lot of time watching other people roll. This is especially true in a game with a lot of players. As BoardGameGeek says, the game is really best with three or four players. “Simultaneous” mode is my attempt to fix these two problems.

Normally, each player takes a turn with the dice, rolling till they take a tile or scratch. In “Simultaneous” mode all the players roll dice at the same time. Once everyone has decided to stop and take a tile, or scratched, all the tiles are distributed at once. If multiple players earn/steal the same tile, they each get a copy of that tile. If a player steals a tile and multiple people are showing that tile, all the players showing the tile lose it and the stealing player gets a single copy. If a player scratches the tile is returned to the table if there isn’t another copy of that tile owned by a player, otherwise the tile is destroyed. The idea is to create copies as needed to make sure that everyone gets what they earned, but to destroy the extra copies whenever possible.

Simultaneous mode would be possible without the computer, but the computer automates all the tile copying and ensures that all the players are following the rules. Simultaneous mode plays much faster and there is no downtime waiting for other players to roll.

Now that I have had a chance to watch the AI, I’d say that the main difference between the AI and the humans I normally play against, is that the AI is more aggressive. The AI also does well at the end of the game when there are only a few tiles available. It can plan which dice to keep to maximize the odds that it will be able to take one of those specific numbers. That said, there is enough luck involved that I don’t feel overwhelmed by the AI.

However, the multi-touch table we just got is still a fairly new technology, and there may be some interest in our experiences with the hardware itself and our attempt to convert board games to play on it.

I have started this blog by creating a bunch of back-dated entries. These entries come from things that I have written on my web site, Facebook, and Google+. There are also some new entries that I created just for this blog.

I expect most of the entries to be about my programming projects and the multitouch table. But I will also create entries for trips that we take and other things that interest me.

The title of this blog comes from the business cards that William and I created when we left Solidyn. Lacking a “title” to fill in, William became the Lounge-About and taking a cue from “The Office,” I chose Assistant to the Lounge-About.