I just finished reading the article The Theory of Parallel Game Universes: A Paradigm Shift in Multiplayer Gaming and Game Accessibility, over at Gamasutra. It talks about presenting a game to different players in different ways; that is, providing a mapping of the game experience to those that might have limitations in the way they can interact with the game, be it a physical disability, a skill gap, or a hardware limitation.
The article talked about the idea of a transition function that would take the viewpoint of one player and convert it to that of another, and vice versa. While I'm not specifically looking to design a system (and in this case, it's a client-side problem and not server-side anyway) to work around a player's disabilities, whether reduced motor functions, poor vision or deafness, I believe I have mentioned my intent to implement various levels of client before.
On the grand scale of things, a MMO is a large-scale simulation, running innumerable things at any given time, into which players have an interface, a viewport, through which they can watch and, we hope, interact with the simulation.
On the top end of the scale, we'd expect a lavish 3D environment, with lighting and shading and textures, something taxing the latest-and-greatest video cards. You can look all around you, interact with the world using the mouse as an extension of your arm, and generally feel fully immersed in your surroundings.
For less powerful machines, we might provide a simpler, 2D interface, perhaps with a top-down or isometric point-of-view, in which we can still see all of the scenery, residents and objects of our world, albeit in lesser detail, fewer colors, a from the "front" only. We have this version because the graphics are bitmaps, not rendered meshes, and so aging hardware can still display it with a sense of immediacy, or perhaps because players just prefer this view-from-above (perhaps to avoid motion sickness when playing in a first-person 3D view).
For specialized devices, such as PocketPCs or cellphones, with very limited resolution, and reduced memory, CPU and GPU availability, we can perhaps provide a very low-res 2D- or 3D-view, flipping menus and text information overtop of our graphics to get non-visual information about our world. Without a mouse, we might have a stylus (for our PocketPC) or a simple control button on our cellphone, each with which we must be able to interact with the world as well as well as with the mouse.
And then we have the lowest level of interface, a text-only interface. Whether this is used because of a lack of video card, because of physical disabilities, or because of a preference for the simple, the ability for the world to be described in text, and interacted with from a keyboard can and should exist. In the case of such an interface on a portable device, a menu-driven or shortcut-driven interface might be used, to obviate the need for a keyboard.
I feel that any virtual world should be represented to the client in such a way that any of the above interfaces can be supported. For testing purposes, the text-only interface is by far the easiest to whip up, to interact with, and even to automate. Proof of concept for a world might be implemented in simple, 2D tiled graphics, where the game's content can still be seen in full, if not in full graphical glory. And time permitting, the 3D eye-candy version can eventually be written to make the game what it was truly meant to be for the player.
But how is this done? By separating out the system into parts conducive to this manner of design. In the world of design patterns, this is the Model/View/Controller pattern. The idea is that you separate the software (in this case, our MMO) into these three different "ideas", and keep them separate, providing an interface between the three. The Model is the simulation itself; the world running the physics, holding the database, and communicating with the other two about what's going on. The View is our world's representation on the client, whether a 2D or 3D graphical display or or a bunch of lines of text. The Controller, in this case tied very closely to the View (because they're both in the client), is our source of input from the user to the simulation, through mouse, keyboard, stylus or joystick.
The work for the designer and programmer is to decide what the communication between Model/View and Model/Controller is going to look like -- to design a proper transition function, as talked about in the article. If something moves in the world, we need to tell the View that this has happened, possibly with the path taken, the speed done, the direction the object faced, etc. In the 3D world, the mesh will be animated smoothly on the client; in the 2D world, it may hop from "tile" to "tile", or may "slide" from one to another; and in the text world, a sentential description of the move would be provided.
Likewise, if the player wants to move herself forward a few steps, her Controller might have her hold down the up-arrow key on the keyboard for a second or two, or might use left- or right-click on the terrain in front of them on the screen, or perhaps typing walk forward 3, all of which are translated into a "walk forward" or "walk forward 3 steps" or "walk to here" message to the Model.
The "trick", in the case of the View, is finding out all of the information that needs to be sent from the Model, and then figuring out how to represent it in all View implementations. Likewise, every type of Controller needs to be able to communicate the players' needs, completely, all boiled down to the common "language" that Controllers use to make requests in the Model.
In theory, people should have no advantage or disadvantage given any implementation of View or Controller. That is, no View information should be extra to some or lost to others, and actions in the simulation should not be possible in some Controllers and not others. While it's a given that for speed-dependent simulations, certain interfaces will have an advantage, it should only be based on time and not lack of information or ability. The time it takes to read the description of the monster is certainly longer than visually seeing some 3D monstrosity eating your head, and typing "shoot bug-eyed creature" over and over is going to take longer than right-clicking on the screen a bunch of times... but these are all limitations of the player, not the interface.
Since I've never read Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, I don't know for sure whether my description of Model/View/Controller is the same as they present; what I've talked about above is something I came up with independently. I have obviously heard of design patterns, though, and the book I talked about before, Massively Multiplayer Game Development, makes mention of them, so I've started reading Design Patterns to finally see what the fuss is about. I'm sure that there will be other patterns in there that are intuitively obvious (to me, anyway) like the MVC pattern, but perhaps I'll learn some other useful nuggets that might be applicable to the MMORF project.
Monday, August 21, 2006
Monday, July 31, 2006
Additional reading
I picked up and started reading Massively Multiplayer Game Development and Massively Multiplayer Game Development 2, both edited by Thor Alexander. I'm halfway through the first one, and am quite disappointed that I didn't know about these books before.
Not that I've found a lot that I hadn't known or determined, but it's good to see that others, especially those that actually do this for a living, have hit the same hurdles and come to the same conclusions that I have about various stages in MMO design.
The first section is about game design, which, if you've read previous postings, is something that I say will come much later for me. After all, MMORF is the foundation for building the games, not the act of making the game itself. Still, that doesn't stop the designer side of me considering all sorts of issues (and telling the developer side to make sure functionality is there to solve them).
The second section is about system architecture, with the first two articles titled Building a Massively Multiplayer Game Simulation Framework. Yeah, that's what I thought. There were interesting articles on open-source platforms out there for game development, and really, the whole section almost made me abandon this project.
But again, the point is to see if *I* can do it, not to have one done, so I kept reading and learned a few tidbits here and there.
Section three, which I've just started, is about server-side development. I've only just finished reading the first article, Seamless Servers: The Case For and Against. As my previous posts have indicated, I'm all for the seamless servers, and this article does a good job verbalizing the pros and cons that I had already determined. I did find his conclusion interesting, where he stated "the author's opinion is that seamless servers are not worth the effort involved."
I find that an interesting statement, because to me, the decision is one that would or should cause contention between the game designer and the game developer. I would imagine that, for the most part, game designers would want the world seamless, so their grand dreams are realized in an epic scape of whatever fits the genre. The developer, for reasons mentioned in the article, is likely to push towards instanced or segmented worlds, where events cannot cross over the boundaries, and thus programming required to handle this crossing (again, very well described in the article) can be avoided.
There are reasons, of course, that a developer might want an instanced world; in DDO, the dungeons are instanced so you and your party are allowed to explore without interference from others. Ultima Online added a similar idea with the Mondain's Legacy expansion, where a group leader can "tag" a group of others that are allowed to cross over and fight the end boss with him or her.
But generally, I wouldn't expect that it's up to the developer. With luck, the developer can point out all of the hurdles, and convince the designer that for time reasons, budgetary reasons, and reasons of sanity, the game needs to be designed around the segmented world. And if he can't convince the designer? I guess this is where the producer comes in, telling one side or the other what's going to happen, or how to compromise, or who gets to find a new job.
And of course, that's something that I'm hoping to avoid with MMORF. I don't want to have to tell a designer that they can't have their wide open plains of Saskatchewan in the Colonizing Canada Online game. I suppose that's one advantage to not having any money or backing from anyone to get this done -- I don't yet have a definitive target to develop for.
As for the rest of the book, we've got sections on Client-Side Development, Database Techniques and Game Systems coming up, which all promise to be as interesting as the first half. I haven't cracked open book two, but I'm sure it's going to be as good a read as this one has been.
Not that I've found a lot that I hadn't known or determined, but it's good to see that others, especially those that actually do this for a living, have hit the same hurdles and come to the same conclusions that I have about various stages in MMO design.
The first section is about game design, which, if you've read previous postings, is something that I say will come much later for me. After all, MMORF is the foundation for building the games, not the act of making the game itself. Still, that doesn't stop the designer side of me considering all sorts of issues (and telling the developer side to make sure functionality is there to solve them).
The second section is about system architecture, with the first two articles titled Building a Massively Multiplayer Game Simulation Framework. Yeah, that's what I thought. There were interesting articles on open-source platforms out there for game development, and really, the whole section almost made me abandon this project.
But again, the point is to see if *I* can do it, not to have one done, so I kept reading and learned a few tidbits here and there.
Section three, which I've just started, is about server-side development. I've only just finished reading the first article, Seamless Servers: The Case For and Against. As my previous posts have indicated, I'm all for the seamless servers, and this article does a good job verbalizing the pros and cons that I had already determined. I did find his conclusion interesting, where he stated "the author's opinion is that seamless servers are not worth the effort involved."
I find that an interesting statement, because to me, the decision is one that would or should cause contention between the game designer and the game developer. I would imagine that, for the most part, game designers would want the world seamless, so their grand dreams are realized in an epic scape of whatever fits the genre. The developer, for reasons mentioned in the article, is likely to push towards instanced or segmented worlds, where events cannot cross over the boundaries, and thus programming required to handle this crossing (again, very well described in the article) can be avoided.
There are reasons, of course, that a developer might want an instanced world; in DDO, the dungeons are instanced so you and your party are allowed to explore without interference from others. Ultima Online added a similar idea with the Mondain's Legacy expansion, where a group leader can "tag" a group of others that are allowed to cross over and fight the end boss with him or her.
But generally, I wouldn't expect that it's up to the developer. With luck, the developer can point out all of the hurdles, and convince the designer that for time reasons, budgetary reasons, and reasons of sanity, the game needs to be designed around the segmented world. And if he can't convince the designer? I guess this is where the producer comes in, telling one side or the other what's going to happen, or how to compromise, or who gets to find a new job.
And of course, that's something that I'm hoping to avoid with MMORF. I don't want to have to tell a designer that they can't have their wide open plains of Saskatchewan in the Colonizing Canada Online game. I suppose that's one advantage to not having any money or backing from anyone to get this done -- I don't yet have a definitive target to develop for.
As for the rest of the book, we've got sections on Client-Side Development, Database Techniques and Game Systems coming up, which all promise to be as interesting as the first half. I haven't cracked open book two, but I'm sure it's going to be as good a read as this one has been.
Monday, March 13, 2006
DDO = MMO?
I started playing Dungeons and Dragons Online: Stormreach (DDO) a few weeks ago. I've been looking forward to this for a while, as I'm a big fan of the D&D franchise, and felt it would make a fine concept for a virtual world.
Before the game's release, there was a lot of talk on the forums about how the game was going to be strongly instanced -- that is, that adventures would be isolated to a party of players (which is limited to six), and their adventure would be separate from another party that happened to be doing the same task. This is an idea that many games are now using, to prevent griefers (players that just wish to annoy other players) and to better handle server resources.
The rest of the world, I was to understand, was not instanced, so if you weren't on an adventure, you could mingle with the other people in the world. This is partially true; you can certainly mingle with others (in the taverns, on the street, or at the various trainers or quest-givers), but even the outside world is instanced -- there are four different "The Harbor" areas, and which one you end up in is based on the load in them all.
Now the game does supply a fiction-breaking method to hop between these four instances, which means you're not forced away from your friends, but this really puts a cap on the "multi" part of "multiplayer".
But is mingling with people what makes a massively multiplayer game or virtual world work? Should DDO be considered one at all?
I've been struggling to like this game. Part of that is because I'd like to play on my own if I wished, but the developers were pretty clear that the game was designed with party adventure in mind. It can certainly be fun when you have others with you (because you aren't dying all the time), but I don't care for the idea of having to find someone to go adventuring with every time I wish to leave the tavern.
I'll admit that the interface for finding others with which to adventure is a good one (although again it breaks fiction -- what's wrong with bellowing out in the tavern, "who wants to clear the sewers of their infestation?" But it does do a good job of helping you find a certain level cleric to heal the group or a rogue to disarm the traps.
But the party is still limited to six. This means you are sharing a common goal, a world event, with at most five other people. It's fun for small adventures, but what about the grand scheme?
And these adventures... I was under the impression, early in the development stage, that the missions had an underlying theme, but that the dungeon or forest or crypt would be different each time, so while you may have heard from others what the gist of the adventure might be, you couldn't know what was coming. I've yet to see this, and it is again fiction-breaking that you can simply redo the same adventure over and over again -- how many times can you save that girl, find the lost badge, or recover that darned healing potion cask?
It finally occurred to me the other day: DDO is not a massively multiplayer game. It's not a persistent world. A better way to define the game is to relate it to a game such as Diablo 2. You could go online, there were other people with which to adventure, you could trade items ... but there was nothing persistent. The only think that changes on the server when I finish saving that girl yet again is that I have a few more experience points, a few more copper pieces, and a damaged mace. But Stormreach is no better off for it; I haven't made things better or worse for other players; and that damned girl is just going to get kidnapped again.
There's no housing with which the players can litter the land. You can't even drop items on the ground -- a good idea from a resource management point-of-view, to be sure, but a bit immersion breaking. And there will be no epic battles as the world's fiction progresses, where dozens or hundreds of players from numerous guilds will come together for a lag-inducing grandiose battle against some great evil.
But perhaps I'm to blame for the misconception, because the game *is* exactly the way they said it was going to be. Perhaps it's my fault that I expected the experience to be more in line with previous entries in the field. Or perhaps they're culpable, because it's not truly a massively multiplayer game. But did they ever claim it was?
As I said, I enjoy the game, and now that I've gotten it out of my head that it's a virtual world, I won't be so critical. It's just an online game where you can see the other players walking around instead of in a roster (like blizzard.net, battle.net, Steam, etc.), and I can enjoy it more now that I'm conscious of that. But I suppose I'm a bit disappointed that we still don't have a D&D virtual world.
Perhaps MMORF can offer that possibility?
Before the game's release, there was a lot of talk on the forums about how the game was going to be strongly instanced -- that is, that adventures would be isolated to a party of players (which is limited to six), and their adventure would be separate from another party that happened to be doing the same task. This is an idea that many games are now using, to prevent griefers (players that just wish to annoy other players) and to better handle server resources.
The rest of the world, I was to understand, was not instanced, so if you weren't on an adventure, you could mingle with the other people in the world. This is partially true; you can certainly mingle with others (in the taverns, on the street, or at the various trainers or quest-givers), but even the outside world is instanced -- there are four different "The Harbor" areas, and which one you end up in is based on the load in them all.
Now the game does supply a fiction-breaking method to hop between these four instances, which means you're not forced away from your friends, but this really puts a cap on the "multi" part of "multiplayer".
But is mingling with people what makes a massively multiplayer game or virtual world work? Should DDO be considered one at all?
I've been struggling to like this game. Part of that is because I'd like to play on my own if I wished, but the developers were pretty clear that the game was designed with party adventure in mind. It can certainly be fun when you have others with you (because you aren't dying all the time), but I don't care for the idea of having to find someone to go adventuring with every time I wish to leave the tavern.
I'll admit that the interface for finding others with which to adventure is a good one (although again it breaks fiction -- what's wrong with bellowing out in the tavern, "who wants to clear the sewers of their infestation?" But it does do a good job of helping you find a certain level cleric to heal the group or a rogue to disarm the traps.
But the party is still limited to six. This means you are sharing a common goal, a world event, with at most five other people. It's fun for small adventures, but what about the grand scheme?
And these adventures... I was under the impression, early in the development stage, that the missions had an underlying theme, but that the dungeon or forest or crypt would be different each time, so while you may have heard from others what the gist of the adventure might be, you couldn't know what was coming. I've yet to see this, and it is again fiction-breaking that you can simply redo the same adventure over and over again -- how many times can you save that girl, find the lost badge, or recover that darned healing potion cask?
It finally occurred to me the other day: DDO is not a massively multiplayer game. It's not a persistent world. A better way to define the game is to relate it to a game such as Diablo 2. You could go online, there were other people with which to adventure, you could trade items ... but there was nothing persistent. The only think that changes on the server when I finish saving that girl yet again is that I have a few more experience points, a few more copper pieces, and a damaged mace. But Stormreach is no better off for it; I haven't made things better or worse for other players; and that damned girl is just going to get kidnapped again.
There's no housing with which the players can litter the land. You can't even drop items on the ground -- a good idea from a resource management point-of-view, to be sure, but a bit immersion breaking. And there will be no epic battles as the world's fiction progresses, where dozens or hundreds of players from numerous guilds will come together for a lag-inducing grandiose battle against some great evil.
But perhaps I'm to blame for the misconception, because the game *is* exactly the way they said it was going to be. Perhaps it's my fault that I expected the experience to be more in line with previous entries in the field. Or perhaps they're culpable, because it's not truly a massively multiplayer game. But did they ever claim it was?
As I said, I enjoy the game, and now that I've gotten it out of my head that it's a virtual world, I won't be so critical. It's just an online game where you can see the other players walking around instead of in a roster (like blizzard.net, battle.net, Steam, etc.), and I can enjoy it more now that I'm conscious of that. But I suppose I'm a bit disappointed that we still don't have a D&D virtual world.
Perhaps MMORF can offer that possibility?
Wednesday, March 01, 2006
Any chance?
I've recently discovered two other projects, Multiverse (http://www.multiverse.net) and BigWorld (http://www.bigworldtech.com). Both of these purport to be "Complete MMOG" solutions.
I heard of Multiverse from its relationship to James Cameron, the director, mentioned I believe in a Wired article. According to their press, they support the .mesh format (though I don't know graphic formats) and have a converter to get you from other popular formats, such as Maya and 3dMax. They have a tool for designing the world. They have support for a product called SpeedTree (http://www.speedtree.com) for providing scenery.
They provide a client, based on the Axiom 3D engine (http://sourceforge.net/projects/axiomengine), and the client can be customized using Python or C#.
The server is written in Java. Their target platform is Linux, but it also runs on Windows XP. They support multiple servers, splitting the world into a quad tree, and passing off quad trees to other servers. Objects are stored as either XML or binary data. Extensions to the server code are either written in Java, for low-level changes, or Java or Python to add features to their MARS (Multiverse Agnostic Rules System). The server does not currently support instanced areas. It uses TCP and UDP for communication.
The game world Kothuria (http://www.kothuria.com) has been built on the Multiverse engine. They do not charge licensing fees provided you do not charge for use of your world.
BigWorld I heard about on the Multiverse forums. I'm not sure what mesh format it uses, but it has a plug-in for 3dMax. They have a BigWorld World Editor to design to world.
They provide a client, the BigWorld Technology Client engine, which is customizable with Python, HTTP and XML. It runs on Windows.
Their server supports multiple machines, and re-aligns server load based on CPU usage. They don't say what language it's written in, but it can be modified with Python. They support dynamic world updates, dynamic manipulation, climate and day/night.
So what does this mean for MMORF? Well, it sure crushes the novelty of it all... I suppose I shouldn't be so surprised -- did I really think no one else would do this?
Both projects talks about being able to distribute the load across multiple servers, which is something that I, too, planned. They both support adding in customizations (I should hope so!) as I did, but I'm again astounded by the popularity for Python in this.
I've got a personal peeve against Python, which is probably clouding my view of it as the be-all end-all of scripting languages. Though I haven't looked too deeply into it, I'm under the impression that the Python runtime allows for some nice on-the-fly interpretation, which can be seen here on the BigWorld site, in the Kill Striff video near the bottom. That kind of interactivity is exactly what I want to be able to provide; not only having a console on which you can change the running world, but to be able to add, change and remove logic to the running server. If these two projects are using Python, I'm starting to ... worry ... that I might have to look into using it too.
I've mentioned before that I've wanted to use C# for this, because that is my current plan for the implementation language. I don't know what kind of interactive solutions are available for C#, or what kind of Python-on-C# solutions are available. I've also mentioned that it would be an interesting exercise to design a stripped-down scripting language, to help the non-programmers still work with the world. Python is a touch too involved for that, and C# would likely be as well.
Both systems provide clients, which is really beyond the scope of MMORF. While I plan to develop clients alongside the server for testing purposes, I hadn't planned on providing a client framework that would be used -- that's something that I would have left to my "customers" to supply.
The World Editor is something I never considered. I suppose providing a world editor would sure make world building a hell-of-a-lot easier than requiring world builders to use their god client to hand-place every item into the world, using the client's interface. Honestly, I hadn't considered it because the purpose of MMORF is to prove the theory that I could write the system, and never to use the actual system for anything concrete. Or populated.
One thing that I haven't found discussed in either project is the interface between client and server (cluster). That is, is there a separate login server, or does each server also act as a login server? If so, is there any rotation of this, or is that done through round-robin methods at the router? BigWorld talks about "[t]he maximum size depends on the number of machines and the switching fabric of the main switch", so this could be exactly what they intend (unless this "main switch" is something they provide.)
I envision MMORF separating the servers that the users connect to (portals to the servers) from the servers themselves -- from a logical view anyway. That is, to reduce the latency (lag) between the user's machine and the world's first point of contact, we might have these points nearer to the user ("near" being a networking idea, not a physical one) than the world servers themselves. The routing and communication between these portal servers and the world servers would then be separately analyzed and configured for optimal communication internally. Of course, they could be the same machine, for the cost-efficient worlds, but I want to provide the ability to separate them.
I'm not abandoning MMORF yet, but it's becoming less of a "wow" thing now. I still want to know, though, that I can write one myself... whether that ever gets done, we'll have to see.
I heard of Multiverse from its relationship to James Cameron, the director, mentioned I believe in a Wired article. According to their press, they support the .mesh format (though I don't know graphic formats) and have a converter to get you from other popular formats, such as Maya and 3dMax. They have a tool for designing the world. They have support for a product called SpeedTree (http://www.speedtree.com) for providing scenery.
They provide a client, based on the Axiom 3D engine (http://sourceforge.net/projects/axiomengine), and the client can be customized using Python or C#.
The server is written in Java. Their target platform is Linux, but it also runs on Windows XP. They support multiple servers, splitting the world into a quad tree, and passing off quad trees to other servers. Objects are stored as either XML or binary data. Extensions to the server code are either written in Java, for low-level changes, or Java or Python to add features to their MARS (Multiverse Agnostic Rules System). The server does not currently support instanced areas. It uses TCP and UDP for communication.
The game world Kothuria (http://www.kothuria.com) has been built on the Multiverse engine. They do not charge licensing fees provided you do not charge for use of your world.
BigWorld I heard about on the Multiverse forums. I'm not sure what mesh format it uses, but it has a plug-in for 3dMax. They have a BigWorld World Editor to design to world.
They provide a client, the BigWorld Technology Client engine, which is customizable with Python, HTTP and XML. It runs on Windows.
Their server supports multiple machines, and re-aligns server load based on CPU usage. They don't say what language it's written in, but it can be modified with Python. They support dynamic world updates, dynamic manipulation, climate and day/night.
So what does this mean for MMORF? Well, it sure crushes the novelty of it all... I suppose I shouldn't be so surprised -- did I really think no one else would do this?
Both projects talks about being able to distribute the load across multiple servers, which is something that I, too, planned. They both support adding in customizations (I should hope so!) as I did, but I'm again astounded by the popularity for Python in this.
I've got a personal peeve against Python, which is probably clouding my view of it as the be-all end-all of scripting languages. Though I haven't looked too deeply into it, I'm under the impression that the Python runtime allows for some nice on-the-fly interpretation, which can be seen here on the BigWorld site, in the Kill Striff video near the bottom. That kind of interactivity is exactly what I want to be able to provide; not only having a console on which you can change the running world, but to be able to add, change and remove logic to the running server. If these two projects are using Python, I'm starting to ... worry ... that I might have to look into using it too.
I've mentioned before that I've wanted to use C# for this, because that is my current plan for the implementation language. I don't know what kind of interactive solutions are available for C#, or what kind of Python-on-C# solutions are available. I've also mentioned that it would be an interesting exercise to design a stripped-down scripting language, to help the non-programmers still work with the world. Python is a touch too involved for that, and C# would likely be as well.
Both systems provide clients, which is really beyond the scope of MMORF. While I plan to develop clients alongside the server for testing purposes, I hadn't planned on providing a client framework that would be used -- that's something that I would have left to my "customers" to supply.
The World Editor is something I never considered. I suppose providing a world editor would sure make world building a hell-of-a-lot easier than requiring world builders to use their god client to hand-place every item into the world, using the client's interface. Honestly, I hadn't considered it because the purpose of MMORF is to prove the theory that I could write the system, and never to use the actual system for anything concrete. Or populated.
One thing that I haven't found discussed in either project is the interface between client and server (cluster). That is, is there a separate login server, or does each server also act as a login server? If so, is there any rotation of this, or is that done through round-robin methods at the router? BigWorld talks about "[t]he maximum size depends on the number of machines and the switching fabric of the main switch", so this could be exactly what they intend (unless this "main switch" is something they provide.)
I envision MMORF separating the servers that the users connect to (portals to the servers) from the servers themselves -- from a logical view anyway. That is, to reduce the latency (lag) between the user's machine and the world's first point of contact, we might have these points nearer to the user ("near" being a networking idea, not a physical one) than the world servers themselves. The routing and communication between these portal servers and the world servers would then be separately analyzed and configured for optimal communication internally. Of course, they could be the same machine, for the cost-efficient worlds, but I want to provide the ability to separate them.
I'm not abandoning MMORF yet, but it's becoming less of a "wow" thing now. I still want to know, though, that I can write one myself... whether that ever gets done, we'll have to see.
Friday, November 25, 2005
Not quite dead
Given the title of the last entry, you'd think I'd abandoned this project. I haven't, but other things have unfortunately taken up a lot of the time that could, would or otherwise should be going to it.
What caused me to post again was not some new revelation or advance in the project, but the fact that I have returned to learning the Ice system mentioned before. Again, this is for a different project, work-related, but as I read about the features, I can't help but think back to MMORF (and the Wish project for which Ice was used). So much of the functionality in Ice is fitting for a MMO, for a multi-server world -- for what I'm trying to do.
By reading the Ice documentation, am I cheating? By seeing the APIs that Ice has available, am I getting an edge on the design of my own system, which would be the core of MMORF?
Luckily, no. I'm proud to say (and you'll have to take my word for it, I suppose) that the features and methodology in Ice are what I had already figured out for myself; that is, the way that objects are handled between servers, and how they are transparently handled by the clients (whether they exist locally or remotely is immaterial).
Perhaps another reason why MMORF has been silent is because I have stopped playing Ultima Online, so I don't have a constant inundation of "I would do that this way" and "I know how to do that" going through my head...
Back to reading, but I'll have time for MMORF soon, I hope.
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
Putting the MMORF project on Ice?
Ice - Internet Communications Engine - is a middleware package designed for object handling across a network, designed by ZeroC. A "replacement" for CORBA, and an improvement upon SOAP and XML-RPC, this package looks very impressive indeed.
Perhaps too impressive.
I'm surprised I haven't heard of Ice before now. It turns out that Ice was used (in fact, one of the articles I read implied it was designed for) the MMORPG game Wish (which I have mentioned before).
Ice handles multiple servers and a multitude of clients. It pretty much handles all of the server-server and client-server communication needed for MMORF.
And that's the problem.
As my very first post said, the point of MMORF is to see if I can do it myself. All of it. Every part of a MMO system, from the database storage, to inter-server communication, to running a multi-million object world. If I use Ice as the foundation for communication, I'm almost cheating myself, aren't I?
And thus I have a quandary.
Luckily(?), I need such a system for a work-related project, so I'm going to continue to read about Ice, and see if, at the very least, it's what that project needs.
After that, the question becomes whether I can write my own (as-good) implementation of Ice for MMORF, or whether I break down and use it.
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
Scripting
As I've mentioned before, scripting will be a big part of MMORF.
Because MMORF is just a framework, meant to run a world of objects and their movement and their interaction and their attributes, it will have only the basic rules that apply to any implementation of a world that a designer might create.
There will be no concept of ability scores (strength, charisma), or race (human, elf, orc) or even gender on the mobiles; objects will not have a weight, or color, or special attributes (magic powers, laser strength). These are all concepts that belong to the design of a world, but not the physics of the world.
The idea is that someone should be able to take the MMORF engine, slap in a bunch of customized code, and have the world run as they wish. If they want a world of fantasy, then the players are elves, have strength and dexterity and such, pick up magic +5 swords, and cast spells; sci-fi worlds will have aliens, lasers and whatnot.
Designing the core rules of the world should be something major, something that takes some time, and something that doesn't necessarily get changed all too often. These could be rules (scripts/code) that are loaded and applied when the world is started up. Any big changes to this world's universe, and the world might go offline briefly to update these programs.
But just as likely, we would want to add some functionality to the world as it's running. Gamemasters (GMs) might want to add some new behavior to a monster in the world, or create a new item that interacts in a new way with other objects, and would want to do these things without having to shut the world down. Additionally, trusted inhabitants (or players, in a game world) might be allowed to customize a subset of their world, as some MUD systems allow.
Because the customization might not be solely in the hands of the world designer (who, if not a competent programmer, would hopefully have one available), we might want to consider the learning curve for scripting.
Because MMORF will be coded in C# and .NET, the obvious way of adding customization is to allow modules (DLLs) to be written in native C# - it will run fast, and merges seamlessly with the system. The other straightforward alternative is to implement a scripting language (much as the Neverwinter Nights (NWN) game has done), which is then translated by the world as it runs.
The first method is appealing from a programmer's point-of-view, as well for time considerations. C# code will just directly access all the data in the world, which, of course, is both good and bad. Questions I had about C# being interpretable or compilable on-the-fly seem to have been partially answered - the RunUO project, also written in C#/.NET, has their customization done through C#.
The second method, providing a scripting engine, also has its plusses. The scripting language can be (if created from scratch) simple enough for the non-programmers to figure out. The NWN language was very C-like, and many tutorials were written on how to use it. Many, many useful scripts came from the NWN community, but it's not clear if the contributors were already programmers, or if they were regular Joes that could pick up the scripting language and use it effectively. The NWN language was pre-compiled, but only down to a byte-code level (I believe), so it was interpreted by the NWN engine. This kind of system would allow people in-game to type in code and have it happen immediately. Mobiles or objects could be examined in-game and have their code appear in a window, edited, and saved.
Not to say that you can't wing something like this from the "direct code" method. If the .NET framework provides a way to compile code on-the-fly, then the same could be done here. As to loading new versions while the world is "live", I'll have to investigate.
I'm leaning to the C# scripting solution. Its feasibility as a live scripting language will have to be checked. Additionally, because of the learning curve on C#, it might be desirable to have a beginner scripting language that can just be translated to C# (and then compiled); this scripting language could be used directly by the non-programmer world designer, or in-game for simple tasks. If the language is kept simple enough, mapping it to C# should be easy, and then that can be passed on and compiled with the scripter none-the-wiser that they just "wrote" C# code.
As for an API to the MMORF internals that the scripting language might use? That's for another time...
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
Michael George Thomas Turner 1944 - 2005
May you rest in peace. You were loved and will be greatly missed.
Developing Online Games
I've just finished reading the above-mentioned book, by Jessica Mulligan and Bridgette Petrovsky.
This book is about the "business" side of online games: the number of people you should have for each job and at which point in the development cycle they should be hired; how you should handle your time; and how much money you'll need to even consider doing something so large.
The authors do a very good job of deterring the casual reader from even considering launching an online world.
But will that stop me? No. Why not? Because that's not what I'm doing (yet). MMORF is a foundation, not a game itself; the goal of this project is to enable people to then go on and develop the online game world that Mulligan and Petrovsky have instilled fear over.
Yes, of course, I do plan on making my own world (for testing out this system, if nothing else). Something that's marketable is a something completely different however. I don't kid myself that I can design a game worthy of massively multi players (as mentioned many times in the book, players compare all future online games to their first one, and I'll admit that I would do the same if designing), nor do I think I have the business acumen to find the funding to start such a venture.
So why did I read this book? Especially when I have others (Bartle's Designing Virtual Worlds for instance), which are at least a little closer to the task at hand?
Because I'm a bad reader. I have over a dozen books that I'm "reading right now", everything from British history to the history of cyberspace to the adventures of Drizzt to the works of Salvador Dali. And I never, ever seem to finish a book. So it's not that I'm NOT reading Bartle's book -- I am, along with many others. Developing Online Games was one of the many others, and it just happened to be the closest one to me when I was reading, okay?
</tirade>
But it's not that the book isn't relevant. Having reasonable Customer Service tools at launch time is something that I might very well have glossed over when designing this framework, but now I know that tools to access internals (with a god client) or just copious, well-organized logs are going to be required, and should be prepared for at the stage I'm at.
I recommend this book to designers, would-be designers, or keeners that just like to follow the industry. Even if the knowledge within doesn't apply to anything you do, it does provide an interested and educated view into the development of online games and the behind-the-scenes events in game companies in general.
This book is about the "business" side of online games: the number of people you should have for each job and at which point in the development cycle they should be hired; how you should handle your time; and how much money you'll need to even consider doing something so large.
The authors do a very good job of deterring the casual reader from even considering launching an online world.
But will that stop me? No. Why not? Because that's not what I'm doing (yet). MMORF is a foundation, not a game itself; the goal of this project is to enable people to then go on and develop the online game world that Mulligan and Petrovsky have instilled fear over.
Yes, of course, I do plan on making my own world (for testing out this system, if nothing else). Something that's marketable is a something completely different however. I don't kid myself that I can design a game worthy of massively multi players (as mentioned many times in the book, players compare all future online games to their first one, and I'll admit that I would do the same if designing), nor do I think I have the business acumen to find the funding to start such a venture.
So why did I read this book? Especially when I have others (Bartle's Designing Virtual Worlds for instance), which are at least a little closer to the task at hand?
Because I'm a bad reader. I have over a dozen books that I'm "reading right now", everything from British history to the history of cyberspace to the adventures of Drizzt to the works of Salvador Dali. And I never, ever seem to finish a book. So it's not that I'm NOT reading Bartle's book -- I am, along with many others. Developing Online Games was one of the many others, and it just happened to be the closest one to me when I was reading, okay?
</tirade>
But it's not that the book isn't relevant. Having reasonable Customer Service tools at launch time is something that I might very well have glossed over when designing this framework, but now I know that tools to access internals (with a god client) or just copious, well-organized logs are going to be required, and should be prepared for at the stage I'm at.
I recommend this book to designers, would-be designers, or keeners that just like to follow the industry. Even if the knowledge within doesn't apply to anything you do, it does provide an interested and educated view into the development of online games and the behind-the-scenes events in game companies in general.
Thursday, April 14, 2005
Triggers and events
While thinking about the scripting language to use (a topic for another day), the idea of event-handling and triggers came to mind. Whatever language I choose to use or write should be able to support them, because I feel that events are a big part of a virtual world.
The best example is speech. A character walks up to the banker and says, "I'd like to access my bank box please." Or he walks onto a magic circle and says a certain word, finding himself teleported to another part of the world. Both of these examples are from Ultima Online, but I'm sure every virtual world has some case of this. Maybe not speech, exactly, but some way for an NPC or object to react to something a character does.
The issue is how to implement it. There are two ways that I can see: each object (which includes PCs and NPCs) has a youJustHeard() function, which is passed a reference to the speaker, and the text spoken; or each speaker has a youJustSaid() function, which takes the text spoken.
In the first case, every object in the world has a listener function. There are really two ways to deal with this: each object, upon creation, must register itself as a listener, to let the world know that it might be interested in things that are said in the world; or whenever something is spoken, the world looks around the speaker to get a list of all the objects within range, and "tells" each of them what was said.
If the world has to check for nearby listeners every time anything is spoken, it should be obvious that there is going to be a lot of this searching. When characters start gabbing in-game, every table, door, dog and character within a given distance is going to be told, whether or not they want to know. In this case, we better hope that we have one hell of an optimized way to get a list of objects within a certain area.
With the registration method, the world would be able to reduce the number of objects that it has to look through, because only objects that can listen are registered. Again, we would still want this to be very optimized, since every character will be in this list, as will many NPCs and probably some inanimate objects.
Both of these methods of listening seem to have a lot of overhead for every word said.
Taking the other approach, it's the responsibility of the speaker to let everyone know what was said. Instead of relying on the server to do all the figuring for finding listeners, the logic for that could be part of the speaker's youJustSaid() script, which would ask the system for a list of things within range (something that seems to be inescapable), and then the speaker's script would call each of the listener's youJustHeard() functions.
At first glance, this seems to be less effective than letting the server do it directly, because the same work is being done (finding a list of listeners, calling each of their functions), but now it's (most likely) being done in an interpreter, which isn't as optimal as a compiled server core. And while that's probably true, having the logic take place in a dynamic spot -- that is, something that the game designer can change -- allows for more flexibility whenever something is spoken.
For instance, perhaps our world allows spells, and instead of clicking an icon or scroll to cast, you simply say the words out loud. As well as having every listener's youJustHeard() being called, we would also want the character to start waving his or her hands, and spell effects to happen, and an apple to appear. Or a certain class of character might be able to open doors with but a word; the doors by themselves have no logic to listen for such things (though it could of course be added), but the speaker's script could not only inform all listeners of the words, but also call the door's use() function. Having the speech handler "local" to the speaker also allows them to control who hears them - they might have a slider that defines how loud they speak (whisper, murmur, talk, yell), or they might be able to speak to one person specifically (telepathy).
All of these things can, of course, be done at the listener's side instead of the speaker's side, and is just as accessible to the world designer, for he or she controls the scripts for everything in the world. And there's no reason that you can't mix the two; the generic "character speaker" script may know how to open doors or cast spells when the character speaks, but there's no need to put the logic for word-activated teleporters in every character when the teleporter itself can have that functionality coded into its listener script. But with this approach, we're saying that it's still the speaker's responsibility to let the teleporter know that something is said -- and what it does with that is up to it.
A third possibility, which I'm not going to entertain, is a "speech parser", which looks at everything everyone says and decides how to handle it. If a sentence contains the word "bank", then search for any bankers nearby and tell them. If one of the four magic words in the game are spoken, check the character is in one of the few places that it matters.
This is very limiting. It basically hard-codes these trigger words, requiring a list of words and their effectual area or audience. The parser might also be responsible for making the effect happen, instead of calling a function on some other object -- again, very awkward.
So, speaker or listener. A decision needs to be made... but not so fast. Triggering and events based on speech is only one possibility. What about the shopkeeper that sees you steal something? What about the citizen that sees you attack another? What about the guard that sees you discard items on the ground - littering!
Speech is only one of the generic actions that we might want world objects to react to. NPCs and monsters should likely defend themselves when you attack them; guards might arrest you if you move somewhere you shouldn't; and the shopkeeper certainly shouldn't sit idly while you get his inventory without paying.
But again, who should handle this? If my character attacks a monster, then it's pretty easy to let that monster (and its beingAttackedBy() function) know this. But what about onlookers? Maybe another monster will step in if you attack its buddy, or a nearby NPC will come to aid you.
If I drop an item on the ground, do I tell every object about this put action I just did, or do I broadcast a "I just put X at Y" message and let the "listeners" do what they will with that knowledge (fined for littering, beggars run over to pick it up). Note that depending on the game interface, this might also "push" a look action to some clients so they now know the item's there, or the world has a constant look going. But it's different to see an object suddenly appear on the ground, and to know that character X put it there. Or at least it should be.
I don't think I've convinced myself either way on who should take care of these messages about the events in the world. I'm hoping as I continue to mull over it that I can find an example that definitively says that one method is better than the other (and I equally hope I don't find two examples that contradict).
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
Never trust the client
A few days ago, in the #ddo IRC channel on SorceryNet, the topic of packet sniffers came up, with respect to the upcoming Dungeons & Dragons Online game.
The issue goes back to the more general rule, "never trust the client", or "The client is in the hands of the enemy". The fact is that no matter how much you try to hide or obfuscate the operation of your client, there are people out there that will figure it out, and they will write a cheat program for your users to use.
The solution, then, is "never trust the client" - that is, anything your client says to do, you verify as "correct" or possible. Instead of taking orders from the client, you take suggestions. And client trust doesn't even have to be in communication, where you are listening to what the client is saying. You can't even trust the client to perform in a commanded way, such as display something it should or hide something it shouldn't. The earliest case I had first heard of (as a player in the community) was in Ultima Online, where the game servers would tell the clients to darken the screen, because it was nighttime or because the player was in a dark dungeon. It was meant to provide atmosphere, but also, I presume, to add more challenge to adventuring in the darkness. I don't know how long it took, but individuals had figured out the packets being passed back and forth between the server and client, had isolated the one that said "make the screen dark", and stripped it out (or modified it to say "make the screen bright").
In the case of the conversation in #ddo, there were the issues of being able to see traps that you hadn't detected yet, or knowing of the presence of monsters that were hiding in the shadows. I, of course, stated flat out that this kind of information shouldn't be in the hands of the client until the player is supposed to know about these. This started a flurry of responses, from "yeah, but every other MMO has had the problem" to "it would be too laggy if you didn't send this stuff beforehand".
Now, I'm one of the first to grit my teeth when I'm reading gaming forums and see people say "they should add feature X. It's really easy, they just need to ..." Invariably, these people are not programmers, and if they are, they're not good ones, and if they are good, then they still don't have the knowledge to say how easy it is to add a feature to someone else's codebase. Almost as bad are people who seem to know what *can't* be done. This is, however, what the discussion became, me included.
One party insisted that game developers are going to keep doing it, even though (I assured them that) experienced developers know about these previous mistakes in this industry, and would know better. Another party insisted that they couldn't get away from sending early information to the client because of lag problems (which is a little better argument than "they'll do it because all games have it").
I disagree with them both. One, at least, is a programmer. And while I find many of the vocal "easy" people on forums try claiming programming skill as well, I usually call bollocks on their abilities, and chalk them up as know-it-alls that know nothing. This chatroom member, though, I'm willing to give credit as a capable programmer, and thus I just disagree with him.
First of all, the "there's always something that a packet sniffer can find" argument is just crap. Yes, it might be that every game so far has had some client vulnerability, but to argue that every game in the future must therefore have the same is ludicrous. The client is just an interface to the information send by and to the server. It should never have extra information that isn't displayed. Enough of that argument.
But the point about lag is valid. The example went something like "if a dozen goblins were sneaking up on you, and suddenly stepped out of the shadows, the sudden surge of data from the server to the client would cause the client to lag and the player to die (or be at a disadvantage)". Fair enough, that might happen. But, this brings up a few points:
Please, prove that one chatroomer wrong.
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
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
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 "useon 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?
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
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
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
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...
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
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
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...
Monday, March 21, 2005
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...
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...
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...
Friday, February 25, 2005
Lag
I've been giving a lot of thought to the problem of lag in MMOs lately. Part of the reason, of course, is that I still play one, and thus experience it, but also because it seems to be quite a large problem that plagues developers. I haven't read anything about the issue, so I'm probably rehashing the old and restating the obvious...
There are, as I see it, a few different issues that all get lumped under the same title of "lag". "Lag", by definition, is to "fail to keep pace". Lag is "experienced" when the action fails to keep pace with a player's commands; when a player fails to keep pace with another player; and when game time fails to keep pace with realtime.
The server
Lag on the server is an example of game time failing to keep up with real time. Players get used to being able to move this distance in this amount of real time, and because the server is so "lagged", they aren't. This usually happens when there is so much action happening on a specific server (for worlds that run multiple servers per world). In-game events, such as a city invasion by hundreds of MOBs, leads to a lot of AI churning away at the server, and an unusually high concentration of players in one spot, fending them off. Also, unsanctioned events can lead to more of a load on a server than developers might expect. The fault: aging hardware, unrealistic computing requirements, underestimation of popularity... mostly things in the developer's realm.
The client
As MMOs get more and more complex, and more and more 3D, the video card is getting taxed to the limit. While this problem will never rear its head in a text-based MUD, graphics are becoming more and more involved, and the creation of them is being done on the client more and more. From environmental textures and effects, to world objects that rotate, flicker and swing, to the numerous MOBs and players that run by with their armor glinting in ten sources of light, the days of static graphics are going. Well, maybe not going, but are falling by the wayside. Here the fault can be prescribed 50/50: users might need to keep up with their state-of-the-art hardware, or developers might be expecting too much of their userbase.
And inbetween...
The biggest culprit of them all -- the Internet. How many miles of cable and fibre do the bits of information between client and server go through? How many pieces of hardware (routers) have to shunt it this way and that? What quality is the medium, and how quick the messenger? This is the biggest bugbear, because it's out of the hands of everyone involved. Neither players nor developers can choose which path their packets should take. Sure, the player can move to a better ISP, or the company can sit on a thicker backbone, but no backbone will be perfect for everyone, and some places still have more hops than desired to get from A to B.
Until the internet is completely pervasive across the globe, and routing technology because near-instantaneous and universally-installed thusly, this will be a problem for the developers to worry about. You need to
By "out-of-sync", I mean our second definition of lag above, where one layer fails to keep pace with another (and in this case, a player could include a MOB).
Make it impossible for two people to become out-of-sync
Force instructions from the player and events from the server to happen based on a "tick" from some clock which keeps track of time. The length of a tick would be the maximum latency of all the players connected to the game. Everyone is forced to play at the speed of the slowest player, in what basically becomes a turn-based game with a timer per turn. Everyone has X seconds to figure out what they're doing this "turn", with the slowest player having the least amount of time to act (because he or she spent most of their turn sending their last action and waiting for results). Doesn't make for much of a game...
Make it so players don't notice if they become out-of-sync
Support on-going commands ("walk north") that will take place on the server, even if the player isn't able to continually send the command. If the server receives a "stop" command a little too late (because it walked them a bit further), then "snap" them back the where they think they should be. This can lead to other players seeing the lagging player hop back a few steps or continue going in the same direction too much (which seems to be what you see in World of Warcraft); or, the player's client, which has been smoothly drawing the action that it's hoping and assuming is happening will suddenly "rubberband" the player back to reality - that is, the spot that he or she is really standing in (now that the client has gotten new information). This is what you see if Ultima Online.
Make it so it doesn't matter if they become out-of-sync
Design the game so it's less of a "twitch" game, where fast reflexes are required to play. Ultima Online PvP used to be all about who had the fastest connection (once the combatants all knew the "best" methods). With one expansion, it changed so that your items were more important than your strategy, thus allowing the server to decide the winner, even if one of the participants couldn't keep up as well as the other. It didn't remove the need for skill in combat, but it helped reduce the effects of differing connectivity between players.
PvM is a bit different. MOBs are designed with their AI as-is, so they don't have different tactics. To make monster X challenging to a 13 level wizard, it has these skills, these stats, these items. But challenging to what level of lag? You want the guy playing down the street with the 5ms latency to have to back off once or twice to heal himself, but does that make it too hard for the woman playing across the continent with the local ISP with bad copper lines underground? Do you make that same monster easier, so the lagged player can still back off in time, thus making it very easy for the low-lag player -- too easy, for the reward?
Or can combat be made even less "twitch" dependant, so a lagged player can decide early on that they're outmatched and thus escape, while there's no benefit to a character of the same strength with a good connection? Do we boil it down to
You have chosen to attack monster X. Do you wish to proceed?
> YES
You have died! / You have vanquished your foe!
where the same result is going to happen to any player, whether their internet connection tells them immediately or half a second later?
Combat, whether PvP, PvM or PvE (versus the environment, such as jumping onto the swaying bridge), is where most of the problems occur. Role-playing is still effective even if your dialog is half a second behind the others -- not everyone's a professional typist! Shopping in-game, wandering the lands, and interacting with NPCs are all things that can happen with leisure. Combat is where it's going to be most noticeable, because that's where the consequence of lag is going to be the most dire: character death, usually.
So the fault for this kind of lag? No fault. But, the developers are the ones that might be able to do something about it.
But that's only half of the problem with the lag between client and server. In addition to the delay between client and server for moving the information, there's also the volume of information.
In Ultima Online, player houses can have items locked down and viewable by passers-by. This means that as a player walks through an area, information about item type and location from many objects are being sent to that player's client. The more items on-screen, the more data being sent. The faster they're moving (or, in this case, trying to move), the more items are coming on screen, and thus even more data. Some houses would be so "decorated" that a noticeable delay would occur as information about hundreds of items was suddenly shoved towards the client. There was even a case years ago where you could make a "black hole" in the game, where if you got too close to a stack of items (a very, very numerous stack), your client would crash. Whether that was from an inability to cope with the number of items, or just too much network data, I don't know. Probably the former, but can you imagine the latter?
In an old text MUD, InFiNiTy CoMpLeX, you could, with the right weapon, take out 15-16 enemies in one shot (it was a rocket launcher). This, I suspect, caused nearly all the different kinds of lag: the server had to handle the firing of the weapon, the damage dealt to numerous MOBs, and their deaths (which included giving experience and broadcasting the event to everyone in the complex) - this was all on a single machine that was running the rest of the BBS on which the game was hosted; the amount of text that had to be send to every client added up to hundreds of bytes, which was significant at 2400 baud; and the sheer number of characters every player received upon this event took some time to display on their slow, 8086 DOS machine (if they were lucky).
Fault: Developers, I suppose: it's up to them to cut down on the size and number of packets being sent back and forth.
Of course, I supply no hard solutions to these problems yet -- I'm still learning. But it's a start, at least, that I know these problems are out there, and that I'm going to have to work around them, if not try to quash them completely.
There are, as I see it, a few different issues that all get lumped under the same title of "lag". "Lag", by definition, is to "fail to keep pace". Lag is "experienced" when the action fails to keep pace with a player's commands; when a player fails to keep pace with another player; and when game time fails to keep pace with realtime.
The server
Lag on the server is an example of game time failing to keep up with real time. Players get used to being able to move this distance in this amount of real time, and because the server is so "lagged", they aren't. This usually happens when there is so much action happening on a specific server (for worlds that run multiple servers per world). In-game events, such as a city invasion by hundreds of MOBs, leads to a lot of AI churning away at the server, and an unusually high concentration of players in one spot, fending them off. Also, unsanctioned events can lead to more of a load on a server than developers might expect. The fault: aging hardware, unrealistic computing requirements, underestimation of popularity... mostly things in the developer's realm.
The client
As MMOs get more and more complex, and more and more 3D, the video card is getting taxed to the limit. While this problem will never rear its head in a text-based MUD, graphics are becoming more and more involved, and the creation of them is being done on the client more and more. From environmental textures and effects, to world objects that rotate, flicker and swing, to the numerous MOBs and players that run by with their armor glinting in ten sources of light, the days of static graphics are going. Well, maybe not going, but are falling by the wayside. Here the fault can be prescribed 50/50: users might need to keep up with their state-of-the-art hardware, or developers might be expecting too much of their userbase.
And inbetween...
The biggest culprit of them all -- the Internet. How many miles of cable and fibre do the bits of information between client and server go through? How many pieces of hardware (routers) have to shunt it this way and that? What quality is the medium, and how quick the messenger? This is the biggest bugbear, because it's out of the hands of everyone involved. Neither players nor developers can choose which path their packets should take. Sure, the player can move to a better ISP, or the company can sit on a thicker backbone, but no backbone will be perfect for everyone, and some places still have more hops than desired to get from A to B.
Until the internet is completely pervasive across the globe, and routing technology because near-instantaneous and universally-installed thusly, this will be a problem for the developers to worry about. You need to
- Make it impossible for two people to become out-of-sync
- Make it so players don't notice if they become out-of-sync
- Make it so it doesn't matter if they become out-of-sync
By "out-of-sync", I mean our second definition of lag above, where one layer fails to keep pace with another (and in this case, a player could include a MOB).
Make it impossible for two people to become out-of-sync
Force instructions from the player and events from the server to happen based on a "tick" from some clock which keeps track of time. The length of a tick would be the maximum latency of all the players connected to the game. Everyone is forced to play at the speed of the slowest player, in what basically becomes a turn-based game with a timer per turn. Everyone has X seconds to figure out what they're doing this "turn", with the slowest player having the least amount of time to act (because he or she spent most of their turn sending their last action and waiting for results). Doesn't make for much of a game...
Make it so players don't notice if they become out-of-sync
Support on-going commands ("walk north") that will take place on the server, even if the player isn't able to continually send the command. If the server receives a "stop" command a little too late (because it walked them a bit further), then "snap" them back the where they think they should be. This can lead to other players seeing the lagging player hop back a few steps or continue going in the same direction too much (which seems to be what you see in World of Warcraft); or, the player's client, which has been smoothly drawing the action that it's hoping and assuming is happening will suddenly "rubberband" the player back to reality - that is, the spot that he or she is really standing in (now that the client has gotten new information). This is what you see if Ultima Online.
Make it so it doesn't matter if they become out-of-sync
Design the game so it's less of a "twitch" game, where fast reflexes are required to play. Ultima Online PvP used to be all about who had the fastest connection (once the combatants all knew the "best" methods). With one expansion, it changed so that your items were more important than your strategy, thus allowing the server to decide the winner, even if one of the participants couldn't keep up as well as the other. It didn't remove the need for skill in combat, but it helped reduce the effects of differing connectivity between players.
PvM is a bit different. MOBs are designed with their AI as-is, so they don't have different tactics. To make monster X challenging to a 13 level wizard, it has these skills, these stats, these items. But challenging to what level of lag? You want the guy playing down the street with the 5ms latency to have to back off once or twice to heal himself, but does that make it too hard for the woman playing across the continent with the local ISP with bad copper lines underground? Do you make that same monster easier, so the lagged player can still back off in time, thus making it very easy for the low-lag player -- too easy, for the reward?
Or can combat be made even less "twitch" dependant, so a lagged player can decide early on that they're outmatched and thus escape, while there's no benefit to a character of the same strength with a good connection? Do we boil it down to
You have chosen to attack monster X. Do you wish to proceed?
> YES
You have died! / You have vanquished your foe!
where the same result is going to happen to any player, whether their internet connection tells them immediately or half a second later?
Combat, whether PvP, PvM or PvE (versus the environment, such as jumping onto the swaying bridge), is where most of the problems occur. Role-playing is still effective even if your dialog is half a second behind the others -- not everyone's a professional typist! Shopping in-game, wandering the lands, and interacting with NPCs are all things that can happen with leisure. Combat is where it's going to be most noticeable, because that's where the consequence of lag is going to be the most dire: character death, usually.
So the fault for this kind of lag? No fault. But, the developers are the ones that might be able to do something about it.
But that's only half of the problem with the lag between client and server. In addition to the delay between client and server for moving the information, there's also the volume of information.
In Ultima Online, player houses can have items locked down and viewable by passers-by. This means that as a player walks through an area, information about item type and location from many objects are being sent to that player's client. The more items on-screen, the more data being sent. The faster they're moving (or, in this case, trying to move), the more items are coming on screen, and thus even more data. Some houses would be so "decorated" that a noticeable delay would occur as information about hundreds of items was suddenly shoved towards the client. There was even a case years ago where you could make a "black hole" in the game, where if you got too close to a stack of items (a very, very numerous stack), your client would crash. Whether that was from an inability to cope with the number of items, or just too much network data, I don't know. Probably the former, but can you imagine the latter?
In an old text MUD, InFiNiTy CoMpLeX, you could, with the right weapon, take out 15-16 enemies in one shot (it was a rocket launcher). This, I suspect, caused nearly all the different kinds of lag: the server had to handle the firing of the weapon, the damage dealt to numerous MOBs, and their deaths (which included giving experience and broadcasting the event to everyone in the complex) - this was all on a single machine that was running the rest of the BBS on which the game was hosted; the amount of text that had to be send to every client added up to hundreds of bytes, which was significant at 2400 baud; and the sheer number of characters every player received upon this event took some time to display on their slow, 8086 DOS machine (if they were lucky).
Fault: Developers, I suppose: it's up to them to cut down on the size and number of packets being sent back and forth.
Of course, I supply no hard solutions to these problems yet -- I'm still learning. But it's a start, at least, that I know these problems are out there, and that I'm going to have to work around them, if not try to quash them completely.
Subscribe to:
Posts (Atom)
Posts
