Latest revision as of 02:36, 5 May 2011

Why Prog?

The first thing anyone (at least, anyone with any taste) who plays a stock ROM/Merc/DIKU is the lack of interactivity. Other than the default interactions of attacking, selling/buying, or practicing, there’s really not a large number of ways players can interact with mobiles, or vice-versa. There are even fewer things that pc’s can act, or be acted on, by objects or rooms. This is a glaring lack, since it several restricts a player’s interaction with his world, along with the player’s expectations about the limits of the game. Consider: In stock ROM, none of the following are possible:

• A mobile remembers multiple people who have attacked it, and will attack them should it meet them in the future.
• You want to have a door that is opened by pulling a lever.
• You have a sword that talks to the player, saying different things depending on the player’s attributes, or current status.
• You want a mobile which rewards you for returning a specific item to it.
• You want a guard that can be bribed into letting you into a locked room.
• You want a room that randomly teleports players who enter it.
• You want a magic genie, which appears when certain words are said.
• You want your mobiles to fight and use the advanced skills present on your mud.
• Etc.

It’s a big list, and in reality, it’s a lot bigger. So, given that there’s a need, how do we fill it?

Ideally, we want to have a system that doesn’t involve constant changes to the code base. We also want something that is relatively secure (we don’t want holes in the prog system to let people exploit the actual server!). Additionally, we want something that’s relatively straightforward, and to have an interface that even non-coders can use.

The answer to these concerns is to have a prog language which is actually interpreted and run by the mud code. This interpreted prog language is very similar to pseudocode (english language descriptions of a program’s logic), making the logic of it easy to understand, without imposing undue syntactical constraints. And, since it is a language which is only executed within the confines of a running mud process, its scope can be easily limited [and, steps can be taken to prevent the progs from crashing the entire mud which don’t involve rewriting major commercial compilers!].

By making it something executed from within the mud, you also make it easy to prog things from within the game’s OLC. This is a perk, as it gives you a ready made, and (relatively) intuitive interface.