a leitura da semana não é exatamente técnica sob o ponto de vista de programação, mas analisando a área administrativa e financeira do nosso nicho de mercado – desenvolvimento de jogos – podemos dizer que vamos falar tecnicamente sobre um ponto bem importante: Lei Rouanet.

Atualmente, muito se corre atrás de investimento e incentivo fiscal para o desenvolvimento de games. Já tivemos vários casos de empresas fechando as portas em função da alta carga tributária brasileira, um caso bem conhecido é o da Ubisoft. Também, em evento da Square Enix em SP no mês passado o Sr. Fukushima foi muito claro ao tocar nessa nossa “ferida”, os impostos, tanto que além do Brasil, outros países da América Latina estão na alça de mira desta publisher para fazer negócios em função dos custos.

O Brasil vem se adaptando a essa realidade do crescimento da área de games a passos lentos. O governo vem fazendo o papel dele, mas claro, nunca perdendo e sempre jogando para ganhar.

Vamos analisar o que diz a nova lei de incentivo ao desenvolvimento de jogos que foi homologada no final do ano passado.

O texto é muito bonito! Pensem bem… não dá vontade de sair correndo, acessar o SalicWeb, cadastrar um projeto de um game que vocês sempre sonharam em fazer e sair buscando um patrocínio. Fácil né?

Pois é… nem tanto!

Os 3 problemas mais graves são os seguintes:

• um processo extremamente burocrático e desanimador;
• se você pedir um patrocínio de R$100 mil para uma empresa, esta não poderá deduzir integralmente do imposto de renda (IRPJ) dela. Apenas parte do valor pode ser deduzido do imposto;
• não pode haver viés comercial;

O terceiro item é gravíssimo, imaginem uma empresa patrocinando um game e não ser possível veicular a marca dela dentro do game porque irá gerar uma exposição da marca com viés comercial que a lei não permite. No máximo um botão de créditos ou ao final do game irá “rolar” na tela um logo e uns textos com os créditos do game. Bom, assim é difícil, ouso a dizer que seria uma “Missão Impossível” conseguir um patrocinador. Para uma produção cinematográfica, até é possível pois o mercado já está acostumado com isso, mas para nossa área que não tem essa cultura ainda… Uauu complica e muito!

Se na nossa área uma das grandes sacadas é trabalhamos com modelos “in game ads” ou “integrated mark” o simples fato de não ter cunho comercial ou apenas veicular a marca do cliente, esse incentivo parece andar na contra-mão.

Enfim, mas também não podemos dizer que o governo não fez nada para ajudar. O governo está jogando, se armou até os dentes e está nos desafiando. A probabilidade de um game over para as desenvolvedoras brasileiras é muito alta. Alguém se habilita?

Até o próximo post pessoal!

Arrumando um tempinho entre as tarefas do dia a dia, trazemos mais um episódio do nosso podcast sobre desnvolvimento de jogos, o PodAbrir. Atendendo a pedidos feitos após o episódio sobre Advergames, o tema de hoje é sobre Serious Games. Abordaremos este conceito que já é bastante conhecido aqui no Brasil, descrevendo as suas ramificações e dando vários exemplos de suas aplicações.

Participantes

Links comentados neste episódio

Visitem nossa página no Facebook

Mesmo com um pouco de atraso, trazemos mais um episódio do nosso podcast sobre desenvolvimento de games, o PodAbrir. Neste episódio eu, sem poder contar com o meu companheiro de trabalho, falo sobre um tema bastante acesso aqui no blog – a Inteligência Artificial em games. O objetivo aqui é introduzir as principais técnicas utilizadas pela indústria de games.

Participantes

Links comentados neste episódio

Visitem nossa página no Facebook

Mesmo que no finalzinho da semana, trago o 3º post do arco sobre Inteligência Artificial para vocês. Como já mencionado no episódio anterior, o assunto hoje será o “famigerado” Pathfinding (busca de caminho). O algoritmo responsável por mover um agente de um ponto a outro, desviando de obstáculos, é famoso por tirar o sono de muitos programadores de games. Para desmestificá-lo, primeiro precisamos entender um pouco sobre a movimentação básica de agentes em games. Vamos lá!

A movimentação de agentes em games é um dos segmento da I.A. mais comuns na produção de games. Os chamados Steering Behaviors (Comportamentos de Direção) consistem em usar regras simples que juntas fornecem uma forma mais realista de movimentação aos agentes. É uma técnica que não preserva estado, economiza memória e reage em tempo real.

Os principais comportamentos desta técnica são destacados abaixo:

• Comportamentos autônomos
  • Perseguição
  • Fuga
  • Perseguição com Linha de visão
  • Interceptação
• Comportamentos em Grupo
  • Separação
  • Coesão
  • Alinhamento

Vamos conhecer com mais detalhes alguns deles.

Perseguição e Evasão

Um algoritmo de busca simples que envolve o decremento das distâncias entre as coordenadas do caçador e da presa.

Pra transformar o algoritmo de perseguição em um algoritmo de evasão, basta fazer exatamente o oposto, invertendo as  coordenadas da presa de modo que sua distância aumente em relação à caça.

//Perseguição
se (caçadorX maior caçaX)
caçadorX--;
senão se (caçadorX menor caçaX)
caçadorX++;
se (caçadorY maior presaY)
caçadorY--;
senão se (caçadorY menor presaY)
caçadorY++;
 
//Evasão
 
se (caçadorX menor caçaX)
caçadorX++;
senão se (caçadorX maior caçaX)
caçadorX--;
se (caçadorY menor presaY)
caçadorY--;
senão se (caçadorY maior presaY)
caçadorY++;

Observe na imagem abaixo, que representa uma matriz de pixels, a trilha percorrida.

Perseguição com Linha de Visão

Na perseguição com linha de visão, o predador move-se em direção à presa através de uma linha reta traçada entre os dois pontos. Se a presa estiver parada, o caminho será uma reta simples. Porém, se a presa estiver em movimento, o caminho será formado por curvas – já que, a cada iteração do laço do jogo, o predador traçará uma reta entre a sua posição e a posição da presa.

Um algoritmo interessante na implementação da perseguição com linha de visão é o algoritmo de Bresenham, que é muito utilizado na computação gráfica para o desenho de retas.

// Bresenham
Determina qual eixo é mais longo; x ou y
Divide um eixo menor pelo outro, encontrando a relação
Itera pelo maior a cada unidade acrescenta o quociente

Apesar de serem bastante úteis, os algoritmos de Steering Behaviors normalmente não consideram os elementos do cenário, ou seja, não levam em conta os obstáculos que possam estar no caminho do movimento.  Essa é uma limitação preocupante. Além disso, é possível perceber que estamos trabalhando diretamente com pixels. Em grandes distâncias, ou em cenário complexos, precisamos utilizar um sistema mais flexível e simples de coordendas. Para solucionar este problema, precisamos recorrer a técnica de mapear o cenário através de um grid. Essa abordagem “milenar” é utilizada até hoje em games AAA, sejam eles 2D ou 3D . Observe um exemplo abaixo:

Com a criação do grid, reduzimos significativamente os pontos que iremos trabalhar, e consequentemente, o nosso problema. Neste exemplo ao invés que trabalhar com uma matriz de pontos de 512 x 448 (resolução do Super Nintendo), reduzimos a área para uma algo em torno de 14 x 14.  Desta forma, o caminho a ser percorrido assemelha-se bastante ao demonstrado em pixel nas primeiras imagens deste post.  O próximo passo seria rotular quais espaços estão livres ou bloqueados. Podemos visualizar na segunda imagem do game que alguns quadrados estão ocupados por troncos ou pedras. Essa informação deve ficar armazenada no mapa para o algotirmo de Pathfinding poder utilizar.

PathFinding

Pathfinding, ou busca de caminhos, é um dos “problemas” mais comuns acerca do desenvolvimento de jogos, e está presente na maioria dos gêneros.

Boa parte dos agentes em IA, sejam elas controladas pelo computador ou um NPC, precisam de pathfinding: tanques, pessoas, veículo ou unidade de combate.

O pathfinding não é utilizado apenas para movimentação simples – podemos utilizá-lo também para resolver problemas como:

• Patrulhamento: consiste na movimentação de uma unidade através de pontos pré-estabelecidos do cenário e em ordem. Isto faz com que as unidades pareçam mais ativas, aumentando as suas chances de encontrar inimigos;
• Desvio de obstáculos: requer que a unidade tenha conhecimento do que está ao seu redor, de modo que evite colisões com este;
• Perseguição: fazer com que a unidade vá em direção ao seu alvo;
• Mirar e atirar: um problema que ocorre quando uma unidade tenta atingir a outra é que obstáculos podem interromper a trajetória. Uma unidade inteligente deverá prever a existência de um obstáculo na rota de colisão do tiro antes de efetuá-lo.

A* (A Star)

Oriundo de outras técnicas mais custosas como o algoritmo de Dijkstra’s, o A* atualmente é a mais popular escolha para pathfinding. Ele é considerado um algoritmo admissível, ou seja, para qualquer grafo ele encontrará um caminho ótimo entre os estados inicial e final.

Para entender mais claramente o funcionamento do algoritmo, vamos fazer um exemplo. Assumindo que temos um NPC que deseja ir do ponto A (verde) ao ponto B(vermelho). Porém, há uma parede separando os dois pontos .

	Definir que o nodo atual é o ponto inicial A (verde); Definir que o nodo final é o ponto B (vermelho); Criar uma lista chamada de Nodos Abertos; Ela é o conjunto com os nodos disponíveis para escolha de caminho; Criar uma lista chamada de Nodos fechados; Ela será o conjunto dos nodos já desconsiderados.
	Adicionar o nodo atual A na lista de abertos; Identifique todos os nodos “vizinhos” ao nodo atual; Calcular o custo de locomoção para cada um destes nodos; Aqui podemos utilizar várias forma de calcular a distância. Vou optar pela fórmula clássica (F = G + H) G : É o custo de deslocamento do ponto atual para o vizinho. Podemos aqui contar com a diagonal ou apenas o movimento ortogonal; H : É um valor heurístico que representa a distância do ponto em questão até o destino. O valor é heuristico pois não contempla os obstáculos (Manhattan, Euclidiana, etc) Adicionar o nodo atual (A) como pai de cada um de seus “vizinhos”; Acrescente os “vizinhos” a lista de abertos;
	Escolher da lista de abertos o nodo de menor custo; Remover o nodo atual da lista de abertos ; Adicionar o nodo atual na lista de fechados; Tornar o melhor nodo escolhido como nodo atual; O valor do canto esquerdo inferior representa o descolamento, 10 para vizinhos diretamente ligados ao nodo A e 14 para as diagonais. O valor no canto direito inferior representa a distância deste nodo em relação ao destino (10 para cada casa);
	Repetir o processo do passo 2; Em casos de nodos de mesmo custo, escolher aleatoriamente ; Em casos de nodos que já estejam na lista de abertos, analisar se o custo de G atual não seria menor que o anterior. (G é acumulativo); Repetir passo 3; *
	O processo se repete até que o nodo alvo seja incluído na listagem; * Como fazemos para encontrar o caminho? Basta, através do nodo atual, pegar o seu antecessor e assim recursivamente; Ao final precisamos apenas inverter o vetor para obter o melhor caminho.

A lógica do Algoritmo não é tão simples de ser entendida a primeira vista, já que utiliza recursividade. Para facilitar o entendimento dos leitores, eu elaborei um exemplo de implementação utilizando a linguagem Action Script 3. Vejam abaixo o código simplificado deste algoritmo.

Obs: Alguns métodos foram abstraídos para facilitar o entendimento.

// Retorna o caminho(trilha) a ser percorrido
function getPath():Vector
{
	//Lista para armazenar os nodos vizinhos
	var nodesAround:Array;
	//Lista para armazenar o caminho a ser percorrido
	var path:Vector = new Vector();
	//Adiciona na lista de abertos a posição inicial
	openList.push(startPoint);
 
	//Laço enquanto o passo atual não for igual ao final
	while(!stepPoint.equals(endPoint))
	{
		//Armazena em uma lista os vizinhos do nodo atual. O método getNodesAround retorna os vizinhos do ponto
		nodesAround = getNodesAround(stepPoint);
		//Para todos os vizinhos encontrados
		for(var i:uint=0;i < nodesAround.length;i++)
		{
			//Verifica se o vizinho é sólido
			if(!isSolidNode(nodesAround[i]))
			{
				//Verifica se o vizinho não está na lista de fechados, ou seja, se já não foi visitado antes.
                                //Se não, o adiciona a esta lista.
				if(!isCloseList(nodesAround[i]))
				{
					//Verifica se foi possível adicionar o vizinho na lista de abertos
					if(addOpenList(nodesAround[i]))
						//Registra o custo G do nodo e também já registra o seu pai (nodo atual)
                                                // O método registreNodeCost calcula o custo de deslocamente e armazena no objeto
						registerNodeCost(nodesAround[i],stepPoint);
					else
						//Recalcula o custo G do nodo
						testGCost(nodesAround[i],stepPoint);
				}
			}
		}
		//Seta que o nodo atual, é o vizinho de melhor custo (dá um passo)
		stepPoint = getBetterNode(openList);
		//Remove o melhor vizinho da lista de abertos
		removeOpenList(stepPoint);
		//Adiciona o melhor vizinho na lista de fechados
		addCloseList(stepPoint);
	}
 
	// Através do nodo final, percorre toda a listagem de trás para frente.
	while(getTileByPosition(stepPoint).nodeParent!= null)
	{
		path.push(stepPoint);
		//Armazena na variável refernte ao nodo atual o nodo pai deste.
		stepPoint = getTileByPosition(stepPoint).nodeParent;
	}
 
	//Retorna o array de nodos invertendo a ordem
	return path.reverse();
}

Para auxiliar ainda mais no entendimento deste importante algoritmo, elaborei um “simulador”, onde é possível definir um ponto de origem, outro de destino e visualizar o caminho ideal a ser percorrido. É possível também, visulizar o funcionamento do algoritmo passo a passo.

O assunto deste post é de nível avançado, sendo sugerido para programadores mais experientes. O que você achou? Não entendeu e gostaria de mais explicações? Podemos seguir com as dicas sobre o algoritimo no fórum. Lá temos um tópico exclusivo para ele. Não deixe de conferir e participar.

