Member Discussions

http://chrysalisgames.blogspot.com/

On your blog you suggest that the main problem with mudding is that people use the same old code over and over, passing it from one incompetent owner to the next, with each adding their own bugs. You mention that the code for your own mud is like that, that "it's like lace into which clumsy fingers have blundered many times".

Although personally I think you're overgeneralising, I can understand why you'd feel that way, particularly if that was your first mud. It's not uncommon for mud developers to discard their first attempt and start from a clean slate.

But then on your mud's blog you state that you're planning to reuse your old mud. Doesn't that mean you're doing exactly what you yourself have described as "the main problem" with muds?

But then on your mud's blog you state that you're planning to reuse your old mud. Doesn't that mean you're doing exactly what you yourself have described as "the main problem" with muds?

No. The difference is that my coder isn't an amature coder who is coding a mud for practice as he learns to code. He's a code artist. He removes the ugly clumsy patches and creates new, elegant work.

We considered starting from scratch, but he has already put in considerable time and effort fixing DR code, and i have put in considerable time and effort fixing the DR landscape and game design. We both like the general idea of ROM muds. Therefore, we will now try to make the best ROM we can.

Very exciting :)

Having read the blog, I would certainly agree. It's been quite a few times that I've thought about game theory, and realized that, essentially, the point of stagnation, is rules and similarity.
I'm no coder, so I have no way of bringing my wishes to fruition nevertheless, I've envisioned a mud that allows for the discovery of skills and spells, a game in which a person can boast of being the possesser of knowledge from the dawn of time that can shatter the land and annihilate enemies, or can boast of being able to heal a ruptured heart with a finger's touch. Not everyone could do this; perhaps only one player would be crafty enough to find these spells of power, and it would drive other players to discover increasingly powerful spells to outmatch the first.
I can tell I'm about to go on a very long tangent, so I'll halt.

No. The difference is that my coder isn't an amature coder who is coding a mud for practice as he learns to code. He's a code artist. He removes the ugly clumsy patches and creates new, elegant work.

That's something most MUD owners would claim about their respective coders, doesn't necessarily make it true in all cases. Not even DBZ MUDs advertise themselves as "We have not just one coder, but three, and they all suck and make spaghetti code so often that we crash every ten minutes!", yet for the majority of them it is probably true.

I can't help bragging about my coder :)

I feel very lucky to have him, because I can't code at all (except for mprogs, which clearly is not in the same ballpark) and he has been able to code literally everything I have asked him for, whether it be awesome mprog tools like mob pause or a million different kinds of ifchecks, or fixing the MANY problems in the code as we got it, or creating cool new spells, skills, or quality of life game features.

He's done such a great job making DR stable that as implementors we have been able to step away from the game completely -- neither of us are involved in running DR now, which gives us time to work on our new project without having to shut down or radically change the mud that so many people have loved for eleven years now.

I do also want to tip my hat to those amature coders who are self-taught and self-teaching. It's a lot more than I could do, and as a gamer and game designer I owe them a lot :)

Drizzt1216
wrote:

No. The
difference is that my coder isn't an amature coder who is
coding a mud for practice as he learns to code. He's a code
artist. He removes the ugly clumsy patches and creates new,
elegant work.

That's something most MUD
owners would claim about their respective coders, doesn't
necessarily make it true in all cases. Not even DBZ MUDs
advertise themselves as "We have not just one coder, but
three, and they all suck and make spaghetti code so often
that we crash every ten minutes!", yet for the majority of
them it is probably true.

I probably shouldn't of laughed, but I did. =(

I can't help bragging about my coder :)

For what it's worth, I don't know your coder, and wasn't insinuating that he is incompetent, was just more generalizing as to why I take people's claims that their coders are amazing with a grain of salt.

Oh c'mon Drizzt, you have to admit it's kind of quaint. They've identified "a lot of problems with how traditional mudding has worked", so now they've got a "code artist" who's going to "create a perfect prototype for a mud" and show all the "amature coders" how it's done. Doesn't it remind you of the 90s? It makes me kind of nostalgic :(

You're just upset he's going to reveal you for the "amature" coder that you are Kavir ;)

