Batalha de rob os

Marco Dimas Gubitoso 30 de outubro de 2013

Sum ario
1 Introdu c ao 1.1 Arena . . 1.2 Rob o . . . 1.3 Sistema de 1.4 Cliente . . . . . . . . . . . . . . . . . . . . gerenciamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2 3 3 4 4 4 5 5 6 7 8 8 11 11 11 11 12 12 12 13 14

2 Primeira fase (em Perl) 2.1 A m aquina virtual . . . . . . 2.1.1 Instru c ao . . . . . . . 2.1.2 Tipos de dados . . . . 2.1.3 Conjunto de instru co es 2.1.4 Execu c ao . . . . . . . 2.2 Montador . . . . . . . . . . . 2.2.1 C odigo de instru c oes .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

3 Segunda Fase A Arena e a M aquina Virtual 3.1 A M aquina virtual em Java . . . . . . . . . . . 3.1.1 Tipos de dados . . . . . . . . . . . . . . 3.1.2 Operandos das instru co es . . . . . . . . 3.1.3 Atribui ca o e consulta a vari aveis . . . . . 3.1.4 Chamada de sistema . . . . . . . . . . . 3.2 Arena . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Chamadas ao sistema . . . . . . . . . . . 3.3 Detalhes nais . . . . . . . . . . . . . . . . . . .

em Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

4 Terceira Fase Sistema de Jogo e Apresenta c ao Gr aca 4.1 Sistema de jogo . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 Rob os . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.2 Arena . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.3 Chamadas ao sistema . . . . . . . . . . . . . . . . . . 4.2 Apresenta c ao gr aca . . . . . . . . . . . . . . . . . . . . . .

. . . . .

14 14 14 15 16 16

Introdu c ao

O jogo se passa em uma arena ou mundo habitado por ex ercitos formados por rob os virtuais. Os rob os s ao aut onomos e obedecem a um programa interno, redigido pelos jogadores e que pode ser substitu do a qualquer momento. O objetivo e colecionar 5 cristais especiais e lev a-los at e a base dos ex ercitos inimigos. O ex ercito que tiver os 5 cristais colocados em sua base estar a automaticamente fora do jogo. O u ltimo ex ercito a permanecer na arena eo vencedor. A descri c ao que segue e intencionalmente vaga em diversos pontos, para que possamos discutir em classe e em uma wiki especialmente criada para isso no Paca. As pr oximas se c oes descrevem os principais elementos do jogo, que ser ao detalhadas em momento oportuno. O servidor (sistema de gerenciamento) e o cliente ser ao componentes do sistema, se houver tempo, implementaremos o jogo em rede.

1.1

Arena

A arena nada mais e do que uma regi ao onde a batalha ocorre. Internamente e uma matriz hexagonal de terreno, onde est ao descritas as posi co es das bases, dos cristais e tipos de solo e acidentes geol ogicos. Cada elemento da matriz pode ser um dos seguintes tipos (outros poder ao ser acrescentados): Terreno plano o rob o pode entrar e sair com custo m nimo. Terreno rugoso o custo de sa da e 3 vezes maior. Reposit orio de cristais cont em um certo vari avel de cristais, mas s ao inicialmente invis veis. Um rob o s o poder a ter ci encia da sua posi ca o ap os explorar o s tio. 2

 Base a base de um ex ercito, o ponto que deve ser defendido.

1.2

Rob o

Como foi dito, um rob o e uma unidade aut onoma, isto e, n ao precisa de comandos do usu ario para agir. Seus modos de a ca o s ao programados a priori. Isto faz com que ele seja um interpretador de uma linguagem, implementando uma m aquina virtual. Esta m aquina ser a capaz de enviar solicita c oes ao sistema de gerenciamento do jogo (veja a se c ao 1.3), informando seu desejo em andar, atacar, explorar, etc. O resultado de cada a ca o depender a do andamento do jogo todo. Cada chamada retornar a a nova posi c ao do rob o e seu estado.

1.3

Sistema de gerenciamento

