Revista JogosPro e-Magazine No. 2 (Versão Antiga)

O estado-da-arte do desenvolvimento de jogos no Brasil

JogosPRO www.jogospro.com.br

Novembro 2004

e-Magazine

Entrevista:

Artigos:

2D .NET Parte 2 Symbian Brew OGL/ES Super Waba

Omarson Costa Colunas:

Java Psicologia XNA e XBOX2

Mobile Games Desenvolvendo Jogos para Celulares

2D:

Fim do Jogo:

3D:

Projeto:

Palmsoft Tecnologia

di

Analises do 3D Studio Max e Maya

Criatividade em Jogos

E

Animações por Tempo

# çã 2 o

Especial: Cobertura do evento SBGames 2004

Conteúdo 3 Cartas dos Leitores 4 Bonus - Pequenas Grandes Notícias Entrevista 5 Omarson Costa por Carlos Caimi

Projeto: Made in Brasil 7 Palmsoft Tecnologia por Equipe Palmsoft

Colunas 10 XNA e XBOX2 por Julio Marchi

15 A “Brasilidade” nos Video Games por Alessandro Vieira dos Reis

17 JAVA Micro Edition por Paulo R. C. Siqueira

Capa 22 Desenvolvimento para Celulares

Clique aqui para acessar o FORUM GERAL desta edição

Prezado Leitor, Antes de mais nada, nós da equipe JogosPRO, gostaríamos de agradecer imensamente a todos que criticaram, enviaram sugestões e mensagens de apoio para a revista. Buscamos atender a todos na medida do possível, visando sempre a qualidade da JogosPRO e-Magazine.

Nesta edição o assunto principal será Jogos para Mobiles. Esta área do desenvolvimento de jogos vem crescendo muito nos últimos tempos. Para quem busca montar uma empresa este mercado é um bom começo, pois pode ser uma boa fonte de receita para agüentar os primeiros passos. Existem diversas opções em linguagens de desenvolvimento para mobiles, as quais buscamos abordar um pouco sobre algumas das mais conhecidas, habilitando o caro leitor a analisar e decidir qual é aquela de sua preferência.

A jogosPRO também foi cobrir o Simpósio Brasileiro de Jogos, o SBGames, que aconteceu em Curitiba nos dia 20 e 21 de outubro, na Unicenp. Tiramos várias fotos para mostrar como foi o evento. Confira!

Nesta edição o leitor poderá notar que todas as matérias possuem um link de acesso direto ao tópico do fórum referente à matéria. Tudo isso para facilitar a troca de experiências com outros leitores e lembramos que o nosso fórum estará sempre à disposição para dúvidas e discussões. E também estamos recebendo artigos técnicos relacionados ao desenvolvimento de jogos. Participe!

A equipe jogosPRO deseja a todos uma excelente leitura.

Grande Abraço, Carlos Caimi Editor Chefe

por Eliazer Kosciuk e Julio Marchi

Artigos 27 Animação 2D baseada em tempo por Paulo V. W. Radtke

30 2D .NET games: Usando a GDI+ II por Wilson Jr

32 BREW Primeiros Passos por Matias Rodriguez

35 Programação no Symbian OS por Daniel “NeoStrider”Monteiro

37 3DS MAX e MAYA por Eduardo Dias Favero

39 Super Wabba por Wilson Jr

43 OpenGL / ES por Bruce Barrera

Especial 49 SBGames 2004 por Matias Rodriguez Fim do Jogo 51 Criatividade nos Jogos por Fabrício Kolk Carvalho

Artista: Murilo Kenji Shimizu (aka DarioLeaf) Personagem: Halberd Von Gauss Gênero: RPG, Medieval Data de Criação: 28/10/2004 E-mail: darioleaf@yahoo.com.br Portifólio: www.yac-rp.com/leaf

Ficha Técnica Editor - Chefe Carlos H Caimi Editor - Assistente Bruce “Sinner“ Diagramação Carlos H Caimi Bruce “Sinner“ Arte-finalização ProVis Design Corporation Equipe Técnica Alessandro V. dos Reis Daniel Monteiro Julio Marchi Matías G. Rodriguez Paulo R C Siqueira Wilson Jr. Revisão Jonatas Moraes Autores Convidados Eduardo Dias Favero Eliazer Kosciuki Equipe PalmSoft Tecnologia Fabrício Kolk Carvalho Paulo V. W. Radtke Capa Carlos H Caimi Webmaster Bruce “Sinner“ Contato jogospro@jogospro.com.br Esta publicação foi arte-finalizada nos estudios da ProVis Design (USA).

Equipe de Arte: Edgar Garduño, Maria Nitzahary e Ralph Wolfgang Ortiz

Coordenação Geral e Produção dos PDF’s: Julio Marchi

Nossos Números Item Downloads full Dowloads parciais Visitas no site Emails recebidos Mensagens no forum Leitores registrados Avalição na enquete

Números 5049 602 14132 51 191 237 8,521

CARTAS

Escreva para a JogosPRO

Clique aqui para acessar o FORUM desta Seção

Se você quer escrever para a JogosPRO para criticar, elogiar, dar sugestões, comentar sobre um artigo ou sobre a revista em geral; não se acanhe: envie um email para jogospro@jogospro.com.br, que nós o leremos com certeza.

Então...

Estou em época de vestibular e passei no vestibular pra design de jogos também. Daí estou na dúvida do que fazer. E a revista saiu bem a tempo de me ajudar a decidir!!! Tá muito legal a revista. Tem uns errinhos de portuga, mas dá pra entender!

Valew t_diego@...

Olá Diego, Legal, tomara que a revista o tenha ajudado a se decidir pelo design de jogos, e não ao contrário . Em ambos os casos, desejamos muito sucesso. Quanto aos erros de português, para essa edição tentaremos melhorar. Conseguimos até um colaborador, que irá fazer parte da equipe, e fará a revisão de todos os textos.

Forte abraço, Equipe JogosPRO A revista é excelente - bom ver que tem gente no Brasil botando fé no potencial do país para a área de software. E eu creio que o Brasil tem um potencial muito, muito alto para jogos!! Na maioria dos casos, é só um sonho... Mas vc deve lutar por ele, pode acabar conseguindo! Aqui no XBOX nós somos 3 brasileiros, em um grupo de algumas centenas de pessoas, mas estamos representando o Brasil firmes e fortes :-). Sempre sonhei em trabalhar com jogos, tive que esperar 22 anos entre o dia em que joguei meu primeiro jogo e o dia que finalmente estava na Game Industry. Sua revista vai ajudar muitas outras pessoas a concretizarem esse sonho, assim espero!

Parabéns!

Daniel Andrade.

Olá Daniel, A equipe da JogosPRO está empenhada em levar sempre um material de alta qualidade para a comunidade brasileira. Nós, como você, acreditamos que o Brasil, logo logo, terá várias empresas de jogos com qualidade internacional. Buscamos com a revista ajudar no que for possível para que isso venha a acontecer o mais rápido possível.

Grande abraço, Equipe jogosPRO. Cara vocês estão de parabéns: a revista é demais, clara, objetiva, e mostra o que há de verdade e mentira no desenvolvimento de jogos. gostei porque esse é meu futuro: desenvolver jogos no brasil, e em java se possível... Eu curto muito java, estava em constante pesquisa sobre a linguagem antes mesmo do lançamento da revista, agora, estou pesquisando mais, principalmente por estar aprendendo na faculdade. No momento estou na criação de um RPG, (...) Bom, a principio é isso, parabéns mais uma vez e até o próximo contato, que será em breve pois quero manter contato com aqueles que fazem o que um dia eu farei: Desenvolver jogos! um abraço, W.O.S Olá, Valeu os elogios. Esperamos que nesta edição possamos fazer jus a eles novamente. Desejamos sucesso na sua carreira promissora. Não deixe de participar dos fóruns de discussão no site da revista, assim poderemos sempre manter contato.

Abraços, Equipe jogosPRO. ah, ia quase esquecendo. Nem todos os emails poderão ser respondidos na revista. E às vezes pela correria, nem todos poderão ser respondidos. Mas nos comprometemos a ler todos os que nos forem enviados. Se você não quiser correr o risco de ver seu email publicado na revista, por favor avise no email, que nós tomaremos o cuidado.

BONUS - Pequenas Grandes Notícias

Clique aqui para acessar o FORUM desta Seção

Se você quer ter sua notícia publicada nesta seção, envie-nos seu texto e a arte necessária para jogospro@jogospro.com.br, colocando no campo assunto “Seção Bonus - Nova Notícia”.

As notícias poderão ser resumidas sem prévio aviso por necessidade de ajuste de espaço.

A determinação de publicar ou não uma notícia será únicamente dos editores. A publicação da notícia é gratuita.

Live Action do TaikoDom

Concurso de Jogos

No verão de Florianópolis, a partir do dia 2 de fevereiro, haverá um evento especial para o mundo dos videogames.

No norte da Ilha, em Canasvieira, um misto de ‘live action’, cinema e videogame dentro de um Sapiens Circus (www. sapienscircus.org.br, instalação de interatividade) vai marcar a estréia do TaikoDom (www.taikodom.com.br), MMOG brasileiro ainda a ser lançado em 2005. Os jogadores, ao entrarem no Sapiens Circus, serão transportados para o mundo de TaikoDom, entrando na pele de patrulheiros, piratas, mercadores espaciais, aprendendo a pilotar naves futuristas e travando combates épicos no espaço. Além do componente videogame, atores, cenografia, jogos de luz e som, e outros recursos cênicos tornarão o Circus uma espécie de LAN House do futuro.

A primeira etapa do Concurso se encerrou no dia 25 de outubro de 2004, à meia-noite, superando todas as expectativas. A página do Concurso conta com 3911 usuários cadastrados, 1537 idéias publicadas, 1317 idéias abertas para visualização, 1271 abertas para colaboração e 1066 idéias inscritas para o concurso. Temos cerca de 3.78 colaborações por idéia, o que dá um total estimado de 4800 colaborações.

O resultado da Primeira Etapa, com as 36 melhores idéias selecionadas para a Segunda Etapa, foi divulgado no dia 19 de novembro de 2004 na EGS.Na segunda etapa, os desenvolvedores de jogos irão apresentar propostas a partir das idéias vencedoras da primeira etapa, e poderão ser apoiados pelo Ministério da Cultura para criar demos de jogos que todos poderão conhecer e jogar.

Eletronic Game Show

Tecnólogo em Desenvolvimento de Jogos de Computador

O EGS é a primeira feira da América Latina onde se reunem os principais fabricantes, desenvolvedores e distribuidores de jogos para consoles, computadores, celulares e internet, atraiu cerca de 22,000 visitantes , nos dias 20 e 21/11, que conheceram o que há de mais novo em Entretenimento Eletrônico. Além do anúncio dos vencedores do concurso JogosBR, promovido pelo M inistério da Cultura, os visitantes puderam cur tir o lançamento de jogos a muito aguardados, como: Half-Life 2, da Valve, e de Halo 2 da M icrosof t.40 expositores marcaram presença na feira, entre eles, Nintendo, Elec tronic Ar ts (EA), M icrosof t, Nok ia e AMD. Alguns lançamentos também marcaram a feira. Inclusive o 64Fun, computador desenvolvido especialmente para jogos.

Será que vai pegar?

Sem contar o N- Gage QD e o Nintendo DS.Esperamos, aciosos, o segundo semestre de 2005, quando acontecerá a edição 2 da feira. http://www.jogospro.com.br

O centro universitário metodista, localizado no Rio de Janeiro, está com as inscrições abertas para a primeira turma do seu curso de desenvolvimento de jogos. O curso tem duração de 2 anos e meio e vai custar 300 reais por mês. Com seu início marcado para fevereiro de 2005, conta com 15 professores (10 mestres e 5 doutores).

O curso de Tecnologia em Desenvolvimento de Jogos de Computadores, com foco nas atividades de projeto e desenvolvimento, é um curso de graduação tecnológica, que atenderá a dois perfis de aluno: o profissional que necessita aperfeiçoar-se rapidamente e o egresso do ensino médio (normal ou técnico) que deseja obter uma qualificação profissional para uma inserção competente, e de curto prazo, no mercado de trabalho de produção de jogos de computador.

Ao término do curso, o aluno obterá o título de Tecnólogo em Desenvolvimento de Jogos de Computador. E como todo desenvolvedor é da noite, o curso será noturno.

NOVEMBRO 2004

JOGOSPRO e-magazine

por Carlos Caimi O sistema BREW (pronuncia-se bruu), da QUALCOMM, é uma tecnologia que conecta a cadeia de valor do mercado wireless.

Envolvendo os desenvolvedores, os distribuidores, os provedores de conteúdo, as operadoras, os fabricantes e os clientes, para que todos saiam ganhando com produtos e serviços para o mercado de comunicação móvel.

Prestes a completar 4 anos de idade, os números do BREW saltam aos olhos (veja quadro).

Hoje já podemos encontrar esta tecnologia em 24 países em todo o mundo, no Brasil, a VIVO é a única operadora que já implantou este tecnologia.

E para quem acha que jogo de celular é sem graça, com o BREW, aliado ao OpenGL ES, já é possível desenvolver jogos 3D.

Números Brew Mais de 180 milhões de downloads de aplicativos BREW em todo o mundo.

Mais de 38 milhões dispositivos BREW no mercado.

Mais de 150 modelos de dispositivos BREW disponíveis comercialmente.

37 operadoras BREW comerciais.

27 fabricantes de dispositivos BREW disponíveis comercialmente.

24 países com serviços BREW

120 jogos disponíveis para download na VIVO. fonte: www.qualcomm.com/brew e www.vivo.com.br http://www.jogospro.com.br

E N T R E V I S TA

A JogosPRO conversou com Omarson Costa, para saber mais sobre o BREW e o mercado brasileiro de jogos para celular. Ele é o responsável pelo processo de contratação e gestão de parceria da VIVO. JogosPRO: Quais as perspectivas da Vivo para o mercado brasileiro de jogos para celulares?

Omarson Costa: Aumentar o número de desenvolvedores e conseqüentemente aumentar a oferta e a receita do serviço.

Investiremos fortemente em políticas de parcerias com desenvolvedores (em geral), mas com foco em jogos feitos em Brew. Já é possível projetar receitas de alguns milhões no prazo de 1 a 2 anos.

JP: Por que a Vivo escolheu a tecnologia Brew e não outra tecnologia como J2ME por exemplo?

OC: Basicamente porque o Brew tem modelo de negócio definido e controle operacional do processo, evitando perdas de receitas. Além disso o Brew era uma plataforma 100% operacional em operadoras ao redor do mundo (quando o escolhemos há um ano e meio atrás), enquanto que o J2ME não funcionava. No resto elas se equivalem ou estão muito próximas.

JP: Esta tecnologia é compatível com todos os celulares?

OC: O Brew é um chip e ao mesmo tempo uma arquitetura de distribuição de aplicativos. Portanto todo o aparelho que possui este chip é um aparelho compatível.

JP: Qual a perspectiva da Vivo e o mercado de aplicações/games 3D nos seus celulares?

OC: Esperamos aumentar a oferta de aplicativos mais desenvolvidos nos aparelhos de 3G, que deverão estar disponíveis no final deste ano e começo de 2005.

JP: A Vivo está trazendo jogos de empresas com tradição neste mercado, como a Jamdat e Gameloft. É por falta de desenvolvedores no Brasil?

NOVEMBRO 2004

OC: Sim. O mercado de jogos na VIVO gera cerca de alguns milhões de reais/ano. Os desenvolvedores internacionais já compreendem o modelo de “revenue-share” (divisão de receitas) e assumem riscos. Os desenvolvedores brasileiros ainda estão aprendendo este modelo e estão “acostumados” em modelos comerciais em que existe sempre um “patrocinador”.

JP: Neste caso, o desenvolvedor brasileiro não pode se sentir intimidado por essa concorrência?

A Vivo pretende incentivar de alguma forma, ou dar preferência, ao desenvolvedor brasileiro?

OC: De forma alguma. Os desenvolvedores brasileiros são tão bons e competentes tecnicamente quanto qualquer estrangeiro. A diferença é assumir riscos e ousar inovar os modelos comerciais.

Preferencialmente a VIVO opta por desenvolvedores nacionais em caso de aplicativos similares.

JP: Que vantagens tem uma empresa brasileira ao optar pela Vivo e a tecnologia Brew?

OC: A VIVO hoje propicia a maior base “monetizável” (capaz de fazer e gerar receitas), além de ter um processo claro de contratação e gestão da parceria. O mercado Brew cresce a taxas de 20% ao mês no mundo todo. Qual negócio cresce a esta taxa e com controle operacional e financeiro? Desta forma acredito, que optando pela VIVO e pelo Brew, os desenvolvedores podem rapidamente gerar receitas nunca antes planejadas ou imaginadas, se comparadas ao mundo Java.

JP: A Vivo subsidia de alguma forma o desenvolvimento de aplicações Brew?

OC: No início de nossas operações fizemos políticas de incentivo.

No momento não fazemos mais incentivos financeiros.

JOGOSPRO e-magazine



E N T R E V I S TA

por Carlos Caimi JP: Como um desenvolvedor faz para vender jogos para a Vivo?

Existe algum tipo de licenciamento ou qualquer um pode se tornar um desenvolvedor?

inovações (planejar updates a cada 3 meses por exemplo), ou seja, planejar o negócio. Isto é um ponto falho enorme dos desenvolvedores nacionais.

OC: Qualquer empresa que queira entrar neste mercado é bem vinda na VIVO. Basta apresentar um sólido portifólio (PPT por exemplo) e a VIVO ter o interesse neste portifólio.

A partir deste “aceite” a VIVO fecha um contrato com o desenvolvedor e entramos em fluxo operacional da parceria. Lembrando somente que a VIVO trabalha com empresas e não com pessoas físicas.

JP: Recentemente a Vivo realizou um concurso para os desenvolvedores de jogos para celular, utilizando o Brew. Qual foi o objetivo principal do concurso?

Quantos jogos foram enviados?

Quem foram os ganhadores?

JP: Como é feita a remuneração?

OC: Mensalmente é emitido um relatório (auditável) sobre a performance do parceiro. Das receitas geradas o desenvolvedor recebe uma porcentagem destas receitas.

“...planejar o negócio. Isto é um ponto falho enorme dos desenvolvedores nacionais. “

JP: Existe alguma preferência por estilos de jogos?

OC: Não. A VIVO opta por todos os tipos de jogos (segmentação de público) e por isto oferecemos para todos os gostos.

JP: Devido ao constante avanço da tecnologia, jogos para celulares tem um ciclo de vida curto. Isto é um mito ou uma verdade? Qual o tempo ideal para esse ciclo?

OC: Verdade. Porém este ciclo pode ser sustentado por pequenas inovações. Assim como temos o Fiat Palio há anos no mercado (muda-se detalhes do carro), pode-se ter jogos que tenham versão 1,2,3 (como filmes) ou versões on-line, ou versões com outro cenário (Doom por exemplo) e assim por diante. O mais importante é que não se faz dinheiro com jogos em celulares pensando em um ou dois jogos. Tem de ser pensado um portifólio coerente e consistente: pensar em categorias de jogos, pensar em constantes http://www.jogospro.com.br

OC: Fomentar o número de desenvolvedores (pessoa física) para gerar cultura de mercado e aumentar o número de pessoas gerando receitas com a tecnologia.

Recebemos mais de 50 aplicativos.

Os ganhadores estarão publicados na mídia em breve.

Descobrir sua área de afinidade.

Conversar com pessoas da área e começar cedo com jogos simples feitos em ferramentas de autoria (flash, rpgmaker, Doom3Maker, etc) é uma atitude inteligente. Aliás, estes pequenos jogos, que são motivo de “nariz torcido” por parte de alguns, estão sustentando muita gente por aí.

Fazer um bom portfolio é importante, pois no momento em que surgir uma boa oportunidade é melhor já estar preparado. 

Omarson Costa É Formado em Análise de Sistemas (FAAP), Marketing pelo Mackenzie (SP), MBA pela USP e Especialização de Direito em Telecom pela FGV-SP. Mais de 15 anos de experiência em TI e Telecom tendo atuado em empresas como EDS, HP e Nokia.

Alguns dos jogos disponíveis para download no site da Vivo.

Saiba Mais sobre o BREW QUALCOMM http://www.qualcomm.com/ BREW http://www.qualcomm.com/brew/br/ VIVODOWNLOADS http://www.vivo.com.br/vivodownloads/ BREW CONNECTION MAGAZINE http://brew.qualcomm.com/brew/en/press_room/adv/brew_connection/ brew_connection.html NOVEMBRO 2004

JOGOSPRO e-magazine

Coluna:

Made in Brasil

http://www.jogospro.com.br

NOVEMBRO 2004

JOGOSPRO e-magazine

A PalmSoft Tecnologia A PalmSoft Tecnologia é uma empresa dedicada ao desenvolvimento de jogos para dispositivos móveis, além de fornecer consultoria nas seguintes áreas: inteligência artificial, ferramentas de autoria, game ports e jogos sob encomenda. A empresa esta sediada em Florianópolis/SC – uma cidade que tem investido pesado para atrair novas empresas de tecnologia.

Nossa principal motivação para o desenvolvimento de jogos eletrônicos para dispositivos móveis está no desafio tecnológico de criar jogos com as grandes limitações impostas por estes dispositivos, tais como: limitação de memória, tamanho reduzido de tela, baixo poder de processamento, etc. Além disso, o desenvolvimento de jogos é um trabalho cativante e multidisciplinar, envolvendo o que há de mais novo e moderno no mundo da computação, da arte e da eletrônica.

Em Crimson After Dusk narramos a história de Alef Dusk Gusev, um vampiro em busca por respostas... Ao longo da história, Alef desvendará os mistérios por trás de sua captura e da recente declarada guerra entre vampiros, humanos e licantropos. Uma trama instigante composta de várias histórias e missões paralelas que complementam o envolvente enredo de Crimson After Dusk...

Um adventure/rpg por PalmSoft Tecnologia.

Soldado, entre em seu tanque e defenda nossos territórios! Esmague seus inimigos em mais de trinta territórios com crescente nível de dificuldade! Mas cuidado: não deixe que os inimigos destruam sua bandeira, ou o tiro sairá pela culatra!

Tank Mission II traz de volta a vida à clássica jogabilidade de Battle City do Nintendo em uma grande sessão de nostalgia.

Um novo desafio da PalmSoft Tecnologia.

Golden West Part I

A Mexican Bullet

No desenvolvimento de nossos jogos utilizamos uma plataforma desenvolvida em casa para suportar o desenvolvimento utilizando as seguintes tecnologias: Symbian, BREW e Java MIDP, e em breve GBA, Nintendo DS e PSP. Além disso, foram criados vários editores para a criação de mapas, cadastro de entidades e edição de imagens, levando em consideração as restrições impostas pelos dispositivos móveis. Em breve estaremos licenciando esta plataforma, como uma forma de auxiliar novas empresas a entrarem no mercado sem ter que passar pelas dificuldades que nós encontramos.

Durante a guerra entre vampiros e um grupo de rebeldes licantropos ocorrida na cidade de Great Abyss, Alef é gravemente ferido. Alef é salvo da morte por um vampiro estrangeiro – Lord Vladistoff, o comandante de um ataque decisivo contra os rebeldes licantropos.

Este ataque pôs fim a guerra e iniciou uma nova era de paz entre http://www.jogospro.com.br

Os dias seguem tranqüilamente até que, durante uma caminhada a cidade, Alef é capturado em uma emboscada e perde os sentidos sem saber o que o atacou. Ao acordar, percebe que está preso em um calabouço.

Tank Mission II

Estima-se um crescimento substancial no mercado de jogos para dispositivos móveis nos próximos anos, criando assim oportunidades empolgantes para empresas que pretendem entrar no mercado de jogos e para empresas já consolidadas neste ramo de atividade.

Este é um setor da economia que tem recebido cada vez mais incentivo do governo para o seu desenvolvimento, pois se vê uma grande chance do Brasil destacar-se em um cenário mundial dominado apenas por empresas estrangeiras.

Crimson After Dusk

vampiros, licantropos e humanos na cidade Great Abyss. Durante a era de paz, Lord Vladistoff é escolhido como o novo líder do clã dos vampiros, passando a treinar dois discípulos para serem seus sucessores: Stepanov Riesk e Alef Dusk Gusev. Este último foi escolhido como o futuro sucessor de Lord Vladistoff, forçando Stepanov Riesk a abandonar a cidade.

Velho Oeste Americano, uma terra selvagem e sem leis, onde apenas os bravos sobrevivem.

O ano era 1968, quando pequenos barcos a vapor traziam da distante Ásia várias famílias de imigrantes chineses perseguindo o sonho americano. Os novos habitantes estavam indo garimpar ouro na Califórnia, procurando assim a segurança para a sua família.

Mais metódicos que os Americanos, os Chineses encontravam ouro rapidamente passando a comemorar dia após dia os novos tempos. Mas os garimpeiros americanos logo organizaram uma estratégia política para impedir os chineses de trabalhar na mineração e roubar o seu

NOVEMBRO 2004

 JOGOSPRO e-magazine

ouro. O exército americano proibiu os chineses de procurar por diamantes, ouro ou qualquer outro deposito de mineral valioso em solo americano.

Quando esta notícia chegou, Chan e outros imigrantes chineses ainda estavam comemorando os resultados do dia. Sheng, o mais velho do grupo rebelou-se contra a decisão e acabou por pagar com a sua própria vida. Todos no grupo assistiram a morte de Sheng e nada puderam fazer para salvar a vida do pobre homem.

Sobre o corpo de seu tio, Chan lembra de uma terrível história que Sheng lhe contou há tempos. A história de um mapa de uma mina de ouro perdida, encontrada por quatro bravos parceiros: um chinês (Sheng), um líder indígena, um ladrão mexicano e um major do exército americano. Eles desenharam um mapa e dividiram em quatro partes, uma para cada um dos integrantes do grupo. Inicialmente Chan havia achado maluca esta história, mas agora as circunstâncias são outras, e Chan decide encontrar esta mina, mas para isso precisaria encontrar primeiro as outras três partes do mapa.

Em Golden West Part I – A Mexican Bullet narramos a história de Chan, um imigrante chinês em busca de uma velha mina de ouro há muito tempo perdida. Durante a sua jornada, ele passará por grandes apuros e precisará contar com a ajuda de seus amigos durante o longo caminho que irão percorrer atrás do sonho americano. Um RPG por PalmSoft Tecnologia.

Shadows of Malquidious

Do diário do tenente Dio Benetti – “Estes foram tempos árduos. Nossos bravos esforços para conter a invasão dos seguidores de Malquidious nas terras do sul não foram suficientes. Todos os dias, mais monstros juntam-se armada de mor tos-vivos e juntos estão destruindo as nossas belas terras.”