Having read the blog, I would certainly agree. It's been quite a few times that I've thought about game theory, and realized that, essentially, the point of stagnation, is rules and similarity.

I think I understand what you meant to say. However it's important to use
terms in the same way that other people use them. "game theory" and "game
design" are not the same thing.

He's done such a great job making DR stable that as implementors we have been able to step away from the game completely -- neither of us are involved in running DR now, which gives us time to work on our new project without having to shut down or radically change the mud that so many people have loved for eleven years now.

I'm glad that your mud project is bringing you joy, and it clearly feels to
you like it's doing things right in such a fundamental way that it is in a
new class of project altogether. That's great and I wish you luck. I'd point
out, though, that *feeling* this to be true does not make it so, and what
you have is a fairly normal situation. Indeed, feeling it's uber can
blind you to errors that are plainly visible from the outside, such as your
mud's awesome development having a serious single-point-of-failure.

I've mentioned Infiniti before...it's a car company whose ads started
out being pictures of waterfalls ans wutnot, real zen stuff, indicating
what a game-changing new company this was. Well it turned out there's only
so transcendental you can make a commercially viable car, and Infiniti
puts out a product with features as mundane as gas mileage and resale value.

I wish you the best of luck, but I think it's fair to point out that
there's only so much revolution in mudding you're going to make with
a ROM derivative...and having one competent coder is better than none,
but not exactly something to crow about.

anyway, ultimately, to make a long story short: we now want to create a perfect prototype for a mud.

I figure you don't mean this to be rude or aggressive, but you're
pretty much setting about opening the curtains and letting in the
light of truth and beauty on us ignorant mudders. You're not the
first to try this, and the curtain-opener typically doesn't quite
realize what he's actually opening.

I suggest you just focus on making a nice mud that suits you, and
forgetting about fixing the "lot of problems with how traditional
mudding has worked."

-Crat
http://lpmuds.net

So what you're really trying to say here is:
"I'm better than you. How dare you imply that you're better than me!? FIRE MORE QUOTE BOXES AND DOUBLE STANDARDS, IMMEDIATELY!"

Meh decided to read the blog instead of just the replies, have to say that it's well, a farce.

ROM is not precious lace when in its stock form, neither is Merc, or even DIKU for that matter, they're all more or less what I'd categorize as being cluster*CENSORED*s.

Also there's simply no way to have "immortals" have the commands necessary to adequately do their jobs without also giving them the ability cheat other than having next to no staff at all on the main game port and VERY scrupulously going over every object, and mob and room etc. before transferring them over from another port where all the work is done.

I only skimmed the blog as I found the colours and writing style too
distracting, but I didn't read anything particularly ground breaking
there.

On a positive note though it is nice to see people trying to take
MUDs seriously and think about their design in a critical way.

I feel very lucky to have him, because I can't code at all (except for mprogs, which clearly is not in the same ballpark) and he has been able to code literally everything I have asked him for, whether it be awesome mprog tools like mob pause or a million different kinds of ifchecks, or fixing the MANY problems in the code as we got it, or creating cool new spells, skills, or quality of life game features.

Nice, and good that you have someone you trust and enjoy working with.

He's done such a great job making DR stable that as implementors we have been able to step away from the game completely -- neither of us are involved in running DR now, which gives us time to work on our new project without having to shut down or radically change the mud that so many people have loved for eleven years now.

I notice here you sort of insinuate, and in your blog, you say that you believe it is possible to stop cheating altogether through coding.

I think that is a naive generalization. I think that overall, good coding, and proper game design can do a considerable job toward stopping cheating, but not eliminate it. If you have a system that is able to be accessed from other people, they will find a way to cheat, if they want to.

An example I would use would be something as simple as multiplay. Most games have rules, in general, about this. Some allow, some do not. It is virtually impossible to stop someone who really really wants to multiplay though. A canny player can easily proxy their IP and have multiple windows open, giving them enough time to seemingly have simultaneous conversations. There is little code can do to stop that. As an extention, if your game has money and each new character gets some, and each new character gets items which can be sold. Well now you have a player who can have virtually unlimited money and items for sale. Be it at a slow pace to avoid speculation, but still possible.

