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

Caros leitores

Ao final de julho de 2004, surgiu na lista jogospro a idéia de criarmosuma 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 maisempolgados 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 co-munidade 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 brasilei-ras 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, divul-gue seu projeto, critique e dê sugestões para aprimorarmos sempre a nossa revista. Envie-nos cartas! O email é [email protected]. Acesse o site e sinta-se a vontade.

- Carlos H. Caimi, Editor-Chefe

Editorial

ConteúdoProjeto3 Anima Projectpor Alexandre “Darkfenrir”

Capa6 Empresas Brasileiras de Jogospor Carlos H. Caimi

Colunas10 Java no desenvolvimento de jogospor Paulo R. C. Siqueira

14 Videogames no Cyberpunk de William Gibsonpor Alessandro Vieira dos Reis

16 Jogos Open Source: Utopia, modismo ou necessidade?por Julio Marchi

Entrevista19 Fábio Binderpor Carlos H. Caimi

Artigos29 Introdução ao OpenGL Shading Languagepor Bruce “Sinner”

23 Iniciando no SDLpor Daniel “NeoStrider” Monteiro

25 2D .NET games: Usando a GDI+ (Parte 1)por Wilson Jr.

PostMortem28 Postmortem do Harenapor Matías G. Rodriguez

Fim do Jogo31 E o Futuro é logo alipor Carlos H. Caimi

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 superficielunar, encarar desavenças políticas, e finalmente des-cobrir que seu colega lhe traiu por interesses únicos e egoístas... Lutar com armas e veiculos de ultima tecno-logia, e simultaneamente derrotar um dragão vulcânico que varre inumeras tropas com seu halito flamejante ! Oumelhor ainda, descobrir que você esta sendo manipula-do por uma mega corporação e pelo próprio governo no qual você trabalha !!! “. Este é o mundo de Anima Project , um duelo de extre-mos, 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 va-lores, 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 des-tino da nova Terra esta em jogo !!!

Assim surgiu o conceito que sus-tenta todo o contexto por trás

desta incrivel aventura ! E lembre-se que você, é mais

do que nunca, o perso-nagem 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 “Tec-noFantasy”, que mistura elementos da fantasia medieval com técnologia e elementos cyberpunk. O mundo de Anima Project consiste no duelo de extre-mos, 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: eleserá explorado de diversas maneiras, num futuro próxi-mo; 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, man-gás, novelbooks... >> RESUMO DA HISTÓRIA - Uma antiga profecia se concretizou, e o mundo dos ho-mens entrou em colapso: guerras, desavenças e catástro-fes 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 bruscamen-te, 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 espe-ravam se reencontrar, nem mesmo entenderam um fato: que o mundo estava se recriando, desde o princi-pio 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 se-res “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 varian-te de seres humanos, os “Alterados”, começou a repo-voar 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

Projeto Anima, que visa desco-brir 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 con-flito : Teraneans (habitantes de Subteranea), Seluneans(habitantes da colônia da Lua), Alterados (os humanos mutantes que povoaram o novo mundo).

>> 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 PHAN-TASY 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 é queesta 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 compre-ensã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. 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 mul-tiplayer famosos, como Diablo, Phantasy Star Online e Ragnarock. Para isso negociaremos com alguma softhou-se 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ãoDEMO 2.0, com mais horas de jogo. Equipe Anima Project 2004Todos os direitos reservados

www.animaproject.make5.com.br [email protected]

Empresas Brasileiras de JogosA difícil arte de desenvolver jogos no Brasil

Porque 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 amadu-recimento 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 Jogos-

PRO entrou em contato com essas empresas para tentar descobrir o segredo do sucesso, e o que elas estão planejando para o futuro.

JogosPRO: A Southlogic desenvol-veu 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 publica-dor. Muitos querem ter uma noção o mais precisa possível do que o de-senvolvedor é 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 propos-ta 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á ou-vimos 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 merca-do fora do Brasil, vocês pretendem

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, aentrada desses produtos no merca-do brasileiro é difícil por causa da baixa popularidade desse esporte por aqui. Esse tipo de produtotem como mercados principais os EUA e Canadá. Acredito que quando lançarmos outros gêneros de jogos a probabilidade deles seremamplamente distribuídos no Brasil vai aumentar. Quanto a produzir um jogo especificamente para o mercado brasileiro, com conteúdovoltado 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 desenvolverjogos 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 Gui-mo para Windows (atualmente o

jogo tem problemas de compatibili-dade 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 re-escrito 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 cresci-mento da empresa?

SL: Com certeza foi uma das de-cisões mais certas que tomamos durante esses anos. Uma empresa desenvolvedora de jogos e tecnolo-gia precisa sobreviver por um bom tempo sem ter faturamento até atin-gir um nível mínimo para realmente atuar no mercado. A incubadora

C A P A

.:Entrevista South Logic

por Carlos Caimi

J O G O S P R O e-magazineS E T E M B R O 2 0 0 4http://www.jogospro.com.br

nos permitiu ter esse tempo, que apesar das dificuldades, foi impor-tantíssimo.

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

SL: O mercado de consoles é muito maior que o de PC, portanto os pu-blicadores preferem jogos para con-soles, e de preferência para PS2. Não tenho dúvidas que um desenvolve-dor para console, ou até de múlti-plas 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 possi-bilidades nessa direção. Infelizmente existem “percalços” nesse caminho por estarmos aqui no Brasil. Dá pra acreditar que em 2004 ainda acon-teç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 ven-dem o hardware ele está sendosubsidiado pelo fabricante, ou seja,

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

Brasil que deixa algunsfabricantes muito descontentes. O que isso tem haver com a seriedade do desenvolvedor de jogos brasilei-ro 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 de-senvolvido no sentido de empregos e poder aquisitivo não pode-mos esperar que um mercado de produtos “supérfulos” como os jo-gos 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 duran-te uma fase de transição, as empre-sas que publicam hardware e jogos devessem ajustar aquele modelo econômico no nosso mercado, pro-vavelmente reduzindo suas margens de lucro.

JP: Teremos uma versão dos Hunter´s para con-sole?

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

JP: Qual os próximos pas-sos da Southlogic?

SL: A nossa meta é enri-quecer o portfólio da em-presa com bons jogos e ir crescendo aos poucos, formando mais pessoal, e

com projetoscada vez mais desafiadores. Não me importo tanto em qual a platafor-ma desenvolver, o mais importante para nós nesse momento é ter boas oportunidades de mostrar o nosso trabalho.

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

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 osjogos 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, docu-mentação, etc). Também conhecer as ferramentas gráficas, de som e de desenvolvimento comoferramentas de controle de versão. Ao mesmo tempo, você precisa se juntar a outras pessoas que se inte-ressam por jogos e com habilidades complementares - os jogos são produtos criados por pessoas com conhecimentos multidisciplinares (arte, programação, design, adminis-tração, etc). E mais aquela clássica de sempre: ficar atento as oportuni-dades e ao que está acontecendo no mercado, para maximizar as chances de sucesso. E como não é um merca-do fácil, recomendo uma boa dose de persistência e de dedicação. �

