Últimas implementações

Olá a todos!

O prazo chegou ao fim, mas conseguimos implementar um gerador de mapas que supra as necessidades do projeto. Eis as últimas implementações:

- O número de trilhos são gerados conforme o tamanho da linha.

- Agora é possível setar a cor dos trilhos

- Também agora é possível definir se o trilho é túnel ou balsa

Acredito que isso seja tudo que será possível implementar até a data limite de entrega. O único principal componente do ticket to ride europe que o gerador ainda não gera é a criação de duplas ligações.  Também seria necessário criar uma interface mais controlável pelo usuário para que ele configurasse ao seu modo alguns parâmetros do gerador, porém isso se torna inviável sem a parte de desenho de textos que faltou para a engine.

Também faltou criar alguns checkboxes que informassem ao usuário o que acontecerá em seguida, como, por exemplo, "tem certeza que deseja excluir esta cidade?"

Também sem a parte de texto, tornou-se inviável poder salvar arquivos XML com nomes diferentes, limitando assim o número de arquivo gerados para 1. Também impossibilitou-se que o usuário carregasse como imagem de fundo um arquivo diferente da nomenclatura "tex/mapaFundo.png"

Bem, é isso. Espero continuar atualizando este blog no futuro com o ticket to ride e a engine totalmente finalizados um dia...

Importação e exportação de mapas

Olá!

A importação e exportação de mapas está concluída felizmente. Durante o fim de semana dei uma boa estudada em XML e na biblioteca rapidXML para implementá-la no gerador de mapas. Obtive um pouco de dificuldade inicial para obter conclusões sobre os aspéctos do analisador da rapidXML, o qual temos que configurar antes de eventualmente efetuar a leitura do arquivo.

No fim acabei implementando em um dia como havia falado o professor Vinícius.

Agora estou focado nos aspéctos essenciais ao trilho como cor, tipo, dentre outras coisas. Esse é o último aspécto importante a se considerar neste gerador, felizmente. O que vier adiante é extra!

Bem, estamos chegando à reta final. Espero que dê tudo certo!

Até mais...

Novas implentações do gerador de mapas

Olá a todos!

Hoje finalizei a parte inicial das ligações. Segue abaixo as implementações realizadas:

- As ligações são criadas clicando-se em uma cidade e depois em outra.

- Se, ao clicar na mesma cidade após ter iniciado uma ligação, esta é deletada. Isso facilita caso o usuário tenha criado uma liação por engano e queira deletá-la.

- Ao mover uma cidade, todas as ligações dependentes desta se movem junto

- Ao excluir uma cidade, todas as ligações envolvidas a esta são deletadas.


Finalizada essa parte, o gerador de mapas já possui uma cara inicial definida. A partir de agora estarei estudando XML para implementar a importação e exportação de mapas.

Até o próximo post!

(novo) Arte Gerador Gráfico

Olá!!!

Acrescentando mais dois assets gráficos ao Gerador de Mapas:

(Figura 1 - Botão de Seleção - Normal e Ativo)

(Figura 2 - Sprite de escolha de cores)

Este sprite será utilizado para a escolha de cor do trilho que o usuário deseja construir, são as cores das cartas mais o cinza que representa neutralidade.

Creio que agora está completo, mas se aparecerem mais exigências estarei postando aqui. Até mais!

Últimas implementações do Gerador de Mapas

Olá!

A partir de agora estarei fazendo posts rápidos sobre o status atual do gerador de mapas focando nas funcionalidades. Até agora, o gerador já possui as seguintes implementações:

* 6 botões inseridos:

   -  Cursor (movimenta e seleciona os objetos);
   -  Criar Cidade;
   -  Excluir Cidade;
   -  Criar Ligações;
   -  Salvar Mapa;
   -  Carregar Mapa;

* Movimentação da câmera programada;

* Colisão e HUD programadas (sistema de coordenadas finalizado);

* Movimentação das cidades;

* Criação e Exclusão das cidades;

* Criação inicial dos trilhos;


Para o próximo post, espero trazer informações sobre a criação dos trilhos completamente finalizada e algumas implementações em XML.

Abraço...

Revisões no carregamento de texturas

Olá

Neste post irei falar brevemente sobre duas atualizações na engine que a tornaram muito mais poderosa no carregamento de texturas.

