[Molly]

I know it’s a popular misconception among some people – (perhaps mainly those who never tried to complete a zone on their own, or who never came in contact with a real quality zone) – that ‘anybody can be a Builder’.

Those of us, who are experienced as Builders, and who have seen lots of other Builders over the years, know that this is a debatable statement. Sure, any 12-year-old with English as their first language can learn to work with the OLC and produce some half-assed zone - (provided they have the patience to complete it, which few really have). But the difference between those average, cheap products and a really GOOD, fully developed, in-depth zone, produced by a skilled Builder who knows their business, is like the difference between night and day.

You could just as well state that ‘anybody can be a Coder’, because any 12 year old kid can download a codebase, compile it, change the colour of a few things and then claim it to be ‘heavily modified’. Skilled, creative, inventive Builders are just as scarce as the really imaginative and original Coders. God knows I’ve seen enough of wannabe Builders come and go in our Build Port over the years to know what I am talking about.

The last few years however, something rather encouraging happened. Somewhere along the road, we passed a turning point. And now - contrary to what I see stated on Staff Boards, that good and serious Builders are almost impossible to get by - we have several Senior Builders, producing new or updating old zones on a regular basis. And not only that - the quality of the new Builders on our Mud has risen dramatically. Even the first zone attempts, (which usually are not nearly up to a Builder’s full potential, for apparent reasons) are now way better than zones that we considered great 5 years ago.

I can see two possible explanations for this.
One is that we added a lot of extra options to the OLC, which gave us a wider range of opportunities to make the zones challenging and interesting. Possibly the Builders like that, and it spurs them to greater efforts. But on the other hand, the immediate effect is that it now takes twice as much work to finish a zone as before, if you take advantage of all the extras full out.

The other and perhaps more probable explanation is, that good Builders breed other good Builders. Builders learn from examples, and the better the examples the better they become. They look at each other’s zones, get input and new ideas, show each other some neat feature they invented. And they feed off each other’s ideas, so that the spin-off effect of one idea can be something related, but yet vastly different in the next zone, created by another Builder, using another angle of the same feature. And so it goes on, spiralling upwards...

So why do I tell you all this? Well, I have this idea, that maybe the positive spiral I described could be extended to other Muds, like rings on the water. I have been building for over six years myself, and picked up quite a few neat tricks on the way. And I know that some of the readers of this board are also very skilled and talented Builders, with equally long experience. And my thought was, that maybe if us old foxes shared some of our building tricks with those who yet have less experience, it might lead to an overall boost of the Building quality, in the same way that happened within my own Mud.

I have quite a few neat tricks of my own that I intend to share with you. Not in this post, since it is way too long already, and it’s also way too late in the night. But I’ll be beck tomorrow, with my first trick. And meanwhile I am hoping for some input from other Builders.

Maybe I’m being too optimistic about this. But hey – let’s at least give it a try!

[Pris]

Code for the highest common denominator.

There's a certain type of person that you're aiming to please. They're the kind of person who lies awake in bed thinking "I wonder what would happen if I tried this." They're the sort of person who spots connections. They'll see an opportunity to use one object in totally unrelated area on the other side of the mud. They'll track down what you think is the smallest, most minute detail, and worry at it until it makes sense in the grand scheme of things.
With that in mind, everything you add to your area should have a purpose and it should be possible for players to figure it all out without having to resort to reading the code. If you have a necklace with writing on it, make it possible for someone, somewhere, be able to read it. Don't just have a string saying: "You can not make out the words."
If you code for that person then every other style of player you get through it will also be catered for.

And don't write a forest area. Coming up with enough unique descriptions for a bunch of trees will drive you insane.

Yours,
Pris

[markizs]

Well there is simple rule. before starting to code area you plan it. first plan overall layout, then make good map with all rooms, dont make first area bigger than 50 rooms. then plan what quests/puzzles you are going to ahve. then think of decent and balanced rewards for those. then think of monsters, how big/small they should be.
Then start actual buildiing, and if you have neat new idea while coding but its not in your plan, better keep it for next area. if you dont you can keep adding new and new features all the time. i have seen areas beein in building for 3-4 years only becouse of new features added constantly. 1 year is more than enough.

and dont write forest area. making descs for it will be pain in the ass. and i bet there are plenty of those around already, better make acid desert or magical island made of honey :)

[jornel]

Thanks to Molly for starting what I hope will be a very interesting and valuable thread for all of us to read.  But firstly, speaking as a Major Druidic Deity , I must take strong exception to Pris's admonishment against writing forest areas; in our world we have several different forests and believe me, they are in no way repetitive or dull!

I would instead suggest that what he really meant to say was that builders should not create a series of repetitive room descriptions (mazes notwithstanding), concering topics that they have too few concrete ideas.  No one will enjoy reading descriptions when even the author finds them too dull to read.  Focus on your strengths, write what you have strong passions about, and let someone else do justice to the parts of the world outside your ken.

Anyway, here's my little builder's tip I'd like to pass on:

Avoid having your areas filled with lifeless mobs that either just stand around waiting to be killed, or silently and pointlessly wander from room to room.  Even if your mobs are meant to be killed - THINK about them - they have a life, they are going about their business doing SOMETHING before the player comes along and splats them.

So use mprogs to give your mobs random actions, but don't just limit them to a single action; that gets way too dull, way too fast.  I put a minimum of 3 single-line actions per mob.  For example a speaking mob might have 2 phrases and an emote (pose or action).  On a non-speaking animal, it might be 2 purposeful emotes and 1 reactive emote.  If you have more ideas, don't limit yourself to 3!  Mix them up and keep the frequency very low so it doesn't get spammy, and your area will begin to feel like it has living, breathing, viable creatures in it.

Its very realistic for players who are slowly exploring new areas reading descriptions, that an occasional creature might wander through doing whatever it is that it does, at its own pace, undemanding any immediate reaction from the player.

And THAT is what life in a forest should be like.  

[Quicksilver]

