Projeto de MAC211 -- 2010
Náufragos


Fabio Kon - Marcelo Reis

Nos capítulos anteriores....

Inicia-se agora o derradeiro episódio do resgate de nossos náufragos...

Terceira Fase

Nesta última etapa de desenvolvimento do projeto vamos finalizar o jogo, dando um acabamento final, implementando a interação com o usuário, pontuação dos jogadores, vidas, telas inicial e final, etc.

Além disso, vamos utilizar o Flex e o Bison para implementar um interpretador de um arquivo de configurações do joguinho, isto é, um interpretador que filtre regras que "personalizem" a sessão de jogo.

Por fim, vamos elaborar mais testes automatizados para validar a correção da ED e do interpretador, caprichar na instalação do joguinho (utilizando o Autoconf) e preparar um relatório final (utilizando LaTeX).


Interação com o Usuário

Teclas dos Botes

Relembrando as descrições do jogo e das teclas, fornecidas em EP2: cada um dos dois jogadores controla um dos dois botes (um de cada cor) e ambos têm a tarefa de recolher a maior quantidade possível de passageiros. Os jogadores devem desviar-se dos perigosos recifes de corais.

Cada jogador controla o seu bote pressionando determinadas teclas, sendo que as teclas de cada um ficam nas extremidades opostas do teclado. São elas:

Para gerenciar as teclas em Allegro, antes de mais nada, inicialize o handler de teclado com a função install_keyboard(). A biblioteca conta com um vetor de chars chamado key, onde cada elemento representa se uma tecla do teclado foi acionada. Se, por exemplo, key[KEY_LEFT] devolve um valor diferente de zero, então a seta esquerda foi acionada num instante de tempo anterior. Consulte o manual e os tutoriais de Allegro para mais informações.

Capacidade dos botes

Cada bote tem um limite máximo de passageiros que podem ser carregados ao mesmo tempo (digamos, 10 passageiros); quando tal limite é atingido, o jogador deve "descarregar" os passageiros recolhidos na R.M.S. Asimov, para poder voltar a recolher os passageiros no mar (com o bote "lotado" não é possível recolher mais passageiros). Para que os passageiros possam ser "descarregados" no navio, o bote precisa "atracar" no mesmo: para isso, é preciso parar o bote ao lado da R.M.S. Asimov e lançar âncora. Um contador de capacidade do bote deve ser exibido em algum canto da tela.

OBS: O jogador não precisa esperar lotar o bote para descarregar passageiros na R.M.S. Asimov.

Pontuação, vidas e dinâmica do jogo

Cada jogador começa com zero pontos e 3 vidas extras (ambos são inteiros não-negativos); tais valores são alterados conforme os eventos que ocorrem durante o jogo: O jogo termina quando todos os passageiros são recolhidos, ou quando ambos os botes são destruídos e não contam mais com vidas extras. Ganha o jogador que fizer mais pontos ao final do jogo.

Ajuste fino da Jogabilidade

Vocês podem fazer ajustes nos diversos parâmetros do jogo (taxa de atualização da tela, velocidade e tamanho dos objetos, etc.) com o objetivo de melhorar a "jogabilidade" de seu joguinho. Lembrem-se que "jogabilidade" também será levada em consideração na avaliação de seu EP.

Importante: todos os parâmetros do jogo devem ser definidos na forma de constantes (#define), nos headers dos módulos do programa ou em variáveis apropriadas (ou seja, evite "números mágicos" no meio do seu código). Se preferir passar alguns parâmetros por linha de comando, não se esqueçam de acrescentar uma opção de "ajuda". Em ambos os casos, expliquem os diversos valores (mínimo e máximo) para cada parâmetro que o seu programa aceita.


Obrigatório: Interpretador de arquivo de configuração

Nesta fase, vamos implementar um interpretador de configurações do joguinho. Esse interpretador, que é chamado toda vez que o jogo é inicializado, lê regras de configuração de um arquivo arbitrário (digamos, config.sys) e assim "personaliza" a sessão de jogo que é inicializada. O arquivo de configurações precisa conter descrições para configuração de ao menos os seguintes itens:

É claro que o interpretador deverá ler corretamente os itens acima independentemente da ordem em que eles aparecem no arquivo. O joguinho deverá atualizar o arquivo de configuração ao menos nos itens em que isso claramente faz-se necessário (como, por exemplo, nos High scores).

Cada grupo está livre para acrescentar itens adicionais que julgar necessários e/ou interessantes. A filtragem deve incluir análise léxica (Flex) e sintática (Bison). Cabe a cada grupo estipular seu próprio léxico e sintaxes das regras para o processamento apropriado do arquivo de configuração.

OBS: é obrigatória a utilização de Flex e de Bison para as análises léxica e sintática, respectivamente. É permitido escrever o arquivo de configuração em XML.



Opcional: Interpretador de scripts de Bots

Como item opcional (vale um ponto extra), temos a implementação de um interpretador de scripts de Bots (ou seja, um conjunto de regras para automatizar o controle de um dos barquinhos). Com isso, poderemos oferecer a opção de jogo para 1 jogador (i.e., jogar contra o computador). O interpretador deve ler um arquivo texto contendo regras de ações do jogo, que devem ser processadas a cada iteração do mesmo. Cada regra deve verificar se uma determinada flag está com um determinado valor e, em caso positivo, tomar uma ação apropriada. Segue um exemplo de um trecho de um possível script para um Bot:

  if passageiro_a_direita
    then virar_a_estibordo
    endif
  elsif coral_em_frente
    then parar
         virar_a_estibordo
         seguir_em_frente
    endif
  elsif passageiros = 10
    then ...

A filtragem deve incluir análise léxica (Flex) e sintática (Bison). Cabe a cada grupo estipular suas próprias regras para produção de um Bot, assim como a elaboração das flags necessárias e do processamento apropriado das regras.

OBS: é obrigatória a utilização de Flex e de Bison para as análises léxica e sintática, respectivamente. As regras aceitas precisam ser suficientes para cumprir todas as ações necessárias para resgatar os passageiros.



Testes Automatizados

Para este EP, vamos elaborar alguns testes automatizados para a validação robustez da ED utilizada para manipulação dos objetos na tela, assim como da correção do interpretador; os pontos que devem ser testados são:

Portanto, a bateria de testes deve verificar a robustez da ED e a correção do interpretador. Tal qual foi feito em EP2 de MAC211, as funções de testes devem estar em um ou mais arquivos separados do "main" do programa principal.


Relatório

Junto com o joguinho, cada grupo deverá entregar um relatório, organizado nas seguintes seções: Sejam bem objetivos em cada seção do relatório; o documento precisa ter entre 2 e 5 páginas e deve ser escrito (obrigatoriamente) em LaTeX.


Melhorias Opcionais

Algumas melhorias opcionais podem ser feitas para aumentar a qualidade do joguinho; elas não são obrigatórias; todavia, uma boa implementação delas, devidamente documentadas, podem render ao grupo um ou dois pontos extras (dependendo da quantidade dos extras implementados). Caso vocês implementem uma ou mais melhorias, devem se lembrar de deixá-las claras em seu relatório final.

Alguns extras sugeridos seriam:



Data de entrega (e o que deve ser entregue)

A última fase deverá ser entregue até o dia 5 de julho (segunda-feira). Dúvidas podem ser discutidas no fórum da disciplina no Moodle, para o aproveitamento de todos.

Devem ser entregues no tar.gz:



Página de MAC211
Página do Fabio
Página do DCC

Valid HTML 4.01 Strict