Dark Risings Admin Blog

The Elephant in the Room

2011-11-18T11:18:00.001-05:00

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:

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.

The Truth Behind Wimpy and Trip

2011-11-08T02:05:00.000-05:00

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:

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

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:

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

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:

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

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:

if ( !IS_NPC(victim)
&& victim->hit > 0
&& victim->hit <= victim->wimpy
&& victim->wait < PULSE_VIOLENCE / 2 )
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:

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.

Coding Quandary for Brawler Scores

2011-11-07T13:10:00.000-05:00

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:

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.

Brawler Scoreboard Stage 2

2011-11-04T13:11:00.000-04:00

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:

no grinding for gold if you just want to pk for fun
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)
cements in PK as a distinct minigame within Dark Risings

CONS:

less of a need for pure-PK players to actually play the game since they don't need to worry about collecting gold
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.

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.

Taking a step back

2011-11-03T14:07:00.000-04:00

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:

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.

Brawler Scoreboard Update

2011-10-23T03:05:00.000-04:00

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.

Chrysalis Games: For the Love of the Game (And Its Players)

2011-09-26T11:47:00.000-04:00

Sidonie's posted to her blog, and it's more than worth linking here:

Chrysalis Games: For the Love of the Game (And Its Players)

Chrysalis Games: Away in White, Back in Black

2011-08-11T15:29:00.000-04:00

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.

Sorry Mark

2011-04-28T00:40:00.003-04:00

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

