MMORF - MMO Roleplaying Foundation system

Offloading the client

2010-07-07T12:10:00.000-07:00

As I mentioned previously, I've had to start working on a bare-bones client so I have a way to test server development as it goes forth. This was a bit disconcerting, because the goal is the server, not the client, but I may have found a solution!

I currently split my rare programming time between two projects, this one and Windows Phone 7 development. I try to give them equal time, and with this project having the client development requirement, that was resulting in maybe 25% of my coding hours going to MMORF. However, I may have found a way to soon return that to the 50% it deserves, by moving the client development to Windows Phone.

For the next little while, I'll still have to put some effort into this console client, just to have that for quick testing, but for anything more than a text interface, I can certainly justify it as "Windows Phone 7 development" and use my phone development time for it. And if my other phone-related projects suffer because of it, well, I can bitch about it over on that blog.

Protocol

2010-07-01T19:38:00.000-07:00

The whole point of this project, as I may have mentioned before, is to develop the servers, the backend, for the roleplaying framework, not the client. Of course, developing one or more clients is to be expected as I work on the project, because much like you'd expect from a blind painter, it helps to have a visual verification that the result is at all accurate; I could work on the server-side code all I want and HOPE it works, but I'd really want to SEE that it works eventually.

Knowing that, I knew that some day I'd be working on a client -- textbased, 2d, 3d, whatever -- but I never thought it'd be so soon. In fact, I'm actually writing a text-based console client before I get any of the "useful" part of MMORF written: even the server-side code that I'm writing to test the client is just login server stuff right now. Where's the good stuff??

Of course, writing the client means that I've had to address the issue of the protocol between the client and the server, which I've briefly discussed before, but have spent a bit of time thinking about already. Two things are important in a protocol, when all things are said and done: it's efficient, and it's debuggable. The second part can always be done regardless of how the protocol is implemented, but its readability corresponds to how easily it is debugged. Sure, you can write loggers and decoders to translate some binary stream to meaningful words for the developer, but when first developing the system, you're better off making it human-readable to start, and worry about the efficiency later, provided you coded the networking subsystems to handle a complete change to the protocol. This means that all communication is handled through functions that generate the protocol packets via a drop-in system, one which can be replaced without anyone being the wiser. In fact, having the client being able to support every drop-in system you've devised based on its ability to detect what's coming down the pipe means no rewriting later in the development cycle.

When I talk about a human-readable protocol, I typically mean an interchange format such as XML, JSON, YAML or even Metaplace's MetaMarkup. It's something that balances readability by humans and parseability by computers. Myself, I tend to lean towards XML, because it handles hierarchical data very well (both structurally and visually), it copes with escaping characters used by the protocol WITHIN the protocol (something which was a recurring theme with MetaMarkup), and because I've had some experience with it as a network protocol.

The only unfun part of developing a protocol is ... developing a protocol. When you get to the binary level and are trying to squeeze as much data through as possible, THEN it might actually be fun, but at the XML level, it can be tedious coming up with the schema for all of the different packets that are going to fly by.

That's why I was quite pleased to find out that the serialization of C# objects results in: XML! Instead of having to come up with an XML protocol schema, all I have to do is come up with an object schema based on all of the communication needed between client-and-server and server-and-server, then pass these objects through the network and let them pop out as objects that need to be handled. Even better, handlers for these objects can actually be part of the object itself.

It's a pretty slick system. It took a bit of designing to come up with a general server framework, allowing the client to handle various login servers (local (object-based) and remote) and client servers (local and remote), but this is done and mostly implemented. I now have a console client that launches its own local login and client servers (internal objects, not even using a loopback network connection) and can send login packets (or rather, serialized login objects). I had to design none of the protocol, instead letting the .NET Serialization system do it for me, and I had to neither write out nor read in the stream of data, deconstituting or reconstituting the meaning. Instead, I create a Login object, call my LoginServerConnection's Send() function with it, and on the other side the LoginServer sees a Login object pop out, which it may deal with as it pleases.

Just think: I'm almost at the point where I can actually design some of the game server and see it working. Amazing.

World events

2010-06-17T19:59:00.000-07:00

As I slowly gain ground on my not-so-rapid prototype (I can pretty much authenticate and connect, and sit ready to send commands and receive world information), my mind wanders to the meat of the game server, which is vastly more interesting than the boring-but-necessary work of having to write login code.

One of the things that I often think about is the interaction between objects in an MMO, and how the interaction takes place from a code point of view. Though I started to write this post over a week ago, it was a post on a friend's blog that finally made me come back and finish it.

Over five years ago, on this blog, I previously wrote on the idea of how to handle the goings-on in a game world, and how the many objects and the world's rules would deal with them. This was before I learned about Metaplace's extension of Lua with their Trigger functions, or the .NET implementation of Events. As I practice my C#/.NET, and continue to work on MMORF, I realize that my method for dealing with such object interaction is still my preferred one.

I have two examples that I keep in mind when I work out the details of this system, both when I was writing my Metaplace RPG subsystem and now as I work on MMORF. These examples, of course, come from UO, my seminal example of what MMORF should be able to do. The main one is simply picking up an item in the game world.

Attempting to pick up an item in UO can involve a lot more checks than might be otherwise apparent. In no specific order, you need to check: if you're close enough to the object; if the character has something in-hand (not equipped, per se, but already being held/dragged by the mouse cursor); if the object is static, that is, part of the map; if the object is locked down (in someone's house, say); if the character has line-of-sight to the object. I'm likely missing something that UO needs, too, and there could be other checks that a non-UO game might want to make such as "is the object too heavy to be lifted?" (in UO you could move mountains, provided they weren't locked down).

