©2001 Moe@OGR. You may copy and redistribute this document provided that it remains complete, with credits intact, and is used only for non-profit purposes.*
*****

Vadiv enters the room through the double doors, which swing closed behind him.

Vadiv strides majestically into the room.

Muse claps!

Elena throws popcorn at Vadiv.

Scaramouche enters the room through the double doors, which swing closed behind it.

Elena hides.

Moth enters the room through the double doors, which swing closed behind it.

Bowing as he gets a standing ovation, Vadiv makes his way to his seat and sits down.

Building Character from the Ground Up -- PLEASE READ ME! has left.

Scaramouche returns!

K'Alan Bryce notes that it wasn't /quite/ a standing ovation. :P

Vadiv says "You're just jealous."

K'Alan Bryce says "Not."

Gandalf enters the room through the double doors, which swing closed behind him.

Vadiv says "Are too."

You say "Okay, welcome to the class on the First Week of a MU*. I'll start off with two disclaimers, and that will set the tone for the rest of the class."

You say "Disclaimer #1: This is purely my opinion, based on how I have learned to do things over 11 years. Do I think it's the best one? Yes. Do I think it's the only one? No."

You say "Disclaimer #2: I have a slight bias towards the code-related side of things. I will try and temper that for the purposes of this class, but if I go to far towards code-y things, you may punch me."

You say "This class assumes that you have gotten yourself serverspace, and have compiled your mush, flavour of choice."

You say "The methods and practices of doing those two above tasks is a class in and of itself."

You say "What I want to discuss are things like building theory, assigning staff, initial coding, and some small matters of Master Room Management."

Alec sadly has to go to bed, will have to read the log. :P

You say "Are there any other topics related to the First Week of a MU* that you guys would like to see added to today's discussion?"

Muse hugs night Alec.

Moe waves to Alec.

Moe waves re-hi to Nymeria.

Alec has disconnected.

Satyr hmms. "'Getting Things Started Right'?"

You say "That would be the aka of this class' title. :)"

Scaramouche says "Security? Master Room and the MU overall?"

Satyr grins.

Moe nods. Master Room mgmt will be addressed.

Scaramouche noddles.

You say "Security also comes in under staff assignments."

Scaramouche noddles.

You say "Pretend I spelled that right, just for fun."

You say "When you first fire up your mush, you have two rooms, and one character. You have room #0, #1(God), and probably one other room, #2, which is your Master Room."

Kellin enters the room through the double doors, which swing closed behind him.

Moe notes that for flavours other than Penn, the master room has to be explicitly assigned before firing up the mush, but can be added at any point.

You say "Penn defaults to #2, but can also be changed in compile. Now, that you have at least #0 and #1, what do you do?"

You say "First."

Vadiv has a topic to add: Defining staff and other positions.

You say "You make yourself a Wizard character. This is the character from which you will do all your 'work'. In general, you don't want God to own things. Period. God has permissions to do things that are just...well, bold. God can do anything, usually without aforethought, or confirmation.//Staffing is going to be addressed."

Scaramouche says "I like God's Omnipotence. ;)"

You say "#1 is the only character on the entire mush that can assign a Wizbit to a /player/. A Wizard character can assign a wizbit to an object/exit for the purposes of coding/permissions, but only #1 can set a PLAYER wizard."

You say "Yes, #1's Omnipotence is a good thing. But, it's best if you do all your work from a Wiz character, besides #1."

Scaramouche nods.

You say "Now, once you have a wizard character, I suggest you sit down and think. As Scara was talking about for building a character, you have to extrapolate those things to building a whole world."

You say "Here, I am going to offer a slightly controversial piece of advice, but one that I have found CONSISTENTLY to be worth it in the end."

Scaramouche noddles.

You say "Take the first working week of your mu*, and do all the building yourself. This doesn't mean don't have anyone else on the mush. It doesn't mean don't do any coding, or have anyone else do it. What it means is that based on YOUR theme and concept for the mush's own persona, this is the only opportunity that you're going to have to do the initial framework yourself."

Vadiv oos, and likes.

You say "Take the time to do ten rooms or so. Ten IC rooms. The staff area, the ooc room, and such amenities as those are truly extra, and can be added in later. I am specifically referring to the first ten or so In Character rooms, the basis of your IC grid."

