Recently we at
Valve started work on a huge MMOG (Massively Multiplayer Online Game) project with a U.S. based games publisher. It's supposed to go live in a little less than a year from now, but we've already got a big team working on the MMOG technology and preproduction.
We're actually not only building a game, we're creating a end-to-end technology platform (code-named TrunkTech) which enables us (or anyone else for that matter) to create browser based MMOG's very rapidly. And I really have to emphasize the word "rapidly", as we've set extremely ambitious goals for our technology.
I'm currently the lead front-end developer and am closely working together with a phenomenal Java guru to specify and develop ( actually specifying through developing ;) ) out the low-level bits and pieces for our technology.
And I must say, I'm having a blast! At long last I'm able to work on stuff that I have almost no prior knowledge of, make sure that whatever code I write should still be readable in five years time and work on a game that I truly believe is going to be a big hit.
So I thought of starting to write a series about building MMOG's with Flash (yeah, it's Flash based), and share my thoughts and learnings from the experiences I gather by working on TrunkTech.
To get an a subject for my first post under this title, I'll start of easy:
Why Flash?
When we stared the project we quickly came to the conclusion that our client would be Flash based. Currently, the biggest web-based MMOG is
Habbo, from
Sulake (back in late 2000, I was supposed to become the first employee of what was later to be Sulake, but I chose to go to Razorfish Helsinki instead. But yeah, that's a different story altogether). Habbo is based on Shockwave, and frankly, I believe that Shockwave is still (barely) alive because of Habbo. Shockwave has seen it's best days and is quickly loosing penetration, developers and the will to live. It's too old and clumsy and has never been a productive development platform.
As we really wanted our games to be playable by everyone on the net without installing anything whatsoever, Flash was the obvious candidate. And as we did not intend to go full 3D (our MMOG's are not for hard core gamers), we quickly ditched Shockwave and
Unity3D as our client-side platform of choice (although we may want to revisit Unity3D at some stage as it's really gaining traction right now).
Flash, ecpecially with the second incarnation of it's virtual machine, has become great for development of even very complex technology platforms with it's modern and fast virtual machine. AS3 is strongly typed, catches quiet a many errors at compile time and let's the developers who use our API debug with strong tools. The syntax is modern and is ECMA-Script compliant... err... Well it was supposed to be, anyways, so people with Web development skills in general can quite easy hop on. Networking is robust as we now have access to binary sockets (very important, more on that later on). And most importantly Adobe is pushing the technology into the right direction, and Flex Builder 4 is going to make development even easier with better debugging, intellisense and auto-completion.
We did pause for a brief moment when deciding upon the technology, though. Why? Rendering speed.
While the VM2 is fast enough for most of the logic we're expecting our platform to be used for, the same thing can't be said about rendering. Kids expect quiet a bit of graphics crunching from todays desktop games, and online games are catching up really quickly. Even five years ago Shockwave was able to harness the power of the GPU, making it still about 10.000 times faster to render texels as Flash 10 does (mileage may vary). While this is crucial for 3D games, it would still make a lot of sense to have 2D drawn on the GPU aswell. (and no, don't even dare to write a comment about wmode=gpu, unless you're Tinic and have some ace up you're sleeve).
But in the end, we quickly decided that penetration was far more important than rendering speed. There's a lot we can do to make up for the poor rendering speed in Flash by beeing creative and applying a trick or two, but penetration is something you can't cheat yourself around.
Up next
In the next few posts I'll talk a bit about our Server (Java-baed), Bamboo (our client-server protocol), our server-side scripting language (ActionScript3 compiled into Java byte code, aha!), meta-programming to let developers "multi-playerize" applications really fast, mixing 3D with pixel bender to texturize a great number of 3D model based avatars and any other experienced I might find worth sharing (or you requesting).
Stay tuned.
Comments
Sounds very interesting! I wonder if you will use an existing 3D Engine (Papervision, Alternativa3D, Sandy or any other) to display 3D objects or make your own (like Roxik with his Saharikura).
Greetings from México!
Posted by: bioRex | 9 Dec 2008 07:18:55
bioRex, our current prototype uses PV3D, mainly because we wanted to quickly get an idea of how many 3D-based, animated avatars we can have on screen (one hundred). But we definetly don't need the whole PV3D package in the long run (as we're isometric and rendering one single animation frame at a time), but for a proof of concept it wasn't worth creating our own rendering engine (although we now will). Our PixelBending and intelligent caching is what gets us to support this a big number of avatars.
Posted by: Tuomas Artman | 9 Dec 2008 19:55:16
your PixelBending and intelligent caching will support 100 animated 3D avatars on screen!!??
Impressive!
Posted by: bioRex | 10 Dec 2008 05:54:01
coolio when you make it can i be a moderator ? if yes send an email to my email at DylanMatthews123@gmail.com
Posted by: Ace of spades | 19 Dec 2008 03:10:06
Seems we're gonna have to hurry a bit more now : )
http://qb9.net/vw
Posted by: Nicolas Cohen | 19 Dec 2008 16:10:07
Post a comment