C A P A


JogosPRO: A Continuum surgiu no ambiente acadêmico e depois consoli-dou-se como empresa para comercia-lizar o Outlive. Vocês consideram essa estratégia, de desenvolver uma demo, buscar patrocínio e depois uma dedi-caçã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 de-senvolvimento com os publicadores, além de ser o modelo de negócios mais comum entre desenvolvedores e publicadores.

JP: Vocês já há dois meses são de-senvolvedores oficiais da plataformaXBOX. 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: Teremos uma versão do OutLive para console?

C: Não temos planos de portar o Outlive para XBOX, pelo menos por enquanto. JP: A Continuum teve sua mar-ca 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.

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

C: Depende muito dos objetivos da empresa. Até algum tempo atrás, nos-so foco era mais amplo e atendiamos este público também. Atualmente estamos com nosso foco restrito ao desenvolvimento de produtos multi-plataforma (PC e XBOX) para os publi-cadores internacionais. Achamos que esta é a estratégia mais adequada para a Continuum. 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: A pirataria de jogos no Brasil afetou de alguma forma o negócio da empre-sa?

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

das. JP: Qual o novo projeto que vocês es-tão desenvolvendo? Vocês poderiam dar essa esclusividade para nós? Ou quando a Continuum pretende divul-gá-lo?

C: Pretendemos divulgar mais informa-ções assim que as negociações estive-rem encaminhadas, o que deve levar ainda algum tempo. JP: Qual a mensagem que a Conti-nuum deixa para quem esta começan-do na área?

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

C A P A

.:Entrevista Continuum


JogosPRO: A Ignis surgiu do trabalho nas horas vagas de seus sócios. Vocês consideram essa estratégia, de desen-volver 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.

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

I: Ajudou muito. Hoje existe muitas in-

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

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

I: Sim. Complementando a questão an-terior, normalmente uma empresainiciante na área conta apenas com pessoal de perfil técnico e isto nãobasta 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 em-presa. JP: Vocês conseguiram uma Capitali-zaçã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 empre-sas 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 conse-guimos é voltado para empresasde tecnologia do Estado do Rio de Ja-neiro. Além disso, é importantea proximidade da empresa com o investidor, pois a colaboração deles é importante para o desenvolvimento do negócio. JP: A pirataria no Brasil influenciou nadecisã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 toma-das em função do mercado e, por uma questão de sobrevivência, não pode ser diferente disso. Nosso focosempre foi o mercado exterior, então não posso afirmar que a piratariateve uma influência significativa nessadecisão. A paixão é o que nosmotiva 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 prin-cipal motivo que nos levoua lançar o Erinia no Brasil também. O público brasileiro ainda tem uma difi-culdade grande em entender que o de-senvolvimento, a distribuição e a ope-ração (no caso dos jogos online) custa muito caro e que, por isso, devem pagar pelo produto. Mas a mentalida-de está mudando rapidamente, e os jo-gagores estão percebendo que, saindo da ilegalidade, estão colaborando para que sejam lançados jogos cadavez 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 viabilida-de 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 difi-culdades que terão pela frente. Nossa profissão é uma das mais difíceis eexigentes 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 desistirnunca, pois não existe recompensa maior que poder trabalhar fazendo o que realmente se gosta. �

C A P A

.:Entrevista Ignis

Southlogichttp://www.southlogic.com.br

Continuumhttp://www.continuum.com.br

Ignis Gameshttp://www.ignisgames.com.br

Saiba mais sobre as empresas


Java no Desenvolvimento de Jogos: Um PanoramaC

OLU

NA

:

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 diver-sas 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.

CENA JAVA

A cada edição, estaremos exploran-do diversas características desta poderosa plataforma, que muitas

