The chicken vs. cow argument goes chickens aren't as valuable as cows, and so you need a way to trade chickens for cows, and so you pay so much per chicken, and pay so much per cow, and now you have a way of trading the two.

However -- this assumes there are people who want chickens, people who want cows, and that the central authority has a relatively fixed pool of money.  In reality, that is not how MMOs function.  Instead, nobody wants the chickens except NPCs who pay from an infinite pot, in order to remove the chickens from the game.  All anyone actually wants are the cows, and so you get infinite and uncontrollable inflation.

To deal with that, you turn the problem on its side.  Why are you giving the players chickens, if what they need are cows?

I see this as like boosters in a collectible card game/trading card game.  There are only certain cards that have value, the rest are garbage.  In order to get the cards that have value, you either buy an ungodly number of boosters or you buy/trade for the card that you want.  All the useless cards have no value, at all, and are just filler.  Once you have a few thousand basic land cards, you don't really benefit at all from obtaining additional basic land cards.  And that is very much how it actually goes.

In the MMO, to remove those useless drops, they use those NPCs with infinite pools of cash.  The issue with that is that if someone can afford to buy a lot of boosters, they can generate a lot of cash -- that is, someone who can play all the time can generate infinite cash, and so inflation runs completely out of control.

You deal with that by removing the booster mentality, and instead going to a redemption or ticket approach.  When you kill something, rather than drop a rare item randomly, it drops a common item all the time.  You trade the common item to a NPC to get a rare item.  You have only chickens (stackable), and there's only one place you can trade them for cows.  That follows a basic pattern, and allows the players to obtain the items that they want.

So how do you handle crafting, then?

Well, the goal behind the redemption system is to reward based on results -- if I run through a mission in record time, without getting hit, etc. then I get a bigger reward than if I wipe a thousand times  It seems like that same logic (to me) applies to crafting -- you don't get the reward from the player asking you to craft the item, the reward -- instead -- comes from the game itself, for doing well at playing it.

This also eliminates the "I'll do that for donations" versus "I want your first born child" problem as well.  :)

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.

Didn't get the servers up tonight, will get them up tomorrow.  Sorry for the delay. :-)

Yeah!  You heard me, something is actually coming online. 

Master Accounts

Each account can be either a master account (parent is null) or a secondary account (parent is not null).  Secondary accounts share all contact information with primary accounts.  Secondary accounts are clearly indicated as such.  This is similar to what Turbine and NCSoft do, in that you only have to adjust billing information in one place. 

Characters

Since the character server is also going up, you will be able to create characters under a master or secondary account.  You will be able to specify the character's name and gender.  You will be able to obtain a signature block that can be embedded in most popular forum software for an avatar image, and you will be able to obtain a signature block that can be embedded as a signature.  The signature version will include online/offline status, and will link to a journal about your character.  It is up to you what events are automatically logged to the journal (completion of stories, etc.) and there will be a facility to log short messages to the journal as well (e.g. On vacation until 1/24).  People reading your profile will be able to instant message you in game, and chat with you in game, when those servers are finally up.

People on Jabber or Google will eventually be able to subscribe to presence notifications and also send IM in and out of the game.  I don't intend to support other chat networks at this time, but that is always subject to change.

Player Associations (Clans)

Master accounts will be able to create Player Associations.  These player associations may cross games and servers.  They will be able to create "subordinate" organizations, alliances and enemies.  There will be a membership roster and a guild events log (similar to the log in EQ2).  There will be the capability, as with characters, to add your own messages to the log as well.  The messages will be available as an RSS feed, filterable by game, server and unit. 

Characters applying for membership in a PA will have their character information added to an RSS feed as well.  Someone with add to clan permission will be able to view the feed, and click a link to allow the user to join. 

Services

The first round of externally accessible services will also be made available, surrounding these features.  As with the clan membership notifications, how this works is the remote site requests access to your character data (note: no personal data is available via this service, only character and clan information is available).  You will be allowed to select "allow this site to access my character" or "do not allow this site to access my character" (same with clans).  This is so that clans or fan web sites can pull data.

Game Cards

Support for game cards is also going up.  Staff accounts will be able to generate game codes for the "alpha test" group, and cards that add as-yet unnamed tokens to accounts.  These will be 25 digit alphanumeric codes that do not use the character 1, 0, I or O -- in upper case.  Note: generated codes won't work in master accounts for staff, and eventually this feature will probably be restricted to certain staff groups -- but for now, we don't have a mountain of staff so I won't lock it down. :-)

Profile Cards for Web Sites

In addition to all the above, there's also an option to generate profile cards for use on other web sites.  This is designed to be larger than a signature or profile box, and will eventually show much more information.  For now, it won't do a heck of a lot.  Player associations will be able to generate such cards.

Cardspace Login

Log in using a Windows Card Space or other information card provider will be supported.