Archive for the ‘cubeia’ Category

« Older Entries

Cubeia Poker Network Demo

Tuesday, January 31st, 2012 by fredrik

We are quickly moving forward with our HTML5 support and are now proud to make our complete poker network demo with an HTML5 prototype client publically available!

You can grab the demo here: http://www.cubeia.org/index.php/labs

Download, unzip and run startup.bat (the demo only runs on Windows).

NOTE: There is a problem with some of the USB demos we handed out at ICE where some files were marked as read-only. If you have a USB demo and it is not starting up correctly you can follow the steps below to fix it (or download the zip above):

  1. Mark all files and folders in the root of the USB stick
  2. Right click and select ‘Properties’
  3. Uncheck ‘read-only’, click OK
  4. Choose ‘Apply changes to the selected items, subfolders and files’, click OK

Thats it! Now it should start as intended. If you want to speed up the startup process you can copy the content from the USB stick to a local hard drive.

Feedback is, as always, most welcome! :)

Posted in cubeia | No Comments »

Mobile devices on the rise!

Thursday, December 1st, 2011 by fredrik

While doing some research for an article today I stumbled upon a study made by KPCB regarding Internet trends for 2011. Below is a graph from the study depicting the percentage of traffic generated from mobile devices for some of the leading service providers Facebook, Twitter and Pandora respectively.

Mobile device traffic

These numbers are actually staggering. In only 3 years one third of the traffic to Facebook have shifted from computers to mobile devices. Mobile search has grown four times in past years. The estimate is that 152 million Android mobiles have been shipped in the second quarter of 2010.

There is no doubt that this will completely change the way we look at online services and how we use them in the near future.

Of course, as a platform developer we ask ourselves how can a game developer most efficiently provide content on such a fragmented market? Choosing the right client technology has never seemed more important than now.

Posted in cubeia | Comments Off

What’s up with Cubeia Poker?

Tuesday, August 23rd, 2011 by larsan

Observant visitors have noticed that on our Community site there mentions of a Cubeia Poker. It is indeed a poker implementation we started a few years back to have a demonstration game. It’s been developed on and off since then and stands at the famous 75% done. But now, thanks to a collaboration with our customer Jadestone AB it’s under active development again!

The source code is available under an AGPL license and there’s even a small demo to download. Even though it is early days still and the poker is not yet an “official” Cubeia product, you can hit the forums at our community site to ask questions. See you there!

Posted in cubeia, firebase | Comments Off

How I Learned to Stop Worrying about Serialization and Love the Wrapper

Saturday, June 18th, 2011 by viktor

Background
One of the great benefits with Firebase is the support for transparent failover. All you as a game developer have to do is to make sure that your game state is serializable.

The Problem
One common pattern that follows from this approach is that non-serializable classes (such as the Notifier or the Scheduler) tend to get passed around a whole lot, because they can’t be stored as instance variables. If you want to do Domain Driven Development, this is a bad pattern.

Half of the Solution
Storing those instances as “transient” is always an option, but only solves half of the problem. On deserialization, those values will be null and there’s no way to recreate them in readObject().

The Solution
Instead of referring to the Scheduler and Notifier directly, create a wrapper class which holds them as transient members. Then, pass that into all your collaborating classes. The parent class will hold a reference to this same wrapper and on each call from Firebase, it will inject the live versions of the Notifier and Scheduler and since all collaborating classes refer to the same instance of the wrapper, we’re now all set!

An Example
I find that a concrete example always makes things clearer. Here’s some code for a poker game. First, here’s the game state class.

public class Poker implements Serializable {
    private Wrapper wrapper = new Wrapper();

    public void addPlayer() {
        Player player = new Player(wrapper);
        ...
    }

    public void handle(GameDataAction action, Table table) {
        injectCallbacks(table.getNotifier(), table.getScheduler());
        ...
    }

    private void injectCallbacks(GameNotifier notifier, Scheduler scheduler) {
        wrapper.setNotifier(notifier);
        wrapper.setScheduler(scheduler);
    }
}

And here’s the wrapper.

public class Wrapper implements Serializable {
    private transient GameNotifer notifier;
    private transient Scheduler scheduler;

    ... getters and setters ...
}

Which means that from any any place in the code, we can do something like player.updateBalance(newBalance), which would look like:

public void updateBalance(int newBalance) {
    balance = newBalance;
    getNotifier().notifyAllPlayers(createGameDataAction(newBalance));
}

So, time for you to fire up your refactoring tool and put some candy in that wrapper!

Posted in cubeia, firebase, java | 2 Comments »

What’s New in Firebase 1.7.2?

Wednesday, March 9th, 2011 by fredrik

Firebase 1.7.2 is just about to be released and even though this is a small release I figured I can go through some of the additions.

Read the rest of this entry »

