4CP Payload, a Numbers Resource with Commentary/Analysis

ibex

aa
Sep 1, 2013
308
528
upload_2022-1-2_21-27-52.png

Intro:
Originally this was going to be my 72hr entry as I thought I wouldn’t have enough time for a map. I ended up not having time for this either, and the actual work and deliberation ended up taking quite some time, too.

Anyway, it’s been too many years since I felt I had the confidence to do a guide on developing payload maps (and many failed payload maps). So I decided I’d try to analyze them purely on numbers instead. Most of you have seen the push times graphic (link) that Idolon made, and while I think it conveys good information on developing your own payload map, I was hoping there might be other useful numbers or ratios.

In order to try and make the data easier to analyze, and provide some relevancy, I limited my analysis to 4CP payload and created a small survey on how fun the existing official and late-stage, community maps were. I used these ratings to select certain maps to analyze (you can find the google form [link] and sheets [link] here).

Some short-comings of the survey to keep in mind:
  • Only posted on TF2Maps.net and the TF2Maps.net discord (some bias)
  • All questions were optional so the number of votes most of the community maps got were pretty variable (I did selectively trim votes that were below a certain threshold, check out the google sheet for more info)
  • Only 42 responses (trimmed down to 25, again not statistically great)
  • Missing some maps that could have been helpful for the analysis
  • Overall rating versus CP to CP rating where the analysis focuses primarily on CP to CP timings
    • I think this would be a good study to pursue if I had more time
I’ll be honest, there aren’t any clear patterns found in this study. This analysis was for naught, but hopefully the base numbers documented might be useful to someone! Continue reading for my search to find something in nothing.

On to the numbers:
I’ve selected two maps from the high rated (badwater, upward, vigil, highwood) and two from the low rated (barnblitz, frontier, shoreleave, coal_event) for both official and community maps. I’ve also included 3 community maps that where on the high and low sides that had lower (statistically less significant) votes.

All times were taken by stopwatch (phone) in seconds and are approximates (+/-1 second). Engi was used for neutral walk speed and cart push speed.

Push times:
Push times.png


upload_2022-1-2_21-45-56.png
  • The push times should look familiar, with some new maps added in. No exceptional trend here as upward bucks the norm and shorter maps appear to not be strictly more fun.
  • I will note that I didn’t check if any of the maps adjust cart speed throughout (not sure if there is an easy way to check this without decompiling, feel free to inform me***), but I did notice that upward halves the cart speed on the roll back zones (learn something new every day!).
Spawn times:
upload_2022-1-2_21-48-25.png

  • The “Spawn Adjusted” sections equal the numerical spawn time as specified by the I/O (and mapper), times 1.5 for the average spawnwave, plus 5 for the deathcam. I was hoping this would create a more accurate picture when turned into ratios. Again, no specific trends in fun vs. spawn time.
  • If I were to touch up the data or find new variables to test, I might try using both the minimum and maximum spawn times as variables for comparison, too.
Walk times:
upload_2022-1-2_21-50-9.png

upload_2022-1-2_21-51-5.png
  • Walk times were taken from spawn to the CP as the payload is a variable distance. Not the best measurement, but it is one that is definite.
  • Point to point is walking the fastest* path between control points. Again, not directly correlated to the payload, but I was hoping there might be something to glean from taking as many measurements as I could.
    • (*As best I could find, and minimizing jumps)
  • The high/low highlighting does seem to suggest that higher point to point walk times are less fun, but not a steadfast rule.
Ratios:
The next series of numbers are the various ratios I tried to see if any relations could be divined (such as “walk time ‘x’ being double spawn time ‘y’ was more fun”, etc.). The answer is “No, not really”; disappointing, but there weren't any clear issues in the base numbers I recorded either. On the flipside it is kind of cool that payload isn’t clearly formulaic.

