Just a reminder that there will be a quest tonight, in 90 minutes of the time of this posting.
It's gonna be a good one but we need a good turnout, so make it if you can!
Monday, July 30, 2012
Friday, April 27, 2012
Fixing What Ain't Broke
We rolled out a bunch of new code during the middle of this past week, and the change I posted contained these lines:
While I cannot discuss the specific case of the recently rewritten DOT spells (I rewrote them as a part of a still-secret new feature), I'll use another recently rewritten spell to illustrate. Back in early April I rewrote the mirror images/astral projection/shield of skulls spells. Briefly, the reasoning was this:
Trying to extend and modify code like this to add new features is similarly difficult; not only do you need to figure out how it works, but you need to figure out at what level in the logic the new feature needs to be added. And wouldn't you know it, huge swaths of the game's code are written in a similar fashion. Either a lot of code is used to accomplish something very little (which makes the code hard to maintain, extend, or modify), or too little code is used to accomplish something very big (in which case the code causes the game to crash whenever someone does something out of the ordinary).
I suspect that most of the game's past coders weren't thinking about how easy their code would be to maintain in five or ten years, and that mentality resulted in a lot of garbage piling up without anyone cleaning up**. Such an approach to code development is not sustainable though, and that approach usually leads up to a major breaking point. In my mind, Dark Risings reached that breaking point right around the same time I took over as coder and the game was crashing on a daily basis.
Although I have no formal training in anything having to do with programming, computer science, IT, or anything like that, my programming mantra is to do things the "right" way rather than the "easy" way. Given our game's code, this results in a significant amount of my time on the game being spent on code maintenance rather than development. While I never go into the code with the intent of just rewriting things, it winds up happening when I need to modify or add a new spell or feature that is tied into a gnarly piece of code from years past. What starts out as a five-minute change can turn into literally days of restructuring and testing. And the real kicker here? Provided I did a good job, nobody will ever notice that I did anything.
This is all part of the job involved in maintaining our Frankenstein code though, and I've put in my share of bad code too. I just thought it might be insightful to get a peek at what coding at Dark Risings entails.
And for those who are interested, I replaced the old mirror image code (above) with this version which does the same thing in a much more concise fashion:
* This is not the whole story, but it's close enough
** Also not entirely true. My predecessor, Kesavaram, did a lot of cleaning up. As far as I can tell, nobody else did.
The following features have been rewritten but should behave identically to how they always have behaved. Please report any abnormalities with them:Upon reading this, a very astute player asked a very sensible question: "When you say DOTs have been rewritten but act the same, why rewrite them?" After all, if the code ain't broke, why fix it?
1. all damage-over-time spells (necro spells, headache, poison, plague)
2. unholy fire, reflect (does anyone still have this spell?), and strawberry fulfillment
While I cannot discuss the specific case of the recently rewritten DOT spells (I rewrote them as a part of a still-secret new feature), I'll use another recently rewritten spell to illustrate. Back in early April I rewrote the mirror images/astral projection/shield of skulls spells. Briefly, the reasoning was this:
- We were going to make pinch always land. This prompted a rewrite of pinch
- Pinch is effectively a DOT spell; it wakes you up on the tick by dealing a small amount of damage to you
- Pinch did this damage by calling the damage() routine, whose function is to apply damage to a victim after checking for sanctuary, magic ward, resists, vulns, and most importantly, mirror image
- Since pinch did such little damage to begin with, it would sometimes not wake you up if you had sanc/ward/etc and they reduced pinch's damage to 0*
- I changed pinch from using damage() to raw_damage(), a routine that does damage but ignores most other factors like sanc, ward, and mirrors.
- Because we still wanted pinch to hit mirrors like poison did, I had to add special code into the pinch spell to make it destroy images in the same way that it does from within the damage() routine
To achieve this, I had to figure out how the mirror images code in damage() actually works. When I opened up the file, I found this:
if (IS_AFFECTED2(victim, AFF_MIRROR))
{
for (paf=victim->affected; paf != NULL; paf = paf->next)
{
if (paf->type == gsn_mirror)
break;
}
if (paf)
{
imagehit = number_range(0,paf->modifier);
/* mirrors exempt */
if( dt == gsn_backstab ||
dt == gsn_blister ||
dt == gsn_decay ||
dt == gsn_atrophy ||
dt == gsn_wilt )
{
imagehit = 0;
}
if (imagehit != 0)
{
act("$n hits an image of $N",ch,0,victim,TO_NOTVICT);
act("$n DESTROYS an image of you!",ch,0,victim,TO_VICT);
act("You DESTROY an image of $n!",victim,0,ch,TO_VICT);
paf->modifier--;
if (paf->modifier == 0)
{
affect_strip(victim,gsn_mirror);
REMOVE_BIT(victim->affected_by2, AFF_MIRROR);
}
return FALSE;
}
}
else
{
bug( "Damage: Mirror Image failure.", 0 );
}
}
In English, the code essentially does this:- Check to see if the target of the damage() is affected by mirror images. If he is,
- Figure out how many images they have left. If we can find this out,
- Determine the % chance of this damage hitting a mirror image:
- if the damage is being done by backstab, blister, decay, atrophy, or fester, the chance of hitting an image is 0% (these skills/spells will never hit images)
- otherwise, the chance of hitting an image is N/(N+1), where N is the number of images the victim has left
- If an image is hit,
- Send messages to the victim, the attacker, and the rest of the room,
- Reduce the number of images on the victim by one,
- and if the number of images is now 0, strip off the aff entirely so the victim can re-cast them
Trying to extend and modify code like this to add new features is similarly difficult; not only do you need to figure out how it works, but you need to figure out at what level in the logic the new feature needs to be added. And wouldn't you know it, huge swaths of the game's code are written in a similar fashion. Either a lot of code is used to accomplish something very little (which makes the code hard to maintain, extend, or modify), or too little code is used to accomplish something very big (in which case the code causes the game to crash whenever someone does something out of the ordinary).
I suspect that most of the game's past coders weren't thinking about how easy their code would be to maintain in five or ten years, and that mentality resulted in a lot of garbage piling up without anyone cleaning up**. Such an approach to code development is not sustainable though, and that approach usually leads up to a major breaking point. In my mind, Dark Risings reached that breaking point right around the same time I took over as coder and the game was crashing on a daily basis.
Although I have no formal training in anything having to do with programming, computer science, IT, or anything like that, my programming mantra is to do things the "right" way rather than the "easy" way. Given our game's code, this results in a significant amount of my time on the game being spent on code maintenance rather than development. While I never go into the code with the intent of just rewriting things, it winds up happening when I need to modify or add a new spell or feature that is tied into a gnarly piece of code from years past. What starts out as a five-minute change can turn into literally days of restructuring and testing. And the real kicker here? Provided I did a good job, nobody will ever notice that I did anything.
This is all part of the job involved in maintaining our Frankenstein code though, and I've put in my share of bad code too. I just thought it might be insightful to get a peek at what coding at Dark Risings entails.
And for those who are interested, I replaced the old mirror image code (above) with this version which does the same thing in a much more concise fashion:
if ( IS_AFFECTED2(victim, AFF_MIRROR)
&& (paf = affect_find(victim->affected, gsn_mirror))
&& number_range(0,paf->modifier)
&& dt != gsn_backstab
&& dt != gsn_blister
&& dt != gsn_decay
&& dt != gsn_atrophy
&& dt != gsn_wilt )
{
act("$n hits an image of $N",ch,NULL,victim,TO_NOTVICT);
act("$n DESTROYS an image of you!",ch,NULL,victim,TO_VICT);
act("You DESTROY an image of $n!",victim,NULL,ch,TO_VICT);
if ( --paf->modifier == 0 )
affect_strip(victim,gsn_mirror);
return FALSE;
}
Much simpler, right?* This is not the whole story, but it's close enough
** Also not entirely true. My predecessor, Kesavaram, did a lot of cleaning up. As far as I can tell, nobody else did.
Wednesday, April 25, 2012
A Case Study
Recently we had a complaint come in regarding a possible multikill rule violation. It was a very interesting case with a lot of points to consider, so we thought it might be interesting to use it as sort of a “case study” to give players an idea of how these kind of investigations are conducted, and why we make the kind of rulings we do. All names have been changed to protect the innocent!
As with all such complaints, we talked with all parties involved, reviewed both the rule itself and timestamped logs from the shell, and also took into consideration other relevant factors, such as if anyone involved was a newbie and how likely each participant was to have been aware of his options at the time. As always, our goal is to make a ruling that is fair for all parties involved, and which overall is best for the game as a whole.
First, we reviewed the rule itself, as it currently stands:
The first thing we do after gathering the facts is return to the rule. Bob was not murdered by Dan, so the part about coming back to his corpse for items does not apply. Since Bob wasn’t the one to start combat with Jim, the part about the victim entering combat again doesn’t apply. The only part to consider is: Once a character is KO'd, they should not be KO'd again until they have reached sanctuary and are out of fight lag.
Bob’s point of view is that since he did not reach sanctuary and was only out of fightlag for a few seconds before Jim attacked, he feels the rule was clearly violated.
On the other hand, Jim is positive Bob was out of fightlag since Jim was careful to count seconds, tacking on an additional 45 seconds past the 90 fightlag count just to be sure, and feels it is not his fault that Bob chose not to get safe when he had plenty of chances. Since Bob could easily have gotten safe and was, without question, out of fightlag, he feels the rule was clearly NOT violated.
Applying the rule (as it is currently written) is certainly problematic in this case because it assumes that the victim of a KO will attempt to get safe immediately after awakening from stupor. Bob could have done this, but he also states that he made a conscious decision not to. What if Bob never went to safe again after the initial knockout? Would Jim never be able to attack him again? Obviously that’s not fair; the line has to be drawn somewhere.
What makes this case messy is how tight the time is. 90 seconds is not that long. 3 minutes is not that long. In a different recent case, we had Roy the rogue fail a steal on new player Pete, who responded by trying to push Roy away repeatedly. Roy knew the rules extremely well and ducked into safe for 93 seconds, and then immediately went back to Pete who was still trying to push him away. Roy then used the psteal rule to KO Pete and loot heavily. In that case, we ruled against Roy for two reasons. First, the psteal rule states that the rogue must CLEARLY have gotten out of fightlag. 93 seconds is not clear to a new player who may or may not be aware of what fightlag even is. Although it’s not up to Roy to know who is and is not a new player, he should know better than to race back to a PK just seconds out of fightlag and try to get attacked so that he can KO that player. Roy should have waited long enough for Pete to realize that they were no longer fighting. 93 seconds is not long enough to be CLEARLY sure someone has gotten out of fightlag.
Once a character is KO'd, they should not be KO'd again until they have reached sanctuary and are out of fight lag.
After deliberating the facts in this case, the admin team decided that although Bob did not reach sanctuary, he could have easily and it was HIS choice not to try, which therefore exempts him from the protection that part of the rule (reaching sanctuary) provides. Therefore the question is whether or not Jim violated the fightlag portion of the rule. Given that Jim waited not only the 90 seconds the rule demands, but well past that, it seems clear that all parties involved had a reasonable chance to be sure that Bob was not still in fightlag from the fight with Dan when Jim initiated the second attack on Bob that day. Therefore we ruled that in this case no rule was broken, and the situation was not multi-kill.
The rule as it stands is badly worded, since it assumes the KO’d player will automatically get safe after a KO when clearly that’s not always the case. It’s also a little vague about what fightlag is: Is it reasonable to expect Jim to factor in fightlag from mobs Bob may or may not be fighting? Should Bob be able to kill a mutt every 85 seconds, stay in fightlag forever, and expect all his enemies to be aware of his fightlag state? Obviously not. For these reasons, we will be revising this rule for clarity.
We thought players might find it interesting to see the thought process behind rules calls. We are also interested to hear from those who think there may be factors we overlooked, but we ask those who may recognize this case (or think they do) to keep identifying factors out of it for the sake of the players involved.
As with all such complaints, we talked with all parties involved, reviewed both the rule itself and timestamped logs from the shell, and also took into consideration other relevant factors, such as if anyone involved was a newbie and how likely each participant was to have been aware of his options at the time. As always, our goal is to make a ruling that is fair for all parties involved, and which overall is best for the game as a whole.
First, we reviewed the rule itself, as it currently stands:
Once a character is KO'd, they should not be KO'd again until they have reached sanctuary and are out of fight lag. They also cannot be KO'd after coming back for the items on their corpse if they have been murdered. This rule does not apply if they enter the combat again after being KO'd. See help etiquette for some finer points on this subject.We then looked at objective facts about what happened, which all parties agree on:
- Bob and Dan start to fight. Another one of Bob’s enemies, and Dan’s ally, Jim logs on during the fight but does not interfere.
- Bob is knocked out by Dan and lightly looted of five items.
- Dan then goes safe and does not participate further.
- After awakening from stupor, Bob checks the who list and sees Jim is still around.
- Bob considers going safe but instead decides to go to Thalos.
- Jim trails Bob to Thalos but does not attack.
- Bob runs into a ghost in Thalos and gets back into fightlag. Jim may or may not be aware of this.
- Bob leaves Thalos and goes through Arinock to the Void. He chooses not to stop in safe along the way.
- Jim follows Bob to the Void.
- At this point almost three full minutes have passed since Bob awoke from Dan’s stupor, double the 90 seconds required by fightlag. Bob has re-equipped and is missing only a light, head slot, and weapon.
- Jim attacks and knocks Bob out.
Bob’s point of view is that since he did not reach sanctuary and was only out of fightlag for a few seconds before Jim attacked, he feels the rule was clearly violated.
On the other hand, Jim is positive Bob was out of fightlag since Jim was careful to count seconds, tacking on an additional 45 seconds past the 90 fightlag count just to be sure, and feels it is not his fault that Bob chose not to get safe when he had plenty of chances. Since Bob could easily have gotten safe and was, without question, out of fightlag, he feels the rule was clearly NOT violated.
Applying the rule (as it is currently written) is certainly problematic in this case because it assumes that the victim of a KO will attempt to get safe immediately after awakening from stupor. Bob could have done this, but he also states that he made a conscious decision not to. What if Bob never went to safe again after the initial knockout? Would Jim never be able to attack him again? Obviously that’s not fair; the line has to be drawn somewhere.
Further muddying the waters is this: Bob was not in fightlag in Thalos, and only got back into fightlag because he ran into an aggressive mob. If he had not run into that mob, then his own estimation of having been out of fightlag for “a few seconds” would have to include “a few seconds + the 90 seconds I was in fightlag from the mob”, which means by his own estimation he absolutely was out of fightlag from the first fight by the 90 seconds required by the rule, plus those few seconds in the Void, plus the time it took him to go from the area where he was KO’d initially by Dan to Thalos: a total of almost three full minutes by the game logs.
So to reiterate:
So to reiterate:
Dan knocked out Bob. Bob spent almost three minutes being shadowed by Jim (who is allied with Dan, but was not working with Dan). Jim counted the time required by the rule to give Bob time to get safe, and added extra time just to be sure. Bob chose to avoid safe. Jim attacked and KO’d Bob.
What makes this case messy is how tight the time is. 90 seconds is not that long. 3 minutes is not that long. In a different recent case, we had Roy the rogue fail a steal on new player Pete, who responded by trying to push Roy away repeatedly. Roy knew the rules extremely well and ducked into safe for 93 seconds, and then immediately went back to Pete who was still trying to push him away. Roy then used the psteal rule to KO Pete and loot heavily. In that case, we ruled against Roy for two reasons. First, the psteal rule states that the rogue must CLEARLY have gotten out of fightlag. 93 seconds is not clear to a new player who may or may not be aware of what fightlag even is. Although it’s not up to Roy to know who is and is not a new player, he should know better than to race back to a PK just seconds out of fightlag and try to get attacked so that he can KO that player. Roy should have waited long enough for Pete to realize that they were no longer fighting. 93 seconds is not long enough to be CLEARLY sure someone has gotten out of fightlag.
In the case with Jim and Bob, both players are pros, and Jim consciously waited out the fightlag time and added extra time to be absolutely sure Bob was out of fightlag. So where Roy did NOT try to make sure that the fightlag time was CLEARLY up, Jim did.
Once a character is KO'd, they should not be KO'd again until they have reached sanctuary and are out of fight lag.
After deliberating the facts in this case, the admin team decided that although Bob did not reach sanctuary, he could have easily and it was HIS choice not to try, which therefore exempts him from the protection that part of the rule (reaching sanctuary) provides. Therefore the question is whether or not Jim violated the fightlag portion of the rule. Given that Jim waited not only the 90 seconds the rule demands, but well past that, it seems clear that all parties involved had a reasonable chance to be sure that Bob was not still in fightlag from the fight with Dan when Jim initiated the second attack on Bob that day. Therefore we ruled that in this case no rule was broken, and the situation was not multi-kill.
The rule as it stands is badly worded, since it assumes the KO’d player will automatically get safe after a KO when clearly that’s not always the case. It’s also a little vague about what fightlag is: Is it reasonable to expect Jim to factor in fightlag from mobs Bob may or may not be fighting? Should Bob be able to kill a mutt every 85 seconds, stay in fightlag forever, and expect all his enemies to be aware of his fightlag state? Obviously not. For these reasons, we will be revising this rule for clarity.
We thought players might find it interesting to see the thought process behind rules calls. We are also interested to hear from those who think there may be factors we overlooked, but we ask those who may recognize this case (or think they do) to keep identifying factors out of it for the sake of the players involved.
Thursday, April 19, 2012
New Vorpal Functionality
Verghazrin was kind enough to host a battle royale PK quest last night which was a great testing grounds for the new functionality we gave vorpal. It generated a fair bit of discussion both last night and this morning, but some of the suggestions or criticisms seem to be rooted in misconceptions on how vorpal weapons now work. So as to make it unambiguous, here's how everything is laid out:
Recharge is the time (rounds of combat) it takes for the vorpal to "recharge." Once a vorpal weapon is recharged, it will discharge (cast its spell) on the next hit, then recharge again.
Relative Damage is a figure of merit expressing how much damage each class's vorpal spell will do. The higher this number is, the more damage a single vorpal discharge will do.
Damage Potential is the Relative Damage divided by the recharge time. It gives you an idea of how much damage a class's vorpal spell will do over time. Necromancers' Damage Potential is a bit trickier to calculate since their spell does damage over time.
Whenever a vorpal weapon discharges (mind you, "discharge" is a term I just made up now), it casts your class's vorpal spell at the level of the weapon and won't discharge again until the recharge time is up. However, this recharge time is attached to the character, not the weapon, so a dual-wielding ranger will not get double discharges, and swapping out vorpal weapons very quickly in combat will not let you get a bunch of free spell casts. Incidentally, a side-effect of these new vorpal spells is that other special weapon properties (chill, flame, shock, poison, and others) are now also limited by each class's recharge time. This side-effect will be removed soon so that chill/flame/shock/poison/etc work the way they used to.
We are fairly confident in how this new vorpal is working for the time being and we do not consider the feature to be still in the testing stage. We aren't looking for unsolicited feedback on what classes should get what spells or recharge times or anything like that; however, we will be keeping an eye on how vorpal weapons get used and, if necessary, can tweak things.
With that being said, we are considering tweaking necromancers after last night's quest. One of the leading suggestions was to make necromancers' vorpal be like judgment but with necro spells instead of maledictions.
| Class | Recharge | Spell | Relative Damage |
Damage Potential |
| Mage | 2 | acid blast | 10 | 5.0 |
| Cleric | 2 | smite | 8.3 | 4.2 |
| Monk | 3 | lightning bolt | 1.3 | 0.44 |
| Warrior | 4 | fireball | 2.7 | 0.66 |
| Barbarian | 5 | N/A | N/A | N/A |
| Psionicist | 2 | mind blast | 8.3 | 4.2 |
| Druid | 2 | natures wrath | 7.1 | 3.6 |
| Ranger | 5 | lightning bolt | 1.3 | 0.26 |
| Rogue | 3 | N/A | N/A | N/A |
| Bard | 3 | deathsong | 7.1 | 2.4 |
| Wildmage | 2 | wildfire | 4.9 | 2.5 |
| Warlock | 3 | ravage | 7.1 | 2.4 |
| Necromancer | 2 | decay | 6.3* | N/A |
| Templar | 3 | flamestrike | 4.6 | 1.5 |
Recharge is the time (rounds of combat) it takes for the vorpal to "recharge." Once a vorpal weapon is recharged, it will discharge (cast its spell) on the next hit, then recharge again.
Relative Damage is a figure of merit expressing how much damage each class's vorpal spell will do. The higher this number is, the more damage a single vorpal discharge will do.
Damage Potential is the Relative Damage divided by the recharge time. It gives you an idea of how much damage a class's vorpal spell will do over time. Necromancers' Damage Potential is a bit trickier to calculate since their spell does damage over time.
Whenever a vorpal weapon discharges (mind you, "discharge" is a term I just made up now), it casts your class's vorpal spell at the level of the weapon and won't discharge again until the recharge time is up. However, this recharge time is attached to the character, not the weapon, so a dual-wielding ranger will not get double discharges, and swapping out vorpal weapons very quickly in combat will not let you get a bunch of free spell casts. Incidentally, a side-effect of these new vorpal spells is that other special weapon properties (chill, flame, shock, poison, and others) are now also limited by each class's recharge time. This side-effect will be removed soon so that chill/flame/shock/poison/etc work the way they used to.
We are fairly confident in how this new vorpal is working for the time being and we do not consider the feature to be still in the testing stage. We aren't looking for unsolicited feedback on what classes should get what spells or recharge times or anything like that; however, we will be keeping an eye on how vorpal weapons get used and, if necessary, can tweak things.
With that being said, we are considering tweaking necromancers after last night's quest. One of the leading suggestions was to make necromancers' vorpal be like judgment but with necro spells instead of maledictions.
Monday, April 16, 2012
Wednesday Night Quest!
Verghazrin is holding a Battle Royale PK quest on Wednesday night (April 18) at 8pm Standard Time.
This quest will test out the shiny new Vorpal flag for quest weapons, which is designed to be the equivalent for magic classes what Sharp is for fighter classes.
Stop in, grab a weapon, and join the fun!
Love,
the staff
This quest will test out the shiny new Vorpal flag for quest weapons, which is designed to be the equivalent for magic classes what Sharp is for fighter classes.
Stop in, grab a weapon, and join the fun!
Love,
the staff
Monday, April 9, 2012
A few new changes
We've got a stack of new changes going in, but we have opted to delay rolling out the new changes (and any possible bugs included with them) until after the big event that's happening tonight happens. So as to not let anyone who follows our Dark Risings twitter feed feel like we've been leading anyone on, I figured it would be appropriate to reiterate that big new changes are going in. Here's a taste of what's going to happen:
- Poison will no longer break sleep, but pinch/haunt will now always work. There are a bunch of auxiliary changes accompanying this too. For example, we are working to replace all current poison-giving items (moldy bread, vial of the undead) with pinch/haunt equivalents, sleep's duration is now much shorter, and things of that nature.
- People were complaining about protection of peaches being undispellable, so we've made it possible to dispel, but not quite as easily as sanctuary.
- Monks will now get divine focus (the templar ability) at level 15. This is in addition to their frenzy spell, so it should give monks a nice boost.
- Lots of changes have been made to the prompt. You now have to manually color %h, %H, %m, %M, %v, and %V, %l will now show the exact number of seconds left in latelog, %f will now show the exact seconds left in fightlag (this is pretty huge!), and some other stuff.
- Ticks will have randomized lengths to curb unfair practices that certain script-happy pkers have been abusing.
There are a lot more intermediate changes going in too; the brawler board will be sorted now, various code has been added to support the new tradeskill we'll be putting in, and a lot of (mostly) transparent bug fixes are going in. For example, sand spirits and desert scorpions should no longer be holding hundreds of fossilized shells, the 'info' command will now work properly in creation, and harm touch will now depend on your skill% in it.
The complete details will be posted as a change in the game once the new code is actually in play. Hopefully they are received well!
Saturday, April 7, 2012
Monday Night Quest!
Hello everyone,
This is just a quick note to get the word out: we are planning a big event for the evening of Monday, April 9. We'd love to see a good turnout and are more than happy to offer bribes in the form of quest eq and prizes :)
You won't want to miss it!
Love,
the staff
This is just a quick note to get the word out: we are planning a big event for the evening of Monday, April 9. We'd love to see a good turnout and are more than happy to offer bribes in the form of quest eq and prizes :)
You won't want to miss it!
Love,
the staff
Sunday, March 18, 2012
Cast 'Dispel Stagnation'
Hello everyone.
It's a beautiful spring afternoon here. The sun is streaming in through the windows, a sweet breeze is blowing, and I am listening to Fleetwood Mac's Rumours. What better time possible to address some of the concerns which have been circulating?
The biggest one, clearly, has been the recent and almost total lack of activity in the game. Since early December, DR has just been slowing down, to the very sluggish state it's in right now. I think it's worth explaining what's been happening behind the scenes, both then and now: what led to this state, and what we're doing to fix it. Just a warning though: I ramble a lot in this post.
The way Dark Risings is designed, it is extremely dependent on having an active staff to keep things moving. For better or for worse, guild immortals are vital to their guilds, and not just as automatons guilding in whomever the players have vouched. Guild immortals are the ones responsible for following the stories of their guild members, for enhancing and building on them, for bringing to admin's attention the ones that require further support in the way of coding or building.
In many ways guild imms are the conduits of player story lines, because most players do not record their own stories or tell the admin staff about them. We have staff policies designed to enhance player privacy, and I think that's a good thing; the downside of that is that admin doesn't often know what's happening in the player world. We need people to keep us informed, and most of the time, those people are the guild immortals. Providing enhancement and support for character stories is also pretty time intensive, so having an active staff means that there is a team working towards a common goal. Without that team, running the mud is impossible.
So what happened?
It started with our decision to ask one imm to step down, followed shortly by having two imms quit. These are delicate situations where it's easy for players to make assumptions based on biased and incomplete information. Whenever an imm quits (or is asked to step down), or a player is penalized, or anything of that nature, that person tends to tell his or her side of the story. And certainly I understand that -- that's such a normal thing to do. The trouble is that our side of the story is almost never told. We hold back, and for several reasons. Part of it is that we understand that people need to save face, that people need to vent. Part of it is that we think the classy thing to do is not to sink to a level of he-said/she-said bickering in an environment where we hold the power (though dang, it's sometimes hard to stick to that high road). Part of it is to protect other people involved in the situation. Part of it is to protect the very person who is telling everyone what he or she sees as the truth.
How much to divulge about this type of decision is something I struggle with in all of these situations. Older players may remember one very infamous episode in DR history where Player X was in a pk with a character who was suspected to be one of Mark's alts (Mark being an implementor at the time, along with Andy and Dan). Player X had Mark's alt slept without poison, and out of nowhere, a "someone" (ie a wizi imm) cast Pinch on him, waking him up. Obviously, that looks horribly like Mark used his imm character to cheat, and Player X went on a huge smear campaign to try to have Mark discredited and thrown out of the game by the other imps. A lot of players heard Player X's story and concluded that Mark MUST have cheated, and it did a lot of damage to the game environment that lasted for years.
I was an imm when that happened and none of us were told anything about it, except that it wasn't what it looked like and that we should trust the imps to handle it. That was all the players got too. That didn't sit well with pretty much everyone. It wasn't until years later when I was an imp, when I had the ability to check the facts, that I got the real story. Pinch was at that time brand new -- I think it had gone in just a day or two before -- and one of the other imms was just being goofy and messing around with it. He didn't know that Mark's character was in a PK, and just to be funny, he cast it on that character. The timing couldn't have been worse, and it sparked this huge, huge, mess which was really devastating in a lot of ways. So everyone on the imp staff was silent about what really happened, to protect the imm who had screwed up with such a simple little thing, a harmless little thing (or at least it would have been, if Mark's character hadn't also been in a PK with probably the worst possible player for this to happen with), and a huge amount of distrust was fostered. And Mark's own personality made matters even worse, because he is the kind of person who, if misjudged, says 'You seriously think this bad thing could be true about me? Screw you, I'll show you bad," and then goads the hell out of the person who misjudged him to start with. And he was really insulted by this -- not so much the assertion that he would cheat, but the assertion that he would cheat in such an obvious, ridiculously blatant way. And so Mark, who has done so much for DR, is still reviled by a large number of old players, for many incidents very similar to this.
So what should we do? In that situation, should they just have thrown the imm who made the mistake under the bus? Were they wrong to expect the players to just accept that no wrongdoing actually took place, regardless of how it looked from Player X's perspective and his many theories about it?
As imps, should we go out of our way to explain our decisions about difficult topics, even if it means outting other people's alts or giving away game secrets that players have worked for months or years to develop, just so that we can clear our names? I guess for us, the answer is clearly 'No.' We would rather take the bullet. When we have asked staff to step down or change something they were doing, it wasn't done out of petty personal self-interest. We have done it because as implementors we see a full picture of the game that no one else has, with the benefit of having more experience running the game than any other implementors in DR's history, and, even more, the added benefit of being able to learn not only from our own mistakes, but the mistakes of everyone who came before us.
Maybe it was a mistake given how it all turned out not to be up-front in divulging what happened in the above situation, but I admire Mark for taking the heat and protecting his staff. I think that took a lot of grit. This is not to say that the staff member got a free pass -- he got a royal chewing out, and all subsequent imms got a big lecture about how immortal powers are NOT toys and shouldn't be used to dick around, because you never know when some innocent goofy prank can have drastic consequences.
In any case, I remain the optimist. I think we must ask staff to believe in us, to believe that our fundamental goal is to make a great game, and if they can't do that, then they probably should not be part of our team and leaving the staff is the right decision for them to make. We aren't looking for a team of yes-men -- the point is we want staff who will come to us when they see problems and work them out with us, not just passively seethe about it in silence or rant about it to players. To us, a team works together towards a common goal, and undercutting members of the team is not going to produce a win.
The point is, it isn't enough just to have bodies on staff. For this game to work, for it to be really great, we need people who have faith in us, and in whom we have faith. And we want DR to be great. We think it has achieved a level of greatness that makes us extremely proud to be a part of it, and we want to keep that going for as long as possible, whether it's us at the wheel or whoever takes over after us. And we will take quality staff members over a quantity of poor ones every day of the week.
So, back to the point: we lost three staff members. Inferno is mortal-run, so that leaves six guilds: doing the math, we lost half our staff within a few months. During that time we also hired one new imm and closed down one guild, leaving us with five guilds who needed immortals, and four people to fill the slots.
That's when things got really bad. Of the four people we had, all four had real life suddenly rear its ugly head, and their time and ability to play DR was suddenly non-existent. Obviously I'm not going to detail the private lives of the staff, but for each one of them, the reason was a very good one, unavoidable, and, while it was long-lasting, temporary. One of the four was me, and while my real-life issue was much shorter than the others, I came back to a mud with no staff support whatsoever.
I have said this before and I'll say it again: it is not possible to run Dark Risings without staff. Just completely not possible at all. For one person to try to do it is a fool's errand. I have heard people assert how easy it is to hire staff, and for other muds that may be true. But it isn't true for -this- mud, at least not at this stage of the game. Hiring a new staff member is a huge investment in time and effort for admin, because of the standards we ask staff to meet and the ways in which we do things. I have seen dozens of imms hired, back in the day, and thrown into a guild they had never even had a mortal in, and left to sink or swim. Most of them sank. It's done very differently now, because want to do everything we possibly can to help new imms prosper, and it takes time. It also helps to have an active staff when hiring new staff members, because we can be a team and work together to teach the new imms everything they need to know: how to make their equipment and token and poofs and room and rank and pretitle and all the other things new imms have to make; the transmission of almost 14 years of guild histories, policies on guilding and ranking and eq, not to mention the story lines; what imm commands they now have and the rules we have about using them -- and all of this is just the tip of the iceberg. It's a lot, both for the new imm and for the current staff.
So when I came back and the staff was still absent, I lost interest myself. Plus, not gonna lie: I had just gotten Skyrim and was totally addicted. It was easy to ignore Dark Risings, because nothing was happening and I didn't have much help to make things happen. The staff would be coming back, I knew, and so I didn't want to replace them. One guild, Covenance, was completely without an imm, but Parviane dragged out one of his old Covenance immortals and was covering there as best he could given how little time he had for DR. Life trumps the game, and that's how it should be, but dang. Tough times for DR.
I often just have to laugh when I hear people with little-to-no imming experience talk about what they think imms do or how easy it is to hire/be staff. I do understand it -- Parviane and I are the only implementors in DR history who started out as players first, and over the years I have been increasingly stunned to realize just how much immortals do that players don't realize, how much admins do that imms don't realize, how much imps do that admin don't realize. It's like an ant climbing to the top of an anthill about which he knows everything, only to have the camera draw back to reveal a whole field of anthills he never knew existed.
And that feeling has intensified over the years, as we have tried to refine the DR gaming experience from one that appealed to 14-year-old boys, to one suitable for our current 20-40 age group made up pretty equally of men and women. Imming at DR is a vastly different experience now from what it was when I was brought on as staff in the spring of 2002. (Holy crap. In two months I will have been a DR staff member for a solid decade.) The game is very different now, and while there are certainly people who will always mourn for the good old days when they played important characters and were known throughout the mud, I am proud of what we've built it into: a unique, original, and cohesive world built out of incongruent sources; a game based on the tenets of fair play, respect for players and their stories (past and present), and balanced mechanics. DR really is a magical place.
Anyway, I think the players saw the lack of staff and thought that since we weren't there to make the magic happen, they had no reason to be there either. And while it is possible to play DR and make magic happen without the presence of a staff, it's a lot less fun that it should be. And what is a game supposed to be, if not fun?
So we stagnated. We were in the position of having very few regular players logging, and possibly having to start from scratch with staff, and not even having much of a pool of players who had shown any interest in being staff to pick from.
I'll admit, I got disheartened. When we came back from our absence a few years ago, DR was in a similar state and we brought it back to life then, through a lot of hard work and constant effort. The thought of doing that again was, for a while, pretty overwhelming. I thought about possibly writing an ending for the DR story, having a set date on which the mud would close and staging a series of climactic events to culminate in one big bang, with the ending determined by player actions along the way. I would rather give the game closure and go out with a bang than just have it waste away to nothing. I even went to the extent of asking a few players if that's something they would like to see, and while they agreed it would be better than letting the game die quietly, they said both options were less desirable than having the game pick back up again.
And isn't that what I want too? It so is. DR can be a frustrating, exhausting creature sometimes. But I love it. I have loved it for ten years. And I want it to be awesome, to give it life, to make it soar.
So.
We are making changes. Of the three staff who had their time sucked away, two are back. We have also hired three new staff members, and the plotting has been fast and furious. I can't tell you how great it feels to have people to conspire with again. We have a ton of great stuff planned and I am really hoping that the resurgence in active staff is going to bring the players back. You have all been sorely missed.
Since it is going to take a few weeks for the new staff to get ready and go vis, I thought I would write this post to let you know that we're focused again, we're taking big steps to fix the horrible problem with stagnation, and we're very excited about the future of the game.
Come back, beloved players: it's about to get good :)
It's a beautiful spring afternoon here. The sun is streaming in through the windows, a sweet breeze is blowing, and I am listening to Fleetwood Mac's Rumours. What better time possible to address some of the concerns which have been circulating?
The biggest one, clearly, has been the recent and almost total lack of activity in the game. Since early December, DR has just been slowing down, to the very sluggish state it's in right now. I think it's worth explaining what's been happening behind the scenes, both then and now: what led to this state, and what we're doing to fix it. Just a warning though: I ramble a lot in this post.
The way Dark Risings is designed, it is extremely dependent on having an active staff to keep things moving. For better or for worse, guild immortals are vital to their guilds, and not just as automatons guilding in whomever the players have vouched. Guild immortals are the ones responsible for following the stories of their guild members, for enhancing and building on them, for bringing to admin's attention the ones that require further support in the way of coding or building.
In many ways guild imms are the conduits of player story lines, because most players do not record their own stories or tell the admin staff about them. We have staff policies designed to enhance player privacy, and I think that's a good thing; the downside of that is that admin doesn't often know what's happening in the player world. We need people to keep us informed, and most of the time, those people are the guild immortals. Providing enhancement and support for character stories is also pretty time intensive, so having an active staff means that there is a team working towards a common goal. Without that team, running the mud is impossible.
So what happened?
It started with our decision to ask one imm to step down, followed shortly by having two imms quit. These are delicate situations where it's easy for players to make assumptions based on biased and incomplete information. Whenever an imm quits (or is asked to step down), or a player is penalized, or anything of that nature, that person tends to tell his or her side of the story. And certainly I understand that -- that's such a normal thing to do. The trouble is that our side of the story is almost never told. We hold back, and for several reasons. Part of it is that we understand that people need to save face, that people need to vent. Part of it is that we think the classy thing to do is not to sink to a level of he-said/she-said bickering in an environment where we hold the power (though dang, it's sometimes hard to stick to that high road). Part of it is to protect other people involved in the situation. Part of it is to protect the very person who is telling everyone what he or she sees as the truth.
How much to divulge about this type of decision is something I struggle with in all of these situations. Older players may remember one very infamous episode in DR history where Player X was in a pk with a character who was suspected to be one of Mark's alts (Mark being an implementor at the time, along with Andy and Dan). Player X had Mark's alt slept without poison, and out of nowhere, a "someone" (ie a wizi imm) cast Pinch on him, waking him up. Obviously, that looks horribly like Mark used his imm character to cheat, and Player X went on a huge smear campaign to try to have Mark discredited and thrown out of the game by the other imps. A lot of players heard Player X's story and concluded that Mark MUST have cheated, and it did a lot of damage to the game environment that lasted for years.
I was an imm when that happened and none of us were told anything about it, except that it wasn't what it looked like and that we should trust the imps to handle it. That was all the players got too. That didn't sit well with pretty much everyone. It wasn't until years later when I was an imp, when I had the ability to check the facts, that I got the real story. Pinch was at that time brand new -- I think it had gone in just a day or two before -- and one of the other imms was just being goofy and messing around with it. He didn't know that Mark's character was in a PK, and just to be funny, he cast it on that character. The timing couldn't have been worse, and it sparked this huge, huge, mess which was really devastating in a lot of ways. So everyone on the imp staff was silent about what really happened, to protect the imm who had screwed up with such a simple little thing, a harmless little thing (or at least it would have been, if Mark's character hadn't also been in a PK with probably the worst possible player for this to happen with), and a huge amount of distrust was fostered. And Mark's own personality made matters even worse, because he is the kind of person who, if misjudged, says 'You seriously think this bad thing could be true about me? Screw you, I'll show you bad," and then goads the hell out of the person who misjudged him to start with. And he was really insulted by this -- not so much the assertion that he would cheat, but the assertion that he would cheat in such an obvious, ridiculously blatant way. And so Mark, who has done so much for DR, is still reviled by a large number of old players, for many incidents very similar to this.
So what should we do? In that situation, should they just have thrown the imm who made the mistake under the bus? Were they wrong to expect the players to just accept that no wrongdoing actually took place, regardless of how it looked from Player X's perspective and his many theories about it?
As imps, should we go out of our way to explain our decisions about difficult topics, even if it means outting other people's alts or giving away game secrets that players have worked for months or years to develop, just so that we can clear our names? I guess for us, the answer is clearly 'No.' We would rather take the bullet. When we have asked staff to step down or change something they were doing, it wasn't done out of petty personal self-interest. We have done it because as implementors we see a full picture of the game that no one else has, with the benefit of having more experience running the game than any other implementors in DR's history, and, even more, the added benefit of being able to learn not only from our own mistakes, but the mistakes of everyone who came before us.
Maybe it was a mistake given how it all turned out not to be up-front in divulging what happened in the above situation, but I admire Mark for taking the heat and protecting his staff. I think that took a lot of grit. This is not to say that the staff member got a free pass -- he got a royal chewing out, and all subsequent imms got a big lecture about how immortal powers are NOT toys and shouldn't be used to dick around, because you never know when some innocent goofy prank can have drastic consequences.
In any case, I remain the optimist. I think we must ask staff to believe in us, to believe that our fundamental goal is to make a great game, and if they can't do that, then they probably should not be part of our team and leaving the staff is the right decision for them to make. We aren't looking for a team of yes-men -- the point is we want staff who will come to us when they see problems and work them out with us, not just passively seethe about it in silence or rant about it to players. To us, a team works together towards a common goal, and undercutting members of the team is not going to produce a win.
The point is, it isn't enough just to have bodies on staff. For this game to work, for it to be really great, we need people who have faith in us, and in whom we have faith. And we want DR to be great. We think it has achieved a level of greatness that makes us extremely proud to be a part of it, and we want to keep that going for as long as possible, whether it's us at the wheel or whoever takes over after us. And we will take quality staff members over a quantity of poor ones every day of the week.
So, back to the point: we lost three staff members. Inferno is mortal-run, so that leaves six guilds: doing the math, we lost half our staff within a few months. During that time we also hired one new imm and closed down one guild, leaving us with five guilds who needed immortals, and four people to fill the slots.
That's when things got really bad. Of the four people we had, all four had real life suddenly rear its ugly head, and their time and ability to play DR was suddenly non-existent. Obviously I'm not going to detail the private lives of the staff, but for each one of them, the reason was a very good one, unavoidable, and, while it was long-lasting, temporary. One of the four was me, and while my real-life issue was much shorter than the others, I came back to a mud with no staff support whatsoever.
I have said this before and I'll say it again: it is not possible to run Dark Risings without staff. Just completely not possible at all. For one person to try to do it is a fool's errand. I have heard people assert how easy it is to hire staff, and for other muds that may be true. But it isn't true for -this- mud, at least not at this stage of the game. Hiring a new staff member is a huge investment in time and effort for admin, because of the standards we ask staff to meet and the ways in which we do things. I have seen dozens of imms hired, back in the day, and thrown into a guild they had never even had a mortal in, and left to sink or swim. Most of them sank. It's done very differently now, because want to do everything we possibly can to help new imms prosper, and it takes time. It also helps to have an active staff when hiring new staff members, because we can be a team and work together to teach the new imms everything they need to know: how to make their equipment and token and poofs and room and rank and pretitle and all the other things new imms have to make; the transmission of almost 14 years of guild histories, policies on guilding and ranking and eq, not to mention the story lines; what imm commands they now have and the rules we have about using them -- and all of this is just the tip of the iceberg. It's a lot, both for the new imm and for the current staff.
So when I came back and the staff was still absent, I lost interest myself. Plus, not gonna lie: I had just gotten Skyrim and was totally addicted. It was easy to ignore Dark Risings, because nothing was happening and I didn't have much help to make things happen. The staff would be coming back, I knew, and so I didn't want to replace them. One guild, Covenance, was completely without an imm, but Parviane dragged out one of his old Covenance immortals and was covering there as best he could given how little time he had for DR. Life trumps the game, and that's how it should be, but dang. Tough times for DR.
I often just have to laugh when I hear people with little-to-no imming experience talk about what they think imms do or how easy it is to hire/be staff. I do understand it -- Parviane and I are the only implementors in DR history who started out as players first, and over the years I have been increasingly stunned to realize just how much immortals do that players don't realize, how much admins do that imms don't realize, how much imps do that admin don't realize. It's like an ant climbing to the top of an anthill about which he knows everything, only to have the camera draw back to reveal a whole field of anthills he never knew existed.
And that feeling has intensified over the years, as we have tried to refine the DR gaming experience from one that appealed to 14-year-old boys, to one suitable for our current 20-40 age group made up pretty equally of men and women. Imming at DR is a vastly different experience now from what it was when I was brought on as staff in the spring of 2002. (Holy crap. In two months I will have been a DR staff member for a solid decade.) The game is very different now, and while there are certainly people who will always mourn for the good old days when they played important characters and were known throughout the mud, I am proud of what we've built it into: a unique, original, and cohesive world built out of incongruent sources; a game based on the tenets of fair play, respect for players and their stories (past and present), and balanced mechanics. DR really is a magical place.
Anyway, I think the players saw the lack of staff and thought that since we weren't there to make the magic happen, they had no reason to be there either. And while it is possible to play DR and make magic happen without the presence of a staff, it's a lot less fun that it should be. And what is a game supposed to be, if not fun?
So we stagnated. We were in the position of having very few regular players logging, and possibly having to start from scratch with staff, and not even having much of a pool of players who had shown any interest in being staff to pick from.
I'll admit, I got disheartened. When we came back from our absence a few years ago, DR was in a similar state and we brought it back to life then, through a lot of hard work and constant effort. The thought of doing that again was, for a while, pretty overwhelming. I thought about possibly writing an ending for the DR story, having a set date on which the mud would close and staging a series of climactic events to culminate in one big bang, with the ending determined by player actions along the way. I would rather give the game closure and go out with a bang than just have it waste away to nothing. I even went to the extent of asking a few players if that's something they would like to see, and while they agreed it would be better than letting the game die quietly, they said both options were less desirable than having the game pick back up again.
And isn't that what I want too? It so is. DR can be a frustrating, exhausting creature sometimes. But I love it. I have loved it for ten years. And I want it to be awesome, to give it life, to make it soar.
So.
We are making changes. Of the three staff who had their time sucked away, two are back. We have also hired three new staff members, and the plotting has been fast and furious. I can't tell you how great it feels to have people to conspire with again. We have a ton of great stuff planned and I am really hoping that the resurgence in active staff is going to bring the players back. You have all been sorely missed.
Since it is going to take a few weeks for the new staff to get ready and go vis, I thought I would write this post to let you know that we're focused again, we're taking big steps to fix the horrible problem with stagnation, and we're very excited about the future of the game.
Come back, beloved players: it's about to get good :)
Friday, November 18, 2011
The Elephant in the Room
I hesitate to air these sorts of administrative concerns over the idea board, so rather than post my response in-game where everyone (especially impressionable newbies) can see it, I'll write it out here.
There were a couple of idea posts overnight that are oddly atypical of what we administrators hear from players. In effect, they called for tightening up regulation of unmanned looping to get gold or level up... Imagine that. Players asking for rules making it harder to get to 50 and get rich. On the one hand, it pleases me to hear players starting to appreciate why this sort of gameplay is bad. On the other hand though, I'm not pleased that we let the situation get to a point where players are starting to complain about it.
The years of admin experience we have means we can typically spot problematic behavior early on, and this is why we try to nip this sort of unfair play in the bud by coming down on people who start doing stuff like gold looping. What's sparked this most recent bout of outrage was certain individuals quietly roboleveled for months during the summer. There was little harm was being done, the admins were largely away on vacation, and nothing came of it. Here we are a few months later, though, and now we've got players equipped with an army of indescript, throw-away, power-combo alts that have tons of money and all the perks that come with that (level 50 baking, crazy quest weapons, etc.). These players have started leveraging their armies of alts, and now suddenly there's a problem.
Addressing these issues is quite tricky; in the past (which I have dubbed Dark Risings 1.0), dealing with isolated abuses were often compulsive and sweeping. A great historic example of this is when the game's economy was redone and a lot of players lost all their gold because a few abusive players (I'll call them powerplayers) got crazy rich. Here in Dark Risings 2.0, we've been trying to curtail these sweeping, reactionary changes in favor of more conservative responses that don't impact the entire game. For example, one of our current powerplayers continued roboleveling despite being told many times to stop, so we made all mobs in all leveling areas aggressive towards just his character. Permanently.
The downside to this approach is that it's extremely time consuming. Once we impose such a punishment on an individual, there is a pretty predictable chain of events that follows:
This process is extremely aggravating and time-consuming for us admins, and this is why, despite our desire to limit fallout, we still sometimes introduce sweeping changes. The case of rose bushes no longer being immune to squires was kind of a balance between the Dark Risings 1.0 approach and the 2.0 approach; initially, I was going to just remove their immunity to pierce altogether, but Sidonie (who has been really championing sensibility) suggested we limit the change to squires so that rose bushes can still be used for honest reasons elsewhere.
The situation in which we now find ourselves is at stage #3. The truth is, there are other charmable mobs in the game that are immune to pierce; people just haven't discovered them. As soon as they are found, I'd be willing to bet that our resident powerplayers will abuse the hell out of them, and we'll have to change them as well. The ultimate question is, how do we break this cycle? We could...
I think option #4 is the gist of what the recent idea posts advocate, but the truth is, this option sucks too. If you think back to the time when afk spamming wasn't allowed, people were still doing it. Even after we've told people that they aren't allowed to robolevel or robofarm gold, they are still doing it. When we catch someone in the act, there's always an excuse. My Chinese food just arrived. I had to walk the dog. I went out for a smoke. My kitchen caught on fire. And even then, we wouldn't be preventing the problem players from manually farming gold. It wouldn't change the facts that they continually strip an area and prevent anyone else from using it, they hog charmies, and they really disrupt the gameplay for others.
So do we still ban them and embitter them against Dark Risings? I'm not sure that's any more fair than saving powerplayers from themselves by plugging up exploits. Both cases are just addressing the symptom, not the problem.
The underlying problem is that powerplayers, to a large degree, just don't "get" Dark Risings. To them, Dark Risings is something for their sole enjoyment (not unlike a single player game), and they don't care about anyone else's fun. They want the high score--the highest hp, the best PK record, and the highest hit/dam. They want to get guilded and become a vampire because they want the best spells and the best equipment in the game. RP is just a formality required to get those things. In many cases, it's not that the player is mean-spirited or "bad," it's just that they don't understand the game that us admins are trying to make and that the majority of our players enjoy.
Dark Risings 1.0 was not a bad place to be for powerplayers; they were on staff, they were in guilds, they were everywhere. And there's nothing wrong with that kind of MUD per se, but it's not the game that Dark Risings has become. Us admins don't have the energy to run a game with the deep undercurrents of acrimony that those games can breed. We want to run a game that's fun and fair to play.
So I guess the punchline here is that I don't know what to do about the bad apples who spoil the fun for others. They tend not to listen to us staff because they don't "get" us, and since they don't understand what we're trying to accomplish with our game, they often assume that we're just out to get them. Maybe they'll listen to what their peers (all you players) are saying instead. Give it a try. Just remember that you catch more flies with honey.
There were a couple of idea posts overnight that are oddly atypical of what we administrators hear from players. In effect, they called for tightening up regulation of unmanned looping to get gold or level up... Imagine that. Players asking for rules making it harder to get to 50 and get rich. On the one hand, it pleases me to hear players starting to appreciate why this sort of gameplay is bad. On the other hand though, I'm not pleased that we let the situation get to a point where players are starting to complain about it.
The years of admin experience we have means we can typically spot problematic behavior early on, and this is why we try to nip this sort of unfair play in the bud by coming down on people who start doing stuff like gold looping. What's sparked this most recent bout of outrage was certain individuals quietly roboleveled for months during the summer. There was little harm was being done, the admins were largely away on vacation, and nothing came of it. Here we are a few months later, though, and now we've got players equipped with an army of indescript, throw-away, power-combo alts that have tons of money and all the perks that come with that (level 50 baking, crazy quest weapons, etc.). These players have started leveraging their armies of alts, and now suddenly there's a problem.
Addressing these issues is quite tricky; in the past (which I have dubbed Dark Risings 1.0), dealing with isolated abuses were often compulsive and sweeping. A great historic example of this is when the game's economy was redone and a lot of players lost all their gold because a few abusive players (I'll call them powerplayers) got crazy rich. Here in Dark Risings 2.0, we've been trying to curtail these sweeping, reactionary changes in favor of more conservative responses that don't impact the entire game. For example, one of our current powerplayers continued roboleveling despite being told many times to stop, so we made all mobs in all leveling areas aggressive towards just his character. Permanently.
The downside to this approach is that it's extremely time consuming. Once we impose such a punishment on an individual, there is a pretty predictable chain of events that follows:
- The player argues and complains with imms, then admins, then imps. It's not fair, this isn't fair, life's not fair.
- A smear campaign is launched against the immortals over IMs for singling out and picking on one poor guy who was just trying to level his character.
- The player gets over his butthurt and just looks for another way to exploit the system.
- The player finds a way to exploit the system, and the cycle repeats.
This process is extremely aggravating and time-consuming for us admins, and this is why, despite our desire to limit fallout, we still sometimes introduce sweeping changes. The case of rose bushes no longer being immune to squires was kind of a balance between the Dark Risings 1.0 approach and the 2.0 approach; initially, I was going to just remove their immunity to pierce altogether, but Sidonie (who has been really championing sensibility) suggested we limit the change to squires so that rose bushes can still be used for honest reasons elsewhere.
The situation in which we now find ourselves is at stage #3. The truth is, there are other charmable mobs in the game that are immune to pierce; people just haven't discovered them. As soon as they are found, I'd be willing to bet that our resident powerplayers will abuse the hell out of them, and we'll have to change them as well. The ultimate question is, how do we break this cycle? We could...
- levy some sort of punishment against the abusive character. This won't work because powerplayers' characters are usually interchangeable and disposeable, and we don't have the effort to persecute every new character they pump out.
- make a sweeping or semi-sweeping change. This is what we've been doing, but it sucks. It's a lot harder for a casual player to get gold now, because all the "easy" ways had to be plugged up on account of powerplayers grossly abusing them.
- ban the powerplayer. But for what? Having the time and dedication to play the game hardcore and make juiced up characters? That's not against the rules.
- make it a serious rule violation to robolevel/robofarm gold, then ban the powerplayer.
I think option #4 is the gist of what the recent idea posts advocate, but the truth is, this option sucks too. If you think back to the time when afk spamming wasn't allowed, people were still doing it. Even after we've told people that they aren't allowed to robolevel or robofarm gold, they are still doing it. When we catch someone in the act, there's always an excuse. My Chinese food just arrived. I had to walk the dog. I went out for a smoke. My kitchen caught on fire. And even then, we wouldn't be preventing the problem players from manually farming gold. It wouldn't change the facts that they continually strip an area and prevent anyone else from using it, they hog charmies, and they really disrupt the gameplay for others.
So do we still ban them and embitter them against Dark Risings? I'm not sure that's any more fair than saving powerplayers from themselves by plugging up exploits. Both cases are just addressing the symptom, not the problem.
The underlying problem is that powerplayers, to a large degree, just don't "get" Dark Risings. To them, Dark Risings is something for their sole enjoyment (not unlike a single player game), and they don't care about anyone else's fun. They want the high score--the highest hp, the best PK record, and the highest hit/dam. They want to get guilded and become a vampire because they want the best spells and the best equipment in the game. RP is just a formality required to get those things. In many cases, it's not that the player is mean-spirited or "bad," it's just that they don't understand the game that us admins are trying to make and that the majority of our players enjoy.
Dark Risings 1.0 was not a bad place to be for powerplayers; they were on staff, they were in guilds, they were everywhere. And there's nothing wrong with that kind of MUD per se, but it's not the game that Dark Risings has become. Us admins don't have the energy to run a game with the deep undercurrents of acrimony that those games can breed. We want to run a game that's fun and fair to play.
So I guess the punchline here is that I don't know what to do about the bad apples who spoil the fun for others. They tend not to listen to us staff because they don't "get" us, and since they don't understand what we're trying to accomplish with our game, they often assume that we're just out to get them. Maybe they'll listen to what their peers (all you players) are saying instead. Give it a try. Just remember that you catch more flies with honey.
Tuesday, November 8, 2011
The Truth Behind Wimpy and Trip
This blog post has two parts. The first part is a rant, and the other part is a little more relevant. If you're interested in just reading the detailed technical info, just scroll down past the rant.
Despite this fact that we did not change anything, a number of players insisted that this wimpying on trip was something new and made a big stink about it. Again, I emphasized that it was not new, but some people refused to believe it, either claiming that (a) they knew more about what I changed in the code than I did, or (b) I was purposely lying to them for some nefarious reason. Both accusations were leveled at me directly (that is, at least one player literally called me a liar on OOC).
This bothered me more than usual because it's a gross mischaracterization of the admin staff, and it reeks of a total lack of understanding of how the admin staff runs Dark Risings. We don't typically change major aspects of PK on a whim, try to sneak it into a bug fix, then lie about it. In fact, literally every significant (and even almost every minor) change to PK we have made has been vetted by players, either by inviting select PKers to participate in closed testing or by hosting an open Hell Night. That's just not how we operate, and I've written about our approach to implementation before.
In the next section, I'll walk through the code and explain exactly what is going on when someone wimpys out due to being tripped, and exactly what I changed in April that got everyone so convinced that we screwed up wimpy+trip.
However, let's look at the code for the trip command from August 26, 2006, which predates the changes I made in April 2011 by a good many years:
To translate a little, here's what's going on:
The next question is, where does wimpy factor into this?
As it turns out, a lot of functionality is wrapped up in the damage() routine (Line 8), and wimpy is a part of this. When you trip someone and the game gets to executing Line 8 in the code, lines 11 and 12 don't get executed until the damage() routine is fully complete. Here's what's going on in damage(), in no particular order:
Line 11 above is a special check that was added in 2000 to prevent a similar problem. Before it was added, some PKers had found out that if you manage to KO someone using a knockdown, they would get set to the unconscious position by damage(), but then immediately get woken back up when the rest of the trip code finished and set the person to the sprawled position. Thus, they didn't have to wait the 45 seconds before they recovered from the KO; they could immediately stand up (after their PULSE_VIOLENCE*2 lag from trip) and run away before anyone could loot them. What Line 11 does is only set the person's sprawled position if they weren't rendered (!= means "not equal") dead or unconscious as a result of the damage() routine immediately preceding it.
So, there you have it. Code from 2006 showing that, due to the order in which damage is dealt relative to the instruction to sprawl out the victim, it is possible to wimpy out due to the damage from trip. Sort of.
As Sintar pointed out (and much to my embarrassment), you can wimpy out of a fight even if you're sprawled. Initially I said this was impossible because wimpy just issues the "flee" command automatically for the player, and the "flee" command can only be used by the player if his character is fighting, not sprawled. Go get bashed by a mob and type "flee." You'll see what I mean.
So how can Sintar get bashed by Heimdall, stay on the ground, and still wimpy out? Well, let's look at the wimpy code in the damage() routine, which happens to be at the very end of it:
So does this mean that you will always wimpy flee if sprawled out in PK?
Not quite.
Line 4 is the key here; although wimpy can make you flee regardless of if you're sprawled, Line 4 says that wimpy won't work unless you've got less than PULSE_VIOLENCE/2, or 1.5 seconds, worth of lag left. Since trip gives the victim 6 seconds of lag, this guarantees that, as long as the trip damage itself doesn't cause wimpy
The trip damage shouldn't ever cause wimpy to fire, because the lag is applied before the damage() (and therefore the wimpy code) gets run. So, by the time the trip damage is dealt, the victim already has the 6 seconds of lag. Line 4 will always cause wimpy to fail both when damage() is called by the trip command and for the first 4.5 seconds of lag caused by trip, which translates to a guaranteed minimum of one round of combat before the victim has a chance to flee-while-sprawled.
So why does the damage caused by trip cause the victim to wimpy out?
Because in the change I made back in April, I moved the WAIT_STATE lines in trip (and bash, entangle, armthrow, et cetera) below the damage() line:
Remembering that computers execute commands in-order**, this means that when the damage from trip is dealt, the victim hasn't been lagged by trip yet. So, wimpy will kick in as long as the victim doesn't have more than 1.5 seconds of lagged already queued up from some other source.
Thus, contrary to the big long tirades I've gone on explaining how we never changed anything, we (that is, I) inadvertently did change (and break) wimpying from trip. While it was true that it was always possible to wimpy out from being tripped, trip used to guarantee you 4.5 seconds of combat (at least one round) before your opponent could wimpy out.
Now there is a question of what we should do about this; the majority of players seem to agree that wimpy is fine as-is, but its as-is state is really the result of a bug. If I'm lucky, I will have put everyone to sleep before they read this far down the post, and nobody will ever become aware of my serious folly here. Realistically though, my inadvertent breakage of wimpy/trip (and subsequent ardent denial of doing such a thing) was not fair to the players, so it should be "fixed" and functionally restored to the way it used to be. It was a reasonably fair way of doing it, too; people could still wimpy out of being tripped, but tagging with trip guaranteed you a round of combat to dish out damage before that happened. The subsequent lag was still in the wimp's favor (6 seconds vs. 7 seconds) which is how it remains; the tripper just had a chance at knocking his enemy out with that one round before the wimp could take off again.
Blearg, I hate being wrong, and I hate more when I've been a jerk in the process of being wrong. Maybe I should take a page from Nixon's book and just destroy all the evidence before word gets out.
** Note: these statements aren't really true, but they are close enough to the truth to illustrate my point.
Rant / Background Info
Back in April of this year, a small bugfix went in to address a problem with wimpy. For some reason, a number of players read this change and assumed that the fact that wimpy can kick in when tripped was something new that we had added as a part of that change. The truth of the matter was that trip always triggered wimpy, and the only thing that we had changed was the need to type "stand" after having wimpy-fled from being tripped. The lag on both the tripper and the person being tripped remained the same, the damages were the same, and the fact that wimpy could be activated by the trip skill itself remained the same.Despite this fact that we did not change anything, a number of players insisted that this wimpying on trip was something new and made a big stink about it. Again, I emphasized that it was not new, but some people refused to believe it, either claiming that (a) they knew more about what I changed in the code than I did, or (b) I was purposely lying to them for some nefarious reason. Both accusations were leveled at me directly (that is, at least one player literally called me a liar on OOC).
This bothered me more than usual because it's a gross mischaracterization of the admin staff, and it reeks of a total lack of understanding of how the admin staff runs Dark Risings. We don't typically change major aspects of PK on a whim, try to sneak it into a bug fix, then lie about it. In fact, literally every significant (and even almost every minor) change to PK we have made has been vetted by players, either by inviting select PKers to participate in closed testing or by hosting an open Hell Night. That's just not how we operate, and I've written about our approach to implementation before.
In the next section, I'll walk through the code and explain exactly what is going on when someone wimpys out due to being tripped, and exactly what I changed in April that got everyone so convinced that we screwed up wimpy+trip.
Detailed Technical Info
I think a large reason people don't understand/believe what I did and did not change in April is that they don't fully understand how trip works. To the casual player, the trip command does these things:- sends messages saying "So-and-so trips you and you go down!"
- does a little damage ("So-and-so's trip scratches you.")
- sets you to the sprawled position so you have to stand up before you can do other stuff
However, let's look at the code for the trip command from August 26, 2006, which predates the changes I made in April 2011 by a good many years:
- act("$n trips you and you go down!",ch,NULL,victim,TO_VICT);
- act("You trip $N and $N goes down!",ch,NULL,victim,TO_CHAR);
- act("$n trips $N, sending $M to the ground.",ch,NULL,victim,TO_NOTVICT);
- check_improve(ch, gsn_trip, TRUE, 1);
- WAIT_STATE(victim, PULSE_VIOLENCE*2);
- WAIT_STATE(ch, PULSE_VIOLENCE*2+4);
- damage(ch, victim, number_range(2, 2 + 2 * victim->size), gsn_trip,
- DAM_BASH, TRUE);
- if ( victim->position != POS_DEAD && victim->position != POS_UNCONCIOUS )
- victim->position = POS_SPRAWLED;
To translate a little, here's what's going on:
- Lines 1-3 are the messages that get sent to the person getting tripped (called victim), the person doing the tripping (called ch), and the rest of the room
- Line 4 is the check to see if your trip skill% should go up
- Line 6 is what puts the trip lag on the person getting tripped (victim). It says PULSE_VIOLENCE*2, which means two rounds of combat, or six seconds.
- Line 7 is what puts the trip lag on the person using trip (ch). PULSE_VIOLENCE*2+4 means six seconds (PULSE_VIOLENCE*2) plus another full second, so a total of seven seconds of lag, or one more second of lag than the victim.
- Line 8-9 is what does the damage from trip. The messages ("Your trip scratches so-and-so.") is generated within this damage() routine, which is why they don't appear here.
- the first parameter, ch, indicates who is dealing the damage
- the second parameter, victim, indicates who should receive it
- the third parameter, number_range(2, 2+2*victim->size), is the amount of damage that should be done before sanc/ward/resists/etc. In this case, it's doing a random amount of damage between 2 and 2+2*(the size of your race)..it's not much.
- the fourth parameter, gsn_trip, indicates the damnoun for the damage (in this case, it'll show up as "Your trip scratches ...")
- the fifth parameter, DAM_BASH, indicates the damage type of the damage. Since it's DAM_BASH here, it'll do bash-type damage. If it were DAM_HOLY, it'd do holy damage; DAM_ACID would do acid damage, and so on.
- the sixth parameter, TRUE, just indicates if the damage message ("Your trip scratches ...") should be sent out at all. If this were set to FALSE, you'd take damage but it would be silent (like how dirt kick is).
- Line 11 is a bugfix that was added back in 2000. More on this below.
- Line 12 is what puts the victim on the ground instead of in the regular fighting position
The next question is, where does wimpy factor into this?
As it turns out, a lot of functionality is wrapped up in the damage() routine (Line 8), and wimpy is a part of this. When you trip someone and the game gets to executing Line 8 in the code, lines 11 and 12 don't get executed until the damage() routine is fully complete. Here's what's going on in damage(), in no particular order:
- the effects of sanctuary are applied
- a check is made to see if the damage should hit a mirror image
- hp is subtracted from the victim
- if the victim's resulting hp falls below 1, either knock them out or kill them (depending on whether ch is a player or a mob)
- if the victim's resulting hp falls below their wimpy, make them flee
- Everyone gets sent the appropriate "trips you and you go down!" message (lines 1-3)
- ch's trip skill might improve (line 4)
- both parties get lagged (lines 6-7)
- damage is dealt to victim (line 8-9)
- if this damage drops victim's hp below his wimpy, he flees at this point
- if this damage drops victim's hp below 1, he is knocked out at this point
- victim is tossed on the ground AFTER the damage() routine completes
Line 11 above is a special check that was added in 2000 to prevent a similar problem. Before it was added, some PKers had found out that if you manage to KO someone using a knockdown, they would get set to the unconscious position by damage(), but then immediately get woken back up when the rest of the trip code finished and set the person to the sprawled position. Thus, they didn't have to wait the 45 seconds before they recovered from the KO; they could immediately stand up (after their PULSE_VIOLENCE*2 lag from trip) and run away before anyone could loot them. What Line 11 does is only set the person's sprawled position if they weren't rendered (!= means "not equal") dead or unconscious as a result of the damage() routine immediately preceding it.
So, there you have it. Code from 2006 showing that, due to the order in which damage is dealt relative to the instruction to sprawl out the victim, it is possible to wimpy out due to the damage from trip. Sort of.
As Sintar pointed out (and much to my embarrassment), you can wimpy out of a fight even if you're sprawled. Initially I said this was impossible because wimpy just issues the "flee" command automatically for the player, and the "flee" command can only be used by the player if his character is fighting, not sprawled. Go get bashed by a mob and type "flee." You'll see what I mean.
So how can Sintar get bashed by Heimdall, stay on the ground, and still wimpy out? Well, let's look at the wimpy code in the damage() routine, which happens to be at the very end of it:
- if ( !IS_NPC(victim)
- && victim->hit > 0
- && victim->hit <= victim->wimpy
- && victim->wait < PULSE_VIOLENCE / 2 )
- do_flee( victim, "" );
with a brief translation:
The reason Sintar's wimpy lets him use the flee command is a bit hard to explain; in essence, the part of the code that takes whatever command you type (e.g., "flee") and translates that into a command that the game understands (e.g., do_flee()) is what imposes the restrictions on whether or not you have to be standing to use a command. Wimpy bypasses that command interpreter entirely, so there's no position check.- if the victim is not an NPC (that is, they are a PC, or a player character)... (line 1)
- AND the victim's hp is above zero (they aren't KO'ed or dead yet)... (line 2)
- AND the victim's hp is less than or equal to their wimpy setting... (line 3)
- AND their current lag is less than PULSE_VIOLENCE/2... (line 4)
- then execute the "flee" command directly, bypassing all the regular checks to make sure the person is standing, of the appropriate level to use the command, etc. (line 5)
So does this mean that you will always wimpy flee if sprawled out in PK?
Not quite.
Line 4 is the key here; although wimpy can make you flee regardless of if you're sprawled, Line 4 says that wimpy won't work unless you've got less than PULSE_VIOLENCE/2, or 1.5 seconds, worth of lag left. Since trip gives the victim 6 seconds of lag, this guarantees that, as long as the trip damage itself doesn't cause wimpy
CRAP
The trip damage shouldn't ever cause wimpy to fire, because the lag is applied before the damage() (and therefore the wimpy code) gets run. So, by the time the trip damage is dealt, the victim already has the 6 seconds of lag. Line 4 will always cause wimpy to fail both when damage() is called by the trip command and for the first 4.5 seconds of lag caused by trip, which translates to a guaranteed minimum of one round of combat before the victim has a chance to flee-while-sprawled.
So why does the damage caused by trip cause the victim to wimpy out?
Because in the change I made back in April, I moved the WAIT_STATE lines in trip (and bash, entangle, armthrow, et cetera) below the damage() line:
- act("$n trips you and you go down!",ch,NULL,victim,TO_VICT);
- act("You trip $N and $N goes down!",ch,NULL,victim,TO_CHAR);
- act("$n trips $N, sending $M to the ground.",ch,NULL,victim,TO_NOTVICT);
- check_improve(ch,gsn_trip,TRUE,1);
- damage(ch,victim,number_range(2, 2 + 2 * victim->size),gsn_trip,
- DAM_BASH,TRUE);
- WAIT_STATE(victim,PULSE_VIOLENCE*2);
- WAIT_STATE(ch,PULSE_VIOLENCE*2+4);
- /* damage() can cause wimpy which changes victim->in_room */
- if (victim->position > POS_FLATFOOTED && victim->in_room == ch->in_room)
- victim->position = POS_SPRAWLED;
Remembering that computers execute commands in-order**, this means that when the damage from trip is dealt, the victim hasn't been lagged by trip yet. So, wimpy will kick in as long as the victim doesn't have more than 1.5 seconds of lagged already queued up from some other source.
Thus, contrary to the big long tirades I've gone on explaining how we never changed anything, we (that is, I) inadvertently did change (and break) wimpying from trip. While it was true that it was always possible to wimpy out from being tripped, trip used to guarantee you 4.5 seconds of combat (at least one round) before your opponent could wimpy out.
Now there is a question of what we should do about this; the majority of players seem to agree that wimpy is fine as-is, but its as-is state is really the result of a bug. If I'm lucky, I will have put everyone to sleep before they read this far down the post, and nobody will ever become aware of my serious folly here. Realistically though, my inadvertent breakage of wimpy/trip (and subsequent ardent denial of doing such a thing) was not fair to the players, so it should be "fixed" and functionally restored to the way it used to be. It was a reasonably fair way of doing it, too; people could still wimpy out of being tripped, but tagging with trip guaranteed you a round of combat to dish out damage before that happened. The subsequent lag was still in the wimp's favor (6 seconds vs. 7 seconds) which is how it remains; the tripper just had a chance at knocking his enemy out with that one round before the wimp could take off again.
Blearg, I hate being wrong, and I hate more when I've been a jerk in the process of being wrong. Maybe I should take a page from Nixon's book and just destroy all the evidence before word gets out.
** Note: these statements aren't really true, but they are close enough to the truth to illustrate my point.
Monday, November 7, 2011
Coding Quandary for Brawler Scores
One of the principal challenges in establishing this new brawler scoreboard was establishing the framework for it. The scoreboard, in the simplest sense, made of a string of individual brawlers and their scores. As such, it would make sense to attach this information to each brawler's pfile (which is where their stats, equipment, description, et cetera are stored) since brawler scores are just another stat. At the same time though, pfiles are loaded into the game dynamically--if a character isn't logged in, all of the information stored in his pfile (stats, equipment, description, et cetera) are totally unknown to the game.
Think about it. Are there any commands that let you get information from another character who isn't logged in? The only example of this that comes to mind reading notes posted by characters who aren't logged in; this is possible because notes are stored in a fashion similar to areas--they are saved to their own special file that is read in when the game starts up, and then the list of notes just floats in the game's permanent memory forever. As new notes are posted, they also go into permanent memory, and they are saved to the special note file so that they can be reloaded after the next reboot.
Notes are static though; once they're up, they really never need to be changed. Brawler stats, on the other hand, will constantly be changing as people claim victory over each other. Although these changes will only happen when brawlers are logged in to fight each other, what do we do with their scores when those brawlers log out? They still need to be accessible by everyone on the scoreboard, and they need to be able to be reloaded after reboots.
This question highlights one of the principal design decisions I had to make in deciding how to actually implement this brawler scoreboard. On the one hand, brawler scores need to be stored permanently like notes are, but on the other hand, they are fundamentally a stat that is attached to one and only one character. Furthermore, we may need to be able to modify brawler scores even if the brawlers aren't logged in (e.g., in case of wimpouts or losses that need to be verified by imms). How can these conflicting ideas be reconciled? Here are the two options that I first considered:
Think about it. Are there any commands that let you get information from another character who isn't logged in? The only example of this that comes to mind reading notes posted by characters who aren't logged in; this is possible because notes are stored in a fashion similar to areas--they are saved to their own special file that is read in when the game starts up, and then the list of notes just floats in the game's permanent memory forever. As new notes are posted, they also go into permanent memory, and they are saved to the special note file so that they can be reloaded after the next reboot.
Notes are static though; once they're up, they really never need to be changed. Brawler stats, on the other hand, will constantly be changing as people claim victory over each other. Although these changes will only happen when brawlers are logged in to fight each other, what do we do with their scores when those brawlers log out? They still need to be accessible by everyone on the scoreboard, and they need to be able to be reloaded after reboots.
This question highlights one of the principal design decisions I had to make in deciding how to actually implement this brawler scoreboard. On the one hand, brawler scores need to be stored permanently like notes are, but on the other hand, they are fundamentally a stat that is attached to one and only one character. Furthermore, we may need to be able to modify brawler scores even if the brawlers aren't logged in (e.g., in case of wimpouts or losses that need to be verified by imms). How can these conflicting ideas be reconciled? Here are the two options that I first considered:
- Store brawler scores in permanent memory, but have players "download" them to their character when they log in and "upload" their new scores when they log out
- Store brawler scores in permanent memory AND on the pfile, then keep track of which set of scores (the ones in permanent memory or the ones on the pfile) were updated most recently and use those
Unfortunately, both of these options raise problems with consistency. Because information gets stored in two places in both cases, it becomes easy to envision a scenario where the information in one place doesn't get updated in the other place and suddenly one brawler has two different sets of scores. This isn't an issue in 100% bug-free code, but the fact is that the system is not robust; if I (or a future coder) needs to modify the brawler code a few years down the road, we have to remember to make sure that both sets of scores need to be manually synced up or else problems arise.
A better option (and what I wound up doing) is to store brawler stats in permanent memory, and instead of worry about uploading/downloading/syncing those numbers against a pfile when it is loaded, just "attach" each player's brawler score info (still in permanent memory) to the pfile when the character logs in. When the character logs out, the attachment breaks, but the brawler record is still floating in the permanent memory.
While we still have to make sure that brawler scores are properly attached to characters when they're logged in, this is far less flaky of a process than ensuring data is consistent across two places since it's trivial to perform the attachment. So, in addition to checking for attachment when a character logs in, we can check for attachment at other critical points in the code such as when a brawler gets thrown out of brawler or scores another kill.
Speaking of getting thrown out of brawler, the reason why I bring this all up is because Stage 2 will include a new "leavebrawler" command that players can use to voluntarily quit. However, quitting Brawler will also ban you from re-joining it for thirty real-life days. Because we store brawler scores in permanent memory rather than on the pfile, this ban has the unintentional (but fortuitous) effect of persisting across recreates. Even though a player may have deleted and re-created his character, that character's brawler record is stored in permanent memory and cannot be deleted by the player.
This might sound a bit trivial ("It'll take 30 days to level back up to 50 anyway!"), but a more powerful result of this is that immortals will have the ability to ban characters from brawler for life (such as may be necessary if they are caught abusing brawler perks). Recreating won't circumvent that ban, which imposes an interesting incentive for players to not try to get cheap healing in a real fight by cheating the system. A ban from brawler will truly be a ban for life.
Friday, November 4, 2011
Brawler Scoreboard Stage 2
We're moving forward with implementing the next stage of our new Brawler system, and based on our original ideas and some suggestions and observations from Stage 1, I think we're looking at rolling out features some fun new features.
A major component that we're currently lacking is the ability for the game to know that a particular fight is a brawl as it's happening; right now, brawls only become brawls when the victory command is used. To address this best, we're planning to add a command that will act as an "opening move" to initiate a brawl called "clobber."
We envision this clobber command functioning like backstab, where one Brawler uses it to tag another Brawler, and thereafter, both combatants are identified as brawling each other. This establishes a nice framework where we can implement some features exclusive to brawls to make it easier, safer, and cheaper to learn PK as a brawler.
One of the significant (and controversial) features we'd like to include immediately is ultra-low-cost healing for brawls. This has the benefit of letting people get up and running in PK without having to grind for gold, and really turns brawling into its own minigame within Dark Risings. However, there are a lot of potential issues here:
I think the pros are self-evident, but let's look at the cons a little more closely.
Realistically though, gold farming has become the norm these days, and there's really no RP involved in that process anyway. So I guess the damage has already been done, and giving Brawlers cheap healing won't cause too much more trouble. It's just that the nightmare scenario for me is having a game full of players used to pure-PK MUDs who log in and are totally OOC in says, tells, over the brawler channel, etc, and generally degrade the quality of the game. I absolutely do not want this, and I hope catering to PKers in this way won't effect that.
A major component that we're currently lacking is the ability for the game to know that a particular fight is a brawl as it's happening; right now, brawls only become brawls when the victory command is used. To address this best, we're planning to add a command that will act as an "opening move" to initiate a brawl called "clobber."
We envision this clobber command functioning like backstab, where one Brawler uses it to tag another Brawler, and thereafter, both combatants are identified as brawling each other. This establishes a nice framework where we can implement some features exclusive to brawls to make it easier, safer, and cheaper to learn PK as a brawler.
One of the significant (and controversial) features we'd like to include immediately is ultra-low-cost healing for brawls. This has the benefit of letting people get up and running in PK without having to grind for gold, and really turns brawling into its own minigame within Dark Risings. However, there are a lot of potential issues here:
PROS:
|
CONS:
|
1. Less of a Need for Pure-PK Players to Actually Play the Game
"and stay IC" should be tacked on to the end of this con, and it's one of the bigger reservations I have. Catering to PK-only players draws in a bigger pbase, and as long as they aren't disruptive to the rest of the game, I don't really mind. However, I like to think that the process of getting money can often involve RP (e.g., collecting people to go kill mobs for equipment), and if we obviate the need for pure-PK players to get gold, it's easy to envision them having no reason to bother trying to roleplay at all.Realistically though, gold farming has become the norm these days, and there's really no RP involved in that process anyway. So I guess the damage has already been done, and giving Brawlers cheap healing won't cause too much more trouble. It's just that the nightmare scenario for me is having a game full of players used to pure-PK MUDs who log in and are totally OOC in says, tells, over the brawler channel, etc, and generally degrade the quality of the game. I absolutely do not want this, and I hope catering to PKers in this way won't effect that.
2. LOTS of Potential for Abuse
Of course, this is the most immediately problematic, because there are a number of ways this healing discount can be abused. Here are a few scenarios.- An Inferno named Jane jumps Bob the Brawler who has a contract on his head. The Bob the Brawler just initiates a brawl against Jane so that Brawler rules (and cheap healing) are in effect and Jane can no longer loot on KO, etc.
- In a real PK, player Bob is getting attacked by player Jane. He has a buddy, Harry, initiate a brawl against him so that Bob gets discounted healing since the game thinks he's brawling Harry when in fact he's fighting for his life against Jane.
- The opposite happens, and Bob initiates a brawl to get discounted healing, then jumps Jane.
Unfortunately, I really only see two solutions to these sorts of abuses. The first one, which perhaps is what many players would immediately think, is to have an immortal arbitrate cases of abuse like this, and have stiff punishments for people who do this sort of thing. This is a possibility, but we don't really have the staffing manpower to be micromanaging brawls and this is not really a good solution.
The second solution is to make it so that this "clobber" command to start a brawl can only be used when both participants are not in PK fightlag. This solves the issues of people initiating brawls mid-fight to abuse the perks of brawling, but it also means that if you forget to make your initial tag with clobber, you have to flee safe before you can correct the issue and re-tag to initiate the brawl. In practice, I suspect this might get annoying.
Another idea would be to create the opposite command of "clobber" and have it be something like "nobrawl." If Jane wants to jump Bob for real, she can issue the "nobrawl" command on him after tagging him to lock Bob (and Jane) out of initiating brawls until they leave fightlag. This is getting a bit complicated though, as Jane would have to remember to keep issuing nobrawl throughout the fight in case Bob momentarily got out of fightlag. It also all operates under the assumption that Bob is definitely going to cheat to get out of getting KO'ed by Jane, which should be a pretty remote possibility to begin with. Throwing a ton of complicated code at such a narrow problem is not something I like doing.
At any rate, for stage 2, the only brawler perk we're looking to put in would be this discounted healing. However, we might also consider features such as...
- people flagged as being in brawls never leave fightlag (this was suggested a few times)
- people flagged as being in brawls cannot be looted (by either anyone, or their brawling opponent) once they are KO'ed
- announcements over the Brawler channel that Bob and Jane have begun brawling
For right now though, just figuring out how to prevent people from spuriously declaring brawls mid-fight to get out of a real PK is challenging enough. Tying it to fight lag is tricky because there may be times when brawlers get out of fightlag but aren't actually done fighting (running to heal, running for a trap, etc), but we're not quite ready to force brawlers to remain in fightlag until someone gets KO'ed.
Comments, ideas, or suggestions are welcome. Since this post won't fit into a note in the game, it's probably best to leave replies (anonymously or otherwise) as comments to the blog here.
Thursday, November 3, 2011
Taking a step back
Just a forewarning: this post is long and rambling. You might want to save it for bathroom reading.
There has been a lot more of a stir surrounding Sidonie's idea post about changing the way sleep/poison/pinch works than I expected, and an interesting discussion came up on OOC yesterday which was suggestive of an ongoing clash of perception. For the sake of just delineating where I (and I think the other admins) are coming from, I think I'll ramble about it.
The issue that came up yesterday was centered around sleep's duration of 50 ticks at level 50. There were essentially two camps here:
There has been a lot more of a stir surrounding Sidonie's idea post about changing the way sleep/poison/pinch works than I expected, and an interesting discussion came up on OOC yesterday which was suggestive of an ongoing clash of perception. For the sake of just delineating where I (and I think the other admins) are coming from, I think I'll ramble about it.
The issue that came up yesterday was centered around sleep's duration of 50 ticks at level 50. There were essentially two camps here:
- sleep's long duration is good way to force people to cool off; if a BR is pestering you, or if someone is freaking out and going kamikaze after getting KO'ed, the 37 minute timeout is very useful
- sleep's long duration is unreasonable since it doesn't let a player actually play.
Oogon then mentioned something that really sheds light on this rift of perceptions that splits our current playerbase:
[OOC] Oogon: 'But really, how often is sleep used in that regard?'
[OOC] Oogon: 'To just let someone 'cool off'.'
And you know, it's the truth. I've the benefit of remembering when sleeping pester characters (BRs, naked rogues, etc), was relatively normal, and during those days, slapping a player-mandated time-out was really the only recourse available. However, something that a lot of older players seem not to realize is that Dark Risings really isn't the same game as it was five years ago; sure, it has the same name and the same backstory, but take a look around. The areas are no longer static: Lilith has the power to corrupt the entire town of Three Firs, gypsy mobs remember their enemies, and the game is dotted with mini-quests that offer 5000-10000 experience for completing them. The races are different: avariels are no longer vuln to all fire, and ogre weres aren't vuln to all magic. The classes are different: there are now templars, which offer a wildly different approach to PK. Pick any aspect of the game, really. I'll bet it's not the same now as it was five years ago.
More importantly, though, is that the whole process of implementation has wildly changed. This point may not be as evident to players, but I think it's really the single largest change that separates "old Dark Risings" from "new Dark Risings." Take, for example, the aforementioned avariel vuln to fire.
When avariels were made vuln to fire (this happened in around 2001), there was no discussion or player input. There was a reboot and a terse note saying "avariels are now vuln to fire." Since my main character was an avariel, this was a pretty devastating change; I went from having no vulnerabilities to being vulnerable to a spell that almost every class can cast (fireball). I immediately protested since avariels really weren't very good to begin with, but my notes fell on deaf ears. I wound up leaving the game a few months later, and while I was gone, flashfire was changed to no longer do fire damage since it was deemed to crippling against avariels. This mitigated the problem to a degree, but it also left one of the "elemental" spells doing unintuitively and decidedly non-elemental damage.
I think these sorts of changes were very telling of the "old Dark Risings" approach to implementation; imps did what they thought was best for the game with a sort of players-be-damned attitude, and if the change proved to be unpopular or unbalancing, another change would be rolled out to mitigate. This sort of implementation practice also meant a lot of decidedly reactionary changes went in; old players are rife with stories of how some skill got changed because an imp got beaten by someone gimping that skill in PK. I'm not sure if these stories hold water, but it doesn't really matter now.
Fast forwarding to the "new Dark Risings," we really don't operate this way at all, and I think this is clearly evidenced by the fact that we solicited player input regarding this poison/sleep/pinch issue. We also solicited (and continue to solicit) feedback on the brawler scoreboard idea. The new spells that Arcaenum has are 100% player conceived and designed. In fact, I don't think there's a single change that we've posted in the last year (except a few exploit fixes) that were done without player involvement.
So what has been the driving force behind this transition from "old Dark Risings" to "new Dark Risings?"
At the "old Dark Risings," the imps had always been people who were at Dark Risings from the very beginning. All of them had always been imms or admins, and they all had a hand in creating Dark Risings out of nothing and making changes before there were even players to upset. In many ways, they had every entitlement to do as they saw fit, because everything that Dark Risings had become was a result of their design.
However, this also created a rift between the players and the staff at times, and in many cases, set the stage for an "us against them" mentality at many levels. The people making the decisions had always been the boss and never enjoyed the "player experience" of not being in control and having changes go in without their approval (or knowledge!).
The "new Dark Risings" really began when Sidonie and I took over the active implementation of the game. When Mark relinquished his position as active imp, Dark Risings was, for the first time, being run by people who had started DR as regular old players. We remember what it was like to be a nobody, and to be a player, and to be the victim of sometimes-heavy-handed changes forced down through the ranks. We also weren't operating under the assumption that we always know what's best for the game, because much of the game was designed and played without us. Dark Risings is "ours" in the sense that our names are on the paperwork, and we do have the benefit of being long-time players with some amount of wisdom, but I think the defining characteristic of the "new Dark Risings" is that its implementation is far more player-inclusive.
I'd like to think that Dark Risings is less dictatorial and more communal now. Of course, that's not to say that us admins still aren't the boss. We are the boss, and we make no bones about letting people know that from time to time. But this new Dark Risings has become a product of player-driven efforts and RP, so we have nothing to gain by excluding players.
Sunday, October 23, 2011
Brawler Scoreboard Update
I've been working on getting this Brawler scoreboard system up and running, and at the present pace, it seems like we're going to likely implement this in stages. Right now the basics are working, but Team Admin(tm) will probably have to decide how to pretty it all up before we can roll out this first stage.
Right now, the general process is that you knock out another Brawler and use the "victory" command on their unconscious body (much like murder or loot) which registers the victory. To the loser, the process would look something like this:
Parviane utters the words, 'xahzf barh'.
Parviane sends a blast of water at you.
Parviane's blast of water <*>_MORTALLY WOUNDS_<*> you!
You are unconscious.
1<1729> 1012<1012> 394<394> <0g 5s> <NEW:FIGHTLAG>
Parviane has claimed victory over you!
Right now, the general process is that you knock out another Brawler and use the "victory" command on their unconscious body (much like murder or loot) which registers the victory. To the loser, the process would look something like this:
Parviane utters the words, 'xahzf barh'.
Parviane sends a blast of water at you.
Parviane's blast of water <*>_MORTALLY WOUNDS_<*> you!
You are unconscious.
1<1729> 1012<1012> 394<394> <0g 5s> <NEW:FIGHTLAG>
Parviane has claimed victory over you!
These victories get added to a global scoreboard which can be accessed via some command (currently called "scoreboard," but this is just a work-in-progress name...it's apt to change). The current rough draft of the scoreboard then looks like this:
Name Wins Losses Wimpouts K/D K/D*
Muristang 1(1) 5(2) 0(0) 0.200 0.500
Parviane 5(2) 0(0) 0(0) 5.000 2.000
Suqlaheru 1(1) 2(2) 0(0) 0.500 0.500
The statistics presented are pretty straightforward; the reason there are two numbers under wins/losses/wimpouts is because the game will keep track of unique wins/losses/wimpouts in addition to overall total. So, in the above example, Parviane beat Muristang four times and Suqlaheru once. This is a total of five wins, but since they were against only two people, there are only two unique wins registered...hence the 5(2) under the Wins column. This should help make obvious cases where one person is racking up a lot of wins by fighting the same opponent.
The K/D and K/D* columns are the standard kill/deaths ratio and the unique kills/unique deaths ratio, respectively.
Under the hood, this system actually keeps a record of every fight (registered by the "victory" command), so brawlers can access a list of their fights using the tentatively named "brawllist" command. If Muristang was to use this command, it would look like this:
1729<1729> 1012<1012> 394<394> <0g 5s> <NEW:>
brawllist
[ 1] Oct 23 2011: Loss against Parviane
[ 2] Oct 23 2011: Loss against Suqlaheru
[ 3] Oct 23 2011: Win against Suqlaheru
[ 4] Oct 23 2011: Loss against Parviane
[ 5] Oct 23 2011: Loss against Parviane
[ 6] Oct 23 2011: Loss against Parviane
At present, these records really don't contain a lot of data other than the date of the fight, the two combatants, and the outcome. However, it does leave the door open to a number of possibilities in the future such as amount of damage done by each side, the duration of the fight, number of times blinded, et cetera. The system is robust enough to allow for the easy addition of features as we move forward.
Anyway, this is just a preview of the first draft of how the brawler scoreboard system will work. Nothing is finalized, and a lot of features are missing. In fact, some core features may still be missing when we decide to roll out the first stage; we haven't discussed whether it'd be better to let you all play with this system live before everything is prim, or to wait until the entire system is done before we release it. Specifically, the following features are currently wholly absent:
- any way to sort the scoreboard
- the entire wimpout reporting system
- any way for immortals to arbitrate fight outcomes and change the scoreboard
- monthly cycling of the scoreboard and retention of each month's top scorers
- automatic monitoring of inactive brawlers
- any diagnostics for admins to make sure the system behaves itself
However, the framework is complete and it's quite flexible and expandable. All in all, I'm quite pleased with the progress and am excited to see how it gets used once Stage 1 is out.
Monday, September 26, 2011
Chrysalis Games: For the Love of the Game (And Its Players)
Sidonie's posted to her blog, and it's more than worth linking here:
Thursday, August 11, 2011
Chrysalis Games: Away in White, Back in Black
For those who may not be subscribed to it, Sidonie posted on her blog about continuing our efforts in our other mud project.
Chrysalis Games: Away in White, Back in Black
Since we're probably going to be working on both games at the same time, I think keeping up with our project will offer some insights into where Dark Risings may be going.
Chrysalis Games: Away in White, Back in Black
Since we're probably going to be working on both games at the same time, I think keeping up with our project will offer some insights into where Dark Risings may be going.
Thursday, April 28, 2011
Sorry Mark
A number of years ago when I first came back to Dark Risings to help run Gypsy, a little feature called Hevige Nacht (HN) was in full swing which essentially gave players a real-life hour where anyone could attack (and loot) anyone else without any IC reason other than it being HN. Considering the fact that I had left the game several years earlier in large part due to roleless PK, I saw HN as an unacceptable deviation from DR's long-held classification of being an "RP MUD with PK," and I made a big stink about it.
Part of the stink I raised involved drumming up support for my "end HN now!" campaign with some old higher-profile DR player pals of mine. One such pal was a fellow (let's call him P) who, for all intents and purposes, was no longer playing the game and would only log in once in a while to read notes and maintain appearances. Upon hearing my tales of HN horrors, he logged his main character and posted a big, two-idea-long diatribe against HN that summarized everything I'd been saying about the whole HN idea all along. Awesome, right?
Actually, the only reason I remember that big posting is because Mark's response was
Fast forwarding a few years, now I find myself in Mark's position. Players who haven't been logging, much less actually playing and keeping abreast of what's going on in the game, crawl out of the woodwork and posit these grand schemes about how aspects of Dark Risings are fundamentally broken. Forget all that business about actually experiencing the proclaimed brokenness, because Gedankenexperiments and weeks (or months) of absence grant supreme enlightenment.
Now, after having been rubbed the wrong way by a no-show player who proclaimed to have better insight into PK than those of us who actually watch and participate in it on a daily basis, I see why Mark reacted the way he did to P's idea.
So, although it's five years late, sorry Mark! I now understand.
Parviane
P.S. also, sorry to the guy who lost all his character's equipment that one night to prove my point about abusing HN. It was not nice, and rest assured, we did get yelled at for it.
Part of the stink I raised involved drumming up support for my "end HN now!" campaign with some old higher-profile DR player pals of mine. One such pal was a fellow (let's call him P) who, for all intents and purposes, was no longer playing the game and would only log in once in a while to read notes and maintain appearances. Upon hearing my tales of HN horrors, he logged his main character and posted a big, two-idea-long diatribe against HN that summarized everything I'd been saying about the whole HN idea all along. Awesome, right?
Actually, the only reason I remember that big posting is because Mark's response was
[OOC] Mark: 'You know what makes me happy? [P], logging on to post a 2 part note about how horrid Hevige Nacht is, after being gone for most of its existance if not all, and then disappearing again.'Mark did pull the plug on HN the day after P posted that two-part idea, so at the time I just thought Mark was being a sourpus because we complained loudly enough to make him back down on the issue.
Fast forwarding a few years, now I find myself in Mark's position. Players who haven't been logging, much less actually playing and keeping abreast of what's going on in the game, crawl out of the woodwork and posit these grand schemes about how aspects of Dark Risings are fundamentally broken. Forget all that business about actually experiencing the proclaimed brokenness, because Gedankenexperiments and weeks (or months) of absence grant supreme enlightenment.
Now, after having been rubbed the wrong way by a no-show player who proclaimed to have better insight into PK than those of us who actually watch and participate in it on a daily basis, I see why Mark reacted the way he did to P's idea.
So, although it's five years late, sorry Mark! I now understand.
Parviane
P.S. also, sorry to the guy who lost all his character's equipment that one night to prove my point about abusing HN. It was not nice, and rest assured, we did get yelled at for it.
Subscribe to:
Posts (Atom)