“Mesmo com nossas vitórias no sul, quando cheguei à minha vila natal ao norte de nossas terras, encontrei o caos e a destruição. Acredito que as razões para esta invasão sejam os lendários poderes místicos selados em uma caverna proibida, dentro dos muros da cidade.

Talvez eles queiram trazer Malquidious a vida novamente utilizando estes poderes.”

“Eu ainda estou machucado e cansado, mas não tenho escolha. Preciso entrar na caverna e pôr um fim a este longo pesadelo.”

“Eu clamo aos deuses que me dêem a força necessária para vencer a iminente batalha”. http://www.jogospro.com.br

Em Shadows of Malquidious narramos a história de Dio em sua jornada para impedir que Zardum ressuscite seu mestre: o demônio Malquidious! Durante o caminho, Dio enfrentará diversos inimigos em um ambiente envolvente e sinistro. Um  RPG por PalmSoft Tecnologia.

Equipe PalmSoft Tecnologia Todos os direitos reservados.

Contato com a PalmSoft Tecnologia: Rod. SC401 Km 1 – Tecnópolis – Centro GeNESS João Paulo – Florianópolis – Santa Catarina Fone: (48) 233-2633 contato@palmsoft.com.br http://www.palmsoft.com.br

NOVEMBRO 2004

JOGOSPRO e-magazine

XNA

e

XBOX 2

Por Julio Marchi

O que nos reserva a Microsoft para o futuro do desenvolvimento de jogos eletrônicos Nos últimos meses muito têm-se especulado sobre o XNA, principalmente depois do sucesso obtido pelo XBox, que apesar de ter chegado relativamente “tarde” ainda assim conquistou seu espaço num mercado que já estava dominado por gigantes como Sony e Nintendo. Praticamente quatro anos se passaram desde os primeiros anúncios do XBox, e a Microsoft em investido mais pesadamente do que nunca no mercado de entretenimento eletrônico desde então. Acompanhando este “time-line”, e conhecendo o perfil da empresa, é fácil imaginar que as intenções da Microsoft com o XNA não sejam nada menos do que a dominação global!

M

as afinal, o que seria então este tão fomentado XNA? Uma versão mais moderninha do “DirectX”? Uma nova linguagem? Independente do que venha a ser, qual será seu foco? Que impacto terá no mercado? Qual a conexão entre o XNA e o XBox 2? E como ficam os “outros” consoles? E os micros (PC, Mac, etc), será o XNA compatível com eles?

Estas e tantas outras perguntas têm trafegado incessantemente pela internet, mas ainda sem uma resposta efetiva da Microsoft. As poucas informações técnicas sobre o projeto têm sido liberadas “à prestação”, deixando a entender que tem sido exatamente esta “expectativa” que a Microsoft vem querendo “deixar no ar”.

Pois bem, mas afinal, de que se trata essa coisa então? Basicamente o XNA pretende ser um ambiente de desenvolvimento universal de aplicativos avançados (não somente jogos). O XNA não será um mero compilador ou uma supercoleção de bibliotecas baseadas em DirectX, mas sim um ambiente de desenvolvimento real que no caso dos jogos virá para facilitar o trabalho em todos os níveis necessários, diminuindo a necessidade de atenção na codificação e deixando assim o foco dos desenvolvedores (artistas) mais centrado nos outros aspectos do jogo em si. Segundo Dean Lester (General Manager of Windows Graphics and Gaming Technologies at Microsoft), responsável diretamente pela maioria dos jogos de sucesso desenvolvidos pela Microsoft, a empresa aprendeu muito nestes últimos anos sobre as necessidades dos desenvolvedores e as expectativas dos jogadores. O DirectX foi um avanço que teve resultados acima do esperado, o qual surgiu inicialmente para atender à http://www.jogospro.com.br

uma necessidade secundária, que era “rodar os joguinhos” no Windows 98. Hoje sabe-se a importância real do DirectX no mercado global de desenvolvimento de jogos e não foi à toa que o XBox foi desenvolvido como um equipamento diretamente derivado do DirectX. Lester aponta que o XNA engloba uma “nova tendência” (não tão nova assim) de que o software é mais importante que o hardware. Houve realmente um tempo em que o código era a parte mais importante no desenvolvimento de jogos, mas atualmente é exatamente ao contrário: a parte artística envolvida é o mais importante.

Não somente os gráficos, mas os efeitos sonoros, as animações, músicas, ambientes, etc. Tudo isso, além de jogabilidade e criatividade, são os elementos que combinados levam um título a ser um sucesso de vendas. Segundo ele, artistas gráficos e compositores não são programadores e vice-versa, e a aproximação que tecnologias como DirectX permitem entre ambos tem trazido excelentes resultados no desenvolvimento dos jogos atuais. Não é por nada que as “engines” tem feito fama nos últimos anos, pois ao facilitar o desenvolvimento geral de um jogo, libera-se mais tempo para investir no restante, que é o que realmente importa. Entretanto, na entendimento da Microsoft, as engines são uma “faca de dois gumes”, pois no geral facilitam o desenvolvimento mas dificultam a portabilidade, que é onde o XNA pretende atuar mais enfaticamente.

Quem desenvolve hoje para XBox sabe a diferença que um bom ambiente de desenvolvimento pode fazer. O XDK (Xbox Development Kit) traz não somente as bibliotecas necessárias para criar os XBE (executáveis do XBox), mas também algumas NOVEMBRO 2004

ferramentas de conversão de objetos 3D, texturas e de composição musical, com direito inclusive a ajuste em tempo real, direto do PC para o XBox, durante os testes do jogo. O mesmo para o “debug” em tempo real, via rede. Eu mesmo andei “brincando” com isso e fiquei impressionado com a simplicidade de se importar objetos e ambientes 3D no XBox, e com simples comandos criar efeitos de ambientação e movimentação.

Quem está acostumado com o desenvolvimento em Windows usando DirectX, e já teve a oportunidade de fazer seus testes com o XDK, certamente sabe a diferença que há entre os dois, e como o XDK por si só já é uma “mão-na-roda” para o programador. Obviamente que em função deste entendimento há uma expectativa bem maior em relação aos avanços que trará o XNA. “Então o XNA será mais uma ‘engine’, só que enfeitadinha e com ‘etiqueta’?” Se foi isso que passou por sua cabeça a resposta é NÃO! Segundo J. Allard (Corporate Vice President and Chief XNA Architect), o XNA nasce para ser um padrão da indústria, e não somente um ambiente de desenvolvimento, e é por isso que a Microsoft vem trabalhando em conjunto com quase todas as empresas de hardware para desenvolver o que serão os “standards” dos protocolos, das APIs, das Interfaces e dos formatos suportados pelo XNA (e pelo DirectX obviamente).

JOGOSPRO e-magazine

Ao que tudo indica os planos da Microsoft vão bem mais além. Nitidamente o XNA vem sendo planejado inicialmente para ser um ambiente central no desenvolvimento de jogos eletrônicos, só que independente de plataforma. Obviamente o Windows (Longhorn) e o Xbox 2 serão o foco central do XNA, e estes por sua vez darão suporte 100% à tudo o que o XNA virá a oferecer, mas nada impedirá que consoles como o GameCube 2, ou o PlayStation 3, assim como computadores como Macintosh e até mesmo o outros sistemas operacionais como Linux venham a ser capazes de rodar jogos e aplicativos desenvolvidos no ambiente XNA; tudo em prol de uma ampliação do mercado de games. Notoriamente a Microsoft hoje não está de olho nos 40% do mercado computacional que já são consumidores de jogos, mas sim nos 60% que ainda não são!

Dean Lester aponta também que o avanço das tecnologias tem sido muito efetivo, mas que isso tem deixado a parte que diz repeito ao desenvolvimento demasiadamente complexa e cara. Mesmo com todas as ferramentas ainda assim é complicado e demorado desenvolver um jogo. Imaginem então como seria desenvolver um jogo para Windows atualmente sem usar o DirectX... Não dá para negar que seria praticamente “inviável” esta tarefa, não só devido à grande variedade de diferentes tecnologias que existem disponíveis, mas principalmente em relação aos “drivers de vídeo” e suas incontáveis diferenças.

Atualmente o DirectX trabalha em um nível semi-direto dependendo do kernel do sistema operacional, no caso o Windows, permitindo que o jogo e o SO compartilhem as funcionalidades da mesma máquina de forma estável e segura.

Já o DirectX a ser implementado pelo XNA (e que virá nativo no XBOX 2 e no Longhorn) deverá ir mais além do que isso, tendo controle direto de cada dispositivo que estiver presente no equipamento. No caso dos consoles o “poder de fogo” deverá ser ainda maior pois não há necessidade de compartilhar o hardware com nenhum outro software, o que dá liberdade de controle total ao DirectX. Com eu disse antes, o LongHorn (futura versão do Windows planejada para 2006) já virá com suporte nativo ao novo DirectX implementado pelo XNA, assim como o XBOX 2, e para que isso seja possível comercialmente a Microsoft tem trabalhado diretamente com os mais renomados fabricantes de hardware, como Nvidia, ATI, Intel e outros, na criação de definições para os “novos PCs”, que sejam mais simples para os usuários e mais genéricas para os desenvolvedores. Não está definido ainda como serão estas definições, mas em “off” me deixaram escapar que haverá classificações por níveis para os PCs do futuro, algo como http://www.jogospro.com.br

“Nível 5” para um computador comum e algo como “Nível 7” para um mais avançado.

O XNA vem sendo então a realização do sonho da Microsoft: a compatibilidade por software com independência do hardware. Esta idéia tem sido também o “sonho dourado” de muitas empresas de desenvolvimento, pois isso baixaria os custos e aumentaria as vendas. Por isso não duvidem que desenvolvedores antes enfocados em “outros” consoles rendam-se ao XNA quando virem que o mercado alheio está ganhando terreno graças à esta ferramenta, e obviamente ao dar-se conta das possibilidades de negócios que seu uso irá proporcionar.

Consoles se distanciam cada vez mais... Antes, imaginava-se que haveria uma união do que é o computador com o telefone, a TV, o rádio etc...

Hoje, já é possível ter todos os recursos destes equipamentos rodando no PC, e mesmo assim este não veio a substituir os “outros” aparatos, e todos continuam tendo seus espaços em nossas casas. Notoriamente não irá acontecer o que o Bill Gates previu em seu livro “A estrada do futuro”, pelo menos não no mesmo nível, mas os consoles seguramente estarão ali “tapando o buraco”, e o XNA deverá ser o laço de união entre o nicho de mercado dos Computadores e o dos Consoles.

Neste ínterim entra ainda outro produto de integração mútua: o LIVE. Atualmente Você que está lendo este artigo deve estar conhecido como XBox Live, esta tecnologia que pensando assim: “O que tem haver Longhorn, permite que se jogue on-line (e que já não era XBox, etc com o desenvolvimento do XNA?”. A nenhuma novidade antes do XBox existir), já resposta, caso você ainda não tenha alcançado a é capaz de algumas “inovações” como permitir idéia da Microsoft, é: simplesmente TUDO! O XNA que se converse via voz durante o jogo. O novo será além de tudo um modelo de implementação, Live deverá vir com grandes novidades em certificação e padronização de periféricos. No sua implementação no XNA, e isso tem sido caso dos “periféricos” para XBox 2 por exemplo, praticamente uma exigência comum entre todos já está definido que TODOS irão ser compatíveis os desenvolvedores consultados. Ao que tudo com PC (e conseqüentemente com Mac pois a indica, boa parte do trabalho tem sido no projeto tendência é que tudo seja USB2). Em verdade, para um “novo Live”, que além da segurança diga-se de passagem, é uma ingenuidade pensar e versatilidade, trará modelos de negócios e que já não é assim atualmente, pois a verdade implementações diversas para atender a várias é que os conectores de Joystick do XBox nada necessidades que se apresentaram. mais são do que portas de um hub USB nível Tendências Futuras 1, apenas o conector é específico. Qualquer Vendo que o XNA será algo totalmente voltado periférico USB pode ser conectado ali com um ao software, e depois de ver tantos investimentos simples adaptador e, para os que possuem seu XBox “MODDED” (modificado), é possível conectar serem feitos no XBox (em hardware) nestes quase teclados, mouses e até impressoras ali para serem quatro anos, muitos assim como eu devem estar controlados por uma versão especial de Linux que imaginando se a Microsoft não estaria andando na contra-mão do mercado? Entretanto, mais uma já existe para o XBox. vez Laster tem um contundente argumento que nos leva facilmente a entender por que a Microsoft Entretanto, por outro lado, na cabeça da está investindo em uma estratégia de software ao Microsoft não se misturam os mercados de PC e invés de concentrar-se no hardware dos consoles.

Windows com o de XBox, e por isso não deverá Segundo uma análise dele, os consoles são como existir uma versão de Windows para o XBox 2 “ondas”, e têm seus altos e baixos, enquanto os PC como muitos imaginavam. Na verdade, PCs e

Uma “criatura” demonstrando os efeitos de “Fur” entre outros. Na animação notam-se sutilmente os “músculos” movendo-se por debaixo da pele do animal, efeito até então somente usado em superproduções hollywoodianas.

NOVEMBRO 2004

JOGOSPRO e-magazine

Foto maior: Um “shot” do impacto entre os dois carros em CRASH DEMO 2. O importante aqui são os efeitos de “desfragmentação”, “pressão”, “gravidade”, “força”, “deformação” e “impacto” executados em realtime no XBox 2 e criados usando as ferramentas do XNA. Foto menor: Um close do carro no CRASH DEMO 2, mostrando os efeitos de renderização de texturas, reflexão e luzes, também em realtime, no XBox 2.

com Windows tem uma caminhada evolutiva mais retilínea e contínua. Isto é, quando se lança um novo console, tudo é novidade, tudo é inovação e ali está a “ponta” tecnológica do momento. Mas, este “momento” fica naquele nível sem evolução real, e demoram anos até que um novo console seja lançado e novamente eleve o nível dos mesmos ao “ultimate hi-tech peak”.

O que se mantém constante nesta linha de tempo é a evolução dos PCs, que entre o lançamento de uma versão de console e outra, evolui constantemente e se torna MELHOR que o console, o qual não evolui até o próximo lançamento (que não vem em menos de 3 ou 4 anos). Um exemplo disso é o próprio XBox, que em 2001 era sem sombra de dúvida o equipamento mais poderoso do mercado, e nem os mais caros PCs da época poderiam compararse a ele. Hoje, qualquer computador de $500 comprado nas lojas de departamentos é mais avançado tecnologicamente que um XBox (ou qualquer console)... O que isso tem a ver com o XNA? Simplesmente TUDO! Então os consoles deixarão de existir ou deixarão de ser o foco dos jogos eletrônicos? A resposta a esta pergunta é NÃO, mas ganharão novos enfoques com certeza.

Assim como o XBox hoje já substitui muitos DVDPlayers, amanhã este poderá ser uma central de entretenimento mais completa e expansível do que simplesmente um “video-game”. E é aí que entra o XNA, principalmente quando em 2006 o Longhorn e o Xbox 2 estiverem nas prateleiras!

Será o poder de desenvolvimento do XNA, aliado às “padronizações” envolvidas nas parcerias, que permitirão que sejam desenvolvidos novos equipamentos facilmente integráveis ao XBox, expandindo suas funcionalidades.

Inovações reais do XNA

Lembro-me quando comecei a aprender CG (Computação Gráfica), com o 3D Studio 2.5 (para DOS), com o Animator PRO e com algumas outras poucas ferramentas que existiam, a maioria ainda baseadas ou dependentes de AutoCad. http://www.jogospro.com.br

Era estrondosamente complexo criar qualquer coisinha mais elaborada. Hoje, com programas como Maya e 3D Studio Max 6 por exemplo, bastam alguns cliques para se conseguir efeitos que antes demoravam semanas ou meses para serem alcançados, os quais muitas vezes tinham que ser quase que manualmente desenvolvidos.

A recíproca é verdadeira para o XNA com relação ao desenvolvimento de jogos. Antes, para fazer um jogo 3D o programador tinha que criar todas as rotinas necessárias, e quase que fazia um 3D renderer em tempo real. Hoje, com o XDK (ou com algumas engines) já é possível importar os elementos 3D em buffers e manipulá-los (ainda via programação) com menos complexidade e sem necessidade de escrever nenhuma rotina 3D em especial. Com o XNA provavelmente haverão mais ferramentas de criação em RealTime, com direito a simulação no próprio ambiente e visualização de resultados antes mesmo de se compilar o programa.

trama. O XNA pretende ter recursos mais intuitivos para o desenvolvimento de tudo isso. Entretanto, não pensem que a Microsoft vai sair “metendo o bedelho” no mercado de empresas como Adobe, Discreet ou Cakewalk por exemplo porque já está notório que não. Na verdade o mais provável é que haja uma integração mais profunda entre o XNA e cada um destes programas do que simplesmente importar e usar seus arquivos. Até porque se não fosse assim o XNA acabaria realmente sendo um XDK enfeitadinho. É bem provável que algum novo modelo de OLE seja disponibilizado para que todas as ferramentas possam trabalhar uniformemente no mesmo ambiente (apenas especulação por enquanto).

No mais, o XNA pretende concentrar seu poder do desenvolvimento no jogo e não no código, muito menos na plataforma (desde que esta seja DirectX compatible), e para isso necessitará ser capaz de compilar o mesmo projeto para diferentes “ambientes” (Windows, XBox, etc), e em cada compilação compatibilizar o produto final ao máximo, o que não é uma tarefa fácil e depende de combinação de esforços entre os fabricantes de cada equipamento e os planos da Microsoft para o XNA.

Parece até que estamos falando de Java, mas a implementação é muito diferente. O que é um fato comum entre ambos é que a multiplataforma é bem mais que uma utopia; é uma necessidade global! A companhia que conseguir ter seu ambiente multiplataforma reconhecido e usado pela maioria dos fabricantes dominará o mercado de software. Isso já acontece hoje com o Photoshop da Adobe, o qual é usado em Macs, PCs, Silicons e etc, além de atender às necessidades de vários nichos diferentes de mercado (desenho gráfico, internet, multimídia, vídeo-produção, desenvolvimento de jogos, etc etc etc). A idéia Pelos “demos” que a Microsoft disponibiliza, é a mesma, só que em uma “camada mais pode-se ver que o novo XBox 2 possuirá poder de baixa”, onde o ambiente fará a diferença e não processamento suficiente para ser até uma estação a ferramenta. O Java tínha condição de alcançar de CGI profissional, e o XNA deverá ser a chave que este nível, mas perdeu o rumo em função de liberará todo este poder para o desenvolvimento outros nichos de mercado e a Microsoft está hoje de jogos num ambiente mais intuitivo. Segundo abocanhando sozinha todo este potencial da área o próprio Bill Gates diz, não adianta ter um super- de entretenimento. No mais, diferentemente do ultra-hyper-hardware que seja tão complicado de Java, o XNA não será “pré-compilado” e executado em uma “virtual-machine” mas sim compilado e programar que faça com que sejam aproveitados somente 20% de seu potencial. Ou ainda pior é ver otimizado para um determinado hardware que, os times de programação se matando para cumprir notoriamente, terá que ser compativel com DirectX (o qual não duvido venha receber muito mais os deadlines (prazos de entrega) das etapas do desenvolvimento de um jogo por questões de suporte diretamente implementado nos novos necessidades técnicas. É aí principalmente onde o componentes de hardware).

XNA fará grande diferença, liberando todo o poder de cada plataforma suportada com o mínimo do On-Line Entertainement esforço dos times de desenvolvimento.

A Microsoft tem estado atenta a este mercado não é de hoje, assim como outras companhias, Já se sabe que não basta ser 3D para que um jogo mas ninguém até então estava seguro de que seja um sucesso, é necessário também uma boa o “cyberspace” realmente se tornaria uma música de fundo, impactantes efeitos sonoros, verdade comercial. Já não é de hoje que jogar excelente jogabilidade e obviamente uma boa on-line é uma atração, mas é bem recente NOVEMBRO 2004

JOGOSPRO e-magazine

a possibilidade de negócios que isso abriu.

Graças à popularização e ao barateamento do que chamamos aqui nos EUA de “broadband” (conexões com a Internet em alta velocidade), não só os jogos on-line, mas os negócios virtuais explodiram em 2003 e 2004. E a tendência é que tornem-se mais efetivos entre 2005 e 2006.

Quando a Microsoft anunciou o Windows .NET na virada do século, não havia toda esta estrutura instalada e acabou que o que era para ser o .NET acabou apenas como uma sombra do projeto original, e é bem provável que boa parte das idéias do .NET venham a ser incorporadas ao XNA, e este aproveite as experiências positivas do XBox Live para tal.

“confusos”, é nítido que a Microsoft trabalhou bem e que o XBox já conquistou grande parte do mercado que antes era dos “outros” consoles.

que o MSX tinha de impressionante era a extrema facilidade de programação, que dava aos iniciantes um gostinho de “sim eu posso” e permitia que qualquer pessoa “leiga”, com algumas poucas linhas de Basic, criassem programas com impressionantes efeitos visuais e sonoros, coisa que nenhum outro computador da época permitia (nem mesmo o PC, Mac ou Amiga). Se o XNA pretende fazer o mesmo hoje, já sabemos que a Microsoft foi capaz de implementar um modelo rústico disso 20 anos atrás, com muito menos recursos do que existem hoje, e com indubitável sucesso!

Mas, existe uma diferença nisso tudo: o mercado de HARDWARE (XBox) e bem diferente do de software (que é onde a Microsoft é realmente forte)... Entretanto, para a maioria que pensa que a Microsoft esteve caminhando em “terreno desconhecido”, saibam que nos primórdios da Microsoft, Bill Gates já andou dando seus pitacos em projetos de hardware. Na década de 80 a Microsoft esteve diretamente ligada, juntamente com a ASCII do Japão, ao projeto de um microcomputador Mas, voltando do passado e olhando para o revolucionário chamado MSX. Não se sabe futuro, por mais que o XBox 2 venha ser uma exatamente os “porquês”, apenas especulam-se os “ameaça” ao PlayStation 3 e ao GameCube, o XNA Mais que uma plataforma de desenvolvimento motivos, mas a Microsoft saiu do projeto do MSX não deverá ser. Na verdade, este poderá ser um de jogos, o XNA será um ambiente de integração no final da década de 80 e deixou tudo nas mãos “ampliador de mercado” para todas as empresas. de recursos, onde os jogos serão o foco, mas não da ASCII (que foi quem praticamente afundou o Segundo analistas da Microsoft, ao desenvolver o único objetivo. A tendência de se ter jogos “on- MSX por falta de visão comercial). Curiosamente um jogo para PlayStation por exemplo, mais de line” (não apenas que se joguem via internet, o MSX nunca foi uma realidade nos EUA, mas 65% do código é “amarrado” ao hardware, e a mas que sejam USADOS via rede) torna-se cada dominou fortemente o mercado de computadores portabilidade dos jogos é complicada. Esse é um vez mais real. Atualmente a Microsoft tem planos na Europa, nos países do Ocidente e em quase efeito bilateral, pois o mesmo se dá para portar de que com o XNA não hajam mais as tediosas toda a América do Sul. É óbvio que as experiências um jogo de outra plataforma para o PlayStation instalações que são necessárias nos jogos de PC. que a Microsoft teve com o MSX (que especula2. O GameCube é mais “light” neste aspecto, mas O “ideal” seriam jogos plug’n’play, tipo: coloca se significava “M”icrosoft “S”ystem e”X”tended) também é muito dependente do hardware. o CD e começa a jogar (como é nos consoles). tem sido válidas hoje, pois para quem não sabe Esse seria o primeiro passo para jogos 100% os primeiros testes do que veio a ser o Plug’n’Play Uma vez que obviamente todos os equipamentos on-line, onde clica-se num ícone e inicia-se um foram feitos no MSX. O que isso tem a ver com são assim (alguns mais, outros menos), o jogo. Assim como Flash e ShockWave são hoje o XBox? Tudo, pois é como se o XBox fosse um diferencial pode estar em uma plataforma de uma realidade que há poucos anos atrás eram “desencavar” de uma antiga idéia, só que agora desenvolvimento integrada, a qual pretende ser inviáveis de se implementar, a tendência é que devidamente implementada. Sem querer comparar o XNA, que além de abrir a possibilidade de um o XNA abra as portas para os tão sonhados “.NET uma máquina com a outra (pois são totalmente mesmo programa ser rapidamente portado para applications”, onde aí incluem–se os jogos! distintas, com enfoques e realidades comerciais outras plataformas, visa diminuir a complexidade Obviamente não será em 2006 ainda, mas se bem diferentes), mas existem sim similaridades do desenvolvimento, baixando assim custos e tudo continuar no ritmo em que está, em 2010 curiosas, entre elas o fato de que o MSX, assim aumentando a qualidade final do produto. será realmente “o ano em que faremos contato”! como o XBox, foi um computador livre de sistema operacional e com um BIOS cheio de recursos, onde Mas, antes que você venha ter “sonhos de Sony x Microsoft x Nintendo o software tinha livre poder de atuação na máquina grandeza” pensando em desde já investir no Se olharmos o PlayStation, o GameCube e o toda! Até aí tudo bem, faz sentido, mas e o XNA , XNA pra XBox sem apaixonismos, e também analisarmos o que tem com isso? Mais ainda! Uma das coisas friamente o “background” das empresas, podemos chegar a fazer algumas “previsões” do que deverá acontecer num breve futuro. A Sony praticamente domina o mercado japonês de entretenimento, seguida de perto pela Nintendo, e deteve por um bom tempo a hegemonia no mercado de jogos com o PlayStation 1 e 2. Desde o PS1 este vinha sendo o console preferido até a chegada do “divisor de águas”, o XBox. A Microsoft nunca entrou numa briga para perder, e mesmo que tenha seus “odiadores de plantão”, não será a primeira vez que a empresa entra “atrásada” em uma competição por um nicho de mercado e acaba por conquistar quase toda a clientela. Ocorreu o mesmo com o MS-DOS frente ao DR-DOS e ao IBM-DOS, o mesmo com Windows frente ao OS/2, o mesmo com o Word frente ao WordStar, com o Excel frente ao VisiCalc Representação de vários movimentos naturais do corpo humano, com deformações faciais para simular expressões (foto e ao Lotus 123, o mesmo com o Internet Explorer menor). No mesmo vídeo notam-se os efeitos de texturização, de partículas (que geram a fumaça do cigarro), vento, frente ao NetScape e tantos outros exemplos que transparência e reflexão (foto maior). O interessante deste vídeo não é que ele tenha todos estes efeitos, pois nada disso é podemos desencavar aqui. Com o XBox não vem novidade em animações 3D, o importante deste exemplo é que tudo é renderizado em realtime, demonstrando o potencial que um jogo poderá ter ao usar-se da combinação destes recursos. sendo diferente, e mesmo que os números sejam http://www.jogospro.com.br

