Monday, October 19, 2009

Consider This Your Invitation

dear people who are interested in thinking seriously about gaming, in writing about gaming, in writing period, in reading the writing of a mad blonde game designer,
--i don't where you all are out there. but i am writing to you, and would love further correspondence.

dear people who are interested in the specific game of dr,
--this blog is not primarily about dr. it is about gaming, but will probably contain references to dr if i can use it to illustrate examples about my theories of game design. you may learn interesting things about how dr works, but nothing that is secret. dr's secrets will not show up here.

to: people who nitpick writing
--if you are are feeling distracted by the absence of capitalization or quotation marks in this work, then please take a moment to consider the following:
-my thoughts have few capital letters.
-my conversations have no quotation marks.
-punctution describes how writing should be read.
-let conventions slide.
-those things are not important here.

i am a game designer who recently left off working on someone else's vision for a game and decided to make my own. making a game, designing a game from the ground up, is sheer pleasure for me. although i feel i did many innovative and interesting things on the game i just left, there was too much there which i felt needed correction and change, too much that had gone bad and too much that had been lost. i also found myself itching to change the story, to make it better, to make it more rich, more interesting, more alluring, more real. i did this in many quiet ways, like replacing dusty felt curtains at an old theatre with heavy velvet ones, rich and red. my partner in crime (ie my coder, a most talented, gifted, and generous coder. he has a good sense of humour, too.) and i did good things at that mud, but we left because what we want now is to create something new and better, something beautiful.

when we left we didn't know exactly what it was we wanted to do. there were no longer any limits. we weren't shackled to an irregular buggy code patched together in snippets and drunken amateur coding attempts. we no longer had to be concerned about player outrage over the changes we felt should be made. there were many reasons we felt we had to leave that other mud which may, i suspect, come up often in my writing here. however, i must point out that although my coder and i still are owners of this other mud (along with our third owner there who is not involved in our project here), we have given up all direct control of this other mud, and no longer have any creative or coding or staffing input whatsoever. i have been playing again as a mortal, the way i used to be able to play before i became involved with the staffing of the game. it is a very enjoyable game to play, which makes me proud and happy. my coder and i no longer pay for the mud either, but we have told the players how to donate, and how cheap it is to keep the mud afloat. between the dedicated staff and the solid commitment and loyalty of the players, i think dr will stay afloat. it will be eleven years old on october 31. <3

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

we see a lot of problems with how traditional mudding has worked. the main problem, i think, is this.

muds were created by people who were learning how to code as they coded. muds were then taken and adapted by other people doing the same thing, and new versions were released. we were running a rom 2.4 mud which not only has gone through several revisions (how muds developed is a fasincating story... i'm unsure of whether to tell that story right now or not... perhaps later, let's go on). anyway, it had gone through several revisions just on the code base itself, which is available for download for free to anyone. then, it had gone through several coders with varying levels of coding proficiency. rom code is COMPLEX. it's full of tables and tables and tables and tenuous links from one part of the game to another. rom code is a delicately patterned, like lace. people who don't know how to make lace, when they try to add to an existing piece of lace or try to fix it, these amateurs may try hard but often accidentally make a clumsy mess of it. that's what the code of dr is like. it's like lace into which clumsy fingers have blundered many times. some of these blunders came from dr's own coders. some came from the blunders of previous rom designers. some came from horribly blundered "snippets" which are patches, patches on lace.

the point is, problems in game play arose from problems in code. since people who work on muds are often not good programmers, attempts to correct those problems were not done with code, but with putting rules into the game. in order to have rules, someone must enforce the rules, and so a game with rules needs arbitrators or "immortals" as they're called in dr) (note: i will not call them immortals on the new game. the term muddies the story of creation since that speaks only of three deities. this is one of the many problems i have with dr. it has such bad form.).

in this type of game, where the conflict is meant to be between players, the introduction of rules inevitably creates conflict between players and staff, instead of just the game-conflict which is player-player. in some cases this player-staff conflict is treated like game-conflict by one or both of the player and staff member involved. this inevitably ends in a player getting banned from the game, whether the staff member is at fault or not, because i am the one who has to deal with it, and i hate it. there is nothing worse to be pulled out of building or writing because i have to deal with some dope who thinks it's okay to pick a fight with the referee. my game, my referees, they know the rules. people who have a problem with them should come to me privately. i am harsh with people who knowingly break the rules, especially if those people are staff, whom i hold to a much higher standard. the player should talk to me about the situation and then find some other player to fight, not keep trying to ko the staff. the staff will always win, and the player will always lose. the staff is immortal. however, i do investigate suggestions that any staff member of mine is corrupt. i police my staff to uphold my ideals. most of the time i have tried to choose staff who share my belief in these ideals of honesty, fairness, honour, like a gentleman's game. sometimes people have fooled me, pretended to beleive in these things to gain power in the game, and behave unscrupulously whenever my back was turned. these people have made me a less trusting person than i used to be. other people do not cheat because they know i am watching them. those kind of people also make me sad.

but i think the ability to cheat is a flaw in game design. games can be ideal worlds, a programmer's ideal and perfect place. places of magic. places of fear and mystery. places of excitement. if a programmer can create all this, then he should be able to create a world in which all attempts to cheat will fail.

if it simply isn't possible to cheat at a game, there don't need to be any rules for a game. if no rules, then the only conflict which can exist will be player-player. i would kind of like a way to make immortal status real and achievable. i think that would be pretty fun. as it is there are only a few things that immortals can do to cheat, and only a very few which could affect someone detrimentally. i think those could be controlled with good coding. then players could become immortal. that would be a pretty cool ability. i think immortals should also be players. dr doesn't have the code to support that, because there are such massive power imbalances between morts and imms there. but the new game can.

in my next post, i will be writing about game theory and applying it to the game of mudding. i will try to use math to explain what i think makes a great game. other posts will relate how the new game is finally coming together, in terms of what it will be, how it will look, what races and classes we will be implementing, the new variables we will be adding to the game, what we will be taking away from the game, and many other things. it's very exciting!

one last thing today. judging from the last blog i wrote on (which was also the first blog i wrote on, an admin blog which my coder created a few months before we left dr), there are many people at dr who are unhappy that we kept the code for dr locked when we left. i know there has been a fear of stagnation, and although to me the game seems vibrant and alive, i do understand your concern. i don't want dr to die off either. i left because i had faith that dr would not die off. i still have that faith. anyway, my coder and i have been discussing whether or not to release dr code, either as it is now, or as it will be once we strip away all the bad and polish up all the good. maybe we will release both versions. maybe not. there are a lot of things to consider, but we are considering things.



  1. Good luck with it, I will be interested to see how this turns out, both as someone who enjoys muds and someone you believe a cheat.

  2. a note about comments:

    comments are moderated by me before they are published. i may or may not publish comments and i may or may not respond to them. if you would like your comments to remain private, simply say so and i will not publish them. i am looking for a good atmosphere here of mutual respect and thoughtful conversation about game theory and design. and in tonight's case, bees.

    good luck to you too, t.