Likewise, no one is perfect. Code is imperfect. Perfection is a laudable goal, no doubt, but to actually attain it is contrary to the rules of our existence. Everything we are is flawed, which makes us unique. It gives us character, and definition, dissimilarity.

You speak of MUDs and say they are broken with bad code, and limited vision. I would half agree, and the other half.. well it makes it what it is. It's like slipping on a pair of comfortable slippers, or a comfortable but worn robe. You don't throw out the slippers because they are scuffed, and if someone decided that your slippers were bad because of how they looked and got you new ones... well you may or may not like them.

People like familiarity. they like quirks, they like old. As much as things change, and evolve, and become something new people still like to feel what they knew. If someone started MUDing on a ROM 10 years ago or so, and they play a derivative of it, that has a core similar to a ROM they will probably be more apt to give it an extended try. If they started on a ROM and play a MUD that is totally dissimilar from it, they may not.

Just as no code can be perfect, that rule is not either. My point is that, to claim a perfect creation is to disrespect the time and effort that others have put in to this genre. You could work towards a design that you feel is feature complete, and something that you enjoy, and matches your vision but that doesn't mean that anyone would like it. (I am not saying no one would, just saying it is possible).


I just find it odd that on one hand you dismiss the amateur, and on the other you tip your hat to them. The subtle contradiction seems to be mirrored in your blog.

I mean no offense by any of this, just an open answer to your thrown gauntlet.

if it simply isn't possible to cheat at a game, there don't need to be any rules for a game.

This goes back to earlier, but there is no such thing as a game without rules. I think what you might have meant was a game with no written rules. At that point the game would be the rules and the enforcement, though again I disagree that this is entirely possible.

I think your point is trying to assert that the addition of rules that are upheld by humans creates a natural tension and power struggle as each tries to assert dominance. While one side obviously has greater power, the other vies for power of influence. I agree that this is largely a problem, but a static non intelligent game cannot adapt to changes in players or new ways they discover to exploit a system.

