Actually not really. They had some really awe inspiring stuff working, ACID at speed. One of the things that could have enabled would be multi-user gaming at a scale that is only imagined today, literally several thousand players on engaged in the same space at the same time, all with predictable semantics that would allow you to provide for individual engagement statistics and client visibility (basically everyone would see the same things happening at the same time, the really "hard" bit of multiplayer gaming). I had started coding up a massively multiplayer version of rogue since my 3d art skills are crap, the idea being to see if we could get a thousand people into the same room of an ascii dungeon at the same time and usefully engage enemies and collect loot. That simple example touches many places where things have to work predictably in order for a virtual "space" to succeed.
Hehe, that's so scary :) I'm busy sketching out something exactly like that at the instigation of my son (who is an avid gamer). I'm nowhere near realizing the vision but I've learned an awful lot just studying the problem from different angles. The key element seems to be 'who owns that data?'.
Exactly, so the player can be modeled as an index attached to several database records. You end up doing a geo-box select (see earlier posting here about why geo information data bases are hard), an inventory select, an equipment select, and an attributes select by player-id. The linkage is (player-id, geo) -> key for 'world' based databases, (player-id) -> key for 'player specific' databases. When you go to do an action you combine the action mechanics (pick up -> delete from world, add to inventory), (attack -> (roll) -> edit other attributes of monsters/players near by), (defend (roll) -> edit player attributes)) and (drop -> delete from inventory, add to world). Where at 'n' frames per second you need to do a select for a given view point to identify what the rendering engine needs to "show".
Clearly doing this with ascii characters on a terminal screen is much easier than trying to render 3D avatars in the real world but the number of database transactions per second becomes massive. If we posit that there are 1,000 players visible to the current player, and just the player / world select is a single transaction, then at 30 fps, that is 60,000 or so queries per second, you throw actions between players, and between multiple players (area of effect attacks) and add another 2,000 monsters and you're easily over 250,000 transactions per second.
Since FoundationDB was talking millions of transactions per second with full ACID it seemed like it would be a useful back end for this. Or put another way, you could contemplate building this and see if their product was actually able to keep up at this rate. And they asserted this was on modest hardware (like 32 nodes).
So yes, I was looking forward to the interesting places that investigation would lead and the things I could learn.
I sent you that mail, please check your spambox since google has an alarmingly high rate of false positives these days, even with people that you've already exchanged email with in the past they'll happily bin messages. Highly annoying.