I’d implore the more analytic-minded individuals to make suggestions for other numbers to gather and/or ratios to test, but even just reading this mess is appreciated/enough.
upload_2022-1-2_21-56-1.png

  • Push time divided spawn time. This was meant to be a measure of how many spawn waves occur across the required push time, however the push time changes as the cart is defended so this really isn’t a super concrete ratio. It seems like less fun maps may tend toward a higher push-to-spawn time ratio, but it clearly isn’t a consistent rule.
  • Push time divided by walk time. Again, this has the issue of the push time changing as the cart is defended. No exceptional trends here, may be more of an indicator of control point difficulty and not strictly tied to how fun a point is.
upload_2022-1-2_21-57-28.png

  • Walk time divided by spawn time. Values below one indicate the walk time is shorter than the average spawn time, which makes sense for defenders (red). Seems like most fun maps prioritize a short walk and longer spawn time for Red, however there seems to be less of a trend for Blu, if anything the data would suggest targeting the averages for a more fun Blu experience.
  • Walk time divided by spawn time (Blu) divided by walk time divided by spawn time (Red). I’ve been staring at this one for awhile trying to contextualize what this ratio would mean, and the best I can think of is the difficulty of the control point, but these max and min’s are not consistent with the Push/Walk time ratios above. And since this doesn’t align with how fun the map might be, it really isn’t telling us anything.
upload_2022-1-2_21-58-33.png

  • Spawn time divided by spawn time. I’ve chosen Red divided by Blu because the values are more expressive (Red generally has higher spawn times so the ratios are generally [here, always] greater than 1). Unfortunately, no specific trends here; I was thinking this one might be the most likely to provide actionable data.
  • Walk time (Red):walk time (Blu). I’ve chosen Blu divided by Red because the values are more expressive (Blu generally has higher walk times so the ratios are generally greater than 1). No specific trends here.
  • If anything I would take these averages as a good indication of where your map should be, and then adjust as testing or the layout suggests; e.g. Blu’s walk to C should be approximate 2 times as long as Red’s.
upload_2022-1-2_21-59-25.png

  • Push time divided by the point-point walk time. This indicates how quickly the attackers can out-pace the cart (higher value indicates that the walk time is lower than the cart travel distance, or the cart travel distance is exceptionally high). I think in particular upward C chose to do this as a solution to getting rolled; even if Blu takes the control point area they still have to wait a few spawn waves for the cart to reach the point.
  • Walk time divided by point-point walk time. The following is a bit of conjecture, but for Red this indicates that the capturers of the previous point can reach the next point either before or after the Red team (higher value may mean easier to roll). For Blu, the higher the value the more likely the initial push after capture may be more critical to the success of the attackers.
  • No specific trends out of these, but I think these would be best reconciled with layout and how these timings may have been adjusted to compensate for other layout concerns.

Take aways:
While no patterns or trends were identified, I think the base numbers or even the averages can be used to help inform your plans/maps. Push times may be one indicator of how well your idea will play, but I think there are other important numbers to consider.
  • Longer push times may be less fun, but they can be used as compensation for other layout issues (e.g. upward C).
  • Red spawn times are generally around 2 times the Blu spawn times, but this is by no means a hard rule. Spawn times can be adjusted to attempt to compensate for a pacing issue (this isn't without it's own cautions thought)!
  • Blu walk times are generally around 2x the Red walk times and can increase to 3 or 4x to increase the difficulty of the point. Reference the Walk/Walk ratio table, but the ratio seems to follow my personal theory of difficulty progression of 4CP payload where B is harder than A, C is less hard than B, and D is harder than C.
  • While I wanted to analyze payload in particular because I love payload, I think this type of analysis would be better suited for control point gamemodes like koth, 5CP, or even linear A/D CP.
Survey take aways:
Some people don’t know how to count.



Thanks for reading!
 

theatreTECHIE

