THE AREA REVIEW PROCESS I. background A. How areas get made at Castle Arcanum. B. Some comments about why we do area reviews. C. What to do when your area is done. II. brief description of the review process A. preliminary review 1. reviewer goes through and looks at the overall quality of the first 5-10 rooms a. are the room and mob descriptions engaging and intriguing? b. are there relatively few spelling grammar errors? c. does it look like the builder took a conscious effort to check the area before submitting it for review? d. does the area reflect the theme/philosophy of the mud? e. is the recommended level of the area one that is needed on the mud? i. if not, builder may be asked to change it to fill a level void. f. the reviewer decides whether it needs more work or decides to do a full review. 2. what happens if it doesn't get past the preliminary review? a. major work probably needs to be done to the area b. work on it some more, and when you think it could pass the full review, submit it again. B. room/roomprogs C. mobs/mobprogs D. objects/obprogs/resets E. playtest III. what is looked at in room review A. room name 1. spelling/grammar errors 2. sums up the room description well B. room description 1. spelling/grammar/logical errors a. spelling and grammar are easy b. logical errors when it says something that isn't possible 2. stylistic errors. (mention hya's builder tips) a. does it tell the reader how they feel? that's bad b. does it give one sided descriptions based on entry direction? also bad c. is the description of the room just there to take up space? d. avoid static weather/time descriptions (use good judgement at least) 3. do interesting things in the description have extra descriptions? or objects to coincide with them? C. room stats 1. check the sector,flags, make sure they fit the room 2. check all of the extra descriptions listed for spelling and grammar 3. check the exits to make sure the door names and door extra descriptions fit and check for grammar/spelling/logical errors. D. rprogs 1. make a note of what the prog does (especially what objects it loads) 2. does the prog work? 3. is the mud overly complex or not well thought out? a. some progs will work perfectly in the way they were designed to work but what happens when you use it in a way it wasn't designed to work? 4. consider how the prog will affect the game world a. would the prog give all players in the game an overly great advantage? b. would the prog give just certain players an unfair advantage? c. does the prog fit the theme/philosophy of the mud? 5. this is a subjective process but common sense and careful consideration by the builder can significantly improve the speed at which an area is approved. IV. what is looked at in mob review A. mob name, short name, and long name 1. does the mob name include the key words from the short name and long name? 2. is everything spelled correctly/consistently B. mob description 1. spelling/grammar/logical/stylistic errors. 2. avoid telling what you feel when you look at them. 3. if you mention objects prominently in the mob description try to have that prominent item in their inventory (use your best judgement.) 4. even if its not an important mob to your story, it doesn't mean it doesn't deserve a good description. C. mprogs (left off here february 1st, 2000) 1. what does the prog do? 2. does it work? 3. how does it affect the game world 4. refer them to the criteria for rprogs. V. what is looked at in the resets/object/oprog review? A. Go through each room seeing what resets where. 1. does the object reset correctly? B. check each item listed in the resets of each room 1. do the short and long descriptions work together? 2. are the key words listed in the short and long descriptions in the object's name? 3. do the wear locations of the object fit the object? 4. is the item something that shouldn't be taken? and is it takeable? 5. flags. a. if the flag has a timer, is the timer set? b. if the item is invisible, is it reasonable for it to be invisible? C. object balance 1. Why worry about object balance? a. everyone wants to have people use the items from their area b. if every new area includes items more useful than previously available then the game becomes easier, which makes the time to level change for the levels where those items are available. i. time to level should remain constant why? ii. if certain items make levelling easier at certain levels then it is not fair to players at other levels. iii. if sufficient items are added to make levelling easier at all levels, then the game loses its challenge. iv. there are 101 levels of mortality and then we run out of game material, so in the interest of keeping players we want to balance the time on average it takes for them to level, while trying to avoid frustration on the player's part. c. if you make an item you want people to use it, and if someone else makes an item that is better than your item you might be dissapointed when people start using the new item and you're contribution goes unused. i. so... we try to use a fair system to make sure that no item on the mud overshadows another item to the point of making it useless. 2. What is the system we use to insure object balance? Why, the Lok Balance System of course. a. What is the Lok Balance system? i. a way of measuring the power of items and placing it in a context of the difficulty of getting that item. ii. tell 'em where to find the lok balance guide (or append it) b. Problems with the Lok Balance system. i. damage undervalued for our mud. ii. that means we may ask you to lower the damage of your items even though they are legal according to the lok balance table. 3. Using the Lok Balance guide a. Concepts used in pricing items i. The lok balance guide sets the cost of items according to how hard they are to get and the penalties associated with using the item, he explains it well so use it. ii. "comprehensive" lok balance cost: there are some items that no matter what the penalties associated with them are, are going to be so good that players will take that special effort to get them, because it would be foolish not too. For these items we calculate the power of the item and compare it to its level without taking into account the difficulty of getting the item. iii. the "lb c" command. our mud has a command for builders, the "lb c" command. syntax "lb c (itemname)" which calculates the most common lok balance costs into the item and returns a number that the builder can compare to the item's level. It is not an all inclusive command however, and does not take into account things like the spells cast by an item, or the number of charges it has or the weight. b. For regular items... go by the guide, and adhere to it as strictly as you can make yourself adhere to it. c. For special items... some items you will want to be better than just your run of the mill everday items, try to keep these limited in quantity in you're area and cap their comprehensive lok value at no more than 2.8 times the level of the item. (and even then we'll probably argue about it) d. For quest items... keep it limited to no more than one quest item for the area, and cap the comprehensive lok value at no more than 3.3 times the level of the item. e. staves, wands. avoid the temptation to put lots of charges on staves and wands 10 or less for mundane spells like infravision, or see invisible, and under 6 for popular spells like sanctuary or heal. There are bad examples on Arcanum and at some point those items will hopefully be powered down. D. oprogs 1. what does the prog do? 2. does it work? 3. how does it affect the game world? 4. refer them to the criteria for rprogs. E. follow up on resets 1. After going through every room and checking the resets to see what objects and mobs repop where, you will often notice that there are some objects and mobs in the area that do not reset anywhere. Find out what it is for. a. is the object or mob that doesn't reset loaded by an rprog, mprog, or oprog? b. if it is not loaded by a prog and not loaded by a reset, then find out if the item or mob is supposed to be in the area or if it can be removed. VI. What is looked at in the playtest phase? A. the reviewer creates a character of the appropriate level and sets its stats so that it will be useful in testing the area. B. the reviewer goes through the area, to get a feel for how the whole thing "feels" 1. looks for the same things as they looked for in the preliminary review 2. does the area flow together nicely? 3. if there is a quest: a. are there enough clues to get the person started on the quest? b. is the quest solvable? are there enough clues to be able to figure it out? c. is the quest too easy? d. is the quest fair, or does it make unreasonable demands on the player? e. how easy would it be to mess up in the quest to the point of not being able to get back on it? and if it's possible for that to happen, fix it. f. is the quest repeatable? and if so, would the quest prize unbalance the game if it is obtainable multiple times? if so, fix it. VII. most common problems A. overpowered items 1. people often don't realize that the items they are making are more powerful than other items on the mud. 2. it may be helpful to compare you're items with the items that most people wear at the level of your area and do a comparison. And make sure they are not more powerful than those items (and don't just compare to those few items that are obviously overpowered.) B. colorful items, mobs, rooms 1. avoid color in items, mobs, and rooms unless it is vital to the story/theme of the area. 2. this reviewer's opinion is that color should be reserved for renamed and special items, so that those renamed and special items remain special. 3. having said that, here's the compromise... a. don't use color on items that a player can add to their inventory or eq. (just keep it to items that can not be taken like furniture) b. if you use color, use color from the very beginning of each string in which that color is used, so as to avoid ugly schemes, for people whose mud client or color settings are set differently than yours. ie... olc command in the object editor: short ^ya ^Yyellow^y item^x c. make sure you add a ^x to the end of strings with color to help prevent color bleeding. C. overly complex mob/ob/room progs 1. Excited builder's are often intrigued by the possibilities that progs offer them. This can yield some pretty exciting stuff, but more often than not, the builder attempts to do more than they are capable of pulling off well, and end up with a prog or series of progs that can cause abuse problems from clever players, or result in quests that people get off track on and can't get back on track. 2. in general, before submitting an area, or before creating a mob prog, consider whether the prog is absolutely necessary to the area. If it is, then by all means proceed, otherwise, scrap it in favor of the less exciting, but more stable alternatives. 3. avoid overusing permanent mpcalcs on players. As mpcalcs are 32 bits and can be broken up into smaller bits of information, there really is no reason to use more than one mpcalc in an area. Temporary mpcalcs on players are fine however. For more information, consult Gomez's mob prog documents. D. uninspired room descriptions 1. You know how it is, you've just done thirtysome fantastic room descriptions and now you are spent, and you just wanna finish the area and submit it for review. 2. Well, I can sympathize, but rooms shouldn't be there just to take up space, either remove those areas and make your area pack a smaller but more professional punch, or take the time to spruce up those bland descriptions. E. weak story/quest 1. Sometimes people make their area first, and then decide to put a quest into it. 2. Make sure the quest is interesting and not just tacked on because you think your area would be better with a quest, or because you want a reason to have that sword of multiple dragon slaying allowed in your area.