Status Update

Quick update:

• A couple of new Wii and DS devkits have arrived this week, one of the Wii-kits is for me so I will join the party soon, at least part-time.
  
• I'm very busy working on Drakensang at the moment, so there won't be a lot of new stuff in the next Nebula3 release from my side, after all I fixed quite a few bugs in the zip-archive code, so that all runtime data is now loaded by default from an export.zip archive (it's also working on the Xbox360, but I will add support for the 360's native compressor at some later time because it's most likely faster then the generic zlib).
  
• Johannes Kosanetzky pretty much finished up the Application layer by porting the essential parts of Mangalore over to Nebula3, this will be in the next SDK release even if it's still work in progress. The general plan here is to have a nice little demo application with simple physics, a player-controllable avatar and a chase camera. All with complete integration into our existing level design workflow.
  
• Malte has been working on porting the Foundation layer over to the Wii, and is now almost finished with it. The Wii specific code won't be part of the public SDK of course.
• The Wii-port got a priority boost recently. Because of this we will essentially take a shortcut and add a new "Nebula2 backward compatibility" layer. This layer will contain essential Nebula2 subsystems (for instance animation, audio, characters, etc...) which are just brought over to N3 without alot of refactoring, so that we can get a good base for a real-world project ASAP. The plan is to replace those N2-subsystem step-by-step with properly refactored systems in parallel to actual project development, so that we have enough time for proper refactoring and to implement platform-specific optimizations where applicable.
  

Slight Wii rant: Aaargh... hardware considerations aside (involving GameCubes, duct tape, etc... which I have no problem with since a scalable engine can take care of that). But I'm really shocked about the development environment and API. I think the last time I worked in a similar environment was when we did Urban Assault in Watcom-C under DOS-Protected-Mode. This was in the mid-90's. Memories of AmigaOS pop up as well (although AmigaOS was in several aspects more advanced, and this was in the mid-80's). I appreciate the simplicity of the hardware and software and all, but... WTF? It's like 20 years of progress in software development simply didn't happen. We're basically expected to built gothic cathedrals with a hand-axe... did I mention already how amazingly f*cking cool the 360's development environment is? Well nevermind...

One more reason to get N3 up and running on the Wii ASAP ;)

Level Design And Build System Thoughts

I've been discussing with Bernd a lot lately how we could improve our build system and level design process over the next months. Turnaround times for complete and incremental builds, and also the "local turnaround" of level designers are starting to become critical for a "big" project like Drakensang. A complete (nightly) build is now at around 11 hours (this includes recompiling and rebuilding everything, building an installer and uploading the result to an FTP site). An incremental build (during the day) takes at least half an hour and up to 2 hours (without building the installer and uploading). To put this into perspective, Drakensang has about 7000 textures and about 4500 to 5000 3D models (I don't have the exact numbers at hand because I'm not at the Labs right now), the runtime data for the whole game is currently about 4 GB in size.

For level designers, there are 2 separate turnaround-time problems: updating the work machine with the new data from the last nightly build (this may take somewhere between half an hour and and hour or so), and the time it takes to test a change in the actual game (we're working with Maya as level design tool right now, not an ingame editor).

We have a few holy dogmas at Radon Labs:

• Daily Build: everybody must work on the most current data which is at most 1 day old
• "Make Game": creating a complete build must be fully automated, and happen on a central build machine
  
• The Toyota Rip Cord (don't know if this is translated correctly, it's the "Toyota Reißleine" in German): if there is no working build, production essentially stops until the problem is identified and resolved (and the responsible person has been ritually tared and feathered).
  
• One Tool For One Job: don't use several different tools for the same job (all 3D modeling is done in Maya for instance)

We also have a some other secret dogmas in our canon, but they don't affect the build system or level design work flow so I won't utter them here :)

We could easily chicken out by giving up daily builds for instance. But this would most likely create "Ivory Tower" pockets inside the company. Tendencies like this happen all the time, they are dangerous for the project, and must be fought the instant they show up.

Instead we stepped back and thought about how a perfect build-system and a perfect level-design system would look like. The whole problem is really 3 separate (but somewhat related) problems:

1. reduce build time
2. distribution of build data to workplaces
3. reduce turnaround times for level-designers

Point (1) is relatively easy. I think the only worthwhile improvement can be gained by distributing the workload across several build slave machines. We already invested serious optimization work into our Maya exporters, so there's not much more to gain there. Setting up a distributed build system is an interesting job, but not too complicated if you have control over all build tools.

Point (2) is more interesting. The question here is "do we really need to distribute all the build data to all workplaces?". That's 4 GB of uncompressed data per day per workplace, but a level-designer typically only needs a fraction of that data during a normal work day, which typically looks like this:

1. level designer comes in at the morning, and pulls the most current build data from the nightly build
2. level designer cvs-edits the files he needs to work on
3. level designer works inside Maya and several specialized tools, like dialog and quest editors
   
4. level designer needs to check his changes in the game frequently (involves starting the game)
   
5. in the evening, level designer cvs-commits his work and goes home
6. the build machine creates the new nightly build for the next day

There are several problems here:

• in the morning, a lot of time is wasted to just update the runtime data of the workplace machines
  
• the local turnaround time to check changes in the game is too long (somewhere between 1 and 3 minutes)
• when the level designer checks in his work in the evening, subtle collisions may occur with the work of other level designers (this is especially critical in "persistent-world-games" like Drakensang)

Above a specific project size and complexity, level design becomes more and more frustrating because more and more time is spent waiting for results.

Now here's the actual point of the whole post: What if level-design would actually be fun? We could improve the fun-factor a lot if the level designers would immediately see results, and could directly work together with others. What if level-design would be like mixture between a Wiki and a multiplayer game?

Here's how we think our level design should work in the future:

1. level designer comes in the morning, and starts the game in level-design mode
2. the game notifies the level designer that an update is available, updating only involves pulling a new executable
   
3. the game connects to a central game server, which holds the actual game data in a database, and the graphical/audio content through a network share
4. the level designer creates, places and destroys game objects directly in the game, all changes are distributed via the game server to other level designers working "nearby"
5. to test the changes, the level designer presses a play button, and after a few (very few!) seconds, the editor will change into game-mode (it is very important to strictly separate the edit-mode from the game-mode, because application programmers should never have to care about level editor stuff)
   
6. the ingame level editor is augmented with specialized tool windows written in C#, some of them generic (i.e. a nifty table view), some of them project-specific (i.e. an inventory editor)
7. in the evening, the level designer shuts down the machine and goes home

So we would give up Maya as level design tool in favor of a "collaborative ingame level editor". The collaborative/multiplayer part sounds like a gimmick, but it's actually very important because it solves the data collision problem. Since all changes are immediately distributed to all level-designers, there's no danger that several conflicting data sets are created (the longer 2 separate data branches are evolving, the more likely collisions will occur which will be difficult to resolve).

Up until a few days ago I would have scrapped the whole idea and declared it as impossible. Implementing an ingame editor which would suit all the different genres we are doing sounded like opening a can of worms. But in the end it isn't that difficult (for a distributed system it's actually necessary to have an "ingame-editor"). We already have a lot of the basic building blocks in place:

• We can pillage a lot of ideas from our current "Remote Level Design" system. At the moment, we can run Maya and the game side by side, and changes in Maya immediately show up in the game, this is nice for tweaking lighting parameters for instance.
• Game data already lives completely in a lightweight local database (SQLite). This gives us a lot of advantages:
• a game entity is completely described by a simple set of named, typed attributes
• a game entity always corresponds to a single row in a database table
• all "other data" already lives in database tables (even hierarchical data, like dialog trees)
• all data manipulations can be expressed with a very small subset of SQL (INSERT, UPDATE and DELETE ROW)
• The only operations that must be supported by the generic ingame level editor must be "Navigate", "Create Entity", "Update Entity", "Destroy Entity", where creation is always a duplication either from a template or from another entity. More complex operations, or different views on the game data, will be implemented in C# tools which are connected through a standardized plugin interface.
  
• With Nebula3's TcpServer/TcpClient classes and orthogonal IO subsystem as base it should be relatively easy to setup the required in-game client/server system
• We are already using some specialized editor tools written in C# (we did some of them in MEL before, and C# is a HUGE improvement over MEL especially for GUI stuff)

The devil is always in the details of course. But I think this is a pretty good plan to fundamentally improve our level design process in future projects.

New Radon Labs Web Page

Our new company web page has gone live over the weekend! I really love the bright and colorful design. Apart from the fresh new design the other reason for the refactoring was better maintainability. Now that we're churning out several games a year it must be easy to update the website with game flyers and news. And it was suprisingly hard to get there. In the beginning we wanted to entrust an external company with our web page. But although Berlin is packed full with web designers it is suprisingly hard to find a good one worth his money. Most of them only seem to care about the artistic side, and more or less ignore usability and maintainablity. What we needed was a carefully engineered webpage that also had to look good. After some failed attempts we finally did it internally, and now we have a solution that's easy to maintain and integrates nicely into our company infrastructure.

