quarta-feira, 2 de maio de 2012

DOCUMENTAÇÃO
Documento de Arquitetura do Jogo (1 – 5)

Seguindo com o assunto de documentação do nosso Documento de Arquitetura do Jogo, neste post irei especificar como abordamos os 5 primeiros tópicos do referido documento.

Introdução
Usamos este tópico para reafirmar que se trata de um projeto interdisciplinar e expormos as metas desejadas pela equipe.
Posicionamento
Colocamos nosso posicionamento diante do projeto e objetivo, além de uma breve descrição do jogo e sua mecânica.
Público Alvo
Descrição do público alvo com base no jogo original.
Ambiente do Jogo
Indicação das ferramentas utilizadas para implementação e gerenciamento do projeto., tal como método ágil, linguagem e bibliotecas,
Requisitos do Jogo
Com o estudo em sala da teoria e exemplos conseguimos reunir os requisitos funcionais e não funcionais necessários para o desenvolvimento de todo o projeto e os organizamos em uma lista com tópicos e sub tópicos com as telas, os menus, opções e o que achamos necessário para a estrutura no geral de acordo com as pesquisas do Game Design do jogo original.

Falarei mais sobre o Documento de Arquitetura do Jogo em posts futuros!

Escopo geral da documentação

Olá!

Neste post serão apresentados os aspéctos da parte mais burocrática do projeto, a documentação!
Como já dito nosso projeto é interdisciplinar e toda a parte de documentação se refere à disciplina de Projetos de Jogos. É nela que aprendemos as metodologias na teoria e na pratica através de exercícios de fixação e exercícios focados no próprio projeto.
Com este aprendizado adquirido, nos foi proposto a realização do Documento de Arquitetura do Jogo que possui a seguinte estrutura:

1.Introdução
*A introdução fornece uma visão geral de todo o documento

2.Posicionamento
*Descrição do jogo, onde este será inserido.

3.Público Alvo
*Descreve o público alvo

4.Ambiente do Jogo
*Detalhe o ambiente de trabalho, ferramentas usadas para implementação do jogo.

5.Requisitos do Jogo
*São todos os requisitos necessários para a realização do jogo, desde a implementação até o resultado final satisfatório ao jogador.
    5.1 Requisitos Funcionais
*Todos os requisitos que são esperados pelo mercado e público alvo do jogo a ser implementado.
    5.2 Requisitos Não - Funcionais
*Qualidade e Restrições que o jogo pode ter, por exemplo, uso de novos dispositivos de interação entre jogo e jogador ou uma restrição de poder utilizar só uma determinada linguagem pra implementação.

6.Estimativa de Desenvolvimento
* Descreve a estimativa de duração das atividades do desenvolvimento do jogo em detalhes.


7.Diagrama de Casos de Uso
*Apresenta o diagrama de Casos de Uso do Jogo

8.Realização de Caso de Uso
*Descreve as realizações para cada Caso de Uso identificado no diagrama de casos de uso.

9.Diagrama de Atividades
*Apresenta o digrama de atividades do jogo.

10.Diagrama de Classes e Objetos
Apresenta o digrama de classes e o diagrama de objetos do jogo.

11.Diagramas de Sequência e Colaboração
Apresenta os diagrama de sequência e os diagramas de colaboração do jogo.

12.Diagrama de Máquina de Estados
Apresenta os diagramas de máquina de estados do jogo.

 13.Diagrama de Componentes, Pacotes e Implantação
Apresenta os diagrama de componentes, pacotes e implantação, se necessários.

14.Telas do Jogo
Apresenta as telas do jogo.


Nos próximos posts estarei especificando qual a abordagem utilizada nos tópicos já finalizados deste documento!

terça-feira, 1 de maio de 2012

Arte Inicial

Olá!

Neste post apresento nossas primeiras ideias e algumas criações sobre a "cara" do jogo, a Arte!

Como combinamos em Game Design optamos em utilizar o máximo da arte original na nossa versão digital com poucas adaptações.

Cartas:

As cartas são as mesmas da versão do tabuleiro, apenas foram colocadas em uma mesma imagem com as devidas divisões para serem utilizadas como sprites na implementação. A novidade está no verso que foi personalizado no estilo do menu  criado por nós.

(Figura 1 – Cartas originais + fundo personalizado)

(Figura 1 – Cartas originais + fundo personalizado)


Menu:

Já o menu optamos em fazer totalmente personalizado utilizando o tema de viagens de trem com um toque de cenário europeu que pode ser visto na vegetação representada pelos pinheiros e na neve derretendo ao fundo e nas montanhas, além de uma pré conceitualização realizei algumas pesquisas para confirmar esses elementos. Todo o cenário foi desenhado no Corel X12 com o mouse utilizando ferramentas básicas como o lápis, pincel, efeitos de transparência e mistura de cores para dar um ar de pintura à ilustração.

Figura 2 – Primeiro ‘Rabisco’ sobre o Menu)
Figura 2 – Primeiro ‘Rabisco’ sobre o Menu)


A ideia é utilizar paralaxe na animação do menu, por isso toda a arte foi feita com os elementos separados em camadas para a implementação.


(Figura 3 – Menu)
(Figura 3 – Menu)



O layout do jogo, como já comentado no post sobre Game Design, será baseado na versão digital do game já existente com dimensões de 1.024 X 768. Pretendemos personalizar os 5 diferentes personagens de escolha pelo player e suas huds se possível no prazo de entrega.



(Figura 4 – Testes e Molduras e Hud personagem)


(Figura 4 – Testes e Molduras e Hud personagem)





Também utilizaremos como peças os vagões originais de plástico convertidos em uma imagem. Para a implementação será utilizada essa imagem que consiste em um vagão de cor branca, alterado através de programação para a cor do player que irá utiliza-lo.
Surgiu uma ideia de colocarmos na primeira casa de um trilho uma peça de locomotiva, se possível será implementado.

Na Figura 5 podemos ver testes de peças tanto com vagões azuis quanto com somente locomotivas:


(Figura 5 – Testes das peças de trem)



(Figura 5 – Testes das peças de trem)


Essa é a base sobre arte, em breve novos posts com as novidades!

Nova Cara do Blog

Olá pessoal

O blog agora tem uma nova cara! Está pesonalizado e original...
Espero que tenham gostado!

Abraço

Game Design

Usarei este post para descrever como foi o estudo inicial do Game Design original do jogo “Ticket to Ride Europe”, sendo este o alvo do nosso projeto.
Para melhor entender o jogo tivemos a oportunidade de jogar a versão de tabuleiro em algumas aulas, o que possibilitou uma interação abrangente da mecânica do mesmo e  maior clareza de suas regras na pratica. 

(Figura1 - Tabuleiro Original de "Ticket to Ride Europe")


(Figura2 - Cartas Originais de "Ticket to Ride Europe")
(Figura2 - Cartas Originais de "Ticket to Ride Europe")


Para complementação da experiência na prática fiz uma pesquisa sobre o jogo na internet e destaco o site http://desbussolados.blogspot.com.br/2012/02/ticket-to-ride-europe.html onde tive a oportunidade de ler uma resenha e as regras em português de “Ticket to Ride Europe “.
A experiência adquirida jogando e os dados pesquisados nos possibilitou desenvolver o Game Design para o nosso projeto que na verdade é seguir o do original com adaptações para o game digital. Utilizaremos as mesmas regras e procuraremos seguir o mesmo conceito de arte, inclusive utilizando as  originais e adaptando o que for necessário.Uma mudança sugerida pelos próprios professores foi a de fazer os trilhos somente utilizando retas.

Também achei exemplos do jogo já implementado digitalmente e decidimos utilizar este modelo de HUD para o nosso projeto: 

Modelo Layout
(Figura 3 - Modelo Layout )

Também pensamos na possibilidade de utilizar um mapa mundi com estações em países de destaque, o que demandou mais pesquisas mescladas com balanceamento, já que as estações precisam ficar em uma distancia favorável para fazer as ligações de modo que possibilite um design atrativo, com um balanceamento eficaz,  sem deixar de lado cidades em destaque, o que se tornou um problema na região da Europa e outras ondem certas estações iriam ficar muito próximas... Mas, ainda está no projeto otimizar um mapa mundi a fim de utiliza-lo no game.

Resumos das Pesquisas:
ESCOLHA DE ESTAÇÕES NO MAPA MUNDI

Critérios:
           As 30 maiores (população) capitais do mundo
           + 15 Melhores cidades para se viver (fora Sidney que está inclusa na primeira lista)
           + RJ, SP e Curitiba.

Total 47 Estações


