Showing posts with label insider info. Show all posts
Showing posts with label insider info. Show all posts

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:

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.

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 :)

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.

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:
  1. sends messages saying "So-and-so trips you and you go down!"
  2. does a little damage ("So-and-so's trip scratches you.")
  3. sets you to the sprawled position so you have to stand up before you can do other stuff
and they all happen at once.  You successfully trip someone, and they're on the ground instantaneously.  This isn't an unreasonable assessment, but the truth is that they don't all happen at once.  In fact, computers really can't do two things at once**; they take an instruction to do something, then they do it, then they take the next instruction, do it, and so on.  The reason it seems to happen all at once is because computers do this VERY quickly--our server's 3.2GHz processors can carry out 3.2 billion instructions per second**, or over three instructions every nanosecond.  To put that into perspective, in the time it takes you to blink your eye (~300ms), Dark Risings knocks out a billion instructions...so it's all effectively instantaneous to the player.

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:

  1. act("$n trips you and you go down!",ch,NULL,victim,TO_VICT);
  2. act("You trip $N and $N goes down!",ch,NULL,victim,TO_CHAR);
  3. act("$n trips $N, sending $M to the ground.",ch,NULL,victim,TO_NOTVICT);
  4. check_improve(ch, gsn_trip, TRUE, 1);
  5.  
  6. WAIT_STATE(victim, PULSE_VIOLENCE*2);
  7. WAIT_STATE(ch, PULSE_VIOLENCE*2+4);
  8. damage(ch, victim, number_range(2, 2 + 2 * victim->size), gsn_trip,
  9.    DAM_BASH, TRUE);
  10.  
  11. if ( victim->position != POS_DEAD && victim->position != POS_UNCONCIOUS )
  12.     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
That last bullet point is the killer here.  Keeping in mind that computers can only do one thing at a time, here's what's happening with the trip command:
  1. Everyone gets sent the appropriate "trips you and you go down!" message (lines 1-3)
  2. ch's trip skill might improve (line 4)
  3. both parties get lagged (lines 6-7)
  4. 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
  5. victim is tossed on the ground AFTER the damage() routine completes
So what's happening is that, since the instruction to actually knock the victim to the ground comes after the damage is dealt, the victim will have already fled (due to damage()) before the trip code ever gets to the point where the victim gets sprawled.  Thus, this old code from 2006 was making people sprawled out even though they had already wimpy-fled from the room.

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:

  1. if ( !IS_NPC(victim)
  2. &&   victim->hit > 0
  3. &&   victim->hit <= victim->wimpy
  4. &&   victim->wait < PULSE_VIOLENCE / 2 )
  5.    do_flee( victim, "" );

with a brief translation:
  • 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)
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.

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:

  1. act("$n trips you and you go down!",ch,NULL,victim,TO_VICT);
  2. act("You trip $N and $N goes down!",ch,NULL,victim,TO_CHAR);
  3. act("$n trips $N, sending $M to the ground.",ch,NULL,victim,TO_NOTVICT);
  4. check_improve(ch,gsn_trip,TRUE,1);
  5.  
  6. damage(ch,victim,number_range(2, 2 +  2 * victim->size),gsn_trip,
  7.     DAM_BASH,TRUE);
  8.  
  9. WAIT_STATE(victim,PULSE_VIOLENCE*2);
  10. WAIT_STATE(ch,PULSE_VIOLENCE*2+4);
  11.  
  12. /* damage() can cause wimpy which changes victim->in_room */
  13. if (victim->position > POS_FLATFOOTED && victim->in_room == ch->in_room)
  14.     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.

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:

PROS:
  1. no grinding for gold if you just want to pk for fun
  2. potentially attracts new players who may start out just looking for a good PK mud (but get sucked into RP in search for a vamp, etc)
  3. cements in PK as a distinct minigame within Dark Risings
CONS:
  1. less of a need for pure-PK players to actually play the game since they don't need to worry about collecting gold
  2. LOTS of potential for abuse if not coded properly
I think the pros are self-evident, but let's look at the cons a little more closely.

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.

  1. 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.
  2. 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.
  3. 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.

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!

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.

Wednesday, April 13, 2011

Memories

If there's one thing science has taught me, it's that the best way to sell an idea is with pretty pictures. So, here's a pretty picture:


We've been having memory issues in the game intermittently since we came back, and the diagram offers a good illustration of the problem. When this bug first manifested, it so happened that I was trying to edit something on our game server and was rudely surprised by all manner of warnings about having insufficient memory to even open the text editor. Sure enough, somehow our game's memory footprint had blown up (seemingly overnight) to over twice its normal size, and there was very little to indicate what had happened. The solution then was to immediately reboot the MUD to flush memory and start from scratch, contact our provider and up our memory, and create a tool to keep track of our game's memory usage.

I've been checking the data dumped out by this tool daily to see if the memory blowup could be reproduced, and today was the first day I had a bite on the line. I suspected to find logs of someone doing something stupid coinciding with this big spike (like spamming haggle, exploiting some bug, etc), but there was nothing. Going back to my own personal logs of that morning though, the memory spikes happened around a time when Sidonie and I were working out some problems with a builder command. Ah-ha!

As it turns out, a very useful but not-often-used command that was put into the code many years ago had a very severe memory leak in it. The command uses the regular expression engine to parse boatloads of mobprogs iteratively, but the code wasn't cleaning up the tail end of the regex calls because the regex libraries silently malloc huge blocks of memory that aren't automatically freed when the parent routine exits.

This was a pretty easy mistake to make; while most high-level programming languages in which one would utilize regexes (like Perl, PHP, and whatever else) abstract away all of the memory management, C certainly does not. I guess the pitfall here is that the regcomp() call buried mallocs within it, so a headfirst dive into using regexes in C wouldn't directly expose the programmer to the mallocs which would raise alarms. An easy pitfall, sure, but like a wise man once said, "if you are going to write C code, you better be willing to deal with the memory management."

For what it's worth, I've gotten the game's code to be remarkably scarce on memory leaks like this despite the fact that I (nor any past coder of whom I know) has ever profiled the code with something like Valgrind or even gprof. While this case may give a pretty good argument for trying to figure out a realistic way to do this, blind dependence on tools like Valgrind to make up for incompetent coding has been known to cause serious problems. If we start running into memory leaks again though, maybe I'll try to figure out a way to set up profiling on a test port somewhere and have some of you players beat on it for a night.

Monday, March 14, 2011

Game Mechanics Q&A

A while ago we answered a number of questions about the rumors that surround game mechanics. They've recently expired off of the ideas board, so someone asked us to make them permanent somehow. Here they are.

Q: Does dex factor into the CLEAR command working?
A: No. It's just a flat % chance.

Q: Is it possible for second attack (or third attack, fourth attack, etc.) to go up without using practices?
A: It is possible if you have first used rage, though we don't quite remember if rage will work this way for all the attacks. We'll figure it out when we get to those helpfiles.

Q: Do stats have any effect on how successful you are at learning trades?
A: No.

Q: Does intelligence help you land spells?
A: With the sole exception of the forget spell, no. For now.

Q: Is blind mental, and does that mean orcs and ogres are vulnerable to the spell?
A: Blind is not mental. It is magic. Races that resist magic resist blind, but it should be noted that the resist bonus for this type of spell is small.

Q: Does wisdom help you resist spells?
A: Wisdom has nothing to do with resisting spells. The vast majority of spells only check the victim's saves and racial adjustments (resist/vuln).

Q: Does having high saves help you land spells?
A: No. The caster's saves have nothing to do landing spells.

Q: Does constitution help you push?
A: No, but strength does.

Q: Should we bother with armor class (AC)?
A: At level 50, I would say not. Basically, in order for you to get the minimum AC necessary for it to be useful, you would need many thousands (like better than -5000) of AC. This is because the game is built around the idea of 8 hitroll being awesome. As soon as awesome hitroll got moved from around 8 to around 80, AC became an irrelevant stat, because nobody can possibly get the huge AC needed for it to matter.

AC is useful at low levels though, because you will be fighting mobs who have such low hitrolls that your AC will actually do something for you. Casting your armor/shield/stoneskin spells while levelling will help you a lot.

This is something we may consider opening the door to changing in the future.

Q: Does dexterity help you land melee blows?
A: Dex does not help you land melee blows. It does factor into your AC, but see the previous question for an explanation as to why this winds up having no effect.

Q: What is dexterity useful for?
A: Dexterity is most useful for landing (and defending against) dirt kick, and for defending against barbarian skills.