Até a próxima.

Mas além da peculiaridade da plataforma, o post do Gabriel é um exemplo. Mostra como é insistir no sonho apesar das dificuldades, e focar em um projeto pequeno e com ele conhecer todas fases do processo (e suas dificuldades). É o tipo de relato que tanto instrui como inspira. Leitura obrigatória para o iniciante.

O material abaixo é um resumo do post feito pelo Gabriel no nosso fórum. O post original é bem longo e tem ainda mais informações. Você pode ler ele aqui.

Olá, meu nome é Gabriel Araujo, tenho 26 anos, natural de Parnaíba – Piaui, atualmente morando em Cuiaba – MT. Infelizmente longe dos grandes polos de tecnologia…
Trabalho com programação em C# já ha 7 anos, atualmente trabalho no Tribunal de Justiça de Mato Grosso como Analista de Sistemas.

Este é um post póstumo sobre como foi o desenvolvimento do Jogo Double Jumper, na tentativa de incentivar outros desenvolvedores a compartilhar suas experiencias.

Era uma vez …

Esse é meu primeiro game publicado. Como todo desenvolvedor sempre tive vontade de fazer meu próprio game. Como programador em C# o caminho mais fácil é utilizar o XNA Framework, não é uma engine, porem nunca levava a sério com a desculpa que não tinha por que perder tempo com isso se ninguém jogaria. Com a ascensão do modelo de negocio das lojas de aplicativos (Steam, App Store, etc) vi uma motivação, porém C++ com DirectX é muito hardcore pra ser um hobby e aprender Objective C é muito sofrimento, trabalhar com java no android, por algum motivo, sequer passou pela minha cabeça…

Quando surgiu o primeiro SDK para desenvolvimento para Windows Phone, minha motivação aumentou. Desenvolver um Jogo, pra min seria por diversão de final de semana, não queria dor de cabeça… então nos tempos livres comecei a brincar com o código, coisas simples…

O primeiro desafio foi fazer um retângulo se mover e colidir com outro retângulo e se mover na direção contraria ao impacto… ótimo, a parte mais difícil foi desenhar o retângulo na tela uma vez que o XNA é um framework te ajuda a printar coisas na tela e atualizar estados e só… não é uma engine completa com milhares de funções pre-defindas… felizmente o site da MSDN (Microsoft Developer Network) é muito completo e útil em todo tipo de tutorial e exemplos, a Microsoft é uma empresa maléfica porém ela trata muito bem seus desenvolvedores.

Era uma vez… jogando um mmorpg chamado lineage2, um colega passa o link do “Robot Unicorn Attack”, na hora foi humilhado pelo visual multicolorido do jogo, mas 10 minutos depois tudo mundo parou de jogar o tal mmo pra ficar disputando Score no jogo do unicornio robo. Isso já tem uns três anos…

Eu gostei particulamente porque era tudo que que queria fazer em Sonic 2, isto é, Correr e pular como se não houve amanhã. No sonic, apesar de ser um jogo rápido, o game design segue muito o estilo “labirinto”. Isso na minha opinião limitava muito o jogo…

Quando comecei a brincar com jogos, mais ou menos depois de ouvir o Podcast “Double Jumper – Eversion”, comecei a fazer uma engine de jogo de plataforma apenas pelo prazer de programar algo diferente de telas que se limitam a trazer e enviar dados do banco pra tela e virse-versa. Logo as coisas foram tomando forma. Mostrei para uns colegas de trabalho e eles me disseram que eu poderia ganhar alguma grana fazer algo para celular… ainda não tenho muita certeza sobre isso…

Então determinei um escopo para o Jogo: O gameplay será mais baseado no Robot Unicorn Attack, isto é, a tela se move automaticamente e destrói os inimigos com um “Dash”. Adicionei dois novos elementos, um botão para retardar o tempo, assim você não fica cego e pode calcular melhor o tempo do seu pulo, esse botão somente fica habilitado depois de uma certa velocidade (que também tem peso no highscore).
Outro elemento é o um shield, estilo chupado do jogo sonic …

Fiz do Jeito que Deu

De fato o visual é o maior problema, com a ideia de produzir algo para celular, tenho no Twitter procurado ilustradores afim de participar do projeto, primeiramente queria fazer uma “parceria”, depois já estava disposto a pagar pelo serviço… tem uma galera boa BR no deviantart, queria fazer um personagem mais engraçadinho, tipo o pateta (hehe). Mas a galera que tá iniciando sempre quer ter seu próprio projeto artístico, então oferecei um papel em branco, o cara poderia sugerir o visual e ate o game play… eu só queria programar de fato.. mesmo assim nada…

Com a Engine 80% pronta para um jogo de plataforma e ainda usando quadrados para simular os personagens decidi me aventurar pelo mundo fantástico do pixel art, vi alguns videos no youtube… e me lembrei de uma engine chamada MUGEN, procurei alguns sprites, comecei a desenhar por cima.

Fiz do meu jeito, mas ao menos produzi algo em vez de ficar estagnado. Afinal é meu primeiro jogo não espero revolucionar o mundo no primeiro jogo. Segue abaixo um exemplo tosco da forma que estou desenhando as plataformas no Paint. Se alguns se sensibilizar com a minha causa será bem vindo a participar do projeto.

Desenvolvimento

A fase de desenvolvimento foi baseada no descomprometimento e amadorismo… isto é, só sentava pra desenvolver no final de semana e mesmo assim era um final de semana sim, oito não… no inicio estava desenvolvendo somente no emulador do windows phone sdk. Quando o jogo começou a tomar forma, num ato de loucura e desespero de me livrar do vicio de jogar um MMORPG chamado Lineage 2, já citado anteriormente, vendi meu personagem no jogo com todos os itens. Consegui mais de 2mil reais nisso, com parte da grana, então, comprei um celular com o Windows Phone no Mercado livre. Na época existia um hack que você poderia fazer o deploy do jogo mesmo sem ser um desenvolvedor registrado. Isso melhorou muito a visualização do gamedesign e de como fazer o jogo se tornar mais interessante, utilizava alguns colegas de trabalho como beta teste…

Cada dia eu tinha uma ideia para incrementar o jogo, cada amigo que via o jogo viajava mais ainda na maionese. A maior dificuldade do desenvolvimento são as imagens, durante centenas de milhares de anos procurei um ilustrador para me ajudar com o projeto. Por fim fui obrigado a simplificar o jogo e fazer as imagens no MS Paint com minhas próprias mãos, digo clicks…

Publicação

No meio do ano de 2011 o jogo estava “pronto”, quero dizer, jogável… e sem um ilustrador para me ajudar não tinha como evoluir mais o gameplay. Então literalmente liguei o f**a-se e paguei a licença de publicação na Marketplace do Windows Phone, 99 Doletas no cartão de credito internacional de um colega…

A publicação na Loja da Microsoft foi muito simples, e foi relativamente rápida, num ato de noobisse (“amadorismo” – nota do editor) eu marquei a publicação automática após a aprovação e o jogo foi ao ar no dia 16 de agosto (uma terça feira). Não faça isso. Minha ideia era ter publicado no sábado. Após a publicação o site de report tem um delay de 1 semana para poder começar a gerar estatística… uma semana depois para minha surpresa o jogo foi bem recebido.

