Category: Games

Simultaneous Pickomino

After completing the AI for Pickomino I wanted to play against it and watch it in action. So I decided to create a version of the game for our touch table. I wont be trying to sell this game since I don’t have the rights from the creator of the board game. So it will just be for our own use.

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.

Continue reading “Simultaneous Pickomino”

Pickomino AI

Pickomino is a dice game where each player takes turn rolling eight, six sided, dice. The player tries to build up a high enough total of dice to capture one of the available tiles from the board or from another player. To build up a die total, the player picks a set of dice all showing the same number to save. The player then re-rolls the remaining dice. Each number can only be saved once. If you can’t pick a new number after a roll, or don’t build up enough points to claim a tile, you scratch and have to return a tile. Full rules are here(PDF).

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.

Continue reading “Pickomino AI”

Fair Dice Roller

I have finished an HTML/javascript version of the fair dice roller. The fair die roller makes a die or dice less random by tweaking the probability of each roll so that the rolls come up in the correct ratios sooner. Check it out here. Or look here for a lot more detail about what this app does.

Continue reading “Fair Dice Roller”

New word game for the touch table

I have almost finished a new game for the touch table. The game is based on the board game “Keesdrow” and is similar enough that I am not going to be selling this game. “Keesdrow” is a word finding game somewhat similar to Boggle, but the board is much bigger and each letter can only be used three times. The first time a letter is used it scores its base value, the second time it scores double and the third time it scores triple. This makes it very important to find words that have repeated letters and use letters that have already been used once or twice.

The most interesting part of this project was the AI. I expected it to play significantly better than it does.

Continue reading “New word game for the touch table”

Writer’s Block

I have been working on a new game for the multitouch table called “Writer’s Block”. In the game, players will compete to find words in a 4×4 or 5×5 grid of letters. 

The players have three minutes to find all the words they can. Words are scored based on length and if multiple players find the same word it scores zero points.

There have a few interesting problems to solve when creating this game:

Continue reading “Writer’s Block”

Hansa Teutonica – Post Mortum

Hansa Teutonica is nearing completion and I wanted to capture some of the lessons that we learned during development. Overall, the game has turned out to be a much larger project that we originally anticipated. We are very happy with the design that we ended up with and we think that future games can use the same design. The game is currently playable except for placing an office to the side of an exiting city. There are also some user interface improvements to make and quite a bit of testing yet to do. But the majority of the code is done.

Continue reading “Hansa Teutonica – Post Mortum”

Wits and Wagers playable

I have completed the base game of Wits and Wagers. This conversion went fairly smoothly, at least compared to Yacht. I am getting used to the torque scripting language, though there is still a lot to learn.

The login screen is similar to the screen for the Concentration Sweep game that William created. I have added the player colors to the login spots so that you can tell what color you will be during the game. We are planning to have a common login system that will also you to pick a color and enter your name for a high score table.

The game is played in seven rounds. In each round you read a question from the boxed game. Once the question has been read, each player’s region displays a panel to enter their answer:

The player uses the touchscreen to type in their guess and then clicks the ready button. The ready button is a toggle, so if you change your mind before the timer runs out, or everyone else is done, you can flip the toggle and change your guess. In order to make sorting the guesses, I decided to stick with purely numeric guesses. This means that everyone has to use the same units. Most of the time there is no ambiguity about what units to use, but if there are, everyone has to use the same units.

Once all the guesses have been entered, the central area shows the guesses on the payout regions and the player area changes to a betting area. Each player gets a small copy of the central area where they can place their bets. It would have been possible to have everyone drag their bet out to the central area, but with a lot of players there could be finger collisions. We also would like to have the option to make all the bets private.

On this panel, the player selects one of the three chip sizes and then clicks on the guess/bet regions to place a bet. A bet can be moved from one column to another by dragging and also dragged off the area to clear the bet.

While the players are betting, the central area is showing the player’s guesses and the payouts and is being updated with their bets as they are made:

Continue reading “Wits and Wagers playable”

Wits and Wagers

After taking a few days to start up this blog, I am ready to go back to game development. The next game that I am going to convert for the touch table is Wits and Wagers.

Wits and Wagers is a casual trivia and betting game. A game consists of seven questions. After the question is read, all players secretly answer. All the questions have a numerical answer and the answers are sorted and placed on the betting table. All players then bet chips on the one or two ranges that they think are correct. The answer is read and the correct range is paid out, all other chips return to the bank except for two permanent chips per player.

It is a fun game where having knowledge of the trivia is not nearly as important as betting well. There are several things that make this a good option for conversion.

  • It is a popular game that is still getting a lot of plays.
  • Everyone acts at the same time when writing their answer and placing their bets.
  • Chip management when doing payouts is a bit of a pain.
  • We would like to be able to have hidden bets and an enforced time limit as options.

The one big problem with this conversion is that we don’t want to type in all the questions. Instead, the original questions from the game will be used and one player will read the question and push a “start round” button on the game.

William and I have already started work on the board layout. As usual, the space is tight. It is a seven player game and each player needs their own numeric keypad and betting table. Plus we need a lot of space in the middle to display the potentially large numeric answers and up to seven different player’s bets.

I am going to write this game with the Torque 2D engine. I am guessing that there wont be any additional C++ code required and that it can all be done in script.

Yacht Completed

William and I have completed the Yacht game.

It ended up being harder than I expected it to be (which seems to always be the case). There are a lot of different ways that the game can move forward – the timer, the user scoring, or the user saying that they are ready for the next roll. And keeping track of the state of the game and the players we messier than I expected.

I also had trouble organizing and designing my script code. The lack of an enforced structure made it difficult to decide what file/class/namespace would have each bit of logic. Between that and my lack of experience with the script language, I spent a lot of time looking for code and moving things around.

It was also somewhat difficult to get used to the more event and schedule driven game flow. For things to animate nicely, we needed to introduce delays where there normally wouldn’t be. For example, the game rolls the dice, the dice animate, then then game tells the players what the roll was and the player class unlocks the player GUI and displays the ready button. In application software, the dice wouldn’t be animating, and that would all be one flow of function calls. For the game, there had to be a scheduled delay between starting the dice animation and telling the players what the result of the roll was.

Space was also a more limiting factor than we thought it would be. On the 46″ 1920×1080 screen, the smallest button that the user can feel confident pushing on the first try is 32×32. To get things to fit, the scoring regions ended up being only 24 high.

Here is a screen shot of the completed game:

Hansa Teutonica – Update 1

There has been a lot of progress made on the Hansa Teutonica conversion. The model is done, though the testing has been pretty light. Many of the graphics have been created and the GUI code for interacting with the player is started.

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;
}