vezes é deixada de lado por puro precon-ceito. 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 rapida-mente 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 lingua-gem. Ela é uma plataforma completa de desenvolvimento de software, que abrange desde dispositivos minúsculos, como Smart Cards, até grandes sistemas corporativos, como o sistema da amazon.com (uma aplicação web que processa de-zenas de milhares de acessos simultâneos). A platafor-ma Java está dividida basicamente em três partes (além da especificação de Smart Cards): Java 2 Micro Edition (J2ME), que possibilita o desenvolvimento de aplica-ções para dispositivos móveis, como celulares e Palms; Java 2 Standard Edition (J2SE), que fornece suporte ao desenvolvimento de aplicações Desktop, além de ser o alicerce para a terceira e mais conhecida parte: Java 2 Enterprize Edition, que fornece APIs, frameworks e ou-tras ferramentas para o desenvolvimento de aplicações corporativas, incluindo as famosas aplicações web.

Independente de qual parte da plataforma está sen-do 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

mesmo em todos os casos. Mudam as APIs disponíveis, mas não a sintaxe da linguagem, que é muito parecida com C/C++ - o que permite a programadores dessas linguagens aprenderem Java facilmente.

Agora que já temos o conhecimento básico sobre o que é Java, podemos falar do que realmente nos interessa: o desenvolvimento de jogos!

Figura 1 – Arquitetura básica da plataforma Java

por Paulo R. C. Siqueira

Paulo R. C. Siqueira é desenvolvedor Java, Programador Cer-tificado pela Sun Microsystems e já está viciado em World of Warcraft, mesmo ainda não tendo jogado.


O Despertar

Quando falamos em desenvolver jogos em Java, logo vem à men-te “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.

Uma outra visão comum são os jo-gos 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 dis-poní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 desenvolvi-mento 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 verda-de? Hoje em dia, muito pouco. Essa fama vem das primeiras versões da linguagem, quando a platafor-ma ainda estava um tanto quanto imatura. Um dos principais culpados por esse desempenho limitado é a API Swing. Esta API tinha como

objetivo facilitar o desenvolvimento de interfaces de aplicações desktop e fornecer aos desenvolvedores uma grande quantidade de recursos. Mas houve um problema: os desenvol-vedores 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.

É claro que essa não era a única razão para o fraco desempenho da plata-forma Java. Houveram diversos outros pro-blemas, que foram sendo corrigidos

conforme as novas ver-sões eram lançadas. E hoje temos uma platafor-ma que traz diversos be-nefícios para quem decide utilizá-la.

Um fato interessante é que a Sun (empresa que desenvolveu a platafor-ma Java) está, já há algum tempo, empregando esforços para facilitar o desenvolvimento de jogos. Em congressos como o Java One (maior congresso sobre Java do mundo, que reúne milhares de de-senvolvedores todo ano), e o Game Developers Conference (GDC), a Sun vem realizando palestras visando mostrar aos desenvolvedores de jogos os ganhos que podem ser ob-tidos com o uso da tecnologia Java.

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 ci-tar 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 regis-trados, e está em constante cresci-mento. Confira também o da comu-nidade: www.javagaming.org. Lá é possível encontrar jogos, demos e APIs. Entre os projetos dessa co-munidade, três merecem destaque: jinput, joal e jogl. O objetivo dos três é basicamente o mesmo: dis-ponibilizar recursos que não estão disponíveis diretamente em Java, ou cujos recursos são insuficientes para o desenvolvimento de jogos.

Os três projetos são OpenSource e tem participação ativa de diversos desenvolvedores da comunidade e do GTG.

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

CENA JAVA

Figura 3: Alien Flux, jogo 2D comercial - roda em Linux, Windows e MacOS

É claro que essa não era a única razão para o fraco desempenho da plata-forma Java. Houveram diversos outros pro-blemas, que foram sendo Figura 2: Ancient Empires e Dragon Island, dois jogos para celulares


Os Três Pilares

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, su-porte a tecnologias de processamen-to gráfico de alta qualidade e recursos de processamento de audio escassos. Visando resolver esses problemas, es-

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 tratamen-to 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 com-ponente registrado para ouvir estes eventos, alocando recursos preciosos do sistema, que ficam, pelo menos em parte, fora do controle do desen-volvedor. 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 desenvol-vedor que deverá verificar quais teclas foram pressionadas, o que pode ser feito na parte de processamento de

entrada do loop principal do jogo.

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

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

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 desenvolve-dores 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 ofere-cem. Para a programação gráfica de jogos, OpenGL é quase unanimida-de. 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.

Figura 4: Flying Guns - Desenvolvido com Java3D

CENA JAVA

Figura 5: WurmOnLine – MMORPG

Além de JOGL, JINPUT e JOAL, temos o LWJGL como uma opção de acesso a Open-GL, 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 tor-nando 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 in-formações acesse: http://www.lwjgl.org.

Light Weight Java Game Library


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ê

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

O Futuro

Nesta edição tivemos uma intro-duçã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-Magazi-ne e opine nos forums!

Figura 6: Jose, feito com Java3D

CENA JAVA

Figura 7: SquareHeads, com um mapa de Quake 3

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 utiliza-dos: 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ís-ticas é a ausência de ponteiros. Portanto você não precisa se preo-cupar 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 Com-evolução não é controlada pela Sun, mas sim pela comunidade, e qualquer um pode participar. É para isso que existe o Java Com-evolução não é controlada pela Sun, mas sim pela comunidade, e

munity 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.