You say "These rooms are likely to be the first things new characters see when they go out on the grid. They are the first impression they have of the IC element of your game, and are also the root from which /all/ other IC building is going to be done."

You say "Given that it is 'your' game, these rooms should be built to 'your' specifications."

You say "In these first ten rooms, you have the opportunity to set a template, so to speak, for how IC descs are going to be done, how exits are going to be named, and messaged, and to how the geography of the grid will grow."

You say "For example."

Moe will take the example of ChicagoMUSH...this small little mush I happen to *cough* play on.

Bingo says "That toddlin' town."

You say "When the building for that mush started, we began with the City Square, which is where the new characters emerge when they first go IC. In that room, I established things like %R%t at the beginning of the desc, %R at the end, that exits would be named as Exit <alias>exit;alias;a;etc. I also established that if there were +views on the room, that polayers would be notified with an @succ on the room that displayed a message."

You say "Polayers=players"

You say "From that initial room, I started on the streets, beginning to lay out the initial four blocks of streets that surround the City Square."

You say "NOte."

You say "When I am talking about building the first ten rooms, I don't mean buildings. I am talking about major outdoor venues. Streets, roads, rivers, parks, meadows. The 'main, outdoor' IC areas."

You say "Granted, if the theme of your personal mu* is all indoors under a bubble, you would take the term 'outdoor' with a rather large grain of NaCl."

You say "Does anyone have any questions about this concept of doing the initial building yourself?"

Scaramouche says "Does that include descing or just general grid layout?"

Scaramouche says "You started with the square, then worked out. How much of that was 'finished'?"

Scaramouche says "Or were you just rying to provide basics for someone else to come follow up on?"

You say "All of it. Since I built that room the first day, I've changed two words in the desc since."

Scaramouche noddles.

You say "The first ten rooms give the 'basics' so to speak for someone else to come and follow up on, but it's following up as regards following your lead."

Scaramouche noddles.

You say "Your first ten rooms set a precedent for how descriptive you want your room descs to be, as well as what kinds of features you'd like to see pointed out."

Scaramouche nods, "I thoroughly agree. But I figured I'm anal retentive." ;)

You say "An example to compare and contrast would be a street desc that focuses on the height of the surrounding buildings, and the hardness of the concrete, as opposed to a street desc that potentially includes weather, and takes a fair amount of space to describe the /mood/ of the populace or the activity on the street."

You say "it's a case of passive vs. active language. Something we have to face in any desc'ing effort."

Scaramouche says "Absolutely."

You say "Any other questions on the initial building?"

Moe counts to 25 and goes on.

You say "Let's go on to staffing."

You say "Okay, I have an old-skool system of staffing, but I think if you take some of the ideas I have and use them as guidelines for hiring, it can be helpful."

You say "I advocate having a small staff, if possible. In general, I break staff responsibilities into four LARGE categories: Theme, Building, Coding, Newbie"

You say "Under each of those categories are potentially bazillions of sub-categories."

You say "Examples are under Theme, you have: TPs, Timeline, Clothing, and Technology"

Moe would classify things like Grid Structure, New Building Approval, Proofreading under Building.

You say "Under Code, you have Weather, combat, faction, globals. Conceivably, on a large or complex enough mu*, it is possible to have an admin for each of the sub-categories that you -NEEEEEED-."

Moe emphasizes need. Here's why.

Moe will talk Code for a moment, as regards staffing. Needless to say, code is something I understand. :P

You say "When you are sitting there with <10 rooms, and probably less than 10 characters on the entire mush, you probably don't need to hire a weather admin at that point."

You say "Nor a combat staffer, who is familiar with all of your combat systems."

You say "At that point, you need _A_ codewiz."

You say "This is the person with the relative amount of kung fu to start very initial basic things. It is with this person that you cooperate, and plan out what systems(faction, weather, combat, chargen, Firan's coded ts) that you're going to install."

Vadiv nods to all this.

You say "Likewise with building, once you have put the initial effort into constructing the beginning of your grid, you don't need fourteen build admins to suddenly explode into 20 different areas."

Moth goes west, through the double doors, exiting the lecture room.

You say "You need one, at most two, build wizzes, with whom you will work to make sure that their efforts go along with what you started, and that THEY set up similar templates to what you did, for people who shall come after."