Each of these things are rules of the world. The close-enough check is a variable (it's two tiles in UO). The something in-hand is an oddity in UO, since it's dependent on what can be considered a hidden character slot (the mouse cursor, a "third hand") being full, not either of the character's actual hands. The line-of-sight might be a universal requirement. Because these are all rules that are bolted on based on the design of the game system, the platform needs to support that bolting-on, not hardcoding just distance checks and locked-down checks and the like, but anything a game designer can think of -- you can only pick up this object if you're an elf, if your 12th level, if you have the right device equipped.

Each of these rules would manipulate a "result" object, something at which the framework can look, after everyone has had their say, to determine whether the action should be allowed. Thus, the distance checking rule might verify the user is close enough, and either say "yes, for now" or simply not say "no". The latter is more likely, as picking something up is probably better implemented as allowed-unless-not versus disallowed by default. But just because the distance rulecheck didn't say no doesn't mean that the next rule might not -- oh look, the object is locked down, so THAT rule will say "no", and the action will be prevented.

From my system administration background comes two kinds of permission systems as hinted at above: permissive unless prevented (except when overridden), and not permissive unless allowed (except when overridden). So picking up an item is likely the first case -- you can have it unless the rules say you can't -- but actually connecting to the MMORF game servers is the other way around: you're not allowed on UNLESS you can provide a valid username/password, EXCEPT you'll still be denied if your account has been suspended. The "except" case for picking things up might be the "gamemaster" rule: sure, the object might be too far away or locked down, but I'm a god in this realm, and such little rules don't apply to me. And it's much better to have the "gamemaster" rule as a separate rule that can overrule the "that's too far" rule, instead of having the distance rule say "okay, the character is further than two squares, but he's a gamemaster, so I'll say it's okay". Going this approach would mean that every rule would have to know to check the player's gamemaster status to know how to decide. Instead, having a single gamemaster rule that can overrule is better. It could also be implemented that the world has a function that returns a character's FurthestDistanceCanPickUp(), which the distance rule uses; THAT function might then look to see if the gamemaster flag is set and return "1000"; this would also also allow game worlds where different characters can reach further, because they are playing a race with longer arms, or are reaching with a pole, or reaching with telekinesis. In fact, this is sounding like a much better way to implement such a distance rule, instead of having a single number that a world builder can set. Just because UO has the two-tile reach for everyone doesn't mean the next game will.

Determining that a character CAN pick up an item then leaves the system to worry about what happens if they DO. In UO, it vanishes from the ground or container and goes into this pseudo-inventory slot, and the only thing that is likely to happen is that the character will attempt to drop the item (into his or her backpack, on the ground, on another player), and a whole other set of permission checks will take place. But what about actions that have more consequences than just moving things around? What if picking up the item causes damage to the holder? What if the item's absence from where it was triggers a trap? This starts a whole other line of thinking on the idea of Triggers - that some objects in the world are going to care when any item moves, so a nearby player's screen can update properly, and others when specific items move (moving the idol triggers the fire traps).

The second example I usually refer back to is using an item, but it rehashes a lot of the same ideas on the permission side as picking up an item. It's here where the result of successfully using the item, and the chain of events and rulechecks that take place, can get interesting, specifically (if you know anything about UO) when you go to use a crafting item. There's the obvious "can you reach the item" and "is it your item to use" checks, but then if you are allowed, how about "do you have the skill to use it", "what can you build at your skill level", "what are you going to make", "using what resources", etc. There can be a lot of back and forth with the user as decisions are being made, each question and decision being based on surroundings, inventory, attributes and who knows what else. And after all of the objects who have a say about the choices have said, there's the whole issue of success at crafting the item, based again on attributes, buffs, enchanted tools, magic forges, standing in a pentagram or whatever, each which might have their own say on how successful the character is.

For the most part, anything that the player has their character do is susceptible to modification by the rules, by their environment, by their belongings and by their characteristics, and the MMORF platform needs to be able to accommodate it all.

Time flies when you're hemming and hawing

2010-05-19T12:19:00.000-07:00

Three months since my last post. Yikes. The main reason for this is because about two months ago, Microsoft announced their Windows Phone 7, which has attracted a lot of my meager free time.

On the one hand, WP7 development is done in C# and .NET, which is my target platform for MMORF, so learning C#/.NET is preparing me for both. On the other hand, producing something for the Phone is a lot easier than a mammoth project such as this.

On the one hand, WP7 is backed by either Silverlight or XNA, depending on whether you're making an application or a game, and both provide a front-end method for test clients for MMORF. On the other hand... producing something for the Phone is a lot easier...

MMORF development is appealing because it's a hobby, a challenge. It's something that I think that I can do (given enough time), and it's something that I want to prove to myself that I can do. But WP7 development actually has the potential to make money. In theory.

For the past few weeks, Ultima Online has been rearing its beautiful head, whether in my RSS feeds or mentioned in passing tweets, and as always, UO makes me reminisce and, ultimately, design. Oh yeah, you could do that in UO, and I would code that this way... it has made me very conscious of my neglect on MMORF's part, and has given me a renewed focus on how much time it will get, and WP7 will not. Besides, how much money could I *really* make from developing mobile apps... right? Right?

That being said, I'm aiming to whip up a rapid prototype of a basic backend with static objects and mobiles, and playing around with that. The basics of connectivity, of representation, of execution. It's likely to all get scrubbed in the end, but it's also just as likely to keep me driven and focused.

Game Engine Architecture

2010-02-17T09:34:00.000-08:00

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.

Messaging, transfers and auctions

2010-01-18T07:59:00.000-08:00

My basic verbs for virtual worlds were a suitable set five years ago, when thinking of gameplay and what it can all be boiled down to. Now, however, I've seen one or two of today's MMOs, and as intimated in my last post, they can't just be summed up with the plain ideas of getting around in a virtual world -- they have needs that transcend the world of the character, to the world of the player. Chat is one of those things; it's all find and good to roleplay your characters talking in-world, even if out-of-context, but that still requires proximity to be heard, or some in-game mechanism to reach further, such as Ultima Online's communication crystals. These other features don't necessitate a new server, as the last post discussed, but just some in-game features -- reduced down to verbs, perhaps, -- that allow them to exist in any game developed in MMORF.

messaging

The chat server discussed before is useful for live communication with players in-world, or indeed, if external access is made available (which I think is necessary), then completely external live communication is supported, making it no different than your ICQ/MSN/AIM environments. But what about leaving messages, the in-game equivalent of email? Ultima Online had the idea of bulletin boards that you could leave on your in-game house, Dungeons and Dragons and World of Warcraft have a mailbox with which you can receive messages from friends, strangers, and perhaps just as importantly, from the game world, either in-context or not.

All three examples use an in-game object or person to get these messages, requiring characters to be in certain areas to receive them. This might not be required, however; a game world might break immersion by allowing access to these communications through some pop-up menu, being more communication for the player and not the character. This means not restricting the functionality just to objects and scripted behaviour, but as something that objects interaction OR the client itself can communicate. Indeed, in DDO, there's an icon that appears on the player's HUD that signals mail presence, thus combining the in-world mailbox for the character with the information provided to the player -- the fact that the character "knows" to go check the post office is only a slight break from immersion.

transfers

Transfers are different from a GIVE verb which is a live interaction between two characters. Instead, transfers are a way to transfer between two characters that aren't in proximity. DDO and WoW support mailing objects to others through the post office -- I don't know about WoW, but DDO has a fee system that provides a gold sink, based on the value of the object. Transfers are often used for two "non-standard" purposes -- transferring between a player's characters on the same account, and storing extra items beyond available in-game storage (character inventory, bank slots, housing). Not that these mechanics matter; what matters is that there's a method to transfer in-game objects, securely, to another character in the game, whether through an in-game system or right in the client. The allowed uses for such a system is up to the game designer.

auctions

MMOs are, to a lot of people, all about acquiring virtual goods. Sometimes this is out of necessity, to advance through the game with the best gear, and sometimes it's just for having the best, for having a whole set, or just for having. To facilitate the trading that goes on between characters/players that don't know each other, having a method to post an item for a specified price (or a minimum bid price) in a centralized location. UO did this by allowing players to purchase vendors, which were placed in player housing and handled the storefront of items priced at a set price; DDO and WoW allowed characters to put items into an auction house and hope that someone else wanted them. Again, each of these games uses an in-game concept for handling this offline transfer between characters, though this doesn't have to necessarily be the case - having a web interface into the auction house could be very useful for the player (and who knows, perhaps WoW offers this). Typically this mechanism also provides a goldsink for the game -- the vendors charge a rent, and the auction house takes a cut on the sale and/or a posting fee. This need means that the auction/vendor system needs to go through the game server to allow for the developer to provide the rules for transfer - to add on the fees, to restrict transfer of too-high items or bound items, etc.

In essence, each of these features could be added in-game using scripting and basic verbs such as USE on mailbox objects, or GET/PUT/SAY to a vendor as Ultima Online indeed does. But the idea of these features existing outside of the world, escaping the virtual to include actions that players might take, means to me that they are their own, albeit more complex, verbs of gameplay in today's virtual worlds. And there are more...

Warming up

2010-01-15T22:43:00.000-08:00

As I wait for the new C# 4.0 Nutshell book to arrive, I'm doing more (re)thinking and planning instead of coding. This involves re-reading my old posts, including the one on the servers that would make up the whole system. I wrote that nearly five years ago, so I've still got to decide whether my thinking back then is still reasonable, but I did come up with two other servers that would be useful to have.

chat server

Chatting between players is a core concept to a multiplayer game. But "chat" is a different idea than the talk verb; talking happens at a range from the player's avatar in-world, where chat transcends the virtual world and is instead a meta event. This is for players talking to players, not characters talking to characters.

Dungeons & Dragons Online had a separate chat server -- this was made obvious when the server was down, and the client outright told you so. Ultima Online, after way too long, added chat to the game -- obviously something revealed to be needed, but I've not played UO since it was added, so I'm not sure if it's a separate server or not. Metaplace, too, had added a chat server after a while, helping to connect multitudes of players and developers who would otherwise each be in their own world.

Does this need to be a different server, or should it just be a new verb to a new "room" that spans the "ether" of the whole game world? I think so, because the idea of a separate server allows for non-game-client chat clients to exist; a web-based client or a plugin to poly-IM tools such as Miranda or Trillian could be written to allow players and guild members to chat with friends without having to be running the actual client. Shouldn't they just use some other chat method, separate from the game itself? No, because the whole ICQ-while-playing is an old idea, and is problematic in full-screen games. The communication while in-game needs to be in the client. Also, a game-aware chat system can access game data, allowing lookups of equipment stats, character levels, guild rosters, etc. as part of the chat protocol. This is data that is being exposed more and more by commercial games, allowing players to watch their characters and guilds through webpages or even an API. The idea of an API into the game server's data is a must, of course, for MMORF, and one that I'll have to keep in mind as it's developed, including the chat server's access to it.

patch server

Typically patch servers are used to patch clients, for both the client's logic (rendering, interface, etc.) and the client's assets (art, animations, sounds). This is typically something that happens when the game client starts up; it connects to the patch server, compares its version to the latest, downloads a new executable, or dynamic library, or art file, or data file, or something, and then launches the "real" game client once that's done. This happens in the UO client, the DDO client, and probably every other online game client out there.

Metaplace was a little different; the logic portion of the game client was a Flash program, which was downloaded when you went to the world's site or a site with an embed of it. The patch in this case happened automatically for you. And the game assets were downloaded at each world visit, though your browser could be caching it and not actually downloading. This was required because the same client was being used for myriad worlds, each with assorted sets of assets. This kind of functionality isn't typically needed in a client with a single game target, however, but it COULD be. There's no reason that assets couldn't be streamed as needed, in the background, as the player first logs in. It would allow a game to update itself while running, instead of downtime on the server, and forcing the player to log out to repatch.

The other reason I can see with the pre-patch versus the live patch is that game clients tend to store their assets in large binary files, perhaps for file access reasons, but more likely to help obscure the file format to keep their assets private. On the other hand, assets in Metaplace were just web assets, PNGs and JPGs and MP3s that had to obfuscation. I will certainly be taking the open approach while developing MMORF, allowing for easy and transparent handling of the local version of assets.

I'll soon have to break out the Visio to make some pretty drawings relating all of the different server parts to this project. It all seems clear in my head, but let's see how it looks on paper.

Re-opening windows

2010-01-07T15:25:00.000-08:00

Last month, Metaplace.com, the site that drew me away from the MMORF project, announced their closure. Not of the whole company, mind, but of the portion in which I was an alpha/beta tester for the last two years. I won't get into my thoughts about that here, as I've written some of them elsewhere. Instead, I'll say a bit about what that means for my free time, as spare as it is...

I'm currently planning on reviving the MMORF project. The whole point of MMORF still stands -- to see if I can write an engine that could run an MMO. But more generally, a generic engine that can be used to implement any genre, and style -- the only common thread would be users connecting to a virtual world and interacting with it and others.

This is what Metaplace provided, in a sense; they wrote the backend which MMORF strives to be, with a full interface for others to create their own worlds. This isn't what MMORF was going for, exactly, but it was enough to distract me for two years, to get a feel for the kind of flexibility that would be needed in an engine to support any kind of game someone could come up with. It gave insight into the kinds of APIs that were needed, the protocols a working system might use, and the scripting that would be needed.

Now that I'm thinking back to the MMORF project, the direction has changed; no longer am I looking to be the content developer, but the backend developer. As previous posts here started discuss, the various pieces that one needs to make, basically, a Metaplace-like system, sans the UGC portion. It was never my intent with MMORF to provide easy-to-use tools for the average joe to make their own world; I had always pictured it as something a more advanced designer/programmer would use to create their world, offline and behind the scenes, instead of right there in the same client as one uses to connect and play.

I'm going to go back and read all of my previous posts, now, to see where my thinking was going and where it left off. Let's see where this project takes me now!

Missed the window

2007-11-26T13:38:00.000-08:00

I know, it has been way too quiet. It's hard to pinpoint the exact reason I've been silent here, except to say that I come up with too many projects at once, and of course none get realized...

Lately, in the MMO/virtual world scene, I've been paying a lot of attention to Metaplace, which I'm planning on experimenting with once it becomes opened up. Tools like this, and Multiverse, and BigWorld, and VastPark, really are emphasizing that there is a need for them, and that if I was able to dedicate all of my free time to such an endeavor, it might have seen use.

Time as it is, and life as it goes, the MMORF project is looking unlikely. Yes, the original idea was to see if I could implement all of the pieces myself, and I'd still like to know the answer to that question, but with environments like Metaplace on the horizon, the world designer in me is going to beat out the backend developer for the bit of free time I have. My apologies to those who might have read this blog up to now, expecting a more dramatic end.

That being said, in the next few months this blog might get reworked a little into a discussion on world design, and when Metaplace goes live, perhaps discussion about my contribution to this potentially huge concept.

Edit: I just went back and read the first post:

If this sounds interesting, please stop by every so often. If it looks like this page hasn't changed in a year, then I apologize for taking your time -- I must have been distracted by something else.

Wow, do I know myself or what?

Back in service

2006-11-13T00:01:00.000-08:00

Sorry to all my thousands of readers... I moved a week ago, and only now got the server back up.

Because of the move, work (and when I say work, I mean thought) on MMORF has been minimal, but it should once again pick up as I ease into my new digs.

Parallel Universes and Design Patterns

2006-08-21T11:59:00.000-07:00

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

2006-07-31T13:15:00.000-07:00

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.

DDO = MMO?

2006-03-13T08:04:00.000-08:00

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?

2006-03-01T14:15:00.000-08:00

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.

Not quite dead

2005-11-25T09:23:00.000-08:00

Given the title of the last entry, you'd think I'd abandoned this project. I haven't, but other things have unfortunately taken up a lot of the time that could, would or otherwise should be going to it.

What caused me to post again was not some new revelation or advance in the project, but the fact that I have returned to learning the Ice system mentioned before. Again, this is for a different project, work-related, but as I read about the features, I can't help but think back to MMORF (and the Wish project for which Ice was used). So much of the functionality in Ice is fitting for a MMO, for a multi-server world -- for what I'm trying to do.

By reading the Ice documentation, am I cheating? By seeing the APIs that Ice has available, am I getting an edge on the design of my own system, which would be the core of MMORF?

Luckily, no. I'm proud to say (and you'll have to take my word for it, I suppose) that the features and methodology in Ice are what I had already figured out for myself; that is, the way that objects are handled between servers, and how they are transparently handled by the clients (whether they exist locally or remotely is immaterial).

