-- BEGIN: What Not to Do... by China --
<Lecturer> China clears her throat. "ok... it's time for the first speaker in this hall. And since I'm it, I'll introduce myself. I'm China@M*U*S*H"
<Lecturer> China clears her throat, as she looks over her paper full of notes for a second, then says, "My topic is "What NOT to do when learning to SoftCode."
<Lecturer> China says, "It would seem the things I'm going to cover in my topic would be unnecessary to even mention, but I'm surprised in listening to the SoftCode Channel how many of them are done."
<Lecturer> China says, "First in making this list is, Don't ask a question on "how" until you've tried to do the code yourself first. UNLESS it's for the purpose of asking to be "pointed" in a starting direction.
<Lecturer> China says, "Nothing is more Twinky then to log on for the sole purpose of asking someone to "give you" the code to ...whatever, that they gave their blood, sweat, and tears to make."
<Lecturer> China says, "There are URL's, the code lab, and lectures to get you started on most anything your trying to do."
<Lecturer> China glances at her notes and continues, "Don't just try once, or twice, and figure "I tried, now, tell me how it's done." Work with the examples you find. They're a great source, even though most of them aren't "perfect" for what your doing, a lot of what they have is a good place to start to play with."
<Lecturer> China says, "And I do mean "PLAY WITH". I do know how engrossed one can get while working with a code and how frustrating it is when you spend hours and it still won't come out... and others are too busy to offer the help you "need" to solve your problem."
<Lecturer> China chuckles as she looks at the audience, "I've literally been frustrated to tears over some code I've spent a week or more on. Twisting it this way, turing it that way, and no way seems to work cause you just don't know what the heck your doing ...or why."
<Lecturer> China says, "SO ..cry! Throw something! ...er, not your pc I hope ...but let your frustrations out so you can get over it. Then tackle the problem when you feel better. Taking a break from it helps too, as time sometimes gives you some insite to something you might not have tried."
<Lecturer> China says, "Then again sometimes it don't."
<Lecturer> China glances at her notes, and then says, "So now, when you do ask, ask for where you might find information on what your stuck on trying to do."
<Lecturer> China says, "Again, no one is just waiting on here, with their code in their hand ready to hand it to YOU. They worked for their code. They put in the time, and paid their dues."
<Lecturer> China says, "Most here are willing to help point you in the right direction "to help you help yourself'. The thought is, if you work for it, you'll learn from that ...and remember."
<Lecturer> China clears her throat again, and says, "That does work for most I'm told. Don't for me. I know a bunch of ways now and most all don't work, and with so many now in my head I don't remember which ways do."
<Lecturer> China says, "SO? Write it down."
<Lecturer> China says, "I have to, as so many ways are now in my mind I can't keep any of them straight. But that's me ...but maybe you too. So write it down somewhere so you got "something" better to help you the next time you run into the same type code situation."
<Lecturer> China continues, "Also when you do ask, be aware that others are not here "just" to answer your questions, they're doing stuff too and are likely busy. At least assume they are."
<Lecturer> China says, "It's also very Twinky to ask and expect them to stumble all over themselves to hurry and answer. Or after a couple minutes with them not responding, to then log off."
<Lecturer> China says, "I've seen lots of times when the question was responded to after the person had left."
<Lecturer> China says, "So give them some time. Then give them some more ...before even thinking of asking again. Good lordy, notice some of the idle times. They "are" idle for reasons, some people have a real life out there."
<Lecturer> China says, "Now another thing done here, is folks usually don't respond when they don't know the answer. Some people think it's rude to not "say something" ...but think on this: it's twinky to do a 12 person, or so, spam of "I don't knows"."
<Lecturer> China says, "Better to be like a RL class room, when the teacher asks a question, you get responses just from the folks who "do" know. Also be aware that everyone on the channel isn't capable of giving answers, as code students are also there."
<Lecturer> China takes a second, then says, "Anyway, the productive way when you do ask ...ask for ideas and explain a bit on what you have tried. Then if you have your attemps handy on an object in here, set it visible OR just show the part of the code your having trouble with, WHEN ASKED."
<Lecturer> China says, "This is possible with your own attempts which you should have done before you asked."
<Lecturer> China says, "Now I know lots just log in and ask right off ...or quick slap up a short line of code and say, "Why don't this work?" and they get answered quickly with exactly what's wrong or even showed the correct version of what they should do."
<Lecturer> China says, "That's great when it happens. And it does at times. Just don't "expect" it."
<Lecturer> China says, "What you don't know is how much time the person already has spend on the code they're struggling with. This might be something they'd been on channel about at other times when you've not been logged in."
<Lecturer> China says, "Or perhaps, the person don't ask very often and others know them well enough from past experience that when they do ask, it's known they tried all the above mentioned options."
<Lecturer> China empathizes, "And the ONE thing that will turn those who would help you, off the quickest, is to bitch and complain about the lack of help your not getting."
<Lecturer> China says, "No one here is being paid to sit here and answer questions. They're here because they honestly wish to help you, in the best way they know how to do. And an expressed "Thank You" for the help you get, goes a long way."
<Lecturer> China glances at her notes again, and then says, "You will find with time, which people are better at explaining things in terms you understand best. When you do you might hold your questions until these people are online ..and hope they're unbusy enought to join in explaining the answer."
<Lecturer> China says, "And goodness gracious don't pester these people with pages to the point they start to log on hidden or put on a page lock to get a break from you. You just defeated your purpose if you do that."
<Lecturer> China says, "With time ..and getting to know people, and them getting to know you and what effort you put forth to learn, you build a rapport with those on SoftCode channel and as a good relationship develops help is easier to come because when you do ask, they "know" you've exhaused what knowledge, and places, and examples, and attemps you know to do"
<Lecturer> China smiles, "This is when you will most likely get that special "here is what you do" answer."
<Lecturer> China says, "Just remember in learning code, don't get discourage. It's not easy for some of us. Just keep trying and with each step you get closer to your goal."
<Lecturer> China says, "And on your way please remember to just be kind, and show consideration."
<Lecturer> China ends her lecture with another smile and says, "thank you for your time."
<Lecturer> China smiles, "are there any questions?
<Lecturer> China don't see any.
<Lecturer> China nods a smile.
<Lecturer> China goes down the few steps to the seating area.
	-- END: What Not to Do... by China --
	-- BEGIN: How to Make a Successful MUSH by Codex --
