Classificação de Chutes Robôs Futebol

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

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

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
Prof. Ph.D Josemar Rodrigues de Souza
Professor Convidado
Salvador-BA, Brasil
14 de julho de 2014

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

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

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.

“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

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.

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.

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

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

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

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

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

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

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

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

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

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)

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.

Parte I
Referenciais teóricos

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:

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)

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,

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)

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/>

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

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 é

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/>

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

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).

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)

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)

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.

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

é 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)

• 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).

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;

• 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]
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]
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).

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

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

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.

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
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;

• 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;

• (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

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

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)

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

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-

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

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

Classificação de Chutes Robôs Futebol

Classificação de Chutes Robôs Futebol

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (10)

Destaque

Destaque (17)

Semelhante a Classificação de Chutes Robôs Futebol

Semelhante a Classificação de Chutes Robôs Futebol (20)

Classificação de Chutes Robôs Futebol