Posted in cubeia | 1 Comment »

ICE 2011

Friday, January 21st, 2011 by fredrik

Cubeia will be exhibiting at ICE in London next week. What will we have in store for the brave souls who come and visit ut?

Read the rest of this entry »

Posted in cubeia | Comments Off

PushButton Engine with FlashBuilder 4

Friday, January 14th, 2011 by fredrik

I have been looking at bit more at PushButton Engine lately, it is potentially a very good fit with Firebase + Flex API. However, setting it up in FlashBuilder 4 took some steps I couldn’t find anywhere so here are the steps I had to do.

Read the rest of this entry »

Posted in cubeia | Comments Off

Using the Styx protocol in your Firebase games

Thursday, January 13th, 2011 by peter

Styx is the binary protocol that the Firebase Server uses for communication with clients.
The styx wire-format is a very efficient and simple binary data stream that can potentially save a lot of bandwith cost.

Read the rest of this entry »

Posted in cubeia | Comments Off

From Idea To Success

Thursday, January 13th, 2011 by fredrik
I have a great idea for a game!

This has been the starting point for many meetings, someone has a refreshingly new idea for a game (social or money-based) and wants to offer it to the world. More often than not the idea is interesting and full of potential, but of course, between the idea and the smashing Zynga-esque success there is some uncharted territory.

Dragons

And beware: Because here be dragons!

Posted in cubeia | 3 Comments »

The Duct Tape Architect

Friday, October 8th, 2010 by fredrik
The Duct-Tape Architect
I have being doing software architectural work for a long time now, and as it turns out, the ‘right way’ of solving things may not always be the best way. Below are two real annecdotes from life in the trenches.
== The Case of the Database Bottleneck
I was visiting a company where we discussed their currenty system design and what problems they were experiencing. Their system had a respectful peak of 7 000 concurrent users and it turns out that at peak times they start to hit the limit of their database which is running as a single entity.
We discussed the regular slew of database scaling solutions such as sharding, dedicated reader nodes etc. and some pros and cons with each solution.
As it turned out however, they solved it in their own way. “Yeah, we solved it. We bought an SSD drive which replaced the old hard-drive, ” they said matter-of-factly.
Naturally I scoffed a bit at this and thought for myself that they have only bought themselves a little bit of time and in best case they could maximum grown by 50-100% but then it would be the same issues all over! Rookies! Surely they did not understand the beauty of unlimited, linear scaling with sharding?
Within one year, they had grown about 20% and was then bought by a much bigger player in the industry and their system was erased from the face of the earth in favor of the larger one. They never hit the limit of the SSD.
Later also did some calculations, if they had grown by 100%, they would have become one of the top5 actors in the market and their profits would have been through the roof.
So when looking back, in this case, it seems like the SSD solution was actually the right thing to do. They only needed to buy some more time for the deal to come through.
== The Case of the Missing Scheduler
Another case occurred when I was reviewing a large gaming network that was running cash games as well as tournaments. There where many tournaments running on a daily basis and most of them are re-occurring events, such as The Daily Lunch Tournament etc. Almost every such network I have known have had a scheduling options for tournaments. You would enter a tournament template and then say something like ‘run every day at 12 AM’ for instance. You would also be able to create a tournament and say ’start this tournament on October 10 at 18 AM’. Then the system would create and start the tournament as specified.
This network did not have that.
Instead, they had about 10 employees in Indonesia who would work in shift and manually create each tournament and then manually click ’start’ to start them. Nuts! This must surely be fixed!
So we started a discussion and I don’t remember my exact word, but they were something like: “This is insane! Surely we should be able to implement a simple scheduler in the system?”.
To which they replied something like: “Sure. But we have made an estimate on the time it would take us, and to cost of the developers that has US salary to implement this equals about 7 years of the Indonesian guys doing this manually.”
Yikes.
“Besides, do you want to be the guy who calls them up and tell them and their families that they are losing their jobs? And for what? Saving a buck after 7 years? We have a choke-full backlog to work on anyway.”
Hmmm. Maybe it would not be worth cutting other features out in order to prioritize a feature that would cause 10 people their jobs and not save any money for a long time. Could this be?
== Summary
Am I advocating that you shouldn’t care about scalability (just buy SSD’s!) or never automate tasks because there are cheap labour to be found? Am I advocating quick hacks and avoiding solid engineering principles? Of course not.
But sometimes it is good to try and raise the view a bit and try to see what *actually* needs to be solved. As engineers we do sometimes get stuck on implementing the ‘right thing’ and lose sight of reality as it comes.

I have been doing software architectural work for a long time now, and as it turns out, the ‘right way’ of solving things may not always be the best way. Below are two anecdotes from life in the trenches.

Read the rest of this entry »

Posted in cubeia | 24 Comments »

« Older Entries