Yet another Techie for the net...
aa
Jun 19, 2015
446
457
This is really in depth, well done! I know that I decreased the speed of the cart on Vigil rollback ramps a bit, although can’t remember off the top of my head by how much. One interesting fact about Thunder Mountain last - once the cart gets to the bottom of the second to last rollback ramp, the time before rollback decreases massively (I think it halves from the default). I tried this out on Vigil as well, having the time before rollback decreased when the cart was up the final hill, but players were just frustrated with that mechanic so I removed it.
 

ibex

aa
Sep 1, 2013
308
528
A really cool read and very informative for payload design. I don't know if you've done other gamemodes but that would be cool to see. Good job.
I'm interested in doing other gamemodes, especially because I think CP maps would be easier to apply these metrics to. Also, I imagine there might be some clear patterns to be found in the more competitive focused maps. Unfortunately, I bet any effort on my part will be sporadic at best so no promises on additional analyses. Fortunately, I think most of my analysis and choice rationale is documented in the google sheets or this post so if someone wants to try to replicate this, I welcome it!

This is really in depth, well done! I know that I decreased the speed of the cart on Vigil rollback ramps a bit, although can’t remember off the top of my head by how much. One interesting fact about Thunder Mountain last - once the cart gets to the bottom of the second to last rollback ramp, the time before rollback decreases massively (I think it halves from the default). I tried this out on Vigil as well, having the time before rollback decreased when the cart was up the final hill, but players were just frustrated with that mechanic so I removed it.
Love this! I wish these little elements and choices were easier to identify or otherwise documented. It sounds like it has a direct impact on the fun when you measured it, but I wonder if people find TM last to be less fun (or even unfair), too.

Again if anyone has a non-decompile method for checking cart speed that'd be super cool! And if anyone has suggestions for additional numbers relevant to payload, let me have them. (or suggestions for posts similar to this, but again no promises!)
 

Box Of Paper

L3: Member
Jul 15, 2019
111
143
For non-decompile methods to debug I can give you these:

To dump keyvalues about a certain entity by targetname:
- ent_dump minecart_tracktrain
- ent_dump watcher
(These are the names used in Upward and Badwater)
ent_dump minecart.png

"startspeed" is the keyvalue for the "Max Speed ( units / second )" property,
"ManualAccelSpeed" e "ManualDecelSpeed" define the acceleration and deceleration.

Not every keyvalue is included in the dump, luckily the speed related ones are.

If you don't know the targetnames, then either try with the console's autofill untill it shows the outputs of the entity you are looking for, or update the targetname with an AddOutput and ent_dump the new name, but this might break the logic.


To check if any path_track changes the cart's speed I used this:
- ent_messages_draw 1
- ent_fire path_track InPass
WARNING: This breaks the map, you will need to reload the map.
InPass.jpg


The "path_track"s request the speed changes to the "team_train_watcher", so look out for where the outputs come from.
(To locate it beforehand use " ent_fire team_train_watcher " (with ent_messages_draw 1))

If you use "developer 2" you can even see by how much the path_tracks change the cart's speed
(good luck finding the inputs).
Speed changes.png

use " ent_fire PathTrackTargetname " to see where the path_tracks are (with ent_messages_draw 1).


To calculate the times between the CPs I've used the "developer 2" timestamps:

sv_allow_point_servercommand always;
ent_create point_servercommand targetname cmd;
ent_fire team_control_point addoutput "OnCapTeam2 cmd,command,developer 2,0,-1";
ent_fire team_control_point addoutput "OnCapTeam2 cmd,command,developer 0,0.1,-1"

Once you execute this, you can start the cart with:

developer 2; ent_fire team_train_watcher SetNumTrainCappers 1; wait 10; developer 0;
OR
developer 2; ent_fire !player addoutput "origin X Y Z"; wait 10; developer 0;

Upward lets you start the cart by using the "team_train_watcher", but some maps like Badwater don't allow it, so you gotta teleport on the cart (use the "getpos" command when on the cart to get the coordinates X Y Z).
upward times.png

475.80 - 164.49 = 311.31 which is close to what you calculated.

(Also works with "host_timescale 20")
 
Last edited: