O documento descreve uma pesquisa sobre classificação de chutes a gol em jogos de futebol de robôs simulados utilizando mineração de dados. O objetivo era extrair conhecimento sobre este importante evento esportivo a partir de logs das partidas para melhorar a análise de desempenho. Foi desenvolvido um classificador que melhorou em 13,99% a classificação de chutes a gol comparado ao método existente, demonstrando a viabilidade de se criar ferramentas avançadas de análise para o esporte de robôs.

1. Bruno Vinicius Silva
Mineração de dados para análise quantitativa
de chutes a gol em um ambiente de simulação
de futebol de robôs em duas dimensões
Salvador-BA, Brasil
14 de julho de 2014

2. Bruno Vinicius Silva
Mineração de dados para análise quantitativa de chutes a
gol em um ambiente de simulação de futebol de robôs
em duas dimensões
Monografia para Trabalho de Conclusão de
Curso de graduação. Áreas de estudo: Mine-
ração de Dados, Aprendizado de Máquina,
Reconhecimento de Padrões, Análise Quanti-
tativa Esportiva e Robótica Inteligente.
UNEB - Universidade do Estado da Bahia
Departamento de Ciências Exatas e da Terra
Curso de Sistemas de Informação
Orientador: Prof. MSc. Marco Antônio Costa Simões
Salvador-BA, Brasil
14 de julho de 2014

3. Bruno Vinicius Silva
Mineração de dados para análise quantitativa de chutes a
gol em um ambiente de simulação de futebol de robôs
em duas dimensões
Monografia para Trabalho de Conclusão de
Curso de graduação. Áreas de estudo: Mine-
ração de Dados, Aprendizado de Máquina,
Reconhecimento de Padrões, Análise Quanti-
tativa Esportiva e Robótica Inteligente.
Monografia apresentada como exigência para obtenção do grau de bacharel no
curso de Sistemas de Informação da Universidade Estadual da Bahia. Entregue por Bruno
Vinicius Silva em 14 de julho de 2014, Salvador-BA, Brasil:
Prof. MSc. Marco Antônio Costa Simões
Orientador, Professor da Disciplina
Universidade do Estado da Bahia
Prof. Ph.D Diego Gervasio Frías Suárez
Professor Convidado
Universidade do Estado da Bahia
Prof. Ph.D Josemar Rodrigues de Souza
Professor Convidado
Universidade do Estado da Bahia
Salvador-BA, Brasil
14 de julho de 2014

4. Ao visionário, ao guerreiro,
ao mestre e ao curador.

5. Agradecimentos
Essa monografia é uma festa. Do “homem das máquinas” para sua avó Vivalda,
que esperou enquanto pôde. E o primeiro pedaço vai para minha mãe, por sempre me
cuidar com tudo que pode. O segundo vai para meu tio José, que me ajudou a realizar
tudo que pude. A vocês, mais do que todos, sou grato.
A minha madrinha, todos meus outros tios e familiares, aprendo cada vez mais
sobre a importância de vocês. À família que eu escolhi, Zélia e todos os seus filhos: Ohana.
A Felipe e Raul, que me acompanharam do primeiro trabalho à monografia, agora sócios,
eu não teria conseguido se não estivéssemos juntos nessa. A Ju em especial, companheira,
competidora e tantos outros papéis em (quase) todas as disciplinas e na vida.
A Caio, grande parceiro de crescimento, por segurar todas as pontas para que
eu pudesse terminar esse trabalho e pelas incontáveis horas de conversa. A Adailton e
Adriano, grandes amigos, apesar da traição de se formarem primeiro: agora sigo logo atrás
de vocês. A Grimaldo, pela inspiração e pela ajuda com modelagem: imagino que não é
fácil ajudar alguém que sempre quer ter razão. Aos amigos não citados, de antes, durante
e depois da UNEB, sem mimimi, sou grato a todos vocês.
Ao ACSO, que fez parte de quase toda minha caminhada na UNEB e foi também
o caminho. Voltar para uma monografia sobre futebol de robôs, não poderia ser diferente.
A Marco Simões, que curiosamente nunca foi meu professor numa disciplina, mas que
até mesmo virou noite junto programando o Bahia2D, durante as alegrias e tensões das
Robocups. Isso contou muito mais. A Diego Frias por me inspirar, não teria entrado no
mundo da modelagem computacional sem sua participação.
A Cláudio Amorim, figura raríssima, por ter me levado muito além do tékhne
(#somostodosornitorrincos). A Jorge Farias pelo primeiro impulso, que me carrega até
hoje, ensinando de forma brilhante os meus primeiros algoritmos. A Ana America, por
nos cuidar enquanto esteve no colegiado. E sem dúvida, a todo colegiado, professores e
coordenador por me aturarem mais tempo do que o devido, dando uma chance a esse
teimoso.
Devo agradecer também a muitos que nunca vi, mas que foram fundamentais. A
empresa Opta por fornecer de modo solícito as definições dos eventos de futebol. Aos
portugueses Luís Paulo e Pedro Abreu, ombros sobre os quais me apoiei mais diretamente
do que os demais. A Robocup, em especial a Itsuki Noda, Hidehisa Akiyama e todos que
trabalharam nas ferramentas e bibliotecas públicas relacionadas. Ao grupo que mantém o
pacote Abntex2 para o LaTeX, não faço ideia de quantas horas me pouparam, para que
pudesse focar no mais importante. Ao Ian Witten e todos envolvidos na Univesidade de

6. Waikato com a ferramenta WEKA, excelente trabalho (também pelo curso aberto oferecido
ao mundo). A todos, de tantas linhas de código, dos softwares gratuitos que pude utilizar.
Muito obrigado.

7. “Everything should be made as simple as possible,
but not simpler.”
Albert Einstein
“Un faro quieto nada sería
guía, mientras no deje de girar
no es la luz lo que importa en verdad
son los 12 segundos de oscuridad.
Para que se vea desde alta mar...
De poco le sirve al navegante
que no sepa esperar.
Pie detrás de pie
no hay otra manera de caminar”
Jorge Drexler / Vitor Ramil

8. Resumo
Este trabalho demonstra que é possível classificar automaticamente eventos complexos
ocorridos durante jogos de futebol de robôs da Liga de Futebol Simulado Robocup 2D.
Utilizando a metodologia CRISP-DM foi realizado um processo completo de Descoberta de
Conhecimento em Bases de Dados sobre os logs das partidas. O objetivo desse processo foi
extrair conhecimento acerca de chutes a gol, o que está relacionado a algumas das métricas
mais importantes no futebol para analisar o desempenho de uma equipe e também com
os eventos com a pior classificação automatizada reportada na literatura (ABREU et
al., 2011). Utilizando uma análise pós-simulação, offline, baseada em técnicas clássicas
de mineração de dados, foi criado um classificador que melhorou em 13,99% o baseline
existente. Esse trabalho é um bom indicativo da viabilidade de desenvolver uma ferramenta
de análise de desempenho completa, que capte as diversas métricas utilizadas no futebol
real também no ambiente de futebol de robôs simulado, o que significaria uma importante
evolução nos métodos de teste e experimentação utilizados atualmente.
Palavras-chave: Mineração de Dados. Aprendizado de Máquina. Reconhecimento de
Padrões. Análise Quantitativa Esportiva. Robótica Inteligente. Robocup.

9. Abstract
This project shows that it is possible to automatically classify complex events that take
place during robot soccer games from the RoboCup 2D Soccer Simulation League. Using
the CRISP-DM methodology a complete Knowledge Discovery in Databases process was
run over matches log files. The purpose was to extract knowledge about shots on goal, which
are related to some of the most important soccer metrics to analyze the performance of a
team and are also related with the events with worst automated classification, according
to literature (ABREU et al., 2011). Using an offline post-simulation analysis, based on
classic data mining techniques, it was created a classifier that has improved the existent
baseline by 13,99%. This project offers a good indicative on the feasibility of developing a
tool to do a complete performance analysis, one that would capture the several key metrics
used on real soccer now on simulated soccer, which could mean an important improvement
to testing and experimentation methods currently being used.
Keywords: Data Mining. Machine Learning. Pattern Recognition. Quantitative Analysis
in Sports. Intelligent Robotics. Robocup.

10. Lista de ilustrações
Figura 1 – Visão geral da Robocup 2012 durantes as competições . . . . . . . . . 21
Figura 2 – Arquitetura do Robocup Soccer Simulator . . . . . . . . . . . . . . . . 26
Figura 3 – Soccer Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Figura 4 – LogPlayer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Figura 5 – As flags e linhas do campo simulado . . . . . . . . . . . . . . . . . . . 31
Figura 6 – Área do tackle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Figura 7 – Área do catch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Figura 8 – Exemplo de conteúdo dos arquivos RCG e RCL . . . . . . . . . . . . . 42
Figura 9 – Interface do TeamAssistant2003 . . . . . . . . . . . . . . . . . . . . . . 47
Figura 10 – Interface do LogAlyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Figura 11 – Interface do OptaPro . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Figura 12 – A essência da mineração de dados . . . . . . . . . . . . . . . . . . . . . 60
Figura 13 – As fases do processo CRISP-DM . . . . . . . . . . . . . . . . . . . . . 61
Figura 14 – A tarefa de classificação . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Figura 15 – Abordagem geral para construir um modelo de classificação . . . . . . 64
Figura 16 – Scatterplot Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Figura 17 – Caras de Chernoff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Figura 18 – Exemplo de overfitting . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Figura 19 – Aba de classificação da ferramenta WEKA . . . . . . . . . . . . . . . . 76
Figura 20 – Metodologia do projeto: dos dados aos resultados . . . . . . . . . . . . 80
Figura 21 – Fase 2: Compreensão dos dados . . . . . . . . . . . . . . . . . . . . . . 82
Figura 22 – Estudo sobre a velocidade da bola em chutes do time Bahia2D . . . . . 86
Figura 23 – Fase 3: Preparação dos dados . . . . . . . . . . . . . . . . . . . . . . . 88
Figura 24 – Diagrama ER do Repositório Intermediário . . . . . . . . . . . . . . . 89
Figura 25 – Diagrama de Classes do RCG2DB . . . . . . . . . . . . . . . . . . . . . 90
Figura 26 – Diagrama de Classes do ShotCandidatesDetector . . . . . . . . . . . . 91
Figura 27 – O problema da bola fora . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Figura 28 – Lances e decisões do algoritmo de detecção de candidatos . . . . . . . . 94
Figura 29 – Diagrama de Classes do RCGCutter . . . . . . . . . . . . . . . . . . . 95
Figura 30 – Lance de Shot on target sendo visualizado e classificado . . . . . . . . . 96
Figura 31 – Exemplo das 4 cenas selecionadas em um caso de Shot on target . . . . 98
Figura 32 – Diagrama de Classes do FeatureSE . . . . . . . . . . . . . . . . . . . . 101
Figura 33 – Diagrama de Sequência do FeatureSE . . . . . . . . . . . . . . . . . . . 102
Figura 34 – Fase 4: Modelagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Figura 35 – Totais das classes finais . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Figura 36 – Distribuição das classes por algumas características . . . . . . . . . . . 105

11. Figura 37 – Diferença dos ângulos x Distância da bola no lastKick . . . . . . . . . 106
Figura 38 – Exemplo de casos filtrados . . . . . . . . . . . . . . . . . . . . . . . . . 108
Figura 39 – Conjunto final mais balanceado após filtragens . . . . . . . . . . . . . . 108
Figura 40 – Experimento configurado e pronto para ser executado . . . . . . . . . . 111
Figura 41 – Comparação dos modelos sendo realizada no WEKA . . . . . . . . . . 114
Figura 42 – Ferramenta para visualizar chutes a gol . . . . . . . . . . . . . . . . . . 120
Figura 43 – Métricas de desempenho de acordo com a força dos times . . . . . . . . 121

12. Lista de tabelas
Tabela 1 – Comparação entre os ambientes do xadrez e do futebol . . . . . . . . . 23
Tabela 2 – Parâmetros do servidor relacionados ao modelo de movimento . . . . . 34
Tabela 3 – Capacidade de atuação - ações primárias . . . . . . . . . . . . . . . . . 38
Tabela 4 – Capacidade de atuação - ações concorrentes . . . . . . . . . . . . . . . 38
Tabela 5 – Parâmetros relacionados aos jogadores heterogêneos . . . . . . . . . . . 39
Tabela 6 – Mensagens enviadas pelo juiz . . . . . . . . . . . . . . . . . . . . . . . 41
Tabela 7 – Dados sobre chutes a gol (ABREU et al., 2011) . . . . . . . . . . . . . 49
Tabela 8 – Resultados para a detecção de chutes a gol (ABREU et al., 2011) . . . 49
Tabela 9 – Hierarquia sobre a relação entre organizações e dados esportivos . . . . 54
Tabela 10 – Matriz de confusão para um classificador multiclasse . . . . . . . . . . 67
Tabela 11 – Matriz de confusão para um classificador binário . . . . . . . . . . . . 72
Tabela 12 – Matriz de confusão um-contra-todos para classe 𝐶1 . . . . . . . . . . . 75
Tabela 13 – Divisão dos times da Robocup 2013 . . . . . . . . . . . . . . . . . . . . 83
Tabela 14 – Resumo dos casos na classificação manual . . . . . . . . . . . . . . . . 96
Tabela 15 – Resumo das características numéricas . . . . . . . . . . . . . . . . . . . 104
Tabela 16 – Variações nas características finais . . . . . . . . . . . . . . . . . . . . 109
Tabela 17 – Resultados do segundo experimento . . . . . . . . . . . . . . . . . . . . 115
Tabela 18 – Matriz de confusão do modelo vencedor . . . . . . . . . . . . . . . . . 116
Tabela 19 – Resultados por classe e métrica para o modelo vencedor . . . . . . . . 117
Tabela 20 – Comparação entre o modelo vencedor e a heurística de Abreu . . . . . 117
Tabela 21 – Médias de cada métrica de acordo com a força dos times . . . . . . . . 121
Tabela 22 – Espaço amostral - times fortes . . . . . . . . . . . . . . . . . . . . . . . 131
Tabela 23 – Espaço amostral - times médios . . . . . . . . . . . . . . . . . . . . . . 132
Tabela 24 – Espaço amostral - times fracos . . . . . . . . . . . . . . . . . . . . . . 132
Tabela 25 – Algoritmos e parâmetros utilizados no WEKA: árvores . . . . . . . . . 133
Tabela 26 – Algoritmos e parâmetros utilizados no WEKA: regras e bayes . . . . . 133
Tabela 27 – Algoritmos e parâmetros utilizados no WEKA: funções e lazy . . . . . 134
Tabela 28 – Algoritmos e parâmetros utilizados no WEKA: meta e outros . . . . . 134

13. Lista de abreviaturas e siglas
ACC Accuracy
ACSO Núcleo de Arquitetura de Computadores e Sistemas Operacionais
ARFF Attribute-Relation File Format
CRISP-DM Cross Industry Standard Process for Data Mining
CSV Comma-separated Values
DM Mineração de Dados (Data Mining)
FDR False discovery rate
FN False negative
FNR False negative rate
FP False positive
FPR False positive rate
IA Inteligência Artificial
KDD Descoberta de Conhecimento em Bases de Dados (Knowledge Discovery
in Databases)
MDL Minimum Description Length
MIT Massachusetts Institute of Technology
NPV Negative predictive value
OvA Um-contra-todos (One-vs-All)
PPV Positive predictive value
ROC Receiver operating characteristic
SVM Support Vector Machines
TDP Team Description Paper
TN True negative
TP True positive

14. TNR True negative rate
TPR True positive rate
UNEB Universidade do Estado da Bahia
WEKA Waikato Enviroment for Knowledge Analysis

15. Sumário
Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
I Referenciais teóricos 20
1 Robot World Cup (Robocup) . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.1 Robocup Soccer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.2 Liga de Futebol Simulado Robocup 2D (Simulação 2D) . . . . . . . . . . . 23
1.2.1 Ferramenta de simulação Robocup Soccer Simulator . . . . . . . . . 25
1.2.1.1 Soccer Server . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.2.1.2 Soccer Monitor . . . . . . . . . . . . . . . . . . . . . . . . 27
1.2.1.3 LogPlayer . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.2.2 O ambiente simulado pelo Soccer Server . . . . . . . . . . . . . . . 29
1.2.2.1 O campo e os objetos fixos . . . . . . . . . . . . . . . . . . 30
1.2.2.2 Objetos móveis . . . . . . . . . . . . . . . . . . . . . . . . 30
1.2.2.3 Sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
1.2.2.4 Atuadores . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
1.2.2.5 Jogadores heterogêneos . . . . . . . . . . . . . . . . . . . 39
1.2.2.6 Técnico online e offline . . . . . . . . . . . . . . . . . . . . 39
1.2.2.7 Juízes e estados do jogo . . . . . . . . . . . . . . . . . . . 40
1.2.3 Os logs das partidas . . . . . . . . . . . . . . . . . . . . . . . . . . 41
1.3 Testes e experimentos na Simulação 2D . . . . . . . . . . . . . . . . . . . . 44
1.4 Outras ferramentas e trabalhos relacionados . . . . . . . . . . . . . . . . . 47
1.5 Semelhanças entre futebol real e simulado . . . . . . . . . . . . . . . . . . 50
2 Análise quantitativa nos esportes . . . . . . . . . . . . . . . . . . . . . . . . 52
2.1 Esportes e mineração de dados . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.2 Ferramentas comerciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
2.3 Definição de eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.4 Diferenças entre o futebol profissional e o de robôs . . . . . . . . . . . . . . 58
3 Mineração de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.1 Metodologia CRISP-DM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.2 Classificação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.3 Visualização de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.4 Generalização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.5 Técnicas de validação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.6 Avaliação e comparação de modelos . . . . . . . . . . . . . . . . . . . . . . 71
3.6.1 Métricas de desempenho para classificadores . . . . . . . . . . . . . 72

16. 3.6.2 F-measure para classificadores multiclasse . . . . . . . . . . . . . . 75
3.7 WEKA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
II Projeto 78
4 Fase 1: Compreensão do problema . . . . . . . . . . . . . . . . . . . . . . . 79
5 Fase 2: Compreensão dos dados . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.1 Análise qualitativa dos logs . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.2 Análise objetiva e descrição dos dados . . . . . . . . . . . . . . . . . . . . . 83
5.3 Seleção do espaço amostral . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6 Fase 3: Preparação dos dados . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.1 Carga do Repositório Intermediário . . . . . . . . . . . . . . . . . . . . . . 88
6.2 Seleção de casos candidatos . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.3 Edição de logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
6.4 Classificação manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
6.5 Engenharia de características . . . . . . . . . . . . . . . . . . . . . . . . . 97
6.5.1 Seleção de características . . . . . . . . . . . . . . . . . . . . . . . . 97
6.5.2 Extração de características . . . . . . . . . . . . . . . . . . . . . . . 99
6.5.3 Criação do vetor de características . . . . . . . . . . . . . . . . . . 101
7 Fase 4: Modelagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
7.1 Pré-processamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
7.1.1 Visualização e exploração dos dados . . . . . . . . . . . . . . . . . . 103
7.1.2 Filtragem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
7.1.3 Seleção de atributos . . . . . . . . . . . . . . . . . . . . . . . . . . 107
7.2 Modelagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
III Resultados 112
8 Fase 5: Avaliação dos resultados . . . . . . . . . . . . . . . . . . . . . . . . 113
8.1 Comparação entre os modelos criados . . . . . . . . . . . . . . . . . . . . . 113
8.2 Comparação com a literatura . . . . . . . . . . . . . . . . . . . . . . . . . 116
8.3 Revisão do processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
9 Fase 6: Implantação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
9.1 Sugestão de implantação do modelo . . . . . . . . . . . . . . . . . . . . . . 119
9.2 Análise da utilidade dos modelos . . . . . . . . . . . . . . . . . . . . . . . 120
9.3 Manutenção e evolução dos modelos . . . . . . . . . . . . . . . . . . . . . . 122

17. IV Conclusão 123
Conclusões e trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Apêndices 130
APÊNDICE A Logs do espaço amostral . . . . . . . . . . . . . . . . . . . . . 131
APÊNDICE B Algoritmos de aprendizado utilizados no WEKA . . . . . . . . 133
Anexos 135
ANEXO A Definições dos eventos da ferramenta OptaPro . . . . . . . . . . . 136

18. 17
Introdução
Este trabalho demonstra que é possível classificar automaticamente eventos com-
plexos ocorridos durante jogos de futebol de robôs da Liga de Futebol Simulado Robocup
2D (Simulação 2D). Foi realizado um processo completo de Descoberta de Conhecimento
em Bases de Dados (Knowledge Discovery in Databases, KDD) sobre os logs das partidas
para extrair conhecimento acerca de chutes a gol, uma das métricas mais importantes
no futebol para analisar o desempenho de uma equipe e também o evento com a pior
classificação automatizada reportada na literatura (ABREU, 2010). Utilizando uma análise
pós-simulação, offline, baseada em técnicas clássicas de mineração de dados (data mining,
DM) foi criado um classificador superior ao baseline proposto, alcançando qualidade similar
à classificação realizada manualmente por especialistas.
Atualmente o tempo necessário para analisar de forma robusta o impacto que uma
mudança no software dos agentes inteligentes causa no desempenho do sistema como um
todo, o que demanda a análise manual de uma grande quantidade de logs, inviabiliza que
testes integrados sejam realizados do modo ideal e na frequência ideal. Uma das abordagens
mais comuns para superar essa limitação é definir o desempenho das equipes apenas em
função da quantidade de gols feitos e tomados, como vemos em artigos de descrição das
equipes (TDPs) de 2013 (RAMOS et al., 2013; LIN, 2013; PROKOPENKO et al., 2013;
HUANG et al., 2013; ZEKAI-CHENG et al., 2013).
Essa abordagem, apesar de funcionar como um método para avaliação do desem-
penho, desconsidera o potencial das informações escondidas nos dados de cada log. Isso
torna mais difícil que os resultados observados nos experimentos sejam compreendidos e
que novas hipóteses sejam levantadas: os gols podem definir o desempenho da equipe mas
não revelam nenhuma pista do porquê desse desempenho.
Esse cenário no ambiente de pesquisa do futebol de robôs contrasta com o ambiente
comercial do futebol real, onde especialistas de domínio como técnicos e olheiros possuem
uma ampla variedade de estatísticas de alto nível sobre as quais podem pautar importantes
tomadas de decisão. Empresas como a Opta Sports, por exemplo, coletam mais de 200
variáveis por jogo (BATEMAN, 2012), além de fornecerem ferramentas para realizar
diversas interações com esses dados.
Esse trabalho buscou diminuir a distância entre esses dois campos demonstrando a
viabilidade de classificar automaticamente eventos complexos da Simulação 2D, apresen-
tando um caminho viável para o desenvolvimento de ferramentas similares para o domínio
da pesquisa científica com futebol de robôs. Com a extração automática de conhecimento a
partir dos logs, orientado pelo que vem sendo aplicado comercialmente no futebol, torna-se

19. Introdução 18
mais fácil realizar comparações entre o futebol de robôs e o futebol real, como a realizada
em (ABREU et al., 2012), úteis para a compreensão do avanço da área.
Ainda mais importante, o trabalho colabora com a discussão sobre o difícil problema
de testar os sistemas multiagentes (GATTI; STAA, 2006), podendo seus resultados serem
utilizados como a base para uma abordagem caixa-preta de testes integrados dos times
participantes da Simulação 2D. Isso porque estatísticas de alto nível podem ser a base
para uma metodologia robusta para análise de desempenho na Simulação 2D, problema
de pesquisa que ganhou destaque durante uma competição em 1998 e permanece um
problema aberto (CHEN et al., 2003).
Por fim, cria novos caminhos para melhorar o desempenho das equipes, pois a
tese de doutoramento de Abreu (2010), que teve como questão de pesquisa: “How to
improve the performance of a soccer team through the calculation of final game statistics”1
,
comprovou que é possível melhorar o desempenho dos times da Simulação 2D a partir do
uso de estatísticas de alto nível.
O restante da monografia está organizada como segue:
1. Parte I: Referenciais teóricos
a) O Capítulo 1 detalha o contexto do problema. Primeiro é apresentada a
Robot World Cup Initiative (Robocup), e os dados dos logs são estudados
a fundo a partir de informações técnicas sobre o ambiente da Simulação 2D.
Depois os métodos de teste utilizados na liga são explorados para deixar clara a
necessidade de métricas de desempenho. O capítulo termina com a apresentação
dos trabalhos relacionados mais importantes;
b) O Capítulo 2 aponta para a solução ao introduzir a análise quantitativa do
ponto de vista do futebol profissional. É apresentada uma análise sobre as
métricas de desempenho utilizadas nesse domínio e são selecionados e definidos
os eventos a serem detectados na Simulação 2D. Aqui também são explicitadas
as diferenças entre o futebol real e o futebol simulado, incluindo o estado da
arte da análise quantitativa em ambas as áreas;
c) O Capítulo 3 mostra o caminho para se chegar do problema até a solução. A
área da Mineração de Dados é explorada, com foco no problema de classificação.
São discutidas a metodologia para o desenvolvimento do trabalho, além dos
problemas relacionados mais importantes, como generalização e validação.
2. Parte II: Projeto
1
“Como melhorar o desempenho de um time de futebol através do cálculo de estatísticas finais de jogo”
(Tradução do autor)

20. Introdução 19
a) O Capítulo 4 ao Capítulo 7 apresentam as 4 primeiras etapas do KDD,
que vão desde a definição dos objetivos do projeto até o desenvolvimento dos
classificadores.
3. Parte III: Resultados
a) O Capítulo 8 e Capítulo 9 apresentam as 2 últimas etapas do KDD, onde os
resultados obtidos são analisados, o processo é revisado e a evolução do modelo
proposto é documentada.
4. Parte IV: Conclusão
a) Resume as contribuições da monografia e destaca possibilidades interessantes
de trabalhos futuros.

21. Parte I
Referenciais teóricos

22. 21
1 Robot World Cup (Robocup)
A Liga de Futebol Simulado Robocup 2D, ou apenas Simulação 2D, é a plataforma
que foi utilizada nesse trabalho. Ela é uma das ligas de simulação que fazem parte da
Robocup, projeto que visa promover a pesquisa e educação sobre Robótica e a Inteligência
Artificial (IA) através, principalmente, do futebol de robôs (KITANO et al., 1997). A
iniciativa teve sua origem em 1993 no Japão, como uma competição nacional de robótica,
mas devido a aderência que obteve da comunidade científica internacional, em apenas
um mês o projeto já havia sido renomeado como Robot World Cup Inititive (Robocup) e
ganhado proporções mundiais (ROBOCUP, 2013a).
Figura 1 – Visão geral da Robocup 2012 durantes as competições
Fonte: (The Verge, 2012)
Desde então, anualmente a Robocup promove num país diferente o que se tornou
um dos maiores e mais importantes eventos de robótica autônoma do mundo, em que
participam pesquisadores de mais de 40 países e que conta com competições, diversas
demonstrações e também com um simpósio onde são discutidos e compartilhados os
avanços científicos na área (a Figura 1 mostra a dimensão do evento). Apesar de sua
origem ter se dado por conta do futebol de robôs e esse continuar sendo o principal foco da
iniciativa, o amadurecimento da Robocup levou a criação de diferentes categorias. Como
visto em (ROBOCUP, 2013c), as 6 categorias do evento oficial de 2013 foram:

23. Capítulo 1. Robot World Cup (Robocup) 22
• Robocup Soccer para robôs especializados em jogar futebol;
• Robocup@Home para robôs domésticos;
• Robocup Rescue para robôs de resgate;
• Robocup@Work para robôs industriais;
• Robocup Sponsored que em 2013 trouxe um desafio para aplicações de robótica na
área de logística;
• RobocupJunior voltada para introduzir estudantes do primário e ginásio no universo
da robótica.
1.1 Robocup Soccer
Robocup Soccer, principal categoria da Robocup, é a categoria relevante para esse
trabalho. Seu arrojado objetivo é, como publicado em (ROBOCUP, 2013a):
By mid-21st century, a team of fully autonomous humanoid robot soccer
players shall win the soccer game, comply with the official rule of the
FIFA, against the winner of the most recent World Cup1
.
Utilizar jogos entre máquinas e humanos é uma abordagem comum na Inteligência
Artificial (IA), já que especialistas humanos são um excelente baseline para inteligência.
Essa estratégia é útil tanto por ajudar a medir o progresso na área quanto por manter
pesquisadores focados e motivados, uma vez que o desafio da IA quando vista de modo
geral é muito grande, como explica em (HAMM, 2012) um dos projetistas do Deep Blue,
Murray Campbell:
If you try to tackle something like general intelligence, you’ll die out of
the blocks. It’s too much. But, with games, you focus on one specific
problem. You have a chance to make progress and produce something of
value that can be used as a component of something bigger.2
O IBM Deep Blue foi um supercomputador criado para ser especialista em jogar
xadrez, e tem um papel de destaque na história da IA por ter derrotado pela primeira vez
um campeão do mundo na modalidade. O feito se deu sobre Garry Kasparov, considerado
um dos maiores enxadristas da história, em maio de 1997. O desafio do futebol, proposto
5 anos antes dessa representativa vitória do Deep Blue, gera na comunidade científica um
1
“Em meados do século 21, um time de robôs humanoides jogadores de futebol completamente autônomos
deve ganhar um jogo de futebol, utilizando as regras da FIFA, contra o mais recente vencedor da Copa
do Mundo.” (Tradução do autor)
2
“Se você tentar lidar com algo como inteligência geral, você vai falhar. Isso é demais. Mas, com jogos,
você pode focar em um problema específico. Você tem a chance de fazer progresso e produzir algo de
valor que pode ser usado como componente de algo maior.” (Tradução do autor)

24. Capítulo 1. Robot World Cup (Robocup) 23
impulso similar, capaz de redefinir o estado da arte da pesquisa nessa área, mas guarda
também importantes diferenças para o desafio do xadrez. Um resumo dessas diferenças de
acordo com classificação proposta em (RUSSEL; NORVIG, 2003) é listado na Tabela 1.
Tabela 1 – Comparação entre os ambientes do xadrez e do futebol
Propriedade Xadrez Futebol
Ambiente Estático Dinâmico
Resultado das ações Determinístico Estocástico
Mudança de estado Por turno Tempo real
Acesso a informação Completa Incompleta
Controle Central Distribuído
Fonte: Adaptado de (ROBOCUP, 2013a)
Essas características tornam o futebol um ambiente mais interessante que o xadrez
por reunir maior similaridade com ambientes reais e complexos, que representam desafios
atuais para a robótica. Sendo mais específico, o futebol abre espaço para endereçar
problemas como fusão de sensores, comportamento reativo, reconhecimento de contexto,
aprendizado de máquina, planejamento em tempo real, sistemas multiagentes, visão
computacional e controle motor. Um resumo sobre a conexão do futebol de robôs com esses
problemas é encontrada em (KITANO et al., 1997). Dada a complexidade desse ambiente e
o atual estado da arte na resolução desses diferentes desafios, a categoria Robocup Soccer
se encontra ainda subdividida em 6 ligas:
• Simulação 2D;
• Simulação 3D;
• Small Size;
• Middle Size;
• Standard Platform;
• Humanoide.
1.2 Liga de Futebol Simulado Robocup 2D (Simulação 2D)
Cada liga colabora de modo diferente para a grande meta da Robocup Soccer,
variando num espectro que vai desde ambientes 100% simulados, como a simulação 2D,
onde se abstrai a complexidade do hardware e do controle do robô, tornando o foco da liga
a elaboração e execução de estratégias coordenadas de alto nível; até ambientes 100% físicos
e com robôs humanoides desenvolvidos de forma independente, como a Liga Humanoide,

25. Capítulo 1. Robot World Cup (Robocup) 24
onde o principal desafio está no projeto, controle dos robôs e na execução bem realizada
das ações.
No estado atual de desenvolvimento da robótica autônoma para futebol é na
Simulação 2D onde podemos assistir partidas de futebol que mais se assemelham a uma
partida de futebol de verdade, tanto pela capacidade de jogar demonstrada pelas equipes
de ponta, quanto pela semelhança entre as regras utilizadas na simulação com as regras da
FIFA. O foco na estratégia presente na Simulação 2D e a sua semelhança com o futebol
real tornam essa liga o ambiente mais propício para a aplicação desse trabalho. Dada a
dinâmica dos jogos é provável que em nenhuma outra liga da Robocup uma visão resumida
do que acontece numa partida na forma de estatísticas de futebol traga o mesmo impacto
para as pesquisas.
A Simulação 2D é uma das ligas mais antigas da Robocup, presente desde a primeira
edição do evento, ocorrida em 1997, o que colabora para que a ambiente seja muito estável
e existam tantas equipes maduras. Já no ano seguinte à primeira Robocup, o grupo que
desenvolveu a primeira versão do simulador propôs que fosse criada uma ferramenta que
extraísse estatísticas de futebol para auxiliar as equipes a identificar suas forças e fraquezas
e mapear seus avanços (TANAKA et al., 1998). Apesar disso uma ferramenta de extração
de estatísticas de alto nível aberta às equipes não existe até hoje.
Um caso interesssante, relatado no próprio manual oficial do servidor da liga, reforça
e até mesmo amplia a relevância de uma ferramenta com esse propósito. A competição
de 1998 foi a primeira a abrigar uma sessão para avaliar a contribuição científica dos
participantes e estimular a transferência de conhecimento, foi a Multi-agent Scientific
Evaluation Session. Nesse evento, a adaptabilidade dos times era testada através de 4 jogos
contra um mesmo oponente, nos quais 3 jogadores eram desabilitados gradativamente.
Durante a sessão, dada a dificuldade em avaliar o desempenho das equipes de forma
criteriosa, encontrar uma metodologia para medir o desempenho dos sistemas e analisar os
resultados em si, foi considerado um problema de pesquisa em aberto (CHEN et al., 2003):
Very early on, even during the session itself, it became clear that while in
fact most participants agreed intuitively with the evaluation protocol, it
wasn’t clear how to quantitatively, or even qualitatively, analyse the data.
The most obvious measure of the goal-difference at the end of each half
may not be sufficient: some teams seem to do better with less players,
some do worse. [...] The evaluation methodology itself and analysis of
the results became open research problems in themselves.3
3
“Muito cedo, ainda durante a sessão, ficou claro que apesar da maioria dos participantes concordarem
intuitivamente com o protocolo de avaliação, não ficou claro como quantitativamente, ou mesmo
qualitativamente, analisar os dados. A medida mais óbvia de saldo de gols ao final de cada tempo
pode não ser suficiente: alguns times parecem jogar melhor com menos jogadores, alguns jogam pior.
[...] A metodologia de avaliação em si e a análise dos resultados se tornaram problemas de pesquisa
em aberto.” (Tradução do autor)

26. Capítulo 1. Robot World Cup (Robocup) 25
Esse trabalho, ao ampliar a oferta de dados sobre cada partida de modo prático,
é um passo intermediário para o desenvolvimento de uma ferramenta que suporte uma
metodologia robusta para análise de desempenho. Como conhecer profundamente os dados
é parte fundamental de qualquer trabalho de mineração de dados, o restante dessa seção
descreve em detalhes os aspectos relevantes da Simulação 2D para a detecção automática
de estatísticas. A motivação para a escolha de chutes a gol é explicada na seção 1.4, a
partir da análise dos trabalhos relacionados.
1.2.1 Ferramenta de simulação Robocup Soccer Simulator
Segundo (RUSSEL; NORVIG, 2003), um agente inteligente é uma entidade autô-
noma que percebe seu ambiente através de sensores e age nesse ambiente através de
atuadores de modo a maximizar o seu desempenho. O Simulador de futebol da Robocup é
um sistema que permite que agentes inteligentes desenvolvidos em diferentes linguagens
possam jogar futebol entre si (CHEN et al., 2003). Ele foi desenvolvido inicialmente em
1993 pelo Dr. Itsuki Noda no Japão e foi posteriormente adotado como o servidor padrão
para a liga 2D (BOER; KOK, 2002). O artigo de 1997 (NODA et al., 1998), ano em que
ocorreu a primeira Robocup, apresenta o simulador como uma importante ferramenta
para realizar pesquisas sobre sistemas multiagentes. Desde então ele já foi utilizado em
diversas competições internacionais e desafios de pesquisa, se tornando uma ferramenta
consagrada.
Atualmente o simulador é um projeto aberto mantido por pesquisadores envolvidos
com a Robocup e se encontra na sua versão 15 4
. Ele possui uma arquitetura cliente-servidor
e se comunica com os clientes através de conexões UDP (Figura 2), sendo três os seus
módulos principais (NODA et al., 1998; CHEN et al., 2003):
• Soccer Server: é o servidor central, principal componente da simulação. Ele provê um
campo virtual onde as partidas são disputadas, controla toda a física do ambiente,
aplica as regras de futebol e intermedia as interações entre os clientes.
• Soccer Monitor: esse módulo permite que as partidas sejam visualizadas por humanos
em tempo real. Ele se conecta com o SoccerServer para receber as posições de todos
os objetos no campo e cria uma representação gráfica do jogo a partir disso.
• LogPlayer: funciona como um reprodutor de vídeo, permitindo que as partidas sejam
visualizadas a qualquer momento a partir dos logs gerados pelo SoccerServer no fim
de cada partida. Agrega também algumas funções úteis para análise das partidas.
4
O simulador pode ser baixado de sua página no Source Forge: <http://sourceforge.net/projects/
sserver/>

27. Capítulo 1. Robot World Cup (Robocup) 26
Figura 2 – Arquitetura do Robocup Soccer Simulator
Fonte: (ABREU, 2010)
1.2.1.1 Soccer Server
O principal componente da simulação é um servidor central chamado Robocup
Soccer Server, que controla toda a física do ambiente, aplica as regras de futebol e
intermedia as interações entre os 11 jogadores (10 de linha e 1 goleiro) e 1 técnico de
cada um dos dois times. Cada jogador e técnico é controlado por um agente de software
autônomo e independente que recebe informações do servidor através de seus sensores
virtuais e deve decidir as ações que irá executar, de modo a influenciar o ambiente na
tentativa de maximizar seus objetivos. Os agentes funcionam então como os cérebros
dos jogadores e técnicos, tendo como únicas restrições obedecerem aos protocolos de
comunicação estabelecidos pelo Soccer Server e nunca se comunicarem diretamente.
O servidor é um sistema de tempo-real onde o tempo transcorre de forma discreta.
Cada partida é dividida em 6000 ciclos de 100 milissegundos (valor atual do parâmetro
simulator_step), que representam uma janela na qual cada agente pode enviar um conjunto
de comandos para serem processados pelo servidor. A cada ciclo o mundo é então atualizado
e o servidor envia as informações sensoriais pertinentes para cada agente. São simuladas
diversas complexidades do mundo real, por exemplo, inserindo ruído nas informações
visuais que cada agente recebe de acordo com a distância dele para outros objetos no
campo. Isso significa que um agente pode não saber a que time pertence outro jogador

28. Capítulo 1. Robot World Cup (Robocup) 27
que esteja muito distante no campo, ou a distância real dele para os outros objetos em seu
campo visual. O funcionamento dos sensores e atuadores dos agentes são detalhados nas
seções 1.2.2.3 e 1.2.2.4, respectivamente.
Como pode ser visto na Figura 2, o Soccer Server possui três componentes principais
(descritos em (NODA et al., 1998)):
• Field Simulator: controla a física do ambiente e as posições dos objetos em campo,
calculando a movimentação resultante das ações dos agentes e de fatores externos
como o vento, também gerenciando as colisões (quando um objeto sobrepõe o outro);
• Messages Board: gerencia a comunicação entre os clientes e o servidor, recebendo as
ações e enviando as informações sensoriais de cada agente individualmente;
• Referee: garante que as regras do jogo sejam aplicadas corretamente, controlando
os estados do jogo (playmodes), checando o fim do primeiro e segundo tempo, gols
e o placar, laterais, tiros-de-meta, impedimentos, faltas, punições com cartões e
garantindo o posicionamento correto dos jogadores em situações especiais (como
distância da bola no caso de faltas).
O arquivo de configuração server.conf permite que diversos aspectos da simulação
sejam configuráveis, como por exemplo o valor padrão para a área em que um agente
consegue influenciar a bola, equivalente ao alcance da perna, dada pelo parâmetro kicka-
ble_margin (atualmente 0.7). Esse tipo de parâmetro é importante durante a terceira fase
do projeto, Preparação dos Dados (Capítulo 6), pois são utilizados para derivar atributos
que não constam nos logs.
1.2.1.2 Soccer Monitor
O Soccer Monitor é um módulo que se conecta com o servidor e permite que a
simulação sendo processada pelo Soccer Server seja visualizada em tempo-real por humanos.
A arquitetura do servidor permite que mais de um monitor seja conectado ao mesmo
tempo. Usando o sistema X window ele gera uma representação gráfica do campo de
futebol e dos objetos da partida tornando intuitivo acompanhar o jogo. Guardados os
limites da comparação, é como assistir a uma partida de futebol de cima. A Figura 3
mostra o Monitor durante uma partida.
O Monitor mostra o nome dos dois times jogando, o placar do jogo, o playmode
atual, o tempo transcorrido de jogo (em número de ciclos), os limites e marcações do
campo, os jogadores (como círculos maiores numerados) e a bola (como um círculo menor
sem número). Para diferenciar os times, cada um recebe uma cor diferente, assim como os
goleiros, que possuem uma cor diferente dos jogadores de linha. As costas dos jogadores é

29. Capítulo 1. Robot World Cup (Robocup) 28
Figura 3 – Soccer Monitor mostrando o ciclo 203 da final da Robocup 2013 entre o campeão
WrightEagle da China (em amarelo) e o Helios2013 do Japão (em vermelho)
Fonte: Elaborado pelo autor (captura de tela)
representada pela metade escura em cada agente, e um traço na parte colorida representa
a posição atual do pescoço. Alguns jogadores possuem tamanhos diferentes, o que está
relacionado com suas características heterogêneas (mais na subseção 1.2.2.5). Algumas
opções especiais, como mostrar os jogadores que receberam cartão amarelo, também podem
ser habilitadas.
Uma das funções importantes do Monitor é permitir que um árbitro humano
interfira durante a partida. Para isso alguns comandos podem ser enviados diretamente
com o mouse, como reposicionar a bola ou os jogadores, determinar o início da partida
(kickoff ) e finalizar o jogo (quit, que desconecta os agentes, salva os logs e finaliza a
simulação). Ao longo dos anos diferentes monitores já foram desenvolvidos 5
. A escolha do
monitor não interfere em nada na partida, e ele sequer precisa estar conectado para que
um jogo ocorra.
1.2.1.3 LogPlayer
O LogPlayer é um software auxiliar para assistir partidas através dos logs gerados
pelo Soccer Server. Ele torna os logs muito mais compreensíveis ao processá-los visualmente
como um jogo de futebol (Figura 4). A primeira vista ele é parecido com o Soccer Monitor,
entretanto possui diversas funcionalidades extras que facilitam realizar análises das partidas.
Criado de forma similar a um reprodutor de vídeo, ele permite avançar e voltar no jogo
conforme desejado, vendo o jogo de forma acelerada ou ciclo a ciclo, além de saltar para
5
A Robocup oficialmente disponibiliza dois deles em <http://sourceforge.net/projects/sserver/>

30. Capítulo 1. Robot World Cup (Robocup) 29
momentos específicos. Os ciclos em que ocorreram gols, por exemplo, já ficam marcados
para facilitar a visualização do replay.
Figura 4 – Replay de uma partida sendo exibida no Logplayer a partir dos arquivos de log
Fonte: Elaborado pelo autor (captura de tela)
Entre as diversas funcionalidades do LogPlayer podemos ver um resumo dos
comandos utilizados por cada agente, traçar a trajetória dos objetos ao longo de toda
partida de modo a visualizar as zonas de maior atividade, prever a trajetória da bola de
acordo com as forças atuando nela a cada ciclo e ver em detalhe o campo de visão de cada
jogador. Essas características tornam o LogPlayer uma das ferramentas mais importantes
para que os pesquisadores possam avaliar suas equipes.
Apesar disso, a carência não suprida é detectar e contabilizar automaticamente os
eventos que ocorrem enquanto a “bola está rolando”, playmode definido como play_on no
servidor, criando dessa forma uma visão resumida dos acontecimentos mais relevantes da
partida: número de passes por tipo, dribles, chutes a gol. Seriam as estatísticas de jogo
comumente analisadas nos jogos de futebol profissional e que são abordadas na seção 2.3.
1.2.2 O ambiente simulado pelo Soccer Server
Nesta seção alguns detalhes da Simulação 2D são observados mais de perto. Nem
todos os aspectos da simulação serão apresentados pois não influenciam diretamente na
solução, como por exemplo alguns modelos de ruído, uma vez que os dados a serem
utilizados são armazenados nos logs com precisão diretamente pelo servidor. Estudar as
restrições do ambiente, por outro lado, ajuda a entender a origem dos dados que estão
nos logs, permitindo uma compreensão mais profunda sobre o problema. A partir desse

31. Capítulo 1. Robot World Cup (Robocup) 30
estudo é possível entender, por exemplo, quais as variações que podem ocorrer nos dados
de um ciclo para o outro, sendo para isso necessário um entendimento básico da física do
ambiente, das regras e das limitações a que os agentes estão submetidos.
Essa seção baseia-se nas informações contidas em (BOER; KOK, 2002; CHEN et
al., 2003; NODA et al., 1998). Como essas fontes (que incluem a documentação oficial
mais recente, de 2003) são antigas e estão em parte obsoletas, onde foi relevante para a
compreensão do entendimento da simulação elas foram atualizadas. Isso foi feito com base
nos arquivos de changelog e no código do Soccer Server e documentadas nas subseções
seguintes.
Como o nome sugere, a 2D é disputada num ambiente simulado de duas dimensões
(a altura é a dimensão inexistente). À parte essa diferença, a 2D provê um ambiente
bastante complexo, simulando características do mundo real como ruídos nos sensores e
atuadores, energia (stamina), percepção limitada do ambiente e restrições de comunicação.
O mundo simulado se restringe a uma partida de futebol e seus componentes. Como tal,
o objetivo de cada time é levar a bola até dentro do gol adversário marcando um ponto,
enquanto evita que o adversário faça o mesmo. Ganha o time que tiver mais pontos no
final. Esse conflito de objetivos cria um ambiente complexo onde 24 agentes (11 jogadores
e 1 técnico de cada lado) competem e cooperam simultaneamente.
1.2.2.1 O campo e os objetos fixos
O campo da Simulação 2D tem as dimensões pitch_length X pitch_width, o que
por padrão na versão atual do servidor significa 105m x 68m, dentro das dimensões de um
campo oficial de futebol. Já as traves, uma vez que sem a dimensão da altura ficaria muito
mais difícil fazer gols, ficam a 14.02m uma da outra (parâmetro goal_width), o dobro da
distância oficial. Isso mostra que nem sempre os parâmetros da simulação serão idênticos ao
do futebol real, mas em geral, incluindo a física do ambiente, serão similares. As traves são
objetos circulares com 6 cm de raio e ficam nas posições 𝑥 = +−(pitch_length×0.5−6𝑐𝑚)
e 𝑦 = + − (goal_width × 0.5 + 6𝑐𝑚). A Figura 5 mostra as flags e linhas do campo, que são
muito importantes como referências para que cada agente possa determinar sua posição
no campo, sua orientação e sua velocidade.
1.2.2.2 Objetos móveis
Entender o comportamento dos objetos é importante pois está estritamente relacio-
nado a variação dos dados encontrados nos logs a cada ciclo. As estatísticas de alto nível
podem ser entendidas como padrões de movimentação nos objetos do campo. Por conta
disso, as equações que regem a movimentação em geral serão apresentadas nessa seção. Os
modelos aqui presentes se baseiam no excelente trabalho descritivo realizado em (BOER;
KOK, 2002).

32. Capítulo 1. Robot World Cup (Robocup) 31
Figura 5 – As flags e linhas do campo simulado
Fonte: (CHEN et al., 2003)
Existem dois tipos de objetos móveis no ambiente da 2D, jogadores e bola. Re-
sumidamente o movimento desses objetos são simulados do seguinte modo: durante a
passagem do ciclo 𝑡 para o 𝑡+1, o vetor velocidade do objeto é acrescido do vetor aceleração
resultante dos comandos enviados pelos agentes, e dos vetores de ruído, compondo uma
nova velocidade a partir da qual a nova posição do objeto é calculada. Depois a aceleração
retorna a zero e a velocidade decai de modo a simular a perda de movimento do objeto. O
modelo detalhado obedece as seguintes equações:
(𝑢𝑡+1
𝑥 , 𝑢𝑡+1
𝑦 ) = (𝑣 𝑡
𝑥, 𝑣 𝑡
𝑦) + (𝑎𝑡
𝑥, 𝑎𝑡
𝑦) + (𝑟1, 𝑟2) + (𝑤1, 𝑤2): nova velocidade (1.1)
(𝑝𝑡+1
𝑥 , 𝑝𝑡+1
𝑦 ) = (𝑝𝑡
𝑥, 𝑝𝑡
𝑦) + (𝑢𝑡+1
𝑥 , 𝑢𝑡+1
𝑦 ): movimento (1.2)
(𝑣 𝑡+1
𝑥 , 𝑣 𝑡+1
𝑦 ) = decay × (𝑢𝑡+1
𝑥 , 𝑢𝑡+1
𝑦 ): velocidade final (1.3)
(𝑎𝑡+1
𝑥 , 𝑎𝑡+1
𝑦 ) = (0, 0): aceleracao final (reiniciada) (1.4)

33. Capítulo 1. Robot World Cup (Robocup) 32
onde, (𝑢𝑡+1
𝑥 , 𝑢𝑡+1
𝑦 ) é a velocidade resultante da interação das forças do ciclo 𝑡. Essas
forças são a velocidade do objeto: (𝑣 𝑡
𝑥, 𝑣 𝑡
𝑦), a aceleração resultante dos comandos enviados
pelos agentes: (𝑎𝑡
𝑥, 𝑎𝑡
𝑦), o vetor de ruído do movimento do objeto: (𝑟1, 𝑟2) e o vetor de vento:
(𝑤1, 𝑤2). O vetor (𝑎𝑡
𝑥, 𝑎𝑡
𝑦) deriva do parâmetro Força passado para o comando dash (no caso
do objeto ser um jogador) ou kick (no caso de ser a bola), ou ainda do resultado de um
tackle, caso em que depende do ângulo passado para o comando. A partir desses comandos
é possível calcular a força efetiva 𝑓 𝑒 que é utilizada para o cálculo da aceleração:
(𝑎𝑡
𝑥, 𝑎𝑡
𝑦) = fe × power_rate × (cos (𝜃 𝑡
), sin (𝜃 𝑡
)): aceleracao (1.5)
onde 𝜃 𝑡
é a direção do objeto no ciclo 𝑡 e power_rate pode ser dash_power_rate,
kick_power_rate ou tackle_power_rate a depender da ação em questão. No caso do kick, a
transformação de Força em 𝑓 𝑒 se dá através da seguinte equação:
𝑓 𝑒 = 𝐹 𝑜𝑟𝑐𝑎 ×
(︂
1 − 0.25 ×
𝑑𝑖𝑓_𝑑𝑖𝑟
180∘
− 0.25 ×
𝑑𝑖𝑓_𝑑𝑖𝑠𝑡
𝑘𝑖𝑐𝑘𝑎𝑏𝑙𝑒_𝑚𝑎𝑟𝑔𝑖𝑛
)︂
(1.6)
onde 𝐹 𝑜𝑟𝑐𝑎 é valor de força enviado pelo agente como primeiro argumento do
comando kick, 𝑑𝑖𝑓_𝑑𝑖𝑟 é o valor absoluto do ângulo entre a bola e a direção do corpo do
jogador, 𝑑𝑖𝑓_𝑑𝑖𝑠𝑡 é a distância entre o jogador e bola, ou seja, a distância mínima entre
as camadas mais externas do jogador e da bola, e kickable_margin é um parâmetro dos
jogadores heterogêneos (mais na subseção 1.2.2.5) que determina o alcance da perna. No
caso do tackle 𝑓 𝑒 é dado por:
𝑓 𝑒 = 𝑚𝑎𝑥_𝑡𝑎𝑐𝑘𝑙𝑒_𝑝𝑜𝑤𝑒𝑟 ×
(︂
1 −
fabs(𝐴𝑛𝑔𝑙𝑒)
𝜋 𝑟𝑎𝑑
)︂
(1.7)
onde max_tackle_power é um parâmetro do servidor que regula a força do tackle e
fabs(Angle) é o módulo do ângulo passado no comando tackle. No caso do dash, 𝑓 𝑒 é dado
por:
𝑓 𝑒 = 𝐹 𝑜𝑟𝑐𝑎 × Effort (1.8)
onde 𝐹 𝑜𝑟𝑐𝑎 é o valor de força enviado pelo agente como argumento do dash e Effort
é um atributo dos jogadores que pode variar durante a partida (mais na subseção 1.2.2.5).
A direção, no caso do jogador é dada pela direção de seu corpo, e no caso da bola pela
fórmula:
𝜃 𝑡
𝑏𝑎𝑙𝑙 = 𝜃 𝑡
𝑘𝑖𝑐𝑘𝑒𝑟 + Direction: direcao (1.9)

34. Capítulo 1. Robot World Cup (Robocup) 33
onde 𝜃 𝑡
𝑏𝑎𝑙𝑙 e 𝜃 𝑡
𝑘𝑖𝑐𝑘𝑒𝑟 são respectivamente a direção da bola e do jogador que a chutou,
e Direction é o segundo parâmetro do comando kick. A multiplicação por (cos (𝜃 𝑡
), sin (𝜃 𝑡
))
transforma os valores em um vetor.
O vetor de ruído (𝑟1, 𝑟2) é inserido para simular o movimento impreciso ou ines-
perado dos objetos no mundo real, por exemplo, desvios ocasionados por irregularidades
no campo. O vetor de ruído na Equação 1.1 contém dois números aleatórios 𝑟𝑖, obtidos
a partir de uma distribuição uniforme sobre o intervalo [−𝑟 𝑚𝑎𝑥, 𝑟 𝑚𝑎𝑥]. 𝑟 𝑚𝑎𝑥 depende da
velocidade do objeto (acrescida da aceleração) e é calculado como segue:
𝑟 𝑚𝑎𝑥 = rand × | (𝑣 𝑡
𝑥, 𝑣 𝑡
𝑦) + (𝑎𝑡
𝑥, 𝑎𝑡
𝑦) | : ruido (1.10)
sendo rand o erro no movimento dos objetos, representado por player_rand no caso
do jogador e ball_rand no caso da bola. O vento, que aparece na Equação 1.1 como o vetor
(𝑤1, 𝑤2), é uma forma de ruído natural que também pode ser inserido na Simulação 2D.
Porém, como na versão atual do servidor o ruído do vento não está sendo inserido, ou seja,
os parâmetros relacionados ao vento estão todos configurados para 0.0, seu funcionamento
não será explicado.
Com essas informações pode ser calculada a Equação 1.1, onde se obtém o novo
vetor de velocidade (𝑢𝑡+1
𝑥 , 𝑢𝑡+1
𝑦 ). Esse vetor é então normalizado, no caso da bola pelo valor
de ball_speed_max e no caso dos jogadores pelo valor de player_speed_max.
Com este vetor é calculada a nova posição do objeto utilizando a Equação 1.2,
onde (𝑝𝑡
𝑥, 𝑝𝑡
𝑦) representa a posição do objeto no ciclo 𝑡. Após determinada a nova posição
do objeto, a velocidade (𝑢𝑡+1
𝑥 , 𝑢𝑡+1
𝑦 ) decai de acordo com a Equação 1.3, onde o decay
representa a taxa em que a velocidade é reduzida, podendo ser player_decay para os
jogadores ou ball_decay para a bola.
A velocidade e posição do jogador no ciclo seguinte, respectivamente (𝑣 𝑡+1
𝑥 , 𝑣 𝑡+1
𝑦 ) e
(𝑝𝑡+1
𝑥 , 𝑝𝑡+1
𝑦 ), estão obtidas. Por fim, a aceleração do ciclo seguinte (𝑎𝑡+1
𝑥 , 𝑎𝑡+1
𝑦 ) é determinada
como nula de acordo com a Equação 1.4. A Tabela 2 mostra os parâmetros do servidor
que são relevantes para o modelo de movimento.
Se no final do ciclo dois objetos estiverem sobrepostos, i.e. tiverem colidido, eles são
movidos para trás na direção que vieram até encontrar uma área livre, e suas velocidades
são multiplicadas por -0.1, exceto pela colisão da bola com a trave que obedece a uma
dinâmica elástica. É importante notar que com este modelo objetos podem passar “através”
dos outros desde que não estejam sobrepostos no fim do ciclo. Isso é mais comum ocorrer
com a bola devido a sua menor área.

35. Capítulo 1. Robot World Cup (Robocup) 34
Tabela 2 – Parâmetros do servidor relacionados ao modelo de movimento e os seus valores
padrões
Parâmetro Valor Parâmetro Valor
ball_accel_max 2,7 player_accel_max 1,0
ball_decay 0,94 player_decay 0,4
ball_rand 0,05 player_rand 0,1
ball_size 0,085 player_size 0,3
ball_speed_max 3,0 player_speed_max 1,05
ball_weight 0,2 player_weight 60,0
dash_power_rate 0,006 tackle_power_rate 0,027
kick_power_rate 0,027 wind_dir 0,0
max_dash_power 100 wind_force 0,0
max_tackle_power 100 wind_rand 0,0
max_power 100
Fonte: Adaptado de (BOER; KOK, 2002)
1.2.2.3 Sensores
Como esse trabalho lida com o comportamento externo observado nos agentes, e
não com seus estados internos, as percepções dos agentes tem um papel menos importante
e serão analisadas apenas superficialmente. O agente possui 3 sensores:
• Auditivo ou aural: detecta as mensagens enviadas pelo juiz, pelos companheiros de
equipe, pelo técnico e pelos oponentes. A comunicação entre os agentes é regulada por
uma série de restrições, como por exemplo, o “limite do alcance da voz” (atualmente
50m);
• Visual: obtém informações visuais (como distância e direção) dos objetos que estão no
campo de visão do agente. As informações são sempre em relação ao próprio agente,
nunca absolutas. Uma série de ruídos e incertezas são adicionadas nas mensagens
visuais, tornando a coleta de informações um desafio a parte;
• Corpóreo: detecta o estado do agente, como sua energia, velocidade e posição do
pescoço.
Com as informações providas por esses diferentes sensores cada agente cria uma
percepção do mundo e decide as ações que vai executar a cada ciclo. Uma característica
complexa da simulação é que sentir e atuar são tarefas assíncronas. Enquanto por padrão
as informações visuais são enviadas para o agente em intervalos de 150ms, ele pode realizar
ações a cada 100ms (tempo do ciclo). De forma a maximizar seu desempenho e não
perder nenhuma oportunidade de agir, passa a ser desejável que ele seja capaz de atuar
baseando-se apenas em informações dos outros sensores e de ciclos anteriores. Essa tarefa

36. Capítulo 1. Robot World Cup (Robocup) 35
é um desafio pois ele precisa realizar predições, fusão de informações e tomar uma decisão
complexa, tudo isso em tempo real.
1.2.2.4 Atuadores
Os atuadores são o conjunto de dispositivos que um agente pode utilizar para
influenciar o ambiente onde está inserido. No caso da Simulação 2D, como não há um robô
real sendo simulado, faz mais sentido falar em ações que o agente pode realizar. Assim
como nos sensores, as ações estão sujeitas a diversos ruídos e incertezas, o que torna o
ambiente estocástico. O nível de abstração que foi utilizado na definição das ações na
2D é um ponto importante do projeto do servidor e mostra como a inclusão do nível
estratégico foi uma decisão de projeto para a liga. Em (NODA et al., 1998), os autores do
Soccer Server deixam claro que houve a intenção de encontrar um ponto de equilíbrio que
permitisse aos desenvolvedores focarem os seus esforços no aspecto estratégico do jogo, mas
que mantivesse o desafio de controlar os robôs, evitando que se perdesse a característica
de tempo real presente no futebol:
The level of abstraction chosen for representing these messagens was
an important consideration during design of Soccer Server. One possi-
bility was a low-level, physical description, for example allowing power
values for drive motors to be specified. However, it was felt that such
a representation would concentrate users’ attention too much on the
actual control of a players’ actions, relegating true investigation of the
multi-agent nature of team-play to the level of a secondary objective. [...]
On the other hand, a more abstract representation, maybe using tactical
commands such as pass-ball-to and block-shoot-course, would produce a
game in which the real-world nature of soccer becomes obscured. Thus,
our representation is a compromise, using basic control commands such
as turn, dash, and kick.6
Existem dois tipos de ações: primárias e concorrentes. Em cada ciclo de jogo
um agente pode realizar apenas uma ação do tipo primária, enquanto diversas ações
concorrentes podem ser executadas simultaneamente. Como organizado em (ABREU,
2010), as ações primárias podem estar relacionadas a movimento (dash, turn e move) ou
interação com a bola (kick, tackle e catch). Já as ações concorrentes se relacionam a controle
da percepção (turn_neck, attentionto e change_view) ou comunicação (say e pointto).
Os efeitos das ações primárias são:
6
“O nível de abstração escolhido para representar essas mensagens foi uma consideração importante
durante o projeto do Soccer Server. Uma possibilidade era uma descrição de baixo nível, física, por
exemplo permitindo que valores de força para os motores fossem específicados. Entretanto, sentiu-se
que tal representação iria concentrar demais a atenção dos usuários no controle das ações dos jogadores,
relegando uma investigação verdadeira da natureza multiagente do trabalho em equipe para o nível de
um objetivo secundário. [...] Por outro lado, uma representação mais abstrata, talvez usando comandos
táticos como passe-bola-para e bloqueie-chute, iria produzir um jogo em que a natureza de tempo-real
do futebol se tornaria obscura. Então, nossa representação é um balanço, usando comandos de controle
básicos como turn, dash, e kick.” (Tradução do autor)

37. Capítulo 1. Robot World Cup (Robocup) 36
• Dash: acelera o jogador com uma certa força em qualquer direção. Realizar um dash
consome energia do jogador, impedindo que ele corra indefinidamente e tenha que
gerenciar muito bem esse recurso. A energia é recuperada lentamente durante cada
ciclo, mas o jogador pode acabar fatigado, ficando limitado a usar apenas sua energia
extra (parâmetro extra_stamina, ver mais na subseção 1.2.2.5). O jogador também
está limitado a uma velocidade máxima (dada pelo parâmetro player_speed_max);
• Turn: altera a direção do corpo do jogador. A velocidade do jogador e a sua inércia
exercem influência sobre sua capacidade de girar, tornando a ação mais complexa.
É importante notar que como turn e dash são ambas ações primárias, o agente não
pode acelerar e rotacionar o corpo no mesmo ciclo;
• Move: permite aos jogadores se moverem diretamente para qualquer ponto do campo
sempre que ocorre um gol, ou antes do início de cada tempo. Serve ao propósito de
reposicionar os times sem a necessidade de deslocamento. É permitido ao goleiro
utilizar o move até 2 vezes para dentro de sua grande área após agarrar a bola. Essa
regra serve para facilitar a reposição de bola, uma vez que as limitações do ambiente
não permitem que ele jogue a bola pelo alto, opção comum ao goleiro;
• Kick: permite ao jogador chutar a bola com uma certa força e direção, influenciando
a sua trajetória. Para realizar um chute com sucesso a bola precisa estar ao seu
alcance (o centro do jogador e o centro da bola devem estar a uma distância máxima
igual ao raio do jogador + raio da bola + parâmetro kickable_margin). A posição
da bola em relação ao jogador influencia a eficiência do chute. Com os parâmetros
atuais do servidor o chute mais forte possível é capaz de fazer a bola percorrer cerca
de 45 metros;
• Tackle: realiza o movimento conhecido como “carrinho” no futebol. Para ter chance
de acertar, a bola precisa estar num retângulo relativo a frente do jogador definido
por tackle_width e tackle_dist, atualmente 1.25m e 2.0m respectivamente (Figura 6).
Uma das vantagens do tackle é permitir ao jogador alcançar bolas mais distantes,
que não seriam alcançáveis utilizando um kick. Desde a versão 14 do servidor o
tackle pode acabar resultando em falta, passível de punição com cartão amarelo ou
vermelho. O cartão vermelho resulta na desconexão do agente punido da partida. A
Simulação 2D é tão rica em detalhes, que um agente pode até mesmo tentar realizar
a falta propositalmente como uma opção para finalizar uma jogada, porém, corre
maior risco de ser punido;
• Catch: permite agarrar a bola com a mão. O único jogador que pode realizar esse
comando é o goleiro. Para isso a bola precisa estar em jogo e dentro de uma área
retangular na direção em que foi realizado o catch, de comprimento catchable_area_l
e largura catchable_area_w, atualmente 1.2m e 1.0m respectivamente (Figura 7).

38. Capítulo 1. Robot World Cup (Robocup) 37
Jogadores heterogêneos (subseção 1.2.2.5) podem ter o valor de catchable_area_l
acrescido por um delta dado por catchable_area_l×(catchable_area_l_stretch−1.0).
Figura 6 – Jogador 11 (azul) tem a bola próxima ao limite da área (vermelho) em que
pode executar um tackle
Fonte: Elaborado pelo autor
Figura 7 – Área de um comando catch com 45 graus
Fonte: Manual do servidor (CHEN et al., 2003)
Os efeitos das ações concorrentes são:
• Turn neck: rotaciona o pescoço do agente mudando seu campo de visão e permitindo
a ele flexibilidade sobre a captação de informações visuais. Como este comando pode
ser realizado simultaneamente a um turn, é importante existir sincronismo entre
o corpo e o pescoço do agente para que ele possa olhar para o local desejado. O
pescoço pode ser movido 90 graus para cada lado em relação ao corpo do agente;
• Change view: altera o foco visual do agente, permitindo controle sobre a abertura,
qualidade e frequência da captação de informações visuais;

39. Capítulo 1. Robot World Cup (Robocup) 38
• Attention to: altera o foco auditivo do agente, permitindo que ele ouça melhor
algum companheiro de equipe específico;
• Say: permite se comunicar através da voz com os companheiros mais próximos
(limite de 50m);
• Point to: faz o agente apontar durante alguns ciclos para uma determinada posição
do campo, simulando comunicação através dos braços.
Em (RUSSEL; NORVIG, 2003) aparece o conceito de capacidade de atuação
(effectoric capability), que consiste no mapeamento do conjunto de ações possíveis de serem
executadas por um agente. A Tabela 3 contém a capacidade de atuação dos agentes da 2D
para as ações primárias e a Tabela 4 para as ações concorrentes.
Tabela 3 – Capacidade de atuação - ações primárias
Comando Sintaxe Argumentos
Dash (dash double double) Força [-100.0, 100.0] e Direção [-180.0, 180.0]
Turn (turn double) Momentum [-180.0, 180.0]
Move (move double double) Eixos do campo: X [-52.5, 52.5] e Y [-34.0, 34.0]
Kick (kick double double) Força [-100.0, 100.0] e Direção [-180.0, 180.0]
Tackle (tackle double {boolean}) Direção [-180.0, 180.0] e Falta {true | false}
Catch (catch double) Direção [-180.0, 180.0]
Fonte: Elaborado pelo autor
Tabela 4 – Capacidade de atuação - ações concorrentes
Comando Sintaxe Argumentos
Turn neck (turn_neck double) Momentum [-180.0, 180.0]
Change view (change_view string string) Largura [narrow|normal|wide] e Qualidade [high|low]
Attention to (attentionto string integer) Time [opp | our | l | r | left | right] e Jogador [0, 11]
Say (say string) Mensagem contendo [0..9a..zA..Z().+-*/? <>]
Point to (pointto double double) Distância [+∞] e Direção [-180.0, 180.0]
Fonte: Elaborado pelo autor
Esta subseção detalhou as ações enviadas pelos agentes para o servidor pois elas
são parte do comportamento externo observável dos jogadores, sendo então um recurso
importante para a extração das estatísticas de futebol desejadas. Para realizar as ações
complexas que fazem parte do jogo, um agente deve combinar diferentes ações de baixo
nível primárias e concorrentes. Dessa forma, um dos desafios do projeto se deve ao fato de
que um mesmo comando básico como um kick pode representar diferentes ações de alto
nível, como um passe, um chute a gol, um domínio ou condução de bola, sendo necessário
um mecanismo de classificação robusto para lidar com essas ambiguidades.
Os comandos de kick, tackle e catch juntamente com as colisões bola-jogador e
bola-trave são os eventos de baixo nível mais importantes para a detecção de chutes a
gol pois resumem as situações em que a aceleração da bola é modificada por um evento
externo (além do seu ruído natural no movimento explicado na Equação 1.10).