ele que mant A parte central do jogo e o sistema de gerenciamento. E em o estado da arena, trata das requisi co es dos rob os e dos jogadores. Em ess encia, e um servidor associado a um mecanismo de atualiza ca o de estados. Na sua vers ao nal, o servidor dever a executar as seguintes tarefas: 1. Inicializar a arena, seja criando uma arena nova a cada jogo, ou lendo um cen ario pronto do disco. 2. Aguardar conex oes dos jogadores e, para cada um deles: (a) Denir uma base na arena (b) Carregar os ex ercitos e distribu -los na arena. (c) Enviar os dados completos do jogo, assim que denidos. 3. Iniciar um la co que permanecer a em execu c ao at e que o jogo termine. Cada itera ca o tratar a de um passo de andamento do jogo (timestep ). Este passo compreende diversas a co es: (a) Vericar e tratar chamadas especiais dos jogadores (desist encia e altera ca o de programa do rob o). (b) Tratar requisi co es dos rob os. (c) Reposicionar os elementos do jogo. (d) Enviar dados de atualiza ca o de cen ario para os jogadores (clientes) 3

1.4

Cliente

O programa cliente e o respons avel pela interface com o usu ario e a conex ao com o sistema gerenciador. Do ponto de vista de tarefas, ele e relativamente simples, suas atribui c oes s ao as seguintes: 1. Permitir que o usu ario congure seu ex ercito, programando os rob os e distribuindo atributos de energia, for ca, velocidade, etc. 2. Fazer a conex ao e registro com o servidor. 3. Apresentar a arena gracamente para o usu ario, com todas as informa co es relevantes. 4. A cada passo, receber do servidor as atualiza c oes do jogo e alterar a imagem mostrada ao jogador de acordo. 5. Permitir que o jogador fa ca as solicita co es ao servidor.

Primeira fase (em Perl)

A primeira fase, feita em perl, n ao ser a usada na vers ao nal do projeto. No entanto, ela ser a bastante u til para aprimorar as ideias e automatizar os testes, at e que o compilador esteja completo. A crit erio de cada um, ela poder a ser adaptada para auxiliar o desenvolvimento de outras formas. Esta fase e composta de duas partes: a implementa ca o de uma m aquina virtual, que posteriormente ser a substitu da por outra em java ; e um montador, que l e um arquivo fonte e gera c odigo execut avel na m aquina virtual.

2.1

A m aquina virtual

necess A m aquina virtual ir a reger o comportamento dos rob os. E ario denir os tipos de vari aveis que esta m aquina pode manipular e quais as instru co es fundamentais e avan cadas dispon veis para o programador. Felizmente a implementa c ao e simples e a inclus ao futura de novos tipos e instru co es e f acil, como veremos. A m aquina se baseia em uma pilha de dados, como em uma calculadora p os-xa ou RPN. Al em disso, ela possui uma pilha de execu c ao e um vetor de mem oria. Algumas vari aveis especiais poder ao ser manipuladas diretamente pelo programa, veja abaixo. 4

As instru c oes s ao colocadas sequencialmente em um vetor e uma vari avel inteira marca o ponteiro de execu c ao, isto e, o ndice da instru ca o sendo executada. Recapitulando, cada m aquina virtual possui, pelo menos, as seguintes vari aveis: Vetor com o programa Um vetor com a sequ encia de instru c oes que devem ser executadas. Ponteiro de instru co es Um escalar inteiro com a posi ca o da pr oxima ins um tru ca o a ser executada. E ndice do vetor de programa. Pilha de dados Uma pilha com os dados usados na execu ca o do programa. Em perl e simplesmente mais um vetor. Pilha de execu c ao Uma pilha com endere cos de retorno, para chamadas de fun co es. Mem oria Simplesmente um vetor com valores. 2.1.1 Instru c ao

Uma instru c ao nada mais e do que um par (opcode, valor )1 , onde o opcode e uma constante indicando o tipo de opera ca o e valor e um operando que pode n ao ser necess ario, dependendo da instru ca o espec ca. 2.1.2 Tipos de dados

Os tipos que devem ser aceitos na m aquina virtual s ao os seguintes: N umero A ca o Cristais Terreno Vizinhan ca Endere co de vari aveis
1

usei o anglicismo opcode porque acredito que deixa a descri c ao mais clara.