Q: What are the bonuses to two-handed weapons?
A: You get a bonus to parry while wielding polearms, spears, and staffs. Typically, two-handed weapons have higher stats than ordinary weapons since they get extra points for builders to allot.

Q: How does dispel magic work?
A: The first check is a flat saves check. If the victim makes his saves check, the caster sees "You failed." If the dispel is landed, each affect on the victim is checked. Essentially, the effectiveness of this second check depends on the level of the affects on the victim. If the level of all affects on the victim are too high to dispel, the caster will see "Spell failed." However, this also indicates that a high-level spell affect had its level lowered, making it easier to dispel in subsequent casts. Each spell affect is independently checked of the others, so it casting a weaker spell on a victim first won't help you dispel other affects.

Q: Is there a 'cap' at which point having more saves, hitroll, and damroll is pointless? If so, what is it?
A: There is no cap on hit/dam. More is always better. It's a little more complicated for saves. Check out this post; there's a bullet called "There is no cap for hit, dam, or saves" which provides a more detailed answer.

Q: How much difference does having the weapon skill you're defending against make?
A: None. There was a myth that if you were skilled in the type of weapon your opponent was using, that you would get a bonus to parry, but although that is an interesting concept, it isn't true.

Q: Does intelligence/wisdom affect mana regeneration?
A: Yes and yes.

Q: Does constitution affect hp regeneration?
A: Yes.

Q: What is the difference between enhanced damage and critical strike?
A: They're completely different skills. Critical strike is pretty rare, even at 100%, but when it does work, it adds a lot more damage to a hit. Enhanced damage at 100% adds a small amount of extra damage to every successful hit.

Q: What are the real effects of having the sharp and vorpal flags on weapons?
A: Sharp is awesome. It gives a significant chance of doing more than double damage. Vorpal literally does nothing. This is subject to change in the future.

Q: What is the chance of shattering someone's shield?
A: Although we are going to be answering a lot of questions about how things work, we don't want to get into specifics about exact chances or formulas, etc. There is -a- chance that it will work, providing the shield isn't unbreakable.

Q: Does the fear spell remove one extra attack?
A: No. It cripples second attack and outright removes third, fourth, and fifth attack. It doesn't affect extra attacks granted by spells such as haste.

Q: What about web, how does it work?
A: Web prevents the victim from moving or fleeing until the web is broken. Strength and dexterity impact a victim's ability to break free.

Q: Do templar maledictions cast at a higher level and land at a lower level?
A: No. However, judgment does have a higher chance of landing than regular maledictions (such as curse, blind, etc.). This was done to balance the penalty templars suffer in not being able to cast specific maledictions.

Q: How does chaotic dispersal compare to dispel magic?
A: There are chances that CD will cast at a much higher level, making it much more effective than a regular dispel. There is also a chance that it will dispel the caster.

Q: Wild summon is supposed to have the chance of doing something great if it works. What's the extra affect?
A: There are two affects. One very significant one is that the victim does not know he is being summoned. The other is that there is a small chance that the summoned person will be blinded during the summon.

Q: What's the purpose of giving constitution to adrenaline rush?
A: Adrenaline rush, like haste, slows down hp regeneration. Since higher con helps hp regen faster, I would say the Con boost is there to balance out the haste penalty to hp regeneration.

Q: Does energy drain have the same chance of landing as blind?
A: Yes.

Q: What is the minimum recommended saves for blended classes?
A: Saves requirements for blended classes are determined by how much mana a class gets per level. If you're getting about 10 mana when you level, you're considered a magic class as far as saves go. If you're getting about 5, then you have the saves requirements of a fighter class. Simple as that.

Q: Do some races/classes cast at higher or lower levels?
A: With the exception of a very few spells, no. Everyone casts spells at his level. One related thing of note: spell affects diminish over time. For example, when I cast curse on myself, I get -7 to hit and +7 to saves, and the affect is at level 60. As the spell ticks down though, its level decreases in addition to its duration, making it easier to dispel.

Sunday, March 13, 2011

More Player Stats

The Dark Risings census and other miscellaneous stats on our official webpage are a bit out of date, and since team admin is in the process of renovating that site, I figured I should generate some new stats. Since the new site isn't ready to go yet, I'll upload them here for the time being.

