My favorite tricks for spicing up otherwise dull areas:

1. In large zones such as city streets, forest, desert, etc., create a base inheritable for all the common describes, zone designations, light levels, room chats, sounds, smells, including those things which change by night or day. I don't reuse room longs, but this helps me a lot for filler/atmosphere rooms and speeds up the qc process since I only have to correct spelling mistakes in one room rather than tracking down all the rooms where I misspelled part of the description for 'leaf/leaves'.

2. Create a base inheritable for monsters that share the same behaviors. They can still have their own unique fights, but I have used this technique to make them go home at night (or come out at night), stay within their districts if they wander, check the same array or add to the same array if they defend each other - or in one case, the array is read by the local law enforcement to see who's murdering town folk.

3. In the case of wandering 'average joe' city folk:
a. Create an array of first names and surnames so that these are randomly generated at creation, giving the illusion of the population being quite large since with a combination of 50 names in each of the arrays, the mix and match is quite varied. Sites such as can help get names filled out.

b. Create a mapping that chooses a trade, gender, size, parses a unique racial description and fleshes out what would normally be a boring city person.

c. For their treasure, make a similar object that randomly generates a type of armor a city person might wear - i.e. rough tunics, leggings, doublet, hose, etc. To reduce the object load, in their base inheritable, make it a chance and give coin half the time rather than an object. Not all of them are going to have usable items after all.

The previous thread had scrolled off the screen, but was still there. I was able to view it by adjusting my dates.

I pinned them both so that doesn't happen again.

I liked the thread, but in general it seemed to be a long discussion on writing descriptions rather than actual building. I (personally) never gave a hoot about descrips as a player and see it as a necessary evil for building. There was a really good (imo) post by erdos and it was unfortunate there wasn't more of that type. It focuses on coding/olc tricks rather than debating description quality.

Few tricks I've started doing myself:

There is always a hidden room players can't get to. This is a great place to run background stuff that players cannot ever mess with or interfere with.

All important fight progs now work outside pulse violence. Keeping it outside makes it a lot more "real" feeling, as well as making the actual pulse a lot less spammy. The system erdos described seemed a bit complex, I just utilize mob echo, trigger via act off that echo (in the hidden room) and then have a short delay before it heads over to do the fight prog. Obviously you need a few checks (like if players == 0, break in the room).

The entry idea was pretty nifty. My key mobs have predefined paths via mprog so I include the mob echos there. But for ones who just wander randomly, sneaking + entry mob echo seems like a really good idea and one that I'll utiilize more in the future.

Less on coding, but imo the most important part: know your niche you plan to fill going in. Why will people go to your area? What does it offer? Is it a leveling area? Is it an endgame area? Is it a quest style area? Is it a combination? What is "special" about this particular area? If you write the most immersive area on the planet but it fills no niche, then your average player won't even bother to go there.

Vilgan

hrmm maybe I was a bit harsh, when commenting on the last thread I didn't notice this thread was a lot better. Hopefully more ideas and concepts will be posted that all can benefit from.

Vilgan

An idea that might be of some help codewise, though it might be unnaplicable, is to create markers for the questions, so that the player could ask "what do you know about #Saran#?" or "do you recognize someone named #Saran#?" or anything like that. I don't know how could it be done code-wise, although it would be a great thing to add.

Just my thoughts.
Ruobhe

Angie: I always try to avoid entire phrases as keywords, so as not to limit the script too much. Unless of course the phrase is some kind of 'invocation', in which case I always make sure that the EXACT phrase is written down somewhere in the zone, (maybe on a paper that the absentminded mage put in a hidden drawer, to remember the wording himself). But otherwise I just use single keywords, and try to guess at things the player might say.  