Expand your possibilities.
Extended descriptions are the lifes blood of the hard core player. Yes, we know they help flesh out a room, give it the most detail, etc.
But, you can use this as a goad to the lesser inclined players. Standard Rom has only 6 exits, N S E W U & D. Others have added the diagonals as well.  You can combine extended descriptions and portals to create "hidden" entrances. Make sure you provide enough details to point them at the name of the portal, and that the descriptions themselves make it clear that the "detail" is enterable.  And, if your mud allows invisible room descriptions on objects, it will be hidden from all but the most discerning players, won't be visible on exit lists and also won't appear with faerie fog or other such spells, as it isn't really invisible or "secret".

Then you can create enterable paintings, mirrors, even the dark alleyway which sits out of the way, but remains invisible, not because it cannot be seen, but because most people haven't looked closer.

--QS

[Sanvean]

I'd add these:

1) Invoke more than one sense. Don't just provide the look, tell the reader what it smells and feels and sounds like as well.

2) Use language to reinforce feeling. Short and simple words will create a vastly different feel than long, polysyllabic latinate words. Want the constant whisper of the wind on those plains heard? Try to convey in sweeping sibilants used in describing the rustle and murmur.

3) God is in the details. Make it so you can look at things and interact with them. I'm working on an area right now where I'm trying to make sure every room is all it should be, including edescs, smell descriptions, scripts, etc. It's slow but I'm really looking forward to unveiling it sometime in the next year.

4) Use the right word, and look it up if you're not totally sure what it means.

[Estarra]

What a great discussion! I don't know where to begin so I'll just share the building guidelines I came up with (and had input from others) for new builders. And can I hear a halleluiah on the forests?!

BUILDING GUIDELINES

Five Simple Do's:

1. Do use all six senses. If you have a mental block and are stuck writing a description, ask yourself how your six senses may react. Of course, you don't want to always include all six senses in every description, but asking yourself the questions may help the creative process. What does it smell like (pleasant or reeking)? What does it taste like (not a common sense except for food)? Are there any sounds (background noise or ominous silence)? What does it look like (colour, size, scope)? What does it feel like (texture, maybe viscosity)? What psychic impressions are felt (foreboding, delight, queasiness, etc.)? Psychic impressions (the "sixth" sense) should be used sparingly.

2. Do use present tense. There's very little reason not to use present tense when writing descriptions.

3. Do use dynamic verbs. Verbs are the workhorse of a sentence so when appropriate try to use dynamic verbs. For example:

Weak

The large mansion is on the hill. Rose bushes are growing in loamy soil
under the windows. There is a little path that leads to the backyard.

Dynamic

The large mansion rises up upon the hill. Rose bushes push up from the
loamy soil beneath the windows. A little path stretches around the mansion
towards the backyard.

4. Do use proper grammar. Though it should go without saying, send your mind back to Mrs. Grundy's bonehead English class and avoid run on sentences, incomplete sentences, awkward wording, etc.

5. Do ALWAYS use complete sentences. This seems like it would fall under grammar, but it is singularly important on its own. A nymph stretches out here, quietly singing to herself. Her damp hair against her body. That second sentence is a VERY common mistake in both room descs and mobile descs. It is not a complete sentence. Why? If I said to you 'Her damp hair against her body' on its own, you would have no idea what I was talking about.


Seven Simple Don’ts:

1. Don't double space between sentences. Those who have worked in an office environment tend to double space between sentences. However, what looks snappy and professional on a business letter looks awkward on a MUD.

2. Don't let Microsoft Word help you. This goes for any word processing program that has an auto-formatting feature that turns everything you type into smart quotes, automatically double spaces, changes ordinals to superscript, etc. Find this feature and turn it off.

3. Don't use "seems to" or "looks like" or "appears to be". This is a common mistake that strikes even the very best and experienced builder. Feel free to use metaphors and simile, but using the phrases "seems", "looks like", and "appears to be" weakens the impact. If the man appears to be the oldest man in the village, then chances are the man is the oldest man in the village. Ninety-nine percent of the time, it can be avoided. For example,

Weak

This troll appears to be the largest of its kind. Its skin seems to be an almost
phosphorescent green and its large fangs looks like it could tear through not
only skin but bone.

Dynamic

The troll is enormous, the largest of its kind. Its skin glows an almost
phosphorescent green and its large fangs could tear through not only skin
but bone.

4. Don't reference the player in a room. Try to avoid using "you" or "your" as little as possible, preferably not at all. Generally, avoid referencing the player in the description. Instead of telling a player directly what he or she is looking at, the impact is greater and illusion less intrusive when descriptions lay before the player what is seen in the third person.

5. Don't describe objects or mobs that can be placed in the room. If the chef is in the kitchen, don't write up the chef in the room description. Rather, create a chef mob and place him in the room. Important objects should also be a separately created item, like the large monolith crackling with energy should probably be a separate object rather than merely described in the room description.

6. Don't reference history in a room. There is no way you can tell by looking at a room that it was built by an ancient group of flesh-eating wizards, known for their purple robes, who scared the natives. This is maybe the only time you can use seems: 'The hall is in shambles, covered with dust and debris of decades past. Indeed, it seems as if a war had happened here, waged on the walls itself.' if its a war-ravaged castle. You can say some things about origins, but there's a definite point of too much.

7. Don't overwrite. First, for reasons of spammy room descs. Most people don't really read the descs but skim them. You don't want to fill out every single detail down to its tile pattern, curtain texture, and the exact location of the desk, table, and three upholestered chairs; however, these little details can help beef up a sparse description for a boring hallway.

Seems everyone is replying mostly with things that would fit in better in a thread titled "Elements of style for writing room descriptions" than one titled "Builder's tricks". Before becoming a coder I myself ascended OLC and mastered it and bent it to my will, utterly. Unfortunately, the entirety of my OLC experience is with SMAUG 1.4a codebase, so this may not apply everywhere, but here are some tricks I devised in those days.......

...give mobs fight progs which transcend pulse_violence, so that they go off "in between rounds". This is rather complicated to pull off. It involves having a bunch of utility mobs in a utility room start fighting eachother when the players attack the main mob. These utility mobs are made invincible, but are all given spec_poison. As they poison eachother, the poison echo triggers a prog that causes the main mob to do "fight progs". The reason this works is because spec_functions are called in a different routine than pulse_violence, and so they transcend the combat roudns (thus the reason mobs with spec_functions seem to get extra attacks all the time) [If any old DSFT players are reading this who fought King Gallant... now you know how he did it!]