[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.

Memories

2011-04-13T14:05:00.004-04:00

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.

PK Poll

2011-03-29T10:38:00.004-04:00

A lot of people have been vocal about the perceived imbalance in our current PK code, so in the interests of getting a lot of one-click feedback, I've opened a poll (should appear to the right) regarding the matter. Please leave comments below.

April 5, 2011: The results are in!

62% felt that spellcasters need a boost
34% don't PK
31% felt it seems pretty balanced
21% think fighters need to be toned down
18% feel fear is too powerful
12% think guild spells make fighters too strong

This was out of a total of 32 votes.

Although we have no immediate plans to change the fighter/spellcaster dynamic (we have a lot of other changes in the works that need to be finalized before then), we will revisit these results and the comments posted and see if we can adjust accordingly.

Crying and complaining about coding

2011-03-28T23:19:00.003-04:00

One of the hardest parts of coding for Dark Risings is the fact that it's derived from code that is over two decades old (Diku was first released in 1990) and, even after transforming into the ROM 2.4b6 codebase (released in 1998), it's been hacked on by twelve years of Dark Risings coders. As much as I hate to say it, the greatest amount of damage to the code has, in fact, been done by the long history of DR coders of varying levels of familiarity with both C and how ROM works.

What's prompted this whiny rant is a problem I discovered while generating a list of all of the scrolls in the game for Sidonie. I'd already done this with wands and staves with the help of a little Perl magic that I wrote, so I expected it to be another straightforward five-minute job. In a sense it was, but upon examining my data dump, I noticed that some scrolls had four spells (some of which are listed as "reserved") and others have blanks where spells should've been. Thinking that my Perl script was defective, I checked the area files themselves, and sure enough, some scrolls have "reserved" and others are just "". What's the difference? Since this sort of ill-defined behavior can lead to major issues (area/pfile corruption, crashes, etc), I started digging and was brought to one particular routine that made me a little crazy.

Consider the following code, straight out of the Dark Risings source:

/*
 * Lookup a skill by name.
 */
int skill_lookup( const char *name )
{
  int sn;

    for ( sn = 0; sn < MAX_SKILL; sn++ )
    {

      if( skill_table[ sn ].name == NULL )
        break;

      if( strcasecmp( name, skill_table[ sn ].name ) == 0 )
        return sn;

      /*
        if ( skill_table[sn].name == NULL )
            break;
        if ( LOWER(name[0]) == LOWER(skill_table[sn].name[0])
        &&   !str_prefix( name, skill_table[sn].name ) )
            return sn;
      */
    }
...

For whatever reason, a past coder decided it best to comment out the stock bits of this subroutine, presumably to force the subroutine to match the whole skill/spell name instead of allowing abbreviation (which can cause issues when you have spells like "lightning bolt" versus "lightning breath").

This sort of thing drives me crazy for many reasons, but here's one.

The stock version of the code was smart; it first checked the first character of the argument against the first character of the entry under examination in the master skill table. Since there's a very large chance that those first characters won't match when ripping through all 298 skills, you wind up not having to incur the overhead associated with a full-on subroutine call for the majority of the misses. This makes the whole process of finding a skill and returning its associated skill number much faster.

Perhaps I am more mindful of the benefit of these tiny performance benefits since I write very computationally intensive scientific code, where one poorly written line of code can add days or weeks onto compute time, for a living. And perhaps there really is no appreciable speed benefit to not preserving this preliminary first-character check when matching strings on modern hardware. However, I see little reason to pull it out outright since it is a smart way of handling these sorts of lookups.

Furthermore, the str_prefix routine (provided with ROM) was replaced with strcasecmp, which is intrinsic to string.h. However, whoever did this code change must have been extremely unfamiliar with ROM's internals (or perhaps extremely tired), because ROM provides str_cmp, its own equivalent to strcasecmp which is used extensively (and I mean extensively) throughout the code.

If strcasecmp and str_cmp serve the same purpose, why do both exist? As it turns out, strcasecmp is indeed included in string.h, but it is not ANSI C (although it is POSIX 2001). POSIX didn't exist back when Diku was first released (and neither did GCC or glibc for that matter), so it's likely that the str_cmp routine was written into the code decades ago. Providing this routine made the code more portable by not having to rely on special extensions that only existed in specific proprietary compilers. It was also tailored specifically to the needs of the code.

For the sake of consistency and portability, str_cmp (which is probably a little faster than strcasecmp) has been used exclusively in ROM's source. Unfortunately, DR's code has become rife with a sloppy mix of strcasecmp and str_cmp, forfeiting the benefits of portability while gaining literally nothing. As DR coders have touched the code, they've left these marks across it without really considering what the implications may have been.

True, since strcasecmp is now POSIX, it is unlikely that Dark Risings will ever be run on a system without it (e.g., DR compiles on HP-UX 11i, which predates POSIX 2001), but this is only an innocuous example. This sort of messy work, where one feature is implemented many times because various coders were ignorant of their predecessors' work, are all over the DR source, and it drives me a little nuts. I could go through and change all those strcasecmps to str_cmp, but to do so would require quite a bit of testing and would open the doors to new bugs. When it comes down to spending time cleaning up code which will not introduce any new features to the game or spending time adding new features while leaving the existing problems as they are, I find myself always choosing the latter.

Nobody cares if our code reads like garbage as long as that garbage is transparent to the players and imms, so I guess I'll have to take out my frustrations on this blog. It probably doesn't help that I spend my entire day at work cleaning up garbage FORTRAN.

Game Mechanics Q&A

2011-03-14T22:54:00.004-04:00

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.

More Player Stats

2011-03-13T17:09:00.006-04:00

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

Interesting statistics

2011-02-11T00:06:00.009-05:00

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

2010-12-18T14:24:00.003-05:00

It's that time of the year everyone! Merry Christmas!

Just a brief reminder, don't forget to log in on Christmas day to benefit from the spirit of giving and get some nice magical gifts! One per person (player not character), so choose which alt you want to get the gift with care. Gifts will only be given out on Christmas day so make sure to stop by. We hope you have a great holiday season. :)

The Staff

2010-11-29T14:24:00.002-05:00

First post in quite a while, but I'll be doing my best to post new updates about the game here from now on as well the changes board. We recently tweaked some of the in-game vuln weapons, I look forward to seeing how it affects the balance of PK on the MUD. Those of you who try it out and think it wasn't enough of a change or it was too much, just note to ADMIN with your feed back.

I'll be posting again later this week with some information about some upcoming events! Don't forget to log consistently through December to grab your Christmas gifts.

nate

p.s.

votevotevotevotevote. Try and break top twenty guys!

Mud Connector and new area.

2009-09-04T22:00:00.003-04:00

Recently, the mud connector started requiring a membership to vote: regular votes from anonymous IPs are no longer counted :(. Starting a membership doesn't take very long, and with this new requirement it means the top MUDs will be losing a lot of ground in the coming weeks. This is a great chance for us to climb in the ranks and attract new players! I'll be making my mud connect account, hopefully you guys will too :)

A new area has just recently been put into the game, a new guild area for the boys in red. This area will be worked upon further in future, and right now has no equipment mobs: really it's more an area to promote RP but will be more in future! It's been linked in an interesting way through the marsh area near the wastelands... if you have trouble finding it, I'm sure there's a guild that knows the way. If you see typos or glitchy bits in the area feel free to send me a note :)

The Chrysalis Project

2009-08-09T02:27:00.003-04:00

Hi everyone,

Although our new project is as yet unnamed, we're calling it the Chrysalis Project for the time being. I think the best part of having a project to work on is having a cool code name for it :)

I have just finished setting up a basic blog. There's nothing on it yet (and don't expect there to be for a little while... the next three weeks are pretty hectic both for Parvi and for me), but if you would like to follow the blog for the new project, then check out the following link:

http://chrysalisgames.blogspot.com/

With that, we turn this blog over to Nate and DR-related discussion.

<3
Sido

The New Project: An Explanation

2009-07-22T11:16:00.004-04:00

Hello everyone!

As of today, Parviane and I have officially stepped away from active management and development of Dark Risings. I want to thank everyone who came forward with kind words over the last week. It's been wonderful to hear that so many of you enjoy the changes we've made to the game, and I hope you continue to enjoy them for a long time to come. We feel great about leaving DR in the very creative and capable hands of our admin Nate and the rest of the imm team. I have full confidence in their abilities, and I am definitely looking forward to seeing the direction they decide to take with DR. Good luck and best wishes!

I know there has been a lot of speculation about why we have chosen to retain rights to DR rather than just leave as most IMPs who step away from the position have done. I appreciate those of you who have taken the time to ask me about it rather than, as others have done, simply bashing us on public forums, knowing we will not respond there. I'd like to try to explain our decision, for anyone who is interested in reading more about it.

Aside from the endless cosmetic changes (such as helpfiles and building, which Nate and the team can do) DR right now is as good as Parvi and I can make it. However, DR is a ten-year old mud, based on ten-year-old code and ten-year-old game design. More and more, it's becoming clear to me that although I don't want to run a text-based version of WoW (which is NOT a role playing game) the fundamental setup of Dark Risings not only enables but encourages this. As a result, we have things happening which, as a game designer, I find extremely frustrating.

For example, many DR players seem to feel that the best way to create a character is to powerlevel to 50 as fast as possible, then spend 3 weeks spamming skills to save an extra 20 or 30 hp, then spend another week spamming gold runs. By the time they are ready to actually play the game (and not just spend hours doing the same thing over and over) they are already a higher level than 90% of the game is intended for. So we get complaints about how boring levelling is, how boring spamming is, how hard it is to get gold, how boring it is to explore areas since they don't give anything good, and so on. This is how the game has always been, and it's proven impossible to convince the majority of players that it should be done differently. It seems like players prefer to play DR in boring ways (and prefer to complain about the game being boring) to trying a different way of playing it.

Personally, I don't like playing games which require (or encourage) excessive mindless repetition, and I don't like running them, either. I think players should explore as they level, finding all sorts of useful equipment and other items which can help them fight, and which they can sell off as they find more, gradually padding their bank accounts. I think they should use their trains, skills, and spells as they get them, because they make an extreme difference in both how easy mobs are to kill, and how fun it is to kill them. This is the kind of game I want to build, and have been building at Dark Risings since I first became a builder almost seven years ago.

However, most Dark Risings players are fundamentally opposed to this kind of game play. I think the "min-max" statsmongering mentality has become so entrenched in the game itself that trying to root it out now would cause not only widespread player unhappiness, since so many people are used to doing it, but would also require code changes so massive that a pwipe would be inevitable. I love Dark Risings: its history, its longevity, its mythology, and its players. It is an established mud with some excellent code and storylines which stretch back over a decade, with no breaks or gaps where the mud was inactive. I think that forcing a pwipe on a mud this old would be fundamentally wrong.

I still want to be working on a very different kind of game, though, and I sure don't have time to work on two muds at once. Therefore, what Parvi and I are doing are splitting the game into two sections: one, Dark Risings, is the game we HAVE built, and which I hope will continue to run for another ten years; the other, as yet unnamed, is the mud we WILL build, using all the things I love about Dark Risings as well all the great code Parviane has written specifically for DR. We are not simply building DR2; the MUD we intend to make will be fundamentally different from DR in many, many, many ways. But certainly, we will be using what we have built on DR; without it, we would have to start from scratch and, in all likelihood, never it get off the ground. It takes far less time to gut a mud and rewrite than it does to start from nothing.

I don't think it's selfish to keep what we have built so that we can continue to build on it. I think it would be a lot more selfish for us to erase ten years' worth of characters so that we could do that. To my knowledge, no other past implementors have gone on to build or even play other muds, and that is pretty significant. We may yet release DR code and our rights to it. That just won't be happening right now, because unlike past owners, we are still USING it. I feel that my last four years as an IMP combined with Parvi's last three as a coder give us the right to do that.

