AIME Builder Tutorial

Index

1. What is the Builder Port?
2. The Database
3. Object Types
4. Logging In and Getting Set Up
5. Loading Areas and Modifying Objects
6. Creating Markers
7. Creating Moveables
8. Creating Books
9. Creating Keys
10. Creating Locations
11. Creating Doors
12. Creating Mobiles
13. Creating Mergers
14. Creating Money
15. Creating Weapons
16. Creating Wearables
17. Creating Food
18. Creating Boats
19. Creating Ropes
20. New, Copy, Rename, and Delete
21. Non-MudObject Objects
22. Creating Spells and Skills
23. Creating Specials
24. Creating Quests
25. Creating Actions
26. Creating Levels
27. Creating Races
28. Creating Texts
29. Creating Bulletin Boards
30. Creating Inclinations
31. Creating Talents
32. Creating Chatlines
33. Using Color
34. Where do I start?
35. I want to make this do that. Can I?

1. What is the Builder Port?

The AIME code provides a separate port for all building activities. It allows for online creation of areas and should provide the builder an efficient method for putting their ideas onto the mud. Some may ask, why create a separate port divided from the game port for building? We did this to provide a functional division between building and game play. This way, all building will be done on the builder port, and functions specific to game play and administration can be accomplished on the game port. To gain access to this building port you need to talk to a mud admin to give your player the correct permissions for port access.

2. The Database

The MUD stores all information in "objects". A location is an object that contains the location description, where the exits go, and other data pertaining to that location. Each mobile is an object, and each door is an object. For the most part, anything you can examine, get, or talk to is an object. In the MUD, we call these objects MudObjects.

The MUD stores all MudObjects, along with several other types of objects (Actions, Spells, Skills, etc.) in a series of area files. An area file is a collection of objects, ranging from Mobiles to Doors to Locations that have some functional connection. One example is the Elven Forest. The entire Elven Forest is stored in the area "eforest". The entire Camelot section is stored in an area called "camelot". When you combine all areas together, they make up the MUD.

For those who are interested and have some knowledge of databases, all MudObjects are stored in an area binary tree. Each area binary tree is then stored in a mud-wide binary tree. So it is in essence a bunch of trees in a tree. If you have no idea what I am talking about, don't worry about it; it is not important for you to understand this to create areas.

3. Object Types

There are many different objects that make up the MUD, each with its own unique attributes. Markers are objects that take up a small amount of memory, and are used for a non-moveable object that you can examine. Doors are links between locations that can be opened, closed, locked, or magically locked. Books are objects that, when read, will print the contents of a file. Locations are, well, locations in the world. Keys are objects that are used to open one or multiple doors. The key will only work on a door if that door is specified as working for that key. Mobiles are game people, creatures, or anything that can die. Most mobiles you can talk to and will respond to you. Moveables are items that you can get, but aren't usually good for anything but taking up space. They could be an item that adds to the "feel" of an area (like a skull head) but has no real use.

4. Logging In and Getting Set Up

In order to be able to log on, you will need to ask a game admin to give you the proper permissions and access. Once you have been configured for building, telnet to the builder port of the MUD and log in with the username and password you use on the regular game port.

5. Loading Areas and Modifying Objects

On login, you will see a prompt that looks something like:

([AREA]:[MUDOBJECT]) B>

The [AREA] indicates which area you have loaded, and the [MUDOBJECT] will indicate which MudObject you are set to modify. To modify a particular object, you'll first need to load the area file it's in, then load the object. For example, suppose you want to change the title of a location called "stinky" in the area called "swamp". You would first type "load swamp". Your prompt would then change to:

(swamp:[MUDOBJECT]) B>

To modify the location "stinky", you would type "modify stinky". Your prompt would then change to:

(swamp:stinky) B>

While more than one person can modify an area at the same time, only one player can modify a particular object at one time. While you are set to modify "stinky", no other player can modify it.

At this point, you can view the attributes of the location "stinky". Typing "describe" (or "desc" for short) will give you the attributes and values of each attribute that make up the location "stinky". You will see the title, description of the location, where the exits lead, and other data pertinent to the location.

