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

Conteúdo Projeto 3 Anima Project por Alexandre “Darkfenrir” Capa 6 Empresas Brasileiras de Jogos por Carlos H. Caimi Colunas 10 Java no desenvolvimento de jogos por Paulo R. C. Siqueira 14 Videogames no Cyberpunk de William Gibson por Alessandro Vieira dos Reis 16 Jogos Open Source: Utopia, modismo ou necessidade? por Julio Marchi Entrevista 19 Fábio Binder por Carlos H. Caimi Artigos 29 Introdução ao OpenGL Shading Language por Bruce “Sinner” 23 Iniciando no SDL por Daniel “NeoStrider” Monteiro 25 2D .NET games: Usando a GDI+ (Parte 1) por Wilson Jr. PostMortem 28 Postmortem do Harena por Matías G. Rodriguez Fim do Jogo 31 E o Futuro é logo ali por Carlos H. Caimi

Editorial Caros leitores Ao final de julho de 2004, surgiu na lista jogospro a idéia de criarmos uma revista para a comunidade de desenvolvedores de jogos do Brasil.

Foram quase 100 post na lista com prós e contras, e por fim, os mais empolgados resolveram concretizar a idéia.

E é com imensa satisfação que apresentamos a você, a primeira edição da primeira revista sobre desenvolvimento de jogos voltada para a comunidade brasileira. A JogosPRO e-Magazine a princípio, será bimestral.

Ela será distribuída gratuitamente por meio eletrônico e teremos um site para discutir e divulgar a revista.

Com a criação da revista pretendemos dar um passo importante para comunidade. Nosso sonho é tornar a revista uma referência nacional, bem como um canal para divulgação da indústria de jogos.

Nessa primeira edição, buscamos saber como anda as empresas brasileiras que já publicaram jogos no brasil, e fora dele, além de trazer artigos interessantes, entrevistas e muito material.

E por isso convidamos você, prezado leitor, a participar junto conosco desse grande projeto. Participe! Contribua com artigos, notícias, divulgue seu projeto, critique e dê sugestões para aprimorarmos sempre a nossa revista. Envie-nos cartas! O email é jogospro@jogospro.com.br.

Acesse o site e sinta-se a vontade.

- Carlos H. Caimi, Editor-Chefe

Anima Project

por Alexandre “DarkFenrir” “O que você acha de passar pela 3ª Guerra Mundial, ver o Sol explodindo anos luz de seu abrigo no fundo da terra, presenciar a idealização de uma civilização na superficie lunar, encarar desavenças políticas, e finalmente descobrir que seu colega lhe traiu por interesses únicos e egoístas... Lutar com armas e veiculos de ultima tecnologia, e simultaneamente derrotar um dragão vulcânico que varre inumeras tropas com seu halito flamejante ! Ou melhor ainda, descobrir que você esta sendo manipulado por uma mega corporação e pelo próprio governo no qual você trabalha !!! “.

Este é o mundo de Anima Project , um duelo de extremos, numa época em que a realidade que conhecemos está se redefinindo radicalmente, em uma saga que narra temas pouco explorados antes: a revolução das espécies, os elementos naturais a espécie humana, a eterna busca pela sobrevivência e seus desejos mais ancestrais... Como nasce uma civilização, sua tecnologia, suas crenças e valores, como ela se adapta ao mundo em que vive ! Numa guerra onde não existe nem certo, nem errado: apenas interesses contraditórios, onde o destino da nova Terra esta em jogo !!!

Assim surgiu o conceito que sustenta todo o contexto por trás desta incrivel aventura ! E lembre-se que você, é mais do que nunca, o personagem principal desta grande saga !!

>> CONCEPÇÃO DO PROJETO Anima Project é um novo produto de entretenimento criado para o mercado nacional, que vem a cada ano ganhando cada vez mais adeptos nessa grande forma de lazer. Mas o Anima Project não é apenas mais um RPG de mesa como tantos outros: ele explora um tema de ambientação pouco explorado até hoje nos RPG’s de mesa do ocidente, mas muito apreciado por jogadores de RPG’s eletrônicos e fãs de Anime / Mangá: o gênero “TecnoFantasy”, que mistura elementos da fantasia medieval com técnologia e elementos cyberpunk.

O mundo de Anima Project consiste no duelo de extremos, como por exemplo, a Tecnologia x Magia, numa guerra onde não existe nem certo nem errado, apenas interesses contraditórios...Tudo isso narrado numa história contada sob diversos pontos de vista, em um mundo novo repleto de tecnologia e misticismo.

O ANIMA PROJECT não ficara preso a um único tema: ele será explorado de diversas maneiras, num futuro próximo; O RPG de mesa, desenvolvido inicialmente para OGL/ D20 System, será o carro-chefe do projeto. E futuramente temos pretenção de apostar o conceito do projeto em outras mídias, como por exemplo jogos eletrônicos, mangás, novelbooks... >> RESUMO DA HISTÓRIA - Uma antiga profecia se concretizou, e o mundo dos homens entrou em colapso: guerras, desavenças e catástrofes naturais mudaram a vida dos habitantes da superfície terrestre..

- Devido a um estranho fenômeno ocorrido no sol, a temperatura terrestre começou a aumentar bruscamente, tornando-se impossível sobreviver nesta atmosfera; então os humanos, sem ter pra onde fugir, construiram um novo mundo: de baixo da terra.

- Mas nem todos puderam migrar para o subterrâneo: alguns radicalistas mais nobres construiram colônias no espaço e na Lua, e os menos afortunados ficaram a mercê da própria sorte, sobrevivendo a todo custo na hostil crosta terrestre.

- 1 milênio se passou, os humanos de Subteranea esque-

ceram-se do mundo antigo, os recursos minerais do subsolo estão se esgotando, então começa o plano de reconquista da superfície. O mesmo acontece com os habitantes de Seluna, que até então criaram uma nova civilização fora do planeta.

- Porem, os humanos de ambas as partes não esperavam se reencontrar, nem mesmo entenderam um fato: que o mundo estava se recriando, desde o principio dos tempos, mas habitado por estranhas e bizarras criaturas que só existiam em lendas e folclores, e também por uma legião de maquinas inteligentes.

- Muitas pessoas começaram a receber “contatos” com seres “divinos”, cujo foram banidos do mundo dos homens antes mesmo da existência de uma civilização humana.

- Ainda ha um fato mais extraordinário: uma nova variante de seres humanos, os “Alterados”, começou a repovoar a superfície. Porem eles alimentam uma profunda angustia em relação aos humanos do subterrâneo que abandonaram seus antepassados para apodrecer neste armagedom.

- Inicia-se uma guerra de reconquista da superfície deste mundo novo: humanos de Subteranea x humanos de Seluna x os Alterados de Cresta.

- O governo de Subteranea cria um audacioso projeto para a exaltação da raça humana: o

>> ANIMA PROJECT - GAME ANIMA PROJECT - ANOTHER REALITY é um game de RPG feito para plataformas PC. Ele utiliza o software RPG MAKER 2003, um programa especialmente feito para a criação de jogos deste gênero, semelhante aos clássicos da geração 16 bits (Megadrive e Super Nintendo), como por exemplo FINAL FANTASY, CRONO TRIGGER e PHANTASY STAR. Assim surgiu a idéia inicial de ANIMA PROJECT, a revolução das espécies, numa época em que a realidade que conhecemos está se redefinindo. O interessante é que esta saga é contada a partir do ponto de vista dos seres humanos originais, que sobreviveram a uma catástrofe no passado. Na verdade tinha-se como base inicial contar a hisstória a respeito de varias realidades paralelas, o surgimento de vários seres e divindades além da compreensão humana...

O jogo de PC, em RPG Maker, ainda está numa fase inicial de desenvolvimento, e em breve colocaremos no site mais versões DEMO, com mais de 1 hora jogável, para você conferir a respeito do game; e também colocaremos screenshots de algumas cenas do jogo para você ter uma idéia de como o game está sendo produzido.

Projeto Anima, que visa descobrir a verdade sobre o fato desta incrível mudança e a reconquista da superfície terrestre.

- Assim então são as novas raças envolvidas neste conflito : Teraneans (habitantes de Subteranea), Seluneans (habitantes da colônia da Lua), Alterados (os humanos mutantes que povoaram o novo mundo).

Futuramente temos o plano de fazer um jogo mais sério, com uma engine própria, feito para computadores de maior desempenho. Seguiremos os moldes de RPG’s multiplayer famosos, como Diablo, Phantasy Star Online e Ragnarock. Para isso negociaremos com alguma softhouse que se interesse pelo potencial do projeto.

O site disponibiliza no momento a versão DEMO 1.0 do Game Anima Project, feito em RPG Maker 2003 Ver.1.08.

Até o final deste ano, pretendemos colocar a versão DEMO 2.0, com mais horas de jogo.

Equipe Anima Project 2004 Todos os direitos reservados

www.animaproject.make5.com.br contatoanima@make5.com.br

por Carlos Caimi

C

A

P

A

Empresas Brasileiras de Jogos

P

A difícil arte de desenvolver jogos no Brasil

orque desenvolver jogos? Existem muitas respostas para essa pergunta, mas nenhuma é tão completa quanto esta: Por Paixão! E é exatamente essa paixão que parece alavancar o mercado brasileiro de desenvolvimento de jogos. Apaixonados utilizam as horas vagas para desenvolvimento de jogos. Iniciando com um desenvolvimento caseiro, até um amadurecimento da idéia, e por fim, a realização de um sonho. Uma empresa de desenvolvimento de jogos.

No Brasil, quando se fala em desenvolvimento de jogos, fatalmente iremos tocar no nome de 3 empresas que obtiveram sucesso nessa empreitada. A Continuum, a South Logic e a Ignis são as brasileiras que conseguiram colocar seus jogos no mercado nacional e internacional. A JogosPRO entrou em contato com essas empresas para tentar descobrir o segredo do sucesso, e o que elas estão planejando para o futuro.

.:Entrevista South Logic JogosPRO: A Southlogic desenvolveu primeiro a Aspen Engine, depois o Jungle Demo. Só depois conseguiu patrocínio para o desenvolvimento de um jogo. Vocês recomendam essa estratégia ainda hoje?

Southlogic: Na verdade a empresa foi fundada em 1996, então fizemos o jogo Guimo, depois a tecnologia Aspen Engine e o jogo Aquarius e só depois fizemos o Jungle Demo.

Até os dias de hoje é muito comum desenvolver protótipos na hora de propor um projeto para um publicador. Muitos querem ter uma noção o mais precisa possível do que o desenvolvedor é capaz de fazer, e um protótipo é uma das formas de fazer isso. Infelizmente fazer um protótipo é a parte mais complexa e mais cara do processo de montar uma proposta de jogo.

JP: A Southlogic se chamava antes Jack in a Box, porque mudaram?

SL: Em 1996 o nome parecia bom para nós aqui no Brasil, mas no primeiro contato com os EUA já ouvimos comentários sobre a cadeira de restaurantes que usa o mesmo nome por lá. Para evitar confusão e qualquer tipo de problema legal ao entrar naquele mercado resolvemos alterar o nome da empresa. Acho que fizemos isso na hora certa.

JP: Hoje a Southlogic atua no mercado fora do Brasil, vocês pretendem http://www.jogospro.com.br

lançar um jogo aqui?

SL: O jogo Guimo, e recentemente o Deer Hunter 2004, foram lançados no Brasil. No momento atual, que desenvolvemos jogos de caça, a entrada desses produtos no mercado brasileiro é difícil por causa da baixa popularidade desse esporte por aqui. Esse tipo de produto tem como mercados principais os EUA e Canadá. Acredito que quando lançarmos outros gêneros de jogos a probabilidade deles serem amplamente distribuídos no Brasil vai aumentar.

Quanto a produzir um jogo especificamente para o mercado brasileiro, com conteúdo voltado para o mercado brasileiro, é uma questão de escalar o projeto de acordo com o orçamento disponível - que normalmente é baixo aqui.

Pessoalmente não acho a melhor estratégia, e você pode ver que os desenvolvedores de outros países sempre tentam desenvolver jogos de conteúdo o mais amplo possível para distribuição mundial e que inclui o Brasil.

JP: Vocês pretendem relançar o Guimo e o Aquarius? Ou uma nova versão desses jogos?

SL: Tenho vontade de portar o Guimo para Windows (atualmente o

jogo tem problemas de compatibilidade porque foi feito originalmente para DOS e Windows 95) e lançá-lo como freeware. Já o Aquarius, que chegou até uma versão beta, é um projeto bem maior e precisa ser reescrito praticamente do zero para virar um jogo com os novos padrões de mercado. Digamos que ele está “engavetado” até que alguém se in-

teresse por ele, e então poderemos finalizá-lo com a atenção que ele merece...

JP: O período que a Southlogic ficou incubada foi relevante para o crescimento da empresa?