Moe will note that he's starting a trend here. One person's work builds on the efforts of those previous, /and/ senior in the levels of staffing.

Scaramouche goes west, through the double doors, exiting the lecture room.

You say "You are God. It is your mush. You hand off your work to your wiz staff. They put their skill and talent into expanding upon what you have done. Once that is going along nicely, it's perfectly safe to individualize the tasks, assign roy's to smaller jobs, and let the small nitty gritty work begin."

Moe preaches a policy of control. And tiered responsibility.

Brigid says "Amen."

You say "When you're hiring your staffers, hire them as you need them. If there isn't even ten IC rooms yet, you don't need to hire admins to plan out how your Elves are going to dress."

You say "The topic of -how- to hire an admin is something that I believe we've had classes on before, and covered on bb7, and I don't want to get into it right now, as it is a wholly-separate(and sticky) topic."

Bingo raises a hand.

You say "Unless you happen to know 8-10 people that are both willing, dependable, and skilled enough to handle all your admin positions, and you have them all hand-picked, interviewed, and hired, I would suggest letting those first initial wiz staffers that you do hire to help in the process.//Yes, Bingo?"

Bingo just wanted to add a comment that I think goes along with what you're saying, Moe. "My experience has been that 'Less is More' with regard to staff. A few (like half-dozen or so) committed staff are much better than a lot (a dozen plus) of staff. And keeps the spirit of the game 'tighter' and less troublesome in the long run."

You say "Yes! Thank you, Bingo. You just addressed the next thing I was going to say."

You say "Less is more. Less people mean there is less chance that someone is going to go off half-cocked in building, coding, or hiring."

You say "Less is more because it is less to organize, it's easier to keep tasks and lists of responsibilities orderly, and you, as God, should always have a better idea of what is going on, overall."

Vadiv has a comment to, although an obvious one.

Vadiv says "too, even. Toooooo."

Brigid raises a hand.

You say "Yes, Vadiv? Then Brigid."

Vadiv says "I would just like to comment: Don't use bits as some sort of heirarchy."

Moe oohs. Good point, and I will address that after Brigid.

Vadiv goodies.

Brigid says "At what point would you condiser it /necessary/ to ever have more than one codewiz? Personally I have one and the rest of the staff is told up front that if they so much as breathe on my master room I'll fire them."

Moe nods. Okay, that was the next thing I was going to cover, so I will do that and then go back to Vadiv's point.

You say "Having more than one codewiz is like taking two dates to the same dance. Sure, it seems fun when you start, but wait till the end, and you'll be sweating bullets."

You say "Here is my criteria for having a second codewiz.(Note I did not say third or fourth...)"

Bingo cackles.

Bingo says "Nice."

You say "When there is one a) system or b) area that is so large and/or all-encompassing that the coding maintenance on that one thing alone is equal to what the primary codewiz is currently doing, globally, for the mush, hire another one. Combat is a good, though not rigid, example of thise."

You say "this."

You say "If your grid is two whole cities, and one of those cities requires zone globals either incompatible, or that would be in place of the existing globals, have a codewiz for each city, or one person with a 4th degree blackbelt in mush kung-fu."

You say "Same would go for a faction system that was /separate/ from the existing globals, or if not separate, required a fair-to-moderate amount of its own maintenance."

Moe won't belabour the point with examples any more. Does that answer your question, Brigid?

Brigid guesses so but has a good coder and does without what he can't manage ;)

Elena has disconnected.

Moe grins. More often than not, that's the case. Coders are usually, by nature, prima donna's. They don't like other people messing with their stuff.

Moe <-- case in point.

You say "Vadiv brought up a good point, with a double-edge to it, and so I want to move to that."

You say "Vadiv brought up the point of not letting bits define hierarchy."

Announcement: Scaramouche shouts "

Howdy all. The discussion on MU Consulting and what it means for Ambassadors and Players will begin about 15 minutes in the Consulting Room. Moe is still discussing The First Week of a MU in the Lecture Room. Thanks!"

You say "This is true, in most cases. A roy-bit staffer in charge of an area is every bit(*rimshot*) the equivalent of a wiz, to that area."

Bingo raises a question hand.

