Back to index

The copyright situation for this article is unclear. It does not belong to the author of this site. Please see the copyright notice. If you have information about the copyright contact me!

Who are you?

by Michael A. Hartman (Aristotle@Threshold)

As muds strive to make player interaction more meaningful and realistic, requiring that players be introduced in order to recognize each other is becoming increasingly popular. This feature is particularly prevalent on role-playing muds since it adds a feeling of realism and significance to the whole process of getting to know someone. When designing such a system, there are a few things you should always keep in mind so that your final product creates the desired effect in your game. Part 1 is an abstract treatment of the issue. It lists some of the major considerations a designer should bear in mind and attempts to explain some of the things one should think about when creating such a system for their mud. Part 2 will address the issue in more practical terms and provide some "nuts and bolts" explanations and suggestions for creating an introduction system using the one designed for Threshold RPG as a major example.
Nuts and bolts

The nuts and bolts of metal.

There are four important things to keep in mind when designing an introduction and recognition system (hereafter referred to as an "intro system"). First: Know the goal of your intro system. Second: Make sure your system is playable. Third: Code it in an efficient manner. Fourth: Keep in mind security and other rule compliance issues.

1) Know the Goal of your Intro System

This sounds obvious, but you would be surprised how often designers skip this step or forget this during the design process. For some people, an intro system is vital to their whole game. The more important role-playing is to your game, the more important a good intro system will become. If player vs. player conflict is the main focus of your game, you will certainly want to make it difficult for players to recognize other players simply on sight. If you are running a mostly hack-n-slash mud, a complex introduction system will not serve much of a purpose. If you are having a lot of trouble getting your players to interact already, you also won't want a complex intro system since this adds additional steps to people being able to see who is around them or currently logged on. By knowing what your goals are for your intro system, you can constantly temper your decisions by evaluating any design questions in light of what you are trying to accomplish. It also helps when dealing with the other issues of playability, efficiency, security, and rule compliance. For example, if a certain feature uses a good bit of system resources but does not really do much to further your goals, you know it is not a worthwhile trade-off. However, if a certain feature is crucial to your goals, then additional memory or CPU usage is probably worth it.

Before thinking about the code or what exact features you want your intro system to have, you should take a good deal of time to really think about what you hope to add to your game by putting an intro system in place. It is wise to discuss the issue with your players and listen to their ideas as well. Player input before the design of something that will affect them in a major way is almost always a good idea. Once you have a grasp on what your goal is with your intro system, you can then move on to actually planning what features it will have and how it will be coded.

2) Make sure your system is playable

Once again, this may sound obvious but it is far too frequently overlooked when designing a new feature for one's game. Ultimately, if the new feature is not very playable, your mud will be less fun with the feature in place. There are two main ways that an intro system can be unplayable. The first is that it is designed in a manner that makes getting introduced to other players extremely onerous and difficult. The second is that the intro system makes it almost impossible to differentiate between various players you are not introduced to. If either failing is present in your intro system, your game can become very unplayable.

Making the actual introduction process playable is the easier part of this feature. Generally, a simple command like "introduce" is used to initiate in the process. The syntax could be something like "introduce to Foo" or even "introduce Foo to Bar". One easy way to make the introduction system far too difficult is to always require that an introduction be handled by a third party who knows both people. Under such a system, how does the whole recognition system get off the ground? Although allowing a third party to handle an introduction is a neat feature, it should never be the only way to get to know someone. Another way to make the system unplayable is to give the "introducee" no way to reject the introduction. You can go with a confirmation process or some other way that the person being introduced to can refuse the information being given. This can also be accomplished by some kind of "forget" or "unintroduce" command that allows a player to no longer recognize the person who introduced to him/her. Some players will go around introducing to everyone in sight, and it is wise to allow your players to help remedy such a situation should a person like that introduce to them without permission or without role-playing the situation in advance (assuming you are playing an role-playing mud).