A primeira delas foi a implementação do carregamento de imagens com alpha. A implementação antiga somente possibilitava o carregamento de imagens no formato RGB, convertendo o Alpha para cores variadas. Agora a engine percebe em momento de execução o formato da imagem e a carrega em RGB ou RGBA dependendo do resultado.

Com essa implementação, removi diversas outras desnecessárias a engine que foram implementadas no início do desenvolvimento.

A segunda atualização foi para a criação de um método que carregasse a textura invertida mesmo, já que muitos casos não precisam da textura invertida. Isso otimiza o carregamento da textura, aumentando o desempenho da engine.

Arte Gerador Gráfico

Oi!

Neste post falarei sobre os gráficos desenvolvidos para o nosso Gerador de Mapas. Os botões padrão foram inspirados nos ícones já conhecidos em softwares: Novo, Abrir/Carregar e Salvar, até mesmo para causar familiaridade ao usuário, porém são personalizados de acordo com a função que possuem e todos eles tem o modo normal e o modo ativo. Abaixo cada um deles:

(Figura 1 - Botão Criar Mapa)

(Figura 2 - Botão Criar Mapa Ativo)

(Figura 3 - Botão Carregar Mapa)

(Figura 4 - Botão Carregar Mapa Ativo) 

(Figura 5 - Botão Salvar Mapa) 

(Figura 6 - Botão Salvar Mapa Ativo) 

(Figura  7 - Botão Sair) 

(Figura 8 - Botão Sair Ativo) 

(Figura 9 - Botão Créditos) 

(Figura 10 - Botão Créditos Ativo) 

Já os botões de construção de objetos no gerenciador são conceitos próprios, confira:

 

(Figura 11 - Construção de Cidade - Normal e Ativo)

 

(Figura 12 - Exclusão de Cidade - Normal e Ativo)

 

(Figura 13 - Ligação entre Cidade - Normal e Ativo)

Aqui alguns botões genéricos, que podem ser utilizados apenas assim ou com imagens como o caso dos botões de Construção e Ligação de cidades:

(Figura 14 - Botões Genéricos, Normais e Ativos) 

Quanto as "peças" utilizadas para criar o mapa, na cidade pensei em fazer algo diferente do circulo utilizado no jogo original, então criei algumas versões, dentre elas as figuras abaixo:

(Figura 15 - Testes de marcação de cidade no mapa) 

Ao realizar testes diretamente no mapa dos gráficos representativos para cidades, a escolhida foi a imagem abaixo:

(Figura 16 - Marcação escolhida para representar a cidade no mapa ) 

E por fim, temos a já os tipos de trilhos entre os quais o jogador poderá fazer as rotas desejadas, são eles:

(Figura 17 - Trilho normal, é possível a escolha da cor desejada ) 

(Figura 18 - Trilho de Balsa) 

(Figura 19 - Trilho de Túnel, é possível a escolha da cor desejada ) 

São estes os gráficos para o nosso gerenciador, desenhados com base em dimensões adequadas  e proporcionais e desenvolvidos pensando no game design e no usuário final, de maneira a tornar a utilização deste a melhor possível.

DOCUMENTAÇÃO Diagrama de Atividades

Olá!

Hoje falarei sobre o Diagrama de Atividades realizado para o nosso projeto, este diagrama possui como caracteristica demonstrar as ações que ocorrem e podem ocorrer no decorrer do processamento do software, no nosso caso demonstrei a interação do jogador com os recursos do jogo.

Estudanto as aulas e realizando pesquisas a parte, utilizei alguns recursos não vistos em aula como o conceito de Pontos de Extensão, que resolveu meu problema de indicar quando o turno finalizou, mas o jogo continua.

(Figura 1 - Exemplo de Pontos de Extensão)

(Figura 2 - Exemplo de Pontos de Extensão aplicado no Diagrama de Atividades do projeto.)

Outro conceito que desejo destacar é o de nó tipo Final de Fluxo, este quando utilizado no final de uma ação indica que o fluxo em questão é finalizado, mas a atividade continua em outros fluxos, ao contrário do nó Final de Atividade que encerra todo o processo.

(Figura 3 - Nó de Final de Atividade)

(Figura 4 - Nó de Final de Fluxo)

(Figura 5 - Exemplo de nó Final de Fluxo aplicado no Diagrama de Atividades do projeto.)

Com isto o Diagrama de Atividades está completo e pronto para entrega!