You say "However, the admin building the ghetto of your IC city is not hierarchially equivalent to your overall building wiz. As well, they may even be more /talented/ than your building wiz. Talent is not a prerequisite for a wiz bit. You give wizbits to those people whom you trust to oversee the work of the admins(roys). Because, most likely in the end, it is going to be the roys that do the bulk of the grunt work. Everything from proofing player's building projects to greeting newbies."

You say "Yes, Bingo."

Vadiv bahs and sticks his hand back up.

You say "Bingo, then Vadiv."

Bingo says "I've always been on games where there were PLAYERs and WIZARDs. That's it. That's all I've ever used. (Well and one of the Wizards was often 'head Wizard' or 'God'). How do other people use the sort of pseudo-WIZARDs like STAFF and ROYALTY and such?"

Bingo points up to his 'less is more' statement a while ago. 6 Wizards all in a row. :)

Moe nods. Yes. Tm3.0 includes the royalty flag now, as does MUX2.0. Penn has had it for eons, and Rhost has five different levels of staffing.

Brigid raises a hand.

Bingo's question is more: I don't see a need for the levels. How do people implement it so that it adds rather than detracts?

You say "Okay, I'll answer that, then Vadiv, then Brigid."

You say "There are coding reasons for the staffing levels. Some softcoded commands should be restricted to wiz-only, some admin-only(wiz & roy), and some available to everyone. Often, the tiers of bits are organized according to power, since roys classically cannot alter bits of the db they do not directly own. Wizzes would have the power to write any obj, while roys are there for helping, debugging, proofreading. It's the latter that is the primary use I've seen of roys, in that they are used for their ability to examine things, and prompt the owners to change according to global specifications, whereas a Wizard can edit everything."

You say "Vadiv."

Vadiv says "Okay, I completely disagree with you. ;)"

You say "Unless Bingo says I wasn't clear."

Vadiv says "Well, not really, but I disagree with what you just said. ;)"

You say "Cool. Good, I like disagreement. Explain."

Vadiv says "I think that bits should not be used as rank, at *all*. ;)"

Bingo says "Thanks, Moe. I can see their usefulness there."

Vadiv says "In other words, your 'head coder', and *all* your coders, may need WIZ powers, whereas builder can get away with just having a few powers, not even being roy."

Vadiv says "Likewise with RP admin."

Vadiv says "Which is why i completely dislike things like 'code wizard' and 'rp admin'."

You say "Why would you want all your coders to have wiz powers?"

Vadiv says "Well, if they don't need it, then they don't need it, that's not the issue."

Vadiv says "My point is, bits are for people who need them, not to denote rank."

You say "RP Admin is the great misnomer of staffing titles, I agree."

Vadiv says "Right, they might not even need to be admin, and they certainly outrank a code wizar dint he day to day running of the place."

Vadiv suddenly becomes unable to type.

You say "Yes. And if the roys in my example above only need to proof player projects, whether they be building or coding, then they only need a roybit. It's not because they don't 'deserve' a wizbit. Their staffing responsibilities just don't call for them to have it."

You say "Brigid, your turn."

Vadiv says "Which is why I'm trying to get people to stop using the terms at all. I prefer 'Head Coder' and 'Sub-Coder', and replace Coder with branch of choice. ;)"

Vadiv shuts up.

You say "Vadiv advocates a revolution of labels. A worthy pursuit. I wish him luck."

Brigid's question was answered.

You say "He's going to need it.//Okay, Brigid."

Moe will move on to the subject that ties in with this. Security and Master Room Management.

You say "Speaking to something Brigid said earlier, it is wise to have only two to three people max that are allowed access to the Master Room. This is the 'brain' of your mush. This is where all of your global code is. The mush treats this room differently than it treats any other room on the game."

You say "As we have all seen, at least once, staffers get pissed, and leave. Staffers who are pissed tend to do things that they would not do under other circumstances. Like assault code, building, etc."

Boo enters the room through the double doors, which swing closed behind him.

You say "The Master Room is vulnerable like this, because anything there, whether it be $command object or exit, is considered global."

You say "Let one or two people, outside of yourself, be involved in the maintenance of the master room. One of them obviously has to be a coder. One of them can conceivably be a builder, if you have global exits."

Quenton enters the room through the double doors, which swing closed behind him.