Outros podem ser inclu dos, de acordo com o interesse de cada grupo e com as discuss oes na wiki. Cada tipo corresponde a uma classe, que dever a ter um construtores espec cos, com todas as possibilidades de argumentos cab veis.2 2.1.3 Conjunto de instru co es

O conjunto de instru co es e o mais delicado em termos de escolha, pois dene o que a m aquina poder a executar ou n ao. Al em de opera c oes b asicas, colocaremos algumas instru c oes complexas, para facilitar a programa ca o. Instru c oes b asicas Este e um subconjunto minimal e n ao e espec co para o jogo, mas e necess ario para permitir a interpreta ca o de uma linguagem mais completa: Manipula ca o da pilha Opera co es aritm eticas Desvios Chamada e retorno de fun co es Atribui ca o e consulta a vari aveis Em todos os casos, os operandos, se houver, devem ser vericados quanto a ` compatibilidade da opera ca o. Manipula c ao da pilha As opera co es normais de pilha, acrescidas de instru co es auxiliares u teis: Empilha coloca um Empilh avel na pilha Desempilha retira e retorna o topo da pilha Dup duplica o topo Descarta retira o topo
N umeros podem ser representados diretamente, sem a necessidade de uma classe em separado. Isso mudar a na vers ao em java.
2

 Inverte troca a ordem dos dois elementos no topo Consulta retorna uma c opia do topo da pilha, sem retir a-lo Opera c oes aritm eticas As opera c oes usuais de soma, subtra ca o, etc. Podem ser inclu das as fun co es mais interessantes, ou mesmo opera c oes novas que se mostrem u teis de alguma forma. Opera c oes l ogicas De modo similar a `s aritm eticas, as opera co es l ogicas atuam sobre os valores no topo da pilha, empilhando o resultado (verdadeiro ou falso ). Desvios Aqui se encontram os desvios incondicionais e os condicionados ao valor no topo da pilha. O operando e o deslocamento com rela c ao a ` posi ca o atual do ponteiro de execu ca o. Chamada e retorno de fun co es Para simplicar a chamada de fun co es, usaremos uma pilha adicional, a pilha de execu c ao, que conter a apenas os endere cos de retorno. Desta forma n ao precisaremos nos preocupar com a implementa c ao do quadro (frame ). Os argumentos s ao empilhados normalmente na pilha de dados e cabe ` a fun ca o retir a-los, se necess ario. A opera c ao de retorno simplesmente desvia para o endere co no topo da pilha de execu c ao. Se a fun c ao precisar devolver um valor, ela simplesmente o coloca na pilha de dados antes de retornar. Instru c oes espec cas S ao instru co es que n ao se enquadram nos casos anteriores, como t ermino de programa, por exemplo. Para testes, e interessante incluir uma instru c ao que imprime o topo da pilha. Novas instru c oes podem ser inclu das posteriormente. Vamos discutir na wiki. As instru co es que devem ser implementadas neste momento est ao relacionadas na descri c ao do montador 2.1.4 Execu c ao

A execu ca o simplesmente percorre o vetor de programa, usando o ponteiro de instru c oes e executa a a ca o correspondente ao opcode encontrado. Estipularemos que a execu ca o sempre se inicia na posi ca o 0 do vetor.

2.2

Montador

A segunda parte desta fase e o montador, respons avel por traduzir um texto com um c odigo fonte (assembly ) e gerar o vetor de programa descrito acima. O formato da entrada e bastante simples, consistindo de uma s erie de linhas com a seguinte estrutura: [label :] [opcode [argumento ]] Os []s indicam que os campos s ao opcionais, al em disso, valem as seguintes regras: Coment arios se iniciam com # e seguem at e o nal da linha. Linhas vazias s ao ignoradas. Cada linha com opcode corresponde a uma posi c ao no c odigo do programa. Um label dene uma constante com a posi c ao corrente do programa. 2.2.1 C odigo de instru co es

