Futebol de Robos F180 » Inteligência

Coloquei os Plays e Tactis de todas as personalidades numa tabela:

https://docs.google.com/document/d/1DlHsFegDVhdFWx1p8dk-aVbl6BGyC5At4mxy-W-87gI/edit?usp=sharing

O número de Roles tem que ser exatamente 6, para cada play existem 6 roles obrigatoriamente, se você quiser colocar defender 1, defender 2 e defender 3 pode também. Podemos discutir o que artigo fala mais tarde, mas eu acho que tem que ser assim.

A princípio TP's terminadas. Está tudo atualizado no doc online.

Adicionei ao doc online as condições de início e término das plays.

Percebi que do jeito que eu fiz, as condições de término não têm importância pois nenhuma condição de início depende de alguma condição de término e as condições de início são todas disjuntas.

Copiei uma parte das terminations conditions do documento que já tinha passado, o resto você vê por lá mesmo: http://papersdb.cs.ualberta.ca/~papersdb/uploaded_files/556/paper_p33.pdf

Termination conditions, such as applicability conditions, use logical formulae of state predicates. In addition to specifying a conjunction of predicates, a termination condition also specifies the result of the play if the condition becomes true. In the play specification, they are delineated by the DONE key-word, followed by the result, and then the list of conjunctive predicates. Multiple DONE conditions can be specified and are interpreted in a disjunctive fashion.

The results for plays are as follows: succeeded, completed, aborted, and failed. These results are used to evaluate the success of the play for the purposes of reselecting the play later. This is the major input to the team adaptation system, which is described later.

Besides DONE conditions, there are two other ways in which plays can be terminated. The first is when the sequence of behaviours defined by the play are executed. As mentioned above, this gives the play the completed result. The second occurs when a play runs for a long time with no other termination condition being triggered. When this occurs the play is terminated with an aborted result and a new play is selected.

Estamos esquecendo de colocar os resultados das plays: succeeded, completed, aborted, and failed. Nesse caso, estou em dúvida se o play selection pode selecionar uma play diferente ou se em uma das condições de término da play deve ter uma condição para abortar a play atual. Por exemplo, se estamos executando a play Stop e mudamos o estado para Halt, teria uma condição de término em Stop que abortaria a play. Acho que faz mais sentido dessa forma.

Estava entendendo errado como seria feita a troca das plays. Dessa forma, as condições de término têm sim muita importância.
Vou fazer as alterações necessárias.

Fiz as alterações devidas e atualizei no doc online:
https://docs.google.com/document/d/1DlHsFegDVhdFWx1p8dk-aVbl6BGyC5At4mxy-W-87gI/edit

De forma a não precisar fazer a play decision em toda iteração do código, uma mudança de play só será efetuada se ocorrer alguma das condições de término da play atual. Caso contrário, o código será poupado dessa análise e apenas manterá a play.

Com isso, as condições de término das plays são MUITO importantes já que o esquecimento de uma pode levar o código a ficar "travado" na play quando outra deveria entrar em ação. Então peço que todos leiam o documento e ajudem a perceber possíveis (bem prováveis) esquecimentos tanto das condições de término quanto de início.

Algumas tactics podem ser destrinchadas em outras, isso é melhor para podermos reutilizar uma tactic já feita em outras plays e também se quisermos fazer alguma alteração só precisaremos alterar 1 VI e não todas as suas implementações individuais. Algumas que na minha opinião podem ser quebradas:

• Receive pass:
  1. position_for_pass
  2. receive_pass
  3. shoot

• Kick:
  1. go_to_point_behind_ball
  2. shoot

Esses são só alguns exemplos, mas como nossas estratégias são simples realmente não temos oq destrinchar tanto. Mas na hora da implementação precisamos ficar atento para algo que queiramos mudar de tactic para skill ou adicionar novas tactics, de forma que tenhamos uma maior reutilização no código.

Lucas Germano escreveu:

Algumas tactics podem ser destrinchadas em outras, isso é melhor para podermos reutilizar uma tactic já feita em outras plays e também se quisermos fazer alguma alteração só precisaremos alterar 1 VI e não todas as suas implementações individuais. Algumas que na minha opinião podem ser quebradas:

• Receive pass:
  1. position_for_pass
  2. receive_pass
  3. shoot

• Kick:
  1. go_to_point_behind_ball
  2. shoot

Esses são só alguns exemplos, mas como nossas estratégias são simples realmente não temos oq destrinchar tanto. Mas na hora da implementação precisamos ficar atento para algo que queiramos mudar de tactic para skill ou adicionar novas tactics, de forma que tenhamos uma maior reutilização no código.

Okay, vou fazer essa subdivisão nessas duas tactics. Um detalhe é que a tactic Receive pass não precisa ser destrinchada em shoot, pois quando o striker receber a bola, a play mudará de "pass state" para "jogo normal sem posse inimiga" e com isso haverá troca de personalidades, fazendo com que o robô que recebeu a bola seja o attacker. Na play "jogo normal sem posse inimiga", o attacker irá chutar a bola.

Ou seja, o Striker não chuta a bola.

Alterações feitas em:
https://docs.google.com/document/d/1DlHsFegDVhdFWx1p8dk-aVbl6BGyC5At4mxy-W-87gI/edit

Eu e o Leonardo começamos a criação das Skills. Elas são independentes das tactis, ou seja, pode haver tactis diferentes usando a mesma skill.

Fizemos uma lista de algumas tactis e listamos as skills necessárias para cada uma, acabou ficando poucas skills para cada tactic, acho que isso se deve à maneira com a qual definimos as plays e as personalidades.

Atualizamos essas alterações no final do doc online: https://docs.google.com/document/d/1DlHsFegDVhdFWx1p8dk-aVbl6BGyC5At4mxy-W-87gI/edit

Como discutido hoje, vamos separar em plays offensive e defensive, Leonardo irá explicar o porquê.

A partir dos documentos (https://tigers-mannheim.de/download/papers/2011-AI-Structure_Koenig.pdf e https://tigers-mannheim.de/download/papers/2011-Studienarbeit_Bot_Skill-Teichmann_Graeser.pdf) da Tigers, obtive os seguintes entendimentos sobre as plays e skills:
obs: Eles não usam exatamente o padrão STP. Não possuem Tactis, por exemplo.

Sobre as Plays, achei muito construtivo pois estávamos pensando em fazer algo parecido com o que eles fazem.
Já as Skills, acho que estão um pouco distantes do que estávamos planejando e creio ser melhor implementar da nossa forma mesmo.

Plays:
Elas são separadas em:
Offense-> Plays destinadas aos robôs de ataque, são exemplos plays de Chute alto, Chute com passe, Chute direto, Posicionamento para recuperar posse de bola etc...

Defense->Plays destinadas aos robôs de defesa, um exemplo é a play de ManMark.

Standard-> São as plays nas quais o time inteiro toma decisões parecidas, como Kickoff, Penalty, Stop, Halt, etc.

Todas as plays são classes filhas de uma classe abstrata que eles chamam de "APlay", em que o método padrão de cada play é o calculo de sua aplicabilidade ou não.

A escolha das plays é feita baseado num fator que varia de 0 a 100, em que quanto maior o valor, mais adequada é a play para a situação. Esse fator é formado a partir de um número base fixo e em conjunto com cada situação. O fator de uma play deve ser dinamicamente relacionado ao seu sucesso em suas execuções passadas durante o jogo.

Comparando ao que temos disponível em nosso código hoje, o cálculo de aplicabilidade de cada play será apenas booleanos dizendo se suas condições de início e término estão ou não sendo satisfeitas. Isso se deve ao fato de o comportamento dos nossos robôs ser relativamente fixo em praticamente todas as situações, fazendo com que tenhamos apenas uma play plausível a ser escolhida.

No código atual, a única situação na qual creio precisarmos de escolha parecida com a deles é entre as plays "PassToStriker" e "PassTo2ndStriker".

Eles citam um Playbook como sendo uma lista com todas as plays, porém os maiores detalhes sobre isso estão numa referência que não abre mais.