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.

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.

This code is surprisingly messy. The first byte is always 0x81. The second byte is a length, but the most significant bit is an indicator of whether there is a mask. If that second byte is less than 126 it is just the length of the data. If it is equal to 126 then the next two bytes are the length if it is equal to 127, then the next four bytes are the length. What is even stranger is that if the mask is set, then all the data sent is XORed with the  a prior byte. Here is the code I ended up with to read a message:



  // Read the message from the client
  // For now we will assume that this is a string of text
  // Read in the header and size
  unsigned char header[10];
  int totalRead = 0;
  while ( totalRead < 2 )
  {
    int bytesRead = mg_read(conn, header+totalRead, 2-totalRead);
    if ( bytesRead <=0 )
      return nullptr;
    totalRead += bytesRead;
  }
  // Check the data received
  if ( header[0] != 0x81 )
    return nullptr;

  long long messageLength = header[1] & 127;
  int maskLength = (header[1] & 128) ? 4 : 0;
  if ( messageLength == 126 ) // Large message
  {
    totalRead = 0;
    while ( totalRead < 2 )
    {
      int bytesRead = mg_read(conn, header+totalRead, 2-totalRead);
      if ( bytesRead <=0 )
        return nullptr;
      totalRead += bytesRead;
    }
    messageLength = (((int) header[0]) << 8) + header[1];
  }
  else if ( messageLength > 126 ) // Very large message
  {
    totalRead = 0;
    while ( totalRead < 8 )
    {
      int bytesRead = mg_read(conn, header+totalRead, 8-totalRead);
      if ( bytesRead <=0 )
        return nullptr;
      totalRead += bytesRead;
    }
    messageLength =  (((long long) htonl(*(int*)&header[0])) << 32) | htonl(*(int*)&header[4]);
  }

  // Now read the data
  unsigned char* buf = new unsigned char[messageLength+maskLength];
  totalRead = 0;
  while ( totalRead < messageLength+maskLength )
  {
    int bytesRead = mg_read(conn, buf+totalRead, messageLength+maskLength-totalRead);
    if ( bytesRead <=0 )
    {
      delete[] buf;
      return nullptr;
    }
    totalRead += bytesRead;
  }
  char* message = new char[messageLength+1];
  for ( int i=0; i<messageLength; ++i )
  {
    int xor = (maskLength==0 ? 0 : buf[i%4]);
    message[i] = buf[i+maskLength] ^ xor;
  }
  message[messageLength] = '\0';
  delete[] buf;
  return message;

With Mongoose integrated and web sockets working, our Torque games can communicate in real-time with web based clients. And since Awesomium is also integrated into our engine, the same web page can be viewed by the players sitting at the touch table. We needed to make a couple improvements to Awesomium so that people could actually interact with the web page:

• To get TUIO and mouse events to the web page, Awesomium requires that touch/mouse events be injected into its system. The mouse events were straight-forward, but the touch event requires a list of new, changed and unchanged touch points every time a touch is added, removed or moved.
• To allow a user to enter data into a web page, we need to provide a virtual keyboard and inject keyboard events into Awesomium

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.

There were a couple of tricky parts to the integration:

• Awesomium has a couple layers: the WebCore, where the preferences are set, and the WebView which renders each webpage. The WebCore is initialized once and should be updated every few milliseconds. Each WebView is created from the WebCore and marks itself ‘dirty’ when the page needs re-drawn. Torque has an iTickable interface which called your processTick function every 32 ms, so we were able to use that to both update the WebCore and check the WebViews.
• We wanted to be able to render plain HTML. Awesomium is setup to render http:// and file:// addresses. To render plain HTML we had to load a special url asset:// which tells Awesomium to call a callback to get any data. We also had to add code to fix the URLs within our custom HTML to be files within our game directory.
• To render the Awesomium WebView onto a Torque sprite, we create a GLTexture that is re-drawn whenever the page updates and is drawn onto the screen every frame. This allows us to position, rotate, and animate the web page on the screen. As we have seen before, when the game switches between fullscreen and windowed mode, the GLTexture has to be re-created. We had this same problem with our custom font library  so we created a common iResurrectable interface that custom textures could implement to be re-built when the screen mode changes.
• We wanted to be able to use the TorqueGameBuilder to add the Awesomium web pages to our games, so we needed to create several hooks to tell the game builder (imagine it like an IDE for putting together the layout of a game) about the members of the web sprite.

Here is the final result in the game. As the player picks different options, the text updates on the fly. The instructions themselves can be moved or rotated with the player’s fingers.

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.

We used the same architecture that we used for Hansa Teutonica. The idea is to have a C++ model that handles the game logic, and all model changes are done with moves. Moves can save/load and do/undo themselves. The GUI is all torque script and is mostly just a dumb canvas that the model controls by calling functions to move around GUI elements and highlight areas for user interaction. User input is returned to the model via a callback written as a C++11 anonymous function.

The architecture continued to serve us well for this game and we made a couple of improvements:

First of all, we made more things into a move. In Hansa, the game setup was separate and it required extra code and work to handle loading a game and getting it setup the same way. In the new game, all game setup is a move that sets up both the model and the GUI when it is executed.

Second, all the model enums were exported to the script so that we didn’t have to define them in two places.

Third, the GUI animation was designed to be instantaneously executable. So, when loading a game, all the moves can happen at once without messing up the GUI or animations.

Finally, this game made full use of torque’s ability to re-load scripts while the program was running. I saved a huge amount of time during development of the GUI code because I could make a code change, hit F5 and have that code change re-loaded and live. Between that and all the moves being undo-able, it was extremely easy to find a bug, fix the bug, rewind the move and test the fix. All without having to re-build or even re-start the game.

There are still a LOT of improvements that could be made to the interface. It could be a lot prettier and more sounds and voice prompts would make it more enjoyable and intuitive. It could also use a computer player. But since the actions of the players strongly effects each other, it is important for any AI to play well.

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.