but the fact is, the magi who have become part of a magic guild, who work and toil day after day to discover and enhance magic, these magi SHOULD have exceptional power to protect themselves. if the game is trying to be realistic (and to me, it should be, even if it's a realistic fantasy about vampires and elves), there should be a way for non-fighter classes to protect themselves and even to be the best WITHOUT having to fight. after all, they CHOSE a non-fighter class.

I agree that a game design should be consistent and coherent across itself. So whatever realism you have created applies evenly.

I do not exactly see what you are trying to say here though. Are you asserting that a player who cannot fight, should be able to best someone that can? Is this a physical game mechanic, or an imaginary one?

If the former, then the answer is no. You wouldn't even be able to measure a win unless you allow some manner for them to fight. If you allow it, then they really aren't a non-fighter, are they?

If the latter, then no they haven't chosen a non-fighter class because the game makes no distinction between a fighter and non-fighter. So either the player construct is invalid, or the game is.

You are using the term BEST without any delineation as to what constitutes the best. I think that would be the start of your design. How can you create a detailed character path without first establishing what you envision the goals to be, i.e. what the best can be. Further, if you choose to let characters who fight and those who do not fight to be evaluated on the same field, how do you measure that? Is the best the one who can kill faster, or knows more? Is it the one that can hide quickest and knows the most terrain? Is it the one that can weave the best story? If so, who determines what the best story is?

i think the concept of guilds needs to change. i think they need to incorporate trades, in a way. a magi guild might have one trade for each circle of magic: one for nature magic, one for death magic, one for healing magic, one for destructive magic. each of these circles might have tasks to do, rituals to perform, potions to brew, etc, etc, tasks which might take years for a character to perform in completion, each granting significant over-other-characters power. in this way, a player who most loves exploration, or who most loves doing quests, or who most loves performing rituals, can rise to power alongside someone who most loves to pk.

I do not see why Guilds need to be inexorably linked to anything. Traditionally a Guild was simply an association of members with like ideals and goals. Why should the Guild dictate a trade or focus? Shouldn't the members do that?

If you want to be specific about the intent, and say that a class is actually a Guild, cool, but why do they need to have a designated trade? What if I am a member of the local Fighter's Guild and want to sell flowers I find on my travels? I just don't see why a trade be linked to the Guild specifically. If a Guild chooses to do something great, but strictly linked, unless backed up with some intrinsic reasoning, not really.

could it be done without imms? it could be done without actually having "guilds" with their pomp and circumstance, but rather just guild areas which supply what is needed, and achievable powers over who can access the supplies in the guild... imagine a magi guild with limited resources... a powerful mage might force other seekers away, using the secrets he's unlocked for himself. a thief guild, which might teach new ways of sneaking, new types of sneak attacks, secrets to picking unpickable locks, poisons, how to apply sleeping potions.... that sort of guild might be totally secret, forcing one who wants to join it to think like a thief to find the hidden knowledge of the masters. a thief guild, which perhaps turns thieves into assassins.

To the first question posed in this; Of course it can be done without immortals. Very poorly planned games might require the Immortals to actively advance the game. Though that is a very poorly planned game, or thinking on it, a game that requires the Immortals to do so for a specific reason. That reason could entirely be design driven and work in the confines of the game. Given the tone of your question though, that seems unlikely in your meaning.

To the second portion in this... You first say that there is no guild 'pomp and circumstance' and all that, then say that there are guilds. I think what you might be insinuating is a guild format in which the guild itself is a transient idea as far as it is visibly taken, and someone can come and use it as a resource, but the guild itself doesn't exactly visibly exist. I could be off base, it's difficult to extrapolate.

I honestly don't see why a system like that would exist. It would make sense to me that either you have a defined Guild system, or you allow the players to shape, create, and manipulate them. Using your example of a Magi Guild, if that powerful wizard came along and 'took over' why can't my friends and I start a new guild with the information we already know? Perhaps we took some of the 'ancient books' and what not too.

I suppose if you equate a physical location to the Guild then someone could come and physically take over, though they couldn't metaphysically do that with an idea or concept. The only way to do that would be to slaughter the old practitioners so they no longer exist, and rewrite history and whatnot. I doubt your game will allow for that.

The thief guild thing... well I suppose someone could find the secrets of the masters and 'stumble' on a guild, thought it makes little sense. A guild is only as physical as people make it. If a guild is truly secret, it should live only in their minds. If they do not dissemble then there is no way to 'find it' unless you find the people, and then they admit there is a guild. More like, some would form a secret Guild, and then watch and indoctrinate those they felt worthy. That would make more sense to me.

if there is going to be competition, there must be fair competition. i think level caps are important for this reason. it's important to have a level to reach which everyone can attain, a point at which, theoretically, the field is fair.

Last comment, promise :P

Why?

I do not like this logic, at all. If you assert a level cap creates a point at which the playing field is even. Why must there be a level system?

I am going to make an assumption that your response would be, so every has all the abilities and skills they will be able to have. Which brings me to the question, why would you make assertions about a guild system that allows for continual learning, and then discount it with a statement about level caps evening a playing field.

This doesn't even begin to get into for it to be completely fair and even, everyone would need identical copies of a character. Your assertion about player skill being the biggest factor, I mostly agree. That being said it's not entirely true either.

I also do not think that all classes should be equal. They should be good at their intent, but that does not mean that they should be on equal footing. How is it that the worlds best assassin should be equal with the worlds best swordsman? If I am an assassin, I am going to poison your food with undetectable poison, and not fight you, period. Likewise if I am the worlds best ranger, I am going to sit a fair distance away and wait until I can shoot you in the face with an arrow from a couple hundred yards. How is any of that equal? If you have a system that is completely equal, then no one is different. They may appear so, but underneath it all, they can't be. There is nothing that makes them uniquely better at X or Y or Z or A. If I had the stupid idea to attack the worlds best swordsman, in a duel, as an assassin, with a sword, well pity me I am going to die. (This is assuming I cannot inexplicably vanish, which truth be told is a weak game mechanic to circumvent this issue).

I really prefer a fluid game system. You have numerous skill trees and abilities, and can work to attain them. There is no level, because there does not need to be. Some prefer a level based system with clear skill paths.

Though I still think if you go level based, with skill paths, you need to design it intelligently and uniquely. Why should I play a fighter if a thief can defeat me at a sword fight? (This is a simplification, obviously, but illustrates my point).

These are largely out of order across your blog, but I think it flowed better with the intent of my argument.

In any event, good luck on your project. :)