In DG_scripts there is a very useful if-check:
if (%speech.contains(keyword)%

This enables you to use the same script for as many keywords as you like, meaning that you'll have one long script instead of several short ones.

Using the if-check you can for instance make the mob respond with the same phrase to the same keyword with and without questionmark:

if ((%speech.contains(john)%)||(%speech.contains(john ?)%)
 say whatever
endif

( The || sign stands for 'or' )

You can also make the same script respond to an infinite number of names or keywords, giving different responses to each name.

In some of our zones the heavily scripted quest mobs may answer to around 30 different names or words, sometimes giving random replies to the same name. This makes for a great variety, and also makes the mobs seem at least semi intelligent. You can actually engage in a conversation with some of them.

Usually it is set up so that one response from the mob would automatically lead to a new question from the player, and in this way they can work their way to a solution by just talking to a mob. In other cases the mobs are just set up to drop random hints, so that you may have to speak to 5 different mobs before you figure out what to do next. And in yet other cases the mob responses are just set up to add to the atmosphere of the zone, like citizens of a town exchanging idle gossip with a stranger.

It's always up to the player to decide what is useful information and what is not.

This thread has very interesting ideas.

I would like to ask about adding extra descriptions for example when you want the player to look at the sign I dont want to make an object to attract there attention but at the same time placing in the description "there is a sign here" erks me...

Often I think  I'll make the mob greet folks with.
Mob says "Look at that sign some one misspelt LOOK SING"

Maybe adding a greet program to the room with "The wind rattles the sign post" or even make it a random event?

Just wondering!

I need to specify a caveat with this suggestion - it is not appropriate in many cases.

Whne I have a cluttered room, one with many fixed objects, that need to be described as objects (the sign above), say a market square, I tend to make a signs objects, or a market stalls object, some object that can be representitive of many things at once.

In the market example, if there are 10 stalls around the square, it is messy to enter a room and see 10 different objects, if they are a point of interest, then they should possibly have individual descriptions, a well written main desc (for the stalls object) removes the clutter when just looking at the room, while the different extra descs can give the level of detail for each one of interest

I have a few tips for builders...

Having titles, exits and room descriptions together is fine but each should be on a new line.

-title
-exits
-description

- mobs in rooms.
- objects in rooms

-space before prompt

Some of this would pertain to the coder in a sense, but when it comes to the builders. Here are a couple tips.

1) room descriptions should never wrap by them selves. you should limit the length of each line.

2) mobprogs should not be so long that they wrap either. use extra emotes, pmotes or whatever as needed.

pmote says "How are you today?"
pmote says "Welcome to the realms of whatever. If you"
pmote says "need any help at any time, just ask on nchat"

There are allot of things that can be done to keep the in game design to a standard. Areas/Rooms that are hard to read can just be annoying. If you need ideas for colors, here is a base set that is getting popular.. I'm very partial to color and very picky so I know it's well liked..

Room titles in yellow
Exits just below titles, default white
Room Descriptions, default white
Mobiles in Rooms, Cyan
Objects in Room, Green

Says = green
tells - magneta
emote, pmote, echos, green
mobprog output, green

chat, cyan
nchat, cyan
eqlists, inventory ect, yellow/cyan

These are just ideas but when put together, make a nicely outputted format in regards to text and it's easy on the eyes. I used this for years and never once got a complaint on color. Also, As I mentioned, I'm very picky when it comes to this myself so these are just ideas..

Just some ideas,
Chris

I think it depends on your target audience. Personally, there isn't enough money in the world that would get me to play a game that forced colors by default. Spending hours UNdoing all that gobbledigook so it reads more like a book and less like a carnival marquis just isn't worth the effort to me.

Oh and yellow for room titles and exits on white would mean I wouldn't be able to read them at all. I like MY backgrounds to be white, or a very pale shade of grey. If I have to endure a black background I might as well just go back to using a teleprompt terminal from back in the days before Microsoft.

As a Smaug builder, I often see areas built using ORB. While this is a more efficient use of online time, I can often tell that ORB has been used because:
1. If there is an exit description, the room name of the room looked at will be on the same line:
>look east
A busy street awaits you.A City Street
2. Mobs with mob descriptions will have the health status attached to the description
>look guard
You don't want to mess with him!The city guard is in perfect health.
3. Quite often, the lines wrap one or two words for me since ORB seems to use a longer line length than my client.

Of course, many areas made through ORB don't have exit descs or mob descs so it won't show so much but this is dull.
>Look east
Nothing special there.
A City Street
>Look guard
You see nothing special about him.
The city guard is in perfect health.

My recommendation is to write the exit and mob descs and make sure the tildes are in place so that ORB can make the proper newlines.

Re: Builders' Tricks II
 

Harlequinesque color schemes are teh suck!

I like black and white as well .. but often struggle with it and find it monotonous. Guess everybody has a personal preference. If ansi, it should be one or two colors and not bright ones!

Re: Builders' Tricks II
 

The first things I ever built when on the staff of SoI was a series of rooms comprising part of a building in Osgiliath. In the description of the central room was mention of a mural on the wall. If one typed look mural they'd get a very generic description of it. If, however, they proceeded to other rooms that comprised the balcony, they would get a slightly different take on the mural and if they approached the south wall from one side of the balcony, they would see more detail including a reference to a feature of the mural. Looking at that feature would give a vague description as it was too far away to make out. But if you progressed to the other balcony across the room and looked at the mural, you could make it more clearly and looking at that feature would reveal what it read.

Long story short, it's up to the player to make what they will from a room description. I always put a bunch of them in every room I build. If the players don't bother to read it, that's their loss. The key is consistency though. If players discover that many rooms have embedded descriptions, they're more inclined to look for them. But if they're too rare, players will give up trying to find them and will miss those that you want them to see. In other words, don't do it half-arsed.

Take care,

Jason