Guild Statistics

  • Of all of the mortals, only 5.03% are guilded. However, of all level 50 characters, 9.64% are guilded. This number should ideally be higher, as we like people to be involved in guilds.
  • Of all guilded mortals the three most populous guilds are Dawning (23%), Gypsy (20%), and Covenance (17%).
  • The most exclusive guilds are Inferno (10%), Arcaenum (13%), and Vermillion (15%).
  • Interestingly, these least populous guilds are designed to be the most exclusive as well. That is, they aren't necessarily the least popular

General Census

  • Of all characters, 75.7% are male, 22.5% are female, and 1.9% are neither
  • Of level 50's, 77.8% are male, 20.9% are female, and 1.2% are neither
  • Of all characters who aren't level 50 yet, 73.4% are male, 24.1% are female, and 2.5% are neither
  • Does this mean girls are bigger quitters than guys?

Werecreature Stats

  • Of all mortal characters, 13.8% are werecreatures
  • Of all level 50 characters, 20.9% are werecreatures (an impressive fraction!)
  • Of all werecreature characters who haven't hit level 50 yet, over half (55%) haven't even gotten to level 30--that is, they don't even know that they're werecreatures yet
  • Of all mortal characters, 5.8% are werecreatures who haven't hit level 30 yet

Highest play times at level 50

 1.      Sintar 6239
2. Adi 4087
3. Tiea 3972
4. Ravindra 3489
5. Mellyrnna 3133
6. Zyggi 2609
7. Yuneo 2459
8. Sutherland 2376
9. Argban 2164
10. Donovan 2024
11. Divinicus 1863
12. Sagoth 1734
13. Brunne 1707
14. Senara 1634
15. Shadowmoon 1615
16. Xanaphia 1613
17. Vaanderun 1606
18. Maaz 1597
19. Rehanea 1571
20. Parisa 1559
Dilaver 1553
Tamlin 1541
Zerikial 1517
Amenia 1495
Kamille 1453
Cailet 1425
Madelaine 1417
Flocrian 1370
Lena 1368
Akemi 1361

Most experience at level 50

 1.  Shadowmoon 3872186
2. Xilokerym 3600337
3. Reilyn 3520363
4. Macainay 3480307
5. Azael 3480293
6. Lasrael 3432018
7. Avidician 3404568
8. Prechu 3220008
9. Madarchod 3192000
10. Radys 3108133
11. Xukuth 3108062
12. Econicue 3000404
13. Derevoc 2904153
14. Hager 2772372
15. Finn 2688013
16. Xianthian 2604451
17. Virstrel 2464235
18. Rakkashavas 2400338
19. Errol 2376025
20. Kenthur 2340123
Lastur 2300064
Anglameil 2208000
Varongril 2200100
Zachariah 2184014
Farris 2112000
Greleil 2080124
Orazbahgn 2024272
Drackion 2024145
Beranon 2024031
Salvatori 2016263

Friday, February 11, 2011

Interesting statistics

In reviewing the suggestions and ideas that have come up in the last few months, I've done a little data mining to look at race/class trends. Some interesting things came up, and I figured that since I've got the data, I may as well share it.

Remember that this admin blog is "unofficial," so take these numbers with a grain of salt. And, under no circumstances are you allowed to attempt to use this data as ammunition for your case as to why some particular race or class is under- or over-powered. There's a lot contributing to these numbers, so much so that I'd wager that most of this data is too convoluted to yield meaningful trends. But it's fun to look.

(note: these tables may not display properly in Microsoft Internet Explorer. You may want to either view this page in Firefox, or copy+paste each table into notepad)

NUMBER OF EXISTING LEVEL 50 CHARS CREATED IN THE LAST FIVE YEARS

These are level 50 pfiles that still exist as of today, but were created not more than five years ago.

mag cle mon war bar psi dru ran rog brd wmg wlk nec tem Total
kine 11 15 5 10 5 4 17 8 6 4 4 4 8 2 103
kender 0 0 0 1 0 0 1 2 10 2 7 1 0 0 24
werekin 5 1 9 3 4 2 6 9 3 5 5 5 2 2 61
lich 6 2 4 0 0 3 5 1 1 2 2 6 13 6 51
avariel 11 9 2 2 0 2 8 1 3 3 10 9 5 2 67
orc 1 2 0 4 4 1 1 2 4 0 0 3 1 1 24
githyanki 5 2 0 0 0 6 0 2 2 0 2 6 3 0 28
merfolk 7 4 3 3 3 6 2 9 1 6 5 5 2 4 60
half-elf 8 12 7 1 3 1 12 3 15 12 0 2 5 0 81
draconian 16 5 2 9 12 1 11 17 6 2 1 13 6 4 105
drow 6 3 4 0 0 2 1 1 13 5 2 4 7 0 48
dwarf 8 6 2 3 5 1 2 4 1 1 0 5 2 6 46
ogre 2 0 2 0 12 0 0 3 1 1 0 1 2 0 24
sylvan 15 5 2 3 3 2 9 3 5 4 7 7 1 0 66
total 101 66 42 39 51 31 75 65 71 47 45 71 57 27 788