-Syn

Just to comment on one point:

> I think that is a naive generalization. I think that overall,
> good coding, and proper game design can do a considerable job
> toward stopping cheating, but not eliminate it. If you have a
> system that is able to be accessed from other people, they
> will find a way to cheat, if they want to.

If there are no rules, then by definition there can be no cheating. However I agree that certain issues are extremely difficult to resolve purely through code - the three big problem areas I've found are multiplaying, botting and communication.

There are various measures that can greatly reduce the value of botting, but you cannot prevent it, and it can become a real problem in combination with multiplaying - enough of a problem that it can drive off existing players. Providing players with 'ignore' commands and the like can allow them to block out obnoxious chats, but many newbies will simply quit in disgust if that's the first thing they see when they log on.

It was also suggested in the blog that if there are no rules, there will be no conflicts between the staff and the players. This is definitely not the case. Some players actively want rules, and will deliberately try to ruin the game for others in an attempt to have rules introduced - meanwhile, their victims will frequently blame the staff for not doing anything about it.

If there are no rules, then by definition there can be no cheating. However I agree that certain issues are extremely difficult to resolve purely through code - the three big problem areas I've found are multiplaying, botting and communication.

True, what I mean, and should have been more clear on, was that if you design the game to have the rules and enforce them people can find ways to circumvent the system and still cheat.

I.e. instead of having a rule that people cannot transfer money to other players, make the game not allow it outright. Players that want to break the rule, should they put enough time in, could probably come up with a way.

I think the problem I was trying to illustrate was saying that you can create a game that is foolproof and therefore walk away, because no one can cheat.

(Comment added by synorel on Mon Nov 2 12:42:01 2009)

^ then obviously that this isnt exactly possible.

Also, thanks KaVir. Appreciate the comment, and your point on the rule breakers to have them forced. I have seen that in the past. Interesting scenario, well from one standpoint anyway.

(Comment added by synorel on Mon Nov 2 12:50:01 2009)

Sigh, I am at work, and scatter brained.

Boils down to, if you create the game to employ the rules you would otherwise state, if someone exploits a way to circumnavigate the inability to do X action, they are cheating and have broken that rule.

Further I do not believe it possible to create a completely locked down foolproof game.

-Syn :)

I feel the need to clarify some things :)

I posted the initial invitation because there seem to be a lot of clever people here who enjoy thinking about game mechanics, and I thought it might interest or amuse. If anything I've written sounds insulting in any way, please let me just say that it was not meant to be so.

I'm thinking and learning about game design as a whole for the first time. I've never designed an entire game before, and my blog is meant to be a chronicle of my learning process and my thoughts as I go about doing this. I don't think that makes it a "farce" as someone said...certainly it is a record of my thoughts... but just as certainly my thoughts are those of a beginner game designer with no experience in this field beyond playing and running one mud, and loving games. My own background is in books.

If what I've written seems naive and idealistic to you, it probably is. I feel like a kid in a build-your-own sundae shop. And I am an idealist.

Thank you for all of the comments so far. Very thought provoking :)

p.s.

I do know that game theory and game design are two different things. I'm interested in learning about game theory because I want to relate the math to mud design and see what it looks like. I'm curious.

> Boils down to, if you create the game to employ the rules
> you would otherwise state, if someone exploits a way to
> circumnavigate the inability to do X action, they are
> cheating and have broken that rule.

Well the point is that there isn't any rule to break. Exploiting a loophole in the design (or a bug in the code) would be the equivalent of exploiting a loophole in the rules in a rules-based game. In both cases I would expect the admin to address the loophole to prevent further exploitation, but technically speaking neither scenario actually involves cheating.

> Further I do not believe it possible to create a completely
> locked down foolproof game.

