A coordenação do curso de Especialização em Engenharia de Software com Ênfase em Padrões de Software da UECE tem o prazer de convidá-lo para a Defesa de Monografia do aluno David de Almeida Ferreira, intitulada “Catálogo de Padrões para Jogos”. A defesa ocorrerá no dia 14/06/2010 (segunda-feira) a partir das 16:00 no prédio da Pós-graduação e Pesquisa em Computação da UECE. Continue reading »
out 282008
Blz!
Para mostrar a um amigo, alguns dos jogos/demos que estou desenvolvendo, coloquei no youtube dois videos, mas cuidado!, É uma super produção caseira 
Para quem não conhece temos, o Pancada, o famoso jogo de boxing, que um dia vou terminar, pior que só esta faltando coragem pra fazer a pseudo-ia do jogo 
E o TechDemo, Caveman (que nome original), o qual é a base de futuros testes para o desenvolvimento de jogos estilo plataforma, existe alguns problemas relacionados a movimentação, regras de saltos, movimento de queda, mas em fim, é o começo
abr 022008
Foi lançado recentemente o FZpong 2.0, o qual faz parte do CDLivre 3.0[1].
O FZPong[2] é um pong com versões para MS-Windows e GNU/Linux, desenvolvido em SDL[3] / GBF[4] e licenciado em GPL, ou seja, você pode estudar o código fonte do FZPong para aprender a programar jogos para computador.
Se antes tudo parecia fácil, agora no FZPong 2.0 as coisas já não estão tão simples assim, o computador ganhou uma nova e melhorada percepção do jogo e que em alguns momentos vai lhe exigir bons reflexos e o uso de estratégias para conseguir vencer.
Como melhorias nesta nova versão temos:
- Suporte a internacionalização, agora o jogo está disponível em português e inglês;
- Melhoria na inteligência artificial do computador;
- Aplicação de novos efeitos na bola de acordo com o local da rebatida;
- Modificação das regras do jogo;
- Melhorias no aspecto visual dos textos e janelas de mensagens;
———————————————-
Referência
[1]http://cdlivre.wordpress.com
[2]http://pjmoo.wiki.sourceforge.net/FZPong
[3]http://www.libsdl.org
[4]http://pjmoo.wiki.sourceforge.net/GBF
[5]http://davidferreira-fz.blogspot.com/2007/06/fzpong.html
nov 232007
Blz!
Na especialização estou começando a disciplina de padrões, e como ficou acertado que para prova o livro base é nada mais nada menos que o do GoF(Padrões de Projeto)[1], então resolvi estudar de uma forma diferente.
Irei implementar os padrões tendo como base o primeiro exemplo apresentado (o labirinto), para isso tive que fazer algumas adaptações nas classes básicas e incluir alguns recursos do framework GBF[2], sendo assim além de apresentar para vocês a implementação dos padrões de quebra ainda vai a utilização do framework GBF[2].
Irei implementar os padrões tendo como base o primeiro exemplo apresentado (o labirinto), para isso tive que fazer algumas adaptações nas classes básicas e incluir alguns recursos do framework GBF[2], sendo assim além de apresentar para vocês a implementação dos padrões de quebra ainda vai a utilização do framework GBF[2].
Antes de começar a publicar os padrões, resolvi montar um exemplo base, para termos idéia de como era a implementação inicial e como ela irá evoluir com o uso dos padrões.
Sendo assim pretendo na medida do possível publicar padrão por padrão.
Lembre-se para poder melhor aproveitar o exemplo você necessita:
- IDE:
- CodeBlocks[3] (Linux e MS-Windows)
- Compilador
- Linux: GCC
- MS-Windows: MinGW[4]
- Modelagem UML
- BoUML[5]
- Bibliotecas:
- SDL (SDL_Image, SDL_Mixer)[6];
- GBF;
- Programar em C++
- Exemplo:
Podemos observar abaixo o diagrama de classes do exemplo
- Classes Cinzas: São do Framework GBF[2];
- Classes Verdes: É o núcleo principal do exemplo, são as classes que dão suporte para implementação de salas, paredes e portas;
- Classe Vermelha: É a enumeração usada para definir os lados da sala;
- Classe Laranja: É a responsável por armazenar o labirinto;
- Classe Amarela: É a classe que monta o labirinto;
A seguir podemos ver as classe da visão de dependência, ou seja, como é o relacionamento de fato com relação aos includes (headers) e a classe que vai executar nosso exemplo:
Essas classes seguem o mesmo código da legenda anterior, a única modificação é a inclusão da Classe Rosa, que contém o método “int main” para executar nosso exemplo.Pois é, podemos criar uma classe que irá gerar o método main
, digamos assim quase imitando o principio do método main da linguagem em java Abaixo podemos ver o resultado da execução do nosso exemplo:
T+!
Vida Longa e Próspera!
———————————————-
Referência
[1]http://pt.wikipedia.org/wiki/Padr%C3%B5es_de_projeto_de_software
[2]http://pjmoo.wiki.sourceforge.net/GBF
[3]http://www.codeblocks.org
[4]http://www.mingw.org/
[5]http://bouml.free.fr
[6]http://www.libsdl.org
[7]http://downloads.sourceforge.net/pjmoo/GoF.zip
out 252007
Blz!
Conforme foi sugerido, um amigo perguntou o que de fato era a interface gráfica que eu havia desenvolvido, então resolvi falar um pouco sobre ela e mostrar a versão atual que agora é parte integrante do framework GBF (Gamework’s Brazilian Framework).
O GBF é um framework em C++, criado para o desenvolvimento de jogos 2D (jogos estilos: nes/snes e mega), seu foco é no uso da programação orientada a objetos além de ser multiplataforma (é compatível para compilação em ms-windows e gnu/linux) e poder ser utilizado em jogos que exijam pouco hardware, confesso que posso estar saindo deste trilho, mas por vez ou outra, volto para otimizar o framework e testa-lo no outro pc que tenho (AMD K6-II 500mhz / 192mb RAM / GeForce 2 MX 400 64 mb).
Tem algum tempo que voltei a mexer no projeto “pancada”, o qual nasceu junto com o framework (por volta de 2004) porém ficou meses(anos) parado e surgiu a necessidade de eliminar aquela codificação chata de preparar as janelas de dialogo, como aquelas telas de vitória, créditos e afins.
Sendo assim comecei a rascunhar (como pode ser visto nos links no final deste post) algumas possibilidades para criação de uma interface gráfica bem simples, que visavam só apresentar um texto dentro de uma área de tela, a qual chamei de janela, e que algumas vezes tivesse um botão “OK” para fechar, para não inchar o desenvolvimento com mil e uma possibilidades, tomei como política básica o de desenvolver/suportar apenas o que de fato é necessário, tentando assim talvez otimizar e ganhar um pouco de performance, futuramente pode ser que adicione outros botões (como os utilizados em jogos de RPG/Quests) por hora não é o foco.
Vamos para de enrolar, e mostrar logo como a coisa funciona.
Abaixo podemos ver o diagrama de classes das janelas
O que de fato acontece é que o desenvolvedor utilizando o framework faria apenas isto:
//Criando um padrão visual com janela transparente - segue o pattern Prototype (GoF)
UserInterfaceVisualImagem *uiVisualImagem = new UserInterfaceVisualImagem();
uiVisualImagem->setCorBorda(255,0,0);
//ou caso seja o desejo utilizar uma janela de cor solida (fundo de uma única cor)
//sendo necessário apenas passar para o método "setVisual".
UserInterfaceVisualSolido * uiVisualSolido = new UserInterfaceVisualSolido();
uiVisualSolido->setCorBorda(255,0,0);
uiVisualSolido->setCorFundo(100,200,100);
UserInterfaceWindowTitulo *janelaAjuda;
janelaAjuda = new UserInterfaceWindowTitulo();
janelaAjuda->setPosicao(40,50);
janelaAjuda->setDimensao(560,400);
janelaAjuda->texto.setFonte("texto");
janelaAjuda->texto.setChaveTexto("tela_ajuda_%02d");
janelaAjuda->titulo.setFonte("menu");
janelaAjuda->titulo.setChaveTexto("titulo_ajuda");
janelaAjuda->setVisual(uiVisualImagem->clone());
janelaAjuda->adicionarBotao(new UserInterfaceBotao("menu","botao_enter",SDLK_RETURN));
janelaAjuda->inicializar();
UserInterfaceVisualImagem *uiVisualImagem = new UserInterfaceVisualImagem();
uiVisualImagem->setTipoBackground(BACKGROUND_LINES);
uiVisualImagem->setCorBorda(255,0,0);
UserInterfaceWindowTitulo janelaCredito = new UserInterfaceWindowTitulo();
janelaCredito->setPosicao(40,50);
janelaCredito->adicionarBotao(new UserInterfaceBotao("menu","botao_enter",SDLK_RETURN));
janelaCredito->inicializar();
janelaCredito->setDimensao(560,400);
janelaCredito->texto.setFonte("texto");
janelaCredito->titulo.setChaveTexto("titulo_credito");
janelaCredito->setVisual(uiVisualImagem->clone());
janelaCredito->titulo.setFonte("menu");
janelaCredito->texto.setChaveTexto("tela_credito_%02d");
A classe “UserInterfaceVisualImagem”, provê o efeito do fundo da janela, o qual aparenta ser transparente, talvez até por meio do canal “alpha”, porém muito pelo contrario, a questão é muito simples, ele desenha no fundo da janela uma imagem, que possui alguns pontos que são transparentes, definido pelo que chamamos de colorkey, onde uma cor(RGB) é mapeada para não ser desenhada, no caso o mais comum é a magenta RGB(255,0,255), essa é uma técnica simples que possivelmente é mais rápida para desenhar que a utilização do canal alpha, ganhando talvez alguns pontos de performance. A figura em questão que possui alguns padrões de “transparência” pode ser vista abaixo, e a seleção de qual utilizar é baseada na enumeração “UserInterfaceVisualTipoBackground”.
Na classe “UserInterfaceWindow” e “UserInterfaceWindowTitulo” existe os atributos “texto” e “titulo” o qual possibilita a utilização do recurso de “localização”, que é a mudança de idioma nos textos de acordo com o sistema operacional do usuário(no caso o jogador), para finalizar o método “inicializar” realiza os ajustes finais para determinar algumas características que devem ser executadas apenas uma vez ou o menos possível.
Após entender assim, mesmo por cima o que deve ser feito, temos a parte importante que é “Como de fato eu uso e desenho a janela”, bem para isso vou mostrar o código:
void Jogo::menuCredito()
{
rameLayerManager::getInstance()->getFrameLayer("background")->desenhar();
janelaCredito->executar();
if (janelaCredito->isBotao(UserInterfaceWindow::BOTAO_OK)){
setMenuPrincipal();
}
Este metodo “menuCredito” é provido por meio de uma classe chamada GAT (GBF Application Template) a qual tem o uso apenas recomendado, de fato começa a oferecer uma estrutura pronta para utilização do GBF.
Neste método podemos observar uma chamada ao “FrameLayerManager” (é um singleton), no caso esta chamada é apenas pq queríamos desenhar o cenário do jogo abaixo da nossa janela. (Ver Figura 1)
O desenho de fato da janela é feito pelo método executar, o qual cuida de renderizar o que for necessário da janela e seus componentes. (Ver Figura 2)
O método “isBotao” verifica se o botão “OK”, único suportado no momento foi acionado ou não, (o botão responde pelo código das teclas definida no SDL), onde caso seja acionado executará os comandos informados (Só a título de curiosidade este método faz o sistema de máquina de estados do GAT retornar ao exibição do menu principal).
Para finalizar podemos entender que o que chamamos de janela, basicamente é uma região da tela, a qual podemos fazer alguma manipulação, no caso da GBF e do Pancada tudo que necessitamos é desenhar as bordas da janela, uma imagem de fundo com efeito de “transparência”, que seja capaz de exibir alguma mensagem(texto e título) e que possa responder ao acionamento de algum botão.
Caso tenham interesse em saber mais detalhadamente como funciona ou detalhes da implementação podem entrar em contato
Figuras Anexas
Figura 1: Tela do Menu Principal
Figura 2: Tela de Crédito
T+!
Vida Longa e Próspera!
———————————————-
Referência
[1]http://davidferreira-fz.blogspot.com/2007/09/gbf-interface-grafica-v05.html
[2]http://davidferreira-fz.blogspot.com/2007/09/rascunho-de-interface-grfica.html
[3]http://pjmoo.wiki.sourceforge.net/
[4]http://pjmoo.wiki.sourceforge.net/GBF
[5]http://www.libsdl.org
set 172007
Blz!
Dando continuidade ao desenvolvimento da interface gráfica para as mensagens no Pancada[1], consegui um novo rascunho de classes as quais possuem uma abstração mediana, visto que resolvi especializar conforme a demanda, para não adicionar tantas classes no framework GBF[2] que acabem não sendo uteis, apresento abaixo o resultado das novas classes de interface gráfica e um pequeno exemplo do que mudou na forma de se fazer as “caixas de mensagens”, as quais são bem simples porém era chato de fazer.
//Criando um padrão visual com janela transparente - segue o pattern Prototype (GoF)
UserInterfaceVisualImagem *uiVisualImagem = new UserInterfaceVisualImagem();
uiVisualImagem->setCorBorda(255,0,0);
//ou caso seja o desejo utilizar uma janela de cor solida (fundo de uma única cor)
//sendo necessário apenas passar para o método "setVisual".
UserInterfaceVisualSolido * uiVisualSolido = new UserInterfaceVisualSolido();
uiVisualSolido->setCorBorda(255,0,0);
uiVisualSolido->setCorFundo(100,200,100);
UserInterfaceWindowTitulo *janelaAjuda;
janelaAjuda = new UserInterfaceWindowTitulo();
janelaAjuda->setPosicao(40,50);
janelaAjuda->setDimensao(560,400);
janelaAjuda->texto.setFonte("texto");
janelaAjuda->texto.setChaveTexto("tela_ajuda_%02d");
janelaAjuda->titulo.setFonte("menu");
janelaAjuda->titulo.setChaveTexto("titulo_ajuda");
janelaAjuda->setVisual(uiVisualImagem->clone());
janelaAjuda->adicionarBotao(new UserInterfaceBotao("menu","botao_enter",SDLK_RETURN));
janelaAjuda->inicializar();
Onde o uso da janela criada se da da seguinte forma:
void Jogo::menuAjuda()
{
FrameLayerManager::getInstance()->getFrameLayer("background")->desenhar();
janelaAjuda->executar();
if (janelaAjuda->isBotao(UserInterfaceWindow::BOTAO_OK)){
setMenuPrincipal();
}
}
Para efeito de comparação logo abaixo um exemplo de como era criada a tela do menu ajuda:
void Jogo::menuAjuda()
{
char textoFormatado[30];
FrameLayerManager::getInstance()->getFrameLayer("background")->desenhar();
for (int i=0; i>;11;i++){
writeSystem->escreverLocalizado("texto",70,120+(26*i),textoFormatado);
}
frameworkGBF->writeSystem->escreverLocalizado("menu", 220, 88,"titulo_ajuda");
if (desenharBotaoEnter()){
if ((frameworkGBF->inputSystem->teclado->isKey(SDLK_RETURN))
|| (frameworkGBF->inputSystem->joystick->isButtonA())){
setMenuPrincipal();
}
}
}
Logo abaixo:
- Janela com fundo transparente
- Janela com Fundo em cor Sólida
E para matar a curiosidade o novo rascunho do diagrama de classes “ainda não integrante do GBF” pode ser visto abaixo:
T+!
Vida Longa e Próspera!
———————————————-
Referência
[1]http://pjmoo.wiki.sourceforge.net/Pancada
[2]http://pjmoo.wiki.sourceforge.net/GBF
Blz!
Faz um bom tempo que não publico nenhuma novidade sobre meus projetos, porém isso não significa que eles estão parados, muito pelo contrario, é tanta coisa pra fazer que não está sobrando tempo pra ficar atualizando.
Tem algumas semanas que voltei a trabalhar no Pancada (assim que possível publico alguma coisa sobre ele), e comecei a ter a velha dificuldade de montar aquelas telas (créditos, ajuda, sobre, final de fase, gameover e etc), então resolvi criar vergonha na cara e comecei a rascunhar componentes que facilitassem minha vida para montar uma espécie de caixa de texto, que nada mais é do que exibir um texto na tela.
Abaixo é possível ver o modelo uml (rascunho) do que vai se torna parte integrante do GBF, porém, só passa de fato para o framework após validação inicial com um projeto, o que deve acontecer nos próximos dias (ou semanas) ai então irá compor o framework e servir de base para um refatoramento das classes de interface Gráfica ou seja classes da série “UserInterface” do GBF.
T+!
Vida Longa e Próspera!
jun 252007
Como mencionei anteriormente, foi criado um grupo de estudos sobre desenvolvimento de jogos na UFC, o DoG[1], e mensagens indo e vindo, foi sugerido pelo Felipe Ribeiro (Moderador do Grupo), que as pessoas participantes com ou sem experiência tentassem desenvolver um jogo/demo para que pudéssemos trocar idéias sobre implementação, dúvidas, curiosidades e dificuldades que surgissem no decorrer do desenvolvimento.Para tentar encontrar pontos comuns para troca de experiência foi proposto dois temas, sendo eles o desenvolvimento de um “Pong” ou de um “Tetris”, e logo em seguida tivemos o primeiro post com o primeiro jogo, era o Pong do Charles[2], o qual de fato acabou servindo de incentivo para mim, e me levou a pensar:
Poderia desenvolver um, serviria tanto pra validar as últimas modificações no GBF[3], quanto a aprender algumas coisas legais e ainda ter a oportunidade de conversar de igual pra igual com as pessoas(já que também era uma experiência nova para mim).
E assim, motivado pela empolgação, desafio e pelo bate-papo, fui levado a desenvolver meu primeiro pong, meio tardiamente, mas fui, e realmente é como falo nas minhas palestras, é uma experiência legal, divertida, simples e viciante, pensei em adicionar mil coisas nele, como sistema de partículas e afins, mas resolvi deixa-lo o mais simples e fiel ao tradicional possível para que quem sabe sirva de exemplo para implementações de quem gostaria de começar a programar jogos.
Experiência
Apesar de já ter desenvolvido o framework GBF[3], e outros demos, não havia feito coisas de concepção simples e divertidas como o pong, e tive que pensar um pouco em como implementar um pong, algumas dúvidas que tive antes e durante o desenvolvimento foram:
- Como fazer a bolinha rebater na tela;
- Como fazer com que o CPU jogasse sem acertar todas e que não fosse totalmente burro;
- Como delimitar a duração do jogo;
Respondendo as essas perguntas comecei então a procurar minhas saídas:
“Como fazer a bolinha rebater na tela”
Fazem anos que não via física, e cheguei a pensar em algo complexo como mudar a 
direção da bolinha por meio de ângulos, seno, cosseno e etc. Acabei procurando um livro de física para lembrar conceitos relacionados a mecânica, como movimentos uniformes, e etc, pois não lembrava mais nada disso, e nem sabia ao certo se isso resolveria, o fato é que o livro que recorri não era muito explicativo, na verdade era apenas exercícios (esses livros de hoje, parecem não serem feitos para que as pessoas aprendam sozinhas), comecei a ler, e reler, porém não consegui ver de fato a aplicação para o meu caso especifico, o qual seria apenas fazer a bolinha se desviar ou voltar. Sendo assim comecei a procurar pelo Google na esperança de achar alguns sources e acabei foi de fato achando um tutorial/apostila do Silveira Neto[7] (hehehe logo do Silveira, tão próximo e tão longe, ele também é daqui de Fortaleza, tive que ir na Internet para achar o que precisava), e lá tinha justamente o exemplo de uma bola sendo rebatida, aproveitei isso e adaptei para o pong. O fato é que a solução era super simples e eu procurando complicações físicas, bastava no caso inverter os valores de x e y para o que a bolinha voltasse na direção oposta exemplo:
direção da bolinha por meio de ângulos, seno, cosseno e etc. Acabei procurando um livro de física para lembrar conceitos relacionados a mecânica, como movimentos uniformes, e etc, pois não lembrava mais nada disso, e nem sabia ao certo se isso resolveria, o fato é que o livro que recorri não era muito explicativo, na verdade era apenas exercícios (esses livros de hoje, parecem não serem feitos para que as pessoas aprendam sozinhas), comecei a ler, e reler, porém não consegui ver de fato a aplicação para o meu caso especifico, o qual seria apenas fazer a bolinha se desviar ou voltar. Sendo assim comecei a procurar pelo Google na esperança de achar alguns sources e acabei foi de fato achando um tutorial/apostila do Silveira Neto[7] (hehehe logo do Silveira, tão próximo e tão longe, ele também é daqui de Fortaleza, tive que ir na Internet para achar o que precisava), e lá tinha justamente o exemplo de uma bola sendo rebatida, aproveitei isso e adaptei para o pong. O fato é que a solução era super simples e eu procurando complicações físicas, bastava no caso inverter os valores de x e y para o que a bolinha voltasse na direção oposta exemplo:if (bola.y>480){
velocidade.y = – velocidade.y;
}bola.y+=velocidade.y;
Isso faz com que se a bolinha bater no fundo da tela, volte. Simples não ? pra mudar a direção de X, basta fazer a mesma operação com o eixo X.
“Como fazer com que o CPU jogasse sem acertar todas e que não fosse totalmente burro”
Minhas primeiras idéias foi tentar fazer algo randomico que, quando a bolinha passase do meio da “quadra”, fosse feito um random para determinar se o cpu iria ou não pegar a bola, porém isso pareceu que ia ser baseado muito na sorte e que não ficaria muito natural, então antes de testar, resolvi abandonar a idéia.
Acabei lembrando do PacZero[4], e que eu havia implementado um algoritmo de colisão circular para determinar quando os fantasmas podia “ver” o pacman, e resolvi aplicar o mesmo principio, sendo assim, resolvi criar uma circulo de visão para o cpu, assim, quando a bolinha entrasse em seu raio de visão ele moveria-se para rebate-la. Porém essa alternativa acabou mostrando que com um circulo de visão grande demais, o cpu não erra, e um pequeno demais ele erra muito, então por meio da tentativa, erro e estimativa defini que seu circulo de visão teria um raio de _VALOR_ pixel, e que conforme o cpu ganhe as partidas maior vai ficando seu circulo de visão para assim dificultar a vida do jogador, porém este ponto não ficou muito natural, tem certos macetes (jogadas) que fazem com que o cpu perca.
Esse é um ponto que está muito aberto as melhorias, visto que ficou altamente simplório o pseudo esquema de I.A. do CPU, pontos que eu talvez mude em versões futuras:
Acabei lembrando do PacZero[4], e que eu havia implementado um algoritmo de colisão circular para determinar quando os fantasmas podia “ver” o pacman, e resolvi aplicar o mesmo principio, sendo assim, resolvi criar uma circulo de visão para o cpu, assim, quando a bolinha entrasse em seu raio de visão ele moveria-se para rebate-la. Porém essa alternativa acabou mostrando que com um circulo de visão grande demais, o cpu não erra, e um pequeno demais ele erra muito, então por meio da tentativa, erro e estimativa defini que seu circulo de visão teria um raio de _VALOR_ pixel, e que conforme o cpu ganhe as partidas maior vai ficando seu circulo de visão para assim dificultar a vida do jogador, porém este ponto não ficou muito natural, tem certos macetes (jogadas) que fazem com que o cpu perca.
Esse é um ponto que está muito aberto as melhorias, visto que ficou altamente simplório o pseudo esquema de I.A. do CPU, pontos que eu talvez mude em versões futuras:
- Fazer com que o cpu se “distraia”, ou que “fique confiante demais” e só vá atrás da bola na última hora, o que causaria o efeito de incerteza se ele acertaria ou não
- Fazer com que ele decida onde bater na bola, use as três partes da raquete para provocar efeitos diferentes na bola;
- Fazer com que a visão aumente quando ele perder uma partida, pois assim na será um desafio maior para o jogador;
“Como delimitar a duração do jogo”
Pensando um pouco em como determinar as partidas, acabei me baseando na experiência do projeto de jogo “Pancada”[5](O qual ainda não concluí), que me lembrou do principio de rounds, porém no pancada esses intervalos de partidas são baseados no tempo, e para o FZPong pensei em utilizar o principio de tempo para determinar a duração de cada set, porém acabei chegando a conclusão que seria mais interessante que fosse espelhado em regras como jogos de volley/tenis, assim determinei que para vencer um set, um jogador precisa de ter 5 pontos de vantagem sobre o outro, e para poder vencer a partida, é necessário que um jogador tenha 2 sets de vantagem sobre o outro.
É algo que pode parecerer estranho, a definição desses valores, visto que 5 pontos podem ora parecer muito, mas se levarmos em consideração a Inteligência do “CPU” é algo que fica plausível visto que a velocidade da bola está programada para ir aumentado gradativamente e assim oferecer um desafio mais equilibrado para o jogador.
FeedBack
Esse é um aspecto muito importante, principalmente quando estamos desenvolvendo nos primeiros jogos, protótipos ou quando queremos repassar o conhecimento para as pessoas, por meio deles podemos fugir um pouco da realidade “técnica” e ver quais as reações de jogadores ou de outros desenvolvedores.
Por meio de um desses feedback do Daniel R. Matos do grupo DoG, foi que caiu a ficha de como a figura(sprite) que eu estava usando para representar a bola no jogo estava fora de contexto, isso se deve pq quando iniciei pensei em recriar como o pong fosse um jogo de futebol, porém com meus “grandes dons artísticos”, acabei extrapolando e indo para outra idéia bem oposta, algo que fosse meio que técnico e meio rudimentar, tanto é que podemos observar que as partes da arena do jogo (parte de cima e de baixo) são feitas de pedra, e o fundo do jogo é algo meio confuso/abstrato porém lembra como se fosse um possível gramado e os dois bastões(jogadores/raquetes) são metálicos, e realmente a bola tradicional de futebol ficava destoando o contexto, então depois de receber esse apontamento, corri para o Google a procura de um tutorial(Esfera 3D)[6] que ensinasse como fazer esferas no gimp.
Isso resultou na nova versão do jogo 1.1 só por causa da bola do jogo que agora é uma “esfera metálica” ou similar, bem assim espero eu.
Espero que esse relato possa ajudar ou clarear um pouco o processo de criação do FZPong e que combinado com conversas e o source do jogo possam ajudar no processo de criação e aquisição de conhecimentos relacionados aos jogos.
E por fim temos o download do FZPong[8]:
Código Fonte: FZPong.1.1.src.zip
Versão Linux: FZPong.1.1.bin.linux.tar.gz
Versão MS-Windows e Linux: FZPong.1.1.bin.all.zip
T+!
Vida Longa e Próspera!
———————————————-
Referência
[1] Grupo DoG – http://groups.google.com/group/dog_/
[2] Pong do Charles – http://www.lia.ufc.br/~rockyspirit/pong.tar.bz2
[3] GBF – http://pjmoo.sourceforge.net/wiki/index.php/GBF
[4] PacZero – http://pjmoo.sourceforge.net/wiki/index.php/PacZero
[5] Pancada – http://pjmoo.sourceforge.net/wiki/index.php/Pancada
[6] Tutorial Esfera 3D – http://www.ogimp.com.br/modules/smartsection/item.php?itemid=7
[7] Blog do Silveira – http://www.eupodiatamatando.com
[8] PJMOO Downloads – http://sourceforge.net/project/showfiles.php?group_id=198186
mai 222007
Estava conversando com um amigo sobre desenvolvimento de jogos, quando lembrei do bom e velho SpaceShooter, e o quão ficou “abafado” com o lançamento e a oficialização da última versão a 1.4 por causa causa do CDLivre[4] e do evento FLISOL.
Pois bem, aproveito a oportunidade agora para falar um pouco mais da experiência que o SpaceShooter me deu, além da diversão gerada tanto pela programação como pelo jogo em si.
História
Spaceshooter pra quem não conhece, é um divisor de águas para mim, ele inaugurou minha “nova geração” de jogos, agora produzidos com o framework GBF[5]. É um jogo simples e fácil no clássico estilo shoot’up, o qual foi muito venerado na época dos consoles Nes/SNes/Mega, tendo como base a temática de Star Trek.
O jogador tem como objetivo salvar seu planeta da extinção, e para isso deverá destruir a grande ameaça a nave Base Borg (Cubo Borg). Para poder enfrentar este desafio, o jogador contará com 04 naves estrelares, onde cada uma está melhor adaptada para as diversas zonas, além de contar com um arsenal de phaser e de alguns poucos torpedos. Para sua defesa deverá contar com sua habilidade, a velocidade dos motores de warp, além da força de seus escudos.
O jogo possui 07 fases, onde o jogador terá que enfrentar campos de asteróides, naves inimigas de várias raças, minas espaciais, e diversos outros desafios. Sua missão é destruir a ameaça cibernética, evitando assim que a extinção da raça humana.
Ficha Técnica
- Linguagem
- C++
- Bibliotecas
- Recursos
- Audio Stereo
- Suporte a Joystick
- Teclado
- Gráficos 2D
- Idiomas
- Português
- Inglês
- Espanhol
- Sistema Operacional
- MS-Windows
- GNU/Linux
- Ferramentas
- IDE: CodeBlocks[7]
- UML: BoUML[8]
- Licença
- GPL
Aprendizado
O SpaceShooter, acabou sendo pra mim um grande laboratório, foram creio que quase 2 anos de desenvolvido, mas isso não quer dizer que o SpaceShooter é um jogo complexo ou que foi difícil de ser criado, muito pelo contrario, graças a sua simplicidade consegui superar tantas mudanças, sendo elas:
IDE, o inicio do SpaceShooter, se confundi que o inicio do framework GBF, os dois praticamente foram criados juntos, e se auto influenciaram, passei por muitas IDE, desde proprietárias a diversas soluções livres, só para ter uma idéia nesse projeto trabalhei com:
- MS Visual Studio 6
- DevCPP[9]
- Eclipse CDT (Plugin para C++)[10]
- KDevelop[11]
- CodeBlocks[7]
E minha opção em busca da unificação dos mundos foi o CodeBlocks, onde de fato consegui criar um projeto e utiliza-lo tanto no Linux quanto no MS-Windows, pois as outras IDEs, mesmo as que tinham versões para os dois S.O me obrigavam a criar projetos para cada S.O.
Sistema Operacional, o inicio do meu projeto se deu com MS Windows, e o Linux era utilizado apenas para compilação, e conforme fui me envolvendo com o Software Livre, pude conhecer mais a fundo o Linux e as ferramentas que eu poderia utilizar, graças a utilização de uma IDE completa para os dois mundos, pude inverter minha situação e ter como meu ambiente de trabalho e de uso domestico o Linux e ter o MS Windows apenas para compilação e testes, creio que graças as características do projeto consegui fazer essa migração de SO sem muitos problemas, porém tive que me adaptar as diversas rotinas que o Linux começava a me apresentar, pois eu queria de fato retirar o máximo possível das características do meu hardware e isso envolveu tempo e estudo, porém hoje estou satisfeito utilizando Linux em casa (Slackware 11.0 e comecei a testar o Ubuntu).
Uma coisa que pude constatar, ambiente mais robusto que o Linux e suas ferramentas não creio que tenha, era comum quando tentava depurar alguma coisa no MS Windows ter problemas ou a aplicação abortar, debugar jogos é complicado, e mesmo usando profilers ou qualquer outra ferramenta que tente ajudar a entender como o programa funciona no MS Windows a coisa ficava sempre muito complicada. Sem falar que se consegui compilar e rodar no Linux sem problema a chance de compilar e funcionar no MS Windows é alta, agora o contrario é complicado.
UML, comecei o projeto do GBF com o Power Designer, uma ferramenta proprietária de modelagem UML e de banco de dados, porém era complicado manter o código sincronizado, pois era necessário codificar dentro da ferramenta o corpo dos métodos, e não era fácil e pior que o suporte a estruturas do C++ não era muito bom (enumerações, structs, typedef), fiquei algum tempo utilizando ela, até que ficou inviável manter o projeto codificando e testando e copiando as implementações para a ferramenta, a engenharia reversa não funciona (ou se funcionava era uma porcaria, faz tanto tempo que não lembro), acabou tendo um lacuna muito grande entre os últimos modelos e o código implementado.
Achei que era hora de procurar outras ferramentas, achei uma chamada jumli[12], era uma ferramenta freeware e tinha versões para Linux e Ms Windows, era melhor que o Power Designer, porém possuía alguma limitação que não me recordo muito bem, sei que não me atendia como eu gostaria, creio que tinha algo relacionado com enumerações ou struct, e mais uma vez cai numa lacuna de tempo entre modelo e implementação monstruosa.
Achei que era hora de procurar outras ferramentas, achei uma chamada jumli[12], era uma ferramenta freeware e tinha versões para Linux e Ms Windows, era melhor que o Power Designer, porém possuía alguma limitação que não me recordo muito bem, sei que não me atendia como eu gostaria, creio que tinha algo relacionado com enumerações ou struct, e mais uma vez cai numa lacuna de tempo entre modelo e implementação monstruosa.
Por fim, consegui achar uma ferramenta francesa chamada BoUML, a qual gostei muito, era leve, prática e muito eficiente, atendia quase que perfeitamente minhas necessidades, sem falar que o desenvolver era muito acessível, troquei algumas mensagens no fórum com ele, e minhas dificuldades foram resolvidas, e chegou até ser implementado uma das minha solicitações que era referente aos includes de outras classes ficarem apenas no header(.h) e não no arquivo fonte (cpp), para isso foi criado uma marcação especial que definia isso, ou seja, é uma ferramenta que recomendo, sem falar que com ela é possível mesclar várias coisas comuns em C++ para produzirem a saída conforme eu queria, no caso jogar vários enums, structs num único arquivo, bastava apenas na parte de deploy informar o “artefato de destino”.
Hoje o modelo do SpaceShooter e do GBF estão mais próximos da implementação porém não posso garantir a fidelidade do modelo do SpaceShooter, porém pretendo nas próximas semanas atualizar e finalizar de vez o projeto.
Técnicas, além de tudo isso tive oportunidades de criar novos mecanismos pro framework GBF, além de desenvolver e aprender novas técnicas, das quais posso destacar:
- Classes para gerenciadores de recursos: Audio, Imagens, Teclado, Joystick;
- Classes para interface: Menus, Teclado Virtual (aqueles usados nos jogos de consoles)
- Classes para efeitos especiais como sistema de partículas;
- Classes para Sprite, Layers, Personagens;
- Utilização de Sockets via SDL_net para envio e recebimento de dados com um servidor (na verdade uma página em php que tem acesso a um banco MySQL)
- Utilização de designer patterns para criação do GBF e do SpaceShooter;
Após dois anos de intenso trabalho, ou quase, pois tive muitos períodos que não encostava em nenhuma linha de código desses projetos, consegui concluir este ano o SpaceShooter e entrega-lo para a comunidade, liberando seu source e agora, passando um pouco da experiência vivenciada com o seu desenvolvimento. Espero que esse relato possa ajudar ou direcionar os interessados em conhecer um pouco mais sobre desenvolvimento de jogos.
T+!
Vida Longa e Próspera!
———————————————-
Referência
[1] PJMOO no Código Livre – http://codigolivre.org.br/projects/pjmoo/
[2] Site SpaceShooter – http://pjmoo.codigolivre.org.br/site/spaceshooter/
[3] Wiki SpaceShooter – http://pjmoo.codigolivre.org.br/wiki/index.php/SpaceShooter
[4] CDLivre – http://cdlivre.codigolivre.org.br
[5] Framework GBF – http://pjmoo.codigolivre.org.br/wiki/index.php/GBF
[6] SDL – http://www.libsdl.org
[7] CodeBlocks – http://www.codeblocks.org
[8] BoUML – http://bouml.free.fr
[9] DevCPP – http://www.bloodshed.net/devcpp.html
[10] Eclipse CDT – http://www.eclipse.org/cdt
[11] KDevelop – http://www.kdevelop.org
[12] Jumli – http://www.jumli.de
fev 182007
SpaceShooter 1.4 e GBF 0.6
Blz!
Pessoal acabei de lançar a versão (correções) no SpaceShooter agora na versão 1.4 (e creio que última deste projeto) e a versão 0.6 do GBF (Framework C++ para jogos multiplataforma).
–
SpaceShooter, é um jogo clássico no estilo shoot’up, tendo como base a temática de Star Trek.
Para enfrentar tudo isso, o jogador contará com 04 naves estrelares, onde cada uma está melhor adaptada para as diversas zonas, além de contar com um arsenal de phaser ilimitados e de alguns poucos torpedos. Para sua defesa deverá contar com sua habilidade, a velocidade dos motores de warp, além da força dos escudos. O jogo possui 07 fases, onde o jogador terá que enfrentar campos de asteróides, naves inimigas de várias raças, minas espaciais, e diversos outros desafios. Sua missão é destruir a ameaça cibernética, evitando assim que a extinção da raça humana.
Licença:
SpaceShooter - GPL GBF - LGPL
Mais informações:
Projeto PJMOO no Código Livre
http://codigolivre.org.br/projects/pjmoo/
Site do jogo SpaceShooter
http://pjmoo.codigolivre.org.br/site/spaceshooter/
Wiki do desenvolvimento do SpaceShooter
http://pjmoo.codigolivre.org.br/wiki/index.php/SpaceShooter
