Monthly Archives: March 2012

MongoDB, Morphia and EmbedMongo

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?

By |Thursday, March 29, 2012|cubeia|5 Comments

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 
      -DarchetypeGroupId=com.cubeia.firebase.bots 
      -DarchetypeArtifactId=firebase-bots-archetype 
      -DarchetypeVersion=1.8.0 
      -DarchetypeRepository=http://m2.cubeia.com/nexus/content/groups/public

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

Firebase from Scratch, pt V: What’s In a Server Game Anyway?

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

By |Thursday, March 1, 2012|firebase|Comments Off on Firebase from Scratch, pt V: What’s In a Server Game Anyway?