EPM

[Lozzano]

Hi there!

I see that there already is an apm object availible, I was wondering if it wouldn't be pretty easy to also add EPM? I am looking to draw out some statistics from thousands of replays, so this information would indeed come in handy.

Another thing would be total minerals/vespine etc. collected throughout the matchup. But I suppose the EPM one would be a lot easier to "implement" on the fly. If anyone would care to do it, I would be very please.

Thanks a lot in advance!

Best regards,

Lozzano

[Graylin Kim]

Hi Lozzano,

I see that there already is an apm object availible, I was wondering if it wouldn't be pretty easy to also add EPM? I am looking to draw out some statistics from thousands of replays, so this information would indeed come in handy.

Unless I misunderstand, EPM is not possible because replays only record actions taken not their "effectiveness". Spamming worker creation for 3 seconds before getting the minerals to do so would generate a large number of actions and in general it would be unclear which were effective and which were not.

You could apply some heuristics and guess which actions are ineffective. If this stat is important to you I'd suggest first finding a reliable way to mark actions as ineffective. If you can provide a proof of concept I'd consider adding the capability to sc2reader.
 

Another thing would be total minerals/vespine etc. collected throughout the matchup. But I suppose the EPM one would be a lot easier to "implement" on the fly. If anyone would care to do it, I would be very please.

Unfortunately replay files don't record resource collection information. If you happen to have the s2gs files available then you can access resource information via both totals and a graph of the resource collection rate throughout the game.
 

~Graylin

[Angel Aponte]

Hi, guys.

I'm investigating how to implement EPM by inheriting from the APM plugin and filtering out spam; perhaps counting spam events separately as SPM (EPM + SPM = APM). Three heuristics are:

1. Immediate repetition filter

a. When someone performs the same AbilityEvent more than once, count the first event toward EPM and all consecutive repetitions as SPM.

 

b. When someone performs the same SelectionEvent more than twice, count the first two events toward EPM and all 

consecutive repetitions as SPM. Does this look right for not filtering out double-clicks that select all units of the same type? Is there an easy way to filter out non-player actions like unit deaths or transformations from these?

 

c. Control Group Events

 i. When someone performs the same SetControlGroup or AddToControlGroup more than once, count the first event toward EPM and all 

consecutive repetitions as SPM.

ii. When someone performs the same GetControlGroup more than twice, count the first two events toward EPM and all 

consecutive repetitions as SPM. Does this look right for not filtering out hitting a control group's number twice to center the screen on that group?

2. Buffered repetition filter -- Similar to 1, except that instead of consecutive actions, a data structure containing a configurable number of the most recent events would be searched to filter out non-consecutive identical events that had occurred recently.

3. Timed repetition filter -- Similar to 2, but a data structure that contains recent events within a configurable amount of time is searched to filter out non-consecutive identical events that had occurred recently.

Are all 3 of these heuristics are needed to calculate EPM? Is there another heuristic that may also be useful?

Thanks,

Angel

[Graylin Kim]

I'd definitely welcome improvements to the APMTracker. It would be preferable for me if you just patched the APM tracker directly though and used other attributes like player.spm for more complex measures.

On Sun, Sep 29, 2013 at 11:01 AM, Angel Aponte <angelint...@gmail.com> wrote:

Hi, guys.

I'm investigating how to implement EPM by inheriting from the APM plugin and filtering out spam; perhaps counting spam events separately as SPM (EPM + SPM = APM). Three heuristics are:

1. Immediate repetition filter

a. When someone performs the same AbilityEvent more than once, count the first event toward EPM and all consecutive repetitions as SPM.

This doesn't seem like it would be effective for all abilities. Someone might want to cast 5 snipes or 3 fungals in a row for instance. For targetted events, you'll want to make sure that the target is the same. 

b. When someone performs the same SelectionEvent more than twice, count the first two events toward EPM and all 

consecutive repetitions as SPM. Does this look right for not filtering out double-clicks that select all units of the same type? Is there an easy way to filter out non-player actions like unit deaths or transformations from these?

A double click will look like a single unit selection followed by a multi-unit selection. I don't think it is obvious that it was a double (or control) click. If all the units added to the selection are the same type then you might be able to make this assumption though. 

The tracker.events log unit deaths and transformations. You could check removed/added units to see if they were killed or transformed in the same frame and disregard those events as game generated. This is a good idea, hadn't thought of it before. 

  

c. Control Group Events

 i. When someone performs the same SetControlGroup or AddToControlGroup more than once, count the first event toward EPM and all 

consecutive repetitions as SPM.

Sounds right.

 

ii. When someone performs the same GetControlGroup more than twice, count the first two events toward EPM and all 

consecutive repetitions as SPM. Does this look right for not filtering out hitting a control group's number twice to center the screen on that group?

Yes, I think this would work. If we're going to get this detailed, I would only count the first action if the control group wasn't already selected. That way first action selects the units, second action centers on them. When the units are already selected the double tap is really just a single action.

 

2. Buffered repetition filter -- Similar to 1, except that instead of consecutive actions, a data structure containing a configurable number of the most recent events would be searched to filter out non-consecutive identical events that had occurred recently.