SL: Com certeza foi uma das decisões mais certas que tomamos durante esses anos. Uma empresa desenvolvedora de jogos e tecnologia precisa sobreviver por um bom tempo sem ter faturamento até atingir um nível mínimo para realmente atuar no mercado. A incubadora S ET E M B R O 2 0 0 4

J O G O S P R O e-magazine

C nos permitiu ter esse tempo, que apesar das dificuldades, foi importantíssimo.

JP: Hoje vocês são desenvolvedores oficiais da plataforma XBOX. Esse é o caminho para manter a rentabilidade da empresa, ou de um jogo, PC + Console?

SL: O mercado de consoles é muito maior que o de PC, portanto os publicadores preferem jogos para consoles, e de preferência para PS2. Não tenho dúvidas que um desenvolvedor para console, ou até de múltiplas plataformas (inclusive PC), vai ter mais chances de fechar contratos nessa indústria. O nosso primeiro passo nessa direção foi com o Xbox, estamos tentando ampliar as possibilidades nessa direção. Infelizmente existem “percalços” nesse caminho por estarmos aqui no Brasil. Dá pra acreditar que em 2004 ainda aconteça isso?

JP: A pirataria no mercado nacional é impedimento para lançar um jogo aqui?

SL: Para os fabricantes de consoles é o motivo que essas plataformas não chegaram aqui. Quando eles vendem o hardware ele está sendo subsidiado pelo fabricante, ou seja,

ele está sendo vendido por um valor abaixo do que realmente vale. Os fabricantes de consoles ganham o seu dinheiro vendendo os jogos depois, e parece que esse modelo de negócio não funcionaria bem no Brasil por causa da pirataria. Infelizmente acho que um dos motivos daqueles “percalços” que comentei seja essa situação no http://www.jogospro.com.br

Brasil que deixa alguns fabricantes muito descontentes. O que isso tem haver com a seriedade do desenvolvedor de jogos brasileiro eu ainda não sei...

JP: O que vocês acham do mercado brasileiro de jogos? Tem Futuro?

SL: Acreditar no futuro do mercado de jogos brasileiro é acreditar no futuro do Brasil.

Sem um Brasil mais desenvolvido no sentido de empregos e poder aquisitivo não podemos esperar que um mercado de produtos “supérfulos” como os jogos evolua. Como todo brasileiro tenho muita fé que o Brasil vá se desenvolver nos próximos anos. Outros países já estão vendo o potencial de mercado aqui, e acho isso um indicador que as coisas vão melhorar. Talvez durante uma fase de transição, as empresas que publicam hardware e jogos devessem ajustar aquele modelo econômico no nosso mercado, provavelmente reduzindo suas margens de lucro.

JP: Teremos uma versão dos Hunter´s para console?

SL: Espero que sim, e também gostaria de ter versões de outros jogos para console!

JP: Qual os próximos passos da Southlogic?

SL: A nossa meta é enriquecer o portfólio da empresa com bons jogos e ir crescendo aos poucos, formando mais pessoal, e com projetos cada vez mais desafiadores. Não me importo tanto em qual a plataforma desenvolver, o mais importante para nós nesse momento é ter boas oportunidades de mostrar o nosso trabalho.

A

P

A

SL: Estudar a sua área de interesse e praticá-la. Nada melhor que a prática para fixar e aprimorar as suas técnicas. Atualmente os jogos estão se tornando projetos grandes, então conhecimento de de-

senvolvimento de sistemas de maior porte é importante (orientação a objetos, notação de código, documentação, etc). Também conhecer as ferramentas gráficas, de som e de desenvolvimento como ferramentas de controle de versão.

Ao mesmo tempo, você precisa se juntar a outras pessoas que se interessam por jogos e com habilidades complementares - os jogos são produtos criados por pessoas com conhecimentos multidisciplinares (arte, programação, design, administração, etc). E mais aquela clássica de sempre: ficar atento as oportunidades e ao que está acontecendo no mercado, para maximizar as chances de sucesso. E como não é um mercado fácil, recomendo uma boa dose de persistência e de dedicação. �

JP: Qual a mensagem que a vocês deixam para quem esta começando na área?

S ET E M B R O 2 0 0 4

J O G O S P R O e-magazine

C

A

P

A

.:Entrevista Continuum JogosPRO: A Continuum surgiu no ambiente acadêmico e depois consolidou-se como empresa para comercializar o Outlive. Vocês consideram essa estratégia, de desenvolver uma demo, buscar patrocínio e depois uma dedicação exclusiva na empresa, como a melhor opção ainda hoje no mercado brasileiro?

Continnum: Utilizamos esta estratégia como meio de dividir o risco do desenvolvimento com os publicadores, além de ser o modelo de negócios mais comum entre desenvolvedores e publicadores.

JP: Fala-se muito hoje em game-propaganda como estratégia para manter a empresa em atividade, a Continuum usou este artifício, ou na prática a teoria é diferente?

C: Depende muito dos objetivos da empresa. Até algum tempo atrás, nosso foco era mais amplo e atendiamos este público também. Atualmente estamos com nosso foco restrito ao desenvolvimento de produtos multiplataforma (PC e XBOX) para os publicadores internacionais. Achamos que esta é a estratégia mais adequada para a Continuum.

JP: Vocês já há dois meses são desenvolvedores oficiais da plataforma XBOX. Esse é o caminho para manter a rentabilidade da empresa, ou de um jogo, PC + Console?

C: Esta é uma maneira de agregar mais valor ao nosso trabalho, aumentando as possibilidades de fechamento de negócios.

JP: O que vocês acham do mercado brasileiro de jogos? Tem Futuro?

C: Acreditamos que o mercado tem futuro, mas por enquanto ele é ainda uma promessa, com poucos casos de sucesso.

JP: Teremos uma versão do OutLive para console?

C: Não temos planos de portar o Outlive para XBOX, pelo menos por enquanto.

das.

JP: Qual o novo projeto que vocês estão desenvolvendo? Vocês poderiam dar essa esclusividade para nós? Ou quando a Continuum pretende divulgá-lo?

C: Pretendemos divulgar mais informações assim que as negociações estiverem encaminhadas, o que deve levar ainda algum tempo.

JP: Qual a mensagem que a Continuum deixa para quem esta começando na área?

C: Além de entender como desenvolver jogos, é importande entender melhor o mercado em si e como funcionam os negócios dentro dele. Esta prática é vital para aumentar a probabilidade de sucesso de uma empresa iniciante. Boa sorte na sua empreitada!

JP: A pirataria de jogos no Brasil afetou de alguma forma o negócio da empresa?

C: Afetou principalmente no mercado nacional, onde perdemos muitas ven-

JP: A Continuum teve sua marca ligada a outras grandes marcas, como Big Brother Brasil, Xuxa e Mac Donalds.

Isso agrega valor na hora de encontrar um publisher disposto a bancar um projeto pró-prio?

C: Eles melhoram a credibilidade da empresa, apesar de serem projetos menores e de pouco apelo internacional.

http://www.jogospro.com.br

S ET E M B R O 2 0 0 4

J O G O S P R O e-magazine

C

A

P

A

.:Entrevista Ignis JogosPRO: A Ignis surgiu do trabalho nas horas vagas de seus sócios. Vocês consideram essa estratégia, de desenvolver uma demo, buscar patrocínio e depois uma dedicação exclusiva na empresa, como a melhor opção ainda hoje no mercado brasileiro?

Ignis: Na verdade essa é a única opção para a gande maioria das empresas.

Todo publisher exige uma prova de competência dos desenvolvedores e, algumas vezes, nem mesmo um bom demo é suficiente.

cubadoras tecnológicas no país, e sempre aconselho os iniciantes a procurar o auxílio delas. A Intec teve um papel fundamental no processo de transferir a Ignis do papel para a realidade.

JP: Vocês recomendariam a quem esta iniciando buscar auxílio em incubadoras?

I: Sim. Complementando a questão anterior, normalmente uma empresa iniciante na área conta apenas com pessoal de perfil técnico e isto não basta para compor uma empresa de sucesso. As incubadoras ajudam muito na parte de preparação do plano de negócios e na administração da empresa.

JP: Vocês conseguiram uma Capitalização através de Capital de Risco. Esse investidores veêm com bons olhos o mercado de jogos?

I: Nem todo investidor de Capital de Risco tem perfil para atuar na nossa área, mas normalmente eles têm uma visão livre de preconceitos.

Se a proposta tiver o respaldo de um bom plano de negócios, ela será avaliada com os mesmos critérios de outras propostas de tecnologia.

JP: No Paraná surgiram várias empresas de jogos, porém a Ignis se mudou para o Rio de Janeiro. Qual o motivo dessa decisão?

I: O fundo de investimento que conseguimos é voltado para empresas de tecnologia do Estado do Rio de Janeiro. Além disso, é importante a proximidade da empresa com o investidor, pois a colaboração deles é importante para o desenvolvimento do negócio.

JP: Durante o processo de desenvolvimento vocês foram selecionados para participar da Incubadora Tecnológica do Paraná. Isso ajudou a Ignis de alguma maneira?

I: Ajudou muito. Hoje existe muitas inhttp://www.jogospro.com.br

JP: A pirataria no Brasil influenciou na decisão de voltar o desenvolvimento para um MMORPG? Ou a decisão foi baseada na paixão?

I: Todas as decisões da Ignis são tomadas em função do mercado e, por uma questão de sobrevivência, não pode ser diferente disso. Nosso foco sempre foi o mercado exterior, então não posso afirmar que a pirataria teve uma influência significativa nessa decisão. A paixão é o que nos motiva a fazer jogos, mas o mercado

e quem determina como temos que fazer esses jogos.

JP: O que vocês acham do mercado brasileiro de jogos? Tem Futuro?

I: Sim. Tem muito futuro e este é o principal motivo que nos levou a lançar o Erinia no Brasil também. O público brasileiro ainda tem uma dificuldade grande em entender que o desenvolvimento, a distribuição e a operação (no caso dos jogos online) custa muito caro e que, por isso, devem pagar pelo produto. Mas a mentalidade está mudando rapidamente, e os jogagores estão percebendo que, saindo da ilegalidade, estão colaborando para que sejam lançados jogos cada vez melhores.

JP: Agora com o lançamento do Erinia, quais os próximos passos?

I: Estamos trabalhando muito nas atualizações e nos preparativos para o lançamento na Europa, mas também estamos fazendo o estudo de viabilidade de 3 novos projetos. Não podemos deixar todos os ovos em um único sexto.

JP: Qual a mensagem que a Ignis deixa para quem esta começando na área?

I: Todos têm que estar cientes das dificuldades que terão pela frente. Nossa profissão é uma das mais difíceis e exigentes que existe e muitas pessoas acabam desistindo por não estarem cientes disso quando começaram. Nós gostaríamos de lembrar que é preciso gostar muito da profissão e não desistir nunca, pois não existe recompensa maior que poder trabalhar fazendo o que realmente se gosta. �

Saiba mais sobre as empresas Southlogic http://www.southlogic.com.br Continuum http://www.continuum.com.br Ignis Games http://www.ignisgames.com.br

S ET E M B R O 2 0 0 4

J O G O S P R O e-magazine

COLUNA:

CENA JAVA

Java no Desenvolvimento de Jogos:

Um Panorama por Paulo R. C. Siqueira

Desenvolver jogos é uma ciência e uma arte eclética. Exige a união de grandes conhecimentos de diversas áreas e envolve muitas complexidades. Para facilitar a nossa vida, existem diversas ferramentas, linguagens, engines etc. prontas para serem utilizadas. Cada ferramenta tem seus prós e contras, além do gosto pessoal de cada desenvolvedor. Uma linguagem que vem aparecendo cada vez mais no cenário do desenvolvimento de jogos é Java. E ela é o foco desta coluna.

A

cada edição, estaremos explorando diversas características desta poderosa plataforma, que muitas vezes é deixada de lado por puro preconceito. Nesta primeira etapa, estaremos fazendo um panorama geral sobre a linguagem, mostrando suas principais características e alguns de seus (muitos) benefícios. Vamos apresentar rapidamente as APIs mais utilizadas e apontar caminhos para que o leitor possa se aprofundar mais.

A primeira coisa que deve ser entendida é que Java é mais do que uma linguagem. Ela é uma plataforma completa de desenvolvimento de software, que abrange desde dispositivos minúsculos, como Smart Cards, até grandes sistemas Figura 1 – Arquitetura básica da plataforma Java corporativos, como o sistema da amazon. com (uma aplicação web que processa demesmo em todos os casos. Mudam as APIs disponíveis, zenas de milhares de acessos simultâneos). A plataformas não a sintaxe da linguagem, que é muito parecida ma Java está dividida basicamente em três partes (além com C/C++ - o que permite a programadores dessas da especificação de Smart Cards): Java 2 Micro Edition linguagens aprenderem Java facilmente.

