Quando iniciamos o desenvolvimento do projeto, muitas das decisões anteriores dificultavam (ou impossibilitavam) a implementação das novas funcionalidades (por exemplo o uso de imagens de fundo), por isso essa primeira parte do projeto era de fundamental importância para seu sucesso.
Porém, percebemos que o trabalho seria maior do que pensávamos, devido à grande modularização que o projeto iria exigir para ser facilmente modificável.
Inicialmente, a classe CombatScene era responsável por desenhar e gerenciar elementos gráficos na tela, checagem de colisão, verificação de entrada de dados, criação de novos elementos e gerenciamento de armas. Essa falta de ``identidade'' iria dificultar a customização do jogo, por isso decidimos criar um sistema de ``managers'', que seriam a única conexão entre o CombatScene e o resto das classes que seriam implementadas.
Um bom exemplo do comportamento dos ``managers'' é a classe Items: Quando iniciamos o projeto não havia distinção entre inimigos e itens, o que tornava a implementação de novos itens muito trabalhosa. Começamos a diferenciar as classes de acordo com a sua natureza dentro do jogo, e não por sua semelhança em termos de implementação (basicamente, um item era um inimigo que não atirava).
Os itens são gerenciados pela classe Items, que mantém uma lista com todos os itens presentes no jogo em um dado momento e é responsável pela sua atualização (movimentação, gerenciamento e destruição) e desenho.
A classe CombatScene (que ainda é a principal classe do jogo) pode fazer quatro operações com itens, todas elas são feitas através de chamadas de uma instância de Items:
Essas modificações acabaram por facilitando a manutenção, customização e mesmo a criação de novos tipos de items. Essa mesma filosofia foi utilizada em todas as outras classes importantes do jogo: Bground, Enemy e Hero.