NUMBER OF EXISTING LEVEL 50 CHARS CREATED IN THE LAST TWO YEARS

Same as above, but for pfiles created not more than two years ago.

mag cle mon war bar psi dru ran rog brd wmg wlk nec tem Total
kine 0 0 1 3 0 1 1 1 0 2 2 2 5 2 20
kender 0 0 0 1 0 0 0 0 3 1 2 0 0 0 7
werekin 0 0 0 1 3 0 1 1 2 0 1 0 0 2 11
lich 2 1 0 0 0 0 0 1 0 0 0 1 5 6 16
avariel 3 3 1 1 0 0 5 0 0 1 1 4 1 2 22
orc 0 0 0 2 2 0 0 1 1 0 0 0 0 1 7
githyanki 5 0 0 0 0 1 0 1 1 0 0 3 0 0 11
merfolk 1 2 2 1 2 3 0 1 0 2 1 3 0 4 22
half-elf 1 1 3 0 2 0 1 1 5 1 0 0 2 0 17
drow 1 2 2 0 0 1 1 0 1 2 0 0 1 0 11
draconian 6 1 0 4 1 0 3 5 4 0 0 3 1 4 32
dwarf 2 0 0 0 1 0 1 0 0 0 0 0 2 6 12
ogre 1 0 0 0 3 0 0 1 0 0 0 0 0 0 5
sylvan 1 1 1 0 0 1 1 2 1 1 1 2 0 0 12
total 23 11 10 13 14 7 14 15 18 10 8 18 17 27 205

NUMBER OF EXISTING LEVEL 50 CHARS CREATED IN THE LAST YEAR

See above clarifications.

mag cle mon war bar psi dru ran rog brd wmg wlk nec tem Total
kine 0 0 1 1 0 0 0 0 0 1 0 0 0 0 3
werekin 0 0 0 0 0 0 0 1 0 0 1 0 0 0 2
lich 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1
avariel 0 2 0 0 0 0 2 0 0 1 0 3 0 0 8
orc 0 0 0 2 1 0 0 0 1 0 0 0 0 0 4
merfolk 0 0 2 0 0 3 0 0 0 0 1 2 0 3 11
githyanki 1 0 0 0 0 0 0 0 0 0 0 1 0 0 2
half-elf 1 1 2 0 2 0 1 1 1 0 0 0 1 0 10
draconian 4 0 0 1 1 0 1 3 0 0 0 1 0 1 12
drow 1 0 0 0 0 1 0 0 1 1 0 0 0 0 4
dwarf 0 0 0 0 1 0 0 0 0 0 0 0 2 1 4
ogre 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1
sylvan 1 1 0 0 0 0 0 0 1 0 0 2 0 0 5
total 9 4 5 4 5 4 4 5 4 3 2 9 3 6 67

NUMBER OF EXISTING LEVEL 50 CHARS CREATED IN THE LAST SIX MONTHS

See above clarifications.

mag cle mon war bar psi dru ran rog brd wmg wlk nec tem Total
kine 0 0 1 1 0 0 0 0 0 1 0 0 0 0 3
werekin 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1
avariel 0 1 0 0 0 0 1 0 0 1 0 3 0 0 6
orc 0 0 0 1 0 0 0 0 1 0 0 0 0 0 2
merfolk 0 0 1 0 0 1 0 0 0 0 1 2 0 2 7
githyanki 1 0 0 0 0 0 0 0 0 0 0 1 0 0 2
half-elf 1 1 1 0 1 0 1 1 1 0 0 0 1 0 8
draconian 3 0 0 1 1 0 1 3 0 0 0 0 0 1 10
drow 1 0 0 0 0 1 0 0 1 1 0 0 0 0 4
dwarf 0 0 0 0 1 0 0 0 0 0 0 0 2 0 3
sylvan 0 0 0 0 0 0 0 0 1 0 0 2 0 0 3
total 6 2 3 3 3 2 3 4 4 3 2 8 3 3 49