Até o próximo, que será o Diagrama de Classes já inicializado, porém aguardando ajustes e a finalização.

paOpenGLPicking

Olá!

De todos os assuntos que me deparo, só existe um que me dá aversão, calafrios, dor de barriga e sofrimento: COLISÃO!!!

De todos os jogos que fiz até hoje, sendo protótipo ou não, incrivelmente apenas um tem uma colisão feita por mim mesmo. Alguns outros que tem foram parceiros de equipe que fizeram.

Tanto é que vocês podem perceber que este assunto nada carismático para mim foi deixado por último, dentre todas as implementações da engine.

Há 100% de chance de que esta seja a última implementação da engine antes da entrega. Só implementei a parte de picking porque ela se faz 100% necessária para o gerador de mapas.

Sem mais delongas, um picking é definido por uma área denominada de viewing volume que intercepta os objetos da cena a fim de gerar hits que serão capturados em um buffer de seleção definido pela engine e atualizado pela OpenGL. Com esse viewing volume, é possível posicionar sua região em torno do mouse e captar com quem ele está colidindo no momento em que se clica, por exemplo.

Para tal, implementei funcionalidades na engine para que o usuário defina grupos e membros para este grupo. A engine tratará de nomeá-los em uma sequência crescente, podendo o usuário saber qual objeto sofreu colisão com o mouse consultando qual membro de qual grupo sofreu colisão.

A facilidade com que o resultado aparenta ser mostra o meu sucesso em abstrair todo o sistema de nomenclatura de objetos, o controle das matrizes para inserção do viewing volume e o gerenciamento do buffer de seleção, sendo este último o maior problema que tive durante esses dias para implementar o picking.

No próximo post falarei sobre as implementações desta técnica de colisão no gerador de mapas, bem como das novas funcionalidades.

Até lá...

Últimos estudos realizados

Olá a todos!

Restam apenas 9 dias para o término do prazo... Estamos ofegantes trabalhando para apresentar o melhor resultado possível no dia da banca.

Estive estudando os últimos diagramas da matéria de Projetos para o nosso projeto. São eles:

- Diagrama de Sequência;

- Diagrama de Comunicação;

- Diagrama de Máquina de Estados.

Apesar da Keli estar focada na parte dos diagramas, é interessante que todos os membros da equipe estejam a par de como funciona a esquematização, para que possamos traduzir nossos pensamentos de maneira rápida na hora de colocar no papel.

Também estive estudando como implementar colisão usando a técnica de Picking. Não foi algo simples coletar todas as informações necessárias para entender com perfeição alguns aspéctos do OpenGL para utilizar o buffer de seleção a fim de capturar os hits do viewing volume. Algumas dúvidas ainda não estão totalmente esclarecidas na minha mente e provavelmente precisarei consultar o professor Vini Godoy e o Binder para sanar algumas importantes dúvidas.

DOCUMENTAÇÃO Diagrama de Casos de Uso com Agrupamento e Reorganização das Realizações

Olá!

Mais uma vez venho aqui falar sobre o Diagrama de Casos de Uso e a Realização de Casos de Uso, ao revisar ambos e analisar se estava tudo no padrão UML, senti que faltavam algumas coisas, ou melhor, haviam casos de uso desnecessários que acabavam poluindo o diagrama. Também restavam algumas duvidas sobre a Realização de Casos de Uso, então sentei com a professora para resolvê-las... e realmente haviam alguns casos de uso que não precisavam existir.

Então, resolvi fazer um agrupamento de casos de uso, tanto para despoluir o Diagrama em si, quanto para tornar a descrição dos cenários mais focada e demonstrando melhor os comportamentos do jogador ao estar jogando.

Um exemplo desses agrupamentos é a junção do caso de uso "Abrir Jogo" com "Visualizar apresentação", o ultimo foi deletado do diagrama e incorporado nas descrições do primeiro na documentação de Realização de Casos de uso, observe:

UC001 - Abrir Jogo

Descrição:

O jogador inicia o jogo e pode ver a apresentação.

Atores:

Jogador

Pré-Condições:

Jogo instalado.

Pós-Condições:

Jogo iniciado.

O jogador com acesso ao menu do jogo.

Fluxo Básico:

1. O jogador executa a ação de inicializar o jogo. (A1)

2. O Jogador visualiza a apresentação. (A2)

3. Realizar caso de uso Utilizar Menu.

Fluxos Alternativos:

A1. O jogador clica em fechar a janela do jogo. (E1)

A2. O jogador encerra a apresentação. O sistema retorna ao passo 2 do Fluxo Básico.

Fluxos de Exceção:

E1. O sistema informa que o jogo será finalizado e solicita confirmação da operação. (RN1)

Regras de Negocio:

RN1. O jogo será encerrado somente se o jogador confirmar que deseja finalizá-lo.

A fim de ilustrar o trabalho observe o primeiro diagrama, que já é a segunda versão (figura 1) e o diagrama atual (figura 2).

(Figura 1 - Diagrama de Casos de Uso (Versão 2))

(Figura 2 - Diagrama de Casos de Uso (Versão 3))

Levando em consideração que cada caso de uso deve ser descrito na Realização de Casos de Uso, não é uma tarefa tão fácil simplesmente juntar os casos de uso, precisei montar e revisar os que faziam ligação com os modificados e colocar no Fluxo Básico cada passo de modo a ser coerente para o funcionamento ideal do sistema, tendo o cuidado de acrescentar os UC's "extend" corretamente nos Fluxos Alternativos. Outro ponto a destacar, é a retirada de casos de uso do tipo "Voltar", a principio foram colocados a fim de expressar tudo o que o jogo terá de alternativas em telas, mas ao tirar algumas duvidas com a professora e realizar pesquisas, ficou mais claro o fato de montar os diagramas com a visão do jogador e não do desenvolver, evitando assim detalhar botões e telas.

Um dos critérios do jogo que não estava conseguindo encaixar na Realização é o "loop" de turnos, analisando resolvi colocar esta condição no
"UC005 – Realizar Turno." 

em:

"Pós-Condições:

O jogador realiza uma ação de sua escolha no jogo.

O jogador aguarda os outros jogadores realizarem sua jogada até ser seu turno novamente."

 

Um detalhe importante, em "Comprar Cartas" eu poderia ter agrupado os casos de uso referentes a está ação, mas resolvi deixa-los separados para melhor visualização e especificação das regras do jogo original, para cada tipo de carta e modo de compra destas. Pode-se ver claramente o efeito dessa escolha no caso de uso "Comprar Coringa da Mesa" que tem apenas uma ação que poderia ser agregada a "Comprar Cartas", porém ficaria pouco visivél está modalidade importante ao visualizar o Diagrama de Caos de Uso. 

O mesmo serve para o casos de uso de "Construir", além do fato de retirar o "Construir Trilho" e colocar  tanto a escolha de construir estações quanto a de construir trilhos generalizados de "Construir", detalhando essa passagem apenas na Realização de Casos de uso.

Finalmente, acredito que Diagramas de Casos de Uso mais Realização de Casos de Uso estão finalizados e balanceados entre si.

O próximo tópico será sobre nosso Diagrama de Atividades.

Ultimas implementações realizadas - Parte 3

Olá!

Vamos falar das técnicas utilizadas para iluminar a cena e os objetos. Antes, é importante ressaltar que a OpenGL trabalha apenas com luzes que impactam diretamente os objetos, ou seja, nenhum cálculo é feito sobre a cena (efeitos de radiosidade) e nem a refexão da luz por objetos é percebida (efeitos de ray tracing).

Implementei as principais e mais utilizadas técnicas de iluminação quando estamos trabalhando com OpenGL. São elas:

- Luz Ambiente Global: É a luz que irradia todo o ambiente de maneira igual. Pode ser definida como escuridão mínima que um objeto pode ter em cena.

- Luz Ambiente: Representa a luz que ilumina de forma igual todas os vértices do polígono em questão. Pode ser representada também como a escuridão mínima que o objeto no campo de atuação daquela luz pode ter em cena.

- Luz Difusa: É a luz angular do objeto. Esta depende da posição em que o objeto está e torna possível efeitos de atenuação. Com essa luz percebemos claramente as faces mais distantes da luz (menos iluminadas) e as mais próximas (mais iluminadas). Para definir essa luz com perfeição, é necessário calcular as normais de cada face para objetos poligonais e a media das normais para figuras arredondadas. Felizmente para o usuário, a paEngine trata de todos os cálculos das normais de luz por debaixo dos panos.

- Luz Especular: É a luz que define o toque especial do objeto, ou seja, o quanto as regiões atingidas por essa luz ficarão mais brilhantes dependendo do material do objeto. O efeito com a combinação das três luzes fica muito bonito se aplicado corretamente.