Publiquei o Jogo “Double Jumper” na Marketplace do Windows Phone dia 16 de agosto totalmente Free.

Em 3 dias de lançamento (16, 17 e 18) o jogo teve:

• 5.672 downloads;
• 57+ Reviews
• 6 Crashs
• Ficou na media de 3.5 Estrelas, sendo o máximo de 5 Estrelas;

Uma dica: a primeira semana é a mais importante, é tudo que você tem, seu jogo estará no Topo do News e será a sua maior visualização, eu errei ao publicar o jogo sem um bom acabamento, na publicação o jogo sequer tinha musica de fundo… posteriormente eu inclui High-Score com Rank online essas features com certeza aumentariam a recepção do Jogo.

Por mais incrível que pareça o meu jogo estava publicado em tudo quanto é pais, mas o Brasil estava de fora. Até porque a maioria dos usuários estão voltados para a Marketplace americana, até mesmo os brasileiros acessam as lojas de App americana.

Todo conteúdo Audiovisual publicado aqui é necessário ter uma Classificação Indicativa. Do site da Marketplace fui redirecionado para o Site do Ministério da Justiça onde, em resumo, dizia o seguinte: você tem que enviar um documento via correio de um formulário sobre seu jogo e escrever um pouco do como é o jogo e PLUS você deve enviar uma mídia jogável ou vídeo gameplay para analise. Esperar 20 dias de burrocracia, se aprovado você tem que esperar seu jogo sair no Diário Oficial (não sei se isso tem custo $) … ai, publicado, você usa o PDF da pagina do Diário Oficial para provar sua classificação Indicativa (Pelo menos foi isso que eu entendi)…

Também publiquei na União Europeia, fui redirecionado ao site de lá, preenchi via web um formulário sobre o jogo, fiz upload de algumas imagens, solicitei classificação livre … e depois de alguns minutos, misteriosamente, estava na minha caixa de email a resposta com um PDF em anexo … enviei o PDF para o site da Marketplace e 3 minutos e pronto, publicado.

Entrei em contato via Twitter com um cara da MS Brasil o @RodoCarmo pedindo ajuda de como publicar aqui no brasil… logo em seguida outra pessoa entrou em contato comigo dizendo que não era tão complicado assim, mandei o link do site do Ministério da Justiça … ele só respondeu uma carinha triste …

Mais tarde um contato do Ministério da Justiça (@classind) se prontificou em cuidar do meu caso, me mandou um endereço de email para conversar diretamente comigo, disse que não preciso enviar nada por correio. Eu posso imprimir o formulário, responder, assinar, digitalizar e enviar por email… o jogo tb não precisa enviar, pq a MS disponibiliza acesso a Marketplace a eles para testarem todos os jogos (pelo que eu entendi).

O jogo foi publicado na Marketplace Brasileira. Tive, dada as devidas proporções, relativamente muitos downloads, porém os reviews (estou falando dos reviews dentro da própria Markeplace) dos brasileiros são desmotivadores, alguns deles são até ofensivos. Mesmo sendo um jogo 100% free, os comentários são muitos maldosos, num ato de tristeza fui pesquisar os reviews de outros jogos de grandes publicadores e apps de grande nome, os comentários são igualmente negativos, acho que isso é mais ou menos da nossa natureza.

Relatórios e reviews

Total: 128.128 Downloads

Vídeo da versão Beta pra vcs terem uma ideia

Review em um Site Americano

Review em um Site Russo

Review no Hot Apps do Site da Microsoft

Pequeno review em um site gringo

No ar mais um episódio do PodAbrir, o seu podcast sobre desenvolvimento de games. Fechando o arco sobre profissões nos games, trazendo a “profissão” do empreendedor, o dono da empresa. Abordaremos neste episódio os desafios que alguém que deseja abrir uma empresa poderá encontrar. Para isso, tanto eu como Alessandro descreveremos nossa trajetória até ingressar na indústria de games.

Participantes

Links comentados neste episódio

Visitem nossa página no Facebook

Que conselho você daria para o aspirante a desenvolvedor de jogos? Essa pergunta foi feita pelo site Design 3 a vários profissionais da indústria em suas entrevistas, ao longo de um ano, e a resposta de todos foi compilada em um único vídeo.

Neste post comentamos estes conselhos, acrescentando nossa opinião pessoal, porque são dicas tão importantes que nunca é demais lembrá-las.

Aqui no Abrindo o Jogo já demos vários conselhos para os desenvolvedores iniciantes, seja em posts específicos, seja em comentários no PodAbrir. Nosso objetivo é sempre o de passar nossa experiência e as boas práticas que coletamos ao longo do tempo para facilitar o trabalho daqueles que estão iniciando agora. Porque sabemos que não é um caminho fácil…

Alguns dias atrás me deparei com um vídeo onde o site Design 3 juntou os conselhos de vários profissionais da área, coletados ao longo de um ano em entrevistas para o site. Não foi surpresa ver que os conselhos são muito parecidos com os que damos aqui. Um material realmente interessante e, acredito, motivador.

Sendo assim, achei interessante compartilhas, e comentar, os principais conselhos neste post. E recomendo, claro, que assistam o vídeo na íntegra (o link está no final do post).

Os dois principais conselhos, que aliás nunca cansaremos de martelar aqui no AoJ, são: comece logo e comece pequeno. Pela quantidade de profissionais que dão estes mesmos conselhos, você pode ter certeza que são os conselhos mais válidos que alguém pode lhe dar nessa área.

Comece logo!

Will Wright (Stupid Fan Club), Ricky Hagget e Richard Hogg (Hohokum), Jesse Schell (Schell Games), Robin Hunicke (thatgamecompany), Ian Dicarlo e David Payne (UAT), Alex Schwartz (Owlchemy Labs), David Helgason (Unity), John Petters e Peter Hunter (Team Krinoid), Matt Rix (Magicule), Alex Neuse (Gaijin Games), Rod Humble (Linden Lab), Kyle Reden (Warden of Raal), Brian Provinciano (Retro City Rampage)

Começe já a fazer um jogo. Faça um nas próximas 48 horas. Sério, se você nunca fez um jogo completo, precisa urgentemente fazer um – nada de ficar uma semana ajustando o game engine, projetando o level design ideal, embelezando o código ou pensando qual o melhor padrão de projeto aplicar. Seu primeiro projeto não tem que ser grande ou legal – ele tem que ser… feito. Inteiro. Jogável. Termine de ler este post e faça um jogo.

Não há desculpas para adiar. Baixe o Construct2, Game Maker, Corona ou mesmo Unity. Outra opção para iniciar é juntar-se a uma comunidade de modders e trabalhar em um mod para um jogo existente. Não fique pensando “e se…”. Não pense muito – apenas faça. Isso é importante: termine algo. Pode ser o pior jogo da sua vida, pode ser apenas um protótipo jogável – mas será inteiramente feito por você e isso é um primeiro passo importante.

