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

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 :)

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

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.

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)

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.

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).

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

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!

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

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.

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

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 :)

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

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?

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 :)

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 ;)

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

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.

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.

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.

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!

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.

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


Esterra

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

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

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

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

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

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

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.

I may be in the minority, but personally I enjoy reading feelings or "vibes" in a room and haven't had any complaints (what I call the "psychic" sense). For example, you walk into a sacrificial pit for a dark god and read as part of the description "Despair and fear vibrate in the air." I've never heard of anyone feeling "forced" by this. Or even: "The statue of the ancient god makes even the most hardened heart flutter at the majesty." (Note: I don't mean things like "You walk into the room and feel fear." I never use the first person.)

In any event, I've heard arguments about never forcing the players what to feel (though I could indeed force them by progging a fear affliction upon entering the room, but that's another story). But, in my opinion, this view taken too far leads to missing out on some descriptive fluorishes which enhance the atmosphere of areas.

there is one very good salution for those kinds of problems.
to make puzzle little different for different players, turn theyr name into ASCII values, sum them up, and then split players into groups using those sums. then when player enters maze you check his ascii sum, and provide exits depneing on group he is in. if there is like 10 groups players will never figure out where is the difference that splits players :)

How can something be much more one-of-a-kind? Either something is unique or it is not unique.

Nah, it's not having duplicate descs that breeds 'briefers', it's having a lot of rooms with no important or pertinent information. It doesn't matter how good a writer you may be; if I'm just trying to travel through a forest, I am not going to stop to check the shimmering morning dew upon the leaves every time I pass through. When travelling or hunting for opponents, all the extra descriptive text becomes background noise and the player often chooses to get rid of it, looking for the signal, which is usually the room name and the exit list, plus any objects or creatures in the room. For this reason, standard Dikus should probably stick to very short descriptions except in important rooms, so that players know when they're seeing something significant. In more advanced muds, you might have a level of detail system that reveals more information about a room the longer you stand there.

Whats wrong with making important things stick out as actual items for once?

You see: A large tree.

While you are at it, why not have some sort of analyze command...

>analyze tree
You see a tree
You can push it
You can climb it
It looks like you can burn it

Heck, whats wrong with making mobs you can analyze?

>analyze jewler
he appears to be looking for an item
he wants to talk about beer

snicker

I'd prefer that players have to figure out what to do with the tree rather than having an analyze command that tells you all possible manipulations. What if you have to thump the tree to make a bird egg drop to the ground that's needed for a quest? I'd prefer players figure that out for themselves or find clues rather than just having them analyze a tree and get a message "You can thump it."

Ugh. I think its much more interesting to interact with a mob to find out his motivations or any quest. Wouldn't this be more fun:

>greet jeweler
Jeweler says, "Hello, mate! Hey have you seen a mug around with a picture of a big ole moose on it?"
>say what about the mug?
Jeweler says, "My moose mug? It's my favorite drinking mug! Beer seems to taste better in it. If you've seen it, I'll pay ye for bringing it back to me.
>say so you like beer?
Jeweler says, "Beer! It's my favorite beverage. If you find my moose mug, I'll pay you for bringing it back, but I'll pay you even more if its filled with beer!

That is exactly my point.. thump tree? What if I tried kicking the tree, punching the tree, hitting the tree with a sword, running into it with a jeep, grabing a bull dozer and smashing it, shooting peas at it... or ####, climibing it and grabing the egg myself.

...gave up and quit your mud cause of all the possible commands I didn't try thump? I knew there was an egg.. I wanted it so I could get my +3 sword to go kill someone.

Not everyone really cares and wants to read, examine, try every possible thing on every mob/item/hint in a room description in the entire world.

thats all makes game way too easy. way too fast for players to explore and master in all ways.
and important things as actual items makes it even simpler. we use that approach only in newbie areas. and analyse command....sounds like it would ruin all the fun of mud. and you would need extreamly large mud world to keep players busy with such analyse feature.

Nice assumption.

I mean really. I want nothing more than to sit around all day being kept busy. Real fun.

You can ignore me on this, but you are ignroing the opinion of a huge amount of mud players.

There are tons of ways you can make quests interesting besides making players brute force 1000 commands to get something to simply interact.

Furthermore, tons of power players like me already have a set of macros which will make 95% of items in most muds do something. And we solve all your quests very quickly, part of playing these types of games over 10 years.

so you assume that 95% of items in most muds are similar? holly smoke. sounds liek you have played some very crapy and stocky muds out there :) come to our mud and solve all quests then. we got only 25 quests or so. but they take #### lot of a time to do :) and not by 1000 stupid command syou need to find out. you need to explore, search and then interract with lots of mobs. and sure, there are no 'annalyse' commands. and our mud isnt like 100% rp enforced. more like hack and slash with forced questing :)

Fair enough. Though perhaps there is a crazy elf that wanders the forest muttering, "When you thump. Thump. Thump. The egg makes a bump. Bump. Bump." Anyway, there could be clues on what to do somewhere.

In any event, these types of quests are generally puzzles or mysteries that are meant for those who enjoy figuring out puzzles or mysteries to solve. If you are not a player who enjoys solving puzzles then of course this type of quest isn't for you. But to make all quests a walkthrough would turn off those who appreciate a challenge.

"Guess the verb" games aren't fun and they aren't hard. They're tedious and are poor design.

--matt

In my experience players that think that quests are solved by "guess the verb" are poor players.

As Estarra pointed out, there is usually a clue about what to do somewhere. The players that don’t bother to look for clues resort to tedious, mechanic and brainless actions, like typing in 1000 random commands. It’s their own fault if that gets boring, and perhaps that type of players should stick to pure hack’n’slash instead.

Of course, if there ISN’T a clue hidden somewhere, THEN it’s poor design.

Also, some things are just logical and don't need clues. For instance, if you read as part of a room description, "there is a crank sticking out of the wall", it's a good bet that you should turn the crank and not sit on it. If you read a box description and see "a lever juts out of the top of the box", chances are you should pull or push the lever and not suck on it. Even something more obscure like "there is a twig stuck between the cracks" may need to be twisted out (which I think is fair game to have the players puzzle it out, though maybe some sort of hint that they're on the right track if they try to pull it--"You pull on the twig but it stubbornly won't budge, though it wiggles a little.").

Two ideas from my own building experience…

1. Build into a zone and its back story the ability for change. Some of the exits are blocked off by boulders that the cave trolls pushed there to turn the caves into a maze to confuse the jackalmen who also live there? Well, make a set of Jackelmen mobs as well, and once in a while, switch the mobs that load, open some exits and close off others. This could reinvent the area for people to visit, and has the added benifit of messing up all those silly people who build macros to fastwalk to an area on the other said of said caves.

2. At DF we employ “Room swaps”, which started out as a way to get bored builders to do some work. Two builders will agree to swap a certain amount of rooms, usually 3-5. They meet, explain the type of rooms they want, then go at it. They have to finish the swapped rooms that same evening. The thing is, when someone else comes into your zone knowing they only have to describe five rooms, they pay more attention to the surroundings and to details. When you go back and see what they did, sometimes you’re disappointed, but many of our builders have said they get new ideas from what the other builder wrote.

Hope those are on topic...