A Room with a View

I’ve been wondering lately about how to handle scope and scale in a PW. This is related to things like zoning and seamless worlds. Developers on the forums for various engines constantly ask for seamless worlds. Players also often ask for them. Three things strike me:

1. Most of the large worlds that have actually implemented them serve as cautionary examples. The great big, seamless world may seem like a nice bullet point for the marketing list, but it is not possible to actually fill that space with content. So the content in the interconnecting regions becomes procedural. Procedural turns the countryside into flyover territory. Our community and indy worlds are SMALL. There is no way that a group of hobbyists working in their spare time can ever produce the kind of content to even contemplate large, seamless worlds.
2. Indy and community teams are beggars rather than choosers when it comes to engines. We hobbyists/indies are not using Hero or Unreal3 with Umbra. We are using things like Realm Crafter, Torque and Unity. We might use an OGRE 3D based engine that supports paging or they might be running an older version of Torque, such as TGEA. Neither of these is problem free and Garage Games has even removed the paged Atlas terrain from its new Torque 3D version due to the numerous problems it caused. Then the whole issue of resource allocation on the server creeps up.
3. Zoned worlds create a hybrid nodal/coordinate based geography. With coordinate based geography, if I want to travel from the desert to the polar icecap, I’d have to traverse transitionary terrain in between; that is if the designer does not want to break the magic circle and provides a sensible transition from the hot, sandy desert to the frozen wastes. In a nodal system, distance is in arbitrary steps and I can simply ignore that transition zone. You leave the desert and enter the arctic. Zone based systems are locally coordinate based and globally nodal. If fact, you can even do seemingly “impossible” things like having Narnia inside a closet via a zone transition.

But… seamless – or at least very large – worlds have certain advantages, not least for the economy. If currency has mass and there is no universal banking, distance starts to matter. If distance matters, the price of “nice Chianti” won’t be the same in Bangalore as in Tuscany. (in fact, it is about four times as much) That jump between the desert and icecap that takes only as long as a load screen means that it is not hard to bring polar bear furs to the bazaar in the desert and that scorpion venom can easily be delivered to the ice lands. Nothing is rare and everywhere is local. Might there be a way to gain the advantages of large, seamless worlds, while keeping the advantages of a global nodal geography and staying within the small, zoned paradigm that hobbyists and indies have to live with? Here is something that might be worth experimenting with:

• Use a few large zones.
• Reduce the movement rate of characters to something sane. Seriously, using the “default” run in many game engines translates to simulated speeds that are only achievable with motorized transport in real life. Dropping the rates to something that humans can actually achieve makes a 4km x 4km zone take 45 minutes to traverse at a walk and half that at a trot.

These two things already go against the grain. There is increasing emphasis on convenience these days and physically slowing players down is anything but convenient. We are designing for immersion however. Now comes the potentially controversial bit… If two zones are very distant from one another, impose a time cost in travelling there. We have two ways of doing this:

1. Incommunicado - If it takes two in-game days to traverse the forty miles that are supposedly between zone A and zone B and the in-game clock runs at 6x real world clock speed, then that character is underway for 8 hours. The key is that it takes real time to travel between zones. If you want to haul your goods to a distant market, you’ll have to accept that your character will be travelling and unavailable for the better part of a workday. If you want to meet your friends for a run on the evening, everyone will have to plan ahead and send their characters to the meeting point ahead of time.
2. Hybrid Text/Graphical – We need not put the character incommunicado during the transit time. We can implement text zones in between the large graphical zones. On text MUDS, the nodes that are called zones in most MMOs and (and areas in NWN) are called rooms. The character could still be available via persistent worlds’ web page or game client in a series of transit nodes. If the travel is automatic, characters can still be accessed, managed, checked on and even re-directed. If it is manual, then the player traverses a series of text rooms.

Has anyone ever built a hybrid text/graphical world?

Some interesting ideas on PW economies

Some interesting ideas on PW economies

Chris (talin) Brown published an interesting concept for a PW economy that draws some inspiration from Sam Lewis’ GDC presentation on the subject. I’m not sure how it would work in practice as it relies on a hypercompetitive PvP environment ala Eve or Darkfall, but it is interesting.

