Tempus New Map Standards

[Waldo]

With Jump Jam coming up I figured it would be good to make a centralized post with mapping guidelines. This is a pretty thorough but non-exhaustive listing of what we check for in new maps -- it's mostly distilled from existing process. This list is intended to streamline the vetting/finishing process for maps before zoning and we'll add to it if anything new comes up as a common concern or point of contention.

TECHNICAL CONCERNS
These are generally pretty easy to follow and are best practices for mapping, both from your perspective and ours. We won't strictly require all maps to follow all of these rules, but we'll defer zoning maps that could be fixed easily.

• INFO_TELEPORT_DESTINATION --- Use info_teleport_destination for all teleport destinations and not info_target or player_teamspawn or anything else. The Tempus plugin looks for this entity when assigning levels and it's also just standard.
• TELE DESTINATION HEIGHT --- Grounded tele destinations must be exactly 1 unit above the ground. 0 height leaves the player stuck in the ground, and anything higher than 1 forces telehops.
• TELE DESTINATION POSITION --- Tele destinations should be placed at the start of the jump; preferably not all the way at the edge or very far away. If making the jump ambidextrous is important, you can use renaming or split teleports to send the player to the appropriate side.
• TELEPORT DESTINATION ANGLES --- For soldier prefire jumps, angle the info_teleport_destination so it auto aims the player towards what he needs to shoot. Otherwise, keep the teleport view angle straight forward.
• CLIENT FLAG --- Make sure the client flag is ticked on all triggers that need to activate for players (e.g. trigger_teleport and trigger_multiple).
• FAIL TELEPORTS TOO LOW --- Don't put your fail teleports too far down where the player ends up falling for a long time when failing a jump. If needed, put one way teleports to help shorten the fall (good idea to filter them for demo usually, but that's case by case). Use this guide for one way teles: https://jump.tf/forum/index.php/topic,3272.0.html
• MOMENTUM CANCELLING CATAPULT --- Not needed in most cases, but if it's likely that the player is rising as they hit a tele (e.g. on a slanted floor) then there should be a 0-velocity catapult overlapping the teleport trigger to reset speed on fail.
• MULTIPLAYER FRIENDLY TELES --- Avoid having teleports that are enabled/disabled with triggers or buttons. This doesn't work in multiplayer.
• BUTTON SETTINGS --- If you use buttons, make sure to use OnDamage output without the damage activate flag OR if you do have it ticked then also tick the DONT MOVE flag. OnDamage will work independently from the flag, and if you have the Damage Activate flag your button will start to move when you damage it.
• OVERHEAL TRIGGERS --- Tempus and offline jumping plugins give players tick regen, so these aren't usually needed. If you want to use them for demo, let us know.
• CONSISTENT AUTOEB --- Use this prefab for auto-edgebug to make them consistent: https://jump.tf/forum/index.php/topic,3051.0.html
  Note: it's better to name the teleport trigger "autoeb" so the landmark destination points to the trigger itself instead of having a tele destination named autoeb that you have to place. This avoids issues from placing the destination improperly.