Google Docs

I recently had to wipe and setup my notebook (it's amazing how fast it feels now again, XP really does rot over time), and with it went the pre-installed Microsoft Office (which I just noticed today). But from time to time I have to write a proper document, nothing fancy, all I usually require is to structure the document with different types of headings, and to insert an image or a table here and there. I'm also often switching between my private notebook which I carry around everywhere and my work desktop, which sometimes involves copying said documents around manually. So in lack of an installed MS Word I gave Google Docs a try, and so far I like it. It even makes a nice blog editor, the builtin Blogger editor messes up source code for instance, but with Google Text everything is ok:

Ptr<MyNS::MyClass> myObj = MyNS::Create();
IndexT i;
for (i = 0; i < myObj->NumItems(); i++)
{

// a comment

myObj->ProcessItem(i);

}

Instead of Tab, one must use the "Indent More" and "Indent Less" functions, otherwise the indents will disappear when exporting to Blogger, but all in all this is a huge step forward from Blogger's builtin editor.

Let's see if tables work as well:

Bla	Blub
123	234

Nice :)

In Praise Of Ninja Gaiden

So I finally played through Ninja Gaiden (Black) in Normal difficulty, boldly moved on to Hard difficulty - which by the way gives a whole new meaning to the word hard - got totally destroyed at the Alma boss battle, and immediately started a new session on Normal again. That's how f*cking cool Ninja Gaiden is. The first play-through is just standard procedure to become familiar with the environments and to know the story just enough to ignore it in the following play-throughs. After these minor nuisances are put aside, the game becomes the true Ninja Gaiden, reduced to the gamer on one side and Ryu's weapon on the other, connected through the game pad. And this essence of the game, unleashing combos, Hayabusa's unbelievable moves, the perfect feedback through audio, gore and rumble is what sets Ninja Gaiden far above all other fighting games I have played so far.

Playing NG is almost like an exercise in meditation. The moment one loses focus and allows the mind to wander off the disciple is mercilessly punished. The difficulty level of Ninja Gaiden is the stuff of legends. But the game is never unfair. Becoming better at the game is purely a matter of training and honing one's skills, and never of pure luck. Sometimes another weapon, a new combo or another way to use the environment makes all the difference, but most of the time it's simply about not losing focus and keeping calm.

So in conclusion I award Ninja Gaiden a score of 11 out of 10, and that's after deducting 2 points for lame story and setting :)

I also played a few hours into Blue Dragon, enough to realize that old-school JRPGs are simply not my thing. Conan is alright but the combat lacks oompfh (maybe I'm spoiled by NG). I'm also feeling a slightly suspicious urge to play Dynasty Warriors (Empires) which I cannot really explain. There's something fascinating about the 3 levels of the game (the turn-based strategy phase on the top level, the Z-like elements of conquering bases during the game, and finally the pure hacking and slaying on the lowest level) which shines through the layers of bad graphics and voice acting.