PK Wins/Losses Since December 2007

These are knockouts resulting from a level 50 knocking out another level 50, tabulated per-class. This does not include suicide knockouts (or similar events such as necro spell knockouts), but it DOES include friendly KOs such as those to remove scars, those that occur in potion roulette, etc. Thus, the below data is extremely convoluted so don't make too much of it. Also remember that one particular good PKer playing one specific character and sparring for a few months can really skew this data.

class wins losses
templar 154 197
warlock 170 138
ranger 350 252
druid 257 267
monk 38 109
cleric 86 124
bard 194 179
rogue 158 222
wildmage 43 71
psionicist 9 35
barbarian 145 131
warrior 294 170
necromancer 29 69
mage 290 253

PK Wins/Losses Since October 2003

Taking the same numbers as above but over a longer time period should smear out the skew due to one or two really good PKers, but it also lumps together changes we've made to classes over the years.

class wins losses
templar 157 211
warlock 967 794
ranger 522 411
druid 1126 910
monk 196 420
cleric 507 545
bard 598 546
rogue 624 574
wildmage 162 214
psionicist 82 187
barbarian 513 527
warrior 549 461
necromancer 215 624
mage 1007 801

Monday, June 8, 2009

Operation Sacred Spork

Phase six of Operation Sacred Spork has finally been concluded, and we're pleased to announce the templar class is finally live! We've been thoroughly testing it for the last couple of weeks and as Parviane said in his last change, we're skipping any "testing" stages as we're fully confident the class is nicely balanced, and will perform great. In terms of player kill, I've had a lot of fun testing this class out and am really interested to see what kind of combos start to turn up; I found that while heavy HP is tempting with them (as they are a fighter variety) the speed of their spells and costs really make heavy mana a necessity. They respond really well to turn around situations which is in the same vein of strategy as a cleric, but with a wildmage touch of chance. Inquisition you can fire off enough to really make the best of a bad situation, but the hp it eats just makes it that much scarier; I'm curious how people will use these... lots of noexits? Less? I'll be watching you guys spar and PK so make sure you aren't slacking >:D

It isn't in the help class tables JUST yet, so just to make it accessible to ever one the stat bonuses are +2 to con, and +1 to wis.

TEMPLARS AREN'T PALADINS! I've already heard this tossed around a lot and I can see how it's easy to think that with the similarities in RP, but this is a class unique to DR that has been constructed to operate very differently (not to mention that we have three different types of Templars, that aren't necessarily "good" "evil" or "neutral"). Warrior-Wildmage-Cleric is what we've described them as in a pinch, like I said... unique class, unique way to operate >:). Really I guess... you just have to try them out to see!

EDIT-

By the way everyone, great work on the voting! We've secured and maintained our number ten position and finally made our way back to the top ten muds. I can't say how impressed I am with the dedication of our pbase, and I really hope you all keep up the great work, this is sure to bring in some new faces. I've had some staff mention to me recently that they're really interested in what the players have been thinking about the changes to the game, so I'd love to see some new reviews on TMC if anyone has time or desire too.

Tuesday, June 2, 2009

New Arcing Quest Series

I wanted to say thanks to everyone who participated in the quest last night, and to say that if you're not involved yet, find a way to get in on the action. It's not over yet, and things are going to get very interesting >:)

It's been a while since I did a series of arcing quest -- the last one was the Golden Knights quests for which the winner got a complete set of matching questeq. They're a lot of work to put together, but the combination of having an awesome admin team to scheme/work with and terrific mortals to RP with makes it a lot of fun, too.

The grand prize for this isn't going to be a set of jacked-up eq, but there will be prizes for each individual quest within the arc (last night's prize was a jacked-up held container full of goodies including a multifaceted gem), and the prize for the finale is going to be BIG.

When will that be? Stay tuned, get involved, and find out :D

<3
S

Friday, May 29, 2009

Sacred Spork

Stage 5 of Project Sacred Spork has concluded, and thus the project is ready to be unveiled. This is all very exciting to us admins, as we've put a considerable amount of time and effort into clarifying what our vision for this was, discussing how it should all fit into the framework of the exiting game, actually implementing it all, and then testing and re-testing everything. As of our last bout of testing this afternoon, everything is in working order, and this evening I finally attached the last pieces of the code to the rest of the game with which players interface.

