*Note: I created the most of the tutorials using the Roboblitz and Gears of War editors. Based on the engine, and the version, some properties specified may be in slightly different locations than what is displayed in the screenshots.

If you need to learn how to create a basic map I would reccomend:
For UT99, UT2K3 & UT2K4: the Unreal Wiki.
For UT3: Waylon's Tutorials.



Prologue - SinglePlayer/Co-op/MultiPlayer

When setting up Kismet, it's very important to consider where the player, or players will be, and the impact they'll have on the events. A default trigger, for example, will only fire once, and with one player, that's simple to set up. But what if there are 10 players in the level and you need it to fire only when there's a player in a certain area? What happens when 6 players enter, but only 3 leave? What happens when all 6 leave? What happens when 5 leave but one dies in the area? There are many considerations to make and 'fortune-telling' to do.
Single-player with no co-op is the easiest to deal with since there's only one player and you can predict where they'll be with ease. However, singleplayer can get a little more tricky if you have game-controlled AI NPCs on your team - then you'll have to treat the Kismet more like a Co-op game.
Co-op would be the next stage in difficulty because you now have more than one player, but on the other hand, there probably won't be very many. However, you'll probably also have to take networking into account.
Multiplayer is the most difficult because you don't know how many players will be in the level, although you'll usually have a maximum you'll know about. Also, there many be networking considerations to take into account.

Singleplayer:
When considering Kismet for SinglePlayer levels, some of the questions to keep in mind are: Where is the player now? Where will the player be? Can this help the player get out of the world? Can the player out-run this? and Can the player break this?

In Kismet:
One of the only Kismet-specific properties you'll need to worry about is the 'PlayerOnly' boolean and the 'ClassProximityTypes'. Depending on the engine, checking and unchecking the 'PlayerOnly' property should control if the player, or the player and any NPC, can set off the trigger. If both NPCs and the player set off the trigger while this is checked off, then you'll probably be able to designate only the player through the 'ClassProximityType' drop-down list. The ClassProximityType might also be able to help you designate 'friendly' versus 'Enemy' teammembers.
Another setting in some other Kismet entities is the 'AllPlayers' boolean. This can cause trouble in entities like the Teleport Action where, if this is checked off, will teleport not only the player, but, depending on the engine, all the AI as well - which leads to the hilarious, but unfortunate result, of everyone in the level suddenly telefragging everyone else as they're all teleported to the same location. Just something to be careful of. :)





Co-Op/SinglePlayer with 'Friendly' AI NPCs:
When considering Kismet for Co-op levels or singleplayer levels with friendly AI NPCs that can also set off the same Kismet as the player, some of the questions to keep in mind are: Where are the players/AI now? Where will the players/AI be? Where are the Players/AI spawning? Can this help the players get out of the world? Can the players/AI out-run this? and Can the players/AI break this? Are the Players/AI taking different routes and if so, will one path have an effect on the other?

In Kismet:
The base Kismet-specific property you'll need to consider is the 'PlayerOnly' boolean and the 'ClassProximityTypes'. Depending on the engine, checking and unchecking the 'PlayerOnly' property should control if the player, or the player and any NPC, can set off the trigger. If both NPCs and the player set off the trigger while this is checked off, then you'll probably be able to designate only the player through the 'ClassProximityType' drop-down list. The ClassProximityType might also be able to help you designate 'friendly' versus 'Enemy' teammembers and/or Co-op players.
As mentioned above, keep an eye on the 'AllPlayers' boolean in some Kismet Entities.

More advanced considerations might be waiting for X number of players to be in a location before triggering something, or perhaps activating a sequence when one player reaches a point, and then teleporting other players to a designated location to 'catch up' with the first player. For both of these the problem is letting Kismet know how many players are playing, and then adjusting the 'count' accordingly. As of now, I know no way of doing this reliably. One method could be to place a trigger or trigger volume around the initial spawning area, and making a one-time initial count of players, and then propagating that number through the rest of the Kismet sequences. However, what if 3 players join, and then 1 leaves the match? The counts would be set for 3, but if only 2 players ever make it to the later trigger, then it will never go off. You could maybe add a timer that would fire the trigger regardless of player count, but then, why not just do that to begin with?



