GAME DEVELOPER DIARY: MAKING ULTIMATE OPEN FACE POKER

Hi! This is Leandro from Trick Gaming Studios. A few months ago we started working on a new mobile game for Royal Flush Apps. They needed a poker card game, but it wasn’t the traditional poker, it was a variant of Chinese poker called Open-face Chinese poker (OFCP).

LEARNING… a lot!

I have to admit we had never heard of this kind of Poker before. Having played Texas Hold ‘em and other traditional variations before, we thought it would not be difficult to learn the rules of OFCP. At first it was a little hard to understand, but once you finally get it, the game becomes very addictive.

Once we familiarized with the mechanics (after some “simulations” playing with real cards over pizza), questions arose about the deeper aspects of the game, like: who wins in a tie or how to make an AI that plays poker, specifically for this little known variation where each player has three hands and the difficulty resides on optimizing your game as a whole and not just a five card hand.

But the biggest question was: How to differentiate it from other mobile poker games?

While there were not many online games of OFCP, we wanted to do it in a way that was easier to approach, fun to play and if you stick around long enough the game would allow you to go even deeper in your strategies. The end result has a good balance, but mostly, it’s much more fun to play than traditional poker, thanks variants such as Fantasyland that allow you to receive all 13 cards in the first round and put together the best possible hands.

Why multiplayer is so important

It’s important for the game to be fun that the Multiplayer (mp) works really well.  In fact the single player option could even not be on the game, the important thing was the multiplayer features. And why this was so important? It is not only more fun to play poker with some real opponents, but also the game monetizes by selling hands to play multiplayer while practicing against the AI is completely free.

Developing Ultimate Open Face Poker

We used Unity 4 to develop Ultimate Open Face Poker and to launch it on Android and iOS first, then later for Facebook, Windows Store and Windows Phone.

There were two important features that had to rely on Photon Turnbased’s webhooks:

User should be able to leave a game at any point and come back to it even if the other player is offline

Users should be able to invite FB friends and bypass the Photon matchmaking system completely

For feature number 1 Photon Turn-based solution and sample webhook project worked out of the box (we had to adapt the structures to suit our data model only). Then within the logic of the game, we make those games private so only the original users can access them and continue where they left off.

The basic flow is something like this: create a game (either by invite or with some random stranger), play a few rounds and leave. At this point Photon calls the webhook you configured for this event and then in your backend you save the state in an Azure table. The key to this entry (in our case) is the unique IDs of each player (which we get the first time they login to the app, allowing them to continue the game from any other device they own).

When the player requests a lists of his games to show on the dashboard, then we filter the list of saved games by those that have his ID on the key. Since all those games are set to private, no one else can access them at this point, except the original players. Basically, once the matchmaking is done, the game is closed to the public and it becomes a private affair between these two players.

The second feature we wanted to support is that users had to be able to send a direct invite to their FB friends. In this scenario, the flow differs from the way Photon traditionally handles matchmaking. Instead of opening a room and waiting for players to join, we create the room and manually add a second player using the friend’s ID. In the server, when Photon calls the create game Webhook, we already know there are two players, so the second player is added to an “Invite List”. Next time he logs in and requests his games, we not only return the ones he was already playing, but also the ones he’s been invited to play while he wasn’t looking.

Something neat about this feature is that Player 1 can invite his friend, make the first move and continue something else. The second player can receive the invite and make his move at any other time, and so on. So with this strategy and Photon Webhooks, players can have a game going for months, without the need to be online at the same time at any point (and of course, if both are connected to the same room at the same time, they can see each other’s moves as soon as they take place).

Some tips for developers

We all know that is important to reduce the amount of information being sent over the network. Some simple optimizations we did for our game and can be adapted to other scenarios are:

While the deck has 50 cards, only 34 are used during a game. When a new game is started, only those 34 cards are actually serialized.

At first during the testing, we wanted to be able to easily read what was being sent to the server. For that reason we coded the cards using long names such “THREE_DIAMONDS” and also used very descriptive names for the fields, like “Player1Name”. This was a decision we took prior to commencing the actual coding, and made sure that every string that was later sent through the network resided on a single configuration file that could then be changed very easily. From the code we would just reference the string constants in a fashion similar to Constants.PlayerNameKey. Then when moving to Production we just changed the constant strings in the configuration file (for example: “P1” to replace “Player1Name”) and the rest of the code remained the same. It is harder to open the Azure table and make sense of the data at a first glance, but there’s less (a lot less!) information transmitted.

TIME TO PLAY