Testes de Estações no Mapa Mundi
(Figura 4 -Testes de Estações no Mapa Mundi)


Bom, por hora é isso. Até a próxima ;)

segunda-feira, 30 de abril de 2012

paCamera, Vector3D e texturas

Funcionando o desenho em OpenGL, as próximas preocupações envolveram como fazer o jogo funcionar, ou seja, lidar com as matrizes OpenGL e com as transformações de translação, rotação e escala.
A forma elegante com que implementei algumas funcionalidades de modo a facilitar a manipulação dessas matrizes pelo usuário foi retornar o ponteiro this a fim de cada método envolvendo a conversão de matriz e transformação poder ser mais bem organizado. Para exemplificar, observe o código abaixo:

//Seta a projeção utilizada (perspectiva)
jogo->setProjectionMatrix()->setIdentity()->setPerspectiveProjection(fov,1.5,20.0);
//Matriz de transformação
jogo->setModelViewMatrix()->setIdentity();
//Transformação e desenho de uma esfera
glPushMatrix();
             jogo->translate(2,0,0)->rotate(angle+1,0,1,0);
             glColor3f(0.8,0.3,0);
             glutWireSphere(0.5,30,10);
glPopMatrix();

Essa implementação foi feita com algumas dependências e modularizações erradas. Ainda pretendo planejar melhor o funcionamento das mesmas.

Ainda implementei uma classe de câmera que chamei de paCamera. Esta classe basicamente contém o update da câmera e os cálculos para strafe, movimentação para frente e para trás e rotação da câmera conforme o mouse. Para o cálculo matemático, integrei as classes de vetores desenvolvidas pelo professor Vinicius Mendonça. Essa classe de câmera ainda necessita de alguns ajustes, mas com essas implementações ja foi possível oferecer um bom controle da câmera para jogos em geral.

Por fim, as ultimas implementações da engine foram as envolvendo o desenho de texturas. Para tal tive que levar em consideração que a SDL carrega as texturas invertidas. A solução foi inverter os píxels um a um e recalcular seu RGB em um código que demorei dias para entender com perfeição. Entender esse código me fez conhecer melhor os recursos que tornam a SDL uma lib tão poderosa para tratamento de imagens.
O suporte para conversão da textura é implementado em paSDL e o próprio carregamento em paOpenGL.

Em geral essas foram as primeiras implementações. Muita coisa falta ser implementada e modificada ainda. A forma como será desenvolvido o projeto ao longo das semanas será melhor explicado pela Keli nos próximos posts.

Até lá...

paOpenGL

Fazendo uma retrospectiva do que foi implementado, a engine possui:

1- Uma classe denominada paSDL, responsável por gerenciar recursos básicos em SDL, como criação de surfaces, desenho de surfaces e controle de game loop.

2- Uma classe denominada paSDLSprite, responsável por desenhar sprites com quadros.

3- Uma classe denominada paGameLoop, responsável por oferecer uma interface semi implementada para classes de game loop para aqueles que desejam uma abordagem mais complexa para seu jogo.

Agora vou falar sobre a implementação inicial da classe OpenGL denominada paOpenGL.

O plano é utilizar a engine, além do projeto "Ticket to Ride", também para o projeto de Computação Gráfica, ou seja, ela deve possuir um mínimo de suporte 3D.

O plano inicial foi integrá-la à paSDL, de forma que a engine OpenGL tratasse o modo de desenho SDL quando esta estivesse em cena. As primeiras alterações necessárias envolveram pensar em como os métodos continuariam sincronizando e limpando a tela, mas em OpenGL. Para tal, pensei em um sistema de heranças em que paOpenGL é uma paSDL, levando em consideração o desenho. Provavelmente essa estrutura necessitará de novas modularizações, mas por enquanto está suficiente para resolver o problema.
Na abordagem utilizada, portanto, esquematizei que a janela é criada na paSDL e é configurada na paOpenGL. As principais configurações envolvem limpeza dos buffers, escolha da cor de limpeza da tela padrão, habilitação do teste de profundidade e posicionamento da área de desenho (view port).

Ainda criei métodos de retorno de strings contendo nome da placa de vídeo e seu vendedor, e também da versão OpenGL usada; método para seleção da qualidade de renderização e escolha do modo de shade.

Essas alterações ja possibilitaram o desenho usando OpenGL na tela.

No próximo post falarei das últimas integrações feitas na engine antes da data de criação do blog.