...give mobs artificial memory by having them drop utility items in a utility room. They can later try picking these back up, and then using ifchecks to see if they have them in their inventory.... in this way, in one of my very first areas I created a village of dwarves who were peaceful by default but all became aggro as soon as you attacked any one of them

...When I was a clan deity on DSFTales, (a good MUD which lacked any coder whatsoever), as a gift I created a locker room for the clan--- without any locker room snippets whatsoever! I kid you not. It is possible to do entirely with stock SMAUG OLC; it involves a tremendously complicated process of invoking containers, mposet'ing their keywords so that, for instance, Joe's container will have "Joe_" as one keyword... then when the player says "unlock", a mobinvis mob tries to unlock "$n_", then invokes a utility item and tries to put it in "$n_", then checks to see if the item is still in inventory... if so, then $n apparently doesn't have a locker, and an echo is sent accordingly. Else, $n evidently DOES have a locker, so take the item back out and purge it and echo to the effect of "your locker swings open". Of course all this must take place in the clan's store room since stock SMAUG only allows 1 saveroom per clan...

A simple but beautiful trick: combine the "eatkey" exit flag and an "unlocks" act prog for some key-destroying fun! "You unlock the door. *Click* Suddenly the key explodes in your hand! That really did HURT!"

Another simple and amusing thing: create a weapon that does, say, 1d200 damage, but at the same time casts 'heal' to recover 100hp... so that, essentially, its damage ranges from 100 to -99 (HEALING 99hp!) [Be warned though, this sword becomes overpowered in nonmagic rooms:(

For pure eye candy: if a mob moves about but is restricted to a reasonably small space, make it sneak but give it entry progs which check where it came from and where it is now and thereby essentially give it its own unique entrance echoes, including direction. ("You feel a certain turbulence in the water. Suddenly a beautiful dragon turtle swims in from the west")

A trick almost certain to be SMAUG only: exploiting SMAUG's ability to have multiple exits in the same direction, go wild with secret hidden keywordless exits in a maze to make "track" go totally bonkers. Mazemastering fun for the whole family!

A more convenient but more restricted trick can be used to give mobs artificial memory, and that is to have them mpmset some useless stat of theirs and then use ifchecks to check what it's set to. Charisma is a good one to use. Remember that mobs with the prototype flag can't mpmset themself so take that off before testing. Anyway, this is most useful for making mobs who rotate their stats around in battle and "remember" what they're currently at. For example, to make a mob who switches from immune cold/suscept fire to immune fire/suscept cold, you'd make the mob start with 15 CHA and immune cold/suscept fire by default; then as a fight prog the mob checks to see if his own CHA is 15. If so, use mpmset to change the immunities and susceptibilities, and change CHA to 16. But else, do the reverse. Remember the "barrier changing" monsters in FFIII? :-)

A neat mob I made on DSFT was a wizard who wore an amulet of eternal life. As long as the amulet remained intact, every round he would heal himself fully with mprestore. In order to kill him, the players had to fight him (and endure his breath attacks!) until the amulet got scrapped.

Well, I could go on like this for a long time, if I had a long time to waste. But you know what they say about giving a man a fish..... Anyway, most building tricks can be done with code much easier and what's more, doing it with code means MUCH more efficient use of resources. For example the mobmemory code I wrote for Aethar was probably 1000+ times more efficient with both RAM and CPU time than dropping utility items in a utility room. If you really want to devise profound building tricks, two things are needed: first, the Muse must bless you with great imagination; and secondly, you must be head builder for years on a MUD which has absolutely no coders.

I was working on an area when Aethar shut its doors, and I propose it as a challenge for those among you who are both builder and coder in one (for this area would require much ingenuity in both areas). The area is in essence the opening scene from the movie "The Two Towers": a long solo fight in free-fall (with specially coded "slowfall" rooms where you fall indefinitely, but with a moment between each room rather than all at once)

[Molly]

WORK WITH YOUR CODER, TO EXPAND YOUR OPTIONS :

A lot of things can be added to the OLC, to make the zones more varied and fun, and to give the Builders a much larger set of tools to work with.

These additions are usually quite simple codewise. When I ask our Coder for a new feature to be added to the OLC, he usually produces the addition in a few minutes.

Quicksilver already mentioned the hidden Portals, and the opportunities they offer for creating exits that are really ‘secret’. Any Twink can learn to type SEARCH (or whatever command you have for hidden exits) a few times in each room, while only the good players read descriptions. Unfortunately any TWINK can also learn to type GET ALL, and this simple command would expose the portal in stock code, with the message: ‘A portal: You can’t get that!’
So don't forhet to ask your Coder to add a HIDDEN Flag to the OLC, and to make it so that it also eliminates the blank line you otherwise get when making an ‘invisible’ object using the color code. Only then are your invisible objects really invisible.

In our Mud we went one step further with the portals. We’ve made four different Portal Types; Room, Hole, Bush and Water, all with different messages to actor and room. This is of course mainly cosmetic, but it looks a lot nicer if you see ‘Actor dives into the water. Splash!’ instead of plain ‘Actor enters the water’. Or ‘You squeeze through the bush, thorns scratching your arms.’

The next thing we added was CLIMB, DESCEND and JUMP Objects, which also are Portals, but with different messages and commands. So now we can climb rocks, descend stairs or jump ravines. These things may or may not show up as objects in the room, dependant on how obvious you want the exit to be. A funny addition to our Jump Objects is that if you are riding, you have to first order your horse to jump the obstacle. Otherwise the mount just refuses, and you fly over the hurdle on your own, landing quite painfully on the ground on the other side.

Next we added LISTEN, SMELL, TASTE, FEEL descs for rooms and objects, and the option to look BEHIND, ABOVE and UNDER objects. All these are just extra descs. Mainly they add some flavour and atmosphere to the rooms and objects, but they are also great for Quest info, especially combined with hidden portals or containers.
Now you can enter a room, where a large bed stands against the off wall. ’Look bed’ tells you that the bedspread hangs all the way down to the floor, ‘Look under bed’ reveals a chamber pot, and ‘look in pot’ shows the key that someone accidentally dropped there. Much neater than just planting the key on a mob, as is usually done.

We also added several new sectors; for instance DESERT (where the hot sun damages you during daytime), UNDERWATER (where you drown within a few second unless you use a waterlung) and SPACE (where you die almost instantaneously without a spacesuit and also are unable to move around much without using a spaceship).

The drawback with these otherwise neat additions is of course that the already existing zones lack them, and have to be updated manually. We still have about 50 of the oldest zones that need to be updated to the new code, which is a boring and rather thankless job. But mercifully there sometimes are shortcuts. For instance our Coder just added Mob Classes, meaning that our Mobs now are a lot more intelligent and use different fighting methods, dependant on Class. So our Mage mobs now cast various spells on you, and even occasionally summon their own minions to help them in the fight. When I grumbled a bit to him about all the extra work this created for me, he obligingly supplied a script, which in one split second set the new abilities on all mobs with the word ‘mage’, ‘magician’ ‘sorcerer’ or ‘witch’ in the alias list. Then he went on doing similar things for the other Mob classes. This may not have caught all of them, but I bet it caught about 90 %, because we use multiple aliases a lot – which is another good habit a Builder should adopt.

Erdos is quite right that many things are easier made in code than scripts. Builders and Coders also tend to think differently, and produce very different solutions to the same problem, because they attack it from different angles. But it is when a Coder and Builder work closely together, that the best solutions come up. So, work WITH your Coder - that usually produces the best results.

[Hephos]

Originally Posted by The next thing we added was CLIMB, DESCEND and JUMP Objects, which also are Portals, but with different messages and commands. So now we can climb rocks, descend stairs or jump ravines. These things may or may not show up as objects in the room, dependant on how obvious you want the exit to be. A funny addition to our Jump Objects is that if you are riding, you have to first order your horse to jump the obstacle. Otherwise the mount just refuses, and you fly over the hurdle on your own, landing quite painfully on the ground on the other side.

Hmm this type of feature is better implmemented IMO with a "real" system. Ie, you build a shaft, ravine, or stair with rooms having special flags. And then you can use commands like climb, jump etc in connection with that.

For example imagine a shaft that is 5 rooms high. You start at the bottom and "climb" your way up using a climb skill. If you loose your grip and fall (no floor in these rooms) you fall down through the rooms eventually hitting a room with ground, and taking damage based on the speed you have accumulated during the fall.

Much more fun. (We use this system at Sharune btw).

[the_logos]

Originally Posted by (Molly O'Hara @ Oct. 16 2003,17:41) Quicksilver already mentioned the hidden Portals, and the opportunities they offer for creating exits that are really ‘secret’. Any Twink can learn to type SEARCH (or whatever command you have for hidden exits) a few times in each room, while only the good players read descriptions.

Of course, any twink can just read the room descriptions as well. Reading the room descriptions doesn't make a player a good player. It just makes a player someone who reads room descriptions. Most players read far less than 10% of room descriptions.

--matt

[Delerak]

Originally Posted by Of course, any twink can just read the room descriptions as well. Reading the room descriptions doesn't make a player a good player. It just makes a player someone who reads room descriptions. Most players read far less than 10% of room descriptions. --matt

Where? Achaea? Or do you have numbers, files, and questionnaires from players of muds whether they read the room descriptions or not? It's not really possible to determine who reads them and who doesn't it depends wholly on the person. Whether they LIKE reading, or not is the first, and hopefully they od or the paradox of them mudding and not liking to read is pretty ironic. Either way, it also depends on the mud, on a hack n slash mud like yours, matt, I would say you are absolutely right that 10% of your players don't read the descriptions, on a RPI mud that doesn't have a huge playerbase but has intelligent, sharp-minded people who do read in the real world, probably 80-90% of their players do.

-Delerak

Originally Posted by (Delerak @ Oct. 16 2003,20:00) (SNIP)...on a hack n slash mud like yours, matt, I would say you are absolutely right that 10% of your players don't read the descriptions,  on a RPI mud that doesn't have a huge playerbase but has intelligent, sharp-minded people who do read in the real world, probably 80-90% of their players do.

Wow, so on a hack-n-slash, 90% of people read roomdescriptions, but in an RPI mud it can be as few as 80%? Who would've thought.
Another example of those profoundly learned RPers sharing their deep insights and ancient wisdom!

[the_logos]

Originally Posted by (Delerak @ Oct. 16 2003,20:00) Where? Achaea? Or do you have numbers, files, and questionnaires from players of muds whether they read the room descriptions or not?  It's not really possible to determine who reads them and who doesn't it depends wholly on the person.  Whether they LIKE reading, or not is the first, and hopefully they od or the paradox of them mudding and not liking to read is pretty ironic.  Either way, it also depends on the mud, on a hack n slash mud like yours, matt, I would say you are absolutely right that 10% of your players don't read the descriptions,  on a RPI mud that doesn't have a huge playerbase but has intelligent, sharp-minded people who do read in the real world, probably 80-90% of their players do.   -Delerak

On an RPI mud, perhaps 90% do, I have no idea. RPI players represent a tiny fraction of mud players, however. My 10% number is purely a guess based on watching countless newbies in our games and other games where I was an admin before starting our games.

And if you seriously think that intelligent and sharp-minded tie directly to "read descriptions", well, that's your problem I guess. Personally, I rarely read room descriptions because I don't care what that section of highway, that section of field, that section of forest look like in particular. Key rooms I'm always interested in reading but, like most players, I've got no interest in reading yet-another-description-of-a-forest-room.
--matt

[the_logos]

Originally Posted by (erdos @ Oct. 16 2003,23:51) Wow, so on a hack-n-slash, 90% of people read roomdescriptions, but in an RPI mud it can be as few as 80%?  Who would've thought. Another example of those profoundly learned RPers sharing their deep insights and ancient wisdom!

Those figures are crap anyway. We're never going to prove it but I have a seriously hard time believing that more than an extremely minor percentage of player of -any- type of mud reads all 10 or 20,000 room descriptions that they might encounter.

The irritating thing to me, as a developer, is that generally the room title is enough to evoke what you're trying to evoke but the descriptions have to be there cause SOME people are going to read each description and they're going to expect that they're there.

[the_logos]

Originally Posted by (Delerak @ Oct. 16 2003,20:00) Whether they LIKE reading, or not is the first, and hopefully they od or the paradox of them mudding and not liking to read is pretty ironic.

Sorry about the multiple responses. I couldn't let this pass though upon re-reading it.

I quite like to read. However, if Lord of the Rings was full of paragraph-long descriptions of every single section of landscape that Frodo went through I think I'd throw the book in the garbage. Because muds aren't experienced linearly like a book is though, and because you never know WHICH descriptions players will read, you do have to have them all there. But to expect all your players to read them all just says to me that a developer is designing for himself rather than for the players -- a trait rightly considered to be the sign of an immature designer. Goes hand in hand with a desire to "beat" the players rather than provide them with meaningful challenges that they can feel good about overcoming.

The fact is, almost nobody wants to read endless descriptions of a forest or an ocean. You can quibble with me if you like because I know that you're mainly concerned with arguing rather than truth, but that's just the way people are.

Rule of thumb: Try to design for the way players play, not the way you think they should play.

--matt

[Pris]

Wow, we got through an entire page a notes before it decended into a flame war and a series of bickering, petty debates. Personal best, team. Stand up and take a bow
I didn't realise that there was actually a difference between builder and coder (on AA the work isn't seperated like that, I don't really understand a lot of what you guys are describing I guess it's just a matter of different code bases) but in general the suggestions make sense for any mud.
I was going to suggest stuff like; make heavy use of baserooms to make describing all the nouns in a description easier and take at least a minimal interest in coding even if the builders on your mud don't need to know it at all. (From what I can gather it seems some people write all the descriptions and others: the coders, stick them into game mechanics, is that right?) Taking an interest in coding and reading through the code for the base objects of the mud and how combat works and such WILL give you massive amounts of information to help feed your imagination. It will help you.

Btw, I code/build for a describe all hack-'n-slash mud. 'Describe all' means that every single noun in every long description in an area needs to be examinable, touchable, tastable, smellable, listenable to and they must be allowed to 'attempt' to 'get' it (although you don't always have to allow them to get it, the noget must be logical). Attempts to climb any trees described must be catered for, players must be allowed to at least try and swim in/drink from pools of water or any other logical thing they may try and do with anything you describe in the room. We don't do it because we EXPECT everyone to do it. We do it because one person out of one thousand might try it. We do it because when we were players we wanted to try and do it.
Nobody is going to read endless descriptions of forest and ocean because those aren't areas. Those are the spaces that seperate areas. Areas are held to a higher standard than general map rooms and I believe that it is that higher standard that the builders tricks section is trying to concentrate on.
Yours,
Pris