E não faça apenas um, faça vários. Experimente mecânicas diferentes, técnicas diferentes. E passe para outras pessoas jogarem. Você aprenderá muito sobre o que funciona ou não, com estas experiências.

O mesmo vale para quando montar uma equipe: façam um jogo simples, qualquer, mas que lhes dê a visão completa do processo, do fluxo de trabalho, das ferramentas necessárias. É incrível como isso pode ser mais importante do que o puro conhecimento técnico.

Comece pequeno!

Michael Allar e Zach Lehman (Emotional Robots Inc), Notch (Mojang), Andrew Maul e Kyle Brannon (UAT), Joe Robins (Unity), Dave Traeger e Scott Reismanis (Desura), Alex Quicke (Depth), Edmund McMillen (Team Meat)

Comece pequeno. Seu primeiro jogo não vai ser o próximo grande jogo da indústria – ele vai ser um dentre muitos projetos pequenos que você vai realizar em uma etapa de aprendizado. Não estou dizendo para desistir do seu sonho de um jogo grandioso. Pelo contrário, quero apenas dizer qual a melhor forma de você torná-lo realidade: não é começando por ele! Fazendo muito projetos pequenos (pequenos mesmo, coisa de uma semana, um mês no máximo), você vai entender as dificuldades do processo e se preparar melhor para “aquele” seu projeto dos sonhos.

Esteja preparado para errar, porque você vai errar. Muito. Projetos pequenos permitem aprender facilmente com os erros, podem ser refeitos do zero se preciso. Em um projeto grande, se um erro te leva de volta à prancheta, é muito provável que você desista se ainda não estiver devidamente preparado.

Invista naquilo em que você é melhor!

Niv Fisher (SpirySnail Games), Chris Hazard (Hazardous Software), Nateon Ajello (Mixamo), Ryan Arndt (IGDA), Charlie Cleveland (Unknown Worlds Entretainment)

Faça aquilo no qual você é melhor, aquilo que gosta, aquilo que sabe mais. Procure ser o melhor possível nisso.

Esse conselho tem dois lados: primeiro, diz respeito à começar pela tecnologia que você conhece. Seu objetivo pode ser fazer jogos para iOS e Android, mas se o que você domina é programação em C para Windows, comece por aí. Se você é novo na área de jogos e também no Android, por exemplo, estará aprendendo duas coisas novas ao mesmo tempo e isso pode dificultar tudo. A experiência adquirida em fazer um jogo vai muito além da linguagem ou plataforma utilizada. Entendendo o processo como um todo, em uma tecnologia conhecida, será mais fácil aprender depois uma tecnologia nova.

Por outro lado, faça algo baseado naquilo que talvez você conheça e outros não – isso permitirá a você fazer algo diferente, único, que chame atenção. Depois de alguns protótipos você certamente vai achar uma área na qual vai se destacar: IA, efeito gráficos, mecânicas inovadoras, game design, roteiro, etc. Ache a aquela área pelo qual você é mais apaixonado e invista nela, em projetos que mostrem o quanto domina ela. Esta é uma indústria bastante concorrida e se você não almejar sempre ser o melhor, pelo menos em uma área específica, ficará para trás.

Conheça o processo completo!

Caitlyn Meeks (Unity)

Aprenda de tudo um pouco. Certamente você vai dominar muito uma coisa ou duas, mas deve conhecer todas as outras. Por isso é tão importante você fazer projetos pequenos mas completos no início da sua carreira. Conheça ferramentas, entenda um pouco de arte (se você é programador) ou um pouco de lógica (se você é artista).

Estude, capacite-se!

Dan Adams (Unity), Mathieu Mazerolle (Autodesk)

Estude. Vá para faculdade… ou não, mas estude o quanto puder. A capacitação é, e sempre será, a escada para alcançar os patamares mais altos.

Torne-se conhecido!

Mathieu Mazerolle (Autodesk), Marc Mencher (Game Recruiter)

Conheça pessoas e faça-se conhecer. Desenvolver suas habilidades e não mostrar isso para ninguém não leva a lugar nenhum. Não são as suas habilidades que te fazem progredir. São as outras pessoas. Lembre-se disso. São as outras pessoas que vão lhe dar emprego, financiar seu projeto e, em última instância, comprar seu jogo. Então, vá a eventos, participe de comunidades on-line, contribua para outros projetos e exercite muito sua capacidade de se comunica – principalmente de forma escrita.

Poupe!

Thomas Grip (Frictional Games), Mark Essen (Nidhogg), Mircea Marghidanu e Chris Migleo (Unity)

Poupe, não gaste dinheiro se não for realmente necessário. Temos muitas opções de ferramentas gratuitas hoje em dia: use-as. Se montar uma equipe, mantenha ela pequena e não contrate ninguém. Procure juntar apenas pessoas comprometidas com o projeto, que trabalhem voluntariamente. Seus primeiros projetos podem não dar retorno financeiro, então não invista diretamente neles. Invista em capacitação.

Conclusão

Se eu tivesse recebido estes conselhos na minha época de iniciante (bons anos atrás) e tivesse acesso à informação e ferramentas que temos hoje, teria passado muito, muito menos trabalho… Por isso meu último conselho é: aproveitem estes conselhos!

Quanto mais você puder aprender com quem já está na área, melhor. Se por um lado hoje a disponibilidade de informação e tecnologias facilita a entrada na indústria de jogos, por outro lado facilita para todos, ou seja, a concorrência é grande. Então a dedicação, a capacitação e a experiência adquirida na prática é que ditarão a diferença entre os novos profissionais.

Abaixo o link para o vídeo (em inglês):

• Assista o vídeo na Design 3

Graças ao leitor Otávio Ortiz, temos o primeiro Leitor no Controle de 2012. Expert no assunto, Otávio traz dicas de como montar um game side scrolling utilizando o engine Game Maker, que aliás recentemente ganhou uma nova versão compatível com HTML5.

Reforço que os demais leitores podem – e devem, seguir o exemplo do Otávio enviando o seu artigo ou tutorial para contato@abrindoojogo.com.br

Como fazer o efeito side scrolling no game maker

E é isso, agora é só executar e ver a câmera seguindo o seu objeto,  este efeito é conhecido com side scrolling. Espero ter ajudado, um abraço a todos e qualquer sugestão utilize os comentários. Para dúvidas sobre esta técnica ou qualquer outra, utilizem o fórum  do AoJ, lá tem um área só sobre Game Maker a qual sou moderador. Até

Otávio Ortiz

No ar mais um episódio do PodAbrir, o seu podcast sobre desenvolvimento de games. Continuando o arco sobre profissões nos games, finalmente o tão esperado Game Designer, profissão abordada em uma entrevista com Cassiano Canheti, Lead Game Designer da Hoplon Infotainment. Como todos devem saber, essa é a empresa criadora do jogo Taikodom, hoje o maior projeto brasileiro da área.

Uma entrevista imperdível para quem quer ficar por dentro desta, que é uma das profissões mais importantes da área.

Links comentados neste episódio

Visitem nossa página no Facebook

