Battle Bazaar Blog

Battle Bazaar.net Developer / Designer Blog

Economy in MMO and the Chicken vs. Cow argument

clock January 10, 2010 02:59 by author DaveB

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



Patcher - how it works

clock June 30, 2009 13:10 by author DaveB

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.



Minimum System Requirements (Tentative)

clock May 18, 2009 17:17 by author DaveB

Tentative update to Minimum System Requirements:

Intel ATOM 1.6Ghz or faster.

1GB RAM

Windows XP Home for Ultra Lowcost Computing

 800x600 min resolution (the specific device I am targetting is 1024x600).  16bit or 32bit color.

*** I believe that 1.6ghz is probably a reasonable target clock speed.  If we can run successfully lower than that, that's great, but I think that the target clock should be right around that anyway.  Like I said, I have a specific device in mind.

*** The invite still will be coming soon for the staff player association.  I'm testing things now, and will send it off as soon as I am sure that it is working.  Long term, the Wiki and blogs will have a visible change as well (authentication will be for all of BattleBazaar.net/BattleBazaar.com, and not for individual pages). 

 *** Part of the delay is that I want to make sure the web features as they stand are "working right."

* Launcher requires the "Install Software" permission on Windows.

* Patcher requires no permissions on Windows.

* Content updates do not require patching (at all).

* Launcher requires root to install for all users on Unix-like operating systems.

* Patcher requires a setuid process on Unix-like operating systems.



Writing DirectX, Direct3D, etc. code

clock December 17, 2008 16:50 by author DaveB

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.



Membership and Player Association Servers coming online

clock January 23, 2008 14:55 by author DaveB

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.



TextBox

Tag cloud

Calendar

<<  July 2010  >>
MoTuWeThFrSaSu
2829301234
567891011
12131415161718
19202122232425
2627282930311
2345678

View posts in large calendar

Sign in