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.

Click through for more photos:

Sandy had made birthday cupcakes which were quite good. She also had savory appetizers, fruit and marshmallow salad.

The guests were asked to guess how many candies were in the jar. Here, Jenna is working on her guess. Danny ended up winning the jar which had 1760 pieces of candy.

There was quite a bit of drama getting everyone into the garage without Brenda noticing. To get Brenda to come over to Sandy’s garage for the surprise, they told her that Jenna and Danny had an announcement. This story was Jenna’s idea and she and Danny made sure to warn their parents that there really wasn’t any news on the baby front! In this picture, Sandy and Tracy are trying to coordinate Brenda’s arrival.

All the deception seems to have worked. Here, Brenda is arriving at the party and she does seem to be surprised!

Along with the candy jar, Sandy had planned a bubble-gum bubble blowing contest (I won) and a round of musical chairs. Musical chairs was a big hit and Ziya ended up winning:

After the party, we setup our touch table in Sandy’s living room and played games the rest of the day. Everyone seemed to enjoy themselves and we got to test out Bio Infiltrators with all four positions controlled with phones. Here we are playing “Temple Raiding”

Download the rest of the pictures that I took of the party (92 MB).

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.

So one of our goals is to update the existing games so that you can switch back and forth between a human and computer player during the game instead of just at startup. Most of the games will be fairly easy to adapt to this system. We generally write the computer players in C++ while the rest of the game logic is in torquescript. This separation has meant that we generally pass everything the AI needs to make a decision each time the AI has to play.

Yacht didn’t have an AI at all, so to adapt it to the new system required me to write a computer player for it.

Yacht is a moderately complex game for a computer to play. The decision of which dice to keep depends not just on what you have rolled, but also on which categories are left to score. To play well, the AI needs to take into account the relative value and difficulty of each category and the chances of getting the bonus.

Fortunately, Yacht has been solved(pdf). Unfortunately, it is still too computationally expensive to use this method while playing a game. I implemented a simpler system. It is fairly simple to find the “best” way to play each round if you ignore future rounds. This is similar to solving for one “widget” as described in the paper linked above. Then, instead of trying to solve for all possible futures, I simply use a set of rules to describe the value of each category. I can also tweak the constants used when applying these rules to make different two computer players play slightly differently.

The computer player plays a pretty good game and is fast enough to not be noticeable. If I wanted the AI to be more sophisticated, I would add more logic for determining the probability of getting the bonus based on the current scores. Then I would try to improve the value that I assign to each category by having AIs play against each other with different settings to see what works best.

Here is what the new GUI looks like:

You can see all the photos here and I have a separate post for our PAX experience.

We started by touring the MIT campus and spent most of our time there in the MIT Museum. The exhibits include AI and robotics, slide rules, holography and the “Gestural Engineering” sculptures of Arthur Ganson. They had a hardware implementation of a LISP interpreter, a bunch of the robots that we have seen in videos, and some pretty impressive holograms. But the best part was the sculptures. These are Rube Goldberg style machines that are both mechanically interesting and artistic. They were all fun to watch and we spent a lot of time tracing how each one worked. My favorite was probably “Beholding the Big Bang” which is a motor attached to a series of 2x reduction gears. The first gear is spinning rapidly and the last gear is embedded in concrete. It would take 13 billion years for the final gear to make one revolution. Video.

MIT Museum – Arthur Ganson – Behold the Big Bang

Another great sculpture was the “Wishbone”. In this sculpture, a wishbone appears to walk down a track dragging a large spinning machine behind it. When it gets to the end of the track it stops and waits while 1/3 of the track rotates 180 degrees so that the wishbone can walk back the other direction. Video.

MIT Museum – Arthur Ganson – Machine with Chicken Wishbone

Our other favorites were:

MIT Museum – Arthur Ganson – Margot’s Cat

Video.

MIT Museum – Arthur Ganson – Machine with ball chain

Video.

MIT Museum – Arthur Ganson – Machine with oil

Video.

We had planned to do the Freedom Walk, but it was really cold, so we went to the Museum of Science instead. We have been to quite a few museums of this style, so we had seen some of the exhibits before. This museum had a unique mathematics exhibit that was sponsored by Mathematica. It had a good probability display and a demonstration of minimal surfaces with soap films.

The signature attraction at the museum is the “theater of electricity” where they have a three story Van de Graff generator, a Faraday cage made by Faraday and a Tesla coil that can be tuned to play music.

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.

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.