[markizs]

Hmm. there is lot of builder tricks mentioned that relies on specific codebase, and well...sometimes those discusions about hidden portals or monsters who can actualy do some extra attacks sounds funny to builders who build in lpmuds. well maybe there are some more general tricks that could be usable by all kinds of muds? dont get too technical. first few notes were ok but then it got too codebase dependant. write somthing everyone could use :)

[the_logos]

Originally Posted by (Pris @ Oct. 17 2003,03:00) Nobody is going to read endless descriptions of forest and ocean because those aren't areas. Those are the spaces that seperate areas. Areas are held to a higher standard than general map rooms and I believe that it is that higher standard that the builders tricks section is trying to concentrate on.

Interesting discrepancy in our approaches. One isn't necessarily better than the other, but what we tried to do in Achaea, initially at least, is treat every part of Sapience as an area. Not that every part has the same density of mobs or quests (or content generally) but try not to build the world with "area vs. filler" distinction. We were eventually forced to abandon that but abandoned it by sticking in an overlaid grid map system to create distance between the main continent and more remote areas.

Ideally I would have liked to have not had to use the generated grid map approach as I think it's inferior to hand-built content but creating similar senses of distance with handbuilt areas is just so incredibly inefficient. My breaking point was spending a couple days building a 100 room area of grasslands that are part of a few areas leading up to the great unexplored north and realizing that I was adding only, at best, about 9 rooms to a player's journey to get across it due to the diameter.