MultiPlayer:
When considering Kismet for MultiPlayer levels, some of the questions to keep in mind are: Where are the players now? Where will the players be? Can this help the players get out of the world? Can the players out-run this? and Can the players break this?

In Kismet:
As described above, you'll want to keep an eye on your 'PlayersOnly' boolean, 'AllPlayers' boolean, and your 'ClassProximityTypes' in your Kismet as these can easily foul any attempts if you set them incorrectly.

There is much to consider when setting up multiplayer Kismet - too much to cover in one tutorial as they're all extensions of logic statements: too many 'if...then's. But I will examine one situation here:

If you are planning to set off any Kismet events that keep track of a player/players being in and/or out of a specific area, you'll need to put some serious thought into its execution. Say 6 players are in a map, and in one area, you want to fire off some ambient noise and emitters - but only when players are there. You'll need a system to detect if players are in that are or not. This sounds simple - if players are in, then do x; if players are out, do not do x. Sounds like a simple yes/no or on/off system - a boolean system. At heart, yes it is. But we cannot use booleans to trigger this. Examine the image below - it seems like a set that will tell whether or not players are in a trigger's radius. If we hooked a compare up to the trigger, would it not tell us that when a player enters, that the boolean gets set to inside, so the 'true' would fire, and the sequence would begin? And if a player leaves, the untouch would set the boolean back to false, and a compare would show false and turn off the system? Well, with one player - yes. With multiple players - no.



Let's keep the example simple with two players. If player1 enters the system, the boolean is set to true, and if a comparison is run, the event would fire as true. If Player 1 leaves the system, the boolean is set to false, and a compare would shut down the system. Well, that's ok. If Player1 AND Player2 enter the system, the boolean is set to true twice. When a compare is run, it will turn up as true, and the event would fire. But what if Player1 leaves, and Player two stays? The trigger's untouch event would fire when Player1 leaves, and the system would shut off while player 2 is still in the area. Therefore the system is broken.
What we need is a system that will keep track of how many players enter, and how many exit. In essence, we need a counter that will cause an event to fire when a count is greater than 0, and will stop the event when the count equals zero. Here's the setup for this system:



In the image above, the trigger events are all set to an infinite number of touches (0) and the two counters keep track of the number of players in the system. In the top counter, the increment is set to 1, which means that whenever a signal comes in - whenever the trigger touch event fires - 1 is added to the A value. Likewise, the increment amount on the lower counter is set to -1. This means that 1 is subtracted from A whenever the trigger's untouch event is fired. So the A value will go up and down depending on the number of players that enter/exit that trigger's radius. The B values in the counters both stay at 0 because we're going to use 0 to designate the trigger as 'empty' or 'no players present'.
So let's follow the path here. Player1 enters the trigger and the Touch event fires. A signal enters the top counter, and A's 0 value is increased by 1. A = 1, B = 0, so the Int Counter fires the event 'A>B' which, in turn, turns on the toggle. If Player1 leaves, the 'untouch' event fires, and, based on the lower counter, 1 is subtracted from A. Therefore A = 0, and B = 0, so the A==B on the lower counter fires, thus turning off the toggle.
If Player1 and Player2 enter the trigger radius, the trigger Touch event is fired twice, thus making A = 2. Since A > B, the toggle turns on. If Player 2 leaves, the 'untouch' event is fired once. So A = 2 - 1, which is 1. Since A > B on the lower counter, nothing happens because nothing is hooked into that output so the toggle stays on. Now A = 1, and when Player2 leaves, the untouch event fires, A = 1 - 1, which is 0 and since A = B now, the event fires and the toggle turns off.
In logical terms, the system above should function properly but it needs more testing. I have not tested it online, and I don't know what would happen if a player died while in the radius - would that count as an untouch? I expect so but I have not verified it.

I hope this has helped demonstrate the kinds of ideas that you need to consider when workng with the different gametypes available - especially multiplayer. Good luck!