Jul 1, 2008
Adobe just dropped a bomb as far as I’m concerned. They’ve announced a collaboration between Google and Yahoo to bring fully searchable SWFs. Ted on Flex reveals the best part:
The cool part is that this also covers dynamic data loaded in from requests to a server, these are typically ignored in both AJAX and SWF applications.
This is going to open the door for a lot of the cool and useful things we’ve been wanting to do for clients at Figaro, but have had reservations about because of SEO implications, and I’m sure many RIA houses out there feel the same.
Combine this news with a tool like swfaddress to provide deep linking into your applications and BAM! you have a killer combo. Let’s just remember to keep our apps classy and tasteful, guys and gals. This news isn’t cause to go hog wild with flash like the late 90s, early 2000s restaurant site debacle.
May 30, 2008
I’ve been thinking a lot about the different options we could use for the Space Survivor infrastructure. The game itself is flash based and the site uses html/css (doesn’t make sense to make the entire site flash for performance reasons) and the site-specific framework and semi state-less page views will most likely be on CakePHP. So, if you just want to check your stats, view ships, read missions, or anything that fits into the normal webpage paradigm it’ll most likely be served from a PHP server.
When we start talking about the technology required to provide a backend for the actual game, that’s when the choices get interesting. Most multiplayer games on the PC or console probably use some sort of custom framework for handling network traffic, probably written in C, C++, Java or some other low-level language. But, I kinda want to mix things up and jump on what I think will be the next generation infrastructure for networking/multiplayer in games - Erlang.
There was an article on Reddit quite a while ago - Writing Low-Pain Massively Scalable Multiplayer Servers - that really says it all a lot better than I am qualified to. I highly suggest reading it, but I’ll talk about concurrency here.
Erlang is a great choice for multiplayer infrastructure because it was built from the ground up to be a high-concurrency system. It’s trivially easy to add nodes to an Erlang cluster because there is built-in node detection; so once you create your new instance of the Erlang emulator and connect it to any other node in your system, all other nodes become aware of it. The bottom line is, you don’t have to spend any resources creating this network effect - it’s a fundamental part of the language!
In the article I linked to above, Joel recommends creating a node for each processor on a machine. It’s not uncommon for servers now to have 8 processors, definitely at least 4. So if erlang is your platform of choice, you can immediately create 4 or 8 instances, each doing separate tasks and maximizing your CPU usage out of the box! Amazing.
I’ll continue this discussion in later posts as I gain more understanding of how things fit together in an erlang-based multiplayer infrastructure.
