We all know the classic way of making player classes: Players choose a hole to drop into, and they land on a pile of weapons, ammo, medkits and batteries. If you wanted you could also give certain players greater movement abilities by supplying them with barnacles or longjump modules.

However, with Sven Co-op 4.5, the ways you can customize players classes has been greatly increased. The following is a short tutorial explaining the most interesting possibilities. However, anyone with a creative mind should easily be able to think up a ton of new ideas not included in this tutorial.


The first step.

Whatever you plans are, the first thing you should be doing is to give the players of each class a specific targetname. This is done simply by having a trigger_multiple that targets a trigger_renameplayer, and specifying a name for the class. The trigger_multiple could be placed in a hole with a sign saying "Heavy" above it, and the targetname could then be "heavy", as an example.


Setting max health, max armor, and max speed.

So now the player has decided he wants to be the Heavy class. Traditionally this means that he will have extra armor and extra health, but move at a slower pace.

A simple way to set this up would be to create a trigger_relay with the same name as the trigger_renameplayer, and set its target to 3 trigger_changevalues with the same name. They should all have "heavy" set as their target.

The first trigger_changevalue:
Set keyname to max_health and set new value to 250. All players with the targetname heavy will now have 250 max health.

The second trigger_changevalue:
Set keyname to armortype and new value to 150. All players with the targetname heavy will now have 150 max armor.

The third trigger_changevalue:
Set keyname to maxspeed and new value to 200. All players with the targetname heavy will now have a max speed of 200. (default is 270)


Visually marking classes.

So how will players be able to see who is who? Aside from things like weapons and movement speed, it is possible to apply specific render settings to player classes. Simply have an env_render target the player targetname of your choice and configure it. You can give players a holographic render fx, make them transparent, or give them colored glow shells.

The glow shell is probably the most suited option for distinguishing player classes. To set a glowshell, set the render fx to glow shell, the fx amount to the thickness you want the shell to have, and fx color to the color you want it to have.

Some servers allow players to select a glow for themselves. This may override your own glow. I haven't checked though. The server glow can possibly be overriden by having a looping multimanager trigger your env_render every 1 seconds.


Class specific abilities.

By using targetnames for classes you also open up for another possibility: Making certain things only triggerable by players of a certain class. You could make computers that can only be hacked by a Hacker class (even opening the possibility of teleporting the hacker to "cyberspace" ala Dystopia), a detpack that can only be planted by a Demoman class, or a Sentry gun that can only be built by an engineer class.

Let's say you want a computer that is only hackable by a Hacker class. Turn the computer into a func_button and have it target a trigger_condition. The trigger_condition should have Cyclic ticked as a flag. Entity to monitor should be "!activator", watch key should be targetname, value to match should be hacker. True target should be an entity that "hacks" the computer, and false target should be left untouched. Make sure the button can be retriggered in case someone who is not a hacker uses it first.

The computer will now only be hacked if used by a player with "hacker" as targetname.


Attaching stuff to players

None of this stuff doing it for you? You want classes that provide a healing aura for nearby players, or a group of players with env_beams attached between them destroying everything in their path? Fine.

Healing aura:

In order for this to work there must only be 1 player with this specific targetname. To prevent multiple players from using the class simply block access to the class after the first player selects it. You can create multiple players with healing auras, but I won't get into that here.

Create a trigger_hurt with negative damage. Create a trigger_setorigin with flags Constant and Copy XYZ axis. Set target as your trigger_hurt, and copy pointer as your player.

Youre done.

Note that doing this will place the "target" directly at the players origin. If you want your target to stay at the same distance from the player, tick the flag "offset difference".


Env_beam stuck to 2 players:

This assume you have 2 player classes with only 1 player in each.

Create an env_beam as you normally would, but set Start Entity as class1, and Ending Entity as class2. Activate the env_beam once both classes have been filled.


Dealing with quitters

Let's say you have class that is absolutely vital to the game, such as the Main Jumper in jumpers. What happens if he leaves? You could either open the class for another player or end the map.

In any case, what you need is a game_player_counter with min value set to 0, min target set to "playergone" and Filter player targetname set to the class you're dealing with. The entity "playergone" will either trigger a game_end or open the class for other players.

I can't say for certain as I haven't tested it, but it's possible the map may end before any player is even given the targetname. In that case, what you should do is to make the game_player_counter target a game_counter with a master, and then trigger the master once a player has been given the targetname.


Custom weapon damage

You can exit smartedit in any weapon_ entity and add the key "dmg" with value set to any number you please. This will override the skill.cfg settings for this particular weapon, setting the damage of the weapon to what you want. Useful if you want classes to have a different melee weapons based on the crowbar for example.