(J2ME), que possibilita o desenvolvimento de aplicações para dispositivos móveis, como celulares e Palms; Agora que já temos o conhecimento básico sobre o que Java 2 Standard Edition (J2SE), que fornece suporte ao é Java, podemos falar do que realmente nos interessa: o desenvolvimento de aplicações Desktop, além de ser o desenvolvimento de jogos! alicerce para a terceira e mais conhecida parte: Java 2 Enterprize Edition, que fornece APIs, frameworks e outras ferramentas para o desenvolvimento de aplicações Paulo R. C. Siqueira é desenvolvedor Java, Programador Certificado pela Sun Microsystems e já está viciado em World of corporativas, incluindo as famosas aplicações web.

Independente de qual parte da plataforma está sendo utilizada, os conceitos principais são sempre os mesmos: toda aplicação Java roda por cima de uma máquina virtual (JVM), o que faz com que seja possível rodar as aplicações em qualquer SO que possua uma implementação da JVM (todos os Sos mais importantes têm). Além disso, a linguagem é a http://www.jogospro.com.br

Warcraft, mesmo ainda não tendo jogado.

S ET E M B R O 2 0 0 4

J O G O S P R O e-magazine

CENA JAVA O Despertar Quando falamos em desenvolver jogos em Java, logo vem à mente “joguinhos” para celular. Isso é compreensível, pois a linguagem vem recebendo bastante destaque neste segmento. Em uma busca de poucos minutos na internet é possível encontrar, literalmente, dezenas de pequenas e médias empresas que desenvolvem este tipo de jogo utilizando Java.

objetivo facilitar o desenvolvimento de interfaces de aplicações desktop e fornecer aos desenvolvedores uma grande quantidade de recursos. Mas houve um problema: os desenvolvedores decidiram que a API seria desenvolvida utilizando todos os conceitos de orientação a objetos ao extremo. E de fato isso foi feito. O Swing é considerado hoje uma obra prima quanto à sua arquitetura mas, em compensação, a execução das aplicações desenvolvidas com ele eram lentas.

Figura 2: Ancient Empires e Dragon Island, dois jogos para celulares

Uma outra visão comum são os jogos disponíveis em sites na internet, feitos com applets Java (a mesma tecnologia que está por trás de diversos teclados virtuais de sites de bancos). E nesse caso já temos jogos bem mais elaborados do que os disponíveis para celular, mas ainda sim um tanto quanto limitados.

Mas nenhum desses dois casos mostram o que realmente é possível fazer com Java. Há mais do que isso. Navegando um pouco mais na internet podemos perceber que a plataforma Java está cada vez mais sendo utilizada para desenvolvimento de jogos mais complexos, que vão desde jogos 2D, até jogos com gráficos 3D cuja qualidade é difícil contestar.

Muitos já devem ter ouvido falar (mal) do desempenho de Java. Mas o quanto disso é realmente verdade? Hoje em dia, muito pouco. Essa fama vem das primeiras versões da linguagem, quando a plataforma ainda estava um tanto quanto imatura. Um dos principais culpados por esse desempenho limitado é a API Swing. Esta API tinha como http://www.jogospro.com.br

É claro que essa não era a única razão para o fraco desempenho da plataforma Java.

Houveram diversos outros problemas, que foram sendo corrigidos

Além dessa exposição, a empresa também está desenvolvendo um produto comercial para jogos MMO, o Java Game Server. Para cuidar das iniciativas para produção de jogos, a Sun criou um grupo interno de desenvolvedores chamado Game Technologies Group (GTG).

