Mobile Entertainment magazine #36 disponível

A edição #36 da Mobile Entertainment já está disponível para download no site da Mobile Entertainment.

 

Mais uma dica de programação (Java ME)

Outro post para os programadores. Dessa vez, venho descrever um probleminha que encontrei no porting de um jogo infantil de PC (feito em Director) para mobile (Java ME) e como solucionei o mesmo. O porting foi de um simples jogo de corrida, com um personagem controlado pelo jogador e outro pelo computador, sem nenhuma Inteligência Artificial avançada (nem intermediária, podemos dizer). Segue uma imagem do jogo:

O problema era referente a colisão do carro com as bordas das pistas, que são irregulares, e também com o oponente. Usar bounding boxes não produzia resultados satisfatórios, como vocês já devem ter percebido. E como os carros possuem 12 direções diferentes, usar AABB (axis-aligned bounding box) para eles também não era a solução. Então, tomei a seguinte decisão: os carros usariam OBB (oriented bounding box) e a colisão das bordas das pistas seriam definidas através de segmentos de reta.

Para os carros, como as direções/ângulos deles já estavam pré-definidas, não precisei recalcular de tempos em tempos o OBB de cada um, o que facilitou tanto na questão de código como de performance. Pré-defini um array de coordenadas (x,y) para cada direção do carro, que seriam adicionadas à posição (x,y) atual de cada carro. Para a pista, também usei valores pré-definidos, isto é, um array contendo as coordenadas (x,y) de todos os pontos que formam os segmentos de reta. A imagem abaixo mostra o jogo com meu ‘debug info’ ativado:

E uma screenshot sem imagem alguma do jogo, somente com informações de colisão, posição dos carros e caminho para o carro controlado pelo computador seguir. Note que não preciso ter as imagens do jogo para que o o mesmo seja jogável (embora precisei das imagens para definir as retas de colisão e caminho).

O que significa esse monte de linhas? Vamos lá… As retas e pontos em vermelho indicam o caminho que o carro controlado pelo computador deve seguir. IA super-ultra-mega-avançada! Tão avançado que o computador nem desvia do jogador (o jogo original era assim). Nada mais é que um path following…

As retas em amarelo são as retas de colisão para que o jogador não saia da pista. Na verdade eu uso o (x,y) de cada ponto para construir a reta e calcular a colisão. Em verde estão indicados os OBB dos carros. Opa! Mas há duas retas em verde que se cruzam. Fazem parte dos OBB dos carros? Não, essas retas indicam os setores da pista.

Eu dividi a pista em setores para diminuir a quantidade de checagem de colisão a cada quadro. Caso contrário, o processador precisaria calcular muita, mas muita colisão, deixando a performance do jogo lá na pqp. Verifico colisão apenas com os segmentos de reta de cada setor onde o jogador se encontra e, caso o oponente esteja em outro setor, não verifico colisão com ele.

Minha explicação foi clara? Para fechar o post, deixo o código que escrevi para a checagem de colisão entre os segmentos de reta, que foi o ‘core’ da implementação. O comentário está em inglês (já que trabalho com noruegueses) mas creio que dê para entender:

// int _11x means line 1, point 1, x
// int _11y means line 1, point 1, y and so on...
public boolean checkCollision(int _11x, int _11y, int _12x, int _12y, int _21x, int _21y, int _22x, int _22y) {
// equation of line 1 -> (_11y - _12y) * x - (_11x - _12x) * y = -(_11x * _12y) + (_12x * _11y);
// equation of line 2 -> (_21y - _22y) * x - (_21x - _22x) * y = -(_21x * _22y) + (_22x * _21y);

// We have two lines, AB and CD
// r1 = you should use point A into CD equation
// r2 = you should use point B into CD equation
// If the sign of r1 and r2 are different, then AB cross CD
// Then you should do the same for points C and D into AB equation
int line1R1 = (_11y - _12y) * _21x - (_11x - _12x) * _21y + (_11x * _12y) - (_12x * _11y);
int line1R2 = (_11y - _12y) * _22x - (_11x - _12x) * _22y + (_11x * _12y) - (_12x * _11y);
int line2R1 = (_21y - _22y) * _11x - (_21x - _22x) * _11y + (_21x * _22y) - (_22x * _21y);
int line2R2 = (_21y - _22y) * _12x - (_21x - _22x) * _12y + (_21x * _22y) - (_22x * _21y);

return( ((line1R1 >= 0) != (line1R2 >= 0)) && ((line2R1 >= 0) != (line2R2 >= 0)) );
}

 

