QR Codes

We integrated a web server with web sockets and a web browser into Torque. The goal is to allow hidden information to be displayed on a phone and to create games where all the player play on a web page whether that is on a phone, computer or at the touch table. For the phones, it would be nice if they could quickly log into the game without the overhead of typing in a web address that looks like http://192.168.1.2/<game name>/<table position>

Most smartphones have a QR code reader that can interpret a URL and open the web browser with that address. So it would be nice to display a QR code at each table position. If the player doesn’t have a smartphone, they could sit at the table and use blinds. If they did, they could scan the QR code and be taken to the locally served web page that displayed their information.

I found a C++ library for generating QR Codes called libqrencode. With some minor tweaks I got this compiling in visual studio and linked into Torque. Integrating with torque was a bit more effort. The library outputs a character array of actual text ones and zeros. To display this on the screen, I build an OpenGL texture and draw it at the position and rotation of the sprite.

Here is what our test application looks like:

Here you can see a web page being displayed by the built in Awesomium browser. The page is being served up by the same program’s built in web server. The virtual keyboard can be used to fill in the text entry field on the web page. When you press the connect button, the page makes a web socket connection to the address entered. The web socket server is also running within the application and just sends the text “Greetings!” when it gets a connection. The QR code displayed on the right can be scanned by a phone and contains the URL to connect to the local web server. When the phone browses to that page, they see the same page as displayed within the application.

Now that all the technologies are integrated. We are ready to put it to use. We have two plans for this system. One is to replace the hidden information areas in the games “Temple Raiding” and “Hearts”. The other is to create a new game called Clever Blitz where the players compete in a series of extremely short mini-games. Each mini-game would be displayed in the web browser.

Web sockets and Mongoose

A couple of weeks ago, I experimented with using bluetooth to communicate hidden information from a game to a phone held by the players. While the prototype worked, there were issues with client side logic and lack of support for iOS.

Another way to achive the goal of displaying hidden information on the phone would be to create a web page that the phone could access. In the past, we have done this by having the game state in a MySQL database and php scripts to access the data. The game server and clients would poll the data watching for updates and sending their moves. This system was cumbersome, laggy and prone to error.

However, the web page is a nice way to provide the data to the clients. It is easy to layout a good looking interface, you can use javascript to allow the player to interact with the game and all phones have a web browser. The problem lies in the communication back to the C++ game.

One solution to this problem would be to use web sockets to send data back and forth between the clients and the game. Ideally, the C++ game would serve out the web pages that the clients display too so that people buying the game wouldn’t have to know how to setup a web server.

Mongoose is a simple web server with web socket support that can be compiled into a C++ application. With a couple of minor tweaks I got the mongoose code integrated into Torque.

Adding web sockets was a bit more problematic. The support for raw web socket connections comes with Mongoose, but I needed to write the code to send and receive the messages in the format expected by the chrome WebSocket class.

Continue reading “Web sockets and Mongoose”

Integrating Awesomium into Torque

Battle Home, one of the games that MCG is developing for Mesa Mundi, has a lot of options which dramatically change the rules to the game. For previous games, we have created instructions by making one or more graphics in Powerpoint or Photoshop and displaying that  graphic on the screen. For this game, each combination of options was going to require another set of images. It would be much easier if we could create the instructions dynamically based on the options selected.

Enter Awesomium, a C++ library that lets you put the Chrome/webkit web renderer into your application. While it was not trivial to integrate Awesomium into torque it does allow us to display any HTML or public webpage within our games.

Continue reading “Integrating Awesomium into Torque”

Electric game for touch-table

We have mostly finished a new board game for the touch table. The game is inspired by Power Grid, but is intended only for use on our own table and will not be for sale.

I am pretty happy with the result. The game plays very fast since you don’t have to worry about setting up, distributing paper money and manipulating the cards. In the original board game, we often needed ‘thinking money’ that we could arrange in piles representing planned expenses. To meet this need in the electronic version, we included a calculator in each player’s area. Hopefully this will be adequate.

Continue reading “Electric game for touch-table”

Hansa Teutonica

Now that we are getting a multitouch table, it is time to write some games for it.

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.