Vantagens de se utilizar Java

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 co-

mum 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.

Java Game Server


Videogames no Cyberpunk de William Gibson

Ficção Científica: Reflexão e Anteci-pação

As mudanças na sociedade decorridas dos avanços tecnológicos costumam mexer com a imaginação dos escrito-res, 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. Pode-mos inferir que além de um eficiente termômetro dos anseios causados pe-las mudanças tecnológicas, as histórias de um tempo também podem subsi-diar reflexões sobre as novas tecnolo-gias 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 high-tech.

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

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

Como cerne deste artigo, tratarei de

outro fator que testemunha a impor-tâ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 Neuro-mancer é 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 pu-nições terríveis, tudo isso faz parte do jogo da invasão.

O protagonista da história é Case, um super-hacker com habilidades inco-muns de invadir e controlar sistemas de informação. Contudo, sua habilida-de ganha dimensões de vício. Gibson, com Case, aborda o comportamento de jogo compulsivo, com todas as im-plicações patológicas que dele decor-rem, 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 imer-são é realizada por neuroimplantes e dispositivos digitais, e opera uma separação da mente e do corpo, sen-do que a primeira é revestida de um personagem digital como roupagem. A realidade virtual tem por caracte-rí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 dese-jo 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.

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 epi-

sódios de X-Files. Hoje aposentado, mora no Canadá.

“A Matrix teve sua origem nos primitivos jogos

eletrônicos”.(trecho de Neu-

romancer, escrito em 1984)


por Alandro Vieira dos Reis

3. Jogos de Simulação

Uma vez inserido no cyberspaço, Case é orientado por uma inteligência artificial chamada Linha Plana, que atua como men-tor 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 artifi-ciais 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 al-goritmos 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.

4. LAN Houses

Casas de jogos eletrônicos figuram regular-mente em ambientes noturnos em Neuro-mancer. Seja em Tóquio ou nas megalópo-les 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

clara referência ao roleplaying game(RPG) mais popular nos EUA nos anos 80: o Dungeons&Dragons. Falar de pessoas co-nectadas todas num mesmo RPG digital significa a antecipação dos massive multi-player on line games (MMOG) como Never WinterNights, Dark Ages of Camelot, etc. Em outro livro, Idoru, tal conceito é desen-volvido, 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 inteli-gências artificiais.

6. First Person Shooters

O episódio notoriamente que mais lembra

