I will always remember the past year as the time when we did an “MMO in 8 months”. 15 months ago I would have laughed about the hubris of the thought alone. Yet here we are, Drakensang Online is going into open beta soon, in fact you can register now and should be able to start playing soon after, since new registrations are now unlocked automatically after at most a few hours. The term MMO is debatable of course. MMO is such a terribly heavy word. MMO has become another term for a “300-million-$ budget, 5-years-in-the-making, overambitious WoW-wanna-be fiasco”.

Drakensang is none of that, and that’s why I hesitate to call it an MMO because the term is loaded with wrong assumptions. But if you look at the technical side of things, Drakensang Online *is* an MMO. But it does many things different then old-school MMOs: it runs in the browser, it doesn’t require a huge front-end download (with an average DSL line you’re up and running after about 30 seconds and we’re working on improving that further), it is free-to-play, it has an action-combat system - but technically it’s still an MMO.

I’m incredibly proud of being part of the Drakensang team and Bigpoint, because the whole “MMO in 8 months” thing wouldn’t have been possible with any other team and without building on Bigpoint’s existing infrastructure and learning from the original F2P gurus. And I’d like to believe that Nebula3 also played its little role by providing a solid code base for the client and game server.

Of course what Drakensang is today is only the beginning. Without having to worry about Gold Masters, patch distribution, or slow TRC/TCR/Lotchecks we currently have a production pipeline in place where we can manage a weekly release cycle and we plan to keep that cycle for the foreseeable future to fix bugs, improve performance and tweak the game play. Big new content releases are on the horizon which will expand the world of Duria with new regions, antagonists and playable character classes, items, skills, etc... “Relase early, release often, and listen to your customers” - indeed.

In the mean time, Nebula3 has gained a few interesting new features:

  • An improved, multithreaded HTTP “virtual file system”, with zlib compression, MD5-hashes for fine-grained local caching, CDN support and background-preloading. Instead of downloading a few big bundle files, our client fires HTTP GET requests when a file is needed (and is not in the cache). Requests are prioritized and handled by several threads, so that large low-priority downloads don’t block small high-priority downloads, and several HTTP GET requests can be in flight at the same time – but since all of this is wrapped in a “virtual filesystem”, the same client can load all of its data from disc as in the olden days without changing a single line of code.
  • We ditched our own Tcl based meta-build-system and went with CMake instead.
  • We also got rid of Maya as our level editor and wrote our own WYSIWYG editor.
  • The Foundation Layer has been ported to Linux, and is the base for our game server
  • We have added wrapper addons for FMOD, FreeType, MySQL, PathEngine, and several Bigpoint-internal APIs.
  • The RakNet-based Network addon has been overhauled and is the basis for our client/server code.
  • The graphics subsystem now supports hardware-instanced rendering to efficiently render many instances of a graphics entity in a single draw call (that’s how we keep the drawcalls under control for our Drakensang maps, from thousands of draw calls down to about 200..300 drawcalls).
  • Character models can now be baked, no matter what equipment a character wears, it’s always rendered in a single draw call (actually two drawcalls because of the depth/normal- and material-passes of the Pre-Light-Pass renderer).
  • The shader code has been refactored for better portability and moved into its own subsystem.
  • The realtime-shadow system has been cleaned up and optimized.
  • A new, modern decal system.

Compared to all the new server and client code these changes are relatively small though.

The completely dynamic lighting and shadowing, and the new decal system help us to hide the fact that our maps are made from many small tiles, and the hardware instancing helps us to render thousands of visible models efficientely. All of these features have been implemented for the single, most important requirement of the Drakensang Online client: to keep the download size of assets as small as possible. While our offline Drakensang titles were about 4.5 GByte in size, all of Drakensang Online currently fits into about 100 MByte, and only a fraction of this is required upfront to start playing. A nice side effect of this hardcore data optimization is that loading times between maps are almost non-existent. If the data is already in the download-cache a map transition takes about one or two second, but even if the data must be streamed it rarely takes longer then 5 or 10 seconds until everything has been streamed – in the old Drakensang we struggled to keep loading times under 40 seconds - from the local hard disc!

In my spare time I also played around with Nebula3 on iOS, up to the point where I’m able to render a Drakensang Online map on the iPhone4 and iPad at about 30 fps in full display resolution. For the Foundation Layer I’m actually using the Linux port with very minor changes, the Render Layer has been ported to OpenGL ES 2.0, and I had to be a bit creative to make up for the missing hardware-instancing. The fill rate of those devices is not enough to support any type of deferred shading, so I went for a simple forward-renderer with one dynamic light source. Maybe the next batch of mobile GPUs will be powerful enough for the light-pre-pass renderer, since it actually is not as demanding on fillrate as other deferred shading solutions. I also played around a bit with the Android SDK, but the whole iOS development process is so much more streamlined that I didn’t get very far yet. It’s just more productive and enjoyable to write, debug and profile with XCode and the iOS SDK then with the Android SDK (even *with* the braindead code-signing bullshit required on the iPhone). Eventually I hope to find some time to port N3 to Google’s NaCl, which in my opinion is the most interesting project coming out of Google EVAAAR on several levels (not just for browser-games but for more secure native code in general).