Manual do Indie Game Developer - Versão Android e iOS.pdf

Manual do Indie Game Developer

Versão Android e iOS

Todos os direitos para a língua portuguesa reservados pela EDITORA CIÊNCIA MODERNA LTDA.

De acordo com a Lei 9.610, de 19/2/1998, nenhuma parte deste livro poderá ser reproduzida, transmitida e gravada, por qualquer meio eletrônico, mecânico, por fotocópia e outros, sem a prévia autorização, por escrito, da Editora.

Editor: Paulo André P. Marques

Produção Editorial: Aline Vieira Marques Assistente Editorial: Amanda Lima da Costa Capa: Carlos Arthur Candal

Diagramação: Equipe Ciência Moderna

Várias Marcas Registradas aparecem no decorrer deste livro. Mais do que simplesmente listar esses nomes e informar quem possui seus direitos de exploração, ou ainda imprimir os logotipos das mesmas, o editor declara estar utilizando tais nomes apenas para fins editoriais, em benefício exclusivo do dono da Marca Registrada, sem intenção de infringir as regras de sua utilização. Qualquer semelhança em nomes próprios e acontecimentos será mera coincidência.

FICHA CATALOGRÁFICA MELO JUNIOR, Cleuton Sampaio de.

Manual do Indie Game Developer - Versão Android e iOS

Rio de Janeiro: Editora Ciência Moderna Ltda., 2013.

1. Informática 2. Linguagem de Programação 3. Jogo eletrônico

I — Título

ISBN: 978-85-399-0460-2 CDD 0001.642 005.133 323.43

Editora Ciência Moderna Ltda. R. Alice Figueiredo, 46 – Riachuelo

Rio de Janeiro, RJ – Brasil CEP: 20.950-150 Tel: (21) 2201-6662/ Fax: (21) 2201-6896 E-MAIL: LCM@LCM.COM.BR

que trabalhar um só dia em sua vida.”

Sumário

Capítulo 1 - Introdução ����������������������������������������������������������������������1

Sobre as plataformas ... 1

Sobre o código-fonte ... 2

Capítulo 2 - Revisão de conceitos ������������������������������������������������������3

Jogos de ação ... 7

Macro funções de um game ... 8

Model / View / Controller ... 10

Objetos e elementos típicos de um Game ... 11

Jogabilidade ... 13

Fatores de sucesso de um Game ... 14

Capítulo 3 - Kit de ferramentas para criação de games ����������������17

Imagens ... 17

Transparência e canal alpha ... 18

Unidades de medida ... 20

Arquivos de imagem ... 21

Ferramenta para “Sketch” ... 22

Ferramentas para desenho Raster ... 23

Ferramentas para desenho vetorial ... 24

Comparação entre renderização raster e vetorial ... 25

Game engines ... 28

HTML 5 + Javascript ... 28

Nativos ... 28

Usar a plataforma nativa ... 30

Ambientes multiplataforma ... 30

Prototipadores ... 31

Bibliotecas auxiliares ... 31

Capítulo 4 - Prototipação do game ��������������������������������������������������33

Um tutorial rápido em Codea ... 35

Usando o “Processing” ... 49

Um tutorial rápido no “Processing” ... 51

Criando o protótipo do “AsteroidNuts” com o “Processing” ... 54

Crie vários protótipos ... 64

Capítulo 5 - Física de games �������������������������������������������������������������65

Bullet Physics Library ... 76

Chipmunk physics engine ... 77

Box2D ... 77

Física com Box2D ... 78

Preparando o laboratório ... 79

O laboratório Java ... 80

Normalização e ajuste para renderização ... 85

Fundamentos do Box2D ... 87

Força e atrito ... 93

Corpos circulares ... 97

Rotação dos corpos ... 98

Desenhando corpos como polígonos ... 100

Desenhando corpos como imagens ... 102

Torque e impulso ... 107

Deteção de colisão ... 110

Juntas ou junções ... 113

Usando o Box2D em plataformas móveis ... 123

Box2D no Android ... 123

Box2D no iOS ... 132

Capítulo 6 - Renderização com OpenGL ES 2�0 ��������������������������143

Fundamentos ... 146

Coordenadas dos vértices e da textura ... 146

Programas de sombreamento ... 152

Matrizes ... 154

Exemplo utilizando Android e projeção perspectiva ... 159

Entendendo a GLSurfaceView ... 160

A implementação ... 163

Concluindo ... 175

Exemplo utilizando iOS e projeção perspectiva ... 176

Entendendo o GLKit ... 176

Criando uma aplicação OpenGL ES ... 178

A implementação ... 179

Achatando as coisas ... 190

Implementação em Android ... 190

Implementação em iOS ... 193

Capítulo 7 - Framework de Física e Renderização ����������������������195

O esquema XML do arquivo de modelo de game ... 197

Proporcionalidade dos GameObjects ... 200

Coordenadas e VBOs ... 201

Movimento e rotação de objetos ... 204

Atualização do mundo Box2D ... 205

Renderização do modelo ... 206

Mipmaps ... 207

Uso do Framework ... 209

Conclusão ... 212

Capítulo 8 - Técnicas Comuns em Games ������������������������������������215

Aumentando o framework de game ... 220

Integrando o game em uma aplicaç�o móvel ... 226

Plataforma Android ... 227 Plataforma iOS ... 231 Tempo e movimento ... 233 Game Loop ... 234 Movimento ... 247 Efeito de paralaxe ... 256 Técnicas de paralaxe ... 257

Implementação Android ... 261

Implementação iOS ... 267

Games do tipo plataforma ... 273

Implementação Android ... 276 Implementação iOS ... 278 Sistemas de partículas ... 280 Composição ... 280 Um exemplo ... 281 Implementação em Android ... 283 Implementação iOS ... 291 Conclusão ... 296

Capítulo 9 - Vamos Criar um Game ����������������������������������������������297

Licença de uso do código-fonte ... 299

A concepção ... 300

Jogos casuais ... 301

Jogabilidade ... 301

Implementação Básica ... 302

I18N e L10N ... 302

Alterações no modelo do game ... 303

Alterações na carga do nível corrente ... 307

Alterações no Game Loop ... 309

Colisões ... 311

Registro de tempos ... 315

�est�o de memória no iOS ... 323

Uso do GLKBaseEffect ... 324

Procure Memory Leaks ... 327

Verifique se está realmente liberando a memória ... 328

Conclusão ... 332

Capítulo 1

Introdução

Quando eu comecei a desenvolver games, li muitos livros sobre o assunto e fiz muitas pesquisas no �oogle. Muitos dos problemas que eu passei no início tive que batalhar muito para resolver sozinho. Dessa forma, reuni um conjunto de técnicas ao longo do meu aprendizado, que são úteis até hoje. Durante esse aprendizado, notei que é muito difícil encontrar guias práticos de uso, com exemplos simples, o que nos força a ler muito e escrever muitas provas de conceito, perdendo tempo neste processo.

Então, resolvi colocar no papel tudo o que eu havia aprendido, e que po-deria ser útil para outras pessoas. Assim, nasceu a ideia deste livro, que é um guia prático com soluções para os problemas comuns no desenvolvimento de games móveis.

Eu queira algo mais que um “recipe book” (livro de receitas), porém me-nos que uma referência completa. Um livro que você consegue ler rapidamen-te e consultar sempre que precisar, com inúmeros exemplos em código-fonrapidamen-te, além de um game completo.

Neste livro, eu assumo que você, leitor, leitora, é um desenvolvedor ex-periente e que deseja criar games para plataformas móveis, especialmente: Android e iOS. Apesar de já haver escrito livros introdutórios sobre o assunto, este é um livro para profissionais que desejem entrar no lucrativo negócio de desenvolvimento de games, tornando-se um “Indie �ame Developer” (desen-volvedor independente de games).

Ao longo do livro, você construirá um framework simples, porém abran-gente, e que pode ser utilizado para criar games móveis biplataforma (Android e iOS) rapidamente. O game exemplo do livro “Bola no Quintal”, foi feito em apenas 1 semana para as duas plataformas!

A melhor maneira de aproveitar todo o conteúdo é ler com a “mão na mas-sa”, rodando todos os exemplos de código.

S

Este livro apresenta exemplos em Android e iOS, logo, você deverá ter instalados os dois kits de desenvolvimento. Nada impede que você opte por uma das duas plataformas, pois o livro n�o obriga você a conhecer ambas. A

plataforma Android utilizada é a última vers�o disponível (4.2, API = 17), po-rém, os exemplos podem ser executados em qualquer dispositivo com versão “�ingerbread” (maior ou igual a 2.3). A plataforma iOS utilizada é também a última vers�o disponível (6.1), com Xcode 4.5.