Mini post-mortem: Chevrolet Prisma Test Life (mobile)

Esse texto apresenta uma pequena análise pós-lançamento (post-mortem) do jogo mobile “Chevrolet Prisma Test Life”, na qual participei como programador principal. Quero deixar claro que as opiniões expressas abaixo são de minha autoria e pessoais, isto é, não refletem necessariamente a opinião da empresa que desenvolveu o jogo nem do cliente que contratou a empresa.

“A campanha “Fases da Vida” para o Chevrolet Prisma foi baseada no tema Games, como continuação da campanha “Seu Primeiro Grande Carro”. O jogo para celular apresenta três fases, cada qual com objetivos como vencer o trânsito, encontrar a casa de praia ou dar carona para os amigos. É uma continuação do jogo em Flash existente na internet.”
(Informação retirada do site da Microways)

Título: Chevrolet Prisma Test Life
Tempo de desenvolvimento: 19 dias corridos (incluindo fins-de-semana)
Lançamento (entrega da versão final para o cliente): 04/jun/2007
Equipe: 2 desenvolvedores full-time (1 artista/designer e 1 programador), 2 desenvolvedores nos dias finais do projeto (1 artista e 1 programador) e 1 músico (conversão da trilha para MIDI)
Linhas de código: 8.051 (incluindo linhas em branco e comentários, divididos em 18 classes)
Imagens finais: 71 arquivos e 52 arquivos (versão Nokia S40 1st Edition – limite de 64kb)
Áudio: 1 trilha (MIDI) e 3 efeitos (WAV e AMR)
Ferramentas utilizadas: NetBeans 5.5 + Mobility Pack 5.5, Sun Java(TM) Wireless Toolkit 2.5 for CLDC, Adobe Photoshop, Blender, Audacity

O advergame Prisma Test Life mobile foi desenvolvido para o cliente McCann Erickson, integrando a campanha “Fases da Vida” para o (carro) Chevrolet Prisma. A campanha contou com um jogo em Flash (link) onde o jogador precisa realizar algumas tarefas para então pegar seu “primeiro grande carro” – o Prisma – e ir para a praia. Ao término do jogo Flash, o mesmo indica um link para download do jogo para celular. A versão mobile começa onde a versão Flash termina: o jogador precisa pegar a estrada e ir até a casa de praia, além de dar carona para os amigos. Nota: a Microways desenvolveu apenas o jogo mobile.

O conceito do jogo foi criado pelo JP Nogueira e, uma vez aprovado pelo cliente, começou a batalha contra o relógio :). Contamos 19 dias de desenvolvimento, mas os dois primeiros dias foram para o game design e aprovação do cliente (ou seja, comecei a programar o jogo mesmo a partir do terceiro dia). O desenvolvimento ocorreu sem grandes problemas, apesar do pouco tempo disponível. Baseado no esquema “What Went Right/What Went Wrong” da Game Developer Magazine, segue minha análise do jogo:

O que deu certo

1 – Cooperação do cliente

Quando você desenvolve um produto para um cliente, é imprescindível que ambos os lados trabalhem em conjunto e cooperem para que o produto seja criado da melhor forma possível. Neste caso, sempre que precisávamos de algum material para referência o cliente nos enviava sem problemas. Parte das imagens do jogo mobile são imagens editadas do material que recebemos (redimensionamento e adaptação à mídia) e o carro Prisma foi criado a partir de renders de um modelo 3D.

2 – Modelo 3D do carro

Uma vez que o foco do jogo era o carro Prisma, nada melhor que ter um modelo 3D do mesmo. O cliente nos enviou um OBJ e a partir dele geramos as imagens do carro nos ângulos que precisávamos. Renderizei tais ângulos com o Blender e passei as imagens para o artista redimensionar e ajustar pequenos detalhes.

3 – Framework Java ME

Obviamente não programamos todos os jogos do zero. O uso de um framework no projeto salvou bastante tempo com tarefas que são comuns em todos os jogos, pois as mesmas já estavam prontas, requerendo apenas algumas adaptações do código-base. Tais tarefas envolvem o gerenciamento de telas, navegação do menu, escrever/ler highscore, Canvas commands, etc.

4 – Equipe adicional no fim do projeto