• COURSES --- Make courses lead the player directly to the next course, not to a hub area. Hubs are fine, but finding the next course in maps like jump_4starters or jump_dystopia is unnecessary.
• SEPARATE CLASS COURSES--- Some maps (e.g. jump_autumn, jump_elite) provide two complete maps so that it's intended for both. We'd prefer that just be two separate maps.
• VSCRIPT --- Avoid using vscript when ordinary hammer logic or entities would suffice. There are a few reasons for this:
  - Plugins can detect and interact with logic entities; they generally cannot do anything with vscript. For example,
  - Plugins (stripper) can let us modify logic entities without needing to wholesale replace any part of the map -- building something parallel for vscript would be a waste of dev effort especially since it's only ever needed for gimmick maps.
  - Reviewing vscript is considerably more time-intensive than a vmf, even more so if it includes thousands of lines of boilerplate or copy&pasted code.
  If you must use vscript (you probably don't!), avoid doing any of the following:
  - Changing the player's class
  - Changing the player's weapon (can add/remove attributes if careful)
  - Killing players
  - Modifying gamemode settings or other aspects of server config
  
• JUMPQOL SPECIFIC --- ILDPRUT's jumpqol plugin makes a number of assumptions about how players and rockets behave in order to work. There are some mitigations to allow for gimmicks, but it is by no means a comprehensive solution and likely never will be. If you have gimmicks that directly act on rockets or player movement (e.g. rocket reflectors, gravity, speed, teleporting, etc.), check that your map works without issue with jumpqol fakedelay and desync fix activated.
• PROCEDURAL --- A few extra pointers/requirements:
  - Use either the Slammin' patch for hammer (https://tf2maps.net/threads/slammin-source-tools-v2-hammer.41335/) or Hammer++ (https://ficool2.github.io/HammerPlusPlus-Website/) to avoid the imprecision issues in stock Hammer.
  - All maps should have assets packed (use CompilePal)
  - All maps should be repacked (use CompilePal)
  - Keep in mind the filesize of your map. The median on Tempus is about 9MB; you do not need 30MB of HD skybox textures, high-poly models, or any substantial amount of packed audio. Also, be mindful of lightmapscale if you have a lot of brushes -- high-quality lightmaps will rapidly inflate both your compile times and filesize with minimal benefit at best.
  

OFFCLASS
We'd like if all maps were runnable for both classes. This isn't always possible (and we don't expect mappers to spend a lot of effort on it), but these guidelines are intended to be easy to follow.

Soldier Intended Maps

• NONADE --- Use 1 unit nonade on surfaces which you don't want rockets to explode on. Larger volumes have no further effect and tend to make the map worse for demo, as well as make unexpected issues for soldier.
• ANTI-TELESYNC --- Do not use physbox_multiplayer for midair nonade. This makes invisible walls for stickies to bounce off of. Usually, this should be fixed with good spacing/better geometry instead of midair nonade. If you absolutely need a midair nonade, use a displacement with no hull and no physics collision surrounded by 1u nonade. Rockets will collide, but players and stickies won't. Use the texture `overlays/no_entry`.
• ACCOMODATIONS --- We would prefer ordinary soldier maps to become boring T3 triplepre maps to boring T6 airpogo maps -- different geometry is the only real way to make many soldier maps play better on demo. Don't add extra teles/roller/nonade just to make the map harder on demoman.

Demo Intended Maps

• REGEN --- We can add flags on Tempus to give one class regen, so this is not a concern.
• ACCOMODATIONS --- Most demo maps can be notele for soldier and play well (e.g. jump_haze). If you want to put more effort in, selective notele like in jump_anothermap or jump_airshift is even better. Sometimes that isn't enough or specific jumps need extra attention (e.g. if anticheat involves a lot of playerclip). Slapping the soldier airpogo prefab + 2x rocket knockback on a map generally makes anything possible, but if the only way to make the map playable is with gimmicks then it's permissible to release the map T0.

QUALITY CONTROL
Map quality is subjective and we're fully aware of that. Nonetheless, adhering these rules/guidelines will generally improve the quality of your maps (and increase the chance we zone them).

• BASICS ---
  - Maps should almost universally be traditional, intended jumping for at least one of soldier or demo. Intended gimmick maps will be subject to very strict scrutiny.
  - Maps should be intended to be enjoyable for at least one of soldier or demo, and not deliberately unfun for either.
  - Maps should be 'well made' from a mapping perspective -- consistent gridsize, properly joined/aligned brushwork, etc. This is hard to specify, but aim for quality even if the map is all dev textures. Obviously low-effort maps are frowned upon.
  - Maps should be some kind of new or creative. This is a pretty soft requirement, but we don't want jump_dev_box_airpogo7.
  
• TESTING --- Maps should be thoroughly playtested. To this end, we strongly recommend that all maps are posted to the forums early and updated in response to feedback. Ignoring feedback is probably the best way to have your map never get zoned.
• DETAILING --- Detailed maps are preferred but not necessary. Detailing should not detract from the gameplay (either for performance reasons or on account of visibility/clarity). If a jump relies on displacements or models as a gameplay element, be sure to test thoroughly to ensure they are reliable.
• TEXTURES ---
  - Maps should be consistently textured. If a texture represents nonade, playerclip, teleport, or any other non-obvious mechanic, it should be consistently marked.
  - Teleports, playerclip, phase, and any other potentially invisible gameplay mechanic should be made clear to the player if relevant (e.g. no giant unintuitive playerclip).
  - Maps should not be too much of an eyesore -- avoid flashing lights, extremely bright textures, and very dark or very light maps. Using very flat/solid color textures is frowned upon, as is excessive use of skybox when it makes judging speed difficult.
  
• DIFFICULTY --- Jumping has a long history of making hard maps just for the sake of it and that isn't changing any time soon. However, harder maps will be held to higher standards -- we don't want the top tier of content to be a series of dumpsterfire "hard because bad" maps. To this end, very difficult maps should be difficult for creative reasons -- not just "koro last but the end is further away" or "do 10 bhops" or "airpogo for longer than the previous hardest airpogo map". In general, we strongly recommend that mappers only make maps which they themselves can confidently complete in a single session -- it is very difficult to make quality jumps when all testing is external.
• SPEEDRUNNING --- Tempus is a speedrunning network at its core. Maps which are decidedly bad for speedrunning are frowned upon -- the following are examples of what not to do.
  - Excessive anticheat: Routing and strat-finding are fundamental parts of jumping; forcing the player to do exactly your intended strat is generally not appreciated. When anticheat is inevitably circumvented, it just makes the run worse (see: jump_zone last). This is relaxed for very hard maps, but remember that many maps were once considered extremely difficult and are now popular for speedrunning -- if jump_pandemonium somehow forced showcase strats, it would be a worse map.
  - Regen in nearly all forms falls under this category -- speedruns already tend to optimize for fewest rockets/stickies so there is rarely a good reason for limited regen. If you must use regen, make sure it's tested and shown to not interfere with prospective speedrun routes.
  
• BONUSES --- The standards for bonuses are much lower than for maps but still exist. Avoid anything extremely time consuming or inherently random; doubly so if it's also difficult. Also, avoid making bonuses which are easy to accidentally enter during a map run.

We'll zone completely finished maps that meet the majority of these guidelines after determining they're ready with consensus from the Jump Illuminati.

Thanks to Gorge for making the first version of these guidelines.