<Lecturer> China says, "I have the pleasure to introduce our next lecture. Making a Succesfull MUSH by Codex@ChibaCity. So without further ado, lets give a round of applause."
Arathas claps.
Trispis claps.
<Lecturer> China smiles and leaves.
<Lecturer> Codex steps up to the dais, sets up an old fashioned slide projector, turns it on, revealing the first slide, "Introduction"
<Lecturer> Codex says, "My name is Codex, as in Codex@ChibaCity and Michael@FadingSuns. I'm here to talk about creating a successful MUSH, and more specifically, organizing and planning for a successful MUSH. We all endeavor to have wonderful, fantastic, detailed, amazing worlds that will delight and entertain players for years. Here are some ideas for making that work. They certainly are not the only way to plan for a MUSH, and I wouldn't claim they were perfect ideas. :)"
<Lecturer> Codex clicks the remote, and the next slide "Planning for Success" pops up on the screen.
<Lecturer> Codex says, "Every great endeavor requires planning. And every successful great endeavor requires great planning. The most important thing for anyone who is creating a MUSH to do is to define their goals ahead of time. This becomes more important if your MUSH is going to be an RP MUSH with a definitive theme."
<Lecturer> Codex says, "If you are planning on having a successful MUSH, you must have a plan for a successful MUSH.
<Lecturer> Codex says, "The theme statement is the mantra, the guiding declaration of what you and your staff are trying to accomplish. The primary goals section elaborates on the objectives you are trying to achieve with your MUSH. The staffing outline is an attempt to foresee your administrative needs, both during the building phase and after you've opened. The timetable is like any military operation timetable: optimistic and unrealistic. :) The coding standards section hopefully makes it easier for coders to work together. A list of systems that need to be coded is essential to prioritizing and delegating coding work. And the list of play areas is essential to prioritizing the work of your builders."
<Lecturer> Codex says, "Let's look at some of the considerations when writing a design document:"
<Lecturer> Codex changes the slide, which now reads "What is the Mission?"
<Lecturer> Codex says, "I'm of the belief that the theme statement is the most important part of planning for a MUSH. If you can't decide what you are trying to accomplish, you probably won't accomplish anything. A theme statement should be at most a couple of sentences, but the shorter, clearer and more focused, the better."
<Lecturer> Codex says, "A theme statement for a MUSH is similar to the 'pitch' used by television producers selling shows to the network: 'Okay, this show is like Friends meets A-Team set in the Battlestar Galactica universe with lots of fighting.' For a MUSH, it would be something like: 'The XYZZY MUSH will capture the raw essence of discovery and problem solving in a subterranean setting with wit and style.'"
<Lecturer> Codex says, "Or in the case of Chiba City: 'Chiba City is a recreation of the influential science-fiction atmosphere of the works of William Gibson and Neal Stephenson, and gives players a chance to revel in a highly detailed, dynamic world that features key cyberpunk themes like cyberspace/net running, cybernetics and body alteration, information warfare, organized crime, corporate domination, new media (StimSim, Guerilla TV News), and urban sprawl and inner-city decay.'"
<Lecturer> Codex says, "So the purpose of a theme statement:
<Lecturer> Codex clicks the button, bringing up a new slide "MUSH Intelligence is not an Oxymoron"
<Lecturer> Codex says, "As you begin planning for your MUSH, you have to think about your options. What are your story options? What are your code options? What are your building options?"
<Lecturer> Codex says, "By story options, I mean how are you going to tell the story of your MUSH? For example, if you were going to build a Tolkien MUSH, are you going to deviate from the canonical timeline, or stick to it exactly. If you are going to create a completely new theme, how are you going to educate the players on your meticulously crafted background? Are you going to have a directed narrative or a free-form style of play? Will story arcs, tinyplots, and events be preplanned, spontaneous, or some sort combination of both?"
<Lecturer> Codex says, "These issues are important, because they can help you lay some important groundwork ahead of time. For example, if you intended to create a game set in the ancient Mediterranean, and had some definite story lines you wanted to include, you might want to have an Oracle as one of your coding and building goals, something that players could get relevant story information from if they made the proper sacrifice."
<Lecturer> Codex says, "By coding and building options, I mean knowing how you can use code and building techniques to accomplish your goals. For example, if you have a science fiction theme in mind, its good to identify early on the possible code options for space systems. For building, knowing how to fully utilize zones and parents can help simplify the building process. Where do you discover these options? On other MUSHes, of course! And while there are some sticklers out there, most MUSH admin will be happy to discuss, if not specifics, the general ways they use code and building options. M*U*S*H and its +softcode and +hardcode channels, is a great resource for any administrator."
<Lecturer> Codex clicks the remote, calling up a slide that reads "Identifying Your Goals"
<Lecturer> Codex says, "Once you know your options, its time to take apart your theme statement and establish some specific objectives for your MUSH. These objectives should be things that will be most important to the MUSH, the things that will help make it stand out in a sea of MUSHes. For each objective, you and your staff should write up the important details of that objective. They serve as the reference book for your staff, so they should be as detailed as possible and as necessary. The more information you can pack into these objective descriptions now, the fewer questions you'll have to answer later."
<Lecturer> Codex says, "For Chiba City, I identified 16 as primary goals, which include obvious goals like Focused RP and Atmosphere to specific things relating to the theme like Cyberspace, Artificial Intelligences, Corporate Domination and Cybernetics. As you can see from my design document, some of my objective descriptions are lengthy, and some are one sentence long."
<Lecturer> Codex clicks the remote again, and a new slide appears. "Creating a Framework"
<Lecturer> Codex says, "As you begin creating descriptions of your objectives, you are actually building the framework from whence your MUSH will rise. The design document is your blue print, and the more complete you can make it, the more efficient the efforts of everyone working on your MUSH will be."
<Lecturer> Codex says, "The more detailed your design document, the better. You can always change it after you've started the main work of building a MUSH, but you'll save time and energy if you work out the details of what you want to do before you start to do it. For example, if you want a coded combat system, knowing how it should work and look will impact how you create Character Generation code, inventory and vendors, and other systems. Knowing what kinds of IC groups you'll have for players can help guide you efficiently in writing backgrounds and building locations for those players, as well as direct some aspects of Character Generation. If you are working by yourself, this sort of planning can help you stay on track and focused."
<Lecturer> Codex says, "If you're already working with a team of people, you'll want to have some sort of review process for the framework you're creating. Better to hammer out agreements on your objectives now than when work has already begun. Nothing will tear apart a staff faster than unresolved differences of opinion on the best ways to achieve your goals or what your goals are! Also, be open to other ideas and criticisms. It can be trying to listen to someone come in and begin criticizing the months of work you've done. Sometimes, however, they may have valid critiques. And sometimes those people can become valued assets for your MUSH."
<Lecturer> Codex clicks one final time, forwarding the slide to "The More Things Change"
<Lecturer> Codex says, "Obviously, things change. You have to be flexible with your design document. You may find that some objectives are not feasible. Or you may come up with new objectives as you begin work. New people may bring with them new ideas or revisions of old ideas that are worth considering. That's certainly happened with Chiba City, where the time table is horribly out of whack, we've changed some of our goals for our Cyberspace, and I've added plans for allowing scientist characters to research new technology."
<Lecturer> Codex says, "The process of creating a wonderful, fantastic, detailed, amazing world is long and exhausting. Hopefully, some of these ideas will make it easier for you and your staff."
<Lecturer> Codex turns off the projector, turns up the lights, and says, "That's all I have for today. Does anyone have any questions or comments?"
Arathas claps.
Nymeria claps too, and now worries she'll be up all night considering a design document. "A really good approach, I have to say."
<Lecturer> Codex says, "Seeing no questions, I'll haul myself off to the next lecture. :)"
<Lecturer> Codex goes down the few steps to the seating area.
	-- END: How to Make a Successful MUSH by Codex --