STARTING THE ANALYSIS: DEVELOPING NOTATIONAL SYSTEMS

The information that is available during a game is diverse and extensive. As the continuous action and dynamic environment make data collection difficult, any quantitative analysis

of a sporting context must be structured effectively. As there are so many ways to collect information about any sport, when developing a notational instrument two very important points should be considered:

1. There should be consultation about the purpose of the analyses with the best technical expert of the game (e.g. a coach). Issues that should be addressed in this context include, What is the question about the sport that needs answering? and, What are the important performance indicators?

2. The potential use of the information should guide how the system will be designed, i.e. what is required from the analysis system should be completely determined before starting.

In conjunction with these, the first step is to create a flow-chart or logical structure of the game itself. This means defining the possible actions in the game, thus describing a sequential path that the game can take. For example, in a team sport such as field hockey, Franks and Goodman (1984) described the game very simply by a two-state model. Either team A has possession of the ball or the opposing team B does. This would be at the top of what Franks and Goodman termed the hierarchy. The next level of questions in the hierarchy would be:

1. Where on the field did Team A or Team B gain and/or lose possession?

2. Can these areas be easily identified (e.g. by dividing the field into six areas)?

3 Who on the team gained or lost possession?

4. How was possession gained and lost (e.g. was it from a tackle, an interception, a foul)?

These questions can be included in a structure as indicated in Figure 9.2. While this level of analysis is obviously very simple, the questions posed can yield extremely useful

notational analysis for coaches

105

BALL POSSESSION

GAINED LOST

Where was it gained/lost?

Specify position Who was involved in gaining/losing possession?

Specify player How was it gained/lost?

Specify action

Figure 9.2

A hierarchically structured model for representing events that take place in an invasion team game such as field hockey, soccer, basketball or water polo

information. Furthermore, they can be easily produced and translated into pictorial representations. More detailed analyses might be concerned with specific techniques or include physiological and psychological parameters that are mapped along a time axis during the performance. No matter what the intended analysis is, it is advised to always start as simply as possible and gradually add other actions and their outcomes. Franks and Goodman (1984) go on to suggest three steps or tasks to be undertaken in the evaluation of performance. These are:

TASK 1: Describe your sport from the general to the specific.

TASK 2: Prioritise key factors of performance (see Figure 9.2).

TASK 3: Devise a recording method that is efficient and easy to learn.

Detailed actions and outcomes (e.g. where and how possession was won and/or lost) can then be incorporated into a model for the events that take place.

Figure 9.3 demonstrates how such actions are subsequently built up into a picture of the game observed. Hence, as possession is gained by one of the players, a number of actions are available to him or her. The outcome of the action determines whether his or her side retains possession, scores a goal, gives away a free kick, etc. Inevitably this notational system (like any other) can be made more sophisticated. For example, the dribble, run, tackle or foul have not been included, nor have any actions when not in possession. The difficult decision to make in designing this type of model is knowing when the limitations of the model are acceptable within the terms of reference of the desired data.

The core elements of player, position and action are fundamental to most, if not all, analysis systems, although they do not need to be always included. For example, if the aim was to analyse the attacking patterns of a hockey team, we would not need to record the players’

identities, only their position on the pitch, the actions undertaken and any outcomes.

However, if we were examining the work rate of a particular player we would need to focus on the player in question, his or her position, action (stand, walk, jog, run etc.) and, possibly, the time. Building on this, the developed system in Figure 9.4 shows the simple logic needed to record and analyse the key elements of performance within the game of squash. The flow-chart (i.e. Figure 9.4) is complicated a little by the concept of lets and strokes. A let is when one player impedes the other in the process of his/her shot, which results in the rally being played again; no change in score, same server. A stroke is given against a player when he/she prevents the opponent from hitting the front wall with a direct shot or prevents a winner. Consequently, a stroke given against a player is equivalent to the player conceding an error.

Creating a model for the sequence of shot production and the respective positions from where shots are played is relatively straightforward. Hence, in most simple systems for racket sports, analysts will start with a winner/error analysis, recording the type of shots that were winners or errors and from where on the court they were played. However, to include the scoring system would require some additions to this flow-chart. The basis of

Good

Figure 9.3 A simple schematic flow-chart of soccer

the so-called English scoring in squash is that the server receives a point if he or she wins the rally. If the non-server wins the rally he or she does not receive a point but wins the right to serve. One way of incorporating the logic of scoring, and who serves, into the model would be to keep the definition of the server and non-server throughout the rally.

This would help clarify if the score increased at the end of the rally or not, depending on who won. The selection of these and other actions to be inserted into such models is determined by the degree of complexity required (Hughes and Franks 2004).