NOVEMBRO 2004

JOGOSPRO e-magazine

eletrônicos para diversas plataformas distintas. Desta forma, se a Nintendo um dia resolver aderir ao XNA, as licenças de venda de jogos para GameCube serão feitas entre a Nintendo e os produtores, sem intervenção da Microsoft.

somente destes mas também de alguns “big guys”. Estima-se que o modelo de licenciamento atual implementado pela Microsoft (e similares da Sony e Nintendo) simplesmente já “mataram” projetos que tinham gasto entre 3 e 5 milhões de dólares, e por isso estão sendo repensadas muitas estratégias de licenciamento novas para produtos gerados através do XNA (e não para o XNA em si), que sejam mais flexíveis e abrangentes, de forma a ampliar o mercado e não o retrair. Entretanto, Isso tudo gera uma pergunta nada de definitivo existe até então, ou talvez comum na cabeça todos: o tema esteja ainda “fechado” para discussão “Como ficarão potenciais novos desenvolvedores pública. O importante é notar que aparentemente desenvolver um jogo 100% compatível com tudo que pretendem ‘tentar’ criar jogos para o XBox 2 ou haverão mudanças ou implementações nos e todos, saiba que nem a Sony nem a Nintendo usando XNA, mas que não possuem recursos para modelos de licenças para gerar facilidades se manifestaram ainda com relação ao XNA (o as licenças iniciais?”. Esta pergunta foi respondida àqueles que pretendem embarcar na aventura de que já era de se esperar). Somente o tempo dirá por J. Allard da seguinte forma: “Eu gostaria de desenvolvimento de jogos, mas que não possuem se a Microsoft vai ter o “poder de fogo” de atrair a “apadrinhamento” ou recursos financeiros para atenção destes dois em específico para dar suporte ver mais e mais ‘garage-games’ surgindo todos ao XNA ou não. O mais provável é que a Nintendo os dias. Assim como hoje acontece com os filmes, investir pesadamente num projeto do gênero. É onde a indústria cinematográfica é capaz de gastar esperar pra ver... A verdade é que, para a Microsoft, renda-se e tire proveito do XNA para ampliar seu neste caso, quantos mais melhor! mercado, mas a Sony dificilmente irá ceder espaço centenas de milhares de dólares em uma única  produção, existem outros como Kevin Smith (que para a Microsoft e para o XNA. Mais informações: produziu Clerks, um filme amador de 1994 que http://www.microsoft.com/xna ganhou vários prêmios e chegou aos cinemas Licenças Uma vez que existem abordagens bem pela Miramax) que foi capaz de produzir um Julio Marchi É Analista de Sistemas especializado em engenharia de diferenciadas no que se refere às licenças dos filme de sucesso apenas com a câmera da mãe software, networking, multimídia e Internet. jogos eletrônicos, obviamente que o XNA já chega emprestada e sem ultrapassar o limite do cartão Atualmente é CEO de duas empresas nos EUA onde deixando esta dúvida no ar: “Se um jogo para de crédito. O mesmo cenário se repete no que desenvolvendo diversos projetos técnicos e audio-visuais.

Windows não exige nenhuma licença, e um jogo tange ao desenvolvimento de jogos. Hoje existem Atualmente está investindo em negócios ligados ao para XBox só pode ser comercializado quando centenas de milhares de programadores e grupos mercado de desenvolvimento de jogos eletrônicos. autorizado pela Microsoft, como fica o caso de de desenvolvimento que um projeto desenvolvido em XNA?” A resposta é são capazes de criar novos De onde vem o nome XNA? simples: exatamente como são hoje! Uma coisa e inovadores títulos, mas será ter a licença de uso do XNA (que ainda está estes ficam na dependência Segundo me disseram J. Allard e Dean Lester, o “X” de indefinida como será), outra serão os módulos de ter alguma chance de XNA representa a junção de esforços de toda a indústria para cada tipo de console/computador. Se você vai mostrar-se para conquistar em torno dos dois produtos chave da Microsoft para o desenvolver para Windows, ou para Xbox, ou para seus espaços, e nisso o XNA mercado de entretenimento: o DirectX e o XBox. O “N” ambos, notoriamente terá que ter módulos do poderá ser uma ferramenta representa a idéia de “Next-generation“ (algo como XNA destinado a cada um deles, e provavelmente importante.”, deixando a “Geração Futura”, nada diretamente ligado à StarTrek), a modularização do XNA será o canal por onde as entender que o XNA não pois explicam eles que na visão geral da Microsoft empresas “amarrarão” suas licenças. terá complicadas licenças “o software é o combustível para o futuro”. Ambos de uso. Ainda sobre os compartilham a idéia de que mesmo com os avanços Atualmente, para se comercializar jogos para ‘garage-games’ Allard do hardware, as inovações mais significativas virão XBox, mesmo que se tenha adquirido o XDK enfatizou: “Queremos ver sempre em formato de software. E finalmente o “A” legalmente, ainda assim tem-se que firmar um mais e mais ‘garage-games’ significa “Architecture” (Arquitetura), demonstrando contrato com a Microsoft para poder vender seu tornado-se sucesso! Os a idéia de que o conjunto de ferramentas conectadas jogo, pois existe um critério de “criptografia” pequenos estúdios e os e combinadas em um ambiente único podem que somente a Microsoft gera na matriz do novos programadores são proporcionar aos artistas uma libertação para sua DVD para que este possa ser reconhecido no ambiciosos e criativos por criatividade, com menos preocupação com a parte XBox (que se “autoprotege” contra a pirataria, natureza” – complementa técnica em si. Allard até fez uma comparação entre o o que não ocorre com o Windows). Existem ele – “e os grandes XNA e a Lego, onde todas as partes se encaixam e se diversos modelos de contratos que a Microsoft distribuidores terão que combinam integralmente, deixando o resultado da oferece hoje para o licenciamento de jogos aprender a dar mais criação para a qualidade imaginativa de quem combina XBox, e mesmo Allard não me pôde (ou não atenção à estes no futuro. os elementos, mas sem necessidade de complexos estava autorizado) a apontar quais mudanças Nós aprendemos a nossa conhecimentos para tal. haverão neste sentido. entretanto, ainda lição e estaremos fazendo a segundo ele, cada caso deverá ser tratado nossa parte com o XNA... “.

Ironicamente poderíamos então dizer que XNA = independentemente, negociável conforme os eXtravagant New-generation Architecture, o que não interesses de cada distribuidor/desenvolvedor e, A Microsoft tem sofrido estaria fora do escopo do produto nem das intenções obviamente, a Microsoft. enormes pressões dos da empresa, mesmo sendo esta nomenclatura apenas “pequenos” e “médios” uma piada! A nomenclatura mais correta seria Nada menos lógico para um produto que desenvolvedores, e ainda “Cross-platform New-generation Architecture”. pretende centralizar o desenvolvimento de jogos segundo Allard, não

“O software será simplesmente o elemento mais importante no entretenimento digital da próxima década. XNA reafirma o compromisso da Microsoft com a indústria de jogos digitais, e o desejo da empresa em trabalhar participativamente para elevar esta mesma indústria a níveis mais amplos.”

- Bill Gates, Fundador e Diretor Geral da Microsoft.

http://www.jogospro.com.br

NOVEMBRO 2004

JOGOSPRO e-magazine

por Alessandro Vieira dos Reis

A “Br asilidade” nos V ideogames No texto a seguir discuto a questão da “brasilidade” nos jogos eletrônicos, para isso fazendo uso de conceitos da Literatura e da Antropologia nacionais. Desenvolvo a questão das temáticas de nosso país, bem como dos atributos comportamentais do brasileiro e das formas de posicionamento de sua cultura diante das estrangeiras.

A - Identidade, Cultura e Marca

Jogos eletrônicos alistam-se como legítimos produtos de uma economia que gira em torno de bens intangíveis tais como símbolos, estética, fruição. Produtos de tal natureza econômica possuem marcas que demandam uma gestão cultural, que toca em questões de cunho psicológico da experiência humana. A marca de produtos da “Era do Conhecimento”, antes de tudo, se define por uma eficaz interação psicológica do produto com seus consumidores.

No caso específico dos jogos eletrônicos, a marca, enquanto estilo único, peculiar, que permite identificar a qualidade, hoje se baseia fundamentalmente no país em que estes são desenvolvidos. Os jogos feitos nos EUA apresentam-se fortemente modelados pelo paradigma cinematográfico de Hollywood (em termos de narratologia, temáticas, acertos e vícios, etc), enquanto os jogos asiáticos, em especial do Japão, costumam apresentar outros modelos, por vezes inovando em termos de história e jogabilidade.

A fim de oferecer subsídios para a discussão de tal tema, proponho resgatar a contribuição dos estudiosos da Literatura e da Antropologia brasileira e procurar, dentro das limitações técnico-científicas existentes, aplicar tais saberes. Quando se fala de “brasilidade” é impossível deixar de pensar no Modernismo, na Semana de Arte de 1922, nas Ciências Sociais de Sérgio Buarque de Holanda, Darcy Ribeiro, na Literatura de Paulo Prado, etc.

B. 1- Temas Brasileiros

Os campos temáticos amplamente estudados e reconhecidos como legitimamente brasileiros por literatos e cientistas sociais podem ser resumidos, a grosso modo, em quatro: 

Os sofrimentos do povo brasileiro, decorrentes de problemáticas sociais (relacionados com o “homem cordial” de Sérgio Buarque de Holanda, que sofre acomodado diante das injustiças; e o conceito do brasileiro como um “povo triste” do escritor Paulo Prado);



Tropicalismo (entendido aqui não como o movimento musical, mas como o conjunto de atributos “tropicais”, latinos, hedonistas, alegres, sensuais, festivos do povo, tais como carnaval, futebol, música, etc).



Qual é, ou deveria, ser a “Marca Brasil” em jogos eletrônicos?

Afinal, o que lhes conferiria um diferencial em termos culturais, que poderia ser comercialmente explorado, dos jogos norteamericanos e asiáticos?

História (Enquadra-se aqui falar de uma ampla gama de eventos tais como o descobrimento do Brasil, guerras internas como Canudos, os desbravamentos dos bandeirantes, o Quilombo de Palmares, e mesmo os folclores do território nacional)



B - A Contribuição da Literatura e das Ciências Sociais

Geografia (As belezas naturais, como florestas, praias, fauna, relevo, riquezas, etnias, colonizações, etc).

B.2 - Atributos Comportamentais do Brasileiro

Neste princípio de século XXI, a indústria dos jogos eletrônicos no Brasil se vê em um impasse quanto a sua identidade cultural de seus produtos. Tal questão veio à tona de forma significativa, incluindo a participação do Ministério da Cultura no debate, no III SBGames (Simpósio Brasileiro de Jogos Eletrônicos, ocorrido em outubro passado em Curitiba).

A discussão em torno da identidade cultural brasileira já é de longa data. O tópico que este artigo enfoca, a “brasilidade” dos jogos eletrônicos, é apenas mais um desdobramento de tal debate. http://www.jogospro.com.br

Ainda seguindo a contribuição dos cientistas sociais, o povo brasileiro tem seu comportamento definido, de modo geral, pela seguinte gama de propriedades:

NOVEMBRO 2004

JOGOSPRO e-magazine



Interpessoalidade (Calor humano, facilidade de comunicação, gosto pela amizade e convívio. Este ítem faz lembrar da revolução que os usuários brasileiros da internet causaram em sites de relacionamentos como o Orkut); Informalidade (Há quem diga que se trata de relaxamento e preguiça, e talvez estejam certos mesmo. O povo brasileiro é informal, dado ao riso, à festa e a formas despreocupadas de relações e tratamentos); O famoso “jeitinho brasileiro” (Levar a melhor, encontrar uma solução mágica, burlar o Sistema, passar a perna, usar de malandragem para vencer sem esforços. Vale lembrar que boa parte dos mais temidos hackers do mundo são brasileiros) Diversidade e Mistura (Dada sua geografia e história, o povo brasileiro na verdade é uma mistura de povos distintos, cada um com identidade própria, porém unidos virtualmente pelo território e a língua portuguesa. Qualquer jogo portador de “brasilidade” deve saber projetar isso em sua jogabilidade, tal como a internet brasileira o fez gerando uma complexidade única de comunidades virtuais).

C - Posicionamento Estratégico

As formas como a identidade nacional, entendida aqui como união das temáticas (ítem B.1) e dos atributos comportamentais do povo (ítem B.2) se posiciona diante da produção cultural, principalmente diante do mundo, foram amplamente discutidas pelos artistas modernistas, no início no século passado.

Conclusão

Nem todo jogo brasileiro precisa explorar temáticas tidas como legitimamente nacionais (B.1). Jogos como “Outlive” e “TaikoDom” não o fizeram, e não por isso deixam de possuir “brasilidade”. Porém a construção de uma “marca Brasil” passa pelo estudo como os atributos comportamentais do povo brasileiro (B.2) podem influir em sistemas de jogabilidade, dada a íntima ligação entre relações sociais e modos de fruição no jogo (como fica evidente em jogos como “The SIMs”).

Da mesma forma, as empresas de desenvolvimento de jogos e publicadoras precisam eleger uma forma de posicionamento estratégico cultural para seus produtos (C). É da opinião do autor que o ufanismo xenófobo do Verde-Amarelismo e a ausência de modelos do Pau-Brasil teriam pouco a acrescentar para a indústria nacional de jogos eletrônicos.

Um posicionamento antropofágico, isto é, na imitação e transformação seletiva de elementos estrangeiros mesclados com nacionais rumo à inovação parece, no atual cenário, a alternativa mais viável para os games no Brasil, como fica transparecido em jogos como o Erinia (onde o modelo de MMOGs é mesclado ao folclore nacional e europeu).

A ausência de uma identidade clara, fixa e estanque proposta pelo posicionamento antropofágico, que se desdobra na aceitação da diversidade e em misturas harmônicas, pode se constituir o grande diferencial dos jogos eletrônicos brasileiros  na atual fase de expansão dessa indústria no país.

Decorrentes da Semana de Arte Moderna de 1922 e todo o debate intelectual e artístico que ela suscitou, foram basicamente três as posições estratégicas emergentes dos modernistas no que diz respeito à cultura nacional diante do mundo.

Alessandro Vieira dos Reis

avr@certi.org.br http://www.certi.org.br/~avr/

Posição

Características

Desvantagens

Verde-amarelismo, de Plínio Salgado, Cassiano Ricardo, etc.

Afirmação defensiva, intensa e ufanista da cultura nacional, em detrimento do estrangeiro. Exposição exagerada dos traços nacionais, apresentados todos como bons, sem seleção.

Xenofobia. Além disso, o Verde-Amarelismo captava e exibia esteriótipos nacionais para o mundo.

Exemplo: “Brasil, a Terra do Futebol” (Apenas do futebol?). Também não permitia intercâmbios, misturas e mudanças

Pau-Brasil, defendido O nosso como é, “errado” mesmo, por Oswald de Andrade sem tratamentos. Devemos mostrar todos os nossos traços culturais tais como são, os bons e os problemáticos.

Antropofagia, desenvolvido a partir do Pau Brasil por Mário de Andrade

http://www.jogospro.com.br

Assimilação seletiva dos modelos e conteúdos estrangeiros, misturando com os nacionais. Forma liberal de nacionalismo, que previa a globalização nesta frase de Mário de Andrade: “Queres ser global? Fala da tua aldeia”.

NOVEMBRO 2004

Ausência de modelos, métodos, projetos. Postura um tanto espontaneísta enquanto arte e técnica.

Sem uma identidade clara: a mistura. Macunaíma é o protótipo do herói antropofágico. Segundo seu criador, Macunaíma não tem nenhum caráter, pois tem vários. Para Mário de Andrade, a pluri-identidade do brasileiro, longe de ser uma desvantagem, era seu grande diferencial: podemos ter diversas identidades, em trânsito, dependendo de nossa dieta cultural.

JOGOSPRO e-magazine

JAVA Micro Edition

por Paulo R. C. Siqueira

Na última edição falamos das possibilidades para o desenvolvimento de jogos utilizando a plataforma Java. Mostramos que, além dos jogos para celular, é possível fazer muito mais. Nesta edição vamos nos concentrar na tecnologia Java para pequenos dispositivos, J2ME, mais especificamente na tecnologia para dispositivos móveis (como celulares), a MIDP.

E

mbora nosso foco seja o desenvolvimento para celulares, J2ME oferece mais do que isso. Essa plataforma está dividida em Configurações e Perfis, sendo que as configurações determinam um conjunto mínimo de funcionalidades que um grupo de dispositivos deve oferecer e o ambiente de execução, e os perfis determinam funcionalidades para um sub-grupo dentro de uma determinada configuração.

Essa divisão em configurações e perfis foi criada basicamente por causa da grande diferença entre os dispositivos existentes.

Existem duas configurações definidas até o momento: CDC (Connected Device Configuration), que roda em cima de uma JVM compatível com a tradicional, e a CLDC (Connected Limited Device Configuration), que roda em cima de uma máquina virtual própria, mais limitada do que a convencional para poder ser executada em dispositivos com pouca capacidade de processamento e memória, além de displays também bastante limitados. Essa máquina virtual é conhecida como KVM (Kilobyte Virtual Machine).

A configuração que nos interessa é a CLDC. Em cima dessa configuração podemos citar dois perfis principais: MIDP 1.0 e MIDP 2.0. Embora a versão 2.0 do MIDP (Mobile Information Device Profile) apresente uma quantidade significativa de melhorias em relação à versão 1.0, estaremos utilizando esta última, pois não existem muitos aparelhos com suporte ao MIDP 2.0 atualmente no mercado. A tendência é que os dispositivos com suporte a MIDP 1.0 sejam aos poucos substituídos por dispositivos para MIDP 2.0; por isso poderemos abordar esse assunto em uma edição futura (opine em nossos fóruns!).

Vamos agora criar um novo projeto. Para isso, clique em “New Project”, coloque “JPong” em “Project Name” e “JPongMIDlet” em “MIDlet class Nosso objetivo aqui é mostrar como pode ser name”. Na próxima tela aceite as configurações feito o desenvolvimento de um pequeno jogo em padrão clicando em “OK”. No diretório de J2ME / MIDP. Para a leitura dos códigos incluídos instalação do WTK há um sub-diretório chamado nesta coluna, consideraremos que o leitor tem “apps”. Quando confirmar a criação do projeto no um conhecimento básico de Orientação à Objetos passo anterior, um subdiretório chamado “JPong” e da linguagem Java (se o leitor não souber Java será criado dentro de “apps”. Todo o código que mas conhecer C++ poderá compreender as for gerado para esse projeto deverá ser colocado listagens com igual facilidade). na pasta “apps/JPong/src”. A figura 2 mostra o diretório criado pela KToolBar e a figura 3 mostra Ambiente de Desenvolvimento a tela principal após a criação de nosso projeto.

A primeira coisa que devemos fazer é preparar Além do diretório para código-fonte, foram o ambiente de desenvolvimento. Para isso criados diretórios para os arquivos de recurso precisaremos do J2SDK (a mesma utilizada no (sons, imagens etc) - “apps/JPong/res” - e desenvolvimento de qualquer aplicação Java) bibliotecas - “apps/JPong/lib”. Se usarmos esses e do WTK (Wireless ToolKit), que podem ser diretórios (e faremos isso), compilar e rodar baixados no endereço http://java.sun.com/ download. Além disso, é interessante instalar nosso exemplo será tão simples quanto clicar no um editor qualquer (como o jEdit – http://www. botão “Build”, e depois em “Run”, na KToolBar. jedit.org/).

Os demais diretórios podem ser ignorados pois serão utilizados internamente pela ferramenta.

Instale o J2SDK, o WTK e o editor seguindo as Criando um Jogo instruções de seus respectivos instaladores.

Vamos então colocar a mão na massa! Abra o Em seguida clique no menu Iniciar, Programas, J2ME Wireless Toolkit <Versão>, seu editor e copie o código da listagem 1. Essa KToolBar, onde <versão> indica a versão do é a nossa MIDlet. É a classe principal de uma WTK que você instalou. Veja a tela principal aplicação MIDP, que controla a execução do da KToolBar na figura 1. programa, e a que será acessada pelo celular básico de desenvolvimento até a geração dos arquivos para distribuição.

Para mostrar como funciona o desenvolvimento de MIDlets (que é como são chamados os aplicativos desenvolvidos com tecnologia MIDP), construiremos um exemplo bem simples e prático, no qual iremos abranger desde a preparação de um ambiente http://www.jogospro.com.br

Figura 01: Tela inicial da KToolBar NOVEMBRO 2004

JOGOSPRO e-magazine



Figura 03: KToolBar após a criação de nosso novo projeto “JPong”

pasta “res” citada anteriormente, para que a “KToolBar possa encontrá-las.

Mais abaixo no código vemos o método “paint”. Esse método é o que desenha a tela do jogo em si. Ele é chamado automaticamente pela máquina virtual sempre que a tela precisa ser repintada e não deve ser utilizado diretamente pelo desenvolvedor.

Figura 02: Diretório criado para nosso exemplo

se o telefone tocar enquanto estivermos jogando, por exemplo.

Nossa classe é herdada da classe MIDlet, que possui três métodos abstratos que devemos implementar: startApp(), que é chamado quando nossa aplicação é iniciada, pauseApp(), chamado quando algum evento do dispositivo interrompe a execução do jogo, e destroyApp(), chamado quando a aplicação é encerrada. No nosso exemplo, iniciamos a lógica do jogo no método startApp e terminamos ele no método destroyApp. Por motivos de simplicidade iremos ignorar o método pauseApp. A próxima classe que iremos analisar é a GameCanvas. É ela que desenha o jogo na tela e que recebe a entrada do jogador. Além disso, o loop principal do jogo foi colocado nesta classe. A listagem 2 apresenta esta classe. Esta classe herda da classe Canvas, o que nos garante o funcionamento básico da renderização da tela. Uma das primeiras coisas que notamos nesta classe é a referência para um objeto da classe Image (o objeto background). MIDP suporta imagens no formato png e a maioria dos dispositivos suporta transparência nessas imagens. Todas as imagens do projeto foram colocadas na http://www.jogospro.com.br

O método “run”, logo abaixo do “paint” é o que executa o loop principal do jogo. Ele basicamente calcula o tempo certo de cada ciclo e chama o método “tick” para atualizar a lógica (falaremos da classe de lógica a seguir) e o método “repaint”, que pede para a máquina virtual redesenhar a tela (o que vai gerar uma chamada para o método paint citado acima).

Os dois últimos métodos desta classe são “keyPressed” e “keyReleased”. Como o nome diz, é através deles (que são herdados da classe Canvas) que a KVM nos informa sobre as teclas que foram pressionadas ou soltas, para que possamos tomar as devidas

providências. No caso, tudo o que fazemos é setar as flags relevantes da classe de lógica do jogo, que se encarregará de tratar os eventos na hora certa.

Antes de falarmos da classe de lógica do jogo, vamos ver uma pequena classe utilitária, chamada Sprite. Pelo próprio nome o leitor já deve imaginar do que se trata: uma classe com as informações e comportamento comuns a todos os objetos do jogo. A listagem 3 apresenta esta classe.

Para os desenvolvedores OO puristas, devemos uma explicação: por quê estamos usando atributos públicos, ao invés de encapsulálos e acessá-los apenas através de métodos de acesso, como mandam as boas práticas no desenvolvimento Orientado a Objetos?

A resposta se resume a uma palavra: performance.

Se seguirmos à risca os conceitos OO, corremos o grave risco de criarmos um jogo lento, de tal forma que tornaria a experiência do jogador um desastre. Este pode não ser o caso do nosso exemplo, pois ele é extremamente simples,

Listagem 1: JPongMIDlet.java

impor t javax.microedition.midlet.*; impor t javax.microedition.lcdui.*; public class JPongMIDlet extends MIDlet { private GameLogic logic; public JPongMIDlet() { logic = new GameLogic( this ); } public void star tApp() { logic.init(); } public void pauseApp() {}

}

public void destroyApp( boolean unconditional ) { logic = null; System.gc(); notifyDestroyed(); } NOVEMBRO 2004

JOGOSPRO e-magazine



Listagem 2: GameCanvas.java

import java.io.*; import javax.microedition.midlet.*; import javax.microedition.lcdui.*; public class GameCanvas extends Canvas implements Runnable { private GameLogic logic; private Image background; public static int screenWidth; public static int screenHeight; public boolean gameRunning; public GameCanvas( GameLogic logic ) { this.logic = logic; try { background = Image.createImage( “/background.png” ); } catch ( IOException e ) { e.printStackTrace(); } screenWidth = this.getWidth(); screenHeight = this.getHeight(); gameRunning = true; new Thread( this ).start(); } public void paint( Graphics g ) { g.drawImage( background, 0, 0, Graphics.TOP | Graphics.LEFT ); logic.playerPaddle.draw( g ); logic.devicePaddle.draw( g ); logic.ball.draw( g ); } public void run() { long lastTickTime = System.currentTimeMillis(); int currentTickTime = 0; while( gameRunning ) { currentTickTime += System.currentTimeMillis() - lastTickTime; while ( currentTickTime < GameLogic.BASE_TICK_TIME ) { try { Thread.sleep( 10 ); } catch ( InterruptedException e ) { } currentTickTime += System.currentTimeMillis() - lastTickTime; } lastTickTime = System.currentTimeMillis(); currentTickTime -= GameLogic.BASE_TICK_TIME;

}

}

logic.tick(); repaint();

Como pode ser visto, não há segredo nenhum no código. Temos um método “init”, que inicializa as variáveis do jogo, um método “tick”, que processa um ciclo do loop do jogo, e diversos métodos utilitários, para nos ajudar com a detecção de colisão e com a falsa inteligência do dispositivo.

Com o código pronto já podemos testar a aplicação. Para isso, clique em “Build” e em seguida em “Run”. A KToolBar irá lançar o emulador padrão e o leitor poderá ver nossa pequena obra em ação. Veja a figura 3 com o resultado esperado. É importante notar que este exemplo foi escrito e testado no emulador colorido padrão do WTK 1.04, que tem uma tela com 96x100 pixels de resolução. No caso de se executar este exemplo em algum outro emulador, o resultado por ser diferente do apresentado aqui, principalmente no que se refere ao tamanho da tela.

Outra observação importante é que o código aqui apresentado foi escrito com objetivo didático e não deve portanto ser tomado como regra. Com o conhecimento aqui adquirido, o leitor deve ser capaz de criar as suas próprias soluções para seus jogos.

Agora que já vimos nosso exemplo rodando, vamos entender um pouco mais do que acontece por trás dos panos. Em aplicações Java convencionais, tudo o que fazemos antes de poder executar o código é compilá-lo. Mas por causa disso, uma série de verificações é feita em tempo de execução para garantir o funcionamento e a segurança do sistema, e essas verificações são pesadas para dispositivos limitados como nossos celulares. Para evitar o uso desses escassos recursos, em J2ME a ordem das coisas é um pouco invertida: após compilar uma aplicação e antes de executá-la, temos um passo adicional: a pré-verificação.

public void keyReleased( int keyCode ) { int gameKey = getGameAction( keyCode ); switch ( gameKey ) { case Canvas.UP: logic.upPressed = false; break; case Canvas.DOWN: logic.downPressed = false; break; } }

http://www.jogospro.com.br

Vamos terminar nossa aplicação de demonstração com a classe central do projeto, a GameLogic. Veja o código na listagem 4.

Por Trás dos Panos

public void keyPressed( int keyCode ) { int gameKey = getGameAction( keyCode ); switch ( gameKey ) { case Canvas.UP: logic.upPressed = true; break; case Canvas.DOWN: logic.downPressed = true; break; } }

}

porém isso certamente seria um problema à medida que ele começasse a crescer.

Esse passo é essencial, pois prepara as classes compiladas para serem verificadas, o que resulta em um ótimo ganho de performance. O leitor NOVEMBRO 2004

JOGOSPRO e-magazine



deve estar se indagando então porque isso não foi apresentado antes e como conseguimos executar o exemplo? Simples, a KToolBar realiza essa pré-verificação automaticamente, poupando uma boa dose de esforço por nossa parte.

Listagem 3: Sprite.java import javax.microedition.lcdui.*; import javax.microedition.midlet.*;

public class Sprite { public int x; public int y; public int vx; public int vy; public Image image;

Além de preparar as classes para serem executadas, todos os MIDlets devem ter suas classes empacotadas em pares de arquivos jar/jad. O jar guarda a aplicação em si, incluindo todas as classes, arquivos de imagens e o que mais fizer parte dela, enquanto o segundo, descreve o que está empacotado no primeiro. Essa fase também é executada “às escondidas” pela KToolBar. Mas nesse caso temos a opção de gerar os arquivos manualmente, pois eles serão necessários quando formos distribuir o jogo. Para isso clique em “Project > Package > Create Package”.

Os arquivos serão gerados no diretório “apps/JPong/bin”.

public Sprite( int x, int y, int vx, int vy, Image image ) { this.x = x; this.y = y; this.vx = vx; this.vy = vy; this.image = image; } public void update() { x += vx; y += vy; } public void draw( Graphics g ) { g.drawImage( image, x, y, Graphics.TOP | Graphics.LEFT ); }

A Estrada Agora que o leitor já domina o básico do desenvolvimento de aplicações MIDP, algumas fontes serão muito úteis para aprofundar mais os conceitos. No final desta pagina estão listadas algumas fontes que podem vir a ser muito úteis.

public boolean collidedXAxis( Sprite sprite ) { if ( y <= sprite.y + sprite.image.getHeight() && sprite.y <= y + image.getHeight() ) {

} }

if ( ( x + image.getWidth() >= sprite.x && sprite.x >= x ) || ( x >= sprite.x && x <= sprite.x + sprite.image.getWidth() ) ) { return true; }

return false;

public boolean collidedYAxis( Sprite sprite ) { if ( x <= sprite.x + sprite.image.getWidth() && sprite.x <= x + image.getWidth() ) { if ( ( y + image.getHeight() >= sprite.y + sprite.image.getHeight() && sprite. y + sprite.image.getHeight() >= y ) || ( y < sprite.y && sprite.y + sprite.image. getHeight() > y + image.getHeight() ) ) { return true; } }

}

}

return false;

 http://www.forum.nokia.com/java Possui uma grande quantidade de tutoriais e ferramentas para auxiliar o desenvolvimento de aplicações MIDP, em especial para dispositivos Nokia

Figura 3: Emulador padrão do WTK rodando nosso exemplo http://www.jogospro.com.br

http://www.motocoder.com Página da motorolla para desenvolvedores de aplicações para seus dispositivos NOVEMBRO 2004

http://java.sun.com/j2me Página oficial da Sun com muitas informações sobre J2ME. O Wireless Toolkit  pode ser baixado deste endereço.

Paulo R C Siqueira É desenvolvedor Java, Programador Certificado pela Sun Microsystems e não entende como Final Fantasy Tactics Advance pode ser tão legal por tanto tempo...

JOGOSPRO e-magazine

import java.io.*; import javax.microedition.lcdui.*; import javax.microedition.midlet.*; public class GameLogic { public static final int BASE_TICK_TIME = 100; public static final int BASE_PADDLE_SPEED = 2; private JPongMIDlet midlet; private GameCanvas canvas; public Sprite playerPaddle; public Sprite devicePaddle; public Sprite ball; public boolean upPressed; public boolean downPressed;

Listagem 4: GameLogic.java Paddle ) ) { ball.vx = -ball.vx; ball.x += 1; // move a bolinha para evitar que ela “grude” na raquete } if ( ball.collidedYAxis( playerPaddle ) || ball.collidedYAxis( devicePaddle ) ) { ball.vy = -ball.vy; ball.y += -1; // move a bolinha para evitar que ela “grude” na raquete } if ( ball.y <= 0 ) { ball.vy = -ball.vy; ball.y = 0; } else if ( ball.y + ball.image.getHeight() >= GameCanvas. screenHeight ) { ball.vy = -ball.vy; ball.y = GameCanvas.screenHeight - ball.image.getHeight(); } }

public GameLogic( JPongMIDlet midlet ) { this.midlet = midlet; } public void init() { Image playerImage = null; Image deviceImage = null; Image ballImage = null; try { playerImage = Image.createImage( “/player.png” ); deviceImage = Image.createImage( “/device.png” ); ballImage = Image.createImage( “/ball.png” ); } catch ( IOException e ) { e.printStackTrace(); } playerPaddle = new Sprite( 5, 35, 0, 0, playerImage ); devicePaddle = new Sprite( 76, 35, 0, 0, deviceImage ); ball = new Sprite( 41, 35, 2, 1, ballImage ); Display display = Display.getDisplay( midlet ); canvas = new GameCanvas( this ); display.setCurrent( canvas ); }

private void checkPaddlesCollided() { if ( playerPaddle.y < 0 ) { playerPaddle.y = 0; } else if ( playerPaddle.y + playerPaddle.image.getHeight() > GameCanvas.screenHeight ) { playerPaddle.y = GameCanvas.screenHeight - playerPaddle. image.getHeight(); } if ( devicePaddle.y < 0 ) { devicePaddle.y = 0; } else if ( devicePaddle.y + devicePaddle.image.getHeight() > GameCanvas.screenHeight ) { devicePaddle.y = GameCanvas.screenHeight - devicePaddle. image.getHeight(); } }

public void tick() { if ( upPressed ) { playerPaddle.vy = -BASE_PADDLE_SPEED; } else if ( downPressed ) { playerPaddle.vy = BASE_PADDLE_SPEED; } else { playerPaddle.vy = 0; }

private void checkGameOver() { if ( ball.x < 0 || ball.x + ball.image.getWidth() > GameCanvas. screenWidth ) { canvas.gameRunning = false; midlet.destroyApp( true ); } } }

moveDevicePaddle();

Uma Pitada de Recursos Exclusivos

playerPaddle.update(); devicePaddle.update(); ball.update();

}