It really depends on the specifics of your game, but it would require some extreme measures to completely avoid the three problems I mentioned previously (and these would have a major impact on the gameplay).

> Boils down to, if you create the game to employ the rules
> you would otherwise state, if someone exploits a way to
> circumnavigate the inability to do X action, they are
> cheating and have broken that rule.

Well the point is that there isn't any rule to break. Exploiting a loophole in the design (or a bug in the code) would be the equivalent of exploiting a loophole in the rules in a rules-based game. In both cases I would expect the admin to address the loophole to prevent further exploitation, but technically speaking neither scenario actually involves cheating.

> Further I do not believe it possible to create a completely
> locked down foolproof game.

It really depends on the specifics of your game, but it would require some extreme measures to completely avoid the three problems I mentioned previously (and these would have a major impact on the gameplay).

Ok, I don't really feel like arguing the point. I see what you're saying and agree mostly. I think its somewhat perspective driven at this juncture. I agree on your last point though, depending on what you plan, I suppose that the statement is null.

I posted the initial invitation because there seem to be a lot of clever people here who enjoy thinking about game mechanics, and I thought it might interest or amuse. If anything I've written sounds insulting in any way, please let me just say that it was not meant to be so.

No offense taken personally, just how it kind of sounded off the cuff, so to speak.

I'm thinking and learning about game design as a whole for the first time. I've never designed an entire game before, and my blog is meant to be a chronicle of my learning process and my thoughts as I go about doing this. I don't think that makes it a "farce" as someone said...certainly it is a record of my thoughts... but just as certainly my thoughts are those of a beginner game designer with no experience in this field beyond playing and running one mud, and loving games. My own background is in books.

Drizzt does like the direct approach heh. That aside, I think it's cool that you are posting it, and exploring the genre, the work, the labor of love.

If what I've written seems naive and idealistic to you, it probably is. I feel like a kid in a build-your-own sundae shop. And I am an idealist.

I would first like to apologize if you took this as an offense, it was not meant to be so.

That being said, we all could use a little more innocence in our lives. Idealism and innocence are not bad things unless they are approached with blind fanatacism in my opinion. As long as we are willing to learn and adapt, sure, its always good to have someone say. Well why can't things be like this?

Thank you for all of the comments so far. Very thought provoking :)

For any that I have made which help in your goals, cool beans. I hope your game dev is going well and that any of these discussions inspire you more than discourage. :)

-Syn

I'm thinking and learning
about game design as a whole for the first time. I've never
designed an entire game before, and my blog is meant to be a
chronicle of my learning process and my thoughts as I go
about doing this. I don't think that makes it a "farce" as
someone said...certainly it is a record of my thoughts...
but just as certainly my thoughts are those of a beginner
game designer with no experience in this field beyond
playing and running one mud, and loving games. My own
background is in books.

I more specifically meant the viewpoint that ROM in its
stock form was beautiful lace and that all the flaws in most
MUDs were introduced to it by the MUD's coders and not
already existing in its stock format was a farce, not the
entire blog or your MUD. ROM is not particularly well coded,
it's memory management in particular is just, well, messy.
If you're starting with stock ROM (or if you already have
but have added few things to it thus far) I'd strongly
suggest taking a look at RaM (basically RaM is to ROM as
tbaMUD is to CircleMUD) , as it's corrected many of the
"flaws" that exist in stock ROM.

Thank you for clarifying; that does make sense.

Maybe what I mean is that a mud's code SHOULD be elegant in the way that math equations can be elegant, in the way that poetry can be elegant. It's about having good form. In writing mprog code I have seen for myself that things can be done clumsily and heavy-handedly, or they can be done efficiently and cleverly. I likened the code to lace because of its beautiful complexity, and the many tenuous and delicate connections which it makes. I don't think that stock ROM code is perfect, but I do think that on my mud, its delicate structures were badly damaged by quick and ugly duct-tape style fixes put in by many different people with many different levels of skill. While the coders who did this have far more skill than I personally have (I would be afraid to try to venture into the game's code to the point of actually touching it), the messy, damaged code remained a problem until fixed by someone who could make it elegant.