Perhaps another reason why MMORF has been silent is because I have stopped playing Ultima Online, so I don't have a constant inundation of "I would do that this way" and "I know how to do that" going through my head...

Back to reading, but I'll have time for MMORF soon, I hope.

Putting the MMORF project on Ice?

2005-06-20T13:48:00.000-07:00

Ice - Internet Communications Engine - is a middleware package designed for object handling across a network, designed by ZeroC. A "replacement" for CORBA, and an improvement upon SOAP and XML-RPC, this package looks very impressive indeed.

Perhaps too impressive.

I'm surprised I haven't heard of Ice before now. It turns out that Ice was used (in fact, one of the articles I read implied it was designed for) the MMORPG game Wish (which I have mentioned before).

Ice handles multiple servers and a multitude of clients. It pretty much handles all of the server-server and client-server communication needed for MMORF.

And that's the problem.

As my very first post said, the point of MMORF is to see if I can do it myself. All of it. Every part of a MMO system, from the database storage, to inter-server communication, to running a multi-million object world. If I use Ice as the foundation for communication, I'm almost cheating myself, aren't I?

And thus I have a quandary.

Luckily(?), I need such a system for a work-related project, so I'm going to continue to read about Ice, and see if, at the very least, it's what that project needs.

After that, the question becomes whether I can write my own (as-good) implementation of Ice for MMORF, or whether I break down and use it.

Scripting

2005-06-13T10:36:00.000-07:00

As I've mentioned before, scripting will be a big part of MMORF.

Because MMORF is just a framework, meant to run a world of objects and their movement and their interaction and their attributes, it will have only the basic rules that apply to any implementation of a world that a designer might create.

There will be no concept of ability scores (strength, charisma), or race (human, elf, orc) or even gender on the mobiles; objects will not have a weight, or color, or special attributes (magic powers, laser strength). These are all concepts that belong to the design of a world, but not the physics of the world.

The idea is that someone should be able to take the MMORF engine, slap in a bunch of customized code, and have the world run as they wish. If they want a world of fantasy, then the players are elves, have strength and dexterity and such, pick up magic +5 swords, and cast spells; sci-fi worlds will have aliens, lasers and whatnot.

Designing the core rules of the world should be something major, something that takes some time, and something that doesn't necessarily get changed all too often. These could be rules (scripts/code) that are loaded and applied when the world is started up. Any big changes to this world's universe, and the world might go offline briefly to update these programs.

But just as likely, we would want to add some functionality to the world as it's running. Gamemasters (GMs) might want to add some new behavior to a monster in the world, or create a new item that interacts in a new way with other objects, and would want to do these things without having to shut the world down. Additionally, trusted inhabitants (or players, in a game world) might be allowed to customize a subset of their world, as some MUD systems allow.

Because the customization might not be solely in the hands of the world designer (who, if not a competent programmer, would hopefully have one available), we might want to consider the learning curve for scripting.

Because MMORF will be coded in C# and .NET, the obvious way of adding customization is to allow modules (DLLs) to be written in native C# - it will run fast, and merges seamlessly with the system. The other straightforward alternative is to implement a scripting language (much as the Neverwinter Nights (NWN) game has done), which is then translated by the world as it runs.

The first method is appealing from a programmer's point-of-view, as well for time considerations. C# code will just directly access all the data in the world, which, of course, is both good and bad. Questions I had about C# being interpretable or compilable on-the-fly seem to have been partially answered - the RunUO project, also written in C#/.NET, has their customization done through C#.

The second method, providing a scripting engine, also has its plusses. The scripting language can be (if created from scratch) simple enough for the non-programmers to figure out. The NWN language was very C-like, and many tutorials were written on how to use it. Many, many useful scripts came from the NWN community, but it's not clear if the contributors were already programmers, or if they were regular Joes that could pick up the scripting language and use it effectively. The NWN language was pre-compiled, but only down to a byte-code level (I believe), so it was interpreted by the NWN engine. This kind of system would allow people in-game to type in code and have it happen immediately. Mobiles or objects could be examined in-game and have their code appear in a window, edited, and saved.

Not to say that you can't wing something like this from the "direct code" method. If the .NET framework provides a way to compile code on-the-fly, then the same could be done here. As to loading new versions while the world is "live", I'll have to investigate.

I'm leaning to the C# scripting solution. Its feasibility as a live scripting language will have to be checked. Additionally, because of the learning curve on C#, it might be desirable to have a beginner scripting language that can just be translated to C# (and then compiled); this scripting language could be used directly by the non-programmer world designer, or in-game for simple tasks. If the language is kept simple enough, mapping it to C# should be easy, and then that can be passed on and compiled with the scripter none-the-wiser that they just "wrote" C# code.

As for an API to the MMORF internals that the scripting language might use? That's for another time...

Michael George Thomas Turner 1944 - 2005

2005-05-01T17:39:00.000-07:00

May you rest in peace. You were loved and will be greatly missed.

Developing Online Games

2005-05-01T17:11:00.000-07:00

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.

Triggers and events

2005-04-14T07:52:00.000-07:00

While thinking about the scripting language to use (a topic for another day), the idea of event-handling and triggers came to mind. Whatever language I choose to use or write should be able to support them, because I feel that events are a big part of a virtual world.

The best example is speech. A character walks up to the banker and says, "I'd like to access my bank box please." Or he walks onto a magic circle and says a certain word, finding himself teleported to another part of the world. Both of these examples are from Ultima Online, but I'm sure every virtual world has some case of this. Maybe not speech, exactly, but some way for an NPC or object to react to something a character does.

The issue is how to implement it. There are two ways that I can see: each object (which includes PCs and NPCs) has a youJustHeard() function, which is passed a reference to the speaker, and the text spoken; or each speaker has a youJustSaid() function, which takes the text spoken.

In the first case, every object in the world has a listener function. There are really two ways to deal with this: each object, upon creation, must register itself as a listener, to let the world know that it might be interested in things that are said in the world; or whenever something is spoken, the world looks around the speaker to get a list of all the objects within range, and "tells" each of them what was said.

If the world has to check for nearby listeners every time anything is spoken, it should be obvious that there is going to be a lot of this searching. When characters start gabbing in-game, every table, door, dog and character within a given distance is going to be told, whether or not they want to know. In this case, we better hope that we have one hell of an optimized way to get a list of objects within a certain area.

With the registration method, the world would be able to reduce the number of objects that it has to look through, because only objects that can listen are registered. Again, we would still want this to be very optimized, since every character will be in this list, as will many NPCs and probably some inanimate objects.

Both of these methods of listening seem to have a lot of overhead for every word said.

Taking the other approach, it's the responsibility of the speaker to let everyone know what was said. Instead of relying on the server to do all the figuring for finding listeners, the logic for that could be part of the speaker's youJustSaid() script, which would ask the system for a list of things within range (something that seems to be inescapable), and then the speaker's script would call each of the listener's youJustHeard() functions.

At first glance, this seems to be less effective than letting the server do it directly, because the same work is being done (finding a list of listeners, calling each of their functions), but now it's (most likely) being done in an interpreter, which isn't as optimal as a compiled server core. And while that's probably true, having the logic take place in a dynamic spot -- that is, something that the game designer can change -- allows for more flexibility whenever something is spoken.