os atuais jogos eletrônicos no livro Neuro-mancer se dá quando Case, através de uma conexão neurodigital (chamada no livro de SIMStim, simulated stimulation, ou “es-timulaçã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-

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 comu-mente, 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 an-tecipados na obra de William Gibson confir-ma a importância da visão deste autor, suas reflexões sobre tais práticas lúdicas. Gib-son, 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.

OBS: Para a escrita deste artigo usei como referência a seguinte versão em português

de Neuromancer:

GIBSON, William. Neuromacer. Editora Ale-ph, 3a edição, 1a reimpressão, São Paulo:

2003.

Alessandro Vieira dos [email protected]

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

Figura: Capa do Livro Neuromancer

O evento será realizado na cidade de Curitiba no Paraná, também nesta cidade, em data próxima ao SBGames, será promovido o SIBGRAPI-2004 (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/


Coluna

Jogos Open SourceUtopia, modismo ou necessidade ?

por Julio Marchi

Desenvolver jogos de com-putador 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 cami-nho 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 progra-mador 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 issocomo atualmente; e não haviam sequer tantos recursos avançados - e simplificados – destinados exclusivamenteao desenvolvimentos de jogos. Entre isso e outras reali-dades, 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 fac-tí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

programador - ou fazer parte de um bom grupo -, hoje desenvolver um jogo assemelha-se mais à produzir um filme de Hollywood do quesimplesmente 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 acompetiçã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 consumidirneste 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 atu-almente a velocidade da informação já desban-cou a da luz, as dificul-dades 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 crescenteacervo de informações, exemplos e “bibliotecas” que colaboram para diminuir o tempo de desenvolvimento de um jogo, o que reflete diretamente no investimen-

to 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

Julio Marchi é Analista de Sistemas formado especilizado em engenharia de software, network, multimídia e Internet. Atual-mente é CEO de duas empresas nos EUA e desenvolve diversos projetos técnicos e áudio-visuais para outras empresas.


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 ten-dem a esquentar nos próximos anos. Mesmo a famosa licença GPL já vem levantando polêmi-ca 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 comercia-lização. Mesmo que um jogo de alto nível, desenvolvido via Open Souce, fosse vendido por apenas UM DÓLAR, ainda assim haveriam outros proble-mas 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 ani-mações, enredo e conteúdo musical, e o Open Source não abrange nada disso; 3) O mercado Open Source ficaautomaticamente 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 Sour-ce para desenvolvimento de jogos” serão demasiados os pontos controversos, mas existe um em específicoque 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 decada sistema, o que obriga que se

desenvolvam versões específi-cas para cada SO. No caso do Mac não há tanto pro-blema porque o Sistema Operacional hoje é basica-mente um só – o Mac OS X. Já o PC sofre atualmen-te 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

Coluna

“Projetos Open Source normal-mente NUNCA

terminam!”


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 engati-nhando. Ainda no enfoque PC, o Linux perde o mercado de “usuários finais” - entenda-se “leigos” – pois seu usopelo 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 aprimora-mento. Entretanto, em países onde o mercado de desen-volvimento 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 aprendi-zado e desenvolvimento de novas técnicas e, principal-mente, 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ís-tica, mas sim em encontrar uma forma de lidar com as licensas tipo GPL sem criar “conflitos legais” ou “roubo de

tecnologia”. Como todo recurso, ferramenta ou idéia, a diferença entre o sucesso e o fracasso de um empreen-dimento 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 me-lhorar a qualidade final de qualquer produto, mas aindahaverão os critérios intelectual e artístico, assim como o problema no manuseio das licenças. O dia que for en-contrada 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, per-mitindo que as empresas brasileiras possam competir mais de perto com produtos das grandes e milionárias empresas internacionais.

por Julio Marchi

Coluna


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 profis-sionais 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 espe-cialização em Web do Unicenp e per-cebi que existia assunto suficiente para montar um curso de desen-volvimento de jogos. O momento era propício devido a algumas re-portagens 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 elabo-raçã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 ape-nas o começo. A consolidação das empresas atuais, o crescente inter-esse da comunidade e a criação de uma associação sólida de empresas

(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 gradu-açã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 “Tec-nologias Educacionais”. Alunos que fizerem o curso de jogos poderão descontar créditos do mestrado. Por sua vez, alunos do mestrado pode-rão fazer determinados módulos

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 comu-nidade está cada vez mais organiza-da, temos empresas com jogos pub-licados, 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 acon-tecido. 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 ex-iste um bom espaço para crescimen-to. 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 universi-dades 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 desco-brir 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 é impor-tante, pois no momento em que sur-gir uma boa oportunidade é melhor já estar preparado.

E n t r e v i s t a

Fábio Binder


“Dos 30 alunos que finalizaram ou queestão finalizando ocurso, atualmente 11 trabalham com

jogos, ...”

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

A R T I G O Spor Bruce “Sinner”

Introdução ao OpenGL Shading Languageintroduçã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 peque-

nos 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 antesAeram renderizados offline, em har-dware 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, seme-lhantes 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çamen-to dos drivers da série 60 da NVi-dia. Ao longo desse texto mostrarei suas características, sintaxe, futuras implementações, como integrá-la ao OpenGL, al[em de alguns exem-plos. Farei também, uma pequena comparação entre ela e outras duas linguagens bastante difundidas, a HLSL da Microsoft e a Cg da Nvidia.

Por quê usar Shaders e GLSL?

O hardware gráfico antigo (GeForce 256, Radeon 7000 ) somente per-mitiam que o pipeline gráfico fosse configurado e não programado. Isso limitava a quantidade de efeitos es-peciais e técnicas avançadas, que deveriam ser simuladas em softwa-re, o que por muitas vêzes impossi-bilitou a utilização deles em tempo real. Um exemplo disso são os mo-delos 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 mo-delos de iluminação. Outros efeitos interessantes também são possíveis, como: Soft Shadows, Environment Mapping, Per-Pixel Lightning, Ske-

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 Open-GL desde 2002 através das extensões ARB_vertex_program e ARB_frag-ment_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 de-senvolvido a GLSL, uma linguagem de alto nível também, que permi-tiu o desenvolvedor a escrever seus shaders numa linguagem similar ao C/C++ tornando a tarefa muito mais fácil !

Características da GLSL

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

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 mo-delos 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 sim-ples pixel. Ele também possui infor-mação como cor, depth, stencil, etc...

Tipos de dados

A GLSL possui quatro tipos prin-cipais: float, int, bool e sampler.

http://www.jogospro.com.br J O G O S P R O e-magazineS E T E M B R O 2 0 0 4

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

Existem também tipos que funcionam como array dos tipos principais. São eles:

Float: v e c 2 v e c 3 v e c 4

Int: i v e c 2 i v e c 3 i v e c 4

Bool: b v e c 2 bve 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 é usa-do 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 proces-sado, como sua posição ou normal, por exemplo. Os Attributes são read-only.

Uniforms: São valores que não mu-dam 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 in-formações do Vertex para o Fragment Shader. Eles são read-only nos Frag-ment Shaders mas permitem leitura e escrita nos Vertex Shaders. Devem ser declarados de forma idêntica nos Ver-tex e Fragment Shaders que os usarem.

Constants: Não podem ter seu valor alterado, assim como no C. Geralmente guardam valores dependentes da imple-mentação do OpenGL que se está usan-do 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.

Attributes, Uniforms e Varyings Inter-nos e Reservados

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

Attributes em Vertex Shaders:

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

Uniforms:

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

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

Attributes, Uniforms e Varyings Per-sonalizados

É possível também criar seus próprios At-tributes, Uniforms ou Varyings personali-zados como mostra os exemplos abaixo:

attribute vec3 rotacaouniform mat4 matrix_de_texturavarying vec3 vetor_normal

Funções

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

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

Exemplo de Shader

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

Figura 2: Resultado do Shader

A R T I G O S

// 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;

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

LightIntensity = DiffuseContribution * diffuse + SpecularContribution * spec;

MCposition = gl_Vertex.xy; gl_Position = ftransform();

}

Listagem 1: Brick Shader Exemplo.


A R T I G O S

Como integrar os Shaders ao OpenGL

A integração dos Shaders é simples e di-reta utilizando-se extensões do OpenGL. Para isso você deve transformar seu Sha-der 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 Ob-ject 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 lingua-gem eficiente, muito promissora e defácil integração a qualquer design exis-tente. O grande problema dela hoje é o fraco suporte que as grandes fabrican-tes de placa de vídeo oferecem. Apesar dos drivers novos da Nvidia (série 60) e da ATI (Catalyst 4.3) já oferecerem supor-te 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,

// Fragment Shader

uniform vec3 BrickColor, MortarColor;uniform vec2 BrickSize;uniform vec2 BrickPct;

varying vec2 MCposition;varying float LightIntensity;

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

position = MCposition / BrickSize;

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);}