As instru c oes que devem ser reconhecidas e consequentemente implementadas na m aquina virtual, nesta fase, s ao as descritas a seguir. Exceto onde explicitado, as instru c oes atuam sobre a pilha de dados. PUSH empilha seu argumento. POP descarta o topo da pilha. DUP duplica o topo da pilha, isto e, empilha uma c opia do topo. ADD desempilha dois argumentos e empilha sua soma. SUB desempilha dois argumentos e empilha sua diferen ca (subtrai o topo do segundo elemento). MUL desempilha dois argumentos e empilha seu produto. DIV desempilha dois argumentos e empilha a raz ao entre o segundo elemento e o topo. 8

 JMP atribui o seu argumento ao ponteiro de instru co es. JIT jump if true atribui seu argumento ao ponteiro de instru co es se o topo da pilha for verdadeiro. Em qualquer caso, descarta o topo. JIF jump if false atribui seu argumento ao ponteiro de instru co es se o topo da pilha for falso. Em qualquer caso, descarta o topo. EQ desempilha dois argumentos e empilha o resultado da compara ca o de igualdade. GT similar, para compara c ao de valor maior entre o GE similar, para maior ou igual. LT similar, para menor. LE similar, para menor ou igual. NE similar, para diferen ca (n ao igualdade). STO remove o elemento do topo e armazena no vetor de mem oria, o ndice e dado pelo argumento da instru ca o. RCL empilha elemento do vetor de mem oria que se encontra na posi ca o dada argumento da instru c ao. END t ermino da execu ca o. PRN desempilha e imprime o topo da pilha. O programa nal desta fase dever a ler um arquivo fonte, gerar o vetor de instru co es e execut a-lo.

Exemplos de programas Conta simples INIC: PUSH 10 PUSH 4 ADD PUSH 3 MUL PRN END

Fibonacci # inicializa PUSH STO STO PUSH STO LOOP: RCL RCL DUP STO ADD DUP STO PRN RCL PUSH SUB DUP STO PUSH EQ JIF END 1 0 1 10 2 0 1 0

#x #y #i

# x = y # x+y #y = x+y

1 2 1

#i-1 2 0 # i = i-1

# i == 0? LOOP

10

Segunda Fase A Arena e a M aquina Virtual em Java

O desenvolvimento desta fase depender a de conceitos que ser ao apresentados em classe, nas pr oximas aulas. Mesmo assim, j a e poss vel projetar o que deve ser feito e tratar da implementa ca o e reconhecimento das instru co es adicionais.

3.1

A M aquina virtual em Java

Uma vers ao da m aquina j a foi constru da em Perl, o que deve ser feito e sua adapta ca o e a reimplementa c ao em Java, usando orienta ca o a objetos. Um dos problemas que precisam ser enfrentados e a identica ca o do tipo de vari avel que est a no topo pilha, para o tratamento correto na execu c ao. Isto pode ser feito de algumas formas diferentes, seja com polimorsmo puro, seja de modo expl cito, usando instanceof. Veja o cap tulo 12 do livro texto(Thinking in Java, dispon vel no Paca). Veja a seguir as principais diferen cas entre a vers ao em Perl e a vers ao em Java. Como dito acima, os conceitos necess arios ser ao vistos nas pr oximas aulas. 3.1.1 Tipos de dados

Todos os tipos de dados ser ao derivados de uma interface comum, que chamaremos de Empilh avel. A pilha de dados (classe Pilha) conter a um vetor de empilh aveis e os m etodos necess arios. Escolhemos Empilh avel como interface e n ao classe, para n ao atrapalhar a hierarquia normal dos outros elementos. 3.1.2 Operandos das instru c oes