Exemplos de um poliedro com as três iluminações pode ser encontrado aqui:

http://www.inf.pucrs.br/~pinho/CG/Aulas/OpenGL/LuzesGL.html

É possível se inserir até 8 luzes na cena com a paEngine, seguindo a limitação da OpenGL...

Após configuradas as luzes da cena, é necessário posicioná-las no local desejado.

Por fim, ainda é necessário atribuir a cada objeto da cena um material. Este material pode ser definido manualmente ou através da sua cor. Para a primeira opção, implementei na engine a seguinte funcionalidade:

setMaterial(ambient[3], diffuse[3],  specular[3], shininess, emissive[3]);

Aqui é que a coisa começa a fazer todo o sentido, pois é nesses componentes que define-se como o objeto refletirá cada tipo de luz que inside em sua superfície. Por exemplo, podemos definir a reflectância do material em specular, e em seguida atribuir a ele uma superfície com brilho localizado, como um metal, passando valores de 100 a 128 em shininess.

Ainda existem funções disponíveis para setar cada um desses componentes individualmente.

No caso do último componente (emissive), este definirá que o objeto, além de refletir as luzes recebidas, também brilha. Isso, combinado com uma luz posicionada no centro do objeto, pode produzir efeitos muito bonitos para a aplicação.

Para definir o material do objeto através de sua cor, deve-se habilitar o color tracking da engine através do método activeColorMaterial. Esta representa uma maneira mais fácil de definir a iluminação para polígonos desenhados pelo programador e para iluminar polígonos sem textura.

A maior dificuldade da implementação do cálculo da luz foi destrinchar o que significava cada uma das luzes, como se comportavam para determinados tipos de materiais e como calcular as normais de luz para cada face. Felizmente, com um pouco de aprofundamento, observação, leitura e abstração foi possível chegar-se a uma implementação mais clara para a engine.

Se eu fosse continuar as implentações, criaria métodos de reprodução de luzes spotlight, melhoraria efeitos de atenuação, inseriria um algoritmo de cálculo de normais mais preciso para objetos que sofrem escala na cena e adicionaria algumas poucas particularidades para modificar a forma de como a luz é tratada. Por hora, essas funcionalidades já suprem as necessidades do projeto.

Com essas implementações, fecho a parte gráfica da engine, faltando apenas a colisão para iniciar o gerador de mapas. Para tal, utilizarei a técnica de Picking. Rezem para que eu consiga!!!

Até lá...

Ultimas implementações realizadas - Parte 2

Falarei agora sobre as implementações de blending...

Após destrinchado o funcionamento das fórmulas de blending usadas em OpenGL, a sua aplicação fica muito fácil. Dessa forma, buscando reduzir o prazo de desenvolvimento dessa parte, especifiquei módulos de inserção de blend usando as principais funções. Também criei constantes da engine referentes às constantes OpenGL para definição do cálculo de blending. Resumindo-as:

- startBlend( S, D): Recebe as constantes S (Source) e D (Destiny) para o cálculo. Um bom exemplo do uso desse método é passar GL_SRC_COLOR em S (na engine definido pela constante B_SC), e GL_ONE_MINUS_SRC_COLOR em D (na engine definido pela constante B_OMSC). Este método não aceita os parâmetros de configuração usando constant colors.

- startBlend(constS,constD,red,green,blue,alpha): Nessa sim, se passam os cálculos com o uso de uma cor constante de blend, como pode-se perceber na passagem de parâmetros. Esta técnica consiste em receber uma cor específica para o blending que será usada junto com as cores já presentes na cena.

Por fim, é sempre importante inserir o método endBlend após cada fim de configuração de um objeto com a propriedade.

Faltou apenas a inserção de um método para modificação da equação usada para cálculo do mesmo, mas preferi não entrar em detalhes sordidos...

No próximo post falarei sobre as implementações de iluminação, as quais sim realmente tomaram muito do meu tempo nesses últimos três dias!

Até lá...

Ultimas implementações realizadas - Parte 1

Uma coisa é fato: O desenvolvimento do gerador de mapas está extremamente atrasado!

- O prazo inicial para o desenvolvimento do mesmo deveria ter começado a um mês atrás.

- A parte de colisão e texto já deveria estar totalmente implementada.

