Cubeia Poker Cloud Scalability


Would you want some cloud with your game server?

Cubeia Firebase was initially build for real money gambling and for deployment on dedicated hardware. It makes sense to control your hardware when you’re dealing with monetary systems but as gambling focus has shifted the last couple of years towards social gaming cloud based deployments makes much more sense. In this article we’ll present Cubeia Poker running on Amazon AWS and our initial load tests and evaluation.

By |Wednesday, December 19, 2012|cubeia, firebase|1 Comment

Cubeia Firebase 1.9.0

Today we release Firebase 1.9.0-CE (and of course also EE for our enterprise customers). It’s been 6 months since 1.8.0 and we’ve been using 1.9 internally for approximately 2 months now, including within a very active development project. This release can be described in two acronyms: JPA and JNDI. By adding JNDI within the server and removing JPA we’ve made it significantly easier to actually use JPA. The king is dead! Long live the king!

By |Thursday, September 27, 2012|firebase|Comments Off on Cubeia Firebase 1.9.0

Firebase from Scratch, pt VIII: Services

In a series of posts we’ll do “Firebase From Scratch”, an introduction to Firebase and its concepts and ideas. Hopefully, reading this series will give you a firm grasp of what Firebase is and what it can do.

Having talked a bit about the server side game the last three episodes, let’s have a look at services. These are extensions to Firebase you can write yourself to provide cross-game functionality and common behavior.

By |Wednesday, April 18, 2012|firebase|Comments Off on Firebase from Scratch, pt VIII: Services

Games & Aynchronous Integrations

When a game network attaches external integrations, such as remote wallets, asynchronous communications becomes important. This can be any kind of integration, but in this blog post we’ll assume it’s a wallet we’re talking with. So, what’s our problem?

  • If the network has several operators no operator must block players from another operator. If the wallet operation is synchronous, one call to an integration may lock the entire table. It is more acceptable if there is only one operator, but when there’s several, we must make sure no-one is penalized by another players operator.
  • Similarly, we may have other integrations that takes time even for a single operator and don’t want to block game play during it’s operation. This might include interactions with national gambling authorities, etc.

So here’ a wallet example: A player needs to buy in after having lost all money at the table. The game server asks the player if he wants to buy in and if the player accepts the buy in he’s placed in a “buy-in in progress” state while the game server sorts out the actual money transfer. Note that the game play may well start at the table with the player in a sit-out state if the buy-in takes a long time.

  1. Send buy-in information to player
  2. On buy-in request from player, set player state to “buy-in in progress”
  3. Hand-off buy-in operation from the game to a wallet service
  4. When buy in is complete, wallet service notifies game
  5. Game sets player as “in game” and notifies the same

Easy, huh? Now let’s do some coding. A word of warning though, I’ll write it down off the cuff so you’d better off treating the following as pseudo code, but it should give you an idea on how it’s done.

By |Tuesday, April 17, 2012|firebase|Comments Off on Games & Aynchronous Integrations

Totally TicTacToe

TicTacToe is one of the classic examples when it comes to multiplayer games. The rules and interactions are simple enough to make it a good example. We have now amassed a few examples. A few…

In fact, we have a server game, an HTML5 client, bots for load and QA testing, and fully fledged tournament support.

Pretty cool, eh?

By |Monday, April 16, 2012|firebase|Comments Off on Totally TicTacToe

Functional Bots in 5 Minutes

Sound like a dream? At Cubeia we often need to write bots, either to test a new aspect of Firebase, or to help customers quality test their products. So, naturally we’ve extracted a little framework for quickly writing bot AI and running batches of bots against a Firebase server.

We’ve never really “officially” released the Firebase Bots. Until now, that is. So here’s how to get functional bots, connecting to a Firebase server, sitting down at tables, ready to implement your own game logic, in 5 minutes.

(OK, so if you don’t have Java and Maven installed, it may take more than 5 minutes…)

First create a new Bot project:

mvn archetype:generate 

When the archetype asks for a “gameId” choose the same ID as the game you want the bots to run against. When it’s finished, you have a new bot project which you can compile, but also, and here comes the deep magic, run against a Firebase server. So try this:

mvn clean package firebase-bots:run

The above package your bots and starts a bot server at HTTP port 8080. So open your browser and check it out!

Yes, the framework handles connections and lobby for you. Yes, they can connect using both binary protocols and Web Sockets or Comet. Yes, they’ll try to seat themselves auto-magically. Yes, it is a pretty neat little tool!

For more information, hit our wiki: Firebase Bots

By |Wednesday, March 14, 2012|firebase|2 Comments

Firebase from Scratch, pt VII: Actions On The Table

In a series of posts we’ll do “Firebase From Scratch”, an introduction to Firebase and its concepts and ideas. Hopefully, reading this series will give you a firm grasp of what Firebase is and what it can do.

Now let’s talk a bit more about handling actions in a server game. Why is the actions binary data as opposed to objects? Who do you do scheduling? Can you send actions internally between games, tournaments, services etc? Read on for some answers.

The Table Instance
When an action comes in to either of the “handle data action” or “handle object action”, you are given two objects, the action itself and a table. It is important to re-iterate at this point that your server Game is a collection of objects that collaborate: the game instance and it’s processors, the activator and all currently existing tables.

You should never keep references to table instances in your game or activator.

The above rule is because Firebase is build to transparently scale across multiple servers: Firebase needs to be able to “move tables” between different servers and will do so to make sure there’s no data loss even if servers are crashing.

By |Tuesday, March 13, 2012|firebase|Comments Off on Firebase from Scratch, pt VII: Actions On The Table

It’s Alive!

Finally, after 6 months of active development, three release candidates and untold liters of developer blood and sweat: Firebase 1.8.0-CE is now released! This release brings HTML5 support in the form of WebSockets and Comet right into the Firebase server.

The kicker? It’s all under the hood: If you’ve written existing games in Firebase they will still work. The addition of HTML5 support is purely in the transport layer and does not concern your server code at all. The same server game can now handle not only Flash, Java and C++ clients, but also any JavaScript capable device.

Go you forth and try it out: Cubeia Firebase 1.8.0-CE Downloads

By |Thursday, March 8, 2012|firebase|Comments Off on It’s Alive!

Firebase from Scratch, pt VI: Activating Games

In a series of posts we’ll do “Firebase From Scratch”, an introduction to Firebase and its concepts and ideas. Hopefully, reading this series will give you a firm grasp of what Firebase is and what it can do.

In the last section we had a look at the game server code and its different components and we learned that “Tables” are the areas around which a number of players join and participate in games. Now we’ll look at the creation of tables, which is done via a game “Activator”.

By |Friday, March 2, 2012|firebase|Comments Off on Firebase from Scratch, pt VI: Activating Games