» the skewed views of a large opinion: Persistent World Design
Thursday, April 29, 2004
  < Advancement >        
A level-free design is not a design without advancement. Rather, it is a design centered primarily on diversification, rather than amplification, of power. The goal of such a system is to reward the veteran with capability, but not at the expense of the newcomer.

As is the norm in persistent worlds, most designs are currently just going back to the well. Amplification of power is an acceptable, and predictable design that draws in a certain core playerbase who never seems to tire of watching numbers increase geometrically (if not outright exponentially). Business realities all but require it in the case of commercial offerings - as almost every attempted level-free game has steadily become a level-based one.

If anyone needed a proof that diversification is a plausible tactic to convey advancement without imbalancing power - consider Everquest and Dark Age of Camelot. Both of these games have added diversification systems in the last couple of years. With their power amplification limits largely met by their playerbase - they're beginning to recognize just how accepted such advancement truly is. Surely their implementations aren't without problem -- Dark Age's planned RA overhaul is evidence of that. But that are a shining proof-of-concept.

Now I'm certain 'tank mage' was uttered by most readers at some point in the first paragraph. Clearly it is undesirable to have a character who can do all things at all times. But why limit capability artificially through 'classes'? Why not simply require players to 'prepare' their capabilities for use, and limit the number of capabilities?

