DDO = MMO?

I started playing Dungeons and Dragons Online: Stormreach (DDO) a few weeks ago. I've been looking forward to this for a while, as I'm a big fan of the D&D franchise, and felt it would make a fine concept for a virtual world.

Before the game's release, there was a lot of talk on the forums about how the game was going to be strongly instanced -- that is, that adventures would be isolated to a party of players (which is limited to six), and their adventure would be separate from another party that happened to be doing the same task. This is an idea that many games are now using, to prevent griefers (players that just wish to annoy other players) and to better handle server resources.

The rest of the world, I was to understand, was not instanced, so if you weren't on an adventure, you could mingle with the other people in the world. This is partially true; you can certainly mingle with others (in the taverns, on the street, or at the various trainers or quest-givers), but even the outside world is instanced -- there are four different "The Harbor" areas, and which one you end up in is based on the load in them all.

Now the game does supply a fiction-breaking method to hop between these four instances, which means you're not forced away from your friends, but this really puts a cap on the "multi" part of "multiplayer".

But is mingling with people what makes a massively multiplayer game or virtual world work? Should DDO be considered one at all?


I've been struggling to like this game. Part of that is because I'd like to play on my own if I wished, but the developers were pretty clear that the game was designed with party adventure in mind. It can certainly be fun when you have others with you (because you aren't dying all the time), but I don't care for the idea of having to find someone to go adventuring with every time I wish to leave the tavern.

I'll admit that the interface for finding others with which to adventure is a good one (although again it breaks fiction -- what's wrong with bellowing out in the tavern, "who wants to clear the sewers of their infestation?" But it does do a good job of helping you find a certain level cleric to heal the group or a rogue to disarm the traps.

But the party is still limited to six. This means you are sharing a common goal, a world event, with at most five other people. It's fun for small adventures, but what about the grand scheme?

And these adventures... I was under the impression, early in the development stage, that the missions had an underlying theme, but that the dungeon or forest or crypt would be different each time, so while you may have heard from others what the gist of the adventure might be, you couldn't know what was coming. I've yet to see this, and it is again fiction-breaking that you can simply redo the same adventure over and over again -- how many times can you save that girl, find the lost badge, or recover that darned healing potion cask?


It finally occurred to me the other day: DDO is not a massively multiplayer game. It's not a persistent world. A better way to define the game is to relate it to a game such as Diablo 2. You could go online, there were other people with which to adventure, you could trade items ... but there was nothing persistent. The only think that changes on the server when I finish saving that girl yet again is that I have a few more experience points, a few more copper pieces, and a damaged mace. But Stormreach is no better off for it; I haven't made things better or worse for other players; and that damned girl is just going to get kidnapped again.

There's no housing with which the players can litter the land. You can't even drop items on the ground -- a good idea from a resource management point-of-view, to be sure, but a bit immersion breaking. And there will be no epic battles as the world's fiction progresses, where dozens or hundreds of players from numerous guilds will come together for a lag-inducing grandiose battle against some great evil.

But perhaps I'm to blame for the misconception, because the game *is* exactly the way they said it was going to be. Perhaps it's my fault that I expected the experience to be more in line with previous entries in the field. Or perhaps they're culpable, because it's not truly a massively multiplayer game. But did they ever claim it was?

As I said, I enjoy the game, and now that I've gotten it out of my head that it's a virtual world, I won't be so critical. It's just an online game where you can see the other players walking around instead of in a roster (like blizzard.net, battle.net, Steam, etc.), and I can enjoy it more now that I'm conscious of that. But I suppose I'm a bit disappointed that we still don't have a D&D virtual world.

Perhaps MMORF can offer that possibility?

Any chance?

I've recently discovered two other projects, Multiverse (http://www.multiverse.net) and BigWorld (http://www.bigworldtech.com). Both of these purport to be "Complete MMOG" solutions.

I heard of Multiverse from its relationship to James Cameron, the director, mentioned I believe in a Wired article. According to their press, they support the .mesh format (though I don't know graphic formats) and have a converter to get you from other popular formats, such as Maya and 3dMax. They have a tool for designing the world. They have support for a product called SpeedTree (http://www.speedtree.com) for providing scenery.

They provide a client, based on the Axiom 3D engine (http://sourceforge.net/projects/axiomengine), and the client can be customized using Python or C#.

The server is written in Java. Their target platform is Linux, but it also runs on Windows XP. They support multiple servers, splitting the world into a quad tree, and passing off quad trees to other servers. Objects are stored as either XML or binary data. Extensions to the server code are either written in Java, for low-level changes, or Java or Python to add features to their MARS (Multiverse Agnostic Rules System). The server does not currently support instanced areas. It uses TCP and UDP for communication.

The game world Kothuria (http://www.kothuria.com) has been built on the Multiverse engine. They do not charge licensing fees provided you do not charge for use of your world.


BigWorld I heard about on the Multiverse forums. I'm not sure what mesh format it uses, but it has a plug-in for 3dMax. They have a BigWorld World Editor to design to world.

They provide a client, the BigWorld Technology Client engine, which is customizable with Python, HTTP and XML. It runs on Windows.

Their server supports multiple machines, and re-aligns server load based on CPU usage. They don't say what language it's written in, but it can be modified with Python. They support dynamic world updates, dynamic manipulation, climate and day/night.

---

So what does this mean for MMORF? Well, it sure crushes the novelty of it all... I suppose I shouldn't be so surprised -- did I really think no one else would do this?

Both projects talks about being able to distribute the load across multiple servers, which is something that I, too, planned. They both support adding in customizations (I should hope so!) as I did, but I'm again astounded by the popularity for Python in this.

I've got a personal peeve against Python, which is probably clouding my view of it as the be-all end-all of scripting languages. Though I haven't looked too deeply into it, I'm under the impression that the Python runtime allows for some nice on-the-fly interpretation, which can be seen here on the BigWorld site, in the Kill Striff video near the bottom. That kind of interactivity is exactly what I want to be able to provide; not only having a console on which you can change the running world, but to be able to add, change and remove logic to the running server. If these two projects are using Python, I'm starting to ... worry ... that I might have to look into using it too.

I've mentioned before that I've wanted to use C# for this, because that is my current plan for the implementation language. I don't know what kind of interactive solutions are available for C#, or what kind of Python-on-C# solutions are available. I've also mentioned that it would be an interesting exercise to design a stripped-down scripting language, to help the non-programmers still work with the world. Python is a touch too involved for that, and C# would likely be as well.


Both systems provide clients, which is really beyond the scope of MMORF. While I plan to develop clients alongside the server for testing purposes, I hadn't planned on providing a client framework that would be used -- that's something that I would have left to my "customers" to supply.


The World Editor is something I never considered. I suppose providing a world editor would sure make world building a hell-of-a-lot easier than requiring world builders to use their god client to hand-place every item into the world, using the client's interface. Honestly, I hadn't considered it because the purpose of MMORF is to prove the theory that I could write the system, and never to use the actual system for anything concrete. Or populated.


One thing that I haven't found discussed in either project is the interface between client and server (cluster). That is, is there a separate login server, or does each server also act as a login server? If so, is there any rotation of this, or is that done through round-robin methods at the router? BigWorld talks about "[t]he maximum size depends on the number of machines and the switching fabric of the main switch", so this could be exactly what they intend (unless this "main switch" is something they provide.)

I envision MMORF separating the servers that the users connect to (portals to the servers) from the servers themselves -- from a logical view anyway. That is, to reduce the latency (lag) between the user's machine and the world's first point of contact, we might have these points nearer to the user ("near" being a networking idea, not a physical one) than the world servers themselves. The routing and communication between these portal servers and the world servers would then be separately analyzed and configured for optimal communication internally. Of course, they could be the same machine, for the cost-efficient worlds, but I want to provide the ability to separate them.


I'm not abandoning MMORF yet, but it's becoming less of a "wow" thing now. I still want to know, though, that I can write one myself... whether that ever gets done, we'll have to see.