For instance, perhaps our world allows spells, and instead of clicking an icon or scroll to cast, you simply say the words out loud. As well as having every listener's youJustHeard() being called, we would also want the character to start waving his or her hands, and spell effects to happen, and an apple to appear. Or a certain class of character might be able to open doors with but a word; the doors by themselves have no logic to listen for such things (though it could of course be added), but the speaker's script could not only inform all listeners of the words, but also call the door's use() function. Having the speech handler "local" to the speaker also allows them to control who hears them - they might have a slider that defines how loud they speak (whisper, murmur, talk, yell), or they might be able to speak to one person specifically (telepathy).

All of these things can, of course, be done at the listener's side instead of the speaker's side, and is just as accessible to the world designer, for he or she controls the scripts for everything in the world. And there's no reason that you can't mix the two; the generic "character speaker" script may know how to open doors or cast spells when the character speaks, but there's no need to put the logic for word-activated teleporters in every character when the teleporter itself can have that functionality coded into its listener script. But with this approach, we're saying that it's still the speaker's responsibility to let the teleporter know that something is said -- and what it does with that is up to it.

A third possibility, which I'm not going to entertain, is a "speech parser", which looks at everything everyone says and decides how to handle it. If a sentence contains the word "bank", then search for any bankers nearby and tell them. If one of the four magic words in the game are spoken, check the character is in one of the few places that it matters.

This is very limiting. It basically hard-codes these trigger words, requiring a list of words and their effectual area or audience. The parser might also be responsible for making the effect happen, instead of calling a function on some other object -- again, very awkward.

So, speaker or listener. A decision needs to be made... but not so fast. Triggering and events based on speech is only one possibility. What about the shopkeeper that sees you steal something? What about the citizen that sees you attack another? What about the guard that sees you discard items on the ground - littering!

Speech is only one of the generic actions that we might want world objects to react to. NPCs and monsters should likely defend themselves when you attack them; guards might arrest you if you move somewhere you shouldn't; and the shopkeeper certainly shouldn't sit idly while you get his inventory without paying.

But again, who should handle this? If my character attacks a monster, then it's pretty easy to let that monster (and its beingAttackedBy() function) know this. But what about onlookers? Maybe another monster will step in if you attack its buddy, or a nearby NPC will come to aid you.

If I drop an item on the ground, do I tell every object about this put action I just did, or do I broadcast a "I just put X at Y" message and let the "listeners" do what they will with that knowledge (fined for littering, beggars run over to pick it up). Note that depending on the game interface, this might also "push" a look action to some clients so they now know the item's there, or the world has a constant look going. But it's different to see an object suddenly appear on the ground, and to know that character X put it there. Or at least it should be.

I don't think I've convinced myself either way on who should take care of these messages about the events in the world. I'm hoping as I continue to mull over it that I can find an example that definitively says that one method is better than the other (and I equally hope I don't find two examples that contradict).

Never trust the client

2005-04-08T07:35:00.000-07:00

A few days ago, in the #ddo IRC channel on SorceryNet, the topic of packet sniffers came up, with respect to the upcoming Dungeons & Dragons Online game.

The issue goes back to the more general rule, "never trust the client", or "The client is in the hands of the enemy". The fact is that no matter how much you try to hide or obfuscate the operation of your client, there are people out there that will figure it out, and they will write a cheat program for your users to use.

The solution, then, is "never trust the client" - that is, anything your client says to do, you verify as "correct" or possible. Instead of taking orders from the client, you take suggestions. And client trust doesn't even have to be in communication, where you are listening to what the client is saying. You can't even trust the client to perform in a commanded way, such as display something it should or hide something it shouldn't. The earliest case I had first heard of (as a player in the community) was in Ultima Online, where the game servers would tell the clients to darken the screen, because it was nighttime or because the player was in a dark dungeon. It was meant to provide atmosphere, but also, I presume, to add more challenge to adventuring in the darkness. I don't know how long it took, but individuals had figured out the packets being passed back and forth between the server and client, had isolated the one that said "make the screen dark", and stripped it out (or modified it to say "make the screen bright").

In the case of the conversation in #ddo, there were the issues of being able to see traps that you hadn't detected yet, or knowing of the presence of monsters that were hiding in the shadows. I, of course, stated flat out that this kind of information shouldn't be in the hands of the client until the player is supposed to know about these. This started a flurry of responses, from "yeah, but every other MMO has had the problem" to "it would be too laggy if you didn't send this stuff beforehand".

Now, I'm one of the first to grit my teeth when I'm reading gaming forums and see people say "they should add feature X. It's really easy, they just need to ..." Invariably, these people are not programmers, and if they are, they're not good ones, and if they are good, then they still don't have the knowledge to say how easy it is to add a feature to someone else's codebase. Almost as bad are people who seem to know what *can't* be done. This is, however, what the discussion became, me included.

One party insisted that game developers are going to keep doing it, even though (I assured them that) experienced developers know about these previous mistakes in this industry, and would know better. Another party insisted that they couldn't get away from sending early information to the client because of lag problems (which is a little better argument than "they'll do it because all games have it").

I disagree with them both. One, at least, is a programmer. And while I find many of the vocal "easy" people on forums try claiming programming skill as well, I usually call bollocks on their abilities, and chalk them up as know-it-alls that know nothing. This chatroom member, though, I'm willing to give credit as a capable programmer, and thus I just disagree with him.

First of all, the "there's always something that a packet sniffer can find" argument is just crap. Yes, it might be that every game so far has had some client vulnerability, but to argue that every game in the future must therefore have the same is ludicrous. The client is just an interface to the information send by and to the server. It should never have extra information that isn't displayed. Enough of that argument.

But the point about lag is valid. The example went something like "if a dozen goblins were sneaking up on you, and suddenly stepped out of the shadows, the sudden surge of data from the server to the client would cause the client to lag and the player to die (or be at a disadvantage)". Fair enough, that might happen. But, this brings up a few points:

Is the protocol so "bulky" that the information about these dozen goblins (or whatever information suddenly because available) will cause such a discernable lag? If so, can the protocol be optimized? There's a reason why MMOs aren't "twitch" games -- because of the latency of the Internet (discussed previously) and disparate speeds of players' computers - is the game too twitchy if this sudden information is a problem?
Does all the information have to be sent immediately? Can the server not say "draw some shadowy figures - I'll let you know what they are in a sec"? Are full texture descriptions being sent up, as one of my debaters suggested, instead of them being pre-existing on the client, or send a little later?
Can the game be designed so that any information sent early (and thus hacked) is of insignificant value? In the case of the darkness if UO, I think it might have been changed so "dark" wasn't really so bad, and it was moved from a game-affecting feature (and thus an advantage to the cheaters) to solely a mood-lighting, visual effect.