- Já deveriamos estar trabalhando no desenvolvimento de um protótipo do Ticket to Ride.

Com certeza nós fomos uma das equipes que mais arduamente trabalhou. Principalmente devido às várias funcionalidades simples e complexas inseridas na engine que requereram pesquisa árdua para serem implementadas. Hoje como um quase post mortem de todo o desenvolvimento, vejo que foi um erro ter escolhido criar uma engine tão ambiciosa em OpenGL, ainda que o meu conhecimento sobre jogos tenha crescido em 1 semestre o que demorei um ano todo para coletar nos períodos passados.

Um erro ou não, aqui estamos com novas funcionalidades extras da engine que integram a parte de efeitos especiais do jogo: Smooth, blending e iluminação!

Sem muito tempo para planejar, modulei todas estas implementações na mesma classe draw que havia terminado. No caso dos desenhos usando smooth esse local na verdade está bem apropriado.

As seguintes alterações foram feitas na parte de desenhos de figuras geométricas sem texturas:

- Desenho de figuras com wireframe e pointframe

- Desenho de um retângulo/quadrado com vértices coloridos

- Desenho de polígonos (de qualquer número de pontos) coloridos

Ainda implementei as seguintes funcionalidades a fim de dar mais liberdade ao usuário para setar suas próprias configurações, ou até mesmo desenhar as texturas a seu modo:

- Habilitar/Desabilitar mapeamento de texturas automático.

- Habilitar/Desabibilitar culling automático

- Inserir configuração manual de culling

- Inserir configuração manual de texturas.

No próximo post falarei sobre as implementações de blending...

paOpenGLDraw finalizada!

Olá a todos!

Consegui finalizar por hora a parte de desenhos de primitivas da engine. Alguns desenhos suportam texturas com GL_REPEAT. Outros, somente texturas com GL_CLAMP_TO_EDGE. Algumas primitivas também suportam smooth de cor para cada vértice.

Algumas coisas ainda estão por ser feitas, como o desenho de qualquer poliedro desejado de modo fácil, desenho usando smooth para todas as formas, e suporte para GL_REPEAT para qualquer tipo de forma geométrica também, o que deixarei para mais tarde devido ao tempo para a entrega do projeto estar se esgotando.

É importante ressaltar que o comando  "setPolygonDrawMode" define o modo como a forma será desenhada (de modo normal, por linhas - wireframe - , ou somente os vértices da mesma).

A seguir, todas as forma geométricas 2D e 3D suportadas e suas respectivas características:

• Pontos;
• Linhas (2D e 3D);
• Linhas tracejadas (2D e 3D);
• Grid;
• Triângulo (suporta texturas com GL_REPEAT);
• Quadrado/Retângulo (suporta texturas com GL_REPEAT);
• Círculo (suporta texturas);
• Elipse;
• Poligonos com textura;
• Polígonos com smooth de cores para cada vértice;
• Polígonos com dimensões internas dinâmicas e ângulo inicial e final variados (Ex: podemos desenhar um polígono com um buraco no centro e indo de 0 a 90 graus, formando assim um leque);
• Skybox;
• Cubo/Paralelepípedo (suporta texturas com GL_REPEAT);
• Pirâmide (suporta texturas com GL_REPEAT);
• Esfera (suporta texturas);
• Poliedros esféricos (que nada mais são que esferas com número de linhas de definição dinâmicas). Suporta texturas;
• Cilindros parciais (somente o envolto) e completos (o envolto e os círculos laterais). Suporta texturas;
• Cones parciais (somente o envolto) e completos (o envolto e o círculo da base). Suporta texturas;
• Polígono/Poliedro com posicionamento dos pontos a ser definido pelo usuário (suporta smooth de cores).

As implementações futuras envolverão:

 * Suporte de textura para todas as fomas

 * Suporte de GL_REPEAT para todas as texturas

 * Desenho com smooth para todas as formas

 * Desenho de qualquer tipo de poliedro de modo fácil

 * Desenho de mais formas cilindricas

 * Melhora das texturas esféricas

 * Suporte a curvas

 * Suporte a texturas 1D (para linhas) e 3D (para volumes)

Arte + Game Design - Elementos gráficos "in Game"

Oie!!!!

Como prometido já estão prontos os novos elementos gráficos, desde umas duas semanas na verdade, mas como estou com várias correções e  atualizações na documentação acabei não fazendo este post antes.
Então, vamos lá!

