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 ...

Game Design por quem entende do assunto

Game Design é um conceito mal compreendido pela maioria das pessoas que não estão envolvidas com o mundo do desenvolvimento de jogos.

É comum as pessoas confundirem com desing gráfico ou até mesmo design da arquitetura do software do jogo.Game design se trata de transformar uma idéia em um jogo de maneira que mantenha o jogador jogando.

E para manter o jogador na frente do seu jogo, há uma quantidade enorme de pontos para se pensar como usabilidade, imersão, narrativa, dificuldade, rejogabilidade e inúmeras outras. Por isso o designer de um jogo precisa entender consideravelmente dos vários aspectos que envolvem a produção do jogo que pretende criar. Um game designer (na minha opinião) deve ser capaz de esboçar no papel a aparência dos personagens e ainda que de maneira simples, modelar um preview (ainda que simplista) de elementos de uma cena do jogo, conhecer tecnicamente a plataforma,linguagens, engines e ferramentas utilizadas no projeto do seu jogo.

Possivelmente alguns vão discordar dessa minha visão, dizendo que o designer do jogo deve se abster dos aspéctos mais técnicos do processo. Bom, como todo apaixonado por desenvolvimento de jogos, procuro ler bastante me informar de como pensam os grandes nomes da indústria, e eis que encontro uma entrevista (antiga) com o Senhor Fumito Ueda, sobre o processo de desenvolvimento de ICO (jogo obrigatório para todo aspirante a game designer!). E nessa entrevista o Senhor Ueda, demonstra em diversos pontos sua multidisciplinaridade e como isso resultou num projeto sublime, que conhecemos como ICO.
A entrevista pode ser lida na íntegra aqui

Vou comentar aqui algumas partes da entrevista que suportam a visão que tenho do game designer:

"In 1997, he got the idea to create a game with the universal theme of "boy meets girl," with the two main characters hand-in-hand during an adventure. To express the imagery behind this vague concept, he took an assistant and made a 3-minute movie using Lightwave."

Ueda iniciou o projeto criando uma animação. Ok, tinha um assistente, mas não parou simplesmente na fase do "Tive uma idéia"!

"Full production on the game began in October 1998; the team had made the decision to go with hand-done key frame animation rather than motion capture. Ueda claims that actors weren't able to understand the situation and move appropriated..."


Aqui, da pra ver o quanto o designer estava comprometido com a sua visão do jogo, dispensou o uso da tecnologia de captura de movimentos e optou por animação manual por que os atores não compreendiam como se mover adequadamente.

"Ueda wasn't satisfied with the results they were achieving, and became frustrated that the hardware wasn't capable of realizing his initial vision. He considered three options: either canceling the project outright, altering the design to try and finish the game on PSone, or changing platforms. After some deliberation, the team began converting the project for the PS2 hardware."

Aqui, o designer percebe que o hardware não estava sendo suficiente para alcaçar a visão inicial do jogo e ficam limitados a 3 opções: cancelar o projeto, alterar o design do jogo, ou mudar par outra plataforma. Como o jogo saiu para Playstation2 e não playstation, sabemos qual foi a decisão tomada. O importante aqui é o quanto o designer apostava na sua visão do gameplay e quanto compreendia da tecnologia em que estava trabalhando. Fico pensando na responsabilidade de entrar numa sala de reunião, e dizer para aqueles que pagam pelo projeto 2 anos depois de começado, que o hardware não é suficiente para implementar a visão inicial. Percebo que muita gente apostava na proposta inicial, afinal, não compete ao designer decidir se um jogo será cancelado ou não. Acredito que o que os executivos das empresas interessadas tinham era apenas o vídeo de 3 minutos, feito no início do projeto mostrando o gameplay que pretendiam alcançar, e ainda sim, mantiveram o design inicial e decidiram mudar a plataforma

Ao longo da entrevista, as visão do Sr Ueda em relação a narrativa, roteiro e imersão são demonstradas como neste trecho onde ele explica uma decisão simples - e fundamental na atmosfera do jogo - de não legendar as falas da personagem Yorda.


"Explaining why he opted not to include subtitles for Yorda's dialogue, he said that it was critical to the physical contact and "holding hands" concept that the two not be able to communicate and talk to each other all the time during gameplay."




Outros exemplos da multidisciplinaridade inerente ao papel do designer, podem ser lidos aqui, onde Ueda comenta tencicamente os efeitos de iluminação aplicados sobre as partículas implementadas para o jogo Shadow of the Colossus (como a poeira que levanta quando os colossos andam por exemplo).

"This is a method which performs lighting calculations using the relationship between the viewing direction and the lights affecting the particle, which creates an effect where the particle textures appear properly highlighted. The particles lighting calculation itself becomes expensive for the vector unit, but "the particle effect becomes 3D, because it is real-time and interactive, which is a big effect in itself."

Como eu disse no início do post, cabe ao designer conhcer tecnicamente os aspectos que envolvem a construção da sua visão. E pudemos ver pelas entrevistas que nos 2 grandes títulos concebidos por Fumito Ueda, ele esteve envolvido desde os aspectos mais técnicos do hardware até as facetas mais sutís da narrativa.

Obviamente o processo de desenvolvimento de um jogo como ICO ou Shadow of the colossus não pode ser comparado a nenhum título produzido atualmente no Brasil, mas a essência do papel do designer, é a mesma desde o mais simples PONG até a sala mais escura do castelo de ICO.

Quando eu crescer, quero ser que nem ele. Ha ha!

Alguns links interessantes:
ICO na fase de desenvolvimento para o PSOne
Making of Shadow of the Colossus
Site brasileiro sobre Fumito Ueda e seus Games

Read more ...