40. Capítulo 1. Robot World Cup (Robocup) 39
1.2.2.5 Jogadores heterogêneos
No começo de cada partida é criado aleatoriamente um conjunto de tipos de joga-
dores (atualmente 18, regido pelo parâmetro player_types) com características diferentes,
como velocidade máxima e capacidade de drible. Antes da versão 7 do servidor todos os jo-
gadores em campo possuiam as mesmas características. A introdução dessa funcionalidade
abriu espaço na 2D para pesquisa sobre alocação dinâmica de recursos (ABREU, 2010).
As características de cada tipo são balanceadas a partir de alguns trade-offs
preestabelecidos, como jogadores mais velozes cansarem mais rápido, ou os que chutam
mais forte terem menos precisão no chute. Para manter o equilíbrio da partida cada equipe
dispõe do mesmo conjunto para escalar 11 titulares e 7 reservas de acordo com suas
estratégias. Durante o jogo cada time pode ainda realizar até 3 substituições (parâmetro
subs_max).
É importante considerar os jogadores heterogêneos na fase de Preparação dos
Dados do projeto pois uma mesma configuração dos objetos no campo pode ter significados
diferentes a depender dos jogadores envolvidos na cena. Uma bola que esteja a 0.8m de
um jogador, por exemplo, pode estar ou não sobre a influência dele a depender do seu
atributo kickable_margin, que varia de 0.7 a 0.9 metros. A Tabela 5 lista o valor padrão de
cada atributo dos jogadores e as suas possíveis variações 7
.
Tabela 5 – Parâmetros relacionados aos jogadores heterogêneos
Parâmetro Padrão Variação Descrição da variante
player_speed_max 1.0 [1.0, 1.2] Jogador com velocidade máxima maior
stamina_inc_max 45.0 [25.0, 45.0] Jogador que recupera menos energia por ciclo
player_decay 0.4 [0.4, 0.6] Jogador cuja velocidade decresce mais devagar
inertia_moment 5.0 [5.0, 10.0] Jogador com dificuldade de girar em movimento
dash_power_rate 0.006 [0.006, 0.008] Jogador com maior aceleração
player_size 0.3 [0.1, 0.3] Jogador com corpo menor
kickable_margin 0.7 [0.7, 0.9] Jogador com maior alcance da bola
kick_rand 0.0 [0.0, 0.1] Jogador com menos precisão no chute
extra_stamina 0.0 [0.0, 100.0] Jogador com energia extra
effort_max 1.0 [0.8, 1.0] Jogador com menor eficiência máxima no movimento
effort_min 0.6 [0.6, 0.8] Jogador com maior eficiência mínima no movimento
kick_power_rate 0.027 [0.027, 0.027] Força do chute. Variação não implementada.
foul_detect_probability 0.5 [0.5, 0.5] Chance de fazer falta. Variação não implementada
catchable_area_l 1.2 [1.2, 1.56] Goleiro com maior alcance com a mão
Fonte: Adaptado de (ABREU, 2010)
1.2.2.6 Técnico online e offline
Além dos 11 jogadores cada time também possui 1 agente técnico. Ele é um agente
com algumas habilidades especiais, sendo a principal delas receber informações visuais
sem ruído de todo o campo. Ele não possui uma representação física na simulação e atua
trocando mensagens com o servidor e se comunicando com sua equipe. Existem 2 tipos de
agente técnico: online e offline.
7
Adaptada de (ABREU, 2010) e atualizada a partir do código da versão 15.2.2 do Soccer Server

41. Capítulo 1. Robot World Cup (Robocup) 40
O técnico online é o responsável por selecionar os jogadores heterogêneos e realizar
a escalação do time no começo do jogo, realizar substituições durante a partida e o mais
importante, dadas as informações privilegiadas que recebe e a menor pressão por atuar em
tempo real, ser o responsável por definir as estratégias da equipe. O técnico online pode,
por exemplo, tentar identificar a estratégia do adversário e alterar o modo de jogar de seu
time. Para se comunicar com sua equipe o técnico deve utilizar um protocolo conhecido
como CLang, que impõe restrições sobre as informações que ele pode compartilhar (do
contrário perderia o sentido o modelo de incertezas associado aos sensores dos agentes).
Já o técnico offline, além de todas as habilidades do técnico online, pode também
controlar diretamente alguns aspectos da simulação. Entre elas, é permitido que ele mude
o playmode do jogo, recupere a energia dos jogadores e até mesmo altere as posições de
todos os objetos móveis no campo. Por conta dessas habilidades, o técnico offline não
pode ser utilizado em partidas oficiais, tendo o propósito de ser utilizado durante a fase
de desenvolvimento do time. Exemplos de uso comum do técnico offline incluem a criação
de cenários de teste específicos ou depuração do sistema.
Por receber informação completa da partida enquanto o jogo permanece em exe-
cução, o agente técnico pode ser fundamental para uma posterior aplicação em tempo
real dos resultados alcançados nesse trabalho. Estatísticas de alto nível em tempo real
permitiriam uma tomada de decisões estratégicas mais rápida, por perceber que o time
não está bem antes mesmo de tomar um gol, e mais robusta, por compreender nuances do
que está acontecendo na partida e poder corrigir detalhes do comportamento da equipe.
1.2.2.7 Juízes e estados do jogo
Como dito na subseção 1.2.1.1 o Soccer Server possui um módulo chamado Referee
que funciona como o juiz da partida. Ele é responsável por garantir que as regras do jogo
sejam seguidas, gerenciando as situações automaticamente, por exemplo, garantindo que a
distância mínima para a bola seja respeitada pelos jogadores adversários em faltas. Para
lidar com algumas situações mais complexas, como falta de fairplay ou obstrução de algum
jogador, as partidas oficiais também contam com um juiz humano (nomeado pelo Comitê
de Organização responsável) que pode realizar interverções através da interface do Soccer
Monitor (subseção 1.2.1.2).
Ao longo dos anos, porém, o juiz automático evoluiu bastante, tornando extrema-
mente rara a necessidade de qualquer tipo de participação do juiz humano, para além de
executar os scripts das partidas. O juiz automático controla os estados do jogo, conhecidos
como playmodes, de modo que todos os agentes saibam como se comportar corretamente
de acordo com a situação, como em faltas, meio de campo e laterais. A maior parte do
jogo, no entanto, se passa no playmode play_on, que significa que a bola está rolando
normalmente. O juiz automático se comunica com os agentes através do broadcast de

42. Capítulo 1. Robot World Cup (Robocup) 41
mensagens sobre a partida.
A Tabela 6 mostra as mensagens que podem ser enviadas pelo juíz (incluindo
os playmodes). Toda mudança de playmode é registrada nos logs. Eles influenciam na
extração de estatísticas de chute a gol pois diversos chutes terminam com uma mudança
de playmode para o estado correspondente, por exemplo, a escanteio, tiro de meta ou
indicação de que o goleiro agarrou a bola.
Tabela 6 – Mensagens enviadas pelo juiz. SIDE pode ser l ou r de acordo com time sendo
referenciado (de left ou right). OSIDE se refere ao time oposto. 𝑇 é a quantidade
de ciclos até o próximo playmode ser anunciado.
Mensagem T Próximo playmode Descrição
before_kick_off 0 kick_off_SIDE No início de cada tempo
play_on - Bola rolando normalmente
time_over - Depois da partida
kick_off_SIDE - Anuncia o início do jogo
kick_in_SIDE - play_on Lateral. O playmode muda após a bola
ser chutada
free_kick_SIDE - play_on Falta ou goleiro agarra a bola. O play-
mode muda após a bola ser chutada
free_kick_fault_SIDE 30 free_kick_OSIDE Infração durante free_kick_SIDE
corner_kick_SIDE - play_on Escanteio. O playmode muda após a bola
ser chutada
goal_kick_SIDE - play_on Tiro de meta. O playmode muda quando
a bola deixa a grande área.
drop_ball 0 play_on Ocorre quando a bola não é colocada em
jogo depois de drop_ball_time cycles.
offside_SIDE 30 free_kick_OSIDE Falta de impedimento
goal_SIDE_N 50 kick_off_OSIDE Anuncia o enésimo gol para SIDE
foul_charge_SIDE 30 free_kick_OSIDE ou indi-
rect_free_kick_OSIDE
Falta cometida com tackle por SIDE
yellow_card_SIDE_P - Cartão amarelo para jogador P do time
SIDE
red_card_SIDE_P - Cartão vermelho para jogador P do time
SIDE
back_pass_SIDE 30 free_kick_OSIDE Recuo de bola pego de mão pelo goleiro
de SIDE
time_up_without_a_team 0 time_over Se oponente não conecta até o fim do se-
gundo tempo
time_up 0 time_over Fim da partida (quando não há empate
ou prorrogação)
half_time 0 before_kick_off Fim do primeiro tempo
time_extended 0 before_kick_off Fim do segundo tempo (quando há em-
pate e há prorrogação)
Fonte: Adaptado de (BOER; KOK, 2002)
1.2.3 Os logs das partidas
A cada partida o Soccer Server gera 2 arquivos de log em texto: o RCG e o RCL.
A maior parte das informações ficam registradas no RCG, que sozinho pode ser utilizado
para reproduzir uma partida. Já o RCL registra todas as mensagens trocadas via servidor,
incluindo as ações básicas enviadas pelos agentes, mensagens dos técnicos, e até mesmo
as mensagens enviadas pelo juíz. Como o ambiente não é determinístico, é impossível
reproduzir um jogo a partir apenas das mensagens no RCL.

43. Capítulo 1. Robot World Cup (Robocup) 42
A Figura 8 mostra os trechos de arquivos RCG e RCL correspondentes ao mesmo
ciclo de uma partida. Por uma restrição de escopo apenas o arquivo RCG foi utilizado
como fonte de dados para esse projeto. Foi a partir dos dados de baixo nível contidos
nesses arquivos que se extraíram estatísticas de chute a gol.
Figura 8 – Exemplo de conteúdo dos arquivos RCG e RCL para o ciclo 7 da simulação
entre os times WrightEagle e HELIOS2013 valendo pela final da Robocup 2013
(a) Trecho de log RCG
(b) Trecho de log RCL
Fonte: Elaborado pelo autor
Dentro de um arquivo RCG encontram-se as seguintes mensagens:
• Header: informa a versão do log. Aparece uma vez no começo do RCG;
• server_param: guarda todos os parâmetros relativos a partida utilizados na simulação.
Aparece uma vez logo após o Header;
• player_param: guarda todos os parâmetros relativos aos jogadores heterogêneos.
Aparece uma vez logo após server_param;

44. Capítulo 1. Robot World Cup (Robocup) 43
• player_type: mostra todos os tipos heterogêneos gerados com os valores de seus
atributos. Aparece uma vez para cada tipo heterogêneo (atualmente 18, como
observado na subseção 1.2.2.5);
• MSG: relativo a atributos extras como o logotipo dos times, quando existente, e uma
mensagem final com timestamp e o resultado da partida;
• playmode: informa sempre que há uma mudança no estado do jogo;
• team: informa o estado do placar. Aparece uma vez no início do log e sempre que
acontece um gol;
• show: principal mensagem do log, aparece uma vez para cada ciclo. Contém todas as
informações relevantes sobre a bola e os jogadores.
A mensagem de show é a principal fonte de dados para realizar o projeto. Ela
contém:
1. (show <time> .. ): cabeçalho e o ciclo de jogo;
2. ((b) x y vx vy): registro sobre a bola. Contém a flag “(b)”, a posição (x, y) e velocidade
(vx, vy);
3. ((side unum) type state x y vx vy body neck [pointx pointy] (v Q W) (s sta eff rec
[cap])[(f side unum)] (c c1 c2 c3 c4 c5 c6 c7 c8 c9 c10 c11)) : registro sobre um jogador.
Onde:
• (side unum): o time e o número do jogador;
• type state: o tipo do heterogêneo e um valor em hexadecimal que representa o
estado do jogador (caído, cartão amarelo, chutou etc);
• x y vx vy: posição e velocidade do jogador;
• body neck: direção do corpo e do pescoço;
• [pointx pointy]: posição para qual o jogador está apontando (opcional);
• (v Q W): registro sobre informação visual. Flag “v”, a qualidade de captação e
a abertura da visão;
• (s sta eff rec [cap]): registro sobre a energia do agente. Flag “s”, energia atual,
atributo effort, recuperação de energia e capacidade de energia total (opcional);
• [(f side unum)]: registro sobre o foco do agente (opcional). Time e jogador no
qual sua atenção está focada;

45. Capítulo 1. Robot World Cup (Robocup) 44
• (c c1 c2 c3 c4 c5 c6 c7 c8 c9 c10 c11): contador de ações básicas. Flag “c” e o
total de comandos utilizados, na seguinte ordem: kick, dash, turn, catch, move,
turn_neck, change_view, say, tackle, pointto e attentionto.
O RCL é um arquivo mais simples, possuindo apenas um tipo de registro. Ele
contém o ciclo da partida (incluindo contador de ciclos de bola parada), o nome do time e
o jogador a que o registro se refere, e as mensagens enviadas a cada ciclo. No caso dos
jogadores as mensagens são compostas pelos padrões que aparecem nas Tabelas 3 e 4, e no
caso do técnico elas obedecem ao protocolo CLang (mencionado na subseção 1.2.2.6). Os
registros relativos ao árbitro são principalmente relativos a mudanças de playmodes. Os
RCLs não foram utilizados no projeto pois agregariam pouco a um alto custo de tratá-los.
Não foi encontrada uma documentação oficial relacionada ao formato dos logs. As
informações contidas nesta seção foram obtidas a partir da análise do código-fonte da
versão 15.2.2 do servidor.
1.3 Testes e experimentos na Simulação 2D
Como visto em (GATTI; STAA, 2006), os agentes dentro de um sistema multiagentes
costumam atuar de forma concorrente, assíncrona e descentralizada. Além disso, são não
determinísticos, uma vez que não é possível determinar à priori quais interações ocorrerão
durante uma execução do sistema, tornando sistemas multiagentes muito complexos de
serem testados e depurados. Essa é exatamente a realidade encontrada na Simulação 2D.
Essa seção foca nas abordagens mais utilizadas para testar os times de futebol simulado
2D e explica como esse trabalho pode aprimorar o ambiente de testes associado.
Um dos métodos mais utilizados é assistir aos replays de partidas no LogPlayer e
observar o comportamento do time. Essa atividade pode ser auxiliada por um arquivo de
log ou debug gerado pelos processos dos agentes durante a execução da simulação, para que
depois se busque manualmente os lances importantes para observar algum comportamento
desejado.
Outra forma muito comum é rodar uma bateria de testes contra equipes selecionadas
e depois assistir a todos os jogos contabilizando manualmente algum comportamento
particular que se tenha interesse, como por exemplo, percentual de passes corretos. Porém,
essas abordagens são muito custosas em tempo, inviabilizando utilizá-las em escala. Se for
necessário rodar os testes novamente todo o trabalho manual precisa ser refeito.
A escala é uma questão essencial quando se trata de testes dos sistemas multiagentes
num ambiente de futebol. Como no futebol real, o resultado de uma única partida pode
representar muito pouco sobre o desempenho de uma equipe, e apenas através de repetições
da simulação de uma partida entre as duas mesmas equipes, sem alterações no software

46. Capítulo 1. Robot World Cup (Robocup) 45
dos agentes, pode-se esperar conseguir um resultado sólido estatisticamente. Além disso
é necessário rodar simulações contra diferentes tipos de equipes, com diferentes forças e
fraquezas, para garantir que a estratégia desenvolvida não é por demais enviesada, ou
verificar se a equipe sabe se adaptar suficientemente bem, o que costuma denotar um
maior grau de inteligência. Essas demandas podem gerar uma séria restrição de tempo
para analisar os testes.
Supondo um setup de teste em que se deseja contabilizar o total de passes realizados
pela equipe antes e depois de uma alteração no código ou nos parâmetros que afete o
comportamento dos agentes, para que o teste seja robusto, são selecionadas pelo menos 5
equipes com características distintas, todas participantes do último mundial. Para cada
equipe decide-se rodar ao menos 10 simulações para que o resultado tenha relevância
estatística. Isso gera um total de 50 simulações para cada versão a ser testada. Com
cada simulação durando cerca de 10 minutos (6.000 ciclos de 100 milissegundos), teremos
1.000 minutos para serem analisados por conta de um único teste, totalizando mais de
16 horas de trabalho (isso considerando que não se volte para analisar algum lance com
mais cuidado, o que não é a realidade). Ainda mais crítico, num processo robusto, testes
similares deveriam ser exigidos sempre antes de fechar uma versão do sistema, para evitar
que uma alteração de código indesejável seja inserida na equipe.
A partir da síntese dos TDPs do mundial de 2013 (disponíveis em (ROBOCUP,
2013d) e (ROBOCUP, 2013e)) nota-se que o setup mais comum é de fato rodar diversas
partidas contra diferentes times, mas analisar apenas os gols feitos e tomados, pois essa
é uma medida fácil de ser obtida. Apenas gols, porém, são uma medida muito indireta
para alguns testes, podendo levar a falsas interpretações. É possível por exemplo, que ao
desenvolver um novo algoritmo para cruzamentos que é pior do que o anterior, uma equipe
passe a fazer mais gols pois isso favoreceu um tipo de interceptação de bola em que ela é
muito boa. Ou ainda, se uma equipe mantiver o mesmo saldo de gols contra duas equipes
distintas isso não significa que ela esteja tendo as mesmas dificuldades contra ambas.
As imprecisões associadas a medir o desempenho das equipes apenas através de
gols ocasionaram uma discussão durante a Robocup de 1998, relatada na seção 1.2, onde
se concluiu que medir desempenho em si é um problema de pesquisa relevante e que não se
resolve apenas medindo saldo de gols. Essa questão permanece em aberto até hoje. Assim, o
que se espera extraindo conhecimento dos logs é criar uma visão mais apurada das métricas
que denotam o desempenho das equipes, abrindo caminho para tornar as pesquisas mais
precisas e menos subjetivas, tornando mais fácil descobrir onde os verdadeiros problemas
ou soluções residem.
Uma abordagem alternativa utilizada por algumas equipes para fazer testes mais
modulares e análises que vão além dos gols feitos, é realizar experimentos sobre cenários
específicos de jogo. A ideia aqui é criar uma situação que se deseja testar, como por exemplo

47. Capítulo 1. Robot World Cup (Robocup) 46
um lance de jogada ensaiada, e repetir exaustivamente apenas essa situação, contabilizando
a taxa de sucesso. Isso é possível utilizando a funcionalidade de reposicionamento do
técnico offline, apresentado na subseção 1.2.2.6.
Em (ZHANG et al., 2013), o WrightEagle, uma das principais equipes da Simulação
2D, 3 vezes campeã do mundo, fala sobre a dificuldade em realizar testes na 2D e sobre
uma ferramenta lançada por eles, chamada Trainer, que serve justamente ao propósito
de facilitar a criação desses cenários e a execução de testes modularizados. Ela funciona
recriando um cenário de um jogo real a partir de um arquivo de log RCG e o número do
ciclo que se pretende reproduzir. Uma ferramenta similar, chamada LabManager, também
havia sido desenvolvida em 2010 no projeto do Bahia2D8
(SILVA et al., 2010; SILVA et
al., 2011).
Esse tipo de ferramenta é um acréscimo muito importante para a liga, principalmente
para testar situações que ocorrem com pouca frequência em jogos normais, mas existem
algumas ressalvas importantes feitas pelos próprios autores. Como dito anteriormente a 2D
é um ambiente que simula diversas complexidades do mundo real, incluindo a percepção
limitada que cada agente tem do ambiente. Ao longo de uma partida normal, um agente
armazena diversas informações em memória, como o posicionamento dos objetos no campo,
inclusive previsões sobre aqueles que estão momentaneamente fora do seu campo visual,
criando uma expectativa sobre o comportamento do mundo.
Ao reproduzir um ciclo de jogo repentinamente, mexendo na posição dos agentes
de um modo que eles não esperam, ainda que esses agentes permaneçam fixados em sua
nova posição por alguns ciclos para permitir que eles atualizem seu modelo de mundo,
como fazem o Trainer e o LabManager, o comportamento normal do time é afetado e o
estado interno do agente pode perder parte de sua coerência. Com isso o desempenho das
equipes acabarão variando numa medida não conhecida, em geral levando a uma queda
nos desempenhos dos times de um modo não uniforme, com alguns agentes, a depender
de sua implementação, sendo mais prejudicados que outros. Isso torna os resultados de
experimentos utilizando essa abordagem menos confiáveis. A complexidade inerente à 2D
torna difícil que o viés dessa abordagem seja superado.
Dito isso, decorre-se o fato de que atualmente o método mais confiável de realizar
um teste integrado do sistema é rodando partidas completas sem intervenção, ainda que se
deseje testar apenas um módulo. Além disso, esse tipo de teste integrado é fundamental para
verificar os impactos que uma mudança, por mais pontual que pareça, causa sobre outras
características do time. Dada a complexidade do ambiente, por mais que os componentes de
um agente sejam testados unitariamente, o funcionamento do sistema em conjunto, ainda
mais num contexto competitivo que envolve outro sistema multiagente independente, torna-
8
Desenvolvido pelo próprio autor enquanto foi bolsista no Núcleo de Arquitetura de Computadores e
Sistemas Operacionais (ACSO), grupo de pesquisa da Universidade do Estado da Bahia (UNEB)

48. Capítulo 1. Robot World Cup (Robocup) 47
se extremamente difícil de prever, sendo comum surgirem comportamentos inesperados.
Esses aspectos reforçam os benefícios da solução proposta neste trabalho. Ao ser
possível criar automaticamente uma camada de visualização em cima dos logs, torna-
se factível realizar um teste integrado do tipo caixa-preta (focado no comportamento
externo do sistema) que verifica se o conjunto funciona como esperado. A abordagem
das estatísticas de futebol ainda possuem a vantagem de servirem tanto para testar o
desempenho do sistema como um todo, quanto para dar respostas sobre o desempenho de
agentes individualmente, além de poder ser utilizada por todos os times pois se baseia
em métricas de desempenho adotadas amplamente no futebol. No fim das contas jogar
futebol bem é o objetivo de todos os sistemas nesse contexto.
1.4 Outras ferramentas e trabalhos relacionados
Ao longo dos anos de simulação 2D surgiram outras ferramentas de análise de logs
além do LogPlayer, como o TeamAssistant2003 (SHAHRI, 2013) (Figura 9), o LogAlyzer
(BEZEK, 2013) (Figura 10) e o SoccerScope2. Essas ferramentas estendem algumas
funcionalidades do LogPLayer, como permitir depurar o modelo de mundo dos agentes e
até mesmo contabilizar algumas situações como passes básicos. Entretanto nenhuma delas,
como mostra (ABREU, 2010)9
, extrai estatísticas de alto nível. Outro problema é que a
maior parte das ferramentas não oficiais acabaram deixando de receber manutenção e se
tornaram obsoletas, perdendo compatibilidade com as versões mais novas do servidor.
Figura 9 – Interface do TeamAssistant2003
Fonte: (SHAHRI, 2013)
9
As citações sobre as ferramentas possuem data posterior pois são citações dos sites dos projetos

49. Capítulo 1. Robot World Cup (Robocup) 48
Figura 10 – Interface do LogAlyzer
Fonte: (BEZEK, 2013)
A Robocup pode ganhar bastante com o amadurecimento das ferramentas de
análise de desempenho para futebol de robôs em suas ligas, uma vez que análises manuais
de muitos logs a cada teste não são factíveis (seção 1.3). Em (STONE; AUGUST, 2013)
encontramos uma ampla coleção dos artigos já publicados que se relacionam às ligas
simuladas da Robocup. Nota-se que não são raros trabalhos que precisem detectar alguma
ação de alto nível, como passe, de modo a poder realizar alguns experimentos, como
vemos em (RILEY; VELOSO, 2000), (TANAKA et al., 1998) e (TAKAHASHI, 2000).
Mas esses trabalhos propõem soluções heurísticas simplificadas para essa detecção e não
se preocupam em avaliar a qualidade das heurísticas, dado que possuem outro enfoque.
O primeiro trabalho a realizar a detecção de estatísticas de alto nível no ambiente da
2D e avaliar a qualidade dessa detecção é apresentado em (ABREU, 2010). Sua abordagem
também utiliza heurísticas (criadas a partir de dados que podem ser encontrados no RCG)
e teve como base para comparação avaliações feitas manualmente por uma equipe de
especialistas sobre 12 partidas. Entre as métricas avaliadas estão passes corretos e errados,
chutes no gol, chutes interceptados, chutes pra fora, gols e impedimentos. A verificação do
desempenho das heurísticas foi feita utilizando True Positive Rate (também chamada de
recall). Como reportado no artigo (ABREU et al., 2011), exceto para os 3 tipos de chutes
a gol que tiveram um recall médio ponderado de 76,33% (ponderado pelo número de casos
observados para cada tipo de chute), todas as métricas foram detectadas com um recall
acima de 92% 10
.
10
O autor cita accuracy nas conclusões, talvez em sentido mais abrangente, mas pelas tabelas apresen-

50. Capítulo 1. Robot World Cup (Robocup) 49
Os 3 tipos de chute são definidos por Abreu et al. (2011) como segue:
• Shot on target: quando jogador chuta a bola na direção do gol com força suficiente
para cruzar a linha de fundo entre as traves (com uma tolerância de 0.5m para cada
lado);
• Shot: quando a bola chutada não tem a direção geral do gol, mas ainda cruza a linha
de fundo dentro do limite da área de penâlti;
• Intercepted shot: quando um oponente intercepta uma bola, com todas as condições
para ser Shot on target ou Shot, depois do primeiro jogador ter chutado.
A Tabela 7 apresenta os dados brutos de (ABREU et al., 2011) para os 3 tipos
de chute nas 12 partidas avaliadas: “Observados” são os lances daquele tipo identificados
na avaliação manual; “TP” são True Positives: lances detectados corretamente; FN
são False Negatives: lances observados mas não detectados; e FP são False Positives:
lances incorretamente detectados como um chute. Vale notar que True Negatives: lances
corretamente descartados, não são reportados. Já a Tabela 8 apresenta os resultados para
cada tipo de chute em função da métrica recall que é utilizada no artigo, e também em
função de precision e F-measure (calculada a partir dos dados fornecidos e que serão úteis
posteriormente, sendo explicadas na seção 3.6).
Tabela 7 – Dados sobre chutes a gol observados sobre 12 partidas (ABREU et al., 2011)
Tipo de chute Observados TP FN FP
Shot on target 35 30 5 1
Shot 56 41 15 6
Intercepted shot 78 58 20 6
Fonte: Adaptado de (ABREU et al., 2011)
Tabela 8 – Resultados para a detecção de chutes a gol (ABREU et al., 2011)
Tipo de chute Recall Precision F-measure
Shot on target 0,8571 0,9677 0,9091
Shot 0,7321 0,8723 0,7961
Intercepted shot 0,7436 0,9063 0,8169
Total (média ponderada) a
0,7633 0,9077 0,8291
a
Ponderada pelo número de instâncias em cada classe como realizada na ferramenta WEKA (seção 3.7),
diferentemente da ponderação pelo número de jogos em grupos predefinidos feita no artigo
Fonte: Adaptado de (ABREU et al., 2011)
Ainda em (ABREU et al., 2011), o autor discute suas hipóteses sobre a menor
eficiência para detecção de chutes e cita as ambiguidades relacionadas a esse tipo de lance,
tadas nota-se que se referia ao recall

51. Capítulo 1. Robot World Cup (Robocup) 50
que por acontecer mais próximo do gol geralmente possui muitos jogadores aglomerados em
uma menor região do campo, tornando mais difícil determinar através de uma heurística,
por exemplo, a posse de bola. Esses resultados levantaram um grande risco quanto a criação
de uma ferramenta para extração de estatísticas, pois diversas das principais métricas
de desempenho no futebol (sendo o próprio chute a gol uma das principais) envolvem
comumente lances com disputa de bola entre diferentes jogadores.
O presente trabalho partiu da hipótese de que a utilização de mineração de dados
no lugar de heurísticas traria um aumento da qualidade na detecção dos eventos de chute
a gol, abrindo caminho para futuramente realizar uma detecção completa das mais de 200
métricas utilizadas amplamente no futebol real (abordadas no Capítulo 2).
1.5 Semelhanças entre futebol real e simulado
Para resumir as características do servidor e compará-lo com o futebol real serão
utilizadas as propriedades do ambiente de tarefa (RUSSEL; NORVIG, 2003), que já foram
em parte apresentadas na Tabela 1.
Completamente observável vs Parcialmente observável
A simulação 2D é parcialmente observável pois os agentes em campo estão limitados
pelos seus sensores a perceberam apenas parte do que está ocorrendo no jogo a cada ciclo.
O modelo de visão é o principal limitador, tornando a coleta de informações um problema
essencial de ser bem resolvido para ser possível uma boa tomada de decisões. A única
exceção é o técnico, que recebe informação visual completa da partida mas possui limitações
para se comunicar com o time. Um aprofundamento do trabalho atual, a extração de
estatísticas de alto nível em tempo real pelo técnico, pode ser uma estratégia interessante
para aprimorar o uso dessa sua vantagem natural.
No futebol real os jogadores também possuem apenas uma visão parcial do que
está acontecendo a cada momento na partida, sendo parte importante do jogo decidir o
que observar, como olhar para a área antes de realizar um cruzamento ou notar se um
adversário se aproxima por trás para tomar a bola. O fato do técnico ter a informação
completa sobre cada ciclo na Simulação 2D não é essencialmente idêntico ao mundo real
mas reflete o fato do técnico estar em posição privilegiada para observar o jogo, contando
inclusive com auxiliares para realizar essa tarefa.
Determinístico vs Estocástico
Podemos classificar o ambiente como estocástico, pois uma mesma ação realizada
duas vezes sobre condições idênticas pode gerar efeitos diferentes, inclusive falhando em
obter o efeito desejado. Elementos comuns de uma partida de futebol real, como vento,
ruídos na informação e imprecisão na realização de determinadas ações são responsáveis

52. Capítulo 1. Robot World Cup (Robocup) 51
pela estocasticidade da Simulação 2D. Isso reflete o fato de que no futebol real ainda que
um jogador esteja sobre as mesmas condições gerais dificilmente conseguirá repetir, por
exemplo, um chute de forma idêntica, devido aos inúmeros pequenos detalhes envolvidos
nesta ação.
Episódico vs Sequencial
O ambiente é episódico em relação a uma série de partidas, porém sequencial em
relação as decisões tomadas dentro de um mesmo jogo, ou seja, a escolha do agente em
um dado ciclo pode afetar suas futuras possibilidades e decisões, exatamente como ocorre
no futebol real.
Estático vs Dinâmico
O agente dispõe de 1 ciclo para escolha de sua ação primária, e nos casos onde
se omitir e não realizar nenhuma ação, o jogo prossegue normalmente, como no futebol
real. Devido a esta independência do fluxo do jogo em relação aos agentes, o ambiente
é classificado como dinâmico. Uma partida prosseguirá até o fim, mesmo que todos os
agentes de ambos os times não tomem nenhuma ação.
Discreto vs Contínuo
O futebol é por natureza um problema contínuo. Porém, diferentemente de cate-
gorias como a Humanoide onde esta característica é preservada, a simulação 2D utiliza
um modelo de ação discreto, sendo uma aplicação de pseudo tempo-real, onde o agente
possui um número limitado de distintas e claramente definidas ações e percepções. Este é
o aspecto que mais difere do futebol real, onde não é natural se falar em ciclos discretos.
Agente único vs Multiagente
O futebol simulado 2D é, assim como o futebol real, disputado entre dois times
de 11 jogadores, e conta inclusive com técnico e jogadores reservas. É, deste modo, um
ambiente multiagente que envolve competição e cooperação.
Além das características acima o ambiente da 2D ainda inclui, como destacado em
(ABREU, 2010), diferentes atributos para cada jogador em campo, modelos realistas de
energia e um amplo conjunto de ações de baixo nível para compor os comportamentos
dos agentes, tornando o ambiente simulado 2D muito similar a um ambiente de futebol
real (à parte as diferenças no estilo de jogo resultantes principalmente da inexistência da
dimensão da altura). Essas semelhanças justificam a busca empreendida no Capítulo 2 por
soluções para análise de desempenho que estejam sendo aplicadas no futebol profissional.

53. 52
2 Análise quantitativa nos esportes
O campo da análise quantitativa nos esportes busca atingir a excelência na tomada
de decisões através de fortes evidências pautadas em dados. Ela busca indicadores de
desempenho mensuráveis em um mundo abundante em dados, com o objetivo de aprimorar
os resultados alcançados em relação a quando se confia apenas na intuição e experiência
de especialistas de domínio (SCHUMAKER; SOLIEMAN; CHEN, 2010).
A área está em franco crescimento nos últimos anos, tendo surgido grandes eventos
como o Sports Analytics Innovation Summit (Innovation Enterprise LTD, 2013), inúmeros
blogs, publicações como o Journal of Quantitative Analysis in Sports (ALBERT, 2013) e
livros como The Numbers Game (ANDERSON; SALLY, 2013b), todos especializados no
assunto. A revista de divulgação científica Galileu, trouxe o tema como capa do mês de
novembro de 2013, onde afirma que o futebol deixou de ser uma “caixinha de surpresas”.
Como citam os autores do The Numbers Game em seu blog Soccer By The Numbers
(ANDERSON; SALLY, 2013a):
After all, no matter how you define data, one thing we all share in
common is the goal to discover patterns, communicate them, and use
them to improve some aspect of decision making and ultimately team
performance, either through efficiency or innovation.1
Esses elementos tornam oportuna a realização desse trabalho nesse momento, dada
sua aderência a essa nova área que se mostra como uma forte tendência dentro do futebol.
A ideia de realizar análises quantitativas para avaliar com precisão o desempenho das
equipes de futebol de robôs se inspira nas abordagens sendo utilizadas no futebol real, que
como mostrou a seção 1.5 é muito similar a Simulação 2D.
2.1 Esportes e mineração de dados
Alguns esportes profissionais comportam os ambientes mais competitivos da atuali-
dade. Nesse contexto, equipes precisam extrair o máximo de suas decisões para conseguir
alguma vantagem. Como visto em (SOLIEMAN, 2006), a busca em nível profissional
por aprimoramentos faz parte da cultura nos esportes desde que eles se mostraram um
empreendimento rentável, mais de um século atrás. A prova disso é a antiga tarefa de
scouting, em que olheiros observam novos atletas e times adversários para gerar relatórios
1
“No fim das contas, não importa como você defina dados, uma coisa que todos temos em comum é a
meta de descobrir padrões, comunicá-los, e usá-los para melhorar algum aspecto da tomada de decisões
e, em última instância, desempenho do time, seja através da eficiência ou inovação.” (Tradução do
autor)