Anyway, I completely agree that there's a huge difference between "areas of interest" and the rest of the world. If an area is interesting and packed with content I'm definitely willing to read and pay attention to the descriptions.

--matt

--matt

[Molly]

Originally Posted by dont get too technical. first few notes were ok but then it got too codebase dependant. write somthing everyone could use

I am afraid that most examples of Builder tricks will have to be at least partly based on specific codebases, Markizs, because that is what the tricks really are. We manipulate the codebase to get an effect, that the average player wouldn’t expect.

The inventive players, the one that like to read, examine, test, experiment, fiddle with the objects, climb things – (the ones I call the ‘good’ players) - are the ones that will cherish those little extras. The rest, which of course are in majority, will just play the mud like any hack’n’slash. But the beauty is that it works for both types. It just gives the smart ones a bit of an advantage – and the Mud an extra dimension.

Just reading descriptions obviously doesn’t make you a good player. It’s how you handle the information you get from reading that determines if you are good or not.

That, at least, is general in all codebases. The examples, I’m afraid, will have to be at least partly code related. But most muds are based on different Diku derivates, and at least those are pretty similar. And if enough Builders from different codebases share their ideas, there should be something in it for everybody. Just skip the parts of the discussion that doesn’t relate to the code you are working in yourself. And maybe it would be a good idea if we all stated our codebases. Mine is Circle, heavily modified.

I’ll be back later with more examples. Hopefully this thread, that started so promisingly, will be back on track then too. Try to look at this in a positive spirit. We are trying to help each other, remember?

[markizs]

Originally Posted by That, at least, is general in all codebases. The examples, I’m afraid, will have to be at least partly code related. But most muds are based on different Diku derivates, and at least those are pretty similar. And if enough Builders from different codebases share their ideas, there should be something in it for everybody. Just skip the parts of the discussion that doesn’t relate to the code you are working in yourself. And maybe it would be a good idea if we all stated our codebases. Mine is Circle, heavily modified.

well thats the problem. our mud iz lpmud and cos that lots of things that is considered tricks are very common in lpc. ofc there can be opposite too, like things u cant make in lpmud but they can be very easy in diku derivatis. maybe. i dont know :)

Originally Posted by The inventive players, the one that like to read, examine, test, experiment, fiddle with the objects, climb things – (the ones I call the ‘good’ players) - are the ones that will cherish those little extras. The rest, which of course are in majority, will just play the mud like any hack’n’slash. But the beauty is that it works for both types. It just gives the smart ones a bit of an advantage – and the Mud an extra dimension.

well that is only possible kind of players for us, those hack n slashers prolly get bored and leave veyr soon, becouse you cant advance levels until you complete quests in our mud, and quests are filled with things u need to fiddle and experiment with. well maybe thats why we dont have huge amount of players. dunno. but those who stay, stay for years :)

so what i meant for more non-technical things is: like what is best size of area, what is easiest way to make area enjoyable, eg what is middle way between having almost no desc or having every thing examinable in every room and every thing pullable climbable and pushable :)
and maybe - what is best way to kick yourself out of lazyness and finish those areas in time. maybe there is a way to somehow motivate yourself better? i sometimes got problem with that ;)

[Hephos]

Originally Posted by well that is only possible kind of players for us, those hack n slashers prolly get bored and leave veyr soon, becouse you cant advance levels until you complete quests in our mud, and quests are filled with things u need to fiddle and experiment with. well maybe thats why we dont have huge amount of players. dunno. but those who stay, stay for years :)

What can they do when they have done all your quests? Do you have anything to entertain the "top" players that have gone through every part of your game? If not, try fiddle up something fun for them to spend their time with :) Doing all the quests over again might not be a very attractive option :p

[shadowfyr]

Originally Posted by (Hephos @ Oct. 16 2003,17:49) Originally Posted by The next thing we added was CLIMB, DESCEND and JUMP Objects, which also are Portals, but with different messages and commands. So now we can climb rocks, descend stairs or jump ravines. These things may or may not show up as objects in the room, dependant on how obvious you want the exit to be. A funny addition to our Jump Objects is that if you are riding, you have to first order your horse to jump the obstacle. Otherwise the mount just refuses, and you fly over the hurdle on your own, landing quite painfully on the ground on the other side. Hmm this type of feature is better implmemented IMO with a "real" system. Ie, you build a shaft, ravine, or stair with rooms having special flags. And then you can use commands like climb, jump etc in connection with that. For example imagine a shaft that is 5 rooms high. You start at the bottom and "climb" your way up using a climb skill. If you loose your grip and fall (no floor in these rooms) you fall down through the rooms eventually hitting a room with ground, and taking damage based on the speed you have accumulated during the fall. Much more fun. (We use this system at Sharune btw).

My own thoughts on this was to check to see if the players remembered to attach a rope or the like. If they did, then all rooms exits are available. Otherwise no exits are shown and an item is added to their inventory. This item is responsible for 'moving' the player object down each room and since it can track how many rooms they have fallen past, it can shorten the time available to attempt to grab the ledge or the like. Since the idea was to make it an infinite fall, where they 'fall' past the same 3-4 rooms each time, damage result from failed attempts, success will slow them down, but not stop the fall, unless they are slow enough to dive towards the opening. If they manage that, it could either seriously hurt, or even kill the player.

Now put a mob that follows you around, is aggro and which may chase an unprepared player into the drop... Bwahahaha!

The advantage of this method is that you can literally have 3-4 players stuck falling in the drop and passing each other as they try to get out, as well as dropping out of sync, so they may not stay in a room long enough to discuss how to rescue themselves.

[Sanvean]

I tend to prefer areas that are detailed, because I think they are part of the overall story, and tell the player something as well as providing atmosphere. There's a lot of good writing that I feel is part of our game's experience.  We tend to put the most detail in places that people use a lot: the Main Bazaar in Allanak, the Trader's Inn and other bars, busy streets, etc.

I'll throw out some things that we've used to add more details to the world, in the hopes that they might spark ideas for other people:

Individual tracking messages, as well as specialized items "skinned" from mobs, which can be set by race, or by npc. Mount animations as well as the ability to give your mount a name to distinguish it from all the other mottled purplish kanks in the world

Animation echoes that go off randomly - generally I try to err on the side of too slow rather than
too fast on these, because spammy, repetitive mob progs are one of my pet peeves. Some busy rooms have these as well as a few less habited places.

Weather messages and equipment status changing as a result - getting sweaty or dusty from travel, bloody from combat, etc.

Molly includes about a bajillion good ideas - we added various taste/scent/eat messages to Arm and they're fun. Players have enjoyed supplying a lot of them. We also began using dawn/dusk/assorted time checks to echo something to the room

We added a lot of sectors and the objects for which you can search on them vary according to the type of sector: one set for heavy forest, another for silt shallows. You can forage for roots/stones/salt/artifacts. Sector can also affect messages/effects from magick spells, travel messages. etc.

Scripts, scripts and more scripts for items and npcs, including things like:
being able to break bottles and turn them into weapons
being able to battle to be the Giant's Fist Champion of Allanak
the ability to seal a scroll with a signet ring
ability to have pepper-eating contests
npcs that walk regular patrols
Scripts can be written and tested by any staff member and we include web utilities for uploading/downloading them, which encourages people to do a lot of these. I have seen some just plain amazing scripts since we added the javascript capability.

Tattoos and scars that can be gained through the course of play and which can be set on individual NPCs, as well as a talk program that allows builders to set npcs to respond to keywords.

examples of animated npcs:
a snake charmer who dances with her snakes, which are objects that are referenced by her emotes and says
various dancers and jugglers throughout the game
npcs who react to specific events

We are roleplay required - so  for most of the players, roleplay comes first and foremost, -  they want that atmosphere, that richness of detail, that helps them live the story - it's a vital part for them.

[Ogma]

A lot of tricks for LPMUD's depend heavily on your mudlib. On the other hand, it's much easier to add a feature to rooms in LPC than it is in a Dikurivative.

I'll give you one tip though, Markisz, that will go a long way to improving any area: use proper and grammatical English, or whichever language your mud uses.

[Molly]

