Most definitely. See the list of resource sites in section 8.4 of this document for a list of places where you'll find code snippets, areas, ideas, information and much more besides for ROM based muds. You should also bear in mind that since ROM is derived from MERC, many of the code snippets for those muds will work on ROM, though how much changes you'll need to make varies from snippet to snippet.
Also, remember that these things are publically available due to a number of people's willingness to share their work with the mud admin community at large. Free things generally come with no warranty, and this is surely the case with what you'll find on the net. The vast majority are very slick packages that work well, but adding a chunk of new code to your mud is something you need to take care over, firstly as the most common problems with such things are installation errors, and also because it is generally not a good idea to start including in your code huge swathes that you don't understand. Time spent reading through the patch carefully to get a grasp on it's workings will surely be time well spent, firstly as it can help avoid the simpler installation errors, and secondly because the more knowledge you have of your codebase the better by far when you find yourself bug hunting.
You also should read carefully any licence that accompanies the code, and don't use the code if you find the terms unacceptable.
A very common philosophy held in Computer Science is "Don't re-invent the wheel", and this holds true for muds. If you need a code patch to perform a specific task and you see one, there is nothing to stop you using it. However, these patches were written to solve the problems that the writer had- nothing says your needs will be exactly the same. As such, getting the patch could perhaps be looked upon as a time-saving exercise to get you up and running with a certain bit of code, but enhancing and altering the patch to your own specific needs is something you probably should consider doing. There are a lot of muds out there, and many many of them will be using the same snippets you are using, so if you wish your mud to stand out from the crowd you need to add things of your own to make it more unique.
Some people dislike using snippets in any form, and this attitude can have it's advantages as writing the code yourself from scratch can be very educational and rewarding, plus it gives you a piece of code that conforms to your exact specifications. And if you do write something yourself that you think may be of use to others, consider making it publicly available- as the MERC headers says "What goes around comes around".
There are two distinct parts to what makes a mud: the compiled C code that is the game engine and the area files that make up the world the players move in, specifying the rooms, objects and monsters. This task of area writing has been traditionally viewed as very difficult as it required the area author to put together a text file containing what often seemed to be incomprehensible strings of numbers and letters to represent things in the world. This process could often be very time consuming and error prone.
The concept of On Line Creation developed some years ago, whereby the mud itself had a range of new commands that allowed characters logged on to the mud to expand the world while the mud was live. The most popular version of an OLC package seen for ROM is the ILAB OLC, originating from the Isles mud and written by Surreality, whose contribution to the mud community has lived on long past his untimely death at a very young age in 1996. Ports have been made to Envy, Rom 2.3 and Rom 2.4 amongst others. Perhaps the two most commonly used ROM OLC's are Beowulf's and Ivan's 2.4 ports of ILAB, available from the sites seen in section 8.4.
Whether you need/want an OLC is a very individual decision, many would
never do the old way of building again, others feel the inclusion of an
OLC causes more problems than it solves. Possible advantages of using an
OLC are:
- The interface to building is easier to use than offline building
- The builder sees their area take shape around them, potentially very
much more rewarding
- Problems in the areas can be easily changed online without rebooting
the mud
- It is much easier for a team of builders to co-operate on an area
- The mud implementors don't have to spend time correcting bad area
files
Possible disadvantages not to use an OLC are:
- The ILAB OLC is to some people far from easy to use
- An OLC is a very large patch, and adding this can cause major
instabilities in your code for a while until it is shaken down (less true
now with packaged OLC's such as Ivan's)
- Security can be a major concern- builders can easily abuse their power
- It can be argued that off-line building gives the builder a more
thorough understanding of what they are doing.
There is another alternative, in the packages intended to make off-line
building less tedious. MZF (Make Zones Fast) is a windows program praised
by many as providing a nice interface to area building that still frees
the mud admins from the problems of an OLC. However, MZF and programs of
it's ilk can be limited in that they can produce area formats of the most
popular mud code bases. If you have significantly altered how your area
files are structured then this may not be an option.
The request for a Colour patch is possibly the most frequent seen on the ROM list. There are a number of these, the 2 most popular probably being Lope's patch and Wrecky boys. They are available from the sites in section 8.4.
Both support the ANSI colour codes, which will mean 16 colours total (bright and dark shades each of 8 colours), and possibly flashing text, though how successful people have been getting this feature to work is limited. Perhaps the biggest difference between the two patches is that Lope's is more of a complete system, whereas Wrecky Boy's provides you with the functions to interpret colour codes, the code to add these to the mud and provide player customisation support is left to you to code. If you want colour quick and fast then Lope's is perhaps better suited for you, those of you who want your own colour system will get better results by using Wreck's code as your colour engine.
See also section 7.14 on the topic of why you are limited to very few colours and can expect great variations on how well they display to users.
One of the most common complaints about muds is how there is little interaction between the mud world and the player. Mobs are most criticised, the description of them as "boxes holding equipment that can be hard to open" is often quite sadly accurate. Special procedures as found in ROM provide a little life to some mobs, but these require hard coding for every such procedure required.
Mobprogs are a system whereby mobs can be assigned actions to perform in certain situations, say greet a character when they enter the room, and this information is stored in the area file, thereby being much easier to change, especially if OLC support is added for them.
Mobprogs can add life to mobs, but the system is not without problems. The mobprog system originally used in Merc was found to be too buggy that it was removed from the code. A Rom 2.4 version of this system with a number of major bugfixes has been written by Newt, available from the site in section 8.4. Some people have still found problems with this system though.
Perhaps the most important point when considering mobprogs is the fact that they are a tool that when used well can give an added degree of atmosphere, but can be used badly and badly overused. Judicious application of well-thought out and designed mobprogs can liven up your mobs considerably though.
In a word- LOTS. Your best bet is to browse around the sites found in section 8.4, but you can expect to find new skills, more efficient replacements for various parts of the code, inter-mud communication packages and much more besides. A lot of people have contributed major work to aid the mud community in general.
Again, many areas have been publicly released, and you are free to add these to your mud. To add a new area to your mud, simply place it in your area directory and add it's name to the area.lst file found there. Make careful note of the area file format however.. you may have to use something like MZF to convert say an Envy area to Rom 2.4 so that you can use it.
You should consider looking at RomLama which is a library of Rom areas that are given to anyone who submits a original area to the distribution and who is in compliance with all Rom licences.
Most patches come in a format that allows their inclusion to your mud to
be done automatically by a program called 'patch', found on most unix
systems and available for other platforms. The code patch should come
with instructions, but the general method of patching is to copy the patch
file into the directory that contains your source files, and typing :
patch < patch_file_name
You should *definitely* backup your code before ever trying to patch in new code, as it is possible to mess things up in quite spectacular ways, and you don't want to lose valuable work. If the patching goes smoothly, then you should just have to recompile the code and away you go. If the patch failed on some of the chunks, then you may have to add these by hand. If a patch for comm.c failed, then the rejected parts of the patch will be saved in a reject file called comm.c.rej, and you will need to look at this file and attempt to determine where the patch should go. Patch is quite clever, it can work on modified code, but its methods of attempting to determine offsets, looking for narrower context and such can sometimes fail, and this will happen more frequently if your code is changed greatly from the original source the patch was made against. Patching by hand is your only alternative in these cases. It can be laborious, but it also means you get to see the code you are adding in detail, something you should always do anyway.