6. Creating Markers

Markers have several purposes. First, they provide something to examine without letting the user know that it is there directly. An object that you can move would normally have a brief description which would appear to the player, like "You see a bone lying here." (We call this a "brief".) The player will only know that a marker is there if the builder identifies the object in the location description. For example, the room description:

"You stand in a small room, complete with a table, chair, and a small uncomfortable-looking bed in the corner. The dust covering the floor indicates that nobody has been here for days."

Given this room description, you should ideally create a marker for the table, chair, bed, and dust. That way, when the player types "examine table", you could provide the description "A small amount of rotten food covers the wooden surface."

A second reason that a marker would be used is to attach a 'special' to it (this will be described in detail later). If you have a torch on a wall, and want a wall to open when the user moves the torch, you would create a torch marker and attach a special to it.

Marker Attributes

7. Creating Moveables

A moveable object is an object that a player can carry. In actuality, Books, Keys, Wearables and Weapons are all Moveables, but with added features. A Moveable is the simplest of all carryable objects. You use this object when you want to create an object just for show, or to attach a special. It could be a skull to create atmosphere or a magical stone that glows when picked up. You can make moveables more functional by adding flags to them. For example, setting the flag 'Container' will permit that object to hold other objects. So one could create an object "bag" and set the 'Container' flag and suddenly this object is a useful container.

Moveable attributes

8. Creating Books

Books provide a method for displaying a large amount of text without using the massive amount of memory that storing all the text would take. A book indicates the name of a text file, which when the user reads the book, it displays the contents of that text file to the user. This way, only the filename needs to be stored in memory, instead of the entire text. Books are gettable, and provide an "examine" as well as the file that "read" displays.

Book Attributes

9. Creating Keys

Keys are identical in attributes to moveables. The only difference is that you can't use a moveable to unlock or lock a door.

Key attributes

10. Creating Locations

Locations are the "meat" of an area. They are the rooms that the player stands in and which contains most Markers, Moveables, and all Mobiles. The locations contain exit pointers for each of the ten directions, and point to either another location or a door. They also contain location flags which define special attributes about the location.

Location attributes

11. Creating Doors

A door is like a mix between an object and an exit. It allows a link to be created between two locations, and depending on the door state, either allows passage or blocks the exit. Doors provide great flexibility in descriptions. Each door has a separate description for the inside and outside of the door. It also allows you to set your own brief message depending on the door state. You set a door by first assigning the inside and outside location of the door to the two locations that the door will exist in. Then on both of those locations, you set the appropriate exits to the door name. Say your door is called "reddoor" and your two locations are called "room1" and "room2". These attributes should be set:

Room1:
East: reddoor

Room2:
West: reddoor

Reddoor:
Outsideloc: Room1
Insideloc: Room2

This will make the door a link between those two locations.

Doors are also used when linking two rooms with a rope. You define the door with the RopeTie itemflag and connect the door like you would any other door. The RopeTie flag prevents players from opening the door by normal means. They actually have to tie a rope to the door (the rope must be long enough) to open the door. For a rope door, the brief 0 is for when a rope is tied to the door, the brief 1 is when no ropes are tied, and brief 2 is for when the rope is tied but not long enough. Brief 3 is not used for a rope door.

Special doors are doors that can only be opened using a special. For instance, if you have thorns blocking a path and the player must light the thorns to clear the path, you set up a special door and create a pre_light special that will open the door when the thorns are lit. To set up the door as a special door, you need to set the SpecialDoor itemflag. If you don't want the exit to show up on "exits", you need to set the HiddenDoor itemflag. This will also prevent briefs from being shown.

Door attributes

12. Creating Mobiles

