Now, this isn't much different than some of the other mutators out there, but what I do, is I included feed back into the equation for handicapping and I think it works quite a bit better. It keeps it competitive and fair. Additionally, I included menus for fully customizing the "impact" of each handicap (in other words, maybe you want to only handicap on Health, or maybe you want to handicap heavily on visibility and not as hard on health). You can also scale the maximum and minimum limits for each category.
Here is the equation used for "handicapping" everytime a player/bot respawns:
player/bot scale = ((Other.PlayerReplicationInfo.Score - min) / (max - min)) * (1.0 - (min/max));
Where min and max are all other player/bot's min/max score (so the play spread) and
then the player/bot in question's score.
Attribute = MinAttribute + (((MaxAttribute - MinAttribute) / 2) * (1 (+-) ((2*scale - 1) * AttributeImpact)));
Where you basically scale from the midpoint of the user selected MIN/MAX based on the overall
"scale" of their score and the impact. In otherwords, if you were the play leader, and the User
selected Impact was set to 100%, then you would have either the minimum or maximum value for a given
attribute depending on if it was a "good" attribute or a bad one.
So here is an example. Player A, B, and C are in a game with handicap mutator running. Mutator config is for min of 30 health, max of 150 health, 80% impact and 0% impact on all other handicap stats. Player A is in the lead at 10 frags, Player B is at 2, and Player C is at 7. Player A will respawn with health of 61 (which is the result of the handicap by the above 2 equations) and Player B will respawn with health of 126 (which is an 80% max impact above the center of 30-150, which is to say it is 30+[120*80%]). Player C will have health of perfect center (i.e. no handicapping at all), which is 90, or 30+(120/2), in this case.
The main reason for all of the "dividing" by the player range and looking at the min score is that a bout between Player A with 10 frags and Player B with 0 is FAR different than a bout that is Player A with 100 frags and Player B with 90 (but they are both 10 frags apart and would be treated the same under other handicapping mutators that simply increment or decrement the attribute in question every time there is a frag change). See how that screws things up and might inadvertantly give Player B an unfair LARGE advantage in an otherwise "close" match? This is a comon problem that the Fatboy mutator suffers from. It is still possible for "cheating" or taking advantage of the handicapping equation to go on. I call it "sling-shotting" and need to sort of figure a way to prevent it. Basically, a player could artificially try to be the lowest scoring person just before the Frag limit, thus granting him the most health, speed, invisibility and thinnest model, then "sling-shot" into the lead with a massive number of frags gained from his artificial handicap. This is because the new attributes only take effect on you at the time you respawn, and not each time you kill another. In future release, I am going to try and trap for "rampage" kills (say 5 in a row or more) if you were the "minimum" frag score holder at the time of your last death. If this happens, then I will immediately call the routine to "recenter" your attributes at that time. Bottom line, is that no handicap should have 100% impact if you want a good game. And speeds of 1 should not be picked because it gets to be a very slow and boring game. I've set some defaults that should work fairly well (be sure to configure it the first time and click "DEFAULTS" on each attribute, then save them). I'm going to play test it pretty hard this next weekend and may do some "on-the-fly" tweaking, so look for a new version in late January.
All you have to do is pick "mutators" from the Start Practice Match menu, and double click or drag the "Handicapper" mutator over to the right screen. A new menu should also appear on your Unreal Tournament main menu bar, called "MODS". Under this, you can fully customize the Handicapper in all 4 areas of:
Many thanks to Tim Sweeny, Brandon Reinhart a.k.a. GreenMarine (brandon@epicgames.com), Jpb (jpb@planetunreal.com), Squidi (howard@mailer.fsu.edu), Bane (bane@unrealized.com) and planet Unreal (http://www.planetunreal.com) for all of the community development support. This is my first mutator, and it was a bit confusing, simply due to the lack of any real compiled source with good documentation. I also spent god knows how much time trying to learn how to use ucc and fix some STUPID warnings in a default properties area simply because UCC didn't like SPACES or TABS between the variable and the equal signs, as well as it didn't like SEMICOLONS in the default prop area...stupid...
Copyrite Jeff McClain, 2000. Don't use this for commercial/profit purposes without the author's express written consent. You are free to look at the code and use for learning purposes.
Send all comments, questions, etc. to jmcclain@micron.net
v0.90 - The Initial Release without any user configurable menus. Never publicly released.
v1.00 - Added user menus and tweaked the handicapping calculations. Improved scale of useable ranges. Never publicly released.
v1.01 - Managed to put in a few more tweaks to many different game play conditions, tested on server, polished help bar text. First Public release.
v1.10 - More tweaks on the starting values and conversion to a .umod distribution.
v1.11 - Updated the default values of some of the things. Also fixed a bug in the VISIBILITY handicapping. Redoing the .umod, since many have had problems with it.
Make the class more inherited to abstract common code up into the parent. This should make it easier to add "new" handicap items. Improve responsiveness to team games.
(C) Jeff McClain 2000