Se optar por utilizar as duas plataformas, será necessário utilizar um com-putador Mac / OS X, com versão mínima “Mountain Lion”, podendo desen-volver para Android e iOS.

S

-

Todo o código-fonte do livro está disponível para download, em formato zip. Você poderá encontrá-lo nos seguintes locais:

• Site da editora: http://www.lcm.com.br, procure pelo título do livro; • Site específico deste livro: http://www.indiegamerbrasil.com; • Site “The Code Bakers”: http://www.thecodebakers.com.

Se tiver alguma dúvida ou dificuldade para instalar os projetos ou sobre o livro, por favor me contate:

Capítulo 2

Revisão de conceitos

�ames... Que coisa apaixonante! S�o capazes de despertar emoções, tanto negativas como positivas e são obras de arte “vivas”, que deixamos para a posteridade. Se você nunca criou um game, n�o sabe qu�o boa é a sensaç�o de saber que as pessoas passam horas se divertindo com a sua criação.

Se alguém me diz que criou um compilador, ou um sistema operacional, certamente vai me impressionar. Agora, se alguém me diz que criou um Game, certamente vai chamar minha atenção imediatamente. Para mim, o “ultimate fight” de todo programador é criar um �ame. Isto é o que diferencia os bons dos comuns.

Para mim, desenvolver um �ame é a maior prova de competência para um programador. É realmente um desafio muito grande, pois existem muitos aspectos a serem abordados. Um game é um projeto de software complexo, com vários recursos, de áreas diferentes envolvidas.

t

g

Existe mais de uma maneira de classificarmos um game, dependendo do ponto de vista. Se estivermos falando sobre visualização, podemos começar com:

• Games 2D: aqueles em que jogamos nos movendo apenas em duas