A mobile can be defined as any non-playing character. This can range from creatures that want to kill you to shopkeepers that want to sell things to you. It could include peasants, lords, and thieves. Mobiles contain a tell/reply feature. It allows the builder to create replies to specified keywords. When a player does a tell to a mobile, the tell string will be searched for certain keywords. If it finds a certain keyword that has a reply, the mobile will reply with the specified string. In general, you will want to create a reply to keywords "hello hi" for each friendly and some unfriendly mobiles. This way, users can start with "tell bob hi" in order to get information from Bob. The replies should help lead the conversation as well. Nobody is going to know that if you tell the dragon "what about the glove" that the dragon will tell you where the magical glove is unless you provide a clue somewhere. An example of an effective leading of the conversation would be:

"tell mayor hi"
Mayor replies "Welcome to my town!"
"tell mayor town"
Mayor replies "Yes, I am the mayor of this town. It isn't much but it does survive."
"tell mayor survive"
Mayor replies "Oh yes, we have had our hard times as of late, what with the big storm and all."
"tell mayor storm"
Mayor replies "Nearly wiped out every building! Was a devil's storm if you ask me!"

Using this technique of leading the conversation, you can provide hints for the players to home in on. For the most part, all keywords should have something directing the player to them, even if it is a mobile on the other side of the mud giving a hint. New tellreplies can be created by typing "new reply (keywords)" and the replies can be changed by typing "set reply (reply number)". Tell Replies can be deleted by typing "delete reply (reply number)".

Mobiles can perform abilities much like a player can. They can also have certain weapons they are skilled at using. These are called proficiencies and can be assigned to a mobile using the command "new proficiency (objname)" where objname is either the name of a spell or skill in the abilities area, or a weapon class. When a mobile has proficiencies assigned to it, a message will appear when the user types "describe" indicating proficiencies exist. These proficiencies can be viewed by typing "describe proficiency". In this list, ProfName indicates the ability or weapon class. Rank indicates how adept they are at using the ability or weapon. It tops out at around 40 for most abilities or weapons. Finally, probability is the probability that each combat turn the mobile will use that ability and does not apply to weapons. You can remove proficiencies with "delete proficiency (number)"

Mobiles can also run a shop, where the user can buy objects from the mobile in exchange for a certain amount of money. Each shop contains a name attribute, which the mobile will use when referring to their shop, like "Bob's Bugs and Beetles". Also, each shop contains a currency attribute stating the denomination of currency in which the shopkeeper lists his prices. These currencies (whether gold, silver or copper) have to be pre-defined MudObjects (such as gold@courtland). Shops can be created by typing "new shop (name of shop)" and deleted by typing "delete shop"

Each shop contains a list of shop items which consist of an alias, an object name, and a value. The alias is the name that the shopkeeper will use to refer to the object. The object name is the name of the actual object. For example, the object "shortsword" could have an alias of "sword". Theoretically, the alias and the object name could be unrelated (ie, you could give the item an alias of sword when it is really a rock) but this would be misleading to the player and isn't recommended. To create a shop item, simply type "new item (alias)" and a shop item by that name will be created. To delete a shop item, type "delete item (alias)". The "value" is the cost of the object, and is specified not in terms of currency but rather in terms of the money index. To get more information on the money index and money objects in general, see Money).

Mobiles have a list of flags, called IndFlags (Individual Flags). See flags.html for a list of available flags.

Mobile Attributes

13. Creating Mergers

A "merger" is an object that will merge together and break apart as needed. An example of this would be a group of arrows. If you carry those arrows and do an inventory, you will see: arrows(10) meaning you hold ten arrows. Actually you hold one arrow object with 10 units. If you type "drop 5 arrows", it will clone the arrows object, set each to 5, and drop one copy of the arrows. Now you will hold in your inventory "arrows(5)", and on the ground there will be "arrows(5)". If you then type "get arrows", it will destroy one arrows object and you will now hold "arrows(10)" again, because the two objects will have been merged. Mergers can be used for any type of object that will normally exist in multiple numbers. Money is an example, but money is a different object that will be talked about later. Weapons ammunition like arrows, bolts, and slingshot pellets would use mergers. Reagents could also use mergers.

To create mergers, you create a template object which is never used in actual gameplay. All mergers will then be generated from this template as needed. All object types have a clone attribute where you can specify mergers that start in that object. For example, a bow may be created with five arrows in it. This object ability excludes actual merger objects, since you can't place a merger within a merger. Another example is having a merger start in a specific location. Say we create a location called "forest1" and in that location, we set Clones = "arrows@castlezone 7". This means that on loading of the zone, it will place an arrows(7) object at that location.

