Projeto Back-off – Cronograma
Segue o novo cronograma do projeto back-off, fase de reconstrução da engine.
| Atividade | Prazo | Responsável |
|---|---|---|
| Documento de game design | 30/07/2009 | Insane/Molusco |
| Viewport | 07/07/2009 | Insane |
| mapa | 07/07/2009 | Molusco |
| colisão | 17/07/2009 | Molusco |
| som | 20/07/2009 | Insane |
| cutscenes | 20/07/2009 | Molusco |
| helpers | 17/07/2009 | Insane |
| HUD | 25/07/2009 | Insane/Molusco |
| sitstema de animação | 05/08/2009 | Insane/Molusco |
| sistema de menus | 27/07/2009 | Molusco |
À medida que as atividades forem concluídas, postaremos notícias sobre o desenvolvimento do projeto.
Projeto Back-off – A Retomada
O Projeto back-off tem ficado de lado nos ultimos meses pela falta de tempo de todos os (2) desenvolvedores. Mas a situação está para mudar. O replanejamento foi concluído e o novo cronograma será postado em breve na página do projeto e aqui. Com mais horas de desenvolvimento semanal e “programming madness” regados a muita cerveja durante os fins de semana, pretendemos concluir o projeto em poucos meses. Até sexta-feira divulgaremos o novo cronograma.
[OFF-TOPIC]Aguardem novidades sobre desenvolvimento de conteúdo para dispositivos móveis, nas próximas semanas.
Projeto Back-off – Status Update (v 0.4)
Estou enfrentando sérias dificuldades na codificação do jogo. Por falta de experiência em jogos e por desconhecimento de computação gráfica, física e até matemática, algumas coisas simples não foram implementadas ainda, outras foram implementadas de formas simplistas demais. Comprei alguns livros (que serão mencionados no final do post) e espero que possa progredir nos quesitos citados. Abaixo seguem minhas maiores frustações no momento:
Caixa de colisão
A colisão entre os sprites foi implementada e está funcionando, até com relativa eficiência. Mas foi usada uma técnica muito simples e insatisfatória. Cada sprite “colidível” tem uma bounding box que é… ele mesmo. Isso mesmo! Não existem regiões colidíveis em um sprite, ele todo é colidível ou não é colidível por completo, sem meio termo. Isso quer dizer que se um sprite é redondo, com as sobras trasnparentes, ainda assim a área de colisão será considerada o quadrado. Lame!
“É uma solução simples”, você pode dizer, mas não para mim. Eu poderia registrar as áreas de colisão individualmente, para cada pixel, e manter isso em memória, mas seria um alto custo de memória que poderia ser gasto em coisas mais legais do jogo. Eu poderia também fazer uma máscara binária para pixels colidíveis do sprite, mas diria adeus à performance, embora o resultado fosse excelente (colisão pixel-perfect)
Editor de mapas
O editor de mapas está “pronto” e funcional. Até minha mulher consegue criar mapas nele, mas a verdade é que ele está muito simples e limitado. A começar pelos sprites, que devem ser todos do mesmo tamanho e pertencer à mesma figura (sprite sheet). O sistema de camadas está muito bom, na minha opinião, e está preparado para resolver problemas clássicos de mapas 2D, como “passar atrás de objetos” em mapas isométricos, transparência de pixels, etc. O projeto poderia sobreviver com a engine de mapas e o editor atual, mas a questão de todos os sprites serem do mesmo tamanho, me tira o sono. Será resolvido antes do jogo ver a luz do dia.
Orientação a Objetos
Eu sou programador de aplicações comerciais desde 2002. Sempre trabalhei com OO, e soluções não-OO me incomodam profundamente. Eis o problema, EU NÃO CONSIGO modelar o jogo do jeito que gostaria. O código da engine está bastante orientado a objetos, ao menos por enquanto, mas o código do jogo em si, é odioso, um tripão de código sem fim. Sempre que acho um lugar onde posso fazer um refactoring, eu o faço, mas sempre me surge um novo problema que inviabiliza o mesmo. Preciso achar um meio termo. Acho que esse é o único assunto que os livros que adquiri não tratam com eficiência. Até onde um jogo pode/deve ser orientado a objetos?
Lista de livros
DESENVOLVIMENTO DE JOGOS ELETRÔNICOS – 2° Edição
Autor: Perucia, Alexandre
Editora: Novatec
Preços
MATHEMATICS AND PHYSICS FOR PROGRAMERS
Autor: Kodicek, Danny
Editora: Charles River Media
Preços: Não pesquisei, comprei no Amazon.com
DESIGN DE GAMES – UMA ABORDAGEM PRÁTICA
Autor: Schuytema, Paul
Editora: Cengage Learning
Preços