We were on a 60″ table using the new SensaTouch IR sensor and modular wooden table frame. It did mean that we were standing all weekend, but it was actually easier than sitting and leaving over to touch the coffee-table sized screen we were on last year.

From the time the hall opened at 10, till it closed at 6, we were always busy playing games. We mostly played Pair Soup because it is super easy and cooperative. People could walk up and join a game any time. By the end of the weekend we had played 160 games of Pair Soup. That adds up to about 13 hours! We were really glad to have the new tile sets.

There was an overhead walkway above us, and many people stopped at our booth saying that they had seen the game from above and had to try it out. We also played quite a bit of Fas’Jack, Dungeon Raiders, Got It and Yacht with people who stuck around for a second or third game.

We played several games of Fire Platoon and people seemed to enjoy it. People didn’t have trouble learning the game and controls and the tablets worked well. The WiFi was much better than last year, but it was still hard for some people to connect to the game.

The other quadrants of the booth were occupied by d20 Pro; a system for running a role playing game, another game table running a fast paced competitive game called WhackIt, and a demo of the modular table system.

There are lots more pictures of PAX and a few of Boston in my gallery.

I’ve also been catching up on blogging about my programming projects. I’ve retroactively posted some entries to the date when I did the work. Since that makes it really hard to spot new content, here are links if you are interested:

• Open source Torque 2D
• Staring Fire Platoon
• Web Controls for Fire Platoon
• OGG support for Torque 2D

What worked

The Move/Ability/Action Point system worked very well. All player actions are a Move, and each Move uses some number of Action Points that build up over time. How many Action Points a Move takes, and whether a player can perform a given Move is determined by the Ability system. Each player has a set of Abilities. We ended up making the Abilities fairly fine grained. So there is not just a “walk” ability. It is actually broken down to walk, walk with victim, walk with item, walk into fire, etc. Each player can start with a different set of abilities to make different characters, and players can gain or lose abilities during the game. This can handle equipment or player upgrades.

The real time Timeline also worked well. Scheduling Moves for a future time was a convenient way to have things happen in the game. It allowed for scripting of events and for Moves to schedule other Moves. This allowed the Moves to be more atomic which prevented code duplication. It also allowed a fairly easy way to animate some of the Moves.

Using websockets and a dumb client for the web page controls: The websocket connection is fast and reliable. We aren’t seeing much lag on our local network, even with 6 players connected at once. Having a dumb web client (all player state and move options are sent to the client) makes it easy to handle phone/connection issues. We have rare instances of someone being disconnected from the game, but all they have to do is re-load the page.

What didn’t work

The biggest problem was our method for connecting the C++ source code to the script. We have traditionally kept any GUI code in the script and game logic in the C++. This worked fairly well, but we decided that the interface between script and code would be function calls back and forth. This was more work than if we had made the C++ model classes derive from ScriptObject. This would have allowed the script to use some of the C++ model directly.

Another problem was keeping the human players separate from the fire fighters they are controlling in the code. This made the disconnect/reconnect code more complicated than necessary.

Finally, we are having a problem with the multiple inputs to the calculation of the action point cost of certain actions. We wanted the model to be fairly flexible, so to determine the cost to walk between two spaces requires input from both the fireman (what abilities do they have, are they carrying stuff) and the board (is there fire on the space, are you going up stairs). Making the abilities more fine-grained helped with this problem, but there is still quite a bit of ugly code that needs revisited before the next game using this system.

We are going to use web sockets to send messages between the game and the player’s web clients. Web sockets are now supported by all the web browsers, so anyone with a smartphone or tablet should be able to connect to the game and play without downloading an app.

We have been using mongoose 3.7 as our built-in web server. We have had a couple problems with it and we decided to upgrade to the latest version which is 5.2. There have been significant changes to how the web server operates. In 3.7 it used a thread pool to handle the connections, which limited the number of simultaneous connections (not really a problem for us), and forced us to pass data received from a client to the main thread for processing. Mongoose 5.2 uses asynchronous IO and has significantly better web socket handling. The new web socket interface allows us to detect when a client disconnects and to force a disconnect. We didn’t expect to see much performance difference, but we were pleasantly surprised that the new version connects quite a bit faster.

Integrating mongoose into Torque was significantly easier than the first time I did it, but it was significantly different because it needed to poll every tick and it consolidated many event handlers into one. If anyone is interested, here is the source code:

WebServer for Torque 2D

To implement our real-time board game, we are going to use the “Move” system that we used in Hansa Teutonica. All player actions will be a Move that is applied to the game board. In this game, the board will change on its own as time passes. These time based changes will also be implemented as Moves. The game will maintain a timeline of when Moves should be executed. This will allow a Move or event to schedule another Move at some later time. Player moves can also be scheduled the same way so that a player could queue up moves.

To keep the game from being an action game where the reaction time of the players is the important factor, we are going to use an “Action Point” system. The players will build up action points over time and all the actions that a player can perform will use those Action Points. The player will be able to build up a limited “savings account” of action points by waiting. This is a common mechanic in board games where each player gets limited action points to spend before it is the next player’s turn. In our game, all the players will be earning and spending action points at the same time, but the fire will spread as the players earn action points.