Não podemos deixar de citar a grande comunidade que existe ao redor deste assunto. O fórum da comunidade de jogos do site java. net (http://www.java.net) possui, no momento em que esta coluna está sendo escrita, 3716 usuários registrados, e está em constante crescimento. Confira também o da comunidade: www.javagaming.org. Lá é possível encontrar jogos, demos e APIs. Entre os projetos dessa comunidade, três merecem destaque: jinput, joal e jogl. O objetivo dos três é basicamente o mesmo: disponibilizar recursos que não estão disponíveis diretamente em Java, ou cujos recursos são insuficientes para o desenvolvimento de jogos.

conforme as novas versões eram lançadas. E hoje temos uma plataforma que traz diversos benefícios para quem decide utilizá-la.

Um fato interessante é que a Sun (empresa que desenvolveu a plataforFigura 3: Alien Flux, jogo 2D comercial - roda em Linux, Windows e MacOS ma Java) está, já há algum tempo, empregando esforços Os três projetos são OpenSource e para facilitar o desenvolvimento de tem participação ativa de diversos jogos. Em congressos como o Java desenvolvedores da comunidade e One (maior congresso sobre Java do do GTG. mundo, que reúne milhares de desenvolvedores todo ano), e o Game Developers Conference (GDC), a Sun vem realizando palestras visando mostrar aos desenvolvedores de jogos os ganhos que podem ser obtidos com o uso da tecnologia Java.

S ET E M B R O 2 0 0 4

J O G O S P R O e-magazine

CENA JAVA Os Três Pilares

entrada do loop principal do jogo.

Java, como qualquer outra plataforma de desenvolvimento, não é perfeito.

No que se refere ao desenvolvimento de jogos, três são os problemas mais encontrados pelos desenvolvedores: tratamento de input do jogador, suporte a tecnologias de processamento gráfico de alta qualidade e recursos de processamento de audio escassos.

Visando resolver esses problemas, es-

Por mais bonito e divertido que um jogo seja, uma boa música e efeitos sonoros são essenciais. Java proporciona uma API chamada Java Sound, que permite utilizar diversos recursos sonoros, principalmente no formato midi (é possível ler outros formatos com algumas APIs externas). Porém, quando precisamos ter realmente um bom controle sobre

Muito programadores já devem ter ouvido falar da biblioteca OpenAL. É com essa biblioteca que foi procurado resolver os problemas do Java Sound.

O projeto JOAL permite a desenvolvedores Java utilizar OpenAL para gerar / reproduzir os sons do jogo, ao invés de Java Sound.

Em Java temos diversas opções para se desenvolver a interface. Há Swing, Java 2D, Java 3D, entre outras. Mas todas elas são incompletas no que se refere ao desenvolvimento de jogos.

Desenvolvedores de jogos querem mais poder do que essas APIs oferecem. Para a programação gráfica de jogos, OpenGL é quase unanimidade. Por causa disso, o projeto JOGL oferece uma opção para se utilizar OpenGL em Java. Para quem já sabe OpenGL, é questão de minutos para se aprender a utilizá-lo com Java, e boa parte da complexidade envolvida em códigos C/C++ fica transparente para o desenvolvedor.

Light Weight Java Game Library

Figura 4: Flying Guns - Desenvolvido com Java3D

tão sendo desenvolvidos três projetos no portal java.net: jinput (jinput.dev. java.net), jogl (jogl.dev.java.net) e joal (joal.dev.java.net).

O jinput ataca o primeiro problema: o tratamento da entrada do jogador.

O modo convencional de tratamento de entrada de dados em Java é baseado em eventos, que são sempre ligados a algum componente gráfico AWT / Swing. Deste modo, é sempre necessário ter pelo menos um componente registrado para ouvir estes eventos, alocando recursos preciosos do sistema, que ficam, pelo menos em parte, fora do controle do desenvolvedor. Além disso, não é possível receber entrada de joysticks ou outros dispositivos que não sejam o mouse e o teclado. O jinput funciona de um modo oposto: ao invés do input ser lançado em um evento, é o desenvolvedor que deverá verificar quais teclas foram pressionadas, o que pode ser feito na parte de processamento de http://www.jogospro.com.br

o que está acontecendo na parte sonora do jogo, ou quando precisamos de recursos mais sofisticados de processamento de som, Java Sound se mostra extremamente limitada.

Além de JOGL, JINPUT e JOAL, temos o LWJGL como uma opção de acesso a OpenGL, OpenAL e tratamento diferenciado de entrada. A principal diferença entre essa API e as anteriores, é que ela engloba as três partes que as anteriores atacam em uma única API. Por isso ela acaba se tornando uma API do tipo tudo ou nada. Entre os jogos produzidos com Java e OpenGL atualmente, o uso de LWJGL e JOGL (e suas irmãs) esta bem equilibrado. Para mais informações acesse: http://www.lwjgl.org.

Figura 5: WurmOnLine – MMORPG

S ET E M B R O 2 0 0 4

J O G O S P R O e-magazine

CENA JAVA Vantagens de se utilizar Java Certo, então com Java é perfeitamente possível desenvolver jogos de qualidade. Mas se eu já programo em C/C++, porque deveria aprender Java? Abaixo estão listadas as suas principais vantagens: ◊ Multiplataforma: A qualidade mais conhecida de Java é a sua portabilidade. O fato de Java ser multiplataforma nos garante que nossos jogos poderão rodar pelo menos nos três SO’s mais utilizados: Windows, Linux e MacOS. ◊Produtividade: Uma outra qualidade muito comentada de Java é a sua produtividade. A linguagem possui algumas características interessantes que nos auxilia nesse sentido. Uma dessas características é a ausência de ponteiros. Portanto você não precisa se preocupar em desalocar memória (fonte de muitos problemas em código C/C++). A própria linguagem se encarrega de detectar classes que não estão mais em uso e liberar a memória usada por estas classes. ◊ Deployment Simplificado: Utilizando Java Web Start (JWS), é extremamente simples para o jogador instalar seu jogo. Tudo o que ele tem que fazer é ir até a página do jogo e clicar em um link. JWS irá fazer o download e a instalação automaticamente. Depois de instalado, o próprio JWS checa por possíveis atualizações. Se estas existirem, ele as baixa e instala. Tudo com a mínima intervenção do jogador. ◊ Evolução Comunitária: A plataforma Java está sempre evo-

luindo. Isso quer dizer que, se há um recurso poderoso do qual o desenvolvedor precisa que não está disponível, há sempre grandes chances dele ser acrescentado ao Java. E o melhor é que essa evolução não é controlada pela Sun, mas sim pela comunidade, e qualquer um pode participar. É para isso que existe o Java Community Process (JCP – http://www.jcp.org). Através dele é possível acompanhar o que está sendo feito para o futuro da plataforma Java e, mais importante, participar deste futuro. ◊ Uso de padrões: Toda a arquitetura da plataforma Java é construída em cima de padrões. A própria JVM é na verdade uma especificação, e qualquer um pode desenvolver a sua. E isso é muito importante, pois trás independência de fornecedores. Você sempre terá a possibilidade de trocar o fornecedor da sua JVM, dos seus parsers XML ou qualquer outra coisa, desde que os padrões sejam seguidos. ◊ Economia: Ferramentas são indispensáveis no desenvolvimento de qualquer aplicação, jogo ou não. Para Java, há uma quantidade enorme opções com as quais o desenvolvimento pode ser feito. E a grande maioria é grátis, e com qualidade profissional. Só para citar algumas, temos duas excelentes IDEs: Eclipse (http://www.eclipse. org) e NetBeans (http://www.netbeans.org), ambas gratuitas e entre as mais utilizadas do mercado.

Por onde começar Então você decidiu tentar utilizar Java. A primeira coisa que deve ser feita é baixar o JDK, disponível em http://java.sun.com. Neste mesmo site há uma extensa documentação sobre toda a plataforma Java. Uma IDE também é importante. As duas mais utilizadas são o Eclipse e o NetBeans, já citadas anteriormente.

Sugiro que baixe as duas e escolha a que mais lhe agradar. Comece como você começaria em qualquer outra linguagem: faça um joguinho básico como Pong, e vá escrevendo outros jogos aumentando a complexidade aos poucos. Comece com Swing e Java2D mesmo (a não ser que você

Java Game Server O mercado de MMOs no mundo vem crescendo bastante nos últimos anos.

Visando este mercado, a Sun está desenvolvendo um servidor de jogos MMO, o Java Game Server (http://www. sun.com/smi/Press/sunflash/2004-03/ sunflash.20040323.1.html), que tem o objetivo de prover a infraestrutura comum a muitos dos jogos massivos, com escalabilidade, persistência automática dos objetos do jogos e mais um monte de coisas. Independente do servidor ser bom ou não, o importante é notar que a Sun, criadora da plataforma Java, está começando a ver o mercado de jogos com bons olhos, o que só tem a nos beneficiar.

Figura 6: Jose, feito com Java3D http://www.jogospro.com.br

já saiba OpenGL). Depois que já estiver familiarizado com a linguagem Java, parta para OpenGL e se divirta!

O Futuro Nesta edição tivemos uma introdução do que pode ser feito com a plataforma Java. Vimos que a falada lentidão não passa de lenda hoje em dia, e que é possível utilizar os mais modernos recursos atualmente disponíveis no mercado. Na próxima edição, iremos abordar algum ponto mais específico, e você pode ajudar a escolher qual será esse ponto.

Acesse o site da JogosPro e-Magazine e opine nos forums!

Figura 7: SquareHeads, com um mapa de Quake 3

S ET E M B R O 2 0 0 4

J O G O S P R O e-magazine

por Alandro Vieira dos Reis

Videogames no Cyberpunk de William Gibson Sobre William Gibson: Escritor norte-americano de contos e romances de ficção científica dos anos 1970, consagrou-se na década de 80, ao criar o estilo Cyberpunk. Atuou no roteiro de filmes para o cinema e alguns episódios de X-Files. Hoje aposentado, mora no Canadá.

Ficção Científica: Reflexão e Antecipação As mudanças na sociedade decorridas dos avanços tecnológicos costumam mexer com a imaginação dos escritores, que tem por hábito criar histórias que expressam seus anseios e sonhos quanto às novidades que a ciência e a tecnologia trazem ao mundo. Podemos inferir que além de um eficiente termômetro dos anseios causados pelas mudanças tecnológicas, as histórias de um tempo também podem subsidiar reflexões sobre as novas tecnologias e costumes e até mesmo ligeiras antecipações.

Este artigo trata das antecipações presentes no livro Neuromancer, de William Gibson, sobre os jogos eletrônicos como componente da cultura, o texto conclui-se compartilhando com o leitor as reflexões que William Gibson propõem em sua poesia elétrica hightech.

O Movimento Cyberpunk O cyberpunk, herdeiro de “1984” de George Orwell, é a ficção científica do nosso tempo, tendo gerado filmes de grande sucesso como a trilogia Matrix.

No início da década de 1980, William Gibson definiu o cyberpunk, marcado pelo viés noir (tramas policiais com densidade psicológica), muita ação e inquietações filosóficas, tendo por pano de fundo um futuro onde as tecnologias moldam cada aspecto do modo-de-vida de todos.

A importância do cyberpunk pode ser avaliada além do cinema, das histórias em quadrinho e livros. O próprio termo cyberespaço, hoje tido como sinônimo de internet, foi inventado por William http://www.jogospro.com.br

Gibson, que também influenciou a NASA a usar luvas e capacetes de imersão para treinamento de astronautas através de jogos eletrônicos de simulação.

Como cerne deste artigo, tratarei de

“A Matrix teve sua origem nos primitivos jogos eletrônicos”.

(trecho de Neuromancer, escrito em 1984) outro fator que testemunha a importância dessa ficção científica para nós: as antecipações sobre os jogos eletrônicos feitas por Gibson, presentes em seu futuro ficcional.

Futuro esse que, até certo ponto, já é o nosso presente.

Jogos Eletrônicos em Neuromancer Basicamente há seis componentes muito comuns dos jogos eletrônicos dos dias de hoje que William Gibson antecipou, com cerca de 15 anos de antecedência, com sua ficção científica.

1. Hackers A mais freqüentemente explorada situação de jogo eletrônico em Neuromancer é a atividade hacker. Descrita

como um estimulante jogo de invasão, de burlar regras e quebrar barreiras do Sistema. O risco alucinante, os ganhos exorbitantes, as possibilidades de punições terríveis, tudo isso faz parte do jogo da invasão.

O protagonista da história é Case, um super-hacker com habilidades incomuns de invadir e controlar sistemas de informação. Contudo, sua habilidade ganha dimensões de vício. Gibson, com Case, aborda o comportamento de jogo compulsivo, com todas as implicações patológicas que dele decorrem, como a desagregação contínua da vida de seu anti-herói.

2. Realidade Virtual Intrinsecamente associada à primeira, está a imersão em mundos virtuais.

Descrita pelo autor como “adentrar numa alucinação consensual”, a imersão é realizada por neuroimplantes e dispositivos digitais, e opera uma separação da mente e do corpo, sendo que a primeira é revestida de um personagem digital como roupagem.

A realidade virtual tem por características o dinamismo do hipertexto, a vida pulsante de uma floresta, a possibilidade de criação e recriação incessantes. Explorá-la é construí-la. Os navegadores desse Novíssimo Mundo são os usuários, que também exercem o papel de criadores deste. É a vez de Gibson alertar para o patológico desejo de alienação, de fuga da realidade: os usuários compulsivos do cyberespace trocam suas vidas por simulacros, numa relação esquizóide com as máquinas.

S ET E M B R O 2 0 0 4

J O G O S P R O e-magazine

3. Jogos de Simulação Uma vez inserido no cyberspaço, Case é orientado por uma inteligência artificial chamada Linha Plana, que atua como mentor em sua jornada pelos mundos virtuais, e lhe informa opções mais acertadas. Se a imersão de Case for vista como um jogo de navegação, Linha Plana funciona como um navegador ou gestor técnico da simulação.

Em outros livros, como em Idoru, Gibson sugere que algumas inteligências artificiais também teriam por função orientar a criação e gestão de mundos virtuais pelos usuários, num imenso jogo de simulação de cidades, países, reinos. As semelhanças desses relatos ficcionais com jogos atuais de simulação, como SIM City, não param por aí. Uma vez criada uma cidade virtual, ela é povoada por pessoas simuladas, que vivem suas vidas artificiais reguladas por algoritmos dos usuários. Jogos de simulação semelhantes fazem imenso sucesso neste início de século XXI, como o mais vendido de todos os tempos, The SIMs.

clara referência ao roleplaying game(RPG) mais popular nos EUA nos anos 80: o Dungeons&Dragons. Falar de pessoas conectadas todas num mesmo RPG digital significa a antecipação dos massive multiplayer on line games (MMOG) como Never WinterNights, Dark Ages of Camelot, etc.

Em outro livro, Idoru, tal conceito é desenvolvido, e figuram em cena comunidades virtuais, tais como conhecemos hoje em sites como Orkut, porém numa versão de realidade virtual imersiva gerida por inteligências artificiais.

6. First Person Shooters O episódio notoriamente que mais lembra

ra pessoa, inclusive cenas de luta, fuga e perseguição alucinantes. Impossível ler a narração do episódio sem pensar em jogos do tipo first person shooter, como Counter Strike.

Reflexões Ao contrário do que se costuma crer comumente, a cybercultura já possui uma História de mais de 20 anos (Neuromancer é de 1984) e conta até com uma densa ficção científica correlata que investiga filosófica e psicologicamente sua estrutura.

O modo como os jogos eletrônicos são antecipados na obra de William Gibson confirma a importância da visão deste autor, suas reflexões sobre tais práticas lúdicas. Gibson, dentre outras coisas, nos alerta para o jogo compulsivo, a fuga da realidade em nome da virtualidade e a banalização do real em detrimento de simulacros, e outros temas que se tornam reflexões filosóficas e emanam da leitura de Neuromancer, que constitui-se o livro fundador e até hoje a ficção mais importante da cultura digital.

4. LAN Houses Casas de jogos eletrônicos figuram regularmente em ambientes noturnos em Neuromancer. Seja em Tóquio ou nas megalópoles dos EUA, surgem grandes salões onde dezenas ou centenas de pessoas estão todas conectadas a uma realidade virtual lúdica. As casas de jogos, curiosamente, são freqüentadas em sua maioria por jovens e adultos. O autor não fala de adolescentes e crianças. Mulheres também constam nas casas de jogos da ficção cyberpunk de Gibson. Em sua visão antecipatória, a faixa etária dos jogadores iria aumentar e a participação feminina seria importante no mundo dos jogos eletrônicos, proposições essas que provocariam risos se fossem ditas há 15 anos.

5. MMOGs Em um dado momento, Gibson descreve um jogo dessas casas de jogos como sendo um jogo de estratégia ambientado num calabouço de um castelo medieval, numa

OBS: Para a escrita deste artigo usei como referência a seguinte versão em português de Neuromancer: GIBSON, William. Neuromacer. Editora Aleph, 3a edição, 1a reimpressão, São Paulo: 2003.

Alessandro Vieira dos Reis avr@certi.org.br http://www.certi.org.br/~avr/

Figura: Capa do Livro Neuromancer os atuais jogos eletrônicos no livro Neuromancer se dá quando Case, através de uma conexão neurodigital (chamada no livro de SIMStim, simulated stimulation, ou “estimulação simulada”), consegue receber as informações sensoriais de Molly, passando a ser como uma câmera na mente de sua parceira. Esta, uma habilidosa guerreira, invade uma instalação inimiga, contando com a monitoração e orientação de Case, que percebe toda a experiência em primei-

O evento será realizado na cidade de Curitiba no Paraná, também nesta cidade, em data próxima ao SBGames, será promovido o SIBGRAPI2004 (Simpósio Brasileiro de Computação Gráfica e Processamento de Imagens) e o SIAGG-2004 (Simpósio Ibero-Americano de Computação Gráfica). Confira tudo em:

http://wwwusers.rdc.puc-rio.br/sbgames/ http://www.jogospro.com.br

S ET E M B R O 2 0 0 4

J O G O S P R O e-magazine

Coluna

Jogos Open Source

Utopia, modismo ou necessidade ? por Julio Marchi

Desenvolver jogos de computador sempre foi um dos mais comuns ideiais de motivação para que os jóvens ingressassem na área de programação de computadores. Muitos de meus amigos – e inclusive eu mesmo – começaram a escrever suas primeiras linhas de código voltadas “àquele jogo fenomenal” que ninguém tinha feito ainda. Entretanto, a esmagadora maioria dos que iniciaram por este caminho não chegaram a alcançar este objetivo primário.

Em critérios gerais, desenvolvimento de jogos para computador é um dos maiores desafios que um programador pode encontrar. É necessário ter o domínio de inúmeras técnicas complexas para que se possa produzir um simples joguinho. Não obstante, há poucos anos atrás, o maior agravante que enfretávamos era a quase total inexistência de documentações sobre o tema. Não existiam exemplos e ferramentas específicas para isso como atualmente; e não haviam sequer tantos recursos avançados - e simplificados – destinados exclusivamente ao desenvolvimentos de jogos. Entre isso e outras realidades, a soma dos fatores foi fazendo com que muitos - assim como eu, que tomei gosto pelos computadores graças aos jogos – estudassem computação à fundo para acabar tendo o foco produtivo em outras coisas mais factíveis, deixando o desenvolvimento de jogos, que era o objetivo primário, apenas como uma “doce recordação”.

Se antes desenvolver jogos de computador era uma questão de ter boas idéias e de ser um excelente Julio Marchi é Analista de Sistemas formado especilizado em engenharia de software, network, multimídia e Internet. Atualmente é CEO de duas empresas nos EUA e desenvolve diversos projetos técnicos e áudio-visuais para outras empresas.

http://www.jogospro.com.br

programador - ou fazer parte de um bom grupo -, hoje desenvolver um jogo assemelha-se mais à produzir um filme de Hollywood do que simplesmente programar. Não é que não hajam mais espaços para os jogos simples e de baixos recursos, porque atualmente, em se tratando de informática, há espaço para quase tudo... Eu me refiro em termos mercadológicos, onde a competição de se “vender” jogos obriga que o produto tenha muitas características avançadas como: música e efeitos sonoros, um “roteiro” envolvente, qualidade gráfica - mesmo em 2D -, jogabilidade, boa apresentação, propaganda e preço. Pode até não parecer, mas para alcançar um nível suficientemente bom e atrair a atenção do consumidir neste mecado altamente competitivo é como embarcar uma “Luta de Titãns”. Em termos gerais, decidir produzir um jogo mediano e de apenas boa qualidade geral, pode chegar a representar um investimento inicial de mais de US$ 50.000,00, o que para países como o Brasil é um investimento demasiadamente alto para arriscar em um mercado ainda emergente, o qual já sofre com a influência do milionário mercado internacional.

Mas, como atualmente a velocidade da informação já desbancou a da luz, as dificuldades se apresentam de um lado e as soluções emergem de outro. Com o avanço da tecnologia tudo tem ficado mais fácil, e o desenvolvimento de jogos não tem sido uma excessão. Alem das novas ferramentas que surgem a cada dia, há também um infindável e crescente acervo de informações, exemplos e “bibliotecas” que colaboram para diminuir o tempo de desenvolvimento de um jogo, o que reflete diretamente no investimento necessário. Com o advento da Internet surgiram também novas linhas de “negócios”, mais baratas e diretas – e ainda pouco exploradas -, que quando bem utilizadas podem atualmente fazer a difereça entre o sucesso e o fracasso de um produto. Ainda graças à grande facilidade de intercâmbio que a Internet oferece globalmente, os produtos “open source” têm S ET E M B R O 2 0 0 4

J O G O S P R O e-magazine

Coluna obtido grande atenção da comunidade desenvolvedora global. Os resultados destes últimos anos e o sucesso de diversos programas desenvolvidos nesta “parceria”, com a colaboração “gratuita” de incontáveis pessoas de todas as partes do mundo, já comprovam que o open source e seus “rabichos” vieram para ficar.

Open Souce soa lindo de todas as formas que se escuta, mas ainda traz algumas “discussões” que tendem a esquentar nos próximos anos. Mesmo a famosa licença GPL já vem levantando polêmica principalmente porque muito dela não se adequa à diversas Leis locais de software de vários países. Não obstante, Open Souce para o mercado de jogos distôa do conceito principal da essência deste mesmo mercado: a comercialização. Mesmo que um jogo de alto nível, desenvolvido via Open Souce, fosse vendido por apenas UM DÓLAR, ainda assim haveriam outros problemas intelectuais com relação a vários pontos: 1) O mais caro de um jogo, e o mais importante, é sua ENGINE. Uma “engine Open Source” tem uma grande possibilidade de ser a melhor que existe, mas por ser Open Souce nada impedirá que esta seja usada indiscriminadamente em produtos comerciais de terceiros; 2) Jogos, ao contrário de outros produtos computacionais, não se restringem somente ao código do programa, mas também às animações, enredo e conteúdo musical, e o Open Source não abrange nada disso; 3) O mercado Open Source fica automaticamente FORA do mercado de consoles (XBox, PlayStation, GameCube) por questões de licenciamento, perdendo uma grande e crescente fatia do mercado