Here’s something simple for all codebases. MAZES. Most players hate them, but we all use them, to add some space between other zones, and also to torment them a bit. But not all new Builders know how to make a Maze right, so here is a crash course:

Basically there are two types of mazes, linear or grids, representing the winding tunnels in a Dungeon or a seemingly endless prairie or forest. Mostly they are created in the same simple way, by linking the rooms back in circles, and here’s where inexperienced Builders quite often go wrong.

Linking in circles is fine, unless you do it on a straight line with too short distance between the back-linked rooms. The minimum distance is the number of rooms you can see other chars in, when looking in a direction. Otherwise you are going to see yourself, and that immediately gives the trick away. So the smallest functional maze you can make is 4 rooms, linked in a square, like this

ab
cd

To make a maze out of this you just need to link a to d both north and west, and then link the three other rooms after the same principle. Even a mini maze like this can keep some players running around in circles for ages, but of course the more rooms you use, the harder it gets. And the room descs don’t HAVE to be all similar either, even though that’s the most common. A maze can be just as confusing - and a lot more interesting - with individual descs.

We have a 100 room desert, that is a grid maze, where the rooms are all individual. The desert has a definite topography with ridges, depressions and a couple of waterholes, and because of the circle linking it gets repetitive in a certain rhythm, but basically you can wander around there forever. The desert code makes it a nasty place, where you mostly need to find some shadow during daytime, and move only at night. And it has had several players begging to be let out, because the exit is quite hard to find, and we made the entire zone !recall, !teleport and !summon-out too.

The exit from a maze is of course the funny thing to make. It can be something as simple as a closed or hidden door, but it can also be something subtler, like an invisible portal or some mob letting you out in return for a favour. Or it can be a nasty trick. Below is an example of the latter. (This maze is in our Mud School, so I am not giving any big secrets away).

----
Before they enter the Maze, the player gets the following information:
‘When you go east from this room, you'll enter a maze. It is not very large, but it can still be pretty confusing. The rooms look all the same, so it will be a bit hard to figure out where you are. The Quest is simply to find the way out of the maze. Apart from the obvious solution of just going DOWN to Recall and dropping out, of course. *snicker*’

The maze itself is only 6 rooms, linked after the principle in the example above, and each room looks like this:

In A Large Forest [ Exits: n e s w d ]
The forest is large, the trees tower above your head. Very little light penetrates through the dense foliage, not even in the middle of the day. Although there is no undergrowth blocking the view, this forest is still confusing, since every direction looks the same. The ground is covered with sparse grass, and there are several rabbit holes here, so watch your step. Occasionally you catch a glimpse of one of these cotton-tails, scampering away at the sound of your footsteps.

You can go in all cardinal directions in all rooms. Looking in any direction gives the same info: ‘All directions look the same in this forest.’

Looking up, only shows the sky above, so that is no option. Climbing the trees doesn’t work either.
Looking down gives this info: ‘A small rabbit hole leads down.’ And also shows up the usual lazy crowd of players squatting at Recall.

There are no hidden doors or portals anywhere. So how do you get out?

Easy. You go down.

One of the six rooms is different, the exit down leads to an extra room, which in turns leads down to Recall. The attentive player would notice this because of the message about the players down there. Instead of ‘You see Soandso immediately to the down’, in one of the rooms it will say ‘close by to the down’ instead.

But since this Maze is in the Mud School, we want to teach the new players to use the not-so-common options LISTEN and SMELL, and therefor we put the main clue there. So in 5 of the rooms you get the Listen message ‘You hear the wind in the crowns of the trees’ while in the room with the exit you get ‘A rustling sound is coming from the rabbit hole below. Wow, that hole is really uncommonly big!’


That's one if the things you can use the extra descs for.

----
On a side note:
There are some coded or scripted ways to make mazes too, and at least one of them is downloadable from the net. Exits get opened and shut randomly as the zone resets, so it’s never quite the same. But I really don’t like those options myself. To me it makes sense that once you have mapped a maze, you should be able to follow the same path next time you enter it. We do have one Maze however, which is scripted to give an individual path for each player who makes it through. For each individual player the path is always the same, but no two players get the same route. This was made to stop the blabbering among some players who told each other the directions, and was of course very effective. But it also took a pretty long and complicated script to set it up, and even though I am fond of scripts, I prefer things to be simple.

[Estarra]

One of my favorite mazes that I created was a mysterious town that would trap unwary players. What I did was create two identical towns. One town was a ghost town, apparently devoid of life. The other was brimming with life (mobs) who mysteriously had never heard of the wider world around them.

Players enter the "ghost" town and upon entering any of the buildings would actually be entering the "trapped" town (through one way exits). Of course players had no way of knowing they were entering a different area since they looked identical. However, they soon realize that the town is suddenly filled with citizens. However, all roads that lead out of the "trapped" town lead back in. The trick is finding the one exit in the "trapped" town that leads back to the "ghost" town, and staying on the roads to exit out (as entering a building would put them back into the "trapped" town).

This is a rather insidious maze and most players will never figure it out. (Thinking about it, I'm not sure if it even qualifies as a "maze" but it's a neat builders trick anyway.) I've found that those who do figure it out guard the secret proprietarily (probably because of all the hours of trial and error it takes to crack the puzzle). Also, I should point out that since it is so difficult, it should be put in a place where newbies can't get to and the players who do have the connections to call for help from other players to get summoned out. Even so, some will still wander in then call on the gods for help to get out of this "impossible" place. Muhahahaha!

[Fharron]

Another way to do a scripted maze is to dispense with the notion that players can solve the maze by finding a room path.

Create a scripted object with a value, and have movement – enter room – update this value via room scripts. Another way would be to set the value to the player instead of using an object. Moving north = +3, south = -3, east = +2, west = -1, up = +1, down = -1.  As the player moves the value is changed and when it reaches a specified value the object transports the player out of the maze. The formula can be made as mathematically complex as the builder wishes, for example north = x2, south = reset to 0 and so on.

In this way the players aren’t attempting to find a specified path they are trying to attain a pre-defined number. Obviously they need some help in doing this, so it is necessary to scatter clues throughout the maze, such as room extra descriptions that provide details of the various movement affects. The strange scratches upon the north wall form an identifiable pattern,  + 1. If you wish to add a random element then you can simply make the value for the object random with each load.