Design Documents – Yes, you need them!

Hallsofvallhalla started a conversation on Friday questioning the value of design documents. I think he is mostly wrong and partially right. I’ll start with why I agree because that is easiest. Most design documents that I have seen are not terribly valuable because they focus solely on the color of the bike shed. They discuss things like level layout, class abilities, races, etc. and ignore the deep decisions about the physics of the world; how it actually works. The design doc should be useful to all team members; not just artists and designers. Now the other side of the argument:

Architecture Matters

Persistent worlds are certainly complex enough to require serious planning. Part of preproduction – and an important part of the design document – is figuring out how to do the hard problems. How will inventory work? How can it be implemented? Etc. Etc. Unless you want to constantly be throwing your work and starting over again, these things need to be worked out before you write a single line of code. All too often, I see freshly started projects publishing screenshots, which hints that they have skipped preproduction entirely.

While writing the Angela interpreter engine for Memotica, I’m reaching the point where I’ve got the core of the interpreter to the point where I’m writing the brokering mechanisms for actions and stimuli. I designed the overall, high level architecture of the engine over a year ago and looking back on it now allows me to continue without flailing about and redesigning the whole choreography. In short, the time spent then is saving me considerable time now.

The ship needs a rudder

Where is the project going? Is it still going in the same direction as six months ago? Or is it adrift and rudderless, buffeted by whatever is being talked about on the project’s forums?

A dirty secret about community/indy teams

One of halls’ argumenents against design documents is that it acts as a straightjacket that restricts creativity and makes the project less interesting to portential team members. One of the dirty secrets is that half of the people who show an interest in helping out a project are useless. They have neither the work ethic, nor the patience and tenacity to stick with the project and be productive. They will happily shoot the breeze on your forums and pontificate endlessly. Do you really want these people setting – and changing – the direction of your project? 90% of the other half are only valuable if they were recruited at the right time and there is consensus on vision; two things that are only possible after the valley of tears phase.

The valley of tears

Every PW project goes through the valley of tears. This is the phase in the project when the interesting theoretical discussions have been had and it is clear that it won’t take weeks to realize the world, but months and years. It will seem that “nothing is happening and the project is going nowhere” for long stretches as the foundations are laid. This is a time when no flashy screenshots are created, but instead the plumbing is laid in. In the worst case scenario, you will be the only person sticking with the project during this time. Projects whose leads allowed them to turn into designed by committee, vampire/puppy/rainbow monstrosities tend to die tragic and lonely deaths in the valley of tears; identified only by the lonely husks of once active forums that will one day disappear into the great 404. You didn’t let it turn into something that you are not entirely happy with during the pontification phase did you? Because it is your passion and drive that will see the project through to the promised land on the other side.

Please tell me that you are recruiting your team at the end of prepreproduction!

You have a prototype. It may be butt ugly. It may not be very performant and will need the attention of better programmers than yourself. The important thing is that the project is past the valley of tears phase, is picking up speed and has direction. The people you recruit at this phase will be attracted to:

• The fact that it has direction. Hey, we have all been on teams with no rudder or team stuck in perpetual pontification mode. Being on a team that is on the move has its own attraction and for years has been one that Luca Pancallo (Talad) of Planeshift has used in dev team recruiting drives.
• The vision. In the pontification (a.k.a. early design) phase, you will inevitably find that others want your goth-vampire world to be about puppies. Perhaps those puppies could have a vampire option as a compromise, but rainbows are much more important. The kinds of people who join because they read your design doc are true believers.

The live team that runs the PW won’t be the same as the one that initially works on it

I don’t say “built” or “delivered” as community worlds are never finished and are always works in progress. People come and go on the project and over time the composition of the dev crew will change. The people coming in will need to sign onto that vision. When a player (always a self identified “ideas” person) starts pontificating about how you need to change your world, you can point him to the vision. Not having a clearly defined vision contributed to Etilica’s death spiral. From the perspective of the leads, I was probably a rogue developer. If there was a design doc to refer back to, we probably would not have been in the habit of surprising each other with changes.