consumidor de jogos.

Se formos explorar e comparar a idéia de “Open Source para aplicativos gerais” com a aplicação do “Open Source para desenvolvimento de jogos” serão demasiados os pontos controversos, mas existe um em específico que mais chama minha atenção: projetos “Open Source” normalmente NUNCA terminam! De tempos em tempos são lançadas novas e mais novas versões do programa com melhorias gerais e mais recursos. Eu não consigo ver esta mesma “característica” do Open Source adaptando-se aos jogos.

Jogos são produtos de consumo direto: compra-se, joga-se, termina-se o jogo e pronto! Não usamos jogos como aplicativos no nosso dia-a-dia e não existe muito esta coisa de adicionar um novo “feature” num jogo porque quase ninguém vai parar um jogo no meio e recomeçá-lo – por exemplo – por causa de um recurso novo que foi implementado na fase “X”. No máximo implementa-se novos inimigos, níveis, armamentos ou coisas assim para dar mais longevidade ao jogo, mas isso não é nada que não possa ser feito com os “patches” ou “expansion packs”.

Não estou dizendo aqui que jogos Open Source não têm seu espaço ao Sol porque a grande verdade é que SIM, é uma excelente idéia! Tão boa que têm até mais espaço e potencial do que muitos aplicativos que eu tenho visto no SouceForge, por exemplo. O que estou dizendo é que, do ponto de vista comercial, eu não vejo futuro para jogos Open Source a não ser no caso de: 1) Jogos Educativos; 2) Jogos para Internet ou; 3) Projetos para Estudo e Aprendizado.

Outro ponto controverso que não pode ser esquecido, e que agride diretamente o tema “jogos Open Source” é o foco das plataformas. Como para os “consoles” os jogos Open Source estão descartados, sobram macissamente o Mac e o PC, onde, no caso do PC entram as variantes de Sistemas Operacionais. O problema principal neste ponto é exatamente a ENGINE, que comumente tem que ser o mais otimizada possível para melhor poder usar mais eficientemente os recursos de cada sistema, o que obriga que se desenvolvam versões específicas para cada SO. No caso do Mac não há tanto problema porque o Sistema Operacional hoje é basicamente um só – o Mac OS X. Já o PC sofre atualmente com as variações de SO’s disponíveis, onde os mais contundentes são Windows e Linux. Para agravar o quadro, cada um destes possui suas próprias “sub-variações”, que

“Projetos Open Source normalmente NUNCA terminam!”

http://www.jogospro.com.br

S ET E M B R O 2 0 0 4

J O G O S P R O e-magazine

Coluna podem diferenciar-se em pontos chaves no que tange às necessidades dos jogos. O Windows pelo menos tem o DirectX, mas para Linux esta idéia está apenas engatinhando. Ainda no enfoque PC, o Linux perde o mercado de “usuários finais” - entenda-se “leigos” – pois seu uso pelo público geral ainda é bem modesto, o que leva o enfoque do desenvolvimento de jogos comercialmente lucrativos para a plataforma Windows.

Em suma, por dependência de recursos (som, animação, engines, etc.) os jogos Open Source são uma grande idéia que já nasce com grandes problemas. Nos EUA essa idéia tem tido muito boa aceitação, só que muito mais enfocada no conceito de estudo e aprimoramento. Entretanto, em países onde o mercado de desenvolvimento de jogos ainda é emergente e a realidade é difícil por conta da forte competição, o Open Source, se bem usado, pode ser uma excelente forma de diminuir os custos na pesquisa e produção de jogos; no aprendizado e desenvolvimento de novas técnicas e, principalmente, no esforço de demonstrar potencial produtivo para os possíveis “investidores”. O maior problema que pode existir talvez nem seja na parte técnica ou artística, mas sim em encontrar uma forma de lidar com as licensas tipo GPL sem criar “conflitos legais” ou “roubo de

http://www.jogospro.com.br

tecnologia”.

Como todo recurso, ferramenta ou idéia, a diferença entre o sucesso e o fracasso de um empreendimento está mais em sua implementação do que em seu conceito geral. Open Source pode ser um grande diferencial, pode ajudar a baixar custos e também melhorar a qualidade final de qualquer produto, mas ainda haverão os critérios intelectual e artístico, assim como o problema no manuseio das licenças. O dia que for encontrada uma fórmula para combinar Desenvolvimento de Jogos com licenças públicas, critérios intelectuais e comerciais o Open Source poderá – e certamente será - uma poderosa ferramenta para, pelo menos, ampliar o mercado de desenvolvimento de jogos no Brasil, permitindo que as empresas brasileiras possam competir mais de perto com produtos das grandes e milionárias empresas internacionais. por Julio Marchi

S ET E M B R O 2 0 0 4

J O G O S P R O e-magazine

Entrevista

Fábio Binder

O

professor Fábio Binder é coordenador do curso de pós-graduação em desenvolvimento de jogos do Unicenp. Foi pioneiro na sua área ao lançar esse curso, quando na área acadêmica ainda não se houvia falar em curso de jogos. A JogoPRO foi conversar com o Binder e saber como anda a academia e o mercado brasileiro de jogos.

JogosPRO: Fábio, em 2001 você teve a iniciativa de criar o primeiro curso de pós-graduação da América do Sul em desenvolvimento de jogos. Formando os primeiros profissionais em jogos brasileiros. Como surgiu essa iniciativa?

Fabio Binder: Eu já trabalhava há vários anos tanto na área acadêmica quanto no desenvolvimento de jogos educacionais. O “pulo do gato” aconteceu em 2000 quando assumi a coordenação do curso de especialização em Web do Unicenp e percebi que existia assunto suficiente para montar um curso de desenvolvimento de jogos. O momento era propício devido a algumas reportagens sobre jogos no Paraná.

Montei a proposta do curso que foi prontamente aprovada. Esbarrei na falta de profissionais para ministrar aulas. Pouco tempo depois soube da Gamenet que me ajudou na elaboração do formato definitivo, indicou professores e bancou várias bolsas da primeira turma, tornando o curso viável financeiramente.

JP: Já tivemos 2 edições da pós, que balanço você faz hoje?

FB: A segunda edição termina agora no final de outubro. O saldo é bastante positivo. Dos 30 alunos que finalizaram ou que estão finalizando o curso, atualmente 11 trabalham com jogos em empresas de jogos, algumas de destaque no cenário nacional como Ignis Games, South Logic e Continuum.

JP: No Brasil hoje temos cursos de graduação, workshops e congressos relacionados a jogos. É um mercado em franca expansão?

FB: Sem dúvida. Mas isso foi apenas o começo. A consolidação das empresas atuais, o crescente interesse da comunidade e a criação de uma associação sólida de empresas http://www.jogospro.com.br

(Abragames que já mostra serviço no seu ano de criação) são fortes indícios de que “neste mato tem coelho”.

JP: Com esse mercado, a Unicenp pretende ter um curso de graduação em jogos, ou quem sabe um mestrado?

FB: O Unicenp está começando em cursos de mestrado. No ano que vem teremos o mestrado em “Tecnologias Educacionais”. Alunos que fizerem o curso de jogos poderão descontar créditos do mestrado. Por sua vez, alunos do mestrado poderão fazer determinados módulos

“Dos 30 alunos que finalizaram ou que estão finalizando o curso, atualmente 11 trabalham com jogos, ...”

do curso de jogos contando como créditos para seu mestrado. Além disso, a graduação do Unicenp já aceita há alguns anos, jogos como projeto final de curso. Eu devo ter orientado uns 15 projetos nesta área nos últimos 10 anos.

JP: O Brasil forma profissionais em desenvolvimento de jogos, a comunidade está cada vez mais organizada, temos empresas com jogos publicados, mas parece que falta alguma coisa. Você, como desenvolvedor e educador, tem uma explicação?

FB: Eu acho que isso é apenas uma falsa impressão. À medida em que as empresas atuais lançarem mais jogos (aqui ou no exterior) e desco-

brirem “novos” modelos de negócio eficientes, o mercado se consolidará de vez. Outras empresas seguirão a onda e logo (se o governo não inventar moda...) todos saberão que existe desenvolvimento de jogos no Brasil. Mas é claro que se houvessem mais investidores dispostos a tirar dinheiro do bolso isso já teria acontecido.

JP: Há 2 anos não se ouvia falar em jogos em faculdades, como você vê a área acadêmica de jogos no Brasil nos próximos anos?

FB: Observando os números dos cursos atuais, parece que ainda existe um bom espaço para crescimento. Os cursos do Unicenp, Puc-Rio e Anhembi-Morumbi já vão para sua terceira turma. No Rio de Janeiro, a T&T que oferece cursos técnicos em jogos possui mais de 100 alunos só nesta área. Em diversas universidades brasileiras (Puc-Rio, UFRJ, USP, Puc-PR, UFPE, UFRS, entre outras) existem pessoas trabalhando em dissertações e teses relacionadas ao desenvolvimento de jogos. Gente competente e vontade é o que não falta.

JP: O que você recomenda para quem esta começando?

FB: Primeiro, jogar bastante e 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 :o), 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.

S ET E M B R O 2 0 0 4

J O G O S P R O e-magazine

por Bruce “Sinner”

A R T I G O S

Introdução ao OpenGL Shading Language

A

introdução de hardware gráfico programável no mercado abriu uma nova era para a Renderização em Tempo Real. Com ele é possível desenvolver pequenos programas (shaders) que são executados diretamente na GPU, com uma performance bem maior por causa disso. A utilização de shaders permitiu artistas e desenvolvedores produzirem efeitos especiais sofisticados que antes