Embora não seja recomendado adicionar pessoas no meio ou no fim de um projeto, isso deu certo para esse jogo. Na arte, o artista principal passou todas as imagens pré-finalizadas para outra artista analisar e melhorar toda e qualquer modificação que achasse necessária. As mudanças envolveram melhorias nos gráficos dos carros, num trabalho de poucas horas. No código, uma programadora entrou nos últimos dias do projeto para ajudar em detalhes como inserção de áudio e animação da tela de abertura, enquanto eu trabalhava na jogabilidade e correção de bugs. Numa hora crítica (algo do tipo “é agora ou nunca”), a programadora adicional ajudou a melhorar a movimentação do carro na segunda fase, que estava um pouco brusca e incomodava a todos.

5 – Instruções antes de cada fase

Quando incluímos uma opção “Instruções” no menu principal do jogo, quase ninguém o acessa e fica com dificuldade em entender os controles e o que deve fazer no jogo. Percebemos que as pessoas que testavam o jogo sempre liam as instruções quando as mesmas apareciam automaticamente antes de começar cada fase.

O que deu errado

1 – Áudio em certos aparelhos

Algo que me incomodou (e que me incomoda sempre) é quanto ao áudio em alguns aparelhos. Sem áudio algum ou somente trilha MIDI, o jogo roda normal. Mas quando a opção de efeitos sonoros é ativada, alguns aparelhos não possuem um bom processador e toda vez que um efeito é executado o jogo tem uma pequena pausa que pra mim quebra a interação. Em particular, a versão para Motorola sofreu nessa parte, inclusive executando efeitos erroneamente.

2 – Prazo de entrega e game design

Incompatíveis. As idéias que tivemos para o conceito do jogo um pouco antes do cliente aprovar o projeto tiveram que ser cortadas ou simplificadas para que o jogo pudesse ser entregue dentro do prazo e ainda assim manter a essência que visávamos. Indico como algo que deu errado (na verdade, algo que não deu muito certo) pois com um prazo maior o jogo poderia ficar mais interessante, com features novas e/ou diferentes.

3 – Divulgação do jogo

Jogo finalizado e entregue pro cliente… Como os jogadores/público-alvo do jogo tomaram conhecimento do mesmo??? Você fez o download gratuito do jogo e o instalou no seu celular? Pois é, quase provável que sua resposta tenha sido “não”, já que o link para download do jogo só foi divulgado na tela final do jogo em Flash. Ou seja, apenas quem sabia do jogo em Flash e jogou até o fim tomou conhecimento do jogo para celular. Fora isso, não fiquei sabendo de nenhum outro lugar em que o jogo foi divulgado. Para piorar, até uma determinada data (enquanto ainda estávamos desenvolvendo o jogo), quem terminava o jogo em Flash se deparava com uma tela pedindo um e-mail de contato, para que no dia 04/jun/2007 recebesse um aviso com o link para download do jogo mobile. Chegou o dia, passou o dia e nunca recebi tal e-mail (é óbvio que iria finalizar o jogo em Flash e inserir meu e-mail para ver se realmente receberia o link de download). Esse foi um pequeno deslize que afetou a quantidade de pessoas conhecendo e jogando um advergame de uma campanha interessante e ousada. De nada adianta um produto existir se ninguém toma conhecimento dele, não?

Conclusões

Com a experiência de desenvolver um advergame em um curto período de tempo e analisando o projeto após seu lançamento, aprendi as seguintes lições:

Saiba aproveitar o que você já fez em outros projetos pois nem sempre o prazo determinado permite que você fique reinventando a roda; crie um framework consistente que cuide de tarefas comuns e pequenos detalhes pois ele o ajudará muito (sim, sempre esquecemos desses pequenos detalhes quando eles não existem, aumentando o tempo de desenvolvimento de um projeto).

Ao trabalhar com clientes (ou terceirizados), comunicação e cooperação são indispensáveis. Caso contrário, um projeto vai de mal a pior (pra não citar cancelamentos, multas e prejuízos). É importante que tanto quem desenvolve como quem contrata estejam cientes disso, e não apenas quem desenvolve (ou apenas uma das partes).

Jogo pronto não significa muito se não for (bem) divulgado. Não assuma que as pessoas vão procurar por algo que elas nem mesmo fazem idéia que existam. Um bom trabalho de divulgação do jogo é essencial; já pensou em enviar press release para sites e blogs especializados? No caso de mobile, um jogo ganha muito mais exposição e conhecimento das pessoas quando o mesmo é incluso em alguma operadora.

Por fim, você pode fazer o download do jogo Chevrolet Prisma Test Life mobile aqui, com acesso via WAP pelo celular ou então fazendo o download dos arquivos .jad/.jar no seu computador e instalando através de cabo, infra-vermelho ou Bluetooth.

 

Concurso Telemig Celular Games