54. Capítulo 2. Análise quantitativa nos esportes 53
que possam ajudar sua equipe a definir a melhor estratégia ou fazer uma contratação
importante.
Mais recentemente, ao se perceber a riqueza escondida nos abundantes dados
gerados a cada partida, novas abordagens ganharam peso, com detaque ao uso de mineração
de dados. Vários times hoje empregam estatísticos e analistas para auxiliar o trabalho
tradicional dos especialistas no domínio (técnicos, olheiros e gerentes). O filme de 2011
MoneyBall, baseado em livro homônimo (LEWIS, 2003), popularizou o assunto ao contar
nos cinemas a história real de como o gerente de baseball Billy Beane construiu um time
competitivo de baixo custo em 2002, desafiando o status quo no esporte ao utilizar uma
abordagem baseada em novas medidas de desempenho pautadas em estatísticas.
Desde então, pode-se dizer que mineração de dados já iniciou uma pequena revolução
nos esportes, como nota-se no livro Sports and Data Mining (SCHUMAKER; SOLIEMAN;
CHEN, 2010):
From players improving their game-time performance using video analysis
techniques, to scouts using statistical analysis and projection techniques
to identify what talent will provide the biggest impact, data mining is
quickly becoming an integral part of the sports decision making landscape
where manager/coaches using machine learning and simulation techniques
can find optimal strategies for an entire upcoming season.2
Em apresentação no Massachusetts Institute of Technology (MIT) (GOLOVNYA,
2011), o especialista Mikhail Golovnya afirma que mineração de dados é uma evolução
dentro dos esportes. Ele mostra que dados históricos são a base para utilização de mineração
de dados e que o domínio esportivo é muito rico em dados. Devido a sua natureza, os jogos
possuem uma estrutura natural que facilita que os dados sejam coletados corretamente, o
que, junto com o grande interesse público, faz com que seja comum existirem bases de
dados abertas na internet com excelente qualidade, seja com dados sobre times, jogadores
individuais, partidas específicas ou temporadas completas.
Em resumo, esportes possuem dados abundantes com qualidade e muita necessidade
de informação, o contexto ideal para utilizar mineração de dados. Soma-se a isso os altos
valores transacionados pelos melhores atletas, que são o principal investimento das equipes,
fazendo com que saber escolhê-los ou prever lesões, por exemplo, sejam atividades que
valem milhões de dólares. Numa hierarquia definida em (SCHUMAKER; SOLIEMAN;
CHEN, 2010) sobre a relação entre organizações profissionais e o uso de técnicas para
analisar os seus dados, mineração de dados ocupa o nível mais alto, como pode ser visto
na Tabela 9.
2
“De jogadores melhorando seus desempenho nos jogos usando técnicas de análise de vídeo, até olheiros
usando análise estatística e técnicas de projeção para identificar quais talentos causarão o maior
impacto, mineração de dados está rapidamente se tornando uma parte integral da tomada de decisões
nos esportes, onde gerentes/técnicos usindo aprendizado de máquina e técnicas de simulação podem
encontrar estratégias ótimas para a próxima temporada inteira.” (Tradução do autor)

55. Capítulo 2. Análise quantitativa nos esportes 54
Tabela 9 – Hierarquia sobre a relação entre organizações e dados esportivos
Nível Relação
Um Nenhuma relação
Dois Especialistas de domínio fazendo predições usando instinto e intuição
Três Especialistas de domínio fazendo predições usando dados históricos
Quatro Uso de estatísticas no processo de tomada de decisão
Cinco Uso de mineração de dados no processo de tomada de decisão
Fonte: Adaptado de (SCHUMAKER; SOLIEMAN; CHEN, 2010)
Com o amadurecimento da tecnologia a tendência é que cada vez mais equipes
avancem para os níveis mais altos dessa hierarquia, sendo que em ligas como a Premier
League da Inglaterra, muitas já estão no nível 5. Enquanto isso, na Simulação 2D, a
realidade bastante diferente é que a maioria dos participantes encontram-se entre o nível 2
e 3, carecendo de ferramentas que popularizem as técnicas e, principalmente, aumentem
a oferta de dados históricos sobre as partidas. No presente, mineração de dados já se
provou útil no domínio da análise esportiva, e o futuro, ao menos como imaginado por
(SCHUMAKER; SOLIEMAN; CHEN, 2010), será muito promissor para área:
With more and more sports organizations embracing the digital era, it
may soon become a battle of the better algorithm or performance metric,
where the back-office analysts may be just as important as the players
on the field.3
2.2 Ferramentas comerciais
O crescimento da área é acompanhado pela evolução comercial, com diversas
empresas concorrendo para fornecer dados estatísticos e ferramentas de análise para
equipes e para a mídia esportiva, como Infostrada Sports, Wyscout, Sportstec, Prozone
e Stats, com destaque para a Opta Sports que lidera o mercado. A Opta existe desde
1996, inicialmente como fornecedor de dados para mídia, mas lançou nos últimos 2 anos a
ferramenta OptaPro, focada em clubes profissionais. Na Figura 11 é possível ver uma das
interfaces do OptaPro.
A base dessas ferramentas são os dados de cada partida. Um dos diferenciais da
Opta é prover os dados em tempo real. Para isso um grupo de três profissionais assistem
aos jogos munidos de ferramentas através das quais realizam a contagem das estatísticas a
medida que cada lance ocorre (PRINCE, 2013a). Apesar de existirem ferramentas para
coletar parte dos dados automaticamente, através de sistemas de câmera especiais e análise
de vídeo ou outras tecnologias de rastreamento como wi-fi ou rádio, para obter uma
3
“Com mais e mais organizações esportivas abraçando a era digital, isso pode em breve se tornar uma
batalha entre o melhor algoritmo ou métrica de desempenho, onde os analistas no escritório podem
ser tão importantes quanto os jogadores no campo.” (Tradução do autor)

56. Capítulo 2. Análise quantitativa nos esportes 55
Figura 11 – Uma das interfaces da ferramenta OptaPro destacando os passes longos do
jogador David Beckham
Fonte: (PRINCE, 2013b)
análise rápida, completa e de qualidade os sistemas comerciais ainda se baseiam em dados
computados por humanos.
A Opta afirma possuir os bancos de dados esportivos mais detalhados do mercado,
tendo sido adotada como fornecedora de dados padrão de grandes equipes do mundo todo,
incluindo em seu portfolio, a partir de agosto de 2013, até mesmo a Confederação Brasileira
de Futebol (Opta Sports, 2013). Dada a maturidade do mercado, com o aval das maiores
equipes do mundo, as abordagens utilizadas por essas ferramentas análiticas comerciais
servirão como orientação sobre quais variáveis são as mais importantes de serem coletadas,
ao invés de utilizar as definições em (ABREU et al., 2011) (descritas na seção 1.4). Outra
vantagem dessa escolha é poder realizar mais facilmente comparações diretas com dados
históricos coletados no futebol real.
2.3 Definição de eventos
Não existe um consenso no futebol sobre quais as métricas mais importantes, com
cada equipe utilizando os dados disponíveis de modo particular. O que é certo, é que
primeiro se precisa de dados abundantes para apenas depois estudar as correlações que
existem entre determinados eventos e o sucesso das equipes, dados estes que não estão
disponíveis na Simulação 2D. O foco desse trabalho foi encontrar um método para extrair
automaticamente dos jogos da 2D as estatísticas relacionadas a eventos de chutes a gol,
que se mostraram de difícil detectação com qualidade através de heurísticas (seção 1.4).
Para se chegar ao conjunto de métricas a serem detectadas foram estudados

57. Capítulo 2. Análise quantitativa nos esportes 56
os eventos coletados no ambiente profissional e disponibilizados através da ferramenta
OptaPro, que como mostrado na seção 2.2 é a líder de mercado e possui bastante maturidade
no setor. A empresa foi contatada por email e forneceu uma lista completa com a definição
dos eventos que utiliza, informação que era mantida online em (BATEMAN, 2012) e
pode ser vista no Anexo A. Existem 4 métricas diretamente relacionadas aos chutes, que
adaptadas ao ambiente da 2D foram assim definidas:
1. Goal/Own goal: os gols e gols contra. Sempre que a bola passa entre as traves
com o playmode play_on, resultando no playmode goal_[l|r]. Quando o último toque
na bola antes de entrar no gol é dado apenas por um jogador defensor, o gol é
considerado gol contra.
2. Shot on target: Toda tentativa de chutar no gol que:
• Termina em gol;
• Bola iria para o gol mas é interrompida por uma defesa do goleiro;
• Bola iria para o gol mas é interrompida por um defensor que é o último jogador
que pode parar a bola.
3. Shot off target: Toda tentativa de chutar no gol que acerta a trave ou vai pra fora
passando pelo limite da área de penâlti;
4. Blocked shot: Toda tentativa de chutar no gol que é bloqueada por um defensor,
onde existam outros defensores ou o goleiro entre o jogador que bloqueou e o gol.
Gols e gols contra são eventos simples de serem detectados através de heurísticas, o
próprio artigo de (ABREU et al., 2011) cita um método para realizar a detecção com alta
taxa de sucesso, sendo desnecessária a criação de um classificador mais robusto. Com o
evento de gols descartado, o foco da classificação foram os eventos de Shot on target, Shot
off target e Blocked shot. Para Shot off target foi adotado o limite da área do penâlti (assim
como Intercepted shot de Abreu, mas diferente da definição da Opta que não possui essa
restrição) pois os atuais modelos de chute na 2D são mais precisos que os chutes humanos,
não ocorrendo um caso onde um robô queira chutar no gol e consiga, por exemplo, conceder
um lateral, como em casos limites podem acontecer no futebol real.
É importante notar que os eventos definidos pela Opta são muito similares aos
eventos definidos em (ABREU et al., 2011) (listados na seção 1.4), havendo uma corres-
pondência entre Blocked shot e Intercepted shot, ambos os casos definidos como Shot on
target e entre Shot off target e Shot. Nos detalhes, porém, todas as definições possuem
casos que as diferem: uma bola salva pelo goleiro ou pelo último defensor é classificada
como Shot on target pela Opta enquanto é Intercepted shot em Abreu; bolas na trave ou

58. Capítulo 2. Análise quantitativa nos esportes 57
que passem a até 0.5m do gol são Shot off target para Opta enquanto são Shot on target
para Abreu.
O resultado dessa diferença é que apesar de todos os chutes a gol dados nos jogos
estarem incluídos em ambas as definições, a classe onde cada chute é colocado pode
variar, ou seja, apesar da soma de todos os chutes dados no gol em um jogo ser a mesma
tanto para Opta quanto para Abreu, os chutes provavelmente estarão agrupados de forma
distinta. Observadas de perto, nota-se qua a abordagem da Opta torna mais difícil realizar
a classificação uma vez que na definição de Abreu todas as bolas bloqueadas estão apenas
em um grupo, todas as bolas que passam perto do gol, incluindo a trave, estão em outro,
e as bolas que claramente vão para fora estão todas agrupadas no último. A classificação
da Opta exige, por exemplo, que caso seja identificado um bloqueio na bola, ainda seja
analisada as posições dos outros defensores na área para chegar a conclusão se foi um Shot
on target ou Blocked shot.
Retornando à lista de eventos da Opta, existem ainda 2 métricas relacionadas a
chute que são derivadas a partir das 4 primeiras, e podem ser calculadas facilmente a
partir da classificação automática das primeiras. São elas:
• Chance conversion ou Goals-to-shot ratio: representam as oportunidas conver-
tidas em gol, dada pelos gols marcados dividido pelo total de chutes (excluídos os
Blocked shots);
• Shooting accuracy: representa a precisão ao chutar pro gol, dada pelo total de
Shots on target dividido pelo total de chutes (excluídos os Blocked shots).
Apesar da extensa lista de eventos da Opta que precisarão ser alvo de trabalhos
futuros, permitir a classificação automática e com qualidade dos 6 eventos definidos acima
já representa um grande benefício para os pesquisadores investigando o desempenho dos
sistemas multiagentes sobre os quais trabalham. Essas são, juntamente com os passes
decisivos e posse de bola, algumas das métricas mais importantes para analisar o desempe-
nho de uma equipe de futebol, sendo amplamente comunicadas, por exemplo, durante as
transmissões esportivas. Na copa de 2014, por exemplo, toda substituição de jogador foi
acompanhada pelas informações sobre total de gols, total de finalizações (Shots on target
+ Shots off target) e finalizações no gol (Shots on target). Todos esses eventos podem ser
usados tanto para avaliar o desempenho da equipe como um todo, quanto de um robô em
particular.

59. Capítulo 2. Análise quantitativa nos esportes 58
2.4 Diferenças entre o futebol profissional e o de robôs
Essa seção faz uma rápida análise sobre o uso de estatísticas no futebol real e no
futebol de robôs simulado. Em ambos os casos há interesse em informações estatísticas,
porém, por motivações diferentes. Enquanto no futebol real o principal motivador é
financeiro, uma vez que uma única decisão pode custar milhões de dólares para um clube,
no futebol de robôs as estatísticas de alto nível são o primeiro passo para criação de uma
metodologia de análise de desempenho que ajude os pesquisadores a avaliar melhor suas
teorias, modelos, algoritmos e arquiteturas, definindo um ambiente mais completo para
testes e experimentações.
A realidade do estado da arte em ambos os contextos difere bastante, o que
provavelmente se explica facilmente pelos bilhões que o futebol profissional movimenta.
Nesse caso, os jogos oficiais atraem o interesse de grande parte da sociedade (o futebol é
considerado atualmente o esporte mais popular do mundo (Enciclopédia Britânica, 2013)),
tornando factível que as empresas especializadas tenham uma equipe focada em cada jogo
para realizar coletas de dados manualmente em tempo real, processo explicado na seção 2.2.
Já sobre o interesse na ciência, foi emblemático o tempo recebido para a demonstração
do projeto Andar de Novo, liderado pelo cientista brasileiro Miguel Nicolelis, durante a
abertura da Copa do Mundo de 2014.
Apesar das ferramentas de coleta automática estarem evoluindo, uma comparação
realizada em (ABREU, 2010) mostra que mesmo nesses casos é comum ser necessário
algum tipo de processamento manual, pois há um desafio inerente à coleta de dados básicos
como a posição dos jogadores e da bola (processamento de imagens, ruídos na detectação
etc). Por outro lado, a grande vantagem do futebol simulado é possuir um servidor central
que possui informações básicas precisas sobre o estado do mundo, o que permitiu que a
coleta manual dos eventos de chute se tornasse desnecessária. Na 2D, em que o interesse
em cada jogo é consideravelmente menor (particular dos pesquisadores envolvidos) e a
quantidade de jogos a ser processados pode ser muito maior (dado que um único teste pode
exigir que se rode diversas simulações), realizar detecções automaticamente é fundamental
para que seja factível obter estatísticas de futebol na Simulação 2D e diminuir a distância
para o estado da arte no futebol profissional.

60. 59
3 Mineração de dados
O trabalho partiu da hipótese de que seria possível solucionar o problema da coleta
de estatísticas de chutes a gol utilizando técnicas clássicas de mineração de dados. Isso
per si já é uma diferença para os trabalhos relacionados mostrados na seção 1.4, que
utilizaram heurísticas para realizar as detecções. Ao longo desse trabalho mineração de
dados é entendida como o processo completo associado a Descoberta de Conhecimento em
Bases de Dados (KDD). Apesar de ser muito comum os dois termos serem usados como
sinônimos, como é feito aqui, é amplamente aceita a distinção técnica feita em (FAYYAD;
PIATETSKY-SHAPIRO; SMYTH, 1996):
In our view, KDD refers to the overall process of discovering useful
knowledge from data, and data mining refers to a particular step in
this process. Data mining is the application of specific algorithms for
extracting patterns from data.1
No mesmo artigo também há uma definição mais detalhada para KDD: “KDD
is the nontrivial process of identifying valid, novel, potentially useful, and ultimately
understandable patterns in data”2
. A Figura 12 apresenta uma visão geral sobre mineração
de dados, mostrando que ela pode ser entendida como usar dados históricos para ganhar
insights sobre a população que gerou esses dados e / ou fazer predições sobre novos dados
oriundos dessa população (GOLOVNYA, 2011).
São esses então os dois objetivos de alto-nível comuns para um trabalho de mineração
de dados: (a) prever valores futuros ou desconhecidos de variáveis de interesse, ou (b)
descrever os dados através de padrões reconhecíveis por humanos (FAYYAD; PIATETSKY-
SHAPIRO; SMYTH, 1996). Essas metas podem ser alcançadas através de uma variedade de
métodos, como classificação, agrupamento (clustering), regressão e associação. O objetivo
desse trabalho pode ser decomposto na tarefa de atribuir registros extraídos dos logs da
Simulação 2D para classes nominais e discretas predefinidas (eventos estabelecidos na
seção 2.3), que é essencialmente um problema de classificação.
O restante do capítulo detalha a metodologia para desenvolvimento da solução,
se aprofunda na área de classificação, mostra os principais algoritmos que foram usados
para derivar modelos de classificação para o problema em mãos e explica alguns tópicos
especiais referentes ao trabalho de minerar dados, como cuidados para se obter um modelo
genérico, e técnicas de validação e visualização dos resultados. Por fim é apresentada a
principal ferramenta utilizada na etapa de modelagem.
1
“Em nossa visão, KDD se refere ao processo geral de descoberta de conhecimento útil a partir de
dados, e mineração de dados se refere a um passo particular deste processo. Mineração de dados é a
aplicação de algoritmos específicos para extrair padrões dos dados.” (Tradução do autor)
2
KDD é o processo não trivial de identificar padrões válidos, originais, potencialmente úteis, e em
última instância compreensíveis, nos dados

61. Capítulo 3. Mineração de dados 60
Figura 12 – A essência da mineração de dados
Fonte: Adaptado de (GOLOVNYA, 2011)
3.1 Metodologia CRISP-DM
A metodologia CRISP-DM (Cross Industry Standard Process for Data Mining)
(CHAPMAN et al., 2000) foi a diretriz utilizada para realizar o projeto. Essa metodologia
foi escolhida por ser amplamente utilizada, sendo considerada em (MARISCAL; SEGOVIA,
2009) como sendo “‘de facto standard’ for developing DM & KD projects”3
. Apesar de
ser desenvolvida para o mercado, sua robustez permite que seja aplicada no processo
científico com adaptações sutis, entendendo que prioridades científicas são diferentes de
prioridades de negócio. Ela possui tarefas distribuídas em 4 níveis de abstração, mas para
fins de objetividade a metodologia será descrita aqui apenas do nível mais alto, o das fases
(Figura 13).
A primeira fase, Compreensão do Problema (Business Understanding), está rela-
cionada a compreensão do objetivo que se deseja alcançar com mineração de dados, as
restrições envolvidas e a elaboração de um cronograma. As metas são definidas tanto em
termos do problema que se quer resolver (business goal) quanto em termos mais práticos
relativo ao que se pretende realizar com mineração de dados (data mining goal). Também
é definido o critério de sucesso do projeto e as ferramentas chave a serem utilizadas. A
principal delas foi o Waikato Enviroment for Knowledge Analysis (WEKA), um software
que é apresentado na seção 3.7.
Na fase 2, Compreensão dos Dados (Data Understanding), uma das principais
3
“’De facto padrão’ para desenvolver projetos de DM e KD” (Tradução do autor)

62. Capítulo 3. Mineração de dados 61
Figura 13 – As fases do processo CRISP-DM
Fonte: (AGENCY, 2013)
atividades é a coleta inicial dos dados e sua descrição. Essa etapa envolveu uma análise
qualitativa dos dados, em que diversas partidas foram assistidas, e também uma análise
mais objetiva, estudando os dados para entender sua estrutura e que atributos são úteis
para a realização da tarefa de classificação. No fim dessa etapa foi realizada a seleção do
espaço amostral que seria utilizado no restante do projeto, uma vez que a classificação
manual feita na próxima fase restringe a massa de dados sobre a qual é viável trabalhar.
Esse contato prévio com os dados servem ao propósito de identificar possíveis problemas o
mais cedo possível, derivar os primeiros insights e entender algumas relações existentes
nos dados, elementos estes que são importantes nas decisões das próximas etapas.
Na terceira fase, Preparação dos Dados (Data Preparation), os dados brutos dos logs
são extraídos e carregados num repositório intermediário. Depois, uma versão final (apesar
de ser comum iterar sobre essa fase) do conjunto de dados utilizado para modelagem é
criada a partir de diversas transformações nos dados originais, como limpeza para garantir
qualidade, derivação de atributos, criação de novas entradas e integração de dados de
diferentes fontes. Ao fim dessa fase, tem-se um vetor de características normalizado que
pode ser utilizado como entrada para os algoritmos de aprendizagem supervisionada
utilizados na etapa seguinte. Atenção particular foi dada a esta fase, pois como citado
em (SANTOS, 2006), “No caso particular de análise de logs, é indispensável, custosa e
problemática”.
Na fase seguinte, Modelagem (Modeling), o conjunto de dados final é pré-processado

63. Capítulo 3. Mineração de dados 62
e técnicas de modelagem são selecionadas, aplicadas e otimizadas. Para selecionar as
técnicas mais propícias foi empreendido um trabalho empírico de testes exaustivos com
diferentes algoritmos de aprendizagem supervisionada. Como diferentes técnicas podem
ser utilizadas para resolver o mesmo problema, foi necessário mais de uma iteração de
prototipação para encontrar a técnica apropriada.
Selecionadas as técnicas, é necessário criar um mecanismo para validação. Existem
diferentes métodos clássicos para proceder com o setup do mecanismo de validação, como
o n-fold cross-validation (TAN; STEINBACH; KUMAR, 2006), que é melhor detalhado
na seção 3.5. Por fim, as técnicas de modelagem são aplicadas sobre os dados preparados e
soluções são obtidas. Essas soluções podem ser chamadas de modelos, e representam a
aplicação de um método específico mais os parâmetros utilizados para maximizar algum
indicador de desempenho. Ainda nessa fase, é feita uma análise prévia sobre os resultados
gerados e decide-se sobre iterar na construção de modelos ou prosseguir.
Quando encontrado pelo menos um modelo satisfatório, entra-se na penúltima fase,
Avaliação dos Resultados (Evaluation). Aqui uma análise mais profunda sobre os modelos
gerados é feita e eles são comparados entre si e com o baseline definido pela literatura. O
resultado alcançado é comparado com os objetivos da pesquisa, permitindo que os modelos
finais sejam aceites como uma solução satisfatória para o problema. É importante também
revisar o processo e verificar se todas as tarefas foram conduzidas corretamente, ou se algo
precisará ser refeito.
A última etapa, Implantação (Deployment), envolve a organização e apresentação
do conhecimento adquirido. Nessa etapa o modelo pode ser aplicado em um contexto real e
colocado em produção, mas como o objetivo desse projeto era encontrar um melhor modelo,
a aplicação do modelo não foi incluída no escopo, apesar de que sua utilidade foi avaliada.
Alguns cuidados sobre a manutenção dos modelos também podem ser listados nesse
momento, afinal serão necessárias atualizações para que eles continuem tendo validade,
uma vez que é possível haverem mudanças nas regras do jogo, na física do ambiente e
principalmente, no comportamento das equipes ao longo do tempo. Como mostrado em
(GOLOVNYA, 2006), mineração de dados não se refere a leis de longo prazo como é comum
na ciência, restando apenas usar um modelo enquanto ele continua tendo aderência aos
dados sobre os quais ele foi desenvolvido (mais sobre isso na seção 9.3).
3.2 Classificação
Classificação é definida em (TAN; STEINBACH; KUMAR, 2006): “Classification
is the task of learning a target function 𝑓 that maps each attribute set 𝑥 to one of

64. Capítulo 3. Mineração de dados 63
the predefined class labels 𝑦”4
, com essa função 𝑓 sendo conhecida como um modelo
de classificação (Figura 14). Isso é feito pelo exame de dados já classificados (casos) e
indutivamente encontrando um padrão para prever essas classes. Como visto em (Two
Crows, 2005), as fontes para os casos podem ser dados históricos, experimentos, ou como
nesse trabalho, advir de classificações feitas manualmente sobre algumas amostras dos
dados disponíveis.
Figura 14 – Classificação como a tarefa de mapear uma conjunto de atributos de entrada
𝑥 para sua classe 𝑦
Fonte: Adaptado de (TAN; STEINBACH; KUMAR, 2006)
Um exemplo de aplicação de classificadores é a filtragem de emails com spam baseada
no cabeçalho e no conteúdo da mensagem. Um outro caso clássico é a identificação de
imagens em grandes bancos de dados, como classificar galáxias de acordo com seus formatos
(TAN; STEINBACH; KUMAR, 2006). Classificar se diferencia de agrupar essencialmente
porque no caso do agrupamento não se sabe os grupos que serão formados, ou dito de
outro modo, as classes finais. Em relação a regressão, a principal diferença é que enquanto
na regressão a saída 𝑦 é contínua, na classificação 𝑦 deve ter um valor discreto (restrição
que não se aplica as entradas 𝑥, que podem ser contínuas).
Mais especificamente, classificadores são mais apropriados para descrever ou realizar
predições em conjuntos com categorias binárias ou nominais (caso da Simulação 2D), sendo
menos efetivos sobre categorias ordinais por não considerar a ordem implicita nas categorias.
Diferentes tipos de modelos podem ser aplicados para solucionar problemas de classificação,
como árvores de decisão, classificadores baseados em regras, redes neurais, support vector
machines (SVM) e classificadores naïve Bayes (TAN; STEINBACH; KUMAR, 2006).
Cada técnica possui diferentes implementações concretas de algoritmos de aprendizado
supervisionado para extrair um modelo que represente a relação entre os dados de entrada
e a classe de saída. A Figura 15 apresenta uma visão geral desse processo.
Os dados alvo comumente são divididos em dois grupos, um para realizar o trei-
namento do classificador e outro formado por dados independentes, não utilizados para
gerar o modelo final, de modo que seja possível medir a taxa de erro do classificador e
4
“Classificação é a tarefa de aprender uma determinada função 𝑓 que mapeia cada conjunto de atributos
𝑥 para um dos rótulos de classe predefinidos” (Tradução do autor)

65. Capítulo 3. Mineração de dados 64
Figura 15 – Abordagem geral para construir um modelo de classificação
Fonte: Adaptado de (TAN; STEINBACH; KUMAR, 2006)
determinar a sua qualidade (mais sobre validação na seção 3.5). Em geral os problemas
de classificação são entendidos como problemas de aprendizagem supervisionada, pois as
saídas para cada exemplo do conjunto de treino são conhecidas.
Apesar da importância da etapa de modelagem, que foi o principal foco dessa seção
e é a que mais recebe atenção na literatura, a etapa de preparação dos dados costuma
ser a mais trabalhosa no processo de construção de um classificador. Os algoritmos de
aprendizado funcionam sobre vetores de dados de tamanho fixo, conhecido como vetores de
características, e até chegar nesses vetores os dados originais precisam ser compreendidos
e transformados de forma significativa, envolvendo um grande número de detalhes.
3.3 Visualização de dados
Visualização de dados é um campo à parte no KDD. Seu principal objetivo é criar
meios de comunicar informações graficamente com clareza e eficiência. Sua relevância é
descrita em (Two Crows, 2005):
Graphing and visualization tools are a vital aid in data preparation and
their importance to effective data analysis cannot be overemphasized.
Data visualization most often provides the Aha! leading to new insights
and success.5
5
“Ferramentas de visualização e criação de gráficos são uma ajuda vital na preparação dos dados e
sua importância para uma análise de dados efetiva não pode ser subestimada. Visualização de dados
geralmente provê o Ahá! que leva a novas descobertas e ao sucesso.” (Tradução do autor)

66. Capítulo 3. Mineração de dados 65
Visualização dos dados tem um papel importante tanto no início quanto no fim
do processo de modelagem. Durante o pré-processamento é essencial para se conhecer
melhor os dados, servindo por exemplo para se ter uma ideia de sua distribuição, de
suas relações, para selecionar atributos e para orientar a escolha dos tipos de modelos
que podem ser aplicados (SANTOS, 2012). Durante a validação servem para clarificar os
resultados obtidos, e durante a implantação podem ser fundamentais para que os usuários
finais extraiam valor de todo o processo.
Em (SANTOS, 2012) são listadas diversas técnicas de visualização famosas divididas
em 3 categorias. A primeira se refere à técnicas geométricas como Matriz Scatterplot
(Figura 16), Coordenadas Paralelas e Mapas de Kohonen. A segunda à técnicas baseadas em
ícones que criam dimensões adicionais, como a curiosa representação conhecida como Caras
de Chernoff (Figura 17). Por último são listadas técnicas hierárquicas, que particionam as
dimensões em subdimensões, como Dimensional Stacking e Treemap.
Figura 16 – Scatterplot Matrix criada no WEKA com cruzamentos entre algumas das
características dos chutes a gol
Fonte: Elaborado pelo autor (captura de tela)

67. Capítulo 3. Mineração de dados 66
Gráficos possuem um poder representacional muito grande quando comparado
a textos e números, tornando muito mais fácil a visualização de alguns padrões, como
correlações lineares entre variáveis contínuas no caso da matriz scatterplot, e a exploração
sobre os dados. Entretanto a área possui um enorme desafio que é conseguir representar
modelos com muitas dimensões em uma tela de computador ou no papel, sendo necessário
formas criativas e inteligentes para colapsar N dimensões em apenas 2 (Two Crows, 2005).
Outro empecilho são os limites da cognição humana, que como se brinca em (SANTOS,
2012), possui também suas próprias limitações de hardware.
Figura 17 – Caras de Chernoff
Fonte: (SANTOS, 2012)
Já no processo de avaliação dos resultados, uma técnica bem simples porém bastante
utilizada em problemas de classificação são as matrizes de confusão (confusion matrices)
(Two Crows, 2005). Elas facilitam a avaliação do desempenho do modelo gerado cruzando os
totais de predições corretas e incorretas, mostrando inclusive qual o tipo de erro cometido.
A Tabela 10 mostra uma matriz de confusão, sua diagonal contendo as informações preditas
corretamente. No exemplo, das 75 instâncias da Classe A, 70 foram preditas de forma
correta e 5 erros foram cometidos, 4 como Classe B e 1 como Classe C. Matrizes de confusão
servem de base para a definição de diversas métricas de desempenho de classificadores
como descrito na seção 3.6.
3.4 Generalização
Uma das características mais importantes de um classificador é que além de
representar bem a estrutura dos dados do conjunto de treinamento, ele deve ser capaz

68. Capítulo 3. Mineração de dados 67
Tabela 10 – Matriz de confusão para um classificador multiclasse
Valor predito
Valor real Classe A Classe B Classe C
Classe A 70 4 1
Classe B 3 74 2
Classe C 7 2 77
Fonte: Elaborado pelo autor
de definir corretamente as classes para dados com os quais o algoritmo de aprendizado
não tenha tido contato. Isto é conhecido como a capacidade de generalização do modelo.
Existem dois problemas clássicos relacionados: underfitting e, o principal deles, overfitting.
Underfitting ocorre quando um modelo ainda não consegue representar bem os
dados sendo trabalhados, consequentemente tendo uma alta taxa de erro tanto no conjunto
de treinamento (chamado de erro aparente) quanto no conjunto de teste (chamado de
erro de generalização). Já o fenômeno de overfitting ocorre quando um modelo passa a
representar o conjunto de treinamento cada vez melhor, ao passo que as taxas de erro de
generalização aumentam. A Figura 18 mostra um exemplo de overfitting na aplicação de
um modelo de árvores de decisão.
Figura 18 – Exemplo de overfitting. A partir de certo ponto, a medida que cresce o número
de nós na árvore, a taxa de erro diminui no conjunto de treinamento enquanto
aumenta no de teste
Fonte: Adaptado de (TAN; STEINBACH; KUMAR, 2006)
Uma das causas do overfitting é que ao se adequar tão bem ao conjunto de trei-
namento o modelo pode representar também os ruídos presentes nos dados. (FAYYAD;

69. Capítulo 3. Mineração de dados 68
PIATETSKY-SHAPIRO; SMYTH, 1996) apresenta o problema e algumas possíveis solu-
ções:
When the algorithm searches for the best parameters for one particular
model using a limited set of data, it can model not only the general
patterns in the data but also any noise specific to the data set, resulting
in poor performance of the model on test data. Possible solutions in-
clude cross-validation, regularization, and other sophisticated statistical
strategies.6
É comum, por exemplo, que um modelo mais complexo seja pior do que um modelo
mais simples, apresentando uma menor taxa de erro aparente mas uma maior taxa de erro
de generalização. Favorecer modelos mais simples está em concordância com o princípio
da Navalha de Occam, que aplicada no contexto de KDD leva a seguinte definição (TAN;
STEINBACH; KUMAR, 2006): “Given two models with the same generalization errors,
the simpler model is preferred over the more complex model”7
. Existem métodos específicos
para verificar a simplicidade de um modelo como Minimum Description Length (MDL)
(WITTEN; FRANK; HALL, 2011).
Uma grande vantagem do contexto da Simulação 2D é a alta qualidade dos dados
que foram utilizados como base, uma vez que estes são logados pelo próprio simulador (como
mostrado na subseção 1.2.3). Isso diminui consideralmente a possibilidade de overfitting
por conta de ruídos nos dados. Algum ruído significativo, porém, ainda é adicionado aos
dados durante a classificação manual e a etapa de seleção e extração de características
realizadas na fase 3, Preparação dos Dados.
Por conta disso é necessário que cuidados especiais sejam tomados nesta etapa,
realizando por exemplo uma dupla checagem das classificações realizadas manualmente.
Ainda assim, é muito provável que algumas situações raras e difíceis de classificar tenham
gerado algum ruído, o que é aceitável (TAN; STEINBACH; KUMAR, 2006): “Errors due
to exceptional cases are often unavoidable and establish the minimum error rate achievable
by any classifier“8
. Isso nos lembra que não existem modelos perfeitos, eles são sempre
modelos.
Quando a base utilizada é muito pequena surge um outro fator importante que pode
levar ao overfitting, a ausência de casos representativos. Outro ponto forte do contexto
da 2D é o fato de se tratar de um ambiente simulado, onde gerar novos casos não é um
6
“Quando um algoritmo busca pelos melhores parâmetros para um modelo particular usando um
conjunto limitado de dados, ele pode modelar não apenas os padrões gerais nos dados mas também
qualquer ruído específico ao conjunto de dados, resultando em um desempenho ruim do modelo
sobre dados de teste. Soluções possíveis incluem cross-validation, regularização, e outras estratégias
estatísticas sofisticadas.” (Tradução do autor)
7
“Dados dois modelos com os mesmos erros de generalização, o modelo mais simples é preferível sobre
o mais complexo.” (Tradução do autor)
8
“Erros devido a casos excepcionais geralmente são inevitáveis e estabelecem a taxa de erro mínima
alcançável por qualquer classificador”

