Game Engine Architecture

I've started reading Game Engine Architecture, and the first chapter starts off with a large diagram featuring all of the subcomponents of a typical game engine. It's quite the diagram, and it allowed me to get a feel for the totality of what MMORF will become, and what will be left to client implementation.

Because I'm currently looking at C#/.NET for MMORF, the bottommost layers of the diagram -- Target Hardware, Device Drivers and Operating System -- are all abstracted away from the CLR in which MMORF will run. Whether on Windows or on a Mono-supported platform, these will hopefully not matter to me.

Third-Party SDKs and Middleware

In previous posts I've hemmed and hawed about using these in MMORF, trying to decide whether it's a cop-out to use them instead of developing my own, whether I'd just be reinventing the wheel, whether I have the time to invest in Wheel 2.0, and whether I could do a decent enough job. I still haven't decided for sure, but I'm still leaning towards coding everything myself, with an open mind to dropping in some middleware if it seems prudent. This section also includes a lot of client-side SDKs, such as OpenGL, which I'm much more open to using for any client implementation I do; writing a 3d library would be fun and all, but I know where to draw the line on priorities with my time. Unity, XNA or WebGL will gladly be leveraged in any client implementation beyond a text interface.

The AI, however, is something that I have a real interest in tackling myself, even if other parts of MMORF are eventually dumped onto other SDKs. I've got myself a growing library of game AI books and a growing appetite for coding it. So much so, in fact, that I have to avoid working on that part of MMORF as long as I can to prevent it from consuming too much time.

Platform Independence Layer

This layer, too, is abstracted away by the CLR, so it is "solved" in this respect.

Core Systems

Most of these fall under the .NET library or the C# language itself, so are provided to me. Huzzah.

Resource Manager (and Collision and Physics)