I would love to discuss this more with anyone who would like to comment on it, and I will continue to post updates here as they occur. Once we decide on a name for the new mud, I will create a new blog for it, as well.

Thanks again to everyone who made imming on DR a pleasure. I look forward to seeing you on DR, and having the chance to play with you as a mort!

<3
Sido

Lag Issues

2009-06-15T15:55:00.003-04:00

Although people have always been complaining about lag that originates in their connections, we've started experiencing server-side lag issues in the game in the last few months. While connection-related lag is something you all can feasibly fix (by changing ISPs, fiddling with their wireless connections, upgrading in-home wiring, et cetera), mitigating server-side lag is something beyond your control; it will happen no matter how good your connection is. Fortunately, server-side lag affects all players equally, and you won't find your character dead if a server-side lag spike happens while you're in a fight.

For the sake of appeasing any fears related to this increase in lag, here is some useful information:

If you come out of the lag spike and a bunch of text (eg battle spam) dumps out on your screen all at once, the lag is due to your connection. If you come out of the lag spike and only one more round of battle spam happens though, it was a server-side problem.
Server-side lag locks up the whole game, including battle, mobs, pk, and everything else. If you're in PK and there is some server-side lag, your opponent feels it just as bad as you do--the tables will not be turned on you. Connection-related lag, though, can be fatal.
Similarly, you aren't going to die if you're fighting the hydra and the server locks up momentarily. The fight itself locks up, so the hydra isn't hitting you while your screen is frozen; the hydra is frozen up too. While it can be unnerving to have your screen freeze up mid-fight, if the problem is on the server side, the fight will resume as normal when everything unfreezes. There will be no catching up on battle as there would've been if the lag was due to your connection.

Thus, if your connection is usually good and you notice your screen freezing up momentarily, for the most part you don't have to worry about anything bad happening to your character.

For those of you who are interested in the technical details, this server-side lag is due to the server on which we run being momentarily overloaded, an effect similar to when you run too many programs on your computer and you get the hourglass icon for a few seconds. Dark Risings runs on the same server as a number of other muds, and if one of them reboots, experiences some nasty bug which causes them to go rogue, or does anything which momentarily strains the server as a whole, we can feel the effects of that in the form of a lag spike.

Unfortunately, these server-side lag issues are something we will all have to just put up with for the time being. Dedicated hosting solutions cost between 3x and 4x as much as our current hosting, and our current costs are already about as much as we can afford without relying on some sort of revenue (donations, fees, et cetera). However, there is light at the end of the tunnel--our server is due to receive a hardware upgrade in the coming months. If this upgrade will include moving to a SMP (multicore) platform, the server-side lag spikes should go away almost completely.

Trouble Logging In?

2009-06-11T09:58:00.008-04:00

If you're having trouble logging into darkrisings.com 1313, redirect your client to titan.mudmagic.com 1313, or 70.85.106.90 1313. All three are the same thing, but the last two should work for everyone. Sorry for the inconvenience! Hopefully we can resolve these technical difficulties soon.
<3
S

PS All technical difficulties are cleared up now, thanks your patience :)

Operation Sacred Spork

2009-06-08T00:30:00.006-04:00

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.

Crash Last Night

2009-06-07T11:59:00.005-04:00

Last night the game crashed, bringing our total crash count for 2009 up to three. The problem which caused the crash was a bit tricky to find because the actual crash was caused by memory corruption which occurred fifteen minutes before. Tracking it down and fixing it was ultimately not very difficult, but what was particularly frustrating for me in this case was that the root of the crash involved the bane of my existence: an old CODE SNIPPET.

In this case, the problem lay in the rename snippet, v1.1 written by some fellows named Voltec and belial in 1998. This particular snippet has been in the Dark Risings source for as long as I've been here (so it was likely in from the beginning), and it is what allows us imms to rename characters named "Drizzt" without forcing them to delete and recreate. However, the guys who wrote it really didn't know what they were doing (which, from my experience, has been 100% of the people who author publicly available snippets) and thought this would be a good way to rename a character:

/* grab old name, insert new name, Save the new p-file */
strcpy(old_name, victim->name);
strcpy(victim->name, new_name);