70. Capítulo 3. Mineração de dados 69
problema. Novamente, o gargalo se tornou a etapa de classificação manual durante a fase
de Preparação dos Dados. Isso se deve ao alto custo em tempo necessário para analisar as
partidas (detalhado na seção 1.3), o que reduziu o tamanho da base de dados disponível
para a classificação.
Isso tornou essencial que a escolha do espaço amostral fosse bastante criteriosa,
garantindo que times com diferentes características e também cruzamentos variados entre
esses times, fossem incluídos no conjunto de dados final. Isso reforça a importância da
segunda fase do projeto, Compreensão dos Dados, sem a qual essa escolha criteriosa não
seria possível.
Algumas técnicas para resolver o problema do overfitting estão associados ao tipo
de modelo sendo utilizado, como pré-poda ou pós-poda, no caso de árvores de decisão.
Outras soluções podem ser mais genéricas, como as relacionadas à técnicas de validação,
exemplo de cross-validation citada acima, que será discutida na seção 3.5.
3.5 Técnicas de validação
Como visto na seção 3.2, para determinar a qualidade de um classificador é preciso
aplicar o modelo gerado a partir de um conjunto de treinamento em um conjunto de teste
independente, que não tenha sido utilizado na modelagem. Isso porque o erro aparente
(medido sobre o conjunto de treino) é uma medida por demais otimista, uma vez que o
modelo foi desenvolvido justamente para representar bem os dados de treinamento, sendo
insuficiente para prever o desempenho do modelo em novos dados, ou seja, sua capacidade
de generalização. Nessa seção serão analisadas técnicas para realizar a separação dos dados
disponíveis nos conjuntos de treinamento e teste.
Quando o volume dos dados é grande não há problemas: é possível treinar e testar o
modelo usando uma quantidade de dados significativa em ambas atividades, o que em geral
leva a um melhor resultado (desde que se garanta que os 2 grupos sejam representativos do
total dos dados). Porém, quando o total de dados disponíveis são uma restrição, técnicas
específicas precisam ser aplicadas para se obter um melhor resultado. Esse tipo de restrição
é comum quando os dados precisam ser classificados manualmente, uma tarefa intensiva e
custosa, que precisou ser realizada nesse projeto.
O problema surge pois para construir um bom classificador é importante ter muitos
dados para treinamento, ao mesmo tempo em que para avaliá-lo de forma confiável, é
necessário possuir muitos dados para o conjunto de teste. Em alguns casos a questão pode
ser ainda mais crítica, pois pode ser necessária a criação de um terceiro conjunto, chamado
de conjunto de validação. Ele pode ser necessário para realizar a otimização de alguns
parâmetros do modelo, e uma vez que também precisa ser um conjunto independente,
ainda menos dados estarão disponíveis para o treinamento e teste.

71. Capítulo 3. Mineração de dados 70
Quando apenas é feita a separação do conjunto independente de teste, o processo é
conhecido como validação simples ou método holdout. O conjunto de treinamento deve
ser o maior entre os dois, comumente contendo pelo menos 2/3 das amostras (WITTEN;
FRANK; HALL, 2011). Ao criar os conjuntos, atenção especial deve ser dada ao método
de seleção das amostras que irão compor cada um deles, de modo que ambos sejam
representativos do total dos dados. Garantir que a seleção seja aleatória não é suficiente,
sendo comum a aplicação de um método conhecido como estratificação (WITTEN; FRANK;
HALL, 2011), que cria subgrupos de dados homogêneos em cima dos quais a aleatorização
é feita de modo controlado.
Entre as técnicas mais sofisticadas, que apresentam um melhor desempenho quando
há poucos dados, destacam-se cross-validation e bootstrap. Essas técnicas utilizam meca-
nismos que permitem que todos os dados disponíveis sejam utilizados para o treinamento.
A essência da cross-validation é realizar a divisão do conjunto total em N subconjuntos
disjuntos de tamanho similar, executando o processo completo N vezes, de modo que cada
um dos subconjuntos assuma o papel do conjunto de teste uma vez. A taxa de erro total
é definida como o somatório ou a média dos erros de todas as execuções. Esse método é
conhecido como n-fold cross-validation. É possível, ainda, realizar um treinamento final
com todos os dados disponíveis, de modo a obter um melhor resultado do treino, mas
mantendo o erro obtido a partir das N execuções anteriores (WITTEN; FRANK; HALL,
2011).
Apesar de não serem conclusivos, diferentes estudos sobre variados conjuntos de
dados e modelos apontam o 10-fold cross-validation como a aplicação específica desse
método que gera os melhores resultados. Na prática a divisão em 10 subconjuntos já se
tornou uma espécie de padrão, sendo comumente a escolha adotada. É comum ainda que
para alcançar uma maior precisão nos resultados, todo o processo seja repetido 10 vezes,
totalizando 110 execuções (com treinamento final) do mesmo algoritmo de aprendizado
sobre o mesmo conjunto de dados. Isso é feito para reduzir o efeito da variação aleatória
no processo de criação dos subgrupos. O resumo é um processo intensivo com um total
de 110 execuções de uma mesma configuração (algoritmo de aprendizado e conjunto de
dados inicial) para obter uma medida de desempenho confiável para um modelo. Todo o
processo é explicado em (WITTEN; FRANK; HALL, 2011).
Um tipo específico de n-fold cross-validation que merece destaque é a leave-one-out,
onde N é o tamanho total do conjunto. Uma das vantagens desse método é a utilização
da maior quantidade de dados possível para realizar cada iteração de treinamento. Ele
também tem o atrativo de ser determinístico, uma vez que o conjunto de testes possui
apenas 1 elemento. A sua desvantagem principal é custo computacional envolvido, o
que pode torná-lo impraticável para grandes conjuntos de dados. Alguns casos especiais
também precisam ser observados. Mais sobre o assunto pode ser encontrado em (WITTEN;

72. Capítulo 3. Mineração de dados 71
FRANK; HALL, 2011).
O outro método citado, o bootstrap, também é bastante popular. A principal
diferença para o cross-validation é que o conjunto de treinamento é gerado utilizando o
processo de amostragem com substituição. Isso significa que ao selecionar uma amostra o
conjunto inicial não é alterado, permitindo que o mesmo caso seja selecionado repetidas
vezes. A variante mais comum do método é conhecida como 0.632.
Nela um novo conjunto do mesmo tamanho do original é gerado utilizando a
amostragem com substituição, ou seja, apesar de ter o mesmo tamanho, ele possui diversas
instâncias repetidas. As amostras que não forem selecionadas nenhuma vez compõem o
conjunto de teste. O modelo obtido do treinamento é aplicado no conjunto de teste e a
taxa de erro (𝑒𝑖) é determinada. O procedimento é então repetido 𝑏 vezes e a taxa de erro
final é calculada como uma média da combinação do erro aparente (ou de resubstituição)
do conjunto de treino (𝑎𝑐𝑐𝑖) com o erro de generalização de cada iteração, utilizando a
seguinte fórmula (TAN; STEINBACH; KUMAR, 2006):
𝑒 𝑏𝑜𝑜𝑡 =
1
𝑏
𝑏∑︁
𝑖=1
(0.632 × 𝑒𝑖 + 0.368 × 𝑎𝑐𝑐𝑖) (3.1)
Um estudo comparativo realizado em (KOHAVI, 1995), que incluiu as técnicas de
bootstrap e cross-validation, apontou que o 10-fold cross-validation estratificado é a melhor
forma de estimar o erro de um modelo. Por isso será essa a técnica adotada nesse projeto.
Vale ressaltar que apesar das técnicas de validação aqui discutidas serem um bom
indicativo de quão bem um modelo desempenhará sobre dados futuros, elas não garantem
que o modelo esteja correto. Elas apenas mostram que aplicados em dados similares, esses
modelos terão uma taxa de erro aproximada da taxa encontrada. É desejável então que
antes de utilizar o modelo em produção, testes sejam realizados no mundo real, pois, por
exemplo, casos representativos podem ter sido deixados de fora do processo de modelagem
ou o comportamento de alguma variável pode ter se alterado.
3.6 Avaliação e comparação de modelos
A capacidade de avaliar os modelos gerados é essencial para fazer progressos
concretos na tarefa de mineração. Dada a natureza iterativa e experimental do processo
de escolher os modelos e algoritmos para resolver um problema, é necessário um método
sistemático para avaliar a qualidade de cada modelo e poder compará-los para definir o
melhor. Os critérios para avaliação são medidas quantitativas de quão bem um padrão
(um modelo e seus parâmetros) atinge as metas do processo de KDD, sejam elas preditivas
ou descritivas (FAYYAD; PIATETSKY-SHAPIRO; SMYTH, 1996).

73. Capítulo 3. Mineração de dados 72
A avaliação de quão bem um modelo realiza uma tarefa de classificação se dá
pela contagem dos casos de teste preditos corretamente e incorretamente. Um modo fácil
de visualizar esses casos em detalhes é criando uma matriz de confusão (apresentada na
seção 3.3). Em um problema de classificação binário com as classes sim e não, as entradas
tabuladas na matriz de confusão (Tabela 11) tem os seguintes significados:
Tabela 11 – Matriz de confusão para um classificador binário com as classes sim e não
Classe predita
sim não
sim true positive false negative
Classe real
não false positive true negative
Fonte: Elaborado pelo autor
• True positive (TP): Elementos corretamente identificados.
• True negative (TN): Elementos corretamente rejeitados.
• False positive (FP): Elementos incorretamente preditos como sim (positivo), quando
na realidade são da classe não (negativo), também conhecido como erro tipo I.
• False negative (FN): Elementos incorretamente preditos como não (negativo), quando
na realidade são da classe sim (positivo), também conhecido como erro tipo II.
As classificações corretas se encontram então na diagonal principal, sendo a soma
de TP + TN. As incorretas são os casos fora dessa diagonal, dado pela soma de FP +
FN. Uma das vantagens de analisar os resultados com uma matriz de confusão é saber
exatamente a quantidade de erros de cada tipo cometidos pelo classificador, informação
essa que pode ser utilizada para realizar uma análise de custo, por exemplo. Geralmente,
para problemas extraídos do mundo real, cada erro possui um impacto diferente para o
problema sendo resolvido (WITTEN; FRANK; HALL, 2011).
3.6.1 Métricas de desempenho para classificadores
Apesar da matriz de confusão ser suficiente para demonstrar a qualidade de um
classificador, para tornar mais fácil a comparação entre diferentes modelos costuma-se
resumir essas informações em um único número, dado por uma das diversas métricas de
desempenho existentes (TAN; STEINBACH; KUMAR, 2006). Uma das mais comumente
utilizadas é accuracy9
:
𝐴𝑐𝑐𝑢𝑟𝑎𝑐𝑦 (𝐴𝐶𝐶) =
𝐶𝑜𝑟𝑟𝑒𝑡𝑎𝑠
𝑇 𝑜𝑡𝑎𝑙
=
𝑇 𝑃 + 𝑇 𝑁
𝑇 𝑃 + 𝑇 𝑁 + 𝐹 𝑃 + 𝐹 𝑁
(3.2)
9
Mantida em inglês para evitar confusão com a métrica precision, e em consequência, todas as medidas
assim o foram

74. Capítulo 3. Mineração de dados 73
Outra métrica comum é error rate (taxa de erro), que é 1 − accuracy, ou:
𝐸𝑟𝑟𝑜𝑟 𝑟𝑎𝑡𝑒 =
𝐼𝑛𝑐𝑜𝑟𝑟𝑒𝑡𝑎𝑠
𝑇 𝑜𝑡𝑎𝑙
=
𝐹 𝑃 + 𝐹 𝑁
𝑇 𝑃 + 𝑇 𝑁 + 𝐹 𝑃 + 𝐹 𝑁
(3.3)
Entretanto accuracy nem sempre é a melhor forma de avaliar um modelo. Conside-
rando por exemplo uma aplicação médica de um classificador para prever uma patologia
que se manifesta raramente, 99,9% dos casos serão negativos. Um modelo que simplesmente
classifique todas as intâncias como falsas terá uma accuracy extremamente alta de 99,9%,
apesar de ser inútil pois não revela nada sobre os 0,1% dos casos que interessam, que é
quando a patologia se manifesta. Esse é um problema comum em conjuntos de dados com
as classes desbalanceadas (GARCÍA; MOLLINEDA; SOTOCA, 2007), como é caso dos
dados de chutes a gol. É importante então considerar outras métricas10
. Métricas cujo
denominador envolve apenas casos que são de fato positivos:
𝑅𝑒𝑐𝑎𝑙𝑙 𝑜𝑢 𝑇 𝑟𝑢𝑒 𝑝𝑜𝑠𝑖𝑡𝑖𝑣𝑒 𝑟𝑎𝑡𝑒 (𝑇 𝑃 𝑅) =
𝑇 𝑃
𝑇 𝑃 + 𝐹 𝑁
(3.4)
𝐹 𝑎𝑙𝑠𝑒 𝑛𝑒𝑔𝑎𝑡𝑖𝑣𝑒 𝑟𝑎𝑡𝑒 (𝐹 𝑁 𝑅) =
𝐹 𝑁
𝑇 𝑃 + 𝐹 𝑁
(3.5)
True positive rate é também chamada de recall no domínio da recuperação de
informação ou sensitivity na medicina. A soma entre essas duas métricas é igual a 1.
Métricas cujo denominador envolve apenas casos que são de fato negativos:
𝑇 𝑟𝑢𝑒 𝑛𝑒𝑔𝑎𝑡𝑖𝑣𝑒 𝑟𝑎𝑡𝑒 (𝑇 𝑁 𝑅) =
𝑇 𝑁
𝑇 𝑁 + 𝐹 𝑃
(3.6)
𝐹 𝑎𝑙𝑠𝑒 𝑝𝑜𝑠𝑖𝑡𝑖𝑣𝑒 𝑟𝑎𝑡𝑒 (𝐹 𝑃 𝑅) =
𝐹 𝑃
𝑇 𝑁 + 𝐹 𝑃
(3.7)
True negative rate é também chamada de specificity (SPC) no domínio da medicina
e false positive rate é chamado de fall-out no domínio de recuperação de informação. A
soma entre essas duas métricas é igual a 1. Métricas cujo denominador envolve apenas
casos preditos como positivos:
𝑃 𝑟𝑒𝑐𝑖𝑠𝑖𝑜𝑛 𝑜𝑢 𝑃 𝑜𝑠𝑖𝑡𝑖𝑣𝑒 𝑝𝑟𝑒𝑑𝑖𝑐𝑡𝑖𝑣𝑒 𝑣𝑎𝑙𝑢𝑒 (𝑃 𝑃 𝑉 ) =
𝑇 𝑃
𝑇 𝑃 + 𝐹 𝑃
(3.8)
𝐹 𝑎𝑙𝑠𝑒 𝑑𝑖𝑠𝑐𝑜𝑣𝑒𝑟𝑦 𝑟𝑎𝑡𝑒 (𝐹 𝐷𝑅) =
𝐹 𝑃
𝑇 𝑃 + 𝐹 𝑃
(3.9)
10
Em (HARTEMINK, 2014) um simples e bom resumo foi encontrado

75. Capítulo 3. Mineração de dados 74
Positive predictive value é também chamado de precision no domínio de recuperação
de informação. A soma entre essas duas métricas é igual a 1. Métricas cujo denominador
envolve apenas casos preditos como negativos:
𝑁 𝑒𝑔𝑎𝑡𝑖𝑣𝑒 𝑝𝑟𝑒𝑑𝑖𝑐𝑡𝑖𝑣𝑒 𝑣𝑎𝑙𝑢𝑒 (𝑁 𝑃 𝑉 ) =
𝑇 𝑁
𝑇 𝑁 + 𝐹 𝑁
(3.10)
Em alguns contextos mais do que uma das métricas apresentadas são importantes,
sendo combinadas em uma nova métrica como é o caso das curvas ROC (Receiver operating
characteristic) e de F-measure. A primeira advém do contexto de detecção de sinais e
representa um balanço entre TPR (Equação 3.4) e FPR (Equação 3.7), enquanto a segunda
é mais utilizada no contexto de recuperação de informação e representa um balanço entre
recall (Equação 3.4) e precision (Equação 3.8).
Para a detecção de lances de chute a gol TN não é importante (seriam os não-
chutes, análogos aos documentos irrelevantes no contexto de recuperação de informação).
O que importa é que os lances verdadeiros de chute sejam identificados sem que pra isso
diversos lances falsos sejam incluídos como verdadeiros. Isso pode ser expresso através de
F-measure, que combina recall, que nos dá uma noção de completude (porcentagem de
lances corretamente identificados de todos os lances verdadeiros existentes), e precision,
que nos dá uma noção de qualidade (porcentagem de lances corretamente identificados
de todos os lances que foram preditos como verdadeiros). Por esses motivos F-measure
foi a métrica de desempenho escolhida para avaliar os modelos gerados nesse trabalho,
combinando simplicidade e expressividade.
Em mais detalhes, F-measure é a média harmônica entre recall e precision. Na
prática o resultado de sua aplicação é um novo valor que estará mais próximo da menor
medida entre recall e precision. Ela é dada pela seguinte equação (WITTEN; FRANK;
HALL, 2011):
𝐹 − 𝑚𝑒𝑎𝑠𝑢𝑟𝑒 (𝐹1) =
2 × 𝑟𝑒𝑐𝑎𝑙𝑙 × 𝑝𝑟𝑒𝑐𝑖𝑠𝑖𝑜𝑛
𝑟𝑒𝑐𝑎𝑙𝑙 + 𝑝𝑟𝑒𝑐𝑖𝑠𝑖𝑜𝑛
=
2 × 𝑇 𝑃
2 × 𝑇 𝑃 + 𝐹 𝑃 + 𝐹 𝑁
(3.11)
Existem diferentes versões de F-measure que podem ser utilizadas a depender do
peso que se queira dar para recall e precision. Por exemplo, em 𝐹2 o peso de recall é
dobrado enquanto em 𝐹0.5 é precision que tem o dobro do peso. 𝐹1 (apresentada acima)
foi escolhida pois no contexto da detecção de chutes a gol, em que se pretende utilizar os
classificadores criados para medir o desempenho das equipes, deixar de incluir um Shot on
target que aconteceu, por exemplo, afasta o analisador da visão do desempenho real do
time tanto quanto incluir um Shot on target inexistente.

76. Capítulo 3. Mineração de dados 75
3.6.2 F-measure para classificadores multiclasse
Recall, precision e consequentemente F-measure, são medidas para classificadores
binários. Entretanto, o classificador para chutes a gol que foi desenvolvido envolve 4 classes,
as 3 classes de chute definidas na seção 2.3 e uma classe falso, para os não-chutes. Todo caso
deve ser classificado em apenas uma classe, caracterizando o problema como multiclasse.
Uma forma para generalizar F-measure para um problema multiclasse é conhecida como a
abordagem um-contra-todos (One-vs-all, OvA), que avalia cada classe individualmente
contra todas as outras agrupadas.
A Tabela 12 mostra um exemplo de OvA para a primeira classe da matriz. Sobre
essa matriz adaptada é possível calcular precision, recall e F-measure para a classe 𝐶1.
O processo é repetido para cada classe e as métricas para cada uma são obtidas. Para
novamente ter uma única medida para o classificador como um todo, a média de F-measure
ponderada pelo número de casos verdadeiros em cada classe é calculada.
Tabela 12 – Matriz de confusão um-contra-todos para classe 𝐶1
Classe predita
𝐶1 𝐶2 𝐶3 ... 𝐶 𝑛
𝐶1 𝑇 𝑃 𝐹 𝑁 𝐹 𝑁 ... 𝐹 𝑁
𝐶2 𝐹 𝑃 𝑇 𝑁 𝑇 𝑁 ... 𝑇 𝑁
𝐶3 𝐹 𝑃 𝑇 𝑁 𝑇 𝑁 ... 𝑇 𝑁
... ... ... ... ... ...
Classe real
𝐶 𝑛 𝐹 𝑃 𝑇 𝑁 𝑇 𝑁 ... 𝑇 𝑁
Fonte: Elaborado pelo autor
Por fim, para definir de modo estatisticamente válido que um classificador é
superior a outro não basta apenas comparar diretamente os valores de suas métricas. É
preciso aplicar algum teste estatístico para fazer essa afirmação dentro de um intervalo
de confiança. Um exemplo é o corrected resampled T-Test que pode ser aplicado com o
auxílio da ferramenta WEKA (seção 3.7). Normalmente os testes são aplicados com uma
significância de 1% ou 5% (WITTEN; FRANK; HALL, 2011).
3.7 WEKA
O WEKA11
, criado na Universidade de Waikato na Nova Zelândia, foi a principal
ferramenta utilizada no projeto. Ele é um software open source desenvolvido em Java que
contém uma coleção de algoritmos de aprendizado de máquina no estado da arte e outras
ferramentas úteis para as diversas fases do projeto (WITTEN; FRANK; HALL, 2011). O
WEKA funciona independente de plataforma e é atualmente uma das ferramentas mais
utilizadas em projetos de mineração de dados, apesar de existirem outras opções populares
11
Disponível em <http://www.cs.waikato.ac.nz/ml/weka/>

77. Capítulo 3. Mineração de dados 76
como o R. Suas funcionalidades podem ser acessadas através de uma interface gráfica
intuitiva que facilita bastante o processo de mineração.
Essa interface possui 3 divisões. No Explorer, primeira delas, é possível testar
diferentes algoritmos de aprendizado nos dados carregados. Uma das limitações do Explorer
é que todos os dados são carregados na memória, limitando sua utilização a conjuntos
relativamente pequenos. Já na interface Knowledge Flow é possível conectar diferentes
algoritmos e fontes de dados, possibilitando o processamento de bases de dados maiores. A
última interface, Experimenter, permite que diferentes métodos sejam comparados dentro
da própria ferramenta, facilitando a escolha das soluções mais eficazes para o problema
sendo resolvido.
O Explorer possui uma aba voltada exclusivamente para classificação, onde os
algoritmos de aprendizado contidos no WEKA podem ser aplicados e os resultados obtidos
validados através de mecanismos como o 10-fold cross-validation estratificado (seção 3.5).
A matriz de confusão do classificador pode ser impressa, e o modelo pode ser analisado
de acordo com diferentes métricas de desempenho, e em alguns casos, como quando
trabalhando com árvores de decisão, é possível visualizar até mesmo o modelo gerado. A
Figura 19 mostra a interface do Explorer com a aba de classificação selecionada.
Figura 19 – Aba de classificação da ferramenta WEKA
Fonte: (Waikato University, 2013)
Segundo os criadores, os recursos mais valiosos do WEKA são as implementações
dos algoritmos de aprendizado, seguido de perto pelas ferramentas de pré-processamento
(chamadas de filters). Uma flexibilidade interessante é que os algoritmos utilizados no

78. Capítulo 3. Mineração de dados 77
WEKA podem também ser integrados em aplicações externas através das bibliotecas
fornecidas. A entrada dos dados (vetores de características resultante da fase de Preparação
dos Dados) para realizar a modelagem também é bastante flexível, podendo ser feita via
arquivos ARFF (Attribute-Relation File Format, desenvolvido para ser utilizado pelo
WEKA), CSV (comma-separated values) ou conexão com bancos de dados.
Nesse projeto o WEKA foi utilizado para auxiliar 5 importantes processos:
• Visualização dos dados: no Explorer existem 2 boas opções de visualização dos dados.
Na aba Preprocess é possível visualizar a distribuição das classes de acordo com cada
atributo e na aba Visualize é possível acessar a matriz scatterplot (seção 3.3) para
os dados de entrada;
• Filtragem: na aba Preprocess do Explorer é possível aplicar filtros para alterar os
dados de entrada, eliminar linhas, colunas e fazer outras modificações;
• Seleção de atributos: na aba Select attributes, ainda no Explorer, é possível aplicar
algoritmos de seleção automática de atributos;
• Experimentação: no Experimenter é possível realizar experimentações combinando di-
ferentes conjuntos de dados e algoritmos de modelagem de forma massiva, facilitando
a tarefa de testar diferentes cenários;
• Avaliação dos resultados: na aba Analyse do Experimenter os resultados dos experi-
mentos executados podem ser comparados utilizando diversas métricas de desempe-
nho (seção 3.6) e testes estatísticos.
Seus criadores escreveram um livro que além de ser uma referência sobre o processo
de mineração como um todo, cobre amplamente a utilização da ferramenta, é o Data
Mining: Practical Machine Learning Tools and Techniques (WITTEN; FRANK; HALL,
2011). A Universidade de Waikato oferece também o curso online Data Mining with WEKA
(WITTEN, 2013), ministrado por um dos autores do livro.

79. Parte II
Projeto

80. 79
4 Fase 1: Compreensão do problema
O projeto segue a metologia CRISP-DM e possui as 6 fases descritas na seção 3.1.
O restante da monografia descreve a execução de cada fase em um capítulo. A principal
tarefa da primeira fase é identificar claramente os objetivos do projeto. O primeiro passo foi
a compreensão do estado da arte na 2D em relação a coleta automatizada de estatísticas. A
tese de doutoramento de Abreu (2010) foi identificada como o principal trabalho relacionado
tanto por validar as estatísticas coletadas quanto por coletar diversas estatíticas sobre
cada partida.
A partir do trabalho de Abreu foi identificado que o principal risco para se construir
uma ferramenta de coleta de estatísticas robusta e completa seria conseguir extrair
conhecimento em lances ambíguos, caracterizados principalmente por altas chances de
disputa de bola e envolvimento de muitos jogadores numa pequena área do campo. Isso
foi demonstrado pelo baixo desempenho das heurísticas criadas em (ABREU, 2010) para
coletar os 3 tipos de chutes a gol definidos e pela análise que o próprio autor faz em
(ABREU et al., 2011). Os resultados de Abreu foram analisados na seção 1.4.
A partir da compreensão desse risco o Objetivo de Pesquisa (equivalente ao “Obje-
tivo de Negócio” na CRISP-DM) foi definido como: Investigar a viabilidade de construção
de uma ferramenta de coleta automatizada de estatísticas de alto nível para o ambiente
de futebol simulado Robocup 2D, utilizando técnicas clássicas de mineração de dados para
superar os problemas na detecção de métricas relacionadas a chutes a gol descritos na
literatura.
A partir desse objetivo foi verificada a viabilidade do projeto. O principal ponto
a ser checado era a disponibilidade de dados históricos que fossem representativos do
problema. Como todos os anos a Robocup promove um evento mundial onde as principais
equipes de pesquisa se encontram e disputam diversas partidas num torneio, e como todas
essas partidas são logadas pelo servidor, a escolha natural foi utilizar os logs do último
mundial (no caso, ocorrido entre junho e julho de 2013 em Eindhoven, Países Baixos)1
.
O mundial é uma excelente fonte por reunir os binários mais atualizados das equipes,
20 em 2013, gerando ao todo 180 partidas oficiais, garantindo 4,6 gigas de dados com muita
qualidade e diversidade. O mundial também é bom por ser uma fonte regular para novos
dados, característica importante para permitir atualizações dos modelos gerados. Por fim,
usar dados recentes de partidas reais das equipes participantes do mundial teve também a
intenção de levantar o interesse da comunidade científica envolvida pelos resultados da
1
O trabalho foi finalizado pouco antes do mundial de 2014 ocorrer, durante o mês de julho em João
Pessoa, Brasil

81. Capítulo 4. Fase 1: Compreensão do problema 80
pesquisa, já que ela permite insights sobre o desempenho de suas equipes.
Estudado o estado da arte na 2D (seção 1.4) e no futebol real (seção 2.2) foi definido
o Objetivo de Mineração: Desenvolver um classificador para as 3 métricas de chute a gol
definidas pela Opta, utilizando os logs da Simulação 2D da Robocup 2013, alcançando um
F-measure superior a 0,90. Esse objetivo foi definido por aproximar o grau de sucesso
na detecção de chutes a gol das outras métricas reportadas em (ABREU et al., 2011). A
Figura 20 dá uma visão geral do processo mostrando todas as etapas e transformações
ocorridas nos dados até se chegar aos classificadores desejados.
Figura 20 – Metodologia do projeto: dos dados aos resultados
Fonte: Elaborado pelo autor
Por fim, as ferramentas utilizadas no projeto também foram definidas nessa fase.
Diversos programas foram criados para realizar as transformações nos dados. Eles foram
codificados com a linguagem de programação C++ de modo a facilitar a reutilização de
bibliotecas relacionadas à Simulação 2D. Os programas foram criados utilizando a IDE
EclipseCDT versão Kepler Service Release 2, e compilados utilizando o GCC 4.7.3. para
o Linux/Ubuntu 13.04. Para criação de scripts foi utilizado o GNU Bash 4.2.45. Para

82. Capítulo 4. Fase 1: Compreensão do problema 81
armazenamento intermediário dos dados foi utilizado o PostgreSQL 9.3.4, assim como a
biblioteca libpqxx 4.0.1, que é um conector C++ para o PostgreSQL.
Os componentes da 2D utilizados para estudar o servidor, assistir partidas e
desenvolver os programas foram o rcssserver-15.2.2, rcsslogplayer-15.1.0 e a librcsc-4.1.02
.
Foram também utilizados trechos do código do time de Simulação 2D Bahia2D (baseado
no UvA Trilearn (BOER; KOK, 2002)), time desenvolvido pelo grupo de pesquisa ACSO3
.
A versão do WEKA, ferramenta de modelagem já apresentada na seção 3.7, foi a 3.6.11.
Para gerenciar a parte prática do projeto foi utilizada a ferramenta web Trello, para
gerenciar a pesquisa foi utilizado o Mendeley Desktop e para criar diagramas foi utilizada
a ferramenta web LucidChart.
2
Pode ser baixada em <http://pt.sourceforge.jp/projects/rctools/>
3
Time que o autor integrou de 2007 a 2010, conhecendo bem o código

83. 82
5 Fase 2: Compreensão dos dados
O principal objetivo dessa fase foi consolidar o conhecimento sobre o domínio
do problema, fundamental como mostra (FAYYAD; PIATETSKY-SHAPIRO; SMYTH,
1996):
Finally, and perhaps one of the most important considerations, is prior
knowledge. It is useful to know something about the domain —what are
the important fields, what are the likely relationships, what is the user
utility function, what patterns are already known, and so on.1
O passo que marcou a transição da primeira para a segunda fase foi a coleta dos
dados2
. A partir dos dados foram realizados dois processos: uma análise qualitativa a
partir da reprodução de partidas no LogPlayer, e a análise e descrição dos dados brutos.
Essas atividades serviram de entrada para o último processo dessa fase, a seleção do espaço
amostral. A Figura 21 esquematiza as atividades dessa fase.
Figura 21 – Fase 2: Compreensão dos dados
Fonte: Elaborado pelo autor
1
“Finalmente, e talvez uma das mais importantes considerações, é conhecimento prévio. É útil saber
algo sobre o domínio — quais são os campos importantes, quais são as relações prováveis, qual é a
função de utilidade do usuário, quais padrões já são conhecidos, e assim por diante.” (Tradução do
autor)
2
Os logs se encontram disponíveis em (ROBOCUP, 2013b), mas vale notar que o site estava fora do ar
na última checagem realizada, em 04 julho de 2014

84. Capítulo 5. Fase 2: Compreensão dos dados 83
5.1 Análise qualitativa dos logs
Para se familiarizar com os lances que seriam detectados, observar o estilo de chute
das diferentes equipes e compreender os cenários em que eles ocorrem foram selecionados
30 logs para serem assistidos através do LogPLayer. A seleção dos logs garantiu que seriam
assistidas partidas de todos os times contra equipes de diferentes níveis. Para isso os 20
times que participaram do mundial foram divididos em 3 categorias de acordo com as suas
posições finais no torneio3
(Tabela 13): fortes, médios e fracos.
Tabela 13 – Divisão dos times da Robocup 2013
Fortes Médios Fracos
1. WrightEagle 7. AUT 14. UTAustinVilla
2. HELIOS2013 8. Cyrus 15. GPR-2D
3. YuShan2013 9. GDUT_Tiji2013 16. WarthogRobotics
4. Axiom 10. FC-Perspolis 17. CSU_Yunlu2013
5. Gliders 11. LegenDary 18. ThunderBots
6. Oxsy 12. FCPortugal 19. HfutEngine2013
13. ITAndroids 20. Ri-one
Fonte: Elaborado pelo autor
A partir da observação dos jogos foi criado um documento descrevendo as equipes
e os chutes na Simulação 2D4
, destacando os jogos em que ocorriam chutes incomuns ou
de difícil detecção. Alguns detalhes que chamaram a atenção:
• Chutes para o gol usando o tackle são mais comuns do que se esperava;
• Chutes de longe (fora da área) são incomuns;
• Equipes fortes só chutam quando tem uma grande certeza do gol pois a ausência
da altura dificulta para os atacantes, mesmo com uma maior largura do gol (como
descrito na subseção 1.2.2.1);
• Entre os lances ambíguos os mais comuns são bolas divididas e passes que podem
ser considerados chutes;
• O modelo de chute da 2D, apesar dos ruídos inseridos, ainda cria um chute muito
mais preciso (que vai próximo de onde o jogador deseja) do que no futebol real.
5.2 Análise objetiva e descrição dos dados
Nessa etapa o ambiente da 2D foi estudado e o principal resultado desse processo é
a documentação detalhada no Capítulo 1. Dois acréscimos que podem ser feitos é sobre a
3
Disponível em <http://www.oliverobst.eu/research/robocup/rc2013-simleague-2d/>
4
Disponível em <http://bit.ly/AnaliseQualitativa>

