Optimizations (Part I): Operation Screaming Pixels
glitch.com
glitch.com
Doubtless the serverside sounds really interesting - Java + presumably rhino or a parallel node.js world. Definitely nice to see its all about content!
On the client-side, they are using Flash - presumably they've got RTMP going (writing RTMP servers is fun and quite doable without using any Adobe $tack), which is neat. Although they might be messing around with "websockets". That might fit better with their plays to move beyond Flash later.
From looking at their videos and dovetailing that with that post, they are doing this as a massive Flash game as 2D sprites. Flash has supported decent 3D graphics for a long time and you could get that same look from a noddy 3D engine and it'd be hardware accelerated and much much faster and smaller, directly addressing the issues of the post. The artwork really ought to measure in megabytes not the hundreds of MB they mention in the post. Are we given to believe that to play the game they will have a few GB of unpacked textures? Madness.
What is odd is that they somehow decided that the server is burdened with sending a finished spritesheet over the wire, instead of having the client composite and cache them. That would reduce their load down to sending the paperdoll parts, which will be about as tiny as any textured 3D model. With some work to space out the compositing process over multiple frames, the CPU burden during caching would be negligible.
Edit: Read it again, looks like they actually were caching on the client before. Too bad; just switching to Molehill and compositing in real-time with textured quads might have been enough.
"command-line version of Flash for Linux running on a server to create source images of the avatar"
That's an.. interesting solution.