The point of the original speaker was valid, in that a game can be ruined if certain kinds of information are available to some players and not others. And that's my point as well I suppose: to release a game that has any of this information available is foolish. Any developer who does this should look at this information and say, "since some people will have it, everyone should to make it fair." And that line of logic, in the case of the sneaking goblins, would mean that they're sneaking no longer. Is that a problem? Perhaps, if your game really depended on the idea of monsters sneaking up on players. But I insist it would be a bigger problem if there were players upon whom the monsters could not sneak, because that will affect the community instead of the gameplay, and that's a much bigger problem.Myself, I'm giving the Turbine developers the benefit of the doubt. They made Asheron's Call and Asheron's Call 2 (at least, I'm assuming some of the DDO developers were also developers on those projects), and thus have made some of the mistakes that the pioneers did. If not, then I will also assume that they've read the same materials I have, which expound on the problem of trusting the client at all, and thus I hope and believe that the DDO developers will not make this mistake.

Please, prove that one chatroomer wrong.

What's in a world, continued

2005-03-23T13:15:00.000-08:00

Continuing on yesterday's discussion...

get/put

Finally the virtual world can go from the just a verbally-interactive world to a "physically" interactive one. Objects are now involved.

But why put group them together, when my list had them separate? I kept hemming and hawing about this, because

they are almost always two distinct commands, but
they are just aliases for a "moveobject" command, yet
"get" implies to the character, where "put" can be to many places, though
a moveobject could handle both of these cases, however
"get" usually requires a lot more "permission" checks, where "put" does not, and

The list goes on. So, while I list them as two separate commands (as they would likely be in any text -based game), I group them here for discussion (as they are much more similar in a graphical game, where both actions are mouse-dragging).In a textual world, "get" implies into a backpack, or some form of inventory. If you can see the object in a text world, then you can probably reach it (by the rules of the world). Since most text worlds are based on rooms, it is assumed that you can move around the room freely to perform other actions, such as getting to the object in question. Movement, in the case, doesn't "count". "Put" in a simple text world would possibly be implemented as a "drop" command, and the floor of each room is a big list of items, in no particular order (or, maybe the order they were dropped there). More complex worlds might support putting onto something, or putting into something. You could even support putting in different locations (though in a textual world, this might be thought of as "throw" into an adjacent room.)Graphical worlds, on the other hand, would usually support into, onto and the rest. The idea of range of reach is most likely introduced, since graphical worlds tend to provide a lot more information from "look" than their textual counterparts. Ultima Online, for instance, allows you to "get" an item up to two squares away, and only allows you to "put" an item the same distance. Here, though, they really are the same thing -- drag the item from ground/corpse/container into backpack, or the other way around.Graphical worlds can also allow you to move things around on the ground, from one spot to another; this is just an abbreviated form of get and put in succession. Indeed, in Ultima Online, having an item "in your hand" (that is, being dragged by the cursor), counts against the character as weight, but does not exist in any place that any other character can see (for instance, a rogue snooping in that character's backpack cannot see it there). You can even walk around with this item "gotten" in this sense, in your hand (though you are then prevented from using your cursor to interact with the rest of the world, which makes sense).This brings up another point, which you might have already questioned: what about inventory? In MUDs, you usually have an "inventory", "inv" or "i" command to get a list. In graphical worlds, it's either a window that can be popped up or a container you use (next section). While "get" might be thought of as a simple verb "get item", worlds can support more complex uses ("get item into backpack"). But yes, this just becomes "move item into backpack", because at what point are you still getting, and what point are you putting?And what of equipping? This is just a special form of putting, with the destination being a "slot" on the character. It might be referred to as "wear" and "remove" instead of "put" and "get", and yes, again these could be generalized as "moveobject".Even trading between characters can be seen as an act of putting an object "to" them; this might require some interaction on their part - whether or not they want to accept the item offered, or a way to have them trade something in return, where both items are traded at the same time, fairly. In this case, the "put" might actually put the item into a "trade window", which is also displayed to the other player, who can them "put" their own items in. This trade window (really a container that exists briefly during this interchange), may not allow any "get" actions at all, so players can't grab an item from it; perhaps the transaction has to be completed through another method, at which point the trade window does its own "put" into each player's inventory. This is how it's done in Ultima Online; I never had the opportunity to trade items in World of Warcraft, to see how they do it.We won't, however, go so far as to say that swinging a sword is "put sword in monster" or firing an arrow is "put arrow in Joe".useUp to now, talking, moving and moving objects has allowed some interaction in our virtual world. We make changes to it from communication (we change what we know), from motion (as we move around), and object interaction (changing the location, and thus the state of the world's objects). Once we allow objects to have a useable property, however, we allow a lot more interaction because we now have a way to change the state of objects, which is a more subtle change compared to moving their physical location, but fleshes out the reality in our world. Having a lantern in a virtual world is nice, and being able to move it around is great and all, but if we can use the lantern to turn it on and off, then it becomes more than a word or a bitmap on the screen -- it becomes a useful object.Some items might just have a single use, such as the lantern. "Use lantern", depending on it's current state, will either turn it off or on; "use apple" might eat it (and we might have a synonym of "eat" for certain objects).Using an item might often require specifying a target. "Use sword" might prompt "on what?", whereas that could be avoided with "use sword on tree". Using an item might be more complex: "use hammer" might provide a list of things you can use the hammer for, and you would then need to choose. Indeed, one of the choices might be "repair", in which case you would then have to supply yet more information for the "use" to finally happen.This is where the graphical worlds have a lot more power than their textual counterparts. We can use the hammer (which is there on the screen in my inventory, or in my hand, by double-clicking it, or clicking it for a context menu, or some other similar action. A window can appear to offer the choices of actions to perform with the hammer. If that choice (repair) requires more information, I can be told to click on the item to be repaired.Doing this in a text world is possible, of course, but not nearly as fluidly as in with a mouse in a graphical world. If I type "use hammer", a dozen or so lines might appear offering my choice of hammer actions. I might select "6" (repair), at which point it might provide another list of items to attempt to repair (and, if we're lucky, the game engine was nice enough to prune the list down to just the items that are repairable (or even those that need repair), instead of every item within view.Alternately, the text world, if equipped with a suitable parser, might support "use hammer to repair chair", or provide a "repair" synonym (which might look around for a suitable object that supports the "repair" action.)Some actions might be very simple; "use door" (or an alias, "open door"), just changes the state of the door object, and affects other actions (such as moving through the doorway). Others might be more complex than just changing an object's state; using a crystal ball might call up a mysterious random image; using a teleporter pad will change the location property of the character itself; using a healing potion changes a different property of the character, their health; and using a lightning wand might cause visual effects for others, might reduce the number of uses in the wand, might drain some mana from the user, and might cause damage to one or more objects (including other characters and NPCs).Other actions in virtual worlds can be mapped to the "use" command. In worlds with magic, characters might have an innate ability to cast spells; while there may not be an actual object in their inventory (it might be on a spell list window, or gump), they still want to "use" a fireball (at something). In this case, the object could be abstracted (in that it kind of exists in the game, but can't be picked up or put down); a synonym "cast fireball" might know to "use special pseudoobject 5". In Ultima Online, players have a spellbook, which is a special container with the spells within; here the object really does exist, and can be used much like any other (though the spell cannot be removed from this special container).Games with skills and feats, or other inherent abilities, can also treat these as pseudo-objects that are used. A character with an affinity for taming animals may not have an "animal taming bauble" in their backpack, but if this non-physical object is accessible through a menu, an icon or a macro, then it can still be treated as an object to "use taming on horse". The character has no way to try and "put taming on floor", because the "put" command just don't know where that "taming" object is.Some might say that this is a stretch, that these inherent abilities should be treated differently. I admit that treating them as any other object can stretch the imagination from a design point of view, but it makes engine design a lot easier. If these pseudo-objects (like animal taming) can have scripts attached to them just as "real" objects (such as a lantern), then game designers can have just a much logic and flexibility behind one as the other. The lantern script might simply flick the lantern on and off, no questions asked, or it might check lantern for a number of uses, before it fails to ever light again.Or even go so far as to require fuel, and checks an internal property for the amount of fuel left. Likewise, our animal taming skill, as a pseudo-object that characters always "have", can determine whether you're of the right class to use the skill at all (if such restrictions exist in the world), whether the target is sensible ("you cannot tame the chef!") or if the skill level is too low ("you have no chance of taming that dragon"). Just because these pseudo-objects can't be picked up or put down, doesn't mean that they can't exist. Just because they're not in the character's backpack doesn't mean that they can't be in some other "container" that the character always carries -- their skills list, their paperdoll, or whatever.As a matter of fact, Ultima Online recently added an item called a soulstone, which lets a player transfer a skill from one character to another. The one character takes their 56 points in Animal Taming and "puts" it "into" the soulstone; another character (on the same account) can then go to the soulstone and "gets" the skill into their own skill list. While it's not necessary that Ultima Online treats their skills as pseudo-objects in the game, it can be seen that if they were, these soulstones would be a very simple thing to implement.It's true, I've lumped a lot of actions (the majority of what might make up a game world) under the "use" command. But that's the way I see virtual worlds; besides the obvious talking, walking and moving things around, the rest of the experience is through using the contents of the world. It could even, maybe, be argued that combat could just be "use sword at monster", but we'll not take that last step...attackCombat in virtual worlds really does require its own command, in my opinion. You can try to think of it as putting" someone to the sword, or "using" a blade on someone, but combat is usually more involved in virtual worlds than just repeated using of an item upon someone.Many combat systems put you in a "combat mode". Often, these modes can "take over", in that your swings and parries are then done automatically, a dance of mathematical functions and randomness displayed on the screen. Interaction from the user might take on an assistant role, such as healing, activating special attacks, or backing off - these are just cases of "use" and "move" while in combat mode. Other games might require the user to make each swing, and in this case combat could be represented as multiple "use sword on target" commands.Combat mechanisms can, for a lot of people, define the world. That is, for virtual worlds in which combat plays a large part (and I'd say this is the majority of them), the combat style is where a lot of thought and design is put in.This means that very little of it should be in the engine -- that it should be all customizable using the scripting language. But what does the engine have to supply? What, beyond the previous commands discussed (and the inclusion of a scripting language), is needed?Perhaps nothing. Perhaps when I type "attack Joe" or "use sword on Joe", the attack or use command launches a "combat script", which first determines if that's possible (are you close enough? Do the rules allow it? Does Joe have to accept this as a duel?), and then if the attack is allowed, informs Joe (maybe just pops up a message, maybe plays battle music on his client, maybe launches another script (if Joe is an NPC)).So should "attack target" just be an alias for "use on target"? Maybe, but the item in hand might also have other "uses", and is it right to put have to attach a combat script to every item with which someone might club another? Instead, we could attach the combat script to the character (or NPC) itself, and have the attack command launch that. It seems ... messy to include combat-handling code for a skinning knife in the same script where we ask which fish you wish to fillet with it.