Collectible-Card Games (which I personally don't care for) demonstrate both diversification-based advancement, and tactically-limited infinite capability. A player could easily own every card ever printed - yet their 'active' capabilities are assembled into a much smaller domain before a match. The near infinite capability of the player has no bearing on his ability to overwhelm a newcomer. Indeed the place where CCG systems tend to fall apart - is when they produce cards with overt amplification of existing capabilities - falling into that old, familiar trap.

Simply by placing limits on the number of abilities that can be actively selectable and the gear that can enhance those abilities solves the tank-mage problem. Current designs balance specialized capabilities with the express lack of other specialized capabilities. If one assumes that powerful magic is mutually exclusive of powerful melee, then surely it's disruptive when both abilities manifest on a single character. However, if capabilities are balanced only in respect to one another, there is no reason to assume diversification is a problem.

Consider a professional athletes for a moment. Surely an American football quarterback who can both run, and throw has more diverse capabilities than one who can either throw well and runs slow, or throws poorly and runs well. Yet since the rules dictate that the quarterback can only use one of these two tools on any given play (he can't throw past the line of scrimmage) it isn't an imbalancing advantage.

The primary benefit of a focus on diversification, is that it obviates many of the problems amplification gives us. In level-based systems, if a player refers his friend to a game, that newcomer won't likely be able to play the game with his friend for quite some time. There are many band-aid fixes to this problem, such as City of Heroes' sidekick system, which grants limited temporary levels to bridge this exact problem. Player vs Player conflict is similarly troubled by amplification designs. Balancing conflict between even small delta's in level is often a major undertaking. Without exception, trying to balance the expected reward of leveling, with an even playing field for all level ranges, is a huge design sink that pleases no-one.

With a design that rewards primarily with diverse capability, pvp conflict isn't a problem. All players have a very tight delta in total power for a given encounter. Some may be more useful in a broader range of encounters, but all are competitive. Similarly, referrals have little problem jumping into such a game - as even a novice character is competitive in the same types of challenges as his more experienced friend. The player doubtlessly has some learning to do - and may not have the most effective tools for any given encounter - but his contribution would not be trivial.

A diversification-based system can solve almost all of the problems of level-based design, from player stratification, to economic caste-ing, to wasted content. The only question remaining is: are players too attached to level-based systems?
  < / Advancement >        
Wednesday, April 21, 2004
  < The Price of Loot >        
Much attention is given to the loot mechanisms in persistent world games. Sure, the Blue Foozle may have a well designed lair, or even a solid context for conflict - but if the reward sucks, who cares? At the same time there is much concern about the prevalence and undesirable effects of 'MUDflation'. Clearly the two are related, but how does one reconcile a stable economy with providing valuable rewards to the players? In all honesty, this update is late, precisely because this problem is thoroughly without a clear solution.

Simultaneously scaling the capability to deal damage, and survive damage imbalances combat between levels. Similarly simultaneously scaling monetary rewards for challenging encounters, and survivability imbalances the economy between levels. The core concept of most loot systems (bigger mob == bigger loot), directly results in more money coming into the economy today than yesterday, regardless of changes in player behavior.

Attempts to stem MUDflation generally manifest in the form of moneysinks. The problem with these moneysinks - is that they are balanced according to the initial economy. They don't take into account the ways that new spells, new tactics, and new content will allow players to amass money more quickly. They stall MUDflation at the expense of making the game more challenging at its initial state -- precisely where MUDflation is rarely a problem.

So why do designs simply accept the status quo of (bigger mob == bigger loot)? Is it because players prefer the instant gratification of seeing a large reward, and don't care if today's reward is irrelevant in tomorrow's MUDflated economy? Everquest has been an overwhelming fiscal success for SOE, despite 5 years of rampant MUDflation. Even if EQ's entire population disappeared tomorrow because of MUDflation - would they even hesitate to jump into a different persistent world with a similar economic structure?

In general, there are two types of moneysinks. There are those that are 'required', and those that are 'desired'. A required moneysink would be expenditure for the weapons, armor, tools, and spells necessary to support a playstyle. A desire moneysink is expenditure on items of primarily social value.

Required moneysinks are generally not effective at balancing MUDflation. They must be balanced under the assumption that players will spend only as much time harvesting content as necessary to advance their character. As soon as players continue to harvest content regardless of its value for advancing their character, the systems break down. Perhaps players are camping for drops, or have simply reached the level-cap. Whatever the cause, as soon as a large-enough contingent of players begin these behaviors, the same effect is seen.

Desired moneysinks are no silver bullet. Generally they rely on the playerbase ascribing value to something they know has no value. Further, as the entire playerbase begins to acquire such status, the status itself loses value. If everyone is wielding a glowing long-sword, exactly how cool is it? Desired moneysinks fall victim to social MUDflation.

If there were an easy way to end MUDflation, I wouldn't hesitate to share it. Frankly, I have no idea how one could manage it in a persistent world game. This post is so delayed because I thought I had workable solutions in mind. But as I worked them through it became apparent that I don't. The options that remain are: balance wealth with scarcity, or stall it with style.

When balancing with scarcity, it is necessary that loot be wholly consumable. One player mining gold outside of town necessarily deprives everyone else of the ability to mine that gold. Every source of incoming wealth would need a finite limit. Inevitable social results would include player contention for resource harvesting rights, the concentration of wealth, and collusion by large groups to explicitly prevent others from the ability to harvest. Essentially, all of the undesirable behaviors that haunt games with scarce static spawns would translate over to player behavior regarding wealth collection. This might give one a more stable economy - but at what cost?

'Stalling with style' boils down to acknowledging the conventions of the genre, and making clear boundaries in the system regardless of impact on immersion. Such tools would include leveraging flags on loot such as no-drop, no-trade, and no-sell, NPC-sell-only, making static content that can only be 'consumed' 1 time per player, etc. These systems boldly break immersion, yet their mechanics are all but necessary if designers are going to have any sort of reasonable expectation of balancing new wealth resources with new moneysinks. There would still need to be careful attention paid to the top-end, when players are done advancing, and have nothing better to do. If the 'end-game' involves gathering wealth, we still have a problem.

The jury's still out on the 'fix'. If immersion at all costs is our aim, scarcity might work. Though, most of us will likely have to strike a balance somewhere between reasonable economic control, and avoiding the encouragement of anti-social behavior. The most interesting solution to date, is the one seen in City of Heroes: the effective lack of loot and economic need. 
  < / The Price of Loot >        
Wednesday, April 07, 2004
  < Stagecraft v Simulation: Quests >        
Stagecraft and Simulation represented the two philosophical extremes in persistent world design. In short, simulationists believe that content should be derived from a dynamically simulated environment to maximize verisimilitude -- the 'sandbox' approach to content. Those in favor of stagecraft feel that content should be persistent, hand-crafted, and emulated to maximize convenience and enjoyment; the 'themepark' approach. Both have their advantages and disadvantages, but I have been thinking for some time now, about how 'questing' works into the picture.

My previous few articles were based on a heavily simulationist approach to creating dynamic questing and content. However, I also intentionally designed the system to assume a designer would be hand-tuning many of the variables to set much of the content in motion. Why not just have planning AI's select goals at random, based on the mob-type they control? Why should developers spend time crafting a 'director' AI to allow designers to create static, hand-crafted, one-time-experience quests when a generalized pure-simulationist approach could provide limitless content for everyone? My reasoning for this comes down to just one concept: dramatic context.

An acting character (actor) within a world is by default aware of little to no dramatic context for his actions. A fire-fighter works to rescue someone from a burning building because that's his job. He doesn't know whether he's saving a line-worker, a lawyer or a drug pusher -- he's saving people from a fire because that's what firemen do. In dramatic narratives, the audience/viewer/reader is treated to 'outside knowledge' that the actor is not privy to. They might be shown a weak spot in the building, foreshadowing a collapse and lending tension to the action. The actor themselves might be similarly exposed to information that is not normally given. They might receive a call from the arsonist, who conveniently explains the mad brilliance of how he booby trapped the building to ensure casualties. This knowledge increases the dramatic tension in the scene immensely.

For interactives, our situation is slightly different: our players are simultaneously the viewer and the actor. Actions that actor performs that are devoid of dramatic context are essentially all equivalent. The player has his dwarf kill orcs, because that's what dwarfs do. Whether those orcs come from a static spawn, or a dynamic ecosystem doesn't matter too much. A dynamic ecosystem without dramatic context might be more desirable than a static spawning environment devoid of dramatic context - but how do either stack up to a system with dramatic context?

In a simulated world, dwarf/orc combat could indeed have more context than in static spawning. However, such context relies on each individual players to have knowledge of historical monster movement in the area, and invent some imaginary 'purpose' behind such actions. For the average player, devoid of local historical information - the experience would appear largely the same as static spawning. Orcs would appear to exist merely to be killed by dwarfs. The primary difference would be that the locality of orcs to be killed for fun and profit wouldn't be consistent. Dwarfs would still kill orcs simply because that is what dwarfs do.

Stagecrafted quests allow designers to give dramatic context to these acts for every player. With a bit of flavor text, and a hand-tuned specific challenge and reward - the player is given context for his dwarf's struggle against the local orc tribes. The purpose of the flavor text is to create such context, and if possible, lend emotional weight to the action. This is most often achieved through having NPCs, gathered information, or enemies give more information to the acting character than he would otherwise know. Instead of merely rushing off to fight orcs for fun and profit -- the player is rushing off to foil an orcish kidnapping plot.

Indeed, often in narratives the information given to the acting character exceeds the plausible. We can see this when Bond villain's unwisely share their entire plot to a confronted hero. Inane, implausible, and oft-times comical - such indulgences are used purely to establish dramatic context. If a cop was merely hunting down a drug-lord it wouldn't be nearly as urgent or tense as it would be if the cop was aware that the drug-lord was on his way to kill the mayor.

Truly, in a thoroughly simulated game world, where player failures could be penalized by a loss of content, even dramatic context could be managed. However, not even the majority of simulationists would argue in favor of such a world. Allowing a dragon to level a city in retaliation for a handful of ill-fated adventurers who disturbed its slumber is a fairly extreme design philosophy. Allowing for one player to be assigned a quest, only to have it be completed for him by other adventurers who completed the objective by happenstance also raises some extremely thorny issues. Similarly, coding a simulation to facilitate assassinations, kidnappings, political intrigue, saboteurs, secret messengers, and border disputes is a daunting task -- let alone balancing a simulation to appropriately reward questors for their time investments.

Stagecrafted quests do lose a bit of their context due their static nature. As no content is ever removed from the game - no enemy can actually succeed with their nefarious plot, and no player can actually stamp out the effort. The same situation will always be played out again and again for the benefit of other players. However, this situation already exists in any story-based interactives, or narratives. No-one expects James Bond to lose, and no gamer is forced to put down the controller when Tommy Vercetti plunges a banshee into the ocean. Failure in interactives leads directly to a reload/retry until victory is achieved. And though failure in narratives does happen from time to time -- the commercial success heaped upon the 'Hollywood ending' shows that audiences do not have a problem with such dramatic predestination.

For the most part, it appears as though establishing dramatic context is sufficient to make even static spawning worlds intriguing. Indeed, Blizzard is set to test just such a hypothesis with their quest-centric approach to static world design. Though their renegade dwarves (complete with seaforium;) can never truly be defeated, thus far no World of Warcraft beta-tester has grown weary of trying to do just that through their stagecrafted quest system.
  < / Stagecraft v Simulation: Quests >        
Monday, April 05, 2004
  < Hierarchical AI >        
One of the great potential benefits of the Mob-Box architecture, is the ability to have Hierarchical AI. In short, we could create a sort of higher-level AI that deals with more abstracts and goals, separate from the day to day 'housekeeping' that normal mobs do. In an effort to make our games more dynamic, or simply appear more dynamic, we could use hierarchical AI as a sort of Director, Stratego, or even load balancer.

In general, the hierarchical AI allows us to abstract planning, keeping individual monster AI cleaner, and keeping more computationally expensive tasks from being run on each and every mob. Simple functions such as local pathfinding, visibility, and combat would be handled by the lowest level of AI. Above that would sit one or more AI routines to flesh out the mob.

A good example would be a goblin tribe. Every goblin would have the same basic AI (or same base AI for their archetype). Every goblin would be individually running the same housekeeping code as any other goblin. When attacked, they would all respond similarly; when determining how to path to the edge of the room, they would all use the same code. However, the tribe overall would have a strategic AI applied to it. This 'chief' AI would track resources, be given plans, and would determine goals.

The chief AI could keep track of how many warriors were assigned to the tribe, how many shamen, and how many huts. He could then be given goals, such as 'expand the tribe', 'acquire the human lands', or 'gather gold'. We could apply personality to the process by which the AI would determine solutions - but it would be a single process giving 'intelligence' to the collection of mobs. It might determine that the best way to gather gold is to run the human miners out of the area and begin a goblin mining operation. A more conservative 'chief' might decide to just raid gold shipments, letting the humans do the work, and playing on surprise.

The chief AI could work out plans to meet its goals, and then issue commands to the mobs to execute them. It might issue a 'Move to [waypoint]' command to three warriors. The mob AI would simply handle defending themselves if necessary, harvesting resources, and finding a path to the determined waypoint. The warrior goblins would report back when they succeed, or perhaps when they meet resistance or die. With such information the chief could adjust his plan to send reinforcements, or try an alternate plan. Such a 'tribe' of goblins would have a purpose for their action - a purpose that could be randomly chosen, or hand-selected by a designer.

This idea of course, needn't be restricted merely to potential enemy AI. It could govern town NPC AI: to repel a PC invasion, for instance, or generate dynamic quests. Imagine designers merely having to feed goals to a town mayor, and tweak its personality to create content. The mayor AI would determine things that needed to be done, and could put out quests for the tasks they could not achieve by themselves. They might dynamically adjust bounty quests to help thin down monsters that were actually presenting an obstacle, and tone down or remove those bounties when the mission was accomplished.

There could even be higher levels of abstraction for the AI as well. There might be a 'king' AI, or 'pope' AI who creates plans and transmits larger goals to those under his rule. There might even be a 'deity' AI that gives goals to his popes and priests and worshipers.

In another direction, we could leverage hierarchical AI, to more easily handle scripted NPC life in an attempt to provide seemingly lively worlds. We might have a 'story' AI, or Director, which holds goals and story text that it distributes to NPCs to play out. Quest designers could focus on goals and story, and not worry about complicating the house-keeping code, or having a quest that doesn't seem responsive to the world.

Imagine a Romeo and Juliet quest. One player might seek to sneak Juliet to Romeo for a secret marriage, while another might choose to help Juliet's father spoil such a marriage. Each one could have a different experience depending on who they helped. The actual NPCs wouldn't be running the show, rather the Director would. When certain goals or events occur, the Director can adjust the situation accordingly. One player might cast invisibility on Juliet to get her past her father's guards - while another could bribe them, or maybe even kill them outright. All that matters to the director is that the player got Juliet to the secret wedding ceremony. The quest designer would be concentrating on setting victory conditions, rewards, and dialogue for content. They wouldn't be spending time limiting the solution set or trying to read players' minds to foresee all possible solutions.

In short, this could give immediate context to much of the humdrum in persistent world gaming through simulation - while retaining the capability for designers to hand-craft story.
  < / Hierarchical AI >        
Thursday, April 01, 2004
  < AI: The Big Idea >        
So AI's a problem; what can we do about it? It turns out, there is a straightforward solution, unique to the architecture of persistent worlds. Put bluntly: it's the network.

The root problem of mob AI shortcomings is limited resources. This problem hinges on the supposition that mob AI runs on the same server that's resolving combat, handling network IO, passing around player communication and handling gameworld updates. Well, what if the mob AI wasn't on that machine? What if we moved mob AI to a separate, dedicated, box on the network? A Mob-Box, whose computation is almost entirely dedicated to AI. We could include copies of the world map in this dedicated AI server's memory and do proper pathing and collision detection. We can improve and expand mob scripting to allow them to behave as intelligently as we can possibly code. When we need more monsters, smarter monsters, or different monsters - we can simply add another Mob-box, or beef up the existing box.

The Mob-box won't be handling player communique, won't be resolving combat, and won't be simulating physics. All it will be doing, is processing mobile AI, and interacting with the zone server. Effectively, we'd be altering the architecture to make the difference between a mob and a PC even more slight in the eyes of the game. Mobs would just be issuing commands to the zone (movement vectors, attacks and targets, etc), and handling all the tricky logic (visibility, collision detection, pathing, strategy, etc) themselves.

Naturally, as with all designs, there is a tradeoff with this solution. The primary consideration for this point, is data transfer. How much information about the world state are we going to be sending across the network, to and from the Mob-box, to facilitate this layout? In the old style, mobs have (comparably) instant access to any data in memory. The world doesn't have to tell a mob anything - the mob can simply look it up.

Moving mob AI to a separate box means that any information that mobs need to act intelligently, must be sent from the zone server to the mob -- the same way they are currently sent to players. On the up-side, this is internal networking: gigabit ethernet is fairly cheap nowadays, and we could even add a dedicated network connection (Mob-net) to handle communique between zone servers and the Mob-box. On the down-side, we'll still have a big pile of data to ship back and forth, as the Mob-box is handling logic and instructions for thousands of mobs. Ideally, a mob-box should be able to handle several zone's worth of mobs to defray the cost of the extra hardware. However, this means that informational updates about the world for thousands of mobs across several zones, are zipping back and forth on the wire.

From my perspective, and bar-napkin calculations, it still seems doable. Particularly considering the rates of content that are largely ignored by players at any given time. In the most conservative case we could simply echo world-state updates over the Mob-net. This way all events short of direct interaction messages needn't be duplicated.

E.g. Mob AI would scan its local cache of player positions/movements to determine visibility/agg. Player movements would simply be echoed over Mob-net by the zone server. This removes the need to have the zone server determine visibility for mobs (essentially collision detection again). Events such as 'Player 342 hit you for 48 damage', or 'Player 101 gave you orc_head_12' would be sent across the network. This removes the requirement of having the Mob-box duplicating combat resolution or trade resolution code.

The only barrier left then, is cost. Another dedicated server, more networking gear - these things will tally up a not insignificant cost. This question of course, can only be addressed by men in suits. Is good AI worth higher cost? Can we attract and retain enough players to defray these extra costs on the merits of AI? Would players be willing to pay more, to play in a game world with better AI. Or is current AI 'good enough', and even state-of-the-art AI not noticeably better?

Business concerns aside: There are a couple other extremely interesting and exciting design possibilities that the dedicated Mob-box/Mob-net architecture allows. These I'll delve into, in detail, in my next post.
  < / AI: The Big Idea >        

Powered by Blogger