terça-feira, 8 de maio de 2012

Nova organização do projeto no VS 2010

Olá leitor!

Hoje vou falar sobre o processo de organização que o Projeto passou dentro de seu ambiente de desenvolvimento: A IDE Visual Studio 2010!

No início do desenvolvimento da engine, o ambiente estava apenas dividido basicamente em uma pasta para os headers files e outra para os cpp files.
Com o aumento das classes e a integração com a biblioteca de matemática de vetores do professor V. Mendonça, foi necessário criar pastas dentro do projeto que o dividissem em 4 partes:

a) .h paEngine;
b) .h math
c) .cpp paEngine;
d) .cpp math

Para um projeto único, esta abordagem é suficiente. Porém, o que estava acontecendo é que eu utilizava a engine em diversos projetos: TicketToRide, Protótipo3D, Gerador de Mapas e exercícios OpenGL, sem contar as trocas de versão com a Keli.

Consequentemente, como a engine estava em fase de desenvolvimento, diversas alterações se faziam necessárias, resultando em um problema de controle de versão ideal para a engine.
A primeira solução foi trocar o método manual de controle de versão que estavamos utilizando pelo controle usando o GIT, mas ainda sim correriamos o risco de acabarmos esquecendo de atualizar a versão, e toda e qualquer ateraçãozinha acarretaria em uma nova versão também.

A solução que encontrei para o problema foi criar um projeto no Visual Studio do tipo Static Library. Com ele, eu teria a engine focalizada em um único local e o problema de alteração mútua da mesma se resolveria.
Resolvido o problema, ainda de quebra acabei fortalecendo ainda mais o encapsulamento do projeto, e finalmente formalizei a engine em um formato simples para o compartilhamento da mesma com minha colega Keli.

Resolvido o problema maior, ainda tive que dar conta de outro detalhe: Os chatíssimos Includes!!!

Como utilizo mais de um computador para trabalhar, constantemente é necessária a mudança dos endereços das variáveis de ambiente responsáveis por linkar as libs ao programa. Isso se tornou ainda mais complicado no caso da engine modulada em dois projetos, pois para trabalhar com ela necessitaria não mais atualizar os linkers de um projeto (coisa que ja é muito chata de se fazer), mas sim de dois! Se trocasse de computador 3 vezes ao dia, teria 6 alterações de linker!

A solução encontrada foi criar arquivos do tipo Property Manager, os quais possibilitam que se forneça todas as configurações de propriedades do projeto no mesmo, e em seguida incluí-lo ao projeto em questão. Ou seja, configurei dois arquivos Property Manager, um para cada computador, e dessa forma só preciso agora incluir ambos no projeto e adeus includes chatos...

Por hoje é só!
Até a próxima...

sexta-feira, 4 de maio de 2012

DOCUMENTAÇÃO
Documento de Arquitetura do Jogo (6)

Olá!
   Continuando com a descrição dos aspéctos do Documento de Arquitetura, hoje veremos como foi construído o sexto tópico, intitulado Estimativa de Desenvolvimento, por nós, onde foi utilizado o método Planning Poker. Também será abordado como este planejamento foi integrado à ferramenta Pivotal Tracker, sendo este um ambiente de gerenciamento de projeto baseado na metodologia Scrum.

Sobre Planning Poker:
   É um Método de estimativa que usa como base o conhecimento dos desenvolvedores para estimar a quantidade de trabalho necessário para realizar o projeto.
   Para isso, são feitas estórias com suas devidas tarefas. Cada tarefa tem seu peso e a complexidade estimada, sendo esta última decidida pela própria equipe de acordo com uma escala pré-estabelecida.
    Geralmente se utiliza um baralho com os valores da escala para ser jogado durante a reunião com a equipe, definindo assim através de uma discussão entre os membros o valor mais adequado. No caso de divergências sem consenso, o maior valor atribuído será o levado em consideração na documentação.

(Figura 1 - Exemplo de baralho Planning Poker)
(Figura 1 - Exemplo de baralho Planning Poker)

Modelo de Estórias:

Estória 1: <descrição da estória>
Tarefa 1: Criação de Menu
Complexidade: 1
Tempo: 2 horas

Estória 2: <descrição da estória>
Tarefa 1: Criação de Menu
Complexidade: 2
Tempo: 4 horas
Tempo Total = 2h + 4 hs =  6 horas

Utilizando o Método:
     Pensamos em tudo o que achamos necessário para a realização do projeto, e em seguida analisamos as tarefas semelhantes e as agrupamos, formando as estórias. Utilizamos a escala de Fibonacci (1,2,3,5,8,13,21) para dar os pesos a cada uma das tarefas da estória.

   Segue uma de nossas estórias e suas tarefas com devidos pesos e atribuição de horas:

Estória: Programação básica da engine.
Descrição: Criação inicial de uma engine que possibilite a criação de protótipos usando OpenGL.
· Tarefa 1: Programação da interface de configuração da janela para WINDOWS. (3)
· Tarefa 2: Programação do desenho básico na tela com SDL. (1)
· Tarefa 3: Programação de uma interface de desenho de Sprite em quadros. (13)
· Tarefa 4: Programação do Game Loop. (21)
· Tarefa 5: Programação da captura de eventos usando Polling (Atenção especial para o MOUSE). (21)
· Tarefa 6: Programação da interface básica de configuração de desenho em OpenGL.(3)
Complexidade: 62
Tempo: 150 homens/hora.

Sobre o Pivotal Tracker:
É uma ferramenta online muito utilizada para projetos ágeis. Nela os desenvolvedores controlam as sprints através do peso atribuído a cada tarefa e a velocidade selecionada.
Mais informações: https://www.pivotaltracker.com/

Utilizando a Ferramenta:
Como a ferramenta trabalha com o escopo de uma única sprint por vez, cada tarefa criada anteriormente utilizando a metodologia é cadastrada e não as estórias.
Assim, ao clicar em “ADD STORY”, cadastramos uma de nossas tarefas no painel (Figura 2) que aparece já na aba “ICEBOX”; e nele colocamos nome, tipo, pontos (complexidade), responsável, descrição, etiquetas, tarefas (para controle de quem estiver implementando), atividades e até anexos se necessário.
(Figura 2 – Painel de cadastro da tarefa-estória)
(Figura 2 – Painel de cadastro da tarefa-estória)

          Ao cadastrar todas as tarefas já definidas, basta definir a velocidade das iterações e arrastar as tarefas para “CURRENT” ou “BACKLOG”, e estas se organizarão de acordo com a complexidade e a velocidade.

(Figura 3 – Visão Básica da ferramenta Pivotal Tracker com tarefas do projeto)
(Figura 3 – Visão Básica da ferramenta Pivotal Tracker com tarefas do projeto)

Confira o link do nosso projeto cadastrado como Public no Pivotal Tracker: 

Link: https://www.pivotaltracker.com/projects/534473

Até a próxima!

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 ;)