checkBallCollided(); checkPaddlesCollided(); checkGameOver();

private void moveDevicePaddle() { if ( ball.y < devicePaddle.y ) { devicePaddle.vy = -BASE_PADDLE_SPEED; } else if ( ball.y > devicePaddle.y + devicePaddle.image.getHeight() ) { devicePaddle.vy = BASE_PADDLE_SPEED; } } private void checkBallCollided() { if ( ball.collidedXAxis( playerPaddle ) || ball.collidedXAxis( devicehttp://www.jogospro.com.br

A dupla CLDC / MIDP nos disponibiliza uma grande quantidade de recursos para trabalharmos, porém muitas vezes eles podem não ser suficientes. Se quiser por exemplo tocar sons, essa dupla não nos dá escolha alguma. Nesse caso, temos que partir para as chamadas APIs proprietárias. Não é o nosso foco discutir essas APIs neste momento, mas é importante que o leitor saiba da existência das mesmas, pois certamente elas ainda serão necessárias.

A maior desvantagem de se utilizar APIs proprietárias é que ficamos “presos” ao dispositivo (ou família de dispositivos) em questão. Por exemplo, se utilizarmos as classes de som da Nokia, todo o nosso código que fizer uso dessas classes só funcionarão em dispositivos Nokia. Há, é claro, algumas maneiras de se contornar esse problema, mas isso já é assunto para uma outra edição.

NOVEMBRO 2004

JOGOSPRO e-magazine

Desenvolvimento de

CAP A

Jogos para Celulares

Um grande mercado para pequenos negócios

Esta edição de JogosPro e-Magazine está sendo um “prato cheio” para todos aqueles que, de alguma forma, estão com os olhos voltados para o desenvolvimento de jogos para “dispositivos móveis”.

Por Eliazer Kosckiuk e Julio Marchi Já era de se esperar que os celulares com capacidade para rodar aplicativos mais complexos -entre estes jogos- se popularizariam rapidamente, até porque tecnologicamente falando, além do momento ser mais propício do que nunca, há muito mais maturidade no mercado de entretenimento eletrônico hoje do que anos atrás!

J

á é comum ver pessoas divertindo-se com seus celulares na fila do banco, nos intervalos entre aulas, na fila do cinema, ou em qualquer outro lugar que se apresente oportuno. E isso não é coisa de “criança” não! Os celulares com poder para rodar jogos chegam em um momento bem oportuno, onde o “adulto” que os usa possui uma certa cultura de entretenimento digital.

Nos EUA, Europa e Japão por exemplo, a maioria das pessoas que estão na faixa entre os 30 e os 45 anos cresceram com os “videogames” ocupando boa parte de sua juventude, e esta realidade não é muito diferente no Brasil. A maioria destas pessoas acompanhou a evolução dos “telejogos”, passando pelos “Ataris” e “Odysseys” da vida, chegando aos MasterSystem’s, PlayStation’s e Xboxes atuais. Nesta caminhada muitos jogos fizeram história e deixaram saudosismo, tanto que a “onda” de emuladores de tudo que é tipo tem abarrotado a Internet nos últimos 5 anos, trazendo de volta à vida muitos dos jogos da época dos 8 bits (década de 80), e é esse também um dos fatores que vem colaborando para o reaquecimento do mercado de jogos em dispositivos móveis.

Mesmo sendo um mercado incipiente (em 2003 o mercado de jogos para celulares – incluído downloads de jogos e partidas online – rendeu somente cerca de US$ 250 milhões de receita ao redor do mundo), o ano de 2004 tem sido muito mais favorável, apresentando um crescimento significativo estimando-se que o ano termine com movimentos em torno dos US$ 1 milhão em negócios. E a previsão é ainda mais otimista para os próximos anos, estimando-se que os números

http://www.jogospro.com.br

facilmente ultrapassem o patamar de US$ 3,5 bilhões até o ano de 2007.

Nesse emergente mercado, todos tem a ganhar: para as operadoras representa uma parcela cada vez mais importante de trafego de dados (uso), gerando receitas também em novos níveis de negócios como na comercialização dos jogos e nas licenças de uso. Não se pode ignorar também que a popularização trará um aumento da clientela potencial, permitindo que os custos diminuam e que o mercado se expanda.

Para os usuários, além de uma melhoria geral no serviço (pois sem isso fica inviável o trafego Em países do primeiro mundo os jovens disputam com os adultos os momentos de lazer exigido pelos jogos), com os celulares (foto maior). Não é incomum encontrar grupos de jovens em torno de um simplesmente por ser aparato telefônico (foto menor, à direita), como também os jogos dos celulares já estão ocupando o espaços dos curtos momentos de ociosidade (foto menor, ao centro). um “produto a mais” isso tem dado nova vida ao aparato telefônico, proporcionando muitos bons Novas soluções para velhas limitações momentos de lazer a um custo relativamente No caso dos celulares e PDA’s (“mobiles” em baixo. Para os desenvolvedores tudo isso geral), atualmente não se podem criar jogos representa um potencial de negócios muito muito complexos, que requeiram complicados atraente, principalmente para os “pequenos” e efeitos 3D, músicas de alta qualidade e efeitos “iniciantes”, que podem competir neste mercado sonoros ambientais. Os jogos para estes onde investimento não é tão abrasivo como no dispositivos ainda tem que ser compactos de jogos convencionais, mercado este que nem (em muitos caso no máximo 50 a 60Kb), e por por isso é menos lucrativo. isso necessitam ser simples e criativos. Estas NOVEMBRO 2004

JOGOSPRO e-magazine

caracterísiticas diferenciam em muito esse mercado do de jogos eletrônicos tradicionais, mas abrem margem para projetos menos ambiciosos, de curto tempo de produção e baixo investimento.

Não fazem 20 anos que empresas como Konami, Atari, Taito (esta última, a qual já descobriu o mercado de celulares), e tantas outras construíram as bases de suas fortunas através dos jogos para as plataformas de 8 bits, cujas características eram bem similares (ou até mais simplórias) às dos celulares atuais. Ciclicamente, hoje vemos este mesmo potencial de lucratividade emergindo para projetos de jogos com características similares aos de 20 anos atrás, só que mais num mercado mais maduro e efetivamente mais amplo.

As boas notícias para os pequenos desenvolvedores é que, por mais que as características de um celular se assemelhem às dos computadores antigos (pouca resolução, limitados recursos sonoros, pouco espaço de memória, processamento limitado de recursos, etc.), as semelhanças param por aí. Hoje basicamente se desenvolve para celulares em linguagens de “alto nível” (C++, Java, Brew, etc), enquando na década de 80 se desenvolviam os jogos em Assembly (Linguagem de Máquina), o que praticamente anula a portabilidade dos mesmos (mas não impede sua “reprogramação”).

E é por isso que dizemos que são “boas notícias”, pois as empresas que fizeram sucesso 20 anos atrás ainda não tomaram posse deste mercado em função disso. Basicamente para relançar um clássico tem-se que reprogramá-lo do zero.

Como estas empresas, em sua maioria, estão hoje concentradas nos “grandes jogos” (PC, XBox, PlaysStation, GameCube, etc), isso vem deixando o caminho aberto para pequenas e médias equipes de desenvolvimento. Então, o que você está esperando? Mãos à obra!

Novamente abre-se espaço para os “escovadores de bits”, tão comuns na época dos micros de 8 bits e praticamente “extintos” atualmente.

Da mesma forma como cada byte do código era tratado com carinho anos atrás, hoje a habilidade de se produzir diminutos programas volta a estar em evidência. Novamente entram em moda termos como scroll parallax (técnica onde a ilusão de tridimensionalidade é criada colocando-se camadas gráficas umas sobre as outras), movintação de sprites, músicas em formato track, filmation, etc... Ao programar para os celulares esqueça das músicas em mp3, dos vídeos comprimidos e de outras soluções rápidas, tão em voga na produção de jogos atualmente, pois apesar de estas tecnologias estarem emergido rapidamente para os celulares, ainda demorarão algum tempo para que possam ser suportadas pelas atuais redes de comunicação, além do fato de que seu custo no http://www.jogospro.com.br

princípio –como qualquer tecnologia nova-não será atraente para o consumidor final . Por agora é hora de voltar a pensar nas antigas (e eficientes) técnicas de desenvolvimento!

Ainda sim, por mais que as plataformas de desenvolvimento disponibilizem muitas novas tecnologias (como OOP, modularidade, engines, etc), os problemas enfrentados pelos programadores são antigos, e profissionais experimentados em tecnologias de 20 anos atrás encontrarão um favorável cenário para desencavar velhos truques e técnicas de programação que foram muito necessários naquela época, e que são quase esquecidos (ou praticamente desconhecidos) pelos programadores da “nova geração”.

Modelo de negócios Aqui está um ponto a ser bem analizado antes de começar. Diferente do mercado de jogos convencionais, não basta que você desenvolva seu jogo para Celulares e o coloque pra vender nas prateleiras porque não é assim que este mercado funciona (pelo menos não ainda).

Os jogos em números • Mais de US$ 250 milhões de receita obtida no mercado mundial em 2003 e estima-se que mais de US$ 1 bilhão serão alcançados até o final de 2004.

• Estimativa de que US$ 3,5 bilhões sejam gerados até 2007.

• Custo dos jogos: Entre US$ 2 e US$ 5 (valor médio cobrado pelo download de um jogo nos EUA e na Europa) • Mais de mil downloads por mês, em média, por jogo, em operadoras nos EUA e Europa.

Fontes: ARC Group e LocZ

As empresas aprendeream com os anos que dá pra ganhar dinheiro estando entre o cliente e o desenvolvedor. Não muito diferentemente de como as licenças para os jogos de Consoles funcionam, para Celulares vc terá que de alguma forma “encontrar” o canal de divulgação e comercialização do seu jogo através das operadoras e/ou fabricantes, e antes de programar você terá que pensar em muitas coisas: na plataforma de desenvolvimento, do celular “alvo”, na companhia de serviço móvel, na tecnologia necessária, etc.

Existem diversos modelos de negócios existentes.

Nos EUA por exemplo, o mais comum hoje é a operadora oferecer os jogos pelo próprio celular e cobrar pelo download na conta mensal (algo entre $2 e $5 por jogo, ou por período, dependendo do caso). A receita é “partilhada” entre a operadora e os desenvolvedores segundo um acordo previamente firmado entre eles, o qual não é padronizado e é revisto caso-a-caso.

Entretanto, já existem diversos portais independentes, e estão surgindo rapidamente NOVEMBRO 2004

outros, alguns patrocinados por grupos de fabricantes, onde se pode baixar jogos gratuitos ou comprá-los direto dos fabricantes. E com a iminente evolução dos browsers dos celulares, o acesso a conteúdos “diretamente” pelo cliente, sem depender da operadora, é algo inevitável.

Se existe um bom momento para investir neste mercado o momento é agora! Além de jogos, o desenvolvimento de aplicativos também tornase emergente, e as empresas que mantiverem um nome respeitável neste mercado poderão estabeler lucrativas parcerias com empresas de vários países (pois, independente de ser Celular, o conteúdo é trafegado via Internet, o que literalmente globaliza a coisa).

Características do Desenvolvimento para Celulares Atualmente todas as plataformas de desenvolvimento trabalham com linguagens Orientadas a Objeto (como o Java, C++, e outras). Isso significa que, para criar o famoso “Hello Word” na telinha do Celular você terá que se envolver com uma dezena de classes e uma boa quantidade de linhas de código. Se, por um lado, isso dificulta o início, por outro lado garante a manutenção e extensibilidade do código. Como exemplificamos anteriormente, muitos títulos (milhares) que foram sucesso na década de 80 nos computadores de 8 bit, os quais poderiam ser adaptados facilmente às características dos Celulares, não são portáveis porque foram escritos em Assembly, e são diretamente dependentes dos recursos do harware dos computadores para que foram criados. Mesmo a portabilidade de um jogo, de um computador para outro da mesma época, é coisa bem complicada (chamamos isso de Remakes). Sendo assim, usar as linguages de “alto nível” garante de que seu produto não se perderá com o tempo (pelo menos não totalmente).

Outra “novidade” dos dias atuais é o Open Source, o que lhe permite aprender técnicas e truques que com certeza poderão reduzir mais ainda o tempo de desenvolvimento de seu projeto.

Portanto, compartilhe seus códigos sempre que possível! Procure não reinventar a roda e, ao mesmo tempo, saiba que não adianta querer guardar a sete chaves aquela sua rotina “especial” porque este tempo já passou. Atualmente é muito mais produtivo estabelecer uma relação de colaboração e troca de informações com outros desenvolvedores para poupar tempo e dinheiro no processo criativo do que sonegar informações com medo da concorrência.

Desenvolver jogos para Celulares tem seus “calcanhares de Aquíles” também. Um deles é definir QUAL ambiente de desenvolvimento você irá usar. Cada modelo de celular possui características diferentes! Resolução de tela, JOGOSPRO e-magazine

número de cores, tamanho de memória, projetado para ser um videogame e não deve ser capacidade de interação, sons, etc... Felizmente a programado como se fosse um. indústria tem aprendido com os erros do passado e está mais madura, levando os fabricantes a Analisemos, por exemplo, a usabilidade: implementar em seus aparelhos características videogames foram criados simplesmente para similares e seguindo uma certa “padronização” o entretenimento, e quando nos dirigimos à entre elas. Por exemplo, a Nokia divide seus eles, estes são usados somente para isso e por aparelhos em Séries como 30, 40, 60 e 80. um período de tempo contínuo normalmente Dentro de cada série, as características principais não muito longo (humm, err... digamos que... são semelhantes. Outros fabricantes usam a na maioria das vezes! ;o). Comparando com o mesma idéia, e alguns até usam-se de tabelas de Celular, que tem uma função primária diferente, comparação entre modelos de outros fabricantes. os momentos de entretenimento são mais E aqui vem uma outra dica importante: quando curtos e irregulares (geralmente enquanto for desenvolver o seu aguarda-se em algum jogo, defina para qual consultório, numa “ E aqui vem uma dica importante: palestra “empolgante” aparelho/série você o vai programar. Não ou durante quando for desenvolver: tente desenvolver um aquela viagem game que vá funcionar interminável). Não concentre-se no que um jogo tem obstante também em todos os aparelhos, mas defina SIM um está o fato de que que ter de melhor: público-alvo para o os “teclados” dos seu game, e explore celulares atuais não a capacidade de entretenimento!” foram projetados todas as capacidades para atender às desta plataforma, de necessidades dos maneira a oferecer uma jogos. Além de experiência estimulante não serem nada resistentes, não possuem e agradável para o seu consumidor. Assim, será mais fácil alcançar o sucesso, e sempre resta a sequer uma ergonomia adequada para se possibilidade de portar o seu game para outras jogar. Isso sem falar que a grande maioria não plataformas caso o mercado apresente este reconhece o apertar simultâneo de duas teclas interesse (vise o resultado e não a ideologia). ou não possuem respósta rápida o suficiente, o que inviabiliza aqueles jogos de ação em Bem, se depois de tantas informações que precisamos nos mover e atirar ao mesmo tempo; ou aquele jogo de luta com as famosas controversas você ainda não desanimou, então combinações de teclas para os golpes superé provável que você possa sim encarar este hiper-ultra potentes (os famosos fatalities). desafio! Sigamos então em frente desbravando “superficialmente” as tecnologias mais importantes que são usadas na criação de jogos E, coroando essa combinação de diferenças, para celulares nos dias de hoje. temos a tela: relativamente minúscula, de cristal líquido, com baixa definição e que, para As Plataformas de Desenvolvimento piorar, muitas vezes é monocromática ou possui As principais plataformas usadas para a limitação de quantidade cores simultâneas. criação de jogos e aplicativos para celulares são: Java2ME, Brew, Mophun e Symbian OS. A Se somarmos tudo isso ao fato de que o jogador geralmente estará em um ambiente com muitos maioria destas tecnologias são dissecadas mais profundamente em artigos de diferentes autores outros estímulos, podemos ter uma idéia da dificuldade que haverá em envolver o usuário na nesta mesma edição de JogosPro e-Magazine, oferecendo para você leitor informações mais trama de um jogo... precisas em cada uma delas dentro de seu escopo de atuação. Neste artigo apresentaremos Sendo assim, se você quer programar jogos apenas um apanhado geral de cada tecnologia, para celulares e quer que seu jogo seja um de forma mais comparativa, para você possa sucesso, você necessitam observar alguns ter uma base na hora de escolher a que melhor fatores importantes antes de iniciar qualquer atende às suas necessidades/idéias. projeto (isso pelo menos nos próximos dois anos.

Depois disso, pelo andar da carruagem, as novas tencologias já terão superado estas “limitações”): Mas, antes de entramos no tema das diferentes plataformas de desenvolvimento, é importante  O jogo tem que ser simples e envolvente. apresentar alguns aspectos que são comuns a todas elas. Comecemos por uma das maiores Os jogos de estratégia, raciocínio e labirinto dificuldades na programação de jogos para (2D) são geralmente uma boa pedida. celulares: assimilar a idéia de que um celular é Alguns shot’n’up podem ser bem sucedidos um... CELULAR! Não é um videogame; não foi também; http://www.jogospro.com.br

NOVEMBRO 2004

Não deve haver necessidade de muito

“controle motor” por parte dos jogadores, porque o celular não vai ajudar nisso (teclado ineficiente, tela ineficiente, processamento ineficiente etc);

Quando possível, deve-se “evitar” os jogos com muita dependência de efeitos sonoros (devido aos ambientes onde normalmente se joga);

Busque investir seu tempo em projetos que

permitem um desenvolvimento dinâmico e rápido. Não perca 20 MESES trabalhando num jogo para Celulares porque é bem provável que no final deste período seu jogo já nasça obsoleto;

Muitos celulares não vão permitir que o

jogo seja “interrompido” durante uma chamada telefônica, de forma que este possa ser “retornado” após o término da mesma. Isso pode levar alguns jogos ao fracasso (ninguém quer jogar as fases 1, 2 e 3 novamente toda vez que for iniciar uma nova partida). Isso tem muito haver com o modelo de celular e com o ambiente de desenvolvimento selecionado!

Desenhos muito detalhados em telas muito

pequenas podem ser de difícil identificação para muitos usuários. Tenha muita atenção para não confundir excesso de elementos gráficos com qualidade visual porque o resultado pode ser o inverso do esperado.

E lembre-se: pense competitivamente, muita atenção na hora de decidir qual “Plataforma de desenvolvimento” será usada e para qual modelo de celulares vc vai desenvolver. Existem muitas variáveis envolvidas nestas decisões e o apaixonismo pelo desenvolvimento de jogos não pode cegar você nesta hora tão importante. Quer uma dica? Tire do armário aquele video-game antigo; baixe alguns emuladores da Internet, jogue alguns jogos da década de 80 e ponha atenção em como eles eram tão envolventes com tão poucos recursos de hardware disponíveis.

Desintoxique sua cabeça dos fantásticos avanços tecnológicos que você tem à disposição hoje e concentre-se no que um jogo tem que ter de melhor: a capacidade de entretenimento!

Obviamente que depois de ler esta revista toda você terá uma definição bem clara de que caminhos vai tomar, mas não esqueça de, mesmo assim, testar e se informar antes de decidir!

Com isso em mente, analise bem as tecnologias que estão à disposição, teste-as todas, e esteja de olho aberto para as novidades. Atualmente os ambientes de desenvolvimento mais difundidos voltados à programação de jogos em celulares são: JOGOSPRO e-magazine

Java2ME

BREW

Conhecido também como J2ME, ou Java 2 Micro Edition, é a versão de Java da Sun destinada a dispositivos com recursos limitados de hardware, tais como PDAs, Smartphones e Telefones Celulares, entre outros. No artigo de Paulo R.C. Siqueira (na página 10 desta mesma edição) você poderá encontrar exemplos de como se desenvolve em J2ME e mais detalhes técnicos sobre este ambiente.

Devido às diferentes limitações de tais aparelhos, a SUN apresentou uma solução simples e uniforme: a Máquina Virtual do J2ME, que foi criada como um subconjunto das Máquinas Virtuais utilizadas pelas versões “maiores” do Java: J2SE (Java Standard Edition) e J2EE (Java Enterprise Edition), mantendo assim certa compatibilidade de linguagem (mas não de recursos).

Acrônimo de Binary Runtime Enviroment for Wireless, algo como Ambiente de Execução Binária para Dispositivos Móveis foi criado pela Qualcomm para ser uma completa plataforma de desenvolvimento e distribuição de aplicações principalmente voltada aos celulares. O BREW tem como principal característica ser extremamente pequeno e eficiente, o que possibilita ser incluso em aparelhos com pouquíssimo poder de processamento, oferecendo uma plataforma aberta e expansível para o desenvolvimento de aplicações. O BREW também foi desenvolvido enfocando diretamente as limitações que essas máquinas possuem, e por isso foi otimizada ao máximo. Mesmo assim, não é menos poderosa que seus “concorrentes irmãos”, podendo até chegar a rodar aplicações nativas (em C/C++) como engines 3D, máquinas virtuais Java e muito mais, tendo excelente performance geral.

Por este motivo, e por trazer o nome Sun por detrás, esta tem sido a plataforma escolhida por uma grande quantidade de desenvolvedores de jogos para celulares, principalmente pela prévia experiência com o J2SE que as equipes de desenvolvimento já possuíam, exigindo um mínimo de adaptação e investimento. Além disso, soma-se também o fato de muitas das ferramentas existentes serem grátis.

No artigo BREW Primeiros Passos, por Matías Rodriguez (também nesta edição de JogosPro e-Magazine), você poderá ter uma boa noção do que o BREW é capaz de oferecer. Como já dissemos, além de aplicações nativas, desenvolvidas em C/C++, BREW pode alternativamente incluir suporte a execução de Java e parsers de xml e flash, por exemplo, o que possibilita uma gama ainda maior de opções para o desenvolvimento de aplicações neste ambiente.

Entretanto, isso não significa que o J2ME seja a melhor e mais adequada opção para seu projeto. A vantágem intrínsica nesta tecnologia é que praticamente todos os fabricantes contam com aparelhos compatíveis com ela, e algumas das operadoras brasileiras tem optado por dar suporte total a essa plataforma (como Claro, Oi e Tim).

Entretanto, o BREW não pode ser comparado ao Java (até porque você pode criar um ambiente Java rodando em BREW), nem tampouco a um sistema operacional completo como o Symbian. Cada um tem seu espaço diferente neste universo, usando-se de idéias/implementações distintas. Por ser o mais simples em se tratando de implementação, o BREW ganhou muito espaço nos telefones com pouca capacidade tecnológica, que eram incapazes de rodar sistemas operacionais completos como Symbian por exemplo.

No site de Jason Lam (http://www.jasonlam604.com) você poderá encontrar para download o livro “J2ME & Gaming Book”, que está sendo escrito em esquema “Open Source”, além de excelentes artigos ligados ao tema, diversos links para SDKs (System Development Kits) e algumas engines bem interessantes.

Symbian Symbian OS é um avançado sistema operacional multitarefa atualmente licenciado pelas maiores empresas de telefonia móvel do mundo. Foi projetado pensando nas restrições dos aparelhos móveis, visando suprir os requerimentos específicos dos modernos celulares 2G, 2.5G e 3G. O Symbian OS, entre inúmeras características, tem como ponto forte:

 Uso mínimo de memória  Eficiente gerenciador de energia  Suporte em tempo real para telefonia e transferência de dados Para o programador o Symbian OS fornece um completo e aberto framework de desenvolvimento, utilizando a linguagem C++, o que possibilita que o programador crie aplicativos que tirem proveito dos recursos específicos de cada aparelho, como câmera, comunicação de dados, etc.

Daniel “NeoStrider” Monteiro demonstra de maneira bastante sucinta e efetiva um pouco do que o Symbian é capaz em seu artigo Introdução a programação em Symbian OS Nokia Series 60 em C++ nesta mesma edição, na página 36.

Existe ainda um riquíssimo conjunto de informações sobre o Symbian Os 7.0 em http://www.symbian.com/technology/symbos-v7x-det.html http://www.jogospro.com.br

Entretanto, como tudo tem um preço, desenvolver para a plataforma BREW pode ser um pouco mais oneroso do que em relação às outras soluções.

Apesar do SDK ser gratuito, você precisa ser um desenvolvedor cadastrado pra ter acesso ao telefones para testes (que carregam as aplicações BREW sem autenticação, similar a como funciona programar para XBox e PlayStation).

No mais, uma vez concluído o seu projeto o programa final necessita ser autenticado pela própria Qualcomm (TRUE BREW), o que pode chegar a custar alguns “miles de dólares” extras em contratos e licenciamento.

Para saber mais sobre BREW e seu sistema de distribuição visite http://brew. qualcomm.com/brew/en/developer/resources/gs/brew_solution.html

Mophun O padrão Mophun, desenvolvido pela sueca Synergenix, que foi o adotado como padrão pelos celulares Sony Ericson (e também é suportado por alguns modelos de telefones da Siemens e de outras marcas “menores”) vem “correndo por fora” para tentar atrair a atenção dos desenvolvedores de jogos para celulares.

O Mophun possui a vantagem de ser um padrão aberto (grátis para o desenvolvedor) e seus programas costumam ficar bem compactos, ocupando a metade da memória de um similar em Java e um terço do ocupado por um similar em Brew, o que tem levado muitas empresas a voltar seus olhos para o Mophun (pois acelera o download dos jogos).

Para completar a Synergenix comprou os direitos de uso de vários jogos do Atari, que fizeram sucesso no começo da década de 80, e pretende usar-se deste universo para atrair a atenção para as potencialidade de seu ambiente.

Mais informações em www.mophun.com.

NOVEMBRO 2004

JOGOSPRO e-magazine

Outras Tecnologias Existem diversas outras “plataformas de desenvolvimento” para celulares surgido, bem como as baseadas em “recursos de Internet” (HTML e XML) que chegaram a ser cogitadas como possíveis ambientes para criação de jogos, mas isso era quando os celulares não suportavam gráficos e processamentos “mais elaborados” como hoje (parece que estamos falando de muito anos atrás, mas a verdade é que não tem muito mais que um ano isso).

assinado por ele (nesta mesma edição, não deixe de ler). Mais informações podem ser obtidas em http://www.khronos.org.

especializadas estão investindo em duas ou três soluções simultâneas, buscando além de tudo estar presente em diferentes mercados, e nós aconselhamos que você faça o mesmo sempre que possível!

O 3GPP (QuickTime and Mobile Multimedia) vem em “linha E como obviamente uma determinada tecnologia paralela” ao OpenGL-SE, somando esforços para ampliar pode atender a um determindao grupo de o potencial dos celulares. O necessidades melhor que outra, isso também tem que ser levado em consideração na hora de decidir.

QuickTime é uma solução da Apple que, no que se refere a áudio e vídeo, é difundida em praticamente Para completar a relação “custo de produção” e todos os ambientes computacionais existentes Algumas destas tecnologias ainda estão em (Mac, Windows, SunSparc Stations, Silicon Graphics, “investimento prévio” não pode ficar de fora de desenvolvimento, como o WAP (Wireless Application etc.), e seguramente não será diferente no caso dos suas analises, bem como potencial de mercado Protocol), o SMS (Short Message Service), o celulares. Segundo diz a Apple, o 3GPP será capaz de e a diferença no tempo de desenvolvimento MMS (Multi Media SMS message), o HAWHAW usar todas as vantagens novos recursos multimidia que cada ambiente impetra. Leve tudo em (HTML and WML Hybrid Adapted Webserver), o dos celulares e já deverá vir integrada nos celulares consideração, mas não deixe passar esta onda sem pegar uma carona nela, pois fazem muito WURLF (Wireless Universal Resource File) e muitas de terceira geração (3G). Atualmente nos EUA as outras... Só que jogos desenvolvidos usando estas duas maiores empresas de comunicação móvel, anos que não se abrem possibilidades de plataformas enfocavam principalmente os do tipo Verizon e Sprint, já estão implementando em suas negócios tão factíveis como as apresentadas pelo Trivia e outros baseados textos, com pouca ou redes as especificações necessárias para dar suporte mercado de Jogos para Celulares (facilmente expansíveis para PDA’s, Palm’s, GPS’s etc). nenhuma necessidade gráfica. a esta tecnologia. Mais informações em http:// www.apple.com/mpeg4/3gpp.

E não deixe de ler os artigos Animação Atualmente, com o avanço tecnológico baratendo Conclusão Baseada em Tempo e Criatividade nos Jogos rapidamente a implementação de modernas Muitas novidades... Muitas siglas... Muitas nesta mesma edição (de Paulo V. W. Radtke e tecnologias nos celulares, estas linguagem estão tecnologias... Muita informação... E pouco tempo Fabrício Kolk Carvalho respectivamente), pois praticamente obsoletas para o mercado de jogos em suas essências também estão diretamente (mesmo antes de amadurecerem como ambiente para se divertir com tudo isso! Estamos vivendo novamente o monento de rápidos avanços (cada vez correlacionados com o tema em questão!  de programação, pois esse é o custo do rápido avanço tencológico que vivemos nesta nova era mais dinâmicos) no mundo da tecnologia, e desde digital), tendo seu enfoque hoje mais voltado para os computadores à HDTV, passando pelo Rádio Eliazer Kosciuk Digital via Satélite, Telefonia Móvel com recursos a área de navegação em Internet. É Engenheiro Agrônomo, especializado em computação Multimidia, GPS’s portáteis, e até novos conceitos e pesquisas na área de tecnologia desde a época dos computadores 8 bits (em especial o MSX).

Ainda assim, dentre tantas siglas e novidades que de dinâmica de combustíveis automobilísticos, tudo Além de desenvolvedor de games e aplicativos vem sendo afetado de alguma forma pelo “correvem surgindo dia-a-dia no mundo dos celulares, para celulares, atua também como web designer e corre” das inovações. duas delas não podem passar despercebidas: webmaster para sua empresa Idea Plus.

OpenGL-ES e 3GPP. Ambas prometem animar Não é fácil estar “up-to-date” com tudo isso e ainda bastante a telinha do seu próximo Celular e vão Julio Marchi É Analista de Sistemas especializado em engenharia de dar mais gás ainda no desenvolvimento dos jogos. ser produtivo, mas em contrapartida existem software, networking, multimídia e Internet. também muitos mais recursos de informação, Atualmente é CEO de duas empresas nos EUA e igualmente dinâmicos, que auxiliam o acompanhar desenvolve diversos projetos técnicos e audio-visuais da “onda tencologica” que estamos vivendo, para o mercado Norte Americano. e com isso abrem-se novas possibilidades de Nota: Eliazer e Julio vem desenvolvendo diversos projetos e negócios para os pequenos e médios empresários/ parcerias de sucesso entre suas empresas, no Brasil e nos EUA desenvolvedores, e num mercado já globalizado (respectivamente). Atualmente planejam dar seus primeiros passos O OpenGL-ES - como o próprio nome diz graças à ajuda da Internet. no mercado de desenvolvimento Games para Mobile Devices.

- é voltado à aplicações (jogos) que necessitem complexos elementos 2D/3D. Por ser grátis e Em se tratando Links relacionados ao tema multiplataforma, assim como seus antecessores do tema para as grandes estações gráficas e computadores Desenvolvimento de Sun One Studio ME .................. http://wwws.sun.com/software/sundev/jde/ convencionais, este deverá estabelecer-se com Jogos para Celulares, Portal Java .............................. http://www.portaljava.com/ Portal JavaFree ........................ http://www.javafree.com.br/ padrão indiscutível no mercado dos celulares, a verdade é que Tutoriais diversos sobre Java ... http://wireless.java.sun.com/ isso à medida em que os aparatos vão ganhando não existe melhor Gel .......................................... http://www.gexpert.com mais recursos e poder de processamento. Outra maneira de um Forum Nokia............................ http://forum.nokia.com/ vantágem é que o enfoque do OpenGL-ES está em programador decidir JBuilder com Mobile Set .......... http://www.borland.com/ um nível mais baixo em relação aos ambientes qual será o ambiente White Board SDK ..................... http://www.zucotto.com/ Code-Blood ............................. http://www.code-blood.com.br/portal/publico/index.jsp de desenvolvimento, possibilitando oferecer para de desenvolvimento Mais sobre OpenGL-ES............. http://ogl-es.sourceforge.net/index.htm estes um conjunto de API’s de baixo nível para mais adequado Bluetooth SDK ........................ http://www.zucotto.com criação de objetos em Real-3D. para seus projetos Bluetooth SDK ........................ http://www.rococosoft.com que não seja Bluetooth SDK ........................ http://www.bluetooth.com Ninguém melhor que o Bruce “Sinner” para ir testando-os. Mas, Bluetooth SDK ........................ http://www.smartnd.com Multiplayer Engines ................ http://www.xadra.com à fundo neste tema, e é por isso que o artigo tenha em mente Multiplayer Engines ................ http://www.demivision.com dedidado a explorar esta novíssima tecnologia é que as empresas http://www.jogospro.com.br

Multiplayer Engines ................ http://www.terraplay.com Multiplayer Engines ................ http://www.butterfly.net JOGOSPRO e-magazine

NOVEMBRO 2004

por Paulo V. W. Radtke

ARTIGO

Animação Baseada em Tempo Nos “velhos tempos” as animações dos jogos eram controladas utilizando o retraço vertical do vídeo e o número máximo de atualizações por segundo, que era fixo em todos os hardwares. Nos sistemas atuais, nem sempre é possível fazer isto e, mesmo quando isso acontece, não sabemos qual a taxa de atualização configurada pelo usuário. Este artigo apresenta uma técnica simples que pode ser aplicada facilmente em lógica de animações 2D e 3D para controlar elementos na tela.

Um exemplo simples em SDL ilustra a técnica discutida.

T

odo objeto animado percorre na tela uma certa distância – seja ela em distância linear ou angular.

Na física a velocidade na qual um objeto se desloca é calculada pela equação v=d/t , aonde d é a distância percorrida pelo objeto entre dois pontos – A e B, t é o tempo utilizado e v é a velocidade resultante. Supondo um exemplo no espaço 2D, se um objeto percorre 100 pixels a cada segundo, temos uma velocidade v=100.

Não sabemos a quantos quadros por segundo o nosso jogo rodará, mas temos como medir o tempo passado entre o quadro anterior e o quadro atual. Com esta informação e a velocidade, podemos calcular o deslocamento do objeto utilizando a equação d=v x t . Se no nosso exemplo tivessem passados 0.1 segundos, o deslocamento do objeto seria d=100 x 0,1=10pixels.

Código exemplo Vamos analisar um exemplo em código que demonstre o efeito.

Por simplicidade, o exemplo em C http://www.jogospro.com.br

usa SDL e pode ser compilado sem problemas em todas as plataformas que aceitem a SDL. O código base é como mostrado na listagem inicial (inicial.cpp), a função main carrega uma imagem bitmap e invoca a função demo para fazer com que a imagem atravesse a tela na horizontal de um lado a outro. Você

programa no meio), mas isola bem na função demo a animação da imagem e evita o uso de buffer duplo que poderia ativar a espera pelo retraço vertical. Mais tarde discutiremos porquê utilizamos uma variável double para a posição x da imagem mesmo quando os pixels são sempre valores inteiros.

pode descarregar os códigos fontes e o arquivo da imagem utilizado, porém qualquer arquivo BMP pequeno (razoavelmente menor que 640x480 de preferência) serve para testar o código.

O problema desse exemplo é que num jogo real o processamento requerido para desenhar um quadro pode variar de acordo com o número de objetos desenhados na tela, overhead da lógica de inteligência artificial e até mesmo programas que estejam rodando em background no sistema. Em jogos que controlam a animação pelo retraço vertical isso gera os conhecidos slow downs.

Experimente colocar no início da repetição do while o código

A cada vez que a tela é atualizada a imagem é desenhada um ponto à direita em relação à posição anterior, até que ela saia da tela.

Esse código não é um primor da programação organizada (nem mesmo permite interromper o NOVEMBRO 2004

JOGOSPRO e-magazine

ARTIGO tem uma largura (distância entre os extremos opostos) de 640 pontos e usando a equação da velocidade mostrada anteriormente, calculamos a velocidade como 320 pixels/ segundo, ou seja, esperamos que a cada segundo passado a imagem desloque-se 320 pontos.

Listagem 1: Código exemplo #include <stdlib.h> #include <SDL.h> SDL_Surface *imagem, *tela; // Ponteiro para o bitmap void demo(); void demo() { SDL_Rect destino; double x=0; // Preencha a parte fixa do rect destino.y = (480-imagem->h)/2; destino.w = imagem->w; destino.h = imagem->h;

}

while(x<640) { // Limpa a tela SDL_FillRect(tela, NULL, SDL_MapRGB(tela->format, 255, 255, 255)); // Em que posicao x desenha a imagem destino.x = (int)x++; SDL_BlitSurface(imagem, NULL, tela, &destino); SDL_UpdateRect(tela, 0, 0, 0, 0); }

int main(int argc, char *argv[]) { // Inicializa a SDL if ( SDL_Init(SDL_INIT_AUDIO|SDL_INIT_VIDEO) < 0 ) { fprintf(stderr, “Unable to init SDL: %s\n”, SDL_GetError()); exit(1); } atexit(SDL_Quit); tela = SDL_SetVideoMode(640, 480, 32, SDL_SWSURFACE); if ( tela == NULL ) { fprintf(stderr, “Falhou inicializacao do video: %s\n”, SDL_GetError()); exit(1); } // Carrega um bitmap (global) imagem = SDL_LoadBMP(“imagem.bmp”); if ( imagem == NULL ) { fprintf(stderr, “Nao achei o arquivo %s: %s\n”, “imagem.bmp”, SDL_GetError()); exit(1); }

}

demo(); // Apaga o bitmap SDL_FreeSurface(imagem); exit(0);

Animação Baseada em Tempo

http://www.jogospro.com.br

Se utilizarmos uma lógica adequada com duas variáveis, podemos determinar quantos milisegundos se passaram entre o início do quadro atual e o anterior utilizando estes valores. Esse valor dividido por 1000 é o intervalo de tempo passado em segundos entre os dois quadros, que multiplicado pela velocidade nos dá o deslocamento da imagem em relação ao quadro anterior.

A listagem temporizado.cpp mostra o código que anima a imagem adequadamente. Criamos três variáveis novas, atual, anterior e tempo, que armazenam respectivamente o número de ticks no início do quadro anterior, no quadro atual e o tempo em milisegundos entre os quadros. A inicialização da variável anterior é

Listagem 1: temporizado.cpp

SDL_Delay(20); para simular um processamento mais lento e veja que o objeto leva mais tempo para atravessar a tela.

O exemplo inicial desloca a imagem um pixel para a direita a cada atualização, porém sabemos que como medida de velocidade isto é ineficiente. Precisamos relacionar a animação ao tempo. Vamos supor que a imagem deva atravessar a tela em 2 segundos. Sabendo que a tela

A SDL, como outras bibliotecas multimídia, disponibiliza a função SDL_GetTicks() que retorna a quantidade de milisegundos passados entre a inicialização do sistema e o momento da execução da função, o número de ticks. Se esta função for chamada a cada atualização de tela, sabemos quantos milisegundos se passaram da inicialização do sistema até o início daquele quadro.

} ...

...

Uint32 anterior, atual; // Tempo anterior anterior=SDL_GetTicks(); while(x<640) { // Tempo atual atual=SDL_GetTicks(); // Qual o tempo passado Uint32 tempo=atual-anterior; // Limpa a tela SDL_FillRect(tela, NULL, SDL_MapRGB(tela->format, 255, 255, 255)); // Em que posicao x desenha a imagem x += (double)(tempo)*320.0/1000.0; // Na próxima iteração, o tempo atual passa a ser o anterior anterior=atual; SDL_BlitSurface(imagem, NULL, tela, &destino); SDL_UpdateRect(tela, 0, 0, 0, 0);

NOVEMBRO 2004

JOGOSPRO e-magazine

ARTIGO Listagem 1: temporizado_melhor.cpp ... // Tempo atual atual=SDL_GetTicks(); // Qual o tempo passado Uint32 tempo=atual-anterior; // Verifica se passou o tempo mínimo necessário if(tempo<10) continue; ... feita com os ticks imediatamente antes de começar a animação (ANTES do while). No início de cada iteração do while a variável atual é atribuída com os ticks do sistema. O número de milisegundos passados é armazenado na variável tempo, que é resultado da diferença das variáveis atual e anterior. A variável x deve ser incrementada pela variação de distância calculada pelo tempo passado dividido por 1000, multiplicado pela velocidade – 320 pixels/segundo. Feita a conta, a variável anterior recebe o valor de atual, já que no próximo quadro os ticks do quadro atual passam a ser do anterior.

Como prometido, vamos discutir o uso de uma variável double para armazenar a coordenada x da imagem. Isto se deve ao fato de que o deslocamento será praticamente sempre um valor com casas decimais, logo para uma aproximação mais adequada sem arredondamentos que comprometam o efeito visual e temporal, devemos utilizar variáveis do tipo ponto flutuante. Para deixar a brincadeira mais divertida, experimente colocar o SDL_Delay(20) no código do while

e note que a imagem continua levando o mesmo tempo para atravessar a tela, ou seja, a animação se adaptou à taxa de atualização.

Outras Melhoras

Mesmo que não tenhamos acesso ao retraço vertical, sabemos que um display de vídeo trabalha com uma taxa de atualização fixa e limitada, logo não adianta desenhar mais quadros por segundo do que o sistema pode exibir. O nosso exemplo certamente faz isso, para evitar este problema, podemos considerar uma taxa máxima de atualização da tela, como 100 quadros por segundo.

Isso significa que entre cada quadro devem se passar pelo menos 10ms, assim basta verificar se o valor da variável tempo é pelo menos 10, como mostrado no código temporizado_melhor.cpp. Se o valor for maior ou igual, desenhamos o quadro, caso contrário, esperamos.

Doom 3 é um jogo que faz isso, limitando a atualização a 60 quadros por segundo, independente dele usar ou não o retraço vertical nas configurações.

O método como apresentado até agora funciona muito bem, porém ele requer um desempenho mínimo do sistema para evitar que ocorra lag no jogo – percebido como falta de precisão no controle e na resposta do jogo. Como as animações são baseadas no

Listagem 1: temporizado_final.cpp ...

...

// Tempo atual atual=SDL_GetTicks(); // Qual o tempo passado Uint32 tempo=atual-anterior; // Verifica se passou o tempo mínimo necessário if(tempo<10) continue; if(tempo>30) tempo=30; // Limpa a tela SDL_FillRect(tela, NULL, SDL_MapRGB(tela->format, 255, 255, 255)); // Em que posicao x desenha a imagem x += (double)(tempo)*320.0/1000.0;

http://www.jogospro.com.br

NOVEMBRO 2004

tempo, você pode num FPS acabar mirando num inimigo do jogo que não está mais lá na próxima atualização – quem jogou Doom 3 numa máquina fraca sentiu na pele isso. No nosso exemplo, a imagem se “teleportaria” de um ponto ao outro da tela, o que não é uma ilusão muito convincente de animação.Esse efeito de falta de precisão pode ser contornado estabelecendo-se um tempo máximo entre cada quadro desenhado – 30ms, por exemplo.

Se o tempo passado for maior que isso, o jogo força o valor limite para animar os elementos sem prejuízos no jogo além de um slow down.

A listagem temporizado_final. cpp realiza essa última etapa.

Simplesmente testamos o valor da variável tempo, se este for maior que 30, o forçamos para este valor, caso contrário usamos o valor calculado normalmente.

Vale lembrar que essa última modificação não resolve o problema de desempenho da máquina, apenas ameniza-o deixando a animação mais lenta de maneira a compensar um processamento anormal – como quando o sistema faz swap de memória em disco ou houvesse elementos demais na tela e a lógica impusesse um overhead muito grande. Se a máquina não tiver condições de rodar o jogo, não será essa última modificação que irá resolver o problema.

Considerações Finais A técnica apresentada nesse artigo certamente não é revolucionária, existem outras variações para fazer a mesma coisa, porém ela ilustra claramente a lógica necessária para um jogo manter as animações de maneira adequada independente do desempenho do sistema e da taxa de atualização do vídeo. Vale lembrar que a técnica pode ser utilizada tanto em jogos 2D como 3D sem restrições, então aproveite e faça isso no seu próximo projeto  que vale à pena.

Paulo V. W. Radtke É professor na PUCPR e programador C++ e Java.

Nas horas vagas desenvolve o Sector 7, um jogo de nave 2D indie, por mais que ainda não tenha achado um pixel artist.

JOGOSPRO e-magazine

ARTIGO

por Wilson “WolveWilson” Jr.

2D .NET Games P

Usando GDI+

de 3 2 te r a

Nesta segunda parte do artigo estaremos abordando como resolver o problema do flicker quando estamos movimentando um gráfico na tela. Você pode estar se perguntando o que é flicker? Flicker é um efeito de refresh que faz com que o gráfico fique trêmulo (piscando) durante o movimento. Isso ocorre porque o desenho está sendo feito diretamente na memória de vídeo, gerando uma falta de sincronia entre o que está sendo desenhado e o que está se desenhando na memória de vídeo naquele momento. Para resolvermos esse problema estaremos ensinando como implementar uma técnica, muito utilizada, chamada de double buffering.

O que é o double buffering ?

Geralmente os programas Windows desenham diretamente no vídeo quando o evento WM_PAINT ocorre. Isso pode causar o efeito de flicker por conta do refresh (atualização) que a janela executa repetidamente. Isso ocorre, por exemplo, durante uma animação, um ‘arrastar’ de mouse, um resize (redimensionamento) de uma janela e etc...

Nós podemos resolver isso aplicando uma técnica conhecida como DOUBLE BUFFERING, que consiste em fazer todo o desenho em um ‘buffer’, ou seja, em background, e só após o término de tudo, o vídeo é atualizado (inteiramente e de uma só vez). Desta forma eliminamos o problema, porque quando o monitor estiver atualizando a tela, não estaremos desenhando diretamente nela, evitando-se a falta de sincronismo que origina o problema.

A grande vantagem dessa técnica é que, como veremos a seguir, ela é de fácil implementação e será muito útil para nossos jogos em 2D, podendo ser aplicada na maioria dos casos. Além disso ela serve de base para técnicas mas avançadas.

Próxima Parte

Na próxima parte deste artigo estaremos entrando na parte mais legal: A implementação de um jogo completo. Estaremos implementando o famoso RALLY-X !!!! E comentando o código para vermos na prática como usar os conhecimentos que adquirimos.

Conto com vocês, até a próxima. 

Wilson Junior É Formado em Informática pela PUC-RIO. Atua na área de informática há mais de 10 anos. Trabalha como Analista de Negócios e tem como hobby a programação de jogos. Já programou em Basic, C, C++, Dbase II, Clipper, VB, Delphi, Assembly, e atualmente, C#. Hoje encontra-se envolvido com o projeto Last Energy, um shoot’em up 3D.

Implementação O próprio C# tem uma implementação interna dessa técnica. Para ‘ativá-la’ basta acrescentarmos as seguintes linhas SetStyle(ControlStyles.UserPaint, true); SetStyle(ControlStyles.AllPaintingInWmPaint, true); SetStyle(ControlStyles.DoubleBuffer, true); A título de exemplo no final do artigo você encontrará os fontes da edição anterior com o acréscimo dessas três linhas e com uma modificação no intervalo do timer1 de 150 para 50.

Experimente comentar as três linhas de setstyle para que você possa notar a diferença. http://www.jogospro.com.br

NOVEMBRO 2004

Não percam na terceira parte a implementação do rally-x em c#.

JOGOSPRO e-magazine

ARTIGO Listagem 1: Exemplo using System; using System.Windows.Forms; using System.Drawing; namespace DefaultNamespace { /// <summary> /// Description of MainForm. /// </summary> public class MainForm : System.Windows.Forms.Form { private System.ComponentModel.IContainer components; private System.Windows.Forms.Timer timer1; public int x,y=10; public MainForm() { // // The InitializeComponent() call is required for Windows Forms designer support. // InitializeComponent();

}

}

}

SetStyle(ControlStyles.UserPaint, true); SetStyle(ControlStyles.AllPaintingInWmPaint, true); SetStyle(ControlStyles.DoubleBuffer, true);

[STAThread] public static void Main(string[] args) { Application.Run(new MainForm()); } #region Windows Forms Designer generated code /// <summary> /// This method is required for Windows Forms designer support. Do not change the method contents inside the source code editor. /// The Forms designer might not be able to load this method if it was changed manually. /// </summary> private void InitializeComponent() { this.components = new System.ComponentModel.Container(); this.timer1 = new System.Windows.Forms.Timer(this.components); // // timer1 // this.timer1.Enabled = true; this.timer1.Interval = 50; this.timer1.Tick += new System.EventHandler(this.Timer1Tick); // // MainForm // this.AutoScaleBaseSize = new System.Drawing.Size(5, 13); this.ClientSize = new System.Drawing.Size(292, 266); this.Name = “MainForm”; this.Text = “MainForm”; } #endregion void Timer1Tick(object sender, System.EventArgs e) { x =x + 1; y =y + 1; Invalidate(); //Força o repaint em todo a janela, tb pode ser //passada a área especifica de refresh por parametro if ((x > 200) & (y > 200)) Application.Exit(); } protected override void OnPaint(PaintEventArgs e) { Graphics dc = e.Graphics; Font fnt1 = new Font(“Tahoma”,30,FontStyle.Bold); dc.DrawString(“teste”, fnt1, Brushes.Black, x,y); base.OnPaint(e); }

http://www.jogospro.com.br

NOVEMBRO 2004

JOGOSPRO e-magazine

por Matías Rodriguez

ARTIGO

BREW Primeiros Passos Este tutorial tenta iniciar o leitor no desenvolvimento de aplicações para dispositivos móveis utilizando a tecnologia Brew (se pronuncia “bruu”). Na primeira parte vamos ter uma visão geral desta plataforma. Na segunda parte iremos configurar o ambiente para que na terceira parte possamos criar uma pequena aplicação de testes. Na quarta e última vamos ver algumas especificações de alguns modelos de celular disponíveis no Brasil.

Para baixar o SDK e desenvolver o exemplo é necessário ter um sistema operacional Windows e o compilador Microsoft Visual C++ 6 ou superior.

Sobre o Brew

A tecnologia Brew (Binary Runtime Enviroment for Wireless) da Qualcomm (mesma criadora da tecnologia CDMA) chegou ao Brasil graças à operadora Vivo. Esta tecnologia já está presente em outros países da América do Sul, América do Norte, Europa e Ásia.

Brew é uma solução tanto de software quanto de hardware. Isto quer dizer que não é qualquer celular que pode rodar uma aplicação Brew, somente um celular com um chip Brew. Na parte de software Brew nada mais é que uma API que fornece acesso aos recursos do hardware como sistema de arquivos, rede, estado das teclas, visor (dependendo do modelo do celular pode existir mais de um) e outras funcionalidades como criar caixas de diálogo para entrar e/ou mostrar informações, tocar sons e músicas, agenda de endereços, etc.

O Brew chama uma aplicação de módulo ou applet. Um módulo pode ou não usar funcionalidades de outros módulos. Um módulo é formado por uma estrutura de arquivos e diretórios. Existe um diretório com todas as aplicações. Cada aplicação possui seu próprio subdiretório. Num dispositivo com as aplicações app1 e app2, por exemplo, existe um “diretório” com os arquivos “app1.mif”, “app2.mif” e os subdiretórios “app1” e “app2”.

O diretório de cada aplicação é formado pelo executável (dll), arquivos de recursos (bar) e arquivos específicos de cada um. A seguir vamos explicar com mais detalhes cada um dos arquivos que o desenvolvedor tem que lidar no desenvolvimento de aplicações Brew.

Arquivo MIF (Module Information File) Arquivo com informações do módulo. Este arquivo contém o identificador único (entre todos os outros módulos Brew existentes no mundo) de 32 bits de uma aplicação, quais classes são exportadas, informações como nome e ícones para serem mostradas no menu de seleção de aplicações, privilégios do módulo (acesso ao http://www.jogospro.com.br

sistema de arquivos, rede, mensagens de outros módulos), etc. O Brew disponibiliza um editor para criar e alterar arquivos MIF. Quando estamos desenvolvendo uma aplicação para rodar no emulador podemos escolher um número aleatório como id mas deve-se tomar cuidado para não escolher o mesmo número de algum componente da API. No caso de querer rodar a aplicação num celular de verdade é necessário requisitar um número único com a própria Qualcomm.

Diretório Diretório da aplicação. Deve ter o mesmo nome que o arquivo MIF. Este diretório contém todos os arquivos da aplicação. A aplicação só enxerga os arquivos neste diretório e os de um outro diretório comum a todas as aplicações.

Arquivo DLL (Dynamic Link Library) Arquivo com a aplicação em si. Deve possuir o mesmo nome que o diretório da aplicação. Contém o código executável da aplicação. Esta DLL é gerada pelo compilador.

o arquivo BAR (visto anteriormente) e o arquivo app_res.h onde app é o nome da aplicação para ser incluído no projeto.

Arquivo _res.h Gerado a partir do arquivo BRI, nada mais é que um arquivo que deve ser incluído (#include) no projeto para saber o identificador dos recursos (imagens, caixas de diálogos, textos) da aplicação.

A programação pode ser feita tanto em C quanto em C++. A API consiste em uma biblioteca de funções estruturadas de uma forma orientada a objetos. A API é muito similar à plataforma COM da Microsoft. Além disso, o próprio estilo de programação é similar ao desenvolvimento de aplicações Win32 (orientado a eventos), onde uma função de callback é registrada e o ambiente repassa todos os eventos (EVT_KEY_ PRESS, EVT_APP_START, EVT_APP_STOP, etc.) ocorridos para esta função.

Uma grande restrição é que não se pode incluir (#include) nenhum arquivo fora os do Arquivo BAR (Brew Applet Resource) Brew e logicamente os da aplicação sendo Arquivo com os recursos da aplicação. Deve possuir desenvolvida. Isto quer dizer que funções como malloc, free, printf, strcmp, memset, objetos da o mesmo nome que o diretório da aplicação. Este stl (Standard Template Library), etc. não podem arquivo guarda recursos como textos, imagens e ser utilizados. Para ajudar um pouco a vida do caixas de diálogo. O Brew disponibiliza um editor desenvolvedor a API define equivalentes em de recursos para gerar este arquivo.

BREW para as funções mais comuns, sendo que Durante o desenvolvimento da aplicação existem o nome é sempre em maiúscula. Ex: MALLOC, STRCMP, ATOI, SPRINTF, etc. Outra restrição outros arquivos que o desenvolvedor tem que importante é que não se pode utilizar variáveis lidar, que são: estáticas nem globais, pois este tipo de dado não pode ser tratado em aplicações que são Arquivo BID (Brew classID) baixadas dinamicamente. A plataforma Brew Nada mais é que um .h disfarçado. Este arquivo é gerado a partir do arquivo MIF e define (#define) o ainda não suporta o uso de ponto flutuante identificador único da aplicação. Deve ser incluído (float e double), para isso são disponibilizadas algumas funções de ponto fixo (fixed point) (#include) no projeto. auxiliares. No caso do C++ é necessário sempre Arquivo BRI (Brew Resource Intermediate) sobreescrever os operadores new e delete É um arquivo manipulado pelo desenvolvedor. globais para utilizarem as funções MALLOC e FREE e não a implementação padrão. O Brew É nele que, usando um editor específico, SDK vem com um emulador onde é possível adicionamos recursos como imagens, textos e caixas de diálogos. Usando o editor podemos gerar testar as aplicações sendo desenvolvidas sem NOVEMBRO 2004

JOGOSPRO e-magazine



ARTIGO a necessidade de ter um dispositivo Brew real como um celular. Para compilar e rodar a aplicação no emulador um compilador como o Microsoft Visual C++ é suficiente.

No caso de querer rodar a aplicação num celular real é necessário adquirir um compilador ARM cujo custo é alto. Existe um compilador GNU mas a Qualcomm não oferece suporte para ele. Para testar a aplicação basta copiar ela para o diretório de aplicações do emulador seguindo os padrões mostrados previamente . No caso de querer rodar a aplicação num celular real, lamentavelmente é bem mais complicado que J2ME, por exemplo. É necessário ter adquirido um celular habilitado para testes Brew. Isto quer dizer que o celular só serve para isso e não pode ser utilizado para outra tarefa.

Para distribuir uma aplicação Brew é necessário ser um Desenvolvedor Registrado da Qualcomm e a aplicação em si tem que passar por uma série de testes onde o valor dos testes pode chegar a mais de US $1.000.

Uma vez que a aplicação passou por todos os testes, é possível oferece-la a todas as operadoras que suportam Brew em todo o mundo. A pesar de o desenvolvimento de aplicações Brew para um desenvolvedor independente ou mesmo uma empresa pequena ser relativamente caro, uma das principais vantagens do Brew é este sistema de distribuição chamado BDS (BREW Distribution System).

Baixando o Brew SDK

um compilador como o Microsoft Visual C++ 6.0 ou superior.

Para facilitar a tarefa de criação da nossa aplicação de testes, vamos baixar também o “Suplementos (add-ins) do Brew para o

Figura 2: Várias versões do SDK para serem baixadas. A versão 2.0 vai ser escolhida pois representam a maioria dos Celulares disponíveis no Brasil.

Microsoft Visual Studio” como mostra a figura 3. Este plugin disponibiliza um Wizard para a criação de aplicativos Brew e disponibiliza uma barra de ferramentas que auxiliam no desenvolvimento.

Aplicação de Exemplo

No Visual Studio 6.0 é necessário habilitar o menu de add-ins do Brew. Para fazer isto deve-se ir em “Tools” -> “Customize...”, clicar Figura 4: Criando um novo id para nossa aplicação na aba “Add-ins and Macro Files” e habilitar os add-ins do Brew. Para criar nossa aplicação “Arquivo” -> “Salvar”. Salve como “demobrew. de exemplo vá ao menu “File” -> “New...” e mif” no diretório do projeto. Nossa aplicação de testes precisa de um arquivo de recursos (demobrew.bar). Para criálo, abra o aplicativo “Brew Resource Editor”, vá ao menu “Recurso” -> “Nova string...” e coloque os dados para nossa aplicação como mostra a figura 7. Salvar o arquivo como “demobrew.bri” no diretório do projeto, e para finalizar, vá no menu “Gerar” -> “Gerar arquivos .BAR...” para gerar o arquivo “demobrew. bar” e “demobrew_res.h”.

Figura 3: Suplementos adicionais para o desenvolvimento de aplicações Brew para o

Para baixar o Kit de desenvolvimento basta acessar o endereço http://brew. qualcomm.com/brew/pt/ e clicar na opção “Faça o Download do Brew SDK” (figura 1). Na primeira vez é necessário se registrar no site (é grátis). Uma vez feito o registro vamos para a página de download do SDK. Vamos escolher a versão 2.0 em Português (o idioma é indiferente) pois atualmente é a versão do Brew que tem mais celulares aqui no Brasil (ver figura 2). O SDK é composto por várias ferramentas, um Emulador, documentação da API e das ferramentas e os arquivos necessários para compilar e linkar uma aplicação Brew utilizando

Microsoft Visual C++ 6.0 ou superior.

selecionar “Brew Application Wizzard”. Como nome, vamos utilizar “demobrew”. Como este é um exemplo simples, na primeira tela do Wizard não vamos escolher nenhuma opção. Caso quiséssemos mexer com arquivos, por exemplo, a opção “File” poderia ser selecionada para que o Brew incluísse os cabeçalhos necessários. Na tela seguinte vamos configurar para não gerar comentários no fonte gerado (o ideal seria colocar sim, mas para facilitar este exemplo vamos colocar não).

Figura 1: Site do Brew em Português onde é possível baixar o SDK. http://www.jogospro.com.br

arquivos “demobrew.mif”, “demobrew.bid” e no caso específico da nossa aplicação (que usa um arquivo de recursos) “demobrew. bar” e “demobrew._res.h”. Abra o “Brew Mif Editor” para podermos criar um identificador único para nossa aplicação. Para isso clique no botão “Novo Applet” (figura 4). Vamos especificar um id local para testes. Então devemos escolher a opção “Localmente” e vamos digitar algum número que não seja utilizado por outra classe do Brew (figura 5). Ao confirmar, uma tela irá aparecer para salvar o arquivo “demobrew.bid”, este arquivo pode ser salvo no diretório do projeto. Termine de preencher as informações da aplicação como mostrado na figura 6 e vá ao menu

Uma vez que o wizard gerou os arquivos, precisamos criar os NOVEMBRO 2004

O Wizard gerou uma estrutura (struct) chamada “demobrew” contendo algumas variáveis que poderão ser acessadas pela aplicação. O ponto de entrada do

Figura 5: É necessário escolher um id local para nossa aplicação.

Usar um número que não seja usado por nenhuma classe da API. JOGOSPRO e-magazine



ARTIGO

Figura 6: Configurando algumas informações da aplicação.

Figura 7: Criando uma string UNICODE no arquivo de recursos para ser usada pela aplicação.

Listagem 1: Exemplo static boolean demobrew_HandleEvent(demobrew* pMe, AEEEvent eCode, uint16 wParam, uint32 dwParam) { AECHAR buffer[ 16 ]; //buffer para guardar a mensagem.

Figura 8: Aplicação demobrew rodando no

emulador. switch (eCode) { case EVT_APP_START: { características de alguns celulares //carregar a string do arquivo de recursos (bar) ISHELL_LoadResString( pMe->pIShell, DEMOBREW_RES_FILE, IDC_MENSAGEM, buffer, sizeof( buffer ) ); Brew disponíveis aqui no Brasil. //desenhar a mensagem na tela.

IDISPLAY_DrawText( pMe->pIDisplay, AEE_FONT_NORMAL, buffer, -1, 0, 0, NULL, IDF_ALIGN_ Conclusão CENTER|IDF_ALIGN_MIDDLE ); Este artigo tentou iniciar o leitor //Atualizar a tela. no desenvolvimento de aplicações este diretório é localizado em “c:\Arquivos de IDISPLAY_Update ( pMe->pIDisplay ); Brew. Existem muitos detalhes técnicos e programas\BREW SDK v2.0.1 Pt\Examples”. return(TRUE); } comerciais não mostrados aqui. O próprio Nesse diretório deve-se criar um subdiretório case EVT_APP_STOP: SDK contém uma vasta documentação da chamado “demobrew” e copiar lá dentro os return(TRUE); arquivos “demobrew.dll” (gerado pelo Visual API e exemplos que podem e devem ser default: break; consultados. O site http://brew.qualcomm.

C++) e “demobrew.bar”. Agora é necessário } com/brew/pt/ está cheio de notícias, abrir a aplicação “Brew Emulator”, escolher return FALSE; exemplos, conselhos, dicas, etc. Possui nossa aplicação e fazê-la rodar.

O resultado é } também fóruns onde desenvolvedores mostrado na figura 8.

Certificados pela Qualcomm podem postar programa é a função “int AEEClsCreateInsta Perfil de alguns dispositivos dúvidas. Quem não é desenvolvedor nce(AEECLSID ClsId, IShell *pIShell, IModule certificado mesmo assim pode ler os fóruns. *po, void **ppObj)”. Esta função é invocada disponíveis no Brasil Ao desenvolver aplicações para dispositivos Os arquivos do projeto estão disponíveis no pelo ambiente Brew e deve chamar a função  celulares devemos tomar precauções site da Revista JogoPRO. “AEEApplet_New” informando a função de callback para receber eventos, quanta memória Memória deve ser alocada inicialmente para a aplicação Celular Versão Brew Resolução Heap Stack Persistente (estrutura demobrew) entre outras coisas.

Foi gerada também a função “boolean demobrew_HandleEvent(demobrew* pMe, AEEEvent eCode, uint16 wParam, uint32 dwParam)”. Esta é a função que irá receber os eventos do ambiente. No nosso exemplo, no evento EVT_APP_START (nossa aplicação está iniciando) iremos carregar uma string em formato unicode do arquivo “demobrew. bar” e em seguida vamos mostrar o seu conteúdo na tela (Listagem 1). O demo não faz muita coisa, mas mostra o básico de uma aplicação Brew. O SDK vem com vários exemplos inclusive com o código fonte que podem ser rodados no emulador.

Para rodar nossa aplicação basta copiar o arquivo “demobrew.mif” para o diretório com as aplicações de exemplo do Emulador. Geralmente http://www.jogospro.com.br

LGE BD6070

BREW 2.0.1

120x146 16 Bits

600 Kb

8 Kb

660 Kb

Motorola E310

BREW 2.0.2.6

128x110 8 Bits

600 Kb

16 Kb

1.5 Mb

LGE LX5450

BREW 2.0.2.6

120x146 16 Bits

500 Kb

?

1.5 Mb

Motorola V810

BREW 2.0.2.6

128x142 16 Bits

1 Mb

?

2.0 Mb

Kyocera KX414c

BREW 2.0.2.6

104x68 12 Bits

400 Kb

?

1.5 Mb

LGE BX4170

BREW 2.0.2.6

128x114 16 Bits

512 Kb

?

1.5 Mb

Samsung SCH-A655

BREW 2.0.2.6

128x146 16 Bits

614 Kb

?

2.0 Mb

Tabela 1: Celulares Brew

extras na hora de alocar memória, programar nossos algoritmos, etc. Tudo isto pois os dispositivos possuem muitas limitações se comparados a um PC, por exemplo. Para conseguir as especificações técnicas de cada dispositivo, muitas vezes devemos recorrer aos próprios fabricantes.

A tabela 1 abaixo mostra algumas NOVEMBRO 2004

Matías Gonzalo Rodriguez É formado em Ciencia da Computação e pós-graduado em Desenvolvimento de Jogos. Diretor da Sumersoft Tecnologia.

Entusiasta das linguagens C/C++, Java e Smalltalk. Gosta de jogar e desenvolver Jogos em suas horas vagas.

JOGOSPRO e-magazine

por Daniel “NeoStrider” Monteiro

ARTIGO

Introdução a programação em Symbian OS Nokia Series 60 em C++.

Com este artigo, pretendo demonstrar esta incrível plataforma que é a Series 60 da Nokia, baseado no sistema operacional Symbian OS. Não pretendo aqui usar qualquer biblioteca extra, de modo que somente com a API básica do sistema seja possível fazer games de qualidade.

Somente com o SDK fornecido pela Nokia.

Vale lembrar, este artigo não vai dar uma aula de programação para N-Gage, embora os softwares criados com o que for ensinado neste artigo possam ser executados nele sem dificuldade.

O

Symbian é um consórcio atualmente formado pelas gigantes Nokia, Sendo, LG Electronics, Mitsubishi Eletric, Siemens, Benq, Lenovo , Motorola, Panasonic, Sanyo , Arima, Samsung , Sony Ericsson e Fujitsu. Todas elas unidas para criar o sistema operacional Symbian, um novo padrão na computação móvel, e agora mais recentemente, um padrão para SmartPhones. O sistema em si não é novo: trata-se de uma evolução do EPOC32, da Psion Computers, que vem usando este sistema em seus handhelds há quase uma década, e muito do que se usa na programação Series 60 é literalmente derivado de componentes antigos do EPOC32.

UID

Para que existem UIDs? Internamente, são usadas pelo sistema para associar tipos de arquivos à suas respectivas aplicações. Mais adiante veremos outra utilidade interessante para as UIDs.

Conceitos Básicos O framework CONE: CONE é o nome dado ao framework de aplicações que possuem interface gráfica no SymbianOS. Refiro me a aplicações com interface gráfica, porque é possível criar “aplicações” sem interface gráfica. Tratamse de servidores de serviço. Eles funcionam junto de aplicações comuns, dividindo as tarefas do programa de uma forma mais racional, e aproveitando melhor a timeslice do sistema.

UID é um numero de identificação associado a cada aplicação Symbian.

Repetir um número ou usar um pertencente a outra aplicação pode trazer complicações Aplicações cone normalmente têm a seguinte ordem: de solução difícil pelo usuário. Para obter um UID para sua aplicação, a Symbian mantém um email destinado a esse fim.

ApplicationDocumentAppUi AppView

http://www.jogospro.com.br

NOVEMBRO 2004

Para criar aplicações, basta derivar estas classes e implementar os métodos apropriados ao comportamento desejado a cada componente do sistema.

Application: (derivada de CEikApplication. Básica do Symbian OS 6.1, montada em cima de CApaApplication, do EPOC32 R5.0) Esta classe encapsula as etapas de construção de estruturas básicas usadas para construir os outros componentes do framework, como a cleanup stack (não por acaso, esta classe é criada com o new tradicional).

A Application é quem cria a Document, que veremos agora.

Document: (derivada de CEikDocument. básica do Symbian OS 6.1, montada em cima de CApaDocument, do EPOC32 R5.0)

JOGOSPRO e-magazine



ARTIGO Na plataforma Series 60 (a propósito: Series 60 se refere a UI, mais especificamente às classes que usamos, como as CEik, que são do UIKON e mais os extras do pacote AVKON), esta classe não tem tanto uso como em outras plataformas Symbian, nas quais esta classe é responsável por cuidar do documento da aplicação. Este documento é um conceito sem uso em Series 60. Trata-se do arquivo de trabalho no momento, como no Microsoft Word, que temos o documento que estamos editando, a document tem seu document. Esta classe cria a AppUi, que será muito importante para nossa aplicação.

AppUI: (derivada de CEikAppUi. Especifica do Symbian 6.0 e derivada de CCoeAppUi) Na UI Series 60, esta classe é uma das mais importantes, pois ela faz parte do sistema de gerenciamento de eventos. Sem falar que ela contem a UI de fato. Curiosamente, não é ela que cuida de desenhar os componentes, mas somente de agrupá-los e representar sua organização. Esta classe cria AppView.

architecture, e é muito boa à medida que permite chamar as views de outras aplicações, mais ou menos como se fosse possível chamar uma janela de uma outra aplicação Windows. Neste caso, precisamos associar identificações para cada view.

Para chamar views de outros programas, precisamos saber os números tanto da UID da aplicação, quanto do ID da View desejada.

Criando Games em cima do framework Quanto à uma melhor opção para multimídia, não vamos abordar aqui nenhuma outra arquitetura que não a arquitetura tradicional. Muito menos usaremos Servidores (embora com eles o desempenho seja maior).

A tática mais comum com a arquitetura tradicional, usando uma única view, é incluir na view uma instância de CPeriodic (ou de sua básica, CTimer), que chama uma função CallBack (passada como TCallBack) que atualiza a tela e responde ao sistema operacional, capturando os eventos do sistema, etc.

AppView: (Também chamada de Container por alguns autores. Classe derivada de CCoeControl porque implementa controles visuais para nossa GUI. Existente desde o EPOC32 5.0, usando o mesmo nome - curiosamente existia sem a AppUi) Nesta classe, temos o input e o output.

Esta classe pode conter instâncias dela mesma e funcionar como um compound control, que divide áreas da tela e repassa para seus componentes. O sistema já veio preparado para isso. No fundo, temos uma única view com diversos compound controls. Essa é a chamada arquitetura tradicional.

Uma outra alternativa para a construção de interfaces gráficas é basear a aplicação em dialogs, neste caso nossa AppView herda uma classe chamada CAknDialog, funcionando de forma parecida com forms, mas menos flexível em termos de manipulação pelo usuário. Funciona parecido com as Common Dialogs da Microsoft e por fim uma alternativa que lembra a tradicional, mas que permite a alternância de views ativas.

Esta é a chamada Avkon Switching view http://www.jogospro.com.br

Respondendo ao sistema

A resposta ao sistema se dá de forma muito semelhante ao Visual BASIC: automáticamente. Tudo que a aplicação deve fornecer são os métodos apropriados a serem chamados pelo framework, para atuar em caso de eventos. Mas sem responder ao sistema, temos apenas uma aplicação que exibe uma única tela e fica parada.

Ferramentas e SDKS

Tudo que precisamos para desenvolver para Series 60 é o SDK fornecido pela Nokia ou por uma das licenciadas , um compilador C++ NOVEMBRO 2004

compatível (C++Builder, CodeWarrior ou Visual C++), de Active Perl, usado no processo de montagem da aplicação, e do JRE 1.3. Alternativamente, é possível pegar um pacote que fornece o SDK 1.2 de Series 60, Active Perl e o C++Builder 6 mobile edition. tudo num único processo de instalação. É fazer o download, instalar e começar a desenvolver.

SDKs: Existem diferenças nos SDKs: SDKs 1.x servem para Series 60 1.0 e SDKs 2.X servem para aparelhos Series 6.0 2.0. Qual é a diferença?

Series 60 2.0 roda em cima de SymbianOS 7.0 e é compatível com Series 60 1.0. enquanto Series 60 1.0 é baseado em Symbian 6.1. A princípio é possível ter dois SDKs instalados no compilador, mas existem precauções a serem tomadas, principalmente quanto às variáveis de ambiente, que controlam o processo de montagem.

Compiladores: Entre os compiladores listados acima como compatíveis, cada um tem suas particularidades de trabalho, bem como vantagens e desvantagens.

Vale lembrar que o consorcio Symbian prefere o CodeWarrior, mas a Nokia esta dando preferência à Borland, tanto que a tendência é transformá-lo no compilador padrão. Outra consideração a ser lembrada é o C++BuilderX que foi feito tendo desenvolvimento multiplataforma em mente e agrega uma função de RAD eficiente, e por isso é uma boa opção para desenvolvimento em Series 60. 

Daniel Monteiro Tem 20 anos, é estudante da Universidade Federal Fluminense e quando não está estudando ou trabalhando nos seus jogos para Symbian, ele está detonando alguém no N-Gage... ‘’ Ashen ROX!!!!’’

Saiba mais Sites www.codeblood.com.br www.newlc.com www.forum.nokia.com.br www.nokia.com www.series60.com www.symbian.com Livro Developing Series 60 Applications , EMCC Software , ISBN 0-321-22722-0 JOGOSPRO e-magazine

ARTIGO

por Eduardo Dias Favero

Apresentação de produtos: 3DS MAX e MAYA Gostaria de agradecer aos idealizadores da revista eletrônica JogosPRO, e aos leitores que apoiaram a idéia e a fazem crescer. Bom, não confrontarei as duas ferramentas de produção 3D, pois não cabe a mim, e o artista 3D não se limita pela sua ferramenta, e sim pela sua imaginação. Irei apresentar os prós e contras de cada ferramenta e seu custo/beneficio, sem “puxar o saco” de nenhum produto, tudo é baseado na minha opinião sobre eles. Caso alguém discorde, mande um e-mail. Separei em tópicos para a fácil análise, então, vamos a eles!

Primeiramente, a Comunidade Brasileira:

A comunidade brasileira de Computação Gráfica é muito grande quando o programa em questão é o 3DS max. Por ter se instalado primeiro no Brasil, o 3DS max é muito difundido entre os artistas, arquitetos e designers, então. Mesmo na comunidade brasileira, você acha muitos sites e fóruns com diversos tutoriais e suporte.

Já o MAYA, por ter entrado depois na indústria brasileira, perdeu o seu espaço para o 3DS max, assim como o Softimage XSI está engatinhando atualmente no Brasil (e tomara que já comece a andar). O MAYA estava na mesma situação há alguns anos atrás. Agora, empresas como a Vetor Zero mostram o poder do MAYA em seus comerciais. Lembram da tartaruga de uma determinada marca de cerveja? Então...

Velocidade de aprendizagem O 3DS max possui uma referência enorme, com diversos exemplos e ajuda após a instalálo. Muitos sites, como o www.redpixel. com.br, oferecem tutoriais em vídeo, o que aumenta a velocidade de aprendizagem. O MAYA também vem com vários exemplos após instalá-lo, e possui um comando dentro do programa, no menu ajuda, que acha o menu ou ferramenta que você procura. Um exemplo de site que possui tutoriais em vídeo é o: www.digital-tutors, e o próprio site da empresa que o produz.

Interface A interface do 3DS max é boa e rápida para se trabalhar, mas há alguns problemas de organização. Um exemplo é o editor de materiais, difícil de organizar seus shaders e a interface não ajuda; outro exemplo é a interface do Character Studio (plugin do MAX http://www.jogospro.com.br

que agora foi incorporado na versão 7), para você editar a figura, é preciso mexer em muitos menus, e a aplicação de pesos de vértices nos bones é demorada e pode causar Lesão por Esforço Repetitivo (LER).

O MAYA não apresenta alguns desses problemas, por poder ajustar apenas com um clique a viewport, se teremos o Hypershade, Hypergraph, e (ou) gráfico de animações.

Modelagem Aqui as duas ferramentas se dividem: Modelagem em polígonos no 3DS max, e modelagem em NURBS no MAYA. Por quê? Bom, pela Auto Desk (3DS Max, Auto CAD) trabalhar antigamente com seu foco somente em arquitetura, as ferramentas precisavam ser as mais precisas possível, e tendo em sua maioria, as “retas” e o uso de polígonos, a parte de modelagem em NURBS do 3DS Max é mais fraca... Já a Alias (MAYA) trabalhou desde o inicio com programas voltados a filmes, logo, precisava de ferramentas que apresentassem “curvas” e o uso de Splines para a modelagem.

Atualmente o NURBS está sendo deixado de lado, sendo substituído pela modelagem em polígonos e subdivisão.

Como o foco são os jogos, o 3DS max se sobressai neste quesito de modelagem em polígonos, com várias ferramentas e várias maneiras de se chegar ao mesmo resultado. Agora, caso queira fazer a produção de vídeos e personagens High Poly, MAYA é a maneira mais rápida. É claro que varia, do gosto do artista.

Texturização Não há muitas diferenças entre as duas ferramentas, somente o suporte que elas dão as Engines, colocando seus shaders na viewport NOVEMBRO 2004

do próprio programa. O MAYA se sobressai neste quesito, o 3DS Max começou a ter suporte a pixel shader na viewport, e aos shaders do Direct X, apenas na versão 6, enquanto o MAYA fazia já há algumas versões. Agora a briga é pelo normal map, que por sinal, fará muita diferença nos próximos jogos. Entraríamos em outra questão que é: os modelos, é melhor que eles tenham poucos polígonos (em torno de 1500), mas tenham vários mapas (Normal, reflexão, especular), do que ter um modelo lotado de polígonos (em torno de 7000), com expressões faciais, mas sem efeitos? O bom seria se os dois estivessem juntos...

Setup/RIG de personagens O que seria do RIG do 3DS max sem o Character Studio ? Seria a mesma coisa que é hoje. O Character Studio (CS) é muito bom para fazer personagens humanos rapidamente, mas é limitado para outros modelos. Um exemplo é: caso for fazer um dragão, suas asas teriam que ser feitas com os bones nativos do 3DS Max. A possibilidade do CS importar arquivos de Motion Capture e migrar a animação de um modelo a outro faz com que ele seja uma ótima ferramenta, porém está sendo ultrapassada por ferramentas como o CAT (Character Animation Toolkit).

O MAYA possui ferramentas muito boas para edição de bones, seleção, limite de rotação, sem a necessidade que há no 3DS max de ir no wire parameters, e com opções semelhantes a do Character Studio.

Animação Os dois produtos apresentam ferramentas de animação robustas e estáveis, com a possibilidade de animação não linear,e edição de Keyframes antigos, e com suporte a exportar soft body. No 3DS max há o plugin Reactor com o Ragdoll (muito usado em toda JOGOSPRO e-magazine



ARTIGO a indústria de jogos por sua física ser mais realista). O Reactor foi incorporado ao 3DS max recentemente, dizem que o 3DS max é uma caixa de plugins, que em todas as versões, eles jogam mais alguns lá dentro. E o MAYA possui seu soft body integrado.

Render O 3DS max só foi incorporar um render na sua versão 6, incorporou o Mental Ray como render nativo do 3DS Max, o MAYA possuia o Mental Ray há mais tempo, sem mencionar os renders: V-RAY, BRAZIL, RENDERMAN, etc.

Plugins O MAYA é um dos poucos programas que não precisam de plugins, tudo o que o artista precisa tem no MAYA, salvo determinadas ferramentas que são muito precisas no desenvolvimento de jogos. O 3DS max, possuí uma das maiores extensões de plugins existentes no mercado, o único problema, é se caso for comprar todos os plugins necessários para o 3DS max, o preço ficará mais caro que o MAYA UNLIMITED (versão com suporte a fluídos, pelos e cabelos, etc).

Interface do 3DS MAX 7

Extensão O 3DS max possuí o MAX Script e o MAYA possuí o MEL, ambos baseados em C, o principal recurso para se usar os scripts, é poder fazer exportadores para as Engines e aumentar a velocidade de produção.

Preços 3DS max: $3,495.00* MAYA complete (versão parecida com a do 3DS max): $2,199.00* MAYA unlimited (versão com todos os plugins e suporte a cabelos, fluídos, pelos, roupa, etc.) $7,199.00* * Nota: preocupado com os preços acima?

O 3DS max e o MAYA possuem versões de aprendizagem gratuitos em seus sites, o 3DS max com uma versão que dura 30 dias, e o MAYA com uma versão de aprendizagem que não há limite de tempo (MAYA Personal Learning Edition).

Interface do Maya Considerações Finais

Se de um lado temos empresas de jogos como: Blizzard, Ubi Soft, Konami, entre outras, usando o 3DS Max, temos de outro lado empresas de jogos como: Sony, Capcom, Nintendo, SquareEnix, entre outras, usando o MAYA, claro que muitas dessas empresas usam os dois programas dentro do desenvolvimento de jogos, chegando a usar o Softimage XSI e o Lightwave também.  http://www.jogospro.com.br

Eduardo Dias Favero É modelador e animador 3D, atualmente trabalha na empresa de jogos Oniria Entertainment, situada em Londrina-PR. Nas horas vagas, gosta de jogar Final Fantasy e relembrar os jogos do Atari. contato: favero_eduardo@ig.com.br NOVEMBRO 2004

Sites 3DS MAX http://www.discreet.com MAYA http://www.alias.com JOGOSPRO e-magazine

ARTIGO

por Wilson “WolveWilson” Jr.

O SuperWaba é uma plataforma de desenvolvimento criada no inicio de 2000 pelo Guilherme Hazan (guich), derivado do projeto livre chamado Waba, do americano Rick Wild. Ambos foram projetados de forma que possibilite o uso de ferramentas já existentes que dêem suporte a Java, como por exemplo o Eclipse, que possui um plug-in especifico para o superwaba.

Vantagens Uma comunidade crescente de cerca de

economia de tempo utilizado por chamadas ao Garbage Collection.

30.000 usuarios de inúmeros países como Brasil, EUA, França, Alemanha, Canada.

Sprite class: Representa um objeto do jogo que pode ser movido. Implementa funções muito úteis para jogos, como testes de colisão, movimento e etc.

Várias novas versões por ano e inúmeras melhorias e correções.

A plataforma é disponibilizada sob a

licença GNU Lesser General Public License (LGPL), que permite o desenvolvimento de aplicações comerciais, ao mesmo tempo que protege a plataforma de ser fechada.

Portabilidade: aplicações desenvolvidas são executadas em todos os PDAs suportados nas várias plataformas sem requererem quaisquer modificações ou especializações.

AnimatedSprite: Extende a classe Sprite visando o suporte de multiplos objetos ou multiplos frames de uma animação.

Metal Corps http://www.geocities.com/veilkrand/Readme.html

A API de games é composta das seguintes classes:

Bibliotecas poderosas e fáceis de usar,

GameEngine: Essa classe abstrata implementa o framework da API, provendo acesso a serviços como configuração do jogo e pontuação, estados do engine, etc.

Baixo custo de propriedade, livre de

Options e HighScores: Usadas respectivamente para guardar informações de configuração / preferência e, pontuações / tabela de recordes.

focadas no desenvolvimento rápido de aplicações, com um baixo uso de memória. licenças (royalty free).

Acesso ao código fonte permite customizações para necessidades específicas, além de permitir a verificação, por questões de segurança ou estratégicas.

Além disso a API acrescenta dois novos controles: O Animation control usado para prover conteúdos de imagem dinâmica, implementando efeitos especiais, e uma extensão desse controle chamada Animated Button, que como o nome sugere, implementa as funcionalidades de um botão em uma imagem animada.

Futuro

Esta para ser lançada a versão 5.0, que agora esta fazendo uso internamente da biblioteca SDL (Simple DirectMedia Layer), obtendo com isso maior performance na parte gráfica, biblioteca de imagens suportando qualquer formato (além TextRenderer: Usada para exibir textos, como de só gif, jpeg e png) e suporte a arquivos de status do game, pontuação, nível e etc, de maneira musica mod, o que nos abre um leque ainda eficiente, sem criação de objetos, o que gera uma maior de opções.

Baixo risco de descontinuidade: O projeto

SuperWaba pode ser mantido pela própria comunidade e não está nas mãos de apenas uma companhia.

Próxima versão, que já esta em fase de testes, prevê compatibilidade com o Symbian OS 6/7.

API de Games Além das vantagens que vimos acima, o superwaba tem uma que muito nos interessa que é a existência de uma API especifica para games, criada pelo Frank Diebolt (um colaborador do projeto), cujo o tutorial esta disponível para download gratuito. http://www.jogospro.com.br

NOVEMBRO 2004

JOGOSPRO e-magazine



ARTIGO

O Lançamento esta previsto para o dia 13 de Dezembro, e será em Fortaleza em um dos primeiros centros de treinamento autorizado.

Conclusão SuperWaba se mostra uma boa alternativa de desenvolvimento, muito similar ao Java e com uma série de vantagens, enfim, algo que vale a pena ser levado em conta quando se precisa de portabilidade e o foco for PDA/Mobile.

Até a próxima...



Wilson Junior É formado em Informática pela PUC-RIO. Atua na área de informática há mais de 10 anos. Trabalha como Analista de Negócios e tem como hobby a programação de jogos. Já programou em Basic, C, C++, Dbase II, Clipper, VB, Delphi, Assembly, e atualmente, C#. Hoje encontra-se envolvido com o projeto Last Energy, um shoot’em up 3D. http://www.jogospro.com.br

Sushi Miaou http://www.wabyanko.com

SW Breakout http://www.programming.de/palm.php

Sites e Links Super Waba http://www.superwaba.com.br SDL http://www.libsdl.org/index.php NOVEMBRO 2004

 JOGOSPRO e-magazine

ARTIGO Exemplo de Código: Jogo Ping.java gameDoClearScreen = CLEAR_SCREEN; gameHasUI = HAS_UI; setBackColor(Settings.isColor ? new Color(102,255,255):Color.WHITE);

import superwaba.ext.xplat.game.*; import waba.fx.*; import waba.sys.*; import waba.ui.*; import superwaba.ext.xplat.util.props.*;

MainWindow.defaultFont = MainWindow.defaultFont.asBold();

public class Ping extends GameEngine { // game API setup parameters

// inform the system to remove any delays when reading the keys waba.sys.Vm.interceptSystemKeys(waba.ui.IKeys.

PAGE_UP | waba.ui.IKeys.PAGE_DOWN | waba.ui.IKeys.HARD1 | waba.ui.IKeys.HARD2); }

protected final static boolean ARCADE_GAME = true; protected final static boolean WAVE_SUPPORT = false; // you may change these 3 boolean values to experiment the game engine // different drawing strategies. protected final static boolean protected final static boolean protected final static boolean 26 protected final static boolean protected final static boolean

DBL_BUFFERED = true; CLEAR_SCREEN = true; USE_BACKGROUND = false; //fdie@420_ SPRITE_BKGD_SAVING = false; HAS_UI = false;

/** * overrideable function called by the framework when the game starts.<br> */ public void onGameInit() { // get the high scores highScores=getHighScores(); // access the settings ‘username’ & ‘sound’ properties // if the properties do not yet exist, use the specified default values

// Increase the game level each time the scores is a multiple of 128 private final static int SCORE_NEXT_LEVEL=128;

settings=getOptions();

// Ball speed increase of 10% at each level private final static int SPEED_INCR_PERC=10;

optUserName = settings.declareString (“userName”,”noname”); optSound = settings.declareBoolean (“sound”,false);

// Racket move speed when controlled with the keyboard private final static int RACKET_SPEED=7;

// set the racket X coordinate which will remain constant racketX=Settings.screenWidth-8;

// reduce the game playground to display the game level and score protected final static int GAME_MINY=12;

// we need 1 racket and 1 ball

// game level & score private int level,score;

racket = new Racket (RACKET_SPEED); ball = new Ball (this,racket);

// racket position private int racketX,racketY;

// create two text renderers, one for the ‘level’ and one for the ‘score’ // we use the current font, the text should be black. // Level value display has 2 and score has 5 digits.

// define the game sprites private Racket racket; private Ball ball;

levelRenderer=createTextRenderer(getFont(),Color.BLACK,”level: “,2,false); scoreRenderer=createTextRenderer(getFont(),Color.BLACK,”score: “,5,true);

// 2 text renderers to quickly display level and score values private TextRenderer levelRenderer; private TextRenderer scoreRenderer;

// load game animated logo logo=new AnimLogo();

// define 2 game settings, // by declaring them static they can be accessed in all classes. protected static Properties.Str optUserName; protected static Properties.Boolean optSound;

}

/** * Game logo accessor. * @return game logo */ Animation getAnimLogo() { return logo; }

// the high scores and settings Options settings; HighScores highScores; // little animation sample private AnimLogo logo; /** * Ping constructor. */ public Ping() { waba.sys.Settings.setPalmOSStyle(true); // adjust attributes gameName = “Ping”; // when not run on device, appCreatorId does not always return the same value. gameCreatorID = Settings.onDevice ? waba.sys.Settings. appCreatorId:”PiNg”; gameVersion = 100; gameHighscoresSize = 7; gameRefreshPeriod = ARCADE_GAME ? 75 : NO_AUTO_REFRESH; gameIsDoubleBuffered = DBL_BUFFERED; http://www.jogospro.com.br

// display the introduction screen showIntroduction();

/** * overrideable function called by the framework when the game exits.<br> * Nothing to do here, the previously accessed Options/Highscores * databases are automaticaly closed by the framework. */ public void onGameExit() { } /** * overrideable function called by the framework when the game starts running. * The game is stopped by the the framework run() function. * (re)intialize the game before the start. */

NOVEMBRO 2004

JOGOSPRO e-magazine



ARTIGO Exemplo de Código: Jogo Ping.java public void onGameStart() { onBounce();

}

{

// reset the racket position & the ball settings (position & speed) racket.setPos(racketX,racketY=Settings.screenHeight>>1,false); ball.reinit(); level=score=0;

public void onBounce() { if (USE_BACKGROUND) { // pass null to disable an automatic background displaying useBackground(logo.nextFrame()); //fdie@420_26 } }

// we got a pen event, store the Y coordinate as the next racket Y position racketY=evt.y; // refresh the racket position racket.setPos(racketX,racketY,true);

}

/** * overrideable function called by the framework when the game stops running.<br> * The game is stopped by the the framework stop() function.<br> */ public void onGameStop() { // when the game stops, popup the GameOver window swap(GameOver.getInstance(this,highScores,score,optUserName. value)); } /** * overload Superwaba’s painting function. * @param gfx Graphics to draw at. */ public final void onPaint(Graphics gfx) { if (gameIsRunning) { int sk = Vm.getSystemKeysPressed(); if (sk != 0) { if ((sk & (Vm.SK_PAGE_UP | Vm.SK_HARD1)) != 0) racket.move(true); if ((sk & (Vm.SK_PAGE_DOWN | Vm.SK_HARD2)) != 0) racket.move(false); }

/** * overrideable function called by the framework when the pen moves.<br> * @param evt */ public final void onPenDrag (PenEvent evt) { // we got a pen event, store the Y coordinate as the next racket Y position racketY=evt.y; // refresh the racket position and cancel the keyboard mode racket.setPos(racketX,racketY,true);

}

}

// draw the ball ball.show(); // Increase the game level each time the scores is a multiple of SCORE_NEXT_LEVEL if ((score & SCORE_NEXT_LEVEL-1) == 0) { // increase the level and the ball speed level++; ball.increaseSpeed(SPEED_INCR_PERC); }

/** * display the game ending screen (hiscores screen). */ public void showHighScores() { swap(GameOver.getInstance(this,highScores,0,null)); }

score++; // render level & score levelRenderer.display(16,2,level,false); scoreRenderer.display(Settings.screenWidth>>1,2,score,false);

/** * overrideable function called by the framework when the pen touches the screen.<br> * @param evt event that occurs. */ public final void onPenDown (PenEvent evt) http://www.jogospro.com.br

// if non arcade game is selected, redrawings have to be called explicitly. if (!ARCADE_GAME) refresh();

Container blankContainer; /** Creates and places a blank container in the screen. */ public void blankScreen() { if (blankContainer == null) { blankContainer = new Container(); blankContainer.setRect(getRect()); blankContainer.setBackColor(backColor); } swap(blankContainer); }

// move the ball, that’s the hard work ball.move();

}

// if non arcade game is selected, redrawings have to be called explicitly. if (!ARCADE_GAME) refresh();

/** * overrideable function called by the framework when a key is pressed.<br> * @param evt */ public final void onKey (KeyEvent evt) { if (evt.key==IKeys.PAGE_UP || evt.key==IKeys.UP) racket.move(true); else if (evt.key==IKeys.PAGE_DOWN || evt.key==IKeys.DOWN) racket.move(false);

// redisplay the racket racket.show();

}

// if non arcade game is selected, redrawings have to be called explicitly. if (!ARCADE_GAME) refresh();

}

/** * display the game introduction screen. */ public final void showIntroduction() { Introduction.swapTo(this); }

NOVEMBRO 2004

JOGOSPRO e-magazine

por Bruce “Sinner” Barrera

ARTIGO

Introdução ao Desenvolvimento de Jogos com

BREW & OpenGL / ES

Demorou um pouco, mas finalmente surgiu a necessidade dos dispositivos móveis terem suporte a aplicativos e jogos 3D. O OpenGL há anos é um padrão da indústria de games por ser suportado diretamente pelo hardware gráfico e além de ser gratuito e multiplataforma. Nada mais natural que houvesse uma implementação dele para celulares e handhelds, surgindo assim o OpenGL/ES (ES de Embedded Systems). Em 2000 foi fundado um consórcio representado pelas grandes companhias do mercado (Nvidia, ATI, 3dLabs, SGI, Sun...), chamado Khronos Group, com o intuito de criar padrões de APIs abertas para inúmeros tipos de mídia e dispositivos. Felizmente, incluído nesse meio, estava o OpenGL/ES e os dispositivos móveis.

L

ançado em 2003, o OpenGL/ES foi definido com um subconjunto do OpenGL. Mas não se iluda, praticamente todas as funções mais importantes da funcionalidade fixa do OpenGL estão presentes no OpenGL/ES apesar das limitações de memória e processamentos dos dispositivos móveis atuais. Mesmo com essas limitações é possível escrever bons jogos para celulares e PDAs e para os desenvolvedores independentes isso até se torna uma vantagem, pois equipamentos limitados não permitem tecnologias de ponta nem gráficos “top quality”, o que permite que pequenas equipes sejam capazes de desenvolver bons jogos e até concorrer com as ditas “grandes” do mercado.

Como o OpenGL/ES é um padrão, várias implementações dele estão disponíveis para diversas plataformas. Nesse artigo procurarei mostrar como montar um pequeno framework funcional do OpenGL/ES em conjunto com a plataforma BREW, desenhar algumas figuras geométricas, receber interação do teclado, trabalhar com timers e eventos do BREW e a partir desse ponto, onde procurar mais informações para que o leitor seja capaz de desenvolver seus próprios games e entrar para o mundo cobiçado do 3D na palma da sua mão!

Iniciando

A primeira coisa que o leitor deve fazer para começar o desenvolvimento é instalar o SDK da BREW. Ele é gratuito e pode ser baixado em https://brewx.qualcomm.com/brew/sdk/ download.jsp?page=dx/3.0.

Nessa edição existe um ótimo artigo do Matías Rodriguez sobre como instalar, http://www.jogospro.com.br

configurar o SDK e até mesmo prepará-lo para utilização conjunta com o Visual Studio 6.0 da Microsoft, por isso não estarei entrando em detalhes nesse tópico.

Além do SDK propriamente dito e do Visual Studio Add-On, será necessário também baixar e instalar a extensão do BREW para o OpenGL/ES. Essa extensão pode ser obtida em: https://brewx.qualcomm.com/brew/ sdk/download.jsp?page=dx/devmisc Descompacte o arquivo em uma pasta qualquer e :

 Mova a pasta inc para a respectiva pasta inc do SDK do BREW.

 Mova a pasta src para a respectiva pasta src do SDK do BREW.

 Mova a dll que está na pasta BREW.3.x para a pasta bin\modules do SDK do BREW

 Mova todos os arquivos da pasta devices para a pasta devices do SDK do BREW.

Para testar no emulador a aplicação gerada, escolha o device BlackCap16, atualmente o único device no emulador que dá suporte ao OpenGL/ES. Voltando à parte técnica, quem está acostumado com a programação do PC tomará um susto a princípio, quando NOVEMBRO 2004

SkyBox no OpenGL/ES descobrir a quantidade de limitações que existem na programação de celulares e PDAs. Verá que não tem milhares de bytes de memória, que não há váriáveis globais nem estáticas (!) e que é tudo baseado em timers e eventos. Mas calma, apesar das dificuldades aparentes não é tão dificil quanto aparenta ser.

As variáveis globais foram pro espaço, e agora ?

Os leitores mais perceptivos a essa altura já estarão se perguntando: se não há variáveis globais nem estáticas como reproduzir suas funcionalidades ? Como criar uma classe global que conterá a lógica do meu game ou aplicativo ?

A plataforma BREW armazena uma struct global para nós, struct essa que obrigatoriamente deve conter como primeiro membro uma outra struct do tipo AEEAplet.

Mas após ela, podemos armazenar qualquer tipo de dados que quisermos. Essa struct global é gerada automaticamente pelo wizard de criação de aplicações (para quem JOGOSPRO e-magazine



ARTIGO usa Visual Studio) e geralmente possui o mesmo nome da aplicação. Veja a criação dessa estrutura e a alocação de um ponteiro para ela no corpo da função AEEClsCreateInstance. Esse ponteiro será passado como parâmetro para a maioria das funções utilizadas por nós.

Seguindo o paradigma da Orientação a Objetos como boa prática de programação, vamos criar uma classe CGame, e acrescentá-la a essa estrutura global do BREW. Essa classe conterá a lógica do nosso jogo conforme mostra o código abaixo: // opengl_1.cpp Efeito de Blur Efeito de Wave texturizado struct opengl_1 { // game.cpp AEEApplet a; // a estrutura obrigatória do BREW boolean CGame::Create(IShell * shell, IDisplay * display) CGame m_Game; // nossa classe do jogo { int m_OldTime; // usado para calcular a velocidade do game m_Shell = shell; }; m_Display = display; Abaixo segue o cabeçalho da nossa classe CGame. Observe a estrutura AEEDeviceinfo que contém diversas informações do celular incluindo o tamanho da tela, sua altura e largura . Essas informações podem ser usadas para adaptar nosso jogo aos mais diversos celulares existentes mudando o tamanho da tela utilizada em run-time, evitando a recompilação do game e facilitando sua distribuição.

return TRUE;

void CGame::Destroy() { } A função DBGPRINTF (Debugger printf) serve para escrevermos texto no painel output do debugger do Visual Studio. Para isso devemos incluir AEEStdLib.h no programa.

// estrutura que contém informações do celular AEEDeviceInfo m_DeviceInfo;

Timers e Eventos A programação no BREW é event-based ou seja, baseado em eventos disparados pela plataforma BREW. Nesse tipo de programação o desenvolvedor deve criar funções de callback que respondem e fazem certas ações dependendo do evento em questão. Se alguma função entrar em loop, o BREW detecta e restarta o dispositivo para evitar deadlock.

public:

// métodos de criação da nossa classe boolean Create(IShell * shell, IDisplay * display); void Destroy(); // o método que sera chamado pelo evento de timer void Tick(int timeElapsed);

Mas como simular um jogo normal, onde geralmente se tem um loop principal onde são feitas as atualizações do elementos do jogo, tratamento de inputs, etc ? A resposta é simples e direta: Através de eventos. Tudo na plataforma BREW é feito através de eventos que são disparados em situações específicas. Ao clicar uma tecla do celular, por exemplo, um evento KeyPress é disparado. Então para simularmos o loop principal de um jogo vamos usar o evento de timer.

// métodos para retornarem os atributos da classe IShell * getShell() { return m_Shell; } IDisplay * getDisplay() { return m_Display; } { return m_DeviceInfo.cxScreen; } { return m_DeviceInfo.cyScreen; }

O trecho de código abaixo mostra parte da implementação da classe CGame, seus métodos de criação e liberação de recursos.

Essas classes devem ser chamadas dentro das funções criadas com o wizard, opengl_1_InitAppData e opengl_1_FreeAppData, respectivamente. Essas duas funções recebem o ponteiro para a estrutura global do BREW, então o acesso à nossa classe CGame é bem fácil. http://www.jogospro.com.br

DBGPRINTF(“ *** Width %d, Height %d”, GetWidth(), GetHeight()); }

// game.h class CGame { private: // ponteiro para ter acesso às funcionalidades do celular IShell * m_Shell; IDisplay * m_Display;

int getWidth() int getHeight() };

// obtem as informações do celular mDeviceInfo.wStructSize = sizeof(mDeviceInfo); ISHELL_GetDeviceInfo(m_Shell, &mDeviceInfo);

Para usarmos o evento de timer, vamos criar uma função de callback que reproduzirá o que faríamos dentro de um loop do jogo. Vamos colocar dentro da nossa classe CGame o método Tick(int elapsedtime) que será invocado sempre que o timer disparar o evento. Esse método é que será responsável por simular o loop principal do jogo.

Para configurarmos o timer do BREW, utilizamos a função ISHELL_ SetTimer. Ela recebe quatro parâmetros, um ponteiro para o ISHELL da aplicação, de quanto em quanto tempo o timer será acionado em

NOVEMBRO 2004

JOGOSPRO e-magazine



ARTIGO TickTime é uma constante usada na função SetTimer. Agora só falta ativar o timer pela primeira vez, pois todas as vezes subsequentes serão ativadas pela própria função SetTimer.

Para isso coloque uma chamada da função no método opengl_1_HandleEvent, criado pelo Wizard. Adicione uma chamada a SetTimer no case EVT_APP_START. Esse case é avaliado quando a aplicação é iniciada.

O cubo girando rodando no emulador

Resolvendo o problema com o Fixed Point Math

Os chips ARM que estão na maioria dos dispositivos que suportam o BREW, não suportam operações aritméticas de ponto-flutuante.

Eles usam um formato chamado Fixed Point Math 16.16. É como pegar uma variável de 32 bits e utilizar seus 16 primeiros bits para parte inteira do número e os 16 restantes para a parte fracionária. Para converter um int para 16.16, basta fazer um shift esquerdo de 16 bits. Um shift direito converte de volta para inteiro. Basta setar uma macro e não se preocupar mais com isso: // int to 16.16 macro #define ITOFP(x) ((x)<<16)

Recebendo Input do usuário

milisegundos, um ponteiro para a função de callback e um ponteiro (void *) que receberá qualquer dado extra que você quiser passar para a rotina de callback. void SetTimer(test_project1 * data) { int result = ISHELL_SetTimer(data->m_Game.GetShell(), TickTime, timer_tick, static_cast < void * > (data));

}

if (result != SUCCESS) { DBGPRINTF(“ *** SetTimer failed”); }

int TimeElapsed = GETUPTIMEMS() - tp1->m_OldTime; tp1->m_OldTime = GETUPTIMEMS();

Resta agora criarmos os métodos KeyPressed e KeyRelease na nossa classe CGame. Esses métodos guardarão as teclas pressionadas no vetor m_KeysDown que possui um tamanho igual a AVK_LAST – AVK_FIRST que são constantes que definem os códigos virtuais das teclas do dispositivo. AVK_FIRST não necessariamente é igual a zero.

tp1->m_Game.Tick(TimeElapsed); SetTimer(tp1);

A função GETUPTIMEMS() retorna o tempo que o dispositivo esteve ligado em milisegundos. É semelhante à função GetTickCount da API do Win32.

Para fazer a função de callback ser chamada na proporção de frames por segundo que você desejar, calcula-se dessa maneira: const int WantedFPS = 20; const int TickTime = 1000 / WantedFPS; http://www.jogospro.com.br

// opengl_1.cpp handle event ... case EVT_KEY_PRESS: pMe->m_Game.KeyPressed(wParam); return TRUE; case EVT_KEY_RELEASE: pMe->m_Game.KeyReleased(wParam); return TRUE; ...

void timer_tick(void * data) { test_project1 * tp1 = static_cast < test_project1 * > (data);

}

Toda vez que o usuário aperta um tecla, um evento é disparado para ser tratado pela função tratadora de eventos, a opengl_1_HandleEvent. Cabe a nós desenvolvedores colocarmos uma chamada a nossa função de tratamento do teclado, após os cases EVT_KEY_PRESS e EVT_KEY_RELEASE:

// game.h class CGame { ... boolean m_KeysDown[AVK_LAST - AVK_FIRST]; ... void KeyPressed(int keyCode); void KeyReleased(int keyCode); ...

NOVEMBRO 2004

JOGOSPRO e-magazine



ARTIGO Comparação entre as outras tecnologias e o OpenGL ES

OpenGL ES finalmente!

Depois de nos preocuparmos com a infraestrutura do jogo, deixemos a parte chata de lado e vamos ao que interessa: 3D com OpenGL ES! Quem já conhece o OpenGL bem, não terá dificuldades para se integrar ao OpenGL/ ES já que praticamente todo o conhecimento se traduz para ele. Esse artigo assume que o leitor já possui um certo conhecimento de OpenGL e não estarei explicando o funcionamento dos comandos básicos.

Uma das primeiras diferenças a ser notada, é a sufixo do nome das funções.

No PC nós usávamos letras que designavam o tipo do parâmetro recebido por cada função. Era i para integer, f para float, v para vetores, etc. Como os tipos de dados no BREW são limitados, estaremos usando na maior parte do tempo o Fixed Point Math, que recebeu o sufixo x no lugar do float.

Então teremos a seguinte tradução: glRotatef -> glRotatex, por exemplo.

Outra diferença significativa que os desenvolvedores irão logo notar, diz respeito a forma de envio de vértices para o pipeline de renderização. O OpenGL ES apenas possui o modo imediato de envio de vértices através da função glDrawElements que envia um buffer de vértices de uma vez só, para aumentar a eficiência e performance. Portanto o desenvolvedor precisará fazer uma pequena revisão de como utilizar glVertexPointer, glColorPointer, glNormalPointer pois provavelmente está acostumado com o par glBegin...glEnd e a função glVertex.

Para utilizar o OpenGL/ES no seu jogo ou aplicativo é necessário adicionar o cabeçalho IGL.h e o arquivo GL.c, ambos encontrados nos diretórios inc e src do SDK. Eles possuem os protótipos das funções do OpenGL/ES. Iremos manter o paradigma da Orientação a Objetos e criar uma classe apenas para o gerenciamento da renderização. http://www.jogospro.com.br

Ela se chamará Renderer e pode ser vista abaixo: // From Renderer.h class Renderer { private: IGL * mIGL; IEGL * mIEGL; EGLDisplay mDisplay; EGLConfig mConfig; EGLSurface mSurface; EGLContext mContext; public: boolean Create(IShell * shell, IDisplay * display); void Destroy(); void FlipToScreen(); }; IGL é a interface do seu programa com o OpenGL. EGL é uma camada específica do BREW para ficar entre o IGL e a arquitetura da plataforma. Os demais atributos guardam informações do vídeo, configurações do modo de vídeo, a superfície de renderização e o estado das variáveis do OpenGL (context).

Inicialização da Classe de Renderização

A rotina de inicialização da classe instancia as interfaces e checa para ver se algum erro ocorreu, para evitar travamento do dispositivo móvel.

NOVEMBRO 2004

JOGOSPRO e-magazine



ARTIGO Bool Renderer::Create() { if (ISHELL_CreateInstance(shell, AEECLSID_GL, (void **)&mIGL) != SUCCESS) { Destroy(); return FALSE; } if (ISHELL_CreateInstance(shell, AEECLSID_EGL, (void **)&mIEGL) != SUCCESS) { Destroy(); return FALSE; } IGL_Init(mIGL); IEGL_Init(mIEGL); mDisplay = eglGetDisplay(display); if (mDisplay == EGL_NO_DISPLAY) { Destroy(); return FALSE; } EGLint major = 0; GLint minor = 0; if (eglInitialize(mDisplay, &major, &minor) == FALSE) { Destroy(); return FALSE; }

Livro “OpenGL ES Game Development” recém lançado

DBGPRINTF(“ *** ES version %d.%d”, major, minor); GLint numConfigs = 1; if (eglGetConfigs(mDisplay, &mConfig, 1, &numConfigs) == FALSE) { Destroy(); return false; } IBitmap * DeviceBitmap = NULL; IDIB * DIB = NULL; if (IDISPLAY_GetDeviceBitmap(display, &DeviceBitmap) != SUCCESS) { Destroy(); return FALSE; } if (IBITMAP_QueryInterface(DeviceBitmap, AEECLSID_DIB, (void**)&DIB) != SUCCESS) { IBITMAP_Release(DeviceBitmap); Destroy(); return FALSE; } mSurface = eglCreateWindowSurface(mDisplay, mConfig, DIB, NULL); IDIB_Release(DIB); IBITMAP_Release(DeviceBitmap); if (mSurface == EGL_NO_SURFACE) { Destroy(); return FALSE; }

Não esqueça de limpar a bagunça

Antes de irmos para a parte mais interessante, um lembrete.

Estamos usando um dispositivo altamente limitado, com memória reduzida. Então não esqueça de criar um método CRenderer::Destroy() onde limparemos todas as interfaces e ponteiros criados no processo de incialização. Esse método deve ser sempre chamado ao fim do nosso jogo ou aplicativo.

Consulte o código fonte para ver como isso é feito.

Até que enfim a tela deixará de ser preta

mContext = eglCreateContext(mDisplay, mConfig, NULL, NULL); if (mContext == EGL_NO_CONTEXT) { Destroy(); return FALSE; } if (eglMakeCurrent(mDisplay, mSurface, mSurface, mContext) == FALSE) { Destroy(); return FALSE; } } http://www.jogospro.com.br

Esse método também inicializa o display e obtém a versão do OpenGL/ES instalada (variáveis major e minor). Depois de mostrar no output do debug a versão atual, obtém a configuração do display e depois obtém um “device bitmap” que será onde será desenhado a saída do OpenGL/ES (Front Buffer).

Feito isso, está na hora de criar um surface de renderização, usando as informações do display e configuração, coletadas antes. Esse surface de renderização será associado com o device bitmap e se transformará no que o OpenGL comum chamaria de device context. (geralmente a GDI do Windows). Por fim, cria um context de renderização, exatamente como o OpenGL normal faz e diz pro OpenGL/ES colocar como target de renderização o display, config, context e surface criados. Se conseguirmos chegar até aqui sem erros, a infra-estrutura toda do OpenGL/ES e do nosso framework estará montada, vindo agora a parte mais divertida, a de desenhar!

NOVEMBRO 2004

Como última parte desse artigo, vamos desenhar um cubo girando. Apesar de ser um exemplo simples, mostra na prática como fazer uma pequena animação e desenhar uma figura geométrica usando o Immediate Mode do OpenGL/ES. Antes de desenhar, vamos ver como fica a implementação da troca do back buffer com o front buffer, o famoso SwapBuffers do OpenGL: void Renderer::FlipToScreen() { glSwapBuffers(mDisplay, mSurface); } JOGOSPRO e-magazine



ARTIGO A rotina anterior troca o que está desenhado no surface de renderização (back buffer) com o display do celular ou PDA (front buffer). Agora que o leitor já sabe enviar o render para a tela, vamos ao código OpenGL puro para desenho de um cubo girando. Esse código está no método CGame::Tick() que se encarrega de desenhar na tela toda vez que o timer é acionado.

Demo de Environment Map feito pela NVidia

void CGame::Tick(int timeElapsed) { glClear( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT ); glPushMatrix(); glLoadIdentity(); glTranslatex(0,0, ITOFP(-15)); if (mRotateAngle > 360) mRotateAngle = 0; glRotatex(ITOFP(mRotateAngle), ITOFP(0), ITOFP(1), ITOFP(0)); glRotatex(ITOFP(45), ITOFP(1), ITOFP(0), ITOFP(0)); int FaceData[24] = { // cubo -ITOFP(2), ITOFP(2), ITOFP(2), ITOFP(2), ITOFP(2), ITOFP(2), ITOFP(2), -ITOFP(2), ITOFP(2), -ITOFP(2), -ITOFP(2), ITOFP(2), -ITOFP(2), ITOFP(2), -ITOFP(2), ITOFP(2), ITOFP(2), -ITOFP(2), ITOFP(2), -ITOFP(2), -ITOFP(2), -ITOFP(2), -ITOFP(2), -ITOFP(2) };

Observe o uso de uma nova constante, o GL_FIXED para dizer para as funções que os números estão usando o Fixed Point Math do BREW. Por último nós trocamos os buffers, efetivando o desenho na tela através da chamada do método FlipScreen() do objeto Renderer. O trecho de código que vem logo a seguir usa apenas a API do BREW para escrever texto na tela, nesse caso, a quantidade de FPS em que o programa está rodando.

int ColorData[32] = { // First to eighth vertex color ITOFP(1), ITOFP(0), ITOFP(0), ITOFP(0), ITOFP(0), ITOFP(1), ITOFP(0), ITOFP(0), ITOFP(0), ITOFP(0), ITOFP(1), ITOFP(0), ITOFP(1), ITOFP(1), ITOFP(1), ITOFP(0), ITOFP(1), ITOFP(0), ITOFP(0), ITOFP(0), ITOFP(0), ITOFP(1), ITOFP(0), ITOFP(0), ITOFP(0), ITOFP(0), ITOFP(1), ITOFP(0), ITOFP(1), ITOFP(1), ITOFP(1), ITOFP(0) }; uint8 IndexData[36] = {

Conclusão

Esse artigo montou um pequeno framework suficiente para o leitor já poder começar a fazer pequenos jogos em 3D e que respondam a interface do usuário. Um tópico não abordado foi o de som com o BREW, possivelmente assunto para um próximo artigo. O código-fonte do framework pode ser encontrado para download no site da revista (www.jogospro.com.br) e foi preparado no Microsoft Visual Studio .NET 2003. Qualquer dúvida usem o tópico do artigo  na seção da Revista no fórum do site. Até a próxima.

0, 1, 2, 0, 2, 3, //front face 4, 5, 1, 0, 1, 5, //top face 3, 2, 6, 7, 3, 6, //bottom face 5, 4, 7, 6, 5, 7, //back face 1, 5, 6, 2, 6, 5, //right face 4, 0, 3, 7, 4, 3}; //left face

Bruce “Sinner” Barrera

glVertexPointer(3, GL_FIXED, 0, FaceData); // Set the vertex (position) data source glColorPointer(4, GL_FIXED, 0, ColorData); // Set the color data source glDrawElements(GL_TRIANGLES, 36, GL_UNSIGNED_BYTE, IndexData); // Draw the triangle glPopMatrix();

É desenvolvedor profissional e atualmente trabalha com visualizações 3D de estruturas de concreto para engenharia.

Também está desenvolvendo uma engine e ferrramentas para jogos 3D. Pretende se candidatar a uma vaga no concurso do Ministério da Cultura (JogosBR).

Quando não está programando, está programando.

Veja Mais m_Renderer.FlipToScreen(); AECHAR buffer[16]; WSPRINTF(buffer, 16, L”FPS: %d”, 1000 / timeElapsed); IDISPLAY_DrawText(mDisplay, AEE_FONT_BOLD, buffer, -1, 5, 5, NULL, 0); IDISPLAY_Update(mDisplay); }

Concurso de OpenGL ES patrocinado pela Qualcomm http://www.gamedev.net/community/contest/qualcomm2004/ OpenGL ES Oficial Site http://www.khronos.org/

// atualiza o angulo de rotação do cubo mRotateAngle += 1;

Site da Qualcomm sobre o OpenGL ES http://www.cdmatech.com/solutions/products/opengles_overview.jsp

No código acima é possível ver os elementos novos do OpenGL/ES: o uso das funções glRotatex e glTranslatex que usam o Fixed Point Math do BREW. Observe que todos os valores me ponto flutuante foram convertidos usando a macro ITOFP. O vetor FaceData guarda as coordenadas de todos os vétices que compõe o cubo e o índice de duas faces são guardados no vetor IndexData. O ColorData guarda as cores de cada vértice.

Com as funções glVertexPointer e glColorPointer nós enviamos os dados para o buffer do OpenGL que por sua vez envia para o pipeline através da função glDrawElements. http://www.jogospro.com.br

Livro OpenGL ES Game Development por Dave Astle and Dave Durnil http://www.gamedev.net/columns/books/bookdetails.asp?productid=425

NOVEMBRO 2004

Nvidia HandHeld SDK baseado no OpenGL ES http://developer.nvidia.com/object/hhsdk_home.html Forum Oficial da Qualcomm sobre OpenGL ES http://brewforums.qualcomm.com/forumdisplay.php?f=49 Demos de OpenGL ES http://www.hybrid.fi/main/esframework/demos.php JOGOSPRO e-magazine

Simpósio Brasileiro de Jogos para Computador e Entretenimento Digital

O SBGames aconteceu em Curitiba, nos dias 20 e 21 de outubro. E a JogosPRO foi lá conferir o maior evento de jogos do Brasil.

Olha nós aqui!

Jogo: Erinia Phillipe Kling David e André Kling David

Jogo: Gods of the Virtual Boards Mariana Stephani e Renato Klieger Gennari

Scylla Cabral da Costa Neto e Jefferson Valadares ambos da Jynx Playware

Jogo: Pequeno Guardião do Tempo Autor: Luis Ernesto

Jogo: Edugraph Autor: Rafael Pereira Dubiela

Hora do lanche!

Esse pessoal vive no mundo da Lua. Luiz Henrique de Figueiredo no tutorial “A Linguagem LUA e suas Aplicações em Jogos”

Representantes das principais empresas de jogos do Brasil marcando presença: Continuum, South Logic e Ignis Games.

O Spy (também conhecido como Rodrigo), na palestra “Desenvolvendo Jogos com Ferramentas de Software Livre”

Galera se preparando para assistir o Festival de Jogos Independentes

Organizadores do Festival de Jogos Independentes contabilizando os votos dos três finalistas.

Veja várias outras fotos do evento no site (www.jogospro.com.br) Todas as fotos por Matias Rodriguez.

Momento artístico do nosso fotográfo.

+Um momento artístico do nosso fotográfo.

por Fabrício Kolk Carvalho

FIM DO JOGO

Criatividade nos Jogos Criatividade. O que é criatividade?

Criatividade é o fator diferencial de qualquer jogo.

Higinbotham. Ele foi o precursor dos jogos. Criou todo um novo universo, com o uso de um osciloscópio e muita imaginação.

explica a P.N.L. (programação neuro lingüística), tente, ao receber um estímulo (uma música por exemplo) interpretá-lo com outros sentidos (essa técnica foi usada para criar o filme “Fantasia” da Disney, que é o mapeamento de uma composição musical).

O que seria criatividade? Criatividade consiste na atividade Mas o mais importante, ao invés de ficar falando de de inventar. Percorrendo pelas páginas do Aurélio passado, é aplicar e desvendar o mistério da criatividade O importante é fazer a transição do lado esquerdo do achamos a seguinte definição para a palavra “invenção”: desses grandes Gurus dos Games. O grande mistério raciocínio para o lado direito, entrando em um estado é associar a todo instante o que quer que você esteja alterado de consciência. Para se atingir esse estado Invenção (do latim inventione) 5. Novo meio para se chegar fazendo, com jogos. Como por exemplo Miyamoto, o há varias maneiras. Ao estar mergulhado em alguma a um fim. inventor de “Link” e “Super Mario Bross”: “Conversando com meus colegas em papos do dia-a-dia, por exemplo, me atividade, isso costuma acontecer, tente a seguinte O fim é o jogo. O meio é a criatividade experiência: traz muitas idéias. As idéias podem vir até no meio de um Qualquer atividade onde algo novo é formado é chamado banho numa banheira quente!”

Coloque um CD que você goste bastante (de preferência de processo criativo. Com esse processo em vista, temos algo mais clássico, melódico ou instrumental. Evite Esses Game designers tem suas mentes livres para fazer dois tipos básicos de criatividade. A pura e a Aplicada. músicas cantadas). Olhe para a palma da sua mão associações a todo instante. Para isso ocorrer, primeiro por aproximadamente 7 minutos. Não dê atenção ao Criatividade pura: É o tipo de criatividade que todos você deve ser uma pessoa com poucos preconceitos. tempo. Sempre que pensar que isso é uma coisa idiota Não ficar ancorado a velhas idéias, ser mutante, nós temos. Consiste de fazer associações deliberadas de se fazer, olhe mais afundo e tente parar com esse constantemente atualizado. unindo coisas que não precisam ter um resultado lógico pensamento. Com a observação da palma da mão, ou aplicado. Geralmente os artistas utilizam esse conceito você começará a perceber a conexão das rugas, verá Muitas das idéias vêem às pessoas em sonhos. Isso para fazer os seus modelos. o universo que existe em cada traço. Você começará acontece por que enquanto sonhamos, desligamos os Criatividade aplicada: Nesse processo, pegamos fatores que inibem as nossas ações pragmáticas em nosso a pensar diferente. Ao se escutar uma música isso acontece com frequência também. todo o potencial da criatividade pura e canalizamos, cérebro. usando o conhecimento. Nesse estágio mais elaborado e O cérebro humano, pode ser dividido em duas grandes Antes de pensar no game design, roteiro, (etc.) de um complexo, que colhemos os frutos aproveitáveis. Frutos jogo, você tem que atingir esse estado. Então, sempre zonas. O lado esquerdo e o direito. Cada zona é como avanços tecnológicos de Engines, a originalidade responsável por um tipo diferente de processamento tente fazer esse exercício. Repita-o até que se sinta em um dos roteiros, os horríveis monstros, as novas técnicas de estado diferente de raciocínio. de informações e jogabilidade. raciocínio. O lado Quando começar a pensar Esses tipos de criatividade podem se formar de duas esquerdo, é o que diferente você está pronto para formas: leva mais ênfase na pensar sobre o seu jogo. Feche os nossa sociedade. É olhos e deixe a imaginação rolar.

1. Quando você cria tudo novo. Uma idéia totalmente o lado matemático, Visualize as suas fases, os seus original, baseada em nada, ou quase nada. Quando algo lógico, preciso, personagens, o jogo todo. desse nível surge, há um salto em todo o paradigma e detalhístico, preto e percepção. Você cria os tijolos. Cria a casa usando-os. branco, enfim, sem jogue-o na sua mente, passe graça. O lado direito pelas missões, escute a música de 2. Quando você cria usando ferramentas já utilizadas por é o artístico, surreal, Storyboard do jogo “Super Mario Bross”. fundo, derrote os inimigos. Você outros. Nesse caso, você tem os tijolos e monta a casa colorido, universal, irá arquitetar o seu jogo (em sua mente primeiro), livre do usando-os. Estas são as coisas na qual você se baseia para criativo. Quando dormimos, entorpecemos o lado obter o produto final já existente. esquerdo, e o direito fica livre para agir. Por isso muitas velho tipo de pensamento. Ao pensar em seu jogo comece a fazer o storyboard. Tome cuidado, idéias construídas idéias nos vêm durante o sono e por isso que temos O segundo processo, “menos” criativo, é o mais comum. sonhos muito bizarros, desvinculados de tempo, lógica nesse estado, geralmente são apagadas facilmente, pelo Isto porque muito já foi inventado, tornando cada vez mais e espaço. Ser criativo significa ver caminhos diferentes, fato de o lado esquerdo (memória) estar entorpecido.

Então, registre todas as idéias rapidamente. difícil o processo. ou seja, fora da lógica. Logo, usar mais o lado direito do cérebro. É capaz de você não criar um enredo como o de Nos tempos atuais, a falta de criatividade tem feito “Final Fantasy”, mas certamente você criará algo bem com que os Game designers dêem mais ênfase aos Certo. Já chegamos a um ponto. Mas e agora? Como melhor do que no estado normal de raciocínio. Com aspectos visuais do jogo, do que os da diversão, fazemos para entorpecer o lado esquerdo e aplicar o a prática, esse potencial criativo apenas cresce e se estratégia e originalidade. Sempre há lançamentos de potencial do direito na criação de jogos? fortalece. Não deixe essa oportunidade passar, Deixe a jogos anteriores, com apelo visual cada vez maior. Os game designer se sentem mais seguros apostando em Há inúmeras maneiras e ferramentas. Uma delas é muito imaginação rolar, Boa Criação! personagens já de sucesso do que arriscar novos. Desde os importante, era a usada por Mozart, Aristóteles, Walt Para maiores informações, se informe sobre o livro primórdios dos jogos essa aposta acontece, assim como disney, e é chamada de Sinestesia. Sinestesia consiste “Pong”, que foi cópia, e depois foi copiado. em interpretar sensações com outros sentidos, como por “Desenhando com o lado direito do cérebro”: exemplo, comer uma música, escutar uma pintura. É a As grandes inovações dependem do meio em que se vive. tentativa de interpretar estímulos usando outros sentidos Fabrício Kolk Carvalho A maior explosão criativa que se teve foi em 1958 com que não são destinados a essa interpretação. Assim como Site: http://btuliob.vilabol.uol.com.br http://www.jogospro.com.br

NOVEMBRO 2004

JOGOSPRO e-magazine