ZIM - Prototipando a idéia

Faz pouco mais de 20 dias que comecei um projeto pessoal chamado "Zim".

Como de praxe, fiquei obcecado pelo projeto que acabou tomando (com muito prazer) todo o meu tempo livre, e tem sido um ótimo exercício de programação e game design.

Conceitos básicos do jogo

Zim é um puzzle game jogo em terceira pessoa sendo desenvolvido sobre Uity3D/C# onde o personagem utilizaria algumas poucas habilidades especiais para concluir cada fase.

Decidir quais habilidades o personagem teria, foi um exercício de game design bem interessante, simplesmente por que é difícil descartar boas idéias. Durante esta etapa, me pareceu que muitas habilidades deixaria o jogador confuso. por isso acabei limitando todas as (centenas) de possibilidades a apenas 3:

1. Um lançador de gel vermelho: O gel repele tudo que toca, logo, pisar no gel, impulsionaria o personagem para cima.
2. Um lançador de óleo: Enquanto estiver sobre o óleo, o personagem correria mais rápido. Quanto mais longo o caminho com óleo, maior a velocidade que o personagem poderia atingir.
3.  Uma "arma magnética", que poderia segurar objetos e arremessá-los.

Com as habilidades definidas ficou claro também algumas coisas divertidas que poderiam ser feitas. Com o gel por exemplo poderíamos alcançar plataformas mais altas:

E com o óleo seria possível ganhar velocidade para vencer obstáculos:

E como o personagem estaria constantemente saltando de um lado para o outro, ficou óbvio que precisava de algum desafio enquanto estivesse "solto no ar" e a idéia mais simples foi um jato de vapor que empurrasse o jogador impedindo-o de aterrissar onde planejava

No caso da arma magnética, seria utilizada para mover todo tipo de plataformas e  posicionar objetos em posições específicas como uma bateria num slot ou lançar um objeto contra um inimigo.

Prototipando - Gel, Óleo e Controles

O primeiro teste foi usando o FirstPersonCharacterController da Unity3D mas logo ficou claro que para atingir os efeitos de física do gel e do óleo precisaria escrever um controlador de personagem totalmente baseado em física, onde o personagem fosse um RigidBody.  

Com o controlador do personagem funcionando, restou fazer a lógica do gel e do óleo. Ambos afetam o vetor velocity de todo RigidBody em que tocam, sempre considerando as normais e a direção do movimento. O resultado é impulso e aceleração instantâneo!

O primeiro resultado satisfatório ficou assim:

Neste ponto a mecânica básica estava funcionando mas o óleo não poderia ser aquela "geléia" azul!

Decidi fazê-lo como um decalque, ou seja, um plano com uma imagem alinhado a superfície. Entretanto isso trouxe problemas, já que as vezes o decalque extrapolava as bordas da face onde havia sido aplicado. Algo parecido com a imagem ao lado.

Por simplicidade, decidi não apelar pra uma engine de decalques e contornar o problema alterando os Bounds do decalque no momento em que era aplicado. Apesar de ter restrições a solução funcionou muito bem. Com o problema do decalque solucionado, o óleo estava de cara nova. Nas imagens abaixo, da pra ver o óleo aplicado bem perto das bordas da rampa sem extrapolar os limites.

 Prototipando - Câmera Orbital, Câmera Fixa e desobstrução do campo de visão
Fiz os primeiros testes com perspectiva de primeira pessoa, mas a intenção é criar um game em terceira pessoa, então passo seguinte foi criar uma câmera orbital de terceira pessoa e um sistema para esmaecer objetos que se obstruem a visão do jogador. Além disso criei regiões onde a câmera estaria fixa num ponto específico, dando um ar mais dramático a cena. Note que ainda não tenho um modelo decente para o personagem, por isso nos vídeos a seguir o personagem será representado com uma cápsula, apenas para termos idéia das dimensões do personagem final.




Prototipando - Jato de vapor, e Sentinelas
Quase todo livro de game design que já li,  começou tentando definir o que é "divertitdo" e por que as pessoas jogam. E um dos fatores que sempre está presente nas definições dadas é o desafio.
Por isso a etapa seguinte, foi incluir alguns obstáculos. De início teremos 2 tipos de obstáculos:

• Jatos de vapor
• Sentinelas

Os jatos de vapor são emitidos por tubos de metal espalhados pela fase. Conforme havia planejado os jatos de vapor empurram o personagem impedindo e atrapalhando a sua trajetória.

O sistema dos jatos foi feito para ser simples de ser adicionado na fase. A quantidade de jatos,  intervalo entre eles, a duração e força do jato são configurados direto no editor.

 Apesar de serem primariamente um obstáculo do jogo, também se mostraram bons efeitos decorativos para a fase

Enquanto os jatos de vapor são intermitentes e causem pouco dano por si só, os Sentinelas são fachos contínuos de laser letais para o jogador. Os lasers permanecem na mesma posição patrulhando seu derredor mas travará a mira no jogador caso cruze seu facho. Alguns segundos sob a mira dos lasers é suficiente para reduzir seu life a zero.