eram renderizados offline, em hardware simples e barato. O aumento do uso dos shaders, que no ínicio eram desenvolvidos em assembler, levou à criação de linguagens mais sofisticadas e de alto nível, semelhantes as linguagens já utilizadas como C++ ou Java. Uma dessas linguagens, a OpenGL Shading Language (GLSL) foi recentemente lançada e passou a ser suportada somente agora, com o lançamento dos drivers da série 60 da NVidia. Ao longo desse texto mostrarei suas características, sintaxe, futuras implementações, como integrá-la ao OpenGL, al[em de alguns exemplos. Farei também, uma pequena comparação entre ela e outras duas linguagens bastante difundidas, a HLSL da Microsoft e a Cg da Nvidia.

letal Animation, Bump Mapping, Parallax Bump Mapping, Glow, Morphing, texturas procedurais em runtime (Figura 1) e outros mais. Os shaders estão disponíveis no OpenGL desde 2002 através das extensões ARB_vertex_program e ARB_fragment_program mas tinham que ser codificados em assembler, o que não os tornava muito popular. Com o surgimento de linguagens de alto nível para os shaders, como a HLSL da Microsoft e Cg da Nvidia, foi desenvolvido a GLSL, uma linguagem de alto nível também, que permitiu o desenvolvedor a escrever seus shaders numa linguagem similar ao C/C++ tornando a tarefa muito mais fácil !

Por quê usar Shaders e GLSL?

Um programa típico feito com a GLSL geralmente é composto de um par Vertex Shader e Fragment Shader:

O hardware gráfico antigo (GeForce 256, Radeon 7000 ) somente permitiam que o pipeline gráfico fosse configurado e não programado. Isso limitava a quantidade de efeitos especiais e técnicas avançadas, que deveriam ser simuladas em software, o que por muitas vêzes impossibilitou a utilização deles em tempo real. Um exemplo disso são os modelos de iluminação do OpenGL. Os modelos Ambient, Diffuse, Specular e Emissive são largamente utilizados mas há outros também como o de Phong por exemplo. Com shaders, é possível programar outros modelos de iluminação. Outros efeitos interessantes também são possíveis, como: Soft Shadows, Environment Mapping, Per-Pixel Lightning, Skehttp://www.jogospro.com.br

Características da GLSL

Vertex Shaders Um Vertex Shader opera em todos os vértices enviados para o pipeline.

Então a cada chamada a glVertex ou glDrawArrays é executado o shader.

Vertex Shaders são usados para se ter amplo controle sobre a posição de cada vértice a ser renderizado.

Exemplos de uso são em animações skeletais, morphing entre dois modelos 3D, a criação de efeito de ondas sobre uma malha de polígonos, etc...

Fragment Shaders Um Fragment Shader opera sobre todos os fragmentos produzidos pela rasterizaçãodo OpenGL. Um fragmento é mais do que um simples pixel. Ele também possui informação como cor, depth, stencil, etc...

Tipos de dados A GLSL possui quatro tipos principais: float, int, bool e sampler.

Figura 1: Modelos 3D mostrando efeitos que são possíveis de se fazer usando Shaders.

Bruce “Sinner” é desenvolvedor profissional e atualmente desenvolve um simulador virtual da linguagem visual dos surdos em C++ e OpenGL. Quando não está programando diverte-se assistindo Tom & Jerry com seu filho no Cartoon Network.

S ET E M B R O 2 0 0 4

J O G O S P R O e-magazine

A R T I G O S Existem também tipos que funcionam como array dos tipos principais. São eles: Float:

vec2 vec3 v e c 4

Int:

ivec2 ivec3 i v e c 4

Bool:

b v e c 2 b ve c 3 b v e c 4

Matrizes: m a t 2 m a t 3 m a t 4 O tipo matriz é composto apenas por floats. O tipo Sampler é usado para operações com texturas.

Attributes, Uniforms, Varyings e Const A GLSL também possui qualificadores de tipo que são: Attributes: Apenas estão disponíveis no Vertex Shaders. São valores de entrada que mudam para cada vértice processado, como sua posição ou normal, por exemplo. Os Attributes são read-only.

Uniforms: São valores que não mudam durante o rendering, como a posição da luz por exemplo. Estão disponíveis nos Vertex e Fragment Shaders. Os Uniforms são read-only.

Varyings: São usados para passar informações do Vertex para o Fragment Shader. Eles são read-only nos Fragment Shaders mas permitem leitura e escrita nos Vertex Shaders. Devem ser declarados de forma idêntica nos Vertex e Fragment Shaders que os usarem.

Constants: Não podem ter seu valor alterado, assim como no C. Geralmente guardam valores dependentes da implementação do OpenGL que se está usando como o número máximo de luzes por exemplo. Read-Only por razões óbvias.

Os qualificadores Atributes, Uniforms e Varyings devem ser sempre declarados globais.

Uniforms: gl_ModelViewMatrix: matriz 4x4 representando a matriz de modelview. gl_ModelViewProjectionMatrix: matriz 4x4 representando a matrix de projeção.

Esses foram alguns exemplos. Há também Varyings pré-definidos e muito mais Uniforms e Attributes. Consulte a seção Links para ter acesso à documentação.

A criação de texturas procedurais em runtime são um ótimo exemplo do quão poderoso os shaders podem ser. Na listagem 1 mostro um exemplo de como criar uma textura simulando uma parade de tijolos. Na figura 2 pode-se ver o resultado.

É possível também criar seus próprios Attributes, Uniforms ou Varyings personalizados como mostra os exemplos abaixo: attribute vec3 rotacao uniform mat4 matrix_de_textura varying vec3 vetor_normal Figura 2: Resultado do Shader

Funções A GLSL já possui algumas funções para ajudar o desenvolvedor nas tarefas mais rotineiras. Alguns exemplos: abs,

Listagem 1: Brick Shader Exemplo. // Vertex Shader uniform vec3 LightPosition; const float SpecularContribution = 0.3; const float DiffuseContribution = 1.0 - SpecularContribution; varying float LightIntensity; varying vec2 MCposition; void main(void) { vec3 ecPosition = vec3 (gl_ModelViewMatrix * gl_Vertex); vec3 tnorm = normalize(gl_NormalMatrix * gl_Normal); vec3 lightVec = normalize(LightPosition - ecPosition); vec3 reflectVec = reflect(-lightVec, tnorm); vec3 viewVec = normalize(-ecPosition); float diffuse = max(dot(lightVec, tnorm), 0.0); float spec = 0.0;

A GLSL já possui uma lista de qualificadores pré-definidos e que podem ser utilizados. Abaixo cito alguns exemplos:

}

if (diffuse > 0.0) { spec = max(dot(reflectVec, viewVec), 0.0); spec = pow(spec, 16.0); LightIntensity MCposition gl_Position

Attributes em Vertex Shaders:

http://www.jogospro.com.br

Exemplo de Shader

Attributes, Uniforms e Varyings Personalizados

Attributes, Uniforms e Varyings Internos e Reservados

gl_Vertex: Vetor 4D representando as coordenadas do vértice sendo processado. gl_Normal: Vetor 3D representando as coordenadas da normal do vértice.

floor, ceil, mod, noise1, etc... Para uma lista completa consulte as referências citadas na seção Links desse artigo.

= DiffuseContribution * diffuse + SpecularContribution * spec; = gl_Vertex.xy; = ftransform();

}

S ET E M B R O 2 0 0 4

J O G O S P R O e-magazine

A R T I G O S Listagem 1: Brick Shader Exemplo. (cont.) // Fragment Shader uniform vec3 uniform vec2 uniform vec2

BrickColor, MortarColor; BrickSize; BrickPct;

FarCry, Unreal 2004) talvez impulsione as fabricantes e façam com que a GLSL se estabeleça de vez como uma das linguagens padrão de desenvolvimento de shaders no mercado de computação gráfica.

varying vec2 MCposition; varying float LightIntensity;

Links 3Dlabs, principal desenvolvedora do GLSL http://www.3dlabs.com

void main(void) { vec3 color; vec2 position, useBrick;

OpenGL Shading Language (Orange Book) http://www.3dshaders.com

position = MCposition / BrickSize;

ATI GLSL exemplos http://www.ati.com/developer/sdk/RadeonSDK/Html/ Samples/OpenGL/GLSLSimpleShader.html

if (fract(position.y * 0.5) > 0.5) position.x += 0.5; position = fract(position); useBrick = step(position, BrickPct);

}

color = mix(MortarColor, BrickColor, useBrick.x * useBrick.y); color *= LightIntensity; gl_FragColor = vec4 (color, 1.0);

Site pessoal do Humus com diversos exemplos interessantes http://esprit.campus.luth.se/~humus Site pessoal de Zaprjagaev Alexander. Seus últimos exemplos usam GLSL http://www.frustum.org OpenGL Shading Language Designer http://www.typhoonlabs.com OpenGL Brasil http://www.opengl.com.br

Como integrar os Shaders ao OpenGL A integração dos Shaders é simples e direta utilizando-se extensões do OpenGL. Para isso você deve transformar seu Shader Source (código fonte do shader) em um Shader Object. Então, compilar o Shader Object. Feito isso, deve-se linkar o Shader Object compilado ao Program Object que é obtido diretamente da própria aplicação OpenGL. Na Listagem 2 mostro um exemplo de como fazer isso tudo:

Conclusão A GLSL se mostrou como uma linguagem eficiente, muito promissora e de fácil integração a qualquer design existente. O grande problema dela hoje é o fraco suporte que as grandes fabricantes de placa de vídeo oferecem. Apesar dos drivers novos da Nvidia (série 60) e da ATI (Catalyst 4.3) já oferecerem suporte a GLSL, não espere uma impletanção completamente estável e livre de bugs.