Moe is going to have a class on Secure Coding at some point, and will cover coding topics in the Master Room there, though I strongly suggest reading both Ambery's and Javelin's Manuals for Mush Gods for issues surrounding Master Room SEcurity.

Quenton smiles as he walks in.

You say "Many of the things I've talked about here, are logical things. But, when it comes to issues like security of your game, you have to introduce rather amorphous variables like Trust."

You say "While bits should not always denote rank, as Vadiv suggests we avoid, you have to keep in consideration that anyone with wiz powers has authority over your master room."

K'Alan Bryce wonders if there's a way to actually lock the MR so that only certain people can make changes.

Moe is not going to advocate paranoia, limiting wizbits(for this reason, specifically), or placing hidden cameras in your staff's RL bathrooms(though URLs would be helpful if you do). I /do/ suggest being cautious. Educated about who you're giving Wiz powers to, and making sure that if they /are/ affecting the Master Room, they know what the heck they're doing.//Yes, K'Alan Bryce is right. You can set teleport locks, and in some codebases, even set who can set attr's on objects.

Brigid has a related point to K'Alan's question...

Moe nods?

Brigid says "As far as I know, nothing you do can keep a wiz out because by default they 'own' the entire db, true?"

Quenton nods.

You say "There is some contention over whether locks and @a-attributes set by God can be undone by wizzes. I personally have not experimented with this too much. Essentially, anything locked by one wiz can be unlocked by another."

Brigid just wanted to clarify that, thanks :)

Moe will research that further and let you know,a s it ties in with the Secure Coding class I'm planning, Brigid.

K'Alan Bryce would be interested to hear the answer ont hat one too. :)

Quenton nods "As would I"

You say "Okay, we're into the last half hour, and this is where I field any and all questions about how to start the first week of a mu*. To sum up the things I have said, I advocate a method where your building is begun by you, handed off to the next level of staff, and onward. Coding is outlined by you, taken on by a codewiz(just one), and handled in the Master Room with kid gloves. I have tried to address various applications of the levels of staffing, based on tiers of responsibility. And I advocate that you keep your staff small to increase productivity that reflects your ideas for the game, promotes organization, and keeps bloat from occurring...too rapidly."

*cricket*cricket*

Satyr chirps?

Moe gets Raid.

Satyr may have missed this, what with RL going on and such, and it may be a bit off the general discussion idea, but.. "Any ideas on how to avoid burnout, when one is handling almost everything on a MU* by oneself?"

You say "I will speak to how I do it, personally, and tell you that it works for me. I become painfully pragmatic and realistic about my goals. Despite the eagerness of filling up a blank canvas, of an empty db, I restrict myself to say one or two rooms a day, or only three hours of coding. Something managable. And then I make myself do other stuff."

You say "I go outside. I run around. I juggle. I cook. I clean. I play with my son. Building a brand-new mu*, with the responsibility that you have for starting it off 'right', can be tiring. Don't let yourself get tired, by not letting yourself try and do it all, the first day."

You say "Hence the title of the class: The first WEEK of a mu*."

Satyr nodnods. "That's been a big problem of mine - when I'm all alone one a MU*, or have a very small staff, I mentally tend to stress myself almost or right into burnout. 's tricky to avoid." :) And grins, and nods.

You say "IF you don't want the responsibility of the code, don't do any. Don't try and code things if it frustrates you. Conversely, if you would rather build just two rooms, and let someone run with it from there...okay. Focus on news files, code, hiring."

Moe irps. News files. Let me talk for a second on those.

You say "news files are important, and often get left until just before the game is going to open. And that becomes a bad thing, and here's why."

You say "I've tried to make a number of references to 'templates' for your staffers. This keeps them organized, focused, and in line with the theme of the game."

You say "The news files are a magnificent way to have a globally-available source of all your thoughts on how things 'should be'."

You say "If you wait until just before your game is going to open to write your news files, you wind up writing your news files to fit what has been done to your game, rather than building your game to fit what is in your news files."

You say "Any questions?"

You say "Comments?"

You say "recipes for banana bread?"

You say "Wait...not the last."

Quenton hands everyone recipies for banana Bread.

Satyr has nada. :)

You say "Ten minutes left."

Gandalf says "Why is that necessarily a Bad Thing(tm)?"

