Create an account


Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
[SUGGESTION] map occupancy statistic

#1
here's the idea: could be useful (at least for me...) to have access to a statistic which describes the occupancy rate of the map during a game for a given player.
Let's say: "you spent 12% of the time in the area close to the mega" or something (just like TV channels provide for football for example).

This occupancy could be depicted at the end of the game on a colored radar view, or even in real-time during the game.

Open question: is this stat shared with other players?


One other idea would be then to agglomerate all these statistics to draw an average occupancy of all players on a given map. This could help map designers to check whether their maps are well balanced.
Fat.bot.Slim
Reply

#2
(07-19-2010, 08:05 AM)Rage_ATWM Wrote: here's the idea: could be useful (at least for me...) to have access to a statistic which describes the occupancy rate of the map during a game for a given player.

...

This occupancy could be depicted at the end of the game on a colored radar view, or even in real-time during the game.

...

One other idea would be then to agglomerate all these statistics to draw an average occupancy of all players on a given map. This could help map designers to check whether their maps are well balanced.

I'm working on something along those lines, but also on weapon & health stats (think heatmaps), yet that code isn't ready for primetime yet and sadly the server that ran a demo of it crashed hard. Also, it wouldn't be ingame but with a web frontend.

I'm also working on an eventlog parser which is getting close to its completion. The parser itself works already, it is just the sinks (think data consumers) that need some work since the default one(s) do pretty much nothing.

Both will Open Source eventually (the eventlog parser already is).

Edit: still had an example output around: http://img407.imageshack.us/img407/5670/toxichp.pnghealth heatmap on toxic, big image.
Edit 2: Explanation of the colors: green (full health) -> red (low health), blue = died at this position.
Reply

#3
I've thought about this a little bit too, but from a different perspective - what if mappers could have a "heat map" of how players move about their maps? Such a map could probably help them with design, flow, etc.
asyyy^ | are you releated to chuck norris?
Reply

#4
yes! that would be nice to see! and maybe helpful!
MY NOOB STATS:
[Image: 788.png]
Reply

#5
i'd love to see the gameplay dynamics visualized, like a 'heat map'/temperature spectrum.
4m038105 - Be the change.
Reply

#6
(07-19-2010, 11:20 AM)dyin Wrote: I'm working on something along those lines, but also on weapon & health stats (think heatmaps), yet that code isn't ready for primetime yet and sadly the server that ran a demo of it crashed hard. Also, it wouldn't be ingame but with a web frontend.

I'm also working on an eventlog parser which is getting close to its completion. The parser itself works already, it is just the sinks (think data consumers) that need some work since the default one(s) do pretty much nothing.

Both will Open Source eventually (the eventlog parser already is).

Edit: still had an example output around: http://img407.imageshack.us/img407/5670/toxichp.pnghealth heatmap on toxic, big image.
Edit 2: Explanation of the colors: green (full health) -> red (low health), blue = died at this position.

Indeed what you propose looks like what i was thinking about.

But please give a bit more detail on the functions you propose:

- what is the difference between the two functions you developped? What kind of data can you trace?
- about your eventlog parser, is it purely (discrete) event-based? If so, can you integrate some "continuous" data like occupancy?
- about the .png heatmap you provide, explain what and how you traced: is it the data coming from one player? during one game? what is the refresh rate for each color point?

PS: i like the blue circle on the left down corner. Rest in peace Michael... Tongue
Fat.bot.Slim
Reply

#7
(07-19-2010, 03:44 PM)Rage_ATWM Wrote: ...
But please give a bit more detail on the functions you propose:

- what is the difference between the two functions you developped? What kind of data can you trace?
- about your eventlog parser, is it purely (discrete) event-based? If so, can you integrate some "continuous" data like occupancy?
- about the .png heatmap you provide, explain what and how you traced: is it the data coming from one player? during one game? what is the refresh rate for each color point?

PS: i like the blue circle on the left down corner. Rest in peace Michael... Tongue

