1
Volleyball Playcharting
Pete Biencourt and Nicole Weigl
Table of Contents:
I.Executive Summary
II.Introduction and Motivation
A.The Problem
B.Importance
C.Proposed Solution
D.Merits of Solution
III.Project Planning
A.Organization
B.Technical Requirements
C.Project Management
IV.Software Design
A.Components
B.Dependencies
C.Intercommunication
D.Design Techniques Used
V.Implementation Results
A.Project Schedules
B.Overall Results
C.Design
D.Problems
E.Algorithms
VI.Verification and Validation
A.Verification of Correct Software
B.Simulations/Testing Methods
C.Lessons Learned from Verification and Validation
VII.Documentation
VIII.Future Work
A.Unfinished Work
B.Moving Forwards
IX.Discussion
A.Things we Learned
Executive Summary
The business of volleyball analytics has yet to reach the magnitude as other sports industries such as baseball and basketball. Although statistical methods do exist for analyzing volleyball, they have not yet been incorporated into standard technologies. The goal of our project was to help bridge the gap left wide open by the current practices of volleyball stat taking.
Shot charting remains the standard method for which to collect and analyze the different passes on the court. While shot charting examines the collection of attack trajectories in search of a pattern, it does not look at a play as a single entity. Therefore we sought to create an easy to use mobile application that not only allows data to be stored via tablet input but gives the user a set of calculated patterns based off of an entire play instead of a single attack.
We were successful in meeting our initial goals and by the end of the semester have produced an Android mobile application, which is compatible with all tablets. Our application gives the user three main tools to help diagnose patterns for a given team. The first is the ability to enter new data through the user interface. The second is the provided Quick Analysis, which will run quickly enough to be used during time outs or breaks between games to gain valuable knowledge about the trajectory of plays so far. Lastly the user can run a Seasonal Analysis on data collected over a long period of time, from one game to an entire season. Resulting patterns can be shown for a variety of situations including all six possible rotations and a view pertaining to the overall common trajectories when looking at all rotations together.
While our final implementation meets the requirements we set for ourselves at the beginning of the semester, it is in no way complete. There are numerous extended capabilities we did not have the time to implement that we feel could prove extremely valuable to coaches or other users of our application. Aside from our extended features, there are a variety of different ways to expand upon our solution to this problem. Many of these ideas were considered in our planning process but we maintained focus on providing users with a clean and simple user interface that provided easily interpreted results.
Introduction & Motivation
The Problem:
Traditional volleyball statistics track players in isolation, but tells us very little about combinations of players, or actions on the court. Traditional statistics simply lack the ability to capture information about how a player performs in a certain situation.
Importance:
There is a method of stat collection called “shot charting” which involves drawing lines to depict the trajectory of an attack, and then looking for patterns in the collected lines. However, generally shot charting is very limited in scope because the more pieces of a play that get collected, the more difficult it is for a person to identify the patterns. The analysis of this data is interesting because with enough data, it could start to give meaningful recommendations about where a team’s situational strengths and weaknesses lie, which is very advantageous information to have.
Proposed Solution:
We built an analysis engine that identifies patterns in the flow of a volleyball team’s games, and then correlates that data to a number of kills achieved. By doing this, we are able to find the strongest and weakest scenarios for a team, which allows teams to train under very specific conditions to address these things. It could also be used to analyze an opposing team. With good scouting before a big match, this kind of analysis could be used to discover the opposing team’s biggest weakness, and use it to your advantage.
Merits of Solution:
Our solution allows us to find patterns in entire plays, which quickly becomes too difficult for humans given the complexity of the plays in even one rotation. This means that given enough data, we can make recommendations to coaches about where their team’s weaknesses and strengths lie. We can also run our analysis based only on the current match, which can help give a team good data about how where the opposing team’s weaknesses and strengths lie.
Project Planning
Organization
Client:
For our project our clients consist of Professor Davison, and volleyball coaches/statisticians who want an idea of how their team functions as a unit in certain types of situations.
Communication and Meetings with Client:
Since each of us worked on a different part of our project, we agreed that we should both maintain communication and attend weekly meetings with our client. We arranged to meet with Professor Davison every Monday at 10:10 AM. Our progress reports were turned in on a weekly basis by Sunday evening.
Technical Requirements
Development Platform:
We’ll be using Android for our UI, Solaris for our backend, and Oracle for our database.
Development Environment/Software/Languages:
We used Eclipse as our IDE, and Java for our software development. We also used Oracle SQL for our database interactions.
Performance Requirements:
Most of our application is not performance critical, the piece that is mildly performance critical is the timeout analysis. This is because a typical timeout in volleyball only lasts about a minute, so we would like to have the analysis done in less than 10 seconds.
Resources Required:
We will need an Android tablet (we will be using a Nexus 7 for this project), access to an Oracle database, and the ability to run a service out of the Sunlab or a similar facility. We are acquiring the tablet privately, and we are working with various faculty members to get access to the others.
Testing Methods:
We will consider our program correct, when it produces what we deem to be reasonable recommendations based on the data that we give it. Unfortunately, we don’t think it will be possible to track this data with unit testing because of the possibility of a range of variance in the outputs. We will consider the User Experience correct when the GUI performs the actions the user requests and relays any appropriate information about them back to the user. Finally, we will consider the GUI (and the architecture correct) when it meets all of the user specifications.
Project Management
Brief Description of Project Execution:
Our list of tasks is roughly as follows:
●Our developing environment and repository will be set up
●We will acquire a tablet and access to an Oracle database
●We will set up our database
●We will mockup GUI
●The data layer will be implemented
●The engine will be implemented
●The UI will be implemented
●Testing and tweaking will begin
Requirements:
1Programmer-defined zone divisions
2Native Android app
3Database schema that supports the following:
●Player
●Zone
●Subzone
●Coordinates (Destination, Origin)
●Action IDs (previous, self, next)
●Play ID (previous, self, next)
●Half Play ID (previous, self, next)
●Match ID
●Result of Play
●Whether or not the action ended the play
●Rotation
4Calculation/recommendation modes
● Timeout Analysis: must be very fast, and based on match data (maybe match data for the opposing team, but season data for the user's team)
●Season Analysis: speed is not an issue, all data should be thoroughly examined
●The program should point out patterns (and make recommendations based on them) that it recognizes such as:
○Defensive Weaknesses
○Defensive Strengths
○Offensive Strengths
○Serve-Receive Patterns
○All of the attributes mentioned above based on each rotation
5Clean, Intuitive GUI
●Precise drawing capturing for play charting
6 The architecture of the program should be extremely modular to support future extensions.
●Specifically, it should separate the data entry functionality and the analysis
●Having such an interface defined will allow for the analysis engine to be used under many UIs and methods of gathering the necessary data.
Risk Areas:
Our biggest risk area will be getting the GUI to communicate with the service. To minimize this risk, we will be keeping our I/O interface as simple as possible and using reliable access methods such as SSH to transfer our data.
Interfaces:
We will need an interface between the database and the engine, and between the engine and the GUI, and obviously the GUI. We will not really be integrating our work with an existing codebase.
Self-Evaluation of Progress:
We will consider our progress satisfactory if we meet our timeline. However, if something unexpected crops up, we will have to revise our timeline, and we will consider a reasonable amount of progress in resolving the unforeseen issue(s) as satisfactory.
Software Design
Components
Database:
This is where we keep all of our information about matches and plays. It contains every action and its result and maps each action to a play, and each play to a match.
Algorithms:
These are the lifeblood of the program. They allow us to analyze a collection of plays and discover meaningful patterns about what typically happens in them. We use these algorithms to discover the patterns that we use to identify the weakest and strongest plays for a team, as well as a team’s typical response to a given player’s serve.
Seasonal Analysis:
This runs our algorithms for every play stored in the database. This allows us to mine the data for our team over the course of an entire season to discover the strongest and weakest patterns for the team in each rotation individually, and also for all of the rotations together.
Quick Analysis:
This analysis method runs our algorithms for only the data from the match that is currently being entered. This can be useful in discovering how to defend against/take advantage of the opposing team.
User Interface:
The UI is responsible for receiving user input and displaying the results produced by our algorithms. When starting the application the user is presented with three main choices, to view the instructions page, add a new match, or run the seasonal analysis.
●The Instructions page gives a general outline and explanation for the format of results returned along with how to enter new data.
●The New Match button allows the user to enter new plays, run a quick analysis on those plays, and display the results of the analysis to the screen.
●The Season Analysis button takes the user to a screen displaying the recommendations for the entire season’s matches. The user has options to view the results for all rotations or for each individual rotation (1-6).
Dependencies
The system dependencies are as follows:
- The GUI depends on the Client
- The Client depends on the Server
- The Server depends on the Engine and DataIO
- DataIO depends on the Database
Intercommunication
Communication between different components is as follows:
●The server communicates with the engine, and with DataIO.
●DataIO is the only class allowed to directly communicate with the database.
●The client communicates with the server.
●The GUI communicates with the client (they are kind of intertwined).
●The server acts as the gatekeeper to the backend. No outside classes are allowed to directly communicate with the engine or DataIO. Similarly, DataIO is the gatekeeper for the database.
Design Techniques Used
A few of these features were mentioned in our requirements document:
●"Design for Extensibility"
○The architecture of the program should be extremely modular to support future extensions.
○Specifically, it should separate the data entry functionality and the analysis
○Having such an interface defined will allow for the analysis engine to be used under many UIs and methods of gathering the necessary data.
●"Make sure the problem is well defined"
○This technique is clearly defined by the detail provided in our requirements document. The document does a meticulous job of mapping out the problem and detailing our proposed solution
Implementation Results
Initial and Final Project Schedules (Gantt Chart)
Below is our final version of our project schedule. Unfortunately we lost access to our original Gantt chart from the beginning of the semester. However we can detail how our progress matches up to the schedule shown below and our original expectations.
After the last week in October we fell a week behind on almost every component of our schedule due to hurricane Sandy. This meant that implementations on the server and for the UI were delayed a week before implementation, causing a delay in the start of Client-Server Communication implementation.
UI Delays:
●Respond correctly to user input: Originally we had planned on giving the user to draw plays by dragging his/her finger across the screen. After this functionality was mostly implemented, we made the decision to change the input method from a dragging motion to points of contact with the ball. Due to the redesign of the input method, the implementation of this feature took longer than expected.
●Season Analysis Display: This feature was mentioned in our initial requirements but was left out of our Gantt chart planning. Once the Quick Analysis recommended plays could be accurately displayed the seasonal analysis layout was implemented. This took approximately two days to implement once the technology on the back end worked for a regular match analysis.
Backend Delays:
●Client-Server communication: Between the unforeseen issues with Android and the mishap with returning nulls in finally blocks, we lost several days attempting to debug the client-server connection.
●Engine: We initially missed a couple of edge cases in the engine that caused it to throw some ArrayIndexOutOfBounds exceptions. These exceptions magically broke the debuggers on the computers that they occurred on, which also slowed us down.
Overall Results
Our overall results were very good. The program can successfully collect and interpret user input, and perform pattern analysis on the data it’s given. Additionally, our app can display the results to the user in a way that they can visually interpret. We also think that we succeeded in creating an attractive, and user-friendly GUI.
Design
We had originally planned to have the entire application run natively on Android, but we ultimately decided to run the backend on a remote server for a couple of reasons. The first was that neither of us knew how to work with Android’s flavor of SQL, and the second that we thought that we might not have enough processing power to crunch our data in a timely fashion. The decision to run the backend remotely meant a couple of things for the architecture. The most impactful, was that it required us to use a client-server model to communicate between the frontend and backend. This communication was tricky to get right, and caused us some major problems.
Problems
Throughout the course of the project, we encountered many problems that could not have been resolved by testing. These problems ranged from debugger errors to code inconsistencies. They simply cropped up and substantially slowed our progress.
One of these problems was that when testing our Server code, if an ArrayOutOfBoundsException occurred, the debugger became permanently broken on that computer, saying that SignatureParser.class could not be found. We found no way to fix this problem, and when trying to debug the interactions between the GUI and the backend, this was significantly damaging to our development cadence.
Another problem that we encountered was with SVN. It would seemingly randomly corrupt our repositories. Until we started checking in small changes very frequently, this continued to hamper our progress.
In addition to problems with our SVN and debugger, we encountered a few problems when integrating the android portion of our code with the work done on the back end. Since all the code for the UI was created with Android functionality in mind, many Android-specific tools and methods were utilized. When we began adding components to the Android code to connect with the back end, some of the features built into both sides of the system did not properly match up. After spending time breaking down the problem we eventually added additional classes and methods supported by Android to enable the user interface to accurately interact with the server.