Ensuring that it is still possible to differentiate between people one does not recognize by name is one of the most crucial elements of a good introduction system. This is where many intro systems become very unplayable. Certainly, people should be able to tell the difference between two people relatively easily even if they don't know their names and have not been formally introduced. In real life, we are able to do this because a visual image provides a wealth of information that can be processed quickly. On a mud (especially on a text based mud), it is very difficult to process such information quickly. You have to read it, and you have to have enough information to differentiate between two players. There are going to be many people playing characters of the same race and gender, so that information is not enough to differentiate between two people. Many muds have features like eye color, hair color, etc, and those can be used to effectively differentiate between players. However, this also will not always be enough since two male humans could easily both select brown eyes and brown hair- even if they are not twins. At that point, you can also differentiate by the equipment players are carrying. Although this is effective, it is also quite possible that two people might be wearing the exact, or nearly exact, same set of equipment. It can also get very "spammy" to give all such information in a short description. Basically, you have to do the best you can given the limitations of the medium. You must find some way to provide an easy method for players to be able to tell who is who, and more importantly be able to direct various commands at the right person. On a mud, one's character name is usually the main way that people differentiate between each other as the name generally serves as the main "id" used to target commands, spells, guild abilities, skills, etc. If you do not provide any means for players to see the names of people around them, you will have to develop an excellent, efficient, and easy to understand method for differentiating between people. That can get extremely onerous, can be very inefficient, and can also require an outrageous amount of typing for players (for example, if they had to type something like attack male elf with green eyes, blue hair, a brown cloak, and black boots). It is often wise to provide a way of determining what the names are for the sole purpose of knowing which person is which for directing commands or anything else that has to be directed at a specific being.

3) Code it in an efficient manner

Yes, once again this issue seems like an obvious one, but it is often overlooked when designers start thinking of "cool" features. An intro system can add a lot to a game, but it is not something that should take up a lot of system resources. An intro system functions in the background and becomes an accepted part of the way players interact with each other. It will never be something players actively get entertainment out of on a day to day basis. Although its effects on your game environment can be significant, most of this effect is gained through the simple fact that you have an intro system at all. Just having the game concept of introducing to people in order to recognize them on sight is what has the largest effect on your game. Additional features will be marginal in comparison to this initial change. Thus, fancy features that use a lot of memory or CPU are unlikely to add enough to your game environment to justify their resource usage. Keep that in mind when planning the elements of your intro system, and even if something seems like it will be interesting, do not add it if it uses too much memory or CPU power. On the other hand, don't be so stingy with system resources that your intro system is extremely boring or barely accomplishes the goals you set out at the beginning. If you have a lot of RAM, then do not be afraid to keep larger amounts of data on each player file that keeps track of who each person knows and perhaps what name they know a person by. As noted in point #1, if a lot of intro features are necessary to accomplish your goals, and you have the system resources to fulfill these goals, then by all means use them!

The other thing to keep in mind is that most likely, whatever function you code to check if Person A knows Person B is going to get called a LOT. It will be called every time someone walks into a room with people in it, every time they use any "who"-like command, every time they type "look" or "glance" or any other visual command in a room, etc. Functions that get called when people move or look are things you really have to code carefully. These are things that happen extremely frequently and are often executed by many people at the same time. You want to make sure that such functions are written efficiently or your machine will get bogged down in no time.

4) Keep in mind security and other rule compliance issues

This issue is related to what was discussed in the last paragraph of point #2. If there is no way for players to know who they are dealing with, they will not be able to report rules violations, harassment, etc. muds with any significant player-base almost always rely upon other players to help police the game, ensure that rules are followed, and the like. Also, if a player is harassing someone else (or many other people), you want to be able to identify the person as quickly as possible so you can remedy the problem with equal haste. These issues are vital to the health of one's game, and should certainly not be taken lightly or underestimated. This factor alone is important enough to make sure that your intro system gives players some way to know who is in the same room or who is talking to them. Coding an extremely complex intro system that provides no such means of knowing who is who will come back to haunt you. You will regret such design decisions the first time some harassing player or habitual cheater ventures onto your game and ruins things for a lot of people while you struggle to track the person down and deal with them.


Introduction and recognition systems have become a common and popular feature for muds of many varieties. This leaves game designers looking for assistance on how to design such a system. If you bear the four issues addressed above in mind, you will be well on your way to designing a good system that will add something interesting and enjoyable to your game. The above article has sketched some broad strokes and addressed the overall issue in a mostly abstract manner. If you found the information helpful or interesting please read Part 2. It will delve into the creation of an intro system in more explicit detail, and even discuss the pros and cons of a variety of specific features. Good luck with your own design, and may the final result be more fun for yourself and your players.

Michael A. Hartman is the sole administrator and author of Threshold RPG.