Listagem 1: Brick Shader Exemplo. (cont.) FarCry, Unreal 2004) talvez impulsione as fabricantes e façam com que a GLSL se estabeleça de vez como uma das lin-guagens padrão de desenvolvimento de shaders no mercado de computação gráfica.

char * my_frag_shader_source;char * my_vert_shader_source;

// Obtem o fonte do Vertex e Fragment Shadersmy_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 Objectsmy_program = glCreateProgramObjectARB();my_vertex_shader = glCreateShaderObjectARB(GL_VERTEX_SHADER_ARB);my_fragment_shader = glCreateShaderObjectARB(GL_FRAGMENT_SHADER_ARB);

// Carrega os Shader Sources para os objectsglShaderSourceARB(my_vertex_shader, 1, &my_vert_shader_source, NULL);glShaderSourceARB(my_fragment_shader, 1, &my_frag_shader_source, NULL);// Compila os Shaders ObjectglCompileShaderARB(my_vertex_shader);glCompileShaderARB(my_fragment_shader);

// Linka os Shader Objects ao Program ObjectglAttachObjectARB(my_program, my_vertex_shader);glAttachObjectARB(my_program, my_fragment_shader);

// Linka o Program ObjectglLinkProgramARB(my_program);

// Usa o Program Object glUseProgramObjectARB(my_program);

Listagem 2: Exemplo de como integrar Shaders ao OpenGL

3Dlabs, principal desenvolvedora do GLSLhttp://www.3dlabs.com

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

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

Site pessoal do Humus com diversos exemplos interessanteshttp://esprit.campus.luth.se/~humus

Site pessoal de Zaprjagaev Alexander. Seus últimos exemplos usam GLSLhttp://www.frustum.org

OpenGL Shading Language Designerhttp://www.typhoonlabs.com

OpenGL Brasilhttp://www.opengl.com.br

Links


Figura 1: Imagens da Cube Engine, desenvolvida com o SDL e OpenGL.

A R T I G O Spor Daniel “NeoStrider”Monteiro

Iniciando no SDLDL. 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 probabili-

dade 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? S


O que você precisa para enten-der de SDL?

Tudo que se precisa para a compre-ensã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 signi-fica isso? O fato de ser uma camada de acesso à Mídia Direta (Simple Directmedia Layer) significa que ela atua como uma camada de sof-tware, simplificando nosso trabalho na produção de conteúdo multimí-dia. Como ela é Simples, não pode-mos 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 adi-cionemos módulos ao nosso gosto.

Como funciona essa camada?

Ela filtra o que é relevante para a produção de mídia do que é pa-drã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 neces-sá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 de-sejamos são aplicações simples multimídia, usando acesso dire-

to, todas as nossas aplicações se-rão focadas na saída em forma de mídia e na entrada do usuário.

Foco na saída de mídia é algo cons-tante para a SDL. Por pensar em aces-so direto à tela cheia e não em jane-las 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 tercei-ra função: ela funciona de forma mul-ti-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é mes-mo sem altera-lo, a SDL permite isso. Basta seu programa ser feito usan-do apenas componentes comuns.

Como é um programa SDL

A SDL trabalha em sistemas ope-racionais 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.

Site Oficial do SDLhttp://www.libsdl.org

Site do Autor http://www.makingthegame.tk

Diversos Artigos de SDL traduzidoshttp://www.pdj.com.br

Cube Enginehttp://www.cubengine.com

Marathon 2http://marathon.bungie.org

Tutoriais de SDL + OpenGLhttp://cone3d.gamedev.net

Links

Marathon - Jogo de MacOS refeito em SDL e rodando

perfeitamente em Windows.

A R T I G O S

Inicialização:Tipicamente contém SDL_Init() e inicia-lização de recursos

Tratamento de eventos:Aqui é necessário tratar eventos do Sis-tema. A SDL já filtra o que é pertinentea 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 alo-cados e liberamos a SDL. Aqui não preci-samos necessariamente terminar nosso programa, mas após SDL_quit, não de-vemos 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 recur-sos inexistem, esta é uma forma de evi-tar problemas nas adaptações.

A forma mais geral de incializar é in-cializar tudo com SDL_Init(SDL_INIT_EVERYTHING). Vale lembrar que os sub-sistemas 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 me-mó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 progra-mas interativos, mas quando se trata de um programa curto que realiza alguma operação e finaliza, não é necessário tra-tar eventos.