85. Capítulo 5. Fase 2: Compreensão dos dados 84
organização dos dados e sobre quais as informações mais importantes disponíveis em cada
log. Sobre a organização, são 6 grupos principais de dados:
• Parâmetros do servidor: se relacionam a partida como um todo e inclui dados como
aceleração e velocidade máxima da bola, tempo de jogo, variações nas regras e
velocidade máxima dos jogadores;
• Parâmetros dos heterogêneos: delta de valores que originam os atributos dos jogadores
heterogêneos (subseção 1.2.2.5);
• Jogadores heterogêneos: conjunto dos atributos para os 18 jogadores heterogêneos
gerados para a partida;
• Bola a cada ciclo: velocidade e posição;
• Jogadores a cada ciclo: velocidade, posição, estado do jogador e outros dados;
• Dados sobre estado do jogo a cada ciclo: playmode, tempo e o placar.
Os parâmetros dos heterogêneos são um conjunto descartável, pois só importam
os heterogêneos que de fato foram gerados para cada partida. Todos os outros grupos
possuem informações importantes mas as principais para a detecção de chutes a gol são
posição e velocidade dos jogadores e da bola a cada ciclo, e a variável state dos jogadores.
A existência dessa última nos logs RCG foi fundamental para uma melhor detecção dos
lances, uma vez que entre seus registros está incluso, por exemplo, se um jogador chutou
ou deu carrinho. State é um número hexadecimal disponível todo ciclo para cada jogador
e que pode representar qualquer conjunto das seguintes situações:
• DISABLE = 0x00000000: jogador desconectado da partida;
• STAND = 0x00000001: jogador de pé;
• KICK = 0x00000002: jogador chutou no ciclo anterior;
• KICK_FAULT = 0x00000004: jogador chutou no ciclo anterior sem a bola estar em
sua área chutável;
• GOALIE = 0x00000008: jogador é goleiro;
• CATCH = 0x00000010: jogador agarrou a bola com a mão no ciclo anterior;
• CATCH_FAULT = 0x00000020: tentou agarrar com as mãos uma bola fora do seu
alcance no ciclo anterior;
• BALL_COLLIDE = 0x00000400: jogador colidiu com a bola no ciclo atual;

86. Capítulo 5. Fase 2: Compreensão dos dados 85
• PLAYER_COLLIDE = 0x00000800: jogador colidiu com outro jogador no ciclo
atual;
• TACKLE = 0x00001000: jogador está no chão após realizar um carrinho em algum
ciclo anterior;
• TACKLE_FAULT = 0x00002000: jogador está no chão pois executou um carrinho
sem sucesso em algum ciclo anterio;
• POST_COLLIDE = 0x00010000: jogador colidiu com alguma trave no ciclo atual;
• FOUL_CHARGED = 0x00020000: jogador está caído após receber um carrinho em
algum ciclo anterior;
• YELLOW_CARD = 0x00040000: jogador recebeu cartão amarelo;
• RED_CARD = 0x00080000: jogador recebeu cartão vermelho.
Importante notar que os lances que envolvem tackle não necessariamente ocorreram
no ciclo imediatamente anterior pois os jogadores ficam no mesmo estado por alguns
ciclos após a jogada, sendo necessário recorrer a contagem de comandos para determinar o
momento exato que um tackle foi executado.
Por fim, um padrão já estudado anteriormente foi resgatado, referente a velocidade
da bola em lances de chute do time Bahia2D. A Figura 22 mostra uma plotagem sobreposta
das velocidades da bola em chutes contra diferentes equipes (cores das barras). Esse estudo
deixou claro que em geral há uma diferença entre as velocidades da bola em cada tipo de
lance, com o primeiro pico (velocidades próximas de 0,0) representando domínios de bola,
o segundo pico (por volta de 0,5) representando conduções de bola e o último grupo (de 1,5
a 2,6, bem separado do resto por um pequeno vale destacado em vermelho) representando
chutes a gol e passes. Essa análise demonstrou o potencial de incluir velocidade da bola
logo após o toque de um jogador como característica importante para detectar chutes a
gol.
5.3 Seleção do espaço amostral
Reduzir o conjunto dos 180 jogos iniciais era fundamental para tornar viável a
classificação manual, processo da fase 3, Preparação dos Dados. A seleção do espaço
amostral seguiu a mesma ideia de cruzar todos os times contra adversários de força variada
utilizada para selecionar os jogos da análise qualitativa (seção 5.1). Entretanto, priorizou
a inclusão de jogos que já haviam sido assistidos e possuiam lances importantes. Esse
critério busca garantir que os mais diversos tipos de chute a gol estejam representados no
conjunto final. Os passos seguidos foram:

87. Capítulo 5. Fase 2: Compreensão dos dados 86
Figura 22 – Estudo sobre a velocidade da bola em chutes do time Bahia2D
Fonte: Elaborado pelo autor
1. Jogos marcados durante a análise qualitativa como importantes (por possuírem
lances difíceis ou raros) foram incluídos primeiro. 11 jogos pareados (em que os 2
times envolvidos ainda não tinham adversário com força correspondente) e 1 sem
par foram incluídos por esse critério;
2. Em seguida, foram acrescentados jogos de acordo com a disponibilidade, de modo
que o melhor time do grupo dos fortes enfrentasse o melhor time disponível de
cada grupo (Tabela 13), e assim sucessivamente até todos os jogos possíveis estarem
pareados. 16 jogos pareados foram escolhidos com esse critério;
3. Mais 5 jogos sem par foram adicionados para garantir que todos os times tivessem
pelo menos 1 adversário de cada grupo;
4. Jogos do Round 0 da competição, que é uma rodada de testes, foram evitados pois
os times poderiam não estar com o seu melhor binário. Houve apenas 1 exceção no
caso do time Ri-one, que só cruzou com um time do grupo dos fracos nesse Round;
5. Nos casos do passo 2 em que havia mais de um jogo entre um determinado par foi
dada preferência para jogos no Round do torneio que tinham menos jogos escolhidos
(o que ajudou a ter mais jogos das fases finais).
Esse processo resultou em um espaço amostral final com 33 jogos (27 pareados e 6
sem par), pouco mais do que 1/6 dos jogos disponíveis, e garantiu que todos os 20 times

88. Capítulo 5. Fase 2: Compreensão dos dados 87
fossem incluídos como fonte de dados em partidas com adversários de 3 níveis diferentes
(forte, médio e fraco). O Apêndice A informa quais os logs selecionados.

89. 88
6 Fase 3: Preparação dos dados
A seleção do espaço amostral marca a transição para essa fase. O principal objetivo
aqui foi gerar os vetores de características (conjunto de dados de tamanho fixo que
representam os casos de chute) a partir dos logs RCG selecionados. É a partir desses
vetores que os algoritmos de aprendizado constroem modelos que representam conhecimento
sobre os logs. Classificação é uma tarefa de aprendizado supervisionado, o que significa
que cada vetor de característica precisa ter sua classe determinada previamente, o que
também foi feito nessa fase.
Essa foi a etapa mais trabalhosa do projeto, o que é comum em processos de
KDD (Two Crows, 2005): “Data preparation is by far the most time-consuming aspect of
data mining. Everything a tool can do to ease this process will greatly expedite model
development”1
. As transformações realizadas nessa fase podem ser vistas na Figura 23. O
restante desse capítulo apresenta cada uma dessas transformações nos dados.
Figura 23 – Fase 3: Preparação dos dados
Fonte: Elaborado pelo autor
6.1 Carga do Repositório Intermediário
A primeira transformação nos dados foi sair do formato texto dos RCGs para uma
representação em banco de dados, mais estruturada e durável, para que os dados estivessem
1
“Preparação de dados é de longe o aspecto de mineração de dados que consome mais tempo. Tudo
que uma ferramenta puder fazer para facilitar esse processo irá acelerar bastante o desenvolvimento de
modelos.” (Tradução do autor)

90. Capítulo 6. Fase 3: Preparação dos dados 89
disponíveis e flexíveis para as etapas subsequentes. Para realizar essa transformação foi
criado o programa RCG2DB, que recebe um arquivo de log como parâmetro e o persiste
num banco com a estrutura mostrada na Figura 24. Apenas as principais colunas são
descritas nesse diagrama.
Figura 24 – Diagrama ER do Repositório Intermediário
Fonte: Elaborado pelo autor
Para criar o RCG2DB o código do LogPlayer foi estudado para que o mesmo parser
fosse reutilizado. Apesar do esforço empreendido, uma vez que há pouca documentação
disponível e boa parte dos exemplos estão desatualizados, fez-se questão de usar o mesmo
parser para minimar a possibilidade de inserir ruídos aos dados nessa etapa, uma vez que
os códigos das ferramentas oficiais já foram amplamente testados.
Para tratar os dados o LogPlayer possui uma classe Parser que trabalha em conjunto
com uma interface chamada Handler. O Parser é responsável por quebrar as entradas no log,
compor objetos que organizam esses dados e passá-los para o Handler. A implementação
concreta de Handler é que define o que será feito com os dados. No LogPlayer existem
algumas utilizações distintas de Handler, como para converter os logs de uma versão para
outra ou escrevê-lo em XML. O Diagrama de Classes do RCG2DB é visto na Figura 25,
as classes reutilizadas em amarelo.

91. Capítulo 6. Fase 3: Preparação dos dados 90
Figura 25 – Diagrama de Classes do RCG2DB
Fonte: Elaborado pelo autor
A classe PersistRCGHandler é a implementação concreta de Handler criada. Ela possui
uma referência para um objeto da classe Holder e para um objeto da classe Persister. Holder
recebe as informações do log a medida que elas vão sendo extraídas, sendo responsável
por manter em memória todos os dados do log. Após todo o arquivo de log ser lido,
uma referência de Holder é passada para o método persist, que se conecta ao banco e faz
o carregamento dos dados. Persister é uma interface genérica para tornar fácil a troca
do método de persistência. Nesse caso, PersistPostgresDB foi a implementação concreta
utilizada. Ela é uma classe que faz uso da biblioteca libpqxx para acessar o PostgreSQL.
Como RCG2DB só persiste 1 log de cada vez, foi criado um script em bash para
buscar todos os arquivos RCG numa árvore de diretórios e chamar o RCG2DB para cada
um. Apesar do espaço amostral já estar definido, decidiu-se por carregar todos os logs no
banco para qualquer eventualidade. O carregamento completo levou cerca de 3 horas para
ser finalizado. A tabela mais larga é tb_server_param com 193 colunas, e a mais extensa é
tb_player com 26.384.556 linhas2
.
6.2 Seleção de casos candidatos
Durante a maior parte de uma partida não estão ocorrendo chutes a gol. Isso
significa que a maior parte do log não interessa para o projeto. Para selecionar apenas os
lances de interesse foi criado o programa ShotCandidatesDetector. A principal preocupação
foi garantir que todos os lances possíveis de serem chutes a gol fossem incluídos, sem
exceções. A contrapartida é que a maior parte dos lances potenciais são na verdade falsos
candidatos. Isso foi tratado no pré-processamento da fase de modelagem (seção 7.1).
O princípio para identificar um chute a gol é o mesmo definido em (ABREU, 2010):
chutes dados no campo de ataque, na direção geral do gol (até o limite da grande área) e
2
Todo o código do RCG2DB, assim como os scripts bash e de criação do esquema do banco estão
disponíveis em <http://bit.ly/carregamentoRI>

92. Capítulo 6. Fase 3: Preparação dos dados 91
com força suficiente para cruzar a linha de fundo. Essa mesma definição geral é importante
para que os resultados alcançados possam ser comparados com os de Abreu. O Diagrama
de Classes do detector é mostrado na Figura 26.
Figura 26 – Diagrama de Classes do ShotCandidatesDetector
Fonte: Elaborado pelo autor
A classe RCGDAO é responsável por recuperar todos os dados de uma partida
e carregar num objeto da classe Holder. Esse objeto é passado para o método run do
DetectorManager que é responsável por invocar o método detect de todos os detectores
que tiverem sidos adicionados a ele. Isso permite que diferentes algoritmos de detecção
encapsulados através da interface Detector sejam executados sobre o mesmo log3
. Essa
flexibilidade foi criada pensando em futuras extensões da ferramenta, em que outros tipos
de eventos precisarão ser detectados.
ShotDetector encapsula o algoritmo de detecção de chutes. Ele varre os ciclos da
partida contida em Holder criando um objeto ShotCandidateT sempre que identifica um
candidato a chute a gol. Todos os candidatos são armazenados num vetor para que no fim
sejam impressos num arquivo CSV com o mesmo nome do log. Cada registro de candidato
impresso no CSV contém as informações: número do candidato, o time ofensivo (team_left
ou team_right), o ciclo de início, o ciclo final e o playmode em que o lance termina. O
pseudocódigo do método de detecção é descrito no Algoritmo 1.
O algoritmo checa os ciclos em ordem e aos pares para verificar as mudanças que
ocorreram entre duas cenas subsequentes. Basicamente ele checa por alguns critérios para
definir se um lance candidato começou e se terminou. Algumas observações:
3
Similar ao padrão de projeto Strategy, mas ao invés de intercambiar o algoritmo, todas as versões são
invocadas

93. Capítulo 6. Fase 3: Preparação dos dados 92
Algorithm 1 Algoritmo de seleção de candidatos
1: function Detect(ℎ𝑜𝑙𝑑𝑒𝑟) ◁ holder contém todos os ciclos da partida
2: 𝑐𝑎𝑛𝑑𝑖𝑑𝑎𝑡𝑜_𝑎𝑏𝑒𝑟𝑡𝑜 ← false
3: 𝑐𝐴𝑛𝑡 ← holder.primeiroCiclo() ◁ inicia ciclo anterior
4: for all Ciclo 𝑐𝐴𝑡𝑢 em holder do ◁ pega ciclo atual
5: if 𝑐𝑎𝑛𝑑𝑖𝑑𝑎𝑡𝑜_𝑎𝑏𝑒𝑟𝑡𝑜 then ◁ verifica se terminou lance
6: if mudouBola(𝑐𝐴𝑛𝑡, 𝑐𝐴𝑡𝑢) || mudouPlaymode(𝑐𝐴𝑛𝑡, 𝑐𝐴𝑡𝑢) then
7: registraCandidato()
8: 𝑐𝑎𝑛𝑑𝑖𝑑𝑎𝑡𝑜_𝑎𝑏𝑒𝑟𝑡𝑜 ← false
9: end if
10: end if
11: if !𝑐𝑎𝑛𝑑𝑖𝑑𝑎𝑡𝑜_𝑎𝑏𝑒𝑟𝑡𝑜 then ◁ verifica se abriu lance
12: if bolaRolando(𝑐𝐴𝑛𝑡) && mudouBola(𝑐𝐴𝑛𝑡, 𝑐𝐴𝑡𝑢) then
13: if bolaRolando(𝑐𝐴𝑡𝑢) then
14: if podeAlcançarLinhaDeChute(𝑐𝐴𝑛𝑡, 𝑐𝐴𝑡𝑢) then
15: 𝑐𝑎𝑛𝑑𝑖𝑑𝑎𝑡𝑜_𝑎𝑏𝑒𝑟𝑡𝑜 ← true ◁ caso normal, fecha depois
16: end if
17: else
18: if saiuPelaLinhaDeChute(𝑐𝐴𝑛𝑡, 𝑐𝐴𝑡𝑢) then
19: registraCandidato() ◁ caso especial, registra logo
20: end if
21: end if
22: end if
23: end if
24: 𝑐𝐴𝑛𝑡 ← 𝑐𝐴𝑡𝑢 ◁ atualiza ciclo anterior
25: end for
26: end function
• Um candidato sempre se inicia em lance de bola rolando (playmode igual play_on),
uma vez que não existe tiro livre direto ou penâlti no meio de uma partida na
Simulação 2D;
• O método mudouBola nas linhas 6 e 12 é um dos principais componentes. Ele verifica
se entre os ciclos houve alguma influência externa na posição ou velocidade da bola
considerando os ruídos naturais inseridos pelo servidor;
• Uma mudança no comportamento esperado da bola indica que ela passou por pelo
menos um dos seguintes eventos: kick, tackle, catch, colisão com jogador, colisão com
trave ou mudança de posição feita pelo juiz;
• No for, primeiro é checado o fechamento para depois ser checada a abertura pois um
evento que finaliza um lance candidato pode ser o mesmo evento que inicia outro;
• O método podeAlcançarLinhaDeChute projeta a bola ciclo a ciclo de acordo com as
equações de movimento do servidor apresentadas na subseção 1.2.2.2. Ele também
considera os ruídos inseridos de modo que a posição da bola é uma área e não um

94. Capítulo 6. Fase 3: Preparação dos dados 93
ponto. Se qualquer parte dessa área projetada a cada ciclo alcançar a linha de chute
(linha de fundo, entre os limites da grande área) o método retorna true;
• A linha 17 trata um caso especial. Uma particularidade descoberta sobre o servidor
é que ele não deixa a bola sair do campo (Figura 27). Se ele verifica que a bola vai
pra fora já reposiciona a bola para a jogada devida e altera o playmode. Por conta
disso pode ocorrer um lance em que um jogador próximo da linha de fundo envie
um comando de chute no ciclo 𝑡, e no ciclo 𝑡 + 1 a bola simplesmente já reapareça
reposicionada pelo servidor e com um novo playmode, sem a bola sequer aparecer
em alguma cena sobre o efeito desse chute;
• Esses casos especiais são os únicos em que um lance candidato pode durar apenas 2
ciclos, sendo aberto e fechado na mesma passagem pelo for. Nesses casos a verificação
de que a bola saiu pela linha de fundo é feita usando uma abordagem alternativa
de acordo com o playmode final do lance e posição da bola no ciclo anterior. Esses
lances com 2 ciclos também precisaram de tratamentos especiais em alguns processos
subsequentes;
• Para construção do detector de chutes foi utilizada a parte geométrica da librcsc4.1.0.
Figura 27 – Cenas subsequentes sem a bola fora: exemplo de candidato com 2 ciclos
(a) Ciclo 3976: Bola será chutada para fora (b) Ciclo 3977: Já aparece no tiro de meta
Fonte: Elaborado pelo autor
Para testar o algoritmo, 4 jogos completos foram checados lance a lance, além de
diversas visualizações ad hoc. Um script bash foi criado para a detecção ser realizada em
todos os 33 logs do espaço amostral. No total foram detectados 1488 candidatos, porém
lances que terminaram em impedimento ou falta foram pós-filtrados, pois as métricas de

95. Capítulo 6. Fase 3: Preparação dos dados 94
chute não devem ser contabilizadas nesses casos. Com 22 candidatos filtrados por esse
critério restaram 1466 candidatos, uma média de 44,42 por jogo4
.
Figura 28 – Lances e respectivas decisões do algoritmo de detecção de candidatos
(a) Cena de lance candidato (b) Cena de lance descartado
Fonte: Elaborado pelo autor (captura de tela)
6.3 Edição de logs
A tarefa de classificação manual é bastante custosa em tempo. Para torná-la mais
objetiva e permitir uma análise mais focada foi criado um editor de logs, chamado de
RCGCutter, para que apenas os trechos de interesse precisassem ser analisados. Ele corta
os logs reutilizando a classe Serializer que é usada pelo servidor para gerar os logs. Cada
lance é cortado de acordo com os ciclos iniciais e finais presentes nos arquivos CSV gerados
na seleção de candidatos, mais uma quantidade parametrizável de ciclos extras que ajudam
na compreensão do contexto em que o lance ocorreu. A Figura 29 mostra o Diagrama de
Classes do RCGCutter, o componente reutilizado em amarelo.
A classe RCGCutter recebe um ostream que é o novo arquivo de log que deve gerar,
um istream que é o arquivo CSV com os candidatos e um int que é a quantidade de ciclos
extras. As informações do log são recuperadas em um objeto Holder e passadas para ele
através do método cutRCG que restaura os candidatos e gera um novo log editado com
auxílio do RCGSerializerV5, objeto que compõe RCGCutter. Para editar todos os logs foi
novamente utilizado um script bash. A saída desse processo são os 33 arquivos de log do
espaço amostral devidamente editados5
.
4
O código do ShotCandidatesDetector, o script em bash e todos os 33 arquivos CSV gerados se
encontram disponíveis em <http://bit.ly/DeteccaoCandidatos>
5
O código do RCGCutter, assim como o script bash e todos os logs editados se encontram disponíveis
em <http://bit.ly/EdicaoLogs>

96. Capítulo 6. Fase 3: Preparação dos dados 95
Figura 29 – Diagrama de Classes do RCGCutter
Fonte: Elaborado pelo autor
6.4 Classificação manual
A partir dos logs editados e dos arquivos CSV com os lances candidatos, os 1466
lances foram analisados cuidadosamente e classificados manualmente. A classificação foi
realizada pelo próprio autor, que trabalhou durante 4 anos com o time de simulação
Bahia2D, participando de 2 mundiais e 4 competições nacionais, acumulando experiência
sobre o domínio do problema. Essa é uma alternativa comum em casos de aprendizado
supervisionado (Two Crows, 2005): “Sometimes an expert classifies a sample of the database,
and this classification is then used to create the model which will be applied to the entire
database”6
.
Além dos 3 tipos de chute, os falsos candidatos também receberam uma classificação
mais específica do que apenas “falso” (como domínio de bola, passe em enfiada), de modo
a criar uma melhor compreensão sobre os não-chutes e entender como diferenciá-los. Para
classificar os lances os logs editados foram assistidos no LogPlayer e a classe de cada
candidato foi anotada no próprio CSV (Figura 30). As funções do LogPlayer de projetar a
bola, de mostrar os comandos enviados pelos agentes e de permitir assistir ao log ciclo a
ciclo foram muito úteis no processo.
Ao final, para minimizar os ruídos inseridos no processo e aumentar a consistência
da classificação (lances similares serem avaliados seguindo os mesmos critérios), toda
a classificação foi revisada. Isso foi especialmente importante nos lances ambíguos, por
exemplo, passes fortes em direção ao gol e bolas divididas. Informações sobre os 1466
lances classificados são resumidas na Tabela 147
.
Dos 293 lances de chute, 74% foram Shot on target, 13,7% foram Blocked shot e
12,3% foram Shot off target. Uma comparação com as classes similares da classificação
manual em (ABREU et al., 2011) (20,7%, 45,2% e 33,1% respectivamente, dados na
6
“Algumas vezes um especialista classifica uma amostra do banco de dados, e essa classificação é então
usada para criar o modelo que será aplicado no banco de dados inteiro” (Tradução do autor)
7
O mapeamento completo pode ser acessado em <http://bit.ly/MapeamentoClassificacaoManual>

97. Capítulo 6. Fase 3: Preparação dos dados 96
Figura 30 – Lance de Shot on target sendo visualizado e classificado
Fonte: Elaborado pelo autor (captura de tela)
Tabela 14 – Resumo dos casos na classificação manual
Classe Total Média
Positivos
Shot on target 217 6,58
Blocked shot 40 1,21
Shot off target 36 1,09
Métricas derivadas
Goals 169 5,12
Chance conversion - 0,66
Shooting accuracy - 0,85
Negativos mais comuns
Condução de bola 488 14,79
Domínio de bola 191 5,79
Passe direto 128 3,88
Resumo
Positivos 293 8,88
Negativos 1173 35,55
Total 1466 44,42
Fonte: Elaborado pelo autor
Tabela 7) ressaltam as diferenças entre a definição utilizada por Abreu e a da Opta,
apontadas na seção 2.3. Por exemplo, enquanto aqui bolas defendidas pelo goleiro (lance
comum) são Shot on target, em Abreu elas são Intercepted shot, explicando em parte a
maior quantidade de Shot on target encontrados aqui8
.
8
Em <http://bit.ly/CandidatosClassificados> estão disponíveis os 33 arquivos CSV com os candidatos
classificados

98. Capítulo 6. Fase 3: Preparação dos dados 97
6.5 Engenharia de características
A última etapa antes de iniciar a modelagem é construir o vetor de características
sobre os quais os algoritmos de aprendizado supervisionado criam os modelos. Ele é um
vetor de tamanho fixo com N atributos que representam um objeto, no caso, os candidatos
a chute. O principal desafio dessa etapa foi definir chutes a gol, que podem ser lances com
variadas configurações e diferentes durações (de 2 a 50 ciclos), em termos de um conjunto
fixo de atributos.
Além disso os dados originais não representam nada diretamente em termos de
chutes a gol, sequer existe a informação de onde fica o gol nos dados do log. Essas relações
mais representativas precisaram ser derivadas dos dados originais. Conhecimento sobre o
domínio do problema foi utilizado para realizar a seleção e extração das características.
Esses processos são fundamentais também por reduzir a dimensionalidade do problema,
uma vez que os dados dos logs possuem muitas colunas e registros, grande parte irrelevante.
(FAYYAD; PIATETSKY-SHAPIRO; SMYTH, 1996) sobre alta dimensionadidade:
A high-dimensional data set creates problems in terms of increasing the
size of the search space for model induction in a combinatorially explosive
manner. In addition, it increases the chances that a data-mining algorithm
will find spurious patterns that are not valid in general. Approaches to
this problem include methods to reduce the effective dimensionality of the
problem and the use of prior knowledge to identify irrelevant variables.9
6.5.1 Seleção de características
Durante a criação do algoritmo de detecção de candidatos e a realização da
classificação manual aconteceram os insights sobre como transformar os candidatos em
um vetor n-dimensional. Apesar das diferentes durações de um chute a gol, os pontos mais
importantes de um chute são sempre o início e o fim. As movimentações que acontecem
enquanto a bola se desloca e ninguém a toca podem ser representadas pelas diferenças
entre a cena inicial e final.
Entretanto, como visto na seção 6.2, para capturar todos os detalhes de um toque
na bola é importante analisar 2 cenas subsequentes: numa cena a bola está parada e
um agente vai executar um comando que influencia a bola, na cena seguinte vemos o
deslocamento e velocidade da bola em consequência desse comando. Para cada candidato
foram então selecionadas 2 cenas iniciais e 2 cenas finais:
1. PreKick: cena em que será dado o chute que inicia o candidato (Figura 31a);
9
“Um conjunto de dados com muitas dimensões cria problemas em termos do aumento do espaço de
busca para induzir o modelo de um modo exponencial. Além disso, aumenta as chances de que o
algoritmo de mineração de dados encontre falsos padrões que não são válidos em geral. Abordagens
para esse problema incluem métodos para reduzir as dimensões efetivas do problema e o uso de
conhecimento prévio para identificar variáveis irrelevantes.” (Tradução do autor)

99. Capítulo 6. Fase 3: Preparação dos dados 98
2. InitKick: primeira cena com a bola em movimento em consequência do preKick
(Figura 31b);
3. LastKick: última cena em que bola se desloca em consequência do preKick (Figura
31c);
4. PostKick: primeira cena após o final do chute, exemplos são a bola se deslocando em
outra direção ou já posicionada para um escanteio (Figura 31d).
Figura 31 – Exemplo das 4 cenas selecionadas em um caso de Shot on target10
(a) PreKick: ciclo 136 (b) InitKick: ciclo 137
(c) LastKick: ciclo 139 (d) PostKick: ciclo 140
Fonte: Elaborado pelo autor
O fato de que o servidor não mostra a bola fora de campo, problema descrito na
seção 6.2, atrapalharia a seleção de cenas, pois nos casos em que isso ocorre o LastKick
não representaria o limite do deslocamento da bola. Um lance que termina em escanteio,
por exemplo, teria como LastKick uma cena em que a bola está dentro de campo. Para
10
O exemplo caracteriza um Shot on target e não Blocked shot pois a bola é bloqueada pelo último
defensor

100. Capítulo 6. Fase 3: Preparação dos dados 99
corrigir essa incongruência os lances que envolviam bola fora foram tratados durante a
seleção de características, com a cena com a bola fora sendo adicionada artificialmente.
Para isso o movimento da bola foi simulado de acordo com a última cena em que ela está
em campo, e o movimento dos jogadores de acordo com o movimento que eles realizaram
no ciclo posterior a saída da bola.
Com esse tratamento, candidatos cuja duração era de apenas 2 ciclos (justamente
casos que envolviam a saída da bola, como mostrado na seção 6.2) passaram a durar 3
ciclos. Para candidatos com 3 ciclos, InitKick e LastKick são as mesmas cenas. Todos os
dados contidos nos logs relacionados às 4 cenas descritas para cada um dos 1466 candidatos
foram selecionados e passados para a extração.
6.5.2 Extração de características
A partir das 4 cenas selecionadas para cada candidato e das informações sobre
as flags do campo (Figura 5), 20 características (nominais e numéricas) foram extraídas
para representar chutes a gol. Algumas delas envolvem conhecimento detalhado sobre o
funcionamento do servidor e cálculos geométricos. As numéricas foram:
1. Vel_ball_inK: Velocidade da bola na cena initKick;
2. Dist_ball_prK: Distância da bola pro gol no preKick;
3. Dist_ball_laK: Distância da bola pro gol no lastKick;
4. Diff_dist_prLaK: A diferença entre as distâncias;
5. Ang_goal_prK: O ângulo de abertura entre a bola e as duas traves no preKick;
6. Ang_goal_laK: O ângulo de abertura entra a bola e as duas traves no lastKick. 0
caso tenha entrado no gol, 180 caso tenha saído do campo;
7. Diff_ang_prLaK: A diferença entre os ângulos;
8. Cycles_prInK: Quantos ciclos a bola levaria para cruzar a linha de fundo a partir
do preKick;
9. Cycles_laK: Quantos ciclos faltavam para a bola cruzar a linha de fundo no lastKick.
0 no caso de já ter cruzado;
10. Goal_line_Y: Valor absoluto do Y do ponto onde a projeção da bola a partir do
initKick cruzaria a linha de fundo;
11. Off_power_prInK: Qual bem posicionado para chutar forte estava o atacante que
deu o principal toque na bola no preKick, dado pela Equação 1.6 e Equação 1.7;

101. Capítulo 6. Fase 3: Preparação dos dados 100
12. Off_bodyG_prInK: Quão bem posicionado para chutar no gol estava o atacante que
deu o principal toque na bola no preKick, dado pelo ângulo do corpo do atacante
para o centro do gol;
13. Def_power_laPoK: Quão bem posicionado para chutar forte estava o defensor no
lastKick, dado pela Equação 1.6 e Equação 1.7, ou 3,0 caso o goleiro possa fazer um
catch.
E as nominais foram:
1. On_ball_prK: Quem poderia influenciar a bola no preKick (attack, both, defense ou
none);
2. Touched_prInK: Quem de fato tocou a bola no preKick (attack, both, defense ou
none);
3. Off_touch_prInK: Qual o principal toque dado pelo time atacante no início do lance
(kick, none, tackle);
4. On_ball_laK: Quem poderia influenciar a bola no lastKick (attack, both, defense ou
none);
5. Touched_laPoK: Quem de fato tocou a bola no lastKick (attack, both, defense ou
none);
6. Def_touch_laPoK: Toque dado pelo defensor para terminar um chute (none, tackle,
kick, collision ou catch);
7. Pmode_poK: Playmode no postKick (goal, play_on, corner_kick, free_kick, goal_kick
ou back_pass).
O fato de existirem características nominais e numéricas restringe a possibilidade
de aplicação de alguns algoritmos do WEKA. O último passo é adicionar as classes
identificadas na avaliação manual para cada vetor. Basicamente as 3 classes de chute a
gol foram repassadas sem alteração, enquanto todas as outras classes receberam o rótulo
“falso”. Um arquivo CSV único com os 1466 vetores de características foi gerado nesse
processo11
.
11
O CSV com os vetores pode ser baixado em <http://bit.ly/VetoresDeCaracteristicasFinal>

102. Capítulo 6. Fase 3: Preparação dos dados 101
6.5.3 Criação do vetor de características
Para implementar a seleção e extração de características foi criado o programa
FeatureSE. Ele recebe como parâmetro o arquivo com candidatos a chute e o arquivo onde
deve escrever os vetores finais. O código do Bahia2D foi transformado numa biblioteca
estática para que a parte geométrica fosse reutilizada. Alguns componentes de geometria
da librcsc4.1.0 também foram utilizados. A Figura 32 mostra o Diagrama de Classes do
FeatureSE.
Figura 32 – Diagrama de Classes do FeatureSE
Fonte: Elaborado pelo autor
Novamente RCGDAO restaura os dados de um log num objeto da classe Holder.
Esse objeto é passado para LocalWorldModel, uma classe com diversos métodos utilitários
para realizar cálculos geométricos, fazer projeções e cálculos relacionados ao funcionamento
do servidor. LocalWorldModel é composto por WorldModel, classe reutilizada do Bahia2D,
que possui também alguns métodos geométricos. FeatureSelector é a classe que faz a
seleção dos dados nas cenas e FeatureExtractor a derivação das características finais.
Ambas possuem uma referência para o mesmo LocalWorldModel.
FeatureSelector usa LocalWorldModel para fazer os tratamento de bolas fora,
criando as cenas extras a partir das cenas originais. Já FeatureExtractor o utiliza para boa
parte das derivações de atributos. CsvIO é responsável por ler o arquivo de candidatos e
escrever o vetor de características final. FeatureSelector é composto por SelectedFeaturesT,

103. Capítulo 6. Fase 3: Preparação dos dados 102
estrutura que guarda os dados sobre os candidatos e as 4 cenas: preKick, initKick, lastKick
e postKick. FeatureSelector cria novos SelectedFeaturesT a medida que vai tratando todos
os candidatos que recebe de CsvIO.
Depois de todos os dados estarem selecionados e armazenados em um vetor de
SelectedFeaturesT pelo FeatureSelector, eles são passados para o FeatureExtractor, que
deriva as características finais e as guarda num vetor de vetores de strings. Por fim o
CsvIO recebe as strings com as características finais do FeatureExtractor e as acrescenta
no final do arquivo definido. O Diagrama de Sequência na Figura 33 mostra as interações
entre os objetos principais do FeatureSE. Para realizar a seleção e extração para os 33 logs
foi criado um script bash que lê todos os arquivos de candidatos numa pasta e chama o
FeatureSE para cada um deles passando o mesmo arquivo de saída (onde os vetores finais
vão sendo armazenados)12
.
Figura 33 – Diagrama de Sequência mostrando as interações principais do FeatureSE
Fonte: Elaborado pelo autor
12
O código do FeatureSE e o script de carregamento estão disponíveis em <http://bit.ly/FeatureSE>

104. 103
7 Fase 4: Modelagem
Essa é a fase em que propriamente ocorre o que é tecnicamente chamado de
mineração de dados ou modelagem. Antes ainda, entretanto, os dados passam por alguns
pré-processamentos. A Figura 34 mostra as transformações que ocorrem nos dados nessa
etapa. Além dessas transformações existe também a visualização e exploração dos vetores
de características, que é a primeira atividade desta fase, parte do pré-processamento.
Figura 34 – Fase 4: Modelagem
Fonte: Elaborado pelo autor
7.1 Pré-processamento
Antes dos algoritmos de aprendizado serem aplicados sobre os dados, uma última
etapa de checagem da qualidade dos dados é realizada. Os dados produzidos na fase de
Preparação dos Dados são analisados em busca de ruídos, dados discrepantes (outliers),
irrelevantes ou redundantes. Tudo para um melhor resultado quando a modelagem for
realizada. Esse processo é conhecido como pré-processamento e foi inteiramente realizado
com o auxílio da ferramenta WEKA.
7.1.1 Visualização e exploração dos dados
A visualização permite aprofundar o conhecimento sobre os dados para tomar
decisões sobre filtragem e seleção de atributos. O primeiro passo da visualização é analisar
o resumo dos dados. Ele é criado automaticamente pelo WEKA na aba Preprocess ao
importar o CSV com os dados. Para os valores numéricos é possível ver o mínimo, máximo,

