Section 1: What is a Mutator
Section 2: What is the Purpose of this Tutorial
Section 3: The Design Phase
Section 4: Configuring Your Mutator
Section 5: Mutators Don't Have to Player Nice, but they should...
Section 6: The Mod Menu
Mutators are special classes which modify the game being played in some way. Normally, mutators are single minded in their goals, such as just making the players fat, or reducing the gravity. Mutators also have another sellling point. They can be linked together, provided they are properly written. This allows you to more fully customize your gaming experience. For instance, it allows you to be fat AND have low gravity. There is a limit to a mutator's ability to change things around, but there are still lots of really cool things you can do with it.
2) What is the Purpose of this Tutorial?
I've seen a lot a people attempt to write mutators, and I've seen a lot of people do some things which can cause problems. The purpose of this tutorial is to explain some features which may be overlooked, as well as provide a nice little list of Do's and Dont's for the aspiring mutator developer. Don't just think of this document as a tutorial...think of it as a style guide.
What this tutorial won't do, unfortunately, is tell you how to use UnrealEd to make classes. The focus of this tutorial is mutators, and nothing but. I don't want to bog things down with extraneous information. This tutorial assumes that you can examine the code from the built-in mutators to figure out the basic outline of how a mutator works. There isn't any hand-holding in this document.
Mutators allows coders a lot of freedom in what can be done. However, one of the most important aspects to keep in mind is that mutators should be limited in scope. If you make them do too much, they won't work well with other mutators. If you provide configuration windows and menus, then you are complicating the process too much. A mutator should be something that is added to a game to change one particular aspect.
Don't create a mutator which replaces every weapon in the game with a new one, then modifies the game so that you only have 3 lives. First, the mutator really does two things. It replaces the weapons and modifies the game. What if the player wants to just use the weapons, or just wants the 3 lives aspect? That should really be two seperate mutators. If you absolutely think the two go together, then you are better off creating a GameType and not a mutator. GameTypes can't be linked together, and therefore are more suited for coherent game playing experiences. Mutators mutate. They aren't meant to be the end experience.
Second, why replace all the guns? What if the player wants to only use one or two from the set, and keep the normal guns? What if the player wants to mix and match guns from different mutator sets? The simple answer here is to split each weapon up into its own mutator. This is similar to what Epic did with the Relic mutators. Rather than having a single Relic mutator, there is a mutator for each relic. That way, you can select which relics you want to add into the game at the mutator window. This rule can apply to anything which has several options that are either on or off. For instance, if you made a mutator which added in monsters to a deathmatch level, you could create a mutator for each monster type. This saves you from having to create an unwieldly configuration dialog.
When creating gun mutators, try to replace the gun which is most similar. The weapons in UT are fairly balanced in that the different weapons appeal to different styles of play. There isn't a whole lot of need for two sniper-esque weapons. Also, the player is guarranteed to be familiar with the default weapon set. By keeping in sync with that (sniper rifles are weapon 9, melee is weapon 1, pistols 2, etc), the player can quickly handle any new weapons you can throw at him. This also has the side effect of the player being able to decide which weapons he wants. He can take the sniper rifle from the realistic weapons pack, and the pistols from the sci fi weapons pack. He can mix and match to his hearts content.
You may want to release a whole bunch of melee weapons. For instance, you may want to release a pack with swords and maces and stuff like that. Since there is really only one melee spot, what you should do is provide two ways to get at the weapons. First, provide mutators for every weapon which replaces the default melee weapon. Second, provide a GameType or second Mutator which replaces all the weapons with those mutator weapons. By doing this, the player can decide whether he wants to choose one weapon from the bunch, or just use the bunch as provided. Remember, the point of mutators is to make the game more flexible, not less so.
Finally, if you are significantly changing the gameplay, you might be better off with a GameType. It allows you to do things that mutators don't, and it is completely apparent to the player that gameplay is different. The one problem here is that if you want to change each GameType (Deathmatch, Team, CTF, Assault, etc), you need a new gametype for each kind. In this case, you obviously aren't modifying the game at a basic level (CTF isn't going to change into Assault), so this is an area where mutators are better suited. You would also need a new GameType for each of those. If everyone released 5 gametypes for every little modification, things could get really ugly. I'll leave it up to your judgement. But if you do a GameType, please see my gameType style guide tutorial first (coming soon).
One thing about Unreal Tournament is that it allows developers to create UWindows (the built in GUI) to allow customization of mutators and mods. You can add in a menu item on the Mod Menu which allows the player to open up this configuration. My suggestion concerning this is simply: DON'T DO IT. If you've kept your mutator simple, and followed my other suggestions, then you shouldn't need to configure anything. Mutators shouldn't be configured. It is an entirely unwieldly experience selecting a mutator and then configuring it each game.
If you've got some options, and multiple mutators or a GameType (which can be configured from custom settings and rules windows) won't cover it, then you could just not make them options. If there is a choice on a subject like how many lives you get, there are several things you can do. You can provide several mutators (3 lives, 5 lives, 9 lives), or you could just hardcode what you think is the best option (5 lives?). If they player never realizes he has a choice, he won't miss not having one.
Say you have a mutator which allows you to change certain attributes of the player. You can select any fatness number you want, and drawscale number, and things like that. Being able to type in any number may seem really powerful, but it is just making things harder for the player. Think about it. What kind of fatness will the player try. He will try skinny, not so skinny, really fat, and pretty fat. You don't need to allow the player to select a fatness of 100.45. Same with scale. The player would want to play at half size, and probably at slightly larger than normal (double size is too large).
Ultimately, the plan is that mutator space is cheap. It takes two seconds to search a list and select a mutator. It takes considerably longer to open a dialog and configure it, especially when you have numbers to type in. It is regrettable that Epic didn't allow Mutator lists like it has Map Lists. That would be a good project for someone to look into.
5) Mutators Don't Have to Play Nice, but they should...
In some functions, you need to make sure you call the parent mutator's function. Some of these just call the next mutator in the list, but even that is important. If you fail to call the next mutator, then it won't work properly. People will think it is a flaw in the other mutator when, in fact, it is your mutator with the flaw. Try to work with other mutators when at all possible. You'll be glad you did. Remember, if a mutator isn't nice, you never know where it will be in the mutator list. It could be first, or it could be last. All this means is that some other mutator might have removed items you need long before the flow even gets to you.
Some mutators don't play nice. For instance, the Arena mutator remove all the weapons in the game and give the players a single type. This can lead to some incompatibilies with other mutators. For instance, try running InstaGib with Guns Akimbo mutator, and bad stuff happens. The thing about Arena mutators is that they do something really simple and to the point. However, this can affect other mutators. I suggest that if your mutator does something that can cause problems, you put it in the readme file. Before you release your mutator, test it will all the mutator that come with Unreal Tournament and test for compatibility issues. If you are feeling really lucky, test it with popular 3rd party mutators too. It never hurts to be too cautious.
If you absolutely feel the need to put a menu item into the mod menu, there are some style tips that I suggest. First, don't do it. The larger the menu gets, the less effective it becomes. By putting in a menu item, you are potentially making the player's life harder. Mutators should be so simple that they don't need menu items. If every mutator released had some configurable options, there would be hundreds of items on the mod menu! Hundreds! I know UWindows is a neat thing, and using it makes your mod look more professional, but ultimately, if you don't need it, don't put it in. Even mod authors who create new game types can put configurable options in the game settings and rules tabs in the game creation dialog.
Don't take up more than one mod menu item. It should go without saying, but don't take up more space than you need. If you have several configurable options, it would be better to have a single window with tabbed pages for each option set. If you want, you can even create a window which will open and allow you to have your own menu bar. The window could even display a nice logo or something. Don't think your mutator is more important than anyone else's.
For your one menu item, name it something short and to the point. If your mutator/mod is called "Terminator", call the menu item "Terminator". Don't bother putting things in the menu title which confuses it, like "Terminator Options" or "Configure Terminator Mutator". Just the single word is more than enough to convey what mod/mutator that menu pertains too. Oh, and don't use abbreviations in the name, if at all possible. I've downloaded mutators that had one name, and their mod menu title was something completely different. As it is, I've got mod menu items I have no idea where they came from or what they do. Avoid this.