A criação destes novos elementos é produto das sprints Produção dos elementos da arte – HUD Padrão e Produção dos elementos da arte – HUD (Personagens) inclusas como tarefas na estória Desenvolvimento Intermediário nas Estimativas de Desenvolvimento no Documento de Arquitetura  e como estórias individuais na ferramenta Pivotal Tracker.

Esses Elementos são os utilizados "in Game"  na tela em que o jogo estará em andamento, ou seja, a partida em si e os turnos de cada jogador.

Como já comentei optamos em utilizar como base o conceito do jogo original em sua versão digital, para mais detalhes confira nos posts anteriores: Arte Inicial e Game Design.

Agora vamos ver a personalização dos elementos gráficos para a nossa própria versão do jogo "Ticket to Ride"!!!

- Produção dos elementos da arte – HUD Padrão

As dimensões de tela foram definidas como 1024 x 768, além do modo Full Screen e a área do mapa 842 x 512, assim desenvolvi o background  com estas dimensões.

Já no conceito resolvi criar um fundo com textura de madeira para proporcionar um ar rústico, também coloquei um trilho na parte inferior da imagem onde ficam as cartas que o jogador atual possui na "mão", levando em consideração que serão estas que ele utilizará para construir suas rotas no mapa, criando assim uma imagem de referencia entre cartas e trilhos. Por fim, fiz uma moldura com tons amarelos e alaranjados.

(Figura 1 - Primeiro estudo do Background)

Para finalizar utilizei efeitos para deixar o conjunto com uma perspectiva melhor com sombra na moldura e 3D no trilho dando uma melhorada na posição deste.

(Figura 2 -  Background com Textura Simples)

Ai surgiu a ideia de estilizar mais a textura de madeira do fundo, confira o resultado:

(Figura 3 -  Background com Textura Estilizada)

Ainda não decidimos qual das texturas de fundo utilizaremos...

Também fazem parte desta as cartas anteriormente estilizadas com base nas originais, porém agora elas estão com as dimensões definitivas, aoalterar as dimensões consequentemente precisei otimizar as imagens.

(Figura 4 - Cartas de Construção (Trens Coloridos))

Quanto as cartas de destino faltam algumas definições, assim que acerta-las disponibilizo as cartas, de qualquer forma seguirão o padrão das originais.

Também entra na hud padrão as peças, que na verdade é uma peça branca que terá a cor modificada de acordo com o jogador que a utilizar.

(Figura 5 - Peça vagão)

O ultimo detalhe da hud padrão é o botão "?" que conterá um help sobre os comandos e esta localizado no canto superior esquerdo da tela.

(Figura 6 - Botão de help "?")

(Figura 7 - Botão de help "?" ativo)

- Produção dos elementos da arte – HUD (Personagens) 

Os personagens são baseados nas 5 cores disponíveis para escolha dos jogadores: Preto, Vermelho, Azul, Verde e Amarelo. Cada um tem uma personalidade distinta como pode ser observado no próprio desenho deles, tentei abranger o máximo de estilos de pessoas que jogam Ticket to Ride apesar da limitação de cinco possibilidades.
A hud é formada pela 'foto' do personagem caracterizado com acessórios da sua cor, a moldura envolve esta e também os locais onde aparecerão a quantidade de trens (abaixo da imagem de locomotiva) e pontos atuais, estendendo-se em uma linha personalizada até a outra extremidade da tela servindo como apoio das cartas do jogador.

Abaixo as huds dos personagens no modo jogador atual, esta fica na parte inferior da tela:

(Figura 8 - Lady a Charmosa)

(Figura 9 - Shadow Mistério...)

(Figura 10 - Scot o Aventureiro)

(Figura 11 - Sarah a Estrategista)

 (Figura 12 - John o Divertido)

E na parte superior da tela ao lado do botão de help ficam as huds dos outros personagens que fazem parte da partida e aguardam seu turno. Se trata de uma hud diminuída da hud de personagem atual sem a linha inferior desta, confira:

                               

                                            

(Figuras 13 - Personagens aguardando seu turno)

Enfim, nas próximas imagens pode-se visualizar o resultado final com a textura normal e a estilizada. Se alguém quiser opinar sobre qual prefere ou fazer sugestões sinta-se a vontade, espero que gostem!

(Figura 14 - Resultado Final)

(Figura 15 - Resultado Final 2)