Apesar do laser só poder mirar em uma direção, certas superfícies podem refleti-lo, criando obstáculos dinâmicos (e mortais mua-ha-ha!!)

Prototipando - Juntando tudo
No final da criação dos lasers, já tinha elementos suficientes para arriscar projetar um level de testes unindo tudo que foi desenvolvido até o momento mais algumas outras features essenciais como checkpoints e pickups. E o resultado é esse:

Conclusão

Muita coisa ainda precisa ser feita, desenvolvida e até mesmo revista, mas estou bastante satisfeito com o resultado. Farei um novo post tão logo tenha boas novidades para mostrar. 

Até!

Read more ...

Componente XNA de Lockpick

Depois de MUITO tempo sem postar, retomo a vida e as atividades anunciando a conclusão de um componente de lockpicking...

Lockpicking já é um recurso batante conhecido e amplamente utilizado em diversos jogos. Quem já jogou Splinter Cell, Oblivion ,Fallout (sim, usamos os gráficos de fallout neste demo) e etc. , já se deparou com essa forma de ganhar acesso a uma área, ou item protegido por uma tranca.



LockpickComponent é um componente XNA (Duh!) e pode ser integrado em qualquer jogo facilmente.
A mecânica é bem conhecida. Deve-se encontrar um ponto na circunferência que permita girar a tranca até o fim (45graus) para destrancá-la.
Ao forçar a tranca entretanto, dependendo de quão longe da posição de abrir estiver o pino, mais ou menos dano é aplicado sobre este. O pino pode quebrar se receber muito dano. Caso hajam mais pinos disponíveis, o componente automaticamente posiciona um pino novo para que o jogador possa tentar novamente.

Baseado na dificuldade escolhida, o componente gera um intervalo aleatório onde o pino deve ser posicionado que a tranca possa ser aberta. Quanto mais próximo o pino estiver deste intervalo, mais a chave de fenda conseguirá girar a tranca. Assim, é possível girar a tranca até bem próximo do fim e perceber que o pino apesar de próximo, ainda não está na posição ideal.


O construtor recebe além da referência ao game, a dificuldade e o total de pinos disponíveis para abrir a tranca.
A assinatura do construtor é a seguinte:




public LockpickComponent(Game pGame, Difficulty pDificulty, int pPinCount)


Logo, uma tranca com dificuldade normal, tendo 3 pinos disponíveis ficaria assim:

LockpickComponent _lpc;
…
// Uma tranca de dificuldade Normal. O jogador terá 3 pinos para tentar abri-la
_lpc = new LockpickComponent(this, _Difficulty.NORMAL, 3);


Ao criar uma instância do componente, pode-se configurar alguns handlers para os 3 eventos gerados pelo componente:


// Evento ao abrir a tranca
_lpc.OnUnlock += onLockEvent;
// Evento ao desistir de abrir a tranca
_lpc.OnCancelPickinLock += onLockEvent;
// Evento ao quebrar todos os pinos disponíveis
_lpc.onBreakAllPins += onLockEvent;


Ao iniciar, o componente faz uma pequena animação, aproximando a “câmera”. O zoom máximo pode ser customizado através da propriedade Scale, sendo 1.0 o tamanho original. No demo o valor padrão (1.5) foi utilizado.


this.Components.Remove(_lpc);


No demo, associei todos os eventos ao mesmo método, que simplesmente habilita o menu e remove o componente deixando a tela principal visível novamente. Em um jogo real, provavelmente você queira associar o eventos a rotinas que atualizem o inventário do personagem para debitar o numero de pinos usados, , abra uma porta em caso de sucesso e obviamente, remova o componente no final.

O demo pode ser baixado aqui Lembrando que é preciso o xna runtime 3.1 para que o demo execute corretamente.

:)

Read more ...

Simplesmente divertido

Hoje encontrei perdido no meu HD de backup, o primeiro game 3D que fiz, há un 1 ano quando comecei a estudar GameDev. Este jogo é para celulares feito em JAVA e simula a velha brincadeira de fincar uma faca entre os dedos com a mão apoiada sobre a mesa.
O jogo move a faca em arco variando o raio, ora mais perto das extremidades dos dedos, ora mais perto do centro da mão. O jogador tem então 30 segundos para fincar a faca na mesa o maior numero de vezes possível. A cada acerto, soma-se 1 segundo ao tempo de jogo, a cada erro, subtraem-se 2 segundos do tempo de jogo. Obviamente o jogo emite gritos de dor quando um dedo é atingido e o vibrador do celular é ativado por uma fração de segundo.

Eu pensava ter perdido este game durante um particionamento mal sucedido no meu notebook.
Depois de enxugar as lágrimas dos olhos (eu me emocionei ao reencontrar meu primeiro game!).
Perdi uns minutos jogando no emulador e pesando na simplicidade desta idéia. Quase me surpreendendo de quão divertido este game é. Uma brincadeira tremendamente simples tornou-se um game divertido de jogar. E isso é basicamente o que importa para o jogador. Diversão!