Merger attributes

14. Creating Money

A money object is a merger with one additional attribute: index. The index reflects how much a single unit of that currency type is worth relative to other currency. For example, let us create three types of money: gold, silver and copper. We assign an index of 200 to gold, 20 to silver, and 1 to copper. Therefore it would take 20 coppers to equal one silver, and 10 silvers to equal one gold.

Keep in mind that if you give weight to the money, each piece of money will weigh that much and if you give a weight of 1, 200 gold will be quite heavy. You may want to give it size but no weight.

See price.html for a list of objects and how much they would be worth for an approximation of how expensive you should make things when designing shops.

Money attributes

15. Creating Weapons

Weapons are objects that can be wielded and cause damage to others. Weapons contain a damage attribute, which stands for the maximum damage that the weapon can cause. The damage that is actually caused depends on how direct the blow is, the damage of the weapon, and how heavily armored the mobile is.

The DepStr attribute is the dependency the weapon has on the user's strength, from 0 to 100 where 0 is not at all dependent, and 100 is fully dependent. A lightweight sword would have a low DepStr level, while a heavy warhammer would have a high DepStr level. DepDex is the dependency the weapon has on the user's dexterity. A bow and arrow may require a higher player dexterity than an axe. For both of these attributes, if the object has a high dependency on either of these levels, then the user should have a high level of strength or dexterity for them to have any accuracy with the weapon. This also affects chance of deflecting the enemy's weapon.

The weapon class is a string that defines a weapon in a certain class. If you create a sword, you should place that in the "sword" class, and this will allow a player who trains on "swords" to gain an advantage with "sword" class weapons.

Weapons must be wielded in either one hand or both hands to be effective. Some weapons, like a short sword, may only require one hand to use. Other weapons, like a two-handed sword or a bow would require both hands. The wield type attribute defines whether the weapon requires one or both hands to wield.

If you set the class to a range weapon such as a bow, it will make it act quite different. You will need to first set the container flag on the bow and ensure the capacity is enough to fit your arrows. To limit what the player can put in the bow, attach a special to the bow with the trigger "preput_receptacle" and ensure the special code allows only the object types you want, such as arrows. Here is a sample bit of code that does just that:

goto_if_eq("end", is_string_eq(get_parent_name("primary"), "arrow@global"), 1);

send_actor("You can't use that with the bow!\n");
return_invalid_criteria();

end:

When the player attacks with their bow, the mud will look for an object inside the bow with a special attached to it with the "on_launch_hit" trigger and will use that to fire with. It will run that special then. An example of that code is:

send_actor("Your arrow sinks into ", get_title("primary"), "!\n");
send_room_except_dual("primary", "this", get_title("this"), "'s ",
get_title("secondary"), " sinks into ", get_title("primary"), "!\n");
send_to("primary", get_title("this"), "'s ", get_title("secondary"),
" sinks into you!\n");
set_counter(25);

decrement_number_of("secondary", 1);
goto_if_neq("end", 0, get_number_of("secondary"));
destroy_this_obj();

end:

It determines damage by what the counter is set to, hence the set_counter(25) line which causes 25 points in damage.

Weapon attributes

16. Creating Wearables

A wearable is an object that can be placed on the body of the player or mobile. It could be anything from clothes, jewelry, armor, etc. A shield is considered a wearable object, but it does not get worn per se as it is wielded. You need to set the Wielded wearflag to make the shield wielded.

Each wearable object is a moveable object, with a few additional attributes. The armor value is the maximum amount of damage that a piece of armor will deflect or absorb. It does not decrease the enemy's chance of hitting you, but it will decrease the damage they cause if they do strike you.

Wearable objects have wearflags that indicate several attributes of the object. First, they indicate on what part of the body an object will be worn. An object can be worn on several parts at once. For example, a chainmail vest would be worn on the back, chest, and arms. The TopLayer flag indicates that this item of clothing will always be the top layer on a body part. You can only wear one top layer item of clothing at a time. This way, nobody can wear two platemail items at the same time.