3. Timed repetition filter -- Similar to 2, but a data structure that contains recent events within a configurable amount of time is searched to filter out non-consecutive identical events that had occurred recently.

Its not clear to me what types of spam these would be effective at fighting. 

 

Are all 3 of these heuristics are needed to calculate EPM? Is there another heuristic that may also be useful?

If you haven't already, you might want to look at the SC2Gears resource on APMs.

~Graylin

Thanks,

Angel

On Friday, July 20, 2012 11:52:02 AM UTC-4, ShadesofGray wrote:

Hi Lozzano,

I see that there already is an apm object availible, I was wondering if it wouldn't be pretty easy to also add EPM? I am looking to draw out some statistics from thousands of replays, so this information would indeed come in handy.

Unless I misunderstand, EPM is not possible because replays only record actions taken not their "effectiveness". Spamming worker creation for 3 seconds before getting the minerals to do so would generate a large number of actions and in general it would be unclear which were effective and which were not.

You could apply some heuristics and guess which actions are ineffective. If this stat is important to you I'd suggest first finding a reliable way to mark actions as ineffective. If you can provide a proof of concept I'd consider adding the capability to sc2reader.
 

Another thing would be total minerals/vespine etc. collected throughout the matchup. But I suppose the EPM one would be a lot easier to "implement" on the fly. If anyone would care to do it, I would be very please.

Unfortunately replay files don't record resource collection information. If you happen to have the s2gs files available then you can access resource information via both totals and a graph of the resource collection rate throughout the game.
 

~Graylin

--
You received this message because you are subscribed to the Google Groups "sc2reader" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sc2reader+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[David Joerg]

I would recommend either

1) implementing EAPM as described here: https://sites.google.com/site/sc2gears/features/replay-analyzer/apm-types#TOC-EAPM

or 2) define something that you think is more useful that EAPM, and first write the documentation for how it works, in something like the style of documentation used for EAPM

or 3) attempt to replicate Blizzard's EPM measurement.  If you want to go this route I can ask Blizzard to see if they can define how it's measured.

If you want to do 3) I recommend starting by looking at a bunch of games and seeing how much EPM and EAPM agree.

If you do 1) you can compare to sc2gears to make sure you're getting it right.

My personal preference is for 1) — no reason to confuse the community with yet another standard, and might as well go for the one that's already described.

[Angel Aponte]

Hi, guys.

I'm using the sc2gears EAPM document as my guide, while also using the existing code in the sc2reader APM plugin as a starting point.

The immediate repetition filter covers a number of the actions listed in the document. A timed filter for a sequence (in sc2gears they're pairs) of actions described in the document would cover most of the others. To meet the full sc2gears EAPM spec, a filter for "failed" actions will also be needed (I haven't started thinking about the failed command filter yet).

One thing that sc2gears doesn't do is discount a "move" (or right click) followed by an "attack" action on the same location or multiple attack (or move) actions separated by half a second. The sc2gears page states that it doesn't take location into account -- only time and repetition. I don't know if Blizzard's EAPM spec considers location when they mark actions as ineffective, but the sc2gears spec is plenty for a starting point -- we can expand the scope to Blizzard's spec if we want to in the future.


Best Regards,

Angel

[Graylin Kim]

Alright cool. I would start by making modifications to the APMTracker to replicate numbers from SC2Gears. This alone, I think, would be helpful to many people as the current reported APM from sc2reader is very basic and people are generally familiar with the SC2Gears numbers/methodology.

At that point it should be clear where you can make improvements and you can make a case for further modifications. If you have questions as you go along please let me know,

~Graylin

[Angel Aponte]

Hi Guys,

I have found that there are 3 groups of repetitive actions that SC2Gears defines as ineffective when they occur within .25, .42, and .83 seconds. I see that the events being counted by the sc2reader APM plugin have useful data members named "second" and "frame" and that there are 16 frames in each second.

1/16th of a second is .0625 seconds and that number divides .25 seconds without a remainder (I can filter that group of ineffective actions out for EPM precisely). On the other hand, .42 and .83 seconds aren't evenly divisible by .0625.

Should I round 6.72 up to 7 frames to approximate .42 seconds (.42 / .0625 = 6.72) and also round 13.28 to 13 frames to approximate .83 seconds (.83 / .0625 = 13.28) between ineffective events? Is this approximation the best I can do right now or am I missing a better way to do this? Please advise.

Thanks,

Angel

[David Joerg]

I think you should round as you suggest.  I don't see any other way to handle it.

[Graylin Kim]

You should decide if you are using real time or game time to filter out repetitive actions because depending on the play speed there may not be 16 frames per "real life" second. Most people play on faster which only has ~11.4 frames per real second (still 16 per game second).

I don't have a preference for how you round but I do wonder why SC2Gears uses such seemingly arbitrary cut-offs that don't evenly divide into frames under any game speed. If I was picking numbers I'd pick numbers that are even multiples of frames on faster since that is how most games are played. Maybe you could ask him how he arrived at those numbers.

~Graylin