RMD version: https://rpubs.com/chadgordon09/step10
1. The next logical step is to take the same methodology we used for attacking and dive deeper into the rest of the skills. If eV+ can help us better evaluate attacking, then perhaps it can be useful in other portions of the game.
2. Again, I’ll attempt not to burry the lede. Above are the ways in which I classify input and output situations – and therefore expected values – for each unique skill.
2.5 We derive “Expected Value Added” (eV+) by simply taking (Output eV – Input eV). This gives us the change in value based on the contact itself.
3. Quick blurb on each skill.
3.1 Serve – Input is a static baseline. Output is the quality of reception + the zone the ball was passed into. Again, for the input, I would tailor this to the specific team or level in question. This baseline is based on a large aggregate set of data, but the concept holds true, you are more likely to lose the point every time you go back to serve, so the Input eV for serving is almost always negative.
3.2 Reception – Input is the inverse of the serve static baseline. Output is the quality of reception + zone the ball was passed into. Naturally, you are more likely to win the rally when you receive serve, therefore the Input eV is almost always positive.
3.3 Set – Input is the output from the Reception, Dig, Cover, Freeball contact (1st touch quality + where the zone of the set’s origin). Output is a combination of In-Sys or OOS attack + the number of blockers the attacker faced after the set. In-system attacks against fewer blockers means the setter did a better job in this case. This is the skill I personally am least happy with. Setting is naturally difficult to evaluate objectively – plus VM doesn’t give you a lot to work with (E#, E-, E=, come on guys…). So what we do here is not work middle-out (#siliconvalleyanyone?) but from the outside-in. The output of the Reception/Dig/Cover/Freeball must be the input to the Set. The input to the Attack must be the output from the Set. So if we assume the output from the 1st touch is what makes setting difficult (quality of pass + location) – and that what makes attacking challenging is In-Sys vs. OOS and the number of blockers you face…we work from those 1st and 3rd contacts to create Input / Output situations for the Set. It’s not perfect, but it’s what we have right now before we get ball tracking software.
3.4 Attack – Input is the output of the set or is overpass. Output is the quality of the opponent’s 1st touch or our cover quality and time to do so.
3.5 Block – Input is the same input as the attack. Output is the same as the attack outputs for the most part. Was there a good dig behind us or did we block into a perfect cover for the attacking team? If it’s a dig, then the blocking team has possession. If it’s a cover, the attacking team retained possession.
3.6 Dig – Input is the same as attacking, unless there is a block touch in which case we account for how much time the block slowdown bought the defender. Output is the quality of the 1st touch + the location the ball was dug into.
3.7 Cover – Input is the speed of the attack + the time allotted for the cover. Output is the same as dig, what’s the quality + location it was covered into.
3.8 Freeball – Input is a static baseline. Output is the same as dig/reception/etc – what’s the quality and location of the freeball you played.
4. I’ve attached all the different skills individually below. Reminder that the eV numbers are aggregated over the entire dataset and do not necessarily apply to every single level and/or gender of play.
5. There are a million ways to create “Expected Value” for different skills – I’ve chosen the above direction after a couple years of experimenting and looking for situations with a large enough sample size combined with decent differentiation between situation eV. If the outcomes don’t vary in eV, then they’re not really useful for our purposes.
6. In the next step, we’ll walk through, from absolute square 1, how to go from VolleyMetrics and DVW files >> download R/RStudio >> use Ben Raymond’s datavolley package >> write code to create Expected Value.