Wearable attributes

17. Creating Food

A food item is an item that can be consumed, and will often give the user energy. Energy is important as it will affect how you fight and some other game aspects. A good player will keep their energy level high by eating food often, so that they can perform at their optimum level. Food is a merger with one special attribute: energy. This is a value from 0-10 that states how much energy eating one of these pieces of food will provide to the player.

Food attributes

18. Creating Boats

A boat item is an item that a player can enter and will allow that player to travel across water. It is a carryable object, but in all actuality most boats would be tough to carry without dropping everything so it would be wise to set the size and weight high. For a boat to work properly, you must set the container flag and set a capacity high enough to carry the players that you want. The default individual size is 180, so for two players you should make the capacity 360 or higher.

The boats do briefs a little bit differently. If the boat is on water, the waterbrief is used. If the boat is in a shore location (meaning that both regular players and water-dwelling mobiles or boats can go there), then the brief0 is used. Otherwise, brief1 is used.

Boat attributes

19. Creating Ropes

Ropes are merely moveables with one additional attribute, length. The length attribute will define if a rope can be used in a specific "rope door". If it is not long enough, it will not reach far enough for the rope door.

Rope attributes

20. New, Copying, Renaming, and Deleting

The builder port supplies methods for manipulating objects. To create an object, the "new" command is used. The "new" command syntax is: "new (objecttype) (objectname)". The type is either one of the object types (like a weapon or a location), atellreply or a special. To create a new weapon, you might type "new weapon shortsword". Each object name has to be unique for that area. For example, you can have several weapons called "sword" in the game, but only one per area. For tellreply, the (objectname) is where you put the keywords for the tellreply (separated by spaces, like: "hi hello") that will activate the reply. For instance, if you want the mobile to reply to "hi" or "hello", you would type "new tellreply hi hello".

For copying, renaming, and deleting objects, you first need to have an object set to modify. (See Loading Areas and Modifying Objects) To copy, the command syntax is "copy (newname)" where (newname) is a unique name for that area. The syntax for rename is "rename (newname)" where (newname) is a unique name for that area. Copy and rename do not work for tellreplies or specials. You will have to delete and recreate these.

To delete anything, you must first have an object set to modify. To delete objects, you simply type "delete" and it will ask you if you really want to delete this object. Say yes and the object will be deleted. It does save the deleted object to a recovery file, so if later you decide you didn't want to delete the object after all, let someone with site access know and they will recover it for you. To delete tellreplies, type "delete tellreply (number)" where the number is the one given to the tellreply under "describe".

21. Non-MudObject objects

Not all items that you can modify on the Builder port are classified as MudObjects. The following objects are objects that the player wouldn't necessarily be able to pick up, look at, or be at. They range from quests to spells and skills and are an integral part of making the mud come alive. In most cases, you have to load a special area to edit these. This will be described in each object.

22. Creating Spells and Skills

Spells and Skills are both Abilities, so in order to edit them you must load the area "abilities" into memory (See Loading Areas and Modifying Objects for more details). Once this is loaded, you can modify, create, and delete abilities as needed.

There are two types of abilities, Spells and Skills. Except for the name and the fact that one casts a spell and performs a skill, they are very similiar. On both, one can set dependencies which limit how the user can perform the ability. If, for instance, you want a spell that requires intelligence and wisdom to cast, you would need to create a dependency on both intelligence and wisdom. The value of that dependency would determine if the the user can even use that ability and if they can, the chances of them being able to successfully carry out the ability. To create a dependency, you would type "new dependency (type)" where type is the type of dependency. This ranges from ReqIntel for requiring intelligence to ReqStrength for requiring strength. Both spells and skills have strings that are displayed during combat to the target, the caster or performer, and finally to bystanders. The "acting" group of strings is displayed when the player casts or performs the ability. If the cast or perform was successful, the "success" group of strings is displayed. If it was a failure, the "failure" group of strings is displayed. ' All in all, you have 9 strings to customize your ability with.

