I wanted to talk about exactly what you can expect to see coming in the next few days.

First, users who currently have accounts (our staff members) will be receiving instructions out-of-band on how to connect up. Basic access will be available after OpenID authentication -- including making posts, working on tickets, etc. -- however administrative functions will require a second, hardware authentication mechanism. A number of mechanisms will be supported out of the gate, but I bought keys for us all. :) The keys will only be necessary in order to perform administrative functions, such as banning accounts, deleting posts or sending modules to the servers. You will, however, be able to opt-in to using the key for everything.

This will be in the form of an invitation, in order to test the invitations functionality, although I'm going to ask that people not invite tons of people just yet. :)

The first big change is going to be in URL's. Existing URLs will continue to work, and will redirect to the new pages -- however, the application is going to function more like GMail or Hotmail, where the application is basically a single HTML page and some scripts. When it needs to update itself, it's going to update the HTML -- versus reloading from the server. As a result, it will be highly interactive. The blogs and wiki will be modules.

There will be a tagging facility, which will be site-wide. Anything you can see, you can tag. You'll be able to create an RSS, ATOM or ActivityStream feed based off of any tag or tags, in order to watch all site activity related to those tags. Similarly, there will be a global, threaded comment facility that includes a "vote up" feature. Many items on the site will have a rating from 1 to 5 stars, as well. The blog will be expanded to support Youtube/Netflix style video streams from Amazon S3, Microsoft Azure and Cloud1. There will be an interactive messaging system -- which will also be accessible via XMPP, a standard instant messaging protocol. There will be API access to many parts of the system.

I've worked up a module that lets me create access control lists on properties in Mongo, so that I can produce filtered objects based on an OpenSocial ID -- a group or user. By default, properties are excluded, and are Owner/Staff view only. That means the owner of the item, and our on-duty staff can see them, but nobody else can. On a privacy screen, you can explicitly grant access to particular properties to groups -- including the "All Users" group and the "Entire Internet" group. The only fields required to be visible (that cannot be hidden) are the random object ID assigned to your record, and the display name.

We don't currently support most of OpenSocial, and probably never will. While I'm basing what I'm doing off of OpenSocial to a point, the way we are functioning is enough different that I don't want to try to implement their standard. For example, user records are always owner and staff only, and so having an OpenSocial endpoint for the user object would be rather futile. We have characters, which are kind of like OpenID people -- but it's not at all clear to me that it would be appropriate for a character to interact with other OpenSocial sites. More importantly and fundamentally, I am using jQuery templates instead of OpenSocial's Java-derived templates, and so I can't support OpenSocial modules in our container. However, I'm providing activity stream support -- among others -- in a fairly compatible way, because it is clear that being able to subscribe to a given character's activity stream might be useful.

Incidentally, the design is also such that all official NPCs in our current project and all future projects will get their own page, with a wall, info, etc. In some cases, game staff may respond on their behalf even. You never know.

There will be more coming in the next few days. Some of the concepts are based on what Microsoft is doing with Windows 8, and it should be the case that our site works quite nicely on Windows 8 devices. Our game will still work on older versions of Windows (as will the site), and I will be testing the game on Ubuntu and BSD as well. I am leaning strongly towards dropping Windows XP based on current timelines and when I expeect to get the thing out the door, but we'll see how it happens.

The important thing is this:

Part of the new site -- fundamentally -- is to let us start setting up game content in a format that the engine can already understand, with a convenient editing facility. The NPCs will have pages because that enables us to edit them, to make certain information public, and to have them interact with players inside and outside the game. One of the things that I want to push for, fundamentally different from other MMOs up there, is the concept that player actions influence the world.

To put it in Dungeons and Dragons sorts of terms...

The Orc Army may be attacking Greyhawk. If the players step up to the challenge, and fight the horde back -- it shouldn't show up again in ten minutes. While I really do like Rift's zone events, and do want to do some of the things they're doing (Ultima did them too) in terms of ongoing semi-dynamic content, the big thing that I want to do is make sure the game itself isn't static. That doesn't mean that there can be no static quests -- it doesn't mean that at all. It doesn't mean there can be no static instances or overworld areas. What it means is that in general, I would like the story to move along, and for there to be new things for newly created characters to do, over time.

Particularly, I want to focus on the feel of a character "fitting in" to the world, and contributing. One of the biggest issues that I have with some of the new games that are coming out is that the developers are giving lip-service to story, but then still piling newbies into an overland zone, where all 8000 of them get to be the first person in a thousand years to forge some weapon. We can have an overland zone with 8000 newbies, too -- that part isn't the problem. The problem is that the zones aren't designed, the stories aren't designed, for the reality of the fact that there are many, many players swarming around the zone.

If there are 20 players standing around newbie land, it is perfectly acceptable to have an army charge them at the gate -- to have them have to work through. I would argue, in fact, that's the ideal scenario if you're wanting to foster membership in player associations, if you're wanting to encourage roleplaying. It's just like having the skill chains be unlocked via trials, versus being unlocked via just levelling and paying some trainer. It is a much more personalized experience, it is a much more entertaining experience.

For example, what I'd like to do with some of the quests is similar to what some of the old hero background systems did (Mekton, CyberPunk had mini-versions of what I'm talking about, Heroes of Tomorrow was a book just about as thick that only did backgrounds), where there are interchangeable quest modules that get shuffled in at various points, to help keep the scenarios fresh, to help keep them enjoyable, to boost replay. The company that did Heroes of Tomorrow had these game decks (forget the name) that had plot elements, and you dealt cards out to the players at the start, and they played them to contribute to the plot in various ways -- it was kind of a "help you along on writing an adventure" sort of a thing. I want to be more like that, because players are going to spend dozens of hours a week (per player) playing the game, and are going to go through various parts of the content more than once.

While I've said I'm against rewarding players randomly -- against the great loot lottery -- on multiple occasions, and that I don't like randomness in combat (my opinion is that combat should be predictable, you should never lose just due to the random number generating deciding to have a run of low rolls), I'm very much for this idea of randomness in repetetive elements of the game. Having your fireball sometimes hit for 100 points and sometimes hit for 700 points isn't particularly fun, particularly if it is just random. Going into a dungeon, and not knowing what critters are going to spawn, etc. -- that part can be random, and if its done right, will greatly increase enjoyment of the game overall.

Which is my primary goal -- to create an enjoyable game, a fun game. There is no competition -- I don't aspire to be as huge as World of Warcraft or Rift, I don't believe we'll take on those major games and win. But I believe if we're a fun game, if people want to play it, that we don't have to compete with those bigger games to do it. All we need to do is to be the best game that we can be, to do things in the best way that we can, and most importantly to understand the users of MMO's and other games and to focus on being what they want, how they want.

I think once you have that -- the players, they'll come.

OK -- so there's a problem with this no class system, and that is that you can't easily implement a consider system.  Traditionally in MUD, there was a consider command that you used on a mobile before fighting it to see if it would be too easy, too tough or just right.

The first thing is I've never seen a "con" system that actually works.  The one in EverQuest and EverQuest 2, for example, doesn't take into account archtype, class, subclass or AA trees -- all of which are factors in how difficult or easy a fight is going to be.  The one in WoW and the one in Warhammer are, similarly, broken.  It's difficult any time you allow player customization at all -- so we need another approach other than looking at a flat level.

First, we're going to keep three scores.  One is the number of wins or losses against easier oponents.  Each time you win against an easy con, we add a point (saying we were right to con it easy).  Each time you lose against an easy con, we subtract a point (saying we were wrong). 

The second number is the number of wins against a medium con.  Again, each win adds a point and each loss subtracts a point.

The third number is the number of wins against a hard con.  Again, each win adds a point -- and each loss subtracts a point.

This forms an index that tells us how to modify cons.  If you have a ton of points against hard con mobs, then we ramp down what we're conning the difficulty at.  If you have lost a ton of points against easy con mobs, then we ramp the con down.  If we're getting things perfect, we know it.  Ideally, medium would be at zero, easy would be positive and hard would be negative -- and so we adjust the cons to try to achieve that, so that things that con as "even" give you about a 50/50 chance.

But how do you determine the initial con?