I think that the hardest thing to do is change someone else's code, especially under less than ideal circumstances (such as: if the previous coder left no indication of his intent or purpose; if the previous coder did not really understand how to make the code do what she intended to do but somehow managed to force it to work capriciously without understanding how or why it was working (when it did); if there have been coders who made changes to the code but not to all parts of the code affected by the changes, leaving many things undefined; etc).

But truthfully, ROM code itself (and, I must assume, RaM code) is beyond my ability to read and understand without painstaking effort, and my impressions of it come from looking at it and making extrapolations about it based on my own experience with writing mprogs (which can have their own complex elegance, though on a much reduced scale), and from speaking with coders about it. Luckily, I don't think I personally need to understand how the code works to respect and admire its complexity, or to be able to design a good game. (thank goodness :)

Thank you for your suggestion about the code base. I think we will stick with ROM because we have already fixed many of the coding bugs we found and identified (things like item duplication, memory leaks, random crash-causing bugs, etc). Maybe we did unknowingly reinvent the RaM wheel in doing so, but we had to, since it was (and remains) the wheel which runs an active mud. Now that we have so many of the basics the way we like them, we want to go further and make changes that will revolutionize how this particular game is played and run. It might not be revolutionary for you mud designers who went through this process a decade ago (ahem), but it's been a very fun and exciting process for me so far, even if I am ten years behind the learning curve :)

A question if I may... are the "flaws" you mentioned in the design of the game, or in the implementation of the design (ie, the code)? And I am also very curious: what do you consider to be flaws in the design of ROM muds?

Also to Synorel: I enjoyed your posts, and yes, your comments and questions will definitely help me focus on what it is I really want to do here. "Exploration is the soul of man," and you have given me many things to explore :)

often in the past, there have been players who did very little fighting, but were still very powerful. they were powerful because many people respected them and did what they said. they were respected not for their pk skill, which was negligble, but for their ability to weave a story around people, to bring other people into the living web of the game. i would like to see there be a way for these sort of people to earn the power to destroy their enemies without having to pk in the traditional means.

Just have to make a comment on this, which I saw in your latest entry. As someone who is capable of PKing and RPing, I can tell you right now that if they were so capable of being respected by other players, the mechanism for them to be able to destroy their enemies already exists. I have been on games where there have been pacifist characters that have been picked on and defended by PKers because of the role they've chosen. Being able to write flowery emotes and RP that you're the son of the beggar mob in the generic poor alley is great and all, but if you're going to start a conflict with someonee, or do something that someone else wants to kill you over, having a big sword, knowing someone with a big sword, or being able to run really fast should be your only choices for recourse.

Sorry to quote myself, but for the sake of context...

> If there are no rules, then by definition there can be no
> cheating. However I agree that certain issues are extremely
> difficult to resolve purely through code - the three big
> problem areas I've found are multiplaying, botting and
> communication.

I was recently reading over some comments about my mud, and came across this gem:

"While the admin has followed a no rules idea, he seems to be actively trying to stop bots by hard coding anti-bot mechanisms rather than finding a proactive solution to make bots less of an issue."

It reminded me of the discussion here concerning a mud with no rules, and my comments about the three big problem areas I'd encountered. I decided to check up on the blog and see what sort of progress they'd made in the last few months, and whether they'd found any solutions to the three issues I mentioned, and came across this posted section of conversation:

-Indi- i think the rules i want are like...
-Indi- don't multiplay
-Indi- and don't spoil the game for other players
-Indi- and if i decide you have broken either of those rules
-Indi- your char goes back to level 1
-Void- That's really ambiguous
-Void- For some people getting PK'd "ruins the game" for them
-Indi- yeah, but i am the one who decides
-Void- So you're like... a dictator :P
-Indi- it's my game
-Void- Heehee
-Indi- don't like it, leave :)

I have to say this definitely isn't the approach to "no rules" that I'd envisioned from the earlier blog entries. In fact it sounds like a step backwards, to the days when most muds didn't bother informing the players of the rules, and instead just made them up on the fly. If you're going to punish people for breaking rules, I think it's only fair that you tell them what those rules are in advance.