It also supplies limitations to the spell casting or ability performing. For instance, with a certain spell you may require that they be holding an emerald staff. The "MustHaveItem" dependency will allow you to specify these limitations. The drain attribute will allow you to specify how much the casting or performing of the ability will drain the player (magical energy drained for spells, endurance drained for skills). Finally, when a spell or skill was successful, it runs the special specified in the Specials attribute. This is what actually runs the "meat" of the ability. For the fireball spell, the following code is what makes it work:

goto_if_eq("ind", 1, is_individual("primary"));
goto_if_eq("light", 1, is_itemflag_set("primary", "lightable"));
goto("end");

light:
set_itemflag("primary", "lit");
goto("end");

ind:
damage_individual("primary", 25);
fight_player("primary");

end:

You can probably see by this code that if you cast fireball on an individual (player or mobile), it does 25 damage while if you cast it on an inanimate object that can be lit, it lights the object. With the special code, you can make a spell to do most anything. From picking a lock to summoning a demon, a spell can be anything you would want it to be.

Spell attributes
Skill attributes

23. Creating Specials

Specials are objects that define unique activity that is not supported in the mud code. For instance, if you want a sword to give the player a shock when they pick it up, you would attach a special to the object that does this. Once attached to an object, specials activate using triggers. The trigger defines the action that will cause the code to be run. In the case of the shocking sword, the trigger would be set to "pre_get" or "post_get" which would give the shock before the sword is picked up or after the sword is picked up. The list of triggers will describe each trigger to you.

The code for the special is in interpreted format (don't worry if you don't know what that means) and is described in the specials tutorial.

Specials attributes

24. Creating Quests

Quests are actual defined puzzles for the player to embark upon and solve. Your MUD may not have quests defined so they will not even come into play, as quests can be done without actually defining them (creature won't teach you a spell until you get a dragon's tooth for example). If the MUD does have quests defined, you can create them by loading the quests zone (See Loading Areas and Modifying Objects for more details).

The attributes in the quest object allow you to indicate attributes of the quest, ranging from the quest points awarded for completion to the description of the quest the player will see when typing "qinfo (questname)". The actual quest will be awarded to the players using a special (See Creating Specials) and the award_quest special command.

Quests attributes

25. Creating Actions

Actions are things that the player can do that are really just for fun or to provide an easy way to express themselves. It can range from smile to laugh, from bopping them on the head to giving them a rose. They are just verbs that display text when executed to the room and to a target if specified. Many other muds call these as "socials".

The action objects consists of five strings which are displayed to different people in different circumstances. The Actor string is displayed to the player performing the action when there is no target involved and the Crowd string is sent to the bystanders witnessing this action. For a targeted action (directed towards somebody), the Target string is sent to the target of the action while the Sender string is sent to the recipient. The Bystander string is sent to those witnessing the action.

All strings provide special characters to insert names and pronouns into the text as appropriate. For example, %a inserts the actor's name into the string. %t inserts the target's name. The full list is as follows:

%a	The actor
%t	The target
%!	"his" if actor is male, "her" if female
%~	"him" if actor is male, "her" if female
%[(malestring)%(femalestring)]	displays first string if actor is male, second if female
%<(malestring)%(femalestring)>	displays first string if target is male, second if female

Actions attributes

26. Creating Levels