The answer is we do things differently from everyone else.  Normally a stat -- lets call it strength -- feeds into a skill.  You determine the stat at character creation, and maybe there's a way to move it through game play (gear, etc.).  There's some magic stat that for your archtype you want to be maxed, and the other stats aren't so important.

So we flip the problem around -- the skills determine the stat, and the stat determines the archtype.  But that's not sufficient -- there's a world of difference between an item you get easily, and an item you have to work for.  Each item has skill requirements to equip.

Only skills that have the necessary gear are useable -- so you take the total of all those skills, and that's the "effective" stat.  You total the "effective" stats, and that gets you a general power level.  But again, that's not enough to get a good con.  Someone who had only support abilities would con the same as someone who could instantly kill anything, and that would be bad.  So the con has to be based on the rock, paper and scissors -- the strongest stat has to be compared to the stat it dominates, and the weakest stat needs to be compared to the stat it is dominated by.  That makes it so that if the mob is really good against, say, ranged then it will con a lot higher versus ranged players than versus melee players.

This, then, helps the LFG system.  A balanced group would have the stats equal, so that no one stat dominated.  So if you're looking for more, the system can try to balance out the stats.

The key is the consider system must consider more than just the character level, and the consider system must consider more than just the points.  Every single piece of equipment and the skill of the player sitting in the seat are factors, and if you're going to ramp the difficulty level to an appropriate level, you're going to have to take all of that into account.  Otherwise there is no way to achieve a balanced game.

I want to emphasize -- all this is in generalities because I don't have specifics yet.  But my personal opinion is that if you look at "Lord of the Rings" as an example -- each member of the Fellowship has their own way of doing things, but when they're fighting they are all equally successful.  It shouldn't be about one guy repeatedly mashing the taunt button, while the rest very carefully avoid grabbing the mobs off of him.  It should rarely be "just one guy," and boss fights should be relatively involved.

I have some more ideas -- some pulled from D&D -- that I'm going to share in a couple of days.  The basic thought is -- the basic buckets should be "ranged," "melee" and "support."  Stealth is applicable to all of those, but in different ways -- a melee stealth would be the backstabber, a ranged stealth a sniper, and a hacking stealth more of a spy.  But I'm pretty sure the three buckets should be ranged, melee and support -- the reason being I can see a clear way to set up the rock, scissors and paper there that is fair to all of them.  Obviously, certain choices will involve more strategy and thought, while other choices will be plow through -- but both choices should be equally effective.  And that's really the key.

Anyway, I'll talk about it some more in a couple of days. 

Just to pass it along -- I've bought from Daz3D for a long time (since before they split off from Zygote), and this is one of the most interesting things to me:

http://developer.daz3d.com/i/3d_art_resource/developer_press

This is pretty freaking awesome, even if you don't know it yet.  First, Zygote was developing content for Poser and other 3D programs.  Daz broke off, and started doing 3D content heavy.  It acquired a few other products, including such heavyweights as Bryce and Cararra, and then they developed a clone of poser (more or less -- you can argue if its a clone or not).  I have a platinum membership and, with some lapses, have had one for a few years.  Their content is awesome, and they resell for many people.  It's a shame they can't integrate things more into Daz Studio (e.g. name the content files something like dazpack, and make them simple zips, so that double clicking them could allow automatic installation on both Windows and MacOS).

Anyway -- if you look here:

http://www.digimi.com/newsite/presite/home.jsp

That can give you an idea of kind of what is going on here.  What they've done is taken a large number of their 3D assets, and made them available for use in video games.  For example, Victoria and Michael are the most popular 3D models on the planet by most measures, because of their long standing use as upgrade to the built-in poser models.  You can now license those for use in video games -- you can take them, apply morphs, and export them and pull them into your game engine.

What they're doing on the digimi site is allowing fully personalized avatars.  You can import the AV from there, and use it in a game.  The game is able to exert some control over that.  I have a few concerns over that approach, but for sure will be buying the Daz3D plug in set they're selling and a few of the models.

Among other things, the license should make it possible to export a model like Aiko (their anime model) and then use Hexagon on the resultant files, for example. 

Anyway -- really excited by this, and whish I had noticed it right when it happened.

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.

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.

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.

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.