Mas com a tendência de todos os games do futuro de utilizarem os shaders para efeitos especiais (como já fazem Doom3, http://www.jogospro.com.br

Listagem 2: Exemplo de como integrar Shaders ao OpenGL char * my_frag_shader_source; char * my_vert_shader_source; // Obtem o fonte do Vertex e Fragment Shaders my_frag_shader_source = GetFragmentShaderSource(); my_vert_shader_source = GetVertexShaderSource(); GLenum my_program; GLenum my_vertex_shader; GLenum my_fragment_shader; // Cria o Shader e Program Objects my_program = glCreateProgramObjectARB(); my_vertex_shader = glCreateShaderObjectARB(GL_VERTEX_SHADER_ARB); my_fragment_shader = glCreateShaderObjectARB(GL_FRAGMENT_SHADER_ARB); // Carrega os Shader Sources para os objects glShaderSourceARB(my_vertex_shader, 1, &my_vert_shader_source, NULL); glShaderSourceARB(my_fragment_shader, 1, &my_frag_shader_source, NULL); // Compila os Shaders Object glCompileShaderARB(my_vertex_shader); glCompileShaderARB(my_fragment_shader); // Linka os Shader Objects ao Program Object glAttachObjectARB(my_program, my_vertex_shader); glAttachObjectARB(my_program, my_fragment_shader); // Linka o Program Object glLinkProgramARB(my_program); // Usa o Program Object glUseProgramObjectARB(my_program);

S ET E M B R O 2 0 0 4

J O G O S P R O e-magazine

por Daniel “NeoStrider”Monteiro

S

A R T I G O S

Iniciando no SDL DL. Você já deve ter ouvido falar em algum lugar essas três letrinhas juntas.

Talvez tenha sido em algum jogo de Linux...Ou foi em um emulador (mesmo em Windows).Não foi em uma port de alguma aplicação antiga? A probabilidade de algumas dessas perguntas ser verdadeira é muito grande. A SDL está por todo o canto. Mas o que é a SDL além daquela DLL que você precisa ter?

O que você precisa para entender de SDL? Tudo que se precisa para a compreensão deste artigo é uma noção de programação concorrente e alguma noção no conceito de plataforma.

O que é a SDL? SDL significa Simple Directmedia Layer. Mas o que exatamente significa isso? O fato de ser uma camada de acesso à Mídia Direta (Simple Directmedia Layer) significa que ela atua como uma camada de software, simplificando nosso trabalho na produção de conteúdo multimídia. Como ela é Simples, não podemos esperar tudo pronto dela, pois isso seria de fato um entrave nas tarefas de tradução de aplicações multimídia de outras plataformas.

A filosofia simples permite que adicionemos módulos ao nosso gosto.

Como funciona essa camada?

Ela filtra o que é relevante para a produção de mídia do que é padrão para a inicialização de uma aplicação na plataforma alvo. Para ficar mais fácil imaginar, pense numa aplicação para windows: Dentre muitas inicializações necessárias, é possível escolher muitos tipos de aplicações que o windows suporta. Mas pense em aplicações que usam janelas. Elas, no mínimo, compartilham de algum código de inicialização. Como o que desejamos são aplicações simples multimídia, usando acesso dire-

http://www.jogospro.com.br

Figura 1: Imagens da Cube Engine, desenvolvida com o SDL e OpenGL. to, todas as nossas aplicações serão focadas na saída em forma de mídia e na entrada do usuário.

Foco na saída de mídia é algo constante para a SDL. Por pensar em acesso direto à tela cheia e não em janelas múltiplas, é fácil pensar que todas as aplicações candidatas a serem feitas em SDL teriam uma inicialização parecida se feitas em Windows.

Por fim, esta camada tem uma terceira função: ela funciona de forma multi-plataforma. Sim, se você quer que seu programa Windows rode em Li-

nux, por exemplo, e não quer alterar seu código quase nada ou até mesmo sem altera-lo, a SDL permite isso.

Basta seu programa ser feito usando apenas componentes comuns.

Como é um programa SDL A SDL trabalha em sistemas operacionais multitarefa, portanto ela precisa responder a eventos do seu ambiente de execução.

Normalmente os programas em SDL envolvem três ou quatro partes:

Daniel Monteiro é aluno da Universidade Federal Fluminense e programador de jogos indie nas horas vagas.Enquanto não esta envolvido com desenvolvimento para móbiles (Symbian C++ em Series 60 1.0) e SDL ele gasta seu tempo em diversas atividades, que vão de jogar Xwing vs Tie-Fighter (como imperial , lógico) a pesquisar sobre música.

S ET E M B R O 2 0 0 4

J O G O S P R O e-magazine

A R T I G O S Inicialização: Tipicamente contém SDL_Init() e inicialização de recursos Tratamento de eventos: Aqui é necessário tratar eventos do Sistema. A SDL já filtra o que é pertinente a seu programa, então não é necessário despachar o resto dos eventos.

Operações de dados internas: Aqui se processa e exibe surfaces, se envia dados de áudio para a SDL, etc.

Desinicialização: Aqui dealocamos todos os recursos alocados e liberamos a SDL. Aqui não precisamos necessariamente terminar nosso programa, mas após SDL_quit, não devemos mais usar nada de SDL.

A Inicialização Na inicialização, usamos principalmente Sdl_init para incializar os sub-sistemas da SDL. Mas por que incializar módulos separados?

SDL é uma API feita para funcionar em diferentes variedades de plataformas e para sistemas onde determinados recursos inexistem, esta é uma forma de evitar problemas nas adaptações.

A forma mais geral de incializar é incializar tudo com SDL_Init(SDL_INIT_ EVERYTHING). Vale lembrar que os subsistemas da SDL devem ser usados com cuidado e usar SDL_INIT_EVERYTHING não é uma boa solução para todos os casos.

Quanto a inicialização de recursos, o mais comum é incializar surfaces, seja carregando arquivos de imagens pronto, quanto criando surfaces vazias na memória.Outros recursos interessantes são áudio e operações de leitura de dados de CDROM e armazenamento persistente de forma independente de plataforma.

Tratamento de eventos Este pedaço é mandatário para programas interativos, mas quando se trata de um programa curto que realiza alguma operação e finaliza, não é necessário tratar eventos.

O tratamento de eventos ocorre de forma independente de plataforma e não usa uma função de callback para tratamento geral (como é comum se acredihttp://www.jogospro.com.br

tar). Tudo pode ocorrer em uma linha, se não for desejo do criador que seu programa trate eventos, mas que ao menos despache para o sistema os eventos que não são de sua pertinência. Em geral tudo é feito de um switch(),que deve ser chamado explicitamente pelo programador, com o cases sendo os tipos de evento.

Marathon - Jogo de MacOS refeito em SDL e rodando Neste ponto é que norperfeitamente em Windows. malmente se obtém a entrada do usuário. Vale lembrar que os Ela merece descansar. Um problema vários dispositivos de entrada possuem comum nos programas SDL em seu essua própria filosofia de informar intera- tágio inicial é o desleixo com esta parte fundamental do programa. Por fim, sesção. sões intermináveis de sucessivas execuções da aplicação – que aloca sem deOperações de dados internas salocar recursos – resulta em memória Agora acontece o processamento que a fragmentada e problemas na alocação SDL tanto espera que o desenvolvedor de dados por parte de execuções de oufaça: a manipulação de dados e a ope- tras aplicações. Neste ponto, encerrar o ração de saída de dados na forma mul- comprometimento com determinados dispositivos pode ser importante para timídia. seu funcionamento. Negligenciar isto Mais uma vez, como ocorre na entrada pode levar a resultados imprevisíveis. de dados, cada dispositivo de saída tem O que eu tenho com tudo isso? sua forma de saída:

• O vídeo funciona por simples operações de surfaces, sendo que o resultado deve ser copiado para uma surface que representa a tela. Esta surface tem uma série de funções de auxílio, da mesma forma que as surfaces de memória tem suas funções especificas, sendo que o uso de funções de uso geral com a surface de tela pode gerar resultados imprevisíveis.

• O sistema de áudio funciona de forma bem próxima ao que se pode esperar da programação dos sistemas em modo real. Devemos enviar dados continuamente para o dispositivo de áudio. Pelo menos desta vez temos um toque de modernidade, pois isso é realizado por uma função de Callback. Assim, criamos essa função e eliminamos nossos problemas.

Deinicialização Neste ponto cabe a liberação de todos os recursos alocados (surfaces, chunks de áudio, etc) e a finalização da SDL.

Uma aplicação multimídia é feita de entrada e saída em diferentes formas de mídia. O resumo acima acabou de mostrar uma pequena fração de tudo que a SDL tem a oferecer ao desenvolvedor sem medo. Arrisque-se a visitar www.libsdl.org para ver o que já foi feito, o que esta se fazendo, o que esta para ser feito e o que você pode ajudar a fazer.

Links Site Oficial do SDL http://www.libsdl.org Site do Autor http://www.makingthegame.tk Diversos Artigos de SDL traduzidos http://www.pdj.com.br Cube Engine http://www.cubengine.com Marathon 2 http://marathon.bungie.org Tutoriais de SDL + OpenGL http://cone3d.gamedev.net

S ET E M B R O 2 0 0 4

J O G O S P R O e-magazine

por Wilson “WolveWilson” Jr.

A R T I G O S

2D .NET games: Usando GDI+ (Parte 1 de 3)

N

este artigo veremos como a GDI+, que é utilizada para gráficos simples em .NET, pode ser utilizada para a criação de jogos 2D de forma simples e funcional. Nesta primeira parte aprenderemos os conceitos; Na segunda parte passaremos para recursos mais avançados; Na terceira e última, iremos partir para a implementação de um jogo.

Introdução ao GDI+ O Windows contém muitas opções de controles que são usados para exibir informações. Como não é impossivel cobrir todas as necessidades de todas as aplicações, alguns programas não fazem uso desses componentes ‘standard’.

Eles optam por criar seus próprios gráficos, imagens , shapes (formas) e etc... Para atender a essas necessidades, o desenvolvedor tem a sua disposição a API chamada GDI+.

Antes de começar ‘sujar’ nossas mãos com código, vamos estudar as técnicas principais que estaremos usando.

O namespace de System.Drawing contem todas as classes que nos ajudarão realizar nosso objetivo. Existe também o namespace mais avançado, o System.

Drawing.Drawing2D, este poderia gerar um novo artigo inteiro, assim como as especializações System.Drawing.Printing especializado, System.Drawing.Text e System.

Drawing.Imaging, que fornecem imprimir, tipografia e e suporte a imagens. Estaremos falando sobre eles e nossos próximos artigos.

Começando pelo System.Drawing, vamos examinar as classes mais importantes para nós. A classe Graphics é fundamental aqui, e re-

http://www.jogospro.com.br

presenta um contexto de display (exibição). Um contexto de display pode ser considerado como um objeto genérico que fornece alguns métodos para desenhar shapes clássicos (linhas, curvas etc..), texto, usando vários estilos da linha (“pens”) e estilos da preenchimento (“fills”). Dessa forma o programador não tem que se preocupar com hardware e dispositivos de saída específicos. As funções e a maneira como são usadas são as mesmas em computadores com hardware diferente.

Um programador não cría explicitamente objetos dos gráficos usando o operador new. Na maioria das vezes, o objeto é obtido indiretamente pelos argumentos passados do sistema operacional à aplicação. Uma vez que nós temos o objeto em nossas mãos, é muito fácil extrair formas usando seus métodos self-describing. Por exemplo, o método de DrawImage() nos exibe uma imagem, enquanto que o DrawLine(), o DrawRectangle(), o DrawCurve() e o DrawArc() são usados criar formas básicas. Há algumas classes

no namespace de System.Drawing que pode ser passadas como parâmetros a estes métodos. A classe Pen é usada para especificar um estilo da linha usado para desenhar a forma e a classe Brush especifica um estilo de preenchimento para formas fechadas. Há algumas classes úteis em especificar áreas e posições na área do cliente (uma área cliente é a parte da janela que uma aplicação tem disponível, que é a janela inteira menos a barra do título, barras de menu/tool, status e barras de scroll). Considerando a posicao 0,0 do formulario o ponto mais alto e mais a esquerda, a classe Point representa um único pixel, cujas as coordenadas sejam mantidas variáveis no membro de X e de Y da classe. X é um inteiro que represente a distância do pixel da parte mais a esquerda da janela do cliente, e Y está a uma distância do ponto 0 (zero). Similarmente, a classe Rectangle (retângulo) representa uma área retangular. Um de seus construtores faz uso de dois objetos do tipo Point (para a parte superior a esquerda e a parte inferior a direita do retângulo).

Redesenhando Gráficos Windows é um sistema operacional complexo. Compreender completamente como tudo trabalha não é realmente uma tarefa trivial,

Wilson Junior. Formado em Informática pela PUC-RIO. Atua na área de informática a 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, Assembler, e atualmente, C#. Atualmente esta envolvido com o projeto Last Energy um shoot’em up 3D.

S ET E M B R O 2 0 0 4

J O G O S P R O e-magazine

A R T I G O S Listagem 1: Exemplo mainform.cs 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(); } [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 de /// signer 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 = 150; 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 + 5; y =y + 5; Invalidate(); //Força o repaint em toda 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

S ET E M B R O 2 0 0 4

J O G O S P R O e-magazine

A R T I G O S e operações aparentemente simples requerem muito trabalho do computador. Uma destas tarefas “simples” é a seguinte: Imagine que um usuário está executando dois programas simultaneamente, cada em sua janela separada.

O primeiro programa esta exibindo a agenda do dia, e o segundo é um browser internet, exibindo algum Web site. De repente, o usuário move seu browser sobre uma parte do primeiro programa.

Eficazmente, essa parte da janela do primeiro programa desapareceu, porque uma outra janela esta sobe ela. Naturalmente, nós temos o sentimento que a informação armazenada lá não é perdida realmente - as janelas devem ter uma maneira redesenhar o que quer que estava lá. E isso é verdadeiro. Se nós movermos, afastando da primeira janela, nosso browser outra vez, a parte do primeiro programa que estava ‘escondida’ se torna visível outra vez. O que está acontecendo realmente?

A parte que apareceu não foi recuperada outra vez diretamente para a memória. Seria um desperdício de recursos se o sistema operacional armazenasse a exposição do video de cada programa na memória - imagine que nós podemos ter muitas janelas, uma no alto do outra. De fato, Windows diz somente a aplicação , no nosso caso a primeira, que ela tem que redesenhar uma parte dela, em exibição, por causa de um evento especial (no nosso caso, o mover de uma outra janela), após isso, a aplicação é responsável pelo que acontece. A ação mais comum para a aplicação é, naturalmente, a de redesenhar essa área específica da janela.

Windows realiza isso emitindo eventos especiais a cada aplicação. É a forma do sistema operacional de “dizer” aos programas de que algo aconteceu no computador de forma que a aplicação possa executar uma função apropriada.

Os eventos fundamentais incluem cliques do mouse e pressionamento de teclas - existem muitos outros eventos emitidos mas em

http://www.jogospro.com.br

Figura: Saída do programa da Listagem 1. nosso caso, nosso interesse esta nos eventos chamados de Paint (Pintura). O Windows emite-os automaticamente a todos os programas que necessitam redesenhar alguma parte de sua interface do usuário. Em nosso exemplo acima, assim que nós movêssemos a janela de browser para trás para seu lugar original, Windows emitiria ao primeiro programa, um evento de Paint. É como se ele estivesse “dizendo” a esse programa que algo aconteceu e necessita redesenhar uma parte específica de sua janela. A informação de que a parte necessita redesenhar seria passada também junto com o evento. Felizmente, esta mensagem que emite e que redesenha é ‘recebida’ automaticamente pelos controles standard. Realmente, a classe Form (formulário) tem um método chamado OnPaint (que é subscrita ,overridden, da classe do Control), que assegura o ‘redesenhar’ automático.

nosso programa necessitará, provavelmente, atualizar seus gráficos não somente quando uma outra janela se move no alto dela, mas quando se minimiza e maximiza outra vez. Isto é, nós emitiremos uma mensagem ao nosso programa que o diga para redesenhar a parte (ou os todos) seus gráficos. A maneira que nós dizemos ao nosso programa para repintar seus gráficos é o método Invalidate().

Nós o encontramos na classe Control, e naturalmente na classe do Form, que a herda. Este método pode ser chamado sem nenhum parâmetro, e neste caso ele redesenhará toda a área do cliente. Mas atualizar partes grandes da exposição de gráficos em intervalos curtos consome muitos recursos.

Na maioria de casos, nós devemos chamar o método que especificamos somente para área onde os gráficos atualizados devem aparecer. Geralmente essa área (suas dimensões) é passada como um objeto Rectangle (retângulo).

Fim da Parte I

Toda a conveniencia de gerencia dos gráficos fornecida pelo Windows, acaba quando chega na GDI+.

Windows não mais atualizara automaticamente as partes da janela da aplicação que têm formas desenhadas nelas pela GDI+. Neste caso, nós teremos que subscrever (override) o método OnPaint, que nós mencionamos antes, e especificamos exatamente como o ‘redesenhar’ ocorrerá. Naturalmente,

S ET E M B R O 2 0 0 4

J O G O S P R O e-magazine

por Matías G. Rodriguez

P o s t M o r t e m

Postmortem do Harena “Harena é um jogo de luta 3D multiplayer com perspectivas nunca antes vistas neste gênero. Explorando a competitividade cada jogador tentará ser o melhor gladiador em vários tipos de arena, além de buscar o reconhecimento dentro da comunidade da Harena.” -- http://www.harena.com.br O Harena é um demo desenvolvido por alunos da primeira turma de Pós Graduação em Desenvolvimento de Jogos da Unicenp. A Pós Graduação teve duração de um pouco mais de um ano com aulas aos sábados. O projeto foi entregue com atraso de vários meses, por uma equipe de 5 pessoas que nunca tinham desenvolvido um demo muito menos um jogo completo. A seguir vamos ver algumas coisas que deram certo e outras que deram errado ao longo do desenvolvimento.

1. O que deu certo.

Reuniões Periódicas: Ao contrário de outras equipes da Pós, todos os integrantes da equipe moravam em Curitiba. Isto facilitava as reuniões que eram feitas uma vez por semana geralmente às quintas-feiras. Tinha bastante pipoca, refrigerante e chocolate.

Passavamos horas discutindo partes do jogo como game design, arquitetura de rede para o multiplayer, renderizador, algoritmos, as matérias da Pós, entre outros assuntos. As reuniões fizeram com que a equipe se mantivesse unida mesmo depois do término das aulas.

Wiki: Logo no começo do projeto criamos um Wiki para colocar nossas idéias, criar atas das reuniões, colocar arquivos referentes ao projeto, receber idéias dos amigos, etc. Ele foi bastante utilizado, mas mais para o final do projeto, caiu em desuso pois a medida que a empolgação foi diminuindo, o fato de ter que manté-lo era uma atividade tediosa. Para quem não sabe o que é um wiki: http://www. c2.com/cgi/wiki?WikiWikiWeb CVS: Bem antes de ter programado uma linha de código, já tinhamos disponível um repositorio CVS onde todos os integrantes da equipe podiam compartilhar os recursos (código fonte, imagens, modelos, etc) do projeto. Isto fez com que o desenvolvimento fosse um pouco mais profissional e menos amador.

Artista na Equipe: Originalmente a equipe era composta por 4 programadores, mas http://www.jogospro.com.br

tomando uma decisão estratégica, decidimos “roubar” um integrante com conhecimento de modelagem 3d de outra equipe.

A outra equipe reclama até hoje.

Esforço Final: Faltando 2 semanas para a data de entrega ainda não tinhamos o demo jogável. Se continuassemos trabalhando no esquema de só nas horas vagas não conseguiriamos terminar. Por isso decidimos pedir férias do serviço, das esposas e namoradas com o argumento de que finalmente íriamos terminar e ter mais tempo para elas. Assim começamos a trabalhar num ritmo bem mais acelerado, principalmente na última semana. Foi neste período que desenvolvemos o networking, suporte às animações, suporte a som/música e a lógica do jogo em sí.

vezes tentamos montar um cronograma realista do desenvolvimento mas falhamos todas as vezes. O motivo principal foi que nenhum dos integrantes conseguia mensurar o tempo que ia conseguir trabalhar no projeto a cada semana. Desenvolvendo “nas horas vagas” é muito difícil de chegar a alguma conclusão.

Reuniões Periodicas: Apesar disto ter sido algo que deu certo, chegou uma hora que as reuniões eram mais um encontro “social” do que uma reunião para desenvolver um demo. Antes da pipoca acabar não se discutia nada relamente relevante ao projeto.

Então decidimos cancelar as reuniões para usar esse tempo para realmente codificar algo.

Figura 01 - Demo Harena: Visão geral da Ópera de Arame de Curitiba.

2. O que deu errado.

Outros Trabalhos da Pós: O desenvolvimento do demo foi prejudicado pois tinhamos que parar de trabalhar nele para poder entregar trabalhos das diversas matérias da Pós. Geralmente esses trabalhos não estavam relacionados ao demo.

Falta de um Cronograma Realista: Várias

Artistas: Logo no começo, fizemos a divulgação do Harena em várias listas procurando artistas interessados em participar do projeto. Várias pessoas ficaram interessadas. Ao longo do projeto devemos ter falado com 5 artistas (entre modeladores 3d e desenhistas) os quais se comprometeram a participar mas, se algum deles durou mais de 3 semanas foi muito. A única exceção S ET E M B R O 2 0 0 4

J O G O S P R O e-magazine

P o s t M o r t e m

Figura 02 - Demo Harena: Oito jogadores lutando dentro da Ópera de Arame de Curitiba.

foi quem fez a arte conceitual de alguns dos personagens do jogo, ele já tinha experiência (fazia desenhos para a revista da Nintendo no Chile).

Falta de Experiência da Equipe: A equipe não tinha nenhuma experiência em jogos.

Mas isto era aceitável, pois essa era mesmo a idéia do projeto final da Pós (o demo): ganhar experiência.

3. O dia da Entrega. É um dia que vai ser lembrado por toda a equipe, foi o fim de um projeto de mais de dois anos. Finalmente chegara a hora do tudo ou nada, a tensão era grande. Trinta minutos antes da entrega oficial ainda estavamos tentando tirar bugs do networking e o renderizador. Quinze minutos antes decidimos deixar como estava, compilar pela última vez, pegar nossos computadores, hub, cabos de rede, monitores (inclusive um de 21 polegadas) e ir para a Unicenp.

Chegando lá, levamos aproximadamente meia hora para montar nossa LAN formada por 4 computadores. Um para rodar o servidor dedicado e 3 clientes. O encarregado de avaliar nosso projeto era o coordenador do curso. Por incrível que pareça nada deu errado pois geralmente é nas apresentações que os bugs aparecem. Mas não neste caso, tudo funcionou, inclusive as coisas que a gente sabia que causavam bugs, quando o coordenador as fez, milagrosamente, funcionaram sem problemas.

Ele gostou muito do projeto e nos deu parabéns seguido da nota máxima. Por um http://www.jogospro.com.br

momento, sentimos que éramos “os reis do mundo”, capazes de fazer qualquer coisa, eramos capazes de desenvolver jogos. É algo realmente difícil de descrever.

4. Conclusão.

O Harena foi um demo desenvolvido por uma equipe de pessoas inexperientes que optaram por usar os seus sábados e tempo livre para tentar aprender um pouco de desenvolvimento de jogos na pratica e apostar num mercado incerto e complicado. Tudo indicava que a equipe não conseguiria terminar o projeto. Mas contra todas as previsões eles provaram que com força

de vontade, determinação e muito trabalho é possível encarar o desafio de desenvolver um demo de jogo e alcançar o sucesso esperado.

Matías Gonzalo Rodriguez é formado pela Unicenp em Desenvolvimento de Jogos. Entusiasta das linguagens C/C++, Java e Smalltalk. Gosta de jogar e desenvolver Jogos em suas horas vagas.

Figura 03 - Da esquerda para a Direita: Marcelo Walter, Eduardo Akatsu, Matías Rodriguez, Bohdan Metchko Jr, Uriel Segall S ET E M B R O 2 0 0 4

J O G O S P R O e-magazine

Fim do Jogo

por Carlos Caimi

E o Futuro é logo ali

P

rever o futuro é algo fascinante.

Ninguém acerta, mas volta e meia a gente encontra algum louco tentando prever o que vai acontecer daqui há alguns anos. Cada coisa maluca. Lembro de uma, da década de 70: uma família sentada a mesa, e vinha uma bandeja, apoiada num tremzinho que andava sobre trilhos, com a refeição a ser servida. Uma clássica adaptação do ferrorama!!!.

Mas como, de desenvolvedor de jogos e de louco todo mundo tem um pouco, vou arriscar o que me resta de sanidade e, tentar expor as tendências que a evolução dos jogos poderá seguir nos próximos anos. Para evitar erros grotescos, e que algum outro maluco tire sarro deste artigo, vou me basear na evolução de algo intimamente ligado a jogos. A tecnologia.

Mas minha bola de cristal se baseia em apenas duas regras que servirão de alicerces para essa extrapolação.

A primeira, e mais famosa, é a Lei de Moore.

Ela nos diz que computadores dobram de processamento a cada 18 meses.

A segunda, menos conhecida, é que uma nova tecnologia leva aproximadamente 20 anos para se popularizar. Exemplo clássico é a Internet. Iniciou em 1969 e em 1999 já era de domínio público.

Mas afinal, em que parte do futuro queremos olhar 10, 50 ou 100 anos? Todo mundo já ouviu falar que a tecnologia avança de maneira exponencial. Mas quase ninguém houve falar que o pensamento humano progride linearmente. E é exatamente por isso que não conseguimos prever com precisão o que a tecnologia nos reserva.

Em curtos períodos é possível uma aproximação com grandes possibilidades de acerto, mas quanto mais adiante olharmos, mais nebuloso fica, logo não nos interessa na prática. Por isso vou estabelecer como meta o ano de 2020.

Fato 1: Os processadores poderão ser fabricados com a tecnologia atual, com leves alterações, até aproximadamente 2020.

Então até lá, não teremos Computadores Quanticos, nem genéticos, nem Óticos, ou qualquer outro. A era do silício, a trancos e barrancos, chegará a 2020.

Previsão: Essa é fácil. Tudo que depende de processamento em jogos sempre terão melhorias significativas. Veremos gráficos cada vez mais bonitos, a física cada vez mais realista e inteligência artificial cada vez mais parecida com a inteligência humana.

Fato 2: O nome do bicho é Computação Onipresente. Esse conceito que esta em franca expansão é o aperfeiçoamento e http://www.jogospro.com.br

massificação dos chips de computadores.

Na verdade já estamos vivendo nesse mundo. Ou seja, estaremos conectado com o mundo virtual praticamente em qualquer lugar, em qualquer hora, em qualquer situação. Em casa, no trabalho, no carro, no celular, na roupa, no óculos, em breve na televisão (televisão digital no Brasil) sem realmente tomar consciência disso.

Previsão: a) Jogos multiplayer acontecerão em qualquer lugar e em qualquer hora.

