Friday, November 25, 2005
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.
Monday, June 20, 2005
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.
Monday, June 13, 2005
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...
Sunday, May 01, 2005
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?
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.
Thursday, April 14, 2005
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).
Friday, April 08, 2005
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.
Please, prove that one chatroomer wrong.
Wednesday, March 23, 2005
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
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".
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...
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
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?
Tuesday, March 22, 2005
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.
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.
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
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. *:^)
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
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.
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...
Monday, March 21, 2005
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.
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.
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.
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.
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...
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.
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 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).
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.
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...
Friday, February 25, 2005
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.
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.
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.
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?
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.
Thursday, January 27, 2005
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.
Wednesday, January 12, 2005
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).
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.
Thursday, January 06, 2005
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.