Apesar da semana ter iniciado bastante corrida aqui na empresa, promessa é promessa, e eu não podia deixar os queridos, e interessados, leitores na mão. Sendo assim, trago para vocês o terceiro post do arco sobre Inteligência Artificial nos Jogos.  O conteúdo de hoje dá continuidade as aplicações das técnicas de I.A. nos mais diversos gêneros de games. O post deu um pouco de trabalho, mas acho que o esforço é merecido. O pessoal está partipando e mostrado-se bastante curioso sobre o tema.

Vamos lá!

Gênero: Adventure

O Adventure coloca o jogador no papel do herói, ou heróis, da história. Este estilo normalmente exige habilidades para a resolução de quebra-cabeças e enigmas. Ele foi consagrado nos anos 90 pelos excelentes títulos da Lucas Arts. Afinal, quem não lembra de The Secreat of Monkey Island ou o engraçado Full Throttle?

Sistemas de Script

Esta técnica é uma das minhas preferidas para este gênero. Os adventures, principalmente os clássicos baseados em  point and click, possuem a jogabilidade bastante amarrada ao enredo. Desta forma, o fluxo da ação assemelha-se muito a um script de filme, com personagens agindo em uma ordem cronológica previamente definida.

Recentemente, participei de um projeto onde recebi a missão de projetar um editor para “roteiros” de personagens em um jogo. O conhecimento de I.A., e principalmente da técnica de Sistemas de Script, foi fundamental para realizar esta tarefa. Com o editor em mãos, o  Game Designer, ou Level Designer, foi capaz de definir as falas e ações de cada personagem diretamente em um arquivo XML. Em seguida, o motor do jogo analisava estas informações, criando as regras e tarefas para cada NPC.

Foi um projeto muito interessante que proporciou um gande ganho em produtividade para a equipe. Além disso, esta técnica somada a outras como FSM e Sistema de Mensagens, proporciona uma excelente experiência para o jogador.

Gênero: Plataforma

Sucesso desde a década de 80, os games de plataforma bidimensionais são característicos por apresentarem uma perspectiva lateral do ambiente. Com a evolução dos consoles, vieram os gráficos em 3 dimensões, criando uma nova variação para o gênero. Mesmo com franquias de sucesso como Mário Galaxy, a jogabilidade em duas dimensões ainda é popular e divertida.

Máquinas de Estados Finitos
Por questões de simplicidade, a maioria dos inimigos segue comportamentos padrões básicos,  movimentam-se em uma direção até encontrar um obstáculo – nesta caso, invertem a posição e reiniciam o procedimento. Para jogos de plataforma, a implementação da técnica de FSM também é simplificada.

Sistema de Mensagens
O estilo puzzle de grande parte dos jogos de plataforma, é um prato cheio para a utilização de mensagens e eventos. Elas são utilizadas normalmente para notificar inimigos ou elementos do ambiente sobre mudanças no estado do jogo ou a presença do player.

Data Driven System (Sistema baseado em dados)
A movimentação da câmera para jogos de plataforma tridimensionais normalmente torna-se bastante complexa  (quem jogou The Simpsons Game, sabe do que estou falando). Consequentemente, caminhos pré-definidos podem ser construídos através de um editor de níveis, caso nenhuma solução algorítmica seja adequada.

Gênero: Esporte

Este gênero é característico por emular a prática de esportes como futebol, vôlei, basquete, hockey, entre vários outros.  A grande maioria enfatiza a prática do esporte do ponto de vista do atleta, enquanto outros apresentam uma visão mais estretégica do ponto de vista do técnico ou treinador.

Máquinas de Estados Fuzzy (FFSM)

Todos os jogos desse gênero seguem um conjunto de regras, e a estrutura da IA dentro dessas regras é normalmente baseada em estados. Por exemplo, o time pode ter uma estratégia se o estado é “Vencendo”, outra se for “Empatando”, ou até uma estratégia complexa, se for “Perdendo a Final do Campeonato, Restando 10 min”. Porém, a transição para estes estados não pode ser precisa. Ai que entra a lógica fuzzy, tornando as decisões a serem tomadas propositalmente não tão claras e evidentes, apresentando um certo grau de incerteza e realismo ao jogador.

Data-Driven System
Com uma grande quantidade de jogadores, dados estatísticos e animações,  jogos de esporte contam com várias ações baseadas em dados pré definidos. Entre as mais populares, estão as animações de movimento e estatísticas de cada jogador.

Sistema de Mensagens
Partindo da realidade que jogadores reais de futebol comunicando-se durante o jogo, faz total sentido utilizar um sistema de mensagens para montar a estratégia do time. Entre os exemplos de aplicação, posso citar o zagueiro que informa aos companheiros  que está partindo para uma jogada de contra-ataque. Em resposta a esta informação, outro jogador pode “cobrir” a defesa.

Gênero: Racing

Esse gênero, nascido nos anos 80, coloca o jogador no controle de um veículo para disputar uma corrida contra outros competidores, ou às vezes, contra o tempo. Este gênero revolucionou a indústria de jogos em termos gráficos e de performance.

Máquinas de Estados Finitos
Jogos de Corrida seguem geralmente uma mesma fórmula. São definidos pelas leis da física e possuem objetivos simples. Dessa forma, os estados de um jogo deste gênero seguem um fluxo comum (Largada, Corrida, Fora da Pista, Chegada).

Algoritmos Genéticos

Alguns jogos de corrida possuem uma enorme quantidade de carros (Gran Turismo, por exemplo,  possui  500 modelos) e cada um exige uma forma peculiar de adaptação e manuseio do volante. Com essa realidade,  algumas empresas têm utilizado técnicas para automatizar a atividade de balanceamento através de uma simples aplicação de algoritmo genético, modificando os parâmetros de performance dos carros. Carros com diferentes atributos de dirigibilidades são combinados, gerando um terceiro. Isso é feito até que obtenha-se um bom resultado. Ao final, esses resultados são então armazenados e alimentam a lista de modelos do jogo.

Gênero: Luta

Este gênero contempla um combate fechado entre dois lutadores que utlizam movimentos especiais para atingir e vencer o adversário. Bom, é difícil definir este gênero, conhece Street Fighter? Pois então, é isso ai

Máquinas de Estados Finitos
Cada lutador em um jogo de luta possui seus movimentos mapeados em estados. Dependendo do estado do oponente (atacando, defendendo, recuando) o NPC irá efetuar uma estatégia de luta ou combinação de movimentos. Uma FSM pode atender à demanda da maioria dos jogos desse gênero. O mapeamento de estados é utilizado inclusive para os comandos do jogador. Se você já deu um “hadouken” saiba que ele também está dentro de uma FSM. Observe o autômato finito abaixo.

No diagrama acima, temos 4 círculos azuis, representando os estados “Baixo”, “Diagonal Inferior Direita”, “Frente” e “Hadouken“. Partindo de um estado inicial – representado pelo círculo preto – podemos interpretar a sequencia de comandos necessária para disparar o golpe. O processo inicia se o jogador pressionar a tecla para “Baixo”, fazendo a máquina se mover para o estado correspondente. Estando nesse estado, qualquer outro comando, que não seja o esperado, leva a máquina para o estado inicial novamente – indicado pelas setas vermelhas. Desta forma, se o jogador seguir corretamente a sequencia de teclas…