O tratamento de eventos ocorre de for-ma independente de plataforma e não usa uma função de callback para trata-mento geral (como é comum se acredi-

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

Neste ponto é que nor-malmente se obtém a entrada do usuário. Vale lembrar que os vários dispositivos de entrada possuem sua própria filosofia de informar intera-ção.

Operações de dados internas

Agora acontece o processamento que a SDL tanto espera que o desenvolvedor faça: a manipulação de dados e a ope-ração de saída de dados na forma mul-timídia.

Mais uma vez, como ocorre na entrada de dados, cada dispositivo de saída tem 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 ouso de funções de uso geral com a surfa-ce de tela pode gerar resultados impre-visí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 continua-mente 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 pro-blemas.

Deinicialização

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

Ela merece descansar. Um problema comum nos programas SDL em seu es-tágio inicial é o desleixo com esta parte fundamental do programa. Por fim, ses-sões intermináveis de sucessivas execu-ções da aplicação – que aloca sem de-salocar recursos – resulta em memória fragmentada e problemas na alocação de dados por parte de execuções de ou-tras aplicações. Neste ponto, encerrar o comprometimento com determinados dispositivos pode ser importante para seu funcionamento. Negligenciar isto pode levar a resultados imprevisíveis.

O que eu tenho com tudo isso?

Uma aplicação multimídia é feita de en-trada e saída em diferentes formas de mídia. O resumo acima acabou de mos-trar uma pequena fração de tudo que a SDL tem a oferecer ao desenvolvedor sem medo. Arrisque-se a visitar www.li-bsdl.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.


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 neces-sidades 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 (for-mas) e etc... Para atender a essas necessidades, o de-senvolvedor tem a sua disposição a API chamada GDI+.

Antes de começar ‘sujar’ nossas mãos com código, vamos estudar as técni-cas principais que estaremos usando. O namespace de S y s t e m . D r a w i n g contem todas as classes que nos aju-darão realizar nosso objetivo. Existe também o names-pace mais avançado, o System.Drawing.Drawing2D, este poderia gerar um novo artigo inteiro, as-sim como as especializações Sys-tem.Drawing.Printing especializa-do, 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-

presenta um contexto de display (exibição). Um contexto de dis-play 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 pre-enchimento (“fills”). Dessa forma o programador não tem que se preocupar com hardware e dis-positivos 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 explicita-mente objetos dos gráficos usando o operador new. Na maioria das vezes, o objeto é obtido in-diretamente pelos argumentos passa-

dos do sistema ope-racional à aplicação. Uma vez que nós temos o objeto em nossas mãos, é muito fácil extrair formas usando seus métodos self-descri-bing. Por exemplo, o método de DrawImage() nos exibe uma ima-gem, enquanto que o DrawLine(), o DrawRectangle(), o DrawCurve() e o DrawArc() são usados criar for-mas 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 dese-nhar a forma e a classe Brush espe-cifica 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 pon-to 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) re-presenta uma área retangular. Um de seus construtores faz uso de dois objetos do tipo Point (para a parte superior a esquerda e a par-te inferior a direita do retângulo).

Redesenhando Gráficos

Windows é um sistema operacio-nal complexo. Compreender com-pletamente como tudo trabalha não é realmente uma tarefa trivial,

A R T I G O S

2D .NET games: Usando GDI+ (Parte 1 de 3)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 fun-cional. Nesta primeira parte aprenderemos os con-ceitos; Na segunda parte passaremos para recursos mais avançados; Na terceira e última, iremos partir para a implementação de um jogo.

N

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 pro-gramaçã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.

por Wilson “WolveWilson” Jr.


A R T I G O S

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); } }}

Listagem 1: Exemplo


