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.