A second trick is to create two virtually identical mazes, but with something different in the second. Perhaps a disguised exit, perhaps a mobile, perhaps an object. Within the first maze is something that permits transference to the second and obviously within the second is something that returns the player to the first. It is an extension of the looped maze principle on a grander scale. From the players perspective they are in a single maze but in reality they are being transferred between two mazes, or more.

Both of these maze variants can be extremely taxing on the trial and error type of players, they could easily wander forever. However, with room extra clues or mob given clues – things players need to look for, their solutions can be fairly straight forward and simple. The hallmark of a good maze is when a player wanders aimlessly for ages, getting more and more frustrated, and then when they find the solution their first groaning thought is – #### that was so simple to solve.

[Iluvatar]

I really hate coming into good conversations late but oh well, I sort of feel obligated since it's this forum.


Esterra

Originally Posted by What does it feel like (texture, maybe viscosity)? What psychic impressions are felt (foreboding, delight, queasiness, etc.)? Psychic impressions (the "sixth" sense) should be used sparingly.

Sparingly is too simplistic here.  We can't predict how they'll feel unless they've chosen the activity.  A good example is fear, how do you "force" a feeling of fear on anyone using text.  Few react in expected ways so it's best to stay away from "forced" feelings unless as a direct result of their actions.
Most of your recommendations are seriously valid and I applaud them for what it's worth.

Molly

Originally Posted by A lot of things can be added to the OLC, to make the zones more varied and fun, and to give the Builders a much larger set of tools to work with.

Unfortunately that's a double edged sword.  It's wonderful to supremely enhance olc options but it also makes teaching a newbie extremely difficult and time intensive for seniors.  I personally prefer the olc as intricate as possible but I have to point out the shortcoming.

Molly

Originally Posted by Erdos is quite right that many things are easier made in code than scripts. Builders and Coders also tend to think differently, and produce very different solutions to the same problem, because they attack it from different angles. But it is when a Coder and Builder work closely together, that the best solutions come up. So, work WITH your Coder - that usually produces the best results.

Oh sooOOoo true!  Even if you have a chain of command so to speak, working with someone to make new things possible is expected of a builder.  Builders work the interactive aspects, coders make it possible and a meeting of the minds is the only way to enable this.  I would suggest also that this process include multiple functions for the same code.  An example would be something like <stay_terrain> which forces a mob keep to specific types of terrain which really decreases the ability to find a fish swimming about in a city terrain but also eliminates <stay_zone> and the necessity for <!mob> blocks.

Hephos

Originally Posted by Quote   The next thing we added was CLIMB, DESCEND and JUMP Objects, which also are Portals, but with different messages and commands. So now we can climb rocks, descend stairs or jump ravines. These things may or may not show up as objects in the room, dependant on how obvious you want the exit to be. A funny addition to our Jump Objects is that if you are riding, you have to first order your horse to jump the obstacle. Otherwise the mount just refuses, and you fly over the hurdle on your own, landing quite painfully on the ground on the other side. Hmm this type of feature is better implmemented IMO with a "real" system. Ie, you build a shaft, ravine, or stair with rooms having special flags. And then you can use commands like climb, jump etc in connection with that.

Pardon, but that IS a real system.  The level of complexity of context is how you discern a 'good' construct as opposed to a 'passable' one.  The more you can put into it, the more your players actually 'feel' it exists and can get into the roleplay.

the_logos

Originally Posted by And if you seriously think that intelligent and sharp-minded tie directly to "read descriptions", well, that's your problem I guess. Personally, I rarely read room descriptions because I don't care what that section of highway, that section of field, that section of forest look like in particular.

While I do agree the "intelligent and sharp" turn on <brief> when going over often trod landscape, it's exactly those types we cater to when we write descriptions.  The more intensely designed the area, the more often they actually read everything.  You seem to be making a presumption that connecting areas are immaterial and that's dangerous and unrewarding in a well built world from a player perspective.

Hephos

Originally Posted by The fact is, almost nobody wants to read endless descriptions of a forest or an ocean. You can quibble with me if you like because I know that you're mainly concerned with arguing rather than truth, but that's just the way people are.

Exactly, so you answered the age old debate of should duplicate rooms exist or automagically code created rooms exist.  I know it's tedious, I know it's unrealistic, but I also know of you really want people to READ, you gotta do it.  A plethora of inane dupes breeds briefers and that voids the whole purpose of having competent builders.  I recognize the disclaimer you posted afterwards showing the difference between *filler* vs *activity_zones*  but my statement still applies.

*pant* sorry I'm so long winded guys, but this overall topic is important to me and I was dumb enough to jump in late.

Molly

Originally Posted by I am afraid that most examples of Builder tricks will have to be at least partly based on specific codebases, Markizs, because that is what the tricks really are. We manipulate the codebase to get an effect, that the average player wouldn’t expect.

Isn't the issue more the idea itself?  I mean regardless of what codebase you use, the idea of something like timed teleport battle mobs replaced by duplicates or composite mobs with invisible body parts that battle are just good ideas.  It's up to each individual's coder ability to enable the concepts as they envision it, but the ideas are sound and why this forum exists.

Well, too much posting in one response for the likes of my ancient buns.  Perhaps I've learned my lesson and will check this place daily, but only time will tell.

[Hephos]

Originally Posted by Hephos Quote   The fact is, almost nobody wants to read endless descriptions of a forest or an ocean. You can quibble with me if you like because I know that you're mainly concerned with arguing rather than truth, but that's just the way people are. Exactly, so you answered the age old debate of should duplicate rooms exist or automagically code created rooms exist.  I know it's tedious, I know it's unrealistic, but I also know of you really want people to READ, you gotta do it.  A plethora of inane dupes breeds briefers and that voids the whole purpose of having competent builders.  I recognize the disclaimer you posted afterwards showing the difference between *filler* vs *activity_zones*  but my statement still applies. *pant* sorry I'm so long winded guys, but this overall topic is important to me and I was dumb enough to jump in late.

Hey i didnt post that. Someone else posted that...