What's in a world, continued

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

use

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

attack

Combat 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?

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

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

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