|
|
| (One intermediate revision by one other user not shown) |
| Line 1: |
Line 1: |
| − | ==General ==
| |
| | | | |
| − | In general, a Jailbreak map is similar to a [[Legacy:CTF|CTF]] in that both teams have a base of some sort which contains a valuable target. The main difference is, of course that the flag has been replaced by a jail release mechanism, and that this jail release mechanism only becomes a viable target when one or more of a player's team mates have become captured.
| |
| − |
| |
| − | The differences in gameplay have several consequences for map design as well. These are strictly conceptual guidelines, not a must of any sort. Because there is no true "objective" until a team mate has been imprisoned, there should be a motivation for a team to venture out of their base, other than reaching the enemy's. This motivation could take the form of a weapon not available in the bases, a powerup, or the like.
| |
| − |
| |
| − | As always, everything to do with red is 0 and blue is 1.
| |
| − |
| |
| − | ==Areas ==
| |
| − |
| |
| − | ===Base ===
| |
| − |
| |
| − | Each team needs a base. This needs:
| |
| − | * a jail release mechanism
| |
| − | * player starts, set with JBPlayerStart actors. Note that Jailbreak never uses the regular PlayerStart class.
| |
| − |
| |
| − | This is much like a base for [[Legacy:CTF|CTF]] – anything goes. However, due to the fact that a player, upon simply reaching a release mechanism, has accomplished his goal and does not have to return to his base in order to score, the mechanism or the complete base may be better defended than it would be in a CTF, since a player only need pass the defense points once.
| |
| − |
| |
| − | Also, successfully invading the base doesn't score a point, in ''prohibits scoring'' for the enemy team. So whereas a base that is easy to attack in CTF produces high scores and fast action, in Jailbreak it will tend to result in a null tie and a dull game.
| |
| − |
| |
| − | The jail release mechanism is an actor of the class TeamActivatedTrigger. Specifics on this actor are given on the [[Legacy:Jailbreak/Classes|Jailbreak/Classes]] page.
| |
| − |
| |
| − | Placement of PlayerStarts is not as important as in CTF: players will only spawn there at the start of the game and on release from the arena. At all other times they spawn in jail and walk out upon release.
| |
| − |
| |
| − | The viewpoint can be made to follow an [[Legacy:Interpolated Path|interpolated path]] or attached to a mover (see [[Legacy:Mover Topics|Mover Topics]] for more).
| |
| − |
| |
| − | ===Jails ===
| |
| − |
| |
| − | The map needs two jails. These each need:
| |
| − | * A JailZone actor to define the zone
| |
| − | * A JBViewpoint actor which sets the capture viewpoint for the scoring team
| |
| − | * A means of exit which is triggered by the jail release mechanism, a TeamActivatedTrigger actor
| |
| − | * player starts, set with JBPlayerStart actors. These need the bJailedStart flag set. It's good design to set these facing the exit, so players that are killed moments before the jail doors are about to close can run out.
| |
| − |
| |
| − | A jail should be sealed insofar that a player, without help and without the use of a translocator, but with an impact hammer should not be able to leave the jail. The exit, triggered by the jail release mechanism can be a simple door, but could also be a kicker, a slide, or what not.
| |
| − |
| |
| − | To ensure correct bot behavior, players should be able to leave the jailzone within five seconds of the release mechanism's activation. This is due to the fact that a bot, upon releasing his teammates, cannot 'see' the release mechanism for that period of time to prevent him from incessantly triggering the mechanism until everybody has left the jailzone.
| |
| − |
| |
| − | Although no doubt entertaining, it is probably inadvisable to create jails in such a fashion that an outside player can kill its inmates (although a kill on an already imprisoned player does not count towards your score).
| |
| − |
| |
| − | :'''Tip:''' If you want to have the jails disregard you for testing purposes, enter <tt>set PlayerPawn bIsPlayer false</tt> at the console. With that you can safely "ghost" into jails and the arena to watch your bots without being subject to those special zones yourself. (To revert the change, enter <tt>set PlayerPawn bIsPlayer true</tt>.)
| |
| − |
| |
| − | ====Placement ====
| |
| − |
| |
| − | The jail area need not be placed directly adjacent to the release mechanism. This mechanism will often be deep within an enemy base, and placing the jail too deep in the enemy base will only lead to a carnage immediately after the jailed prisoner's release. Rather, released prisoners should have a reasonably safe route back to their own base, so they may regroup in relative peace and mount a new assault. If placed between bases, the jail exit should probably face away from the enemy base, so that snipers will not immediately shoot the heads off the escapees.
| |
| − |
| |
| − | ====Style ====
| |
| − |
| |
| − | Weaker players may spend quite some time in jail. Some ideas to alleviate the boredom of hard time:
| |
| − | * sculpt and place the jails in such a fashion that a jailed player has a good view of one or several key points in the game
| |
| − | * add map [[Legacy:Screen|Screen]]s or [[Legacy:CameraSpot|CameraSpot]]s so players can watch the action
| |
| − | * add [[Legacy:Screen|Screen]]s with web pages, server stats or IRC channels.
| |
| − |
| |
| − | ====Death ====
| |
| − |
| |
| − | When all players of one team are held in their jail, the game marks a point, kills them & shows the carnage to the scoring team players. However, it's possible to enhance the standard gibbing with a custom death scene.
| |
| − |
| |
| − | If the game finds something that's triggered by RedCaptured/BlueCaptured, the standard gibbing after 4 seconds is disabled and the game expects the map to kill the prisoners. After ForceKillAfter seconds, they're gibbed anyway.
| |
| − |
| |
| − | ====Viewpoint ====
| |
| − |
| |
| − | Each jail needs a JBViewpoint actor.
| |
| − |
| |
| − | Quote from the JB forums:
| |
| − |
| |
| − | The camera starts at the InterpolationPoint with Position=0 and moves along the path. When it arrives at an InterpolationPoint with bEndOfPath=True, it stops; otherwise it loops when it arrives at the last InterpolationPoint in the path.
| |
| − |
| |
| − | * To reiterate, if no path is present, JBViewpoint actors simply behave like before; that is, they sit there and don't do anything.
| |
| − | * To make a path work with JBViewpoint actors, the individual InterpolationPoint actors' bNoDelete property must be set to "True." If it isn't, the JBViewpoint will refuse to use this path (and state so in the log). The reason for this is replication-related.
| |
| − | * Since the players that were subjected to the death sequence start watching from the JBViewpoint much later than the players from the capturing team, I have introduced a new JBViewpoint property comprehensibly called "StaticCameraForDyingTeam" (defaults to "True"). If set to "True," members of the captured team will have their viewpoint set to the JBViewpoint's original location without any movement; if set to "False," they'll perform the same camera movement as their capturers, starting when they switch their viewpoint.
| |
| − |
| |
| − | A different matter is that you can also (successfully) attach a JBViewpoint to a mover now (Beta 5). If you have a normal mover that rotates back and forth, so will the the JBViewpoint. If you need rotation in pitch and roll direction too, you might need El's [[Legacy:ActorAttacher|ActorAttacher]].
| |
| − |
| |
| − | Or, set the JBViewpoint's RotationRate and set bFixedRotationDir to "True" and Physics to "PHYS_Rotating," and the JBViewpoint will continuously revolve according to its RotationRate.
| |
| − |
| |
| − | ===Arena ===
| |
| − |
| |
| − | The arena is an optional component. It's possible to have more than one. Each needs:
| |
| − | * A JBArenaZone actor
| |
| − | * Two JBArenaStart actors, with their teams set.
| |
| − |
| |
| − | It should be an area of the map from which it is not possible to escape, or for a specator to fall in. Zone it off nicely, and watch out for those impact jumps.
| |
| − |
| |
| − | A subclass of ZoneInfo, JBArenaZone, tells the game where to host the fight and holds settings on how frequently to stage fights. Add to your arena two JBarenaStarts (subclass of playerstart). Set the teamnumber to 0 for the red start and 1 for the blue. Placing more than one JBArenastart for each team is futile, since the system will always grab the first one.
| |
| − |
| |
| − | There are a few more things to keep in mind:
| |
| − | * Don't trigger them too often. If you set them off too often, it may prove very difficult to get all the players in jail at the same time.
| |
| − | * Your arena can be as big or as small as you want, and can contain weapons or other pickups. However, all pickups stay in the arena and may not be kept by either player win or lose. You can have as many arenas in your map as you like. They don't conflict with each other and will summon players independently of each other. For best results, set their '''TriggerAfter''' property so that they're not all triggered at the same time.
| |
| − |
| |
| − | :'''Tip:''' If you want to have the arena disregard you for testing purposes, enter <tt>set PlayerPawn bIsPlayer false</tt> at the console. With that you can safely "ghost" into jails and the arena to watch your bots without being subject to those special zones yourself. (To revert the change, enter <tt>set PlayerPawn bIsPlayer true</tt>.)
| |
| − |
| |
| − | :'''Tip:''' In order to shorten the wait time between arena fights when testing (or debugging) arenas, here's a bunch of useful console commands that temporarily tell the arena to make fights as frequent as possible: <br /><tt> set JBArenaZone TriggerAfter 0</tt> <br /><tt> set JBArenaZone TriggerSeconds 2</tt> <br /><tt> set JBArenaZone NextTrigger 0</tt> <br />You can enter those commands at the console. For more convenience, you can also write them to a plain text file (called "arenatest.txt," for instance) and simply call with <tt>exec arenatest.txt</tt> at the console prompt.
| |
| − |
| |
| − | ==Weapons and Items ==
| |
| − |
| |
| − | When placing weapons, keep in mind that Jailbreak will probably be played with weaponstay off. (The Mothership servers have weaponstay on.) This adds weapons distribution as a strategic element. It also some way towards alleviating the imbalance between a team whose players are all free and one with members imprisoned, since relatively more weapons will be available on the side of the 'losing' team.
| |
| − |
| |
| − | ===Translocator ===
| |
| − |
| |
| − | Jailbreak equips players with a translocator but disallows its use on a zone by zone basis. To allow players to translocate into a zone, the [[Legacy:ZoneInfo|ZoneInfo]]'s '''ZoneTag''' must begin with the string "JBTransloc".
| |
| − |
| |
| − | ==Bot Support ==
| |
| − |
| |
| − | Pathnoding is very similar to [[Legacy:CTF|CTF]]. Bots use [[Legacy:DefensePoint|DefensePoint]]s and [[Legacy:AmbushPoint|AmbushPoint]]s. Also, bots will use altpaths, although the return only variable has no meaning in this context. Be sure to pathnode a route out of the jail.
| |
| − |
| |
| − | Again, much of the above is simply a guideline and is in no way binding.
| |
| − |
| |
| − | :Bots may have trouble finding the release switch. Try lowering it slightly, this usually fixes the problem.
| |
| − | ::This was an occasional problem in 205, may no longer be an issue with 300 →[[Legacy:Tarquin|Tarquin]]
| |
| − | :'''Tip:''' When spectating your bots to check their gameplay and your botpathing, sorting the scoreboard by bot orders is very handy: It displays all attacking bots at the top, all defending bots below, and jailed bots at the bottom. Simply press F1 to display the scoreboard and then press GreyStar [*] (by default; or the key you bound to "Switch compass/scoreboard order") until the status line below the scoreboard reads "Scoreboard sorted by <b>Orders</b>".
| |
| − |
| |
| − | ==Team Settings ==
| |
| − |
| |
| − | A quick run-down of the actors and settings required for Jailbreak to work. Remember to set the '''DefaultGameType''' in the [[Legacy:Level Properties|level properties]] to "JailBreak"!
| |
| − |
| |
| − | ===PlayerStarts ===
| |
| − |
| |
| − | The map must not contain any ordinary PlayerStart actors.
| |
| − | ; Main area : JBPlayerStart. Set JBPlayerStart -> bJailedStart = False
| |
| − | ; Jail : JBPlayerStart. Set JBPlayerStart -> bJailedStart = True Several are needed in each jail, maybe 4-6.
| |
| − | ; Arena : JBArenaStart.
| |
| − |
| |
| − | In all cases, set PlayerStart -> TeamNumber to 0 (red) or 1 (blue).
| |
| − |
| |
| − | ===JailZone ===
| |
| − | * Red Jail: holds red players prisoner. JailedTeam = 0
| |
| − | * Blue Jail: holds blue players prisoner. JailedTeam = 1
| |
| − |
| |
| − | ===Release Switch ===
| |
| − |
| |
| − | This is an actor of the class TeamActivatedTrigger. Set:
| |
| − | * isJailReleaseMechanism = true
| |
| − | * Team:
| |
| − | ** Defended by blue, releases the red team: Team = 0
| |
| − | ** Defended by red, releases the blue team: Team = 1
| |
| − | * Event so something happens to let players out. It's also a good idea to trigger some sort of visual cue so the player activating knows they have suceeded (a lever moving for example).
| |
| − |
| |
| − | ==Dynamics ==
| |
| − |
| |
| − | There are two main incidents that take place during a Jailbreak game: Release and capture. Both of these require a certain amount of work on the part of the mapper:
| |
| − |
| |
| − | ===Release ===
| |
| − |
| |
| − | The release mechanism at its simplest is an actor of the class TeamActivatedTrigger. Set ''IsJailReleaseMechanism'' to True so bots know that it is a jail release switch. It's the responsibility of the mapper to choose an Event name and thus tie the TeamActivatedTrigger to the relevant jail doors (or kicker, or whatever system releases players).
| |
| − |
| |
| − | Remember that the release switch located in the Red base must open the doors of the Blue jail to release the Blue players. For headaches induced by the whole red/blue thing, we recommend aspirin ;-)
| |
| − |
| |
| − | Note that you can also use a TeamActivatedMechanism for making simple team-specific triggers, like for a team-based armory.
| |
| − |
| |
| − | ===Capture ===
| |
| − |
| |
| − | The game automatically fires events 'RedCaptured' and 'BlueCaptured' when all players of a team are in the jail. If nothing is triggered by these, then players will be gibbed after a certain time (how much?). It's the responsibility of the mapper to make capture deaths more interesting by using these events to trigger something. Note that special JailZone subclasses which incorporate a death method (eg PressureJailZone) need to have their ''Tag'' set to either 'RedCaptured' or 'BlueCaptured' by the mapper to function.
| |
| − |
| |
| − | :'''Tip:''' Because the capture events are built into the game type, you won't see red lines connecting actors which are triggered by them. If you find this disturbing, or just to check things are properly connected, create dummy triggers either outside the level or set so nothing can collide with it & give them the each a capture event.
| |
| − |
| |
| − | ==Finishing Touches ==
| |
| − |
| |
| − | As well as a [[Legacy:Screenshot|screenshot]], a Jailbreak map can incoporate a Map Banner and HUD Skins.
| |
| − |
| |
| − | The map banner is displayed on the HUD during pre-play flyby. This is created by embedding one or two 256x128 textures in the [[Legacy:MyLevel|MyLevel]] package, named "SkinMapBanner1", and optionally "SkinMapBanner2" to make a wider banner.
| |
| − |
| |
| − | These textures must both be referenced in the map (by an actor, or discreetly on a surface somewhere) otherwise UnrealEd will discard them on saving.
| |
| − |
| |
| − | It is also possible to embed entire custom HUD skins in maps. See the [http://www.ph.tum.de/~mkath/jb/jbskintutorial.html HUD skinning tutorial] for details.
| |
| − |
| |
| − | ==Map Standards ==
| |
| − |
| |
| − | [[Legacy:ElBundee|ElBundee]] came up with the "'''Jailbreak seal of approval'''", a short list of useful things each Jailbreak mapper should take care of:
| |
| − | * DefaultGametype set to Jailbreak
| |
| − | * JBPlayerStarts in jail: at least 3 each jail
| |
| − | * JBPlayerStarts outside: at least upper IdealPlayerCount / 2 + 1 each team
| |
| − | * No normal [[Legacy:PlayerStart|PlayerStart]]s left
| |
| − | * Set all JailDoorMovers to "CrushWhenEncroach"
| |
| − | * Map Logo
| |
| − | * LocationStrings wherever possible for [[Legacy:Zone|Zone]]s
| |
| − | * Translocator support (if any)
| |
| − | * JBViewpoints ( = DeathCams): 1 each jail
| |
| − | * Arena (optional)
| |
| − | * Jail escape routes (optional)
| |
| − |
| |
| − | ==Other Things ==
| |
| − | * [[Legacy:AmbushPoint|AmbushPoint]]s (drat. It's [[Legacy:DefensePoint|DefensePoint]]s for team stuff?)
| |
| − | * use [[Legacy:MapScale|MapScale]] to make a reflection of one base
| |
| − | * [[Legacy:Screen|Screen]]
| |
| − | * [[Legacy:CameraSpot|CameraSpot]]
| |
| − | * [[Legacy:HeroStatue|HeroStatue]]
| |
| − | * HUD Skin: http://www1.physik.tu-muenchen.de/~mkath/jb/jbskintutorial.html
| |
| − |
| |
| − | ==See Also ==
| |
| − |
| |
| − | On the Unreal Wiki:
| |
| − | * [[Legacy:Jailbreak/Classes|Jailbreak/Classes]]
| |
| − |
| |
| − | On the Web:
| |
| − | * [http://forums.beyondunreal.com/forumdisplay.php?forumid=382 Jailbreak Mapping and Development forum]
| |
| − |
| |
| − | ----
| |
| − |
| |
| − | '''Mychaeel:''' How about calling this page "Mapping for Jailbreak (UT)" instead to stick with the convention?
| |