direções. Podem até utilizar recursos para dar “ilusão” de profundi-dade (como “paralaxe”, vis�o isométrica etc), mas nos movemos em um plano. Existem jogos que permitem mudar de plano (e perspec-tiva), como o “Fez” (http://en.wikipedia.org/wiki/Fez_(video_game)), mas ainda são basicamente 2D nos movimentos;

• Games 3D: aqueles em que jogamos nos movendo em seis graus de

liberdade (http://en.wikipedia.org/wiki/Six_degrees_of_freedom), com movimentos possíveis de: aproximaç�o / afastamento (eixo “z”), di-reita / esquerda (eixo “x”), cima / baixo (eixo “y”), e rotações em cada eixo. Alguns games 3D não permitem isso tudo, restringindo as rotações, por exemplo;

Há uma certa confusão quando falamos em “Games 3D”. Algumas pessoas confundem este conceito com ilusão 3D. Na verdade, o conceito que a litera-tura e os “gamers” mais aceitam é o dos “6 graus de liberdade”.

Ilustraç�o 1: Seis graus de liberdade

(autor: Horia Ionescu, Wikipedia http://en.wikipedia.org/wiki/Six_degrees_of_freedom)

A figura anterior nos mostra os movimentos possíveis em um verdadeiro �ame 3D. Podemos: correr, pular, saltar, rolar (nos três eixos) etc. Alguns ga-mes limitam o movimento somente aos três eixos, evitando rotações, porém, mesmo assim, não se limitam a um plano, como os Games 2D.

Também podemos classificar um �ame quanto ao seu tipo de projeç�o, que é a maneira como o modelo é projetado na tela.

Ilustraç�o 2: Projeç�o 3D

Se for um Game 3D, isto é mais crítico ainda. A tradução do modelo “espa-cial” para o modelo 2D da tela pode ser feito de várias maneiras:

• “Projeção Ortográfica” (ou ortogonal): é a ilus�o de 3D criada ao criarmos projeções ortogonais ao plano, ou seja, não há diferença de tamanho entre objetos próximos e objetos distantes. Desta forma, mostramos os elementos em um ângulo diferente do que veríamos apenas de cima, ou de lado. Evita os cálculos complexos de projeção 3D e mantém uma boa ilusão para o jogador.

• “Visão Isométrica”: n�o é uma projeç�o, mas uma forma de mos-trarmos os objetos. Neste tipo de visão, rotacionamos um pouco os eixos para mostrar mais detalhes dos objetos, criando a ilusão 3D. Neste caso, o ângulo entre os eixos (x, y, z) no plano é igual, ou seja: 120 graus. Normalmente, a vis�o isométrica é utilizada com proje-ç�o ortográfica. Era muito comum nos anos 80 e 90, embora alguns jogos ainda a utilizem. Alguns exemplos famosos que usam visão isométrica: Q*Bert (Gottlieb), Civilization II (MicroProse), Diablo

(Blizzard);

• “Projeção Perspectiva”: vem do desenho tradicional, no qual as partes mais próximas parecem maiores do que as mais distantes. Também é conhecida como perspectiva cônica. Dão maior ilusão de realidade aos games, porém exigem maior complexidade de progra-maç�o e poder de processamento. Os jogos mais modernos, como:

Battlefield, Assassin’s Creed, Halo e outros apresentam visão em

perspectiva;

Ilustraç�o 3: Projeções 2D de um cubo

É claro que procurei simplificar ao máximo o conceito de projeç�o 3D, mas é apenas para facilitar o entendimento. Se quiser saber mais, recomendo um bom livro, como o “Mathematics for Game Developers”, de Christopher Tremblay (Amazon). Porém, existem bons artigos introdutórios na Wikipedia:

• Perspectiva (gráfica): http://pt.wikipedia.org/wiki/Perspectiva_(gr%C3%A1fica); • Isometria: http://pt.wikipedia.org/wiki/Isometria_(geometria);

• Isometric graphics in video games and pixel art: http://en.wikipedia. org/wiki/Isometric_graphics_in_video_games_and_pixel_art;

Também existem classificações de games quanto às suas características, algumas delas s�o:

• “Arcade”: este termo é mal interpretado, mas sua origem vem das máquinas de jogos, conhecidas aqui como “Fliperama”. Jogos “ar-cade” possuem regras simples, partidas rápidas, com pontuação,

vidas, vis�o Isométrica etc). Exemplos de “arcades” clássicos: “Spa-ce invaders” e “Pac-Man”. Os jogos “arcade” evoluíram e hoje est�o disponíveis em várias plataformas, incluindo mobile;

• Jogos de Ação: desafiam o jogador fisicamente, seja por

coorde-nação motora, visão de movimento ou tempo de reação. Possuem várias subcategorias, como: plataforma, tiro e luta. Exemplos clás-sicos: “River raid” (Atari), “Sonic” (SE�A), “Super Mario (Ninten-do) e outros mais modernos, como: “Angry Birds” (Rovio), “Jetpa-ck joyride” (Halfbri“Jetpa-ck). Na verdade, “arcades” s�o jogos de aç�o, só que com regras e visual mais simples;

• Aventura (adventure): jogos que desafiam a inteligência do

joga-dor, colocando-o em determinado mundo, com uma miss�o a cum-prir. Nos primórdios da computaç�o pessoal, os jogos de aventura eram simples, muitas vezes textuais, ou com poucos gráficos. Eu gosto de citar os exemplos do Renato Degiovani, como: “Serra Pe-lada” e “Angra-I”. Hoje em dia, muitos jogos de aventura também misturam características de jogos de ação, como os “Shooters”;

• Role Playing Game (RPG): s�o derivados dos famosos jogos de

RPG textuais, como “Dungeons & Dragons”. Na verdade, são jogos de aventura, nos quais o jogador assume um papel e uma vida para-lela em um universo virtual. A principal diferença para os jogos de aventura tradicionais é a duração do jogo, que pode ser indetermi-nada. Hoje em dia, os jogos RPG ganharam versões multiusuário online, como os MMORPG – Massively Multiuser On-line RP� (RP�s on-line massivamente multiusuários). Exemplos: “World of Warcraft” (Blizzard) e “Ragnarök” (�ravity Corp);

• Tile based games: podem ser jogos de aç�o ou RP�, nos quais os

personagens se movem em um “tabuleiro”, de casa em casa. Exis-tem vários padrões e ferramentas para criar “Tile Based Games”, como o padr�o TMX (https://github.com/bjorn/tiled/wiki/TMX--Map-Format) e TiledEditor (http://www.mapeditor.org/). Alguns RPGs e jogos de aventura são também “Tile Based”;

• Menu games: s�o jogos de simulaç�o e RP�, com interface baseada

em escolha. Parecem muito com os jogos de cartas, como: “Magic”. Você tem uma série de atributos e vai desafiando os outros jogado-res, acumulando vitórias ou amargando derrotas. Um bom exemplo é o “Mafia Wars” (Zynga);

• Simuladores: simulam veículos ou atividades. Existem simuladores

de voo (Microsoft Flight Simulator), de carro (�ran Turismo – Sony), de cidade (SimCity – Maxis). S�o mais difíceis e desafiadores;

• Estratégia: s�o uma mistura de simulaç�o e RP�, no qual o

joga-dor tem que conquistar um objetivo, geralmente através da guerra. Exemplos: “Age of Empires” (Microsoft) e “Civilization” (Micro Prose);

Outra classificaç�o importante é quanto ao público-alvo do �ame, por exemplo:

• Infantis: jogos para crianças, geralmente n�o alfabetizadas ou em

fase de alfabetização. São simples e visuais;

• Jogos para meninas: as meninas est�o cada vez mais “tomando de

assalto” o mundo dos games e existem jogos específicos para elas, como: jogos de vestir, jogos de cozinhar, jogos de princesas;

• Casual games (jogos casuais): s�o feitos para quem n�o é jogador

habitual (ou “gamer”). S�o para pessoas que jogam casualmente, sem ter isto como atividade constante. Podem ser de vários tipos, mas, geralmente, são simples, com poucas regras, fácil jogabilidade e baixo comprometimento (você n�o tem que criar uma “carreira”). Podem ser quebra-cabeças simples, como: “Where is my water” (Disney) ou jogos de tiro, como “Angry Birds” (Rovio);

• Hardcore games: s�o feitos para jogadores habituais ou “gamers”.

Normalmente, exigem um comprometimento maior do jogador, que tem que criar uma “carreira” virtual, que pode ser comunicada em redes sociais de games. �eralmente possuem várias sequências, como: “Assassin’s Creed” (Ubisoft), “Battlefield” (EA �ames) ou “�ran Turismo” (Sony);

Jogos de ação

O objetivo principal deste trabalho são jogos de ação. Em primeiro lugar, porque todos os elementos clássicos (Player Object, NPC, �ame loop) s�o en-contrados neles e, em segundo lugar, porque são uma “porta de entrada” para o desenvolvimento de games.

Os jogos de aç�o podem ser divididos também em subcategorias, como:

• Plataforma: s�o jogos 2D com ilus�o 3D, nos quais o jogador se

move entre plataformas, de diversas altitudes, pulando, correndo e saltando. Ele pode ter que enfrentar desafios físicos, como abismos,

ou mesmo adversários. Exemplos s�o: “Sonic” (SE�A), “Super Ma-rio” (Nintendo) e, mais modernamente, “Super Meat Boy” (Team Meat);

• Tiro: seu objetivo é matar inimigos atirando diretamente neles ou

derrubando-os. Podem ser simples como o “Angry Birds” (Rovio), ou complexos, como o “Doom” (Id Software / Nerve Software). En-tre os jogos de tiro, existem os “First Person Shooters”, nos quais a vis�o é a do jogador (em primeira pessoa), ou “Third Person Shoo-ters”, nos quais a visão é externa ao jogador;

• Luta: s�o jogos nos quais o jogador é desafiado a derrotar

lutado-res, que podem ser totalmente virtuais, ou avatares controlados por outras pessoas. Alguns exemplos s�o: “Street Fighter” (Capcom) e “Mortal Kombat” (Midway games);

Jogos de ação são baseados em tempo, ou seja, a cada fatia de tempo a posiç�o do jogador (e das balas) muda, sendo atualizada constantemente. Quando o processamento de uma fatia de tempo demora demais, acontece o efeito de “Lagging”, que é quando o jogador percebe a lentidão do jogo em determinados momentos. O “Lag” pode ter diversas causas, como a latência da rede, em caso de jogos multiusuário, ou mesmo a lentidão da renderização de frames. O “Lag” pode causar grande insatisfação no usuário, compromen-tendo o sucesso do Game.

Devido a esta característica de sensibilidade ao tempo, jogos de ação exi-gem muito do programador. É necessário racionalizar os gráficos, utilizando ao máximo o poder de processamento de �PU (�raphics Processing Unit), e também empregar recursos de multiprogramação, de modo a aproveitar o pa-ralelismo, afinal, muitos dispositivos móveis s�o multicore (dotados de mais de uma CPU – ou núcleo).

m

Se pensarmos nas macrofunções de um game, veremos algo como o dia-grama seguinte.

Inventário

Responsável pelos objetos e propriedades do Game. Os elementos ativos do jogo (personagens ou Player Objects e NPCs) e suas propriedades (quan-tidade de vidas etc).

Pontuação

Responsável por acompanhar a pontuação do usuário, suas conquistas e o compartilhamento destas informações.

Estratégia

Quando o jogo tem caracteres próprios, n�o manipulados pelo usuário (Non-Player Character ou NPC), é preciso dar alguma inteligência a eles, caso contrário, o jogo será fácil demais. Alguns tipos de jogos dispensam a estratégia, baseando-se apenas em cálculos aleatórios, como: labirintos, por exemplo. Jogos do tipo “Shooting” (2D, 3D, TPS, FPS), quando n�o est�o em modo multiusuário, necessitam de estratégias avançadas, para dar a sensação de realidade ao usuário.

Configuração

Responsável pela persistência e recuperaç�o de todas as informações de configuraç�o do jogo, como: níveis oferecidos, nível do jogador, conquistas, opções etc.

Game loop

É o conjunto de comandos repetidos a cada fatia de tempo, responsáveis por movimentar os objetos, atualizando o modelo de dados. Ele também pode, ao final do processamento, invalidar a apresentaç�o, ordenando o redesenho da tela. Em jogos de ação, geralmente existe um Game loop baseado em tem-porizador, que atualiza a tela em determinadas fatias de tempo (time frame). Alguns tipos de jogos dispensam este recurso.

Animação

Os caracteres do jogo e até mesmo o cenário podem exibir animações. O personagem pode sorrir, chorar, gritar e o cenário pode mudar. Até mesmo a movimentação dos personagens é tratada por esta função. A animação também envolve a técnica utilizada para desenhar os objetos na tela a cada fatia de tempo passada.

Física

A macrofunção de física é muito importante em jogos de ação. Ela é res-ponsável por dar realismo ao movimento dos caracteres. Coisas como: impul-so, gravidade, movimento e colisão são tratadas por esta função.

Interação

Controla a maneira pela qual o usuário interfere no jogo. É responsável por capturar o “input” do usuário e converter em ações no jogo.

Comunicação

É responsável por comunicar ao usuário o “status” do jogo, e também o resultado de suas ações. Pode manter “energy bars”, contadores, emitir sons, acionar explosões etc.

Algumas destas macrofunções podem ser implementadas em parte por bi-bliotecas de terceiros, como: Box2D e Open�L ES. Porém, mesmo assim, é necessário um esforço do desenvolvedor para configurar e interagir com elas.

Uma função muito importante é a de “Inventário”, que também abrange o modelo de dados do Game.

Model / View / Controller

Um �ame bem construído é sempre baseado no padr�o MVC – Model / View / Controller, no qual os três aspectos da aplicaç�o est�o separados:

• Model: responsável por manter o estado da aplicaç�o;

• View: responsável por ler o estado atual e apresentar ao usuário; • Controller: responsável por alterar o estado da aplicaç�o atualizando

o modelo e controlar a atualização da “View”;

O modelo de um �ame é a sua representaç�o em memória. Normalmente, mantemos referências dos objetos ativos, como: caracteres e cenário. Mas po-demos ter variações, como camadas diferentes, para dar efeito de “paralaxe” (http://en.wikipedia.org/wiki/Parallax_scrolling), que é quando os objetos distan-tes se movem mais lentamente do que os objetos mais próximos, dando ilus�o de profundidade.

Na figura, vemos três camadas de objetos (céu, celeiros e ch�o), que se movem em velocidades diferentes, dando ilusão de profundidade ao Game.

A camada de apresentaç�o (ou View) de um �ame é responsável por cap-turar o estado do modelo e desenhar os objetos em sua posição atual. Existem várias técnicas para desenhar objetos, desde utilizar os próprios “Widgets” nativos do aparelho (Android ImageView ou iOS UIView), ou desenhar di-namicamente os elementos (Android onDraw / iOS drawRect:(C�Rect)rect).

Finalmente, a camada Controller tem a missão de atualizar o modelo e ordenar que a camada de apresentação atualize a tela. A camada Controller é responsável por executar o “Game loop” e por obter o “input” do usuá-rio. Também deve se comunicar com a macrofunção de “Estratégia” para ver como o jogo deve reagir.

o

g

Temos alguns elementos comuns em vários tipos de games, especialmente nos jogos de ação. Por exemplo, sempre existe um objeto que representa o jo-gador ou que ele está controlando diretamente. Este tipo de objeto é chamado de “Player Object”. Existem casos em que mais de um PO (Player Object) existe ao mesmo tempo, e o jogador consegue mudar o controle de um para outro (Sonic & Tails, Jogos de Futebol etc). Porém, geralmente, o jogador está controlado apenas um único PO a cada momento.

O Player Object pode ser uma nave, como no famoso jogo “Asteroids” (Atari – http://en.wikipedia.org/wiki/Asteroids_(video_game)), no qual o jogador tinha uma nave e podia virar e atirar contra os asteroides. Também pode ser um objeto como uma bola, como no jogo para iPad “Labirynth HD” (Illusion Labs AB). No jogo que apresentei em meu último livro, “BueiroBall”, o joga-dor controlava a mesa, logo, todas as bolas eram POs.

Outro tipo de objeto é o NPC – Non Player Character (Caractere ou per-sonagem n�o controlado pelo jogador). Ele representa o adversário, que pode (ou n�o) ser dotado de alguma inteligência. Nos jogos multiusuário, o NPC pode ser um PO controlado por outro Jogador, ou pode ser algo controlado pela inteligência do jogo em si. NPCs existem para complicar a vida do joga-dor, tornando a partida mais divertida e interessante. Quem é que não se lem-bra das “tartarugas” do “Super Mario”? O ponto mais importante dos NPCs é que eles possuem “movimento” e “comportamento”, ou seja, podem atirar, perseguir, se esconder, explodir ou tomar atitudes, que são controladas pela macro função de “Estratégia” do jogo. Um NPC é sensível ao movimento e à colisão.

Levando em conta a característica de sensibilidade ao tempo, típica dos jogos de ação, um NPC ocupa fatia considerável do processamento e dos re-cursos. Quanto mais NPCs um jogo tem em determinado momento, maior a quantidade de recursos para atualizá-los e movimentá-los. Balas também podem ser consideradas como NPCs, pois se movimentam e são sensíveis a colisões.

Também existem os objetos estáticos, que não são sensíveis a colisões. Objetos estáticos podem até se mover, mas sempre como parte de um cenário. Não são sensíveis a colisões e nem podem ser controlados pelo jogador. Al-guns exemplos: cenário, nuvens, árvores distantes, montanhas etc. Em certos casos, os objetos estáticos nem existem, sendo parte da imagem de fundo. Em jogos mais modernos, objetos podem ser acrescentados ao fundo para dar a ilusão de paralaxe. O importante é que objetos estáticos não podem ser afeta-dos pelo PO ou pelos NPCs. Jogos mais modernos permitem que se deforme em algum grau o cenário, destruindo prédios, veículos de fundo etc. Nestes casos, os objetos estáticos estão se comportanto como NPCs, recebendo e se deformando em função de tiros, o que exige um alto poder de processamento da console ou do dispositivo móvel.

Game Loop é o núcleo de atualização de um jogo de ação. É nele que

ocorre a atualização do “Modelo” e pode também ocorrer a “renderização” da “View” (MVC). Os game loops mais simples podem fazer apenas isto:

1. Verificar se o usuário entrou com algum estímulo; 2. Executar a estratégia pra os NPCs;

3. Mover o Player Object; 4. Mover os NPCs; 5. Verificar colisões; 6. Atualizar inventário; 7. Invalidar a “View”; 8. Dar feedback sonoro.

Na verdade, o �ame loop constrói um “momento” do jogo, que é apresen-tado em sequência de modo a dar a ilus�o de movimento. Apesar de parecer simples, existem várias considerações importantes a respeito do Game loop. Por exemplo, ele comanda a renderizaç�o? Ele é baseado em time-frame? Ele roda em um “Thread” separado? Como lidar com a concorrência?

Em alguns casos, o Game loop é independente da fase de “renderização”, e ocorrem em momentos (e até em CPUs) separados. O ideal é que o �ame loop seja “enxuto” o suficiente para rodar a cada Time-frame, evitando “Lag”.

Outro problema típico é a aceleração provocada pelo hardware. Por exemplo, ao jogar em um dispositivo mais veloz, o �ame loop fica mais rápido e os NPCs também. É preciso haver um controle de temporização, garantindo um “frame-rate” (taxa de atualizaç�o) constante por segundo. Normalmente os games atuam entre 30 e 60 FPS (frames por segundo).

Game Level ou nível, pode ser entendido como duas coisas diferentes: o

nível em que o jogador está e o cenário do nível atual. Na verdade, Game Le-vel é o conjunto de: cenário, miss�o e elementos que o jogador deve enfrentar em um jogo. Alguns jogos não possuem este conceito, por exemplo os “Never ending games” (jogos que n�o terminam), como o “Temple Run” (Imangi), por exemplo.

Jogabilidade

Jogabilidade, ou “Gameplay”, é uma característica ligada à usabilidade do jogo, ou seja, o qu�o o jogo nos diverte. Eu diria que é o somatório das expe-riências do usuário durante o jogo, que envolve: facilidade de controle, boa visualizaç�o de informações, nível crescente e ajustado de desafios etc.

Outros aspectos que influenciam a jogabilidade s�o: • Satisfação proporcionada ao jogador;

• Facilidade de aprendizado do jogador;

• Eficiência de envolvimento. O qu�o eficientemente o jogo envolve o jogador. Jogos eficientes envolvem o jogador rapidamente;

• Motivação para evolução, ou se o jogo motiva o usuário a cumprir atividades;

• Cativação, se o jogo faz com que o usuário volte a jogar novamente ou se interesse em adquirir novas fases, armas etc;

Um dos fatores importantes na jogabilidade pode ser a socialização, ou a facilidade que o game dá para divulgar suas conquistas.

Muita gente confunde “jogabilidade” com “facilidade de jogar”, que é um dos aspectos do conceito. Embora seja muito importante, a usabilidade (faci-lidade de jogar) sozinha n�o garante o sucesso de um game.

Talvez seja melhor citar alguns exemplos de games com boa jogabilidade: • “Angry Birds”: simples, fácil e rápido de aprender;

• “World of Goo”: fantástico! Embora seja um jogo de desafios, sua jogabilidade é ótima;

• “Fruit Ninja”: igualmente simples e fácil, com alta eficiência de envolvimento.

f

g

Um game bem projetado envolve várias atividades separadas:

• Game design: é o processo de criar o conteúdo, as regras, os

cená-rios, os personagens e a Jogabilidade. É um trabalho que envolve várias especialidades, não apenas programação. Durante o Game design é muito produtivo criar protótipos do �ame, para avaliar se o conjunto está agradando;

• Mecânica do Jogo: estuda-se a interaç�o do usuário com o �ame,

como serão os movimentos, controles e como serão implementadas as regras. A mecânica também se preocupa com o “desacoplamento” entre os níveis e o código-fonte, procurando parametrizar a seleç�o e montagem de níveis. Também pode envolver prototipação para estudo e seleção de alternativas, além de seleção de “engines”, mo-dalidades e recursos para dar ao usuário a melhor experiência com o game;

• Game construction: é a programaç�o do jogo propriamente dita,

que engloba a criaç�o de artefatos (imagens, sons, música), níveis (cenários, dificuldade, etc) e código-fonte para a implementaç�o da mecânica do jogo de acordo com o “Game design”;

São aspectos diferentes entre si e que não devem ser tratados apenas como problemas de programaç�o. Em equipes independentes (“indie gamers”) é co-mum termos esses conceitos misturados, porém, os games mais bem sucedidos são aqueles em que existem especialistas de várias dessas áreas envolvidos.

Outro fator de sucesso, sem dúvida é o visual do Game, que deve ser atra-tivo e coerente com o �ame design, ou com a história e ambientaç�o. Um dos exemplos mais interessantes é o do “World of �oo” (2D Boy), que tem um visual meio dark e nojento, bem apropriado para as bolas de “Goo” do jogo (gosma ou coisa nojenta). Outros exemplos de visual interessante s�o: “Angry Birds” (Rovio), “Fruit Ninja” e “Jetpack joyride” (Halfbrick), “Where’s my water” (Disney) e vários outros.

Quando falamos em jogos móveis (este trabalho é voltado para eles), a jogabilidade tem outros critérios de avaliação. Quando estamos em casa, com um Xbox / Kinect, da Microsoft, ou um PS3, temos vários recursos para con-trolar o �ame, porém, quando estamos com um Smartphone (um iPhone ou um Android qualquer) ou mesmo um Tablet, os recursos s�o mais limitados. Embora contemos com acelerômetro e multitoque, não temos o mesmo con-trole que um Joystick ou um dispositivo ótico proporcionam. A tela é menor e, geralmente, n�o estamos em um ambiente ótimo para jogar (penumbra,

silêncio e uma tela de LED enorme). A jogabilidade para jogos móveis deve ser estudada levando-se em conta estas características.

Um erro muito comum dos desenvolvedores de games móveis é criar as mesmas versões para smartphones e tablets. Não são a mesma coisa, embora, com o Samsung �alaxy S III e o iPhone 5, os smartphones estejam crescen-do, ainda s�o bem diferentes de um tablet de 8 ou 10 polegadas. É necessário adaptar a jogabilidade ao tamanho do dispositivo.

A originalidade também tem um papel importante no sucesso de um Game, especialmente se for do tipo “casual”. Games muito parecidos com outros, de maior sucesso, n�o s�o bem vistos e a tendência do público é considerar como uma imitaç�o, mesmo que seja apenas uma coincidência. Quanto mais origi-nal seu game for, mais poderá chamar a atenção deste público.

Neste livro, não vou falar sobre este assunto, mas a forma de “monetiza-ção” também pode ter um impacto positivo ou negativo no Game. Em meu livro anterior “Mobile �ame Jam” (www.mobilegamejam.com), focamos muito nestes aspectos, porém, não podemos deixar de mencionar alguns problemas. Para começar, nem todos os usuários são fãs de jogos “Ads based” e podem se irritar com aquela faixa de tela utilizada para veicular anúncios. Eu tenho games publicados que são deste tipo, e a rentabilidade é muito baixa. Outra forma que deve ser evitada é cobrar licença de uso. Se você já cobra pelo uso sem deixar o usuário experimentar, é receita para o fracasso, a não ser que seu game seja realmente sensacional. O ideal é dar ao jogador uma maneira de experimentar o game antes de comprá-lo. Aí entra o processo de “in-app pur-chase” (compra por dentro da aplicaç�o), e os “bens virtuais”. É uma maneira de fazer o usuário se div ertir e recuperar gradativamente o seu investimento.

Capítulo 3

Kit de ferramentas para

criação de games

Quando eu era garoto, passava aquele seriado antigo do Batman (DC Comics), no qual o Morcego tinha um “cinto de utilidades”, e eu achava aque-le cinto sensacional. Com Games, não é muito diferente, pois necessitamos ter a m�o (e saber usar) algumas ferramentas importantes, que nos poupar�o muito tempo na criação de um Game.

Dependendo do tipo de �ame que você vai fazer, algumas ferramentas se tornam mais importantes e outras, desnecessárias, mas sempre existe um con-junto básico que você deve ter. Vamos mostrar algumas delas aqui.

f

Em �ames, as imagens s�o fundamentais e nós já discutimos isso, agora, é o momento de entrarmos mais um pouco a fundo no assunto, focando nas principais ferramentas para criação de imagens.

Imagens

Vamos começar a estudar imagens em seu formato virtual e, depois, vamos ver como ela é renderizada (apresentada) na tela.

Toda imagem na memória é um conjunto de pontos. Estes pontos s�o ar-mazenados na memória e, posteriormente, s�o exibidos para o usuário. Cada ponto tem as propriedades: coordenadas e cor.

As coordenadas de um ponto indicam onde ele está em nosso “mapa” virtual (Bitmap – n�o confundir com o formato “BMP”). Dependendo do tipo de gráfico que estamos trabalhando, pode ser em um mapa tridimensional ou bidimensional. Como estamos falando de imagens, vamos supor que seja ape-nas bidimensional.

Já a cor, normalmente é expressa em quantidade de vermelho (red), verde (green) e azul (blue), podendo também trazer a quantidade de transparência (Alfa). Vamos ver alguns exemplos simples de representações.

t

As imagens podem trazer informações sobre trasnparência, conhecidas como “Canal Alpha”.

�eralmente, um valor zero no canal alfa de uma imagem significa que ela é totalmente transparente, e um valor 100% significa que é totalmente opaca, mas isto varia de acordo com a ferramenta que utilizamos. Por exemplo, o LibreOffice Draw considera uma imagem com zero no canal alfa como sendo totalmente opaca, e um valor 100% como totalmente transparente.

Ilustraç�o 6: Propriedades dos pontos gráficos no LibreOffice Draw

Como podemos ver na figura anterior (LibreOffice Draw), temos dois “pontos” (é claro que s�o imaginários) com suas características. Note como formamos a cor em formato RGBA – Red, �reen, Blue e Alfa (http://www. w3schools.com/cssref/css_colors_legal.asp). No formato R�B – Red, �reen e Blue (http://www.w3schools.com/cssref/css_colors_legal.asp), temos um indicador da quantidade ou intensidade de cada cor, representado por um valor entre 0 e 255 (1 byte), assim, podemos representar as cores:

• Preto: R�B (0,0,0);

• Branco: R�B (255,255,255); • Cinza: R�B (128,128,128);

• Vermelho: R�B (255,0,0); • Verde: R�B (0,255,0); • Azul: R�B (0,0,255); • Amarelo: R�B (255,255,0);

• Azul ciano (azul bebê): R�B (0,255,255); • Rosa bebê: R�B (250,200,200);

Se quiser ver as combinações de RGB, pode usar um programa como o “LibreOffice Draw” (http://pt-br.libreoffice.org/), ou o �imp (http://www. gimp.org/) e usar a ferramenta de Cores.

Note que o diálogo de cores do LibreOffice Draw também tem uma aba de transparência, que permite ajustar a “opacidade” da cor.

Como vimos na ilustraç�o 6 (Propriedades dos pontos gráficos), além do formato RGB, também temos o canal “Alfa”, que regula a “opacidade” ou “transparência” da cor. Este formato é conhecido como “R�BA”. Existe algu-ma confusão quanto ao fato do canal representar o nível de opacidade ou de transparência. Uma boa referência, o W3Schools (http://www.w3schools.com/ cssref/css_colors_legal.asp), diz que o canal alfa representa o nível de opaci-dade da cor, variando entre 0 (totalmente transparente) e 1 (totalmente opa-co). Já alguns softwares e literaturas tratam essa medida como percentual, variando entre 0% (totalmente transparente e 100% (totalmente opaco) (http:// en.wikipedia.org/wiki/R�BA_color_space). Vamos mostrar alguns exemplos de transparência.

Temos que prestar atenção na forma como as ferramentas se referem ao canal “alfa”. O LibreOffice Draw encara como “transparência”, logo, 0% sig-nifica “opaco” e 100% sigsig-nifica “transparente”. Já, para o �imp, uma camada 0% significa totalmente transparente, e 100% significa totalmente opaco.

Na imagem anterior, usamos o LibreOffice Draw para desenhar. Os qua-drados, que possuem cor de fundo preta, estão com o canal alfa variando de 0 até 1, ou, na “linguagem” do LibreOffice, variando de 100% até 0% de transparência.

Toda imagem é armazenada da mesma maneira. Porém, há alguns detalhes sobre imagens que precisamos conhecer.

Unidades de medida

Quando falamos em imagens, é muito comum ouvirmos “pontos” e “pi-xels”, conceitos que muitas vezes nos confundem. Um “ponto” (point) é uma medida de tipografia e equivale a 1/72 de polegada. Um “pixel” é uma unidade gráfica de um dispositivo. É a menor unidade utilizável de um dispositivo grá-fico, como uma tela de LCD. Temos que deixar claro que estamos estudando gráficos exibidos em telas, e n�o impressos, pois, caso contrário tudo mudaria.

Resolução e densidade

Há muita confusão sobre estas duas métricas. O senso comum diz que

re-solução é a quantidade de pixels, tanto na horizontal quanto na vertical, que

um dispositivo pode exibir. Também serve para determinar o “tamanho” de uma imagem. Por exemplo, uma imagem de 5 Megapixels tem 5 milhões de pixels, o que n�o está relacionado ao tamanho físico. Uma tela WX�A, com 1280 x 800 pixels, tem 1,024 Megapixels.

Já o tamanho que uma imagem ou tela terão depende muito da densidade, que é a quantidade de pixels por polegada (PPI) que a tela pode exibir (ou que a imagem espera ser reproduzida). Isto determina qual tamanho a imagem terá na tela real. Cada dispositivo tem sua densidade específica, por exemplo (fonte: gsmarena.com) :

• Samsung �alaxy S III: 306 PPI; • Apple iPhone 5: 326 PPI; • Apple iPad 4: 264 PPI; • Apple iPad 2: 132 PPI;

• Motorola Xoom 2 Media Edition: 184 PPI.

Profundidade de cor

A profundidade de cor (Color depth) é o número de bits necessários para representar cada cor de um pixel. Temos dois grandes sistemas para repre-sentar a cor: indexado e direto. O sistema indexado é utilizado quando temos

baixa profundidade de cor, ou seja, temos poucos bits para representar cada cor. Ent�o, é criada uma “palheta” (tabela) com as cores utilizadas e o código é, na verdade, o índice nesta tabela. Sistemas com 8 ou 12 bits por cor geral-mente utilizam “palhetas” de cor. O sistema direto é quanto não usamos pa-lheta, mas representamos diretamente o valor de cada cor. Podemos ter várias profundidades neste sistema, como 8 bits, 16 bits ou “true color”, que s�o 24 bits de cor (8 para cada cor – R�B). Com este sistema, podemos representar mais de 16 milhões de cores. É claro que o sistema direto requer mais memó-ria (RAM ou arquivo) para representar as imagens, porém, fica mais fiel.

Hoje em dia, o sistema indexado é utilizado para armazenamento de ima-gem, de modo a economizar espaço. Entre os tipos de arquivo que usam pa-lheta temos: BMP, �IF e PN�.

Arquivos de imagem

Existem vários padrões para armazenamento de imagem, cada um é me-lhor para determinada aplicação. Temos formatos que usam palheta, formatos que usam Color deph e formatos que podem utilizar os dois sistemas. Também podemos armazenar uma imagem de maneiras diferentes, como: “Raster” e “Vetorial”.

Imagens em formato “Raster” são as mais comuns. São mais simples em termos de processamento, pois basicamente armazenam os pontos e suas cores. Só isso. É necessário apenas decodificar (ou descomprimir, caso necessário) o arquivo e acionar os pontos na tela com a cor necessária. Porém, o formato “Raster” tem a desvantagem de ser grande. É claro que podemos comprimir a imagem, perdendo ou não informação, mas, ainda assim, o arquivo é grande.

Existem formatos de arquivo “Raster” que comprimem a imagem, com perda ou sem perda de informação. O JPEG, por exemplo, utiliza compressão com perda, que pode ser regulada através da qualidade do arquivo. Arquivos como PNG comprimem sem perda de informações, porém geram arquivos maiores.

Já as imagens em formato vetorial não representam a imagem na forma de pixels, mas como vetores. Elas contêm as instruções para desenhar a imagem, permitindo mais suavidade na renderização. Os arquivos em formato vetorial são menores do que os em formato raster, porém, sua renderização exige mais recursos de processamento e pode gerar distorções quando utilizamos dispo-sitivos diferentes.

Os principais formatos de arquivos de imagem s�o:

Formatos “Raster”:

• GIF: usa compress�o sem perda e pode representar imagens com

palheta de 256 cores. Suporta animaç�o e é mais indicado para ima-gens com grandes áreas de uma só cor, como: gráficos comerciais, desenhos simples etc;

• BMP: é o formato nativo do Microsoft Windows. N�o usa

compres-s�o e pode representar “true color” (24 bits). Os arquivos BMP compres-s�o grandes, em comparação com outros formatos;

• PNG: suporta “true color” com canal alfa (transparência). É mais

indicado para imagens com grandes áreas de cor única. Também suporta imagens em sistema direto, sem palheta;

• JPEG: comprime imagens de maneira extraordinária, podendo

re-duzir absurdamente o tamanho do arquivo. Porém, usa compressão com perda de informação. Uma vez salvo, não é possível restaurar a imagem original. É mais indicado para arquivos de fotografias;

Formatos vetoriais:

• SVG: “Scalable Vector �raphics”, um formato padr�o, criado pelo

W3C, e utilizado no HTML 5;

• CGM (Computer �raphics Metafile), CDR (Corel Draw), WMF

(Windows Metafile Format);

Ferramenta para “Sketch”

É muito importante criar “Sketches” ou rascunhos das imagens de seus �ames. Nada impede que você use papel e lápis para isto, mas um “Ske-tch” digital tem a vantagem de poder ser utilizado diretamente. Eu me lembro quando criava �ames para Windows e desenhava a imagem em papel para depois passar por um “Scanner”.

O ideal é ter algum dispositivo para digitalização de desenho livre, como uma mesa digitalizadora, que é um “tablet” (n�o confundir com Tablet Mo-bile), que tem uma caneta especial e permite capturar seu desenho manual. Outra opção é usar algum aplicativo de desenho em um Tablet mobile, como o iPad (ou algum dispositivo Android).

Eu costumo usar o “Sketchbook Pro for iPad”, da AutoDesk. É um progra-ma barato e muito fácil de usar e que me permite criar iprogra-magens rapidamente, como a da figura a seguir.

Ilustraç�o 8: Rascunho de personagem de �ame

Utilizando uma caneta para iPad, consigo desenhar rapidamente e até colorir a imagem, sem grande sacrifício, pois posso apagar partes e corrigir rapidamente.

Ferramentas para desenho Raster

Na minha opinião, a melhor ferramenta para edição de imagens raster é o

PhotoShop, da Adobe. Não há dúvida alguma sobre isso. Porém, ele tem um

custo de licença relativamente alto, com relação a outras alternativas. Na mi-nha opini�o, se você tiver condiç�o, compre logo a licença da Adobe Creative

Suite 6, que já vem com tudo o que você pode necessitar para criar gráficos.

Porém, se você é um “Indie �amer”, provavelmente n�o estará t�o moti-vado assim para investir uma alta soma, especialmente se estiver começando. Mas lembre-se: o investimento se pagará com a qualidade e facilidade de uso dos produtos da Adobe.

A opção mais popular de editores “raster” gratuitos é o Gimp (http://www. gimp.org/) - �NU Image Manipulation Program. É um editor poderoso, com interface simples, porém dotado de muitos efeitos interessantes. Há versões para MS Windows, Mac OS X e Linux. Entre outras coisas, o �imp permite:

• Trabalhar com transparências;

• Trabalhar com vários formatos diferentes de imagem, inclusive SVG;

• Criar imagens com múltiplas camadas, que podem ser superpostas; • Criar animações em GIF;

• Selecionar partes da imagem de várias formas: retangular, elíptica, livre, por cor etc;

• Usar várias ferramentas nativas de transformação, cor e pintura; • Usar vários filtros de efeitos, como: entalhar, esculpir, realçar,

pin-tura a óleo, clarões etc;

Ilustraç�o 9: Exemplo de uso de filtro de clarões do �imp

Uma opç�o profissional de custo relativamente mais baixo é o Corel Painter (http://www.corel.com/corel/product/index.jsp?pid=prod4030123&cid=catalog3590 073&segid=2100019&storeKey=br&languageCode=pt). Ele permite baixar uma vers�o de avaliaç�o (30 dias) que dá uma boa ideia dos seus recursos, porém só está disponível para MS Windows e Apple Mac OS X. É melhor do que o Gimp em alguns aspectos, como os recursos de pintura digital.

Ferramentas para desenho vetorial

Você pode trabalhar com imagens vetoriais em seu game. Em meu livro an-terior “Mobile �ame Jam” (www.mobilegamejam.com) nós utilizamos imagens vetoriais, sendo desenhadas em um Canvas. Porém, isto pode demandar re-cursos de processador, caso seu game seja muito complexo. Outra maneira de trabalhar com imagens vetoriais é criá-las em um editor de imagens vetoriais e, posteriormente, converter os arquivos em algum formato raster. O Gimp faz isto com perfeição.

Comparação entre renderização raster e vetorial

A renderização raster é muito rápida e o trabalho pode ser dividido com a �PU (�raphics Processing Unit), evitando “lags” no game. Porém, é mais su-jeita às diferenças de densidade e resolução entre os equipamentos, exigindo versões diferentes ou então operações de “resizing”, que podem resultar em arquivos serrilhados (pixelados, uma consequência do processo de reduç�o / ampliaç�o).

Já a renderização vetorial é uma operação de desenho completa e, geral-mente, é executada na CPU. Existem alguns artigos interessantes sobre téc-nicas para utilizara a GPU na renderização de desenhos vetoriais, entre eles este, da NVidia: http://http.developer.nvidia.com/�PU�ems3/gpugems3_ch25. html, porém, não é a forma comum de se trabalhar. A vantagem da renderi-zação vetorial é a suavidade do desenho, que pode ter sua escala facilmente aumentada ou diminuída. Além disto, os arquivos vetoriais são menores e não é necessária mais de uma versão de cada imagem.

De qualquer forma, eu sempre crio a imagem dos meus games em formato raster (usando o “Sketchbook pro”) e depois converto para formato vetorial. No final, eu converto as imagens vetoriais finalizadas em formato raster, com um arquivo para cada tamanho (resoluç�o / densidade) de dispositivo.

Ilustraç�o 10: Um ensaio de personagem

Na figura anterior, vemos dois ensaios de uma personagem de game que eu estou criando. O da esquerda (raster) foi criado rapidamente no “Sketchbook pro”. Note como ainda mantive as linhas de construção que usei. A imagem da direita é feita em formato vetorial (no aplicativo “iDesign”, para iPad). Eu tenho a tendência de criar personagens em estilo “mangá”, porém, resolvi dar

uma “ocidentalizada” no rosto (arredondando e diminuindo a inclinaç�o dos olhos). Mas ficou do jeito que eu queria: uma personagem meio rebelde e misteriosa.

Eu n�o vou trabalhar com a imagem vetorial, mas vou utilizá-la para criar imagens raster. O desenho vetorial me ajuda a criar imagens mais perfeitas, já que eu não tenho muito talento para desenho manual.

A ferramenta que eu gosto de usar para criar desenhos vetoriais é o “iDesign” para iPad, da Touchware (https://itunes.apple.com/us/app/idesign/ id342790226?mt=8). Ele é barato (cerca de US$ 5,00), possui os recursos bá-sicos de ediç�o vetorial, como: curvas de Bèzier, auto fechamento, pintura, rotação, combinação com imagens de fundo e até gradientes.

Outra boa ferramenta, na minha opinião é o Fireworks, da Adobe (http:// www.adobe.com/br/products/fireworks.html), uma ferramenta voltada para web designers, que permite trabalhar imagens vetoriais e raster também. Em-bora seu uso seja mais voltado para criaç�o de Web designs (sua integraç�o com CSS é fantástica), também permite gerar temas para JQuery Mobile e tra-balhar imagens vetoriais. Seu preço é um pouco alto, assim como toda a suite da Adobe, mas acredite: o investimento se pagará em produtividade!

É claro que n�o podemos sequer falar em gráficos vetoriais sem mencionar o Corel Draw (http://www.corel.com/corel/product/index. jsp?pid=prod4260069), cujo preço da licença é mais competitivo e os recur-sos são fantásticos.

Como eu mencionei anteriormente, eu uso o iDesign, da TouchWare (), na versão iPad. Embora tenha menos recursos que os produtos mencionados, tem baixo custo e funciona muito bem no iPad. Sua licença custa cerca de US$ 5,00, e vem com um tutorial muito fácil de entender.

Agora, se você quer uma opç�o gratuita, eu recomendaria o Inkscape (www.inkscape.org), que é Open Source e gratuito. Ele possui versões para MS Windows, Apple Mac OSX e Linux. É muito fácil de usar e permite gerar a maioria das imagens que você necessita. Suas características importantes s�o:

• Trabalha com camadas de desenhos;

• Gera arquivos raster a partir dos desenhos vetoriais;

• Consegue importar vários formatos de imagem, tanto vetoriais como raster;

Ilustraç�o 11: O ensaio de personagem no Inkscape

O Inkscape pode ser gratuito, mas é cheio de surpresas. Assim como o �imp, ele também tem filtros sensacionais, que permitem dar um efeito pro-fissional em seus trabalhos. Para dar um exemplo, eu transformei a imagem da minha personagem em um “android”, com efeito “Glowing Metal”.

g

Um Game engine é uma ferramenta para facilitar o desenvolvimento de ga-mes. Eles são compostos por editores, bibliotecas e interface de programação, que podemos utilizar para criar nossos próprios games. Existem game engines para várias plataformas, seja 2D ou 3D, com níveis diferentes de facilidade de uso.

Adotar um Game engine pode aumentar sua produtividade, permitindo que você se concentre mais no �ame design (incluindo a jogabilidade), ao invés de se preocupar com detalhes de animação, game loop etc.

HTML 5 + Javascript

Existem vários �ame engines para HTML 5 + Javascript. Já que a Adobe discontinuou o desenvolvimento do Flash player para dispositivos móveis, a galera que fazia jogos em Flash está migrando para HTML 5 e Javascript.

Em meu último livro, “Mobile Game Jam”, eu mostrei como desenvolver games móveis usando HTML 5 e Javascript, e mostrei um engine multiplata-forma: o Phone�ap (Cordova). Mas n�o mostrei nenhum �ame engine desta plataforma.

O ImpactJS (impactjs.com) é uma boa opç�o. Ele permite criar games em HTML 5 + Javascript para Desktops e dispositivos móveis. Vem com um editor de níveis (o Weltmeister), que facilita muito a criaç�o de cenários para diferentes níveis do jogo. Ele vem com ferramentas de depuração e empacota-dores, que permitem colocar sua aplicação diretamente na AppStore iOS. Seu custo é relativamente barato (US$ 99,00).

Existem vários outros game engines para HTML 5 + Javascript, porém o ImpactJS, na minha opini�o, é o mais profissional.

Nativos

Um Game engine nativo é aquele que possui bibliotecas nativas e executa fora do ambiente do Browser. Geralmente, apresentam melhor performance do que os �ame engines baseados em HTML 5 + Javascript.

O Cocos2D for iPhone (http://www.cocos2d-iphone.org/) é um port do Game engine original “Cocos2D”, para Python. É bastante popular, com vá-rios games famosos no mercado. Ele vem com um ambiente de desenvolvi-mento (CocosBuilder), a biblioteca do �ame engine em si (cocos2D), e um engine de física (Chipmunk). Existem versões para HTML 5 (http://cocos2d-x.

googlecode.com/files/Cocos2d-html5-v2.1.zip) e Android (http://code.google. com/p/cocos2d-android/). É gratuito.

O AndEngine (http://www.andengine.org/blog/) é um game engine para Android, similar ao Cocos2D. Também é gratuito e open source.

Para quem quer um engine mais profissional, tem o Antiryad Gx (http:// www.arkham-development.com/antiryadgx.htm), que permite criar games 2D ou 3D para várias plataformas, entre elas: iOS e Android. Ele possui vários tipos de licenças, desde gratuita até “enterprise” (900 euros).

Porém, se você quiser realmente “detonar” com um �ame 3D animal, use o UDK – Unreal Development Kit (www.udk.com) para iOS, Android, PS3, Xbox, Windows, Mac OSX etc. Com o UDK, você pode desenvolver seu game sem custo e, quando estiver pronto para publicar, pagará uma taxa de US$ 99,00 (única). Porém, há mais cobranças se você alcançar US$ 50.000,00 em vendas.

Finalmente, temos o Unity (http://unity3d.com/), que é um engine para ga-mes 3D muito interessante. A versão básica é gratuita e permite criar gaga-mes para MS Windows e Apple Mac OSX, e você pode criar games comerciais com ela. Se quiser criar games para dispositivos móveis, você deve adquirir os “add-ons” específicos, como: Unit iOS (US$ 400,00) e Unit Android (US$ 400,00). Também existem as licenças “pro” para estes ambientes. O Unity é sensacional e vem com um editor fantástico.

Ilustraç�o 13: Jogo que estou criando com o Unity

Se você vai criar um game 3D, é melhor considerar uma ferramenta de de-senho apropriada. Eu recomendo o AutoDesk Maya (http://usa.autodesk.com/ maya/), apropriado para criaç�o de personagens 3D com animaç�o. Agora, se

preferir um software gratuito, o Blender (http://www.blender.org/) é uma ex-celente opção. E os modelos 3D criados com o Blender podem ser importados em game engines 3D, como o Unity.

Usar a plataforma nativa

Embora um Game Engine possa acelerar o desenvolvimento do seu game, ele também tem algumas desvantagens, entre elas:

• Ficar “preso” aos recursos disponíveis no Engine; • Complexidade de aprender a API;

• Preço da licença;

• Dependência de suporte (ou comunidade) para Bugs;

Além destas possíveis desvantagens, é necessário considerar que as APIs das plataformas nativas, tanto do Android, como do iOS, permitem criar ga-mes com recursos avançados, como o OpenGL ES, por exemplo.

Mesmo que você queira utilizar um �ame Engine, eu considero funda-mental que você saiba o que está acontecendo e, para isto, nada melhor do que criar um game “na mão”, sem engine algum. Depois, se considerar rele-vante para o seu projeto, poderá escolher um Game Engine apropriado, porém saberá avaliar e usar melhor as funcionalidades, pois já sabe os detalhes de programação de games.

a

Fora os Game engines, existem alguns ambientes multiplataforma para criaç�o de aplicações móveis, alguns deles com recursos para �ames. Para começar, vou vender o meu “peixe”. No nosso portal The Code Bakers (www. thecodebakers.org), criamos um framework de aplicações móveis multiplata-forma, o AAMO (www.aamoframework.org). Ele é baseado em Lua e pode ge-rar aplicações em iOS e Android. Futuramente, haverá versões para Desktop e também um game engine embutido: o AAMO Xtreme. O AAMO é totalmente gratuito e Open Source, mas ainda não contempla os recursos para criação de Games.

Outro ambiente multiplataforma interessante é o CoronaSDK (http://www. coronalabs.com/products/corona-sdk/). Ele também é baseado na linguagem Lua e possui recursos muito interessantes para criação de games. Ele foi escolhido pela EA (famosa por vários games) para criar seu jogo móvel: World Smack ( http://www.coronalabs.com/blog/2012/11/08/corona-spotlight-ea-chooses-corona--for-word-smack/). O corona n�o é gratuito, mas tem licença de baixo custo, só necessária quando você for publicar o game.

p

Um grande recurso, geralmente ignorado pelos desenvolvedores de game, é a prototipação. Este recurso nos permite capturar, de maneira simples e cla-ra, os requisitos de uma aplicação. Como games possuem requisitos muito subjetivos (jogabilidade é um deles), a prototipaç�o pode ser um excelente instrumento para acelerar o desenvolvimento, evitando retrabalho.

Seja utilizando um Game engine ou não, o comprometimento do projeto de um game cresce rápida e exponencialmente. Em poucas semanas, já temos tanto código escrito que criamos um forte comprometimento com ele, deixan-do de ver coisas óbvias. Com um protótipo isto é evitadeixan-do, pois podemos jogar tudo fora e começar novamente.

Felizmente, existem alguns softwares excelentes para prototipação de ga-mes e aplicações em geral. Eu uso dois deles, que considero excelentes.

Para começar, gostaria de falar do Codea (http://twolivesleft.com/Codea/), uma ferramenta que roda diretamente (e apenas) no iPad. Com ela, podemos programar diretamente no iPad, sem necessidade de um laptop ou desktop. Infelizmente, só existe vers�o para iPad. Podemos até baixar o Codea Runti-me (https://github.com/TwoLivesLeft/Codea-RuntiRunti-me) e distribuir a aplica-ç�o na AppStore. A licença do Codea custa US$ 9,99 e acredite: ela se paga rapidamente!

Vou mostrar o protótipo de um game que foi feito originalmente no Codea em menos de 4 horas! Eu aprendi a usar o Codea, aprendi a linguagem Lua e criei o Game enquanto estava hospitalizado, aguardando uma cirurgia renal. Quando fui para a sala de cirurgia, o Game estava pronto. É claro que era um protótipo, mas estava funcionando completamente.

Eu sou f� do Codea, porém, fiquei completamente atônito e pasmo quando conheci a oitava maravilha do mundo: O Processing (http://processing.org/)! É aquele tipo de coisa bombástica que nos faz gritar: “Para tudo!” O Processing é um ambiente de simulação e prototipação, que já vem com tudo em cima para criar Games. Ele usa uma linguagem “tipo” java, mas também permite exportar seu projeto para HTML 5 + Javascript e até mesmo Android, ou seja: lava, passa, cozinha e, ainda por cima: é gratuito!

b

Como já discutimos, um Game é um projeto muito complexo, com várias macrofunções diferentes. Certamente, podemos utilizar Game engines para nos auxiliar, porém, ainda existem alguns motivos importantes para estudar-mos as bibliotecas em separado:

1. Custo. Se criarmos diretamente o game, não necessitaremos adquirir licenças e, como já discuti, alguns Game engines possuem requisitos de licença meio complexos;

2. Domínio. Se você souber o que está “por baixo do capô”, vai saber tirar maior proveito dos componentes para seu Game;

Uma ferramenta importante é um engine gráfico que permita utilizar os re-cursos de aceleraç�o de sua placa de vídeo (�PU – �raphics Processing Unit) e esta ferramenta é a biblioteca OpenGL ES (http://www.khronos.org/opengles/), que é uma versão da OpenGL (http://www.opengl.org/) para dispositivos mó-veis. A principal vantagem é renderizar imagens mais rapidamente, utilizando multiprocessamento compartilhado entre CPU e �PU, tanto para gráficos 2D como para 3D. Tanto no iOS como no Android, existem recursos para facilitar o uso do OpenGL ES na criação de games.

E, finalmente, temos a biblioteca Box2D (http://box2d.org/), que é um “phy-sics engine”, ou seja, uma biblioteca que fornece funções físicas, como: movi-mento, forças e colisões para nossos games parecerem mais realistas. Para ter uma ideia de quanto a Box2D é importante, o game “Angry birds” a usa como seu “physics engine”.

Capítulo 4

Prototipação do game

Bem, vamos começar realmente o nosso game. Imaginemos uma ideia simples e vamos tentar criar um protótipo com ela, de modo a avaliar se está boa para virar um Game.

Tudo começa com uma ideia. Que tal criarmos um “shooting” game? Afi-nal de contas, “shooting” games são fáceis de criar e, geralmente agradam a todos. Podemos começar com um rascunho (“Sketch”) do game. Eu pensei em um game de escapar de asteroides. Você está em uma nave e tem que manobrar em um campo de asteroides, evitando colidir com eles. Você ganha pontos de acordo com a distância percorrida, em anos-luz.

Uma dica: se você começar a complicar, pensando coisas do tipo: “já tem muita coisa assim, preciso criar algo diferente...” seu projeto não vai andar. Você vai criar um protótipo do jogo, logo, n�o é o momento de pensar nisso. Depois, você pode fazer as otimizações que desejar.

Um rascunho é tudo o que precisamos

Eu peguei meu iPad e, usando o “Sketchbook”, criei vários desenhos. Eu fui desenhando o que me vinha à mente, sem me preocupar muito com estética ou funcionalidade. O desenho que mais gostei foi o da próxima figura.

A nave se move para cima e para baixo, e os asteroides vêm em sua di-reç�o, pois ela está se movendo para a frente. Existem asteroides “bons” (os brilhantes), que repõem a energia da nave, e os asteroides ruins (opacos), que podem destruir a nave. Caso ela colida com um asteroide ruim, sua energia é drenada, pois ela usa os “escudos” para impedir sua colisão.

Ilustraç�o 14: Rascunho do jogo

Se o seu jogo tiver mais telas ou níveis, você pode ir criando rascunhos para cada um deles. O importante é colocar a idea no papel (digital), antes que você se esqueça.

u

c

O Codea é um ambiente de programação sensacional. É simples e prático, permitindo criar rapidamente jogos e simulações gráficas. Ele é uma aplicaç�o para iPad, que está disponível na AppStore por cerca de US$ 10,00.

Os pontos positivos do Codea s�o:

1. Tem recursos que facilitam o desenvolvimento rápido de games; 2. Já vem integrado com o engine de física Box2D;

3. Usa a linguagem Lua (www.lua.org), que é simples e pouco verbosa; 4. Vem com Spritepacks (conjuntos de imagens) e outros recursos para

criação de games.

Porém, o Codea carece desesperadamente de documentação decente. Não parece um produto comercial e, certamente, não tem o suporte necessário, em caso de problemas. O site da empresa, “Twolivesleft.com”, é muito minima-lista e n�o tem uma documentaç�o formal. Existem vários tutoriais (alguns criados por terceiros) que explicam rapidamente como ele funciona.

É claro que podemos criar Games com o Codea e distribuir na AppStore, pois ele tem um “Codea Runtime” (https://github.com/TwoLivesLeft/Codea--Runtime) que permite fazer isto. Porém, quando se trata de criar um produ-to comercial, eu sou muiprodu-to conservador, pois, em caso de problemas, o meu cliente vai reclamar comigo e eu, como desenvolvedor do Game, não terei a quem recorrer. É por isso que eu não uso o Codea para desenvolvimento, mas apenas para prototipação.

No Codea, podemos criar código-fonte para responder a eventos e para criar classes, que ser�o utilizadas no �ame. A linguagem é a Lua (www.lua. org), criada pela PUC-RJ. Lua é uma linguagem simples, intuitiva e pouco verbosa, cujo aprendizado é extremamente simples. Nós iremos ensinando Lua conforme o protótipo for se desenvolvendo. Aliás, foi assim que eu apren-di a usar Lua. Só para começar, Lua é “canse sensitive” e n�o precisa de ponto e vírgula no final da linha. Os comentários s�o iniciados por “--”.

Um tutorial rápido em Codea

Vamos fazer uma “porcaria” em Codea para você “pegar o jeito”. Comece iniciando um novo projeto, na tela do Codea (Ahn, galera: só funciona no iPad, ok? Se você n�o tem um iPad, leia a prototipaç�o no “Processing”). Escreva um nome qualquer para o projeto, por exemplo: “bola”. Ele vai criar todo o código do projeto, que apenas escreve “Hello world” na saída.