e operações aparentemente sim-ples requerem muito trabalho do computador. Uma destas tarefas “simples” é a seguinte: Imagine que um usuário está executando dois programas simultaneamen-te, cada em sua janela separada. O primeiro programa esta exibin-do 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 desapare-ceu, porque uma outra janela esta sobe ela. Naturalmente, nós te-mos 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 é verda-deiro. Se nós movermos, afastan-do da primeira janela, nosso brow-ser 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 recu-perada outra vez diretamente para a memória. Seria um desperdício de recursos se o sistema operacio-nal armazenasse a exposição do video de cada programa na memó-ria - imagine que nós podemos ter muitas janelas, uma no alto do ou-tra. De fato, Windows diz somente a aplicação , no nosso caso a pri-meira, que ela tem que redesenhar uma parte dela, em exibição, por causa de um evento especial (no nosso caso, o mover de uma ou-tra 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 pressiona-mento de teclas - existem muitos outros eventos emitidos mas em

nosso caso, nosso interesse esta nos eventos chamados de Paint (Pintura). O Windows emite-os au-tomaticamente a todos os progra-mas que necessitam redesenhar alguma parte de sua interface do usuário. Em nosso exemplo acima, assim que nós movêssemos a ja-nela de browser para trás para seu lugar original, Windows emitiria ao primeiro programa, um evento de Paint. É como se ele estivesse “di-zendo” a esse programa que algo aconteceu e necessita redesenhar uma parte específica de sua jane-la. A informação de que a parte necessita redesenhar seria pas-sada também junto com o even-to. Felizmente, esta mensagem que emite e que redesenha é ‘re-cebida’ automaticamente pelos controles standard. Realmente, a classe Form (formulário) tem um método chamado OnPaint (que é subscrita ,overridden, da classe do Control), que assegu-ra o ‘redesenhar’ automático.

Toda a conveniencia de gerencia dos gráficos fornecida pelo Windo-ws, acaba quando chega na GDI+. Windows não mais atualizara au-tomaticamente as partes da janela da aplicação que têm formas de-senhadas nelas pela GDI+. Neste caso, nós teremos que subscrever (override) o método OnPaint, que nós mencionamos antes, e especi-ficamos exatamente como o ‘rede-senhar’ ocorrerá. Naturalmente,

nosso programa necessitará, prova-velmente, atualizar seus gráficos não somente quando uma outra janela se move no alto dela, mas quando se mi-nimiza e maximi-za outra vez. Isto é, nós emitiremos uma mensagem ao nosso progra-ma que o diga para redesenhar a parte (ou os todos) seus gráficos. A manei-ra que nós dizemos ao nosso programa para repintar seus gráficos é o mé-todo Invalidate().

Nós o encontramos na classe Con-trol, e naturalmente na classe do Form, que a herda. Este método pode ser chamado sem nenhum parâmetro, e neste caso ele redese-nhará toda a área do cliente. Mas atualizar partes grandes da expo-sição de gráficos em intervalos curtos consome muitos recursos. Na maioria de casos, nós devemos chamar o método que especifica-mos somente para área onde os gráficos atualizados devem apa-recer. Geralmente essa área (suas dimensões) é passada como um objeto Rectangle (retângulo).

Fim da Parte I

A R T I G O S


Figura: Saída do programa da Listagem 1.

Postmortem do Harena

O Harena é um demo desenvolvido por alunos da primeira turma de Pós Gradua-ção em Desenvolvimento de Jogos da Uni-cenp. A Pós Graduação teve duração de um pouco mais de um ano com aulas aos sába-dos. 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 de-senvolvimento.

1. O que deu certo.

Reuniões Periódicas: Ao contrário de outras equipes da Pós, todos os integran-tes 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 de-sign, arquitetura de rede para o multiplayer, renderizador, algo-ritmos, as matérias da Pós, entre outros assuntos. As reuniões fizeram com que a equipe se mantivesse unida mesmo de-pois do término das aulas.

Wiki: Logo no começo do proje-to criamos um Wiki para colocar nossas idéias, criar atas das reuniões, colocar arquivos refe-rentes 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 programa-do uma linha de código, já tinha-mos 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 pou-co mais profissional e menos amador.

Artista na Equipe: Originalmente a equipe era composta por 4 programadores, mas

tomando uma decisão estratégica, decidi-mos “roubar” um integrante com conheci-mento 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 traba-lhando no esquema de só nas horas vagas não conseguiriamos terminar. Por isso de-cidimos pedir férias do serviço, das esposas e namoradas com o argumento de que finalmente íriamos terminar e ter mais tem-po para elas. Assim começamos a trabalhar num ritmo bem mais acelerado, principal-mente 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í.

2. O que deu errado.

Outros Trabalhos da Pós: O desenvolvi-mento do demo foi prejudicado pois tinha-mos que parar de trabalhar nele para poder entregar trabalhos das diversas matérias da Pós. Geralmente esses trabalhos não esta-vam relacionados ao demo.

Falta de um Cronograma Realista: Várias

vezes tentamos montar um cronograma realista do desenvolvimento mas falhamos todas as vezes. O motivo principal foi que nenhum dos integrantes conseguia men-surar 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 dis-cutia nada relamente relevante ao projeto. Então decidimos cancelar as reuniões para usar esse tempo para realmente codificar algo.

Artistas: Logo no começo, fizemos a divul-gação do Harena em várias listas procuran-do artistas interessados em participar do projeto. Várias pessoas ficaram interessa-das. Ao longo do projeto devemos ter fala-do 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

P o s t M o r t e m

“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

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


por Matías G. Rodriguez

foi quem fez a arte conceitual de alguns dos personagens do jogo, ele já tinha ex-periê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 esta-vamos tentando tirar bugs do networking e o renderizador. Quinze minutos antes de-cidimos 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 ser-vidor 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 apresen-taçõ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, mila-grosamente, funcionaram sem problemas. Ele gostou muito do projeto e nos deu parabéns seguido da nota máxima. Por um

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 complica-do. Tudo indicava que a equipe não conse-guiria 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.

P o s t M o r t e m

Figura 03 - Da esquerda para a Direita: Marcelo Walter, Eduardo Akatsu, Matías Rodriguez, Bohdan Metchko Jr, Uriel Segall


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

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

E o Futuro é logo ali

Prever 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 sen-tada 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 ap-enas 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 quere-mos 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 apro-ximaçã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 fa-bricados 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 hu-mana.

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

massificação dos chips de computadores. Na verdade já estamos vivendo nesse mun-do. Ou seja, estaremos conectado com o mundo virtual praticamente em qualquer lugar, em qualquer hora, em qualquer si-tuaçã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, jo-gando 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, uti-lizando seus óculos com mini-telas, a cami-nho da lanhouse, porque afinal, é sempre bom relembrar os velhos tempos.

Fato 3: A tecnologia já existe, mas faltava uma utilização para ela. Com processado-res mais velozes sobrará mais tempo para um reconhecimento de voz mais preciso. E cada vez mais teremos jogos sendo co-mandados, além do teclado, mouse e joys-tick, 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.

Fato 4: O dinheiro, em meio físico, esta aca-bando. Dos 4 trilhões aproximados existen-tes 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 digi-tamente. Usando dinheiro digital para um mundo virtual. Essa previsão, na verdade, é apenas mais uma conseqüência da Com-putaçã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, tam-bé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 po-legadas, luvas para realidade virtual, já exis-tem monitores holográficos e mouse com

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 con-versa 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 com-putaçã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.

Fim do Jogopor Carlos Caimi

Carlos H Caimi - [email protected], é 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.


EEExpedientexpedientexpedienteExpedienteEEExpedienteEExpedientexpediente

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é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:

[email protected]

pelo surgimento da idé

Documents

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