the two apps have a different purpose.
ulp (the eventlog parser) is parsing the eventlog and (in the case of use together with gl2i -- that's what I'm working on atm) inserts the parsed data into a sql database.
gl2i (the fancy image thing) is a bit more complex:
- a static web page is delivered to the user.
- javascript inside that page is loading json chunks from the server which in turn is reading the database.
- said javascript then is using html 5 canvas to paint the json data accodingly to what shall be shown.
- atm, 3 plugins (javascript again) are supported: health, weapon use/damage and line of fire. the image shows the health plugin in a somewhat older version.

the ulp is parsing the eventlog (see Docs/eventlog.txt) and those data are indeed discrete (technically, any sort of 'realtime' info inside the game's also discrete after all, just in way shorter intervals). It is quite hard to get 'real time' data (say, player positions) as the Quake-C interpreter can't handle it that well. I used to have a patch for damage events, but even on a 1on1, it caused random lag spikes inside the server, noticable to players. The only idea so far I have is to accumulate areal data and then dump those at the end of a round, yet that sounds quite ugly.

the data in the image come from one botmatch with iirc 7 bots. all bots are drawn together. I'm not sure what you meant with refresh rate for each color point...

as for the circle, that's the spinner inside the slime, since bots don't know how to get out of there Big Grin
Reply

#8
(07-19-2010, 04:21 PM)dyin Wrote: ulp (the eventlog parser) is parsing the eventlog and (in the case of use together with gl2i -- that's what I'm working on atm) inserts the parsed data into a sql database.

The whole idea sounds nice. If you need help with integrating sqlite3 to write data into a file, PM me...
Reply

#9
(07-19-2010, 04:21 PM)dyin Wrote: It is quite hard to get 'real time' data (say, player positions) as the Quake-C interpreter can't handle it that well.
Without being a QuakeC expert, could you give me some clues on the difficulties to easily get player positions?

(07-19-2010, 04:21 PM)dyin Wrote: I'm not sure what you meant with refresh rate for each color point...
I guess you depict each point every X second. What is X?

A naive comment: you take your .png image, you set all points in the same color, you then compute a point spatial density (=number of points by surface unit) by a 2D histogram; and you build the occupancy map i was talking about.
Am I wrong?
Fat.bot.Slim
Reply

#10
(07-20-2010, 02:20 AM)tankmiche Wrote: The whole idea sounds nice. If you need help with integrating sqlite3 to write data into a file, PM me...

Thanks for the offer, yet I'm using Python, so it is actually quite easy to do sqlite3. However, I also want the sql to be usable for about every DB-API 2.0 (see PEP 249) driver, so I thought about using an ORM, yet that didn't make the work any bit easier.

As soon as I get finished with the sql tables, I'll post the url for ulp on here.

(07-20-2010, 03:21 AM)Rage_ATWM Wrote: Without being a QuakeC expert, could you give me some clues on the difficulties to easily get player positions?

...
I guess you depict each point every X second. What is X?

A naive comment: you take your .png image, you set all points in the same color, you then compute a point spatial density (=number of points by surface unit) by a 2D histogram; and you build the occupancy map i was talking about.
Am I wrong?

The problem isn't that much of getting the player position(s), but to get those data into any sort of a log, since that would require a considerable amount of string conversions which are quite slow for that many data.

Actually, I'm not. Instead I check if there's new hit-data and if so, then I'll just add points for these -- aka no need to refresh every point. Atm, I'm polling for new data at about every 10 seconds, yet that can be easily tweaked inside the javascript.
Reply

#11
(07-19-2010, 11:20 AM)dyin Wrote: Edit: still had an example output around: http://img407.imageshack.us/img407/5670/toxichp.pnghealth heatmap on toxic, big image.

But it would be nice to smooth it up a bit!
Maybe use bigger dots?
But nice!
MY NOOB STATS:
[Image: 788.png]
Reply

#12
(07-20-2010, 08:38 AM)dyin Wrote: The problem isn't that much of getting the player position(s), but to get those data into any sort of a log, since that would require a considerable amount of string conversions which are quite slow for that many data.

ok... again, i'm not into details, but it seems to be possible to build an occupancy map (or any continuous statistics map) without storing anything in a sql data-base:
Let's say you first chunk the map into non-overlapping square cells, which each has a size DxD meters. You then have your occupancy grid.
During the game, you periodically call get_player_position() every X ms, the resulting (X,Y,Z) coordinate falls into a given cell, you add +1 to the score of the corresponding cell, and the job is done.
Fat.bot.Slim
Reply

#13
(07-20-2010, 10:48 AM)rainerzufalldererste Wrote: But it would be nice to smooth it up a bit!
Maybe use bigger dots?
But nice!

the points in that old output are actually squares, but since the move from that old Qt-based (server-side) renderer to the new html5 canvas (client-side) renderer, the points are actual circles (with antialiasing) and they're already a bit bigger.
Thank you Smile

(07-20-2010, 06:12 PM)Rage_ATWM Wrote: ok... again, i'm not into details, but it seems to be possible to build an occupancy map (or any continuous statistics map) without storing anything in a sql data-base:
Let's say you first chunk the map into non-overlapping square cells, which each has a size DxD meters. You then have your occupancy grid.
During the game, you periodically call get_player_position() every X ms, the resulting (X,Y,Z) coordinate falls into a given cell, you add +1 to the score of the corresponding cell, and the job is done.

Except that this means
a) you've to compute the cell(s) for each map individually
b) you've to convert/compare the floats to find a matching cell
c) you've to update a pretty huge array. let E, F, G be width, depth, and height of a map divided by D each. then you've to have an array of size 64xExFxG, which, unless D is rather large, becomes pretty big. Yet you can not pick D large or else you'll loose accuracy for 'camps on a random spot' vs 'waits to get mega health' vs 'somewhere between mega health, rocket launcher and nex gun'.