Levels are used to indicate how far a player has progressed on a specific track or chain. All levels are stored in chains, where a chain may be the "Wizard" chain containing all levels of the wizard's guild. This way, a player can be level 6 in the wizard's guild (wizard's chain) and level 12 in the warrior's guild (warrior chain), making them a strong warrior with some magical abilities.

Players advance to the next level once certain specified criteria are met. This criteria is contained in the level object in several ways. A few attributes of the level object allow you to specify specific criteria, such as the MinStr attribute which allows you to set a minimum strength for the player to be at. MinDex, MinIntel, and MinExp all provide a means of ensuring the player has certain attributes before the level is awarded. You can specify specific criteria using the SpecialReq attribute. When a special is attached with the trigger "on_level", it will run the special and if the special return with the return_invalid_criteria function, it will not award the level. This way you can specify specific things that must be true, such as the player has to have an object in their inventory to gain level.

By using the WhenAwarded attribute, you can reward the players for their level advance by performing most anything your imagination can come up with, from increasing their attributes to awarding them priviledged objects. You could even give them some adminflags, such as when they make master level.

Levels attributes

27. Creating Races

Races define a race of creature. It contains attributes that indicate what a player from that race starts out with. It can indicate spells and skill they initially know, how strong they are initially, how dexterous they are, etc. Many items in the game will depend upon what race the player is. Their communications will depend on what race they are and what they can understand initially. An elf will not understand what a dwarf says and visa versa. Races also set which tutorial the players travel through when they first create their character. When a race object is being modified, the builder can type "new tutorial (name)" which will create a tutorial. The tutorial is basically a special that can display text, transport a player to a tutorial zone, or whatever else you want it to do. The player does not exit the tutorial until the special function exit_tutorial is executed using another special. If you have transported a player to a specific tutorial location, then you could set up a special to run exit_tutorial when a player tries to leave the tutorial area. It is important that, while in the tutorial, the player is not given the opportunity to exit into the game as they have not finished building their character and will be disadvantaged. Tutorials can be renamed with "rename tutorial (name)" and deleted with "delete tutorial (name)". Other attributes for tutorials are described in the race attributes section.

Race attributes

28. Creating Texts

Text objects provide a means to edit various texts througout the game. This could range from help and info files to the banners that players see when they logon and quit the game. The type of text object depends on the area you load. To edit and create help files, you would load the "help" area. For info files, the "info" area should be loaded. The "banner" area will provide a means to edit the specific banner files that are used. Currently, two banners exist. The bldrbanner is the banner that will appear when a player logs onto the builder port while the gamebanner is displayed to players logging onto the game port. Text objects are fairly simple, in that they only have the Title (with the exception of Banners which don't have this) and the body. You create the texts by typing "new (type) (name)" where type is either Help, Info, or Banner. The type must match the area that is loaded. One point to note on texts: you can't save these to a temporary file. Once you have modified them, the only way to store them is to commit, which will write them to their permanent files and incorporate them into the mud.

Texts attributes

29. Creating Bulletin Boards

Bulletin boards can be a good forum for players to express ideas to other players on the game. They can be used to put out ideas or even add to the roleplaying environment of the game. Bulletins can be set up to be global, meaning players can access it from anywhere on the game, or set to a specific object so that players must be at that object to access. They include several attributes that permits you to tailor who can access the board and who is denied access. If denied access, the player won't even know the board exists. You can create a bulletin board by first loading the "bulletins" area and then typing 'new bulletin (name)' where (name) is a name that the players will refer to it as if the global flag is set. If the global flag is not set, the players will have to use the object the bulletin board is attached to in order to access the board.

Bulletin attributes

30. Creating Inclinations

Inclinations are used during the initial login for new players. It permits builders to define and players to select certain inclinations for the race. For instance, in the elven race, most would not be exceedingly strong but amidst the elves you would find those that are stronger than most and those that are even more dexterous than others. Inclinations could include musclebound (stronger but stupider than most), scholar (more intelligent but weaker and clumsier), and on and on. Inclinations only define offsets, meaning how much the attributes increase or decrease. This means that a dwarf who selects musclebound inclination is going to be much stronger than the elf who picks the musclebound inclination. Builders should take care when developing inclinations so that one is not more advantageous overall than others or players will discover and continually select that inclination. Balance is the key. Inclinations are maintained in the inclinations area. Loading this area will allow a builder to modify, add, or delete inclinations. If you do not wish inclinations to be availble to the players, just delete all inclinations in the inclinations area and the players will not be asked to select an inclination.

Inclination attributes

31. Creating Talents

Talents are used to fine-tune the character creation. The game developer can offer several attributes for the players to start out with, all tailorable via a special. Implementors can offer a dexterity increasing talent or a strength decreasing deficiency (which gives more talent funds). It allows for players to set indflags, such as night vision or any other flags that exist. Players use talent funds to spend on talents. The amount of talent funds players start out with is determined in the aime.conf configuration file. As with inclinations, talents should be balanced so they do not offer too great an advantage. Talents could even be coupled with deficiencies, so that a player who selects a talent would suffer somewhere else, providing a balanced trade-off. The talents area allows builders to add, delete, and modify talents. If the game implementor does not want talents to be offered to the player, merely leave the talents area empty and the player will not be asked to select talents.

Talent attributes

32. Creating Chatlines

A Chatline is a capability that permits players or builders to transmit messages across the entire mud. It could be anything from a regular chat line to a line for coders or administrators to discuss issues. A chatline requires two seperate permissions. First, one must have permission to transmit over a chatline (see the user's manual for how to set this) and second, the users must have permission to see the messages. A player could have permission to receive but not to send (such as a system message), or to send and not receive (such as a wish line that goes to the immortals).
The Chatline object contains attributes that define the format of the message that is sent. It also contains lineflags, which define who the message will go to.

Chatline attributes

33. Using Color

Color can add to the atmosphere that you are trying to create in your area. For instance, if you are creating an area of cold and ice, using white and blue will heighten that effect. For a volcanic area, reds will certainly make the player "feel" the area better. Green colors can also emphasize forested areas, while yellow can portray a desert area (relentless sun). A list of color codes can be found on the game port by typing "info colorcodes"

34. Where do I start?

Below are my suggestions for creating a good zone.

Before you even create your first MudObject, you want to plan out your location. First, think of the overall "feel" of the zone that you mean to portray. If it is a mountain zone with a small village, imagine what a mountainous village would be like. A village needs to have a reason for being, so plan out the industry that drives the village, how the villagers live, what they live in, and what traditions and cultures that they may have.

Next, map out the layout of the zone. Keep in mind the things you decided already, and develop the map accordingly. A mountainous village would probably have buildings made partially of stone and wood, and could even contain a mine or two. It would have a store to buy food, a blacksmith, a woodworker, and maybe a bowsmith. Most settlements would have a pub or some other form of entertainment for the inhabitants.

Adding mobiles to this village would come next. This and the next step of planning underlying "events" almost come hand in hand, since the people are what will help make the village interesting. A village will probably have a village leader, or a council that runs things. It might have shopkeepers, workers, and some kids as well. Wives of miners could dwell in the houses, and maybe some hermits living away from the village.

Next, you need to plan out the underlying "events" and "turmoil" that dwells just below the surface of the village. When a player talks to a wife of a miner, they may say that "Sylva" is a good person, but talking to another villager you may find a feud between this wife and Sylva that when you ask them about it, they go on and on about this person. You could create underground societies, hidden traitors, and insurgency warriors fighting against the king. All this for the player to uproot with a thorough investigation. Often, the more complex the underlying puzzles are, the more interesting the zone will end up being. It might be a good idea to create links to other zones, meaning someone may have a brother in Courtland, and then add tellreplies to that person and the brother. You may have to get permission from the maintainer of that zone to add to it. While you're at it, plan out the puzzles to be solved, hidden passageways to find, etc.

Finally, you create. Start with the locations, and add markers as you create these locations. Add mobiles and tellreplies, and inventories to shops as you see fit. Add specials to appropriate objects, and finally, when you feel that you have a fully functional zone, test and test some more. Login as a regular user and travel down every possible path (including social and verbal paths, tellreplies and stuff) and ensure the user can chase these paths as well. When it is tested, your masterpiece is ready for the users to marvel at your creativity!

Again, this is just a suggested way of doing things, you are free to find the method that works best for you.

35. I want to make this do that. Can I?

If there is something you want to put in your zone and either you don't understand how to do it, or the tutorial doesn't explain a way, be sure to tell a coder. They will be able to tell you if it is possible and how to do it, or explain to you why it is not possible and offer possible alternatives. The last thing we want to do is stifle the creativity of your zones, so please ask.

[ Concept | Status | Latest News | Tutorial | Building ]