Computadores jogando com consoles, jogando com celulares, jogando com PDA´s, etc... b) Você não estará preso a um único dispositivo para jogar. Poderá começar no PC, continuar no Console, e terminá-lo, utilizando seus óculos com mini-telas, a caminho da lanhouse, porque afinal, é sempre bom relembrar os velhos tempos.

Fato 3: A tecnologia já existe, mas faltava uma utilização para ela. Com processadores mais velozes sobrará mais tempo para um reconhecimento de voz mais preciso.

E cada vez mais teremos jogos sendo comandados, além do teclado, mouse e joystick, também por microfones.

Previsão: O reconhecimento de voz será a próxima evolução na jogabilidade dos jogos do futuro. E juntamente com uma IA mais avançada, ele alavancará uma nova maneira de jogar, e arrisco a dizer, até um novo estilo de jogo. Isso vai chegar muito antes que tenhamos computadores com percepção extra-sensorial.

force-feedbacks. Sem contar capacetes que reconhecem para onde você esta olhando.

Previsão: A jogabilidade irá mudar muito até 2020. Imagine-se coberto com toda essa parafernália e jogando um jogo de ação. Essas novas interfaces só precisam de tempo para se estabelecer e cair no gosto dos jogadores.

Poderíamos extrapolar, e muito, essa conversa sobre o futuro dos jogos. Mas resolvi me contentar em apenas identificar as tendências tecnológicas que estaremos presenciando nos próximos anos. Pelo menos até o final previsível da era do silício.

Depois de 2020 estaremos vivenciando uma nova era na informática. Um novo tipo de computador, os óticos são fortes candidados. Capacidades surpreendentes de armazenamento, com novas memórias holográficas. Internet super rápida e a computação onipresente, todos eles abrem inúmeras possibilidades de imaginarmos os mais variados tipos de jogos. Mas, como sei que você já tá perguntando. E a Matrix, onde fica nisso tudo. Bom talvez o século 22 chegue antes.

Esse artigo foi baseado no livro Visões do Futuro (Visions), do físico Dr. Michio Kaku.

Leitura recomenda para todos aqueles que curtem tecnologia.

Fato 4: O dinheiro, em meio físico, esta acabando. Dos 4 trilhões aproximados existentes circulando no mundo, apenas 10% dele está em espécie.

Previsão: O jogo de caixinha vai acabar.

Com a internet mais rápida, e onipresente.

O jogos serão comprados e baixados digitamente. Usando dinheiro digital para um mundo virtual. Essa previsão, na verdade, é apenas mais uma conseqüência da Computação Onipresente. Resolvi incluir apenas por que afetará nossa maneira de comprar jogos.

Fato 5: Imersão. Esta palavrinha tão batida por nós, desenvolvedores de jogos, também sofrerá grandes mudanças. Novos dispositivos de interface homem-máquina são lançados a cada dia no mercado. Hoje já temos: Óculos com mini-telas de 52 polegadas, luvas para realidade virtual, já existem monitores holográficos e mouse com

Carlos H Caimi - defiler@brturbo.com.br, é pós-graduado em Desenvolvimento de Jogos pela Unicenp, editor da JogosPRO e-Magazine e nas horas vagas, se não tá programando, tá jogando.

S ET E M B R O 2 0 0 4

J O G O S P R O e-magazine

Expediente E xpediente Editor-Chefe: Carlos H. Caimi Editor-Assistente: Bruce “Sinner” Diagramação: Bruce “Sinner” Carlos H. Caimi Colaboradores: Carlos H. Caimi Bruce “Sinner” Julio Marchi Daniel Monteiro Alessandro V. dos Reis Paulo R C Siqueira Wilson Jr. Alexandre “DarkFenrir” Matías G. Rodriguez Webmaster: Bruce “Sinner” Agradecimentos: Ao pessoal da lista JogosPRO pelo surgimento da idé idéia.

Fábio Binder Ignis Games Continuum Southlogic A todos que nos apoiaram e não foram mencionados, vocês sabem quem são!

Contato: jogospro@jogospro.com.br