105. Capítulo 7. Fase 4: Modelagem 104
média e desvio padrão de cada característica (Tabela 15). Para os valores nominais é
possível ver os totais de cada tipo.
Tabela 15 – Resumo das características numéricas
Característica Mínimo Máximo Média Desvio padrão
Vel_ball_inK 0,099 3,126 1,521 0,904
Dist_ball_prK 0,634 51,423 14,384 7,381
Dist_ball_laK 0,0 39,983 9,821 6,477
Diff_dist_prLaK -11,091 36,983 4,564 5,083
Ang_goal_prK 0,278 160,68 29,751 26,002
Ang_goal_laK 0,0 180,0 45,99 57,61
Diff_ang_prLaK -125,389 158,942 16,239 43,093
Cycles_prInK 1 51 18,762 14,766
Cycles_laK 0 51 14,869 15,359
Goal_lineY_inK 0,007 48,963 11,012 6,369
Off_power_prInK 0,0 2,7 1,928 0,744
Off_bodyG_prInK -100,0 175,172 26,862 57,124
Def_power_laPoK 0,0 3,0 0,538 1,011
Fonte: Elaborado pelo autor
Uma parte valiosa da visualização fornecida pelo WEKA é a distribuição das classes
de chute a gol para cada característica. Os dados sobre velocidade (Figura 36a), por
exemplo, mostram que a menor velocidade que indica um chute a gol é por volta de 1,6,
confirmando a expectativa criada pelo estudo anterior apresentado na Figura 22. Um
grande volume de falsos se acumulam em lances de bola com baixa velocidade, prováveis
conduções e domínios de bola, tornando velocidade um atributo interessante para identificar
falsos candidatos.
Figura 35 – Totais das classes finais
Fonte: Elaborado pelo autor
O ângulo final para as traves (Figura 36b) também se mostrou um atributo interes-
sante, fazendo uma separação razoável entre Shot on target e Blocked shot, que é um caso
difícil. Como bolas bloqueadas geralmente terminam mais longe do gol, consequentemente

106. Capítulo 7. Fase 4: Modelagem 105
Figura 36 – Distribuição das classes por algumas características
(a) Distribuição em função da velocidade
(b) Distribuição em função da ângulo final para as traves
(c) Distribuição em função do posicionamento do atacante
Fonte: Elaborado pelo autor
é comum terem ângulos mais fechados. Ele separa bem também os Shot off target dos
outros chutes, pois em chutes para fora o ângulo pro gol fica completamente fechado no
final (exceto nos casos de bola na trave, que aparecem como uma linha muito fina nas
colunas com 13 e 14 ocorrências, em destaque).
A visualização permitiu também perceber que algumas das características finais
pouco dizem sobre chutes a gol. O ângulo do corpo do atacante em relação ao centro do

107. Capítulo 7. Fase 4: Modelagem 106
gol, por exemplo, que se esperava influenciar pois denota um atacante melhor posicionado,
apresenta proporcionalmente a mesma distribuição de classes independente do ângulo
(Figura 36c). Isso se deve ao modelo de chute na 2D, em que a força do chute só depende
da posição da bola em relação ao atacante (Equação 1.6) e não da direção final do chute,
permitindo chutes fortes e precisos mesmo com o atacante de costas para o gol.
Outra forma interessante de visualizar os dados provida pelo WEKA é a matriz
scatterplot (exemplo com dados de chutes a gol na Figura 16), que permite perceber
correlações entre variáveis. Porém, tirando correlações óbvias como entre os atributos de
ângulo inicial e final, ou entre os atributos de distância inicial e final, não foram feitas
grandes descobertas. Um dos gráficos mais interessantes da matriz, por separar todos os
grupos relativamente bem e mostrar uma correlação entre ângulo e distância, pode ser
visto na Figura 37. A visualização garantiu também que os totais para cada classe estavam
corretos, evitando ruídos nos dados por conta de erros de digitação.
Figura 37 – Diferença dos ângulos para as traves x Distância da bola para o gol no lastKick
Fonte: Elaborado pelo autor
7.1.2 Filtragem
A partir da visualização alguns filtros foram aplicados no WEKA, ainda na aba
Preprocess do Explorer. Os filtros no WEKA são muito poderosos, permitindo que diversas
transformações sejam realizadas. Entretanto o único filtro necessário foi o RemoveWithVa-
lues, que permite remover casos específicos a partir de valores de alguma característica.

108. Capítulo 7. Fase 4: Modelagem 107
Primeiro os dados discrepantes foram verificados caso a caso. Apenas 1 problema foi
confirmado, um caso em que nenhum jogador estava na bola na cena inicial (On_ball_prK
igual a none). O lance é um caso raro em consequência do tratamento para o caso especial
do algoritmo de seleção de candidatos (Algoritmo 1, linha 17), em que a bola acaba saindo
dentro do limite da grande área devido ao ruído do servidor, após um chute inicial em
que ela iria sair em um ponto mais distante. Havia sido observado na análise manual, mas
acabou não sendo limpo anteriormente.
Pela Figura 35 é possível notar como os dados finais eram desbalanceados, com
a grande maioria dos casos sendo da classe falso. Analisando os dados percebeu-se que
diversos dos casos falsos poderiam ser eliminados usando alguns valores das variáveis
nominais que continham apenas casos falsos. São eles:
1. Bolas cujo toque inicial é dado apenas por algum defensor (Touched_prInK igual a
defense), casos de recuos de bola e passes para trás;
2. Bolas cujo toque final é dado por algum atacante (Touched_laPoK igual a attack),
casos de condução de bola, por exemplo, que o atacante toca e vai atrás da bola
para tocar novamente;
3. Cena final com a bola está dividida (On_ball_laK igual a both), por exemplo, casos
de passe que o receptor recebe sob pressão.
O segundo caso representou a principal filtragem. É possível ver o grande volume
de casos falsos separados por essa variável na Figura 38. Essas 3 filtragens identificados
poderão futuramente já serem realizadas na etapa de seleção de candidatos, a partir de
melhorias no algoritmo de detecção. Isso não foi feito devido ao conhecimento incompleto
que se tinha sobre o dado state contido nos logs (que mostra o estado dos jogadores,
discutido na seção 5.2) durante a criação do algoritmo de detecção de candidatos.
As filtragens eliminaram 1060 casos falsos, deixando 406 candidatos num conjunto
de dados muito mais balanceado (Figura 39).
7.1.3 Seleção de atributos
Enquanto na filtragem casos inteiros foram eliminados (linhas), na seleção de
atributos o objetivo foi criar algumas variações de conjuntos de dados a partir da eliminação
de algumas características (colunas). Ao todo foram criadas 9 variações em cima do conjunto
com 406 casos e 20 características. 2 delas foram criadas utilizando conhecimento sobre
o domínio do problema e as observações feitas na exploração dos dados. Outras 7 foram
criadas aplicando algoritmos de seleção automática que compõe a ferramenta de seleção
de atributos do WEKA (na aba Select Attributes do Explorer).

109. Capítulo 7. Fase 4: Modelagem 108
Figura 38 – Exemplo de casos filtrados
Fonte: Elaborado pelo autor
Figura 39 – Conjunto final mais balanceado após filtragens
Fonte: Elaborado pelo autor
Para o primeiro caso criado usando conhecimento sobre o domínio a abordagem foi
eliminar os piores atributos, aqueles que demonstraram representar pouco sobre chutes a
gol ou que após a filtragem fariam pouco sentido em serem mantidos. Foram eliminadas 8
características segundo esse critério. A segunda abordagem foi apenas deixar os melhores
atributos, onde os 7 que foram considerados mais representativos foram mantidos.
Para as abordagens automáticas foram testados os algoritmos de avaliação de
subconjunto Cfs e Consistency (com o método de busca exhaustive), e os algoritmos de
avaliação de atributos individuais InfoGain, GainRaio, OneR, Relief e Symmetrical (com
método de busca ranked). Mais sobre os métodos de seleção de atributos disponíveis no
WEKA em (WITTEN; FRANK; HALL, 2011).
A Tabela 16 apresenta os atributos escolhidos nas abordagens que tiveram mais

110. Capítulo 7. Fase 4: Modelagem 109
sucesso (conjuntos sobre os quais foram gerados modelos com as maiores médias ponderadas
para F-measure). Os atributos escolhidos estão marcados com ’x’ ou com o número que
representa sua posição quando o método de busca ranked foi utilizado. Esse processo
produziu 10 arquivos ARFF1
com variações de conjuntos de dados para serem testados
durante a modelagem.
Tabela 16 – Variações nas características finais
Original Sem piores Só melhores Consistency InfoGain Symmetrical
Vel_bal_inK x
Dist_ball_prK x x
Dist_ball_laK x x x 2 2
Diff_dist_prLaK x
Ang_goal_prK x 10 8
Ang_goal_laK x x 1 1
Diff_ang_prLaK x x 3 3
Cycles_prInK x x x 7 7
Cycles_laK x x 5 5
Goal_lineY_InK x x 6 6
On_ball_prK x
Touched_prInK
Off_touch_prInK
Off_power_prInK
Off_bodyG_prInK
On_ball_laK
Touched_laPoK x
Def_touch_laPoK x x x 8 10
Def_power_laPoK 9 9
Pmode_poK x x x 4 4
Fonte: Elaborado pelo autor
7.2 Modelagem
A modelagem começou com a realização de alguns simples testes no Explorer do
WEKA para ter as primeiras noções sobre a qualidade dos modelos que poderiam ser
gerados. Existia uma grande expectativa sobre a etapa de modelagem mas ela acabou
se revelando anticlimática, pois logo nos primeiros testes alguns resultados promissores
apareceram, já acima do baseline de Abreu. De todo modo, testes mais organizados foram
realizados para se obter um resultado mais consistente. Foi o momento de sair do Explorer
do WEKA e partir para o Experimenter (onde experimentações massivas podem ser
realizadas). Configurar um experimento no WEKA consiste basicamente de 5 passos:
1. Definir um arquivo onde as informações sobre o processo serão salvas, essas informa-
ções são a base para análise dos resultados;
2. Carregar os conjuntos de dados que serão utilizados;
1
Arquivos ARFF disponíveis em <http://bit.ly/VariacoesDeDatasets>

111. Capítulo 7. Fase 4: Modelagem 110
3. Definir o tipo de experimento, o que está relacionado ao método de validação;
4. Definir quantas iterações serão realizadas, importante para diminuir a variância e se
obter um resultado mais confiável;
5. Escolher os algoritmos (e seus parâmetros) que serão aplicados.
Os dados foram os 10 conjuntos preparados no pré-processamento (arquivos ARFF).
O tipo de experimento foi 10-fold cross-validation, que na seção 3.5 foi definido como
método mais adequado, principalmente por permitir utilizar todos os dados disponíveis
para criar o modelo. O número de iterações escolhido foi 10, suficiente segundo (WITTEN;
FRANK; HALL, 2011).
Sobre os algoritmos, viu-se mais de uma vez na literatura que é difícil definir essa
escolha sem experiência prévia, como em (FAYYAD; PIATETSKY-SHAPIRO; SMYTH,
1996): “Thus, there is no universal data mining method, and choosing a particular algorithm
for a particular application is something of an art”2
. Ou em (WITTEN; FRANK; HALL,
2011): “Which methods and parameter values work best for the given problem? There
is usually no way to answer this question a priori”3
. Ou ainda em (Two Crows, 2005):
“You may not be able to determine which model type is best until you’ve tried several
approaches” 4
.
Por conta disso, na ausência de um método que pudesse guiar alguém menos
experiente na área, e dada a possibilidade criada pelo WEKA de aplicar facilmente
diferentes algoritmos e ver na prática os seus resultados concretos, uma abordagem
empírica foi escolhida. Todos os algoritmos disponíveis no WEKA que eram aplicáveis ao
problema foram selecionados para serem testados, totalizando 44 algoritmos, divididos em
7 categorias: árvores, regras, funções, lazy (preguiçoso), bayes, meta (que utilizam outro
algoritmo como base) e outros (ver o Apêndice B para a lista completa utilizada).
Considerando que foram selecionados 44 algoritmos para serem testados em 10
bases, temos 440 modelos gerados; e que cada combinação de algoritmo × base é executada
110 vezes (11 por conta da técnica de cross-validation escolhida, iterada 10 vezes), temos a
tarefa de criação de um modelo sendo repetida 48.400 vezes: 44 × 10 × 110 = 48.400. Esse
processo de experimentação completo levou pouco mais de 8 horas para ser completado.
Após análise dos resultados do primeiro experimento, os 5 algoritmos com melhor
desempenho foram testados isoladamente com as 4 bases onde os melhores desempenhos
ocorreram, de modo a obter resultados mais limpos e mais fáceis de serem analisados.
2
“Então, não há nenhum método universal de mineração de dados, e escolher um algoritmo particular
para uma aplicação específica é algo como uma arte.” (Tradução do autor)
3
“Que métodos e parâmetros funcionam melhor para um dado problema? Normalmente não há nenhum
modo de responder essa questão a priori.” (Tradução do autor)
4
“Você pode não ser capaz de determinar que tipo de modelo é melhor até que você tenha tentado
várias abordagens.” (Tradução do autor)

112. Capítulo 7. Fase 4: Modelagem 111
Figura 40 – Experimento configurado e pronto para ser executado
Fonte: Elaborado pelo autor (captura de tela)
Nesse último experimento, foi mantido o algoritmo ZeroR, que simplesmente classifica
todas as instâncias com a classe de maior ocorrência. Ele serve como baseline interno,
permitindo analisar o desempenho dessa estratégia simples no conjunto de dados sendo
trabalhado e quanto os outros algoritmos superam essa estratégia5
. Os resultados são
discutidos na próxima parte da monografia.
5
Em <http://bit.ly/ExperimentosWEKA> estão disponibilizados os arquivos de setup e os dados
gerados pelos experimentos

113. Parte III
Resultados

114. 113
8 Fase 5: Avaliação dos resultados
Nesse capítulo os modelos gerados são comparados entre si e um modelo é escolhido.
O modelo escolhido é comparado ao baseline de (ABREU et al., 2011). O processo como
um todo é revisado e os objetivos traçados são avaliados em face aos resultados alcançados.
8.1 Comparação entre os modelos criados
O próprio Experimenter do WEKA, na aba Analyse, oferece todo o suporte para
a realização da comparação entre os modelos criados nos 2 experimentos descritos na
seção 7.2. Os principais passos para realizar a análise são:
1. Carregar o experimento que se quer analisar;
2. Escolher o tipo de teste estatístico que será utilizado;
3. Escolher a métrica de desempenho que será utilizada na comparação;
4. Escolher a significância estatística;
5. Definir um algoritmo para ser o baseline.
As análises foram realizadas utilizando o Paired T-Tester (corrected), recomendado
em (WITTEN; FRANK; HALL, 2011). A métrica de desempenho utilizada foi a média
ponderada de F-measure, como explicado na seção 3.6. A significância escolhida para
comparar os modelos foi de 5%, valor comum de ser utilizado também segundo (WITTEN;
FRANK; HALL, 2011). Visualizar os resultados utilizando diferentes algoritmos como
baseline ajudam na compreensão. A Figura 41 mostra a análise sendo realizada utilizando
o algoritmo meta.LogitBoost como baseline, que foi o que obteve o valor mais alto para a
média ponderada de F-measure, com 0,933.
Nessa análise, além dos 10 conjuntos de dados definidos no pré-processamento, o
conjunto original com 1466 candidatos também foi avaliado. Isso mostrou que para esse
conjunto desbalanceado, com um grande volume de falsos, mesmo utilizando F-measure
como base (que é uma boa métrica em conjuntos desbalanceados), o resultado acabaria
sendo um desempenho exageradamente otimista. Isso se dá devido ao grande volume de
casos fáceis de falsos candidatos classificados corretamente quando esse conjunto é usado,
elevando a média de F-measure para próximo de 0,98 em alguns casos. Esse grande valor
de F-measure porém não é tão representativo para o problema em questão, pois seria um

115. Capítulo 8. Fase 5: Avaliação dos resultados 114
Figura 41 – Comparação dos modelos sendo realizada no WEKA
Fonte: Elaborado pelo autor (captura de tela)
aumento forçado pelo peso da classe falso nesse cenário, ao passo que nas 3 classes de fato
importantes chega a ocorrer uma queda em F-measure.
A questão aqui é que um maior volume de casos falsos corretamente classificados,
não representam um melhor clasificador para o problema de chutes a gol: “não-chutes”
corretos são irrelevantes. Dos falsos importam apenas os erros cometidos, mas sejam
eles falsos negativos ou falsos positivos, já entram no cálculo de precision ou recall (e
consequentemente F-measure) para as outras classes. Por conta disso, o mais correto é
avaliar o F-measure ponderado apenas pelas 3 classes de chute, tirando a influência do
volume de casos falsos corretamente classificados.
Entretanto, como o WEKA não oferece essa possibilidade em sua interface, por
praticidade, na comparação interna entre os 440 modelos gerados foi utilizado o F-measure
ponderado por todas as classes, o que não é grave uma vez que os 10 conjuntos de
dados usados nessa comparação envolvem os mesmos 406 casos. Já na comparação com
a literatura, em que é preciso recalcular o valor de F-measure apenas para o modelo
escolhido, esse ajuste será feito. Isso é inclusive mais correto para o baseline de (ABREU
et al., 2011), uma vez que ele só reporta os valores para as 3 classes de interesse.

116. Capítulo 8. Fase 5: Avaliação dos resultados 115
Voltando ao WEKA, ele permite visualizar o valor obtido para a métrica de
desempenho por cada algoritmo sobre cada um dos conjuntos de dados. A ferramenta
facilita a comparação dos resultados do algoritmo definido como baseline com todos
os outros, mostrando se com o intervalo de confiança definido é possível afirmar que o
algoritmo tem um melhor desempenho. Para meta.LogitBoost, por exemplo, apesar de ter
obtido o melhor resultado, não é possível afirmar estatisticamente, com uma significância
de 5%, que ele é melhor que 14 dos outros 43 algoritmos utilizados. O algoritmo rules.NNge
com 0,9111 de F-measure ponderado, por exemplo, está tecnicamente empatado com
meta.LogitBoost com seus 0,933.
O segundo experimento foi analisado com as mesmas configurações. Lembrando, a
modelagem foi repetida apenas com os 5 algoritmos que obtiveram os melhores resultados
e com o ZeroR para servir de baseline. A Tabela 17 reproduz os resultados. O “v” ao lado
de cada valor de F-measure ponderado confirma que o algoritmo supera o baseline. Esses
resultados mostram uma grande superioridade desses algoritmos sobre a simples estratégia
do ZeroR. Estão destacados em verde os 3 melhores resultados, únicos a ficarem acima de
0,93.
Tabela 17 – Resultados do segundo experimento
Dados ZeroR LMT SimpleLogistic ViaRegression LogitBoost MultiClass
Original 0,3724 0,9328v 0,9328v 0,9210v 0,9188v 0,9066v
Só melhores 0,3724 0,9177v 0,9179v 0,9214v 0,9330v 0,9148v
Sem piores 0,3724 0,9192v 0,9191v 0,9214v 0,9189v 0,9269v
Consistency 0,3724 0,9132v 0,9132v 0,9241v 0,9187v 0,9165v
Average 0,3724 0,9207 0,9208 0,9220 0,9223 0,9162
Fonte: Elaborado pelo autor
Vale notar que todos os 5 melhores resultados foram obtidos com algoritmos que
utilizam técnicas de regressão como base. Também que o LMT, que é um algoritmo de
árvore de decisão que usa regressão logística nas folhas, gera os mesmos modelos que
SimpleLogistic nos casos em que tem apenas um nó. Essa situação acontece no caso que
ambos tiveram melhor desempenho, destacados na Tabela 17.
Uma vez que diferentes modelos ficaram tecnicamente empatados, diferentes critérios
podem ser utilizados para escolher algum desses modelos a depender da aplicação. O
modelo com o menor tamanho serializado pode ser escolhido levando em conta que possui
uma representação mais simples para o conhecimento (seguindo o princípio da Navalha de
Occam). Ou para o caso de uma análise de desempenho em que os erros cometidos sobre
alguma classe específica sejam mais relevantes, uma análise de custo pode ser feita para
escolher o modelo que gera o menor custo. Ou ainda, algum modelo de árvore pode ser
considerado o mais interessante por permitir uma melhor interpretação dos resultados.

117. Capítulo 8. Fase 5: Avaliação dos resultados 116
O modelo vencedor aqui foi o criado com o algoritmo meta.LogitBoost sobre o
segundo conjunto de dados, chamado de “Só melhores”. Suas vantagens: ele é o de menor
tamanho serializado, é o que usa menos dados como entrada (apenas 7 características -
ver Tabela 16), no fim das contas é o que teve o melhor F-measure ponderado, também
teve o melhor desempenho sobre a classe Shot on target que em geral é a métrica mais
importante das 3, e ainda é o modelo em que o treinamento ocorre mais rapidamente1
.
8.2 Comparação com a literatura
Nessa seção o modelo vencedor é comparado com o baseline selecionado na literatura,
que como definido e detalhado na seção 1.4 é o trabalho de (ABREU et al., 2011).
Para realizar a comparação, dada a decisão de descartar o peso dos falsos corretamente
classificados, que foi explicada no início da seção anterior, é necessário obter a matriz de
confusão para o modelo vencedor e recalcular a média ponderada de F-measure. A matriz
não é gerada na modelagem feita com o Experimenter, então o Explorer foi utilizado para
recriar o modelo e obter a matriz.
O resultado gerado não é completamente idêntico, uma vez que a divisão dos dados
na cross-validation acaba sendo diferente, mas são muito próximos pois em ambos os
casos foram feitas 10 iterações para reduzir a variância, além claro das 10 repetições
para mensurar o desempenho do modelo já realizadas naturalmente pela cross-validation.
Não obstante, o valor de F-measure ponderado por todas as classes, que havia sido de
0,933, mudou apenas levemente para 0,936. A matriz de confusão obtida pode ser vista na
Tabela 18.
Tabela 18 – Matriz de confusão do modelo vencedor
Valor predito
Valor real Shot on target False Shot off target Blocked shot
Shot on target 213 0 1 3
False 3 103 4 3
Shot off target 0 5 31 0
Blocked shot 2 5 0 33
Fonte: Elaborado pelo autor
A partir dela podem ser calculados os valores de precision, recall e F-measure pra
cada classe, utilizando a abordagem um-contra-todos (seção 3.6). A Tabela 19 mostra os
valores calculados para cada uma das métricas para o modelo vencedor. Já a Tabela 20
resume as métricas de desempenho do modelo vencedor, resgata os valores obtidos por
1
A partir dos dados dos experimentos, disponíveis em <http://bit.ly/ExperimentosWEKA>, é possível
carregar a interface de análise no WEKA sem precisar repetir a modelagem e analisar todas essas
informações

118. Capítulo 8. Fase 5: Avaliação dos resultados 117
Abreu (Tabela 8) e mostra quanto o novo classificador gerado melhorou precision, recall e
F-measure.
Tabela 19 – Resultados por classe e métrica para o modelo vencedor
Tipo de chute Recall Precision F-measure
Shot on target 0,982 0,977 0,979
Shot off target 0,861 0,861 0,861
Blocked shot 0,825 0,846 0,835
Total (média ponderada) a
0,9453 0,9449 0,9451
a
Ponderada pelo número de instâncias em cada classe. Os valores não são calculados para a classe falso,
que também não é reportada em Abreu
Fonte: Elaborado pelo autor
Tabela 20 – Comparação entre o modelo vencedor e a heurística de Abreu
Tipo de chute Recall Precision F-measure
Heurística de Abreu 0,7633 0,9077 0,8291
Modelo vencedor 0,9453 0,9449 0,9451
Melhoria 23,84% 4,10% 13,99%
Fonte: Elaborado pelo autor
Os resultados mostraram claramente que a principal melhoria do classificador
criado foi aumentar o recall, ou seja, ampliar o percentual dos lances relevantes sendo
detectados (em 23,84%). É importante notar que isso não foi feito ao custo de adicionar
falsos positivos, pelo contrário, uma melhoria também foi observada em precision, apesar
de menos expressiva. Em suma, a média ponderada de F-measure, que foi a métrica de
desempenho escolhida para avaliar os modelos, melhorou em 13,99%.
8.3 Revisão do processo
Essa seção lista diversos pontos do processo que devem ser alvo de melhoria
numa próxima iteração. Todas as oportunidades de melhoria identificadas estão na fase 3,
Preparação dos Dados, e na fase 4, Modelagem. São elas:
• Fase 3, Detecção de candidatos: os casos falsos filtrados no pré-processamento
podem ser filtrados já na detecção de candidatos utilizando os dados de state. Isso
diminuiria consideravelmente a quantidade de eventos que precisam ser classificados
manualmente, tornando o processo mais rápido ou permitindo que mais jogos sejam
classificados num mesmo período;
• Fase 3, Classificação manual: pode ser realizada por um grupo, o que traria uma
visão mais consensual sobre eventos ambíguos, difíceis de serem classificados;

119. Capítulo 8. Fase 5: Avaliação dos resultados 118
• Fase 3, Seleção de características: lances que terminam em colisão ficariam melhor
caracterizados com um tratamento especial. A cena que está sendo pega como
lastKick é o último ciclo antes da colisão, com a bola ainda distante do jogador em
que colide, mas deveria ser a bola já próxima, mostrando o limite do deslocamento
dela e deixando claro que existia um jogador próximo da bola nesta última cena;
• Fase 3, Seleção de características: o ciclo extra inserido em lances de bola fora precisa
de uma correção nos dados de state dos jogadores para torná-los coerentes. Essas
duas mudanças na seleção de características provavelmente eliminarão um pouco de
ruído, podendo sozinhas já causarem uma melhoria nos resultados;
• Fase 3, Extração de características: o modelo vencedor teve um desempenho pior
para Shot off target e Blocked shot (Tabela 19), o que pode indicar que faltam
características para melhor identificar esses tipos de lance. No caso de Blocked shot,
por exemplo, devem ser acrescentadas informações sobre o posicionamento da defesa,
o que foi deixado de fora nas iterações realizadas;
• Fase 4, Revisão: seria interessante utilizar o WEKA para avaliar os casos classificados
incorretamente para tentar entender o que pode ser feito para melhorar a classificação
desses casos, como definir novas características para serem extraídas, item acima;
• Fase 4, Modelagem: realizar novas iterações, entendendo melhor os algoritmos que
podem ser utilizados e fazendo ajustes finos na escolha dos parâmetros;
Para além das melhorias identificadas, o processo realizado obteve os resultados
propostos. O Objetivo de Mineração de alcançar um F-measure de 0,90 foi superado e
com isso, o Objetivo de Pesquisa de investigar a viabilidade de construir uma ferramenta
de coleta de estatísticas completa a partir dos chutes a gol mostrou um cenário bastante
promissor. As métricas de chute estão entre as principais métricas de desempenho no
futebol e agora possuem um modelo de coleta satistório. Esse é um forte indicativo de que
outras métricas podem ser coletadas com sucesso, pois em grande parte são os mesmos
tipos de ambiguidade enfrentados e superados aqui que serão encontrados, como bolas
divididas.

120. 119
9 Fase 6: Implantação
A organização e apresentação de todas as informações sobre o processo, que foram
dispostas na Parte II e III da monografia, integraram essa fase. A criação de uma ferramenta
prática aplicando o modelo num contexto real não foi incluído no escopo do projeto (ver
Metodologia, seção 3.1), mas nesse capítulo é mostrada uma sugestão de ferramenta
utilizando os mesmos dados da OPTA. Também é analisada a utilidade das métricas de
desempenho possíveis de serem extraídas com o uso dos modelos criados. Por fim, são
listados alguns cuidados relacionados a manutenção e atualização dos modelos.
9.1 Sugestão de implantação do modelo
Uma grande vantagem de utilizar a mesma definição de dados da OPTA, além
de permitir uma comparação mais direta com o futebol real, é poder se inspirar em
ferramentas que utilizam os mesmos dados. Uma dessas ferramentas é o Stats Zone do site
FourFourTwo. Nela é possível visualizar todos os eventos de uma partida separado por
time ou por jogador. Numa única tela é possível visualizar todos os chutes a gol que um
time deu num jogo. A Figura 42, por exemplo, mostra todos os chutes a gol dados pelo
Brasil na fatídica derrota por 7x1 para a Alemanha no mundial de 20141
.
Nessa interface é possível ainda aplicar diversos filtros, como recortar um deter-
minado período da partida ou visualizar apenas chutes dados de fora da área. Poder ver
todos os chutes dados num jogo em poucos segundos, lado a lado, ou quem sabe ainda
poder analisar as médias comparadas de dois conjuntos de partidas, representariam uma
evolução no modo de avaliar e testar os sistemas que jogam futebol quando comparado
com as alternativas mais comumente utilizadas atualmente: contabilizar apenas gols ou
assistir jogos no LogPlayer e registrar eventos manualmente.
O modelo vencedor seria a base para desenvolver uma ferramenta similar para a
Simulação 2D. O WEKA inclusive gera o código do modelo em Java, de modo que possa
ser utilizado externamente. Levando em consideração que os programas de detecção de
candidatos (ShotCandidatesDetector) e extração de características (FeatureSE) já foram
criados durante esse projeto, para construir essa ferramenta seria necessário: mesclar
detecção e extração num único programa para gerar vetores de características a partir de
novos logs, passar esses vetores para o modelo em Java para serem classificados, e criar
uma interface final similar a do FourFourTwo para apresentar as informações.
Outra possibilidade interessante, uma vez que todas as características que o modelo
1
Esse interface pode ser acessada publicamente em <http://bit.ly/FourFourTwoExample>

121. Capítulo 9. Fase 6: Implantação 120
Figura 42 – Ferramenta para visualizar chutes a gol
Fonte: Elaborado pelo autor (captura de tela)
vencedor utiliza para classificar um caso estão acessíveis para o técnico durante uma partida,
seria usar as estatísticas em tempo real, para que o técnico tome decisões estratégicas
durante o jogo.
9.2 Análise da utilidade dos modelos
Para demonstrar o potencial dos eventos coletados pelo modelo, os dados dos 33
jogos classificados manualmente foram analisados de acordo com as 6 métricas relacionadas
a chutes a gol apresentadas na seção 2.3 (as 3 coletadas pelo modelo, gols e as 2 derivadas).

122. Capítulo 9. Fase 6: Implantação 121
Os times foram novamente separados em 3 grupos de acordo com suas forças (Tabela 13),
como feito para selecionar o espaço amostral. A Tabela 21 apresenta as médias por jogo
de cada métrica, separada pela força dos times. Entre parênteses está a quantidade de
vezes em que um time com aquela força aparece nas partidas analisadas (“Fortes” possui
menos partidas porque o grupo ficou com 6 times, 1 a menos que os outros 2).
Tabela 21 – Médias de cada métrica de acordo com a força dos times
Métrica Fortes (18) Médios (21) Fracos (21)
Shot on target 4,89 2,81 1,33
Shot off target 0,72 0,76 0,14
Blocked shot 0,72 0,67 0,43
Goals 3,83 2,19 0,86
Chance conversion 0,67 0,51 0,3
Shooting accuracy 0,85 0,7 0,51
Fonte: Elaborado pelo autor
Pelos dados tabelados é possível perceber como o grupo dos times fortes de fato
supera os outros times em praticamente todas as métricas. A única exceção foi em chutes
para fora (Shot off target), o que não é ruim e pode simplesmente significar chutes mais
precisos (como de fato mostra Shooting accuracy). Para melhor visualizar esses dados, eles
foram plotados num gráfico de radar - Figura 43 (com as 4 primeiras métricas da Tabela 21
sendo normalizadas pelo maior valor). No gráfico é ainda mais fácil visualizar como os
times fortes dominam os médios, que por sua vez também dominam os fracos. Sair de
apenas gols para esse conjunto de métricas acrescenta mais textura a análise de um time2
.
Figura 43 – Radar com métricas de desempenho de acordo com a força dos times
Fonte: Elaborado pelo autor
2
Os dados completos por time estão disponível em <http://bit.ly/utilidadeMetricas>

123. Capítulo 9. Fase 6: Implantação 122
9.3 Manutenção e evolução dos modelos
É difícil afirmar nesse momento com que frequência os modelos devem ser atu-
alizados. O ideal será aproveitar os dados do próximo mundial para verificar quanta
qualidade o modelo perde após um ano de evolução dos times. Porém, como o servidor
já está bastante estável e poucos mudanças estão sendo inseridas recentemente, como a
amostragem utilizada para criar os modelos atuais foi bastante variada, e como em um
ano de trabalho sobre um time muitas vezes nada se altera em relação ao modo como são
dados os chutes a gol, espera-se que os modelos criados não fiquem obsoletos tão rápidos.
Para checar a qualidade do modelo o ideal é que já exista uma ferramenta criada
para utilizá-lo sobre novos logs, como a descrita na seção 9.1. Com ela o processo poderia
ser simplificado para utilizá-la sobre novos logs (uma seleção criteriosa de espaço amostral,
garantindo representatividade) e comparar as classificações geradas pela ferramenta com
uma classificação manual. Catalogar esses dados numa matriz de confusão permitiria
checar se o F-measure do modelo se deteriorou.
O caso mais comum provavelmente será o de surgirem novas jogadas que não
estavam representadas nos dados de treinamento da versão atual. Se o modelo se mostrar
incapaz de generalizar esses casos e isso estiver causando um grande impacto sobre F-
measure, por exemplo levando-a novamente para um valor abaixo de 0,90, isso tornaria
necessário repetir o treinamento com novos dados. Outro aspecto, tão importante de ser
observado quanto é incomum de acontecer, são mudanças no formato do log do servidor,
o que demandaria uma análise sobre a mudança inserida e o impacto que ela causa nas
diversas ferramentas desenvolvidas nesse projeto.

124. Parte IV
Conclusão

