Implementação do Breakout

Para o jogo Breakout, as seguintes técnicas de detecção de colisão (e variações) foram implementadas:

• Detecção padrão (Object to object); • Região de influência;

• Ordenação pelo eixo x sem região de influência; • Ordenação pelo eixo x com região de influência; • Ordenação pelo eixo y sem região de influência; • Ordenação pelo eixo y com região de influência;

• Gerenciador de objetos (com quatro objetos por gerenciador); • Gerenciador de objetos (com oito objetos por gerenciador); • Baseada em ladrilhos (ladrilho de 6x12 [altura x largura]); • Baseada em ladrilhos (ladrilho de 6x4 [altura x largura]).

Como foi explicado na seção 3, com base nos estudos sobre experimentação, apenas a variável de interesse (a técnica de detecção de colisão) deve ser responsável por variações nos resultados do experimento, eliminando qualquer outro fator que também possa levar a uma variação nos resultados. O código comum entre as implementações das técnicas é um fator bastante importante e necessário para se atingir este objetivo, pois qualquer variação de código que não tenha como meta a implementação da técnica pode levar a uma diferença nos resultados, que não refletiria

Eric Bruno Perazzo Mariz 41 uma variação (desses resultados) em função da variável em questão. Isto é, qualquer variação no código que não tenha a ver com a implementação de uma determinada técnica pode comprometer os resultados do experimento. Como foi mencionado na seção 3.3.1, inicialmente o padrão Strategy foi utilizado para a implementação de todas as técnicas em apenas um MIDlet, isso facilitava bastante a questão do código comum, pois era necessário apenas implementar diferentes classes para as técnicas de detecção, onde o resto do código permanecia o mesmo. No entanto, esta abordagem não permitia identificar, ou pelo menos dificultava a medição, da variável tamanho de código. Desta forma, cada técnica foi implementada em um MIDlet separado. Para se fazer isto, é necessário se ter cuidado na replicação do código, para evitar que qualquer mudança possa levar a uma inconsistência dos resultados.

Na Figura 5.1 pode-se observar o diagrama de classes da implementação das técnicas de detecção de colisão para o Breakout. O BreakOutMIDlet é a classe que estende da classe básica MIDlet do MIDP, que é o ponto de partida de execução da aplicação. Uma das principais funções desta classe é a execução das iterações do teste, ou seja, ela possui o laço principal de execução da aplicação. A classe

BreakOutCanvas é responsável, principalmente, pelo gerenciamento da parte gráfica da aplicação. Ela estende da classe abstrata Canvas do MIDP e implementa a função

paint dessa classe abstrata, que é responsável pela atualização da tela a cada iteração da aplicação. Este método basicamente chama a função de atualização da tela,

drawWorld, definida na interface WorldInterface que é específica à implementação de cada técnica de detecção de colisão. Isto é, cada técnica possui a liberdade de implementar o modo como a tela deve ser atualizada em função de sua implementação do “mundo” do jogo, refletida na classe BreakOutWorld. Na verdade, apenas a técnica baseada em ladrilhos possui sua implementação diferente das demais. Isto é, para todas as outras técnicas de detecção de colisão, a implementação do método de atualização da tela é a mesma. A classe BreakOutWorld é a implementação do “mundo” do jogo que implementa a interface WorldInterface, que possui os seguintes métodos:

• public void loadWorld(int level);

• public void updateWorld();

• public void drawWorld(Graphics g);

Eric Bruno Perazzo Mariz 42 Figura 5.1: Diagrama de classes da implementação das técnicas de detecção de colisão para o Breakout.

O método loadWorld é responsável por carregar os objetos que fazem parte do jogo para os dois níveis de cada iteração. Desta forma, este método é executado duas vezes por iteração. O método updateWorld é responsável por atualizar as coordenadas dos objetos do jogo. Após a chamada deste método é feita a verificação de colisão entre os objetos usando o método checkCollision. Uma vez que os objetos tenham suas novas coordenadas definidas, o método drawWorld é chamado para a atualização da tela. O método isGameOver é chamado para saber se o nível de uma iteração terminou, ou seja, ele verifica se todos os tijolos da tela foram destruídos, em caso positivo, passa-se para o segundo nível da iteração ou inicia-se uma nova iteração. A classe Brick modela um tijolo e contém informações como a imagem associada ao

Eric Bruno Perazzo Mariz 43 objeto, a largura e altura, a posição relativa do tijolo e o estado de visibilidade do objeto. Um BreakOutWorld possui o conjunto de tijolos que formam um nível.

Além das classes mencionadas acima, outras duas classes fazem parte da implementação do jogo, a classe Constants, que possui constantes e variáveis estáticas de uso global pela aplicação, e a classe Float, que é utilizada pelo

BreakOutMIDlet para realizar os cálculos da média do número de quadros por segundo entre as iterações, já que a API do MIDP não disponibiliza manipulação de tipos básicos com ponto flutuante. O número de quadros por segundo é calculado pela aplicação contando-se o número de quadros entre uma colisão e outra e dividindo-se o valor encontrado pelo tempo gasto entre as colisões. Desta forma, é possível obter o número de quadros por segundo para um determinado número de tijolos na tela. Isto é, obtém-se a performance em fps por número de tijolos, identificando assim a variação de performance em termos do número de objetos (em termos do número de verificações de colisão feitas). Quanto menor o número de objetos na tela, menor é o número de detecções realizadas.

A classe BreakOutWorld possui todo o código relevante à implementação das técnicas, ou seja, nas outras classes não há modificações, permanecendo o mesmo código para todos os MIDlets. Na verdade, para todas as implementações das técnicas, exceto a da baseada em ladrilhos, apenas o código que verifica a colisão (cuja implementação encontra-se no método checkCollision) é que sofre modificação entre as implementações. Desta forma, seria possível restringir ainda mais a variação do código entre as implementações a apenas esse método. Entretanto essa abordagem exclui a implementação da técnica baseada em ladrilhos. Como o objetivo é propiciar uma porção de código que seja comum a todas as implementações, é necessário manter o limite entre o código comum e código específico de cada técnica no nível de implementação do mundo do jogo, dado que a técnica baseada em ladrilhos possui uma forma distinta intrínseca de implementação. Não obstante, o código da implementação do mundo do jogo para as outras técnicas permanece o mesmo, possibilitando-se fazer, caso haja interesse, uma comparação apenas entre as técnicas não baseadas em ladrilhos em função apenas do método específico de detecção de colisão. O apêndice A mostra as implementações dos métodos de detecção de colisão para as diversas técnicas implementadas no Breakout.

Eric Bruno Perazzo Mariz 44 A implementação do Breakout disponibiliza uma variável de configuração no arquivo JAD (ver seção 2.2). A variável “NUM_ITERATIONS” permite a quem estiver executando os testes configurar de forma fácil (isto é, sem necessitar recompilar o código) o número de iterações que o MIDlet precisa executar. O valor que esta variável pode assumir é um valor inteiro positivo não nulo.

Como foi dito na seção 3.3.2, o Breakout foi reestruturado para retirar as características de interação com o usuário. Sendo necessário para que o experimento pudesse ser repetido outras vezes gerando os mesmos resultados inicialmente obtidos. A única característica presente no jogo era a raquete que o jogador usava para fazer a bola refletir em direção aos tijolos. Esta raquete foi retirada e a bola, ao atingir a parte inferior da tela, passou ser refletida automaticamente, da mesma forma como ela é refletida ao se chocar com as paredes laterais ou a parte superior da tela.