Ufa, espero que tenham gostado do post de hoje. O assunto é um pouco complexo, mas fiz o possível para condensá-lo e facilitar o entendimento. E ai o que acharam? Já é possível ter uma visão geral da I.A nos games, conhecendo o conceitos das principais técnicas utilizadas pela indústria? Espero o comentário de vocês.

Não deixe de conferir as partes 1 e 2, pois nos próximos posts, partiremos para a prática. É isso mesmo, vamos implementar as principais técnicas descritas até o momento. Esteja preparado para desenvolver o seu primeiro algoritmo de Path Finding, o A Star (A*).

Até lá!

Esta semana, especialmente, não teremos o nosso podcast. Mas não se preocupe, semana que vem voltamos com a periodicidade normal. Sendo assim, fique atento e não perca o próximo episódio com o tema Game Design. Nele entrevistamos Cassiano Canheti – Game Director da Hoplon, empresa responsável pelo audacioso projeto Taikodon.

Para o pessoal que está voltando de “férias”, ou de um carnaval estendido, recomendamos os episódios de fevereiro sobre criação de persoangens 3D – uma entrevista muito bacana com Alessandro Lima – escritor e Lead Character Designer na empresa Aquiris Game Experience.

• Episódio 12 – 3D Character Design parte 1
• Episódio 13 – 3D Character Design parte 2

Veremos como separar a lógica do jogo da renderização, fazendo a lógica rodar a uma taxa fixa (e baixa) e atualizando a tela o mais rápido possível. Embora esta seja uma técnica genérica, útil em qualquer tecnologia, é especialmente aplicável em jogos HTML onde o ideal é atualizar a lógica do jogo mais lentamente.

Continuaremos com o exemplo da parte anterior, sendo que os arquivos aojcanvas.js e aojinput.js permanecem inalterados. Nossa maior modificação não será no motor em sí, mas na própria página do jogo, onde temos a divisão do pulso em update() e render().

No entanto o motor recebe uma pequena modificação. Iniciaremos por ela.

Substituindo setInterval por setTimeout

Na conclusão da parte anterior, comentei sobre um problema que pode afetar o jogo caso a lógica demore muito para executar. No caso, o problema ocorre se a lógica levar mais tempo para executar do que o esperado para cada pulso.

Imagine que o pulso está agendado (com setInterval) para ser chamado a cada 50 milisegundos, mas por algum motivo nossa lógica leva 60 milisegundos. Ela ainda vai estar executando quando for disparado um novo pulso, iniciando novo processamento da lógica do jogo. Isso gera duas execuções em paralelo, diminuindo ainda mais a performance, piorando o prolema.

Para resolver isso, trocamos o uso de setInterval por setTimeout. A diferença entre elas é a seguinte:

• setInterval agenda chamadas contínuas para a rotina informada. Ou seja, fica chamando a rotina automaticamente a cada X milisegundos.
• setTimeout agenda apenas um execução da rotina. Ou seja, chama a rotina daqui a x milisegundos e só. Para executar a rotina novamente, precisamos agendar com um novo setTimeout.

A mudança que faremos, então, consiste em trocar a chamada de setInterval presente em aojStartGameLoop(), como também adicionar uma chama semelhante dentro de aojPulse. Veja abaixo.

function aojStartGameLoop() {
       ... // mesmo código de antes
       setTimeout('aojPulse()', 0); // trocamos setInterval por setTimeout
       // isso vai chamar aojPulse apenas uma vez, então dentro dela precisamos de outros setTimeout
}
 
function aojPulse() {
        ... // mesmo código de antes
        setTimeout('aojPulse()', 0); // adicionamos uma chamada a setTimeout - a cada pulso agendamos outro
    }
}

Bem, se você tiver prestado atenção, percebeu que o código acima não é exatamente equivalente ao que tínhamos antes. Estamos passando zero milisegundos para o setTimeout, o que faz com que a próxima execução seja agenda para imediatamente – ou, na prática, para tão logo seja possível. Ou seja, não respeitamos mais o limite de FPS informado, rodando, ao invés disso, na velocidade máxima possível.

Se colocarmos esse game loop nos exemplos anteriores, sem modificá-los, teremos a ação deles acelerada, porque neles a lógica roda a cada pulso, sem nenhum filtro. Mas a modificação que faremos nos exemplos dará conta disso.

Separando update() e render()

Vamos lembrar como era a relação entre nosso pulso e as rotinas update() e render() no exemplo anterior.

function pulse() {
    update();
    render();
}
 
function update() {
    ... // lógica do jogo
}
 
function render() {
    ... // atualiza a imagem na tela
}

Não poderia ser mais simples. A cada pulso executamos um update e um render. Vejamos agora o que muda. O código está abaixo e logo após a explicação.

var _lastMilisecond = 0;
var _updatesCount = 0;
var _updatesInLastSecond = 0;
var _lastUpdateMilisecond = 0;
var _frameCount = 0;
 
function pulse() {
    var d = new Date();
    if (d.getTime() - _lastMilisecond > 50) {
        _lastMilisecond = d.getTime();
        update();
        _frameCount = 0;
    }
    _frameCount ++;
    render(_frameCount / (_aojPulsesInLastSecond / _updatesInLastSecond));
}
 
function update() {
    _updatesCount ++;
    var d = new Date();
    if (d.getTime() - _lastUpdateMilisecond > 1000) {
        _lastUpdateMilisecond = d.getTime();
        _updatesInLastSecond = _updatesCount;
        _updatesCount = 0;
    }
    ... // lógica do jogo
}

Vamos analisar a rotina pulse() primeiro. Em linhas gerais, agora ela executa update() a cada x milisegundos e executa render() sempre, ou seja, a cada pulso. O filtro para update é feito com o seguinte algoritmo:

1. A cada pulso é obtido o tempo atual;
2. Se a diferença entre o tempo atual e o tempo armazenado anteriormente (_lastMilisecond) for maior do que 50 milisegundos:
   1. Armazenamos o tempo atual em _lastMilisecond;
   2. Zeramos _frameCount (explicada abaixo);
   3. Chamamos update();

O efeito disto é que update() é chamado a cada 50 milisegundos. Ignorei a rotina de informar o FPS desejado e utilizei o valor fixo 50, mas poderia ter feito algo configurável. Executando um update a cada 50 milisegundos terei 20 updates por segundo. Na realidade, teremos um pouco menos, porque a estes 50 milisegundos somamos o tempo de execução da própria rotina update().

O código colocado dentro da rotina update é comum e serve para contar quantas vezes por segundo ela é chamada. É o mesmo código que tínhamos dentro de aojPulse() no exemplo anterior.

A variável _frameCount serve para contar quantos frames (que nesse caso são iguais a pulsos) ocorrem entre duas chamadas de update. Por isso é zerada quando ocorre um update e a partir daí vai sendo incrementada a cada pulso.

Veja no gráfico abaixo como se comporta essa variável. Vamos assumir que a duração aqui seja 1 segundo, ou seja, temos 20 pulsos por segundo. As linhas vermelhas mostram os pulsos onde update é chamado (aqui temos apenas 4 updates por segundo, para simplificar).

Já a chamada de render é feita sem nenhum controle, ou seja, é chamada em todos pulsos. E veja que ela recebe um valor como parâmetro. Vejamos o que ele significa.