125. 124
Conclusões e trabalhos futuros
A última década marcou uma grande mudança na relação entre o futebol profissional
e os seus dados. Das contratações à escalação das equipes, passando pelo condicionamento
físico, são utilizadas ferramentas analíticas e estatísticas para apoiar a tomada de decisões.
Nesse período, entretanto, o ambiente da pesquisa científica com futebol de robôs não
acompanhou a evolução dessas ferramentas. Esse estudo buscou aproximar os dois campos
ao investigar como realizar a coleta automatizada de estatísticas utilizadas no futebol
profissional a partir dos logs das partidas da Simulação 2D.
O primeiro resultado prático são diversas ferramentas auxiliares que foram construí-
das para realizar o processo de Preparação dos Dados, etapa mais trabalhosa, que podem
ser reutilizadas em novos processos de Descoberta de Conhecimento nos dados da Simula-
ção 2D. Segundo, foram criados modelos para detecção de chutes a gol, uma das métricas
mais importantes no futebol e que ainda não haviam sido detectadas de modo satisfatório
segundo a literatura. Esses modelos aprimoraram o F-measure da alternativa existente em
13,99%. O uso em si de F-measure como medida de desempenho para classificadores de
eventos de futebol é uma escolha importante.
O trabalho é um bom indicativo de que com os dados contidos nos logs da Simulação
2D e a metodologia utilizada é possível realizar a detecção com qualidade dos outros
diversos eventos contabilizados no futebol profissional. Essa expansão para outros eventos
é, aliás, um dos trabalhos futuros importantes de serem realizados. Outro, é construir
uma ferramenta que utilize os modelos gerados nesse trabalho para detectar e visualizar
os eventos de chutes a gol em novos logs, ferramenta essa que poderia ser utilizada para
testes na Simulação 2D, promovendo uma evolução nos métodos de experimentação na
liga.
Com a coleta detalhada de eventos e uma maior oferta de dados históricos é possível
ter uma visão muito mais clara não só sobre os avanços de cada time independentemente,
mas sobre a evolução da liga como um todo, ano após ano. Como os eventos são os mesmos
utilizados no futebol real, torna-se também mais fácil realizar comparações deste com
a Simulação 2D, contribuindo para medir a evolução rumo a meta da Robocup. Essa
comparação pode servir de guia para realizar atualizações que mantenham a 2D como
uma liga relevante dentro da Robocup, potencial que ela tem, desde que consiga se tornar
cada vez ainda mais parecida com o futebol real.
A coleta de estatísticas sobre as partidas é apenas um primeiro passo para que seja
possível estudar as relações mais profundas que existem nos dados, desdobrando essas
diversas aplicações. É um passo fundamental de ser dado não apenas na Simulação 2D,

126. Conclusões 125
mas por todas as ligas da Robocup em que os jogos se tornem dinâmicos e mais complexos
de serem entendidos, afinal análise de desempenho é um problema transversal. Em suma,
para que a Robocup continue a caminhar firme para sua meta, é importante também que
acompanhe as evoluções do esporte.

127. 126
Referências
ABREU, P. et al. Human versus virtual robotics soccer: A technical analysis. European
Journal of Sport Science, n. January 2012, p. 37–41, 2012. 18
ABREU, P. H. Artificial Intelligence Methodologies Applied in the Analysis and
Optimization of Soccer Teams Performance. 280 p. Tese (Tese de Doutorado) —
Universidade do Porto, 2010. 17, 18, 26, 35, 39, 47, 48, 51, 58, 79, 90
ABREU, P. H. et al. Performance analysis in soccer: a Cartesian coordinates based
approach using RoboCup data. Soft Computing, v. 16, n. 1, p. 47–61, maio 2011. ISSN
1432-7643. Disponível em: <http://link.springer.com/10.1007/s00500-011-0733-0>. 7, 8,
11, 48, 49, 55, 56, 79, 80, 95, 113, 114, 116
AGENCY, T. M. As fases do CRISP-DM. 2013. Disponível em: <http://
the-modeling-agency.com/series-package/>. 61
ALBERT, J. (Ed.). Journal of Quantitative Analysis in Sports. Berlin, Boston: De
Gruyter, 2013. Disponível em: <http://www.degruyter.com/view/j/jqas>. 52
ANDERSON, C.; SALLY, D. Soccer By The Numbers. 2013. Disponível em: <http://
www.soccerbythenumbers.com/2013/03/what-exactly-is-football-analytics-what.html>.
52
ANDERSON, C.; SALLY, D. The numbers game. Viking, 2013. 384 p. ISBN 0670922242.
Disponível em: <http://www.amazon.co.uk/The-Numbers-Game-Everything-Football/
dp/0670922242>. 52
BATEMAN, R. OptaPro’s event definitions, and the importance of consistent data. 2012.
Disponível em: <http://www.optasportspro.com/en/about/optapro-blog/posts/2012/
optapro’s-event-definitions.aspx>. 17, 56, 136
BEZEK, A. Logalyzer. 2013. Disponível em: <http://dis.ijs.si/andraz/logalyzer/>. 47, 48
BOER, R. de; KOK, J. The Incremental Development of a Synthetic Multi-Agent System:
The UvA Trilearn 2001 Robotic Soccer Simulation Team. 217 p. Tese (Tese de mestrado) —
University of Amsterdam, 2002. 25, 30, 34, 41, 81
BOUCKAERT, R. R. et al. WEKA Manual for Version 3-6-8. 2012. 133
CHAPMAN, P. et al. Crisp-dm 1.0. [S.l.], 2000. 78 p. 60
CHEN, M. et al. RoboCup Soccer Server 7.07, Manual. [S.l.], 2003. 150 p. 18, 24, 25, 30,
31, 37
Enciclopédia Britânica. Enciclopédia britânica sobre futebol. 2013. Disponível em:
<http://global.britannica.com/EBchecked/topic/550852/football>. 58
FAYYAD, U.; PIATETSKY-SHAPIRO, G.; SMYTH, P. From Data Mining to Knowledge
Discovery in Databases. AI Magazine, v. 17, n. 3, p. 37–54, 1996. 59, 68, 71, 82, 97, 110

128. Referências 127
GARCÍA, V.; MOLLINEDA, J. S. S. R. A.; SOTOCA, R. A. J. M. The class imbalance
problem in pattern classification and learning. II Congreso Español de Informática, 2007.
73
GATTI, M. A. d. C.; STAA, A. von. Testing & Debugging Multi-Agent Systems: A State
of the Art Report. Rio de Janeiro, 2006. 28 p. 18, 44
GOLOVNYA, M. Introdution to Data Mining. 2006. Disponível em: <http:
//www.salford-systems.com/products/treenet/testimonials/127-all/videos/introductory/
81-introduction-to-data-mining>. 62
GOLOVNYA, M. A Step by Step Introduction to Data Mining for Sports Analysis. MIT
Video, 2011. Disponível em: <http://mit.tv/wr99gv>. 53, 59, 60
HAMM, S. GrandChallenges. 2012. Disponível em: <http://asmarterplanet.com/blog/
2012/05/ibm’s-grand-challenges-pitting-machine-against-man.html>. 22
HARTEMINK, A. Clarifying various terms for evaluating classifier (or hypothesis testing)
performance. 2014. Disponível em: <http://www.cs.duke.edu/courses/spring11/cps262/
classifier.evaluation.updated.txt>. 73
HUANG, H. et al. GDUT TiJi 2013 2D Soccer Simulation Team Description. 2013. 17
Innovation Enterprise LTD. Sports Analytics Innovation Summit. 2013. Disponível em:
<http://theinnovationenterprise.com/summits/sports-analytics-london-2013>. 52
KITANO, H. et al. RoboCup: A challenge problem for AI. AI magazine, v. 18, n. 1, p.
73–85, 1997. Disponível em: <http://www.aaai.org/ojs/index.php/aimagazine/article/
viewArticle/1276>. 21, 23
KOHAVI, R. A Study of Cross-Validation and Bootstrap for Accuracy Estimation and
Model Selection. International Joint on Artificial Intelligence, 1995. 71
LEWIS, M. Moneyball: The Art of Winning an Unfair Game. [S.l.: s.n.], 2003. 53
LIN, T. Y.-y. 2013 Team Description Paper: UBC Thunderbots Simultation. 2013. 17
MARISCAL, G.; SEGOVIA, J. A Data Mining & Knowledge Discovery Process Model.
In: PONCE, J.; KARAHOCA, A. (Ed.). Data Mining and Knowledge Discovery in Real
Life Applications. Vienna: I-Tech Education and Publishing, 2009. cap. 1, p. 1–17. ISBN
9783902613530. Disponível em: <http://cdn.intechopen.com/pdfs/5937/InTech-A_data
_mining_amp_knowledge_discovery_process_model.pdf>. 60
NODA, I. et al. Soccer Server: a tool for research on multi-agent systems. Applied
Artificial Intelligence, v. 12, p. 233–250, 1998. 25, 27, 30, 35
Opta Sports. OptaPro named as Official Data Partner for the Brazilian National Team.
2013. Disponível em: <http://www.optasportspro.com/en/about/optapro-blog/posts/
2013/news-optapro-named-as-official-data-partner-for-the-brazilian-national-team.
aspx>. 55
PRINCE, J. How Opta altered the Premier League, and soccer, fore-
ver. 2013. Disponível em: <http://prosoccertalk.nbcsports.com/2013/10/02/
how-opta-has-helped-alter-the-premier-league-and-soccer-forever-part-i/>. 54

129. Referências 128
PRINCE, J. Opta and MLS - a beautiful game they play. 2013.
Disponível em: <http://prosoccertalk.nbcsports.com/2013/10/03/
opta-and-mls-progressing-soccer-in-north-america/>. 55
PROKOPENKO, M. et al. Gliders2013: Tactical Analysis with Information Dynamics.
2013. 17
RAMOS, L. et al. ITAndroids 2D Soccer Simulation Team Description 2013. 2013. 17
RILEY, P.; VELOSO, M. On Behavior Classification in Adversarial Environments.
In: PARKER, L.; BEKEY, G.; BARHEN, J. (Ed.). Distributed Autonomous Robotic
Systems 4. Springer Japan, 2000. p. 371–380. ISBN 978-4-431-67991-2. Disponível em:
<http://dx.doi.org/10.1007/978-4-431-67919-6_35>. 48
ROBOCUP. A Brief History of Robocup. 2013. Disponível em: <http://www.robocup.org/
about-robocup/a-brief-history-of-robocup>. 21, 22, 23
ROBOCUP. Logs do campeonato de 2013. 2013. Disponível em: <http://www.socsim.
robocup.org/files/2D/log/RoboCup2013/>. 82
ROBOCUP. Página oficial da Robocup 2013. 2013. Disponível em: <http:
//www.robocup2013.org/>. 21
ROBOCUP. TDPs de 2013. 2013. Disponível em: <http://staff.science.uva.nl/
~arnoud/activities/robocup/RoboCup2013/Symposium/TeamDescriptionPapers/
SoccerSimulation/index.html>. 45
ROBOCUP. TDPs de todos os anos. 2013. Disponível em: <http://www.socsim.robocup.
org/files/2D/tdp/>. 45
RUSSEL, S. J.; NORVIG, P. Artificial Intelligence: A Modern Approach. 2. ed. [S.l.]:
Pearson Education, 2003. ISBN 0137903952. 23, 25, 38, 50
SANTOS, R. Análise de Logs : Abordagens Tradicionais e por Data Mining. 2006. 100 p.
61
SANTOS, R. Princípios e Aplicações de Mineração de Dados (aula 4). 2012. 43 p. 65, 66
SCHUMAKER, R. P.; SOLIEMAN, O. K.; CHEN, H. Sports Data Mining. Boston,
MA: Springer US, 2010. 176 p. (Integrated Series in Information Systems, v. 26). ISBN
978-1-4419-6729-9. Disponível em: <http://www.springerlink.com/index/10.1007/
978-1-4419-6730-5>. 52, 53, 54
SHAHRI, A. H. TeamAssistant2003. 2013. Disponível em: <http://sourceforge.net/p/
team-assistant/wiki/Home/>. 47
SILVA, B. et al. Bahia2D 2010: Team Description. 2010. 46
SILVA, B. et al. Implementação do nível cognitivo na arquitetura multiagentes do time de
futebol de robôs simulado Bahia2D. 63º Reunião Anual da Sociedade Brasileira para o
Progresso da Ciência, 2011. 46
SOLIEMAN, O. K. Data Mining in Sports: A Research Overview. 76 p. Tese (Doutorado),
2006. 52

130. Referências 129
STONE, P.; AUGUST, G. K. Publications Related to the RoboCup Soccer Simulation
League. [S.l.], 2013. v. 6, n. 5, 893–910 p. 48
TAKAHASHI, T. LogMonitor: From Player’s Action Analysis to Collaboration Analysis
and Advice on Formation. In: VELOSO, M.; PAGELLO, E.; KITANO, H. (Ed.).
RoboCup-99: Robot Soccer World Cup III. [S.l.]: Springer Berlin Heidelberg, 2000. cap.
LogMonitor, p. 103–113. ISBN 978-3-540-45327-7. 48
TAN; STEINBACH; KUMAR. Classification: Basic Concepts, Decision Trees, and Model
Evaluation. In: Introduction to Data Mining. 1. ed. Addison-Wesley, 2006. cap. 4. Classif,
p. 769. ISBN 0321321367. Disponível em: <http://www-users.cs.umn.edu/~kumar/
dmbook/ch4.pdf>. 62, 63, 64, 67, 68, 71, 72
TANAKA, K. et al. A Statistical Perspective on the Robocup Simulator League: Progress
and Prospects. 1998. 24, 48
The Verge. Real steel: the broken robot necks and baby steps of RoboCup
2012. 2012. Disponível em: <http://www.theverge.com/2012/9/7/3287515/
robocup-2012-robots-soccer-broken-necks-baby-steps>. 21
Two Crows. Introduction to Data Mining and Kowledge Discovery. 3. ed. Two Crows
Corporation, 2005. 36 p. Disponível em: <http://www.twocrows.com/intro-dm.pdf>. 63,
64, 66, 88, 95, 110
Waikato University. Página web do projeto WEKA. 2013. Disponível em:
<http://www.cs.waikato.ac.nz/~ml/weka/gui_explorer.html>. 76
WITTEN, I. H. Data Mining with WEKA. 2013. Disponível em: <https:
//weka.waikato.ac.nz/>. 77
WITTEN, I. H.; FRANK, E.; HALL, M. A. Data Mining: Practical Machine Learning
Tools and Techniques. 3. ed. San Francisco: Morgan Kaufmann Publishers Inc, 2011. ISBN
978-0-12-374856-0. Disponível em: <http://www.cs.waikato.ac.nz/ml/weka/book.html>.
68, 70, 71, 72, 74, 75, 77, 108, 110, 113, 133
ZEKAI-CHENG et al. Yu Shan Soccer 2D Simulation Team Description Paper for
RoboCup 2013. 2013. 17
ZHANG, H. et al. WrightEagle 2D Soccer Simulation Team Description 2013. p. 3–8,
2013. 46

131. Apêndices

132. 131
APÊNDICE A – Logs do espaço amostral
As tabelas abaixo mostram os jogos incluídos no espaço amostral. A primeira coluna
representa a força do time adversário segundo a Tabela 13. A segunda coluna indica se é
um “Jogo” selecionado, se é apenas o “Espelho” de um jogo já incluído no espaço amostral,
ou se é um jogo em que não foi feito um pareamento perfeito e apenas um dos times era o
foco da avaliação, marcado como “Único”. A terceira coluna indica o nome do adversário.
A quarta coluna indica o critério que definiu a escolha do jogo, “Prioridade” indica um
jogo que possui lances representativos e foi incluído antecipadamente, “Força” indica que
foi escolhido normalmente pelo critério da força, e os jogos espelho são marcados com “-”
pois são incluídos por consequência de um outro jogo ter sido adicionado. A última coluna
mostra o timestamp do jogo que permite identificar o arquivo de log unicamente.
Tabela 22 – Espaço amostral - times fortes
WrightEagle
Forte Jogo Helios2013 Força 20130630132958(...).rcg
Médio Jogo AUT Força 20130630092901(...).rcg
Fraco Jogo UTAustinVilla Força 20130629135833(...).rcg
HELIOS2013
Forte Espelho WrightEagle - -
Médio Jogo GDUT_Tiji2013 Força 20130629133635(...).rcg
Fraco Jogo GPR-2D Força 20130628121215(...).rcg
YuShan2013
Forte Jogo Axiom Força 20130630105407(...).rcg
Médio Jogo FC-Perspolis Força 20130629151846(...).rcg
Fraco Jogo CSU_Yunlu2013 Força 20130628121632(...).rcg
Axiom
Forte Espelho YuShan2013 - -
Médio Jogo Cyrus Força 20130629141215(...).rcg
Fraco Jogo WarthogsRobotics Força 20130628131043(...).rcg
Gliders2013
Forte Jogo Oxsy Força 20130630105409(...).rcg
Médio Jogo LegenDary Prioridade 20130629140255(...).rcg
Fraco Jogo Ri-one Força 20130628144006(...).rcg
Oxsy
Forte Espelho Gliders2013 - -
Médio Jogo FCPortugal Prioridade 20130628124345(...).rcg
Fraco Jogo HfutEngine2013 Prioridade 20130628144522(...).rcg
Fonte: Elaborado pelo autor
O Round 0, de testes, teve apenas 1 jogo selecionado (apenas pois não possível
parear de outra forma). Do Round 1 (primeira fase) foram selecionados 16 jogos. Do
Round 2 (segunda fase), 9 jogos. Do Round 3 (terceira fase), 2 jogos. Do Round 4
(double-elimination), 4 jogos. E do Round 5 (final), o único jogo possível foi selecionado.

133. APÊNDICE A. Logs do espaço amostral 132
Tabela 23 – Espaço amostral - times médios
AUT
Forte Espelho WrightEagle - -
Médio Jogo Cyrus Força 20130630103945(...).rcg
Fraco Espelho UTAustinVila - -
Cyrus
Forte Espelho Axiom - -
Médio Espelho AUT - -
Fraco Jogo GPR-2D Força 20130629120009(...).rcg
GDUT_Tiji2013
Forte Espelho Helios2013 - -
Médio Jogo LegenDary Prioridade 20130629122918(...).rcg
Fraco Jogo WarthogsRobotics Prioridade 20130629160346(...).rcg
FC-Perspolis
Forte Espelho YuShan2013 - -
Médio Espelho FCPortugal - -
Fraco Jogo ThunderBots Prioridade 20130628122518(...).rcg
LegenDary
Forte Espelho Gliders2013 - -
Médio Espelho GDUT_Tiji2013 - -
Fraco Jogo CSU_Yunlu2013 Força 20130628105538(...).rcg
FCPortugal
Forte Espelho Oxsy - -
Médio Jogo FC-Perspolis Prioridade 20130629172117(...).rcg
Fraco Jogo HfutEngine2013 Prioridade 20130628133736(...).rcg
ITAndroids
Forte Único Oxsy Força 20130629145630(...).rcg
Médio Único LegenDary Força 20130629164055(...).rcg
Fraco Único ThunderBots Prioridade 20130628115913(...).rcg
Fonte: Elaborado pelo autor
Tabela 24 – Espaço amostral - times fracos
UTAustinVilla
Forte Espelho WrightEagle - -
Médio Jogo AUT Prioridade 20130628122928(...).rcg
Fraco Jogo CSU_Yunlu2013 Prioridade 20130628110905(...).rcg
GPR-2D
Forte Espelho Helios2013 - -
Médio Espelho Cyrus - -
Fraco Jogo ThunderBots Prioridade 20130628110628(...).rcg
WarthogRobotics
Forte Espelho Axiom - -
Médio Espelho GDUT_Tiji2013 - -
Fraco Jogo HfutEngine2013 Força 20130628132413(...).rcg
CSU_Yunlu2013
Forte Espelho YuShan2013 - -
Médio Espelho LegenDary - -
Fraco Espelho UTAustinVila - -
ThunderBots
Forte Único Helios2013 Força 20130628111930(...).rcg
Médio Espelho FC-Perspolis - -
Fraco Espelho GPR-2D - -
HfutEngine2013
Forte Espelho AUT - -
Médio Espelho FCPortugal - -
Fraco Espelho WarthogsRobotics - -
Ri-one
Forte Espelho Gliders2013 - -
Médio Único Cyrus Força 20130628131813(...).rcg
Fraco Único CSU_Yunlu2013 Forçaa 20130627132605(...).rcg
a
Jogo do Round 0
Fonte: Elaborado pelo autor

134. 133
APÊNDICE B – Algoritmos de aprendizado
utilizados no WEKA
As tabelas a seguir mostram os algoritmos do WEKA utilizados nos experimentos,
separados pela família a qual pertecem. A linha de comando é mostrada nas tabelas pois
através dela é possível saber todos os parâmetros aplicados na utilização do algoritmo.
Mais sobre cada família e algoritmos pode ser encontrado em (WITTEN; FRANK; HALL,
2011), (BOUCKAERT et al., 2012) e também clicando em cada algoritmo na própria
ferramenta WEKA (onde há referências para os principais artigos relacionados).
Tabela 25 – Algoritmos e parâmetros utilizados no WEKA: árvores
Árvore
Algoritmo Linha de comando
BFTree trees.BFTree ’-S 1 -M 2 -N 5 -C 1.0 -P POSTPRUNED’
DecisionStump trees.DecisionStump ”
FT trees.FT ’-I 15 -F 0 -M 15 -W 0.0’
J48 trees.J48 ’-C 0.25 -M 2’
J48graft trees.J48graft ’-C 0.25 -M 2’
LADTree trees.LADTree ’-B 10’
LMT trees.LMT ’-I -1 -M 15 -W 0.0’
NBTree trees.NBTree ”
RandomForest trees.RandomForest ’-I 10 -K 0 -S 1’
RandomTree trees.RandomTree ’-K 0 -M 1.0 -S 1’
REPTree trees.REPTree ’-M 2 -V 0.0010 -N 3 -S 1 -L -1’
SimplesCART trees.SimpleCart ’-S 1 -M 2.0 -N 5 -C 1.0’
Fonte: Elaborado pelo autor
Tabela 26 – Algoritmos e parâmetros utilizados no WEKA: regras e bayes
Regras e Bayes
Algoritmo Linha de comando
ConjuntiveRule rules.ConjunctiveRule ’-N 3 -M 2.0 -P -1 -S 1’
DecisionTable rules.DecisionTable ’-X 1 -S “BestFirst -D 1 -N 5”’
DTNB rules.DTNB ’-X 1’
JRip rules.JRip ’-F 3 -N 2.0 -O 2 -S 1’
NNge rules.NNge ’-G 5 -I 5’ 4084742275553788972
OneR rules.OneR ’-B 6’
PART rules.PART ’-M 2 -C 0.25 -Q 1’
Ridor rules.Ridor ’-F 3 -S 1 -N 2.0’
ZeroR rules.ZeroR ”
BayesNet bayes.BayesNet ’-D -Q bayes.net.search.local.K2 – -P 1 -S BAYES
-E bayes.net.estimate.SimpleEstimator – -A 0.5’
NaiveBayes bayes.NaiveBayes ”
Fonte: Elaborado pelo autor

135. APÊNDICE B. Algoritmos de aprendizado utilizados no WEKA 134
Tabela 27 – Algoritmos e parâmetros utilizados no WEKA: funções e lazy
Funções e Lazy
Algoritmo Linha de comando
Logistic functions.Logistic ’-R 1.0E-8 -M -1’
MultilayerPerceptron functions.MultilayerPerceptron ’-L 0.3 -M 0.2 -N 500 -V 0 -S 0 -E 20 -H
a’
RBFNetwork functions.RBFNetwork ’-B 2 -S 1 -R 1.0E-8 -M -1 -W 0.1’
SimpleLogistic functions.SimpleLogistic ’-I 0 -M 500 -H 50 -W 0.0’
SMO functions.SMO ’-C 1.0 -L 0.0010 -P 1.0E-12 -N 0 -V -1 -W 1 -K “functi-
ons.supportVector.PolyKernel -C 250007 -E 1.0”’
IB1 lazy.IB1 ”
IBk lazy.IBk ’-K 1 -W 0 -A “weka.core.neighboursearch.LinearNNSearch -A
“weka.core.EuclideanDistance -R first-last””’
KStar lazy.KStar ’-B 20 -M a’
LWL lazy.LWL ’-U 0 -K -1 -A “weka.core.neighboursearch.LinearNNSearch -A
“weka.core.EuclideanDistance -R first-last”” -W trees.DecisionStump’
Fonte: Elaborado pelo autor
Tabela 28 – Algoritmos e parâmetros utilizados no WEKA: meta e outros
Meta e outros
Algoritmo Linha de comando
ViaRegression meta.ClassificationViaRegression ’-W trees.M5P – -M 4.0’
END meta.END ’-S 1 -I 10 -W meta.nestedDichotomies.ND – -S 1 -W trees.J48 – -C
0.25 -M 2’
LogitBoost meta.LogitBoost ’-P 100 -F 0 -R 1 -L -1.7976931348623157E308 -H 1.0 -S 1 -I
10 -W trees.DecisionStump’
MultiBoost meta.MultiBoostAB ’-C 3 -P 100 -S 1 -I 10 -W trees.LMT – -I -1 -M 15 -W 0.0’
MultiClass meta.MultiClassClassifier ’-M 0 -R 2.0 -S 1 -W functions.Logistic – -R 1.0E-8
-M -1’
ClassBalancedND meta.nestedDichotomies.ClassBalancedND ’-S 1 -W trees.J48 – -C 0.25 -M 2’
ND meta.nestedDichotomies.ND ’-S 1 -W trees.J48 – -C 0.25 -M 2’
RandComittee meta.RandomCommittee ’-S 1 -I 10 -W trees.RandomTree – -K 0 -M 1.0 -S 1’
RandomSubSpace meta.RandomSubSpace ’-P 0.5 -S 1 -I 10 -W trees.REPTree – -M 2 -V 0.0010
-N 3 -S 1 -L -1’
RotationForest meta.RotationForest ’-G 3 -H 3 -P 50 -F “unsupervised.attribute.Principal
Components -R 1.0 -A 5 -M -1” -S 1 -I 10 -W trees.J48 – -C 0.25 -M 2’
HyperPipes misc.HyperPipes ”
VFI misc.VFI ’-B 0.6’
Fonte: Elaborado pelo autor

136. Anexos

137. 136
ANEXO A – Definições dos eventos da
ferramenta OptaPro
Como disponível no blog da ferramenta OptaPro em 27 de novembro de 2013
(BATEMAN, 2012).
Opta’s key strength is the ability to provide in-depth, accessible data that is
consistent across the globe. Without this certainty, Opta’s player and team statistics can
be far less valuable and there would be a danger that different leagues would be analysed
in conflicting ways, rendering proper player comparison invalid.
To avoid this, Opta have a long-established a consistent list of ’Event Definitions’
in football that are adhered to across all data collection centres.
Opta Glossary
This is a list of the main football events logged by Opta:
Goal/Own Goal - While this one may seem obvious, different governing bodies
have different rules and Opta usually works with the relevant people to reflect their official
decisions on goalscorers.
Shot on target - Any goal attempt that:
1. Goes into the net;
2. Would have gone into the net but for being stopped by a goalkeeper’s save;
3. Would have gone into the net but for being stopped by a defender who is the last
man.
Shot off target - Any goal attempt where the ball is going wide of the target,
misses the goal or hits the woodwork.
Blocked Shot - Any goal attempt heading roughly on target toward goal which is
blocked by a defender, where there are other defenders or a goalkeeper behind the blocker.
Chance conversion/Goals-to-shots ratio - A calculation of goals scored divided
by shots attempted (excluding blocked attempts).
Shooting Accuracy - A calculation of Shots on target divided by all shots
(excluding blocked attempts).
Pattern of play for Goals/Attempts - Set Piece goals/attempts are those
where the ball starts from a dead ball situation such as a corner, a free kick, a penalty or

138. ANEXO A. Definições dos eventos da ferramenta OptaPro 137
a Throw-in and results in a shot before the phase of play has broken down into open play.
The exact point at which it becomes open play is usually clear but set pieces which are
cleared and then the ball is put straight back into the penalty area are still deemed to be
part of the set piece as the defending team is still positioned to deal with the set play.
Big Chances - A situation where a player should reasonably be expected to score
usually in a one-on-one scenario or from very close range.
Goal Assist - The final pass or pass-cum-shot leading to the recipient of the ball
scoring a goal.
Fantasy Goal Assist - From Summer 2013, Opta have started to collect a range
of other assists used by fantasy football, but also available to clients to determine their
own definition should they wish:
• Heavily deflected pass
• Shot on target saved, rebound scored
• Shot blocked rebound scored
• Shot hit woodwork rebound scored
• Penalty won
• Free kick won by foul
• Free kick instigated by forced handball
• Instigating own goal through shot/pass
Second Assist/Key Pass - A pass/cross that is instrumental in creating a goal-
scoring opportunity, for example a corner or free-kick to a player who then assists an
attempt, a chance-creating through ball or cross into a dangerous position.
Key Pass - The final pass or pass-cum-shot leading to the recipient of the ball
having an attempt at goal without scoring.
Chances Created - Assists plus Key passes.
Passes - An intentional played ball from one player to another. Opta adds a whole
range of qualifiers to each pass event, so that various things can be measured:
• Chipped pass - a lofted ball where there is a clear intended recipient
• Headed pass - a header where there is a clear intended recipient
• Launch - a long high ball into space or into an area for players to chase or challenge
for the ball

139. ANEXO A. Definições dos eventos da ferramenta OptaPro 138
• Cross - a pass from a wide position into a specific area in front of the goal
• Flick-on - a glancing pass with head or foot onto a team mate where the ball is
helped on in the same general direction
• Pull back - a pass inside the penalty area which is pulled back from the goal-line to
the centre of the penalty area
• Lay-off - a ball returned back to where it came from (usually by a forward) with one
touch
• Through Ball - a pass splitting the defence for a team-mate to run on to.
Each pass is logged with X and Y co-ordinates for its point of origin and destination.
This allows Opta to log the following:
• Passes broken down area of the pitch for example by own half/opposition half or
defensive/middle/final third or left/right/centre
• Passes broken down by half, for example short/long, short medium/long
• Pass direction, for example backwards/sideways/forwards.
Of course, the event based nature of the data is such that you can calculate any
combination such as chipped passes over 20 yards in the final third that go sideways. Opta
also logs whether the pass is from open play or a dead ball situation such as a corner, a
free kick, a throw or goalkeeper distribution from hands or goal kicks.
Pass completion - This is simply a formula where Successful passes are divided
by Total attempted passes in whichever combination of passes is selected. Usually, pass
completion excludes crosses. Crosses are usually treated separately and Crossing success is
the percentage of successful crosses out of the total attempted.
Touch/Unsuccessful touch - When the ball bounces off a player and there is no
intentional pass, we award a touch. Where there is a mis-control we award an Unsuccessful
touch.
Dribbles/Take-ons - This is an attempt by a player to beat an opponent in
possession of the ball. A successful dribble means the player beats the defender while
retaining possession, unsuccessful ones are where the dribbler is tackled, Opta also log
attempted dribbles where the player overruns the ball.
Tackles - A tackle is defined as where a player connects with the ball in ground
challenge where he successfully takes the ball away from the man in possession. All tackles
are really a successful event. A Tackle Won is deemed to be where the tackler or one of his

140. ANEXO A. Definições dos eventos da ferramenta OptaPro 139
team-mates regains possession as a result of the challenge, or that the ball goes out of play
and is "safe". A Tackle Lost is where a tackle is made but the ball goes to an opposition
player.
Missed Tackles - This is where a player attempts to challenge for the ball and
does not make it – it is calculated by adding fouls with an attempted tackle qualifier to
challenge lost.
Clearance - This is a defensive action where a player kicks the ball away from his
own goal with no intended recipient of the ball.
Block - This is where a player blocks a shot from an opposing player.
Interception - This is where a player intentionally intercepts a pass by moving
into the line of the intended ball.
Recovery - This is where a player wins back the ball when it has gone loose or
where the ball has been played directly to him.
Shield ball out of play - Where a player shields the ball from an opponent and
is successful in letting it run out of play.
Foul conceded - Any infringement that is penalised as foul play by a referee.
Foul won - Where a player is fouled by an opponent. There is no foul won for a
handball or a dive where a free kick is conceded.
Offside - Awarded to the player deemed to be in an offside position where a free
kick is awarded.
Duels - A duel is an 50-50 contest between two players of opposing sides in the
match. For every Duel Won there is a corresponding Duel Lost depending on the outcome
of the Duel.
Aerial Challenge won - Aerial Challenge lost - This is where two players
challenge in the air against each other. The player that wins the ball is deemed to have
won the duel. When more than two players are involved the player closest to the duel
winner is given an Aerial Duel lost.
Successful Take-on/Dribble - Challenge lost - The player who has been
beaten is given a Challenge lost if they do not win the ball.
Tackle - Unsuccessful Take-on/Dispossessed - A tackle is awarded if a player
wins the ball from another player who is in possession. If he is attempting to beat the
tackler, the other player will get an unsuccessful Take-on. If he is in possession but not
attempting to "beat"his man, then he will get a dispossessed.
Smother - Unsuccessful Take-on - A goalkeeper who comes out and claims the
ball at the feet of a forward gets a smother, similar to a tackle.

141. ANEXO A. Definições dos eventos da ferramenta OptaPro 140
Foul won-Foul conceded - The player winning the foul is deemed to have won
the duel and the player committing the foul having lost the duel.
Save - A goalkeeper preventing the ball from entering the goal with any part of
his body. Saves are broken down into:
• Hands/Feet/Body
• Caught/Collected/Parried Safe/Parried Danger area/Fingertip
• Diving/Standing/Reaching/Stooping
Clean Sheet - A player or team who does not concede a goal for the full match.
Penalty faced - We log which way a goalkeeper dives regardless of the outcome
of the penalty.
Catch - A high ball that is caught by the goalkeeper
Punch - A high ball that is punched clear by the goalkeeper.
Drop - A high ball where the goalkeeper gets hands on the ball but drops it from
his grasp.
Cross not claimed - When a goalkeeper comes off his goal line to claim a high
ball and misses the ball.
Catch Success - The percentage of high balls that a goalkeeper tries to deal with
where he is successful - Catches+Punches divided by total high balls he came for.
Keeper Sweeper - When a goalkeeper comes out of his goal to sweep up behind
his defence and attempt to clear the ball.
Touches - A sum of all events where a player touches the ball, so excludes things
like Aerial challenge lost or Challenge lost.
Disciplinary Points - For Opta Discipline tables, we award one point per foul
conceded, three points per yellow card and six per red card. For Referees’ tables we also
add three points per penalty awarded.