O maior problema deste tipo de abordagem é que propostas aparentemente simples, tornaram-se verdadeiros ``mamutes'' no momento da implementação. Talvez esses problemas tivessem sido evitados se um maior planejamento fosse feito no momento da concepção do projeto. Foi muito freqüênte passar horas tentando implementar algum feature previamente especificado, mas completamente incompatível com o código previamente escrito (como em alguns casos de implementação de armas).
Outro ponto a ser levantado, foi a quase que total inexperiência do grupo com o uso de C++ e (boa) orientação a objetos. Em muitos casos, a tendência de ``quebrar'' as regras de boa programação OO foi escolhida no lugar de uma implementação mais ``limpa'', porém mais complexa. Isso levou à criação de classes mais bagunçadas que o necessário, sobretudo durante a implementação dos primeiros módulos do jogo, mais evidentemente no caso dos gerenciadores de background, armas e em menor escala o de inimigos, que no fim tornaram essas classes focos de vários problemas não previstos.
Um exemplo seria o sistema de backgrounds, inicialmente ineficiente e inflexível, devido à falta de suporte a tiles. A correção desse problema teve de ser ``hackeada'' no código por falta de solução melhor.
Por fim, é extremamente frustrante ter que conciliar horários e necessidades de outros membros da equipe e ainda manter a disciplina de implementar semanalmente trechos significativos de código (E, devo acrescentar, sobreviver ao tradicional caos imeano...). Problemas como falta de interesse de alguns membros do grupo, excesso de trabalhos e provas, falta de condições do próprio IME (consenso sobre horários de funcionamento e equipamento por exemplo), falta de experiência, entre outros, dificultaram consideravelmente um projeto aparentemente simples, resultando em volumosos atrasos que realmente cobraram seu preço na implementação final.