And really, that's what it all comes down to. For every command, the outcome is going to be decided by the game designer, and thus the scripts that are written for the game, and not really for the engine itself. The engine should be able to support passing these commands back and forth, but it is not up to the game engine to decide whether or not you can move north: the move script should check that the terrain is blocked or not, and decide for itself. The rules (embodied in the scripts) decide if you're allowed to pick up that item (because it's close enough, because it's not secured down, because it's not too heavy), and the engine just calls the item's "you'reBeingGotten()" function (or, more likely, calls the character's get() function, which would at some point call the isItOkayYou'reBeingGottenByMe() function).

So as a designer for a virtual world framework, I need to support the communication of these basic commands, and the ability to tie their appearances to attached scripts. That's it. But am I coding myself into a corner if I hard-code the set of commands that are allowed? Sure, I might think I've encompassed to whole of virtual world goings-on, but what if I've missed one? What if something new comes to the realm of the virtual experience?

What's in a world?

2005-03-22T15:05:00.000-08:00

This project aims to ultimately reduce all MMOs down to their bare essentials, to their common ground.

I posit that all MMOs are the same; they just differ in graphics, text, and play interface. Sacrilege, some might cry, but it's all in the presentation, I say.

So what's in a world? What can you do? Here's a list off the top of my head; I'm sure I could find a similar list in literature about virtual worlds if I just went looking.

LOOK (around, at this item, at that mobile)
SAY (or whisper, or yell, or private-message)
EMOTE (bow, yawn, laugh, cry...)
MOVE ("go north", "go to room 5", "run this way")
GET (this or that item)
PUT (this item)
USE (this item)
ATTACK (that target)

These are in order of "difficulty" or "complexity", in that simple worlds might just implement the first few, but more complex worlds would have the later commands. Let's look at each in detail.

look

This command would get information about your location, about objects nearby, or about other characters or NPCs in the area. You could implement a virtual world that has nothing but this command, though it would be very limiting indeed.

In a text world (MUD), you might use "look", "look [at] Joe" or "look [at] sword". As you enter a room, you might automatically be given the results of a "look" command, or perhaps that only happens the first time you enter a given room. Some systems will give you the full description the first time, and an abbreviated version the next; typing the "look" command at any time after that might re-iterate the full description. Looking at an object or mobile will return information about it, though perhaps not all - I might be able to see how many uses are left on my magic wand, but other people can only see that it's a magic wand. I might see Joe, that he's a human barbarian, and that he's got a shield, but his guildmates might also get to see his guild title, and the amount of stamina he has left. Looking can have very different results based on the looker.

In a graphical world, there is no explicit "look" command - the graphics are there to constantly show you what you see. Some games (World of Warcraft) might not only show you the terrain, and the objects, and the mobiles nearby, but the names of them above their heads. Ultima Online, on the other hand, shows you the names as they enter your view, but they vanish after a few moments -- an "all names" macro can be set up so you can "look" once more at these specifics.

Looking at an object in a graphical world might involve passing the cursor overtop it, prompting a "tooltip" to appear with the object's information, it might require clicking once on an object; or it might require bringing up a context menu for the object, and viewing the properties that way. In the case of mobiles, one might be able to bring up a separate window that continually updates with the "look" information about it, so you could watch the health of a monster as you fought it, or the health of an ally as he was being attacked. This information might also be constantly present (as I believe it is in WoW) as a statbar above or below the mobile.

As for implementation, the server might send a certain set of information to the client in anticipation of the user asking to look at this or that object. Alternately, the server may send nothing up until the client (by way of the user) explicitly asks for it; this could also allow every object to have a "look" script attached to it, so a character that looks at the crystal ball is teleported inside, or anyone that looks in the mirror is paralyzed by their true reflection.

Interestingly, you *can* implement a world without this command; I would say that a chatroom would almost be such a world, except most chatrooms have a "user list", and that itself is a "look" in the room.

say

Communication is probably the most important part of a virtual world; it's what makes it a community.

A world could, I suppose, function without any way of characters to communicate directly to each other -- they could run around, attack each other, pick things up, and perhaps try to spell messages on the ground with items, but it wouldn't be very immersive if basic communication is missing. And, in my opinion, that communication should be immersive. In Ultima Online, a player types in the game window, and their words appear above their heads; the conversation appears where the player is looking, and associating the text with the character is simple. In World of Warcraft, however, there was a text window on the bottom of the game window in which all communication took place.

To know if someone in front of you was talking to you, you would have to look in the main screen to see the name of the character that walked up, and then watch the chat window to see if any messages came in with that name. I did not like this method of communication at all.

Granted, the WoW method is useable across vast game distances, where the UO method is not. In UO, you must be on the same screen to communicate with people. There is another method in-game in UO that allows a similar chat window to the one in WoW, and it has the limitation of having to "enter" a room to chat with people you probably know. WoW has the idea of rooms, too; your guild, public channels, and probably "area" rooms too.

Talking can also include "tells" or "whispers", where communication is directly to one individual, perhaps in the same vicinity, perhaps not. In virtual worlds where everyone has a unique name, you can attempt to "/tell Joe" and be guaranteed to get the Joe you know, not a stranger. In games that do not prevent name collisions (Ultima Online), this mechanism isn't available, though there is a way to whisper to a person nearby, by being within a couple of spaces of them and starting your conversation with a "; ".

Because speaking in world is a textual affair, the keyboard is involved whether the client is a text-only one or a graphical one. Whether communication happens directly (just start typing) or requires a prefix ("/tell ", "say ") or requires typing into a separate window, is up to the designer of the client, not necessarily the game.

But is communication solely text? With Teamspeak and Ventrillo, two popular voice-chatting programs over the internet, more and more players are able to communicate with each other without using in-game mechanisms, and certainly more quickly than having to type. This can lead to an eerie feeling from observers, as they watch a whole guild of characters swarm into an area, fight for a bit, then leave, all without a single word to each other. They just seem to move as a hive mind. While being able to speak directly to the "character" right beside you is great for immersion for the players involved, it can prevent immersion for those nearby.

So perhaps, in these days of high-speed connectivity, a game could support this natively (as many games are starting to do), and audio can be passed back and forth from client to server and to other "nearby" clients. This would just be a version of the "say" command that has a binary stream of digitized voice instead of a string of characters. Players could hold down a key on the keyboard, or the mouse, if they wish to speak to their guild (a party chat) versus "out loud" in the game.

Of course, profanity, slurs and the like are less likely to be screened in this scenario, but that's not the concern of the designer of the game framework -- that's up to the administrators. *:^)

emote

This should, perhaps, be a sub-command of say, though with graphical worlds, the outcome can be quite different than the spoken word.

Emotes are ways to portray emotions or actions. Early chatrooms used "<laugh>" or "*grins*" or "*:^)" to demonstrate that the user is laughing, grinning or smiling. Acronyms appeared (LOL, ROFL, etc.) to denote more complex feelings and actions. Internet Relay Chat (IRC) supports a "/me " command, where "/me grins" will say "* Crwth grins" to others in the room. This is usually highlighted in a different color, and is preceded with special characters (an asterisk and a space) to let others in the room know the difference between an emote and a typed message.

Textual worlds might have a generic command (like /me or /emote), and might also have shortcuts for many of the popular ones (/grin, /laugh, etc.) They might allow the character to use a macro to insert their name in a different part of the action ("/emote you made $$ cry!"), making it more powerful than the IRC "/me" command which always puts the user's name first. In all cases, the other characters in range will be told in words what the other character is doing.

Graphical worlds might support something similar. In Ultima Online, text preceded with ": " will be surrounded by asterisks and possibly shown in a different color, above the character's head (": grins" will show "*grins*"). While a person could just as well type the asterisks to the same affect, the use of a different color for emotes allows those viewing the emote to tell the difference.

Additionally, graphical worlds allow for animation, so common emotes can not just be told, but seen. Ultima Online has support for a few, including bowing, so there is no need to use ": bows", when your character can actually be seen doing it. World of Warcraft has many as well, and perhaps too many; for some reason, the designers thought it would be amusing to allow some characters to make a train-like motion with their arms while their character says "chooga chooga chooga chooga! WOO WOO!" And in the beta test, at least, the players were just as amused. I suppose that beats having "*choochoo*" above your head?

Emotes are, of course, not necessary. In the early chatroom days, as mentioned, people parenthesized their actions well enough, and email still has this type of emote within. But for those who want to be immersed in their world, these are an easy enough addition to any game, and with graphical clients, they're even more so.

move

Before I sorted the list above, this was the first command I typed in. You would think that movement is the fundamental action in a virtual world. How else do you get around the virtual world??

But, from the simplest example, a chatroom, you don't. Okay, perhaps that's not quite true, as even in IRC you can "/join" a different room, and this is just like moving from one to another (or, being in two places at once -- not something you do in most MUDs!)

Text-only worlds typically have a "go" command, such as "go north". This is usually also available as the shorter "north", and most likely "n". Newer ones might support the special keycodes of the arrow keys on the keyboard, so the up-arrow can send a "go north" command automatically. As mentioned above, this usually returns the result of a "look" command explicitly, as you're now in a new location (provided there wasn't a wall). Veterans of a virtual world may not need (and may wish to remove) the explicit "look", because they have a map of the world in their head. The old game InFiNiTy CoMpLeX didn't have such a device, but the software on which it ran (MajorBBS), supported the CTRL-O character as a "flush anything you were going to send me" code, so you could send ten or twenty movement commands rapidly, and instead of waiting for ten to twenty room descriptions to appear on the screen (over a nice, slow modem), you could send this "abort" command and you would suddenly be 20 rooms away, ready to give more commands.

