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!