Não adianta um game com gráficos arrasadores se não tiver um gameplay divertido! Em muitos casos menos é mais. Antigamente, não era possível ter os gráficos que temos hoje e não haviam recursos computacionais para simulações físicas complexas tais como vemos nos jogos atuais.
Nessa época, os jogos valiam a diversão que ofereciam. Vai dizer q nunca passou uma tarde inteira jogando Enduro, pitfall ou Pac-man ? Lembre-se como eram toscos (visualmente) mas como eram divertidos estes games!

Vamos fazer uma comparação tosca, Assassins Creed Versus Tetris. Claro que se compararmos gráficos tetris nem entra na disputa, mas e quanto ao desafio ? E diversão ? Assassins Creed é um jogaço, mas depois da segunda ou terceira "missão" você começa a ver que todas vão ser iguais...
O jogo não te desafia (apesar de ainda ser um bom jogo! Não me crucifique!), enquanto cada partida de tetris é nova e imprevisível!

No game que estou desenvolvendo atualmente, me deparo em momentos onde ainda não decidí como certas ações serão feitas pelo jogador. Com certeza, o ponto de partida para decidir será respondendo a pergunta: "Como fica mais divertido ?"

Read more ...

O primeiro game – 5 dicas para começar

Todo geek ama video-games! Como todo bom geek, eu sempre quis criar meus próprios games. A estrada para a criar games é árdua, longa e a curva de aprendizado é grande. Por isso, para aqueles que querem começar , aqui vão dicas para evitar que seu primeiro game vire um vaporware:

1 – Não morda mais do que consegue mastigar

Não comece tentando fazer um clone do seu jogo preferido! Ele certamente foi feito por uma equipe enorme de profissionais experientes trabalhando full time e com recursos adequados. Seja realista, se você não tem experiência com 3D, comece com 2D ou modo texto. Saiba até onde você pode chegar com o conhecimento que tem. Obviamente todo projeto tem um desafio e algo que precisamos aprender durante o percurso. Questione-se se o volume de conhecimento que você precisa obter para concluir seu projeto, é razoável. Não adianta planejar algo que você precise estudar 1 ano para conseguir começar. Uma boa idéia é começar com jogos clássicos como pedra-papel-tesoura , jogo da velha ou tetris.

2 – Comece com Demos

Um game é composto de muitos elementos. Quando possível , faça pequenos projetos para aprender cada elemento separadamente. Por exemplo, lembra de Resident Evil 1 ? Esse game não permitia que o jogador movesse a câmera, ao invés disso, mudava o ângulo da câmera automaticamente de acordo com a posição do personagem no mapa. Se seu game utilizará esse recurso, faça um demo antes para entender melhor como funciona esse mecanismo. Isso evita que você polua o código do projeto completo com código de algo que você ainda está estudando.

3 – Planeje!

Por mais simples que seja o game, faça um documento de como ele deve funcionar. Descreva o gameplay, sistema de contagem de pontos, teclas utilizadas para controlar o jogador, condições de vitória, derrota e etc. Quando você documenta o seu game, vai perceber que ao contrário do que imagina, você não sabe exatamente como vai funcionar cada parte.Durante o projeto este documento servirá de guia, e você saberá exatamente em que parte do game estará trabalhando, quais estão prontas quais ainda serão feitas. Além disso, documentar o game permite que outras pessoas possam te ajudar no projeto, já que o conceito não está só na sua cabeça.

4 – Participe da comunidade

Ao contrário de Chuck Norris, nós meros mortais, não sabemos tudo e sempre precisaremos de ajuda em algum momento. Participe de forums sobre GameDev, Um bom começo é o www.gamedev.com.br.

5 – Não parta do Zero

Não gaste tempo fazendo o que você pode obter pronto com a comunidade ou com o oráculo (leia-se Google). Se seu game precisa de um emissor de partículas e você não sabe como fazer um, consiga um pronto na internet e utilize! Não estou dizendo que você não deve aprender como funciona um emissor de partículas, mas para que seu primeiro game saia do papel, você precisará manter o foco no que interessa: o game. Isso se aplica a tudo, física, networking, AI, GUI e etc. Para seus primeiros games, faça o mínimo de código que não se aplique diretamente ao gameplay. Assim seu projeto ganha vida com menos esforço e você não desanima!

Como dizia o tio Ben: “Grandes poderes trazem grandes responsabilidades”. Tome cuidado para deixar nos fontes as referências do autor (nome, email, site onde conseguiu) do código que você está utilizando. Obviamente, não é por utilizar algo que já está pronto, que você deve se acomodar. Reserve um tempo para estudar o código que pegou e aprender a fazer um demo (dica 2) com sua própria implementação.

Bom começo!

Read more ...