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.

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.

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.

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.

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.

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

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.

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!