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.

It is never just a game

I keep track of several roleplay PWs on various platforms. One of them is Arelith, an NWN1 world. I highly respect the team that built and maintains the world. Their world is a mod of a seven year old game that last had an expansion nearly five years ago, yet the community is still healthy and active.

One thread on its forums however caught my eye, because it is about a design decision that makes me cringe. Like most NWN PWs, Arelith is a diku style world with a serial martyrdom death system. It has the slight variant to this that a dead character can either respawn, or wait until someone brings their corpse somewhere to be raised. If they are revived, they escape the death penalty that would otherwise have been applied. So far, this is typical NWN and there are many variants on this theme; some of which leave the player’s camera at the scene of death and others that move the camera to a death plane, leaving the corpse behind that can be revived. In NWN, the camera is tied to the PC avatar, so the latter is usually accomplished by moving the avatar to another location and leaving a corpse object behind. In Arelith’s case, the corpse object can be picked up and it can also be destroyed. The owner of the dead character currently gets a message indicating whenever their corpse has been picked up, dropped or destroyed, but not who did it. If the corpse has been destroyed, the destroyer gets a skull, a small amount of money and the “victim” loses his/her get out of jail free card and must take the respawn penalty.

This is where the fun begins. There is a mechanism where one player can make gain by inflicting other players with a perceived loss.

I’m not privy to the motivations for that design, though I suspect a pen and paper (PnP) D&D influence. Most likely, the convincing arguments were on a gamist and/or simulationist basis. In the former case, the idea that someone would want to avoid the “legitimate” penalty for failure is anathema. In the latter case, there is a realism factor in carrying corpses. I’m not actually interested in the specifics of the system or in the reasoning behind it so much as in the effect on the players. Some players have little or no advancement motive. If the player does not derive pleasure from counting points, grinding is a job; an entry level, low pay, low status job and loss of avatar capital is akin to not being paid for putting in your hours at McDonalds. Such players will go to great lengths to avoid a death penalty. If there is a way for them to avoid it by waiting for a rez, then they will do so.

If another player comes along and takes away that escape clause, it will cause distress. There are lots of arguments that the whole thing is entirely appropriate because it is in character (IC) and that it is just a game, so nobody should get worked up. Such arguments forget a little aspect of human psychology. When people feel that another player – as a player – has screwed them – as a player – over, then what is IC and what is metagaming simply does not matter. It does not matter if that player feels that it is entirely legitimate that the victim accepts the penalty. The victim feels that they are losing hours of grinding at the hands of another player; especially as it is not on a consensual basis. It is as if someone jumped on their sand castle and losing your sand castle this way is never just a game.

If you wanted to create a gameplay mechanic tailor made for griefing, you could do little better than Arelith’s corpse bashing, except perhaps by adding permadeath to the mix. Well, you could remove the message that a character’s corpse has been destroyed, causing them to wait in vain.

Anyone who has ever read through Nick Yee’s excellent work researching MMO player motivations may have caught the fact that the roleplay motivations are quite independent from other motivations. They might also have noticed that the roleplayer motivations are held more often by females and older players and the competition tends to be a motive for younger, male, players. In short, though you can’t make the blanket statement that roleplayers are carebears, the transect between the darkfall playerbase and the roleplayer motivation is only a fraction of the roleplay crowd. If your world is Darkfall meets roleplay and you are building for those players whole like to be IC while they gank people, then you can just tell the victim that he is being a whiney carebear and be done with it. Otherwise you have to do your best to “goon proof” your world.

There is a general rule that 1% of the population is sociopathic. This does not mean that they are raving serial murderers, but it means that at least one percent of the population – a subset composed almost entirely of males, so 2% of all men – lack empathy. Some are simply indifferent to the needs of others. Others actively enjoy inflicting anguish. The anonymity of online games is an attractant to these people in the same way that sweets attract bears at a campsite; so we have to reckon that our sociopath fraction is higher than 1%. Even if there was no gain to the character that destroyed the corpse, such people will derive pleasure from it for its own sake. That world currently has a problem with a griefer who repeated returns despite being repeatedly being banned. If he were more sophisticated, he’d not be attacking live characters, but instead anonymously bashing corpses. Such an individual could operate indefinitely, cause a great deal of psychological harm and never be caught. How many such individuals are currently operating this way on Arelith, using the IC cover that their character is evil? In addition to the bona fide sociopaths, a sizable portion of the playbase will not be averse to putting the screws to someone outside their monkeysphere if there was something to be gained from it. They’ll give plausible IC justifications of course, but the fact is that they – as players – are defecting when they harm other players in a non consensual way. This may sound strange coming from a advocate of strong IC systems, but “it is IC” can also be used as a pretext for a player to be a wanker. A “be nice” rule is meaningless in such an environment.

With this in mind, consider that your highly networked players are statistically more likely to be older females. 40 year old librarians who live with three cats and can name every character from the Wheel of Time series are a bit more likely to end up victimized by such a scheme than to be perpetrators. It is a hard fact that some of your players – the highly networked ones – are simply more valuable to the health of your community than others. These people won’t say a word, they’ll just leave for greener pastures and their friends will eventually follow them. This has happened before. I’ve spoken to one roleplay NWN2 PW admin who had his playerbase decimated by a something awful faction moving in. (Edit) Some of them (SA people/goons) seem to be excellent roleplayers, but they’ll still leave your world as a bloody, empty corpse if they don’t like it; and still might anyway even if they do. (/Edit) Now imagine if goons invaded your world? Do you have any systems that can abused to empty it?

The question I’d have for the server admin is whether he/she has an overview of the usage patterns of this bashing feature. Any time you have a gameplay feature that can be abused, you should assume that it will be and closely monitor it. The best way would be logging corpse related actions (perp playername & character name, victim playername and character name, the races of the two, was it bashed? Dropped into a container? Rezzed? Etc.) to a database and periodically pull it into Excel to data mine it in a pivot table. Such surveys would tell the server management who is doing what and under what conditions and would let them easily root out abuses of the system.

As for player behavior, he/she should also consider game theory and that if there is a gain and no penalty for defecting, eventually defecting will become the norm. He should resist calls to exacerbate the problem by removing the message that the corpse has been destroyed and instead give a clear indication of who picked the body up and what they did with it (e.g. if it was put down and where or put into another container). Such accountability may be metagaming, but by exposing players to a possible tit-for-tat retaliation if they defect, it enforces the be nice rule.

Postmortem: Etilica’s Lag – Part II

Since this is post two of the lag theme, I’ll catalog the things that I would have done differently as a live team dev. Later in the week I can delve into design and management lessons. I’ll try to keep the lessons generic and skip the platform specific ones. What I’d do differently taking over running the live team of a world now:

Perform an exhaustive survey of the world – Let’s not trust the documentation; even if it exists. Even among professional teams, the design docs are likely to be outdated. Let’s assume that we don’t have a large block of time for a handover. Up to date design docs and handover meetings are luxuries that professionals have. The alternative that amateurs have is to survey the server. Don’t change anything until all of the resources are understood.

Run scheduled stress tests – Do you have a new AI package? Have you completely revamped your honey pot zones? Do you have a fancy schmancy new dynamic content generator or crafting system? Run a scheduled stress test on a dev server before making those changes live. Advertise it to your playerbase like you would an event. Beg, borrow and steal players from other places just to be there for the stress test.

Make sure that there is only ONE definitive version of the module – From Thrym’s observations of the Etilica in the comments on part one, I suspect that he is looking at a different version than I worked on. I know that there were multiple, unsynchronized versions of the module lying about. Sometimes it was a mystery as to who had a version of the module with which changes. I made the biggest changes and made the most cleanup, but other versions sometimes slipped into the live position or were passed to builders. Etilica should have been committed to a version control system such as Perforce or SVN, so that changes could be tracked, rolled back and there would be only one head revision.

What I would not do is start overhauling the module at the kind of rate that I did last time - There were certain things that needed to be done to whip Etilica into shape that were not really practical, or were just so painful to do that nobody wanted to do them. First and foremost, there was the issue of the half-implemented and orphaned script packages and other resources. A huge portion of the module’s resources were deprecated, but could not safely be removed without an exhaustive and time consuming survey of the mod. There are no tools for that engine that allow you to search for deprecated and unused resources. Moreover, many obscure resources WERE used somewhere. You would be surprised how many different AI scripts were in use and how many item and creature templates popped up somewhere; but making changes too rapidly in a cruft encrusted environment is asking for trouble.

Postmortem: Etilica’s Lag – Part I

Several former Etilica players have commented about the lag on that world. That is my fault and I learned a great deal from it. Allow me to explain. In part II, I’ll list what I would have done differently if I were to work on that world again.

The buzzword on ETI is cruft. ETI was built by three generations of builders who overlapped very little or not at all. It had about 250 areas (small zones) and an immense number of placed NPCs when I started overhauling it in earnest; even in places where players rarely went. I think I counted 400 placed NPCs when I started cataloging them. ETI’s NPCs also had a heavy heartbeat script (which fires every six seconds on that platform) and heavy combat scripts; courtesy of me. I think in many respects, it catalogs a list of mistakes that can be made when building and running a server. There are many things that can be learned from examining the life and death of ETI, but here I will concentrate on my lag. When I took over as lead builder, I made two server killing mistakes:

I did not completely familiarize myself with the mod as much as I should have – This was ultimately fatal. There were big parts of the module – especially in the desert (about 2/3 of the world was in the desert) – that were so hard to get to that I only ever saw them in the toolset or via DM client teleport when testing. The very first thing that I should have done was to catalog all of the areas and familiarize myself with them; even the rarely visited ones. I quickly grew intimate with the high traffic portions of the mod, but not the low traffic areas. Had I done this, I would have been aware of the placed NPC count.

I did not stress test the server before making changes live - I brought in a couple of AI systems that I had worked on for my NWN version of Epoch. They included custome a waypoint walker, a new heartbeat routine and a heavily modified version of Jasperre’s combat AI package to spice up combat.

Altogether, they were heavy in terms of CPU. They worked fine on Epoch, which was small and heavily dynamic. Most NPCs were only around when there was actually a PC in the area. On ETI, this caused an enormous amount of overhead on the server. It only took one player getting into a heavy fight somewhere on the server to cause serious lag. Also, there was a rebuild of the main high traffic areas. They were arguably nicer, prettier and more immersive. They were also prone to lag afterwards as well. Sometimes a plain soundstage is the best. A proper scheduled stress test would have revealed this.

Postmortem: The Etilica Soulflash – Part I

Since subject of death systems came up in the last post, I thought I’d elaborate on the death system used on the long defunct NWN persistent world Etilica. Etilica’s final death system came about in an accidental way. It originally had a fugue plane death system; where the player is teleported to the afterlife on death, leaving a corpse behind. It had stopped working when an admin who could not script installed a script package that overwrote one of the server events that the old death system used and I had more or less a free hand in fixing it. So I got to working on the appropriate NWscript fu.

My goals were simple. I was not looking to overhaul both the mechanics and lore of the death system, but fix what was there and possibly make it nicer. I always disliked the jarring instant teleport that is typical of fugue plane systems. One moment you are in combat and then suddenly you are looking at a load screen. I set it up so that the player got a popup on death asking them if they wanted to wait for a rez or respawn with a penalty. If they respawned, then they went to the fuge plane from whence they could exit and go to the bindstone that they had last selected. I also disliked the generic corpse object that was left behind. Since that version of NWN did not have the SetName() script command, players could not tell who’s corpse it was. Why not make a copy of the deceased PC, kill it and leave it behind so that everyone knows who’s corpse it was? It can be removed when the player leaves the fugue plane. Great! I fixed the problem and added a nice tweak!

Except that I did not properly test it before putting it into the live server. The problem was that the clone was rezzable. Sooner or later, a well meaning character was going to pull out a raise dead scroll after a player had hit the respawn button, but before the clone was cleaned up. When this happened, they effectively had a zombie on their hands. It did not even have a heartbeat script, so it was more of a standing vegatable. This being a roleplay server, the players ran with it and it was the source of some fantastic RP. I could have just fixed the clone so that it was not rezzable anymore, but after seeing the RP, I had an idea; and thus was born “the shell”.

I saw a way to logically resolve the whole PCs respawn and are not lootable, but NPCs perma-die and are lootable problem. After a few seconds (or when respawn was clicked in the case of PCs), everyone respawned and everyone got a new body. An empty shell was left behind. The difference was that the PC’s shells took their gear with them. To give some sort of plausible cover, 10% of all NPCs (randomly determined) also took their gear as well. The cloning, killing and stripping process caused the corpse to jerk about a bit, so I added a flashy effect to cover it. This was the soulflash; when the soul left the body (and sometimes took possessions as well).

I came up with some lore that shells could be rezzed (and made the appropriate technical moves to make them viable mobs) to be what would effectively be a zombie; a golem if you will. As this golem was a mindless similarcum of a living person and was in fact their old body, the idea of a shell would be horrifying to the populace. People burned shells quickly to prevent either necromancers from turning them into undead, or other malcontents from raising them from the dead and using them as living zombies. I also reckoned that since in some cases the soulflash also takes the possessions, that there would be a prohibition against public nudity; lest that person be mistaken for a shell.

To be honest, I never really delved too deep into the ramifications of everyone respawning. The background that I came up with was that everyone respawned, but I was never really happy with this. I realized what a profound effect this would have on life, but I was not prepared to venture into the sort of society that would create. Nor was I about to start those changes on a live server with an active playerbase.

When I tried to discuss it among the builders and GMs, there was a distinct lack of interest in the subject; either positive or negative. As the server owner was too busy playing WoW at the time to even check in on the world that was ostensibly his and I was the member of the builder/GM team with the highest degree of involvement, I was the de-facto lead. Finally I posted on the developer boards that I planned to put the lore and technical changes in if nobody objected. There were no objections and after a week I made the changes live.