Um pouco antes do Natal de 2007, a Telemig divulgou a lista dos ganhadores do concurso Telemig Celular Games em um edital bem tímido (ao contrário da divulgação do concurso em si, o resultado não teve muita exposição na mídia online).

Não comentei nada por aqui, mas a empresa onde trabalho participou do concurso na categoria Patrimônio Cultural e acabamos ganhando o primeiro lugar! Recebemos um convite para participar de uma festa da Telemig no dia 19/12/2007 (não sei ao certo se era lançamento do Instituto Telemig Celular) e fomos até Belo Horizonte para prestigiar o evento. Além do primeiro lugar, pudemos ver outros ótimos trabalhos envolvendo vídeos, imagens e trabalhos educacionais/culturais, assim como aproveitar pra comer e beber de graça e passar por momentos engraçados durante a curta viagem. Seguem algumas fotos:

Nosso jogo, “Delícias da Vovó”, rodando num Nokia N73.

Robert, JP e Tetsuo em frente ao painel com os jogos ganhadores do concurso

Eu e Robert checando o 3o colocado na categoria Tema Livre, “Egg Drop” de Adriano C. Campos. Em uma mão o N73 e na outra uma taça de champagne :-).

Festa do Instituto Telemig Celular

A Microways participou com o jogo Delícias da Vovó, “um jogo baseado na culinária mineira, que se espalhou pelo Brasil inteiro e é conhecida em vários lugares pela sua simplicidade e sabor. A personagem principal é uma prendada Vovó, que prepará várias receitas para sua família. O cenário de jogo é uma cozinha tipicamente mineira e o objetivo do jogo é concluir o maior número de receitas ao longo do dia. São 11 receitas diferentes (Trança de Rainha, Pão de Queijo, Biscoito de Polvilho, Biscoito Frito, Bolo de Fubá, Arroz Doce, Feijão Tropeiro, Lombinho, Arroz de Forno, Tutu com Lingüiça, Caldo de Feijão), e a cada partida elas aparecem em ordens diferentes. Também é preciso organizar a bagunça entre uma receita e outra, utilizando a Pia para lavar a louça e o Lixo para jogar os restos.”

Segundo o regulamento do concurso, o jogo estará disponível para download gratuitamente pela Telemig. Agora resta aguardar. Enquanto isso, deixo algumas screenshots do jogo Delícias da Vovó:

 

Mobile Entertainment magazine #35 disponível

A edição #35 da Mobile Entertainment já está disponível para download no site da Mobile Entertainment.

 

Mobile Entertainment magazine #34 disponível

A edição #34 da Mobile Entertainment já está disponível para download no site da Mobile Entertainment.

 

Mobile Entertainment magazine #33 disponível

A edição #33 da Mobile Entertainment já está disponível para download no site da Mobile Entertainment.

 

Mobile Entertainment magazine #32 disponível

A edição #32 da Mobile Entertainment já está disponível para download no site da Mobile Entertainment.

Atualização: como o site foi modificado, agora é necessário logar no mesmo para baixar a versão digital da revista, igual no Develop Magazine. Lembrando que o cadastro é gratuito (caso você já tenha feito download de alguma edição anterior, você provavelmente recebeu/receberá um e-mail deles informando seu login e senha).

 

Telemig Celular Games

Mais um contest envolvendo gamedev. Dessa vez, pelo Instituto Telemig Celular. Os criadores dos 13 melhores jogos mobile serão premiados (prêmios de até R$10.000,00) e terão os trabalhos disponibilizados para download no site do instituto.

O contest vai de 08/10/2007 até 09/11/2007. Versões demos não serão aceitas, apenas jogos completos. Quer participar? Corra para o site oficial do contest já! E boa sorte!

 

Desenvolvedor: cuidado com as palavras usadas no seu jogo…

…porque senão o seu jogo pode não ser bem aceito pelo mercado, ter que ser recolhido (e até parar de ser vendido) e talvez a imagem da sua empresa seja manchada.

Uma notícia informou que o pai de uma criança parou de jogar o “Junior Scrabble 2007” para Nintendo DS após a palavra “lesbo” aparecer no jogo. De acordo com a notícia e depoimento do pai, “lesbo” é uma gíria ofensiva e ele achou que tal palavra não deveria estar presente no jogo.

Portanto, saiba bem o que é permitido/aconselhável usar visualmente e textualmente nos seus jogos e conheça bem o seu público-alvo. E aqueles que estão ao redor do público-alvo (neste caso, pais podem -e devem- verificar e controlar o que seus filhos de 7 anos estão jogando).