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.

Parallel Universes and Design Patterns

I just finished reading the article The Theory of Parallel Game Universes: A Paradigm Shift in Multiplayer Gaming and Game Accessibility, over at Gamasutra. It talks about presenting a game to different players in different ways; that is, providing a mapping of the game experience to those that might have limitations in the way they can interact with the game, be it a physical disability, a skill gap, or a hardware limitation.

The article talked about the idea of a transition function that would take the viewpoint of one player and convert it to that of another, and vice versa. While I'm not specifically looking to design a system (and in this case, it's a client-side problem and not server-side anyway) to work around a player's disabilities, whether reduced motor functions, poor vision or deafness, I believe I have mentioned my intent to implement various levels of client before.


On the grand scale of things, a MMO is a large-scale simulation, running innumerable things at any given time, into which players have an interface, a viewport, through which they can watch and, we hope, interact with the simulation.

On the top end of the scale, we'd expect a lavish 3D environment, with lighting and shading and textures, something taxing the latest-and-greatest video cards. You can look all around you, interact with the world using the mouse as an extension of your arm, and generally feel fully immersed in your surroundings.

For less powerful machines, we might provide a simpler, 2D interface, perhaps with a top-down or isometric point-of-view, in which we can still see all of the scenery, residents and objects of our world, albeit in lesser detail, fewer colors, a from the "front" only. We have this version because the graphics are bitmaps, not rendered meshes, and so aging hardware can still display it with a sense of immediacy, or perhaps because players just prefer this view-from-above (perhaps to avoid motion sickness when playing in a first-person 3D view).

For specialized devices, such as PocketPCs or cellphones, with very limited resolution, and reduced memory, CPU and GPU availability, we can perhaps provide a very low-res 2D- or 3D-view, flipping menus and text information overtop of our graphics to get non-visual information about our world. Without a mouse, we might have a stylus (for our PocketPC) or a simple control button on our cellphone, each with which we must be able to interact with the world as well as well as with the mouse.

And then we have the lowest level of interface, a text-only interface. Whether this is used because of a lack of video card, because of physical disabilities, or because of a preference for the simple, the ability for the world to be described in text, and interacted with from a keyboard can and should exist. In the case of such an interface on a portable device, a menu-driven or shortcut-driven interface might be used, to obviate the need for a keyboard.


I feel that any virtual world should be represented to the client in such a way that any of the above interfaces can be supported. For testing purposes, the text-only interface is by far the easiest to whip up, to interact with, and even to automate. Proof of concept for a world might be implemented in simple, 2D tiled graphics, where the game's content can still be seen in full, if not in full graphical glory. And time permitting, the 3D eye-candy version can eventually be written to make the game what it was truly meant to be for the player.