checking the player positions each X milliseconds would mean 64*(1/X) updates per second at most. with all of b), so it is still computationally expensive and I fear it would cause server-lag. And again as with the 3d-resolution, you also need a high enough time-resolution.

now the old damage-eventlog patch would output x,y,z*2 (attacker+victim) and weapon-id on each hit which means upto 640 events/second (mg = 0.1s refire x 64 players). Keep in mind that the damage-eventlog caused noticable lag even with only 2 players, i. e. upto 20 events/second.
So my guess is that the cells-approach would be up in that league, to not to mention a big lag-spike at the end of each round for dumping those data into a logfile/stdout/whatever.
Reply

#14
(07-20-2010, 06:58 PM)dyin Wrote: Except that this means
a) you've to compute the cell(s) for each map individually
b) you've to convert/compare the floats to find a matching cell
c) you've to update a pretty huge array. let E, F, G be width, depth, and height of a map divided by D each. then you've to have an array of size 64xExFxG, which, unless D is rather large, becomes pretty big. Yet you can not pick D large or else you'll loose accuracy for 'camps on a random spot' vs 'waits to get mega health' vs 'somewhere between mega health, rocket launcher and nex gun'.

checking the player positions each X milliseconds would mean 64*(1/X) updates per second at most. with all of b), so it is still computationally expensive and I fear it would cause server-lag. And again as with the 3d-resolution, you also need a high enough time-resolution.

ahhhh, at last, we go into details Tongue

a) yep, this task could require some work to do manually. I don't know. Maybe mappers could help us. We should keep in mind that the cell-mapping does not have to exactly match the map. Indeed, it is enough to have a cell-mapping larger than the actual map, and you simply will have some cells which won't never be occupied.

c) I get your point, but you here consider to achieve the most complete system. Instead you could:
- make the function only at the client side, so your 64 becomes 1 and you then trace only your own statistics. Nothing is lost because if you further want to get the statistics of all players, you only should send these individual stat to the server, which in turn will build the heat map by averaging all stats.
I you want to maintain it at the server-side, you could start by only tracing some 1v1 or 2v2 games, which would already be very useful.
- make all the statistic computation off-line. To do this, you can use the demo recording system. Then, time-constraints become none critical.
- only trace the surfacic occupancy, not the volumic one. Then G = 1.
- X does not need to be 1ms. I'm pretty sure you can choose a reasonnably lower sampling rate and still extract a representative information.
- Of course D comes with a tradeoff. Again, D does not need to equal 100000 to be significant.

