Posts Tagged ‘ruby’

Script Support in Firebase

Wednesday, March 10th, 2010 by larsan

Now we have released a candidate for script support in Firebase! This is something we’re very excited about as it means no more Java (unless you want to of course, old hands like me aren’t likely to change in a hurry).

This is a first release so there’s no support for tournaments or services yet. But is not far off.

We’re using Java’s built in scripting support under the hood. It turned out to be not to trivial, but not very hard either. The interesting issues are likely to arrive when we start optimizing and bug hunting. And speaking of optimizing, I ran a few bots, say 50, against a very small script (basically the equivalent of a hello world) and on avarage the bots returned on 10 ms. That’s 10 ms for network latency, Firebase internals, and script evaluation for each event. Pretty damn good! Next step there will be to start optimizing depending on the script implementation, cashing compiled scripts, mutli-threading etc.

One major up-shot of writing on a script language and re-evaluating the script for each event is the velocity: you don’t have to restart Firebase when you change code, the script is re-evaluated automatically. The round-trip time is cut dramatically!

And… You want to see code? Here’ you are, this is the server part of the Hello World tutorial, written in…

JavaScript:

function handleDataAction(action, table) {
    _log.debug('Entering handleDataAction');
    var data = _support.getActionDataAsUTF8(action);
    var playerId = action.getPlayerId();
    var outAction = _support.newGameDataAction(playerId, table);
    _support.setActionDataAsUTF8(outAction, data);
    table.getNotifier().notifyAllPlayers(outAction);
    _log.debug('Exiting handleDataAction');
}

Ruby…

def handleDataAction(action, table)
    $_log.debug("Entering handleDataAction")
    data = $_support.getActionDataAsUTF8(action)
    playerId = action.getPlayerId()
    outAction = $_support.newGameDataAction(playerId, table)
    $_support.setActionDataAsUTF8(outAction, data)
    table.getNotifier().notifyAllPlayers(outAction)
    $_log.debug('Exiting handleDataAction')
end

Python…

def handleDataAction(action, table):
    _log.debug("Entering handleDataAction")
    data = _support.getActionDataAsUTF8(action)
    playerId = action.getPlayerId()
    outAction = _support.newGameDataAction(playerId, table)
    _support.setActionDataAsUTF8(outAction, data)
    table.getNotifier().notifyAllPlayers(outAction)
    _log.debug('Exiting handleDataAction')

Groovy…

def handleDataAction(action, table) {
    _log.debug('Entering handleDataAction')
    data = _support.getActionDataAsUTF8(action)
    playerId = action.getPlayerId()
    outAction = _support.newGameDataAction(playerId, table)
    _support.setActionDataAsUTF8(outAction, data)
    table.getNotifier().notifyAllPlayers(outAction)
    _log.debug('Exiting handleDataAction')
}

Cool, eh?

You’ll notice some strange objects above. We bound some helper objects in the evaluation context, “_log” a Firebase Log4j logger, “_support” a tool for string to byte conversion etc, and some other helpful stuff.

The JavaScript Hello World can be found here.And tentative documentation here. Have fun!

Firebase CE – What’s next?

Tuesday, January 26th, 2010 by larsan

So, we’ve released Firebase Community Edition. Now there’s a Java game server which is open source and available to be used. Now what?

Well, here’s what! There’s a couple of things we’d like to get out of the door immediately and some of them will start appearing soon indeed:

  • Script support: Java 6 has build in support for JavaScript and can be extended to support a rather large list of script engines. We’d like to add support for writing your game using any of these script languages. We’d love to see the first Ruby+Flash game out there!
  • IDE support: We already have proto code for some Eclipse plugins lying about, and these should be polished up and released. Of course, you can always use our Maven archetypes and plugins, and then import into Eclipse, but direct support would be nice too. Of course, if anyone want to use NetBeans weed have to figure out something for you to eh?
  • Documentation: It’s sparse at the moment and needs to be fleshed out. We hope you’d like to help us here by simply telling us what is missing and asking us about all those things weäve forgotten to write down. Or indeed wasn’t explained properly.
  • IoC support: This is a biggy. Again we have proto code for for Guice lying about which needs to be fixed and published, but obviously we need to add direct support for Spring as well. Actually, you can write your components in Guice now but you’d have to wire it together yourself. Spring needs to be tested, so let us get back to you on that, ok?

And that’s what we want to do the immediate future. Watch this space, this is going to be fun!