Em todos os casos, os operandos, se houver, devem ser vericados quanto a ` compatibilidade da opera c ao. Isso pode ser feito pela m aquina virtual do Java, com blocos try/catch, ou explicitamente, com instanceof. Sugiro o uso do instanceof por ser mais eciente. A outra possibilidade e ter um m etodo para cada tipo de opera ca o que sempre retorne um valor v alido. Esta estrat egia tem as desvantagens de

11

for car um acoplamento maior entre as classes e n ao fazer um tratamento de erros mais adequado. 3.1.3 Atribui c ao e consulta a vari aveis

Um conjunto de instru co es poder a alocar, consultar e alterar vari aveis adicionais. A aloca c ao coloca o endere co de uma nova vari avel na pilha, a consulta troca o endere co do topo da pilha pelo seu conte udo e a atribui c ao coloca o valor do topo da pilha no endere co que se encontra na segunda posi ca o. 3.1.4 Chamada de sistema

Precisaremos incluir uma instru co es especiais para fazer chamadas ao sistema (Arena), solicitando opera co es que alterem o estado do jogo (pegar ou depositar um cristal, movimentar o rob o, ataques, etc). Cada instru c ao especial dever a retirar os argumentos da pilha, montar um objeto da classe Opera c ao e chamar a Arena (veja em 3.2), obtendo uma resposta. No retorno, o resultado se encontrar a no topo da pilha.

3.2

Arena

Esta classe cont em a representa c ao do mundo. Essencialmente e uma matriz 3 hexagonal cujos elementos s ao classes de terreno como descrito na se ca o 1.1, mas deve tamb em conter a posi c ao dos rob os e o estado geral do jogo. Entre as informa co es que um objeto desta classe deve manter, encontramse: Lista dos ex ercitos ativos, com a posi ca o de cada rob o. Tempo transcorrido Note que os dois primeiros atributos s ao objetos compostos, portanto devem ser implementados em uma classe espec ca. Os m etodos importantes, al em do construtor, incluem: Atualiza() movimenta os ex ercitos e atualiza o estado do sis o m tema. E etodo respons avel para avan car um timestep. nesta implementa c ao, signica fazer com que cada rob o se adiante um ciclo da m aquina virtual.
3

discutida em classe

12

 InsereExercito() inclui um novo ex ercito no jogo. RemoveExercito() retira um ex ercito derrotado do jogo. Sistema(Opera c~ ao op) Este m etodo ser a chamado por uma instru ca o especial da m aquina virtual. A classe Opera c ao possui uma identica c ao do tipo de chamada e eventuais operandos. Para exemplos, veja 3.2.1. A Arena pode ainda percorrer sua matriz e atualizar os diversos elementos de terreno, permitindo um mundo din amico. Discutiremos isso em classe. 3.2.1 Chamadas ao sistema

As chamadas ao sistema permitem a altera ca o do estado do mesmo. A solicita ca o espec ca est a codicada em um objeto Opera c ao que, como j a dito, possui um c odigo, operando e uma refer encia ao rob o que realizou a chamada. Os resultados dever ao ser tratados (por exemplo, empilhar) pela instru ca o que realizou a chamada. Note que um rob o n ao pode modicar seu estado sozinho, a menos de vari aveis internas que n ao tem impacto direto sobre o ambiente. Se ele quiser se mover, dever a solicitar ao sistema que fa ca isso. Veja alguns exemplos: [Mover, dire ca ~o] o c odigo mover solicita que o rob o seja movido na dire ca o indicada. A dire c ao e uma das seis possibilidades de deslocamento em uma matriz hexagonal. [Recolhe,dire c~ ao] recolhe um cristal que est a posi ca o vizinha indicada pela dire c ao. [Deposita,dire c~ ao] deposita um cristal na posi ca o vizinha indicada pela dire ca o. [TipoAtaque,dire c~ ao] realiza um ataque do tipo indicado na dire ca o. O alcance do ataque depende de seu tipo.

13

3.3

Detalhes nais

poss E vel que surjam conitos entre requisi co es ao sistema: por exemplo, dois rob os tentam ir para a mesma posi ca o. Uma sa da e colecionar todos os movimentos e decidir caso a caso. No entanto, vou propor uma solu ca o mais simples em aula. Nesta fase, o mais importante e ter o arcabou co montado. Nem todas as chamadas do sistema precisam ser implementadas e mesmo que uma ou outra instru ca o que faltando, n ao haver a problema contanto que seu programa esteja preparado para coloc a-las rapidamente nas pr oximas fases.

Terceira Fase Sistema de Jogo e Apresenta c ao Gr aca

A segunda fase montou o funcionamento b asico da m aquina virtual e do sistema de gerenciamento. Agora completaremos o sistema de jogo, a menos da linguagem de alto n vel, que ocorrer a na u ltima etapa. O trabalho necess ario para esta fase e um pouco menor, j a que a parte mais complicada j a est a pronta. A maior novidade e a interface gr aca, que ser a apoiada por exemplos de implementa c oes, disponibilizadas em aula e no Paca.

4.1

Sistema de jogo

O sistema de jogo nada mais e do que a Arena com os rob os e demais elementos j a distribu dos e com todas as chamadas de sistema implementadas. Seguem os pontos que devem estar implementados para que o jogo comece a funcionar como tal. 4.1.1 Rob os

Os rob os devem ser inicializados de forma completa. Existem vari aveis de estado importantes, como sa ude, energia, tipo e n umero de armas. As vari aveis que ser ao implementadas depende da complexidade desejada do jogo. O rob o b asico deve ter pelo menos a sa ude (percentual de avaria), um n vel de ocupa c ao (veja abaixo) e um objeto para guardar a vizinhan ca apresentada pelo sistema.

14

Rob os derivados podem incluir outras caracter sticas, como velocidade em cada tipo de terreno, energia, sensores, etc. Fica a crit erio de cada grupo o que implementar, mas a implementa ca o n ao deve impedir extens oes a priori. O mais importante e que o rob o n ao pode mudar seu pr oprio estado pela m aquina virtual. Qualquer mudan ca de estado e feita pela Arena. 4.1.2 Arena

Na inicializa ca o, a Arena deve realizar as seguintes tarefas: Inicializar a matriz que representa o mundo, indicando o tipo de terreno em cada c elula (veja abaixo) Determinar as c elulas bases de cada ex ercito e marc a-las Distribuir os cristais aleatoriamente Distribuir os ex ercitos de rob os, tomando o cuidado de n ao sobrep olos. Esta distribui c ao pode ser aleat oria ou n ao, e uma op c ao de cada grupo. Minha sugest ao e colocar os rob os em uma a rea pr oxima a ` sua base. Ap os a inicializa c ao da Arena, o mundo constru do deve ser apresentado gracamente (se ca o4.2) de modo que as c elulas mostrem apropriadamente os itens gr acos correspondentes (o terreno espec co, a presen ca ou n ao de um rob o, etc). Neste momento, as m aquinas virtuais devem come car a executar os programas recebidos, uma instru c ao por vez, e prosseguir ao iterativamente. As m aquinas ser ao percorridas por um iterador aleat orio. Ao nal de cada rodada a matriz e atualizada4 , se ocorrer alguma mudan ca de estado. Ao escalonar a m aquina virtual de um determinado rob o, a Arena deve antes vericar se este rob o est a ocupado. A ocupa ca o e determinada por um contador no rob o. Se o contador for 0, a instru c ao pode ser executada normalmente, caso contr ario, o contador e decrementado e a instru ca o n ao e executada. Isto permite que chamadas ao sistema durem mais do que um ciclo, permitindo penalizar o rob o quando caminhar por terrenos escorregadios ou quando estiver recebendo um novo programa na u ltima fase.
A apresenta c ao na tela da matriz atualizada pode n ao ocorrer imediatamente, mas isto n ao e um problema, pois agendaremos o desenho a intervalos regulares.
4