Early multiline bulletin board systems, such as MajorBBS, had their chatrooms as well, in which you could only be one at a time. The command was probably something like "/room" (it's been a long time) and this could be seen as an absolute movement, where "go north" is a relative movement.

I would say that relative movement is the norm, and absolute movement not. You could, of course, support "go to blacksmith", where the game then tries to figure out the best path from where you are to the blacksmith, but this is just shorthand for "go north; go north; go west; go west; go north". The point of a virtual world, at least one with a large expanse, is probably to have things in the spaces between A and B, and thus the world designer is most likely to want the character to traverse that space.

Note that there can be in-game methods of performing absolute movement, but these are not actual "absolute movement" commands. Ultima Online has moongates in which you can step to transport yourself around to one of the other moongates scattered across the land. It also allows mages to "mark" a runestone and use it at another time to "recall" back the spot on which it was marked. Instant transportation, true, but not as a simple command -- it's objects in the game that do this for them.

Graphical worlds, and their close tie to the mouse, don't require these obvious commands. Sure, early graphical games, before the mouse (early Ultima or any other Computer Role Playing Games (CRPGs)) still had the arrow keys or something similar to move them about on the colorful screen. But some modern clients now let you click on the screen to tell your character to walk there, or you hold down a mouse button and your character walks in the direction of your cursor. Other graphical games have stayed with the keyboard interface for movement, leaving the mouse available for every other action (coming up in the list).

Variations on movement my be supported in the world as well. Running might be possible, but then your character most likely has some sort of stamina attribute which will wear down as you continue to do so. Worlds might also support "crawl", "sneak", "tiptoe" or some other form of movement, either for roleplaying purposes or actual in-game effect.

The rest of the list will be continued tomorrow...

Servers revisited

2005-03-21T15:17:00.000-08:00

Following on the last post, I'll talk about the "work" involved in each portion. We'll do them backwards, as the design of some can influence others.

World servers

Basically a database. We need to be able to add (INSERT), remove (DELETE), find (SELECT) and change (UPDATE) the object records. These objects would have many properties, and would most likely have to support a wide variety of properties, so a schema would have to be flexible (or not required). As to whether or not this is simply implemented as an SQL database, or as some sort of SOAP server, still needs to be visited, but the world server should be written in such a way that it has no knowledge of the world itself, and thus the same setup could be used from one world to the next (though the data within might not transfer between). There should be no "getSword()" or "getAlienStats()" specific to the protocol for the world server. Simple "getObject()" "createObject()" etc.

Compute servers

These, for the most part, are script engines. They run multiple scripts (written in a language I haven't begun to figure out), all of which interact with the objects in the world. These might range from creating new objects (a flower sprouts), refreshing objects (the mine produces 20 more ore now), spawning encounters (orc ambush, bandit raid, elephant stampede). They might be watching when PCs approach, might be set to timers, or set to randomly act. They might listen to PCs, in the case of NPCs. They might react to an NPC being attacked.

The scripts, and thus the compute servers, will communicate with: compute servers, either itself or others, to let other objects know that something is happening to them (NPC X is attacking NPC Y, the volcano just exploded and poured lava onto that flower, etc.); world server, to get/set/add/remove objects; and the client servers, to inform them of changes within their clients' view (monsters just appeared, you now see a field of carrots, it's raining).

The compute servers, therefore, should also have no "knowledge" of the world; they should just run scripts, all of the same language. This scripting language does the same thing in a fantasy world as it would in a futuristic world, as it would in a historical world: at time X a monster Y will appear in region Z; if NPC A sees a creature of type B, it will run away. The values of X, Y, etc. are specific to the world, but that is up to the script, not the compute server. In the end, the compute server acts on behalf of the many scripts it's running, and thus speaks the generic protocol of "getObject()" etc. to the world server, and "showObject()" etc. to the client server. Therefore, a compute server should be usable from one world to the next, much as the world server is, though it will likely be loaded with different scripts.

Client servers

Here we get a bit different. The client server is largely responsible for enforcing the rules of the world. It has to decide whether or not the commands from the client are valid (never trust the client!) as well as if the commands are successful. Can the character pick that item up? Can they use that object? It also has to relay in-game events back to the client, though this is largely a communicative role, as we trust the results of what the compute server does.

Does this require the client server to be world-specific? Or is it possible to abstract all the rules into a set of numbers, or perhaps formulate them into a few dynamic libraries that are plugged in? Or even write them in the same scripting language in which the rest of the world is run? Should these rules be moved, then, into the compute server instead, and just leave the client server's role as a trusted version of the client itself?

The more I think about it, this is the way it should be. If a player tries to use an object, that object's script should run on the compute server, and it will decide whether that's allowed, whether the character is close enough, etc. This way, world-specific rules are handled by the scripts.

So is there a need for a client server? Yes, because we still need a sanity checker; something that can determine if the requests coming from the client are "well formed". Are they sending commands too fast? Did they somehow say "eat the chair" even though the client is designed to not allow that action (and thus the user must have forged a packet, or hacked the client)? Did they try to wear a monster on their head?

While a lot of these things could also be handled in the scripts, there will be other things that aren't going to be definable in the scripting language. Maybe. Until world design actually starts (and client design, too), this is an open question, as is how generic the client server can be written for a specific world.

Login server

This can probably be done very generically, as all worlds most likely need a way to login, might need a way to choose the world they want to connect to, need a way to choose from a possible list of characters to play (or, to accept character creation from the client). With the exception of character creation, this is all very generic to any world.

Character creation can either happen through the login server (as a series of communications between the client and, perhaps, the client server), or could be done fully on the client (though verified by the client server). This leaves out any world-specific names, classes, or numbers from the login server. It's just a vessel for authenticated connectivity between a client and their world.

Client

Though not a server, we might as well discuss it here. While it might seem that a client will be very world-specific, I don't think it has to be so. As long as the client engine (text, 2d, 2.5d, 3d) supports external resource files, the same client can run the fantasy world as it can the futuristic one. Looking at the files for Ultima Online, for instance, you could change the majority of it into a completely different world just by editing them (with a lot of time to redraw every item, monster and tile in a different setting). The only thing remaining would be the text labels and messages that are received from the server.

The client is all about the interface; how to see what's going on, and how to influence the goings-on. It's all about "walk here", "pick this up", "attack that", "say this to her". Nothing world-specific. The same client, if done right, will just access a different set of data files to get its graphics, it's themed interface (skill lists, gump graphics, etc.) but all games boil down to the same actions (though how the client performs these actions is what can make or break the game.

All the above basically shows my motivation for this project: that I should be able to write a foundation on which a variety of games can be "plugged" into. Players would then download different resources (graphics, sound), and the designers would design new worlds (in the form of the scripts that run on the compute servers). And these, really, are a separate project, though I might just talk about them here anyway...

Servers

2005-03-21T10:18:00.000-08:00

I've been giving thought to what kind of servers I want to see in this engine, lately. The reason for so many servers is to allow the world to be (infinitely) expandable, limited only by the available hardware (and not the speed of that hardware).

Some games (Ultima Online), split their world into different parts, having a server run each part of the world. These splits are static (same for every Ultima shard) and noticeable by the players: the client "skips" a little when you cross a server boundary; NPCs (until recently, it seems) couldn't cross them; and information across the boundary was incomplete (PCs/NPCs would "echo" their location on the other side). Everquest, from what I hear, has things even more blatant - you actually cross into a new zone, where the screen blanks/blinks/loads and you're in a new area, and nothing but players can cross this boundary (and it's not seamless).

I want to avoid these problems. They break immersion; when you play a massively-multiplayer game, or are in a virtual world, you want it to be a world, not a bunch of disjointed rooms or areas. Additionally, while the technical reason for having multiple servers is most likely to distribute load for many players, these methods fail if all the players get together in one area (for an in-game event, for example). Optimally, then, I'd like to have a system where, given enough resources (read: money), one could just keep adding machines to a world, and allow it to use the available hardware to share out the work. No fixed boundaries - they could be moved around, either at server-setup time, or maybe dynamically?

This is what I've come up with for now. It might change, as I might decide more servers are needed, or that, perhaps, some are not. If I had some sort of chart-drawing program, I'd post a picture, but for now, I hope I can describe the doodle I have in front of me well enough to make it understood.

Login servers

These servers are the only servers exposed to the outside world. They are connected to by the client, and are the gateway for all commands from the client to the virtual world. These servers do authentication, character creation, and perhaps account management. They provide the list of worlds (if there are more than one), and communicate further in the "chain" to the client server.

You can have a single login server (if your virtual world is small), or you can have multiple ones; in the case of more than one, there would probably be a proxy at the "front" of them all to distribute the client connections evenly amongst all the login servers. A client would connect to the one login server and stay connected to it for the life of their session. Also, the client server that the login server connects to would remain the same for the life of the client's session.

The number of login servers would be a function of how many (expected) users the worlds have (connected at any one time). More can be easily added, as only the proxy would need to know to add it to its list of possible choices. The login server needs to have fast throughput, as it's funneling commands to and from the client, but wouldn't need much in the way of actual processing power, or storage.

Client servers

Client servers can be thought of as clients, in that they do everything on behalf of the player, if only we could trust them not to cheat. At this point, we believe they are who they say they are (authenticated). In the client server, we would verify commands from the player (too many commands sent at once, etc.), and decide whether or not these commands were valid (permission to pick that up, close enough to pick it up, etc.) A client server can talk to more than one compute server at once, depending on how they're implemented, and possibly the world server.

You can have a single client server (if your virtual world is small), or you can have multiple ones; as with the login server, you would probably have a proxy for the client servers so the connections between the login servers and the client servers are shared evenly to distribute load. Multiple login servers can connect to a single client server, so they client server acts as multiple players. The client server could be on the same machine as the login server; that is, they could be two separate processes running on the same hardware, communicating through IPC (or TCP/IP loopback). They could, too, be the same process, though this prevents scaling.

The number of client servers would be a function of how many (expected) users the world has (connected at any one time). Where the login servers had to account for every player on every world, client servers just need to account for players on a single world. More client servers could be added, and the proxy would just need to be configured to know about them. The client server would need to have fast throughput, as it's funneling commands much as the login server is, as well as decent processing power, as it might have to do some sanity checks on the data received from the client (by way of the login server).

Compute servers

These are the core processors of the virtual world. They move NPCs, they trigger events, and they handle player actions. Really, they run scripts for the most part, and communicate with the world server.

You can have a single compute server (if your virtual world is small, or you can have multiple ones. They might be partitioned so one (or more) run the NPCs, another (group) for triggered events (spawn of monsters and resources), another (group) for handling client interaction, etc. Or, one (or more) might handle area A of the world, another (group) area B, and so on. Compute servers might also communicate with each other, to let one know that an object has moved between areas. In this way, the compute server acts as a client server, "requesting" that this object be allowed to step here or be placed there. The compute server, too, could be on the same machine as the client server (and the login server), if the world is small enough, each running as a different process. This could speed communication between them, again using IPC, local TCP/IP, etc.

The number of compute servers would depend on the complexity of the world; how large, how many events happen at any given time, how many triggers are waiting to be run, how many NPCs are meandering, etc. Adding another compute server would probably require bringing the world down to reconfigure which one handles which tasks, whereas login servers and client servers could probably be added live (where their proxies were just "refreshed" with the new server's information). While it's possible to design the compute servers so they, too, could be added dynamically, "live", that would require a lot of extra work. Indeed, allowing the compute servers to change their workload on-the-fly would be optimal, but a much bigger coding task.

World servers

This is basically the world database. It knows about every object, and every property about them. It backs up the data, it provides the data to the client servers, it changes the data on behalf of the client servers. It, most importantly, locks the data when two client servers are trying to affect the same object at the same time. It is nothing but a specialized database. Maybe even not that special... could be just mySQL, Oracle, or something similar.

You would likely have just one world server. While it could be implemented on any number of machines, perhaps for redundancy, perhaps to share the load (player information there, NPC information there, item information here), but the point-of-view to the compute servers would be of just one central database of information about the world. Whatever the internals of the world server, it would be its responsibility to keep the data sane: to never "lose" an object, to never allow duplication of an object (duping), etc. The world server, could, as before, be on the same hardware as the compute server (and the client server, and the login server...) if the world is small enough. Communication could then be improved in a world that's small enough to allow one physical machine to handle all these processes, but of course a world that small may not need such performance. It's the large-scale worlds which require multiple machines that also require efficient communication between them.

To be continued...

Lag

2005-02-25T14:01:00.000-08:00

I've been giving a lot of thought to the problem of lag in MMOs lately. Part of the reason, of course, is that I still play one, and thus experience it, but also because it seems to be quite a large problem that plagues developers. I haven't read anything about the issue, so I'm probably rehashing the old and restating the obvious...

There are, as I see it, a few different issues that all get lumped under the same title of "lag". "Lag", by definition, is to "fail to keep pace". Lag is "experienced" when the action fails to keep pace with a player's commands; when a player fails to keep pace with another player; and when game time fails to keep pace with realtime.

The server

Lag on the server is an example of game time failing to keep up with real time. Players get used to being able to move this distance in this amount of real time, and because the server is so "lagged", they aren't. This usually happens when there is so much action happening on a specific server (for worlds that run multiple servers per world). In-game events, such as a city invasion by hundreds of MOBs, leads to a lot of AI churning away at the server, and an unusually high concentration of players in one spot, fending them off. Also, unsanctioned events can lead to more of a load on a server than developers might expect. The fault: aging hardware, unrealistic computing requirements, underestimation of popularity... mostly things in the developer's realm.

The client

As MMOs get more and more complex, and more and more 3D, the video card is getting taxed to the limit. While this problem will never rear its head in a text-based MUD, graphics are becoming more and more involved, and the creation of them is being done on the client more and more. From environmental textures and effects, to world objects that rotate, flicker and swing, to the numerous MOBs and players that run by with their armor glinting in ten sources of light, the days of static graphics are going. Well, maybe not going, but are falling by the wayside. Here the fault can be prescribed 50/50: users might need to keep up with their state-of-the-art hardware, or developers might be expecting too much of their userbase.

And inbetween...

The biggest culprit of them all -- the Internet. How many miles of cable and fibre do the bits of information between client and server go through? How many pieces of hardware (routers) have to shunt it this way and that? What quality is the medium, and how quick the messenger? This is the biggest bugbear, because it's out of the hands of everyone involved. Neither players nor developers can choose which path their packets should take. Sure, the player can move to a better ISP, or the company can sit on a thicker backbone, but no backbone will be perfect for everyone, and some places still have more hops than desired to get from A to B.

Until the internet is completely pervasive across the globe, and routing technology because near-instantaneous and universally-installed thusly, this will be a problem for the developers to worry about. You need to

Make it impossible for two people to become out-of-sync
Make it so players don't notice if they become out-of-sync
Make it so it doesn't matter if they become out-of-sync

By "out-of-sync", I mean our second definition of lag above, where one layer fails to keep pace with another (and in this case, a player could include a MOB).

Make it impossible for two people to become out-of-sync

Force instructions from the player and events from the server to happen based on a "tick" from some clock which keeps track of time. The length of a tick would be the maximum latency of all the players connected to the game. Everyone is forced to play at the speed of the slowest player, in what basically becomes a turn-based game with a timer per turn. Everyone has X seconds to figure out what they're doing this "turn", with the slowest player having the least amount of time to act (because he or she spent most of their turn sending their last action and waiting for results). Doesn't make for much of a game...

Make it so players don't notice if they become out-of-sync

Support on-going commands ("walk north") that will take place on the server, even if the player isn't able to continually send the command. If the server receives a "stop" command a little too late (because it walked them a bit further), then "snap" them back the where they think they should be. This can lead to other players seeing the lagging player hop back a few steps or continue going in the same direction too much (which seems to be what you see in World of Warcraft); or, the player's client, which has been smoothly drawing the action that it's hoping and assuming is happening will suddenly "rubberband" the player back to reality - that is, the spot that he or she is really standing in (now that the client has gotten new information). This is what you see if Ultima Online.

Make it so it doesn't matter if they become out-of-sync

Design the game so it's less of a "twitch" game, where fast reflexes are required to play. Ultima Online PvP used to be all about who had the fastest connection (once the combatants all knew the "best" methods). With one expansion, it changed so that your items were more important than your strategy, thus allowing the server to decide the winner, even if one of the participants couldn't keep up as well as the other. It didn't remove the need for skill in combat, but it helped reduce the effects of differing connectivity between players.

PvM is a bit different. MOBs are designed with their AI as-is, so they don't have different tactics. To make monster X challenging to a 13 level wizard, it has these skills, these stats, these items. But challenging to what level of lag? You want the guy playing down the street with the 5ms latency to have to back off once or twice to heal himself, but does that make it too hard for the woman playing across the continent with the local ISP with bad copper lines underground? Do you make that same monster easier, so the lagged player can still back off in time, thus making it very easy for the low-lag player -- too easy, for the reward?

Or can combat be made even less "twitch" dependant, so a lagged player can decide early on that they're outmatched and thus escape, while there's no benefit to a character of the same strength with a good connection? Do we boil it down to

You have chosen to attack monster X. Do you wish to proceed?
> YES
You have died! / You have vanquished your foe!

where the same result is going to happen to any player, whether their internet connection tells them immediately or half a second later?

Combat, whether PvP, PvM or PvE (versus the environment, such as jumping onto the swaying bridge), is where most of the problems occur. Role-playing is still effective even if your dialog is half a second behind the others -- not everyone's a professional typist! Shopping in-game, wandering the lands, and interacting with NPCs are all things that can happen with leisure. Combat is where it's going to be most noticeable, because that's where the consequence of lag is going to be the most dire: character death, usually.

So the fault for this kind of lag? No fault. But, the developers are the ones that might be able to do something about it.

But that's only half of the problem with the lag between client and server. In addition to the delay between client and server for moving the information, there's also the volume of information.

In Ultima Online, player houses can have items locked down and viewable by passers-by. This means that as a player walks through an area, information about item type and location from many objects are being sent to that player's client. The more items on-screen, the more data being sent. The faster they're moving (or, in this case, trying to move), the more items are coming on screen, and thus even more data. Some houses would be so "decorated" that a noticeable delay would occur as information about hundreds of items was suddenly shoved towards the client. There was even a case years ago where you could make a "black hole" in the game, where if you got too close to a stack of items (a very, very numerous stack), your client would crash. Whether that was from an inability to cope with the number of items, or just too much network data, I don't know. Probably the former, but can you imagine the latter?

In an old text MUD, InFiNiTy CoMpLeX, you could, with the right weapon, take out 15-16 enemies in one shot (it was a rocket launcher). This, I suspect, caused nearly all the different kinds of lag: the server had to handle the firing of the weapon, the damage dealt to numerous MOBs, and their deaths (which included giving experience and broadcasting the event to everyone in the complex) - this was all on a single machine that was running the rest of the BBS on which the game was hosted; the amount of text that had to be send to every client added up to hundreds of bytes, which was significant at 2400 baud; and the sheer number of characters every player received upon this event took some time to display on their slow, 8086 DOS machine (if they were lucky).

Fault: Developers, I suppose: it's up to them to cut down on the size and number of packets being sent back and forth.

Of course, I supply no hard solutions to these problems yet -- I'm still learning. But it's a start, at least, that I know these problems are out there, and that I'm going to have to work around them, if not try to quash them completely.

A Theory of Fun (?)

2005-01-27T09:48:00.000-08:00

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...

2005-01-12T13:30:00.000-08:00

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).

If I had just one Wish

2005-01-12T13:05:00.000-08:00

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.

Introduction

2005-01-06T14:24:00.000-08:00

Howdy...

This weblog was set up to give me a sounding board for my own ideas (and those of others, I suppose) for designing a MMORPG system.

The five Ws:

Who? My name's Wayne Pearson. I've got a Computer Science degree from the University of Calgary, and have been programming for over 23 years. My interests in computing are wide, from the cool to the dull.
What? The system will be a few separate projects, actually. There will be a backbone server (the foundation) that handles objects generically, but has no idea about the rules of the RPG that will be placed atop it; the rules (and the ability to create and change them) is another part of the project -- I want to be able to run a fantasy world, a sci-fi universe or a wild-west town all on the same base; and the client, which is how people interact with the world, be it through a text interface, 2D, 2-1/2D, 3D, or neural implants.
When? When I have time. This is a project that gets a lot of "mind time" when I'm doing things that give me time to daydream (exercising, driving, surgery). There's no timeline for when any part of this will be done. It may very well go the same route as many other ideas over the years, and never see even this much mention in print.
Where? Right here. This weblog will be my diary or journal for what I'm thinking about, what I've decided, and what I might have actually implemented. The main site will have links to code and software if that ever exists. And there's even a place where I can be contacted if you've stumbled in here.
Why? Why write a(nother) MMORPG? For the challenge, mainly. I'm not looking to compete with Ultima Online, Everquest, Star Wars Galaxies or World of Warcraft. I want to see if I can write those games myself. I'm a UO player myself, and as I play, I find myself thinking, "I know how I'd do that" or "I bet they have a such-and-such system to allow this to work this way". I want to prove (or disprove) that I can write a system like this. This is why the When? above is so vague -- those companies have whole groups, doing it as a full-time job. I have my spare time (and as just mentioned, it can be filled with Ultima Online).

If this sounds interesting, please stop by every so often. If it looks like this page hasn't changed in a year, then I apologize for taking your time -- I must have been distracted by something else.