Contact us for your own Poker & Casino license now!

info@cubeia.com
Stora Nygatan 44, 111 27 Stockholm
  • No products in the cart.

March 2012

Most of the times when working with online games we run into the need to persist data that is produced by the games. This can be anything from hand history to game state to audit trails for remote calls to other systems. But what they usually have in common is that it is high volume writes, hardly any updates, some reads and that the data has large variation in what we need to store even if it is within the same context. That last part about the data having variations is what makes this interesting. Take hand history for instance, we want to save events that are executed on a Poker table. On a Poker table many things happens - player join and leave the table, bets are made, cards are dealt, players get more chips etc. etc. These individual events might have a very different set of attributes; a raise will be type of action (i.e. raise) and an amount, but a player making a buy in will have completely other attributes. So how can we best solve this with the lowest complexity?

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.

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

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".

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.

And in this installment we'll get to some actual code! Exciting! We'll start off with looking quickly at the major building blocks that goes into a server side Game, and then we'll dive into a traditional "Hello World".