You say "It's your game. Therefore, your game should ultimately reflect your vision of it. If you write your news files to fit what everyone else has built/coded on your game, then it's somewhat like writing the manual by poking the buttons on the program, rather than deciding what the program is going to do, and building it from there."

You say "I don't say that /all/ news files need to be completed prior to game building."

Vadiv says "Wait, wait, you mean that's not how we're supposed to write manuals?"

You say "However, if you handle the major ones, like theme...(just a thought), /before/ you build your game, then staff have no excuse for not building in accordance with the theme."

Moe suggests it as a profitable alternative, Vadiv. :)

Brigid says "Maybe its just that news/theme/backgame has always been my main focus, but I cannot imagine that you could build/code without them being mostly finished first."

You say "Right. It's hard to code an econ system without knowing how the coinage is broken down in your IC society. You can't build geography or code weather for an area you don't know what it looks like, physically."

Brigid nodnods.

Quenton waves "I REALLY have to go..".."hopefully i'll have a chance to read the log on the site when its up."

Moe nods. Should be up tomorrow. After the class, I'm going to edit it first, and then go on the Wizard vs. Wizard Master Room hunt.

Gandalf knows lots of people who would beg to differ about that.

Quenton nods..and waves.

Quenton has disconnected.

You say "NO, I promise that I will edit the log, Gandalf. ;P"

Gandalf says "I'm not one of them, mind you, but there seems to be a prominent school of thought out there that Details Don't Matter."

Satyr snickers at Moe, and was just about to say..

Gandalf laughs, and didn't mean that.

Moe nods. This is true. And no offense to those that play and build the good versions of the games, but quite often in WoD, you lose details at the expense of...ambience.

Brigid won't even go into what 90% of WoD games are missing

Gandalf says "A clue. :)"

You say "The 'Oh We can Fix that Later' attitude is another personal favourite of mine."

You say "What do you /mean/ my 90-room area isn't connected to the rest of the grid?"

Brigid says "A question: How long do you think it should take from week 1 to opening to players? I have my own unpopular opinion of at minimum 6 months, but what do you think?"

Satyr says "Depends on the game. :-)"

Moe grins at Satyr, and will speak to that.

You say "Assuming that some work gets done everyday, you don't have an inordinate amount of staff turnover, and you are able to satisfy coding needs on at least a semi-regular basis, I say three months to have a working, though perhaps small, game. IC grid size is a big factor. Chicago started off with a large initial grid, so it took us about 9months to build. Shadow of Olympus started with a small grid, so once the building got started, it was up in about 3.5 months."

You say "any of the qualifications and disclaimers I listed above will affect opening time. You need to build a place to play, code commands that augment your IC environ, and ensure that you have people on hand that can administrate the game. Losing any one of those areas can add a month or more to build-time."

Satyr has seen good games set up in a matter of three - four weeks, simply because, well.. The game(s) was simple. No coding except Sandbox Globals, a small grid. The newsfiles usually took the longest to finishing. "Other games can take literally years to set up right, and they're worth every penny. It all depends on the game."

Moe nods to what Satyr said. SGP, The Mistress Project, the ChiaMUSH project I'm working on...they can all speed things up. Working a lot offline to do descs, newsfiles, mapping...that can speed things up.

Gandalf says "BBL"

Moe imagines that if you could get four uber-talented wizzes, one of which who was a psychocoder, and one or two roys, you could have a fully-working game in 4 weeks.

Nymeria needs to buy a few of those uber-talented people. ;)

You say "$299.95 + GST"

Brigid laughs and was assuming in her 6 month estimate staff problems of the usual variety, OR doing -everything- oneself.

Gandalf has disconnected.

You say "Doing everything oneself guarantees about a year, unless you can do it for 6 months without burnout."

Brigid nods, "Took about 8 months with me and my coder.

Brigid says "But I don't -try- to code, since I wreck more than I fix on average :)"

Moe laughs. Some people shouldn't code, and that's just the way it is.

You say "Some people shouldn't build."

You say "People have their strengths, and they should just go with them."

You say "Okay, any other questions?"

Satyr shakeshakes. :)

You say "Going once."

You say "Going twice."

You say "Gone. Log is off. Thank you all /very/ much for attending."