But how is this done? By separating out the system into parts conducive to this manner of design. In the world of design patterns, this is the Model/View/Controller pattern. The idea is that you separate the software (in this case, our MMO) into these three different "ideas", and keep them separate, providing an interface between the three. The Model is the simulation itself; the world running the physics, holding the database, and communicating with the other two about what's going on. The View is our world's representation on the client, whether a 2D or 3D graphical display or or a bunch of lines of text. The Controller, in this case tied very closely to the View (because they're both in the client), is our source of input from the user to the simulation, through mouse, keyboard, stylus or joystick.

The work for the designer and programmer is to decide what the communication between Model/View and Model/Controller is going to look like -- to design a proper transition function, as talked about in the article. If something moves in the world, we need to tell the View that this has happened, possibly with the path taken, the speed done, the direction the object faced, etc. In the 3D world, the mesh will be animated smoothly on the client; in the 2D world, it may hop from "tile" to "tile", or may "slide" from one to another; and in the text world, a sentential description of the move would be provided.

Likewise, if the player wants to move herself forward a few steps, her Controller might have her hold down the up-arrow key on the keyboard for a second or two, or might use left- or right-click on the terrain in front of them on the screen, or perhaps typing walk forward 3, all of which are translated into a "walk forward" or "walk forward 3 steps" or "walk to here" message to the Model.

The "trick", in the case of the View, is finding out all of the information that needs to be sent from the Model, and then figuring out how to represent it in all View implementations. Likewise, every type of Controller needs to be able to communicate the players' needs, completely, all boiled down to the common "language" that Controllers use to make requests in the Model.

In theory, people should have no advantage or disadvantage given any implementation of View or Controller. That is, no View information should be extra to some or lost to others, and actions in the simulation should not be possible in some Controllers and not others. While it's a given that for speed-dependent simulations, certain interfaces will have an advantage, it should only be based on time and not lack of information or ability. The time it takes to read the description of the monster is certainly longer than visually seeing some 3D monstrosity eating your head, and typing "shoot bug-eyed creature" over and over is going to take longer than right-clicking on the screen a bunch of times... but these are all limitations of the player, not the interface.


Since I've never read Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, I don't know for sure whether my description of Model/View/Controller is the same as they present; what I've talked about above is something I came up with independently. I have obviously heard of design patterns, though, and the book I talked about before, Massively Multiplayer Game Development, makes mention of them, so I've started reading Design Patterns to finally see what the fuss is about. I'm sure that there will be other patterns in there that are intuitively obvious (to me, anyway) like the MVC pattern, but perhaps I'll learn some other useful nuggets that might be applicable to the MMORF project.

Additional reading

I picked up and started reading Massively Multiplayer Game Development and Massively Multiplayer Game Development 2, both edited by Thor Alexander. I'm halfway through the first one, and am quite disappointed that I didn't know about these books before.

Not that I've found a lot that I hadn't known or determined, but it's good to see that others, especially those that actually do this for a living, have hit the same hurdles and come to the same conclusions that I have about various stages in MMO design.


The first section is about game design, which, if you've read previous postings, is something that I say will come much later for me. After all, MMORF is the foundation for building the games, not the act of making the game itself. Still, that doesn't stop the designer side of me considering all sorts of issues (and telling the developer side to make sure functionality is there to solve them).


The second section is about system architecture, with the first two articles titled Building a Massively Multiplayer Game Simulation Framework. Yeah, that's what I thought. There were interesting articles on open-source platforms out there for game development, and really, the whole section almost made me abandon this project.

But again, the point is to see if *I* can do it, not to have one done, so I kept reading and learned a few tidbits here and there.


Section three, which I've just started, is about server-side development. I've only just finished reading the first article, Seamless Servers: The Case For and Against. As my previous posts have indicated, I'm all for the seamless servers, and this article does a good job verbalizing the pros and cons that I had already determined. I did find his conclusion interesting, where he stated "the author's opinion is that seamless servers are not worth the effort involved."

I find that an interesting statement, because to me, the decision is one that would or should cause contention between the game designer and the game developer. I would imagine that, for the most part, game designers would want the world seamless, so their grand dreams are realized in an epic scape of whatever fits the genre. The developer, for reasons mentioned in the article, is likely to push towards instanced or segmented worlds, where events cannot cross over the boundaries, and thus programming required to handle this crossing (again, very well described in the article) can be avoided.

There are reasons, of course, that a developer might want an instanced world; in DDO, the dungeons are instanced so you and your party are allowed to explore without interference from others. Ultima Online added a similar idea with the Mondain's Legacy expansion, where a group leader can "tag" a group of others that are allowed to cross over and fight the end boss with him or her.

But generally, I wouldn't expect that it's up to the developer. With luck, the developer can point out all of the hurdles, and convince the designer that for time reasons, budgetary reasons, and reasons of sanity, the game needs to be designed around the segmented world. And if he can't convince the designer? I guess this is where the producer comes in, telling one side or the other what's going to happen, or how to compromise, or who gets to find a new job.


And of course, that's something that I'm hoping to avoid with MMORF. I don't want to have to tell a designer that they can't have their wide open plains of Saskatchewan in the Colonizing Canada Online game. I suppose that's one advantage to not having any money or backing from anyone to get this done -- I don't yet have a definitive target to develop for.



As for the rest of the book, we've got sections on Client-Side Development, Database Techniques and Game Systems coming up, which all promise to be as interesting as the first half. I haven't cracked open book two, but I'm sure it's going to be as good a read as this one has been.

Developing Online Games

I've just finished reading the above-mentioned book, by Jessica Mulligan and Bridgette Petrovsky.

This book is about the "business" side of online games: the number of people you should have for each job and at which point in the development cycle they should be hired; how you should handle your time; and how much money you'll need to even consider doing something so large.

The authors do a very good job of deterring the casual reader from even considering launching an online world.

But will that stop me? No. Why not? Because that's not what I'm doing (yet). MMORF is a foundation, not a game itself; the goal of this project is to enable people to then go on and develop the online game world that Mulligan and Petrovsky have instilled fear over.

Yes, of course, I do plan on making my own world (for testing out this system, if nothing else). Something that's marketable is a something completely different however. I don't kid myself that I can design a game worthy of massively multi players (as mentioned many times in the book, players compare all future online games to their first one, and I'll admit that I would do the same if designing), nor do I think I have the business acumen to find the funding to start such a venture.

So why did I read this book? Especially when I have others (Bartle's Designing Virtual Worlds for instance), which are at least a little closer to the task at hand?

Because I'm a bad reader. I have over a dozen books that I'm "reading right now", everything from British history to the history of cyberspace to the adventures of Drizzt to the works of Salvador Dali. And I never, ever seem to finish a book. So it's not that I'm NOT reading Bartle's book -- I am, along with many others. Developing Online Games was one of the many others, and it just happened to be the closest one to me when I was reading, okay?

</tirade>

But it's not that the book isn't relevant. Having reasonable Customer Service tools at launch time is something that I might very well have glossed over when designing this framework, but now I know that tools to access internals (with a god client) or just copious, well-organized logs are going to be required, and should be prepared for at the stage I'm at.

I recommend this book to designers, would-be designers, or keeners that just like to follow the industry. Even if the knowledge within doesn't apply to anything you do, it does provide an interested and educated view into the development of online games and the behind-the-scenes events in game companies in general.

A Theory of Fun (?)

As I mentioned before, I've got a small list of reference material that I plan to read or access as I work through this project. One of them is A Theory of Fun for Game Design by Raph Koster.

I got the book almost two weeks ago, and finished reading it almost a week ago. I've wanted to write about it earlier, but... well, I didn't know how.

I suppose you could say that I'm a fan of Koster. He was the Creative Lead on Ultima Online, my favorite game, and he has always seemed personable (in postings on the ultima mailing list) and knowledgeable (on his website). That's why it's hard to say that I was disappointed by this book.

The shortcomings of the book as a production, first: it's a half-height trade paperback, 244 pages. Half-height really cuts that down by half. A drawing on every second page does so again. A somewhat large font perhaps again. So, we've got a book of 30 pages of content. To be fair, some of the drawings convey some useful or enhancing information. So, say 50 pages? I'm glad I didn't pay the cover price.

The content is about fun in games, and I suppose I'm to blame for assuming it meant online games, or video games specifically. Still, what applies to all games, including board games or tic-tac-toe (a frequent theme in the book), should be applicable to all games, right?

I finished the book feeling like I didn't learn anything. I don't feel that I have any better idea on how to make a game fun than I did before. Does that mean that I just knew everything Koster had to say? Or that I just didn't get it?

To be fair, the book is what it claims to be: a theory of fun. Quite theoretical, I'd say, to the point of it really just analyzing the concept, but not necessarily telling you how to use the results.

I'm sorry, Raph. Perhaps I'm not being fair? Perhaps I read it too quickly, and didn't let things sink in? Perhaps it's just beyond me?

Perhaps I'll re-read it in a few months, and give it another try.

Background reading...

Before I dive into this project (as I usually do), I decided that it would be reasonable to do some research into the development of virtual worlds.

Currently, I'm reading Designing Virtual Worlds by Richard A. Bartle. Bartle is usually known as the Father of MUDs, as he's often attributed with creating the first one (though he points out in his book that this isn't so).

I'm almost a third through the book, and it has been interesting reading so far. I kind of see Bartle as the Dr. Phil of virtual world design, in that everything he's saying seems like common sense, but it isn't until he actually spells it out that you know it.

I mean this as a compliment, because the "common sense" of virtual world design isn't anywhere near as obvious as real-world common sense is (thus the "common" part). But none of his discussion seems wild or out-there -- and you realize that it's good to have an old hand guiding you, so you don't make the mistakes of others. "History repeats itself" is very true in virtual world design, both good and bad.

I've also picked up Developing Online Games: An Insider's Guide by Jessica Mulligan and Bridgette Petrovsky, but haven't cracked that book yet. Also ordered and apparently on its way is Theory of Fun for Game Design by Raph Koster. I'm looking forward to this one because Koster was involved (Lead Designer? Producer?) in Ultima Online, which is my jeu du jour.

Additionally, I'm subscribe to the MUD-dev mailing list, but admittedly all the messages get stored in a folder right now for lack of time to read them. This, I expect, will be a great source of information, since it's more "live" than a published book -- though established knowledge is just as good as innovation!

I also frequent the occasional blog that talks about MMORPGs and virtual worlds, though not necessarily from a developmental point-of-view.


With all this reading, will I ever get to designing and writing this engine? Sure, but I want to know that the initial decisions I make are reasonable, and aren't going to make me start over again (and again).