Unfortunately for every mud which has used this snippet, the authors of it did not understand that the game does not allocate entire player characters in the game on the stack as it would a local variable; characters (and therefore the names associated with them) are malloc'ed to some block of permanent memory. Using strcpy on any permanently allocated member of a char_data structure is an incredibly novice mistake; strcpy knows nothing about the size of the space in memory allocated for a character's name, so it does absolutely nothing to ensure that it doesn't either overrun the space allocated for the character's name (and therefore corrupts whatever is in the memory adjacent to it, which is what caused yesterday's crash) or release any unused but allocated memory (which would cause a memory leak).

So at best, this snippet causes memory leaks, and at worst, it overruns the boundaries of the part of memory reserved for a character's name, silently corrupts other parts of adjacent memory, and causes a mysterious crash a few minutes down the road when the game tries to allocate memory for a new string and cannot find the correct boundaries for existing strings because they got corrupted. The correct way of doing this sort of renaming routine is actually already written all over the stock ROM code, so it's not like it is even a novel concept:

free_string(victim->name);
victim->name = str_dup( newname );

ROM and ROM-derivatives have their own internal memory handling and allocation subroutines which must be used when creating and destroying strings in this malloc'ed space; that's what free_string() and str_dup() do. My guess is that the authors of the original rename snippet learned about strcpy in their high school programming class, but did not learn about the importance of understanding how the whole program works before screwing around with pieces of it. Shoddy and broken code was the result.

This is exactly the reason Dark Risings no longer incorporates any publicly available snippets. I found myself spending my Sunday morning rewriting the rename command from scratch because the snippet we have been using for it was sloppy, buggy, and caused our game to crash right in the middle of our peak hours, undoubtedly ticking off some players and disrupting the experience for everyone logged in. It took me less time to just rewrite this command myself than it took to debug the code and trace the crash back to some crumby snippet that triggered a bug a quarter of an hour before the game actually caught up with the corrupted memory and tanked.

The funniest part of all of this is that the snippet says at the top:

* also, comes complete with comments! for the budding
* coder to know whats going on */

I feel genuinely sorry for any mudder who plays on a game whose "budding coder" learned how to code from junk snippets like this. At any rate, anyone who posts an idea or suggests to me "______ should be easy to implement because there is a snippet available" will be very rudely pointed to this blog entry. Dark Risings will never use anyone else's code under my tenure as coder.

Arcing Quest

2009-06-06T01:12:00.004-04:00

The quest tonight started off slow but ended up being very fast-paced and eventful! Thanks so much to all the players who made this fun for each other and for me... you know who you are, I hope!

I'll give out prizes as people start to hand in their roses.... the question is, as it always is for me, what do people want? Hmmm....

I am really looking forward to Sunday!!!!! Hopefully we get a great turnout for it... It's getting hard to wait :D

I'm so curious to hear what people thought of the new spell Parvi whipped up for this quest...and of how the quest has been in general so far.... If you want to comment about it, I'd love to hear it :)

<3
S

Reboot

2009-06-05T13:06:00.003-04:00

We rebooted this afternoon and a couple of large revisions to portions of the code went in. Most of these changes should be completely unnoticed by you all, as they were aimed at restructuring the internals of the game to make future changes a bit easier to make. One major revision, though, has resulted in the 'practice' list now being sorted alphabetically by spells, then skills. This should make it much easier to find certain spells or skills on your practice list as you spam, practice, or whatever else.

This process of restructuring the master skill and spell table had some unintended side effects which we quickly patched up before the revision went live. While we're pretty confident that everything should be fine now, if anyone notices anything clearly weird with skills or spells now (such as you clearly missing some spells you had before the reboot, or certain objects in the game no longer having spells on them which they should have), I'd like to hear about it. Most of these anomalies, should they occur, will show up on my screen before they show up on yours, and so far the game has shown no indication that anything went awry. Thus, I don't expect to hear any bug reports related to this most recent reboot for now, and hopefully the number of people crying wolf will remain low.

I am posting this to the blog rather than as a note because I don't think the changes that went in with this reboot are important enough to bring to everyone's attention.

New Arcing Quest Series

2009-06-02T12:42:00.004-04:00

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

TMC Rankings Reset

2009-06-01T10:24:00.005-04:00

This morning The Mud Connector reset its rankings, putting us back at an arbitrarily low ranking on the list. My guess is that they've started doing this every other month (or every quarter?) so that gigantic muds who have short-lived voting drives can't stay at the top forever without sustained voting. That can be good and that can be bad, but what's nice is that the playing field is even. As of this morning when I checked, we were already ranked at #7 with 15 total votes, but I'm sure we'll need to do better than that to maintain a solid lead.

Our officially stated ranking is updated only once a day, so today's rank of #1986 is really what we were ranked when we had zero votes (which is the same number of votes as every other mud) this morning. You can check the up-to-the-minute rankings here, and you can vote for us here.

Sacred Spork

2009-05-29T22:22:00.004-04:00

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.

Did you know?

2009-05-28T23:57:00.008-04:00

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.

Premise of the Dark Risings Admin Blog

2009-05-28T21:31:00.005-04:00

In the past, I've not thought there to be much of a reason to expand Dark Risings outside of itself; notes, ideas, histories, changes, and the OOC channel really seemed to cover all of the necessary bases. I didn't think there would be any reason for anyone to post thoughts or comments on anything mud-related anywhere else, and the short-lived, unofficial Dark Risings forums sort of exemplified that. After all, if someone had something to share with the rest of the players about the game, why wouldn't it get blurted out on the OOC channel (as what usually happens) or in a note?

Of course, I've become somewhat wizened over the years to the fact that there are gaps within our mud's channels-notes-helps communication fabric. There exist a wide range of thoughts and responses of mine which aren't important enough to warrant a note to everyone yet should reach more screens than just the people who have OOC turned on. Help files are meant to fill in that gap, but they tend not to be topical and tend not to be discovered until long after they are written. While I could just be more liberal on what I say over OOC or what notes I post to everyone, I'd rather give players the option to "opt in" to all of this less-important information. Thus, having some sort of blog where I can easily post information without forcing all players to wade through it all seems like a good idea.

While I cannot speak on behalf of the other admins, I do have an idea of what I would like to post here. One major motivation for me writing to this blog is that, as an admin, I have unique access to a tremendous amount of interesting game information that nobody else does. Although some of it should be kept secret in the spirit of fairness, a lot of it is information that isn't secret; it's just hard to get out there. Nobody seems to talk to me on instant messengers except my fellow admins, and most people seem to regard the helpfiles as completely unchanging, so I cannot rely on them as a medium for disseminating new information. This blogging business fills a nice gap, as it appeals to everyone's secret desire to spy on others over the internet and get insider info, yet people who want to contribute to the discussion are free to do so (using the comment feature which should appear at the bottom of this post). All of you readers can get topical, insider info at your leisure, and can participate to whatever extent (if any) you want.

There are also sometimes new and fun things which us admins get excited about but simply have nobody to share it with, and I hope to start venting some of that here as well. This Project Sacred Spork is a good example; I personally have been working on it full-time (in excess of at least eight hours a day) for a few days now, although it has been in the planning for months now. As it nears completion and we get to test it out to make sure it's all in working order, it's hard not to get excited about it--it's fun, it's fresh, and it's finally taking its final form before our eyes. It won't be long before you all get to use it, and I hope most of you will be as pumped about it as we have been once it hits the game.

Finally, I can also see this blog as being a potential place for us IMPs to let our voices be heard with regards to some of the gossip that we know floats around the instant messages. Although I'll not get into it now, one of the biggest frustrations associated with being an IMP is that we don't often have a way to share our side of things with people. For example, when we ban someone, that person is free to (and usually does) tell everyone who will listen how we banned them for shoddy reasons over instant messengers. I'd say 99% of the people who hear how the IMPs banned _____ for no reason just leave it at that, and never hear the other side of it. Although I don't envision this blog as being a "hall of shame" sort of setup, I certainly can see it as being an appropriate place for us to vent. And, since everyone is free to comment here on what we say, it's a bit fairer than just having us IMPs talk smack about people we banned on a place where they can't defend themselves.

So, for those of you too lazy to read the giant block of prose which preceded this, here is a summary:

This blog will be a place for the Dark Risings admins to share our thoughts on current things happening on the game
Everyone will be able to stalk us on the internet anonymously and get insider info without us IMPs explicitly knowing it
This'll be a place for us to respond to good ideas or common misconceptions that keep cropping up but don't quite warrant a note to all or a help file
We might vent here from time to time--but everyone will be allowed to post comments

I should also say that, for the time being, this blog is "unofficial." Despite being the DR Admin Blog, what I post here under my name are my thoughts alone. Unlike the notes I post to everyone on the game, what I post here has not been previewed and approved by the other admins, and my views here may differ from my "official" stance on the game. Don't expect to be able to hold anything I write here against me in the game.