P ost M ortem

Conteúdo
Projeto
3 Anima Project
por Alexandre “Darkfenrir”
Capa
6 Empresas Brasileiras de Jogos
por Carlos H. Caimi
Colunas
10 Java no desenvolvimento de jogos
por Paulo R. C. Siqueira
14 Videogames no Cyberpunk de William Gibson
por Alessandro Vieira dos Reis
16 Jogos Open Source: Utopia, modismo ou
necessidade?
por Julio Marchi
Entrevista
19 Fábio Binder
por Carlos H. Caimi
Artigos
29 Introdução ao OpenGL Shading Language
por Bruce “Sinner”
23 Iniciando no SDL
por Daniel “NeoStrider” Monteiro
25 2D .NET games: Usando a GDI+ (Parte 1)
por Wilson Jr.
PostMortem
28 Postmortem do Harena
por Matías G. Rodriguez
Fim do Jogo
31 E o Futuro é logo ali
por Carlos H. Caimi
Editorial
Caros leitores
Ao final de julho de 2004, surgiu na lista jogospro a idéia de criarmos
uma revista para a comunidade de desenvolvedores de jogos do Brasil.
Foram quase 100 post na lista com prós e contras, e por fim, os mais
empolgados resolveram concretizar a idéia.
E é com imensa satisfação que apresentamos a você, a primeira edição
da primeira revista sobre desenvolvimento de jogos voltada para a comunidade brasileira. A JogosPRO e-Magazine a princípio, será bimestral.
Ela será distribuída gratuitamente por meio eletrônico e teremos um site
para discutir e divulgar a revista.
Com a criação da revista pretendemos dar um passo importante para
comunidade. Nosso sonho é tornar a revista uma referência nacional,
bem como um canal para divulgação da indústria de jogos.
Nessa primeira edição, buscamos saber como anda as empresas brasileiras que já publicaram jogos no brasil, e fora dele, além de trazer artigos
interessantes, entrevistas e muito material.
E por isso convidamos você, prezado leitor, a participar junto conosco
desse grande projeto. Participe! Contribua com artigos, notícias, divulgue seu projeto, critique e dê sugestões para aprimorarmos sempre a
nossa revista. Envie-nos cartas! O email é [email protected].
Acesse o site e sinta-se a vontade.
- Carlos H. Caimi, Editor-Chefe
Anima Project
por Alexandre “DarkFenrir”
“O que você acha de passar pela 3ª Guerra Mundial, ver o
Sol explodindo anos luz de seu abrigo no fundo da terra,
presenciar a idealização de uma civilização na superficie
lunar, encarar desavenças políticas, e finalmente descobrir que seu colega lhe traiu por interesses únicos e
egoístas... Lutar com armas e veiculos de ultima tecnologia, e simultaneamente derrotar um dragão vulcânico
que varre inumeras tropas com seu halito flamejante ! Ou
melhor ainda, descobrir que você esta sendo manipulado por uma mega corporação e pelo próprio governo no
qual você trabalha !!! “.
Este é o mundo de Anima Project , um duelo de extremos, numa época em que a realidade que conhecemos
está se redefinindo radicalmente, em uma saga que narra
temas pouco explorados antes: a revolução das espécies,
os elementos naturais a espécie humana, a eterna busca
pela sobrevivência e seus desejos mais ancestrais... Como
nasce uma civilização, sua tecnologia, suas crenças e valores, como ela se adapta ao mundo em que vive ! Numa
guerra onde não existe nem certo, nem errado: apenas
interesses contraditórios, onde o destino da nova Terra esta em jogo !!!
Assim surgiu o conceito que sustenta todo o contexto por trás
desta incrivel aventura ! E
lembre-se que você, é mais
do que nunca, o personagem principal desta
grande saga !!
>> CONCEPÇÃO DO PROJETO
Anima Project é um novo produto de entretenimento
criado para o mercado nacional, que vem a cada ano
ganhando cada vez mais adeptos nessa grande forma
de lazer. Mas o Anima Project não é apenas mais um
RPG de mesa como tantos outros: ele explora um tema
de ambientação pouco explorado até hoje nos RPG’s de
mesa do ocidente, mas muito apreciado por jogadores de
RPG’s eletrônicos e fãs de Anime / Mangá: o gênero “TecnoFantasy”, que mistura elementos da fantasia medieval
com técnologia e elementos cyberpunk.
O mundo de Anima Project consiste no duelo de extremos, como por exemplo, a Tecnologia x Magia, numa
guerra onde não existe nem certo nem errado, apenas
interesses contraditórios...Tudo isso narrado numa história contada sob diversos pontos de vista, em um mundo
novo repleto de tecnologia e misticismo.
O ANIMA PROJECT não ficara preso a um único tema: ele
será explorado de diversas maneiras, num futuro próximo; O RPG de mesa, desenvolvido inicialmente para OGL/
D20 System, será o carro-chefe do projeto. E futuramente
temos pretenção de apostar o conceito do projeto em
outras mídias, como por exemplo jogos eletrônicos, mangás, novelbooks...
>> RESUMO DA HISTÓRIA
- Uma antiga profecia se concretizou, e o mundo dos homens entrou em colapso: guerras, desavenças e catástrofes naturais mudaram a vida dos habitantes da superfície
terrestre..
- Devido a um estranho fenômeno ocorrido no sol, a
temperatura terrestre começou a aumentar bruscamente, tornando-se impossível sobreviver nesta atmosfera;
então os humanos, sem ter pra onde fugir, construiram
um novo mundo: de baixo da terra.
- Mas nem todos puderam migrar para o subterrâneo:
alguns radicalistas mais nobres construiram colônias no
espaço e na Lua, e os menos afortunados ficaram a mercê
da própria sorte, sobrevivendo a todo custo na hostil
crosta terrestre.
- 1 milênio se passou, os humanos de Subteranea esque-
ceram-se do mundo antigo, os recursos minerais do
subsolo estão se esgotando, então começa o plano
de reconquista da superfície. O mesmo acontece
com os habitantes de Seluna, que até então criaram
uma nova civilização fora do planeta.
- Porem, os humanos de ambas as partes não esperavam se reencontrar, nem mesmo entenderam um
fato: que o mundo estava se recriando, desde o principio dos tempos, mas habitado por estranhas e bizarras
criaturas que só existiam em lendas e folclores, e também
por uma legião de maquinas inteligentes.
- Muitas pessoas começaram a receber “contatos” com seres “divinos”, cujo foram banidos do mundo dos homens
antes mesmo da existência de uma civilização humana.
- Ainda ha um fato mais extraordinário: uma nova variante de seres humanos, os “Alterados”, começou a repovoar a superfície. Porem eles alimentam uma profunda
angustia em relação aos humanos do subterrâneo que
abandonaram seus antepassados para apodrecer neste
armagedom.
- Inicia-se uma guerra de reconquista da superfície deste
mundo novo: humanos de Subteranea x humanos de
Seluna x os Alterados de Cresta.
- O governo de
Subteranea cria
um audacioso
projeto para a
exaltação da
raça humana: o
>> ANIMA PROJECT - GAME
ANIMA PROJECT - ANOTHER REALITY é um game de
RPG feito para plataformas PC. Ele utiliza o software RPG
MAKER 2003, um programa especialmente feito para a
criação de jogos deste gênero, semelhante aos clássicos
da geração 16 bits (Megadrive e Super Nintendo), como
por exemplo FINAL FANTASY, CRONO TRIGGER e PHANTASY STAR.
Assim surgiu a idéia inicial de ANIMA PROJECT, a revolução das espécies, numa época em que a realidade que
conhecemos está se redefinindo. O interessante é que
esta saga é contada a partir do ponto de vista dos seres
humanos originais, que sobreviveram a uma catástrofe
no passado. Na verdade tinha-se como base inicial contar
a hisstória a respeito de varias realidades paralelas, o
surgimento de vários seres e divindades além da compreensão humana...
O jogo de PC, em RPG Maker, ainda está numa fase inicial
de desenvolvimento, e em breve colocaremos no site
mais versões DEMO, com mais de 1 hora jogável, para
você conferir a respeito do game; e também colocaremos
screenshots de algumas cenas do jogo para você ter uma
idéia de como o game está sendo produzido.
Projeto Anima,
que visa descobrir a verdade
sobre o fato desta
incrível mudança
e a reconquista
da superfície
terrestre.
- Assim então são as novas raças envolvidas neste conflito : Teraneans (habitantes de Subteranea), Seluneans
(habitantes da colônia da Lua), Alterados (os humanos
mutantes que povoaram o novo mundo).
Futuramente temos o plano de fazer um jogo mais sério,
com uma engine própria, feito para computadores de
maior desempenho. Seguiremos os moldes de RPG’s multiplayer famosos, como Diablo, Phantasy Star Online e
Ragnarock. Para isso negociaremos com alguma softhouse que se interesse pelo potencial do projeto.
O site disponibiliza no momento a versão DEMO 1.0 do
Game Anima Project, feito em RPG Maker 2003 Ver.1.08.
Até o final deste ano, pretendemos colocar a versão
DEMO 2.0, com mais horas de jogo.
Equipe Anima Project 2004
Todos os direitos reservados
www.animaproject.make5.com.br
[email protected]
por Carlos Caimi
C
A
P
A
Empresas Brasileiras de Jogos
P
A difícil arte de desenvolver jogos no Brasil
orque desenvolver jogos? Existem muitas respostas para essa pergunta, mas nenhuma é
tão completa quanto esta: Por Paixão! E é exatamente essa paixão que parece alavancar
o mercado brasileiro de desenvolvimento de jogos. Apaixonados utilizam as horas vagas
para desenvolvimento de jogos. Iniciando com um desenvolvimento caseiro, até um amadurecimento da idéia, e por fim, a realização de um sonho. Uma empresa de desenvolvimento de
jogos.
No Brasil, quando se fala em desenvolvimento de jogos, fatalmente iremos tocar no nome de 3
empresas que obtiveram sucesso nessa empreitada. A Continuum, a South Logic e a Ignis são as
brasileiras que conseguiram colocar seus jogos no mercado nacional e internacional. A JogosPRO entrou em contato com essas empresas para tentar descobrir o segredo do sucesso, e o que
elas estão planejando para o futuro.
.:Entrevista South Logic
JogosPRO: A Southlogic desenvolveu primeiro a Aspen Engine, depois
o Jungle Demo. Só depois conseguiu
patrocínio para o desenvolvimento
de um jogo. Vocês recomendam essa
estratégia ainda hoje?
Southlogic: Na verdade a empresa
foi fundada em 1996, então fizemos
o jogo Guimo, depois a tecnologia
Aspen Engine e o jogo Aquarius e
só depois fizemos o Jungle Demo.
Até os dias de hoje é muito comum
desenvolver protótipos na hora de
propor um projeto para um publicador. Muitos querem ter uma noção
o mais precisa possível do que o desenvolvedor é capaz de fazer, e um
protótipo é uma das formas de fazer
isso. Infelizmente fazer um protótipo
é a parte mais complexa e mais cara
do processo de montar uma proposta de jogo.
JP: A Southlogic se chamava antes
Jack in a Box, porque mudaram?
SL: Em 1996 o nome parecia bom
para nós aqui no Brasil, mas no
primeiro contato com os EUA já ouvimos comentários sobre a cadeira
de restaurantes que usa o mesmo
nome por lá. Para evitar confusão e
qualquer tipo de problema legal ao
entrar naquele mercado resolvemos
alterar o nome da empresa. Acho
que fizemos isso na hora certa.
JP: Hoje a Southlogic atua no mercado fora do Brasil, vocês pretendem
http://www.jogospro.com.br
lançar um jogo aqui?
SL: O jogo Guimo, e recentemente
o Deer Hunter 2004, foram lançados
no Brasil. No momento atual, que
desenvolvemos jogos de caça, a
entrada desses produtos no mercado brasileiro é difícil por causa da
baixa popularidade desse esporte
por aqui. Esse tipo de produto
tem como mercados principais os
EUA e Canadá. Acredito
que quando lançarmos
outros gêneros de jogos
a probabilidade deles
serem
amplamente distribuídos
no Brasil vai aumentar.
Quanto a produzir um
jogo especificamente
para o mercado brasileiro,
com conteúdo
voltado para o mercado
brasileiro, é uma questão
de escalar o projeto de
acordo com o orçamento disponível
- que normalmente é baixo aqui.
Pessoalmente não acho a melhor
estratégia, e você pode ver que os
desenvolvedores de outros países
sempre tentam desenvolver
jogos de conteúdo o mais amplo
possível para distribuição mundial e
que inclui o Brasil.
JP: Vocês pretendem relançar o
Guimo e o Aquarius? Ou uma nova
versão desses jogos?
SL: Tenho vontade de portar o Guimo para Windows (atualmente o
jogo tem problemas de compatibilidade porque foi feito originalmente
para DOS e Windows 95) e lançá-lo
como freeware. Já o Aquarius, que
chegou até uma versão beta, é um
projeto bem maior e precisa ser reescrito praticamente do zero para
virar um jogo com os novos padrões
de mercado. Digamos que ele está
“engavetado” até que alguém se in-
teresse por ele, e então poderemos
finalizá-lo com a atenção que ele
merece...
JP: O período que a Southlogic ficou
incubada foi relevante para o crescimento da empresa?
SL: Com certeza foi uma das decisões mais certas que tomamos
durante esses anos. Uma empresa
desenvolvedora de jogos e tecnologia precisa sobreviver por um bom
tempo sem ter faturamento até atingir um nível mínimo para realmente
atuar no mercado. A incubadora
S ET E M B R O 2 0 0 4
J O G O S P R O e-magazine
C
nos permitiu ter esse tempo, que
apesar das dificuldades, foi importantíssimo.
JP: Hoje vocês são desenvolvedores
oficiais da plataforma XBOX. Esse é o
caminho para manter a rentabilidade da empresa, ou de um jogo, PC +
Console?
SL: O mercado de consoles é muito
maior que o de PC, portanto os publicadores preferem jogos para consoles, e de preferência para PS2. Não
tenho dúvidas que um desenvolvedor para console, ou até de múltiplas plataformas (inclusive PC), vai
ter mais chances de fechar contratos
nessa indústria. O nosso primeiro
passo nessa direção foi com o Xbox,
estamos tentando ampliar as possibilidades nessa direção. Infelizmente
existem “percalços” nesse caminho
por estarmos aqui no Brasil. Dá pra
acreditar que em 2004 ainda aconteça isso?
JP: A pirataria no mercado nacional
é impedimento para lançar um jogo
aqui?
SL: Para os fabricantes de consoles é
o motivo que essas plataformas não
chegaram aqui. Quando eles vendem o hardware ele está sendo
subsidiado pelo fabricante, ou seja,
ele está sendo vendido por um valor
abaixo do que realmente vale. Os
fabricantes de consoles
ganham o seu dinheiro vendendo
os jogos depois, e parece que esse
modelo de negócio não funcionaria
bem no Brasil por causa da
pirataria. Infelizmente acho que um
dos motivos daqueles “percalços”
que comentei seja essa situação no
http://www.jogospro.com.br
Brasil que deixa alguns
fabricantes muito descontentes. O
que isso tem haver com a seriedade
do desenvolvedor de jogos brasileiro eu ainda não sei...
JP: O que vocês acham
do mercado brasileiro
de jogos? Tem Futuro?
SL: Acreditar no futuro
do mercado de jogos
brasileiro é acreditar
no futuro do Brasil.
Sem um Brasil mais desenvolvido no sentido
de empregos e poder
aquisitivo não podemos esperar que um
mercado de produtos
“supérfulos” como os jogos evolua. Como todo
brasileiro tenho muita
fé que o Brasil vá se desenvolver
nos próximos anos. Outros países já
estão vendo o potencial de mercado
aqui, e acho isso um indicador que
as coisas vão melhorar. Talvez durante uma fase de transição, as empresas que publicam hardware e jogos
devessem ajustar aquele modelo
econômico no nosso mercado, provavelmente reduzindo suas margens
de lucro.
JP: Teremos uma versão
dos Hunter´s para console?
SL: Espero que sim, e
também gostaria de ter
versões de outros jogos
para console!
JP: Qual os próximos passos da Southlogic?
SL: A nossa meta é enriquecer o portfólio da empresa com bons jogos e
ir crescendo aos poucos,
formando mais pessoal, e
com projetos
cada vez mais desafiadores. Não me
importo tanto em qual a plataforma desenvolver, o mais importante
para nós nesse momento é ter boas
oportunidades de mostrar o nosso
trabalho.
A
P
A
SL: Estudar a sua área de interesse
e praticá-la. Nada melhor que a prática para fixar e aprimorar as suas
técnicas. Atualmente os
jogos estão se tornando projetos
grandes, então conhecimento de de-
senvolvimento de sistemas de maior
porte é importante (orientação a
objetos, notação de código, documentação, etc). Também conhecer
as ferramentas gráficas, de som e de
desenvolvimento como
ferramentas de controle de versão.
Ao mesmo tempo, você precisa se
juntar a outras pessoas que se interessam por jogos e com habilidades
complementares - os jogos são
produtos criados por pessoas com
conhecimentos multidisciplinares
(arte, programação, design, administração, etc). E mais aquela clássica
de sempre: ficar atento as oportunidades e ao que está acontecendo no
mercado, para maximizar as chances
de sucesso. E como não é um mercado fácil, recomendo uma boa dose
de persistência e de dedicação. �
JP: Qual a mensagem que a vocês
deixam para quem esta começando
na área?
S ET E M B R O 2 0 0 4
J O G O S P R O e-magazine
C
A
P
A
.:Entrevista Continuum
JogosPRO: A Continuum surgiu no
ambiente acadêmico e depois consolidou-se como empresa para comercializar o Outlive. Vocês consideram essa
estratégia, de desenvolver uma demo,
buscar patrocínio e depois uma dedicação exclusiva na empresa, como a
melhor opção ainda hoje no mercado
brasileiro?
Continnum: Utilizamos esta estratégia
como meio de dividir o risco do desenvolvimento com os publicadores,
além de ser o modelo de negócios
mais comum entre desenvolvedores e
publicadores.
JP: Fala-se muito hoje em game-propaganda como estratégia para manter
a empresa em atividade, a Continuum
usou este artifício, ou na prática a teoria é diferente?
C: Depende muito dos objetivos da
empresa. Até algum tempo atrás, nosso foco era mais amplo e atendiamos
este público também. Atualmente
estamos com nosso foco restrito ao
desenvolvimento de produtos multiplataforma (PC e XBOX) para os publicadores internacionais. Achamos que
esta é a estratégia mais adequada para
a Continuum.
JP: Vocês já há dois meses são desenvolvedores oficiais da plataforma
XBOX. Esse é o caminho para manter
a rentabilidade da empresa, ou de um
jogo, PC + Console?
C: Esta é uma maneira de agregar mais
valor ao nosso trabalho, aumentando
as possibilidades de fechamento de
negócios.
JP: O que vocês acham do mercado
brasileiro de jogos? Tem Futuro?
C: Acreditamos que o mercado tem
futuro, mas por enquanto ele é ainda
uma promessa, com poucos casos de
sucesso.
JP: Teremos uma versão do OutLive
para console?
C: Não temos planos de portar o
Outlive para XBOX, pelo menos
por enquanto.
das.
JP: Qual o novo projeto que vocês estão desenvolvendo? Vocês poderiam
dar essa esclusividade para nós? Ou
quando a Continuum pretende divulgá-lo?
C: Pretendemos divulgar mais informações assim que as negociações estiverem encaminhadas, o que deve levar
ainda algum tempo.
JP: Qual a mensagem que a Continuum deixa para quem esta começando na área?
C: Além de entender como desenvolver jogos, é importande entender
melhor o mercado em si e como funcionam os negócios dentro dele. Esta
prática é vital para aumentar a probabilidade de sucesso de uma empresa
iniciante. Boa sorte na sua empreitada!
JP: A pirataria de jogos no Brasil afetou
de alguma forma o negócio da empresa?
C: Afetou principalmente no mercado
nacional, onde perdemos muitas ven-
JP: A Continuum teve sua marca ligada a outras grandes
marcas, como Big Brother
Brasil, Xuxa e Mac Donalds.
Isso agrega valor na hora de
encontrar um publisher disposto a
bancar um projeto pró-prio?
C: Eles melhoram a credibilidade da
empresa, apesar de serem
projetos menores
e de pouco apelo
internacional.
http://www.jogospro.com.br
S ET E M B R O 2 0 0 4
J O G O S P R O e-magazine
C
A
P
A
.:Entrevista Ignis
JogosPRO: A Ignis surgiu do trabalho
nas horas vagas de seus sócios. Vocês
consideram essa estratégia, de desenvolver uma demo, buscar patrocínio
e depois uma dedicação exclusiva na
empresa, como a melhor opção ainda
hoje no mercado brasileiro?
Ignis: Na verdade essa é a única opção
para a gande maioria das empresas.
Todo publisher exige uma prova de
competência dos desenvolvedores e,
algumas vezes, nem mesmo um bom
demo é suficiente.
cubadoras tecnológicas no país, e sempre aconselho os iniciantes a procurar
o auxílio delas. A Intec teve um papel
fundamental no processo de transferir
a Ignis do papel
para a realidade.
JP: Vocês recomendariam a quem esta
iniciando buscar auxílio em incubadoras?
I: Sim. Complementando a questão anterior, normalmente uma empresa
iniciante na área conta apenas com
pessoal de perfil técnico e isto não
basta para compor uma empresa de
sucesso. As incubadoras ajudam muito
na parte de preparação do plano de
negócios e na administração da empresa.
JP: Vocês conseguiram uma Capitalização através de Capital de Risco. Esse
investidores veêm com bons olhos o
mercado de jogos?
I: Nem todo investidor de Capital de
Risco tem perfil para atuar na nossa
área, mas normalmente eles têm uma
visão livre de preconceitos.
Se a proposta tiver o respaldo de um
bom plano de negócios, ela será
avaliada com os mesmos critérios de
outras propostas de tecnologia.
JP: No Paraná surgiram várias empresas de jogos, porém a Ignis se mudou
para o Rio de Janeiro. Qual o motivo
dessa decisão?
I: O fundo de investimento que conseguimos é voltado para empresas
de tecnologia do Estado do Rio de Janeiro. Além disso, é importante
a proximidade da empresa com o
investidor, pois a colaboração deles é
importante para o desenvolvimento
do negócio.
JP: Durante o processo de desenvolvimento vocês foram selecionados para
participar da Incubadora Tecnológica
do Paraná. Isso ajudou a Ignis de alguma maneira?
I: Ajudou muito. Hoje existe muitas inhttp://www.jogospro.com.br
JP: A pirataria no Brasil influenciou na
decisão de voltar o desenvolvimento
para um MMORPG? Ou a decisão foi
baseada na paixão?
I: Todas as decisões da Ignis são tomadas em função do mercado e, por uma
questão de sobrevivência, não pode
ser diferente disso. Nosso foco
sempre foi o mercado exterior, então
não posso afirmar que a pirataria
teve uma influência significativa nessa
decisão. A paixão é o que nos
motiva a fazer jogos, mas o mercado
e quem determina como temos que
fazer esses jogos.
JP: O que vocês acham do mercado
brasileiro de jogos? Tem Futuro?
I: Sim. Tem muito futuro e este é o principal motivo que nos levou
a lançar o Erinia no Brasil também. O
público brasileiro ainda tem uma dificuldade grande em entender que o desenvolvimento, a distribuição e a operação (no caso dos jogos online) custa
muito caro e que, por isso, devem
pagar pelo produto. Mas a mentalidade está mudando rapidamente, e os jogagores estão percebendo que, saindo
da ilegalidade, estão colaborando para
que sejam lançados jogos cada
vez melhores.
JP: Agora com o lançamento do Erinia,
quais os próximos passos?
I: Estamos trabalhando muito nas
atualizações e nos preparativos para o
lançamento na Europa, mas também
estamos fazendo o estudo de viabilidade de 3 novos projetos. Não podemos
deixar todos os ovos em um único
sexto.
JP: Qual a mensagem que a Ignis deixa
para quem esta começando na área?
I: Todos têm que estar cientes das dificuldades que terão pela frente. Nossa
profissão é uma das mais difíceis e
exigentes que existe e muitas pessoas
acabam desistindo por não estarem
cientes disso quando começaram. Nós
gostaríamos de lembrar que é preciso
gostar muito da profissão e não desistir
nunca, pois não existe recompensa
maior que poder trabalhar fazendo o
que realmente se gosta. �
Saiba mais sobre as empresas
Southlogic
http://www.southlogic.com.br
Continuum
http://www.continuum.com.br
Ignis Games
http://www.ignisgames.com.br
S ET E M B R O 2 0 0 4
J O G O S P R O e-magazine
COLUNA:
CENA JAVA
Java no Desenvolvimento de Jogos:
Um Panorama
por Paulo R. C. Siqueira
Desenvolver jogos é uma ciência e uma arte eclética. Exige a
união de grandes conhecimentos de diversas áreas e envolve
muitas complexidades. Para facilitar a nossa vida, existem diversas ferramentas, linguagens, engines etc. prontas para serem
utilizadas. Cada ferramenta tem seus prós e contras, além do
gosto pessoal de cada desenvolvedor. Uma linguagem que vem
aparecendo cada vez mais no cenário do desenvolvimento de
jogos é Java. E ela é o foco desta coluna.
A
cada edição, estaremos explorando diversas características desta
poderosa plataforma, que muitas
vezes é deixada de lado por puro preconceito. Nesta primeira etapa, estaremos
fazendo um panorama geral sobre a
linguagem, mostrando suas principais
características e alguns de seus (muitos)
benefícios. Vamos apresentar rapidamente as APIs mais utilizadas e apontar
caminhos para que o leitor possa se
aprofundar mais.
A primeira coisa que deve ser entendida
é que Java é mais do que uma linguagem. Ela é uma plataforma completa
de desenvolvimento de software, que
abrange desde dispositivos minúsculos,
como Smart Cards, até grandes sistemas
Figura 1 – Arquitetura básica da plataforma Java
corporativos, como o sistema da amazon.
com (uma aplicação web que processa demesmo em todos os casos. Mudam as APIs disponíveis,
zenas de milhares de acessos simultâneos). A plataformas não a sintaxe da linguagem, que é muito parecida
ma Java está dividida basicamente em três partes (além
com C/C++ - o que permite a programadores dessas
da especificação de Smart Cards): Java 2 Micro Edition
linguagens aprenderem Java facilmente.
(J2ME), que possibilita o desenvolvimento de aplicações para dispositivos móveis, como celulares e Palms;
Agora que já temos o conhecimento básico sobre o que
Java 2 Standard Edition (J2SE), que fornece suporte ao
é Java, podemos falar do que realmente nos interessa: o
desenvolvimento de aplicações Desktop, além de ser o
desenvolvimento de jogos!
alicerce para a terceira e mais conhecida parte: Java 2
Enterprize Edition, que fornece APIs, frameworks e outras ferramentas para o desenvolvimento de aplicações
Paulo R. C. Siqueira é desenvolvedor Java, Programador Certificado pela Sun Microsystems e já está viciado em World of
corporativas, incluindo as famosas aplicações web.
Independente de qual parte da plataforma está sendo utilizada, os conceitos principais são sempre
os mesmos: toda aplicação Java roda por cima de
uma máquina virtual (JVM), o que faz com que seja
possível rodar as aplicações em qualquer SO que
possua uma implementação da JVM (todos os Sos
mais importantes têm). Além disso, a linguagem é a
http://www.jogospro.com.br
Warcraft, mesmo ainda não tendo jogado.
S ET E M B R O 2 0 0 4
J O G O S P R O e-magazine
CENA JAVA
O Despertar
Quando falamos em desenvolver
jogos em Java, logo vem à mente “joguinhos” para celular. Isso é
compreensível, pois a linguagem
vem recebendo bastante destaque
neste segmento. Em uma busca de
poucos minutos na internet é possível encontrar, literalmente, dezenas
de pequenas e médias empresas
que desenvolvem este tipo de jogo
utilizando Java.
objetivo facilitar o desenvolvimento
de interfaces de aplicações desktop
e fornecer aos desenvolvedores uma
grande quantidade de recursos. Mas
houve um problema: os desenvolvedores decidiram que a API seria
desenvolvida utilizando todos os
conceitos de orientação a objetos
ao extremo. E de fato isso foi feito. O
Swing é considerado hoje uma obra
prima quanto à sua arquitetura mas,
em compensação, a execução das
aplicações desenvolvidas com ele
eram lentas.
Figura 2: Ancient Empires e Dragon Island, dois jogos para celulares
Uma outra visão comum são os jogos disponíveis em sites na internet,
feitos com applets Java (a mesma
tecnologia que está por trás de
diversos teclados virtuais de sites de
bancos). E nesse caso já temos jogos
bem mais elaborados do que os disponíveis para celular, mas ainda sim
um tanto quanto limitados.
Mas nenhum desses dois casos
mostram o que realmente é possível fazer com Java. Há mais do que
isso. Navegando um pouco mais na
internet podemos perceber que a
plataforma Java está cada vez mais
sendo utilizada para desenvolvimento de jogos mais complexos,
que vão desde jogos 2D, até jogos
com gráficos 3D cuja qualidade é
difícil contestar.
Muitos já devem ter ouvido falar
(mal) do desempenho de Java. Mas
o quanto disso é realmente verdade? Hoje em dia, muito pouco. Essa
fama vem das primeiras versões
da linguagem, quando a plataforma ainda estava um tanto quanto
imatura. Um dos principais culpados
por esse desempenho limitado é
a API Swing. Esta API tinha como
http://www.jogospro.com.br
É claro que
essa não era
a única razão
para o fraco
desempenho
da plataforma Java.
Houveram
diversos
outros problemas, que
foram sendo
corrigidos
Além dessa exposição, a empresa
também está desenvolvendo um
produto comercial para jogos MMO,
o Java Game Server. Para cuidar das
iniciativas para produção de jogos,
a Sun criou um grupo interno de
desenvolvedores chamado Game
Technologies Group (GTG).
Não podemos deixar de citar a grande comunidade que existe
ao redor deste assunto. O fórum da
comunidade de jogos do site java.
net (http://www.java.net) possui, no
momento em que esta coluna está
sendo escrita, 3716 usuários registrados, e está em constante crescimento. Confira também o da comunidade: www.javagaming.org. Lá é
possível encontrar jogos, demos e
APIs. Entre os projetos dessa comunidade, três merecem destaque:
jinput, joal e jogl. O objetivo dos
três é basicamente o mesmo: disponibilizar recursos que não estão
disponíveis diretamente em Java,
ou cujos recursos são insuficientes
para o desenvolvimento de jogos.
conforme as
novas versões eram
lançadas. E
hoje temos
uma plataforma que traz
diversos benefícios para
quem decide
utilizá-la.
Um fato
interessante
é que a Sun
(empresa que
desenvolveu
a plataforFigura 3: Alien Flux, jogo 2D comercial - roda em Linux, Windows e MacOS
ma Java)
está, já há
algum tempo, empregando esforços
Os três projetos são OpenSource e
para facilitar o desenvolvimento de
tem participação ativa de diversos
jogos. Em congressos como o Java
desenvolvedores da comunidade e
One (maior congresso sobre Java do
do GTG.
mundo, que reúne milhares de desenvolvedores todo ano), e o Game
Developers Conference (GDC), a Sun
vem realizando palestras visando
mostrar aos desenvolvedores de
jogos os ganhos que podem ser obtidos com o uso da tecnologia Java.
S ET E M B R O 2 0 0 4
J O G O S P R O e-magazine
CENA JAVA
Os Três Pilares
entrada do loop principal do jogo.
Java, como qualquer outra plataforma
de desenvolvimento, não é perfeito.
No que se refere ao desenvolvimento
de jogos, três são os problemas mais
encontrados pelos desenvolvedores:
tratamento de input do jogador, suporte a tecnologias de processamento gráfico de alta qualidade e recursos
de processamento de audio escassos.
Visando resolver esses problemas, es-
Por mais bonito e divertido que um
jogo seja, uma boa música e efeitos
sonoros são essenciais. Java proporciona uma API chamada Java
Sound, que permite utilizar diversos
recursos sonoros, principalmente no
formato midi (é possível ler outros
formatos com algumas APIs externas). Porém, quando precisamos ter
realmente um bom controle sobre
Muito programadores já devem ter
ouvido falar da biblioteca OpenAL. É
com essa biblioteca que foi procurado
resolver os problemas do Java Sound.
O projeto JOAL permite a desenvolvedores Java utilizar OpenAL para gerar
/ reproduzir os sons do jogo, ao invés
de Java Sound.
Em Java temos diversas opções para
se desenvolver a interface. Há Swing,
Java 2D, Java 3D, entre outras. Mas
todas elas são incompletas no que se
refere ao desenvolvimento de jogos.
Desenvolvedores de jogos querem
mais poder do que essas APIs oferecem. Para a programação gráfica de
jogos, OpenGL é quase unanimidade. Por causa disso, o projeto JOGL
oferece uma opção para se utilizar
OpenGL em Java. Para quem já sabe
OpenGL, é questão de minutos para
se aprender a utilizá-lo com Java, e
boa parte da complexidade envolvida
em códigos C/C++ fica transparente
para o desenvolvedor.
Light Weight Java Game Library
Figura 4: Flying Guns - Desenvolvido com Java3D
tão sendo desenvolvidos três projetos
no portal java.net: jinput (jinput.dev.
java.net), jogl (jogl.dev.java.net) e joal
(joal.dev.java.net).
O jinput ataca o primeiro problema:
o tratamento da entrada do jogador.
O modo convencional de tratamento de entrada de dados em Java é
baseado em eventos, que são sempre
ligados a algum componente gráfico
AWT / Swing. Deste modo, é sempre
necessário ter pelo menos um componente registrado para ouvir estes
eventos, alocando recursos preciosos
do sistema, que ficam, pelo menos
em parte, fora do controle do desenvolvedor. Além disso, não é possível
receber entrada de joysticks ou outros
dispositivos que não sejam o mouse
e o teclado. O jinput funciona de um
modo oposto: ao invés do input ser
lançado em um evento, é o desenvolvedor que deverá verificar quais teclas
foram pressionadas, o que pode ser
feito na parte de processamento de
http://www.jogospro.com.br
o que está acontecendo na parte
sonora do jogo, ou quando precisamos de recursos mais sofisticados de
processamento de som, Java Sound
se mostra extremamente limitada.
Além de JOGL, JINPUT e JOAL, temos o
LWJGL como uma opção de acesso a OpenGL, OpenAL e tratamento diferenciado de
entrada. A principal diferença entre essa
API e as anteriores, é que ela engloba as
três partes que as anteriores atacam em
uma única API. Por isso ela acaba se tornando uma API do tipo tudo ou nada. Entre
os jogos produzidos com Java e OpenGL
atualmente, o uso de LWJGL e JOGL (e suas
irmãs) esta bem equilibrado. Para mais informações acesse: http://www.lwjgl.org.
Figura 5: WurmOnLine – MMORPG
S ET E M B R O 2 0 0 4
J O G O S P R O e-magazine
CENA JAVA
Vantagens de se utilizar Java
Certo, então com Java é perfeitamente possível desenvolver jogos
de qualidade. Mas se eu já programo em C/C++, porque deveria
aprender Java? Abaixo estão listadas as suas principais vantagens:
◊ Multiplataforma: A qualidade mais conhecida de Java é a sua
portabilidade. O fato de Java ser multiplataforma nos garante que
nossos jogos poderão rodar pelo menos nos três SO’s mais utilizados: Windows, Linux e MacOS.
◊Produtividade: Uma outra qualidade muito comentada de Java
é a sua produtividade. A linguagem possui algumas características
interessantes que nos auxilia nesse sentido. Uma dessas características é a ausência de ponteiros. Portanto você não precisa se preocupar em desalocar memória (fonte de muitos problemas em código
C/C++). A própria linguagem se encarrega de detectar classes que
não estão mais em uso e liberar a memória usada por estas classes.
◊ Deployment Simplificado: Utilizando Java Web Start (JWS), é
extremamente simples para o jogador instalar seu jogo. Tudo o que
ele tem que fazer é ir até a página do jogo e clicar em um link. JWS
irá fazer o download e a instalação automaticamente. Depois de
instalado, o próprio JWS checa por possíveis atualizações. Se estas
existirem, ele as baixa e instala. Tudo com a mínima intervenção do
jogador.
◊ Evolução Comunitária: A plataforma Java está sempre evo-
luindo. Isso quer dizer que, se há um recurso poderoso do qual o
desenvolvedor precisa que não está disponível, há sempre grandes
chances dele ser acrescentado ao Java. E o melhor é que essa
evolução não é controlada pela Sun, mas sim pela comunidade, e
qualquer um pode participar. É para isso que existe o Java Community Process (JCP – http://www.jcp.org). Através dele é possível
acompanhar o que está sendo feito para o futuro da plataforma
Java e, mais importante, participar deste futuro.
◊ Uso de padrões: Toda a arquitetura da plataforma Java é
construída em cima de padrões. A própria JVM é na verdade uma
especificação, e qualquer um pode desenvolver a sua. E isso é
muito importante, pois trás independência de fornecedores. Você
sempre terá a possibilidade de trocar o fornecedor da sua JVM, dos
seus parsers XML ou qualquer outra coisa, desde que os padrões
sejam seguidos.
◊ Economia: Ferramentas são indispensáveis no desenvolvimento
de qualquer aplicação, jogo ou não. Para Java, há uma quantidade
enorme opções com as quais o desenvolvimento pode ser feito. E a
grande maioria é grátis, e com qualidade profissional. Só para citar
algumas, temos duas excelentes IDEs: Eclipse (http://www.eclipse.
org) e NetBeans (http://www.netbeans.org), ambas gratuitas e
entre as mais utilizadas do mercado.
Por onde começar
Então você decidiu tentar utilizar
Java. A primeira coisa que deve ser
feita é baixar o JDK, disponível em
http://java.sun.com. Neste mesmo
site há uma extensa documentação
sobre toda a plataforma Java. Uma
IDE também é importante. As duas
mais utilizadas são o Eclipse e o
NetBeans, já citadas anteriormente.
Sugiro que baixe as duas e escolha a
que mais lhe agradar. Comece como
você começaria em qualquer outra
linguagem: faça um joguinho básico
como Pong, e vá escrevendo outros
jogos aumentando a complexidade
aos poucos. Comece com Swing e
Java2D mesmo (a não ser que você
Java Game Server
O mercado de MMOs no mundo vem
crescendo bastante nos últimos anos.
Visando este mercado, a Sun está
desenvolvendo um servidor de jogos
MMO, o Java Game Server (http://www.
sun.com/smi/Press/sunflash/2004-03/
sunflash.20040323.1.html), que tem o
objetivo de prover a infraestrutura comum a muitos dos jogos massivos, com
escalabilidade, persistência automática
dos objetos do jogos e mais um monte
de coisas. Independente do servidor ser
bom ou não, o importante é notar que a
Sun, criadora da plataforma Java, está
começando a ver o mercado de jogos
com bons olhos, o que só tem a nos
beneficiar.
Figura 6: Jose, feito com Java3D
http://www.jogospro.com.br
já saiba OpenGL). Depois que já estiver familiarizado com a linguagem
Java, parta para OpenGL e se divirta!
O Futuro
Nesta edição tivemos uma introdução do que pode ser feito com a
plataforma Java. Vimos que a falada
lentidão não passa de lenda hoje
em dia, e que é possível utilizar os
mais modernos recursos atualmente
disponíveis no mercado. Na próxima
edição, iremos abordar algum ponto
mais específico, e você pode ajudar
a escolher qual será esse ponto.
Acesse o site da JogosPro e-Magazine e opine nos forums!
Figura 7: SquareHeads, com um mapa de Quake 3
S ET E M B R O 2 0 0 4
J O G O S P R O e-magazine
por Alandro Vieira dos Reis
Videogames no Cyberpunk
de William Gibson
Sobre William Gibson: Escritor norte-americano de contos e romances de
ficção científica dos anos 1970, consagrou-se na década de 80, ao criar o
estilo Cyberpunk. Atuou no roteiro de filmes para o cinema e alguns episódios de X-Files. Hoje aposentado, mora no Canadá.
Ficção Científica: Reflexão e Antecipação
As mudanças na sociedade decorridas
dos avanços tecnológicos costumam
mexer com a imaginação dos escritores, que tem por hábito criar histórias
que expressam seus anseios e sonhos
quanto às novidades que a ciência e
a tecnologia trazem ao mundo. Podemos inferir que além de um eficiente
termômetro dos anseios causados pelas mudanças tecnológicas, as histórias
de um tempo também podem subsidiar reflexões sobre as novas tecnologias e costumes e até mesmo ligeiras
antecipações.
Este artigo trata das antecipações
presentes no livro Neuromancer, de
William Gibson, sobre os jogos eletrônicos como componente da cultura, o
texto conclui-se compartilhando com
o leitor as reflexões que William Gibson
propõem em sua poesia elétrica hightech.
O Movimento Cyberpunk
O cyberpunk, herdeiro de “1984” de
George Orwell, é a ficção científica do
nosso tempo, tendo gerado filmes de
grande sucesso como a trilogia Matrix.
No início da década de 1980, William
Gibson definiu o cyberpunk, marcado
pelo viés noir (tramas policiais com
densidade psicológica), muita ação
e inquietações filosóficas, tendo por
pano de fundo um futuro onde as
tecnologias moldam cada aspecto do
modo-de-vida de todos.
A importância do cyberpunk pode ser
avaliada além do cinema, das histórias
em quadrinho e livros. O próprio termo
cyberespaço, hoje tido como sinônimo
de internet, foi inventado por William
http://www.jogospro.com.br
Gibson, que também influenciou a
NASA a usar luvas e capacetes de imersão para treinamento de astronautas
através de jogos eletrônicos de simulação.
Como cerne deste artigo, tratarei de
“A Matrix teve
sua origem nos
primitivos jogos
eletrônicos”.
(trecho de Neuromancer, escrito
em 1984)
outro fator que testemunha a importância dessa ficção científica para nós:
as antecipações sobre os jogos eletrônicos feitas por Gibson, presentes em
seu futuro ficcional.
Futuro esse que, até certo ponto, já é o
nosso presente.
Jogos Eletrônicos em Neuromancer
Basicamente há seis componentes
muito comuns dos jogos eletrônicos
dos dias de hoje que William Gibson
antecipou, com cerca de 15 anos de
antecedência, com sua ficção científica.
1. Hackers
A mais freqüentemente explorada
situação de jogo eletrônico em Neuromancer é a atividade hacker. Descrita
como um estimulante jogo de invasão,
de burlar regras e quebrar barreiras do
Sistema. O risco alucinante, os ganhos
exorbitantes, as possibilidades de punições terríveis, tudo isso faz parte do
jogo da invasão.
O protagonista da história é Case, um
super-hacker com habilidades incomuns de invadir e controlar sistemas
de informação. Contudo, sua habilidade ganha dimensões de vício. Gibson,
com Case, aborda o comportamento
de jogo compulsivo, com todas as implicações patológicas que dele decorrem, como a desagregação contínua
da vida de seu anti-herói.
2. Realidade Virtual
Intrinsecamente associada à primeira,
está a imersão em mundos virtuais.
Descrita pelo autor como “adentrar
numa alucinação consensual”, a imersão é realizada por neuroimplantes
e dispositivos digitais, e opera uma
separação da mente e do corpo, sendo que a primeira é revestida de um
personagem digital como roupagem.
A realidade virtual tem por características o dinamismo do hipertexto,
a vida pulsante de uma floresta, a
possibilidade de criação e recriação
incessantes. Explorá-la é construí-la. Os
navegadores desse Novíssimo Mundo
são os usuários, que também exercem
o papel de criadores deste. É a vez de
Gibson alertar para o patológico desejo de alienação, de fuga da realidade:
os usuários compulsivos do cyberespace
trocam suas vidas por simulacros, numa
relação esquizóide com as máquinas.
S ET E M B R O 2 0 0 4
J O G O S P R O e-magazine
3. Jogos de Simulação
Uma vez inserido no cyberspaço, Case é
orientado por uma inteligência artificial
chamada Linha Plana, que atua como mentor em sua jornada pelos mundos virtuais,
e lhe informa opções mais acertadas. Se a
imersão de Case for vista como um jogo de
navegação, Linha Plana funciona como um
navegador ou gestor técnico da simulação.
Em outros livros, como em Idoru, Gibson
sugere que algumas inteligências artificiais também teriam por função orientar a
criação e gestão de mundos virtuais pelos
usuários, num imenso jogo de simulação
de cidades, países, reinos. As semelhanças
desses relatos ficcionais com jogos atuais
de simulação, como SIM City, não param
por aí. Uma vez criada uma cidade virtual,
ela é povoada por pessoas simuladas, que
vivem suas vidas artificiais reguladas por algoritmos dos usuários. Jogos de simulação
semelhantes fazem imenso sucesso neste
início de século XXI, como o mais vendido
de todos os tempos, The SIMs.
clara referência ao roleplaying game(RPG)
mais popular nos EUA nos anos 80: o
Dungeons&Dragons. Falar de pessoas conectadas todas num mesmo RPG digital
significa a antecipação dos massive multiplayer on line games (MMOG) como Never
WinterNights, Dark Ages of Camelot, etc.
Em outro livro, Idoru, tal conceito é desenvolvido, e figuram em cena comunidades
virtuais, tais como conhecemos hoje em
sites como Orkut, porém numa versão de
realidade virtual imersiva gerida por inteligências artificiais.
6. First Person Shooters
O episódio notoriamente que mais lembra
ra pessoa, inclusive cenas de luta, fuga e
perseguição alucinantes. Impossível ler a
narração do episódio sem pensar em jogos
do tipo first person shooter, como Counter
Strike.
Reflexões
Ao contrário do que se costuma crer comumente, a cybercultura já possui uma História de mais de 20 anos (Neuromancer é de
1984) e conta até com uma densa ficção
científica correlata que investiga filosófica e
psicologicamente sua estrutura.
O modo como os jogos eletrônicos são antecipados na obra de William Gibson confirma a importância da visão deste autor, suas
reflexões sobre tais práticas lúdicas. Gibson, dentre outras coisas, nos alerta para o
jogo compulsivo, a fuga da realidade em
nome da virtualidade e a banalização do
real em detrimento de simulacros, e outros
temas que se tornam reflexões filosóficas
e emanam da leitura de Neuromancer, que
constitui-se o livro fundador e até hoje a
ficção mais importante da cultura digital.
4. LAN Houses
Casas de jogos eletrônicos figuram regularmente em ambientes noturnos em Neuromancer. Seja em Tóquio ou nas megalópoles dos EUA, surgem grandes salões onde
dezenas ou centenas de pessoas estão
todas conectadas a uma realidade virtual
lúdica. As casas de jogos, curiosamente, são
freqüentadas em sua maioria por jovens e
adultos. O autor não fala de adolescentes
e crianças. Mulheres também constam
nas casas de jogos da ficção cyberpunk
de Gibson. Em sua visão antecipatória, a
faixa etária dos jogadores iria aumentar e a
participação feminina seria importante no
mundo dos jogos eletrônicos, proposições
essas que provocariam risos se fossem ditas
há 15 anos.
5. MMOGs
Em um dado momento, Gibson descreve
um jogo dessas casas de jogos como sendo
um jogo de estratégia ambientado num
calabouço de um castelo medieval, numa
OBS: Para a escrita deste artigo usei como
referência a seguinte versão em português
de Neuromancer:
GIBSON, William. Neuromacer. Editora Aleph, 3a edição, 1a reimpressão, São Paulo:
2003.
Alessandro Vieira dos Reis
[email protected]
http://www.certi.org.br/~avr/
Figura: Capa do Livro Neuromancer
os atuais jogos eletrônicos no livro Neuromancer se dá quando Case, através de uma
conexão neurodigital (chamada no livro
de SIMStim, simulated stimulation, ou “estimulação simulada”), consegue receber as
informações sensoriais de Molly, passando
a ser como uma câmera na mente de sua
parceira. Esta, uma habilidosa guerreira,
invade uma instalação inimiga, contando
com a monitoração e orientação de Case,
que percebe toda a experiência em primei-
O evento será realizado na cidade de Curitiba no Paraná, também nesta cidade, em data próxima ao SBGames, será promovido o SIBGRAPI2004 (Simpósio Brasileiro de Computação Gráfica e Processamento de Imagens) e o SIAGG-2004 (Simpósio Ibero-Americano de Computação
Gráfica). Confira tudo em:
http://wwwusers.rdc.puc-rio.br/sbgames/
http://www.jogospro.com.br
S ET E M B R O 2 0 0 4
J O G O S P R O e-magazine
Coluna
Jogos Open Source
Utopia, modismo ou necessidade ?
por Julio Marchi
Desenvolver jogos de computador sempre foi um dos mais comuns ideiais de
motivação para que os jóvens ingressassem na área
de programação de computadores. Muitos de meus
amigos – e inclusive eu mesmo – começaram a escrever
suas primeiras linhas de código voltadas “àquele jogo
fenomenal” que ninguém tinha feito ainda. Entretanto, a
esmagadora maioria dos que iniciaram por este caminho não chegaram a alcançar este objetivo primário.
Em critérios gerais, desenvolvimento de jogos para
computador é um dos maiores desafios que um programador pode encontrar. É necessário ter o domínio de
inúmeras técnicas complexas para que se possa produzir
um simples joguinho. Não obstante, há poucos anos
atrás, o maior agravante que enfretávamos era a quase
total inexistência de documentações sobre o tema. Não
existiam exemplos e ferramentas específicas para isso
como atualmente; e não haviam sequer tantos recursos
avançados - e simplificados – destinados exclusivamente
ao desenvolvimentos de jogos. Entre isso e outras realidades, a soma dos fatores foi fazendo com que muitos
- assim como eu, que tomei gosto pelos computadores
graças aos jogos – estudassem computação à fundo para
acabar tendo o foco produtivo em outras coisas mais factíveis, deixando o desenvolvimento de jogos, que era o
objetivo primário, apenas como uma “doce recordação”.
Se antes desenvolver jogos de computador era
uma questão de ter boas idéias e de ser um excelente
Julio Marchi é Analista de Sistemas formado especilizado em
engenharia de software, network, multimídia e Internet. Atualmente é CEO de duas empresas nos EUA e desenvolve diversos
projetos técnicos e áudio-visuais para outras empresas.
http://www.jogospro.com.br
programador - ou fazer parte de um bom grupo
-, hoje desenvolver um jogo assemelha-se
mais à produzir um filme de Hollywood do que
simplesmente programar. Não é que não hajam
mais espaços para os jogos simples e de baixos
recursos, porque atualmente, em se tratando
de informática, há espaço para quase tudo... Eu
me refiro em termos mercadológicos, onde a
competição de se “vender” jogos obriga que o
produto tenha muitas características avançadas
como: música e efeitos sonoros, um “roteiro”
envolvente, qualidade gráfica - mesmo em 2D -,
jogabilidade, boa apresentação, propaganda e
preço. Pode até não parecer, mas para alcançar um nível
suficientemente bom e atrair a atenção do consumidir
neste mecado altamente competitivo é como embarcar
uma “Luta de Titãns”. Em termos gerais, decidir produzir
um jogo mediano e de apenas boa qualidade geral,
pode chegar a representar um investimento inicial de
mais de US$ 50.000,00, o que para países como o Brasil
é um investimento demasiadamente alto para arriscar
em um mercado ainda emergente, o qual já sofre com a
influência do milionário mercado internacional.
Mas, como atualmente a velocidade da
informação já desbancou a da luz, as dificuldades se apresentam de
um lado e as soluções
emergem de outro. Com
o avanço da tecnologia
tudo tem ficado mais fácil, e o desenvolvimento
de jogos não tem sido
uma excessão. Alem das
novas ferramentas que
surgem a cada dia, há também um infindável e crescente
acervo de informações, exemplos e “bibliotecas” que
colaboram para diminuir o tempo de desenvolvimento
de um jogo, o que reflete diretamente no investimento necessário. Com o advento da Internet surgiram
também novas linhas de “negócios”, mais baratas e
diretas – e ainda pouco exploradas -, que quando bem
utilizadas podem atualmente fazer a difereça entre
o sucesso e o fracasso de um produto. Ainda graças
à grande facilidade de intercâmbio que a Internet
oferece globalmente, os produtos “open source” têm
S ET E M B R O 2 0 0 4
J O G O S P R O e-magazine
Coluna
obtido grande atenção da comunidade desenvolvedora
global. Os resultados destes últimos anos e o sucesso de
diversos programas desenvolvidos nesta “parceria”, com
a colaboração “gratuita” de incontáveis pessoas de todas
as partes do mundo, já comprovam que o open source e
seus “rabichos” vieram para ficar.
Open Souce soa lindo de todas as formas que
se escuta, mas ainda traz algumas “discussões” que tendem a esquentar nos próximos anos. Mesmo a famosa
licença GPL já vem levantando polêmica principalmente porque muito dela
não se adequa à diversas Leis locais de
software de vários países. Não obstante,
Open Souce para o mercado de jogos
distôa do conceito principal da essência
deste mesmo mercado: a comercialização. Mesmo que um jogo de alto
nível, desenvolvido via Open Souce,
fosse vendido por apenas UM DÓLAR,
ainda assim haveriam outros problemas intelectuais com relação a vários
pontos: 1) O mais caro de um jogo, e o
mais importante, é sua ENGINE. Uma
“engine Open Source” tem uma grande possibilidade de
ser a melhor que existe, mas por ser Open Souce nada
impedirá que esta seja usada indiscriminadamente em
produtos comerciais de terceiros; 2) Jogos, ao contrário
de outros produtos computacionais, não se restringem
somente ao código do programa, mas também às animações, enredo e conteúdo musical, e o Open Source
não abrange nada disso; 3) O mercado Open Source fica
automaticamente FORA do mercado de consoles (XBox,
PlayStation, GameCube) por questões de licenciamento,
perdendo uma grande e crescente fatia do mercado
consumidor de jogos.
Se formos explorar e comparar a idéia de “Open Source
para aplicativos gerais” com a aplicação do “Open Source para desenvolvimento de jogos” serão demasiados
os pontos controversos, mas existe um em específico
que mais chama minha atenção: projetos “Open Source”
normalmente NUNCA terminam! De tempos em tempos
são lançadas novas e mais novas versões do programa
com melhorias gerais e mais recursos. Eu não consigo
ver esta mesma “característica” do
Open Source adaptando-se aos jogos.
Jogos são produtos de consumo direto:
compra-se, joga-se, termina-se o jogo
e pronto! Não usamos jogos como
aplicativos no nosso dia-a-dia e não
existe muito esta coisa de adicionar
um novo “feature” num jogo porque
quase ninguém vai parar um jogo no
meio e recomeçá-lo – por exemplo
– por causa de um recurso novo que foi
implementado na fase “X”. No máximo
implementa-se novos inimigos, níveis,
armamentos ou coisas assim para dar
mais longevidade ao jogo, mas isso não é nada que não
possa ser feito com os “patches” ou “expansion packs”.
Não estou dizendo aqui que jogos Open Source
não têm seu espaço ao Sol porque a grande verdade
é que SIM, é uma excelente idéia! Tão boa que têm até
mais espaço e potencial do que muitos aplicativos que
eu tenho visto no SouceForge, por exemplo. O que
estou dizendo é que, do ponto de vista comercial, eu
não vejo futuro para jogos Open Source a não ser no
caso de: 1) Jogos Educativos; 2) Jogos para Internet ou;
3) Projetos para Estudo e Aprendizado.
Outro ponto controverso que não pode ser
esquecido, e que agride diretamente o tema “jogos
Open Source” é o foco das plataformas. Como para os
“consoles” os jogos Open Source estão descartados,
sobram macissamente o Mac e o PC, onde, no caso do
PC entram as variantes de Sistemas Operacionais. O
problema principal neste ponto é exatamente a
ENGINE, que comumente tem que ser o mais
otimizada possível para melhor poder usar
mais eficientemente os recursos de
cada sistema, o que obriga que se
desenvolvam versões específicas para cada SO. No caso
do Mac não há tanto problema porque o Sistema
Operacional hoje é basicamente um só – o Mac OS
X. Já o PC sofre atualmente com as variações de
SO’s disponíveis, onde os
mais contundentes são
Windows e Linux. Para
agravar o quadro, cada
um destes possui suas próprias “sub-variações”, que
“Projetos Open
Source normalmente NUNCA
terminam!”
http://www.jogospro.com.br
S ET E M B R O 2 0 0 4
J O G O S P R O e-magazine
Coluna
podem diferenciar-se em pontos chaves no que tange
às necessidades dos jogos. O Windows pelo menos tem
o DirectX, mas para Linux esta idéia está apenas engatinhando. Ainda no enfoque PC, o Linux perde o mercado
de “usuários finais” - entenda-se “leigos” – pois seu uso
pelo público geral ainda é bem modesto, o que leva o
enfoque do desenvolvimento de jogos comercialmente
lucrativos para a plataforma Windows.
Em suma, por dependência de recursos (som,
animação, engines, etc.) os jogos Open Source são uma
grande idéia que já nasce com grandes problemas. Nos
EUA essa idéia tem tido muito boa aceitação, só que
muito mais enfocada no conceito de estudo e aprimoramento. Entretanto, em países onde o mercado de desenvolvimento de jogos ainda é emergente e a realidade é
difícil por conta da forte competição, o Open Source, se
bem usado, pode ser uma excelente forma de diminuir
os custos na pesquisa e produção de jogos; no aprendizado e desenvolvimento de novas técnicas e, principalmente, no esforço de demonstrar potencial produtivo
para os possíveis “investidores”. O maior problema que
pode existir talvez nem seja na parte técnica ou artística, mas sim em encontrar uma forma de lidar com as
licensas tipo GPL sem criar “conflitos legais” ou “roubo de
http://www.jogospro.com.br
tecnologia”.
Como todo recurso, ferramenta ou idéia, a
diferença entre o sucesso e o fracasso de um empreendimento está mais em sua implementação do que em
seu conceito geral. Open Source pode ser um grande
diferencial, pode ajudar a baixar custos e também melhorar a qualidade final de qualquer produto, mas ainda
haverão os critérios intelectual e artístico, assim como
o problema no manuseio das licenças. O dia que for encontrada uma fórmula para combinar Desenvolvimento
de Jogos com licenças públicas, critérios intelectuais e
comerciais o Open Source poderá – e certamente será
- uma poderosa ferramenta para, pelo menos, ampliar
o mercado de desenvolvimento de jogos no Brasil, permitindo que as empresas brasileiras possam competir
mais de perto com produtos das grandes e milionárias
empresas internacionais.
por Julio Marchi
S ET E M B R O 2 0 0 4
J O G O S P R O e-magazine
Entrevista
Fábio Binder
O
professor Fábio Binder é coordenador do curso de pós-graduação em desenvolvimento
de jogos do Unicenp. Foi pioneiro na sua área ao lançar esse curso, quando na área
acadêmica ainda não se houvia falar em curso de jogos. A JogoPRO foi conversar com o
Binder e saber como anda a academia e o mercado brasileiro de jogos.
JogosPRO: Fábio, em 2001 você
teve a iniciativa de criar o primeiro
curso de pós-graduação da América
do Sul em desenvolvimento de
jogos. Formando os primeiros profissionais em jogos brasileiros. Como
surgiu essa iniciativa?
Fabio Binder: Eu já trabalhava há
vários anos tanto na área acadêmica
quanto no desenvolvimento de
jogos educacionais. O “pulo do gato”
aconteceu em 2000 quando assumi
a coordenação do curso de especialização em Web do Unicenp e percebi que existia assunto suficiente
para montar um curso de desenvolvimento de jogos. O momento
era propício devido a algumas reportagens sobre jogos no Paraná.
Montei a proposta do curso que foi
prontamente aprovada. Esbarrei na
falta de profissionais para ministrar
aulas. Pouco tempo depois soube da
Gamenet que me ajudou na elaboração do formato definitivo, indicou
professores e bancou várias bolsas
da primeira turma, tornando o curso
viável financeiramente.
JP: Já tivemos 2 edições da pós, que
balanço você faz hoje?
FB: A segunda edição termina
agora no final de outubro. O saldo é
bastante positivo. Dos 30 alunos que
finalizaram ou que estão finalizando
o curso, atualmente 11 trabalham
com jogos em empresas de jogos,
algumas de destaque no cenário
nacional como Ignis Games, South
Logic e Continuum.
JP: No Brasil hoje temos cursos de
graduação, workshops e congressos
relacionados a jogos. É um mercado
em franca expansão?
FB: Sem dúvida. Mas isso foi apenas o começo. A consolidação das
empresas atuais, o crescente interesse da comunidade e a criação de
uma associação sólida de empresas
http://www.jogospro.com.br
(Abragames que já mostra serviço
no seu ano de criação) são fortes
indícios de que “neste mato tem
coelho”.
JP: Com esse mercado, a Unicenp
pretende ter um curso de graduação em jogos, ou quem sabe um
mestrado?
FB: O Unicenp está começando em
cursos de mestrado. No ano que
vem teremos o mestrado em “Tecnologias Educacionais”. Alunos que
fizerem o curso de jogos poderão
descontar créditos do mestrado. Por
sua vez, alunos do mestrado poderão fazer determinados módulos
“Dos 30 alunos que
finalizaram ou que
estão finalizando o
curso, atualmente
11 trabalham com
jogos, ...”
do curso de jogos contando como
créditos para seu mestrado. Além
disso, a graduação do Unicenp já
aceita há alguns anos, jogos como
projeto final de curso. Eu devo ter
orientado uns 15 projetos nesta área
nos últimos 10 anos.
JP: O Brasil forma profissionais em
desenvolvimento de jogos, a comunidade está cada vez mais organizada, temos empresas com jogos publicados, mas parece que falta alguma
coisa. Você, como desenvolvedor e
educador, tem uma explicação?
FB: Eu acho que isso é apenas uma
falsa impressão. À medida em que
as empresas atuais lançarem mais
jogos (aqui ou no exterior) e desco-
brirem “novos” modelos de negócio
eficientes, o mercado se consolidará
de vez. Outras empresas seguirão
a onda e logo (se o governo não
inventar moda...) todos saberão que
existe desenvolvimento de jogos no
Brasil. Mas é claro que se houvessem
mais investidores dispostos a tirar
dinheiro do bolso isso já teria acontecido.
JP: Há 2 anos não se ouvia falar em
jogos em faculdades, como você vê
a área acadêmica de jogos no Brasil
nos próximos anos?
FB: Observando os números dos
cursos atuais, parece que ainda existe um bom espaço para crescimento. Os cursos do Unicenp, Puc-Rio e
Anhembi-Morumbi já vão para sua
terceira turma. No Rio de Janeiro,
a T&T que oferece cursos técnicos
em jogos possui mais de 100 alunos
só nesta área. Em diversas universidades brasileiras (Puc-Rio, UFRJ, USP,
Puc-PR, UFPE, UFRS, entre outras)
existem pessoas trabalhando em
dissertações e teses relacionadas ao
desenvolvimento de jogos. Gente
competente e vontade é o que não
falta.
JP: O que você recomenda para
quem esta começando?
FB: Primeiro, jogar bastante e descobrir sua área de afinidade. Conversar
com pessoas da área e começar
cedo com jogos simples feitos
em ferramentas de autoria (flash,
rpgmaker, Doom3Maker :o), etc) é
uma atitude inteligente. Aliás, estes
pequenos jogos, que são motivo de
“nariz torcido” por parte de alguns,
estão sustentando muita gente por
aí. Fazer um bom portfolio é importante, pois no momento em que surgir uma boa oportunidade é melhor
já estar preparado.
S ET E M B R O 2 0 0 4
J O G O S P R O e-magazine
por Bruce “Sinner”
A R T I G O S
Introdução ao OpenGL Shading Language
A
introdução de hardware gráfico programável no mercado abriu uma nova era
para a Renderização em Tempo Real. Com ele é possível desenvolver pequenos programas (shaders) que são executados diretamente na GPU, com uma
performance bem maior por causa disso. A utilização de shaders permitiu
artistas e desenvolvedores produzirem efeitos especiais sofisticados que antes
eram renderizados offline, em hardware simples e barato. O aumento
do uso dos shaders, que no ínicio
eram desenvolvidos em assembler,
levou à criação de linguagens mais
sofisticadas e de alto nível, semelhantes as linguagens já utilizadas
como C++ ou Java. Uma dessas
linguagens, a OpenGL Shading
Language (GLSL) foi recentemente
lançada e passou a ser suportada
somente agora, com o lançamento dos drivers da série 60 da NVidia. Ao longo desse texto mostrarei
suas características, sintaxe, futuras
implementações, como integrá-la
ao OpenGL, al[em de alguns exemplos. Farei também, uma pequena
comparação entre ela e outras duas
linguagens bastante difundidas, a
HLSL da Microsoft e a Cg da Nvidia.
letal Animation, Bump Mapping,
Parallax Bump Mapping, Glow,
Morphing, texturas procedurais em
runtime (Figura 1) e outros mais. Os
shaders estão disponíveis no OpenGL desde 2002 através das extensões
ARB_vertex_program e ARB_fragment_program mas tinham que ser
codificados em assembler, o que
não os tornava muito popular. Com
o surgimento de linguagens de alto
nível para os shaders, como a HLSL
da Microsoft e Cg da Nvidia, foi desenvolvido a GLSL, uma linguagem
de alto nível também, que permitiu o desenvolvedor a escrever seus
shaders numa linguagem similar ao
C/C++ tornando a tarefa muito mais
fácil !
Por quê usar Shaders e GLSL?
Um programa típico feito com a GLSL
geralmente é composto de um par
Vertex Shader e Fragment Shader:
O hardware gráfico antigo (GeForce
256, Radeon 7000 ) somente permitiam que o pipeline gráfico fosse
configurado e não programado. Isso
limitava a quantidade de efeitos especiais e técnicas avançadas, que
deveriam ser simuladas em software, o que por muitas vêzes impossibilitou a utilização deles em tempo
real. Um exemplo disso são os modelos de iluminação do OpenGL. Os
modelos Ambient, Diffuse, Specular
e Emissive são largamente utilizados
mas há outros também como o de
Phong por exemplo. Com shaders,
é possível programar outros modelos de iluminação. Outros efeitos
interessantes também são possíveis,
como: Soft Shadows, Environment
Mapping, Per-Pixel Lightning, Skehttp://www.jogospro.com.br
Características da GLSL
Vertex Shaders
Um Vertex Shader opera em todos
os vértices enviados para o pipeline.
Então a cada chamada a glVertex ou
glDrawArrays é executado o shader.
Vertex Shaders são usados para se
ter amplo controle sobre a posição
de cada vértice a ser renderizado.
Exemplos de uso são em animações
skeletais, morphing entre dois modelos 3D, a criação de efeito de ondas
sobre uma malha de polígonos, etc...
Fragment Shaders
Um Fragment Shader opera sobre
todos os fragmentos produzidos
pela rasterizaçãodo OpenGL. Um
fragmento é mais do que um simples pixel. Ele também possui informação como cor, depth, stencil, etc...
Tipos de dados
A GLSL possui quatro tipos principais: float, int, bool e sampler.
Figura 1: Modelos 3D mostrando efeitos que são
possíveis de se fazer usando Shaders.
Bruce “Sinner” é desenvolvedor profissional e atualmente desenvolve um simulador
virtual da linguagem visual dos surdos em C++ e OpenGL. Quando não está programando diverte-se assistindo Tom & Jerry com seu filho no Cartoon Network.
S ET E M B R O 2 0 0 4
J O G O S P R O e-magazine
A R T I G O S
Existem também tipos que funcionam
como array dos tipos principais. São eles:
Float:
vec2 vec3 v e c 4
Int:
ivec2 ivec3 i v e c 4
Bool:
b v e c 2 b ve c 3 b v e c 4
Matrizes: m a t 2 m a t 3 m a t 4
O tipo matriz é composto apenas
por floats. O tipo Sampler é usado para operações com texturas.
Attributes, Uniforms, Varyings e Const
A GLSL também possui qualificadores
de tipo que são:
Attributes: Apenas estão disponíveis no
Vertex Shaders. São valores de entrada
que mudam para cada vértice processado, como sua posição ou normal, por
exemplo. Os Attributes são read-only.
Uniforms: São valores que não mudam durante o rendering, como a
posição da luz por exemplo. Estão
disponíveis nos Vertex e Fragment
Shaders. Os Uniforms são read-only.
Varyings: São usados para passar informações do Vertex para o Fragment
Shader. Eles são read-only nos Fragment Shaders mas permitem leitura e
escrita nos Vertex Shaders. Devem ser
declarados de forma idêntica nos Vertex e Fragment Shaders que os usarem.
Constants: Não podem ter seu valor
alterado, assim como no C. Geralmente
guardam valores dependentes da implementação do OpenGL que se está usando como o número máximo de luzes por
exemplo. Read-Only por razões óbvias.
Os qualificadores Atributes, Uniforms e
Varyings devem ser sempre declarados
globais.
Uniforms:
gl_ModelViewMatrix: matriz 4x4 representando a matriz de modelview.
gl_ModelViewProjectionMatrix:
matriz 4x4 representando a matrix de
projeção.
Esses foram alguns exemplos. Há também Varyings pré-definidos e muito mais
Uniforms e Attributes. Consulte a seção
Links para ter acesso à documentação.
A criação de texturas procedurais em
runtime são um ótimo exemplo do quão
poderoso os shaders podem ser. Na listagem 1 mostro um exemplo de como criar
uma textura simulando uma parade de tijolos. Na figura 2 pode-se ver o resultado.
É possível também criar seus próprios Attributes, Uniforms ou Varyings personalizados como mostra os exemplos abaixo:
attribute vec3 rotacao
uniform mat4 matrix_de_textura
varying vec3 vetor_normal
Figura 2: Resultado do Shader
Funções
A GLSL já possui algumas funções para
ajudar o desenvolvedor nas tarefas
mais rotineiras. Alguns exemplos: abs,
Listagem 1: Brick Shader Exemplo.
// Vertex Shader
uniform vec3 LightPosition;
const float SpecularContribution = 0.3;
const float DiffuseContribution = 1.0 - SpecularContribution;
varying float LightIntensity;
varying vec2 MCposition;
void main(void)
{
vec3 ecPosition = vec3 (gl_ModelViewMatrix * gl_Vertex);
vec3 tnorm
= normalize(gl_NormalMatrix * gl_Normal);
vec3 lightVec
= normalize(LightPosition - ecPosition);
vec3 reflectVec = reflect(-lightVec, tnorm);
vec3 viewVec
= normalize(-ecPosition);
float diffuse
= max(dot(lightVec, tnorm), 0.0);
float spec
= 0.0;
A GLSL já possui uma lista de qualificadores pré-definidos e que podem ser
utilizados. Abaixo cito alguns exemplos:
}
if (diffuse > 0.0)
{
spec = max(dot(reflectVec, viewVec), 0.0);
spec = pow(spec, 16.0);
LightIntensity
MCposition
gl_Position
Attributes em Vertex Shaders:
http://www.jogospro.com.br
Exemplo de Shader
Attributes, Uniforms e Varyings Personalizados
Attributes, Uniforms e Varyings Internos e Reservados
gl_Vertex: Vetor 4D representando as coordenadas do vértice sendo processado.
gl_Normal: Vetor 3D representando
as coordenadas da normal do vértice.
floor, ceil, mod, noise1, etc... Para uma
lista completa consulte as referências
citadas na seção Links desse artigo.
= DiffuseContribution * diffuse +
SpecularContribution * spec;
= gl_Vertex.xy;
= ftransform();
}
S ET E M B R O 2 0 0 4
J O G O S P R O e-magazine
A R T I G O S
Listagem 1: Brick Shader Exemplo. (cont.)
// Fragment Shader
uniform vec3
uniform vec2
uniform vec2
BrickColor, MortarColor;
BrickSize;
BrickPct;
FarCry, Unreal 2004) talvez impulsione
as fabricantes e façam com que a GLSL
se estabeleça de vez como uma das linguagens padrão de desenvolvimento
de shaders no mercado de computação
gráfica.
varying vec2 MCposition;
varying float LightIntensity;
Links
3Dlabs, principal desenvolvedora do GLSL
http://www.3dlabs.com
void main(void)
{
vec3 color;
vec2 position, useBrick;
OpenGL Shading Language (Orange Book)
http://www.3dshaders.com
position = MCposition / BrickSize;
ATI GLSL exemplos
http://www.ati.com/developer/sdk/RadeonSDK/Html/
Samples/OpenGL/GLSLSimpleShader.html
if (fract(position.y * 0.5) > 0.5)
position.x += 0.5;
position = fract(position);
useBrick = step(position, BrickPct);
}
color = mix(MortarColor, BrickColor, useBrick.x * useBrick.y);
color *= LightIntensity;
gl_FragColor = vec4 (color, 1.0);
Site pessoal do Humus com diversos exemplos
interessantes
http://esprit.campus.luth.se/~humus
Site pessoal de Zaprjagaev Alexander. Seus últimos
exemplos usam GLSL
http://www.frustum.org
OpenGL Shading Language Designer
http://www.typhoonlabs.com
OpenGL Brasil
http://www.opengl.com.br
Como integrar os Shaders ao
OpenGL
A integração dos Shaders é simples e direta utilizando-se extensões do OpenGL.
Para isso você deve transformar seu Shader Source (código fonte do shader) em
um Shader Object. Então, compilar o
Shader Object. Feito isso, deve-se linkar o
Shader Object compilado ao Program Object que é obtido diretamente da própria
aplicação OpenGL. Na Listagem 2 mostro
um exemplo de como fazer isso tudo:
Conclusão
A GLSL se mostrou como uma linguagem eficiente, muito promissora e de
fácil integração a qualquer design existente. O grande problema dela hoje é o
fraco suporte que as grandes fabricantes de placa de vídeo oferecem. Apesar
dos drivers novos da Nvidia (série 60) e
da ATI (Catalyst 4.3) já oferecerem suporte a GLSL, não espere uma impletanção
completamente estável e livre de bugs.
Mas com a tendência de todos os games
do futuro de utilizarem os shaders para
efeitos especiais (como já fazem Doom3,
http://www.jogospro.com.br
Listagem 2: Exemplo de como integrar Shaders ao OpenGL
char * my_frag_shader_source;
char * my_vert_shader_source;
// Obtem o fonte do Vertex e Fragment Shaders
my_frag_shader_source = GetFragmentShaderSource();
my_vert_shader_source = GetVertexShaderSource();
GLenum my_program;
GLenum my_vertex_shader;
GLenum my_fragment_shader;
// Cria o Shader e Program Objects
my_program = glCreateProgramObjectARB();
my_vertex_shader = glCreateShaderObjectARB(GL_VERTEX_SHADER_ARB);
my_fragment_shader = glCreateShaderObjectARB(GL_FRAGMENT_SHADER_ARB);
// Carrega os Shader Sources para os objects
glShaderSourceARB(my_vertex_shader, 1, &my_vert_shader_source, NULL);
glShaderSourceARB(my_fragment_shader, 1, &my_frag_shader_source,
NULL);
// Compila os Shaders Object
glCompileShaderARB(my_vertex_shader);
glCompileShaderARB(my_fragment_shader);
// Linka os Shader Objects ao Program Object
glAttachObjectARB(my_program, my_vertex_shader);
glAttachObjectARB(my_program, my_fragment_shader);
// Linka o Program Object
glLinkProgramARB(my_program);
// Usa o Program Object
glUseProgramObjectARB(my_program);
S ET E M B R O 2 0 0 4
J O G O S P R O e-magazine
por Daniel “NeoStrider”Monteiro
S
A R T I G O S
Iniciando no SDL
DL. Você já deve ter ouvido falar em algum lugar essas três letrinhas juntas.
Talvez tenha sido em algum jogo de Linux...Ou foi em um emulador (mesmo
em Windows).Não foi em uma port de alguma aplicação antiga? A probabilidade de algumas dessas perguntas ser verdadeira é muito grande. A SDL está
por todo o canto. Mas o que é a SDL além daquela DLL que você precisa ter?
O que você precisa para entender de SDL?
Tudo que se precisa para a compreensão deste artigo é uma noção de
programação concorrente e alguma
noção no conceito de plataforma.
O que é a SDL?
SDL significa Simple Directmedia
Layer. Mas o que exatamente significa isso? O fato de ser uma camada
de acesso à Mídia Direta (Simple
Directmedia Layer) significa que
ela atua como uma camada de software, simplificando nosso trabalho
na produção de conteúdo multimídia. Como ela é Simples, não podemos esperar tudo pronto dela, pois
isso seria de fato um entrave nas
tarefas de tradução de aplicações
multimídia de outras plataformas.
A filosofia simples permite que adicionemos módulos ao nosso gosto.
Como funciona essa camada?
Ela filtra o que é relevante para a
produção de mídia do que é padrão para a inicialização de uma
aplicação na plataforma alvo. Para
ficar mais fácil imaginar, pense
numa aplicação para windows:
Dentre muitas inicializações necessárias, é possível escolher muitos
tipos de aplicações que o windows
suporta. Mas pense em aplicações
que usam janelas. Elas, no mínimo,
compartilham de algum código
de inicialização. Como o que desejamos são aplicações simples
multimídia, usando acesso dire-
http://www.jogospro.com.br
Figura 1: Imagens da Cube Engine,
desenvolvida com o SDL e OpenGL.
to, todas as nossas aplicações serão focadas na saída em forma
de mídia e na entrada do usuário.
Foco na saída de mídia é algo constante para a SDL. Por pensar em acesso direto à tela cheia e não em janelas múltiplas, é fácil pensar que todas
as aplicações candidatas a serem
feitas em SDL teriam uma inicialização parecida se feitas em Windows.
Por fim, esta camada tem uma terceira função: ela funciona de forma multi-plataforma. Sim, se você quer que
seu programa Windows rode em Li-
nux, por exemplo, e não quer alterar
seu código quase nada ou até mesmo sem altera-lo, a SDL permite isso.
Basta seu programa ser feito usando apenas componentes comuns.
Como é um programa SDL
A SDL trabalha em sistemas operacionais multitarefa, portanto
ela precisa responder a eventos
do seu ambiente de execução.
Normalmente os programas em
SDL envolvem três ou quatro partes:
Daniel Monteiro é aluno da Universidade Federal Fluminense e programador de
jogos indie nas horas vagas.Enquanto não esta envolvido com desenvolvimento
para móbiles (Symbian C++ em Series 60 1.0) e SDL ele gasta seu tempo em diversas
atividades, que vão de jogar Xwing vs Tie-Fighter (como imperial , lógico) a pesquisar
sobre música.
S ET E M B R O 2 0 0 4
J O G O S P R O e-magazine
A R T I G O S
Inicialização:
Tipicamente contém SDL_Init() e inicialização de recursos
Tratamento de eventos:
Aqui é necessário tratar eventos do Sistema. A SDL já filtra o que é pertinente
a seu programa, então não é necessário
despachar o resto dos eventos.
Operações de dados internas:
Aqui se processa e exibe surfaces, se
envia dados de áudio para a SDL, etc.
Desinicialização:
Aqui dealocamos todos os recursos alocados e liberamos a SDL. Aqui não precisamos necessariamente terminar nosso
programa, mas após SDL_quit, não devemos mais usar nada de SDL.
A Inicialização
Na inicialização, usamos principalmente
Sdl_init para incializar os sub-sistemas
da SDL. Mas por que incializar módulos
separados?
SDL é uma API feita para funcionar em
diferentes variedades de plataformas e
para sistemas onde determinados recursos inexistem, esta é uma forma de evitar problemas nas adaptações.
A forma mais geral de incializar é incializar tudo com SDL_Init(SDL_INIT_
EVERYTHING). Vale lembrar que os subsistemas da SDL devem ser usados com
cuidado e usar SDL_INIT_EVERYTHING
não é uma boa solução para todos os casos.
Quanto a inicialização de recursos, o
mais comum é incializar surfaces, seja
carregando arquivos de imagens pronto,
quanto criando surfaces vazias na memória.Outros recursos interessantes são
áudio e operações de leitura de dados de
CDROM e armazenamento persistente
de forma independente de plataforma.
Tratamento de eventos
Este pedaço é mandatário para programas interativos, mas quando se trata de
um programa curto que realiza alguma
operação e finaliza, não é necessário tratar eventos.
O tratamento de eventos ocorre de forma independente de plataforma e não
usa uma função de callback para tratamento geral (como é comum se acredihttp://www.jogospro.com.br
tar). Tudo pode ocorrer
em uma linha, se não
for desejo do criador
que seu programa trate eventos, mas que ao
menos despache para
o sistema os eventos
que não são de sua
pertinência. Em geral tudo é feito de um
switch(),que deve ser
chamado
explicitamente pelo programador, com o cases sendo
os tipos de evento.
Marathon - Jogo de MacOS refeito em SDL e rodando
Neste ponto é que norperfeitamente em Windows.
malmente se obtém a
entrada do usuário. Vale lembrar que os Ela merece descansar. Um problema
vários dispositivos de entrada possuem comum nos programas SDL em seu essua própria filosofia de informar intera- tágio inicial é o desleixo com esta parte
fundamental do programa. Por fim, sesção.
sões intermináveis de sucessivas execuções da aplicação – que aloca sem deOperações de dados internas
salocar recursos – resulta em memória
Agora acontece o processamento que a fragmentada e problemas na alocação
SDL tanto espera que o desenvolvedor de dados por parte de execuções de oufaça: a manipulação de dados e a ope- tras aplicações. Neste ponto, encerrar o
ração de saída de dados na forma mul- comprometimento com determinados
dispositivos pode ser importante para
timídia.
seu funcionamento. Negligenciar isto
Mais uma vez, como ocorre na entrada pode levar a resultados imprevisíveis.
de dados, cada dispositivo de saída tem
O que eu tenho com tudo isso?
sua forma de saída:
• O vídeo funciona por simples operações de surfaces, sendo que o resultado
deve ser copiado para uma surface que
representa a tela. Esta surface tem uma
série de funções de auxílio, da mesma
forma que as surfaces de memória tem
suas funções especificas, sendo que o
uso de funções de uso geral com a surface de tela pode gerar resultados imprevisíveis.
• O sistema de áudio funciona de forma
bem próxima ao que se pode esperar da
programação dos sistemas em modo
real. Devemos enviar dados continuamente para o dispositivo de áudio. Pelo
menos desta vez temos um toque de
modernidade, pois isso é realizado por
uma função de Callback. Assim, criamos
essa função e eliminamos nossos problemas.
Deinicialização
Neste ponto cabe a liberação de todos
os recursos alocados (surfaces, chunks
de áudio, etc) e a finalização da SDL.
Uma aplicação multimídia é feita de entrada e saída em diferentes formas de
mídia. O resumo acima acabou de mostrar uma pequena fração de tudo que
a SDL tem a oferecer ao desenvolvedor
sem medo. Arrisque-se a visitar www.libsdl.org para ver o que já foi feito, o que
esta se fazendo, o que esta para ser feito
e o que você pode ajudar a fazer.
Links
Site Oficial do SDL
http://www.libsdl.org
Site do Autor
http://www.makingthegame.tk
Diversos Artigos de SDL traduzidos
http://www.pdj.com.br
Cube Engine
http://www.cubengine.com
Marathon 2
http://marathon.bungie.org
Tutoriais de SDL + OpenGL
http://cone3d.gamedev.net
S ET E M B R O 2 0 0 4
J O G O S P R O e-magazine
por Wilson “WolveWilson” Jr.
A R T I G O S
2D .NET games: Usando GDI+ (Parte 1 de 3)
N
este artigo veremos como a GDI+, que é utilizada
para gráficos simples em .NET, pode ser utilizada
para a criação de jogos 2D de forma simples e funcional. Nesta primeira parte aprenderemos os conceitos; Na segunda parte passaremos para recursos
mais avançados; Na terceira e última, iremos partir
para a implementação de um jogo.
Introdução ao GDI+
O Windows contém muitas opções
de controles que são usados para
exibir informações. Como não é
impossivel cobrir todas as necessidades de todas as aplicações,
alguns programas não fazem uso
desses componentes ‘standard’.
Eles optam por criar seus próprios
gráficos, imagens , shapes (formas) e etc... Para atender a essas
necessidades, o desenvolvedor
tem
a sua disposição a
API chamada GDI+.
Antes de começar
‘sujar’ nossas mãos
com código, vamos
estudar as técnicas principais que
estaremos usando.
O namespace de
System.Drawing
contem todas as
classes que nos ajudarão realizar nosso
objetivo. Existe também o namespace mais avançado, o System.
Drawing.Drawing2D, este poderia
gerar um novo artigo inteiro, assim como as especializações System.Drawing.Printing especializado, System.Drawing.Text e System.
Drawing.Imaging, que fornecem
imprimir, tipografia e e suporte a
imagens. Estaremos falando sobre
eles e nossos próximos artigos.
Começando pelo System.Drawing,
vamos examinar as classes mais
importantes para nós. A classe
Graphics é fundamental aqui, e re-
http://www.jogospro.com.br
presenta um contexto de display
(exibição). Um contexto de display pode ser considerado como
um objeto genérico que fornece
alguns métodos para desenhar
shapes clássicos (linhas, curvas
etc..), texto, usando vários estilos
da linha (“pens”) e estilos da preenchimento (“fills”). Dessa forma
o programador não tem que se
preocupar com hardware e dispositivos de saída específicos. As
funções e a maneira
como são usadas
são as mesmas em
computadores com
hardware diferente.
Um
programador
não cría explicitamente objetos dos
gráficos usando o
operador new. Na
maioria das vezes, o
objeto é obtido indiretamente pelos
argumentos passados do sistema operacional à aplicação. Uma vez que
nós temos o objeto em nossas
mãos, é muito fácil extrair formas
usando seus métodos self-describing. Por exemplo, o método de
DrawImage() nos exibe uma imagem, enquanto que o DrawLine(),
o DrawRectangle(), o DrawCurve()
e o DrawArc() são usados criar formas básicas. Há algumas classes
no namespace de System.Drawing
que pode ser passadas como parâmetros a estes métodos. A classe
Pen é usada para especificar um
estilo da linha usado para desenhar a forma e a classe Brush especifica um estilo de preenchimento
para formas fechadas. Há algumas
classes úteis em especificar áreas
e posições na área do cliente (uma
área cliente é a parte da janela que
uma aplicação tem disponível, que
é a janela inteira menos a barra do
título, barras de menu/tool, status
e barras de scroll). Considerando
a posicao 0,0 do formulario o ponto mais alto e mais a esquerda, a
classe Point representa um único
pixel, cujas as coordenadas sejam
mantidas variáveis no membro de
X e de Y da classe. X é um inteiro
que represente a distância do pixel
da parte mais a esquerda da janela
do cliente, e Y está a uma distância
do ponto 0 (zero). Similarmente,
a classe Rectangle (retângulo) representa uma área retangular. Um
de seus construtores faz uso de
dois objetos do tipo Point (para a
parte superior a esquerda e a parte inferior a direita do retângulo).
Redesenhando Gráficos
Windows é um sistema operacional complexo. Compreender completamente como tudo trabalha
não é realmente uma tarefa trivial,
Wilson Junior. Formado em Informática pela PUC-RIO. Atua na área de informática a
mais de 10 anos. Trabalha como Analista de Negócios e tem como hobby a programação de jogos. Já programou em Basic, C, C++, Dbase II, Clipper, VB, Delphi,
Assembler, e atualmente, C#. Atualmente esta envolvido com o projeto Last Energy
um shoot’em up 3D.
S ET E M B R O 2 0 0 4
J O G O S P R O e-magazine
A R T I G O S
Listagem 1: Exemplo
mainform.cs
using System;
using System.Windows.Forms;
using System.Drawing;
namespace DefaultNamespace
{
/// <summary>
/// Description of MainForm.
/// </summary>
public class MainForm : System.Windows.Forms.Form
{
private System.ComponentModel.IContainer components;
private System.Windows.Forms.Timer timer1;
public int x,y=10;
public MainForm()
{
// The InitializeComponent() call is required for Windows Forms designer
support.
InitializeComponent();
}
[STAThread]
public static void Main(string[] args)
{
Application.Run(new MainForm());
}
#region Windows Forms Designer generated code
/// <summary>
/// This method is required for Windows Forms designer support.
/// Do not change the method contents inside the source code editor. The Forms de
/// signer might not be able to load this method if it was changed manually.
/// </summary>
private void InitializeComponent() {
this.components = new System.ComponentModel.Container();
this.timer1 = new System.Windows.Forms.Timer(this.components);
// timer1
this.timer1.Enabled = true;
this.timer1.Interval = 150;
this.timer1.Tick += new System.EventHandler(this.Timer1Tick);
// MainForm
this.AutoScaleBaseSize = new System.Drawing.Size(5, 13);
this.ClientSize = new System.Drawing.Size(292, 266);
this.Name = “MainForm”;
this.Text = “MainForm”;
}
#endregion
void Timer1Tick(object sender, System.EventArgs e)
{
x =x + 5;
y =y + 5;
Invalidate(); //Força o repaint em toda a janela, tb pode ser passada a área
especifica de refresh por parametro
if ((x > 200) & (y > 200))
Application.Exit();
}
protected override void OnPaint(PaintEventArgs e)
{
Graphics dc = e.Graphics;
Font fnt1 = new Font(“Tahoma”,30,FontStyle.Bold);
dc.DrawString(“teste”, fnt1, Brushes.Black, x,y);
}
}
base.OnPaint(e);
}
http://www.jogospro.com.br
S ET E M B R O 2 0 0 4
J O G O S P R O e-magazine
A R T I G O S
e operações aparentemente simples requerem muito trabalho do
computador. Uma destas tarefas
“simples” é a seguinte: Imagine
que um usuário está executando
dois programas simultaneamente, cada em sua janela separada.
O primeiro programa esta exibindo a agenda do dia, e o segundo
é um browser internet, exibindo
algum Web site. De repente, o
usuário move seu browser sobre
uma parte do primeiro programa.
Eficazmente, essa parte da janela
do primeiro programa desapareceu, porque uma outra janela esta
sobe ela. Naturalmente, nós temos o sentimento que a informação armazenada lá não é perdida
realmente - as janelas devem ter
uma maneira redesenhar o que
quer que estava lá. E isso é verdadeiro. Se nós movermos, afastando da primeira janela, nosso browser outra vez, a parte do primeiro
programa que estava ‘escondida’
se torna visível outra vez. O que
está acontecendo realmente?
A parte que apareceu não foi recuperada outra vez diretamente para
a memória. Seria um desperdício
de recursos se o sistema operacional armazenasse a exposição do
video de cada programa na memória - imagine que nós podemos ter
muitas janelas, uma no alto do outra. De fato, Windows diz somente
a aplicação , no nosso caso a primeira, que ela tem que redesenhar
uma parte dela, em exibição, por
causa de um evento especial (no
nosso caso, o mover de uma outra janela), após isso, a aplicação é
responsável pelo que acontece. A
ação mais comum para a aplicação
é, naturalmente, a de redesenhar
essa área específica da janela.
Windows realiza isso emitindo
eventos especiais a cada aplicação.
É a forma do sistema operacional
de “dizer” aos programas de que
algo aconteceu no computador
de forma que a aplicação possa
executar uma função apropriada.
Os eventos fundamentais incluem
cliques do mouse e pressionamento de teclas - existem muitos
outros eventos emitidos mas em
http://www.jogospro.com.br
Figura: Saída do programa da Listagem 1.
nosso caso, nosso interesse esta
nos eventos chamados de Paint
(Pintura). O Windows emite-os automaticamente a todos os programas que necessitam redesenhar
alguma parte de sua interface do
usuário. Em nosso exemplo acima,
assim que nós movêssemos a janela de browser para trás para seu
lugar original, Windows emitiria ao
primeiro programa, um evento de
Paint. É como se ele estivesse “dizendo” a esse programa que algo
aconteceu e necessita redesenhar
uma parte específica de sua janela. A informação de que a parte
necessita redesenhar seria passada também junto com o evento. Felizmente, esta mensagem
que emite e que redesenha é ‘recebida’ automaticamente pelos
controles standard. Realmente,
a classe Form (formulário) tem
um método chamado OnPaint
(que é subscrita ,overridden, da
classe do Control), que assegura o ‘redesenhar’ automático.
nosso
programa
necessitará, provavelmente, atualizar
seus gráficos não
somente quando
uma outra janela se
move no alto dela,
mas quando se minimiza e maximiza outra vez. Isto
é, nós emitiremos
uma
mensagem
ao nosso programa que o diga para
redesenhar a parte
(ou os todos) seus
gráficos. A maneira que nós dizemos
ao nosso programa
para repintar seus
gráficos é o método Invalidate().
Nós o encontramos na classe Control, e naturalmente na classe do
Form, que a herda. Este método
pode ser chamado sem nenhum
parâmetro, e neste caso ele redesenhará toda a área do cliente. Mas
atualizar partes grandes da exposição de gráficos em intervalos
curtos consome muitos recursos.
Na maioria de casos, nós devemos
chamar o método que especificamos somente para área onde os
gráficos atualizados devem aparecer. Geralmente essa área (suas
dimensões) é passada como um
objeto Rectangle (retângulo).
Fim da Parte I
Toda a conveniencia de gerencia
dos gráficos fornecida pelo Windows, acaba quando chega na GDI+.
Windows não mais atualizara automaticamente as partes da janela
da aplicação que têm formas desenhadas nelas pela GDI+. Neste
caso, nós teremos que subscrever
(override) o método OnPaint, que
nós mencionamos antes, e especificamos exatamente como o ‘redesenhar’ ocorrerá. Naturalmente,
S ET E M B R O 2 0 0 4
J O G O S P R O e-magazine
por Matías G. Rodriguez
P o s t M o r t e m
Postmortem do Harena
“Harena é um jogo de luta 3D multiplayer com perspectivas nunca antes vistas neste
gênero. Explorando a competitividade cada jogador tentará ser o melhor gladiador
em vários tipos de arena, além de buscar o reconhecimento dentro da comunidade
da Harena.” -- http://www.harena.com.br
O Harena é um demo desenvolvido por
alunos da primeira turma de Pós Graduação em Desenvolvimento de Jogos da Unicenp. A Pós Graduação teve duração de um
pouco mais de um ano com aulas aos sábados. O projeto foi entregue com atraso de
vários meses, por uma equipe de 5 pessoas
que nunca tinham desenvolvido um demo
muito menos um jogo completo. A seguir
vamos ver algumas coisas que deram certo
e outras que deram errado ao longo do desenvolvimento.
1. O que deu certo.
Reuniões Periódicas: Ao contrário de
outras equipes da Pós, todos os integrantes da equipe moravam em Curitiba. Isto
facilitava as reuniões que eram feitas uma
vez por semana geralmente às
quintas-feiras. Tinha bastante
pipoca, refrigerante e chocolate.
Passavamos horas discutindo
partes do jogo como game design, arquitetura de rede para o
multiplayer, renderizador, algoritmos, as matérias da Pós, entre
outros assuntos. As reuniões
fizeram com que a equipe se
mantivesse unida mesmo depois do término das aulas.
Wiki: Logo no começo do projeto criamos um Wiki para colocar
nossas idéias, criar atas das
reuniões, colocar arquivos referentes ao projeto, receber idéias
dos amigos, etc. Ele foi bastante
utilizado, mas mais para o final
do projeto, caiu em desuso pois
a medida que a empolgação foi
diminuindo, o fato de ter que
manté-lo era uma atividade
tediosa. Para quem não sabe
o que é um wiki: http://www.
c2.com/cgi/wiki?WikiWikiWeb
CVS: Bem antes de ter programado uma linha de código, já tinhamos disponível um repositorio CVS onde
todos os integrantes da equipe podiam
compartilhar os recursos (código fonte,
imagens, modelos, etc) do projeto. Isto fez
com que o desenvolvimento fosse um pouco mais profissional e menos amador.
Artista na Equipe: Originalmente a equipe
era composta por 4 programadores, mas
http://www.jogospro.com.br
tomando uma decisão estratégica, decidimos “roubar” um integrante com conhecimento de modelagem 3d de outra equipe.
A outra equipe reclama até hoje.
Esforço Final: Faltando 2 semanas para
a data de entrega ainda não tinhamos o
demo jogável. Se continuassemos trabalhando no esquema de só nas horas vagas
não conseguiriamos terminar. Por isso decidimos pedir férias do serviço, das esposas
e namoradas com o argumento de que
finalmente íriamos terminar e ter mais tempo para elas. Assim começamos a trabalhar
num ritmo bem mais acelerado, principalmente na última semana. Foi neste período
que desenvolvemos o networking, suporte
às animações, suporte a som/música e a
lógica do jogo em sí.
vezes tentamos montar um cronograma
realista do desenvolvimento mas falhamos
todas as vezes. O motivo principal foi que
nenhum dos integrantes conseguia mensurar o tempo que ia conseguir trabalhar
no projeto a cada semana. Desenvolvendo
“nas horas vagas” é muito difícil de chegar a
alguma conclusão.
Reuniões Periodicas: Apesar disto ter sido
algo que deu certo, chegou uma hora que
as reuniões eram mais um encontro “social”
do que uma reunião para desenvolver um
demo. Antes da pipoca acabar não se discutia nada relamente relevante ao projeto.
Então decidimos cancelar as reuniões para
usar esse tempo para realmente codificar
algo.
Figura 01 - Demo Harena: Visão geral da Ópera de Arame de Curitiba.
2. O que deu errado.
Outros Trabalhos da Pós: O desenvolvimento do demo foi prejudicado pois tinhamos que parar de trabalhar nele para poder
entregar trabalhos das diversas matérias da
Pós. Geralmente esses trabalhos não estavam relacionados ao demo.
Falta de um Cronograma Realista: Várias
Artistas: Logo no começo, fizemos a divulgação do Harena em várias listas procurando artistas interessados em participar do
projeto. Várias pessoas ficaram interessadas. Ao longo do projeto devemos ter falado com 5 artistas (entre modeladores 3d e
desenhistas) os quais se comprometeram a
participar mas, se algum deles durou mais
de 3 semanas foi muito. A única exceção
S ET E M B R O 2 0 0 4
J O G O S P R O e-magazine
P o s t M o r t e m
Figura 02 - Demo Harena: Oito jogadores lutando dentro da Ópera de Arame de Curitiba.
foi quem fez a arte conceitual de alguns
dos personagens do jogo, ele já tinha experiência (fazia desenhos para a revista da
Nintendo no Chile).
Falta de Experiência da Equipe: A equipe
não tinha nenhuma experiência em jogos.
Mas isto era aceitável, pois essa era mesmo
a idéia do projeto final da Pós (o demo):
ganhar experiência.
3. O dia da Entrega.
É um dia que vai ser lembrado por toda a
equipe, foi o fim de um projeto de mais de
dois anos. Finalmente chegara a hora do
tudo ou nada, a tensão era grande. Trinta
minutos antes da entrega oficial ainda estavamos tentando tirar bugs do networking
e o renderizador. Quinze minutos antes decidimos deixar como estava, compilar pela
última vez, pegar nossos computadores,
hub, cabos de rede, monitores (inclusive
um de 21 polegadas) e ir para a Unicenp.
Chegando lá, levamos aproximadamente
meia hora para montar nossa LAN formada
por 4 computadores. Um para rodar o servidor dedicado e 3 clientes. O encarregado
de avaliar nosso projeto era o coordenador
do curso. Por incrível que pareça nada deu
errado pois geralmente é nas apresentações que os bugs aparecem. Mas não
neste caso, tudo funcionou, inclusive as
coisas que a gente sabia que causavam
bugs, quando o coordenador as fez, milagrosamente, funcionaram sem problemas.
Ele gostou muito do projeto e nos deu
parabéns seguido da nota máxima. Por um
http://www.jogospro.com.br
momento, sentimos que éramos “os reis do
mundo”, capazes de fazer qualquer coisa,
eramos capazes de desenvolver jogos. É
algo realmente difícil de descrever.
4. Conclusão.
O Harena foi um demo desenvolvido por
uma equipe de pessoas inexperientes que
optaram por usar os seus sábados e tempo
livre para tentar aprender um pouco de
desenvolvimento de jogos na pratica e
apostar num mercado incerto e complicado. Tudo indicava que a equipe não conseguiria terminar o projeto. Mas contra todas
as previsões eles provaram que com força
de vontade, determinação e muito trabalho
é possível encarar o desafio de desenvolver
um demo de jogo e alcançar o sucesso
esperado.
Matías Gonzalo Rodriguez é formado pela
Unicenp em Desenvolvimento de Jogos. Entusiasta das linguagens C/C++, Java e Smalltalk. Gosta de jogar e desenvolver Jogos em
suas horas vagas.
Figura 03 - Da esquerda para a Direita: Marcelo Walter, Eduardo
Akatsu, Matías Rodriguez, Bohdan Metchko Jr, Uriel Segall
S ET E M B R O 2 0 0 4
J O G O S P R O e-magazine
Fim do Jogo
por Carlos Caimi
E o Futuro é logo ali
P
rever o futuro é algo fascinante.
Ninguém acerta, mas volta e meia
a gente encontra algum louco
tentando prever o que vai acontecer daqui
há alguns anos. Cada coisa maluca. Lembro
de uma, da década de 70: uma família sentada a mesa, e vinha uma bandeja, apoiada
num tremzinho que andava sobre trilhos,
com a refeição a ser servida. Uma clássica
adaptação do ferrorama!!!.
Mas como, de desenvolvedor de jogos
e de louco todo mundo tem um pouco,
vou arriscar o que me resta de sanidade e,
tentar expor as tendências que a evolução
dos jogos poderá seguir nos próximos
anos. Para evitar erros grotescos, e que
algum outro maluco tire sarro deste
artigo, vou me basear na evolução de algo
intimamente ligado a jogos. A tecnologia.
Mas minha bola de cristal se baseia em apenas duas regras que servirão de alicerces
para essa extrapolação.
A primeira, e mais famosa, é a Lei de Moore.
Ela nos diz que computadores dobram de
processamento a cada 18 meses.
A segunda, menos conhecida, é que uma
nova tecnologia leva aproximadamente 20
anos para se popularizar. Exemplo clássico
é a Internet. Iniciou em 1969 e em 1999 já
era de domínio público.
Mas afinal, em que parte do futuro queremos olhar 10, 50 ou 100 anos? Todo mundo
já ouviu falar que a tecnologia avança de
maneira exponencial. Mas quase ninguém
houve falar que o pensamento humano
progride linearmente. E é exatamente por
isso que não conseguimos prever com
precisão o que a tecnologia nos reserva.
Em curtos períodos é possível uma aproximação com grandes possibilidades de
acerto, mas quanto mais adiante olharmos,
mais nebuloso fica, logo não nos interessa
na prática. Por isso vou estabelecer como
meta o ano de 2020.
Fato 1: Os processadores poderão ser fabricados com a tecnologia atual, com leves
alterações, até aproximadamente 2020.
Então até lá, não teremos Computadores
Quanticos, nem genéticos, nem Óticos, ou
qualquer outro. A era do silício, a trancos e
barrancos, chegará a 2020.
Previsão: Essa é fácil. Tudo que depende
de processamento em jogos sempre terão
melhorias significativas. Veremos gráficos
cada vez mais bonitos, a física cada vez
mais realista e inteligência artificial cada
vez mais parecida com a inteligência humana.
Fato 2: O nome do bicho é Computação
Onipresente. Esse conceito que esta em
franca expansão é o aperfeiçoamento e
http://www.jogospro.com.br
massificação dos chips de computadores.
Na verdade já estamos vivendo nesse mundo. Ou seja, estaremos conectado com o
mundo virtual praticamente em qualquer
lugar, em qualquer hora, em qualquer situação. Em casa, no trabalho, no carro, no
celular, na roupa, no óculos, em breve na
televisão (televisão digital no Brasil) sem
realmente tomar consciência disso.
Previsão: a) Jogos multiplayer acontecerão
em qualquer lugar e em qualquer hora.
Computadores jogando com consoles, jogando com celulares, jogando com PDA´s,
etc... b) Você não estará preso a um único
dispositivo para jogar. Poderá começar no
PC, continuar no Console, e terminá-lo, utilizando seus óculos com mini-telas, a caminho da lanhouse, porque afinal, é sempre
bom relembrar os velhos tempos.
Fato 3: A tecnologia já existe, mas faltava
uma utilização para ela. Com processadores mais velozes sobrará mais tempo para
um reconhecimento de voz mais preciso.
E cada vez mais teremos jogos sendo comandados, além do teclado, mouse e joystick, também por microfones.
Previsão: O reconhecimento de voz será
a próxima evolução na jogabilidade dos
jogos do futuro. E juntamente com uma IA
mais avançada, ele alavancará uma nova
maneira de jogar, e arrisco a dizer, até um
novo estilo de jogo. Isso vai chegar muito
antes que tenhamos computadores com
percepção extra-sensorial.
force-feedbacks. Sem contar capacetes que
reconhecem para onde você esta olhando.
Previsão: A jogabilidade irá mudar muito
até 2020. Imagine-se coberto com toda
essa parafernália e jogando um jogo de
ação. Essas novas interfaces só precisam de
tempo para se estabelecer e cair no gosto
dos jogadores.
Poderíamos extrapolar, e muito, essa conversa sobre o futuro dos jogos. Mas resolvi
me contentar em apenas identificar as
tendências tecnológicas que estaremos
presenciando nos próximos anos. Pelo
menos até o final previsível da era do silício.
Depois de 2020 estaremos vivenciando
uma nova era na informática. Um novo
tipo de computador, os óticos são fortes
candidados. Capacidades surpreendentes
de armazenamento, com novas memórias
holográficas. Internet super rápida e a computação onipresente, todos eles abrem
inúmeras possibilidades de imaginarmos
os mais variados tipos de jogos. Mas, como
sei que você já tá perguntando. E a Matrix,
onde fica nisso tudo. Bom talvez o século
22 chegue antes.
Esse artigo foi baseado no livro Visões do
Futuro (Visions), do físico Dr. Michio Kaku.
Leitura recomenda para todos aqueles que
curtem tecnologia.
Fato 4: O dinheiro, em meio físico, esta acabando. Dos 4 trilhões aproximados existentes circulando no mundo, apenas 10% dele
está em espécie.
Previsão: O jogo de caixinha vai acabar.
Com a internet mais rápida, e onipresente.
O jogos serão comprados e baixados digitamente. Usando dinheiro digital para um
mundo virtual. Essa previsão, na verdade,
é apenas mais uma conseqüência da Computação Onipresente. Resolvi incluir apenas
por que afetará nossa maneira de comprar
jogos.
Fato 5: Imersão. Esta palavrinha tão batida
por nós, desenvolvedores de jogos, também sofrerá grandes mudanças. Novos
dispositivos de interface homem-máquina
são lançados a cada dia no mercado. Hoje
já temos: Óculos com mini-telas de 52 polegadas, luvas para realidade virtual, já existem monitores holográficos e mouse com
Carlos H Caimi - defi[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.
S ET E M B R O 2 0 0 4
J O G O S P R O e-magazine
Expediente
E
xpediente
Editor-Chefe:
Carlos H. Caimi
Editor-Assistente:
Bruce “Sinner”
Diagramação:
Bruce “Sinner”
Carlos H. Caimi
Colaboradores:
Carlos H. Caimi
Bruce “Sinner”
Julio Marchi
Daniel Monteiro
Alessandro V. dos Reis
Paulo R C Siqueira
Wilson Jr.
Alexandre “DarkFenrir”
Matías G. Rodriguez
Webmaster:
Bruce “Sinner”
Agradecimentos:
Ao pessoal da lista JogosPRO
pelo surgimento da idé
idéia.
Fábio Binder
Ignis Games
Continuum
Southlogic
A todos que nos apoiaram e
não foram mencionados, vocês
sabem quem são!
Contato:
[email protected]