(Just found that this has been sitting as a Draft for the last six+months...)
Wow, another year goes by without a post. And granted, little time has gone to MMORF, what with life's other concerns and distractions. But, like the tides, my interests ebb and flow, and for now have flown back to MMORF.
I've started a skeleton structure for MMORF, abstracting the various server concepts and even putting together the roughest of text clients for testing purposes. Perhaps it's the complexity of the project, or perhaps it's old-age, but I'm finding myself needing to sketch and list out ideas and concepts a lot more than I used to...
I've been using Fogbugz and Kiln for a few months now, for a variety of projects, and have found that jotting down milestones and future ideas there instead of in in-code comments is working better than I expected. I've also realized that I really need to learn to use a tool like Visio so I can sketch out flows and connections, because my handsketched drawings just don't cut it.
Even though work happens in small bursts and fits, usually within the span of a lunchhour, I'm finding I'm learning the .NET libraries quickly and the cool C# features at the same time. With the Mono system as mature as it is, thanks to the guys at Xamarin, I feel C# and .NET are the right choice for MMORF. The Serialization support means I don't have to worry as much about a protocol between client and server or between servers, because objects can be used as the protocol and can be passed effortlessly between. Indeed, by choosing the method of serialization, I also leave open the ability to watch traffic by leaving it somewhat human-readable in XML, or streaming it in binary form for a bit of speed a little obfuscation.
As with all large projects (at least, for me), doing it so piecemeal has the big disadvantage of ramping up where you left off when you come back to it a day later. Unlike some other projects that I've been trying to work on, though, this one has been churned in my head for a long time (six-and-a-half years!) so the "where was I?" problem is definitely lessened.
Here's hoping that the next post is sooner than a year from now, and has some exciting developments!
Tuesday, March 13, 2012
Wednesday, July 07, 2010
Offloading the client
As I mentioned previously, I've had to start working on a bare-bones client so I have a way to test server development as it goes forth. This was a bit disconcerting, because the goal is the server, not the client, but I may have found a solution!
I currently split my rare programming time between two projects, this one and Windows Phone 7 development. I try to give them equal time, and with this project having the client development requirement, that was resulting in maybe 25% of my coding hours going to MMORF. However, I may have found a way to soon return that to the 50% it deserves, by moving the client development to Windows Phone.
For the next little while, I'll still have to put some effort into this console client, just to have that for quick testing, but for anything more than a text interface, I can certainly justify it as "Windows Phone 7 development" and use my phone development time for it. And if my other phone-related projects suffer because of it, well, I can bitch about it over on that blog.
I currently split my rare programming time between two projects, this one and Windows Phone 7 development. I try to give them equal time, and with this project having the client development requirement, that was resulting in maybe 25% of my coding hours going to MMORF. However, I may have found a way to soon return that to the 50% it deserves, by moving the client development to Windows Phone.
For the next little while, I'll still have to put some effort into this console client, just to have that for quick testing, but for anything more than a text interface, I can certainly justify it as "Windows Phone 7 development" and use my phone development time for it. And if my other phone-related projects suffer because of it, well, I can bitch about it over on that blog.
Thursday, July 01, 2010
Protocol
The whole point of this project, as I may have mentioned before, is to develop the servers, the backend, for the roleplaying framework, not the client. Of course, developing one or more clients is to be expected as I work on the project, because much like you'd expect from a blind painter, it helps to have a visual verification that the result is at all accurate; I could work on the server-side code all I want and HOPE it works, but I'd really want to SEE that it works eventually.
Knowing that, I knew that some day I'd be working on a client -- textbased, 2d, 3d, whatever -- but I never thought it'd be so soon. In fact, I'm actually writing a text-based console client before I get any of the "useful" part of MMORF written: even the server-side code that I'm writing to test the client is just login server stuff right now. Where's the good stuff??
Of course, writing the client means that I've had to address the issue of the protocol between the client and the server, which I've briefly discussed before, but have spent a bit of time thinking about already. Two things are important in a protocol, when all things are said and done: it's efficient, and it's debuggable. The second part can always be done regardless of how the protocol is implemented, but its readability corresponds to how easily it is debugged. Sure, you can write loggers and decoders to translate some binary stream to meaningful words for the developer, but when first developing the system, you're better off making it human-readable to start, and worry about the efficiency later, provided you coded the networking subsystems to handle a complete change to the protocol. This means that all communication is handled through functions that generate the protocol packets via a drop-in system, one which can be replaced without anyone being the wiser. In fact, having the client being able to support every drop-in system you've devised based on its ability to detect what's coming down the pipe means no rewriting later in the development cycle.
When I talk about a human-readable protocol, I typically mean an interchange format such as XML, JSON, YAML or even Metaplace's MetaMarkup. It's something that balances readability by humans and parseability by computers. Myself, I tend to lean towards XML, because it handles hierarchical data very well (both structurally and visually), it copes with escaping characters used by the protocol WITHIN the protocol (something which was a recurring theme with MetaMarkup), and because I've had some experience with it as a network protocol.
The only unfun part of developing a protocol is ... developing a protocol. When you get to the binary level and are trying to squeeze as much data through as possible, THEN it might actually be fun, but at the XML level, it can be tedious coming up with the schema for all of the different packets that are going to fly by.
That's why I was quite pleased to find out that the serialization of C# objects results in: XML! Instead of having to come up with an XML protocol schema, all I have to do is come up with an object schema based on all of the communication needed between client-and-server and server-and-server, then pass these objects through the network and let them pop out as objects that need to be handled. Even better, handlers for these objects can actually be part of the object itself.
It's a pretty slick system. It took a bit of designing to come up with a general server framework, allowing the client to handle various login servers (local (object-based) and remote) and client servers (local and remote), but this is done and mostly implemented. I now have a console client that launches its own local login and client servers (internal objects, not even using a loopback network connection) and can send login packets (or rather, serialized login objects). I had to design none of the protocol, instead letting the .NET Serialization system do it for me, and I had to neither write out nor read in the stream of data, deconstituting or reconstituting the meaning. Instead, I create a Login object, call my LoginServerConnection's Send() function with it, and on the other side the LoginServer sees a Login object pop out, which it may deal with as it pleases.
Just think: I'm almost at the point where I can actually design some of the game server and see it working. Amazing.
Knowing that, I knew that some day I'd be working on a client -- textbased, 2d, 3d, whatever -- but I never thought it'd be so soon. In fact, I'm actually writing a text-based console client before I get any of the "useful" part of MMORF written: even the server-side code that I'm writing to test the client is just login server stuff right now. Where's the good stuff??
Of course, writing the client means that I've had to address the issue of the protocol between the client and the server, which I've briefly discussed before, but have spent a bit of time thinking about already. Two things are important in a protocol, when all things are said and done: it's efficient, and it's debuggable. The second part can always be done regardless of how the protocol is implemented, but its readability corresponds to how easily it is debugged. Sure, you can write loggers and decoders to translate some binary stream to meaningful words for the developer, but when first developing the system, you're better off making it human-readable to start, and worry about the efficiency later, provided you coded the networking subsystems to handle a complete change to the protocol. This means that all communication is handled through functions that generate the protocol packets via a drop-in system, one which can be replaced without anyone being the wiser. In fact, having the client being able to support every drop-in system you've devised based on its ability to detect what's coming down the pipe means no rewriting later in the development cycle.
When I talk about a human-readable protocol, I typically mean an interchange format such as XML, JSON, YAML or even Metaplace's MetaMarkup. It's something that balances readability by humans and parseability by computers. Myself, I tend to lean towards XML, because it handles hierarchical data very well (both structurally and visually), it copes with escaping characters used by the protocol WITHIN the protocol (something which was a recurring theme with MetaMarkup), and because I've had some experience with it as a network protocol.
The only unfun part of developing a protocol is ... developing a protocol. When you get to the binary level and are trying to squeeze as much data through as possible, THEN it might actually be fun, but at the XML level, it can be tedious coming up with the schema for all of the different packets that are going to fly by.
That's why I was quite pleased to find out that the serialization of C# objects results in: XML! Instead of having to come up with an XML protocol schema, all I have to do is come up with an object schema based on all of the communication needed between client-and-server and server-and-server, then pass these objects through the network and let them pop out as objects that need to be handled. Even better, handlers for these objects can actually be part of the object itself.
It's a pretty slick system. It took a bit of designing to come up with a general server framework, allowing the client to handle various login servers (local (object-based) and remote) and client servers (local and remote), but this is done and mostly implemented. I now have a console client that launches its own local login and client servers (internal objects, not even using a loopback network connection) and can send login packets (or rather, serialized login objects). I had to design none of the protocol, instead letting the .NET Serialization system do it for me, and I had to neither write out nor read in the stream of data, deconstituting or reconstituting the meaning. Instead, I create a Login object, call my LoginServerConnection's Send() function with it, and on the other side the LoginServer sees a Login object pop out, which it may deal with as it pleases.
Just think: I'm almost at the point where I can actually design some of the game server and see it working. Amazing.
Thursday, June 17, 2010
World events
As I slowly gain ground on my not-so-rapid prototype (I can pretty much authenticate and connect, and sit ready to send commands and receive world information), my mind wanders to the meat of the game server, which is vastly more interesting than the boring-but-necessary work of having to write login code.
One of the things that I often think about is the interaction between objects in an MMO, and how the interaction takes place from a code point of view. Though I started to write this post over a week ago, it was a post on a friend's blog that finally made me come back and finish it.
Over five years ago, on this blog, I previously wrote on the idea of how to handle the goings-on in a game world, and how the many objects and the world's rules would deal with them. This was before I learned about Metaplace's extension of Lua with their Trigger functions, or the .NET implementation of Events. As I practice my C#/.NET, and continue to work on MMORF, I realize that my method for dealing with such object interaction is still my preferred one.
I have two examples that I keep in mind when I work out the details of this system, both when I was writing my Metaplace RPG subsystem and now as I work on MMORF. These examples, of course, come from UO, my seminal example of what MMORF should be able to do. The main one is simply picking up an item in the game world.
Attempting to pick up an item in UO can involve a lot more checks than might be otherwise apparent. In no specific order, you need to check: if you're close enough to the object; if the character has something in-hand (not equipped, per se, but already being held/dragged by the mouse cursor); if the object is static, that is, part of the map; if the object is locked down (in someone's house, say); if the character has line-of-sight to the object. I'm likely missing something that UO needs, too, and there could be other checks that a non-UO game might want to make such as "is the object too heavy to be lifted?" (in UO you could move mountains, provided they weren't locked down).
Each of these things are rules of the world. The close-enough check is a variable (it's two tiles in UO). The something in-hand is an oddity in UO, since it's dependent on what can be considered a hidden character slot (the mouse cursor, a "third hand") being full, not either of the character's actual hands. The line-of-sight might be a universal requirement. Because these are all rules that are bolted on based on the design of the game system, the platform needs to support that bolting-on, not hardcoding just distance checks and locked-down checks and the like, but anything a game designer can think of -- you can only pick up this object if you're an elf, if your 12th level, if you have the right device equipped.
Each of these rules would manipulate a "result" object, something at which the framework can look, after everyone has had their say, to determine whether the action should be allowed. Thus, the distance checking rule might verify the user is close enough, and either say "yes, for now" or simply not say "no". The latter is more likely, as picking something up is probably better implemented as allowed-unless-not versus disallowed by default. But just because the distance rulecheck didn't say no doesn't mean that the next rule might not -- oh look, the object is locked down, so THAT rule will say "no", and the action will be prevented.
From my system administration background comes two kinds of permission systems as hinted at above: permissive unless prevented (except when overridden), and not permissive unless allowed (except when overridden). So picking up an item is likely the first case -- you can have it unless the rules say you can't -- but actually connecting to the MMORF game servers is the other way around: you're not allowed on UNLESS you can provide a valid username/password, EXCEPT you'll still be denied if your account has been suspended. The "except" case for picking things up might be the "gamemaster" rule: sure, the object might be too far away or locked down, but I'm a god in this realm, and such little rules don't apply to me. And it's much better to have the "gamemaster" rule as a separate rule that can overrule the "that's too far" rule, instead of having the distance rule say "okay, the character is further than two squares, but he's a gamemaster, so I'll say it's okay". Going this approach would mean that every rule would have to know to check the player's gamemaster status to know how to decide. Instead, having a single gamemaster rule that can overrule is better. It could also be implemented that the world has a function that returns a character's FurthestDistanceCanPickUp(), which the distance rule uses; THAT function might then look to see if the gamemaster flag is set and return "1000"; this would also also allow game worlds where different characters can reach further, because they are playing a race with longer arms, or are reaching with a pole, or reaching with telekinesis. In fact, this is sounding like a much better way to implement such a distance rule, instead of having a single number that a world builder can set. Just because UO has the two-tile reach for everyone doesn't mean the next game will.
Determining that a character CAN pick up an item then leaves the system to worry about what happens if they DO. In UO, it vanishes from the ground or container and goes into this pseudo-inventory slot, and the only thing that is likely to happen is that the character will attempt to drop the item (into his or her backpack, on the ground, on another player), and a whole other set of permission checks will take place. But what about actions that have more consequences than just moving things around? What if picking up the item causes damage to the holder? What if the item's absence from where it was triggers a trap? This starts a whole other line of thinking on the idea of Triggers - that some objects in the world are going to care when any item moves, so a nearby player's screen can update properly, and others when specific items move (moving the idol triggers the fire traps).
The second example I usually refer back to is using an item, but it rehashes a lot of the same ideas on the permission side as picking up an item. It's here where the result of successfully using the item, and the chain of events and rulechecks that take place, can get interesting, specifically (if you know anything about UO) when you go to use a crafting item. There's the obvious "can you reach the item" and "is it your item to use" checks, but then if you are allowed, how about "do you have the skill to use it", "what can you build at your skill level", "what are you going to make", "using what resources", etc. There can be a lot of back and forth with the user as decisions are being made, each question and decision being based on surroundings, inventory, attributes and who knows what else. And after all of the objects who have a say about the choices have said, there's the whole issue of success at crafting the item, based again on attributes, buffs, enchanted tools, magic forges, standing in a pentagram or whatever, each which might have their own say on how successful the character is.
For the most part, anything that the player has their character do is susceptible to modification by the rules, by their environment, by their belongings and by their characteristics, and the MMORF platform needs to be able to accommodate it all.
One of the things that I often think about is the interaction between objects in an MMO, and how the interaction takes place from a code point of view. Though I started to write this post over a week ago, it was a post on a friend's blog that finally made me come back and finish it.
Over five years ago, on this blog, I previously wrote on the idea of how to handle the goings-on in a game world, and how the many objects and the world's rules would deal with them. This was before I learned about Metaplace's extension of Lua with their Trigger functions, or the .NET implementation of Events. As I practice my C#/.NET, and continue to work on MMORF, I realize that my method for dealing with such object interaction is still my preferred one.
I have two examples that I keep in mind when I work out the details of this system, both when I was writing my Metaplace RPG subsystem and now as I work on MMORF. These examples, of course, come from UO, my seminal example of what MMORF should be able to do. The main one is simply picking up an item in the game world.
Attempting to pick up an item in UO can involve a lot more checks than might be otherwise apparent. In no specific order, you need to check: if you're close enough to the object; if the character has something in-hand (not equipped, per se, but already being held/dragged by the mouse cursor); if the object is static, that is, part of the map; if the object is locked down (in someone's house, say); if the character has line-of-sight to the object. I'm likely missing something that UO needs, too, and there could be other checks that a non-UO game might want to make such as "is the object too heavy to be lifted?" (in UO you could move mountains, provided they weren't locked down).
Each of these things are rules of the world. The close-enough check is a variable (it's two tiles in UO). The something in-hand is an oddity in UO, since it's dependent on what can be considered a hidden character slot (the mouse cursor, a "third hand") being full, not either of the character's actual hands. The line-of-sight might be a universal requirement. Because these are all rules that are bolted on based on the design of the game system, the platform needs to support that bolting-on, not hardcoding just distance checks and locked-down checks and the like, but anything a game designer can think of -- you can only pick up this object if you're an elf, if your 12th level, if you have the right device equipped.
Each of these rules would manipulate a "result" object, something at which the framework can look, after everyone has had their say, to determine whether the action should be allowed. Thus, the distance checking rule might verify the user is close enough, and either say "yes, for now" or simply not say "no". The latter is more likely, as picking something up is probably better implemented as allowed-unless-not versus disallowed by default. But just because the distance rulecheck didn't say no doesn't mean that the next rule might not -- oh look, the object is locked down, so THAT rule will say "no", and the action will be prevented.
From my system administration background comes two kinds of permission systems as hinted at above: permissive unless prevented (except when overridden), and not permissive unless allowed (except when overridden). So picking up an item is likely the first case -- you can have it unless the rules say you can't -- but actually connecting to the MMORF game servers is the other way around: you're not allowed on UNLESS you can provide a valid username/password, EXCEPT you'll still be denied if your account has been suspended. The "except" case for picking things up might be the "gamemaster" rule: sure, the object might be too far away or locked down, but I'm a god in this realm, and such little rules don't apply to me. And it's much better to have the "gamemaster" rule as a separate rule that can overrule the "that's too far" rule, instead of having the distance rule say "okay, the character is further than two squares, but he's a gamemaster, so I'll say it's okay". Going this approach would mean that every rule would have to know to check the player's gamemaster status to know how to decide. Instead, having a single gamemaster rule that can overrule is better. It could also be implemented that the world has a function that returns a character's FurthestDistanceCanPickUp(), which the distance rule uses; THAT function might then look to see if the gamemaster flag is set and return "1000"; this would also also allow game worlds where different characters can reach further, because they are playing a race with longer arms, or are reaching with a pole, or reaching with telekinesis. In fact, this is sounding like a much better way to implement such a distance rule, instead of having a single number that a world builder can set. Just because UO has the two-tile reach for everyone doesn't mean the next game will.
Determining that a character CAN pick up an item then leaves the system to worry about what happens if they DO. In UO, it vanishes from the ground or container and goes into this pseudo-inventory slot, and the only thing that is likely to happen is that the character will attempt to drop the item (into his or her backpack, on the ground, on another player), and a whole other set of permission checks will take place. But what about actions that have more consequences than just moving things around? What if picking up the item causes damage to the holder? What if the item's absence from where it was triggers a trap? This starts a whole other line of thinking on the idea of Triggers - that some objects in the world are going to care when any item moves, so a nearby player's screen can update properly, and others when specific items move (moving the idol triggers the fire traps).
The second example I usually refer back to is using an item, but it rehashes a lot of the same ideas on the permission side as picking up an item. It's here where the result of successfully using the item, and the chain of events and rulechecks that take place, can get interesting, specifically (if you know anything about UO) when you go to use a crafting item. There's the obvious "can you reach the item" and "is it your item to use" checks, but then if you are allowed, how about "do you have the skill to use it", "what can you build at your skill level", "what are you going to make", "using what resources", etc. There can be a lot of back and forth with the user as decisions are being made, each question and decision being based on surroundings, inventory, attributes and who knows what else. And after all of the objects who have a say about the choices have said, there's the whole issue of success at crafting the item, based again on attributes, buffs, enchanted tools, magic forges, standing in a pentagram or whatever, each which might have their own say on how successful the character is.
For the most part, anything that the player has their character do is susceptible to modification by the rules, by their environment, by their belongings and by their characteristics, and the MMORF platform needs to be able to accommodate it all.
Wednesday, May 19, 2010
Time flies when you're hemming and hawing
Three months since my last post. Yikes. The main reason for this is because about two months ago, Microsoft announced their Windows Phone 7, which has attracted a lot of my meager free time.
On the one hand, WP7 development is done in C# and .NET, which is my target platform for MMORF, so learning C#/.NET is preparing me for both. On the other hand, producing something for the Phone is a lot easier than a mammoth project such as this.
On the one hand, WP7 is backed by either Silverlight or XNA, depending on whether you're making an application or a game, and both provide a front-end method for test clients for MMORF. On the other hand... producing something for the Phone is a lot easier...
MMORF development is appealing because it's a hobby, a challenge. It's something that I think that I can do (given enough time), and it's something that I want to prove to myself that I can do. But WP7 development actually has the potential to make money. In theory.
For the past few weeks, Ultima Online has been rearing its beautiful head, whether in my RSS feeds or mentioned in passing tweets, and as always, UO makes me reminisce and, ultimately, design. Oh yeah, you could do that in UO, and I would code that this way... it has made me very conscious of my neglect on MMORF's part, and has given me a renewed focus on how much time it will get, and WP7 will not. Besides, how much money could I *really* make from developing mobile apps... right? Right?
That being said, I'm aiming to whip up a rapid prototype of a basic backend with static objects and mobiles, and playing around with that. The basics of connectivity, of representation, of execution. It's likely to all get scrubbed in the end, but it's also just as likely to keep me driven and focused.
On the one hand, WP7 development is done in C# and .NET, which is my target platform for MMORF, so learning C#/.NET is preparing me for both. On the other hand, producing something for the Phone is a lot easier than a mammoth project such as this.
On the one hand, WP7 is backed by either Silverlight or XNA, depending on whether you're making an application or a game, and both provide a front-end method for test clients for MMORF. On the other hand... producing something for the Phone is a lot easier...
MMORF development is appealing because it's a hobby, a challenge. It's something that I think that I can do (given enough time), and it's something that I want to prove to myself that I can do. But WP7 development actually has the potential to make money. In theory.
For the past few weeks, Ultima Online has been rearing its beautiful head, whether in my RSS feeds or mentioned in passing tweets, and as always, UO makes me reminisce and, ultimately, design. Oh yeah, you could do that in UO, and I would code that this way... it has made me very conscious of my neglect on MMORF's part, and has given me a renewed focus on how much time it will get, and WP7 will not. Besides, how much money could I *really* make from developing mobile apps... right? Right?
That being said, I'm aiming to whip up a rapid prototype of a basic backend with static objects and mobiles, and playing around with that. The basics of connectivity, of representation, of execution. It's likely to all get scrubbed in the end, but it's also just as likely to keep me driven and focused.
Wednesday, February 17, 2010
Game Engine Architecture
I've started reading Game Engine Architecture, and the first chapter starts off with a large diagram featuring all of the subcomponents of a typical game engine. It's quite the diagram, and it allowed me to get a feel for the totality of what MMORF will become, and what will be left to client implementation.
Because I'm currently looking at C#/.NET for MMORF, the bottommost layers of the diagram -- Target Hardware, Device Drivers and Operating System -- are all abstracted away from the CLR in which MMORF will run. Whether on Windows or on a Mono-supported platform, these will hopefully not matter to me.
The AI, however, is something that I have a real interest in tackling myself, even if other parts of MMORF are eventually dumped onto other SDKs. I've got myself a growing library of game AI books and a growing appetite for coding it. So much so, in fact, that I have to avoid working on that part of MMORF as long as I can to prevent it from consuming too much time.
That's the MMORF engine itself, though;.I *can* see providing tools for profiling the actual framework stats earlier, as the In-Game Menus or Console portion hints at; regardless of how lousy the performance of the actual engine is, knowing where it's spending its time -- running scripts, checking collisions, processing AI, backing up data -- will be an earlier set of profiling tools.
Game-Specific Rendering and Game Cameras definitely feel like they fall into the realm of the client, but I think the rendering is just a function of the client's interpretation of the server's presentation of the player's view: if I look in my text client, I get a text description, in 2d I get 2d sprites rendered up to my view range, and in 3d I get nicer looking figures, textured and cropped again based on the player's view range or stats. A game camera may or may not be considered an in-game function; does the fact that I cannot see behind me in my 3d client mean that anything approaching from behind in my text client shouldn't be revealed? The idea of "facing" would be up to the game developer, and if facing wasn't important (as it isn't in most 2d and text-based games) then the 3d player either accepts this disadvantage (as a perk of the lovely rendering of his or her world) or gets indicator arrows, and rear-view mirror, or some alternative client-based device to allow 360 viewing.
And of course, collision/physics and AI once again appear, and again, would be the realm of the server, and specifically the scripting engine, whether as flags ("collision detection ON") or as function calls to be used ("walk to here directly", "walk to here avoiding being seen").
This is only the first chapter, but the rest of the book promises to be interesting. Quite a few of the chapters focus on client-side concerns, which are only secondary to me (for now), but chapter 14, on the Runtime Gameplay Foundation Systems, looks to be very pertinent, and might just be read out-of-order.
Because I'm currently looking at C#/.NET for MMORF, the bottommost layers of the diagram -- Target Hardware, Device Drivers and Operating System -- are all abstracted away from the CLR in which MMORF will run. Whether on Windows or on a Mono-supported platform, these will hopefully not matter to me.
Third-Party SDKs and Middleware
In previous posts I've hemmed and hawed about using these in MMORF, trying to decide whether it's a cop-out to use them instead of developing my own, whether I'd just be reinventing the wheel, whether I have the time to invest in Wheel 2.0, and whether I could do a decent enough job. I still haven't decided for sure, but I'm still leaning towards coding everything myself, with an open mind to dropping in some middleware if it seems prudent. This section also includes a lot of client-side SDKs, such as OpenGL, which I'm much more open to using for any client implementation I do; writing a 3d library would be fun and all, but I know where to draw the line on priorities with my time. Unity, XNA or WebGL will gladly be leveraged in any client implementation beyond a text interface.The AI, however, is something that I have a real interest in tackling myself, even if other parts of MMORF are eventually dumped onto other SDKs. I've got myself a growing library of game AI books and a growing appetite for coding it. So much so, in fact, that I have to avoid working on that part of MMORF as long as I can to prevent it from consuming too much time.
Platform Independence Layer
This layer, too, is abstracted away by the CLR, so it is "solved" in this respect.Core Systems
Most of these fall under the .NET library or the C# language itself, so are provided to me. Huzzah.Resource Manager (and Collision and Physics)
This is largely the realm of the client, dealing with graphics and rendering, but the latter part of this block, including the collision, physics and map resources, is all server-side, and will all be part of MMORF. Collision and physics are large components, ones that will certainly be implemented later in the project, as there are worlds that can implemented without them, and the scripting engine would allow world builders to code these themselves if necessary (as we saw in Metaplace when the built-in collision and physics support wasn't adequate for all cases).Rendering Engine and Human Interface Devices
These are wholly the realm of the client. I put them together because they pretty much make up what the client is, and apart from the communication their communication to/from the server, are completely separate from the MMORF itself.Profiling and Debugging Tools
Err, yeah... I have to admit that I'm really bad for this. I'm still an old-school printf() debugger unless it comes down to a timing issue. And profiling is an end-of-project task for me unless performance is so unbearably poor during development that time needs to be taken to improve it for the sake of continued development. Naturally, profiling MMORF will be important once it starts to see use, but in its early days, it just won't matter much.That's the MMORF engine itself, though;.I *can* see providing tools for profiling the actual framework stats earlier, as the In-Game Menus or Console portion hints at; regardless of how lousy the performance of the actual engine is, knowing where it's spending its time -- running scripts, checking collisions, processing AI, backing up data -- will be an earlier set of profiling tools.
Animation and Audio
Both of these sections fall under the realm of the client. As I develop MMORF, I always keep the idea of the text-only client in mind, and thus look at all of these features from that point-of-view: what's the text-only client's equivalent of animation and audio? Text descriptions of what's going on, whether provided as metatext to the animation and audio data ("the guard rocks against his spear, unaware of your presence" or "the sword clangs loudly off of your shield!") or perhaps as nothing at all, emphasizing why graphical clients have become popular, delivering the image and sound to you implicitly instead of leaving it up to your imagination.Online Multiplayer/Networking
This book is not specific to (massively) multiplayer games, but is about game engines in general, so approaches the multiplayer angle as an optional component, though one that is admittedly more common. Because of MMORF's whole purpose, this is a required component -- perhaps the defining one -- and is naturally the realm of both the client and server, since that's the whole point of the project.Gameplay Foundation Systems
This is the core of MMORF. This is the objects in the world and their behaviours, the scripting engine behind the world, the event-handling within the world and between the world's objects. Sure, we need collision and physics on top, and file access and networking on the bottom, but this is the real body of the MMORF system, and probably the most interesting. This is the part I will likely blog about most, because file access and networking aren't exciting, and collision and physics... well, let's hope I get there.Game Specific Subsystems
This is quite the range of topics, and at first glance, I'd be tempted to split the workload between "client" and "scripting". But part of the point of MMORF is to make the engine generic enough (a Foundation) so that the client doesn't have to have game-specific coding. The top blocks, such as weapons, power-ups, vehicles, etc., are all the realm of the scripts that power the game, and how they are presented to the player should be done in a generic enough way that any client is going to render them as well as any other game world.Game-Specific Rendering and Game Cameras definitely feel like they fall into the realm of the client, but I think the rendering is just a function of the client's interpretation of the server's presentation of the player's view: if I look in my text client, I get a text description, in 2d I get 2d sprites rendered up to my view range, and in 3d I get nicer looking figures, textured and cropped again based on the player's view range or stats. A game camera may or may not be considered an in-game function; does the fact that I cannot see behind me in my 3d client mean that anything approaching from behind in my text client shouldn't be revealed? The idea of "facing" would be up to the game developer, and if facing wasn't important (as it isn't in most 2d and text-based games) then the 3d player either accepts this disadvantage (as a perk of the lovely rendering of his or her world) or gets indicator arrows, and rear-view mirror, or some alternative client-based device to allow 360 viewing.
And of course, collision/physics and AI once again appear, and again, would be the realm of the server, and specifically the scripting engine, whether as flags ("collision detection ON") or as function calls to be used ("walk to here directly", "walk to here avoiding being seen").
This is only the first chapter, but the rest of the book promises to be interesting. Quite a few of the chapters focus on client-side concerns, which are only secondary to me (for now), but chapter 14, on the Runtime Gameplay Foundation Systems, looks to be very pertinent, and might just be read out-of-order.
Monday, January 18, 2010
Messaging, transfers and auctions
My basic verbs for virtual worlds were a suitable set five years ago, when thinking of gameplay and what it can all be boiled down to. Now, however, I've seen one or two of today's MMOs, and as intimated in my last post, they can't just be summed up with the plain ideas of getting around in a virtual world -- they have needs that transcend the world of the character, to the world of the player. Chat is one of those things; it's all find and good to roleplay your characters talking in-world, even if out-of-context, but that still requires proximity to be heard, or some in-game mechanism to reach further, such as Ultima Online's communication crystals. These other features don't necessitate a new server, as the last post discussed, but just some in-game features -- reduced down to verbs, perhaps, -- that allow them to exist in any game developed in MMORF.
messaging
The chat server discussed before is useful for live communication with players in-world, or indeed, if external access is made available (which I think is necessary), then completely external live communication is supported, making it no different than your ICQ/MSN/AIM environments. But what about leaving messages, the in-game equivalent of email? Ultima Online had the idea of bulletin boards that you could leave on your in-game house, Dungeons and Dragons and World of Warcraft have a mailbox with which you can receive messages from friends, strangers, and perhaps just as importantly, from the game world, either in-context or not.
All three examples use an in-game object or person to get these messages, requiring characters to be in certain areas to receive them. This might not be required, however; a game world might break immersion by allowing access to these communications through some pop-up menu, being more communication for the player and not the character. This means not restricting the functionality just to objects and scripted behaviour, but as something that objects interaction OR the client itself can communicate. Indeed, in DDO, there's an icon that appears on the player's HUD that signals mail presence, thus combining the in-world mailbox for the character with the information provided to the player -- the fact that the character "knows" to go check the post office is only a slight break from immersion.
transfers
Transfers are different from a GIVE verb which is a live interaction between two characters. Instead, transfers are a way to transfer between two characters that aren't in proximity. DDO and WoW support mailing objects to others through the post office -- I don't know about WoW, but DDO has a fee system that provides a gold sink, based on the value of the object. Transfers are often used for two "non-standard" purposes -- transferring between a player's characters on the same account, and storing extra items beyond available in-game storage (character inventory, bank slots, housing). Not that these mechanics matter; what matters is that there's a method to transfer in-game objects, securely, to another character in the game, whether through an in-game system or right in the client. The allowed uses for such a system is up to the game designer.
auctions
MMOs are, to a lot of people, all about acquiring virtual goods. Sometimes this is out of necessity, to advance through the game with the best gear, and sometimes it's just for having the best, for having a whole set, or just for having. To facilitate the trading that goes on between characters/players that don't know each other, having a method to post an item for a specified price (or a minimum bid price) in a centralized location. UO did this by allowing players to purchase vendors, which were placed in player housing and handled the storefront of items priced at a set price; DDO and WoW allowed characters to put items into an auction house and hope that someone else wanted them. Again, each of these games uses an in-game concept for handling this offline transfer between characters, though this doesn't have to necessarily be the case - having a web interface into the auction house could be very useful for the player (and who knows, perhaps WoW offers this). Typically this mechanism also provides a goldsink for the game -- the vendors charge a rent, and the auction house takes a cut on the sale and/or a posting fee. This need means that the auction/vendor system needs to go through the game server to allow for the developer to provide the rules for transfer - to add on the fees, to restrict transfer of too-high items or bound items, etc.
In essence, each of these features could be added in-game using scripting and basic verbs such as USE on mailbox objects, or GET/PUT/SAY to a vendor as Ultima Online indeed does. But the idea of these features existing outside of the world, escaping the virtual to include actions that players might take, means to me that they are their own, albeit more complex, verbs of gameplay in today's virtual worlds. And there are more...
messaging
The chat server discussed before is useful for live communication with players in-world, or indeed, if external access is made available (which I think is necessary), then completely external live communication is supported, making it no different than your ICQ/MSN/AIM environments. But what about leaving messages, the in-game equivalent of email? Ultima Online had the idea of bulletin boards that you could leave on your in-game house, Dungeons and Dragons and World of Warcraft have a mailbox with which you can receive messages from friends, strangers, and perhaps just as importantly, from the game world, either in-context or not.
All three examples use an in-game object or person to get these messages, requiring characters to be in certain areas to receive them. This might not be required, however; a game world might break immersion by allowing access to these communications through some pop-up menu, being more communication for the player and not the character. This means not restricting the functionality just to objects and scripted behaviour, but as something that objects interaction OR the client itself can communicate. Indeed, in DDO, there's an icon that appears on the player's HUD that signals mail presence, thus combining the in-world mailbox for the character with the information provided to the player -- the fact that the character "knows" to go check the post office is only a slight break from immersion.
transfers
Transfers are different from a GIVE verb which is a live interaction between two characters. Instead, transfers are a way to transfer between two characters that aren't in proximity. DDO and WoW support mailing objects to others through the post office -- I don't know about WoW, but DDO has a fee system that provides a gold sink, based on the value of the object. Transfers are often used for two "non-standard" purposes -- transferring between a player's characters on the same account, and storing extra items beyond available in-game storage (character inventory, bank slots, housing). Not that these mechanics matter; what matters is that there's a method to transfer in-game objects, securely, to another character in the game, whether through an in-game system or right in the client. The allowed uses for such a system is up to the game designer.
auctions
MMOs are, to a lot of people, all about acquiring virtual goods. Sometimes this is out of necessity, to advance through the game with the best gear, and sometimes it's just for having the best, for having a whole set, or just for having. To facilitate the trading that goes on between characters/players that don't know each other, having a method to post an item for a specified price (or a minimum bid price) in a centralized location. UO did this by allowing players to purchase vendors, which were placed in player housing and handled the storefront of items priced at a set price; DDO and WoW allowed characters to put items into an auction house and hope that someone else wanted them. Again, each of these games uses an in-game concept for handling this offline transfer between characters, though this doesn't have to necessarily be the case - having a web interface into the auction house could be very useful for the player (and who knows, perhaps WoW offers this). Typically this mechanism also provides a goldsink for the game -- the vendors charge a rent, and the auction house takes a cut on the sale and/or a posting fee. This need means that the auction/vendor system needs to go through the game server to allow for the developer to provide the rules for transfer - to add on the fees, to restrict transfer of too-high items or bound items, etc.
In essence, each of these features could be added in-game using scripting and basic verbs such as USE on mailbox objects, or GET/PUT/SAY to a vendor as Ultima Online indeed does. But the idea of these features existing outside of the world, escaping the virtual to include actions that players might take, means to me that they are their own, albeit more complex, verbs of gameplay in today's virtual worlds. And there are more...
Friday, January 15, 2010
Warming up
As I wait for the new C# 4.0 Nutshell book to arrive, I'm doing more (re)thinking and planning instead of coding. This involves re-reading my old posts, including the one on the servers that would make up the whole system. I wrote that nearly five years ago, so I've still got to decide whether my thinking back then is still reasonable, but I did come up with two other servers that would be useful to have.
chat server
Chatting between players is a core concept to a multiplayer game. But "chat" is a different idea than the talk verb; talking happens at a range from the player's avatar in-world, where chat transcends the virtual world and is instead a meta event. This is for players talking to players, not characters talking to characters.
Dungeons & Dragons Online had a separate chat server -- this was made obvious when the server was down, and the client outright told you so. Ultima Online, after way too long, added chat to the game -- obviously something revealed to be needed, but I've not played UO since it was added, so I'm not sure if it's a separate server or not. Metaplace, too, had added a chat server after a while, helping to connect multitudes of players and developers who would otherwise each be in their own world.
Does this need to be a different server, or should it just be a new verb to a new "room" that spans the "ether" of the whole game world? I think so, because the idea of a separate server allows for non-game-client chat clients to exist; a web-based client or a plugin to poly-IM tools such as Miranda or Trillian could be written to allow players and guild members to chat with friends without having to be running the actual client. Shouldn't they just use some other chat method, separate from the game itself? No, because the whole ICQ-while-playing is an old idea, and is problematic in full-screen games. The communication while in-game needs to be in the client. Also, a game-aware chat system can access game data, allowing lookups of equipment stats, character levels, guild rosters, etc. as part of the chat protocol. This is data that is being exposed more and more by commercial games, allowing players to watch their characters and guilds through webpages or even an API. The idea of an API into the game server's data is a must, of course, for MMORF, and one that I'll have to keep in mind as it's developed, including the chat server's access to it.
patch server
Typically patch servers are used to patch clients, for both the client's logic (rendering, interface, etc.) and the client's assets (art, animations, sounds). This is typically something that happens when the game client starts up; it connects to the patch server, compares its version to the latest, downloads a new executable, or dynamic library, or art file, or data file, or something, and then launches the "real" game client once that's done. This happens in the UO client, the DDO client, and probably every other online game client out there.
Metaplace was a little different; the logic portion of the game client was a Flash program, which was downloaded when you went to the world's site or a site with an embed of it. The patch in this case happened automatically for you. And the game assets were downloaded at each world visit, though your browser could be caching it and not actually downloading. This was required because the same client was being used for myriad worlds, each with assorted sets of assets. This kind of functionality isn't typically needed in a client with a single game target, however, but it COULD be. There's no reason that assets couldn't be streamed as needed, in the background, as the player first logs in. It would allow a game to update itself while running, instead of downtime on the server, and forcing the player to log out to repatch.
The other reason I can see with the pre-patch versus the live patch is that game clients tend to store their assets in large binary files, perhaps for file access reasons, but more likely to help obscure the file format to keep their assets private. On the other hand, assets in Metaplace were just web assets, PNGs and JPGs and MP3s that had to obfuscation. I will certainly be taking the open approach while developing MMORF, allowing for easy and transparent handling of the local version of assets.
I'll soon have to break out the Visio to make some pretty drawings relating all of the different server parts to this project. It all seems clear in my head, but let's see how it looks on paper.
chat server
Chatting between players is a core concept to a multiplayer game. But "chat" is a different idea than the talk verb; talking happens at a range from the player's avatar in-world, where chat transcends the virtual world and is instead a meta event. This is for players talking to players, not characters talking to characters.
Dungeons & Dragons Online had a separate chat server -- this was made obvious when the server was down, and the client outright told you so. Ultima Online, after way too long, added chat to the game -- obviously something revealed to be needed, but I've not played UO since it was added, so I'm not sure if it's a separate server or not. Metaplace, too, had added a chat server after a while, helping to connect multitudes of players and developers who would otherwise each be in their own world.
Does this need to be a different server, or should it just be a new verb to a new "room" that spans the "ether" of the whole game world? I think so, because the idea of a separate server allows for non-game-client chat clients to exist; a web-based client or a plugin to poly-IM tools such as Miranda or Trillian could be written to allow players and guild members to chat with friends without having to be running the actual client. Shouldn't they just use some other chat method, separate from the game itself? No, because the whole ICQ-while-playing is an old idea, and is problematic in full-screen games. The communication while in-game needs to be in the client. Also, a game-aware chat system can access game data, allowing lookups of equipment stats, character levels, guild rosters, etc. as part of the chat protocol. This is data that is being exposed more and more by commercial games, allowing players to watch their characters and guilds through webpages or even an API. The idea of an API into the game server's data is a must, of course, for MMORF, and one that I'll have to keep in mind as it's developed, including the chat server's access to it.
patch server
Typically patch servers are used to patch clients, for both the client's logic (rendering, interface, etc.) and the client's assets (art, animations, sounds). This is typically something that happens when the game client starts up; it connects to the patch server, compares its version to the latest, downloads a new executable, or dynamic library, or art file, or data file, or something, and then launches the "real" game client once that's done. This happens in the UO client, the DDO client, and probably every other online game client out there.
Metaplace was a little different; the logic portion of the game client was a Flash program, which was downloaded when you went to the world's site or a site with an embed of it. The patch in this case happened automatically for you. And the game assets were downloaded at each world visit, though your browser could be caching it and not actually downloading. This was required because the same client was being used for myriad worlds, each with assorted sets of assets. This kind of functionality isn't typically needed in a client with a single game target, however, but it COULD be. There's no reason that assets couldn't be streamed as needed, in the background, as the player first logs in. It would allow a game to update itself while running, instead of downtime on the server, and forcing the player to log out to repatch.
The other reason I can see with the pre-patch versus the live patch is that game clients tend to store their assets in large binary files, perhaps for file access reasons, but more likely to help obscure the file format to keep their assets private. On the other hand, assets in Metaplace were just web assets, PNGs and JPGs and MP3s that had to obfuscation. I will certainly be taking the open approach while developing MMORF, allowing for easy and transparent handling of the local version of assets.
I'll soon have to break out the Visio to make some pretty drawings relating all of the different server parts to this project. It all seems clear in my head, but let's see how it looks on paper.
Thursday, January 07, 2010
Re-opening windows
Last month, Metaplace.com, the site that drew me away from the MMORF project, announced their closure. Not of the whole company, mind, but of the portion in which I was an alpha/beta tester for the last two years. I won't get into my thoughts about that here, as I've written some of them elsewhere. Instead, I'll say a bit about what that means for my free time, as spare as it is...
I'm currently planning on reviving the MMORF project. The whole point of MMORF still stands -- to see if I can write an engine that could run an MMO. But more generally, a generic engine that can be used to implement any genre, and style -- the only common thread would be users connecting to a virtual world and interacting with it and others.
This is what Metaplace provided, in a sense; they wrote the backend which MMORF strives to be, with a full interface for others to create their own worlds. This isn't what MMORF was going for, exactly, but it was enough to distract me for two years, to get a feel for the kind of flexibility that would be needed in an engine to support any kind of game someone could come up with. It gave insight into the kinds of APIs that were needed, the protocols a working system might use, and the scripting that would be needed.
Now that I'm thinking back to the MMORF project, the direction has changed; no longer am I looking to be the content developer, but the backend developer. As previous posts here started discuss, the various pieces that one needs to make, basically, a Metaplace-like system, sans the UGC portion. It was never my intent with MMORF to provide easy-to-use tools for the average joe to make their own world; I had always pictured it as something a more advanced designer/programmer would use to create their world, offline and behind the scenes, instead of right there in the same client as one uses to connect and play.
I'm going to go back and read all of my previous posts, now, to see where my thinking was going and where it left off. Let's see where this project takes me now!
I'm currently planning on reviving the MMORF project. The whole point of MMORF still stands -- to see if I can write an engine that could run an MMO. But more generally, a generic engine that can be used to implement any genre, and style -- the only common thread would be users connecting to a virtual world and interacting with it and others.
This is what Metaplace provided, in a sense; they wrote the backend which MMORF strives to be, with a full interface for others to create their own worlds. This isn't what MMORF was going for, exactly, but it was enough to distract me for two years, to get a feel for the kind of flexibility that would be needed in an engine to support any kind of game someone could come up with. It gave insight into the kinds of APIs that were needed, the protocols a working system might use, and the scripting that would be needed.
Now that I'm thinking back to the MMORF project, the direction has changed; no longer am I looking to be the content developer, but the backend developer. As previous posts here started discuss, the various pieces that one needs to make, basically, a Metaplace-like system, sans the UGC portion. It was never my intent with MMORF to provide easy-to-use tools for the average joe to make their own world; I had always pictured it as something a more advanced designer/programmer would use to create their world, offline and behind the scenes, instead of right there in the same client as one uses to connect and play.
I'm going to go back and read all of my previous posts, now, to see where my thinking was going and where it left off. Let's see where this project takes me now!
Monday, November 26, 2007
Missed the window
I know, it has been way too quiet. It's hard to pinpoint the exact reason I've been silent here, except to say that I come up with too many projects at once, and of course none get realized...
Lately, in the MMO/virtual world scene, I've been paying a lot of attention to Metaplace, which I'm planning on experimenting with once it becomes opened up. Tools like this, and Multiverse, and BigWorld, and VastPark, really are emphasizing that there is a need for them, and that if I was able to dedicate all of my free time to such an endeavor, it might have seen use.
Time as it is, and life as it goes, the MMORF project is looking unlikely. Yes, the original idea was to see if I could implement all of the pieces myself, and I'd still like to know the answer to that question, but with environments like Metaplace on the horizon, the world designer in me is going to beat out the backend developer for the bit of free time I have. My apologies to those who might have read this blog up to now, expecting a more dramatic end.
That being said, in the next few months this blog might get reworked a little into a discussion on world design, and when Metaplace goes live, perhaps discussion about my contribution to this potentially huge concept.
Edit: I just went back and read the first post:
If this sounds interesting, please stop by every so often. If it looks like this page hasn't changed in a year, then I apologize for taking your time -- I must have been distracted by something else.
Wow, do I know myself or what?
Lately, in the MMO/virtual world scene, I've been paying a lot of attention to Metaplace, which I'm planning on experimenting with once it becomes opened up. Tools like this, and Multiverse, and BigWorld, and VastPark, really are emphasizing that there is a need for them, and that if I was able to dedicate all of my free time to such an endeavor, it might have seen use.
Time as it is, and life as it goes, the MMORF project is looking unlikely. Yes, the original idea was to see if I could implement all of the pieces myself, and I'd still like to know the answer to that question, but with environments like Metaplace on the horizon, the world designer in me is going to beat out the backend developer for the bit of free time I have. My apologies to those who might have read this blog up to now, expecting a more dramatic end.
That being said, in the next few months this blog might get reworked a little into a discussion on world design, and when Metaplace goes live, perhaps discussion about my contribution to this potentially huge concept.
Edit: I just went back and read the first post:
If this sounds interesting, please stop by every so often. If it looks like this page hasn't changed in a year, then I apologize for taking your time -- I must have been distracted by something else.
Wow, do I know myself or what?
Monday, November 13, 2006
Back in service
Sorry to all my thousands of readers... I moved a week ago, and only now got the server back up.
Because of the move, work (and when I say work, I mean thought) on MMORF has been minimal, but it should once again pick up as I ease into my new digs.
Because of the move, work (and when I say work, I mean thought) on MMORF has been minimal, but it should once again pick up as I ease into my new digs.
Monday, August 21, 2006
Parallel Universes and Design Patterns
I just finished reading the article The Theory of Parallel Game Universes: A Paradigm Shift in Multiplayer Gaming and Game Accessibility, over at Gamasutra. It talks about presenting a game to different players in different ways; that is, providing a mapping of the game experience to those that might have limitations in the way they can interact with the game, be it a physical disability, a skill gap, or a hardware limitation.
The article talked about the idea of a transition function that would take the viewpoint of one player and convert it to that of another, and vice versa. While I'm not specifically looking to design a system (and in this case, it's a client-side problem and not server-side anyway) to work around a player's disabilities, whether reduced motor functions, poor vision or deafness, I believe I have mentioned my intent to implement various levels of client before.
On the grand scale of things, a MMO is a large-scale simulation, running innumerable things at any given time, into which players have an interface, a viewport, through which they can watch and, we hope, interact with the simulation.
On the top end of the scale, we'd expect a lavish 3D environment, with lighting and shading and textures, something taxing the latest-and-greatest video cards. You can look all around you, interact with the world using the mouse as an extension of your arm, and generally feel fully immersed in your surroundings.
For less powerful machines, we might provide a simpler, 2D interface, perhaps with a top-down or isometric point-of-view, in which we can still see all of the scenery, residents and objects of our world, albeit in lesser detail, fewer colors, a from the "front" only. We have this version because the graphics are bitmaps, not rendered meshes, and so aging hardware can still display it with a sense of immediacy, or perhaps because players just prefer this view-from-above (perhaps to avoid motion sickness when playing in a first-person 3D view).
For specialized devices, such as PocketPCs or cellphones, with very limited resolution, and reduced memory, CPU and GPU availability, we can perhaps provide a very low-res 2D- or 3D-view, flipping menus and text information overtop of our graphics to get non-visual information about our world. Without a mouse, we might have a stylus (for our PocketPC) or a simple control button on our cellphone, each with which we must be able to interact with the world as well as well as with the mouse.
And then we have the lowest level of interface, a text-only interface. Whether this is used because of a lack of video card, because of physical disabilities, or because of a preference for the simple, the ability for the world to be described in text, and interacted with from a keyboard can and should exist. In the case of such an interface on a portable device, a menu-driven or shortcut-driven interface might be used, to obviate the need for a keyboard.
I feel that any virtual world should be represented to the client in such a way that any of the above interfaces can be supported. For testing purposes, the text-only interface is by far the easiest to whip up, to interact with, and even to automate. Proof of concept for a world might be implemented in simple, 2D tiled graphics, where the game's content can still be seen in full, if not in full graphical glory. And time permitting, the 3D eye-candy version can eventually be written to make the game what it was truly meant to be for the player.
But how is this done? By separating out the system into parts conducive to this manner of design. In the world of design patterns, this is the Model/View/Controller pattern. The idea is that you separate the software (in this case, our MMO) into these three different "ideas", and keep them separate, providing an interface between the three. The Model is the simulation itself; the world running the physics, holding the database, and communicating with the other two about what's going on. The View is our world's representation on the client, whether a 2D or 3D graphical display or or a bunch of lines of text. The Controller, in this case tied very closely to the View (because they're both in the client), is our source of input from the user to the simulation, through mouse, keyboard, stylus or joystick.
The work for the designer and programmer is to decide what the communication between Model/View and Model/Controller is going to look like -- to design a proper transition function, as talked about in the article. If something moves in the world, we need to tell the View that this has happened, possibly with the path taken, the speed done, the direction the object faced, etc. In the 3D world, the mesh will be animated smoothly on the client; in the 2D world, it may hop from "tile" to "tile", or may "slide" from one to another; and in the text world, a sentential description of the move would be provided.
Likewise, if the player wants to move herself forward a few steps, her Controller might have her hold down the up-arrow key on the keyboard for a second or two, or might use left- or right-click on the terrain in front of them on the screen, or perhaps typing walk forward 3, all of which are translated into a "walk forward" or "walk forward 3 steps" or "walk to here" message to the Model.
The "trick", in the case of the View, is finding out all of the information that needs to be sent from the Model, and then figuring out how to represent it in all View implementations. Likewise, every type of Controller needs to be able to communicate the players' needs, completely, all boiled down to the common "language" that Controllers use to make requests in the Model.
In theory, people should have no advantage or disadvantage given any implementation of View or Controller. That is, no View information should be extra to some or lost to others, and actions in the simulation should not be possible in some Controllers and not others. While it's a given that for speed-dependent simulations, certain interfaces will have an advantage, it should only be based on time and not lack of information or ability. The time it takes to read the description of the monster is certainly longer than visually seeing some 3D monstrosity eating your head, and typing "shoot bug-eyed creature" over and over is going to take longer than right-clicking on the screen a bunch of times... but these are all limitations of the player, not the interface.
Since I've never read Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, I don't know for sure whether my description of Model/View/Controller is the same as they present; what I've talked about above is something I came up with independently. I have obviously heard of design patterns, though, and the book I talked about before, Massively Multiplayer Game Development, makes mention of them, so I've started reading Design Patterns to finally see what the fuss is about. I'm sure that there will be other patterns in there that are intuitively obvious (to me, anyway) like the MVC pattern, but perhaps I'll learn some other useful nuggets that might be applicable to the MMORF project.
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, 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?
Subscribe to:
Posts (Atom)
Posts