Esse valor é calculado da seguinte forma: primeiro a quantidade de pulsos ocorridos no último segundo é dividida pela quantidade de updates no mesmo período. Na figura acima, que representa 1 segundo, ocorreram 20 pulsos e 4 updates. Então temos 20/4 = 5.

Esse número (5) é a quantidade de pulsos que ocorre entre dois updates – e vem a ser a quantidade de vezes que render() é chamada entre dois updates.

Para completar o valor do parâmetro de render, dividimos o valor de _frameCount pela quantidade de pulsos entre dois updates, de forma a obter um valor normalizado entre 0 e 1. Por exemplo, quando _frameCount é 1, teremos 1/5 = 0.2; quando _frameCount é 2, teremos 2/5 = 0.4; quando _frameCount for 5, teremos 5/5 = 1. Veja na figura abaixo.

Interpolação

A interpolação consiste em obter valores intermediários entre dois valores conhecidos. Por exemplo, dados os valores 10 e 20, se fizermos a interpolação entre eles com três passos, teremos os valores (12.5, 15.0, 17.5). Se fizermos com 7 passos teremos (11.25, 12.5, 13.75, 15.0, 16.25, 17.5, 18.75).

Nosso objetivo aqui é interpolar as posições dos nossos sprites de forma a gerar posições intermediárias que não são calculadas pelo update. Por exemplo, digamos que no último update ocorrido nosso sprite tenha ficado na posição x=150 e no próximo update, ele vá para a posição x=180. Se nada for mudado em render, veremos nosso sprite saltar diretamente da posição 150 para a 180.

Lembre-se que entre estes dois updates tivemos (conforme a figura acima) 5 chamadas a render. Se não tivermos interpolação implementada, o que ocorre é que as cinco chamadas vão mostrar o sprite na posição 150, até que ocorre o próximo update e a posição muda para 180 – e os próximos cinco render mostrarão ele na posição 180, e assim por diante.

Com a interpolação, no entanto, calcularemos dentro de render posições intermediárias. Sabemos que são 5 render entre os updates. Assim, o primeiro render deverá mostrar o sprite a 1/5 (0.2) do caminho entre 150 e 180; o segundo update mostrará a 2/5 (0.4) do caminho; e o quinto mostrará a 5/5 (1.0) do caminho, ou seja, bem no 180.

Os valores 0.2, 0.4, etc, como vimos, são aqueles passados para render no parâmetro, que chamaremos de delta. Como usamos esse delta para afetar o x do sprite? Basta multiplicar o delta pela distância entre as duas posições (180 – 150 = 30) e somar na primeira posição (150).

Ou seja, a fórmula é essa: x = x1 + (x2 – x1) * delta, onde, no exemplo, x1=150, x2=180 e delta = 0.2, 0.4, 0.6, etc.

Os valores de x serão assim:

1. Primeiro update
   x = 150 + (180-150) * 0.2;
   x = 150 + 30 * 0.2;
   x = 150 + 6;
   x = 156;
2. Segundo update
   x = 150 + 30 * 0.4;
   x = 150 + 12;
   x = 162;
3. Terceiro update
   x = 150 + 30 * 0,6;
   x = 150 + 18;
   x = 168;
4. Quarto update
   x = 150 + 30 * 0,8;
   x = 150 + 24;
   x = 174;
5. Quinto update
   x = 150 + 30 * 1,0;
   x = 150 + 30;
   x = 180;

Veja como este recurso é poderoso: ele nos permitiu mostrar o sprite em 6 posições diferentes (150, 156, 162, 168, 174 e 180), embora a lógica do jogo tenha calculado apenas duas (150 e 180). Isso nos permite rodar o jogo a uma baixa taxa de updates, mas mostrar uma animação suave, tanto mais suave quantos forem os frames entre os updates.

Quanto melhor o desempenho do computador do jogador, mais vezes render vai ser chamada entre os updates e assim mais passos teremos em nossa interpolação, melhorando a animação.

Vejamos, então, como ficou o código da rotina render:

function render(delta) {
     aojFillRect(0, 0, aojCanvas().width, aojCanvas().height, 'gray');
     var x = carro.lastX + ((carro.x - carro.lastX) * delta); // x = x1 + (x2-x1) * delta
     var y = carro.lastY + ((carro.y - carro.lastY) * delta);
     aojDrawImage(carro.sprite, x, y);
     aojFillRect(57,5,50,20, 'blue');
     aojSetFont('');
     aojDrawText(_updatesInLastSecond + ' tps', 65, 20, 'yellow');
}

Mas que atributos são esses: “lastX” e “lastY”? Bem, estes são atributos adicionados ao sprite para armazenar a posição anterior dele – afinal, agora precisamos de duas posições para fazer a interpolação. Sempre que update muda o valor de x, armazena o anterior em lastX. Veja abaixo o código completo de update:

function update() {
      _updatesCount ++;
      var d = new Date();
      if (d.getTime() - _lastUpdateMilisecond > 1000) {
           _lastUpdateMilisecond = d.getTime();
           _updatesInLastSecond = _updatesCount;
           _updatesCount = 0;
      }
      carro.lastX = carro.x;
      carro.lastY = carro.y;
      carro.x += carro.dx;
      carro.y += carro.dy;
      if (carro.x < 0 || carro.x > aojCanvas().width) {
           carro.dx *= -1;
      }
      if (carro.y < 0 || carro.y > aojCanvas().height) {
           carro.dy *= -1;
      }
}

Está implementada assim a interpolação da posição do sprite entre updates, criando um movimento mais suave e contínuo do que tínhamos no exemplo anterior.

Conclusão

Como dito no início deste post, a interpolação é uma técnica genérica, que pode ser utiliza em qualquer motor para melhorar a aparência do movimento dos sprites. Mas é especialmente bem vinda em jogos para navegadores, já que o desempenho do javascript ainda não é tão alto. Assim, é bom podermos rodar o jogo a uma taxa de atualização mais baixa, dando mais tempo para a lógica dentro de update ser executada, sem, no entanto, ter a animação prejudicada.

Uma coisa interessante de notar nessa técnica é que o que vemos na tela está sempre um passo atrás da lógica do jogo. Veja vem: quando o update coloca o sprite na posição 180, recém inicia a apresentação dele entre 150 e 180. Quando ele chegar no 180, já teremos outro update que colocará o sprite mais para frente, digamos x=210. Agora o render vai interpolar entre 180 e 210.

Isso não causa nenhum problema visível na maioria dos jogos, mas naqueles cuja ação é muito rápida (geralmente shooters), poderão ser percebidas discrepâncias com relação aos controles – afinal, o input está sendo processado pelo update, levando em conta a posição atual, enquanto o render vem atrás, interpolando a partir da posição anterior.

Nesses casos extremos não podemos usar a posição atual com relação à anterior. É preciso, de alguma forma, usar a posição atual com relação à próxima, que ainda não foi calculada! Para isso usamos a extrapolação ao invés da interpolação – basicamente é seguir o calculo da interpolação passando do valor de destino. Mas essa já é outra história. Fica como lição de casa…

• Visualizar o exemplo do game loop
• Visualizar o exemplo de input
• Baixar o código fonte do exemplo