A final caveat. The document need not be set in stone

A design document needs to be a living document. You’ll want to prevent the pontificators from rewriting your design document, but you’ll also want the committed team members to effect change as long as they earn the right. As these committed team members get their ideas accepted, the design doc should be updated to reflect the new status quo.

How do people feel about meta-roleplaying?

Creating alternate player personas has a long history in roleplay environments and it does always stop at the character. Some players are open about their real world selves and are clear about the level of the roleplay. “Hi, I’m Bob the sales manager from New York, but my character is an evil elven mage”. Others meta-roleplay player personas to a greater or lesser degree. I never thought about it much and tend to assume that player personas – especially those players who are coy about their own identities – are likely to being meta-roleplayed. I thought about the issue again as there is a thread on the Planeshift forums about meta-roleplaying. The discussion’s OP clearly did not think it was a good thing and complained about “wasting time” showing a player the ropes when they already knew them. From the perspective of the meta-roleplayer, it makes sense not to let on that the player persona itself is being roleplayed.

My question is how do people generally feel about meta-roleplaying.

There was once a player. She was a good roleplayer and had an easygoing and friendly personality; which made her easy and fun to play with. This made her popular wherever she went. It made her so popular in fact that she would get a storm of tells whenever she logged in and felt that her character received “special” treatment. So one day she tried an experiment. She created a new account and logged in with a new character on her alt account. She found a completely different experience. She found that people behaved less familiar and more respectfully with the new “player”, but also more aloof. She considered it refreshing to simply be able to roleplay anonymously and developed a habit of using alt accounts, sometimes dual boxing them to misdirect any suspicions that might develop that these multiple players were in fact the same person.

On an old Neverwinter Nights PW, the GM (DM in NWN parlance) team members always used alter egos when logging into the forum or game to mask their other identities. This was usually done to shield the GMs from a storm of GM’ing related tells when they were off duty and to prevent players from acting differently around players that they knew were GMs. Some were an open secret and everyone knew that GM persona X was in fact player Y, but some were closely held and players in the community would gossip endlessly about the identity of new GMs.

Then there is the whole subject of myspace roleplay.

My last example is potentially the most interesting as it had shades of a story about a tree. The player was a man. He played a female player playing a female character. There were multiple levels of roleplay. He had gone to great lengths to build his player persona. He had created a yahoo profile many months beforehand using the femininized version of his name and a photo of a moderately attractive woman in the profile. This is a classic meta-roleplayer step; to give the alter ego a believable internet footprint that can easily be googled, but not enough to cause cognitive disconnect when “she” does not meet other players at gatherings or speak to them by voice. The female “player” was extremely outgoing in the community that “she” played in and became a highly networked player. Over time, she amassed a small following of “fanbois”. He was a US Army reservist. When he was deployed to Iraq, she went to Iraq and the community followed “her” experience there. She was able to acces the game from the war zone and remained active.

The meta-character had developed personal relationships with some of the other community members. When she was coming down to her last weeks in Iraq, she sent a quick message that she had been badly hurt by an IED. I had been expecting this. The player persona was starting to make commitments to visit other players after returning from the war zone; commitments that could never be fulfilled without letting the cat out of the bag. He was getting in too deep with her and killing her off in Iraq was a wonderful way to get out of the bind he was in. She “survived”, but was only intermittently active and eventually disappeared into the ether altogether. Aside from my misgivings about having highly networked players who are meta-roleplayed, I’d certainly be happy to have him play on my next world. That guy is a master roleplayer.

How do others see meta-roleplay?

Deep Physics – Moment of Inertia and Animation Profiles

In the last installment, we gave a high level overview of rotational energy, momentum and moments of inertia. None of these things are covered in modern “physics” engines. What we call physics engines would better be called “rigid body” engines. This means that we need to devise a way of dealing with these attributes.