This is largely the realm of the client, dealing with graphics and rendering, but the latter part of this block, including the collision, physics and map resources, is all server-side, and will all be part of MMORF. Collision and physics are large components, ones that will certainly be implemented later in the project, as there are worlds that can implemented without them, and the scripting engine would allow world builders to code these themselves if necessary (as we saw in Metaplace when the built-in collision and physics support wasn't adequate for all cases).

Rendering Engine and Human Interface Devices

These are wholly the realm of the client. I put them together because they pretty much make up what the client is, and apart from the communication their communication to/from the server, are completely separate from the MMORF itself.

Profiling and Debugging Tools

Err, yeah... I have to admit that I'm really bad for this. I'm still an old-school printf() debugger unless it comes down to a timing issue. And profiling is an end-of-project task for me unless performance is so unbearably poor during development that time needs to be taken to improve it for the sake of continued development. Naturally, profiling MMORF will be important once it starts to see use, but in its early days, it just won't matter much.

That's the MMORF engine itself, though;.I *can* see providing tools for profiling the actual framework stats earlier, as the In-Game Menus or Console portion hints at; regardless of how lousy the performance of the actual engine is, knowing where it's spending its time -- running scripts, checking collisions, processing AI, backing up data -- will be an earlier set of profiling tools.

Animation and Audio

Both of these sections fall under the realm of the client. As I develop MMORF, I always keep the idea of the text-only client in mind, and thus look at all of these features from that point-of-view: what's the text-only client's equivalent of animation and audio? Text descriptions of what's going on, whether provided as metatext to the animation and audio data ("the guard rocks against his spear, unaware of your presence" or "the sword clangs loudly off of your shield!") or perhaps as nothing at all, emphasizing why graphical clients have become popular, delivering the image and sound to you implicitly instead of leaving it up to your imagination.

Online Multiplayer/Networking

This book is not specific to (massively) multiplayer games, but is about game engines in general, so approaches the multiplayer angle as an optional component, though one that is admittedly more common. Because of MMORF's whole purpose, this is a required component -- perhaps the defining one -- and is naturally the realm of both the client and server, since that's the whole point of the project.

Gameplay Foundation Systems

This is the core of MMORF. This is the objects in the world and their behaviours, the scripting engine behind the world, the event-handling within the world and between the world's objects. Sure, we need collision and physics on top, and file access and networking on the bottom, but this is the real body of the MMORF system, and probably the most interesting. This is the part I will likely blog about most, because file access and networking aren't exciting, and collision and physics... well, let's hope I get there.

Game Specific Subsystems

This is quite the range of topics, and at first glance, I'd be tempted to split the workload between "client" and "scripting". But part of the point of MMORF is to make the engine generic enough (a Foundation) so that the client doesn't have to have game-specific coding. The top blocks, such as weapons, power-ups, vehicles, etc., are all the realm of the scripts that power the game, and how they are presented to the player should be done in a generic enough way that any client is going to render them as well as any other game world.

Game-Specific Rendering and Game Cameras definitely feel like they fall into the realm of the client, but I think the rendering is just a function of the client's interpretation of the server's presentation of the player's view: if I look in my text client, I get a text description, in 2d I get 2d sprites rendered up to my view range, and in 3d I get nicer looking figures, textured and cropped again based on the player's view range or stats. A game camera may or may not be considered an in-game function; does the fact that I cannot see behind me in my 3d client mean that anything approaching from behind in my text client shouldn't be revealed? The idea of "facing" would be up to the game developer, and if facing wasn't important (as it isn't in most 2d and text-based games) then the 3d player either accepts this disadvantage (as a perk of the lovely rendering of his or her world) or gets indicator arrows, and rear-view mirror, or some alternative client-based device to allow 360 viewing.

And of course, collision/physics and AI once again appear, and again, would be the realm of the server, and specifically the scripting engine, whether as flags ("collision detection ON") or as function calls to be used ("walk to here directly", "walk to here avoiding being seen").


This is only the first chapter, but the rest of the book promises to be interesting. Quite a few of the chapters focus on client-side concerns, which are only secondary to me (for now), but chapter 14, on the Runtime Gameplay Foundation Systems, looks to be very pertinent, and might just be read out-of-order.

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.

If I had just one Wish

For those who follow the gaming industry or the virtual world industry, you've probably heard that Mutable Realms has cancelled the Wish project.

Even though there have been quite a few virtual world projects that have failed in the last year, I was still surprised by Wish. Why? Because it actually made it to Beta (Beta 2, in fact). The other projects that I heard about (and, because of their demise, I have forgotten with the exception of Ultima Online 2) did not even make it that far.

The reasons for Wish's failure aren't clear. Some speculate that it's financing, while others believe that the Wish system just wasn't able to perform as Mutable Realms had hoped -- they called themselves the first ULTRA MMORPG, purporting to support (or be able to support) 10,000 simultaneous users in a single world (without "cheating" with zones, facets, etc.)

I don't know why other projects failed, either, but they were earlier in the lifecycle. Perhaps those others realized earlier that today's hardware couldn't do what they need it to? Perhaps their investors finally realized how expensive it would be? Or perhaps their game just wasn't turning out fun or appealing?

Of these reasons, only the first bothers me. I have no financing for my own engine, except for my own free time, so unless that gets cut off (which it very well could, I suppose), I'm good for "investment". The "fun" or "playability" reason doesn't really apply to me either, for the primary purpose of MMORF is not to make a game (though that's a great secondary purpose), but to make a game engine. This is why the first reason concerns me.

Did Wish fail because they couldn't support 10,000 players as they wanted? Was it because they didn't have the talent, or that hardware can't keep up? Was it their design that was flawed, or could no one do it?

While I haven't set any goals, benchmarks or targets for MMORF yet, I'm sure there will be some reasonable expectation about performance that I'll want to meet. Knowing that Wish has been cancelled, and guessing that it might be because of a lack of performance (Viagra jokes aside), I worry that I might design or code myself into a similar situation, which is of course what I don't want.


Could it have been the playability that sank Wish? I had wanted to be in the Beta (especially because they had specifically targetted Ultima Online players), but I didn't make it in. While my goal isn't to create a game, specifically, my goal is to allow others to make a game on top of my system, which means that the game has to be able to allow the game designer(s) to do everything they need to make the game appealing. This means that any decision I make that might be seen as a "restriction" is something that I'll have to give careful thought to, so as not to make an engine that is lacking.


The other theory I've heard about Wish's demise (and a reason that has been cited for other failed worlds) is "the competition". Specifically for Wish, it has been said that World of Warcraft (WoW) is what made Wish not come true. Apparently the sales of WoW are staggering, and that might have led to investors to bail out of Wish. Or, perhaps the gameplay of WoW was above what Wish had, and thus there was no point in releasing a game that was already "obsolete" in terms of playability, features, and design?

Again, this doesn't concern me that much, because I'm not looking to compete with WoW, or UO, or anyone else. This is for me. However, one thing that will always been on my mind is "can MMORF do this like UO/WoW/EQ does?" Not whether any game built on top of MMORF will do these things, but whether MMORF can support a game that does.

Basically, I want it to be possible for you to write UO on top of MMORF, to write WoW on top of MMORF. Granted, I don't have any experience with most of the "surviving" MMORPGs, so I'll have to learn there, too -- read fansite or strategy sites to know how each game works, what it allows, and to be always asking myself if MMORF could do that too.