#1
|
|||
|
|||
Heat Map for ball maps
This idea is to create a gallery of ball maps that show where the ball is most often. Sorta like this:
Server owners could check this option on or off. When a map is being played, the server would write down the ball's xy position every ten seconds or so, and then add this to the pile of data from other games on the same map. This data would get chewed every week or so to spit out a colorful heat map that shows where the ball is most often. This would allow some powerful insights into ball map design. |
#2
|
|||
|
|||
Cool idea. It would probably have to be every second, though (I know, that would bog down the servers) since the ball moves so fast. I timed a self-pass randa one time and it could get across mayhem in two seconds (pre-patch).
|
#3
|
|||
|
|||
Yes! And perhaps not just ball locations. Team Fortress 2 does this for player deaths.
|
#4
|
|||
|
|||
Player deaths and ball location would be awesome info! This would help map creators a lot and also help the analyzing of weaknesses of existing maps that is going on on the forums right now. This would probably require a bit of extra processing power for the server so it's good to leave as an option, but I'm fairly certain it wouldn't be anything of concern for servers running on VPS's for example. (of course this depends a lot on the method if implementation)
|
#5
|
|||
|
|||
Glad to hear other people like the idea of heat maps!
If you pull data from a large sample of games, then you need less data per game, which means the server can check the ball's position every 5 or 10 seconds. Since the ball's x,y is presumably stored in the game code at each moment already, it wouldn't be too hard to pull. The great thing about heat maps is they will show how the ball's gametime is distributed vertically as well as horizontally. For example Football would probably look like this: Which would show us that the ball spends a lot of time in the center, and in the lower half of the map. Death maps would require a lot more server activity and actually, I think they would be more or less the same pattern on all maps, give or take a few chokepoints. |
#6
|
|||
|
|||
Death maps would indeed allow for choke point detection, and any other weird death realted things. I think both data maps are useful in their own ways. Lots of it will be overlapping, but not all.
|
#7
|
|||
|
|||
Quote:
So it's not exactly the same as death point, but it's like: Death point v X Kill Point v X This shows the killer coming from below and killing the dead player from a certain distance away. This way doesn't really show choke points as well as death maps would, but it shows camping spots alot better as you can see where the most kills occur from. |
#8
|
|||
|
|||
With the server JSON log, a heat map for ball location can already be approximated by recording all the times that a ball is shot and a ball is caught. You can also do powerup-usage heat maps. You can't do death and kill maps as of yet, but I think it wouldn't be too hard for lam to include that functionality in.
The only thing preventing this from actually happening is for someone to take the initiative to code something up that would generate this stuff. But having said that, let me be the first to say: not it. |
#9
|
|||
|
|||
I think there's quite a lot you could do with heat map technology, for example, how about setting this up for ball to show position where goals were scored from?
|
#10
|
|||
|
|||
That depends on how often you want to sample the ball location. If the frequency at which people die is greater than the frequency at which you store the ball location, then yes.
Anyway, the frequency at which people die in TF2 and Altitude is probably in the same ballpark (no pun intended), and the overhead is low enough for their servers. Should work for Altitude as well. |
#11
|
|||
|
|||
This sounds cool
/heatActivation true This way you don't have to see it all the time. |
#12
|
|||
|
|||
I don't think the idea is to see it during the game, but to keep track of the information so it can be analized later by map developers so they can improve the maps.
|
|
|