Moment of inertia depends on the distribution of the mass relative to the pivot point. This means that you can simply define a number and leave it at that. You have to track your mass distribution. We already have a tool that gets us part of the way there; the 3D mesh from the model(s). If we have a character model and a sword model attacked to a dummy node located at the character’s hand, we have two defined objects and a constant mass, bit the moment of inertia changes every time the character moves. The brute force approach would be to devise a mathematical model – a single equation – to determine the moment of inertia at each. Our swing motion is a smooth motion through an arc and the position and orientation of each mass in that motion results in an and ugly and expensive to solve equation. This is impossibly impractical for each motion permutation, so we’ll impose a couple of tricks.

The Horse can be approximated as a sphere

The above statement means that we don’t need to be exact and we can get away with a lot of approximating. Specifically, we’ll do two things.
We have explicit time slices where we know the exact configuration of the masses in our character/sword system because we have the animation key frame data. We’ll solve I for each key frame only and hand wave/approximate it. This is also how physics engines approximate rigid body motion. They don’t solve Hailtonians or Lagrangians. They step through time slices.
We need to have the mass distribution of each object. It is right there in the 3D mesh and we can pull it out with an algorithm. We can even go a step further and reduce that mesh shape to a collection of points representing the mass distribution of the object. The moment of inertia for a point mass is simply its mass times the distance from the axis of rotation. This makes for a speedy calculation.

The leftmost image is the blade from the sai model that eq2001 put up on turbosquid. The middle is that model with a rough approximation of its mass by individual point masses superimposed. The rightmost image is the resulting “mass cloud”. At each keyframe, we can now easily determine the total moment of inertia. This allows us to calculate such things as angular momentum, kinetic energy of rotation, etc.

In fact, we can take it a step further. If we agree that a character’s “strength” attribute defines his/her ability to generate torque and that a given character would have a “terminal rotation velocity”, where the motion simply can’t accelerate anymore, then we have a few more tricks up our sleeve. If the motion has not yet reached its terminal velocity, then we can – in principle – shift the keyframes around in time. Weaker characters, or ones wielding heavy weapons, now swing slower than strong characters or ones wielding light weapons. We can call this shifting of keyframes an “animation profile”. It is essentially a list of time/space shifts in the keyframes. This requires a change to the way that clients typically handle animation calls; namely that an additional parameter of the animation profile list.

Deep Physics – Momentum, Moment and Rotation

In this installment of the deep physics series, we’ll continue turning animations into salad by looking at the rotational dynamics in animations. As a note of warning to the reader. I will try to explain some physics in a clear manner, without equations, but there is an element of leaving the bike shed behind in this discussion.

We’ll refer back to our sword swings in Monday’s post as our starting point. The important thing to note is that swords do their fine work by turning rotational kinetic energy into entropy. We’ll discuss the role of the first two laws of thermodynamics in a later installment. But before we can deal with energy dissipation, we have to get to the point where we have that energy to dissipate. This means accelerating the sword through its swing arc.

Rotational kinetic energy is analogous to linear kinetic energy; with the moment of inertia standing in for mass and angular velocity standing in for linear velocity. Moment of inertia is a funny beast – and an extremely important one in the dynamics of mêlée weapons. Inertia is the predisposition for all objects to continue with their current state – i.e. resist change. Moment is a term for a bending/turning force. Thusly, moment of inertia is the predisposition of an object to resist changes in how fast it turns. Moment of inertia is composed of how heavy an object is and how that weight (mass really, strictly speaking “weight” is the force mass experiences under the influence of gravity) is distributed. If you were to hold a bucket of water in your hand and spin yourself in circles, you would find this much easier to do than if you were holding that bucket of water on the end of a ten foot pole. The latter had a higher moment of inertia, even if the mass is unchanged.

Another interesting thing about moment is, the more MoI that a rotating body has, the harder it is to stop; obviously. This means that it has a greater rotational kinetic energy and momentum of rotation; also known as angular momentum. This is of course why a maul head on the end of a 3 foot handle is so much more effective at splitting wood than one held directly in your hand. So the shape of a sword and how it is positioned determine how hard it is to swing, as well as how hard it hits.

So our sword moving through an arc hits something. We know this because the physics engine determined that the collision shape of the sword hit the collision shape of something else. We simply assume that the sword comes to a complete halt, or that it rebounds depending on the material that it strikes. Whatever momentum is lost translates to kinetic energy lost to entropy. This gives us a clear, consistent, measure of damage that is consistent and removes the need to have a “sword” entry in a weapon damage table. In fact, it relieves of the need for such a table at all for kinetic weapons. We simply track kinetic energy and changes.

In the next installment, we’ll review a methodology for tracking moment of inertia, angular velocity, momentum and kinetic energy.

Roleplay Builds

Dana Massey of mmorpg.com wrote an inflammatory piece last week, essentially calling roleplayers on MMOs crybabies and drama queens. The following day, Sanya Weather, also of mmorpg.com and eating bees, wrote a more nuanced piece laying out the problems that MMO operators face when setting up a roleplay server. Given the extra support costs associated with roleplay worlds, it is not a surprise that operators don’t put too much investment into roleplay servers. Also, on the so called roleplay servers, many (most?) players are there simply for the restricted general chat and character naming schemes and not in it for the RP at all. This is a problem for roleplayers. Deeply immersive roleplay is a bit like canoeing on some wilderness lake. You can enjoy the mist, the quiet, perhaps see a moose on the lakeshore and hear a loon. If someone comes along on a jetski, there quiet is shattered, the moose is scared off and the loon flies south for the winter a bit early. The canoeist, who’s trip has effectively been ruined sees only two options; to stew and be angry – becoming like “those who shush you on a campus library on a Friday night” to use Massey’s example – at the inconsiderate jetskier, or give up on enjoying nature and also jetski. Just as there are those who choose to be in the library on Friday night and there are those who choose to canoe on the deserted lake at dawn, there are those who simply want to roleplay in peace. They search about for guilds of likeminded individuals, search for the nooks and crannies where they can roleplay unmolested, away from those who don’t understand, or respect RP. Many simply give up roleplay in persistent worlds because of the lack of immersion. In the NWN persistent world community, those worlds with “lite roleplay” restrictions eventually (quickly actually) turn into “no roleplay” and the only ones where roleplay is really possible are the IC obligatory ones.

Even in what should presumably be the roleplayer heaven of community run, ic-obligatory, roleplay worlds, all is not well. The playerbase is torn between the gamist instinct and the simulationist and dramist instincts. The gamist players- being more focused on the game aspect – will invariably end up with top flight builds that might be a bit of a stretch in terms of character development logic. A certain subset of the playerbase will deliberately gimp their character builds because a blind knight with a severe limp is an interesting character to play. Another subset won’t deliberately sabotage their character’s build, but won’t stick to the excel sheet plan if the roleplay direction dictates something else. This is how you end up with wizard/rogue/shadowdancer/blackguard combinations. This leads to tension between the powergaming gamists and the other two factions and lovely message board threads about “rp builds” and lectures from the gamist faction about the Stormwind Fallacy.

In her article, Sanya Weathers lays out all of the requirements for implementing a roleplay server in a normal MMO environment. In addition, near the end she muses that the game needs to be designed from the ground up to accommodate RP- which – like hardcore PvP – is a nich player set with a unique set of requirements.

All these special needs for a population that won’t exceed 10% of the playerbase, and can’t agree on a single definition of roleplay? It’d almost be more cost effective to make an entire niche game for this playstyle, rather than trying to make a massively multiplayer game that equally appeals to the roleplayer and a mass market audience.

I’m not sure I completely agree that there should be no OOC communication channels. Like David Bowers, I feel that OOC communication actually helps strengthen roleplay. Even NWN fails at being a complete immersion environment, because at the end of the day, its diku-ness is hardcoded in. There will always be a powergaming versus RP tension, even in the best of communities. So what can be done? There are two things in addition to Weathers’ list that can go a long way to building a perfect RP storm.

Character Applications – If you want to play on a world, you first need to familiarize yourself with it enough to write an application proposing a character concept to the staff. If you want to create an additional character, you need to apply for it as well; along with each additional one. Some regard this as an annoyance. That is precisely the point. The theory is that roleplayers who want to be left alone in peace are more willing to jump through these hoops than the inconsiderate, immature, anti-roleplayers who want to grief them as well as the “roleplay lite” players who don’t actually do much roleplaying. Most of the latter two groups are of the opinion that “applications are stupid”. Text MUSHes and some older NWN RP worlds used this technique very successfully.

Rethinking rules – This one is trickier, but anyone designing a roleplay world needs to address the powerbuild/rp-build dichotomy. The best way to do this is to make the character and player domain knowledge one and the same. Make the best swordsman on the server the server be the one played by the player with the most dedication to roleplaying a swordsman; not the one who always skips interacting to hunt. This is not to drive the gamists off, but rather give them incentive to be more IC. By replacing spreadsheet analysis with IC discussions of strikes, counterstrikes, tactics, motion analysis and even allowing them to invent new moves and new styles (via player created content), you remove the powerbuild/rp-build build tension by conflating the two.

Deep Physics – Rethinking the Role of Animation

For our first step into the deep physics, I’m going to advocate something that would get me pilloried by every professional designer who read it; but since I’m a hobbyist off in a highly specialized corner, I won’t be read and I’m safe. I’m going to advocate rethinking animations and their role; making them a design element, rather than an art element.

Let’s take a look at a sword swing. Traditionally, 3D worlds follow a tradition set by 2D worlds. Most “sword swing” sprites are played whenever an appropriately equipped character makes a swing attack; which is actually resolved by rolling a random number and comparing tables, or calculating an equation(s). In a 2D environment, graphics are displayed by sprites and by necessity are decoupled from the action. The sprites exist only as a feedback to the player. This fits smoothly with the conventions of highly abstracted inherited from the earlier text MUDS and the tabletop RPGs that inspired them. Quite simply, there is not much of a conceptual leap going from a text MUD to a 2D world. Most 3D persistent worlds follow this tradition as well. The swing animation on an avatar is simply visual feedback to the player.

From the perspective of roleplay, this is unhelpful. When using highly abstracted die rolls and table checks, there is a certain degree of (to put it euphemistically) “making things up” when roleplaying. Also, the character’s domain knowledge is quite different from the players domain knowledge; forcing the “how to play your character” discussions into the OOC space.

What if the character’s domain knowledge and the player’s comain knowledge were the same? What if instead of being feedback, the animation was the swing? A “hit” comes whenever there is a collision. We’ll come to the details of resolving “damage” in a later installment. Just keep in mind that we’re actually using the animation itself to make the attack; promoting the swing animation from dressing to salad. By now, you are probably thinking of the infamous female DPS bug in Age of Conan. This is perfectly reasonable, but please bear with me for now.

For the record, we should probably avoid combat moves invented by animators who never studied swordsmanship. They will look good, but won’t work very well; especially when we introduce angular acceleration and angular momentum concepts later on. For our purposes here, we’ll look to the Lichtenauer school of swordsmanship – also known as the “German School” of swordsmanship – as practiced by the European martial arts revivalist community. The oberhau makes an excellent move to examine. It is one of the basic moves and is very simple. It contains two components. The rear foot takes one step forward and the sword is dropped vertically onto the opponent.

One of the things to note is that the footwork can be treated separately from the swing and the student is encouraged to practice the footwork separately as the same steps get used repeatedly in different situations. In game engine terms, this means two animations that are blended; the forward step and the overhead sword swing. We can simply “tie” the two together with an action and leave the hit determination to collision detection.

If one character attacks another with an oberhau, his opponent has a few different options available for countering. One is known as a Pflug, which itself is actually a stage in a thrust; essentially a block/counterstrike situation. This opens up a whole range of “game rules”. Does the defender realize that it is in fact an oberhau attack? (a skill and experience measure) Does he realize in time to make his counter move? (again, a skill and experience measure). How quickly can he get his counter moving? (reflexes) Which countermeasure does he use? Is it a feint? If so, can he detect that it is a feint in time? Etc.

Note that there is no presumption of gameplay type here. If it is a low latency, twitch environment, then the player might be expected to micromanage his oberhauing and pfluging. It might just as easily be an AI driven environment, where the player makes high level decisions and allows the AI to make the moment to moment decisions about which move and countermove to use. It might be a player-scriptable environment, where players are encouraged to script combos and counters. It might be a mix of two or more of these approaches.

Also, when the player’s domain knowledge and the characters domain knowledge are the same, advice like “you can block an oberhau with a pflug and stab the guy in the face” becomes IC as well as OOC advice. This can only deepen immersion.

The Deep Physics – Intro

There was a recent change to Planeshift’s crafting system. It received criticism from a portion the playerbase, largely those players felt that it added too much realism at the expense of fun. This is a common complaint and it is certainly understandable. Anyone who has ever grappled with the grappling mechanics in 3rd edition D&D understands this. Longtime MMO designers, such as Brian Green and Damian Schubert regard realism as a false god; one that gets in the way of gameplay.

What exactly is the problem with realism?

One of the delightful things about the old first edition AD&D was the smorgasboard of detailed, realistic special case rules for everything from loot in NPC pouches to detailed (and graphic) critical hit and critical miss tables that took seemingly everything into account. Rolling critical hits using the optional rules from Dragon Magazine was a mini-game in itself. Half of the Dungeon Master’s guide and almost all of the later rulebooks from the Fiend Folio onwards were an anthology of these special case rules. AD&D was in the tradition of the fantasy literature of Doyle and Tolkien. It had started as a game and had layer after layer of realism added and nurtured my simulationist, world building urges. It also had no sense of balance; that word that seems so important today. Viewed strictly through the game prism, AD&D was a horrible hodpodge. 2nd edition AD&D was the first attempt to simplify this multi-headed hydra, but it was not until the 3rd edition that D&D’s tyranny of special cases was substantially contained and even then – as with the grappling rules – this was not entirely so.

The problem with realism is the same problem that 1E had. In 1628, the Swedish navy’s newest warship set out on its maiden voyage. The Vasa was the king’s pride and one of the finest warships in the world; for about an hour. As it sailed out of port, it capsized and sank. It was recovered and restored during the 20th century and is now a museum exhibit in Stockholm. The reason it sank is that King Gustavus Adolphus insisted on putting more cannon on it than it was designed for, making it top heavy. Building lots of special case rules on top of a game is like building a top heavy ship.

Most modern persistent worlds are viewed as games rather than places. The exceptions are the social worlds such as Second Life; which follow in the footsteps of the MOOs of yore. A thematic adventure world that is a place first and a game second goes against the grain. This was not always so. Twenty years ago, most worlds billed themselves as simulations. In my lightweight rulesets post a few months ago, I suggested using physics and a lightweight ruleset instead of a heavyweight ruleset. The universe as we know it arises from a handful of rules. If you look at a ball game, such as tennis, something comes to light. The rules of the game define the boundaries of what good play is. The rules never define that a level 60 tennis player has a 95% chance of putting the ball on path X and that a level 55 player has a 80% chance of playing off of it. Newtonian mechanics defines how the ball behaves. The player simply chooses how he hits it and the designer simply defines the dimensions of the court and the scoring system. Unfortunately, most PW designers – as is most of the population in general – are woefully scientifically illiterate. Most people regards science – and physics in particular – as “complicated”; failing to understand that science – and physics in particular – is all about simplification. Because of this perception of complexity, when most designers do create realism rules, they invariably make them overcomplicated; and end up creating a Vasa.

The purpose of this post is to introduce a new series on building the physics which designers would then build the “rules” on top of. It is named in honor of the term CS Lewis used in the Narnia Series. Naturally, these will be lightweight rules and naturally, this series will have a simulationist rather than gamist bent. If you are a “game” designer first and foremost and enjoy the game design challenges that Dan Cook and Brian Green like to post on their blogs, then this series is probably not for you. If a framework where you can water down the wine for a little extra profit at a fool’s expense, tinker with the balance on your sword to bet match it to your swing style, smell the campfire, and feel the drizzle on your skin as you see the ruins through the mist sounds interesting to you, then this series is for you.

Postmortem: The Etilica Soulflash – Part II

Continued from part I – (I realized that I’d never finished the Etilica Soulflash story)

When the soulflash went live on Etilica and the lore changes went into the documentation, along with a note on the forums detailing how death worked. There was uproar!

Generally, Etilica’s community fell into three camps:

1 – Those who did not think too much about the ramifications of everyone respawning – or were okay with it – and just found it kind of cool to find dead bodies from player character now and then. If you were on the server during off hours when it was very quiet and happened to be in a far flung zone, coming across a shell from a respawn hours ago was a concrete sign that you were not alone. Also, PCs could get a small amount of experience from cremating a shell and it served as a roleplay device

2 – Those who did not think too much about the ramifications of everyone respawning – or were okay with it – and were simply happy to rezz shells and do bizarre things with them. It quickly became de rigueur for evil characters to rezz shells of fallen enemies to mock them. The whole “turn your worst enemy’s cast off corpse into your mindless, living zombie butler” was part of the intent of the system and I heard that my own character’s shell was used for precisely this kind of roleplay. I was also given vague hearsay warnings about inappropriate usage, but was never told the details.

3- The last group was the ones who were not okay with the everyone respawn lore. They were extremely vocal about it. They were completely fine with the fact that their character was more or less immortal. What bothered them was the fact that slaying the orc king would now seem utterly pointless because he returned to life. They would be trapped in a groundhog day scenario forever.

They had something of a point. The problem was this was in fact already the case. There were a number of repeatable quests where the PCs had to kill named villains and bring back their heads/rings/etc. or rescue the children that they had kidnapped. Everyone conveniently overlooked the fact that these named villains – whose lairs we would probably now call raid instances – would probably be reset and ready to fight again even before their ring was turned into the quest giver. Where is the closure in rescuing the children when you go back out and there they are again? This is a problem that every PW, from the small text MUDs to WoW experiences. Players consume content. In the absence of compelling GM activity and in the absence of player driven roleplay plots, players will grind and run quests during quiet times. But this is another problem for another time.

These resistant players were correct about the groundhog day effect. The problem was that they were not really thinking through the effect of having a sub-population that was effectively immune to death, while the rest were. And for the record, if a god restores you to life every time you die, you are pretty fucking immune to death. They despaired at the pointlessness of it all. I despaired at the thought that the logical way to play the alternative out would be to effectively turn most NPCs into second class citizens at best and slaves at worst with the respawners as a divinely chosen aristocracy. Eventually I implemented a compromise. Everyone – PC and NPC alike – still soulflashed. All PCs and 10% of NPCs (all named bosses and 10% of spawns) also took their gear to the fuge plane. There people were destined to be respawned and were collectively the immortals. With such people, the shell left behind was naked. The rest of the NPCs left their gear behind when they soulflashed. They were truly dead. It was a sloppy compromise and I was never really happy with it; not least because I still had to paper over the cracks in the lore and pretend that human nature was not at play here and that the world would not develop a caste system. Nevertheless, the changes did not go over well and some people left. Ironically, one of the most vocal of the resistant players was a member of the dev team. He had ignored the posts on the builder forums leading up to the insertion of the new death system/lore into the world and only spoke up afterwards.

I took two lessons away from this:

1- “Everyone Respawns” is not an acceptable alternative to “Only Players Respawn”. Some players will happily ignore the knock on effects of their own serial resurrection, while getting hot and bothered about NPC resurrection. This reality and consideration of possible alternatives eventually led to HSM.

2 – In addition to being competent team players, devs actually have to participate in the developer discussions. This is kind of ironic in a way as – at least at the level of technical skill required to work on NWN1 – all development PW discussions are essentially bike shed discussions. Users don’t pontificate about ERP software, but they’ll do so endlessly about PWs. On the forums, they’ll give unsolicited advice on changes to the world that are either technically impossible to implement or miss the point of the world’s vision. If they are not posting on the forums, they are blogging. I know this phenomenon quite well. Over on Project Angela, the brainstorming discussions of what was to eventually become the Memotica design language were full of debate. I had trouble keeping up sometimes. When the discussions reached the advanced stage where deep thought was required in solving tricky design problems, I found myself being the only meaningful participant as often as not. When it came to actually doing the grunt work in the formal language design and writing the interpreter, I was completely alone.

In the case of that guy on Etilica, I still don’t know why he did not know what was going on.