15

4.1.3

Chamadas ao sistema

Como j a dissemos, toda altera c ao de estado deve ser feita exclusivamente 5 pela Arena . A co es como ataque, movimenta ca o, pegar ou largar um cristal, devem estar implementadas por chamadas ao chamadas ao sistema (se ca o 3.2.1). Algumas, talvez todas, j a foram implementadas na segunda fase. Nesta fase, e o momento de complet a-las e vericar seu funcionamento correto. Em resumo, cada chamada deve: 1. Vericar o tipo de opera c ao solicitada (objeto Opera c~ ao). 2. Vericar a viabilidade da opera ca o: o caminho pode estar obstru do na dire ca o do movimento, a sa ude do rob o n ao permite que ele carregue mais cristais, ou n ao existem cristais na posi ca o, etc. 3. Se a opera ca o puder ser executada, atualiza o estado do sistema de acordo. 4. Atualiza, se for o caso, o contador de ocupa ca o do rob o. 5. Retorna.

4.2

Apresenta c ao gr aca

Usaremos as bibliotecas do Java, Swing e Awt, que s ao contidas na distribui ca o padr ao. O monitor colocar a alguns exemplos comentados, al em de algumas boas refer encias no paca.

N ao custa lembrar que Arena e sistema se referem ` a mesma entidade, que controla a execu c ao do programa todo

16