After playing the game a few times, I began to wonder if this game could be “solved” by a computer. Would it be possible to consider all the possible sets to save and all the possible rolls that would result for all the rounds in one player’s turn to determine their best choice.

I started by writing a fairly standard recursive function that looks like this:

choseBestFace()
{
  for each distinct number in the roll
  {
    if we can take a tile with this set
      score = value of the tile
    else
      score = -value of our last tile
    score = max ( score, valueOfRoll(remaining dice after taking this face) )
  }
  return the face with the highest score
}

valueOfRoll(remainingDice)
{
  if ( no remaining dice )
    return score of choseBestFace()
  else
  {
    value = 0;
    for each number of the first remaining die (1-6)
      value = value + valueOfRoll(firstDie, rest of remaining dice)/6
  }
  return value
}

Imagine that we only roll 2 dice and they come up different. Now there are only two options and each option needs to calculate all the possible rolls of 6 dice. There will be a total of 14 calls to these functions. If we have 3 dice that come up different, there would be three options and each would need to try 36 combinations. But lots of those combinations will have a third round of rolling with six more options. It ends up being 1179 function calls. Starting with four dice is 487,636 calls. While this seems like a huge amount, computers are really fast and the result comes back immediately  Five dice is 958,460,025. On my machine, this takes several minutes. The problem space is growing exponentially and there is no way this method will be able to reach six dice, let alone eight.

While debugging and stepping through this code, I was struck by how many times the same problem was being solved. There are lots of ways to get the same set of dice. So, instead of re-calculating the solution each time, the program calculates the result once and then saves it. The input to the valueOfRoll function is the combination of: the number of dice left to roll, the number of each die face that we have saved and the number of each die face in this roll. There ends up being 8*6^8*6^8 = 816 million different ways to call this function (for eight dice). Most of those combinations can’t really happen. After putting in this change, I was shocked by how well it worked. For the same five die problem that ended up calling the functions almost 1 billion times, I ended up with only 4270 unique combinations. It seemed unbelievable till I stepped through the code and realized that one  early cache hit can save thousands of later recursive calls.

With this improvement in, I kept increasing the number of dice to see if I could do all eight. Six dice was 14,574 combinations. Seven dice is 38717 and eight is 93454. On my machine it takes about a fifth of a second to determine the best play.

There are some subtleties of the game that this AI is not considering. It doesn’t consider stealing a tile from another player to be any better or worse than taking a new one from the table. It also doesn’t try to make any calculation about whether a play would cause the game to end sooner or later. Both of these could be added by changing the scoring function, but would involve my judgement about what is best and would not change the overall speed much.

We are planning to show off the new mini-games, which are on sale now at Mesa Mundi’s site, along with Hansa Teutonica and a new game in development where players can control the action with a web browser on their phone.

D20Pro will also be on hand at Mesa Mundi’s booth to show off their role playing system. It should be an exciting weekend where we can see how people react to the touch tables and our games. Mesa Mundi has a short write up about PAX here.

One of the first board games that we played over and over was Settlers of Catan. We got a lot of enjoyment out of that game, but the more we played it, the more frustrated we got with how random the game could be. We almost always played with the random board, but the initial city spots could vary so much in quality that picking first could be enough to win the game. But even more frustrating than the randomness of the board was the randomness of the dice. It seemed like some games we would roll three sixes for every eight. In others we would have long streaks of fours or tens that could win the game for the player on those tiles.

To solve this problem with a game that we otherwise still enjoyed, we created a fair board builder and fair die roller. The board builder would try to make a board that was balanced for all the players and the fair die roller would try to even out the distribution of rolls within a single game. The first version of this program was in Java and Java Web Start. As Java and especially Java Web Start fell out of favor and I learned C#, I re-wrote the application in C#. The C# app was great, but could be a pain to install at friends houses before a game. At my last job I learned Flash, so I re-wrote the fair die roller and board builder in Flash. Now that Flash is falling out of favor, I have re-written the fair die roller again in javascript.

Like the other re-writes before it, this version has been a learning experience. I have programmed in javascript before, but for this application I decided to learn and use jQuery. jQuery has some great features and there is a lot to like, but I would have to say that this version of the fair die roller has taken me longer to build than any of the others except the original in Java. I am not an expert at HTML or CSS and I spent a lot of time fighting with the layout of the page.

You can check out my latest fair die roller here. You can also compare it to the previous versions in flash, c#, and java.

I’d like to eventually add the fair board builder. But for that I will probably try to learn the HTML5 canvas. We also don’t play Settlers as much as we used to, so that isn’t a very high priority right now.