Appendix
- The Mutator Class
1) What is a Mutator?
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.
3) The Design Phase
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).
4) Configuring Your Mutator
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.
6) The Mod Menu
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.
Appendix:
The mutator class in
detail
