> Brett C Helgeson <bhelgeson@csc.Cornell-Iowa.edu> writes... > > Just some things that someone might find usefull...: >** When making areas, make monster "chutes" Its a room with one way exits > in all directions. > The idea is that monsters leave in random directions.. Yeah, this is something that occured to me a while back as well: having 'monster lairs', rooms that PCs cannot access that have multiple exits to various places in the world - occasionally through multiple other rooms (a virtual maze, even!) to control the rough probability of the MOB making it through to a specific room. I had planned on using this for Isha at one point, so she'd "issue forth" at a random location in the forest or in the drow area (visiting family, I geuss ;) > >** By having monsters at different positions when loaded, an aggressive mob > won't attack if its sitting down. If its default is standing, it will > wander around looking for things to kill... Huh.. I'm a bit baffled by this one; 'won't attack if its sitting down'? Either I've forgotten something or you meant 'won't WANDER'...correct me if I'm wrong... >** Careful placement of no_mob bits in areas can make good effects by > seperating mobs from one another. Works good if you want to have a > psuedo underwater area, and keep the aquatic mobs in the water, without > giving them a new zone. It works the other way around too... Yeah, this is good... nice as a diagonal line across 'matrixed' areas. I personally think 'NO_MOB' *door flags* would be a god's gift to fancy area designing (short of using Silly code, with teleport rooms - Ahh, *those* have wonderful (underused ;) potential...but I'm rambling!) and MOB_ONLY doors, which wouldn't show up on 'exits' and which would possibly allow for a special string (given with the room in the .wld file) which would be printed when a MOB when through it, basically allowing MOBs to flee out of the PCs reach (like bird people flying into the trees, where either they are safe or at least the players would have find the 'tree trunk' room to get into the tree and find the proper branch, thus giving the impression that the MOBs could fly without making them wear 'magic' wings (not a good Object use, IMO)) and adding some challenge for the players. > >** By giving important mobs a spec_procedure, even if it is just blabbing, > makes them seem more alive: For example in the lair of the Goblin King, > the king rants and raves while calling for his guards, food, telling the > pc's hes gonna rip their heads off etc. Its a simple thing to do as well Simple... mmmm maybe not... The main problem with spec_procs is that they must be coded - which requires coders. Alot of area builders are NOT coders... and you've got to deal with debugging someone else's code, etc.. As I have posted before, I've never worked with the MERC code MOBprogs but such triggers and such really seemed like a nice addition to areas without requiring detailed C knowledge. >** By creating a 'Buffer' zone between a high level zone and a lower level > zone, you save potential problems by saving hapless newbies from certain > death, it also gives a better 'feel', since there is a something else > instead of Mnts, then a forest, for example.. It can be as big or as small > as you want it to be, even devoid of mobs, but maybe there is a spring or > an old fountain with magical properties, or whatever you want... In the final version of the world that I'm working towards most low level areas will be to the west of town, making it easier for newbies to simply stay in that direction to find appropriate lev areas. Some mid- range things will be north and close to the east, etc. >** Just some things I had written down. I don't clain creationship over any > they are just somethings that help liven things up for the Pc's > Brett@Legends... Glad to see that other people think about these sort of things :) Danny +---------------------------------------> | Danhiel Baker // Derkhil CatSpawn /) /) Fade away | dbaker@harpo.dev.uga.edu ( o o ) into the | dbaker@jb.ucns.uga.edu = x = ethereal grey... | Danny.Baker@bbs.oit.unc.edu m m +--------------------------------> ***(=======-
This archive was generated by hypermail 2b30 : 12/07/00 PST