b) taking into account the restrictions of c), the computational load should remain quite reasonnable.

Let's take an (almost) pure 2D map like eggandbaccon, with X = 0.1 s, E = F = 100.
Giving a (X,Y,Z) position, you have basically compute 2 divisions (plus some cheaper operations) to determine the cell containing (X,Y,Z).
Total: you have to manage a matrix which is 100x100, and make 20 divisions/sec. Any 90's computer can do this. Tongue

For 3D maps containing several floors, this approach has to be adpated, but i don't see anything impossible.

What do you think dyin?
Fat.bot.Slim
Reply

#15
(07-21-2010, 04:12 AM)Rage_ATWM Wrote: ahhhh, at last, we go into details Tongue

a) yep, this task could require some work to do manually. I don't know. Maybe mappers could help us. We should keep in mind that the cell-mapping does not have to exactly match the map. Indeed, it is enough to have a cell-mapping larger than the actual map, and you simply will have some cells which won't never be occupied.

c) I get your point, but you here consider to achieve the most complete system. Instead you could:
- make the function only at the client side, so your 64 becomes 1 and you then trace only your own statistics. Nothing is lost because if you further want to get the statistics of all players, you only should send these individual stat to the server, which in turn will build the heat map by averaging all stats.
I you want to maintain it at the server-side, you could start by only tracing some 1v1 or 2v2 games, which would already be very useful.
- make all the statistic computation off-line. To do this, you can use the demo recording system. Then, time-constraints become none critical.
- only trace the surfacic occupancy, not the volumic one. Then G = 1.
- X does not need to be 1ms. I'm pretty sure you can choose a reasonnably lower sampling rate and still extract a representative information.
- Of course D comes with a tradeoff. Again, D does not need to equal 100000 to be significant.

b) taking into account the restrictions of c), the computational load should remain quite reasonnable.

Let's take an (almost) pure 2D map like eggandbaccon, with X = 0.1 s, E = F = 100.
Giving a (X,Y,Z) position, you have basically compute 2 divisions (plus some cheaper operations) to determine the cell containing (X,Y,Z).
Total: you have to manage a matrix which is 100x100, and make 20 divisions/sec. Any 90's computer can do this. Tongue

For 3D maps containing several floors, this approach has to be adpated, but i don't see anything impossible.

What do you think dyin?

a) can be done fully automatic. the naive approach would be stepx, stepy = width,depth/D. A more sophisticated one would be to create small boxes around the X important items (megas, nex, quad, shield) and then to spread the remaining DxD-X cells evenly.

c) as for getting the x/y coords: index_x = floor( (x-min_x)/stepx ), and similiar for index_y. stepx/y/(z) would only have to be computed once per map load and could even be cached. Same thing goes for min_x/y/(z). I wonder if parsing the demo data would actually be feasible. Also, client-side is imo bad for 2 reasons.
c-a) In case that one wants to display those data using ulp&gl2i, then the client would have to send them to the server. that sounds to me like a new piece of network Quake-C. Else, in case of client-side display, it would either mean that each client has to run its own ulp&gl2i instance or to duplicate the functionality inside the game logic.
c-b) Also, nothing would stop a client to send bogus position data which couldn't be spotted unless the server made a server-side client-demo and is comparing those two. Of course the cost of parsing the server-side client-demo would be just as high as ingame.
Afterall, it still looks to me like the best approach is server-side ingame parsing, at least for the work involved.

of course any 90's computer can do that many matrix ops, it's just a question of whether a 2010 computer with a Quake-C interpreter can do that, too Wink

Anyway, that's future music since now I first have to finish the eventlog parser, and then to get the server back online.

Edit: typo.
Reply



Forum Jump:


Users browsing this thread:
1 Guest(s)

Forum software by © MyBB original theme © iAndrew 2016, remixed by -z-