We're aiming to unveil the project sometime in the coming ten days or so, with the latest target date being Sunday, June 7. Hopefully everyone finds that it's worth all of this hype.

Thursday, May 28, 2009

Did you know?

Now that the introductory stuff is out of the way, I can post some meat.

Soon after becoming an IMP, I posted a change to everyone that in fact was not a change at all. It was entitled "Did you know?" (a name inspired by a series of emails that used to be sent out by a dean of mine) and it contained little features that existed in the game that were underutilized or undocumented. The original change posting is still in the game (change search know), and I think another round of fun insider info is past due. Here goes.

Here are some fun facts:
  • The chance to get were is not 5%. Although it has long been stated as such, the truth is that it's been 7% for a long time--longer than I've been an admin. Granted, a 2% difference isn't that big, but all you statisticians who want to recreate for were twice in a row might find this useful to know.
  • We have an online who list. It's still in its beta testing stage and will probably always be that way, but it's a good way to see who's on so that you can decide which character to log. A link is also provided on this blog's sidebar there.
  • There is no cap for hit, dam, or saves. Hitroll and saves work against other factors, so there is no hard cap on them. For example, having higher hitroll decreases your opponent's ability to parry. At some point of having absurdly high hitroll, your opponent's chance to parry cannot get any lower--sure, that's a cap, but it's different depending on who you're fighting. The same applies to saves. Damroll, on the other hand, never stops being useful. Its effect becomes less apparent the higher it gets because the ranges between the different damage indicators (eg, <<< ERADICATES >>> and <*>_MORTALLY WOUNDS_<*>) widens. That extra +5 dam helps no matter what, but it may not be enough to show up as a change from eradication to mortally wounding.
  • Clerics do not get any sort of casting bonus over any other spellcasting class. They may have at some point, but they have not since I started coding.
  • Barbarians heal much faster than any other class. This is a relatively recent change, but keep this in mind the next time you consider poisoning your barbarian before going into pk. Sure, you might get maladicted up and put in an exitless room, but you'll also be at full health when you wake up, even if your opponent is quick about it.
  • You can get experience while leveling for completing in-game miniquests. Miniquests are being added to the game every day, and completing each one typically rewards you with 1000-5000 experience. The next time you create a new character, check out the sewers area. It has been redone to have quite a number of very cool and very lucrative miniquests.
  • Contrary to how it used to be, the %l tag in prompts will now accurately indicate whether or not you're in latelog. If your prompt does not say you are in latelog, you are not in latelog, period.
  • You can send notes to... admin, brawler, immortal, imm, any guild, any player, any race, any class, and any brood. You can also send notes to Snitch to submit gossip and it'll get read by someone.
  • There is an open bounty on crashing the game. If you can crash the game, you will get a restring token. In the year of 2009, the game has only crashed twice--in both cases, the offending crash bug was identified and fixed in less than ten minutes after the game booted back up.
Here are some goofy and dorky things that most people won't care about.
  • The mud's source is written in C and compiles readily on GNU/Linux systems and Sun Solaris using both GNU and Sun compilers. This cross-compatibility is necessary due to one of the game's testing platforms being a SPARC-based Sun system. The game which everyone actually connects to runs on a regular PC server and is compiled with GNU.
  • There is a limit to how much gold you can have deposited. Because the game stores bank accounts in signed long integers (32 bits), it cannot count past 2,147,483,647 gold. If you deposit anything in excess of this, you wind up having negative gold.
  • As of this writing, the game currently takes up 35.5MB of physical memory. This is not to be confused with how much disk space it takes up; that figure is somewhere in the vincinity of 250MB.
  • Since I have become the coder, Dark Risings' official policy is to not use code snippets, ever. All new code is written specifically for Dark Risings from scratch, as the time it would take to properly audit, port, and test others' code (which is often amateur and unreliable) would take far longer than just writing it correctly from scratch.
As people come up with more goofy rumors and outrageous claims over the OOC channel, I will post more of these little clarifications and fun facts. Of course, this isn't to say that us admins are going to disclose how everything works; some aspects of the game (such as what role intelligence plays in spellcasting) will remain deliberately ambiguous.