The "patcher" in a traditional MMO generally, in some shape or form, requires an account that has administrative privleges.  This is solved in a variety of ways; for example, the new version of the Station Launcher installs a service, which allows it to apply patches using the Local System account.  We are taking a different route, however.

A common approach to loading game resources is to have a "Virtual File System."  Most games do this, at some level, just to manage resources.  Resources could be on a CD-ROM, could be downloaded from the server, and so forth.  The concept is fairly straightforward -- you have a path like: "/themes/systemFaction/systemFaction.jpg."  Under the covers, the system takes the specified path and maps it to "C:\ProgramData\BattleBazaar.net\Iron\themes\systemFaction\systemFaction.jpg."  You don't have to worry about where the ProgramData folder is located in the code, just one spot has to ask the operating system for it.

What we find is that most players spend most of their time in a small subset of the game world, with most MMO's.  Why patch 30 zones the player doesn't care about, to patch the 3 in which they are currently playing?  Now there's something -- obviously -- to maximize the use of zones.  Large, outdoor zones have to be constructed with a target level, and as expansions come out, etc. people are going to move outside that target level.  Using a skills centric system, like we are, doesn't change that -- if you have a large, outdoor zone the difficulty level can't really be scaled.

A strategy that helps with keeping the game footprint small, then, would be to download just what you need as you go along.  This increases load time a little, but you can cache the data and perform just a quick check when returning to the zone.  This removes the need to patch all the various files that go into making a zone, such as the themed textures and so forth.  Meanwhile, it means when you add new content, you just add the new content and immediately start referencing it.  That rules out dial up, but dial up is not a huge market segment anymore.

Now, extending this to the application itself -- if you trust the application using a digital signature, then the assembly can be read from the cache just as easily as from program files or some other, patch-friendly, location.  By trusting the application using a digital signature, you can give the application the level of access that it needs for things like OpenGL calls, but at the same time, you can load it cache-friendly from the web.

The way it works is that you mark some resources "retain," and they are always retained.  You allow the user to set a minimum and maximum cache size, potentially for multiple games.  Then once they download the client, everything routes through the VFS and so the assemblies are brought down automatically, and trusted as necessary via the signatures.  This is similar to how Final Fantasy XI operates, for example.

I was going to post here a sample VB project using DirectX, but I remembered there's an easier solution.

 Download #Develop from http://icsharpcode.net/OpenSource/SD/Default.aspx -- it has a template for DirectX already set up.  To use it, you need three things:

1.  Either Microsoft's .NET Runtime 2.0 or Mono 2.0

2.  DirectX 9 (XP) or DirectX 10 (Vista) from http://www.microsoft.com/downloads/browse.aspx?displaylang=en&productID=9C954C37-1ED1-4846-8A7D-85FC422D1388 (the SDK and/or REDIST will install the support -- better to install the SDK, so you can get help if you need it)

3. #Develop or Visual Studio -- #Develop has a template, Visual Studio does not.  The two use interchangeable project formats.

Alternatively, with the Microsoft toolset go here:

http://microsoft.com/xna

That will give you the XNA toolset, which allows you to write code in any managed language (including C#, VB.NET, Python, PHP, C++, Delphi -- whatever language floats your boat and is applicable to the target) and deploy to the following devices:

1.  Windows Computers

2.  XBox 360

3.  Zune MP3 Player

The XBox 360 support requires whoever owns the XBox to pay an extra premium to play "Creator's Club" games.  Zune currently doesn't require this extra premium.

Alternatively, if you're writing a new engine from scratch, TAO from the Mono project is a good option.  TAO uses SDL, a highly portable 2D graphics platform, and has bindings for OpenGL and a large number of other highly portable libraries.  As a result, code in any .NET programming language compiled against TAO is itself highly portable -- it will run, from the same executable, on MacOS X, Linux and Windows.

If it is desired to run against Mono on non-Microsoft OS, then avoid DirectX -- DirectX is a Microsoft proprietary technology, not supported on non-Microsoft platforms.  OpenGL is widely supported and, additionally, offers the entire DirectX 10.1 feature set on Windows XP with nVidia and ATI drivers.  OpenGL is driven by the video card companies in conjunction with industry partners from CAD-CAM and video game companies, not by Microsoft.  It is easier to introduce proprietary extensions, it is easier to introduce agreed-upon standard extensions, and generally the video card companies are fully supporting their chipsets features on that side.

On Windows Vista and later -- as well as all Linux distros and MacOSX -- you should use OpenAL in some form for audio.  Either directly via C++, TAO's OpenAL support (from .NET languages) or via a library like fmod.  Pure and simple, on Windows Vista the driver natively speaks OpenAL.  DirectSound goes through a compatibility library that invokes OpenAL.  On Windows XP, you should install Creative Labs OpenAL driver (which works with all sound cards), and on Creative Labs cards, that card will bypass DirectSound and talk straight to the hardware.  On non-Creative Labs cards, it will route through DirectSound.

http://blogs.msdn.com/andrewarnottms/archive/2007/10/29/what-do-you-think-of-the-new-wcf-store-and-forward-mail-transport.aspx

I can't speak for the mail transport in WCF, because I've not yet used it, however I've used other mail transports with .NET before.  The nice thing about the mail transports is that it is a technology that crosses firewalls easily.  If you have a client outside the firewall, it is almost never a problem for it to e-mail someone inside the firewall.  It is usually easy to get an e-mail account (regardless of the server software involved).

E-mail transports are also useful because Microsoft Message Queue requires a domain controller for some distributed scenarios, but you are sometimes on leased servers that aren't domain controllers.  In those scenarios, e-mail transport provides most of the same benefits as message queues, but without the need for a PDC.  That is huge for some setups.

The other really nice thing about e-mail transports is that given backup MX service (something that only costs around $20/year from companies like no-ip and the like), servers can go offline -- even for a week or more -- and the messages will recover when it comes back up.

The big drawback to e-mail is that it is very high latency.  The messages might get there in 10 seconds.  The messages might get there in an hour.  The messages might get there in a week.  This usually isn't a problem on internal e-mail, but it is a big problem for system domain boundaries. 

Also, you have to watch for filtering as well.  For example, is the remote system allowed to send mail by the SPF?  I am a huge advocate of SPF -- I have it set up on my servers, I enforce it on inbound mail, and you should too.  SPF blocks more than 300 messages a day on battlebazaar.com, and around twenty to thirty a day on battlebazaar.net, and we don't have a ton of users (but battlebazaar.com was used in several discussion lists and newsgroups, and so the spammers came).

Many anti-spam programs will trigger off of message headers, and off of receiving many similar messages.  You have to be certain whatever anti-spam you have server-side is able to handle the messages reliably also.