Untitled

Transcrição

Untitled

PONTIFÍCIA UNIVERSIDADE CATÓLICA DE SÃO PAULO
Programa de Pós-Graduação em Tecnologias da Inteligência e Design Digital
METAVERSOS E JOGOS DIGITAIS MULTIJOGADOR:
ASPECTOS HISTÓRICOS E METODOLÓGICOS DE UMA
ABORDAGEM DO CIBERESPAÇO
Dissertação de Mestrado
Pesquisador: Maigon Nacib Pontuschka
Orientador:
Prof. Dr. Luís Carlos Petry
São Paulo
2012
Capa:
Imagem conceitual do "Guild Hall" desenhada a lápis por Gil Keppler em
11 de novembro de 2000 para o Myst Online URU live - Cyan Worlds
(nunca implementada no metaverso).
METAVERSOS E JOGOS DIGITAIS MULTIJOGADOR:
ASPECTOS HISTÓRICOS E METODOLÓGICOS DE UMA
ABORDAGEM DO CIBERESPAÇO
DISSERTAÇÃO DE MESTRADO
Dissertação
apresentada
à
Banca
Examinadora da Pontifícia Universidade
Católica de São Paulo, como exigência
parcial para obtenção do título de MESTRE
em Tecnologias da Inteligência e Design
Digital – área de concentração “Processos
Cognitivos e Ambientes Digitais”, linha de
pesquisa “Design Digital e Inteligência
Coletiva” – sob a orientação do Prof.
Doutor Luís Carlos Petry.
São Paulo
Fevereiro de 2012
Banca Examinadora
________________________________________
________________________________________
________________________________________
AGRADECIMENTOS
Quero agradecer a Deus que trabalha de maneiras misteriosas e sempre
nos faz renascer das cinzas para um novo amanhã.
A minha esposa Rute por seu apoio incondicional, meus filhos Yannis e
Anna por sua paciência e compreensão no período crítico em que tive que
me recolher para escrever esta dissertação.
A meus pais Walter e Nídia que sempre desejaram que eu seguisse a
carreira acadêmica e estão curtindo comigo cada segundo desta nova
caminhada.
Ao meu irmão Maurício que me estimulou a entrar no mestrado em
Tecnologias da Inteligência e Design Digital, mudando radicalmente o
curso da minha vida.
A meu sogro e minha sogra Antonio e Margarida, que como verdadeiros
segundos pais, me esconderam e acolheram em sua casa nos últimos
dias frenéticos de elaboração desta dissertação para que eu pudesse
terminar o trabalho da melhor maneira e no tempo possível.
À minha grande família, meus tios, tias, primos e primas, que sempre me
estimulam tanto nos bons como nos maus momentos e que me dão
energia e incentivo para continuar a caminhar.
Ao meu orientador, Prof. Dr. Luís Carlos Petry que me contaminou com
seu amor pela vida acadêmica e pelas coisas boas da vida.
Aos amigos e colegas do curso de Pós-Graduação em Tecnologias da
Inteligência e Design Digital que me deixaram lembranças de aulas,
discussões e descobertas memoráveis.
Aos membros da banca, Profa. Dra. Arlete Petry e Prof. Dr. Rogério
Cardoso dos Santos que com seus comentários valiosos durante o exame
de qualificação trouxeram um caminho mais rico para minha pesquisa.
Aos membros da equipe do Projeto Pirarucu-Gente, em especial seu
idealizador, o Prof. Dr. Josenildo Silva.
Aos amigos e colegas do Departamento de Engenharia de Pesca e
Aquicultura da Universidade Federal de Rondônia.
RESUMO
A
presente
dissertação
pesquisa
os
metaversos
e
jogos
digitais
multijogador, tema profundamente associado a um mundo digital cada vez
mais participativo, colaborativo e, fundamentalmente, massivo. Ela identifica
os elementos e as características nucleares que permitem a delimitação dos
metaversos e jogos digitais enquanto área de pesquisa, as suas aplicações e
os aspectos vinculados com a técnica de desenvolvimento pragmática.
Organiza um panorama temático, analisando sua estrutura derivada da
recente
história
dos
jogos
digitais,
das
pesquisas
estatísticas
e,
particularmente, dos desenvolvimentos que resultaram nas abordagens
multijogador. Propõe uma classificação com base em suas propriedades
ontológico pragmáticas constituintes. Aplica a classificação resultante
organizando-a em uma abordagem que mostra a relação entre as pesquisas
acadêmicas, as desenvolvidas por produtores independentes, bem como as
das empresas produtoras de motores de jogos e metaversos. Com os
resultados da classificação dos metaversos e jogos digitais resultantes,
apresenta uma descrição e análise de exemplos modelares, enfatizando
suas
características
desenvolvimento
e
histórico
suas
evolutivas,
aplicações
seu
práticas.
escopo
Reúne
um
técnico
de
corpus de
informações que mostra um panorama da pesquisa atual e que indica
caminhos
para
uma
possível
metodologia
de
avaliação
de
uso
e
desenvolvimento dos metaversos e jogos digitais. Culmina na avaliação do
conceito
de
game
acadêmico,
na
perspectiva
da
formulação
das
especificações para o desenvolvimento de um metaverso acadêmico
intitulado Pirarucu-Gente.
Palavras-chave:
metaversos,
ciberespaço, multijogador.
games,
metodologia,
ontologia,
ABSTRACT
This dissertation studies metaverses and multiplayer digital games, a theme
that is deeply associated with an increasingly participatory, collaborative and
fundamentally massive digital world. It identifies the elements and core
characteristics that allow the delimitation of metaverses and multiplayer
digital games as a field of research, its applications and the aspects
associated with pragmatic development techniques. It organizes and
analyzes a thematic overview whose structure stems from the recent history
of digital games, from statistical research and, particularly, from the
developments that resulted in the multiplayer approaches. It proposes a
classification based on constituent ontological pragmatical properties. It
applies the resulting classification into organizing an approach that shows
the relationship between academic research, research developed by
independent game producers, as well as companies producing game
engines and metaverses. With the resulting classification of the metaverses
and digital games, it presents a description and an analysis of model
examples, emphasizing their evolutionary history characteristics, their
technical
development
scope
and
their
practical
applications.
The
dissertation brings together a body of information that shows an overview
of current research and leads the way to a possible methodology for
evaluating the use and development of metaverses and digital games. It
culminates in the evaluation of the concept of academic game, with a view
to drawing up specifications for the development of an academic metaverse
entitled Pirarucu-Gente.
Key-words: metaverses, games, methodology, onthology, cyberspace,
multiplayer.
SUMÁRIO
Introdução .................................................................................................. 1
Apresentação ........................................................................................... 1
Capítulo 1: Uma introdução aos Metaversos ................................................ 9
A origem dos conceitos de ciberespaço e metaverso .............................. 18
Aportes do conceito de metaverso derivados da literatura científica
internacional .......................................................................................... 19
Conceituando Mundos Virtuais, Metaversos e Protometaversos .............. 22
Uma arqueologia da questão dos metaversos ......................................... 25
Uma perspectiva ontológica do conceito de metaverso ........................... 28
Panorama histórico: jogos multijogador e jogos multijogador em rede ... 39
1. A distinção entre “Games em Rede” e “Games Multijogador” ............... 39
2. Os primeiros jogos multijogador ........................................................ 41
Tennis for two: O primeiro jogo eletrônico multijogador ...................... 41
Spacewar: O primeiro jogo multiusuário por computador .................... 43
O Sistema PLATO - os primeiros jogos multijogador via mainframe ..... 43
Adventure e Zork: games precurssores dos MUDs ............................... 46
Os MUDs – Multiple User Dungeons ou Multiple user Domains............. 49
Arcade Games ou jogos multijogador de fliperama .............................. 51
Jogos Online Hospedados em servidor ................................................. 54
Jogos Multijogador em Rede ................................................................ 54
3. Os precursores dos metaversos .......................................................... 55
Doom – a chegada dos primeiros FPS em rede ..................................... 55
SimCity ................................................................................................ 57
A série Zork em aventuras gráficas ...................................................... 63
Myst .................................................................................................... 67
4. Metaversos ......................................................................................... 73
MMOs e suas subcategorias ................................................................. 73
Algumas estatísticas sobre os metaversos e mundos virtuais ............... 78
Capítulo 2: Implantando o componente multijogador em metaversos ...... 89
Arquiteturas e modelos de comunicação nos jogos multijogador em rede
.............................................................................................................. 89
O Modelo OSI ...................................................................................... 91
Modelos de conexão ............................................................................ 97
Montando uma rede multijogador no Unity para a criação de metaversos.
............................................................................................................ 100
Técnicas de M. Hergaarden (Leepo) para instalação de componente
multijogador em rede no UNITY ......................................................... 101
Exemplos de scripts de Hergaarden para sistemas multijogador ........ 123
O Photon e as técnicas da Exit Games para montar uma rede
multijogador com Unity 3D ................................................................ 133
Exemplos de funcionamento do Photon com Unity3D ........................ 142
Capítulo 3: Proposta de continuidade na criação conceitual e montagem do
Metaverso Pirarucu-Gente ....................................................................... 153
A experiência do Game Acadêmico Ilha Cabu ........................................ 154
Utilização de uma taxonomia dos processos de produção e de avaliação
de hipermídias................................................................................... 155
O processo inicial de concepção do jogo ........................................... 156
Puzzles como recompensas ............................................................... 159
Manter um bom grau de imersão ....................................................... 160
O Método de trabalho e registro de atividades ................................... 161
Documento de Design ....................................................................... 161
O Método de Programação ................................................................. 162
Técnicas da Aquiris no desenvolvimento do Bootcamp FPS Demo para o
Unity 3 ................................................................................................. 164
Palhetas de cores ............................................................................... 166
Colecionar referências ....................................................................... 167
Planejando espaços ........................................................................... 169
Regras de composição ....................................................................... 169
Ilusão do inalcançável ........................................................................ 171
Modelagem........................................................................................ 173
Escala das texturas ............................................................................ 173
Vegetação realista ............................................................................. 174
Iluminação ......................................................................................... 175
Um olhar sobre a metodologia da pesquisa-ação ................................. 177
A criação do metaverso dentro de um contexto colaborativo e reflexivo180
Game Design Document do Metaverso Pirarucu-Gente ......................... 182
Histórico do Projeto ........................................................................... 183
Visão Geral do Metaverso .................................................................. 185
Características ................................................................................... 187
O Mundo do jogo .............................................................................. 190
Considerações finais e Conclusões .......................................................... 199
Referências ............................................................................................. 207
Índice de figuras ..................................................................................... 214
Índice remissivo ...................................................................................... 219
Anexos.................................................................................................... 225
Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 1
INTRODUÇÃO
APRESENTAÇÃO
I
negavelmente a Internet revolucionou a maneira como vivemos, como
agimos e pensamos. Como diz Sherry Turkle a Internet e o ciberespaço
criaram uma cultura da simulação que está “afetando nossas ideias sobre
a mente, o corpo, o eu e a máquina” (TURKLE, 1999, p.16). Hoje, na
sociedade ocidental, não conseguimos mais nos ver sem o uso da Internet,
do e-mail, das redes sociais e de tantos outros serviços que a web
proporciona. O ciberespaço tornou-se parte integrante do nosso cotidiano e
nós o modificamos e somos modificados por ele. Nos países desenvolvidos
e nos grandes centros urbanos brasileiros o desenvolvimento dos recursos
computacionais revolucionou completamente a maneira de trabalhar, de
fazer negócios e até mesmo os relacionamentos pessoais e afetivos entre as
pessoas.
Ao mesmo tempo, o desenvolvimento computacional das tecnologias 3D 1
permitiu que milhões de pessoas, mesmo nos lugares mais longínquos,
tivessem acesso a consoles como o Playstation 2 e 3, o Wii e o Xbox 360 e
experimentassem jogos eletrônicos que simulam na tela a física do espaço
real, criando mundos virtuais bastante críveis. Estes milhões de usuários
encontram nos games uma forma de lazer e entretenimento importante e
isto tem chamado a atenção de governos e da indústria por conta dos
números e das altas somas de dinheiro envolvidas. O próprio Governo
Federal Brasileiro reconheceu isto ao lançar, por meio da FINEP, edital para o
financiamento de projetos de jogos eletrônicos relacionados a conteúdos
educacionais, aberto a instituições universitárias federais, estaduais e
comunitárias. O gigantesco interesse despertado pelos jogos eletrônicos
acabou elevando uma categoria até então considerada menor pelas
universidades ao patamar de disciplina de estudo acadêmico: os games.
1
Ao falarmos tecnologia 3D não nos referimos à tecnologia estereoscópica de
simulação de visão tridimensional utilizada nas novas televisões 3D, mas à
tecnologia baseada em vetores que recria em 2D a sensação do espaço físico real.
2
Os desdobramentos do uso da internet e do desenvolvimento computacional
das tecnologias 3D possibilitaram a criação de uma categoria especial de
games, os MMOs (massive multiplayer online games). São os chamados
“metaversos”, cujo exemplo mais conhecido é o Second Life (2011). A
palavra metaverso vem da ficção científica, tomada de empréstimo do
romance de Neal Stephenson, Snow Crash (Stephenson 1994), no qual havia
um mundo virtual ficcional que simulava a vida real dentro de um espaço
virtual na Internet. Sua etimologia vem de “meta” – além e “verso” – universo,
portanto é tudo o que está além do universo real.
Com o advento dos metaversos temos a possibilidade de participar e
conviver em ambientes virtuais 3D, interagir com objetos, “non-player
characters” e avatares 2 de outros humanos. Os metaversos colocam-se
como verdadeiros mundos paralelos ao real, onde existe uma interação
entre indivíduos reais por meio de seus avatares.
Atualmente,
a
maioria
dos
metaversos
proporcionam
experiências
estruturadas nas áreas de entretenimento, redes sociais e negócios. Estes
são alguns dos motivos pelos quais grande parte da literatura atual enfoca a
questão dos metaversos na perspectiva de suas potencialidades para o
entretenimento e negócios.
Uma outra possibilidade reside em considerarmos os metaversos sob outro
ponto de vista, perguntando-nos se eles não poderiam também constituirse em objetos e ambientes para a produção e transmissão de conhecimento,
strictu et lato sensu.
Quando se pensa em “produção de conhecimento”, uma das inúmeras
possibilidades a serem consideradas consiste na utilização dos metaversos
dentro de processos de pesquisa acadêmica, associados à criação de
conteúdos novos em áreas do conhecimento científico, associados às
comunidades de pesquisadores e usuários. Um trabalho interessante nesta
direção pode ser o de Schlemmer e Backes (2008), no qual as autoras
afirmam que os metaversos constituem-se em novos espaços para a
construção de conhecimento, discutindo suas aplicações para o campo
pedagógico e, principalmente, para as estratégias da educação a distância.
As autoras também afirmam que apesar de ser um mundo paralelo ao real,
2
Avatares são as representações gráficas virtuais dos humanos que estão online
em um game multiusuário.
ele tem utilidade concreta, pois trata-se de uma ampliação do espaço real
onde os
sujeitos
continuam
relacionando-se, trocando
informações,
modificando e sendo modificados via seus avatares.
Para além do genuíno enfoque colocado pelas autoras, talvez possamos
pensar igualmente a participação dos metaversos em outras áreas como,
por exemplo, a da pesquisa acadêmica. Neste sentido, o verdadeiro
potencial dos games, em especial dos metaversos, ainda mal foi tocado.
No Brasil, por conta das constantes políticas de democratização do uso da
internet e da ampliação do acesso via banda larga em todo o país, locais e
pessoas que nunca haviam usado computadores estão experimentando
verdadeiras revoluções por conta da expansão do acesso à internet, seja via
computador, seja por dispositivos móveis. Por outro lado, apesar dos
esforços do governo e de diversas ONGs que querem ver o acesso à internet
disseminado por todas as classes sociais no Brasil, esta ainda não é uma
realidade para todos e requer especial atenção.
Ainda se fazem necessários investimentos em infraestrutura para uma
banda larga de qualidade para que os locais mais distantes do país possam
experimentar esta revolução que já acontece nos locais em que a
infraestrutura já está bem estabelecida. No mais, novas formas e atitudes
frente à utilização da internet e dos games são necessárias para que um
salto de qualidade possa acontecer.
O presente trabalho surgiu por ocasião dos estudos para o desenvolvimento
de um projeto que pretende utilizar um metaverso em um projeto
colaborativo que se serve da metodologia da pesquisa-ação participativa, o
Projeto Pirarucu-Gente. Trata-se de um projeto de pesquisa e extensão
junto à comunidade para a construção de conhecimento com fins de
inclusão social e digital. A proposta é transformar o metaverso em um
espaço de discussão e treinamento real, e também criar um acervo que
constitua uma espécie de biblioteca virtual 3D sobre uma variedade de
assuntos relacionados a uma área específica de conhecimento, já que é
possível manter textos e vídeos online nestes ambientes.
Desde o início a nossa intenção é sistematizar o processo de criação do
metaverso, tornando-o inteligível mesmo a pessoas que não sejam ligadas à
área de informática ou games, isto para que possam participar e ajudar a
criar um metaverso significativo e que ajude a modificar sua realidade. A
ideia é fazer uma espécie de “roadmap” da criação de um metaverso
4
multiusuário que venha a ser útil para outros grupos de outras áreas que
queiram fazer projetos de construção de conhecimento semelhantes.
Na direção da incorporação dos metaversos na pesquisa acadêmica,
observamos
que
Thiollent
(2007)
nos indica
que
a
pesquisa-ação
participativa tem como meta a integração dos pesquisadores e membros de
uma organização de forma cooperativa e participativa, para a solução de um
problema social. A observação do pesquisador indica-nos elementos que
podem estar presentes nesses mundos massivo-colaborativos que são os
metaversos. Ora, nos metaversos temos a interação entre indivíduos reais
por meio de seus avatares e esta interação pode provocar mudanças
significativas no mundo real como no digital (MURRAY, 2003). Quando
utilizados em projetos de cunho social, os metaversos podem ter a
capacidade de potencializar mudanças e introduzir seus participantes em
novos mundos que permitem, por sua vez, abrir novas perspectivas no
mundo real. Será nesta perspectiva que iremos apresentar o projeto de
metaverso em desenvolvimento, o metaverso do Projeto Pirarucu-Gente. Foi
por ocasião deste projeto que nos lançamos na aventura de conhecer mais a
fundo os metaversos, suas nuances e como implantá-los, em especial a
implantação do componente multijogador em rede, questão central desta
dissertação.
O Projeto Pirarucu-Gente é um projeto de 24 meses que surgiu a partir de
uma chamada do CNPq para projetos de desenvolvimento tecnológico de
áreas rurais. Trata-se de um projeto de assessoria técnica e de extensão
rural
do
Departamento
Universidade
Federal
de
de
Engenharia
Rondônia
de
(UNIR),
Pesca
que
e
seria
Aquicultura
da
originalmente
desenvolvido completamente off-line. O projeto tem este nome porque
trabalha com agricultores, pescadores artesanais e piscicultores de base
familiar da região denominada Território Central da Cidadania de Rondônia.
Considerado um verdadeiro dinossauro dos rios, o Pirarucu é o maior e um
dos mais resistentes peixes da Amazônia. Assim como o Pirarucu, o povo
sofrido da Amazônia consegue passar bravamente pelas dificuldades,
privações e sobreviver. O projeto vai ajudar as diversas associações destes
trabalhadores a conseguir melhores resultados nas suas atividades. Visa
fomentar o desenvolvimento organizacional e proporcionar capacitação
focada
em
autonomia,
gestão
de
empreendimentos
de
produção,
beneficiamento e comercialização. Além dos agricultores, pescadores
artesanais
e
piscicultores,
participam
do
projeto
técnicos
em
desenvolvimento rural de agências do governo, bem como pesquisadores,
professores e alunos da UNIR. O projeto pretende fazer um diagnóstico da
situação atual no estado e também o levantamento de boas práticas com
objetivo de subsidiar a autogestão e a sustentabilidade destas organizações
associativas.
Baseado na metodologia da “pesquisa-ação participativa”, o projeto leva os
participantes a fazerem a “problematização”, que é o levantamento dos
pontos importantes que precisam ser discutidos e melhorados na sua
prática diária, e desenvolvam projetos com o auxílio da universidade para
resolver estes problemas e planejar o futuro de sua própria instituição.
A assessoria técnica rural baseada na pesquisa-ação participativa vem se
contrapor
a
uma
prática
de
assessoria
rural
realizada
até
muito
recentemente, em que o governo ou as instituições de assessoria técnica
vinham com um projeto pronto e fechado de forma que os produtores rurais
eram meros receptáculos de um pretenso saber dos técnicos. É o que Paulo
Freire chama de “educação bancária” (FREIRE, P., 1983). Uns detêm o saber e
outros simplesmente o recebem de modo passivo. Este tipo de extensão
rural toma por certo que os agricultores e pescadores são desprovidos de
qualquer tipo de saber e que precisam de socorro por parte daqueles que o
detêm. O resultado desta prática é muitas vezes desastroso, pois os
produtores acabam não se engajando nos projetos, já que as ações
desenvolvidas nem sempre atendem às suas verdadeiras necessidades. Pior
que isso, práticas deste tipo acabam fazendo com que se endividem com os
bancos. A pesquisa-ação participativa toma como pressuposto que os
produtores são sujeitos ativos e que possuem uma riqueza de saberes que
nem sempre é reconhecida pela academia ou pelo governo. Todos têm sua
história e sua forma de saber específico, e esse saber tem importância
fundamental porque é baseado na vida prática e nas descobertas da
observação empírica. Estes saberes podem enriquecer muito o trabalho da
pesquisa acadêmica e, na interação entre os diversos participantes, um
saber completamente novo pode surgir com soluções inovadoras (FREIRE, P.,
1983; WILLIAMS, 2011).
Os trabalhos do projeto serão desenvolvidos em sete módulos presenciais
de 40 horas cada ao longo de 24 meses, com o objetivo de fazer o
diagnóstico da situação de cada instituição e auxiliar cada uma na definição
do seu projeto de futuro e de seus planos estratégicos segundo os seus
interesses e valores.
Os temas dos módulos são: 1) Metodologias
participativas de apoio à gestão compartilhada de recursos naturais,
pesqueiros e da biodiversidade; 2) Agroecologia: história, princípios e
fundamentos; agricultura familiar, pesca artesanal e campesinato; 3)
Extensão rural: história e evolução; 4) Diagnóstico, inventário ambiental e
6
capacidade
de
desenvolvimento
suporte
e
dos
ecossistemas;
economia
ecológica;
participativo;
mudanças
climáticas,
envolvimento
serviços e tecnologias ambientais; recuperação de nascentes de água, mata
ciliar e áreas degradadas; 5) Segurança e soberania alimentar; 6) Aquicultura
de base ecológica; 7) Economia popular e solidária: redes sociais solidárias e
formas de comercialização em grupo.
Um total de 11 entidades participarão dos trabalhos, entre elas associações
de pescadores e de produtores rurais, entidades de assessoria técnica rural
e a universidade, com apoio das prefeituras da região.
O projeto prevê a montagem de cartilhas com as melhores práticas
agroecológicas e outras boas práticas de auxilio às atividades dos
agricultores, pescadores artesanais e piscicultores levantadas durante o
período de execução. Ao final do projeto será publicado um livro com todo
este material.
Diversos fatores contribuíram para que entendêssemos que um metaverso
no Projeto Pirarucu-Gente poderia enriquecer, e até mesmo redimensionar,
o trabalho em andamento. Por serem elementos que recriam a realidade de
modo visual e lúdico, os metaversos poderiam ser de utilidade para
trabalhar com pessoas que não tivessem muito domínio da linguagem
escrita ou acadêmica, caso dos agricultores, pescadores e piscicultores. Os
metaversos podem trazer informações e ensinar de maneira visual e prática,
o que serviria para o propósito de inclusão digital. O Projeto Pirarucu-Gente
já incluía treinamentos em informática para que os participantes pudessem
utilizar
o
computador,
acessar
a
Internet
e
desenvolver
controles
financeiros. A introdução de um metaverso enriqueceria ainda mais estas
práticas. Outro fator foi que o metaverso apresenta a oportunidade ideal
para juntar em um mesmo ambiente virtual os parceiros de diferentes áreas
do estado, alguns a mais de 400 km de distância dos outros, e criar uma
comunidade virtual.
Fora isso, o metaverso, associado à criação de um
website do Projeto Pirarucu-Gente (2011), poderia ampliar o alcance do
projeto permitindo que qualquer pessoa tivesse acesso ao material
produzido.
Dada a duração de dois anos do Projeto e o tempo limitado de que
dispúnhamos para a realização desta dissertação, optamos por limitar nosso
estudo somente ao processo de implantação inicial do metaverso, incluindo
a fase de criação conceitual e a programação multijogador em rede, com
mais ênfase nesta última.
Deste modo, no primeiro capítulo vamos dar as primeiras pinceladas
conceituais sobre os metaversos discutindo o que são e se existe realmente
uma definição para eles. Começaremos por uma arqueologia da questão,
retomando
outros
conceitos
importantes
relacionados
como
o
de
ciberespaço, universo digital e comparando as definições de mundos
virtuais, metaversos e protometaversos. Vamos falar sobre a importância de
estudar os metaversos de um ponto de vista ontológico, introduzindo a
ideia de uma “topofilosofia” que pensa o processo criativo-reflexivo-prático
que está na base da modelagem de mundos, objetos e sujeitos digitais.
Neste contexto, iniciaremos uma caminhada desde os primórdios dos
primeiros jogos eletrônicos, levantando aqueles que contribuíram de alguma
maneira para o advento dos metaversos, isto a partir de duas de suas
características básicas: a de serem ao mesmo tempo games em rede e
games multijogador. Neste passeio, pode-se até sentir falta de alguns
games clássicos que foram importantes para a História dos videogames,
como Space Invaders ou sobre o desenvolvimento dos consoles, mas estes
não estarão lá porque não tiveram, a nosso ver, influência decisiva sobre o
desenvolvimento
dos
metaversos.
Falaremos,
sim,
dos
games
que
trouxeram alguma inovação tecnológica fundamental ou alguma inovação
conceitual ou artística importante.
Finalizaremos o primeiro capítulo procurando resumir as principais
características dos metaversos que levantamos nos autores que mais
destacam-se na área de metaversos e mundos virtuais. Traremos, também,
algumas estatísticas recentes a respeito dos metaversos que mostram a
situação atual e algumas perspectivas futuras quanto ao desenvolvimento e
utilização e aplicações dos metaversos no futuro.
O segundo capítulo será direcionado à questão da criação de metaversos do
ponto de vista puramente técnico. Vamos procurar entender algumas bases
para a implantação de metaversos pensando especificamente na questão do
componente multijogador em rede. Levando em conta o que estudamos no
capítulo 1 sobre os games multijogador e os games multijogador em rede,
apresentaremos alguns conceitos básicos importantes sobre redes e os
possíveis modelos de comunicação entre os nós da rede que são
fundamentais para o entendimento do funcionamento e a implantação de
metaversos. Neste capítulo, começaremos por explorar o modelo OSI em
camadas lógicas para podermos entender o funcionamento do envio de
dados via redes e uma série de outros elementos de importância para o
funcionamento de games multijogador em rede, como a questão da
latência, largura de banda, sincronização, entre outros. Veremos os tipos e
8
modelos de conexão e de comunicação de dados que podem ser utilizados
em games em rede e em metaversos.
Após este passeio teórico trabalharemos na prática mostrando algumas
alternativas de como montar o componente multijogador em rede para a
criação de um metaverso com o Unity 3D. Vamos estudar alguns trabalhos
interessantes que fornecem tutoriais para ajudar de forma didática na
criação de games multijogador em rede ou MMOs. Seguimos estes tutoriais
e mostramos os resultados de nossos testes com os scripts fornecidos por
eles. Nosso objetivo com este capítulo é duplo: 1) criar um material em
português que possa ser seguido e entendido por pessoas que não tenham
formação em ciência da computação ou áreas afins, mas que queiram
montar um metaverso 2) auxiliar-nos no desenvolvimento do componente
multijogador em rede do nosso metaverso, o Metaverso Pirarucu-Gente.
O terceiro capítulo constitui uma proposta de continuidade da criação
conceitual e da implantação do Metaverso para o Projeto Pirarucu-Gente.
Retomamos algumas questões a respeito desse projeto e suas bases
teóricas, em especial a metodologia utilizada em suas sessões presenciais: a
pesquisa-ação. Em seguida, fazemos uma reflexão a respeito de como
podemos levar o real para o virtual e vice-versa de modo a termos um
trabalho colaborativo no metaverso, assim como acontece no real, com a
pesquisa-ação. Em seguida analisamos alguns trabalhos de implantação de
games acadêmicos, games multijogador e metaversos para podermos
levantar algumas experiências e técnicas para o levantamento conceitual e
artístico na criação de games ou metaversos.
Finalizamos o capítulo com um GDD – Game Design Document inicial para o
Metaverso do Projeto Pirarucu-gente que nos ajudará a nortear e a
desenvolver nosso metaverso. De forma alguma trata-se de um documento
pronto. É apenas a versão inicial que ajudará a equipe do projeto a melhor
definir objetivos, parâmetros e o formato final do metaverso.
Embarquemos em nossa aventura!
CAPÍTULO 1: UMA INTRODUÇÃO AOS METAVERSOS
Figura 1 - SimCity 2000
D
urante uma viagem ao Canadá em 1994, encontrei uma cópia do
game SimCity 2000 da Maxis (figura 1) em uma loja de material de
escritório. Atraído pela bonita caixa e pela ideia de gerenciar uma
cidade em um jogo, comprei o pacote. Por andar muito ocupado com meu
trabalho, não consegui instalar nem dar atenção ao jogo. Passaram-se
alguns meses até que eu finalmente me sentasse para instalá-lo e
experimentá-lo. A experiência foi crescendo. Um prazer indescritível foi
tomando conta de mim ao criar diferentes tipos de cidades, com áreas
comerciais, industriais e residenciais, conectando-as com ruas, estradas,
viadutos, ferrovias e até mesmo metrô. Ver a dinâmica da cidade era algo
incrível. Se as áreas que tinham sido criadas como distritos industriais não
contassem com estradas para que os trabalhadores pudessem chegar e para
poder escoar sua produção, deterioravam rapidamente ou simplesmente
não cresciam. Se não colocássemos delegacias de polícia e estações de
bombeiros espalhadas pela cidade corríamos risco de ver um incêndio
espalhar-se ou um grupo de manifestantes quebrar tudo. Desastres
aconteciam de vez em quando, como um terremoto, um tornado ou mesmo
uma invasão alienígena ateando fogo em tudo. Estas coisas mudavam
radicalmente a dinâmica da cidade fazendo eu, seu prefeito, tomar medidas
extremas para que a cidade não fosse totalmente destruída. Em tempos de
paz, criar escolas, universidades e bibliotecas, além de embelezar a cidade
com árvores, parques, lagos e parques de diversão proporcionavam um
prazer indescritível.
10
A experiência cresceu e o número de horas que passava em frente ao
computador também. Sentia-me imerso na experiência. As cidades eram
reais para mim. Ficava imaginando estratégias para fazê-las crescer mais
rapidamente, sem deixar que problemas como criminalidade, desemprego e
falta de verbas deixassem-nas degradadas. Chegava a sonhar com o jogo e
com possíveis novas estratégias.
Apesar de o jogo incluir cenários com missões que podiam ser escolhidas,
por exemplo, fazer uma cidade crescer até o tamanho “x” de população em
“x” anos para poder ganhar uma partida, nunca me interessei por isso. Meu
empenho e prazer estavam no processo, no viver aquela experiência e no
criar novas cidades radicalmente diferentes das outras.
Jogava todos os dias, e as horas no mundo real passavam como um rio. Em
dado momento dizia: “Vou jogar só uma hora antes de dormir. Amanhã
preciso acordar cedo para trabalhar”. Quando olhava pela janela, pasmo, via
que o sol já estava nascendo. Sem dormir, ia direto para o trabalho. Ao
voltar, “entrava” diretamente no computador para jogar “um pouco” mais.
Meus pensamentos giravam em torno do SimCity todos os dias e o tempo
todo, em casa e no trabalho. Comecei a ver meu rendimento no trabalho
cair e, obviamente, sentia um sono terrível, mas não conseguia parar de
jogar.
Em dado momento, confrontado com as necessidades do mundo real, assim
como tinha que tomar ações extremas como prefeito da cidade no SimCity,
senti-me obrigado a tomar uma ação extrema: parar de jogar. Na época
sentia-me culpado por estar tão imerso no mundo do SimCity e estar
“fugindo da realidade”, apesar de nada estar efetivamente errado na minha
vida real. Eu era solteiro, tinha um trabalho em um escritório, amigos e
família. Mas o “mundo virtual” me atraía de maneira incrivelmente tentadora.
Meus pais recriminavam-me dizendo: “Menino, você está ficando doente!
Pare de jogar. Você precisa dormir para poder trabalhar.”
Foi então que parei, e parei mesmo, de jogar SimCity. Tudo em favor da vida
real, uma vida real simples, mas, pensando bem, medíocre e um pouco sem
graça. Na época achei que tinha tomado a decisão certa.
Havia me esquecido completamente deste episódio até pensar no que
escreveria no capítulo sobre introdução aos metaversos e mundos virtuais.
Curiosamente, ao pensar sobre as características dos metaversos, o
episódio me voltou por inteiro à mente.
Aparentemente, o relato pode não ter nada a ver com os metaversos, mas
alguns elementos do jogo SimCity 2000, prenunciavam já nos anos 1990
alguns elementos que fazem dos metaversos coisas tão fascinantes hoje.
O SimCity foi um dos precursores dos metaversos porque já incluía um
espaço navegável e uma forma elementar de simulação de um terreno 3D.
Não incluía avatares propriamente ditos, mas a minha ação como prefeito
afetava todos os habitantes da cidade, que podiam ser minimamente vistos
andando em carros ou trens, protestando na rua, quando sentiam que os
impostos estavam altos demais ou gritando de alegria quando a cidade
ganhava alguma nova obra importante como uma escola, biblioteca ou um
estádio de futebol. Enfim, o jogo constituía um mundo virtual em si mesmo.
Naqueles idos tempos de 1994,
quando a internet estava apenas
começando no Brasil, a experiência
que o SimCity pôde me proporcionar
era o mais próximo do que Janet
Murray
chamou
de
“imersão”
(MURRAY, 2003, p.101). Era também
um vislumbre do que chamou de
“agência” (MURRAY, 2003, p.127) e
também uma sensação fantástica
proporcionada pela “transformação”
(MURRAY,
habilidade
2003 p. 153), aquela
de
ver
uma
mesma
realidade de maneira caleidoscópica
Figura 2 - Janet Murray: autora de Hamlet no
e enriquecedora. Foram exatamente
Hollodeck
estes fatores que me fascinaram
tanto na época, mas na falta de algum critério de análise para a experiência,
acabei por ficar com aquilo que o senso comum dizia: “os gamers são
vagabundos que ficam jogando o dia inteiro e deixam a vida real e as coisas
importantes passarem” ou “os games são coisas para quem não tem o que
fazer”. Então parei de jogar por muitos anos.
Aqui cabe um parênteses importante sobre como minha visão a respeito
deste assunto mudou. Agora, tantos anos depois, vejo que fui vítima de
uma visão de mundo preconceituosa contra os games. E esta visão faz parte
do senso comum da nossa cultura e simplesmente considera tudo o que é
relacionado a games como “coisa inútil para a nossa realidade” e não reflete
12
o que realmente significa ser um gamer ou a riqueza que os games podem
trazer para a nossa vida real.
De fato, nos últimos tempos esta visão de mundo distorcida parece ser
confirmada pela enorme leva de pessoas que passam cada vez mais tempo
jogando videogames e Jogos Massivos Multijogador Online (MMOs). Alguns,
até anteveem uma espécie de cataclismo social pelo fato de tantas pessoas
estarem “migrando” para o mundo virtual. São pessoas que preferem passar
horas em frente a um computador ou console de videogame do que fazer
qualquer outra coisa que seja na vida real. Seria importante entendermos o
porquê deste fenômeno.
No
livro
“Reality
is
Broken”
(MCGONIGAL, 2011), a game designer
Jane
McGonigal,
fundadora
do
movimento “Games for Change”, tem
uma
teoria
interessante
a
respeito
disso. Para ela:
“Esses jogadores não estão rejeitando a
realidade inteiramente. Eles têm trabalhos,
metas, trabalhos de escola, famílias e vidas
reais com que se preocupam. Mas à medida
que dedicam mais e mais do seu tempo
livre para os mundos dos jogos, cada vez
mais parece que está faltando alguma coisa
no mundo real.
Os gamers querem saber: Onde, está aquele sentimento do gamer de
estar totalmente vivo, focado e engajado a cada momento? Onde
estão o sentimento de poder, de propósito heroico e de comunidade
do gamer? Onde estão as explosões de alegria por conta das
realizações de um jogo emocionante e criativo? Onde está a emoção
de um coração explodindo por conta do sucesso e da vitória da
equipe? Enquanto os jogadores podem experimentar esses prazeres
ocasionalmente em suas vidas reais, experimentam-nos quase
sempre quando estão jogando seus jogos favoritos.”3 (MCGONIGAL,
2011, p. 2)
3
No original: “These gamers aren’t rejecting reality entirely. They have jobs, goals,
schoolpwork, families, and real lives that they care about. But as they devote more
and more of their free time to game worlds, the real world increasingly feels like
O fato de tantas pessoas em todo o mundo estarem escolhendo passar boa
parte do seu tempo em games e nos chamados mundos virtuais é sinal de
algo importante, uma realidade que precisamos urgentemente reconhecer. A
realidade é esta:
“(...) na sociedade de hoje, os videogames e jogos de computador
estão preenchendo uma necessidade humana legítima que o mundo
real de hoje não pode suprir. Os games estão proporcionando
recompensas que a realidade não está proporcionando. Estão
ensinando, inspirando e nos engajando de maneiras que a realidade
não consegue fazer.”4 (MCGONIGAL, 2011, p. 4)
Em outras palavras existe uma sensação de que não somos tão bons na vida
real quanto nos games.
O fato é que, na verdade, não existe esta
dicotomia entre o eu real e o eu virtual. Como bem estudou Sherry Turkle a
respeito dos MUDs (e que pode ser aplicado aos games e metaversos), os
chamados mundos virtuais são locais onde é possível experimentar
identidades alternativas (TURKLE, 2003), mas seja lá como for, todas estas
fazem parte e são facetas da nossa identidade real. Assim, os games e
mundos virtuais despertam em cada um de nós muitas qualidades e pontos
fortes que, de outra maneira, ficariam adormecidos ou jamais seriam
descobertos no mundo real. Neles somos otimistas, focados, determinados,
trabalhamos em grupo e persistimos até conseguimos “vitórias épicas”.
Feita esta constatação, McGonigal perguntou-se: “Como poderíamos pegar
estes sentimentos dos games e aplicá-los ao trabalho no mundo real?” Foi
assim que passou a estudar o game World of Warcraft (WoW), que é um
ambiente colaborativo dos mais propícios à resolução de problemas em
equipe e começou a perceber alguns elementos que tornam aquela sensação
it´s missing something.
Gamers want to know: Where, in the world, is that gamer sense of being fully alive,
focused and engajed in every moment? Where is the gamer feeling of power, heroic
purpose, and community? Where are the bursts of exhilarating and creative game
accomplishment? Where is the heart-exploding thrill of success and team victory?
While gamers may experience these pleasures occasionally in their real lives, they
experience them almost constantly when they´re playing their favorite games.”
4
No original: “in today’s society, computer and videogames are fulfilling genuine
human needs that the real world is currently unable to satisfy. Games are providing
rewards that reality is not. They are teaching and inspiring and engajing us in ways
that reality is not.”
14
de “vitória épica” tão possível nos games. Neste estudo fez uma série de
constatações, em especial que a) no WoW todos recebem uma missão de
salvar o mundo e metas específicas que estão ao seu alcance conforme o
seu nível no jogo b) todos sempre têm a sensação de que existem centenas
de colaboradores com o mesmo propósito; c) sempre existe um feedback
imediato da sua atuação; d) constatou a produção imensa dos usuários do
jogo no Wiki do WoW, fazendo-o o segundo maior wiki do mundo com cerca
de 80.000 artigos ficando somente atrás da Wikipédia.
Constatou também quatro características apresentadas por pessoas que
jogavam muito o “World of Warcraft”:
1)
um
sentimento
de
“otimismo
urgente”, isto é, o desejo de agir
imediatamente frente a um obstáculo;
2) um senso de colaboração social
importante, ou seja, jogar com outros
faz com que gostemos mais das
pessoas
com
quem
jogamos
contribui
para
criarmos
relações
de
confiança
e
vínculos,
e
de
cooperação;
3) produtividade feliz5, um jogador de
WoW gasta em média 22 horas por
semana
no
jogo,
ou
seja,
Figura 3 - Jane McGonigal: autora de "Reality is
aproximadamente o tempo de um
Broken"
emprego de meio período. Isto é
porque, segundo McGonigal, somos mais felizes trabalhando duro do que
relaxando. Como seres humanos, sentimo-nos melhor quando fazemos um
trabalho que tenha significado para nós e estamos sempre dispostos a
trabalhar duro o tempo todo se o trabalho certo nos for dado.
4) um sentido épico6. Os gamers adoram estar ligados a missões de caráter
humano e em histórias de escala planetária.
5
No original: “Blissful productivity”.
6
No original: “Epic meaning”.
Ainda segundo McGonigal (2010), estas quatro excelentes características
fazem-nos
perceber
que
os
gamers
são,
na
verdade,
indivíduos
esperançosos e cheios de potencialidades. São pessoas que acreditam que
podem individualmente mudar o mundo. O único problema é que acham
que só podem mudar mundos virtuais e não o mundo real.
Foi neste ponto que McGonigal fez uma “descoberta épica”. Se toda esta
energia e talentos que hoje estão voltados para a criação de um mundo
virtual fictício fosse aplicada em problemas e cenários reais, imagine o
quanto não seria possível resolver “problemas épicos” do mundo real. Assim
surgiu o movimento Games for Change, propondo a criação de jogos de
qualidade sobre problemas reais e que permitam aos jogadores utilizar todo
seu potencial na solução de problemas reais.
Foi assim que seu grupo do Institute for the Future passou a criar games
sobre questões reais à busca de soluções para questões reais. O primeiro,
chamado World Without Oil (2007) (O mundo sem petróleo), um jogo
massivo multijogador de roleplay que fazia uma simulação do mundo sem
petróleo e todas as consequências que isto acarretaria. O segundo game foi
Superstruct (2008), jogo massivo multijogador de roleplay no qual os
jogadores organizam a sociedade para resolver questões que confrontarão o
planeta em 2019, quando um supercomputador calcula que a vida somente
será viável na Terra por mais 23 anos se as coisas continuarem como estão
e que ações os humanos devem tomar para evitar um colapso catastrófico
que nos levaria à extinção. Desde então, outros games-experimento foram
criados, cada um com uma produção enorme de material em wikis, vídeos e
outros meios com soluções inovadoras para problemas reais. A este tipo de
jogos, a imprensa denominou “alternate reality games” ou jogos de
realidade alternativa.
Fechando este parênteses, gostaria de dizer que o movimento “Games for
Change” representa um avanço importante para uma nova visão dos games
na sociedade. Os games não são mais apenas um elemento para
entretenimento. Podem ser ferramentas de transformação social. Neste
sentido, o nosso Projeto Pirarucu-Gente, mesmo que de natureza um pouco
diferente dos projetos desenvolvidos pelo movimento Games for Change,
vem somar às experiências voltadas para melhorias das condições sociais e
de vida de inúmeras pessoas.
Pois bem, Sherry Turkle, em seu livro “Life on the Screen”, faz uma reflexão
sobre o papel que a tecnologia tem na criação de uma nova sensibilidade
social e cultural (TURKLE, 1997, p.31). O livro de Turkle analisa a questão
16
dos MUDs (Multi User Dungeons) ainda no início da década de 1990 e
verifica o quanto as relações humanas são afetadas, modificadas e
modificam a vida real com o uso de computadores e seus periféricos. Tratase de um estudo ainda quando os metaversos propriamente ditos não
existiam, pois os MUDs eram mundos criados principalmente por meio de
textos. Ainda assim, as modificações no modo de vida dos seus usuários
foram grandes e ocasionaram mudanças interessantes e importantes na
identidade daqueles que os utilizavam. Em seu livro, Turkle discute
“as relações intensas que as pessoas
têm com os computadores e como
estas relações estão mudando a forma
como pensamos e sentimos” (TURKLE,
1997, p. 32).
Tudo ocorre porque passamos de
uma fase em que os computadores
eram utilizados em uma “cultura
do cálculo” para uma fase da
“cultura
da
simulação”
o
que
produziu uma mudança qualitativa
de “o que o computador pode fazer
para nós” para “o que ele faz em
nós”, em nossas relações e nossas
Figura 4 - Sherry Turkle: autora dos livros "Life on
the Screen" e "Alone Together"
formas
de
pensar
sobre
nós
mesmos.
A revolução digital acabou por fazer com que a área da computação,
anteriormente conhecida essencialmente como domínio das Ciências Exatas,
passasse a possuir um forte componente humano, que pode e precisa ser
analisado do ponto de vista das Ciências Humanas. Um novo campo de
estudo tem se aberto. Quanto mais os humanos passam a ter uma vida
online, a relacionar-se com outros seres humanos via ciberespaço,
mudamos e somos mudados por este ciberespaço.
Nos MUDs, jogadores distantes entre si podiam compartilhar, por meio da
internet, um espaço virtual no qual podiam conversar uns com os outros via
digitação em tempo real. O texto digitado por jogadores em qualquer parte
do planeta aparecia na tela de cada participante no mesmo tempo em que
eles improvisavam e imaginavam coletivamente mundos fictícios. Como
mencionamos
anteriormente,
segundo
Turkle
os
MUDs
tornaram-se
verdadeiras oficinas psicológicas em que os jogadores podiam experimentar
múltiplas identidades e papéis. Um homem podia ser uma mulher, um
animal ou um dragão, coisas que seriam praticamente impossíveis no
mundo real. Nos metaversos atuais estas características ficam ainda mais
marcadas por conta da sofisticação que atingiram. Existem metaversos e
MMORPGs das naturezas mais distintas onde cada um pode “encenar as
suas fantasias”, como diz Murray, em MMORPGs fantásticos como o World of
Warcraft (2012) ou em metaversos para entretenimento adulto como o
metaverso com o nome sugestivo Red Light Center ou Utherverse (2012).
Daí aflora uma riqueza de elementos passíveis de estudos acadêmicos
psicológicos, sociais e até mesmo econômicos.
Em seu novo livro, “Alone Together” (2011), Sherry Turkle afirma que
estamos tão conectados que já chegamos a um ponto de saturação. Antes
perguntávamos o que faríamos com o computador, agora perguntamos o
que fazemos sem o computador. A tecnologia promete deixar-nos fazer o
que quisermos de qualquer lugar com qualquer um, mas ao mesmo tempo
nos exaure quando tentamos fazer todas as coisas em todos os lugares.
Começamos a nos sentir oprimidos. Podemos ser livres para trabalhar de
qualquer lugar, mas nós também somos propensos a sentirmo-nos
solitários em toda parte. Ficarmos conectados o tempo todo pode levar-nos
a uma nova forma de solidão. Voltamo-nos para uma nova tecnologia para
preencher o vazio, mas quando fazemos isto, a nossa vida emocional se
desgasta. Frente a tudo isso, Turkle propõe uma espécie de “regime” de
tecnologia. É importante aprendermos a usá-la da melhor maneira, mas
afastarmo-nos dela de vez em quando é salutar também. É bom estar
online, mas não o tempo todo.
Voltando à questão das origens dos mundos virtuais e metaversos, se
pensarmos do ponto de vista tecnológico, seus primórdios começam mesmo
com os experimentos digitais dos MUDs (Multi User Dungeons) no final da
década de 1970 e começo da de 1980 ainda em formato de texto.
Os
MUDs, Zork I a III (1980 e 1981),
SimCity (1989), Myst (1993), Doom
(1992), Return to Zork e Zork Nemesis (1993 e 1996) foram fundamentais,
cada um com a sua contribuição, para o desenvolvimento dos games, em
especial para o advento dos MMOs (Massive Multiplayer Online Games –
Jogos Massivos Multijogador Online) e dos MMORPGs (Massive Multiplayer
Online Roleplaying Games – Jogos Massivos Multijogador Roleplay Online).
18
Tudo isto não poderia ter acontecido sem que as chamadas "novas
tecnologias", em especial a internet, acabassem por desenvolver este novo
ambiente humano designado como ciberespaço. O nosso encontro com este
lugar de navegação que é o ciberespaço inevitavelmente dar-se-á na forma
de um espaço digital e, sobremaneira, dentro de um espaço navegável
(MANOVICH, 2011; PETRY, 2003).
Saltando de um site a outro por meio de seus links, o sujeito humano passa
de um ponto a outro da cultura, deslocando-se por milhares de lugares
dentro dos limites culturais, políticos e geográficos de uma malha que
"promete" vincular em um discurso partilhado e colaborativo a humanidade
(MANOVICH, 2001; MURRAY, 2003). Esta constitui-se em uma faceta
importante do chamado ciberespaço, a qual nos encaminha discreta e
sutilmente ao contexto dos ambientes virtuais completamente imersivos,
massivos e persistentes, chamados aqui de metaversos.
Mas nos deteremos um pouco aqui, pois convém falarmos mais claramente
do que chamamos ciberespaço, mundos virtuais e metaversos antes de
entrarmos na arqueologia da questão ontológica destes últimos.
A ORIGEM DOS CONCEITOS
DE CIBERESPAÇO E METAVERSO
Tanto o termo “ciberespaço” como o termo “metaverso” são originalmente
provenientes da literatura de ficção científica. O termo ciberespaço foi
criado em 1984 por William Gibson, um escritor canadense que o usou em
seu romance de ficção científica Neuromancer. No livro, este termo designa
o universo das redes digitais, descrito como campo de batalha entre as
multinacionais, palco de conflitos mundiais, nova fronteira econômica e
cultural. Alguns heróis são capazes de entrar “fisicamente” nesse espaço de
dados para lá viver todos os tipos de aventuras. O ciberespaço de Gibson
torna sensível a geografia móvel da informação, normalmente invisível. Com
base na descrição do ciberespaço de Gibson, Pierre Lévy define o
ciberespaço como “o espaço de comunicação aberto pela interconexão
mundial dos computadores e das memórias dos computadores” (LÉVY,
1999, p. 94).
Já o termo metaverso vem do livro de Neal Stephenson “Snow Crash” de
1994 (STEPHENSON, 1994), traduzido em português como “Nevasca”7. No
livro, o “Metaverso” é um ambiente virtual urbano constituído por uma única
rua de 100 metros de largura que circundava um planeta perfeitamente
esférico e preto de 65636 km de circunferência. Os terrenos ao longo desta
avenida poderiam ser comprados no mundo real para serem usados para a
construção de prédios virtuais. No livro, os usuários acessavam o Metaverso
por meio de óculos de visualização em alta definição ou via terminais de
baixa qualidade em cabines. Dentro do Metaverso os usuários eram
representados por seus avatares. O livro mostra o Metaverso como um único
sistema e a etimologia da palavra vem de meta: além, verso: corruptela de
universo, portanto, sendo um universo paralelo ao real.
APORTES DO CONCEITO DE METAVERSO DERIVADOS DA
LITERATURA CIENTÍFICA INTERNACIONAL
Figura 5 - Metaverso Friendshangout
7
Nota da publicação em português:
STEPHENSON, Neal (2008). Nevasca. São Paulo. Editora Aleph. ISBN: 8576570548 ISBN-13:
9788576570547
20
As definições de metaverso encontradas na literatura científica são por
vezes confusas e não deixam claras as limitações entre os conceitos de
mundo virtual e de metaversos.
O site da Metaverse Worldmap (ASF 2010) tem um glossário que traz uma
série de definições do que podem ser os metaversos. A primeira definição é
a mais abrangente e surgiu a partir da definição original de Stephenson. O
“Metaverso” (com “m” maiúsculo e no singular) seria “o nosso espaço online
coletivo compartilhado”. O Metaverso inclui todos ambientes sociais online
interativos e compartilhados como elementos, seja um MUD de texto, um
chat, um mundo persistente 3D ou um mundo colaborativo online. Neste
caso a questão do compartilhamento é mais importante que a da
dimensionalidade.
Outra definição no glossário do site da Metaverse Worldmap também tem
este conceito de metaverso como sendo o espaço real estendido por meio
de elementos de realidade aumentada:
“Um
mundo
físico
virtualmente
melhorado.
As
pessoas
frequentemente pensam no metaverso de Stephenson como um
“outro” lugar, mas para diversos propósitos o melhor modelo de
metaverso para 2016 pode ser a realidade aumentada – um ambiente
físico cheio de informação onde a web 3D é apenas uma aplicação
executada em circunstâncias especiais. Em um mundo com recursos
avançados de navegador 3D teremos nosso bate-papo, nosso e-mail,
nossos navegadores 2D etc. A voz será usada para muitas consultas
básicas, mas o texto, mesmo o texto de IM, é privado e discreto, por
isso não irá desaparecer no metaverso de amanhã.” (Definição de
Mike Liebhold, Institute for the Future http://www.iftf.org )8.
8
No original: “A virtually-enabled physical
world. People often think of
Stephenson’s metaverse as an “other” place, but for many purposes the best model
for the metaverse of 2016 may be augmented reality – an information-drenched
physical environment where the 3D web is just one application, run in special
circumstances. In a world with advanced 3D browser capabilities we will have our
chat, our email, our 2D browsers, etc. Voice will be used for many basic queries, but
text, even IM text, is private and unobtrusive, so it will not disappear in tomorrow's
metaverse.”
Liebhold apresenta uma concepção expandida de metaverso. A definição
inclui o conceito da utilização de dispositivos móveis como smartphones e
tablets conectados à internet e a softwares que permitem ampliar a
percepção do mundo real. Comporia uma estrutura híbrida, em que
elementos virtuais são sobrepostos ao nosso sentido visual ou audível do
mundo físico para aumentar o fluxo de informações. Mais tipicamente,
imagens fixas ou em 3D são sobrepostas sobre um fundo ao vivo obtido
pela câmera do dispositivo móvel exibindo e acompanhando o ponto focal
da câmera dinamicamente enquanto movemos nosso dispositivo. Um
exemplo, ao caminhar por uma rua, o dispositivo móvel utiliza o GPS e a
câmera para obter em tempo real informações mais precisas sobre serviços
e produtos que o local em que a pessoa está apontando oferece. Por meio
da câmera um software poderia identificar, por exemplo, uma pizzaria e já
buscar dados na internet sobre preços etc., oferecendo informações em
tempo real sobre a imagem da pizzaria captada pela câmera. Da mesma
maneira, ao mover a câmera para outro ponto da rua, poder-se-ia
identificar um museu e visualizar em 3D em sua imagem na tela algumas
das principais obras a visitar nele.
As definições acima, apesar de interessantes, não expressam o que
entendemos por “metaversos”. Aqui dizemos “metaversos” no plural porque
podem existir uma infinidade deles com naturezas e características
diferentes, mas que compartilham algumas características comuns que nos
permitem classificá-los como tal e que serão de valia para o nosso trabalho.
Muitos trabalhos, como a abordagem de Deterco e Alcântara (2004), não
fazem distinção entre mundos virtuais e metaversos, apesar de estarem
referindo-se claramente aos metaversos. Para estes autores o conceito de
“mundo virtual” é algo que deve ser entendido como mundos que “não têm
existência real palpável e, sim, uma existência aparente ou simulada”. Estes
possuem um “entorno tridimensional” que indicam que seu aspecto é
aparentemente tridimensional, pois a “representação interna dos elementos
que compõem o ambiente virtual é tridimensional”, ou seja, representada
por vetores x, y e z. Os mundos virtuais possuem também um caráter
interativo e autônomo, pois os usuários podem interagir com o entorno e
podem alterar o ambiente ou serem alterados por ele. Outra característica
segundo os autores é a imersão. A imersão “se refere principalmente ao
feito de reconhecer que o usuário está dentro de um entorno tridimensional,
e isto se consegue quando existe um acima, um abaixo, um perto, um
longe, e outra quantidade de aspectos espaciais e temporários”. Outra
característica é que tudo ocorre em tempo real, pois todas as interações
22
com o meio refletem-se imediatamente no próprio mundo virtual. Para
Deterco e Alcântara, os mundos virtuais também possuem o fator
multijogador como característica, em que diversas pessoas podem participar
por meio de avatares.
CONCEITUANDO MUNDOS VIRTUAIS, METAVERSOS E
PROTOMETAVERSOS
Como vimos acima, parece ainda não haver um consenso quanto aos
conceitos de mundo virtual e metaversos. Mesmo que clareza e precisão
absolutas do conceito somente poderão advir com mais pesquisa e mais
tempo, para os fins da presente pesquisa iremos agora selecionar as
definições que mais se ajustam ao nosso escopo, para que possamos
discuti-las em nossa exposição.
A definição de William G. Burns III no site da Metaverse Worldmap (ASG
2011) já se encaminha para uma definição mais clara do que são os
metaversos:
“Uma representação eletrônica de um ambiente do mundo real,
populada por pessoas reais e por programas construídos (conhecidos
como “bots”). Dentro de tais ambientes é possível não somente
interagir com o cenário assim como se faria no mundo real, mas
também é possível interagir com outros usuários do sistema em
tempo real 3D.”9
No entanto, a definição que consideramos mais simples e abrangente de
metaversos é a de Davis et al. (2009):
9
No original: “An electronic representation of a real world environment, populated
by real people and constructed programs (known as bots). Within such an
environment it is possible not only to interact with the scenery as you would in the
physical world, it is also possible to interact with other system users in 3D real
time.”
“Metaversos são mundos virtuais tridimensionais imersivos nos quais
as pessoas interagem entre si e com agentes de software, usando a
metáfora do mundo real, mas sem suas limitações físicas”.10
Nas duas definições anteriores temos um elemento implícito que é a
questão multiusuário ou multijogador. Ambas falam em interação com o
ambiente e com os demais usuários. A nosso ver, os metaversos são
necessariamente de caráter multiusuário.
Figura 6 - Alletsator: um protometaverso.
Apesar de altamente instigante, a definição de mundos virtuais de Deterco e
Alcântara
inclui o
fator multiusuário
como
característica intrínseca.
Entretanto, existem mundos virtuais que não possuem a característica
multiusuário. Exemplos disto seriam games que possuem uma topologia
virtual navegável 3D, mas que não incluem um sistema multiusuário a
exemplo do mundo virtual “AlletSator” 11 (BARBOSA e PETRY, L. C. 2008)
(figura 6) e do game “Ilha Cabu” (2010). Na definição de Petry (2011), estes
são protometaversos, pois têm quase todas as características de um
metaverso, mas não são multiusuário. Nestes, cada usuário interage e
10
No original: “Metaverses are immersive three-dimensional virtual worlds in which
people interact as avatars with each other and with software agents, using the
metaphor of the real world but without its physical limitations.”
11
Ópera Quântica (Eletrônica) Alletsator de Pedro Barbosa e Luís Carlos Petry -
http://www.topofilosofia.net/bienal
24
modifica o ambiente, mas somente relaciona-se com NPCs (non player
characters, personagens não-jogador) automatizados e inteligentes.
Deste modo, entendemos que mundos virtuais são mundos imersivos
navegáveis 3D, não importando se são multiusuário ou não. Podemos ter
um mundo virtual em um MMO, em um MMORPG ou em um game em modo
standalone como no caso do belíssimo mundo virtual do game Shadow of
the Colossus (2003) para Playstation 2 e 3, que não possui modo
multijogador.
Assim, para maior precisão conceitual, seria importante designarmos o
Second Life, o Entropia e outros chamados “mundos virtuais”, como
metaversos e não mais como “mundos virtuais”. Assim, o conceito geral de
metaverso poderia englobar uma estrutura que se apresentasse composta
de três níveis, como o colocado a seguir: (1) mundos virtuais, (2)
protometaversos, (3) metaversos plenos. Os elementos ou características
aqui são cumulativos e progressivos. Vejamos:
Mundos virtuais: eles são constituídos por ambientes imersivos e
navegáveis, podendo ser nos formatos 2D ou 3D. O critério da imersão se
dá pela possibilidade da afirmação do espaço digital, no qual colabora tanto
a qualidade gráfico-visual (tendo o seu limite no fotorrealismo), como a
estrutura da oferta de interação baseada na coerência do próprio ambiente
proposto (no limite inferior o conceito de interface navegável e no limite
superior o conceito de verossimilhança). São eles que apresentam a
proposta de um ambiente para receber o sujeito, a navegação, a interação
como agência e a transformação. Eles não permitem o acesso a uma física
do mundo real ou imaginária.
Protometaversos:
somados
às
propriedades
ontológicas
acima,
os
protometaversos se constituem em ambientes, panorâmicos ou na forma de
ambientes tridimensionais plenos que estabelecem uma relação direta e
subjetiva com o jogador. Eles situam-se na metáfora do mundo real e/ou
possível (verossímil), podendo ter ou não física incluída neles e, quanto
mais o mundo construído propicia um conceito interativo de física (no seu
limite superior com a Sandbox), mais ele se encaminha para o conceito de
metaverso pleno. Nos protometaversos nós temos a entrada dos elementos
da inteligência artificial, a qual representa um dos elementos da autoria
conceitual presentes nele; o jogador interage com agentes inteligentes,
objetos ou NPCs que lhe colocam problemas e interagem positivamente.
Nesse sentido, a organização de uma história que é apresentada ao jogador
é uma necessidade, podendo ela ser aberta, persistente ou não. Um aspecto
restritivo dos protometaversos é que eles sempre são monousuários. Este é
o seu grande elemento diferencial para com os metaversos plenos.
Metaversos plenos: Considerando todas propriedades ontológicas acima, os
metaversos plenos se estruturam a partir da possibilidade da participação
multijogador. Comunicação, relacionamento com outros jogadores, mútua
influência, ação conjunta, dentro de um mundo que oferece uma narrativa
aberta (ou não), porém sempre persistente é o elemento diferencial.
Assim, o conceito geral de Metaverso (inclui): em um nível mais amplo e
elevado os Mundos Virtuais (digitais), os Protometaversos, bem como
Metaversos Plenos:
Definição
Característica
Exemplos
Mundo virtual
Mundos imersivos navegáveis 2D ou
Mundo virtual do Shadow
3D. Podem existir dentro de Metaversos
of the Colossus,
ou em games mono ou multijogador.
mundo virtual do Second
Life, mundo virtual do
Entropia Universe
Protometaverso
real, mas sem suas limitações físicas.
Ilha Cabu,
Labirinto Artístico
Filosófico 1260,
Alletsator,
Série Zork e Série Myst
Característica monojogador.
Heavy Rain, L.A. Noire
Mundos
virtuais
imersivos
nos
Second Life,
Entropia Universe,
Myst Online Uru Live,
WoW
Mundos
virtuais
imersivos
nos
tridimensionais
quais
as
pessoas
interagem somente com agentes de
software, usando a metáfora do mundo
Metaversos Plenos
tridimensionais
quais
as
pessoas
interagem entre si e com agentes de
software, usando a metáfora do mundo
real, mas sem suas limitações físicas.
Característica
multiusuário/multijogador
UMA ARQUEOLOGIA DA QUESTÃO DOS METAVERSOS
A ideia de um espaço navegável e interativo necessita ser estruturada em
uma base conceitual que nos forneça uma plataforma de apoio para nossa
pesquisa. Ela começa com uma arqueologia da questão, para encontrar o
26
seu escopo conceitual sendo retomada pelos autores que tratam do
digital.12
Uma arqueologia da questão remontaria, por exemplo, aos pensamentos de
René Descartes (1596–1650) e Gottfried Leibniz (1646-1716), filósofos que
são considerados precursores do pensamento digital. Em seu célebre livro O
sonho de Descartes, Davis e Herch (1988) apontariam o sonho febril de
Descartes, em 1619, na cidade de Ulm na Alemanha, como o evento que
marcaria a base imaginária do computador. A partir da ideia de
matematização do real, o pensador francês estaria colocando as bases de
seu computador. É nesse sentido que o pesquisador brasileiro, Cléuzio
Fonseca Filho, em seu livro, História da computação (2007), nos diz que a
partir de Descartes surgiu a constante preocupação de minimizar o esforço
repetitivo,
o
qual
traduziu-se
no
desenvolvimento
de
máquinas
(automatons) que possibilitaram a substituição do esforço humano em
tarefas monótonas e cansativas. Mas será em 1666, com o livro “De Arte
Combinatoria“ e a “characteristica universalis” que Leibniz pode ser
entendido como o precursor, não somente da lógica moderna 13 , mas
também dos elementos fundamentais do computador em si e igualmente
como um dos pensadores que lançou as bases de importantes componentes
dos games e metaversos, como por exemplo, a IA – Inteligência Artificial:
“(...) para a História da Computação, tem um particular interesse, pois
esse calculus ratiocinator de Leibniz contém o embrião da machina
ratiocinatrix, a máquina de raciocinar buscada por Turing e depois
pelos pesquisadores dentro do campo da Inteligência Artificial”
(FONSECA FILHO, 2007, p. 51).
Ainda que muitos estudiosos dos fundamentos da computação tenham
referindo-se sistematicamente a Descartes e Leibniz como grandes
precursores, será com o fenomenólogo americano Michael Hein que o tema
será retomado no âmbito do ciberespaço.
A posição de Leibniz, na perspectiva colocada por Heim (1993) de uma
fundação ontológica do ciberespaço é introduzida por Petry (2009), a qual
12
O presente se baseia em uma pesquisa acadêmica do Prof. Dr. Luís Carlos Petry,
a qual resumimos em seus aspectos iniciais e gerais.
13
Especialmente no capítulo 4.2.1 Leibniz, o precursor da Lógica Matemática
moderna
resumimos aqui. A abordagem parte do conceito leibniziano de mônada14.
Uma mônada se constituiria em uma enteléquia possível, uma estrutura
atômica simples, independente e dotada de caraterísticas individualizadas.
Heim identificaria tais estruturas (metafísicas) com as estruturas formativas
do ciberespaço, responsáveis pela organização dos mundos tridimensionais,
“cuja apetência última se expressaria nos metaversos”. Em seu livro The
metaphysics of virtual reality, Heim compara o Calculus universalis de
Leibniz com o sistema lógico atualmente presente nos computadores. Ao
propor esta conjunção metafórica, ele utiliza a expressão linguagem elétrica
de Leibniz15. Tal linguagem elétrica teria uma estrutura e características que
estariam na base do conceito de metaverso. Acompanhamos Petry que
escreve, neste sentido, em sua nota 10, página 4:
“De acordo com as palavras do filósofo: “a “linguagem elétrica” de
Leibniz opera pela emulação da inteligência divina. O conhecimento
divino possui a simultaneidade da omnipresença e, a fim de
estabelecer o acesso divino às coisas, as funções globais da matrix
interligam-se, por meio de uma rede em uma espécie de atual
eterno, entre as lacunas de toda a linguagem. Devido ao acesso que
não necessariamente necessita ser linear, o Ciberespaço, a princípio,
não requer um salto de uma posição a outra ordenadamente. Os
escritores de ficção científica frequentemente imaginaram o que seria
experimentar viajar na velocidade da luz e, um escritor, como Isaac
Asimov,
14
descreveu
esta
viagem
como
um
“salto
através
do
Mônada: A nota 7 do texto de Petry nos diz: “conceito-chave na filosofia
metafísica de Leibniz., o qual designa a substância simples - do grego μονάς,
μόνος, que pode ser traduzido por "único" ou "simples". Como tal, a mônada faz
parte constitutiva do compostos, sendo ela própria porém, sem partes e, portanto,
indissolúvel e indestrutível. O hodierno conceito de pattern possui relações de
parentesco com a Mônada leibniziana”.
15
A teoria das mônadas de Gottfried Leibniz constitui a contribuição mais importante de
Leibniz para a metafísica, expostas em sua obra Mônadologia. As mônadas equivalem para a
realidade metafisica o que os átomos equivalem para os fenômenos físicos. As mônadas são
"formas substancias do ser com as seguintes propriedades: elas são eternas, indecompostas,
individuais, sujeita as suas próprias leis, sem interação mútua, e cada uma refletindo o
próprio universo dentro de uma harmonia pré-estabelecida. Mônadas são centros de forças;
substância é força, enquanto o espaço, extensão e movimento são meros fenômenos. A
essência ontológica das mônadas é sua simplicidade irredutível.Assim como os átomos, as
mônadas não possuem nenhuma matéria ou caráter espacial.Elas ainda se diferenciam dos
átomos por sua completa mútua independência, assim as interações entre as mônadas são só
aparentes.
(Wikipédia.
A
enciclopédia
livre.
http://pt.wikipedia.org/wiki/Gottfried_Leibniz. Acesso em 18 nov. 2011)
Disponivel
em
28
hiperespaço”. Quando, em sua ficção, a nave atinge a velocidade da
luz, Asimov diz que ela realiza um tipo especial do salto. Nessa
velocidade, é impossível seguir os pontos discretos da distância
atravessada por ela” (HEIM, 1993, pp. 95-96)
Como podemos ver, a identificação entre a linguagem elétrica de Leibniz e o
ciberespaço nos ajudam a pensar a questão dos metaversos de um ponto de
vista ontológico.
UMA PERSPECTIVA ONTOLÓGICA DO CONCEITO DE METAVERSO
Para podermos entender a importância da abordagem ontológica do
conceito de metaverso, precisamos inicialmente tomar conhecimento de
dois conceitos importantes que se conjugam e por vezes se sobrepõem. Um
seria o de universo digital e o outro o de ontologia no contexto digital.
O conceito de universo digital refere-se ao conjunto formado pelos recursos
técnicos computacionais, às atividades relacionadas por meio destes em
ferramentas e ambientes simuladores, bem como aos seus resultados
práticos, os quais resultam em objetos os mais variados. O conceito possui
uma perspectiva metafórica e indica aspectos técnicos, sociais, econômicos,
cognitivos e afetivos. O universo digital compõe a totalidade de nossa
atividade mediada pelos dispositivos computacionais, ultrapassando o
âmbito do computador pessoal e abrangendo o todo do ciberespaço, os
consoles de games, a TV interativa, até nossas relações atuais com os
sistemas jurídicos e bancários (PETRY, 2011). No nosso caso, nos
interessam os metaversos e games imersivos que nos permitem explorar o
ambiente a partir da navegação e estabelecer uma série de relações
interativas com outros seres humanos, por meio de avatares ou com seres
programados, os NPCs 16 , constituindo verdadeiros mundos que têm sua
forma virtual de existir e cujos elementos relacionam-se segundo regras
intrínsecas a cada um deles.
De outro lado, a ontologia (em grego ontos e logoi, "conhecimento do ser")
é a parte da filosofia que trata da natureza do ser, da realidade, da
existência dos entes e das questões metafísicas 17 em geral. O conceito
16
non-player characters, personagens não-jogadores
17
Ao dizermos metafísica, (em grego além da física) estamos nos referindo ao modo como
ela é vista inicialmente em Aristóteles.
deriva de uma longa discussão dentro das ideias do Ocidente que têm
origem ainda nas ideias de Platão e nas de Aristóteles quando este último
tratou de uma filosofia primeira, incluindo nela tanto o estudo do ente
enquanto ente, bem como de um ente principal ao qual se subordinavam os
demais. Para Petry, ontologia “consiste no estudo das propriedades gerais
do ser, da sua existência ou realidade” (PETRY, 2011).
O
conceito
de
ontologia
recebeu
inúmeras
formulações,
algumas
discordantes entre si. Uma delas define a ontologia como a ciência do ser
em si, do ser último ou irredutível ou ainda de um ente a partir do qual
todos os demais dependem. Outra formulação do conceito fala da ontologia
como aquela que pensa a determinação daquilo em que os entes consistem
e ainda aquilo em que consiste o ser em si. Nesta última temos uma ciência
das essências que resulta em uma teoria dos objetos.
Petry trabalha esta questão ontológica “a partir do lado da existência ou
realidade que o problema dos entes coloca para nós sob uma perspectiva
ontológica, especialmente quando este ente é o homem”. Quando o ente é
capaz de pensar-se a si mesmo é aberta a porta para propormos a
“independência dos signos em um sistema de elementos e de posições ao
mesmo tempo articuláveis, relacionáveis e capazes de comunicação”
(CAPURRO, 2009).
Ao estudarmos a ontologia temos dois caminhos a seguir, como diz Manuel
Garcia Morente (2006). Um seria o método da análise dialética da noção
mesma de ser. Poderíamos tomar a noção de ser, dirigir a ela nossa atenção
e ir separando, por análise dialética, as diferentes significações da noção
para compará-las intuitivamente com o conjunto da realidade e ver até que
ponto, como e em que sentido, cada uma das distintas significações da
noção de ser tem direito legítimo e possui algum sentido e não é
simplesmente uma palavra. Este é o caminho tomado por Aristóteles na
análise dialética em sua Metafísica. Num dos livros da Metafísica,
justamente o que começa dizendo: "o ser se diz de muitas maneiras",
Aristóteles vai assinalando os distintos sentidos em que se pode tomar o
ser. Mas podemos seguir um segundo método, uma segunda via, que
consistiria em colocar-nos diante da realidade, diante do ser pleno, diante
do conjunto total dos seres, na situação em que a própria vida nos coloca.
Consistirá esse método em destacar-nos e partir de nossa vida atual, de
30
nossa realidade como seres viventes, de nós mesmos tais como estamos
rodeados de coisas, vivendo no mundo. Tal é o ponto de partida de
Heidegger.
Seguindo esta linha heideggeriana, para Petry, os metaversos e games
constituem universos virtuais que devem ser considerados a partir de
pressupostos ontológicos:
“Dentro de uma análise dos contextos de produção de metaversos e
games a partir de pressupostos ontológicos, se reveste da máxima
importância os contextos de fundação construtivos dos próprios
ambientes digitais e seus habitantes, a saber, os metaversos como o
universo em seu conjunto, a partir da ideia de uma physis digital e os
caracteres18 digitais que nele habitam”. (PETRY, 2011)
Baseado nisso, Petry propõe o seu conceito de topofilosofia ao dizer:
“Neste sentido é que postulamos que o trabalho de modelagem
tridimensional para ambientes tridimensionais interativos, tais como
engines de games e metaversos, são atividades reflexivas de alto
nível. Enquanto atividade o ato de modelar um objeto digital
equivaleria ao ato de pensar a coisa enquanto tal, isto em sua
constituição de coisa digital, o que equivaleria a dizer, em uma
linguagem filosófica, que consistiria em pensar a coisa, no próprio
processo de desenvolvimento coisico. Tal possibilidade e atividade,
designada por nós com o termo topofilosofia.” (PETRY, 2003)
Desta forma, a topofilosofia pensa o processo criativo-reflexivo-prático que
está na base da modelagem de mundos, objetos e sujeitos digitais,
organizando-se a partir de uma fundamentação hermenêutica 19 , sendo
18
“caracteres” no sentido da representação de uma personagem em uma narrativa, no caso
aqui como a estrutura tridimensional (meshe) de uma determinada personagem no
metaverso.
19
O termo "hermenêutica" provém do verbo grego "hermēneuein" e significa "declarar",
"anunciar", "interpretar", "esclarecer" e, por último, "traduzir". Significa que alguma coisa é
"tornada compreensível" ou "levada à compreensão". A hermenêutica é um ramo da filosofia e
estuda a teoria da interpretação, que pode referir-se tanto à arte da interpretação, ou a
teoria e treino de interpretação. A hermenêutica tradicional - que inclui hermenêutica Bíblica
- se refere ao estudo da interpretação de textos escritos, especialmente nas áreas de
literatura, religião e direito. A hermenêutica moderna, ou contemporânea, engloba não
somente textos escritos, mas também tudo que há no processo interpretativo. Isso inclui
formas verbais e não-verbais de comunicação, assim como aspectos que afetam a
tomada como conceito chave para o entendimento dos processos digitais
que realizam a ponte entre os processos artísticos e os computacionais.
(PETRY 2006).
Uma das justificativas que Petry utiliza para basear esta relação entre a
modelagem tridimensional de mundos e a ontologia, vem a partir do
trabalho de Heim (1977) quando este coloca como fundamento do
hiperespaço a ontologia das mônadas 20 de Leibniz em uma espécie de
linguagem elétrica aplicando-a inicialmente ao editor de textos, depois à
Web e finalmente a todo o ciberespaço na proposta de uma ontologia na
qual conjuga aspectos da fenomenologia hermenêutica (Heidegger) e da
teoria da comunicação (McLuhan). As mônadas leibnizianas podem ser
perfeitamente identificadas com o 0/1 digital e são, assim, encontradas nos
processos
digitais
que
constituem
a
base
de
todos
os
sistemas
computacionais que compõem o ciberespaço. Esta constatação alia-se ao
fenômeno e processo de digitalização da cultura. Para que qualquer coisa
possa ser transmitida pela web, precisa primeiramente ser digitalizada, isto
é, reduzida a uma lógica binária, para depois constituir novas formas de
organização na web que, por sua vez, podem gerar novas significações para
estes mesmos elementos culturais.
Um outro conceito importante que deve ser utilizado em uma reflexão
ontológica sobre os metaversos é o conceito heideggeriano de instrumento
(Zeug) ou de utensilidade de algo. Trata-se do caráter de ser útil de algo
enquanto instrumento, utensílio ou ferramenta, pois este conceito permite
situar a posição e a relação do sujeito ou ente no digital para com seus
semelhantes, para com os objetos e as entidades com as quais interage, e,
finalmente, para com o mundo digital em geral. Para Petry
“o mundo digital se abre em uma estrutura complexa de relações que
são passíveis de serem pensadas do ponto de vista ontológico e,
derivadas de uma ontosemântica.” (PETRY, 2011).
comunicação, como preposições, pressupostos, o significado e a filosofia da linguagem, e a
semiótica. A hermenêutica filosófica refere-se principalmente à teoria do conhecimento de
Hans-Georg Gadamer como desenvolvida em sua obra "Verdade e Método" (Wahrheit und
Methode), e algumas vezes a Paul Ricoeur. Consistência hermenêutica refere-se à análise de
textos para explicação coerente. Uma hermenêutica (singular) refere-se a um método ou
vertente
de
interpretação.
(Wikipédia.
A
enciclopédia
livre.
http://pt.wikipedia.org/wiki/Hermenêutica. Acesso em 18 nov. 2011).
20
Ver nota 7 sobre a teoria das mônadas de Gottfried Leibniz.
Disponivel
em
32
A questão da fundação monadológica do ciberespaço e dos metaversos
suscita um rico diálogo da questão entre Heidegger, MacLuhan e Marcuse,
isto é, “uma fundação lógica do ciberespaço e dos metaversos em muito
teria a ganhar ao ser pensada à luz de uma fundamentação ontológica do
mundo e do Dasein21” (PETRY, 2011). Este tipo de abordagem permite que
pensemos o estatuto ontológico do ciberespaço e dos metaversos ao
mesmo tempo que podemos “pensar as comunidades de sujeitos que
navegam e interagem, se comunicam e produzem suas transformações no
digital” (MURRAY, 2003) em meio a outras entidades sintéticas e seus
mundos.
A fenomenologia hermenêutica, a história e a etnologia nos ensinam que
este pressuposto pode ser encontrado no conceito de mundo. Ora, se o
pressuposto fundamental é o conceito de mundo encontramos aqui uma
espécie de redundância, pois tanto os metaversos quanto os games são,
cada um à sua vez, mundos constituídos digitalmente. Se isso for correto,
poderemos dizer que somente poderemos estar imersos em um mundo,
seja ele fático ou representacional. Enquanto que o primeiro, o mundo
fático, também chamado de modo ordinário de mundo real, não coloca
problemas para o senso comum, dado que ele nos é diretamente percebido
e conhecido pelos sentidos e pela experiência sensível, o segundo, o mundo
representacional, necessita demonstração.
Ora, dizemos que os mundos representacionais são formados por
representações. Representações são construções presentes em nossa mente
em primeiro lugar, compreendendo todos os nossos pensamentos,
sentimentos, desejos etc., os quais formam uma estrutura complexa que se
apresenta como uma imagem ou uma cena, dependendo da situação ou
sujeito em questão. Mas são representações também aquelas construções
humanas que por fim acabam possuindo uma existência material, tal como
os desenhos, as pinturas, as fotografias, os filmes, etc. (AUMONT, 2004;
GILSON, 2010; GADAMER, 2008; PETRY, 2003). Por outro lado, algumas
experiências realizadas e/ou vivenciadas por sujeitos humanos também
entram no que podemos chamar de campo da representação. É o caso da
experiência da leitura por parte de um sujeito. Ao ler, na mente do leitor
forma-se uma imagem, uma estrutura ou mesmo uma paisagem, a qual é o
21
Dasein entendido como “ser-aí” ou “ser no mundo” é um dos principais conceitos
de Heidegger.
resultado, o vetor derivado da confluência do lido com a mente do leitor (o
conjunto das representações deste). Na literatura dizemos que uma
paisagem ou cena se forma na mente do leitor. Ora, Freud (1900)
acrescentou a este campo os sonhos, isto quando mostrou que estes
constituíam uma Outra Cena para o sujeito da consciência. Ao relacionar o
pensamento de Freud com as novas tecnologias e a hipermídia, Petry (2001)
mostrou que os ambientes tridimensionais interativos possuíam um
funcionamento homólogo ao descrito por Freud para o sonho. Esta ideia já
havia sido anteriormente apresentada pelos surrealistas no campo da arte
quando mostravam que a produção artística constitui-se em uma produção
onírico-automática (AGRA, 2004). Em primeiro lugar é o que visualizamos
na abordagem de Salvador Dalí, ao desenhar uma Cena-Sonho, intitulada La
ville de tiroirs (A cidade das gavetas), conforme a imagem a seguir:
Figura 7 – La Ville de Tiroirs – Salvador Dalí
Do ponto de vista do mundo real, a imagem constitui-se em um semsentido. Pois é justamente este aspecto do seu sem-sentido ou não-senso
que lhe conferem um alto nível de representação, pois apresenta uma cena
onírica, na qual o corpo humano apresenta-se como metáfora para os
segredos: o corpo é um armário de segredos. Ora, Petry (2001) utiliza esta
imagem para abrir a possibilidade de compreendermos as estruturas
tridimensionais
dos
mundos
virtuais
como
mundos
ou
cenas
34
representacionais.
A
fim
de
fundamentarmos
a
ideia
de
mundo,
representação, ambientes virtuais e imersão, acompanharemos o trabalho
realizado por Petry (2001) na perspectiva do digital, em um momento no
qual ele ainda não havia proposto a ideia de uma topofilosofia.
É neste sentido que ele nos oferece duas imagens como suporte
explicativo-visual de sua abordagem.
Figuras 8a e 8b - A correlação entre o arame e a imagem. Imagem “xicaras_4.jpg” Fonte: (PETRY 2001)
Petry faz uma analogia entre o sonhar e a modelagem tridimensional. Para
ele, “assim como todo arame tridimensional, todo sonho possui uma
estrutura”. Quando um sujeito começa a contar seu sonho, começa por
estabelecer via linguagem uma estrutura espacial em que os seus elementos
estão inseridos e estabelece as relações entre estes. Isto ajuda aqueles que
ouvem a remontar esta estrutura dentro de si e imaginar a cena. No caso de
uma imagem tridimensional montada por meio de vetores em um software
3D, inicialmente o que podemos ver é uma estrutura bastante clara de
arames (figura 8a) constituída por vértices e faces bastante organizados que
constituem os objetos da cena. A significação da cena, tanto nos sonhos
como nas imagens 3D se dá pelo contexto que estas cenas montam. No
caso da figura acima, temos duas xícaras absolutamente iguais do ponto de
vista do número de vértices e de faces. Uma foi criada a partir da outra.
Entretanto, apesar de idênticas o seu significado é completamente diverso.
Uma está em pé, cheia de café. A outra está vazia e deitada em cima do
pires, como se alguém já tivesse tomado o café que estava em seu interior.
Na segunda figura (figura 8b) já renderizada, é possível ver as texturas e o
jogo de luz e sombras a que cada objeto é submetido. Nas palavras de
Petry:
“Ambos objetos são idênticos em todos os seus aspectos formais
computacionais. No entanto, guardam eles uma secreta diferença que
se revela quando observamos a imagem gerada: posição, luz e
sombra na revelação da diferença do contexto de sentido que há
entre as xícaras, para além de sua identidade formal” (PETRY, 2001)
O mesmo elemento, ao ser colocado em uma outra posição, sob outra luz e
sombra adquire um novo significado, representando algo completamente
diverso apesar de estruturalmente continuar sendo essencialmente o
mesmo. O objeto adquire uma função que lhe dá um novo significado
segundo seu posicionamento relativo aos outros objetos dentro da cena,
bem como no modo pelo qual a luz e as sombras aparecem sobre eles.
Figura 9 - A sala de James Owen - imagem renderizada – (PETRY 2001)
Ao realizar uma análise comparativa entre os processos do sonho e os
processos da produção tridimensional de cenas para ambientes virtuais,
Petry destaca o caráter hiper-realista que existe em ambos os mundos, o
mundo do sonho e o mundo do tridimensional. Como exemplo mostrativo,
ele apresenta a modelagem de uma sala metafísica, apresentada na Figura 9
intitulada Sala de James Owen. Em sua estrutura, a sala apresenta
componentes essenciais na sua formação, os quais podem ser encontrados
tanto em uma Cena dos Sonhos, bem como na imagem tridimensional da
mesma. Estes elementos manifestam-se pela luminosidade e textura que
36
conferem ao ambiente tanto a sua forma plástica como o tônus emocional
da cena, conferindo um certo ar de mistério metafísico.
Tanto nos sonhos como nos ambientes 3D existe uma construção
subjacente que dá o significado ao todo e a cada elemento individual da
cena. Aliás, se na produção em modelagem tridimensional ela chama-se
“cena”, no sonho poderíamos chama-la de “significação” ou “sentido”. Petry
explica esta construção cheia de significado em uma perspectiva freudolacaniana, e afirma que este contexto de produção de sentido está ligado a
uma historicidade: “Esta historicidade será a historicidade do sujeito
produzido como o efeito necessário dentro da rede dos significantes que o
constituem como falante dentro de um sistema”. (PETRY, 2001)
As relações internas do sonho estão submetidas a determinadas funções. E
quais
seriam
estas
grandes
funções
sempre
presentes?
Seriam
principalmente as leis internas ou as leis de formação do sonho de Freud no
livro Traumdeutung (A interpretação dos sonhos), em especial os conceitos
de deslocamento e condensação.
Em uma resenha dos 100 anos da publicação do livro “A interpretação dos
sonhos” de Freud, o psicanalista Augusto Cesar Freire faz um apanhado dos
mecanismos descritos por Freud (FREIRE, A. C., 2000), explicando os
mecanismos mencionados por Petry. Segundo Freire, a tese central do livro
de Freud é a de que "O sonho é a realização de um desejo". Este desejo não
é necessariamente um desejo que possamos aceitar em nossa vida vigil.
Quando não se trata de um desejo aceitável, diz Freud, preferimos esquecêlo. Este esquecimento será descrito como consequência de um mecanismo
chamado 'recalque'. No inconsciente, este desejo vai procurar sua expressão
a qualquer custo. Se não é possível que ele se expresse conscientemente,
vai buscar alguma expressão substitutiva que consiga escapar à censura. O
sonho pode ser entendido como a expressão de uma série de desejos que
encontram nele a única via para a consciência. É por isto também que o
sonho será entendido por Freud como a via régia para o inconsciente, uma
vez que é sua manifestação mais direta. Aos processos que ocorrem no
inconsciente
Freud
chama
processos
primários,
em
oposição
aos
secundários, do consciente. Freud apresenta, então, o mecanismo de
trabalho dos sonhos e o funcionamento do aparato mental. O primeiro seria
o mecanismo de “deslocamento”, que preconiza a possibilidade que as
ideias têm, no inconsciente, de “emprestar” seu valor para outras ideias. Se
o psiquismo não pode representar diretamente uma ideia por conta do seu
processo de repressão, recorre a uma representação e transfere-a para
outra ideia ou imagem associada. O “deslocamento” acontece quando uma
representação tem algo em comum com a representação anterior. Assim,
fatos ou imagens aparentemente sem importância compõem o material do
sonho, mas se estudados a fundo mostrarão a ideia original que os gerou,
esta sim, de grande importância.
Um exemplo dado por Freud é o do
pequeno Hans que tinha medo de cavalos. Freud descobriu que o jovem
tinha uma representação negativa do pai e deslocou essa representação
para outra – o medo dos cavalos. No sonho há também em funcionamento o
mecanismo da “condensação”. Este mecanismo permite que um pequeno
detalhe possa representar uma ideia completa. Nos exemplos de Freud
vemos como características isoladas de uma pessoa podem representá-la
por inteiro ao se compor com outras características que representam outras
pessoas. Assim, um personagem pode estar ocupando a função de toda
uma multidão de personagens que não figuram no sonho senão por
fragmentos.
Para Freud, a “condensação” procura não só concentrar os pensamentos
disseminados do sonho formando unidades novas, mas também criar
compromissos e meios termos entre diversas séries de representações e de
pensamentos. A condensação, pelo seu trabalho criativo, dir-se-ia mais
apropriada do que outros mecanismos para fazer emergir o desejo
inconsciente, frustrando a censura, mas ao mesmo tempo torna mais difícil
a leitura do texto manifesto do sonho. Podemos dizer então que a
“condensação” assemelha-se a uma metáfora e o deslocamento a uma
metonímia.
Voltando a Petry e sua metáfora comparativa entre a modelagem
tridimensional e o sonho, vemos que é possível visualizar nos processos
complexos,
aos
quais
os
objetos-arame
da
modelagem
3D
estão
submetidos relações metodológicas com os processos que sustentam a vida
onírica, como por exemplo, o deslocamento e a condensação. Como
exemplo, Petry faz um paralelo entre o deslocamento e o processo de
“morphing” de um objeto tridimensional ao transformarmos um objeto 3D
em outro diferente, contanto que o número de vértices permaneça o
mesmo. Este processo, baseado nos algoritmos de Boole, faz com que, por
exemplo, no cinema, uma personagem tenha sua cabeça aumentada de
tamanho ou o aspecto de sua face seja totalmente modificado aparentando
ser outra pessoa. Petry termina seu texto dizendo que “toda a vida anímica
do sujeito está baseada na percepção e na transformação da experiência
vivida em todos os sentidos, dentro do âmbito da linguagem que nos
engloba, nos circunda e nos determina” (PETRY, 2001)
38
A metáfora de Petry entre o sonho e a modelagem tridimensional não
poderia terminar de outra forma que não pela questão da linguagem. Se na
Psicanálise os sonhos são trabalhados de maneira artificial pela linguagem
de modo a mostrar aquilo que está no inconsciente para por a nu a sua
estrutura última, na modelagem tridimensional esta estrutura está dada,
mas a forma, a função e sua natureza são questões a desvendar. Na
verdade, se considerarmos que autores como Lúcia Santaella e Sergio Bairon
consideram a hipermídia uma nova linguagem, a metáfora de Petry não
poderia ser mais oportuna.
No livro Matrizes da Linguagem e Pensamento, Lucia Santaella diz que:
“Propiciada, entre outros fatores, pelas mídias digitais, a revolução
tecnológica
que
estamos
atravessando
é
psíquica,
cultural
e
socialmente muito mais profunda do que foi a invenção do alfabeto,
do que foi também a revolução provocada pela invenção de
Gutemberg. É ainda mais profunda do que foi a explosão da cultura
de massas com seus meios técnicos mecânico-eletrônicos de
produção e transmissão de mensagens. Muitos especialistas em
cibercultura não têm cessado de alertar para o fato de que a
revolução teleinformática, também chamada de revolução digital é
tão vasta a ponto de atingir proporções antropológicas importantes,
chegando a compará-la com a revolução neolítica. Para se ter uma
ideia das consequências trazidas por esta revolução, basta dizer que
a nova ordem econômica, social e cultural mundializada não seria
possível sem ela. (SANTAELLA, 2000, p. 389)
Esta revolução teve início com a proposta teórica do hipertexto, ainda na
década de 1940. Historicamente, a estrutura e a ferramenta do hipertexto
estão ligadas a Vannevar Bush 22 , que formulou a ideia de que a mente
humana opera por associação. A partir de um conceito, ela pode saltar
imediatamente para outro por meio de uma associação de pensamentos.
Este conceito foi aplicado como base da internet, constituindo os sistemas
de hipertexto, organizando as informações de maneira lógica e superando a
maneira sequencial, anteriormente dominante, permitindo saltos de um
documento a outro com base em associações de conteúdo. Esta modificação
já havia representado uma ruptura bastante importante, pois estabelecia
uma forma não linear de escritura e permitia leituras não sequenciais
22
BUSH, Vannevar. (1945) “As we may think” ln: Nelson, Theodor. Literary
Machines. Sausalito, Mindful Press
abrindo um leque de possibilidades. O hipertexto deu muito mais poder aos
leitores para que pudessem escolher o que leriam a seguir, pois não eram
obrigados a seguir uma linha única. Esta foi a primeira revolução. Os
leitores poderiam fazer seu próprio caminho. Já no início da internet esta
forma de relacionar-se com os textos criou uma nova forma de literatura na
internet que permitia aos leitores, pela simples escolha de um hiperlink ou
outro, decidir quais atitudes uma personagem deveria tomar dentro de um
momento da história e podendo experienciar diferentes linhas narrativas
que produziriam finais diferentes.
Se ainda no contexto da web 1.0 o hipertexto já havia produzido uma série
de modificações na forma de agir e de pensar, com o aperfeiçoamento da
web 2.0 e a fusão de todas as mídias na internet, a saber, imagem, vídeo,
som e tecnologia 3D, o que viemos a
chamar
hipermídia, estas
transformações foram potencializadas de maneira antes inimaginável. Na
hipermídia, a forma e a função de um objeto estão intimamente ligadas ao
seu significado.
PANORAMA HISTÓRICO : JOGOS MULTIJOGADOR E JOGOS
MULTIJOGADOR EM REDE
A seguir procuraremos resgatar um pouco do histórico dos jogos
multijogador desde os seus primórdios nos primeiros jogos eletrônicos até
os mais recentes MMOs – Massive Multiplayer Online Games - mostrando a
trajetória destes sistemas até hoje. Não vamos fazer um histórico exaustivo
com todos os games, mas apenas com relação àqueles que tiveram alguma
importância para o contexto do advento dos metaversos.
1. A DISTINÇÃO ENTRE “GAMES EM REDE” E “GAMES
MULTIJOGADOR”
Hoje em dia os conceitos de “games em rede” e de “games multijogador”
podem parecer sinônimos, mas, na verdade, não o são. É importante
analisarmos mais de perto o que cada um destes dois conceitos realmente
significa. Por definição, um game em rede necessariamente inclui uma rede
de computadores trabalhando, isto é, uma conexão digital entre dois ou
mais computadores (ARMITAGE et al., 2006, p. 5). Neles, os jogadores estão
fisicamente separados, cada um em uma máquina que pode estar na mesa
ao lado ou a centenas de quilômetros de distância, mas todos estão
40
conectados em uma mesma rede. No entanto, existem games multijogador
que não são games em rede. Existem jogos eletrônicos multijogador mais
antigos em que um jogador joga primeiro enquanto o outro assiste e,
depois que aquele “morre”, o outro jogador assume dali. Outros jogos mais
recentes, como o Boxe do Wii (figura 10), fazem com que dois jogadores
possam jogar simultaneamente, um contra ou outro. A tela é dividida em
dois e cada jogador pode ver seu avatar na sua parte da tela lutando contra
o avatar do outro. Podemos dizer que trata-se de um jogo multijogador no
sentido de que dois jogadores podem jogar ao mesmo tempo, mas não é
um jogo em rede. Deste modo, a área de games multijogador inclui jogos
que não são jogos em rede.
Figura 10 - Alguns jogos multijogador não são jogos em rede. Este é o caso de jogos esportivos como o
Don King Boxing para o Nintendo WII.
Da mesma forma, alguns jogos em rede não são jogos multijogador. Em
alguns deles uma rede é utilizada para acessar um servidor remoto que
controla o jogo, mas este é para apenas um jogador que não vai ter
interação com outros. Exemplos deste tipo são alguns jogos antigos que
funcionavam em rede porque utilizavam um mainframe 23 para funcionar.
23
Computador de grande porte.
Toda a programação ficava no mainframe e os jogadores faziam o login a
partir de um terminal, mas cada jogador jogava sozinho.
Resumindo, os domínios dos jogos em rede e o dos jogos multijogador
podem sobrepor-se em alguns casos, mas os dois tipos não são sinônimos
e “nenhum dos dois contém ou está contido no outro” (ARMITAGE et al.,
2006, p.6).
2. OS PRIMEIROS JOGOS MULTIJOGADOR
A seguir, vamos estudar alguns dos primeiros jogos multijogador do início
da história dos jogos eletrônicos e sua importância para o advento dos
metaversos.
TENNIS FOR TWO: O PRIMEIRO JOGO ELETRÔNICO MULTIJOGADOR
O primeiro jogo eletrônico multijogador surgiu
em 1958, quando William A. Higinbotham (figura
11) usou um osciloscópio para simular um jogo
virtual
de
tênis.
O
Tennis
for
Two
24
(Higinbotham 1958) permitia que dois jogadores
jogassem um contra o outro no monitor do
osciloscópio. Apesar de definitivamente ser um
jogo multiusuário, o “Tênis para dois” utilizava
um sistema de circuitos e o osciloscópio, mas
Figura 11 - W. Higinbotham o
não utilizava um computador propriamente dito.
inventor
O jogo baseava-se em um programa de cálculo
do
jogo
eletrônico
multiusuario Tennis for Two.
de trajetórias que o exército americano usava na
época. Consistia em uma “Bouncing Ball” controlada por circuitos eletrônicos
e conectada a um osciloscópio que funcionava como dispositivo de saída. A
visualização representava uma quadra de tênis de um ponto de vista lateral
por meio de uma reta horizontal e uma linha perpendicular no seu ponto
médio para representar a rede. Um ponto azulado representava a bola que
traçava trajetórias na tela redonda do osciloscópio. (figura 12)
24
Para amostra de Tennis for Two ver
http://www.youtube.com/watch?v=6PG2mdU_i8k
42
Figura 12 - O osciloscópio que servia como dispositivo de saída para o jogo.
Higinbotham preparou dois joysticks metálicos que utilizavam um botão
giratório para definir o ângulo com o qual a bola deveria ser acertada, e um
botão que, ao ser pressionado, fazia com que a bola fosse rebatida para
tentar acertar o campo do adversário (figura 13).
Figura 13 - William Higinbotham também criou o primeiro joystick da história por ocasião do projeto
Tennis for Two.
SPACEWAR: O PRIMEIRO JOGO MULTIUSUÁRIO POR COMPUTADOR
O primeiro jogo multiusuário que efetivamente utilizou um computador foi
o Spacewar (figura 14) criado em 1961 em um computador mainframe PDP1 no MIT por Steve Russell. A intenção inicial era mostrar a capacidade do
mainframe em realizar atividades complexas com gráficos até então não
realizadas por outros mainframes. No Spacewar, dois jogadores duelavam
um contra o outro usando dois foguetes que lançavam torpedos25. O jogo
não possuía som ou qualquer efeito de partículas, mas já mostrava o quanto
o jogo eletrônico poderia ser viciante mesmo sem gráficos muito
sofisticados. Mais tarde, seus programadores começaram a incluir gravidade
e mapas estelares sofisticando um pouco mais o gameplay.
Figura 14 - O primeiro jogo de computador multiusuário foi o Spacewar do MIT em 1961. A foto da
direita mostra o mainframe em que era baseado.
O SISTEMA PLATO - OS PRIMEIROS JOGOS MULTIJOGADOR VIA
MAINFRAME 26
“Duas décadas antes da World Wide Web entrar em cena, o sistema
PLATO já era pioneiro com fóruns online e message boards, e-mail,
salas de chat, mensagens instantâneas, compartilhamento de telas
remotas e games multijogador, liderando a emergência do que talvez
25
Para amostra do Spacewar ver http://www.youtube.com/watch?v=Rmvb4Hktv7U
26
O termo “mainframe” se refere a computadores de grande porte que têm grande
capacidade de processamento e uma normalmente uma arquitetura em estrela. Um
poderoso servidor central serve a muitos terminais.
44
tenha sido a primeira comunidade online do mundo.”27 (WOOLLEY,
1994)
Provavelmente a primeira comunidade online do mundo foi organizada em
torno do sistema PLATO (Programmed Logic for Automated Teaching
Operations). O PLATO teve início na University of Illinois em 1960 e aos
poucos
ganhou
apoio
do
governo
dos
EUA
e
adesão
de
outras
universidades. Nos anos 1970 já tinha adquirido tal preeminência que era
utilizado em quase doze mainframes espalhados pelo mundo, somando
alguns milhares de terminais de uso. O PLATO era um sistema baseado em
mainframe em que os usuários interagiam ao fazer login por meio de
terminais. Inicialmente criado com o propósito de realizar “instrução
assistida por computador”, o projeto PLATO foi sendo desenvolvido e
passou a incluir uma série de elementos que suplantaram sua função inicial.
Possuía mecanismos de comunicação tais como e-mail e chat e diversos
games online foram criados para ele durante os 40 anos em que existiu.
Teve diversas versões, do Plato I ao Plato V, que foram ficando cada vez
mais sofisticadas (as últimas possuíam até alguns elementos básicos de
multimídia). As ferramentas de comunicação e os games que possuía
formaram a base de uma comunidade online espontânea28 de milhares de
usuários do PLATO, que durou por mais de vinte anos (WOOLLEY, 1994).
Diversos jogos multijogador foram desenvolvidos para o PLATO29 durante a
década de 1970 e 1980, tais como Empire (um game multiusuário baseado
na série Jornada nas Estrelas), Airfight (um precursor do Microsoft Flight
Simulator), Panther (um jogo de gráficos vetoriais baseado em um tema de
tanques de guerra, precursor do BattleZone da Atari), e diversos games
como o role-playing game Dungeons & Dragons (DnD) de 1975. Estes, e
27
No original: “Two decades before the World Wide Web came on the scene, the
PLATO system pioneered online forums and message boards, email, chat rooms,
instant messaging,
remote screen sharing, and multiplayer games, leading to the
emergence of what was perhaps the world's first online community.”
28
Um vídeo no YouTube mostra uma discussão em 2010 sobre a comunidade de
usuários do PLATO muito antes da criação da Internet e os fenômenos típicos das
comunidades multiusuário que já aconteciam na época e que se repetem hoje com
as comunidades virtuais na internet. Veja: http://youtu.be/qmuN_RpXn6I
29
Lista de games desenvolvidos para o PLATO e detalhes sobre o seu gameplay.
Wikipedia http://en.wikipedia.org/wiki/Category:PLATO_games
alguns outros mais, pressagiavam os MUDs30 assim como os populares first
person shooters 31 como Doom e Quake, também MMORPGs como o
Everquest e World of Warcraft. O jogo Avatar, foi o game mais popular do
PLATO e um dos primeiros MUDs lançados no mundo, somando mais de um
milhão de horas de uso.
Figura 15 - Um terminal do PLATO V em 1981 com uma tela do Game Empire baseado na série Jornada
nas Estrelas
Todos os games para o PLATO somente eram em rede no sentido em que
eram jogados por meio de um terminal conectado ao mainframe. A
arquitetura do game era composta por terminais e toda a computação e
comunicação entre os avatares acontecia no servidor. A performance da
rede dos primeiros sistemas era, assim, determinada pela comunicação do
terminal com o servidor do mainframe via protocolo do programa Telnet
(padrão RFC 854). A conexão Telnet usava conexão TCP (Transmission
Control Protocol) para transmitir os dados que os usuários digitavam com
informações
de
controle.
Cada
tecla
digitada
era
30
MUDs - Multi-user Domains ou Multi-user dungeons.
31
FPS - First Person Shooters - Jogos de tiro em primeira pessoa.
processada
46
individualmente pelo mainframe central e a resposta (ou "eco") mostrada no
monitor do terminal era quase instantânea. (Woolley, 1994) Entretanto, uma
tela completa de um MUD, por exemplo, poderia demorar até 10 segundos
para carregar na tela do terminal.
ADVENTURE E ZORK: GAMES PRECURSORES DOS MUDS
Apesar
plataforma
da
importância
PLATO
desenvolvimento
e
para
da
o
disseminação
dos MUDs, a origem dos MUDS tem
como base dois jogos anteriores: O
Adventure e o Zork (BARTLE, 1990).
Muitos dizem erroneamente que foi
Zork que introduziu o mundo nos
adventure games, mas, na verdade,
Figura 16 - Colossal Cave Adventure: o primeiro jogo
de aventura em texto na tela de um terminal do minicomputrador PDP-10.
foi Colossal Cave Adventure ou
simplesmente Adventure o primeiro
jogo de aventura por computador
em texto (JERZ, 2007).
Figura 17 – Tela inicial do jogo Colossal Cave Adventure
Diz a lenda que Adventure foi criado em 1975 por Will Crowther,
inicialmente simplesmente para entreter suas filhas em dias em que elas o
visitavam, já que era separado. O assunto do jogo não era por acaso já que
Crowther e sua ex-esposa eram espeleólogos e viviam mapeando novas
cavernas no estado de Kentucky nos EUA antes de separarem-se (JERZ
2007). “Adventure" foi o primeiro da série de games baseados em texto que
surgiriam a partir de então que enfatizavam exploração, puzzles e tinham
uma história de narrativa fantástica. O tema das cavernas e mundos
subterrâneos passou a ser uma constante na vasta maioria dos games em
texto dali em diante. O jogo foi depois ampliado significativamente em
1976 por Don Woods da Stanford University, que incluiu uma série de novos
elementos ao original de Crowther.
O jogador interagia com o jogo por meio de comandos em texto de duas
palavras, por exemplo, “OPEN BOX”, ”GET ROD”, “GO SOUTH”. A cada
comando, um novo ambiente era descrito em texto e o jogador podia
decidir que nova ação tomar (figura 17).
Tim Anderson (1985) ao falar sobre a História de Zork, conta que:
“No início de 1977, Adventure simplesmente “varreu” a ARPAnet 32 .
Embora Willy Crowther fosse o autor original e Don Woods tivesse
ampliado o game, este último inadvertidamente liberou o código do
jogo na rede. Quando Adventure chegou ao MIT, a reação foi típica:
depois de todo mundo ter gasto muito tempo não fazendo nada a
não ser tentar resolver o jogo (estima-se que Adventure fez toda a
indústria
da
computação
se
atrasar
em
duas
semanas),
os
verdadeiros lunáticos começaram a pensar sobre como poderiam
fazê-lo melhor. Adventure for escrito em FORTRAN, então, não podia
32
ARPANet, acrônimo em inglês de Advanced Research Projects Agency Network
(ARPANet) do Departamento de Defesa dos Estados Unidos da América, foi a
primeira rede operacional de computadores à base de comutação de pacotes de
dados. Foi criada entre 1969 a 1972 e é considerada o embrião da Internet que
conhecemos hoje. A rede entrou no ar em dezembro de 1969, inicialmente com
apenas 4 nós, que respondiam pelos nomes SRI, UCLA, UCSB e UTAH e eram
sediados, respectivamente, no Stanford Research Institute, na Universidade da
California, na Universidade de Santa Barbara e na Universidade de Utah, nos EUA.
Eles eram interligados através de links de 50 kbps, criados usando linhas
telefônicas dedicadas, adaptadas para o uso como link de dados. A rede cresceu
rapidamente e em 1973 já interligava 30 instituições, incluindo universidades,
instituições militares e empresas. (Morimoto 2011).
48
ser tão difícil assim. Ele aceitava somente comandos de duas
palavras, e era obviamente difícil de mudar.”
Inspirados pelo game Adventure, Dave Lebling, Marc Blank, Tim Anderson, e
Bruce Daniels, um grupo de estudantes do M.I.T., escreveram Zork em 1977
para o minicomputador PDP-10. A primeira versão de Zork também tornouse bastante popular na ARPAnet. Uma versão do Zork chamada DUNGEN foi
mais tarde desenvolvida em FORTRAN e copiada para diversos outros
computadores de outras localidades.
Zork inovou em relação ao Adventure, cujos comandos possuíam apenas
duas palavras (verbo-substantivo), ao fazer com que também incluíssem
conjunções e preposições. Por exemplo, um comando que em Adventure
seria apenas “OPEN BOX” ou “KILL SNAKE”, em Zork poderia ser “OPEN BOX
WITH GOLDEN KEY”, “KILL SNAKE WITH ELVISH SWORD”, ou combinações
muito mais complexas e ricas como: "PUT THE LAMP AND SWORD IN THE
CASE ", "LOOK UNDER THE RUG", e "DROP ALL EXCEPT LANTERN ". O jogo
entende vários verbos incluindo "take", "drop", "examine", "attack", "climb",
"open", "close", "count" e muitos outros.
Alguns comandos em Zork
> n, s, e, w
Abreviação de "go North", "go South” etc.
> nw, ne, sw, se
Abreviação de "go North West", "go South West" etc.
> u, d
Abreviação de "go up" e "go down"
>i
Mostra o inventário do jogador
> verbose
Mostra descrições completes de cada comando
> score
Mostra a pontuação, número de movimentos e o ranking do jogador
Três dos programadores originais de Zork juntaram-se a alguns outros
para fundar a Infocom em 1979. Já na nova empresa, adaptaram o Zork que
havia sido produzido para o minicomputador PDP-10 para funcionar nos
microcomputadores populares da época como o Apple II, o Commodore 64,
o Commodore Plus/4, o Atari de 8-bits, o TRS-80, sistemas CP/M e o IBM
PC.
“You are standing in an open field west of a white house.” (Você está em pé
em um campo a oeste de uma casa branca). Com estas linhas de abertura
começava Zork I: The Great Underground Empire, um dos mais famosos
jogos de computador lançado em 1980. Foi assim que surgiu a trilogia Zork
I-III, a trilogia de games mais popular da época. Assim como o Adventure, o
Zork original e a trilogia Zork I-III eram feitos para apenas um jogador. (JERZ
2007)
Adventure, Zork e diversos outros teriam um impacto cultural significativo
no final dos anos 1970 e um impacto comercial significativo no início dos
anos 1980 e foram fundamentais para a criação de uma nova modalidade de
games de aventura, os MUDs, que seriam criados para múltiplos jogadores.
Anos depois, a partir de 1993, novos jogos da série inovariam mais uma vez
com jogos de aventura gráficos que provocariam novos impactos no mundo
dos games e representariam mais um passo importante para o advento dos
metaversos, como veremos adiante.
OS MUDS – MULTIPLE USER DUNGEONS OU MULTIPLE USER DOMAINS
Os MUDS, que em português significariam “Masmorras Multiusuário” ou
“Domínios Multiusuário”, ficaram populares pouco depois que o sistema
PLATO adquiriu notoriedade.
O primeiro MUD - Multi-User Dungeon era simplesmente chamado de
“MUD” e foi escrito em 1978 por Roy Trubshaw, um estudante da Essex
University na Inglaterra, originalmente na linguagem MACRO-10 para um
computador DECsystem-10. O “MUD” foi o primeiro adventure game a
suportar múltiplos jogadores. O nome foi escolhido parcialmente como um
tributo à variante DUNGEN do Zork, que Trubshaw tinha adorado jogar. O
sucesso do game acabou promovendo a criação uma série de outros games
semelhantes no meio universitário.
Os MUDs são, na verdade, sessões de chat que proporcionam um ambiente
virtual em que usuários podem interagir com o mundo e uns com os outros.
50
Compreendem uma estrutura navegável com elementos de gameplay em
que existem uma multiplicidade de “locais” para os quais os jogadores
podem mover-se e interagir, como em Adventure e Zork. Podem incluir
armadilhas, puzzles33, encantamentos e até mesmo um tipo de economia
peculiar ao MUD (ARMITAGE et al. 2006). Os primeiros MUDS tinham
interfaces somente em texto, em que os usuários digitavam comandos
básicos utilizando verbos, substantivos, conjunções e preposições assim
como em Zork (figura 18). Os usuários podiam incluir mais estruturas ao
mundo adicionando mais conteúdo à base de dados principal do MUD. Esta
natureza “open source” dos MUDs fez com que fossem cada vez mais
populares no mundo acadêmico. Os primeiros MUDs foram uma inspiração
importante para os games multiusuário em rede posteriores.
Um dos MUDs mais populares foi o “DnD” ou Dungeons and Dragons”. O
Dungeons and Dragons foi originalmente um RPG Role Playing Game (offline), que fez muito sucesso entre universitários americanos entre o final da
década de 1970 e início da de 1980 (TURKLE, 1995 p. 18), que recriava um
mundo de batalhas medievais e elementos fantásticos. A herança dos games
Adventure e Zork associada às experiências do jogo de RPG (off-line)
Dungeons and Dragons foram transpostas para o mundo dos computadores
com a criação do MUD DnD.
Figura 18 - Tela de um dos primeiros MUDs, semelhante a Adventure e Zork.
33
Preferimos utilizar o termo “puzzle” em inglês pois o termo “quebra-cabeça” não
reflete na totalidade o que um “puzzle” significa. Os puzzles são jogos em que os
jogadores devem resolver um problema ou um enigma proposto.
Os MUDs baseavam-se em uma arquitetura cliente-servidor (Figura 19) em
que um administrador do MUD disponibilizava o servidor e os jogadores
conectavam-se
com
este
através
de
um
programa
cliente
Telnet,
inicialmente por meio de um terminal. A desvantagem do Telnet era que ele
nem sempre funcionava adequadamente. Enquanto alguém estivesse
escrevendo um comando, mensagens novas poderiam entrar e atrapalhar.
Aos poucos outros aplicativos cliente para MUDs foram sendo criados,
proporcionando melhorias tais como o uso de novas fontes e outras novas
capacidades que enriqueceram a comunicação entre os jogadores.
Figura 19 - Topologia cliente/servidor básica utilizada pelos MUDs iniciais. Os terminais eram
conectados a uma rede, mas todo o processamento era feito no servidor, um mainframe ou
minicomputador. (Fonte: ARMITAGE et al., 2006, p.10)
ARCADE GAMES OU JOGOS MULTIJOGADOR DE FLIPERAMA
Profundamente influenciado por Spacewar, Nolan Bushnell, estudante de
engenharia da Universidade de Utah, teve a ideia de criar máquinas de
fliperama com jogos eletrônicos do tipo Spacewar em que as pessoas
pudessem pagar para jogar. Começou com o projeto “Computer Space”
fazendo uma adaptação do Spacewar.
Diz a lenda que transformou o
quarto de sua filha em um laboratório para fazer o primeiro protótipo do
Computer Space (Figura 20). Conseguiu vender a ideia para uma empresa
chamada Nutting Associates, que o contratou para supervisionar a
fabricação das primeiras 1500 máquinas.
52
O Computer Space, de 1971, foi o primeiro jogo multiusuário por
computador usado comercialmente como máquina de fliperama. O monitor
do Computer Space não passava de uma televisão P/B de 13 polegadas
acoplada a um totem de fibra de vidro. Possuía uma placa com a parte
eletrônica e botões de controle, latas de tinta adaptadas eram utilizadas
para recolher as moedas inseridas pelos jogadores. As máquinas foram
produzidas e instaladas em diversos locais, mas os jogadores acharam o
jogo difícil de jogar. Bushnell tentou criar mais alguns jogos sem sucesso e
acabou saindo da Nutting.
Figura 20 - Computer Space, de 1971, foi o primeiro jogo multiusuário por computador usado
comercialmente como máquina de fliperama.
Em 1972, Nolan Bushnell fundou a Atari com o intuito de continuar seu
trabalho e montar máquinas de fliperama que funcionassem com moedas.
Um dos primeiros jogos produzidos pela Atari foi o Pong (Figura 21), uma
versão aperfeiçoada do “Tênis para dois” de Higinbotham, que funcionava
com moedas. O Pong foi o primeiro videogame multijogador comercial de
sucesso.
Figura 21 - Pong - O primeiro jogo de fliperama multiusuário de sucesso
Nos anos 1970 houve um grande
crescimento dos jogos de computador,
e os jogos de fliperama ganharam cada
vez mais projeção. Com eles, novos
estilos de ação multijogador. Um jogo
que vale mencionar foi o Football da
Atari, baseado no futebol americano. A
Atari criou um jogo inicialmente para
dois jogadores e depois para quatro em
que a tela ficava na horizontal como se fosse o campo. No para quatro
jogadores, os controles ficavam em cada um dos quatro cantos do campo
(figura 22).
Figura 22 – O Atari Football para 2 jogadores e para 4 jogadores.
54
JOGOS ONLINE HOSPEDADOS EM SERVIDOR
Nos anos 1980 a ideia de “pay for play” ou pagar para jogar começou a
emergir. Diversas empresas cobravam uma taxa mensal para que as pessoas
pudessem jogar. Empresas como Dow-Jones (The Source) e a Compuserv (H
and R Block) utilizavam os ciclos livres de computação dos seus servidores
fora do horário comercial cobrando acesso aos seus computadores para que
se pudesse jogar diversos jogos. Inicialmente eram jogos baseados em texto
que
prevaleciam
no
mundo
acadêmico,
mas
muitos
eram
versões
multijogador tais como o Mega Wars I da Compuserv, uma batalha espacial
que suportava até 100 jogadores simultâneos. Os preços de acesso eram
salgados, custando de US$5 a US$ 22,50 por hora.
Estas taxas altas para os jogos online acabaram por criar novos grupos de
usuários que criaram hospedagens de tipo BBS Bulletin Board Systems que
proporcionavam jogos de mesa como o xadrez e versões do Dungeons and
Dragons. Os usuários conectavam-se aos BBSs via modem e por via discada.
Alguns destes proporcionavam experiências de jogo mais ricas cobrando
taxas mais baixas que as dos serviços anteriores.
JOGOS MULTIJOGADOR EM REDE
Entre o início e o meio dos anos 1990, o poder de computação das CPUs
aumentava rapidamente, permitindo aos computadores produzir gráficos e
qualidade de som mais realistas. Ao invés de controlar um quadrado
vagaroso em uma tela de apenas 4 cores, agora podiam mover-se mais
rapidamente em um ambiente de 256 cores, proporcionando uma
experiência mais rica e realista. Além disso, tornou-se cada vez mais
comum que os computadores possuíssem conexões de rede, criando uma
nova área para jogos multijogador, a área dos jogos multijogador em rede.
3. OS PRECURSORES DOS METAVERSOS
DOOM – A CHEGADA DOS PRIMEIROS FPS EM REDE
Apesar de não ter sido
exatamente
o
primeiro
jogo de tipo First Person
Shooter (FPS), jogo de tiro
de
primeira
pessoa,
o
Doom (Figura 23) foi o
mais relevante entre os
primeiros que surgiram.
Produzido em 1993 pela
ID
Software,
levou
o
gênero FPS a um novo
patamar
proporcionando
um motor poderoso que
Figura 23 - Tela inicial de Doom
permitia um jogo de tipo
“fogo neles” violento e rápido, com níveis de jogo e criaturas mais realistas
do que jamais havia sido visto até então.
O Doom permitia que até quatro jogadores jogassem cooperativamente ou
uns contra os outros utilizando o protocolo IPX da Novell em uma rede local.
O IPX, ou Internet Packet Exchange da Novell, era um protocolo de
interconexão de redes que
funcionava para a conexão de
LANs
(Figura
25).
Era
normalmente combinado com
o
SPX
–
Exchange
formar
o
Sequence Packet
da
Novell
pacote
funcionalmente
para
SPX/IPX,
equivalente
ao TCP/IP sobre o qual a
internet é baseada hoje. O
SPX/IPX
não
conseguiu
competir com o TCP/IP em
relação à performance em
áreas muito amplas, e acabou
por desaparecer.
Figura 24 - Doom foi o game multijogador em rede que deu
início ao “boom” dos jogos multijogador em rede.
56
Figura 25 – As camadas de software e hardware do Doom, jogo multijogador em rede baseado em uma
rede Novell.
O
Doom podia funcionar em duas topologias: com computadores
conectados a uma LAN Ethernet ou por conexão via modem. (Figura 26)
Figura 26 - As topologias possíveis utilizadas pelo Doom. (a) computadores conectados a uma LAN
Ethernet, cada um como um “peer” do Doom. (b) computadores conectados via modem, também cada
um como “peer”.
O Doom utilizava uma topologia de rede “peer-to-peer” que significa que
cada jogador era um “peer” independente que fazia funcionar a sua própria
cópia do jogo e comunicava-se diretamente com os outros “peers” do
Doom. “Peer” é uma palavra em inglês que significa “colega”, “par” ou
alguém igual a você. A cada 1/35 de segundo o nó de rede do Doom
checava o input de cada jogador (tais como códigos de tecla de movimento,
de tiro etc.) e retransmitia para todos os demais jogadores. Quando os
comandos de todos os outros jogadores tivessem sido recebidos, a timeline
do jogo avançava. O Doom utilizava números sequenciais para determinar
se um pacote de dados havia sido perdido. Se algum dos nós de rede do
jogo recebia um pacote de um número não esperado, este verificava qual
número havia sido perdido e enviava um “acknowledgement” negativo ou
NACK ao node para o qual o pacote havia sido perdido, para que este fosse
reenviado (The Doom wiki, 2011).
Os peers do Doom comunicavam-se utilizando Ethernet broadcasts para
todo o tráfego de dados. Isto tinha como efeito colateral que, quando um
jogador atirasse, o pacote Ethernet enviado pelo peer não era recebido
somente pelos outros nodes do Doom, mas por todos os outros
computadores da rede local, aumentando bastante a carga de dados na
rede, mesmo para os computadores que não estivessem jogando. Os outros
computadores que não estivessem jogando Doom ignorariam o pacote de
broadcast, mas o seu processamento ainda assim era interrompido para que
pudessem receber o pacote, transferi-lo para a sua memória principal e
fazer com que esta determinasse que não eram necessários naquele
computador. A degradação da performance da rede causada por isto forçou
os
administradores
de
sistemas
de
muitas
redes
de
empresas
e
universidades a banirem o Doom (The Doom wiki, 2011).
Em 1994, a id Software lançou a sequência, o Doom 2. O Doom 2 vendeu
mais de dois milhões de cópias e podia suportar até oito jogadores. Mais
importante que isso, não utilizava mais os pacotes broadcast e esta
modificação
trouxe
um
novo
crescimento
na
aceitação
de
jogos
multijogador em rede nas LANs de empresas e universidades, pois já não
significavam mais um problema quanto à performance da rede local.
SIMCITY
O
SimCity
original
foi
lançado em 1989, mas a
sua história começa quatro
anos antes. Em 1985, o
então
desconhecido
Wright
lançou
chamado
Bungeling
o
"Raid
Bay"
para
Will
jogo
On
as
plataformas Commodore 64
e NES. O objetivo deste
consistia em controlar um
helicóptero
carregado
de
mísseis e metralhadoras e
destruir arquipélagos onde
baterias
defendiam,
derrubá-lo.
longo
Figura 27 - Capa do SimCity Classic de 1989
antiaéreas
se
tentando
Durante
período
o
de
58
desenvolvimento do jogo, Will teve que criar diversos e variados mapas num
editor de terrenos. Logo percebeu que gostava mais de construir cidades do
que de destruí-las. Foi então que teve a ideia: "Por que não criar um jogo
onde se pode construir e gerir uma cidade?"
Will Right criou o jogo inspirado nos livros Urban Dynamics e System
Dynamics de Jay Forester, inicialmente intitulado City Builder ou Micropolis
(RABIN, 2010, p.17). Ao juntar-se à equipe da Maxis, empresa criada por
Jeff Braun e Ed Kilham com o intuito de criar games para adultos, o jogo
seria rebatizado como SimCity. Em fevereiro de 1989 a versão Classic (figura
28) do jogo foi lançada para o Macintosh e mais tarde para PC.
Figura 28 - Aspecto do Sim City Classic
Inicialmente pouco notado o jogo foi ganhando popularidade por conta de
propaganda boca-a-boca, até que um artigo na revista Newsweek selou o
seu grande sucesso. As pessoas amaram o jogo no qual era possível
gerenciar os diversos aspectos do desenvolvimento de uma cidade. O
SimCity Classic foi seguido por uma versão mais sofisticada, o SimCity 2000
(figura 29) em 1994 e outros jogos de menor sucesso como o SimEarth,
SimAnt, SimFarm, o que acabou por definir a marca “Sim”. Mais tarde Will
Right, novamente inspirado por um livro – “Understanding Comics” de Scott
McCloud – criou seu maior sucesso, o the Sims, fenômeno que vendeu mais
de 100 milhões de cópias desde seu lançamento em 2000.
O objetivo do SimCity, como o próprio nome sugere, é o de desenhar e
construir uma cidade. O jogador pode fazer o zoneamento de regiões como
zona comercial, industrial ou residencial, pode adicionar prédios, criar e
mudar a porcentagem dos impostos, construir uma malha de energia
elétrica, construir sistemas de transporte e tomar diversos tipos de ações
para melhorar a cidade. Uma vez que as condições sejam criadas em uma
determinada área, por exemplo, estabelecendo o tipo de zona, criando
meios de transporte até ela e proporcionando água e luz, os habitantes da
cidade, conhecidos por “Sims”, começam a construir, por si mesmos, casas,
blocos de apartamentos, prédios comerciais, prédios industriais, hospitais,
igrejas e outras estruturas. Os “Sims” fazem escolhas baseados em diversos
fatores como quantidade de trânsito, disponibilidade de eletricidade, nível
de crime e proximidade de determinados tipos de prédios.34
Além disso, a cidade pode enfrentar desastres incluindo enchentes,
tornados e incêndios a partir da queda de aviões ou afundamento de navios,
terremotos e ataques de monstros. Em algumas versões acontecem também
desastres nucleares, incêndios por causa de raios, vulcões, meteoros e
ataques alienígenas.
O SimCity originalmente não tinha sido concebido como um jogo que
pudesse ser ganho, isto é, Will Right o criou para ser um jogo em que a
pessoa tivesse o prazer de criar e desenvolver a cidade sem que houvesse
um fim de jogo, quando o jogador ganharia ou perderia. No entanto, para
que o SimCity se parecesse mais com um jogo no sentido tradicional
incluindo esta característica de ganhar ou perder, Right acabou criando o
que intitulou “cenários”. Os cenários foram uma adição sugerida pela
Brøderbund, empresa que havia se associado à Maxis para a criação do
jogo, pois a Brøderbund achava que assim seria mais vendável. Os cenários
compreendiam objetivos específicos que deveriam ser atingidos pelo
jogador dentro de um prazo específico. Se o jogador conseguisse atingi-los
ganharia, caso contrário perderia. As cidades destes cenários eram todas
baseadas em cidades reais, uma tradição criada a partir do SimCity 2000.
34
Um trabalho interessante é o paper “SimCity Classic History and Review” de Eric
Albert
da
Stanford
University
que
pode
http://www.stanford.edu/group/htgg/cgibin/drupal/sites/default/files2/ealbert_2001_1.pdf
ser
encontrado
em
:
60
Enquanto a maioria dos cenários se colocavam em um tempo fictício no
futuro ou uma cidade ficava em estado de atenção por conta de uma
calamidade, alguns cenários baseavam-se em acontecimentos históricos
reais. Por exemplo, um dos cenários retratava o grande Terremoto de 1906
de São Francisco e outro mostrava a crise de Detroit em 1972 por conta dos
altos índices de crimes após a crise da indústria automobilística deixar
milhares de desempregados na cidade.
Figura 29 - As capas do SimCity 2000 e SimCity 2000 network edition
Uma versão do SimCity 2000 para funcionamento em rede (figura 29b) é
especialmente interessante. Lançada em 1996, permitia que até 3 pessoas
jogassem juntas via LAN, Internet, ou modem de modo colaborativo ou
competitivo. Também juntava um elemento especial que permitia a
customização de edifícios.
Além das versões já mencionadas foram lançadas outras: SimCity 3000 em
1999; SimCity 4 em 2003; SimCity DS e SimCity Societies em 2007;
SimCity Creator e SimCity DS 2 em 2008 e, finalmente, versões para iPad,
Blackberry Playbook e Android em 2011 do SimCity Deluxe HD.
A grande contribuição do SimCity para o advento dos metaversos, antes de
mais nada, está no fato de o SimCity ser um dos primeiros exemplos de
mundo virtual gráfico. Nele já era possível criar e customizar um terreno
navegável, onde toda a atividade do jogo se desenvolveria. Não se tratava
propriamente de um sistema de gráficos 3D, mas era uma simulação 2D de
gráfico 3D que já dava aos jogadores uma sensação de “em cima”, “em
baixo” e profundidade, como fica evidente na figura 30. No SimCity Classic
já havia uma tentativa inicial de fazer isso (figura 28), mas esta sensação
fica bem mais definida nas versões a partir do SimCity 2000.
Figura 30 - No SimCity 2000 a sensação de tridimensionalidade foi aperfeiçoada em relação ao SimCity I
Outra contribuição estava no que bem definiu Janet Murray como “agência”
(MURRAY, 2003, p. 127). Toda ação do jogador produzia reações múltiplas
no jogo e efeitos de todo tipo, melhorando ou piorando as condições da
cidade, o que acabou fazendo de SimCity um dos primeiros “God Games”. O
prefeito tinha o poder de decidir quase tudo sobre a cidade. Poder de criar
bairros inteiros ou de destruir construções antigas para construir algo novo.
Isto dava aos jogadores uma sensação de poder criativo muito grande e foi
um dos grandes atrativos do jogo.
Algo interessante que contribuía para esta quase onipotência do prefeito era
o fato de ser possível controlar a passagem do tempo no jogo fazendo o
tempo andar mais devagar ou mais rapidamente. Em momentos de crise,
por exemplo, em meio a um incêndio na cidade, podia-se fazer o tempo ir
mais devagar de modo a impedir que o fogo se espalhasse permitindo que
as equipes de bombeiros pudessem apagar melhor os focos de incêndio. Por
62
outro lado, se a cidade estivesse com poucos fundos, por exemplo, para
construir um estádio ou mais ruas e viadutos, era possível acelerar o tempo
para que, juntamente com a virada do ano, os impostos fossem recolhidos e
mais dinheiro ficasse disponível para a realização de obras na cidade.
Ainda outra contribuição está na questão da imersão. Como também diz
Murray (2003, p.102) acerca da imersão:
“A experiência de ser transportado para um lugar primorosamente
simulado é prazerosa em si mesma, independentemente do conteúdo
da fantasia. Referimo-nos a essa experiência como imersão.
“Imersão” é um termo metafórico derivado da experiência física de
estar
submerso
na
água.
Buscamos
de
uma
experiência
psicologicamente imersiva a mesma impressão que obtemos num
mergulho no oceano ou numa piscina: a sensação de estarmos
envolvidos por uma realidade completamente estranha, tão diferente
quanto a água e o ar, que se apodera de toda a nossa atenção, de
todo o nosso sistema sensorial.”
Uma vez começado o jogo, o jogador engajava-se imediatamente nas
atividades de criação da cidade e a via crescer ou deteriorar-se, conforme as
condições dadas e as ações que tomava como prefeito. Ainda diz Murray:
“Mas num meio participativo, a imersão implica aprender a nadar, a
fazer as coisas que o novo ambiente torna possíveis.”
Neste sentido, o jogador imergia no jogo e na sua função, sendo obrigado a
“aprender a nadar” como prefeito. Por tentativa e erro, via como funcionava
cada elemento da cidade, o modo como a questão financeira determinava o
que seria possível ou não fazer. O resultado desta imersão era essa
“experiência prazerosa” mencionada por Murray.
Em SimCity, ainda outro prazer típico dos mundos virtuais podia ser
deleitado, o prazer da “transformação”, como descrito por Murray (2003 p.
153). A possibilidade de modificar o ambiente, construindo e destruindo
bairros inteiros permitia verificar como, dentro de uma mesma realidade, os
“sims” comportavam-se a partir de alguma modificação no ambiente. Um
exemplo. Algum tempo após ser criada, uma região industrial podia se
deteriorar, e as fábricas nela podiam fechar transformando-se em prédios
abandonados. Isto fazia com que toda a região em volta perdesse o valor e
que, por exemplo, áreas residenciais adjacentes também se deteriorassem.
Era possível, frente a esta situação, fazer uma série de modificações no
local, seja para tentar reativar esta área industrial, seja para transformá-la
em uma área de outro tipo. Isto permitia múltiplas experiências, por
exemplo, criar uma rodovia próxima ao terreno para reativar a área, ou
simplesmente demolir tudo e transformá-la em uma área comercial ou
residencial, ou ainda criar um parque ali. Com estas modificações, as áreas
circunvizinhas sofriam um impacto de nossa ação e era possível ver as
reações dos “sims” ao longo do tempo criando novos prédios ou
melhorando os já existentes. Isto permitia que, a partir dos mesmos
elementos, tivéssemos um caleidoscópio de opções e de possibilidades. Era
também
possível
ver
diversas
áreas
desenvolverem-se
e
outras
deteriorarem-se ao mesmo tempo, o que criava situações completamente
diferentes em regiões diversas da cidade, fazendo com que o prefeito
sempre tivesse que estar atento às “histórias” contadas pelo espaço de cada
área da cidade, para poder agir sobre elas.
Todos estes elementos fizeram do SimCity um dos primeiros experimentos
em criar uma simulação do real interessante. Se considerarmos a definição
de metaversos como “mundos virtuais tridimensionais imersivos nos quais
as pessoas interagem entre si e com agentes de software, usando a
metáfora do mundo real, mas sem suas limitações físicas”, o SimCity nos
trouxe uma primeira forma de simulação que constitui uma metáfora do
mundo real e sem suas limitações físicas. Ainda não havia avatares ou uma
representação gráfica do jogador, nem interação entre pessoas, mas os
elementos de imersão, agência e transformação já estavam presentes.
A SÉRIE ZORK EM AVENTURAS GRÁFICAS
Return to Zork
Return to Zork (1993) é o primeiro jogo da
série Zork estabelecido em um mundo
totalmente gráfico e o último jogo da série
produzido pela Infocom. Ao contrário dos
jogos anteriores, que foram aventuras em
texto, Return to Zork acontece em uma
perspectiva em primeira pessoa e com
gráficos detalhados para a época. O que
este jogo começou a fazer e que muitos
outros depois fizeram foi um esforço em
mesclar computação gráfica com imagens
de atores reais em cena. A atuação dos
Figura 31 - Capa de Return to Zork
64
atores era absolutamente horrível e “enlatada”, pois não era constituída
exatamente por vídeos, mas por imagens de atores em diversas posições
que faziam movimentos muito básicos como abrir e fechar a boca ou
movimentar-se de modo um tanto tosco. Entretanto, tudo estava de acordo
com a atmosfera leve de fantasia e o humor da série original.
Uma interface do tipo “apontar-e-clicar” substitui os comandos de texto
pela primeira vez em um jogo Zork. Esta interface era bastante inovadora se
comparada à de outros jogos, como o Myst, pois permitia uma gama muito
maior de ações do que em outros jogos de aventura gráficos. Ao clicar em
um objeto, abria-se um menu com ações possíveis que poderiam ser feitas
com ele e, clicando em um objeto e depois em outro, apresentava ainda
outras ações possíveis entre os dois objetos. A interface de conversação
também era inovadora: cada vez que conversasse com uma personagem, o
jogador podia selecionar o tipo de tom e humor da sua fala, por exemplo, se
sentisse que alguém estivesse escondendo alguma coisa, poderia mudar o
tom da sua fala para o modo “ameaçar” para obter a informação desejada
figura 32).
Figura 32 Em Return to Zork era possivel utilizar diferentes tons de humor para falar com as
personagens e obter informações.
Também era possível perguntar a qualquer personagem sobre qualquer
objeto que estivesse no seu inventário ou sobre qualquer foto que tivesse
tirado. Às vezes somente fazendo isso o jogador podia obter pistas
importantes para resolver os puzzles. Entretanto, alguns dos puzzles eram
tão difíceis de resolver, que muitos desistiam de continuar jogando. Alguns
consideram os puzzles o grande ponto fraco do jogo por causa disso.35
O estilo de jogo em geral é um pouco semelhante ao Myst, embora Return
to Zork tenha sido lançado alguns meses antes de Myst. Return to Zork
mostrava várias maneiras de interagir com cada objeto no mundo do jogo,
bem
como
com
vários
NPCs
(personagens
não-jogadores) também
presentes no mundo através de um menu que aparecia do lado esquerdo da
tela. Ele também apresentava diversas maneiras de "terminar" o jogo, o que
incentivava jogá-lo outras vezes para ver os finais alternativos.
Diversos aficionados do Zork em texto disseram que, apesar das grandes
mudanças gráficas, Return to Zork conseguia manter a essência dos
puzzles, diálogos e humor característico da série inicial. Esta já não foi a
crítica ao próximo jogo da série, Zork Nemesis, que foi considerado por
muitos fãs da série Zork original como uma “ovelha negra” - e bem negra da família Zork, mas não menos interessante.
ZORK Nemesis
Em Zork Nemesis (1996), primeiro
jogo da série Zork produzido e
distribuído pela Activision, o humor
sarcástico
dos
diálogos
simplesmente desaparece e dá lugar
a uma atmosfera realmente sombria
e tétrica, mas, ao mesmo tempo,
profundamente
graficamente
sedutora
muito
e
superior
a
Return to Zork. Alguns defensores
mais aficcionados da série original
acreditavam
que
este
jogo
não
deveria ser considerado parte da
série Zork por causa desta mudança
Figura 33 - Capa de Zork Nemesis
drástica.
O
modo
de
jogo,
entretanto, tinha um estilo bastante
interessante que também diferia um
35
Ver comentário interessante a este respeito no site Free Games Downloads na
URL: http://free-gamedownloads.mosw.com/abandonware/pc/adventure/games_p_r/return_to_zork.htm
66
pouco dos jogos da série Zork originais. Havia puzzles lógicos a resolver,
mas muitos deles precisavam de uma abordagem quase que de um detetive.
Era necessário caminhar por todo o mundo do jogo, conversar com as
personagens e fazer perguntas. Ao fazê-las outras opções apareciam. Era
possível gravar o que as personagens falavam e tocar estas gravações para
que outras personagens escutassem. Assim, o jogo era não linear e fazia-se
necessário juntar as peças para os puzzles a partir de informações
fragmentadas de diversas fontes.
No mais, Zork Nemesis também utilizou pela primeira vez uma tecnologia
chamada pela Activision "Z-Vision Surround Technology" que dava aos
jogadores uma visão de 360 graus de cada local visitado, mas apesar de
acrescentar uma nova dimensão ao modo de jogo ainda apresentava
algumas limitações. As imagens de 360 graus eram de menor qualidade que
as imagens fixas e um pouco pixeladas e a movimentação somente podia
acontecer na horizontal ou na vertical e não nas diagonais. Isto seria
corrigido e aperfeiçoado no próximo game da série, Zork Grand Inquisitor.
O Zork Nemesis também fazia uso de vídeos de atores mesclados com
computação gráfica, todos os personagens principais eram atores gravados
em vídeo. O jogo foi um dos maiores da sua época, ocupando 3 CD-ROMs
justamente por conta dos vídeos e das cenas panorâmicas.
Voltando à questão do ambiente sombrio e o quanto contrastava com a
atmosfera leve e sarcástica dos jogos anteriores, o exemplo mais chocante
que representa bem esta mudança é um momento em que o jogador precisa
cortar a cabeça de um cadáver nu que está em uma geladeira de um asilo de
loucos para poder pegá-la e fazê-la falar (figura 34).
Aqueles que foram expostos à série Zork pela primeira vez com Zork
Nemesis (como é o meu caso) geralmente aprovaram o realismo do jogo e
achavam-no
macabramente
interessante.
As
críticas
da
imprensa
especializada em games eram todas positivas na época. Apesar disso, o
jogo seguinte da série, Zork Grand Inquisitor, voltou a apostar na atmosfera
leve de humor do restante da série.
Figura 34 - Momento mais chocante de Zork Nemesis: cortar a cabeça de um cadáver e fazê-la falar.
A grande contribuição desta nova série gráfica de Zork está justamente em
juntar a herança dos adventure games em texto e seu forte apelo narrativo a
uma forma gráfica, incluindo imagens ricamente elaboradas, elementos de
visualização 360 graus e vídeos de atores. Além disso, a maneira de
apontar-e-clicar tanto para a navegação pelo espaço do jogo como para
interagir com o ambiente e com os objetos também foi uma inovação muito
importante. Tudo isso contribuiu para um nível de realismo e de imersão
ainda não experimentado no mundo dos games até então. Por esta razão,
Return to Zork, Zork Nemesis e, em menor escala, Zork Grand Inquisitor
estão ao lado de Myst em um momento importante de inovação gráfica no
mundo dos games, que será de suma importância para o advento dos MMOs
e MMORPGs.
MYST
Com a intenção de criar um game para adultos, os irmãos Robyn e Rand
Miller criaram Myst (1993), um jogo utilizando cenas renderizadas em 3D de
rara beleza atmosférica, pontuada por pequenos vídeos que faziam a
história avançar.
Como diz Lorna Dannan no site mais completo em português sobre a série
Myst, o site “Grande Caverna D’ni” :
68
“(...) o primeiro jogo da série foi
lançado no início da década de
noventa, por volta de 1993 e
chamou-se
MYST.
somente
Levando em conta os recursos
dos computadores da época, os
gráficos não são tão apurados
como
os
contudo
gráficos
os
atuais,
Millers
se
consagraram por criar uma nova
forma de jogar no computador,
o que elevaria a categoria dos
jogos de simples movimentos,
restritos
comandos
repetitivos,
para
e
um
sons
mundo
quase real e palpável, onde o
jogador, com o auxilio de um
leitor de CD, um mouse e um
teclado poderia mergulhar de
corpo
e
alma
na
aventura
chamada de: imersão total. Hoje
Figura 35 - Myst (1993)
em dia este conceito é usual,
mas
em
1993
completamente
era
algo
fantástico.”
(DANNAN, 2011)
Como bem diz Dannan, Myst vem inaugurar o conceito de imersão total
utilizando imagem, sons e dentro de um espaço navegável. O usuário do
jogo clicava com o mouse para navegar de uma cena para outra de modo
“point-and-click” (apontar e clicar), análogo ao que se fazia via texto nos
antigos MUDs para passar de uma sala para outra, mas agora com um forte
apelo gráfico e sonoro que criavam uma atmosfera densa. O jogador deveria
navegar pelo jogo, resolver puzzles para solucionar o mistério da ilha de
Myst. (RABIN 2010, p.26)
Myst I foi lançado inicialmente para Macintosh e logo em seguida para PC e
tornou-se sucesso de público e crítica bem no início da era dos CD-ROMs.
O enorme sucesso de Myst levou ao lançamento de sequências como Riven,
Myst III: Exile, Uru: Ages Beyond Myst e Myst IV, bem como a três livros.
Figura 36 - Myst Online Uru Live: um metaverso pleno
Mais recentemente, Myst foi transformado em um metaverso, o Myst Online
Uru Live (figura 36), criado pela Cyan, que recria toda a beleza dos games
Myst iniciais em um mundo virtual 3D de grande beleza. Nele é possível
explorar as diversas “eras” e resolver puzzles para conhecer mais sobre o
mundo de Myst.
Na perspectiva de Manovich (2002) em seu livro “The Language of New
Media”, tanto Doom como Myst “são formas estéticas genuinamente
originais e historicamente sem precedentes”. Para ele, Doom e Myst
produziram uma série de elementos que resignificaram a ideia que se tinha
até então sobre conceitos como autoria, comunicação e o potencial das
linguagens expressivas.
“Em uma série de fatores, Myst e Doom são completamente
diferentes. Doom tem um passo rápido enquanto Myst é vagaroso.
Em Doom o jogador corre pelos corredores tentando terminar o nível
o mais rápido possível para passar para o seguinte. Em Myst, o
jogador move-se pelo mundo literalmente um passo a cada vez,
desvendando a narrativa ao longo do caminho. Doom é populado por
inúmeros demônios esperando em todos os cantos para atacar; Myst
é completamente vazio.” (MANOVICH, 2002)
Manovich afirma que Doom segue a convenção dos jogos de computador:
possui algumas dúzias de níveis de jogo. Embora Myst também tenha
quatro mundos separados, cada um parece mais com um universo
70
independente do que um tipo tradicional de nível de jogo de computador.
Enquanto os níveis de jogo de Doom são semelhantes uns aos outros, os
mundos de Myst são absolutamente diferentes.
Quanto à navegação, em Doom o jogador move-se em linhas retas e vira
abruptamente em ângulos retos para entrar em novos corredores. Em Myst a
navegação é mais livre, o jogador pode mover-se mais devagar, explora o
ambiente, andar em círculos, voltar ao mesmo lugar.
Além das diferenças acima, Doom e Myst possuem tipos específicos de
“economias culturais”.
Com Doom, a id Software foi pioneira em uma nova economia, resumida
pelo crítico de games J. C. Herz da seguinte maneira:
“Foi uma ideia que marcou um novo tempo. Lançar uma versão
emagrecida e gratuita (do jogo) através dos canais de shareware, da
Internet e serviços online, seguida de uma versão do software para a
venda, completa e registrada”.36
Ora, com este procedimento inicia-se formalmente a política das Demo
Plays, as versões jogáveis de softwares, nas quais mostramos as
potencialidades do produto. Como resultado desta política, quinze milhões
de cópias de Doom foram baixadas. A análise de Manovich é apoiada pelos
estudos do pensador Michel de Certeau, quando diz que:
“os produtores definem a estrutura básica de um objeto, e lançam
alguns exemplos e as ferramentas para permitir aos consumidores
que criem as suas próprias versões, partilhando-as com outros
consumidores.” (CERTEAU, 2000)
Isto já vem semear as primeiras sementes do que vai ser a base da web 2.0,
ou seja, a produção de conteúdo pelo usuário. Com este tipo de política
econômica começa a abrir-se o caminho para o estabelecimento de novos
objetos digitais: o software aberto, o software livre e toda a gama de
36
No original: "It was an idea whose time has come. Release a free, stripped-down
version through shareware channels, the Internet, and online services. Follow with a
spruced-up, registered retail version of the software." Mencionado por Manovich
(2002)
produções e licenças que hoje encontramos no ciberespaço. Será a ênfase
neste tipo de perspectiva que permitiu, em curto espaço de tempo, que a
Web se convertesse em um ciberespaço, ou seja, em um espaço navegável e
interativo.
Em contraste com esta perspectiva de economia cultural iniciada por Doom,
Myst ainda apresentava um modelo de economia cultural mais antigo, que
mais parecia com uma obra de arte tradicional do que propriamente um
software: era algo para ser olhado e admirado, ao invés de algo para ser
modificado. Era um sistema proprietário fechado que só os seus criadores
poderiam modificar.
Apesar de todas estas diferenças ambos jogos eram semelhantes em um
ponto: eram “jornadas espaciais” (MANOVICH, 2002). Ambos apresentam ao
jogador um espaço a ser atravessado e mapeado. Ambos começam com o
jogador sendo colocado em algum ponto e antes de chegar ao final da
narrativa este precisa descobrir a sua topologia e aprender sua lógica e seus
segredos.
De acordo com esta perspectiva, uma das consequência que temos é a de
que
o
ciberespaço
se
tornou,
progressivamente,
um
lugar
que
disponibilizava uma infinidade de percursos encarados como ambientes
para serem percorridos. Esta foi a ideia apresentada por Robin Miller, um
dos autores de Myst, quando disse:
“Estamos criando ambientes simplesmente para se passear dentro. As
pessoas estão chamando isso de jogo, por falta de um termo melhor
e nós temos chamado de jogo às vezes. Mas não é isto o que
realmente é: é um mundo."37
37
No original: "We are creating environments to just wonder around inside of.
People have been calling it a game for lack of anything better, and we've called it a
game at times. But that's not what it really is; it's a world."
Manovich (2002).
Mencionado por
72
Janet Murray, ao comentar sobre Myst e por que tornou-se tão especial, diz
o seguinte:
“(...) alguns criadores de jogos fazem bom uso de técnicas
cinematográficas
para
intensificar
a
força
dramática
de
seus
produtos. Por exemplo, o jogo de CD-ROM Myst (1993) deve muito
de seu poder de imersão a seu sofisticado projeto de som. Cada uma
das áreas do jogo é caracterizada por um som ambiente distinto,
como assobio do vento por entre as árvores ou o rebentar de ondas
no litoral, reforçando a realidade dos mundos imaginários, que são,
na verdade, apenas uma sucessão de imagens estáticas. Objetos
individuais também são apresentados de um modo mais concreto
quando
pingam,
batem
e
chiam
apropriadamente
ao
serem
manipulados. (...) A trilha sonora faz parte da técnica do jogo: ela
fornece pistas de que estou clicando com o mouse na direção certa,
como as dicas de frio e quente nas brincadeiras de caça ao tesouro.”
(MURRAY, 2003, p.63)
O projeto de som está intimamente ligado ao espaço navegável em Myst,
ajudando a criar a imersão e proporcionando um realismo impressionante
ao jogo que lhe confere uma força dramática impar.
Jogos como Doom e, sobretudo Myst, se constituem em narrativas digitais,
em ambientes digitais navegáveis e interativos e, sobretudo, inauguram
“formas
culturais”
específicas
e
poderosas
o
suficiente
para
redimensionarem vários aspectos da vida e cultura da humanidade. Com os
estudos de Lev Manovich e de Janet Murray podemos entender aspectos
importantes quanto a estes elementos que serão fundamentais nos
metaversos.
4. METAVERSOS
MMOS E SUAS SUBCATEGORIAS
Os
MMOs ou MMOGs
(Massive Multiplayer
Online Games
– Jogos
Multijogador On-Line Massivos) seriam a categoria principal do que
chamamos “metaversos plenos” em nossa definição no início do capítulo. O
termo “massivo” refere-se ao fato de serem mundos virtuais persistentes
que são populados por centenas, e mesmo até milhares, de jogadores
simultâneos por meio da Internet. Nestes, o jogador é representado por uma
personagem gráfica denominada avatar.
Pelo termo persistente entendemos que o mundo virtual do metaverso
permanece lá mesmo quando não estamos online, isto é, eventos continuam
a acontecer, outras pessoas podem interagir e modificar o ambiente
enquanto não estivermos conectados. Nos jogos que não são persistentes,
uma vez que nos desconectamos, o mundo virtual deixa de existir.
Segundo a Wikipédia em português para o termo “Massively multiplayer
online game”, existem diversas subcategorias de MMOs:
“MMORPG - MMO role-playing game – jogo de interpretação de
personagem
online
em
massa.
O
jogador
"incorpora"
um
personagem, geralmente mágico ou com poderes extra-humanos.
Podem ser escolhidas várias classes como, por exemplo, um vampiro,
um lobisomem ou um bruxo. Ex: World of Warcraft, Ragnarök, Final
Fantasy XIV, Silkroad.
MMORTS - MMO real time strategy – jogo de estratégia em tempo
real online em massa. O jogador comanda um exército e/ou nação,
podendo formar alianças, captar recursos e atacar outros jogadores
(visa a parte estratégica), como em Age of Empires, Eve Online,
Stronghold: Crusader, Saga, Beyond Protocol e Ballerium.
MMOFPS - MMO first person shooter – jogo de tiro em primeira
pessoa online em massa. O jogador "incorpora" um soldado e/ou
mercenário, usando armas e bombas contra outros jogadores (visa a
ação).
MMOSG - MMO social games – jogo de relacionamentos online em
massa. O jogador cria um avatar objetivando interação com outros
usuários. Tais interações incluem passeios por ambientes virtuais,
comunicação via texto e/ou voz, realização de atividades em grupo.
Ex: Second Life, Club Penguin, Habbo e IMVU.
74
MMOEG - MMO erotic game – jogo erótico online em massa. Jogos
para o público adulto, com temática sexual. Ex: Red Light Center,
Naughty America, Virtual Hottie.
MMOBG - MMO browser game – jogo de navegador online em massa.
Jogos que não necessitam de instalação. São jogados diretamente
nos navegadores de internet. Ex: Dragon Fable, Guerra Khan,
Hattrick, oGame.”
(Wikipédia, 2012)
O metaverso mais conhecido,
como já dissemos, é o Second
Life (figura 37). Apesar de ser
considerado pelo verbete da
Wikipédia
tecnicamente
um
MMOSG, o aspecto social dele
não
é
mais
sua
característica,
por
principal
isso
o
consideraremos simplesmente
um
MMO.
A
categoria
principal MMO não define a
Figura 37 - Second Life - o metaverso mais conhecido
priori um tema específico.
Nestes tipos de metaverso os
jogadores têm total liberdade de escolher o modelo de avatar que desejam
criar. Os avatares nestes casos não têm que estar dentro de uma categoria
ou grupo, mesmo porque não existe um tema ou uma história específica a
ser contada como nos MMORPGs. Nos MMOs existem “ilhas” temáticas, que
são espaços virtuais dedicados a algum assunto ou tema, mas não existe
uma narrativa. Em alguns MMOs os usuários ou jogadores também têm a
possibilidade de escrever programas em linguagens apropriadas e produzir
objetos e aplicações para funcionamento dentro daquele metaverso
específico. No Second Life, por exemplo, existe a LSL – Linden Script
Language para a criação de aplicações e jogos dentro do metaverso.
Podemos considerar os MMORPGs atualmente como a categoria de
metaversos mais difundida. Os MMORPGs são metaversos temáticos em que
os jogadores assumem papéis com identidades definidas segundo o tema
do metaverso. Entre os principais temas estão fantasia, ficção científica e
temas infantis. A origem deste tipo de metaverso remonta aos MUDs – Multi
User Dungeons - baseados em texto, mas os MMORPG atuais têm uma
natureza fortemente gráfica. O MMORPG mais conhecido e difundido é o
World of Warcraft, com mais de 11 milhões de pessoas registradas.
Os jogadores representam uma personagem dentro de alguma categoria ou
grupo de personagens que têm alguma função específica dentro da história
proposta pelo metaverso. Nos MMORPGs, os avatares normalmente têm
tarefas ou missões coletivas a cumprir que direcionam o desdobramento
dos acontecimentos no metaverso funcionando como fio condutor da
história.
Janet Murray em seu livro “Hamlet no Holodeck” (MURRAY 2001) mostra
diversos exemplos de como o campo das novas mídias, em especial os
MMOs e MMORPGs, possuem algumas características bastante peculiares e
inovadoras. Murray faz a distinção entre três prazeres importantes deste
meio: a imersão, a agência e a transformação.
A. Imersão
“A experiência de ser transportado para um lugar primorosamente
simulado é prazerosa em si mesma, independentemente do conteúdo
da fantasia. Referimo-nos a essa experiência como imersão.
“Imersão” é um termo metafórico derivado da experiência física de
estar
submerso
na
água.
Buscamos
de
uma
experiência
psicologicamente imersiva a mesma impressão que obtemos num
mergulho no oceano ou numa piscina: a sensação de estarmos
envolvidos por uma realidade completamente estranha, tão diferente
quanto a água e o ar, que se apodera de toda a nossa atenção, de
todo o nosso sistema sensorial. Gostamos de sair de nosso mundo
familiar, do sentido de vigilância que advêm de estarmos neste lugar
novo e do deleite que é aprendermos a nos movimentar dentro dele.”
(MURRAY, 2003, p.101)
Por imersão Murray entende o poder desta mídia em ajudar o seu usuário a
adentrar um mundo completamente novo e pleno de emoções e sensações
que não seriam possíveis no mundo real e que possa encenar suas fantasias
e ter novas experiências.
Enquanto experiência, os ambientes virtuais dos metaversos e games, em
primeiro lugar, propiciam a um sujeito, um estado, sentimento ou sensação
de imersão. Ora, estar imerso significa estar envolvido perceptualmente por
um ambiente que pode ter características físicas ou simplesmente
representacionais. Dizemos que estávamos imersos quando momentos atrás
estávamos absorvidos em uma leitura de um texto que nos parecia por
demais interessante, ou ainda quando estávamos a olhar atentamente,
absortos, capturados em nosso olhar e fascinados um filme, na televisão
ou no cinema. Mas não somente! Quando assistimos a uma peça de teatro,
76
podemos estar tão absortos que nossa atenção, nossa alma e nossos
sentimentos ficam capturados pelos eventos que se desenrolavam no palco.
Então, a partir destas constatações, percebemos que a imersão se constitui
em uma estrutura complexa, formada por vários elementos, estruturas e/ou
camadas. Compreender a sua natureza, forma, função e finalidade é
fundamental para podermos entender mais adequadamente a nossa
presença e ação dentro dos metaversos e games.
B. Agência
Agência é a capacidade desta mídia de permitir ao usuário realizar ações
que provoquem consequências na representação:
“Quanto mais bem resolvido o ambiente de imersão, mais ativos
desejamos ser dentro dele. Quando as coisas que fazemos trazem
resultados
tangíveis,
experimentamos
o
segundo
prazer
característico dos ambientes eletrônicos - o sentido de agência.
Agência é a capacidade gratificante de realizar ações significativas e
ver os resultados de nossas ações e escolhas. Esperamos sentir
agência no computador quando damos um duplo clique sobre um
arquivo e ele se abre diante de nós, ou quando inserimos números
numa planilha eletrônica e observamos os totais serem reajustados.
No entanto, normalmente não esperamos vivenciar a agência dentro
de um ambiente narrativo.” (MURRAY, 2003, p.127)
C. Transformação
Finalmente, por transformação entende a habilidade que os computadores
proporcionam para fazer mudanças. Podem ser mudanças de formas
(morphing) ou processos:
“Tudo o que vemos em formato digital – palavras, números, imagens,
animações – torna-se mais plástico, mais suscetível a mudanças.”
(MURRAY, 2003, p.153)
Este prazer da transformação é possível ao experimentar múltiplas
perspectivas sobre um mesmo assunto a partir do verdadeiro caleidoscópio
de uma determinada situação que o computador permite criar por conta
desta plasticidade dos dados. Isto somente é possível nos meios eletrônicos.
Murray vê o computador e o ciberespaço como meios que permitem contar
histórias com novas possibilidades expressivas impossíveis nas mídias
tradicionais.
“Uma das mais atraentes é a capacidade de apresentar ações
simultâneas de múltiplas formas. Em um romance tradicional as
ações simultâneas são apresentadas sequencialmente, mas no
computador podemos dispor de todas as ações simultâneas numa
grade e, então permitir que o interator navegue entre elas. Podemos
ter a expansibilidade do romance com os cortes rápidos dos filmes.”
(MURRAY, 2003, p.155)
Um exemplo disso é contar uma história mostrando a perspectiva interna de
cada um dos personagens, permitindo foco no pensamento de cada um
deles, a gosto do jogador. Em seu trabalho, Murray afirma que os
computadores permitiram a expansão do conceito de narrativa, para aquilo
que chama de “ciberdrama”, que inclui tanto elementos dos meios
tradicionais
(literatura,
cinema,
teatro)
como
as
formas
interativas
emergentes (videogames, hipertextos, MMOs e MMORPGs).
Quanto mais um metaverso consegue gerar estes três prazeres no jogador,
maior o engajamento conseguirá da parte deste jogador. Metaversos que
melhor
conseguem
estabelecer
este
“mix”
recebem
mais
visitantes
simultâneos. Entretanto, a imersão parece ser o principal entre eles,
enquanto a agência e a transformação são secundários, mas também
bastante relevantes.
Enquanto o World of Warcraft
bate
recordes
de
utilização
(figura 38), nos últimos tempos
muito se falou na imprensa sobre
a visível queda nas visitações ao
Second Life. Basta visitá-lo para
ver
ilhas
sucesso
com
belas
construções
completamente
vazias.
internautas
Muitos
blogueiros
Figura 38 - World of Warcraft - MMORPG de maior
imensas
dizem
aconteceu “pela
que
falta
do
e
isto
que
fazer lá”, isto é, não existia um
estímulo ou uma história que
mantivesse os jogadores ocupados ali e engajados. Talvez esta tenha sido
a grande falha do Second Life, a inexistência de uma narrativa. Agora, isto
significa que o Second Life esteja morto?
78
ALGUMAS ESTATÍSTICAS
SOBRE OS METAVERSOS E MUNDOS VIRTUAIS
No momento em que estamos escrevendo esta dissertação no início de
2012 podemos vislumbrar uma nova emergência dos metaversos ou
mundos virtuais. Depois do grande pico de popularidade em 2006 e do
declínio acentuado dos mundos virtuais a ponto de alguns se perguntarem
se o Second Life não estaria “morto” (LIVINGSTONE, 2011), entramos em
uma fase em que benefícios reais ao invés de altas expectativas por causa
da novidade começam a fluir novamente com tecnologias que mostram um
potencial de transformação real.
Se alguns afirmam que o Second Life, o maior expoente dos metaversos nos
últimos anos, parece estar morto, dados estatísticos definitivamente
mostram que este não é o caso do Second Life e muito menos de outros
metaversos e mundos virtuais.
De acordo com dados recém-divulgados em janeiro de 2012 pela KZero
Worldwide (2011), até o final de 2011 cerca de 1,77 bilhão de usuários
estavam registrados em mundos virtuais (figura 39), mais que o dobro do
que havia ao final de 2009. Um fator curioso é a faixa etária dos usuários. A
vasta maioria tem até 15 anos de idade. Somente 49 milhões deste total de
1,77 bilhão têm mais de 25 anos de idade.
Além disso, os números dos lucros da indústria de vendas de bens virtuais
passaram de inexistentes há alguns anos aos US$ 4 bilhões globais em
2011, com estimativa de chegarem a US$ 6 bilhões em 2012, também
segundo a Kzero worldwide (figura 40).
Em
2011,
houve
um
aumento
na
velocidade
com
que
novos
desenvolvimentos de mundos virtuais aconteceram, como os dos mundos
virtuais baseados em browsers como o BlueMars, OpenSim, OurBricks,
realXtend e o mais recente, o Kitely. Devido ao rápido crescimento do
acesso à internet de banda larga e ao maior poder de computação dos
novos processadores, pessoas e organizações dos mais diversos ramos
estão entrando na internet e experimentando novas maneiras de utilizar os
mundos virtuais como meios complementares ao mundo real para
comunicarem-se, colaborarem e organizarem atividades econômicas e
produtivas.
No quadro acima observamos os números de novos usuários registrados,
em geral, no conjunto dos metaversos acompanhados pela KZero. Observase que o número máximo de adultos é o número menos expressivo das
quatro faixas etárias e tem mantido um crescimento menor que o dos não
adultos. No gráfico a seguir são apresentados os registros acumulativos.
Figura 39 – Dados de janeiro de 2012 com o total de contas registradas em mundos virtuais por idade
em milhões. Fonte: Kzero Worldwide
80
Figura 40 - Prognóstico dos lucros dos mundos virtuais. Fonte Kzero Worldwide
Quanto ao Second Life, as últimas estatísticas mostram que, apesar de não
apresentar mais o número de visitantes que tinha em 2009, em torno de
50,000 pessoas ainda o acessam semanalmente (figura 41). Mesmo que não
seja mais aquele ponto de encontro social como era preconizado no seu
período de pico, empresas e principalmente instituições educacionais
continuam a utilizá-lo, e muito.
Figura 41 - Média de visitantes ao Second Life por semana de maio de 2006 a dezembro de 2011
Fonte: Dwell on it website (2012)
Segundo a metodologia do “Hype Cycle” criada pela Gartner Inc. (2012) toda
nova tecnologia tem um ciclo de vida que passa por pelo menos cinco fases:
a) o início da tecnologia, b) o pico ou “hype” com expectativas exacerbadas
sobre aquela tecnologia; c) período de desilusão; d) o aclive da iluminação e
e) o planalto da produtividade (figura 42).
Figura 42 - Metodologia dos Hype Cycles da Gartner Research Inc.
O conceito de Hype Cycle é usado pela Gartner desde 1995 para chamar
atenção para os padrões de “entusiasmo exacerbado”, “desilusão” e eventual
“realismo” que acompanham cada nova tecnologia e inovação. A Gartner
estuda estas fases com objetivos comerciais para verificar se uma
determinada tecnologia é comercialmente viável em um determinado
momento para uma empresa e o quanto é provável que traga benefícios.
“Os Hype Cycles proporcionam uma apresentação gráfica do grau de
maturidade e de adoção de tecnologias e aplicações e do quanto são
potencialmente relevantes para resolver problemas de negócios reais
e explorar novas oportunidades. A metodologia do Hype Cycle da
Gartner dá a você uma visão do quanto uma tecnologia ou aplicação
deve evoluir ao longo do tempo, proporcionando uma fonte confiável
de insight para gerenciar a sua adoção dentro do contexto de suas
metas específicas de negócios.” (GARTNER RESEARCH INC., 2012)
82
As cinco fases da metodologia do “Hype Cycle” (Gartner Research Inc. 2012)
são as seguintes:
1. "Início da Tecnologia"
A primeira fase é aquela em que uma nova tecnologia, uma descoberta,
produto ou evento é lançado e gera muito interesse, inclusive da imprensa.
2. "Pico das Expectativas Exacerbadas"
Na próxima fase, um frenesi de publicidade gera mais entusiasmo e
expectativas irreais a respeito da tecnologia. Pode haver algumas aplicações
bem sucedidas de uma tecnologia, mas normalmente há mais que não o
são.
3. "Vale da Desilusão"
As tecnologias entram no "vale da desilusão", porque não conseguem
atender
às
expectativas
e
rapidamente
ficam
fora
de
moda.
Consequentemente, a imprensa geralmente abandona o tema e a tecnologia.
4. "Aclive da Iluminação"
Embora a imprensa possa ter parado de cobrir aquela tecnologia, algumas
empresas
continuam
no
"aclive
da
iluminação"
e
experimentam
e
compreendem os benefícios e aplicações práticas da tecnologia.
5. "Planalto da Produtividade"
A tecnologia alcança o "planalto da produtividade" quando os seus
benefícios passam a ser amplamente demonstrados e aceitos. Torna-se
cada vez mais estável e evolui na segunda e terceira gerações. A altura final
do “planalto” varia se a tecnologia é amplamente aplicável ou se beneficia
apenas um nicho de mercado.
Conforme o último gráfico publicado pela Gartner em julho de 2011 a
respeito das tecnologias emergentes, os “mundos virtuais” estavam bem no
fundo do “vale da desilusão”, mas encaminhando-se para o “aclive da
iluminação” (figura 43). De fato, é o que os números parecem indicar seis
meses depois. Aos poucos a aplicação dos metaversos e mundos virtuais
parece lentamente erguer-se das supostas cinzas. Não existe mais qualquer
frenesi da imprensa quanto aos metaversos e mundos virtuais. O pico já
passou. Agora podemos esperar um amadurecimento da tecnologia e
experimentar os reais benefícios dela, sem a pressão da novidade.
Figura 43 - Hype Cycle de Tecnologias Emergentes de Julho de 2011 - Gartner Research
Enquanto os metaversos e mundos virtuais passam do estágio de novidade
ao de tecnologia consolidada, usuários e organizações estão mais
preparados para utilizar estas tecnologias em modos que oferecem
benefícios práticos que poderão ser de uso em larga escala (e não apenas
participar de um mundo virtual porque todo mundo está lá como acontecia
no período de pico). Espera-se que nos próximos 5 ou 10 anos, quando a
tecnologia dos metaversos passar para uma segunda e terceira geração e os
jovens usuários dos mundos virtuais também envelhecerem, a demografia
dos usuários destes mesmos mundos também amadurecerá, transformando
a adoção e uso dos mundos virtuais em uma prática de maior aceitação. À
medida que a nova geração de gamers continua a entrar na força de
trabalho, suas demandas e necessidades deverão mudar sensivelmente o
modo como a socialização e o trabalho acontecem, de modo a vermos que
as fronteiras entre trabalho, jogo e aprendizado tendem a dissolver-se, ou
pelo menos serem modificadas (WASKO et al., 2011).
Os quadros a seguir, nos apresentam um panorama do número de contas
registradas nos mundos virtuais e a sua organização de acordo com faixa
etária a que são destinados em uma série histórica.
84
86
Cada círculo representa um mundo virtual, o que nos dá uma representação
mais fidedigna da correlação entre faixa etária e mundo correspondente.
Assim,
o
Second
Life
e
o
Utherverse
estão
mais
relacionados
estatisticamente com sujeitos acima de 30 anos, pois são mundos que são
mais direcionados para adultos. Por outro lado, Poptropica e Foopets são
mundos virtuais que situam-se na faixa etária entre 5 e 10 anos, mostrando
que as características constitutivas do mundo tendem a arregimentar
usuários estritamente situados em faixas cognitivas específicas e momentos
de maturação psicológica determinados. Ambos os mundos situam-se no
ponto do desenvolvimento psíquico designado por Freud (1905) como
situados período do declínio do complexo de Édipo. Foopets encontra-se
logo no começo da chamada latência e Poptropica situado no final do
período da mesma. Certamente um estudo psicanalítico destas implicações
seria algo que muito contribuiria para entendermos melhor e mais
profundamente a organização e estrutura ontológica dos mundos virtuais,
coisa que se encontra, entretanto, fora dos domínios da presente pesquisa.
A diversidade e variedade de questões que podem ser examinadas em
mundos virtuais, uma vez que espelham, modelam e ampliam a miríade de
interações disponíveis no mundo físico, fazem dos mundos virtuais um
contexto muito interessante de estudo.
Em meio a tudo isso, uma coisa sabemos: os metaversos e mundos virtuais
vieram para ficar.
*
Além dos aspectos referentes à utilidade e pertinência dos metaversos, uma
questão emergente é a relacionada com o agreement, também conhecida
como acolhimento. Ela designa quando um novo usuário resolve aceitar as
regras de participação dentro de um mundo virtual. Ainda que atualmente
elas sejam organizadas unilateralmente pela equipe de desenvolvimento,
com tempo e uso tendem a ser modificadas. Uma pequena observação aqui
pode ser colocada, em função do EULAs – End User License Agreement e os
aspectos que estão relacionados com ela. Vejamos.
Falamos acima do forte crescimento dos lucros da indústria de metaversos e
mundos virtuais. Diversas delas, como o Second Life e o WoW possuem até
mesmo economias virtuais que foram objeto de estudos por Baincridge
(2007) e outros autores. Pois bem, estas economias virtuais estão afetando
a economia real e também criando situações legais em que o Direito já está
sendo obrigado a considerar a questão da propriedade nos mundos virtuais.
Neste aspecto, encontramos um estudo muito interessante de Kim Barker
(2011) da Aberystwyth University sobre os EULAs – End User License
Agreements de metaversos e o quanto precisaram ser revistos por conta de
contravenções que jogadores começaram a fazer dentro dos mundos
virtuais:
“Dado o grande número de pessoas engajando-se e registrando-se
em
jogos
online
e
mundos
virtuais,
não
é
particularmente
surpreendente que disputas comecem a aparecer perante os
tribunais. Em outras jurisdições, as disputas já acontecem bastante,
com a Coreia do Sul até mesmo estabelecendo um esquadrão de
polícia especialmente dedicado a lidar com disputas virtuais.38 Nos
EUA também, há um histórico maior de casos do que no Reino Unido,
com litígios iniciados contra os desenvolvedores de plataformas em
relação às suas ações,39 e a ações de usuários.40 No Reino Unido não
houve nenhum exemplo de litígio relacionado com jogos online e
mundos
virtuais
ainda.
No
entanto,
no
início
deste ano,
a
propriedade virtual foi juridicamente reconhecida no Reino Unido
pela primeira vez.41
No Tribunal de Exeter Crown, Mitchell foi condenado por quatro
acusações de mau uso do computador relativas à invasão de contas
da Zynga e por roubar ouro virtual da Zynga.42 Esse ouro foi, então,
trocado por moeda real. Mitchell estava conseguindo um lucro no
mundo real a partir de seu furto no mundo virtual. Mitchell foi
considerado
culpado
e,
no
acórdão,
o
tribunal
reconheceu
judicialmente que a propriedade virtual pode existir e que direitos
podem ser reclamados sobre ela. Este é um desdobramento
significativo no Reino Unido porque sugere que os tribunais estão
dispostos a reconhecer que as pessoas podem ter direitos de
propriedade
38
quanto
aos
objetos
e
ouro
em
jogos
online,
BBC News, ‘’Game theft’ led to fatal attack’ (31 March 2005) Disponível online:
<http://news.bbc.co.uk/1/hi/technology/4397159.stm> [Acessado em 24/01/2012].
BlackSnow v Mythic Interactive Inc No 02-00112 (C.D. Calif.) [2002]; Bragg v Linden
Research Inc. (487 F.Supp 2d 593 E.D. Penn) (2007)
39
40
Hernandez v Internet Gaming Entertainment, U.S. Dist. Ct. Southern District of Florida,
Case No:07-CIV-21403-COHN/SELTZER [2007]
41
Herald Express, ‘Zynga hacker faces jail for $12 million theft” available online:
<http://www.thisissouthdevon.co.uk/news/HACKER-ADMITS-STEALING-12m-POKERCHIPS/article-3170994-detail/article.html> [Acessado em 24/01/2012].
42
ibid
88
independentemente do que esteja declarado nos EULAs. (BARKER,
2011)
O trabalho de Barker mostra o quanto a legislação e a sociedade foram
obrigadas a mudar por conta dos jogos online e metaversos. Os exemplos
são questões extremas: roubo de objetos virtuais que acabam em morte no
mundo real como em um caso na Coréia; roubos virtuais que acabam em
enriquecimento no mundo real; batalhas nos tribunais por questões de
disputa de autoria, entre outros. O mais interessante é que os tribunais na
Inglaterra já estão sendo obrigados a reconhecer os direitos das pessoas em
relação a bens virtuais. Isto é uma enorme mudança de paradigma, pois, o
que é um “bem virtual” no mundo real? Efetivamente não passa de bits e
bytes, mas significa dinheiro no mundo real.
CAPÍTULO 2:
IMPLANTANDO O COMPONENTE MULTIJOGADOR EM
METAVERSOS
N
este capítulo pretendemos fechar uma lacuna importante na
literatura brasileira ao explicar os rudimentos para estabelecer um
sistema multijogador que possa ser utilizado em metaversos. Nosso
objetivo último é que, ao final deste capítulo, o leitor possa entender como
criar um sistema multijogador em rede no Unity para a criação de um
metaverso. Não encontramos nenhum texto em português que indique o
caminho para isso de maneira que um não iniciado possa conseguir
estabelecer um sistema deste tipo.
ARQUITETURAS E MODELOS DE COMUNICAÇÃO
NOS JOGOS
MULTIJOGADOR EM REDE
Para podermos entender com propriedade os jogos multijogador em rede e
seu funcionamento precisamos antes ter ideia clara de alguns elementos
básicos sobre redes e os possíveis modelos de comunicação entre os nós da
rede.
Os jogos multijogador em rede dependem totalmente do tipo de conexão
entre os nós da rede em que os jogadores estão conectados. O tipo de
conexão determina uma série de fatores fundamentais para o perfeito
funcionamento deste tipo de game, dentre eles a latência43 e a largura de
banda44 da conexão. Para os jogos multijogador em rede podemos ter os
seguintes tipos de conectividade em tempo real (RABIN, 2010, p. 606):
43
Em uma rede com comutação de pacotes, latência é sinônimo do tempo que um
pacote de dados demora entre o seu envio por um nó da rede e a sua recepção no
nó de destino. Quanto menor a latência, mais rápida é a rede, portanto em jogos
multijogador deseja-se sempre a menor latência possível e altas latências podem
impedir que um jogo multijogador funcione.
44
Em telecomunicações, largura de banda refere-se ao “bit rate” de uma rede de
transferência de dados, isto é a quantidade de bits por segundo que a rede suporta.
(Fonte: Wikipedia)
90
Link direto: ligar computadores em uma conexão curta normalmente
garante baixa latência enquanto a largura de banda depende do meio.
Modos populares de fazer links diretos incluem um cabo serial modificado
(um cabo de modem de tipo NULL) e cabos USB. Links wireless populares
incluem infravermelho e Bluetooth. Cada um deles possui protocolos
especializados para facilitar a comunicação.
Redes com comutação de circuitos: o exemplo claro desta é a conexão por
telefone, que consiste em uma conexão direta dedicada (não compartilhada)
de baixa latência e com pouca distribuição, ou seja, acaba sendo limitada a
dois jogadores.
Redes com comutação de pacotes: a comutação de pacotes é um paradigma
de comunicação de dados em que pacotes (unidades de transferência de
informação) são individualmente encaminhados entre nós da rede através de
ligações de dados partilhadas por outros nós. A comutação de pacotes é
utilizada para otimizar o uso da largura de banda da rede e minimizar a
latência.
Uma vez estabelecido o tipo de conexão, é necessário um protocolo, ou
seja, um formato padronizado de transferência de dados entre os
dispositivos. Estes protocolos podem variar em sua função e seus métodos,
podendo definir, por exemplo, tamanhos e formatos diferentes de pacotes
de dados, metodologia de “acknowledgement” de recepção de dados,
checagem e correção de erros, compressão de dados, encripção de dados e
controle de pacotes (RABIN, 2010, p. 606).
Conforme o protocolo, o pacote de rede terá tamanho e formato diferentes,
mas sempre terá pelo menos duas ou três partes:

O cabeçalho que contém instruções sobre os dados contidos pelo
pacote. Estas instruções podem incluir comprimento do pacote,
sincronização (alguns bits que ajudam o pacote a se manter
ajustado com a rede); número do pacote (em uma sequência de
pacotes); bits que indicam o protocolo (o protocolo define o tipo de
pacote que está sendo transmitido: e-mail, página da Web, vídeo);
endereço de destino e endereço de origem.

O corpo que é composto pelos dados que estão sendo efetivamente
transmitidos.

O rodapé é composto por alguns bytes que avisam ao dispositivo
receptor que o fim do pacote foi atingido. Também pode haver algum
tipo de verificação de erro. A verificação de erro mais comum
utilizada nos pacotes é a Verificação de Redundância Cíclica (CRC).
O MODELO OSI
O modelo OSI é baseado em uma proposta da ISO (Internacional Standards
Organization) e foi a primeira iniciativa para a padronização internacional
dos protocolos usados por meio de um sistema de camadas.
H ISTÓRICO
No final dos anos 1970, enquanto a ARPAnet começava a fazer sucesso,
começaram a surgir computadores de pequeno porte e microcomputadores
de diversos tipos. Neste período também aumentou a procura por
equipamentos de rede. Entretanto, cada fabricante praticamente criava seu
próprio padrão, tornando impossível a comunicação entre equipamentos de
diferentes fabricantes.
Com base nesse contexto, em 1978 a ISO resolveu criar o Subcomitê SC16,
para estudar padrões para sistemas abertos. Assim, o SC16 criou o padrão
internacional 7498, chamado de Open Systems Interconnection, que definia
um modelo de referência para interconexão de sistemas abertos.
AS
CAMADAS DO MODELO
OSI
O objetivo de uma rede é transportar dados de um computador a outro da
melhor maneira possível. Para que isto aconteça os dados precisam ser
transmitidos em pacotes de bits um e zero. O modelo OSI estabelece os
padrões para que isto seja feito de modo que tanto o computador que está
enviando os dados possa fazê-lo em pacotes de modo organizado, como o
computador que recebe estes pacotes possa rearranjá-los de modo a
montar os dados do modo como eram originalmente no computador que os
enviou.
O Modelo OSI tenta explicar o funcionamento da rede, dividindo-a em 7
camadas como mostra a figura abaixo
92
Figura 44 - Modelo de referência OSI da ISO - Fonte: (RABIN, 2010, p.608)
Como vemos acima, o modelo OSI é dividido em sete camadas: aplicação,
apresentação, sessão, transporte, rede, enlace de dados e camada física.
Cada uma dessas camadas sintetiza, de modo abstrato, o funcionamento
dos computadores interligados em rede. O modelo utilizado pela internet
hoje é o do TCP/IP, uma variação do modelo OSI que combina as camadas
de Aplicação, Apresentação e de Sessão em apenas uma camada chamada
camada de Aplicação. Isto pode simplificar o modelo para quem trabalha
com as camadas inferiores, mas o grosso do trabalho de desenvolvimento
de games multijogador em rede acontece nas camadas superiores.
A seguir mostramos a função de cada uma delas a partir de um resumo da
explicação de Rabin (2010) sobre o Modelo OSI e sua importância para os
games multijogador em rede:
1 - Camada Física: tem a função de transformar os dados de enlace em bits
para transmiti-los no meio físico até alcançar o destino. Esta camada define
as características de tensão e de corrente elétrica para representar os bits, a
intensidade da luz num sistema de fibra ótica, os conectores, os cabos, o
clock usado na transmissão, a interface de rede, a topologia física da rede, o
meio de transmissão, o tipo de codificação usada para representar o bit 1 e
o 0. Não tem o intuito de verificar problemas como erros de transmissão.
Essa verificação deve ser realizada pelas camadas superiores;
A maior preocupação dos desenvolvedores de jogos com esta camada
refere-se à latência, à largura de banda e à confiabilidade do meio físico.
2 - Camada de Enlace de Dados: Essa camada é responsável por sequenciar
os dados para a camada física e gerencia a transmissão para o próximo nó
da rede. O adaptador Ethernet ou a placa de interface de rede gerencia esta
sequenciação ou serialização. Cada placa de rede contém um endereço MAC
para identificá-la como um nó único em uma rede local. Nem todas as
placas de rede possuem um endereço MAC único, entretanto para que uma
subrede possa comunicar-se, todas as placas de rede daquela subrede
precisam conter endereços MAC únicos.
3 – Camada de Rede: Esta camada gerencia a rota que os pacotes irão seguir
para atingir o seu destino. Aqui entra o IP (Internet Protocol) que é utilizado
como endereço de origem e de destino de um pacote.
4 – Camada de Transporte: Garante a entrega de dados entre nós da rede.
Ela pode recuperar-se de erros e controlar o fluxo de dados. Nela estão as
“portas” que são extensões lógicas dos endereços de IP. Aqui o protocolo
TCP junto ao sistema operacional controla a transmissão dos dados,
detectando problemas na transmissão e corrigindo erros.
Portas
Um número de porta funciona de modo análogo ao número de um
apartamento enquanto o endereço de IP equivaleria ao endereço de um
prédio. Para entregar correspondência, o carteiro precisa de ambos. As
conexões em rede também precisam de um “Endereço de Rede” completo.
Portanto um Endereço de rede = Endereço de IP + Porta
O TCP – Transmission Control Protocol funciona melhor para grandes
transmissões de dados que precisam chegar a seu destino. O TCP entrega
os dados para a camada de sessão na ordem absolutamente correta. Tem
um sistema de correção e controle que garante a integridade dos dados,
garantindo inclusive que pacotes que tenham sido perdidos sejam
reenviados. Os dados transmitidos via TCP entram na camada de sessão
mais como um stream do que pacotes individuais.
O UDP – User Datagram Protocol é um protocolo do tipo “envia e esquece”,
ou seja, não garante a ordem de recebimento dos pacotes ou sequer que o
pacote seja recebido no destino. Entretanto, justamente porque não tem
tantos controles de integridade dos dados do pacote, o tamanho dos seus
cabeçalhos é menor. Um tamanho menor de cabeçalho aliado à ausência de
94
reenvios de pacotes proporciona um modelo de melhor latência por largura
de banda do que o TCP.
5 – Camada de Sessão: Gerencia as conexões entre as aplicações. Suas
responsabilidades incluem estabelecer as conexões, finalizar conexões e
coordenar a troca de dados. A API de Sockets proporciona um modelo de
camada de sessão interplataforma para lidar com estas tarefas.
Sockets
A grosso modo, um socket é uma conexão através da qual pode-se enviar
ou receber bytes. Trata-se de um elo bidirecional de comunicação entre
dois programas baseados em computadores diferentes. O conceito de
realizar uma conexão em socket é que um computador esteja aguardando
(escutando) uma conexão e a respectiva mensagem em uma determinada
porta e que o outro computador tente se conectar ao primeiro em uma outra
porta determinada para passar a mensagem. Quando uma porta está
esperando uma conexão dizemos que ela está “aberta”.
É também uma abstração computacional que mapeia diretamente a uma
porta de transporte (TCP ou UDP) e mais um endereço de rede IP. Com esse
conceito é possível identificar unicamente um aplicativo ou servidor na rede
de comunicação IP.
Conexão de TCP
De acordo com Rabin (2010) O processo tem início com a criação de um
Socket, já especificando se utilizará o protocolo TCP ou UDP. Em seguida
passamos à conexão do TCP (TCP connect). Para conectar-se com um socket
aberto (escutando) em um outro host é necessário definir um endereço de
destino.
TCP Listener
Depois o host do TCP deve ligar o socket a uma porta e a um local adapter.
Em seguida o host deve escutar e esperar por conexões e finalmente esperar
para aceitar a conexão.
Transmissões em Stream
Depois da conexão, o cliente e o host/servidor podem enviar e receber
dados livremente. O stream significa aqui um fluxo de dados que já passou
por autorização.
Resumindo, a camada de sessão fornece os seguintes serviços:

Serviço para a conexão de sessão: antes da troca de dados é necessário
estabelecer uma conexão de sessão. O serviço orientado à conexão de
sessão é fornecido em três fases: estabelecimento da conexão, troca de
dados e encerramento da conexão.

Gerência de token: token é um controle que indica qual usuário pode
transmitir. A camada de sessão é responsável pela posse e entrega
desses tokens, auxiliando a controlar o ordenamento da transmissão.

Estabelece pontos de sincronização: esse recurso pode parar uma
determinada atividade que está em andamento (ex: transferência de um
arquivo na rede) e iniciar outra de maior prioridade ou quando o próprio
usuário interrompe a transferência para reiniciá-la mais tarde. Ao
reiniciar a transferência que foi interrompida, ela irá recomeçar do
último ponto de sincronização estabelecido. Esse ponto de sincronização
é uma marcação realizada durante a transferência de dados. Assim, caso
haja uma interrupção na transferência durante a transmissão, não será
necessário transferir todo o dado (todos os bits) novamente, mas
somente o que faltava, ou seja, do último ponto de sincronização em
diante. Esse recurso é também bastante utilizado quando acontece uma
parada, inesperada (ex: queda de energia) durante uma transferência em
rede, sendo que quando os equipamentos voltam a funcionar a atividade
pode recomeçar do último ponto de sincronização.
6 – Camada de Apresentação: Esta camada faz a conversão de diferentes
códigos ou formatos de dados, seja preparando dados para a transmissão
ou convertendo dados que estão chegando da rede para um formato
reconhecido pela camada de aplicação. Alguns códigos que podem ser
convertidos
são:
ASCII
(American
Standard
Code
for
Information
Interchange), EBCDIC (Extended Binary Code Decimal Interchange Code) e
Unicode. Além dessa conversão de formatos, essa camada pode trabalhar
com compressão de dados e criptografia.
A compressão de dados, segundo a Wikipédia, pode ser definida como a
redução de espaço ocupado por dados num determinado dispositivo por
meio da utilização de algoritmos de compressão que reduzem a quantidade
96
de bytes para representar um dado, de modo a retirar a redundância de bits,
reduzindo o tamanho total do arquivo.
A compressão é útil porque ajuda e reduzir o consumo de recursos de um
sistema, seja espaço em um hard disc ou consumo de banda na transmissão
de dados. Por outro lado, dados comprimidos precisam ser descomprimidos
para serem utilizados e este processamento extra pode ser prejudicial em
algumas aplicações.
A encriptação de dados é fundamental para evitar fraudes em jogos. Os
jogadores são as pessoas mais prováveis de fazerem um hack em um pacote
de jogo, portanto é boa prática nunca colocar dados sensíveis em uma DLL,
pois elas sáo facilmente abertas, permitindo que o usuário substitua a DLL
autêntica por uma outra em um processo conhecido como shimming. O
melhor método de esconder dados de olhos indesejáveis é fazer a
encriptação dento do módulo executável (RABIN, 2010 p.623)
Buffering
É na camada de apresentação que ocorre o “buffering”. O buffer45 (retentor)
é uma área de memória temporária utilizada para a escrita e leitura de
dados. Normalmente é utilizado quando existe uma diferença entre a taxa
em que os dados são recebidos e a taxa em que podem ser processados e
utilizados, ou no caso em que estas taxas são variáveis. Os buffers são
mecanismos muito utilizados em aplicações multimídia e em games em
especial nas aplicações de streaming
7 - Camada de Aplicação: é a camada de nível mais alto, ficando mais
próxima do aplicativo que o usuário utiliza. Aqui fica o programa que envia
e recebe dados da rede. Essa camada é responsável pela comunicação direta
entre o usuário do computador e a rede. No caso dos games, a camada de
aplicação lida diretamente com os dados e com a lógica do jogo. Enquanto
as camadas de apresentação e de sessão contêm implementações que
podem ser substituídas por middleware, a camada de aplicação é sempre
45
Ainda não existe uma tradução comumente aceita para o termo “buffer”, mas o
termo “retentor” seria uma boa alternativa, pois o buffer é uma área de memória
temporária que retém dados e libera-os à medida em que outras partes do sistema
estão prontas para recebê-los e processá-los.
parte do jogo. Aqui o modelo de atualização e os códigos de sincronização
são a parte principal dos jogos em rede.
Modelos de atualização (update models)
O modelo de atualização do jogo guia o design dos pacotes mais intensos
do jogo, enquanto o modelo de reflexão de input apresenta os pacotes que
chegam da rede como se fossem um outro dispositivo de i/o conectado ao
computador. O modelo de reflexão de estado processa o input de modo
local e envia os dados processados, como novas posições, orientações,
velocidades e acelerações.
Sincronização
Uma das atividades mais importantes de um programador de jogos em rede
é fazer com que todos os clientes permaneçam em sincronia com o mínimo
de anomalias visuais por conta de problemas com atrasos na rede. Existem
uma série de técnicas de compensação para prevenir problemas e
anomalias, como “lags” (atrasos) entre a sua posição e o que está sendo
mostrado nas telas dos outros computadores da rede, e para fazer com que
os movimentos dos objetos do jogo sejam tão fluentes e realistas quanto
possível.
MODELOS DE CONEXÃO
A partir da apresentação sintética do modo como funciona a transmissão de
dados, vejamos agora as possíveis alternativas de conexão para jogos
multijogador em rede (figura 45).
O item a) da figura 45 mostra um exemplo de jogo multijogador sem a
utilização de rede. É um exemplo em que os jogadores utilizam um mesmo
computador e compartilham a mesma tela. Há os casos dos jogos esportivos
em que existe um único campo de jogo na tela para todos os jogadores a
exemplo do Pong e do Atari Football. Em outros casos a tela é fisicamente
dividida com cada lado mostrando o avatar de cada jogador em jogo.
Diversos jogos de consoles atuais utilizam este modo, como o Boxe para o
Wii, já mencionado.
98
Figura 45 - As arquiteturas de comunicação possíveis para jogos multijogador:
a) somente um
computador utilizado por todos os jogadores e tela b) peer-to-peer c) cliente-servidor d) híbrido de
peer-to-peer e cliente-servidor e) rede de servidores. (Fonte: ARMITAGE et al., 2006 p.16)
O item b) representa uma arquitetura peer-to-peer. Nesta arquitetura todos
os clientes são “colegas” ou “peers”, isto é, nenhum tem mais controle do
jogo que os outros. Trata-se de um sistema descentralizado e sem qualquer
tipo de controle de segurança. Não há nenhum mediador que controle o
estado do jogo ou que faça o roteamento de mensagens. Todos os clientes
conversam entre si na rede. Este modelo apresenta a menor quantidade de
latência porque os pacotes não têm que ser enviados primeiro para um
servidor para depois serem transferidos para o cliente final. O benefício em
relação à latência tem como contrapartida um custo em maior utilização de
banda. As arquiteturas “peer-to-peer” são populares em jogos multijogador
jogados em redes locais geralmente por conta do pequeno número de
jogadores participando de um jogo.
Já o exemplo c) da figura 45 é o de uma arquitetura cliente-servidor. Em
uma arquitetura deste tipo, um processo tem o papel de servidor,
comunicando com cada cliente e mediando o estado do jogo. Os clientes
não se comunicam diretamente uns com os outros, mas o servidor roteia as
mensagens para os clientes apropriados. Este é um exemplo de arquitetura
que possui uma estrutura centralizada no servidor e qualquer ação e
comunicação da parte dos clientes precisa necessariamente passar pela
autorização deste. O servidor é a parte crítica da comunicação na rede, se
um cliente não puder comunicar-se com o servidor do jogo não conseguirá
jogar e se o servidor puder mantiver a comunicação e computação
necessárias, a jogabilidade poderá degradar para todos os clientes. A
arquitetura cliente-servidor é a mais utilizada em jogos on-line comerciais,
bem como nos clássicos MUDs.
No exemplo d) da figura 45 de arquitetura híbrida de peer-to-peer e
cliente-servidor, o processo do servidor medeia o estado do jogo com base
em informações enviadas pelos clientes como na arquitetura clienteservidor tradicional, mas os clientes também são capazes de comunicaremse uns com os outros como na arquitetura peer-to-peer tradicional. A
comunicação entre os peers do cliente serve geralmente para informações
do jogo que não são essenciais para alcançar pontos ou que possam afetar a
jogabilidade dos outros jogadores. Por exemplo, é comum ter comunicação
via VoIP (Voice Over Internet Protocol) feita de modo peer-to-peer enquanto
os comandos para controlar um avatar continuam feitos pelo modo clienteservidor.
Com uma arquitetura cliente-servidor pura ou híbrida, o servidor pode
facilmente tornar-se um gargalo para o desempenho, seja porque não pode
acompanhar a taxa de envio e recebimento de mensagens para todos os
clientes ou porque não pode processar as atualizações de estado do jogo
rápido o suficiente. Para resolver esta situação, podemos ter uma
arquitetura como a sugerida pelo exemplo e) da figura 45, uma arquitetura
com uma rede de servidores. Nesta, ao invés de um único servidor,
podemos ter um conjunto de vários servidores interligados. A comunicação
entre os servidores pode ser configurada de forma peer-to-peer (ou seja,
todos os servidores são iguais) ou de forma cliente-servidor em que os
servidores comunicam-se com um servidor mestre de forma hierárquica. Ao
dividir a carga dos clientes por vários servidores, a rede de servidores pode
reduzir as necessidades de capacidade imposta a um único servidor. Isto
pode aumentar a escalabilidade da arquitetura do jogo, mas, por outro lado,
tem a desvantagem de possuir um mecanismo de comunicação mais
complicado, geralmente com dificuldade extra para manter informações de
estado de jogo consistentes.
Além dos modelos acima, temos aquele inicialmente usado pela primeira
versão de Doom que é o broadcast, em que todos os nodes transmitem para
100
os demais indistintamente. Isto provou ser não aconselhável, como vimos na
situação do banimento da primeira versão do Doom em redes de empresas
e universidades devido à deterioração das condições da rede que este tipo
de comunicação provoca.
MONTANDO UMA REDE MULTIJOGADOR NO UNITY PARA A
CRIAÇÃO DE METAVERSOS .
Com a apresentação dos protocolos e modelos de comunicação dos jogos
multijogador em rede vamos agora mostrar algumas alternativas de como
montar o componente multijogador em rede para a criação de um
metaverso no Unity 3D. Primeiro vamos estudar algumas técnicas de M.
Hergaarden, codnome Leepo, sobre como implementar alguns elementos
básicos de sistemas multijogador e entender como funcionam. Depois
vamos estudar um exemplo de um framework já estabelecido de socketserver (sistema cliente/servidor multijogador), o Photon, que pode facilitar
muito a criação de metaversos, nosso objetivo aqui.
TÉCNICAS DE M. HERGAARDEN (LEEPO) PARA INSTALAÇÃO DE
COMPONENTE MULTIJOGADOR EM REDE NO
UNITY
Uma das propostas interessantes que trabalha com a implementação do
componente para múltiplos jogadores em rede no motor Unity 3D, é o
trabalho de M. Hergaarden (2011) intitulado “Ultimate Unity Networking
Project” disponível na Asset Store do Unity e no website da empresa de
produção de games independentes M2H da Holanda.
O trabalho de Hergaarden organiza-se como uma solução proprietária 46
que promete ajudar os desenvolvedores a adicionar um componente para
múltiplos jogadores a games criados com o Unity. O projeto é composto por
três partes: (1) Tutoriais, (2) Projetos de exemplo e (3) documentação
adicional.
Hergaarden nos informa que seu trabalho discute os elementos básicos e
que proporciona todos os recursos necessários para integrar o componente
para múltiplos jogadores em rede para projetos de games em Unity. O
ponto positivo do trabalho é que o autor procurou ser bastante didático e
mostrou de maneira prática os principais passos e métodos de scripting
para a criação de jogos multiusuário no Unity. O ponto negativo é que, a
46
Por se tratar de uma solução proprietária, os scripts serão colocados somente em
parte para garantir os direitos de autor de M. Hergaarden. Para visualizar todo o
código, favor acessar a Asset Store do Unity e comprar acesso ao “Ultimate
Networking Project”.
102
despeito disso, o trabalho de Hergaarten pode ser bastante obscuro para
pessoas não iniciadas por não explicar em detalhe a questão da arquitetura
e modelo de comunicação utilizados.
1. T UTORIAL 1 – C ONECTAR
E
D ESCONECTAR
O SERVIDOR E UM CLIENTE
O Tutorial 1 consiste em uma cena para o Unity que mostra como conectar e
desconectar de um servidor em uma arquitetura cliente/servidor (figura 46).
Figura 46 - Aspecto da tela do Tutoria1 1 de Hergaarden mostrando um servidor desconectado e depois
conectado como servidor.
O procedimento de funcionamento do Tutorial 1 é o seguinte:
1. Abrir a cena Tutorial 1 no Unity. Esta cena é composta por uma
câmera, um GameObject com o script de conexão e um GameObject
para exibir o título da cena.
2. Criar e executar um webplayer
3. Iniciar a cena no editor também e clicar em “Start Server” (iniciar
servidor) utilizando os valores padrão para IP e porta.
4. Clique em "Connect as client” (conectar-se como cliente) no
webplayer.
5. Com isto será possível ver "Connection status: Client" em uma
instância e "Connection status: Server!" na outra.
Hergaaden pede que olhemos o arquivo Tutorial1/Connect.js no editor de
scripts. Todo o código que foi usado neste tutorial pode ser encontrado na
função OnGUI() como segue:
function OnGUI()
{
if (Network.peerType == NetworkPeerType.Disconnected){
//We are currently disconnected: Neither client nor host
GUILayout.Label("Connection status: Disconnected");
connectToIP = GUILayout.TextField(connectToIP,
GUILayout.MinWidth(100));
connectPort = parseInt(GUILayout.TextField(connectPort.ToString()));
GUILayout.BeginVertical();
if (GUILayout.Button ("Connect as client"))
{
//Connect to the "connectToIP" and "connectPort" as entered via
the GUI
Network.Connect(connectToIP, connectPort);
}
if (GUILayout.Button ("Start Server"))
{
//Start a server for 32 clients using the "connectPort" given via
the GUI
//Ignore the NAT setting for now (False)
Network.InitializeServer(32, connectPort, false);
}
GUILayout.EndVertical();
}else{
//We've got one or more connection(s)!
if (Network.peerType == NetworkPeerType.Connecting){
GUILayout.Label("Connection status: Connecting");
} else if (Network.peerType == NetworkPeerType.Client){
GUILayout.Label("Connection status: Client!");
GUILayout.Label("Ping to server: "+Network.GetAveragePing(
Network.connections[0] ) );
} else if (Network.peerType == NetworkPeerType.Server){
GUILayout.Label("Connection status: Server!");
GUILayout.Label("Connections: "+Network.connections.length);
if(Network.connections.length>=1){
GUILayout.Label("Ping to first player:
"+Network.GetAveragePing( Network.connections[0] ) );
}
}
if (GUILayout.Button ("Disconnect")) {
Network.Disconnect();
}
}
}
As duas variáveis no topo do script (connectToIP e ConnectPort) são
utilizadas para captar a entrada do campo GUI. Esses valores são usados
quando se pressiona o botão para conectar o servidor ou o botão para
conectar o cliente. A Função GUI é dividida em quatro partes: uma para o
servidor, outra para os clientes conectados, outra para os clientes que estão
conectando-se e outra para clientes desconectados. O "Network.peerType" é
utilizado para verificar o status da conexão atual. Chamamos a função
“Network.Connect” para conectar clientes ao servidor, esta função tem
porta, IP e opcionalmente uma senha como argumentos. Para iniciar um
servidor chamamos a função “Network.InitializeServer” com porta, número
máximo permitido de conexões e um booleano para configuração do NAT
como argumentos.
O NAT, “Network Address Translation”, é fundamental para que os clientes
atrás de um roteador (dentro de uma LAN) possam conectar-se com outros
usuários pela internet. No Tutorial 1 o “Network.InitializeServer” deve ser
definido como falso, pois somente vai ser utilizado dentro de uma LAN e
não se conectará a usuários externos.
104
O restante do código do arquivo contém aproximadamente 10 outras
funções que são automaticamente chamadas pelo Unity. Nenhuma delas é
necessária ao tutorial. Se desejar removê-las, o tutorial continuará a
funcionar normalmente. As primeiras cinco funções do cliente e do servidor
são bastante auto-explicativas. Elas são chamadas apenas pelo(s) cliente(s)
ou apenas pelo servidor. Somente o OnDisconnectedFromServer é chamado
por ambos, tanto clientes como servidores. Se quiser utilizar os parâmetros
passados pelas funções por alguma razão, veja o manual do Unity sobre
estas funções.
As últimas três funções são diferentes. “OnFailedToConnectToMasterServer”
é chamada por um cliente (ou servidor) quando, de alguma forma, não
conseguimos nos conectar ao servidor principal do Unity. Mais detalhes
sobre isto serão tratados adiante. A função “OnNetworkInstantiate” é
chamada por objetos instanciados, veremos isto também mais adiante. A
função “OnSerializeNetworkView” é o primeiro dos dois métodos para o
envio de mensagens por meio do servidor para todos os clientes. Os
“Remote Procedure Calls” ou RPCs - são chamadas de procedimentos
remotos, que são funções ou mensagens de rede que você mesmo pode
definir. Estes serão discutidos no Tutorial 2.
Ao final do Tutorial 1, Hergaarden aconselha que vejamos a documentação
sobre redes do Unity (Network Documentation), em especial os itens
“Messages Sent”, “Class Variables” e “Class Functions“ na seguinte URL:
http://unity3d.com/support/documentation/ScriptReference/Network.html
Esta página apresenta uma referência rápida a todas as funções de
networking do Unity.
2. T UTORIAL 2A – O
SERVIDOR JOGA , O CLIENTE OBSERVA , SEM
INSTANCIAÇÃO
Os Tutoriais 2A1, 2A2 e 2A3 mostram três maneiras diferentes de enviar
mensagens entre o servidor e os clientes. Cada um mostra uma técnica
diferente, cada vez um pouco mais sofisticada para ter melhor controle dos
objetos que fazem parte da rede.
T UTORIAL 2A1
No Tutorial 2A1, Hergaarden adiciona aos códigos de conexão do Tutorial 1
alguns novos elementos, como o objeto "PlayerCube" que, por sua vez, tem
o script
"Tutorial_2A1.js" e um
componente "Network View" anexados.
Todo objeto que envia ou recebe mensagens de rede requer um
componente “Network View”. É fundamental adicionar um Network View por
objeto que você desejar que faça parte da rede, por exemplo, adicionar um
Network View a cada jogador e ao código do GameManager.
Figura 47 - Tutorial 2A1 em funcionamento. A janela da esquerda está com o servidor conectado. A da
direita e a inferior estão com clientes conectados. Quando a janela do servidor está selecionada podemos
movimentar o cubo com as setas do teclado. As janelas dos clientes acompanham a movimentação do
cubo no servidor.
Se executarmos o tutorial 2A1 em janelas via webplayer com um servidor e
dois clientes, os clientes poderão ver o servidor movendo um cubo sobre
um tabuleiro (figura 47). A “mágica” deste movimento deve-se à observação
do Network View e o código de movimento
que está no script
“Tutorial_2A1.js” anexado ao cubo. Este código é executado somente no
servidor (por meio do Network.isServercheck). Veja parte do script do
Tutorial_2A1.js abaixo:
/*
This file is part of the "Ultimate Unity networking project" by M2H
(http://www.M2H.nl)
* This project is available on the Unity Store. You are only allowed to use these
* resources if you've bought them from the Unity Assets Store.
*/
#pragma strict function Update(){
//This is only run on the Server
if(Network.isServer){
var
moveDirection
:
Vector3
=
new
Vector3(1*Input.GetAxis("Vertical"), 0, Input.GetAxis("Horizontal"));
var speed : float = 5;
transform.Translate(speed * moveDirection * Time.deltaTime);//now
really move!
}
}
106
Quando usarmos as teclas de movimento no servidor, o cubo será movido
para qualquer direção que desejarmos. Agora, como os clientes enxergam o
movimento do servidor? Basta ver o Network View anexado ao cubo. O
Network View está observando as "transformações" do cubo, ou seja, o Unity
irá automaticamente enviar as informações de transformação do objeto, isto
é, a posição, rotação e escala de Vector3. Neste exemplo as informações
somente são enviadas do servidor para os clientes (e não o contrário)
porque o servidor é o proprietário deste Network View (aqui os clientes não
enviam informações, somente recebem-nas). O servidor é automaticamente
o proprietário de objetos que são hardcoded'47 em uma cena. Mais adiante
vamos ver como os clientes podem ser proprietários de objetos que eles
instanciarem na rede.
A utilização da propriedade de sincronização "Observed" (figura 49) ajudounos a rapidamente habilitar na rede o movimento do jogador. No entanto, a
propriedade "Observed" não é muito inteligente: pode ser usada para
transformações, mas envia dados não necessários, como escala, por
exemplo. Fora este exemplo simples do Tutorial 2A1, não utilizaremos a
propriedade "Observed" para configurar automaticamente as mensagens à
nossa rede, já que seria realmente necessário definir manualmente o tráfego
de rede para obter o máximo proveito dela.
47
O termo “hardcoded” não possui um termo semelhante em português. Significa escrever o código
diretamente sobre o motor, sem que este esteja dentro de um script que pode ser tratado ou chamado.
Figura 48 - No mesmo contexto da figura anterior, o cliente que estava na janela inferior foi
desconectado. Neste caso, somente o cliente que continua conectado (direita) acompanha a
movimentação do cubo do servidor (esquerda).
Em nosso teste do Tutorial_2A1 desconectarmos um dos clientes (figura
48). Somente o cliente que continua conectado continua mostrando a
movimentação do cubo do servidor, pois a comunicação do cliente na janela
inferior foi interrompida quando foi desconectado do servidor e este não
recebe mais as atualizações das transformações de posição do cubo.
Vejamos as demais opções
do “Network View” (figura
49).
A
opção
“State
Synchronization” 48 (estado
de
sincronização)
do
Network View quanto ao
Cubo
“PlayerCube”
definida como
for
“Reliable
compressed” (comprimido
confiável).
que
o
Isso
significa
Network
View
somente enviará os valores
Figura 49 - Na tab “inspector” do Unity definimos como deve ser
o estado da sincronização da comunicação de dados com a rede
via Network View para um dado objeto. As opções disponíveis são
“reliable delta compresssed”, “unreliable” e “off”.
48
State synchronization – Ver documentação do Unity :
http://unity3d.com/support/documentation/Components/net-StateSynchronization.html
108
do objeto observado se os valores forem modificados. Esta é uma maneira
inteligente de diminuir o trafego de dados desnecessários na rede. Se o
servidor não se mover, não enviará quaisquer dados. Por outro lado, se o
“State Synchronization” for definido como “Unreliable” (não confiável) o
Network View enviará os dados de transformação a todo momento
independentemente deste ter sido alterado ou não. Finalmente, a definição
do “State Synchronization” como "off" obviamente parará toda sincronização
de rede neste Network View. Se o seu Network View não está observando
qualquer objeto, obviamente não enviará qualquer dado e a opção de
sincronização
pode (mas
não
precisa) ser
configurada
como
"off".
Poderíamos nos perguntar por que usaríamos Network View em “off”. A
resposta é para RPCs: “Remote Procedure Calls” (Chamadas de Procedimento
Remoto). Estas precisam de um Network View, mas não utilizam a opção
“State
Synchronization”
nem
a
propriedade
“Observed”.
Ambas
são
ignoradas para RPCs. Os RPC são trabalhados no tutorial 2A3 de
Hergaarden.
T UTORIAL 2A2
O Tutorial 2A2 aparentemente funciona do mesmo modo que o Tutorial
2A1, mas o código executado em segundo plano foi alterado. Este novo
código proporciona um controle maior sobre o que está sendo sincronizado
pelo Unity. Por exemplo, poderia ser útil se desejássemos mover o cubo no
eixo y e não somente no x e z como acontece no Tutorial 2A1.
O Network View anexado ao PlayerCube agora está observando o script
"Tutorial_2A2.js". Isto significa que o Network View está procurando a
função "OnSerializeNetworkView" dentro desse script. Para os scripts, esta
função define o que está sendo observado. Vejamos o script:
Conteúdo do script Tutorial_2A2.js
/*
(http://www.M2H.nl)
*/
function Update(){
//Only the server can move the cube!
var
moveDirection
:
Vector3
=
new
1*Input.GetAxis("Vertical"), 0,Input.GetAxis("Horizontal"));
transform.Translate(speed * moveDirection * Time.deltaTime);
}
}
Vector3(-
function OnSerializeNetworkView(stream : BitStream, info : NetworkMessageInfo)
{
if (stream.isWriting){
//Executed on the owner of the networkview; in this case the Server
//The server sends it's position over the network
var pos : Vector3 = transform.position;
stream.Serialize(pos);//"Encode" it, and send it
/*
var jumpBoolean = Input.GetButton ("Jump");
stream.Serialize(jumpBoolean);
*/
}else{
//Executed on the others; in this case the Clients
//The clients receive a position and use it
var posReceive : Vector3 = Vector3.zero;
stream.Serialize(posReceive); //"Decode" it and receive it
transform.position = posReceive;
/*
var jumpBoolean = false;
stream.Serialize(jumpBoolean);
if(jumpBoolean){
Debug.Log("We are jumping");
}
*/
}
}
Agora a função "OnSerializeNetworkView" define explicitamente o que
deseja sincronizar. Podemos usar esta função para sincronizar quaisquer
elementos que desejemos e, somente os valores que realmente forem
mudados serão enviados se usarmos a opção "Reliable delta compressed”. A
função “OnSerializeNetworkView” é utilizada para enviar e receber os dados.
O Unity decide se você pode enviar ("istream.isWriting") ao checar quem é o
dono no Network View, caso contrário, você só será capaz de receber
(porção do script depois do "else"). O servidor é sempre o proprietário neste
caso, uma vez que detém todos os Network Views que estão hardcoded na
cena.
T UTORIAL 2A3
O terceiro método para enviar mensagens apontado como preferido de
Hergaarden é o que é feito por meio de RPCs ou Remote Procedure Calls845
(Chamadas de Procedimento Remoto). Mais uma vez, esta demo funciona
exatamente como as duas anteriores, mas usa ainda outra maneira de
enviar mensagens.
O NetworkView já não está observando nada (e a opção de “state
synchronization” está, portanto, definida como "off"). A chave deste terceiro
método está no script "Tutorial_2A3.js”, especificamente esta linha:
networkView.RPC ("SetPosition", RPCMode.Others, transform.position);
110
Vejamos o código do Tutorial_2A3.js:
/*
(http://www.M2H.nl)
*/
#pragma strict
private var lastPosition : Vector3;
function Update(){
//Only the server can move the cube!
var
moveDirection
:
Vector3
=
new
1*Input.GetAxis("Vertical"), 0,Input.GetAxis("Horizontal"));
Vector3(-
//Save some network bandwidth; only send an rpc when the position has
moved more than X
if(Vector3.Distance(transform.position, lastPosition)>=0.05){
lastPosition=transform.position;
//Send the position Vector3 over to the others; in this case
all clients
networkView.RPC("SetPosition",
RPCMode.Others,
transform.position);
}
}
}
@RPC
function SetPosition(newPos : Vector3){
//In this case, this function is always ran on the Clients
//The server requested all clients to run this function (line 25).
transform.position=newPos;
}
O RPC é chamado pelo servidor com o efeito de pedir aos outros clientes
que chamem a função "SetPosition" com o transform.position do servidor
como parâmetro (por exemplo: 5.2). Então, SetPosition(5.2); é chamado por
todos os clientes. É assim que o movimento é processado:
1. O jogador do servidor pressiona uma tecla de movimento e move seu
próprio jogador.
2. O servidor verifica se a sua posição mudou pelo menos em um valor
mínimo desde a última atualização da rede. Em caso afirmativo, envia uma
RPC para todos, menos para si, com a nova posição como parâmetro.
3. Todos os clientes recebem o SetPosition do RPC com o parâmetro
definido pelo servidor, e executam esse código em "seu próprio mundo".
4. O resultado é que os cubos ficam exatamente na mesma posição no
servidor e nos clientes.
Para ativar uma função para atuar como RPC você precisa adicionar "@RPC"
acima dela em javascript (ou [RPC] no C#). Ao enviar um RPC é possível
especificar os receptores da seguinte forma:
RPCMode.Server
Enviar somente para o servidor
RPCMode.Others
Enviar
para
todos,
exceto
para
exceto
para
quem está enviando.
RPCMode.OthersBuffered
Enviar
para
todos,
quem está enviando, utilizando um
Buffer.
RPCMode.All
Enviar para todos, inclusive para
quem está enviando.
RPCMode.AllBuffered
Enviar para todos, inclusive para
quem está enviando, utilizando um
Buffer
O buffer significa que sempre que novos jogadores conectarem-se, vão
receber esta mensagem. Um RPC com buffer é útil, por exemplo, para
criar/gerar um jogador (Spawn). Esta chamada de criação (spawn call) será
lembrada e quando novos jogadores conectarem-se, estes receberão RPCs
de criação para criar as instâncias dos jogadores que já estavam jogando
antes deles.
3. T UTORIAL 2B - S ERVIDOR
E CLIENTES JOGAM UTILIZANDO INSTÂNCIAS .
Os detalhes apresentados por Hergaarden neste tutorial podem formar as
bases para um jogo FPS real. Queremos permitir múltiplos jogadores. Para
isso, será necessário instanciar os jogadores quando eles se conectam, em
vez de ter um playerobject na cena.
Abra a cena "Tutorial 2B" com um servidor e um cliente. Neste exemplo, ao
ser selecionado, o servidor deve ser capaz de mover o seu próprio cubo e o
cliente, por sua vez, também deve ser capaz de mover o seu: o segundo
cubo. Mais clientes gerarão cubos adicionais e cada um controla o seu
respectivo cubo.
112
O GameObject “PlayerCube” foi removido nesta cena. Em seu lugar, o script
“Tutorial_2B_Spawnscript.js”
foi
adicionado
ao
novo
GameObject
“Spawnscript”. Vejamos parte do script Tutorial_2B_Spawnscript.js:
/*
(http://www.M2H.nl)
*/
public var playerPrefab : Transform;
function OnServerInitialized(){
Spawnplayer();
}
function OnConnectedToServer(){
Spawnplayer();
}
function Spawnplayer(){
var
myNewTrans
:
Transform
=
Network.Instantiate(playerPrefab,
transform.position, transform.rotation, 0) as Transform;
}
function OnPlayerDisconnected(player: NetworkPlayer) {
Debug.Log("Clean up after player " + player);
Network.RemoveRPCs(player);
Network.DestroyPlayerObjects(player);
}
function OnDisconnectedFromServer(info : NetworkDisconnection) {
Debug.Log("Clean up a bit after server quit");
Network.RemoveRPCs(Network.player);
Network.DestroyPlayerObjects(Network.player);
/*
* Note that we only remove our own objects, but we cannot remove the other
players
* objects since we don't know what they are; we didn't keep track of them.
* In a game you would usually reload the level or load the main menu level
anyway ;).
*
* To reset the scene we'll just reload it:
*/
Application.LoadLevel(Application.loadedLevel);
}
Quando um jogador (seja servidor ou cliente) começa a cena, o Spawnscript
irá instanciar o “prefab” especificado (Tutorial_2B_Prefab). A instância
necessita de argumentos como posição, rotação e grupo. Aqui copiamos a
posição e a rotação do objeto do Spawnscript e utilizamos “0” como grupo
por enquanto. Quando um cliente desconecta-se do servidor, o Spawnscript
remove o objeto instanciado que era de sua propriedade. Aquele que chama
o “Network.Instantiate” é automaticamente o proprietário deste objeto. É por
isso que os controles de movimento dos cubos de cada um dos jogadores
clientes funcionam logo de início para todos os clientes que se conectam. O
sistema verifica quem é o proprietário do NetworkView para decidir se este
cliente
pode
controlar
um
determinado
jogador
ou
não.
O
"Tutorial_2B_Playerscript.js" usa o código de movimento do Tutorial 2A2
com a diferença de que apenas as teclas de movimento pressionadas pelo
proprietário do objeto farão com que este objeto mova-se. Veja parte do
código do Tutorial_2B_Playerscript.js:
/*
(http://www.M2H.nl)
*/
function Awake(){
if(!networkView.isMine){
//We aren't the networkView owner, disable this script
//RPC's and OnSerializeNetworkView will STILL get
prevent Update from running
enabled=false;
}
}
trough
but
we
function Update(){
if(networkView.isMine){
//Only the owner can move the cube!
//(Ok this check is a bit overkill since we did already disable the
script in Awake)
var moveDirection : Vector3 = new Vector3(Input.GetAxis("Horizontal"),
0, Input.GetAxis("Vertical"));
}
}
function OnSerializeNetworkView(stream : BitStream, info : NetworkMessageInfo)
{
if (stream.isWriting){
//Executed on the owner of this networkview;
//The server sends it's position over the network
var pos : Vector3 = transform.position;
stream.Serialize(pos);//"Encode" it, and send it
}else{
//Executed on the others;
//receive a position and set the object to it
var posReceive : Vector3 = Vector3.zero;
stream.Serialize(posReceive); //"Decode" it and receive it
transform.position = posReceive;
}
}
4. T UTORIAL 3 – S ERVIDORES
AUTORIZADORES ( AUTHORITATIVE SERVERS )
As configurações do servidor dos últimos exemplos são o que chamamos
servidores "não-autorizadores". Não havia nenhum tipo de autorização do
servidor sobre as mensagens da rede. Os clientes compartilhavam sua
posição e todos aceitavam estas mensagens automaticamente. Em um FPS
multijogador você não quer que as pessoas editem seus pacotes de rede (ou
editem o jogo diretamente) para serem capazes de se teletransportar, fazer
“cheats” etc. É por isso que os servidores são sempre configurados como
114
servidores autorizadores nestes jogos. A criação de um servidor autorizador
não necessita de códigos muito rebuscados, mas requer que seu código
multijogador seja desenhado de um modo um pouco diferente dos
exemplos anteriores. É necessário que o servidor faça todo o trabalho,
verifique e autorize toda a comunicação.
Primeiro
pensemos
em
quais
mudanças
no
último
exemplo
(2B)
precisaríamos fazer para que tenhamos um servidor autorizador em nosso
novo exemplo. Em primeiro lugar, o servidor precisa gerar os jogadores
(fazer o “spawn” dos jogadores). Os jogadores não podem decidir quando
querem ser gerados e onde. Em segundo lugar, o servidor precisa enviar a
todos a posição correta de todos os objetos dos jogadores. Os jogadores
não podem compartilhar as suas próprias posições. O servidor precisa fazer
isso. Por esta razão, ao cliente só é permitido solicitar a movimentação por
meio do envio de uma requisição do movimento desejado. Isto significa
enviar para o servidor quaisquer códigos de entrada de movimento que o
cliente realizar pelos dispositivos de entrada do computador, seja via
teclado, mouse ou joystick. Vamos enviar todas as requisições de
movimento dos clientes para o servidor, e o servidor as processará e enviará
o resultado (a nova posição) de volta para todos os clientes.
Vejamos a cena do Tutorial 3. Mais uma vez, ela aparentemente funcionará
como o exemplo anterior, mas o código por trás mudou. O movimento
provavelmente será feito com um pouco de atraso (“lag” em inglês), mas
isso não tem importância agora. Mais adiante apresentaremos algumas
técnicas para resolver este tipo de questão.
Nenhum script novo foi adicionado desde o último exemplo, somente o
Playerscript e o Spawnscript foram alterados. Vamos começar com o
"Tutorial_3_Spawnscript.js":
Código completo somente via Asset store da Unity – Ultimate Networking Solution
/*
(http://www.M2H.nl)
*/
import System.Collections.Generic;
public var playerPrefab : Transform;
public
var
playerScripts
:
List.<Tutorial_3_Playerscript>();
List.<Tutorial_3_Playerscript>
function OnServerInitialized(){
//Spawn a player for the server itself
Spawnplayer(Network.player);
}
function OnPlayerConnected(newPlayer: NetworkPlayer) {
=
new
//A player connected to me(the server), spawn a player for it:
Spawnplayer(newPlayer);
}
function Spawnplayer(newPlayer : NetworkPlayer){
//Called on the server only
var playerNumber : int = parseInt(newPlayer+"");
//Instantiate a new object for this player, remember; the server is therefore
the owner.
var
myNewTrans
:
Transform
=
Network.Instantiate(playerPrefab,
transform.position, transform.rotation, 0) as Transform;
//Get the networkview of this new transform
var newObjectsNetworkview : NetworkView = myNewTrans.networkView;
//Keep track of this new player so we can properly destroy it when required.
playerScripts.Add(myNewTrans.GetComponent(Tutorial_3_Playerscript)
as
Tutorial_3_Playerscript);
//Call an RPC on this new networkview, set the NetworkPlayer who controls this
new player
newObjectsNetworkview.RPC("SetPlayer", RPCMode.AllBuffered, newPlayer);//Set
it on the owner
}
Debug.Log("Clean up after player " + player);
for(var scripta in playerScripts){
var script : Tutorial_3_Playerscript = scripta as Tutorial_3_Playerscript;
if(player==script.owner){//We found the players object
Network.RemoveRPCs(script.gameObject.networkView.viewID);//remove the bufferd
SetPlayer call
Network.Destroy(script.gameObject);//Destroying the GO will
destroy everything
playerScripts.Remove(script);//Remove this player from the list
break;
}
}
//Remove the buffered RPC call for this player (SetPlayer, line 37)
var playerNumber : int = parseInt(player+"");
Network.RemoveRPCs(Network.player, playerNumber);
// The next destroys will not destroy anything since the players never
// instantiated anything nor buffered RPCs
}
Debug.Log("Resetting the scene the easy way.");
Application.LoadLevel(Application.loadedLevel);
}
Os clientes já não vão fazer nada aqui, o servidor inicia um processo de
geração de jogador (spawn) quando um novo cliente se conecta. Além disso,
o servidor mantém uma lista de jogadores conectados usando seus
playerscripts para ser capaz de excluir o objeto correto do jogador quando
este se desconectar. O Spawnscript seria um script 100% para o servidor se
não fosse a função “OnDisconnectedFromServer" que também é chamada
pelos clientes.
Passando para o script "Tutorial_3_Playerscript.js", este script não é somente
executado pelo proprietário do Network View do objeto. Já que o servidor
116
instanciou todos os objetos, ele é sempre dono de todos os Network Views.
Portanto, nós agora podemos usar nossa própria variável de proprietário
para detectar qual jogador "virtualmente" possui esse objeto de acordo com
nossa lógica de jogo. O proprietário do playerscript envia os códigos de
entrada de movimento para o servidor. O servidor executa todas as
playerscripts para processar o movimento de entrada e realmente mover os
jogadores. Agora, sim, temos um servidor autorizador em funcionamento.
Por favor, veja o código completo do "Tutorial_3_Playerscript.js" por meio da
Asset Store do Unity.
( ... ) Código completo disponível somente na Asset store da Unity – Ultimate
Networking Solution
public var owner : NetworkPlayer;
//Last input value, we're saving this to be able to save network messages/bandwidth.
private var lastClientHInput : float=0;
private var lastClientVInput : float=0;
//The input values the server will execute on this object
private var serverCurrentHInput : float = 0;
private var serverCurrentVInput : float = 0;
function Awake(){
if(Network.isClient){
// We are probably not the owner of this object: disable this script.
// RPC's and OnSerializeNetworkView will STILL get trough!
// The server ALWAYS run this script though
enabled=false;
// disable this script (this disables Update());
}
}
@RPC
function SetPlayer(player : NetworkPlayer){
owner = player;
if(player==Network.player){
//Hey thats us! We can control this player: enable this script (this
enables Update());
enabled=true;
}
}
function Update(){
//Client code
if(owner!=null &&
//Only the
var HInput
var VInput
Network.player==owner){
client that owns this object executes this code
: float = Input.GetAxis("Horizontal");
: float = Input.GetAxis("Vertical");
//Is our input different? Do we need to update the server?
if(lastClientHInput!=HInput || lastClientVInput!=VInput ){
lastClientHInput = HInput;
lastClientVInput = VInput;
//Too bad a server can't send an rpc to itself using
"RPCMode.Server"!
//This is a Unity "feature", see `Tips`
SendMovementInput(HInput, VInput);
}else if(Network.isClient){
//SendMovementInput(HInput, VInput); //Use
this
(and
line 64) for simple "prediction"
networkView.RPC("SendMovementInput",
HInput, VInput);
}
RPCMode.Server,
}
}
//Server movement code
if(Network.isServer){//To also enable this on the client itself, use: "||
Network.player==owner){|"
//Actually move the player using his/her input
var moveDirection : Vector3 = new Vector3(serverCurrentHInput, 0,
serverCurrentVInput);
}
}
@RPC
function SendMovementInput(HInput : float, VInput : float){
//Called on the server
serverCurrentHInput = HInput;
serverCurrentVInput = VInput;
}
(...)
Para voltar ao assunto do “lag”, nos exemplos anteriores o cubo dos
jogadores movia-se imediatamente quando se pressionava uma tecla de
movimentação, mas neste exemplo com servidor autorizador precisamos
enviar o nosso pedido, esperar que o servidor processe-o para, finalmente,
poder receber do servidor a nova posição do objeto. Ao mesmo tempo queo
queremos que o servidor tenha toda a autoridade, não queremos que os
clientes fiquem à espera da resposta do servidor por tempo demais.
Podemos
facilmente corrigir
esse
“lag”
por
meio
de
um tipo
de
compensação, fazendo com que o cliente também calcule o movimento
imediatamente. O servidor irá sempre sobreescrever os movimentos
calculados de qualquer maneira e ainda continuará sendo um servidor
autorizador. Isto é bastante fácil de fazer. No "Tutorial_3_Playerscript.js"
basta fazer com que o cliente execute "SendMovementInput(HInput,Vinput);"
onde você está enviando a RPC de movimento (para fazer isso, descomente
a linha 56 do script). Certifique-se que o RPC call do SendMovementInput
realmente afete o cliente, atualizando o movimento (do servidor) com o
código na parte inferior da função Update(). Também execute-a no player
local também adicionando "|| Network.player == owner) {"na cláusula IF (ver
abaixo). Estas duas edições garantirão que o movimento dos clientes seja
aplicado de imediato, mas os cálculos do servidor ainda terão a última
palavra no final.
Vejamos as modificações no código para que isto aconteça. No final da
função “OnSerializeNetworkView”:
118
// transform.position = posReceive;
//To reduce laggy movement a bit you could comment the line above and
use position lerping below instead:
transform.position = Vector3.Lerp(transform.position, posReceive, 0.9);
//"lerp" to the posReceive by 90%
//It would be even better to save the last received server position
and
lerp
to
it
in
Update
because
it
is
executed
more
often
than
OnSerializeNetworkView
No IF final da função Update():
if(Network.isServer || Network.player==owner){
//Actually move the player using his/her input
var moveDirection : Vector3 = new Vector3(serverCurrentHInput,
serverCurrentVInput);
}
0,
Após a aplicação da “previsão” do cliente o movimento ainda parecerá um
pouco atrasado ou interrompido, especialmente se o cliente estiver fazendo
um movimento em outra direção. Para melhorar isto, na linha 100, aqui está
um trecho para "mesclar" a posição atual do cliente com a posição fornecida
pelo servidor, sendo que esta última tem maior peso na equação. É possível
levar isso um passo adiante guardando a posição real do servidor em uma
variável e fazer uma interpolação linear (Lerp) (ver Vector3.Lerp) para esta
posição no loop de atualização em vez de apenas pular diretamente para
esta posição a cada chamada “OnSerializeNetworkView” (que é executado
muito menos do que o Update). O que isto faz é gradualmente misturar o
movimento criando uma sensação de continuidade ao invés de causar
movimentos interrompidos.
5. T UTORIAL 4: I NSTANCIANDO
NETWORK V IEW
ID S
MANUALMENTE
Uma última prática importante a dominar é instanciar manualmente os
objetos de rede, especificamente os NetworkView IDs. Para poder enviar os
primeiros bits de dados em um jogo você precisa de um NetworkView ID
funcionando, isto é, é preciso um ID válido. Um Network View ID recebe um
ID válido quando você :
1. usa Network.Instantiate (mas Hergaarden aconselha a não utilizá-lo)
2. salva-o em cena (por exemplo, se tiver um objeto do GameManager com
um NetworkView anexo)
3. instancia manualmente um Network View e atribui a ele uma identificação
(ID). Cada jogador precisa receber uma mensagem e definir o viewID
correto.
Usar alocação manual em vez de Network.Instantiate() dá ao programador
muito mais poder, além de forçá-lo a escrever uma classe de gerenciamento
de jogador clara e, por isso, Hergaarden recomenda muito esta prática.
O Tutorial 4 refere-se principalmente a um script de gerenciamento de jogo
ou GameManager (Tutorial_4_GameManager.js). A movimentação do jogador
baseia-se no Tutorial 2B. Para ver o código completo, por favor, acesse via
Asset Store da Unity.
( ... )
Código completo disponível somente na Asset store da Unity – Ultimate Networking
Solution
//////////////////////////////
// Manage players
@RPC
function AddPlayer (networkPlayer : NetworkPlayer,
pname : String
Debug.Log("AddPlayer "+networkPlayer+" name="+pname);
if (GetPlayer(networkPlayer) != null)
{
Debug.LogError("AddPlayer: Player already exists!");
return;
}
var pla : PlayerInfo4 = new PlayerInfo4();
pla.networkPlayer = networkPlayer;
pla.name = pname;
playerList.Add(pla);
) : void {
if (pla.IsLocal())
{
localPlayerInfo = pla;
}
}
@RPC
function RemovePlayer ( networkPlayer : NetworkPlayer ) : void {
Debug.Log("RemovePlayer "+networkPlayer);
var thePlayer : PlayerInfo4 = GetPlayer(networkPlayer);
Network.RemoveRPCs(networkPlayer);
if (Network.isServer)
{
Network.DestroyPlayerObjects(networkPlayer);
}
if (thePlayer.transform)
{
Destroy(thePlayer.transform.gameObject);
}
playerList.Remove(thePlayer);
}
function GetPlayer ( networkPlayer : NetworkPlayer
for( var pla : PlayerInfo4 in playerList )
{
if (pla.networkPlayer == networkPlayer)
{
return pla;
}
}
return null;
}
////////////////////////////
// STARTUP: Spawn own player
//Server
function OnServerInitialized () : void {
SpawnLocalPlayer();
) : PlayerInfo4 {
120
}
//On server:
function OnPlayerConnected ( player : NetworkPlayer
//Nothing, await the clients own initiative..
}
) : void {
//Client
function OnConnectedToServer () : IEnumerator {
SpawnLocalPlayer();
}
function SpawnLocalPlayer () : void {
//Spawn local player
Debug.Log("SpawnLocalPlayer ");
//Get random spawnpoint
var
spawnPoints
:
GameObject[]=
GameObject.FindGameObjectsWithTag("Spawnpoint");
var theGO : GameObject= spawnPoints[Random.Range(0, spawnPoints.Length)];
var pos : Vector3 = theGO.transform.position;
var rot : Quaternion = theGO.transform.rotation;
//Manually allocate NetworkViewID
var id1 : NetworkViewID = Network.AllocateViewID();
AddPlayer(Network.player, PlayerPrefs.GetString("playerName"));
SpawnOnNetwork(pos, rot, id1, true, Network.player);
networkView.RPC("AddPlayer",
RPCMode.OthersBuffered,
PlayerPrefs.GetString("playerName"));
networkView.RPC("SpawnOnNetwork", RPCMode.OthersBuffered,
false, Network.player);
}
Network.player,
pos,
rot,
id1,
@RPC
function SpawnOnNetwork ( pos : Vector3 ,
rot : Quaternion ,
id1 :
NetworkViewID , amOwner : boolean,
np : NetworkPlayer ) {
var newPlayer : Transform= Instantiate(playerPrefab, pos, rot) as Transform;
//Set transform
var pNode : PlayerInfo4 = GetPlayer(np);
pNode.transform = newPlayer;
//Set networkviewID everywhere!
SetNetworkViewIDs(newPlayer.gameObject, id1);
if (pNode.IsLocal())
{
localPlayerInfo = pNode;
}
//Maybe call some specific action on the instantiated object?
//var tmp : PLAYERSCRIPT = newPlayer.GetComponent(PLAYERSCRIPT);
//tmp.SetPlayer(pNode.networkPlayer);
}
//When a NetworkView instantiates it has viewID=0 and is unusable.
//We need to assign the right viewID -on all players(!)- for it to work
function SetNetworkViewIDs ( go : GameObject ,
id1 : NetworkViewID ) : void {
var nViews : Component[]= go.GetComponentsInChildren(NetworkView);
(nViews[0] as NetworkView ).viewID = id1;
}
//On server: When client disconnects, cleanup
function OnPlayerDisconnected ( player : NetworkPlayer ) : void {
var pNode : PlayerInfo4 = GetPlayer(player);
if(pNode!=null){
var playerNameLeft = pNode.name;
//I.e.: Chat.SP.addGameChatMessage(playerNameLeft+" left the game");
}
networkView.RPC("RemovePlayer", RPCMode.All, player);
}
//Server OR client: Disconnect
function OnDisconnectedFromServer(info : NetworkDisconnection) : IEnumerator {
//Remove all players
yield 0;//Wait for actual disconnect
for(var i : int=playerList.Count-1;i>=0;i--)
{
var pla : PlayerInfo4 = playerList[i];
////if (pla.networkPlayer != Network.player && (pla.networkPlayer + "")
!= "0") //except yourself
//// {
RemovePlayer(pla.networkPlayer);
//// }
}
//Other stuff?
if (Network.isServer)
{
//We shut down our own server
}
else
{
if (info == NetworkDisconnection.LostConnection)
{
//Debug.LogWarning("Client Lost connection to the server");
}
else
{
//Debug.LogWarning("Client
Successfully
disconnected
from
server");
}
}
the
}
O GameManager mantém uma lista de todos os jogadores e suas
transformações. Quando um servidor é iniciado e os clientes conectam-se,
são gerados jogadores para cada um deles. As funções “AddPlayer” e
“SpawnOnNetwork” são usadas para este fim. Elas são chamadas no player
local imediatamente. O “RPCMode.OthersBuffered” é usado para enviar a
mensagem para todos os outros jogadores. A listagem de propriedades
guardada no buffer garante que quaisquer futuros clientes recebam as
mensagens automaticamente.
Em vez de usar “OthersBuffered” também poderíamos simplesmente usar
“RPCMode.Others”
para
enviar
as
mensagens
do
“AddPlayer”
e
“SpawnOnNetwork” somente uma vez, sem colocá-las no buffer. Quando um
novo cliente se conecta, o servidor deve, então, enviar todos os dados do
jogador manualmente.
122
6. A
CLASSE
M ULTIPLAYER F UNCTIONS
Hergaarden criou uma classe reutilizável que envolve uma série de funções
de rede para simplificar algumas tarefas comuns na criação de games
Multijogador no Unity.
Características principais:
● Gerencia a conexão de rede
● Servidor principal: configuração automática e funções fáceis de usar. (É
possível, opcionalmente, especificar um servidor mestre personalizado)
● Funções de conexão e de inicialização de servidor
● Permite novas tentativas de conexão em caso de falhas (caindo na porta
padrão do servidor sem NAT)
● Reconectar ao último host (por exemplo, se você precisar desconectar
temporariamente)
Como utilizar:
1) Adicione o script MultiplayerFunctions.cs a todas as suas cenas.
Anexar o script a um GameObject. Verifique se o script está
disponível em todas as cenas em que você deseja utilizá-lo. Você
pode adicioná-lo ao seu preloader e habilitar "DontDestroyOnLoad
(this);" na função Awake para garantir que esteja disponível em todas
as cenas de seu projeto.
2) Customize as três configurações do MultiplayerFunctions.cs:

masterserverGameName: usado pelo MasterServer ("NomeDoJogo")

defaultServerPort: a porta padrão do servidor (20000)

connectTimeoutValue: valor de tempo limite de conexão (timeout)
(10 segundos)
3) Implemente as funções que precisar
Veja o topo do arquivo fonte para ter uma visão geral de todas as
funções disponíveis.
Veja os exemplos mais adiante para vários usos deste script.
Esta classe pode ser encontrada em “Plugins/MultiplayerFunctions.cs”. Uma
vez que for colocada na pasta de plugins é possível utilizá-la tanto em
JavaScript como em C#. Essa classe será usada em todos os exemplos a
seguir. Hergaarden nos encoraja a utilizá-la em nossoss próprios projetos
e também alterá-la para nossas próprias necessidades. Usar um wrapper em
vez das funções do Unity dá ao desenvolvedor maior poder e permite
futuras customizações.
Além da classe funções multijogador, Hergaarden adicionou a classe
“GameSettings.cs”.
O
objetivo
desta
classe
é
salvar
facilmente
as
configurações de vários jogadores (ou jogos) no menu principal e ser capaz
de lê-las no jogo. Trata-se de uma classe estática para que você não precise
adicioná-la a uma cena/GameObject. O exemplo 2 mostra o uso dessa
classe. Em vez de “GameSettings.cs” você também pode usar seu próprio
objeto persistente ou “PlayerPrefs” para salvar os dados entre as cenas.
Para ter acessso à classe, favor comprar acesso ao código via Asset Store da
Unity.
EXEMPLOS DE SCRIPTS DE HERGAARDEN PARA SISTEMAS MULTIJOGADOR
1. E XEMPLO
DE CHAT
A cena "Example1_Chat" nada mais é que o script de conexão visto no
Tutorial 1 combinado com um script novo de chat. Adicionar um chat para
jogos é fácil se você reutilizar este script aqui fornecido. Quase nenhuma
modificação é necessária, apenas certifique-se de ligar os nomes dos
jogadores. No exemplo, o chat mostra até 4 linhas de texto. Quando você
modificar o código para mostrar mais linhas, poderá usar “yield” ou uma corotina para apagar ou fazer "fade out" das mensagens antigas. O servidor
guarda uma lista de jogadores. Em um jogo real, você provavelmente vai
querer essa lista em um script mais central/geral já que só precisará de uma
lista de jogadores e escondê-la no script de chat não é o melhor lugar.
Vejamos o código chat.js:
/*
(http://www.M2H.nl)
*/
#pragma strict
public var usingChat : boolean = false;
stop player movement since we're chatting
//Can be used to determine if we need to
124
var skin : GUISkin;
var showChat : boolean= false;
public static var SP : Chat;
//Skin
//Show/Hide the chat
(...}
Código completo disponível somente na Asset store da Unity – Ultimate
Networking Solution
Este código é exatamente o que foi utilizado no chat do game multijogador
“CrashDrive 3D” (figura 50). O código pode ser perfeitamente adaptado para
outros games ou metaversos criados em Unity.
Figura 50 - Tela do jogo multijogador em rede “CrashDrive 3D”. Depois de feita a conexão com um
servidor o chat aparece no canto inferior esquerdo.
2. E XEMPLO
DE
M ASTER
SERVER
– S ERVIDOR
MESTRE
Figura 51 - Um servidor mestre consiste em uma interface que mostra uma lista com grupos de clientes
que estão conectados a um mesmo servidor. Os servidores são, na verdade, as salas de jogos
disponíveis. Casa “sala” mostra a quantidade de jogadores alocados em cada uma e quantas pessoas no
total podem participar de cada uma delas.
A cena “Example2_menu" mostra como você pode usar um servidor mestre
para ver os grupos de jogadores que vão participar de um jogo em torno de
um servidor específico. No servidor mestre é possível ver os grupos que
estão se formando para que um jogo multiplayer possa acontecer. Ao clicar
“connect” em uma das opções listadas o jogador é levado para o “lobby”,
que seria uma sala de espera, onde já pode conversar com os outros
jogadores que farão parte daquela sessão de jogo específica antes de o jogo
começar. Uma vez que o jogo tenha iniciado, o item desaparece da lista do
servidor mestre e não é mais permitido entrar nele49. A interface do servidor
mestre (figura 51) mostrada no exemplo possui recursos de funcionalidade
flexível: Na caixa “join a game” o jogador pode ver uma lista de todos os
servidores ativos, e pode atualizá-la clicando o botão “refresh”. Outra opção
é escolher diretamente um IP e porta para conectar-se na caixa da direita. A
opção “quick play” pode ser utilizada pelo jogador que quiser participar da
primeira sessão de jogo que estiver disponível ("Join random game"). Esta
opção só é apresentada quando um ou mais hosts estão disponíveis. No
mais, na caixa “host a game” um jogador pode iniciar um grupo seu e
atribuir um nome a ele.
Vejamos o script “MultiplayerMenu2.js” da cena “Example2_menu”:
(...} Código completo somente via Asset store da Unity – Ultimate Networking Solution
import System.Collections.Generic;
//GUI vars
private var hostPlayers : int= 16;
private var hostSettingTitle : String= "No name";
private
private
var currentSubMenu : String= "";
var levelNrToLoad : int= -1;
function Awake () : void {
GameSettings.Clear();
}
for(var hData : HostData
in newData )
{
var cHost : MyHostData= new MyHostData();
cHost.realHostData = hData;
cHost.connectedPlayers = hData.connectedPlayers;
cHost.IP = hData.ip;
cHost.port = hData.port;
cHost.maxPlayers = hData.playerLimit;
49
Em outros jogos multijogador os servidores mestre continuam a mostrar as salas
mesmo quando estão cheias. No caso de algum jogador desconectar-se, a sala já
mostrará automaticamente que existe uma vaga para um novo jogador que queira
entrar.
126
}
(...}
Networking Solution
O script do game “gamescript.js” fornecido por Hergaarden neste exemplo
só mostra o status da conexão do servidor e dos clientes. É possível
substituir esta cena facilmente por alguma outra e fazer a rede funcionar da
mesma maneira. Veja o “gamescript.js”:
(...}
Código completo disponível somente na Asset store da Unity
Networking Solution
– Ultimate
/*
(http://www.M2H.nl)
*/
#pragma strict
function Awake(){
//RE-enable the network messages now we've loaded the right level
Network.isMessageQueueRunning = true;
Debug.Log("Server registered the game at the masterserver.");
MultiplayerFunctions.SP.RegisterHost(GameSettings.serverTitle,
GameSettings.description);
}
}
function OnGUI ()
{
if (Network.peerType == NetworkPeerType.Disconnected){
//We are currently disconnected: Not a client or host
GUILayout.Label("Connection status: We've (been) disconnected");
if(GUILayout.Button("Back to main menu")){
Application.LoadLevel(Application.loadedLevel-1);
}
}else{
//We've got a connection(s)!
if (Network.peerType == NetworkPeerType.Connecting){
GUILayout.Label("Connection status: Connecting");
} else if (Network.peerType == NetworkPeerType.Client){
GUILayout.Label("Connection status: Client!");
GUILayout.Label("Ping
to
server:
"+Network.GetAveragePing(
Network.connections[0] ) );
} else if (Network.peerType == NetworkPeerType.Server){
GUILayout.Label("Connection status: Server!");
GUILayout.Label("Connections: "+Network.connections.length);
if(Network.connections.length>=1){
GUILayout.Label("Ping
to
first
player:
"+Network.GetAveragePing( Network.connections[0] ) );
}
}
if (GUILayout.Button ("Disconnect"))
{
Network.Disconnect();
}
}
}
if (Network.isServer) {
Debug.Log("Local server connection disconnected");
}else {
if (info == NetworkDisconnection.LostConnection)
Debug.Log("Lost connection to the server");
else
Debug.Log("Successfully diconnected from the server");
}
}
//Server functions called by Unity
function OnPlayerConnected(player: NetworkPlayer) {
Debug.Log("Player connected from: " + player.ipAddress +":" + player.port);
}
Debug.Log("Player disconnected from: " + player.ipAddress+":" + player.port);
}
Somente será necessário definir "Network.isMessageQueueRunning = true;"
já que ela está desabilitada na cena do menu para impedir que coisas
estranhas aconteçam na cena principal quando um cliente se conecta a um
jogo que está em andamento. Também é importante lembrar de registrar o
jogo no servidor mestre, uma vez que o servidor tenha iniciado a cena do
jogo. Por último, é necessário personalizar a interface do servidor mestre e
do lobby, pois o exemplo apresentado é muito básico.
Abaixo mostramos outro exemplo de servidor master utilizando o código de
servidor master de Hergaarden. No jogo “Surrounded by death”, assim que
escolhemos a opção multijogador vemos um menu (figura 52) que mostra
algumas opções do servidor master, a saber, criar um servidor, selecionar
um servidor que já está em fase de lobby ou usar a opção “quick play” que
insere o jogador no lobby do primeiro jogo que tiver espaço disponível para
um jogador.
Figura 52 - Menu do servidor master do game “Surrounded by death”.
128
Na figura 53 abaixo vemos a interface gráfica principal (GUI) do servidor
master do jogo “Surrounded by Death”. Neste exemplo vemos que existe um
grupo em fase de lobby formado já por dois jogadores e com a
possibilidade de até quatro jogadores simultâneos.
Figura 53 - Aspecto do GUI do servidor master do jogo “Surrounded by Death”, mostrando um servidor já
com 2 jogadores à espera.
3. E XEMPLO
DE
L OBBY S YSTEM
Como o próprio nome diz, um “lobby” é uma sala de espera. Ao clicar
“connect” em uma das opções de servidor listadas no servidor master o
jogador é levado para o “lobby” onde já é possível conversar com os outros
jogadores que farão parte daquela sessão de jogo específica via chat antes
de o jogo começar. Uma vez que o “dono” daquele servidor clica no botão
para dar inicio ao jogo, o nome deste lobby desaparece da lista do servidor
mestre. Não é mais permitido entrar nele porque o jogo já começou.
Abaixo vemos o lobby do ponto de vista do jogador que é o “dono” daquele
servidor/sala de jogo, ou seja, aquele que o criou (figura 54). O dono pode
esperar o quanto quiser para começar o jogo. Ele define o número máximo
de participantes quando faz a criação do servidor.
Figura 54 - O lobby do ponto de vista do criador do servidor. O jogador que cria a sala determina qual é
o número máximo de participantes e tem a autoridade para começar o jogo quando desejar.
Figura 55 - O lobby do ponto de vista de um dos jogadores que aguarda o início do jogo.
O “Example3_lobby" é muito parecido com o exemplo anterior, exceto que
mostra o “lobby” do jogo com a opção de inserir senhas para os jogadores.
Os jogos somente são mostrados na lista do servidor mestre quando ainda
130
estão em fase de “lobby”. Jogos que já começaram são removidos desta lista
imediatamente.
É possível facilmente utilizar este código para outros jogos em rede
copiando a cena do lobby e ajustando-a às suas necessidades. É importante
não esquecer de habilitar a fila de mensagens em sua cena de jogo.
4. E XEMPLO
DE J OGO
FPS ( SERVIDOR
NÃO AUTORIZADOR )
O exemplo de jogo FPS que Hergaarden oferece em seu trabalho é de
servidor não autorizador. Se desejarmos um FPS com servidor autorizador é
necessário reescrever o código para uma configuração segura autorizadora.
O exemplo é muito simples e não mostra qualquer alvo ou outro jogador
para ser acertado. Trata-se apenas de um exemplo do espaço de jogo, da
navegação em primeira pessoa e de como coletar objetos.
Este exemplo usa o script do Exemplo 2 de menu principal de servidor
master para configurar uma conexão no menu principal. Os recursos deste
jogo multijogador incluem: um chat, scoreboard, movimento, tiros, objetos
para recolher. Se desejar usar este exemplo como base para um jogo FPS,
adições possíveis poderiam ser:
● Movimento autorizado por servidor: para evitar trapaças
● Personagens animados: sincronizar as animações ou fazer os clientes
"calcularem" a animação correta a tocar.
● Troca de armas
● Outras questões não necessariamente relacionadas ao fator multijogador:
Crosshairs, melhorar a interface gráfica, o modo de espectador, rodadas de
jogo e limites das rodadas etc.
Networking Solution.
5. E XEMPLO
DE JOGO MULTIJOGADOR SEM INTERFACE INICIAL
O exemplo 5 apresenta um jogo multijogador sem uma tela inicial para a
escolha ou configuração de servidores. Não mostra configurações de master
server, nem salas ou lobbies. Surgiu a partir de uma constatação importante
que Hergaarden e seus companheiros da M2H fizeram com o jogo
“CrashDrive”. Perceberam que a maioria dos jogadores simplesmente não
entendiam a interface inicial com as configurações de IP e escolha de
servidor (retratada na figura 27) e saíam sem jogar. Na segunda versão do
“CrashDrive”, decidiram tirar a tela inicial de escolha de servidor e
desenvolveram um meio de fazer o jogador começar a jogar imediatamente
e de o sistema inserí-lo automaticamente em um servidor com outros
jogadores. Desta forma os jogadores não têm qualquer aborrecimento de
configuração e não são impedidos de jogar se não entenderem a interface
inicial.
Figura 56 - Jogo multijogador sem tela inicial de configuração e alocação de servidor.
O Exemplo 5 apresenta a mesma modificação que foi feita no jogo
“CrashDrive”. Existe apenas uma cena, a cena do jogo. Basta começar a jogar
e deslocar-se pelo espaço (figura 56). Na figura acima, do lado esquerdo
está um primeiro usuário que entrou no jogo. Imediatamente foi criado um
servidor para ele. Um segundo jogador também entrou no jogo e foi
automaticamente assinalado como cliente e inserido na sala/servidor em
que o primeiro jogador estava. Tudo isso acontece de modo não aparente
132
para o jogador. O código de rede checa todos os servidores disponíveis do
servidor mestre para poder colocar este jogador em um deles. Se nenhum
servidor estiver disponível o jogo vai criar um servidor novo, tornando
possível que outros jogadores juntem-se a ele. Se nenhum jogador juntarse dentro de “X” segundos, o jogo tentará novamente conectar-se a todos
os servidores disponíveis novamente e o ciclo se repete enquanto o jogador
estiver jogando sozinho para que mais jogadores possam juntar-se a ele.
Essa configuração vai exigir um planejamento extra para todos os eventos
de seus jogos multijogador que depende dos estados “desconectado”,
“cliente” ou “servidor”. Qualquer um desses três estados são possíveis a
qualquer tempo. Isso significa que o código terá que verificar se você é um
cliente ou servidor para enviar uma mensagem de rede ou para executar
uma mensagem local, quando você for desconectado.
Vejamos o código do GameManager.js:
Código completo disponível somente na Asset store da Unity – Ultimate Networking
Solution
//import UnityEngine;
//import System.Collections;
class PlayerInfo5
{
public var networkPlayer : NetworkPlayer;
public var name : String;
public var transform : Transform;
public var isLocal : boolean;
public function Clone () : PlayerInfo5 {
var pla : PlayerInfo5= new PlayerInfo5();
pla.networkPlayer = networkPlayer;
pla.name = name;
pla.transform = transform;
pla.isLocal = isLocal;
return pla;
}
}
}
O PHOTON E AS TÉCNICAS DA EXIT GAMES PARA MONTAR UMA REDE
MULTIJOGADOR COM
UNITY 3D
Além do trabalho interessante de Hergaarden discutido acima, o site da Exit
Games (figura 57) fornece um rico material para quem deseja montar um
metaverso ou um jogo multijogador. O Photon é um motor de rede
multijogador criado pela Exit Games, empresa alemã que fornece serviços
de hospedagem para MMOs (Massive Multiplayer Online Games) e FPSs (First
Person Shooters).
Figura 57 - Site da Exit Games com o seu carro chefe, o Photon.
O Photon é um Framework de desenvolvimento de “Socket-Server” em
tempo real escrito em C# sobre um aplicativo em Windows. A API cliente
está disponível para múltiplas plataformas, entre elas DotNet, Unity3D,
C/C++ e ObjC. A Exit Games declara orgulhosamente que o Photon é o
motor de rede mais rápido e fácil de usar e que estabelece uma base
escalável para MMOGs, FPSs e outros games multijogador, tanto para PC
como para Mac, para funcionamento em browsers, em dispositivos móveis,
consoles e cross-plataformas.
Escolhemos o Photon, pois ele foi desenvolvido já com vistas a uma
integração suave com o Unity3D, motor de games escolhido para o nosso
trabalho. Como dissemos, o Photon trabalha tanto com o Unity3D como
com outras plataformas e para iOS e Android. Em nosso trabalho vamos nos
134
limitar apenas à questão dos serviços do Photon ligados ao Unity3D para
uso em browsers na plataforma Windows.
Enquanto o trabalho de Hergaarden é destinado a iniciantes, o material da
Exit Games para ser entendido necessita de certa experiência no trabalho
com redes para jogos multijogador. Entretanto, a Exit Games tem procurado
fazer com que sua documentação seja cada vez mais completa e didática de
modo a atender a crescente demanda por hospedagem de MMOs e FPSs por
pessoas que nem sempre são desenvolvedores profissionais.
E STUTURA
DE ALTO NÍVEL DO
P HOTON S OCKET -S ERVER
O Photon versão 3 é fornecido basicamente em dois SDKs50 básicos: o do
servidor e do cliente, sendo que o servidor pode gerenciar clientes ligados a
diferentes tipos de plataforma. Para cada plataforma específica existe um
SDK diferente. Neste trabalho, veremos somente com SDK cliente para
Unity3D.
O gráfico a seguir mostra a arquitetura de alto nível do Photon como
mostrada no site da Exit Games (2011):
50
SDKs ou Software Development Kits são pacotes de programas que ajudam um
programador
a
desenvolver
aplicativos
para
uma
plataforma
específica.
Tipicamente, um SDK inclui um ou mais APIs, ferramentas de programação e
documentação.
Figura 58 - Arquitetura de alto nível do Photon.
O Gráfico mostra algumas das características principais do Photon. Entre
elas estão:

Núcleo nativo em Windows.

Lógica de jogo do servidor desenvolvida em C#.

Framework bastante completo resolve a maioria das tarefas de rede
comuns para o desenvolvedor.

Mapeamento simples e flexível de chamadas RPC para instâncias de
operação.

O Photon Lite é fornecido como lógica de jogo baseada em salas
simples para fácil prototipagem.

Implantação simples, incluindo em computação em nuvem.

Projetado para saturar a largura de banda antes que a CPU torne-se o
gargalo

Protocolo binário enxuto faz UDP ordenada e confiável-sobdemanda.

Plataformas
de
clientes
comuns
são
suportadas
diretamente,
proporcionando fluxos de trabalho semelhantes.

O Photon empacota a camada de rede de cada plataforma de cliente.
136
S ISTEMA
DE LICENÇA DO
P HOTON
Um detalhe interessante que faz do Photon uma boa opção para projetos em
teste é a sua forma de licenciamento: ele é gratuito para até 100 usuários
simultâneos. A partir daí as tarifas são crescentes conforme o número total
de usuários simultâneos. Isto permite que pessoas possam desenvolver
sistemas de testes com o Photon sem nenhuma restrição a qualquer uma de
suas funcionalidades e sem custos.
De qualquer maneira, mesmo que gratuitas, licenças são necessárias para
fazer o Servidor Photon funcionar em um computador local. O sistema
sempre contata o “License Monitor” via HTTPs para checar se a cópia local
do servidor Photon é licenciada antes de iniciar, portanto não é possível
fazer um jogo que utilize o Photon como servidor sem que o computador
esteja conectado à internet. Ele não funcionará.
F UNCIONAMENTO
BÁSICO DO
P HOTON
O fluxo de trabalho Cliente/Servidor do Photon.
Aplicações
Uma aplicação é a lógica de um jogo que fica no lado do servidor. Todas as
características de um jogo (por exemplo, RPCs, armazenamento de dados
etc.) são implementadas em uma aplicação do Photon. A fonte em C# é
compilada e esta compilação é carregada pelo núcleo principal do Photon. O
Núcleo do Photon usa arquivos de configuração para configurar aplicações e
definir parâmetros de inicialização.
Normalmente, toda a lógica de um jogo é feita em uma única aplicação.
Ainda assim, o Photon é capaz de executar várias aplicações ao mesmo
tempo. Cada aplicação pode ter uma tarefa diferente.
A lógica do jogo
A lógica do jogo define como um cliente pode interagir com o servidor. Ela
implementa as operações, eventos e tudo o que o servidor faz por si
mesmo.
Uma boa base para jogos que utilizem um sistema de salas é fornecida pela
aplicação "Photon Lite", encontrada na pasta src-server/Lite SDK. Ela não
sabe a lógica do seu jogo ainda, mas dispõe de um sistema de salas em que
os jogadores podem se comunicar facilmente. O aplicativo "Photon
LiteLobby" estende o “Photon Lite” com listas de salas, caso você deseje que
os usuários selecionem manualmente uma sala.
Se o seu jogo vai ser um mundo único e enorme, a Aplicação de
Demonstração de MMO é uma boa base para começar. Esta aplicação lida
com o gerenciamento de interesses para seus clientes e fornece classes de
itens, propriedades, atores e muito mais.
Alternativamente,
qualquer
lógica
de
jogo
pode
ser
desenvolvida
diretamente no framework em C#. O ponto de entrada para isso é a classe
de aplicação, definida no Photon.Socketserver.dll.
Operações
Uma Operação no Photon é o equivalente a uma RPC (chamada de
procedimento remoto). Os clientes Photon usam chamadas de Operação
para qualquer coisa que queiram fazer.
As Operações e todos os seus parâmetros são definidos na aplicação do
lado do servidor. Os clientes podem chamar qualquer operação através do
estabelecimento do que chamamos “Hashtable” com chaves e valores de
acordo com as convenções da operação. Os frameworks do cliente e do
servidor cuidam da serialização, transferência e desserialização.
Cada Operação também pode fornecer um resultado. Esta é uma forma de
oferecer ao cliente os dados solicitados. Claro, o resultado pode ser
ignorado o que economiza largura de banda.
Chamadas de Operação e resultados são exclusivos entre o servidor e cada
cliente. Os outros clientes não têm acesso a estas Operações e resultados.
Eventos
Os eventos do Photon são mensagens para os clientes. Cada evento é
tipificado por um código de bytes e carrega atualizações do jogo. A
aplicação Lite define vários eventos, mas é possível definir eventos
customizados puramente no lado do cliente.
138
Ao contrário dos resultados das Operações, um evento recebido é
provavelmente causado pela chamada de Operação de outro cliente. Isto
significa: eventos podem chegar a qualquer momento. O Photon Lite envia
os eventos quando alguém entra ou sai de uma sala.
A Operação “RaiseEvent” (no Lite) é o que faz os eventos verdadeiramente
universais: qualquer cliente pode criar novos eventos criando uma
“Hashtable” com os dados e aplicar um código ao enviá-lo. Dados do jogo
podem ser enviados sem qualquer necessidade de alterar o servidor.
Claro que, para reações mais elaboradas do lado do servidor para com
eventos, podem ser definidas Operações customizadas que checam os
dados dos eventos, compilam-nos ou criam outros eventos.
Conexões e Tempo limite
Ao contrário do protocolo UDP simples, o protocolo UDP confiável do Photon
estabelece uma conexão entre o servidor e os clientes: os comandos dentro
de um pacote de UDP têm números de sequência e uma “flag”, que indicam
se são confiáveis. Se assim for, quem quer que esteja recebendo os dados
tem que confirmar (acknowledge) o comando. Comandos confiáveis são
repetidos em intervalos curtos até que uma confirmação chegue. Se não
chegar, a ligação é encerrada por meio de um “time out”.
Ambos os lados monitoram esta conexão independentemente de sua
perspectiva. Ambos os lados têm as suas regras para decidir se o outro
ainda está disponível.
Se um “time out” é detectado, uma desconexão acontece daquele lado da
conexão. Como achamos que o outro lado não responde mais, nenhuma
mensagem é enviada a ele. É por isso que as desconexões de tempo limite
são unilaterais e não síncronas.
I NSTALAÇÃO
DO
P HOTON
O Photon é muito fácil de instalar e de inicializar. Primeiro, crie uma conta
no site da Exit Games e depois faça o download do SDK do servidor do
Photon v3 disponível no seguinte endereço:
http://www.exitgames.com/Download/Photon
Figura 59 - Conjunto de arquivos do Photon 3 - SDKs de servidor e de clientes e licenças de uso
A versão 2 do Photon ainda está disponível, mas vamos agora trabalhar com
a versão 3. Uma vez na tela com os links para os arquivos do Photon 3
(figura 59), faça o download do arquivo compactado do SDK do Servidor:
“ExitGames-Photon-Server_SDK_v3-0-15-2544-RC7.zip”.
Depois
de
baixado o arquivo compactado é necessário descompactá-lo em um
diretório de desenvolvimento, à sua escolha (figura 60).
Figura 60 - É necessário definir o diretório onde o Photon deverá ficar em seu computador.
Uma vez que isto tenha sido feito, entre na pasta “deploy” (figura 61) e
escolha a versão adequada à sua plataforma:
bin_Win32: para Windows Vista 32 bits ou superior
bin_x64: para Windows Vista 64 bits ou superior
140
bin_Win32_xp: 32 bit Windows XP ou 2003 de 32 bits
bin_Win64_xp: 64 bit Windows XP ou 2003 de 64 bits
Figura 61 - O conteúdo do pasta "deploy".
Dentro da pasta da sua plataforma clique em PhotonControl.exe (figura 61).
Isto criará um ícone do Photon na barra de acesso do Windows e um menu
para gerenciar o Photon no canto inferior direito da tela do Windows.
Figura 62 - O arquivo Photon Control.exe instala o Photon.
Figura 63 - O menu de controle do Photon 3.0.
No menu de controle do Photon (figura 68), selecionar “Photon Instance1” e
“Start as application”. Isto inicializará o Photon. Pode demorar alguns
minutos até que tenha inicializado por completo e esteja pronto para uso.
Como inicializar o Testclient
O SDK de servidor possui um testclient que simula múltiplos clientes e cria
alguma carga de uso para teste. Para iniciá-lo basta acessar “Photon
instance1/Run Testclient” pelo Menu de controle do Photon.
O Testclient é uma aplicação que simula 100 jogadores dentro de 25 jogos,
com 4 jogadores cada um (figura 64).
Figura 64 - O Testclient em funcionamento, simulando 100 jogadores em 25 jogos.
É possível checar os “logs” do Photon a qualquer momento pelo menu de
gerenciamento escolhendo a opção “Open logs” para ver se o serviço está
funcionando corretamente.
142
Figura 65 - Os logs do Photon.
EXEMPLOS DE FUNCIONAMENTO DO PHOTON COM UNITY3D
Assim como no trabalho de Hergaarden, a documentação disponível no site
da Exit Games51 também procura mostrar o conteúdo de maneira didática.
Nas primeiras vezes que visitamos o site da Exit Games logo que
começamos nosso trabalho de pesquisa, a qualidade da documentação
deixava muito a desejar. Era realmente impossível para não iniciados
entenderem o material disponibilizado a ponto de quase desistirmos de
estudar a solução Photon. O material não apresentava exemplos e era muito
complexo.
Vimos
que
a
documentação
vem
melhorando
muito
consideravelmente ao longo dos últimos meses, o que mostra o esforço da
Exit Games em melhorar a qualidade do produto e do serviço aos
desenvolvedores. Neste período, a Exit Games incluiu alguns exemplos de
utilização bastante úteis que ajudam no entendimento do funcionamento do
Photon e na sua aplicação em projetos de MMOs e FPSs.
Entre os exemplos bastante úteis encontrados no site da Exit Games, vamos
discutir três. O primeiro é o “Photon Viking Demo”, que é um MMO baseado
no Photon Cloud, isto é, utiliza o servidor Photon em nuvem da Exit Games.
O segundo é o “Photon BootCamp FPS Demo” que é a recriação do jogo FPS
demo do Unity 3.3 transformado em versão multijogador utilizando o
51
Documentação de desenvolvimento do Photon no site da Exit Games disponível
na URL: http://doc.exitgames.com/
servidor Photon (não em nuvem). O terceiro exemplo é a recriação do demo
da ilha do Unity 2.5, também transformado em multijogador. Vejamos cada
um deles.
1 P HOTON V IKING D EMO – U M MMO
EM TERCEIRA PESSOA COM
P HOTON
Figura 66 - Página de download do Photon Viking Demo.
O Photon Viking Demo52 é uma modificação de um projeto feito pela Unity,
para mostrar o controlador de terceira pessoa para MMOs, mas agora
adicionando a funcionalidade multijogador por meio da utilização do serviço
Photon Cloud. Primeiro é preciso fazer o download do projeto na Asset Store
do Unity e também é necessário criar uma conta na Photon Cloud via site da
Exit Games. Com isso é possível obter um APP ID da Photon Cloud que será
utilizado no “build” do Unity para conexão com o servidor na nuvem (figura
67). Uma vez que isto tenha sido feito, o “build” já será compilado com os
códigos para acesso direto à nuvem do projeto específico criado.
52
Download do Photon Viking Demo pode ser feito pela URL:
http://u3d.as/content/exit-games/photon-viking-demo/2gg
144
Figura 67 - Janela de conexão com o Photon Cloud por meio de uma APP ID.
Utilizando a nuvem, obviamente não é necessário criar um servidor (já está
criado), mas sim garantir que o seu jogo esteja de acordo com os
parâmetros estabelecidos pelo Photon para funcionar com o servidor.
O
exemplo
Photon
Viking
Demo vem com um terreno que
simula
inverno
uma
paisagem
com
pinheiros
de
e
colinas cobertas de neve e uma
personagem
viking
padrão
de
carregando
um
um
machado. Começa com uma
interface
para
definição
do
nome do jogador e criação de
uma sala ou para escolha de
Figura 68 - Interface inicial do Photon Viking Demo
uma sala já em funcionamento
(figura 68). Na figura temos
uma sala em funcionamento chamada “myRoom” já com 3 jogadores com
espaço para um total de 10.
Figura 69 - Experimento com o Photon Viking Demo
Abrindo janelas diferentes para o mesmo build do Unity conectamos 4
jogadores simultâneos com sucesso a partir de um mesmo computador,
como é possível ver na figura 69.
O serviço Photon Cloud passou a ser pago a partir de 1º de fevereiro de
2012 e conta com taxas iniciando em US$9,00 mensais para a faixa de até
100 jogadores simultâneos, e o preço sobe conforme maior número de
jogadores.
146
2. O B OOTCAMP FPS D EMO – E XEMPLO
DE
FPS
COM
P HOTON
Figura 70 - Página de download do Photon Bootcamp FPS Demo
O Photon Bootcamp FPS Demo53 é a recriação do jogo FPS demo do Unity
3.3
(criado
pela
empresa
brasileira
Aquiris
de
Porto
Alegre-RS)
transformado em versão multijogador utilizando o servidor Photon 2.6 (não
confundir com o Photon Cloud). O exemplo não funciona com o Photon 3.0,
como pudemos constatar.
Trata-se apenas da primeira fase do FPS original da Aquiris, mas a
funcionalidade multijogador está excelente, constituindo um verdadeiro
exemplo de FPS. O exemplo já vem com uma licença para até 20 jogadores
simultâneos, mas esta pode ser estendida para até 100 jogadores com a
licença gratuita que pode ser obtida no site da Exit Games.
Antes de começar o jogo é necessário iniciar o Servidor Photon 2.6 e
garantir que seus serviços estejam rodando, procedimento retratado nas
figuras 62 a 66 a respeito o Photon 3, mas que é bastante semelhante no
Photon 2.6. A estrutura de pastas do Photon 2.6 é exatamente igual à do
3.0 e deve-se escolher a pasta “deploy” e a pasta conforme tipo de sistema
operacional em que o servidor vai funcionar e selecionar o aplicativo
“PhotonControl”. Quando abrir o menu de controle os nomes dos itens serão
53
Download pode ser feito pela URL: http://u3d.as/content/exit-games/photon-
bootcamp-demo/1AA
ligeiramente diferentes dos da versão 3.0. Para iniciar os serviços basta
clicar em Photon / Start as application (figura 71).
Figura 71 - O menu do Photon 2.6 é ligeiramente diferente do da versão 3.0
Depois de clicar em “start as application” é importante garantir que o serviço
esteja funcionando verificando os “logs”. Clique sobre o item “open logs” e
garanta que a última linha dos logs esteja como “service is running”. Se não
estiver com esta mensagem o servidor não funcionará. A principal razão
pode ser que a máquina não esteja conectada à internet e o sistema não
pode fazer a verificação da licença no “License Monitor” via HTTPs da Exit
Games.
Uma vez iniciado o serviço do socket-server já é possível fazer os “builds”
do BootCamp funcionarem em modo multijogador via browser. Assim como
no exemplo dos Vikings, o jogo começa com uma interface para escolha de
nome do jogador e, em seguida, criação de sala ou escolha de sala já
existente (figura 72).
Figura 72 - Interface de escolha de nome e de entrada de sala no Photon Bootcamp Demo
Fizemos um teste e conseguimos conectar até 3 usuários simultâneos em
um mesmo computador utilizando três navegadores diferentes: IE, Firefox
e Safari (figura 73). É possível usar o avatar para correr, pular e agachar-se
explorando todo o espaço do jogo. O sistema de tiros é bem feito e, uma
148
vez que um dos jogadores é morto, ele reaparece em algum local aleatório
do terreno para que o jogo continue.
Figura 73 - Teste com o Photon Bootcamp Demo com três jogadores
3. MMO I SLAND D EMO
DO
U NITY 3D
COM
P HOTON
Figura 74 - Teste da ilha básica do Unity com Photon
A MMO Island Demo é uma demonstração do potencial de um cliente
utilizando o MMO application do Photon como servidor. É um pouco mais
difícil de fazer funcionar do que as Demos anteriores, principalmente
porque a ilha básica foi criada para Unity 2.5 e apresenta algumas
incompatibilidades com o Unity 3.4 que precisam ser corrigidas para que a
Demo possa funcionar.
Antes de mais nada é necessário fazer o download da Island Demo a partir
do site da Unity 3D por meio da URL:
http://unity3d.com/support/resources/example-projects/islanddemo.
Diferentemente dos Demos anteriores, os arquivos para a conversão da
Island Demo em um game multijogador estão disponíveis dentro do Server
SDK na pasta: \src-server\Mmo\Photon.MmoDemo.Client.UnityIsland e
precisam ser mesclados com os arquivos originais da Island demo baixados
do site da Unity. Para isto basta colar o conteúdo do arquivo “island.zip”
baixado do site da Unity dentro da pasta “islanddemo” do SDK. Um detalhe
importante: ao copiar o conteúdo do “island.zip” na pasta, garanta que
nenhum arquivo seja substituído caso o sistema reconheça arquivos de
nomes iguais. O arquivo readme.txt dentro da pasta pode ajudar em caso de
problemas.
Abra a cena Islands.unity dentro da pasta Assets. O Unity vai atualizar a
cena se necessário (figura 75), mas podem ocorrer alguns erros. Se o
processo travar, tente novamente. O Unity normalmente recupera-se caso
aconteça algum problema inicial.
Figura 75 - Mensagens de atualização da Island Demo para a versão do Unity 3.4
Quando o Editor estiver aberto, o compilador certamente acusará alguns
erros (figura 76):
150
Figura 76 - Mensagens de erro do compilador do Unity 3.4 para o Island Demo
Você deve abrir o “Console view”. Dê um duplo click para abrir o código
fonte e simplesmente comente as linhas que apresentarem erro.
As linhas que apresentaram erros em nosso teste foram as seguintes:
1) No arquivo: Assets/Scripts/UnderwaterEffects.js
Linha 23:
if(water) waterLevel = water.gameObject:
Modificação:
// if(water) waterLevel = water.gameObject:
2) No arquivo: Assets/Editor/UpdateTreeColors.js
Linha 13:
UnityEditor.TerrainLightmapper.UpdateTreeLightmapColor(tex,
Terrain.activeTerrain.terrainData);
Modificação:
// UnityEditor.TerrainLightmapper.UpdateTreeLightmapColor(tex,
Linha 31:
UnityEditor.TerrainLightmapper.UpdateTreeColor(tex,
Modificação:
// UnityEditor.TerrainLightmapper.UpdateTreeColor(tex,
Depois que isto for feito, será possível iniciar a cena na janela Game do
Unity e andar pelo terreno da ilha. É importante, então fazer o “build and
run” da cena para que possamos utilizá-la em navegadores. Somente dois
elementos ficarão com problemas, a saber, o atualizador de lightmaps das
árvores do script UpdateTreeColors.js e o elemento de efeito de “blur”
quando estamos em baixo d’água, do script UnderwaterEffects.js.54
Feito o build, antes de abrir qualquer cliente via navegador, primeiro é
necessário garantir que o servidor Photon 3.0 esteja funcionando.
Depois basta abrir diversas janelas em seu navegador e colocar o endereço
onde está o “build” criado da ilha demo. Abrimos três janelas e conseguimos
três jogadores simultâneos, como é possível ver na figura abaixo.
Figura 77 - Teste da ilha básica do Unity com Photon e três jogadores simultâneos
Quando estávamos para entregar esta dissertação, o site da Unity adicionou
um material excelente criado pela equipe da Kingsmound, empresa
54
Quanto ao script UnderwaterEffects.js, mesmo na versão do Demo original
disponibilizado pela Unity não tínhamos o efeito de “blur” e, quando se saia da água
os objetos inseridos no ambiente pelo usuário no desenvolvimento apresentavam
“halo glow”. Durante a pesquisa preliminar para o projeto da Ilha Cabu, o Prof. Luís
Carlos Petry descobriu que a solução para o problema poderia ser tratada através da
indicação da posição da câmera estando acima ou abaixo do nível da água, e,
consequentemente, as variáveis glow e blur serem verdadeiras ou falsas. Para
maiores detalhes sobre a solução do Prof. Petry, entrar em contato pelo e-mail
[email protected].
152
mexicana que fez a adaptação do Bootcamp da Aquiris para o Photon.
Trata-se da explicação dos detalhes da transposição do Botcamp para uso
com o Photon. O material é totalmente gratuito e os códigos com
explicações detalhadas estão disponíveis sem qualquer restrição. O Material
pode
ser
envontrado
na
seguinte
http://doc.exitgames.com/v3/bootcampmultiplayerdemo .
URL:
CAPÍTULO 3:
PROPOSTA DE CONTINUIDADE NA CRIAÇÃO
CONCEITUAL E MONTAGEM DO
METAVERSO PIRARUCU-
GENTE
Antes de passarmos a uma proposta de continuidade para o processo de
criação do Metaverso Pirarucu-Gente, gostaríamos de reunir algumas
experiências e técnicas a fim de fazer o levantamento conceitual e artístico
para a criação de games e metaversos. Entre elas, vamos analisar a
experiência do Game Acadêmico Ilha Cabu, como relatada na tese de
doutorado da Profa. Arlete Petry, e também algumas técnicas apresentadas
pela equipe da Aquiris Game Studio, empresa de Porto Alegre, durante o
Unite 10 em outubro de 2010 em Montreal sobre o “Bootcamp”, game de
exemplo criado para a versão 3.3 do Unity (e apresentado no capítulo
anterior em versão modificada pela Kingsmound para uso com Photon). Em
seguida vamos analisar mais de perto o método da pesquisa-ação utilizado
pelo Projeto Pirarucu-Gente para melhor entendermos o projeto e, por
conseguinte, adequarmos apropriadamente o metaverso aos seus objetivos.
Finalmente, começaremos a esboçar um primeiro “Game Design Document”
que deverá ser desenvolvido posteriormente com a equipe do projeto.
154
A EXPERIÊNCIA DO GAME ACADÊMICO ILHA CABU
Figura 78 - O Game Acadêmico Ilha Cabu
O Game acadêmico Ilha Cabu foi uma importante referência para o trabalho
do metaverso Pirarucu-Gente. Foi o primeiro grande estímulo para
começarmos a trabalhar com mundos virtuais e o nosso primeiro contato
com o Unity 3D como ferramenta para a criação de games e metaversos.
Faremos aqui um pequeno resumo das características que mais nos
chamaram a atenção no projeto Ilha Cabu a partir de dois relatos
importantes que contam o seu processo de concepção e criação, a saber, o
relato contido na tese de doutorado da Profa. Arlete Petry (2010) intitulada
“O jogo como condição da autoria e da produção de conhecimento: análise e
produção em linguagem hipermídia” e na dissertação de mestrado de
Cristiano Tonéis (2010) de tema “A lógica da descoberta nos jogos digitais”.
UTILIZAÇÃO DE UMA TAXONOMIA DOS PROCESSOS
DE PRODUÇÃO E DE
AVALIAÇÃO DE HIPERMÍDIAS
O trabalho de Arlete Petry faz a análise de diversas produções em
hipermídia utilizando como base a taxonomia proposta por Sérgio Bairon
para a análise destas produções. A taxonomia de Bairon 55 propõe uma
metodologia que serve tanto para processos de produção como de avaliação
do conhecimento científico em hipermídias. Segundo Arlete Petry, o trabalho
de Bairon:
“Propõe a adoção de uma taxonomia às estruturas digitais, que seja
passível de aplicação aos temas teórico-metodológicos ou técnicometodológicos
que
a
hipermídia
produz,
composta
por:
1.
argumento (o tema a ser trabalhado), 2. entorno (o ambiente no qual
o
tema
será
discutido/apresentado),
3.
formação
de
bancos
multimidiáticos (recolha ou criação de imagem, som e texto que
habitará
o
entorno),
4.
programação
e
unidades
de
análise
(sistematização das associações conceituais e estudo dos softwares
para a produção do que se pretende), 5. criação de reticularidades
conceituais (planejamento dos locus de presença da reticularidade) e
6. programação reticular dos jogos de linguagem (presença do
randomismo).” (PETRY, Arlete, 2010, p. 125)
Estas seis partes da taxonomia colocam-se como guias bastante úteis para
concepção e a produção de hipermídias, e foram utilizadas na criação do
Projeto Ilha Cabu. Vemos que também serão de muita utilidade para o nosso
metaverso Pirarucu-Gente, pois ajudam a criar com clareza todos os
elementos básicos de um projeto em hipermídia. A proposta do argumento
e do entorno são fundamentais para situar o projeto. Além disso, chama a
atenção a ideia de Bairon de criar um banco de dados de hipermídias:
“De acordo com Bairon, ter um banco de dados bem elaborado e com
grande quantidade de materiais é uma necessidade para a produção
em linguagem hipermídia e um dos primeiros passos para sua
realização. Lembra, esse professor, que a quantidade varia com a
extensão do projeto e tem relação também com o quanto já sabemos
do que queremos buscar. Ao modo da reflexão de Salles, poderíamos
pensar na constituição do banco de dados como parte de um
processo com tendências, ou seja, que a recolha e escolha do que
55
Proposta de taxonomia de Bairon como proposta em seu texto “Tendências da
Linguagem Científica Contemporânea em Expressividade Digital” de 2006.
156
será utilizado na produção, segue um pensamento, ideia ou modo de
ver o tema, nem sempre, desde o início, consciente para seu autor.”
(PETRY, Arlete, 2010, p. 129)
A coleta de materiais hipermidiáticos é parte integrante do processo de
concepção do projeto, pois imagens, vídeos e sons relacionados ao tema do
argumento podem ajudar a definir a forma e conteúdo finais da produção. O
trabalho de criação do roteiro depende em grande parte disso:
“Sendo assim, qualquer dado percebido, em qualquer lugar, é
material que pode acionar em nós o movimento de produção de algo.
Uma conversa na hora do cafezinho, uma imagem em um filme, um
gesto, uma frase em algum muro da cidade...uma lembrança. Não há
limites para a imaginação. Imaginação é, por excelência, liberdade.”
O PROCESSO INICIAL DE
CONCEPÇÃO DO JOGO
O processo inicial de criação conceitual do Game Ilha Cabu começou com a
listagem de uma série de elementos que a equipe gostaria de ver no projeto:
“Retomamos grande parte dos elementos trabalhados na experiência
de 2005 (Ogro, Boitatá, Pequeno Príncipe, Lobos, algumas frases
selecionadas, a ideia de usar uma determinada música) e outros,
pensados em julho de 2008, quando já intencionávamos propor uma
hipermídia como parte integrante de nossa pesquisa de Doutorado.
Esses outros elementos referiam-se ao espaço de navegação ser
organizado em torno dos quatro ambientes/conceitos principais da
Tese, quais sejam: jogo, autoria, produção de conhecimento e
linguagem hipermídia. Além disso, listamos objetos representativos
na história da autoria, como a pedra de Uhr, o rolo de papiro, o
códice, o livro, a tela do computador etc. Tivemos também a ideia de
que o andar pelo ambiente se daria sobre um grande tabuleiro,
organizado em casas que indicariam tarefas a realizar, ao estilo de
jogos de tabuleiro como Devagar se vai ao longe, Jogo da vida, Banco
Imobiliário etc.” (PETRY, Arlete, 2010, p. 216)
No relato da Profa. Arlete Petry também vemos a importância da montagem
de uma equipe multidisciplinar com pessoas que trabalhem conforme suas
habilidades específicas para que o trabalho seja enriquecido:
“Essa tem sido uma característica necessária na construção de
hipermídias,
dada
a
complexidade
e
a
diversidade
dos
conhecimentos com os quais ela lida. Além de necessária, nós a
percebemos como uma possibilidade bem vinda, pois torna visível o
processo de construção do conhecimento, com sua multiplicidade de
pensamentos e vozes que se cruzam.” (PETRY, Arlete, 2010, p. 129)
Uma das marcas do Projeto foi exatamente o trazer para a equipe de
produção pessoas com características bastante distintas, cada uma com
seus dons específicos.
“Inicialmente procuramos conhecer as competências de cada um e
seus interesses, para organizar as atividades que caberiam a cada um
dos participantes.” (PETRY, Arlete, 2010, p.242)
O
projeto
concepção
colaborativo
e
criação
de
depende
disso e fica cada vez mais rico
dependendo das habilidades que
cada um dos membros da equipe
traz para o trabalho, do quanto
lançam mão dos seus pontos
fortes e se estão bem colocados
em funções que têm a ver com
estes pontos fortes pessoais. Não
é necessário (nem possível) que
todos os membros trabalhem em
todas
as
conceitual
game.
e
Alguns
questão
outros
fases
da
são
na
criação
produção
são
artística
o
da
e
fortes
do
na
conceitual,
questão
da
programação, outros na criação
de puzzles, outros na modelagem
3D e outros na produção de
áudios de ambientação e músicas.
Figura 79 - Mapa da Ilha Cabu
Além disso, existe uma relação
entre as etapas do próprio projeto, como uma ligação entre pré-produção e
planejamento com as ferramentas para a produção: 3D, áudio, code,
gráficos, interface, texto e tipografia, vídeo, web/HTML. Cada membro
conhece e atua em maior ou menor grau com estas ferramentas.
As reuniões de trabalho conceitual com a equipe são fundamentais:
158
“Nesta reunião explicamos o contexto do projeto, os conceitos que
seriam discutidos e as ideias já pensadas para a sua concretização.
Mostramos imagens que informavam a respeito, entre elas, um mapa
já modificado da Ilha Cabu” (PETRY, Arlete, 2010, p. 217) (figura 79)
As definições iniciais importantes do projeto baseiam-se em parte na
taxonomia de Bairon e incluíram o seguinte:
“A – Mote inicial: descrição que situa em que tipo de ambiente ocorre
a narrativa do game, (o que seria o argumento, na linguagem do
cinema) descreve minimamente a personagem principal e algumas de
suas
características.
falas/pensamentos
Podem
possíveis
ser
para
a
acrescentadas
algumas
personagem.
Também
contextualiza as ações com as quais o navegador irá se defrontar,
fornecendo um objetivo para a sequência de fatos. Aqui, pode-se já
indicar de que forma e qual o(s) desfecho(s) para a narrativa.
B – Tipo de roteiro: caracterização do roteiro, por exemplo: se a
narrativa seguirá as características da Tragédia (forma dramática) ou
da Epopeia (forma épica) grega, definição se a narrativa será linear ou
não, se a história se dará em 1ª ou 3ª pessoa, responder quem vê,
quem narra e quem fala na narrativa, qual o nível de bifurcação do
roteiro (possibilidades de escolhas), forma de revelação do que deve
ser descoberto etc.
C – Ambientes: Definição e caracterização do(os) ambiente(s) a
ser(em) navegado(s). Pode-se já planejar como se darão as passagens
de um a outro ambiente.
D – Elementos em cada um dos lugares: Lista dos personagens e dos
objetos com suas características. As ações físicas e o clima emocional
correspondente
pode
aqui
ser
acrescentado.
Novamente,
especialmente por se tratar de um game acadêmico, uma breve
explicação dos conceitos a serem discutidos em cada ambiente se
mostrou como importante, particularmente no momento da criação
dos caracteres em 3D, das animações dos personagens e da
programação sonora.
E – Ideias/Conceito para a Narrativa: Pode ser realizado em forma de
uma grande lista de ações a ocorrerem em determinados locais e
momentos da narrativa, e o motivo para as escolhermos (conceito a
ser trabalhado), quando sabido, é adequado que seja explicitado.
Inclui-se também aqui elementos (personagens e/ou objetos) que se
gostaria de utilizar, mas ainda não se definiu em que ambiente.
F – Frases para o Roteiro: Fazer uma recolha de frases pertinentes à
proposta do game mostrou-se fundamental para ir dando corpo ao
roteiro. Isto por três motivos: 1-não tínhamos grande habilidade com
a criação de roteiros; 2- o roteiro em linguagem hipermídia, a nosso
ver, não necessita seguir o tipo de narrativa exigido no texto apenas
verbal, escrito ou não e, ainda; 3-nosso game tem como referência e
é parte integrante de uma pesquisa acadêmica de doutorado,
portanto, discute conceitos e defende uma tese. Essas frases foram
sendo colocadas na boca de personagens, representadas em ações
ou mesmo materializadas em objetos.
G – Ideias-guia: Esta informação não é fundamental para a
organização do roteiro, mas pode ser útil, quando queremos deixar
registrada (a memória pode nos fazer perder muito) alguma ideia ou
pensamento do qual não queremos nos afastar como proposta de
roteiro.
H – Outros dados: Lista de endereços web com referências a objetos
ou informações importantes para a produção do game.” (PETRY,
Arlete, 2010, p. 220)
Arlete Petry explica que, após a definição de todos os itens acima, várias
reuniões se seguiram, em que o detalhamento do roteiro foi trabalhado por
meio de dois tipos de documentação: fluxogramas dos eventos e
representações gráficas dos mesmos:
“Éramos acompanhados por uma imagem ampliada no mapa da Ilha
Cabu, que nos ajudava a planejar o espaço no qual cada elemento ou
evento aconteceria. Esta foi a forma que nos pareceu mais natural do
roteiro ir crescendo. Não mais texto verbal escrito, mas texto na
forma de Fluxogramas e Desenhos.” (PETRY, Arlete, 2010, p. 229)
PUZZLES COMO RECOMPENSAS
Para além da concepção da ambientação e do espaço navegável do game,
diversos puzzles foram propostos por Cristiano Tonéis e desenvolvidos pela
equipe. A definição do que são os puzzles é bastante interessante.
De acordo com Arlete Petry, Stan Isaacs56 afirma que um puzzle tem duas
características: é algo divertido e possui uma resposta correta. De forma
mais elaborada, Tonéis (2010, p. 152) dirá que “um puzzle se constitui em
uma estrutura lógica organizada e aberta que encaminha um processo
reflexivo que culmina na compreensão de um dado problema que se
constitui no próprio puzzle”.
56
Apud SCOTT no texto de FULLERTON, 2008
160
Ilha Cabu possui diversos puzzles, sendo cinco de pensamento lógicomatemático, dois de lógica e um de memória auditiva. Há ainda outros
menos complexos, como o dar corda em uma Caixa de Música, descobrir
um Mapa da Ilha em meio a livros etc.
“Tínhamos como fio norteador que a consequência de resolver um
puzzle deveria vir na forma de um maior esclarecimento a respeito da
Ilha, ou seja, de um aumento no conhecimento. Em face disso, em
quatro dos puzzles a recompensa é a passagem para outra ilhota, em
outro, além de chegar à outra ilhota, é receber um barco que
possibilite ao navegador trafegar pelo rio entre as ilhotas. Ainda em
outro, a recompensa é poder ouvir música na ilhota Linguagem
Hipermídia.” (PETRY, Arlete, 2010, p. 231)
MANTER UM BOM GRAU DE
IMERSÃO
Uma preocupação da equipe do Ilha Cabu é a de manter um bom grau de
imersão mais do que privilegiar a questão de um conteúdo educativo.
“Embora não julgamos ter conseguido atingir no game Ilha Cabu toda
a qualidade que aprendemos ser importante para ser atraente, nos
esforçamos dentro de todas as limitações que fomos enfrentando, a
explorar nossas maiores qualidades ou forças, sem abandonar
nossas referências conceituais. Uma delas era manter um bom grau
de imersão, experiência de forte envolvimento com uma questão,
como quando pesquisamos ou queremos descobrir algo.” (PETRY,
Arlete, 2010, p. 236)
Esta preocupação é importante por conta do grande problema dos
chamados
“games
educativos”
tradicionais
que
simplesmente
não
conseguem ser interessantes por focar demais na questão do conteúdo
educativo e não conseguem engajar ou produzir imersão. São produzidos
segundo uma visão conteudista completamente inadequada aos novos
tempos da revolução digital e simplesmente fazem um tipo de transposição
de livros didáticos para um formato digital.
Arlete menciona o projeto “Games-to-Teach” do Departamento de Estudos
de Mídia Comparativa do Massachusetts Institute of Technology (MIT) e um
roteiro que deve ser observado durante o desenvolvimento de jogos
didáticos:
•
Os desafios não devem estar relacionados com o assunto
educativo;
“- Os aspectos educativos devem ser apresentados através do
contexto, da ambientação ou de conhecimentos prévios do
usuário;
•
Ambientes imersivos e personagens bem elaborados. Lembrando
que imersão implica em envolver o jogador no ambiente;
•
A ênfase no lúdico. As características pedagógicas devem se
adaptar ao roteiro;
•
Roteiros ricos, bem elaborados e com alto grau de interação.”
O MÉTODO DE TRABALHO E REGISTRO DE ATIVIDADES
As ações do projeto incluíam reuniões com a equipe dos participantes e a
implantação de um espaço virtual no qual todos foram incentivados a
armazenar as etapas de suas criações, na forma de um site, blog e wiki. Na
wiki foi colocado o documento de design da Ilha, no blog as notícias mais
relevantes do processo em andamento e o site tinha a função de tornar o
projeto público. O game propriamente dito foi projetado para ser baixado
pela web.57
DOCUMENTO DE DESIGN
Desde o início, a equipe entendeu que seria importante documentar e
parametrizar por escrito o trabalho de criação conceitual para que não
somente os programadores pudessem realizar o seu trabalho, mas também
para que houvesse organização da documentação do design do game. Além
disso, fazendo a parametrização dos eventos uma documentação estava
sendo gerada, registrando todo o processo de produção.
Entretanto, curiosamente o processo de criação da documentação causou
resistência, pois transportar os fluxogramas construídos nas reuniões para
o digital levava tempo e os programadores achavam mais fácil programar
direto do que primeiramente fazer um fluxograma ou uma especificação
para depois programar (p. 247).
57
O game acadêmico Ilha Cabu está disponível para download na URL
http://www.ilhacabu.net
162
De qualquer maneira, alguns dos puzzles receberam parametrizações em
texto e fluxogramas antes de serem programados, como mostram as figuras
80 e 81 sobre o puzzle da canoa.
Figura 80 - Parametrização do puzzle da canoa na Ilha Cabu
O MÉTODO DE PROGRAMAÇÃO
O trabalho de programação foi construído a partir de reuniões da equipe de
programação que aconteciam concomitantemente às da equipe de roteiro.
Foram ciclos semanais para definir o escopo da programação e o que
precisaria ser implementado. As ideias eram especificadas, pensadas como
seriam implementadas, implementadas via trabalho no código, testadas em
ambiente teste e, finalmente, apresentadas. A partir disso, novas definições
eram especificadas. Este ciclo de trabalho é denominado em computação de
“modelo em espiral”, compreendendo: especificação, codificação, testes e
entrega. (p. 247)
O engine utilizado foi o Unity e a programação foi realizada em Javascript e
C#. Foi implementada Inteligência Artificial (IA) no sistema de locomoção.
Programado um caminho de percurso a ser executado por um personagem e
foram colocados Waypoint colliders para marcar os pontos por onde ele iria
passar.
Figura 81 - Fluxograma do puzzle da canoa.
164
TÉCNICAS DA AQUIRIS NO DESENVOLVIMENTO DO BOOTCAMP FPS
DEMO PARA O UNITY 3
A Aquiris é um estúdio de desenvolvimento de games de Porto Alegre que
foi convidado a desenvolver o game de demonstração intitulado Bootcamp
para a versão 3.3 do Unity 3D. Durante o Unite 2010, o encontro anual
promovido pela Unity para desenvolvedores de games que aconteceu em
Montreal no Canadá, o Diretor Maurício Longoni, o Líder de arte sênior
Amilton
Diesel
e
o
diretor
de
programação
Rafael
Baldi
fizeram
apresentações sobre o desenvolvimento conceitual e sobre a implementação
do projeto Bootcamp em Unity. A apresentação intitulada Bootcamp
Postmortem 58 (LONGONI et al., 2010) foi interessante por colocar alguns
conceitos e algumas técnicas que podem ser muito úteis para quem está
desenvolvendo jogos digitais, sejam eles mono ou multiusuário.
Em especial, vamos estudar aqui a palestra do diretor de arte da Aquiris,
Amilton Diesel que mostra algumas técnicas para a criação de ambientes a
partir de algumas das novas características que a nova versão, naquela
época o Unity 3.3, trazia em relação à versão anterior. A riqueza dos
58
O
vídeo
da
apresentação
pode
ser
visto
na
seguinte
URL:
http://unity3d.com/support/resources/unite-presentations/bootcamp-postmortem
O vídeo no site da Unity parece estar corrompido, razão pela qual disponibilizamos
uma cópia para download no site do projeto Pirarucu-Gente na seguinte URL:
http://www.pirarucugente.com.br/bootcamp-postmortem.mp4
detalhes e os aspectos metodológicos do trabalho da Aquiris aplicam-se a
qualquer trabalho em desenvolvimento de games e não somente àquela
versão específica do Unity, razão pela qual achamos importante registrá-los
aqui.
Amilton Diesel conta que o briefing que receberam da Unity para a criação
do game de demonstração definia que este deveria retratar uma situação de
“treinamento militar” que tivesse carregamentos dinâmicos, gráficos de alta
qualidade e que tivesse “cut scenes” para “esconder” o download de dados
do jogo.
Figura 82 - As fases do jogo Bootcamp como planejadas inicialmente
O plano inicial de jogo era composto por quatro fases (figura 82): uma
floresta, um complexo industrial, uma estrada onde o jogador andaria de
jipe e a chegada à base militar, mas somente as duas primeiras fases
puderam ser concluídas por conta da data de entrega. Cada fase mostraria
algumas das novas características da nova versão do Unity.
De acordo com Amilton Diesel, o visual é uma parte importante do projeto e
precisa ser planejado com cuidado e os “game artists” precisam levar em
conta uma série de outras disciplinas para poder criar um game com boa
aparência. Uma delas é a Fotografia e seus princípios.
Como primeira tarefa de trabalho, a criação de um storyboard é essencial
(figura 83). Serve para termos uma visão geral do jogo e definir o seu
166
formato definitivo. É útil para estudar cores, câmeras e como o jogo vai fluir.
O storyboard precisa ser bastante detalhado de todas as cenas e juntamente
com este trabalho, é importante fazer uma pesquisa de imagens para os
objetos e elementos que serão importantes para o jogo e sua jogabilidade.
Figura 83 - Storyboards são importantes para o planejamento
PALHETAS DE CORES
Às vezes esquecidas pelos “game artists”, as palhetas de cores são um outro
passo importante do processo. As cores são parte importante da informação
que registramos em nosso cérebro quando assistimos a um filme, vemos
uma propaganda ou jogamos um jogo. Mesmo que não consiga lembrar-se
do que viu na história, as cores ainda estão na sua mente. Os storyboards já
servem, inclusive, como testes de palhetas de cores para definir um guia de
cores para o projeto e definir as sensações que cada ambiente do jogo deve
proporcionar.
É importante tomar a palheta de cores em uma perspectiva que é ao mesmo
tempo posta ao longo da linha do tempo do jogo e que componha um
painel das cores e das sensações ou emoções que devem provocar. O
estudo das cores e das sensações que provocam, segundo Diesel, é uma das
questões que todos que querem desenvolver jogos digitais deveriam
estudar. Uma técnica para fazer isso chama-se “Timeline color pallete”
(figura 84), ou palheta de cores em linha de tempo. Esta técnica define as
cores para cada momento do jogo e é poderosa para definir as sensações
para cada momento. Ela traduz em uma única imagem a composição de
cores para toda a sequência do jogo. Não é necessário que isto seja um
documento oficial, mas ajuda o diretor de arte a orientar outros artistas na
composição dos elementos para cada uma das fases do jogo.
Figura 84 - A palheta de cores na linha do tempo do jogo Bootcamp
COLECIONAR REFERÊNCIAS
Criar níveis de jogo realistas não é algo fácil. Sair criando elementos,
modelando-os e fazendo suas texturas sem pesquisa não produz bons
resultados. Para criar níveis de jogo realistas que produzam imersão é
importante coletar muitas e muitas referências realistas antes de modelar ou
texturizar. Em outras palavras, é importante coletar imagens e fotos de
inúmeros locais reais. Em Bootcamp, por exemplo, todos os prédios
baseiam-se em imagens de locais reais. Nas figuras 85 e 86 podemos ver
do lado esquerdo a foto de locais reais e do lado direito imagens dos
ambientes recriados já com objetos 3D. A semelhança é impressionante. O
estudo das fotos e suas cores e texturas é essencial para conseguir este
efeito. É possível criar ambientes críveis desta maneira.
É importante filtrar as referências antes de começar o trabalho de
modelagem. Foram coletadas mais de 3.000 imagens dos mais diversos
elementos: indústrias, florestas, helicópteros, cachoeiras, armas militares
etc. para depois selecionar apenas algumas. Menos de 20% delas foram
efetivamente utilizadas na criação de Bootcamp.
168
Figura 85 - Do lado esquerdo estão as fotos de lugares reais. Do lado direito, os ambientes de
Bootcamp.
Figura 86 - A semelhança entre a foto original e os ambientes recriados é notável.
Como conseguir estas imagens? Pode ser por meio de bancos de imagens
na internet ou alguns artistas preferem fazer coleções de imagens de
ambientes de referência a partir de fotos tiradas por eles mesmos. Alguns,
como Diesel, fazem coleções de imagens de texturas de paredes de
concreto, por exemplo.
PLANEJANDO ESPAÇOS
Existe uma técnica para juntar todas as imagens selecionadas em apenas
um lugar e transformar um álbum de fotos em um nível de jogo.
Começamos com uma planta do nível de jogo e definimos onde cada
elemento se encaixa no mapa geral do terreno (figura 87).
Figura 87 - Correlacionar cada objeto com o local onde estará dentro do jogo para criar um nível de jogo
Na imagem é possível ver a planta do nível de jogo da indústria no
Bootcamp. Cada local possui uma imagem associada. Foram criadas
somente as conexões entre uma e outra para ter uma sensação de
continuidade entre elas. O resultado final é um nível de jogo original e ao
mesmo tempo muito realista porque se baseia em imagens reais.
REGRAS DE COMPOSIÇÃO
As regras de composição podem trazer uma sensação de harmonia para as
mídias visuais entre elas a pintura, a fotografia, os filmes e, mais
recentemente, os games. Os níveis de jogo destinam-se a proporcionar uma
boa experiência de jogo, mas alguns “truques” de composição podem
enriquecer sobremaneira esta experiência de jogo, transformando-a em
170
uma experiência agradável e memorável. Estas são técnicas presentes na
fotografia e em outras mídias tradicionais como a pintura.
Na entrada do nível de jogo da indústria em Bootcamp existe uma
composição que foi trabalhada utilizando uma perspectiva simétrica para
criar um ponto focal, como vemos na figura 88.
Figura 88 - Composição que usa a perspectiva com um ponto focal
Este tipo de perspectiva leva o jogador a sentir que vale a pena ir em frente
e que se trata de um lugar interessante a explorar. Produzir esta sensação
foi algo intencional. Este local transformou-se quase em um cartão postal
do jogo, e isto não foi por acaso. Foi deliberadamente projetado para isso. A
simetria e a perspectiva fazem deste local um lugar mais memorável do que
qualquer outro do jogo, mais do que os prédios comuns e interiores.
Diversos games utilizam estas regras de composição para valorizar seus
níveis de jogo e levar os olhos dos jogadores para algum ponto focal
importante. Na figura abaixo está um exemplo das chamadas “proporções
divinas” e das “regras dos terços” (figura 89).
Figura 89- Utilização de proporções divinas e regra dos terços na composição
As proporções divinas são utilizadas desde a arquitetura grega, ao iPod até
mesmo pela interface do Twitter. Ela é de 16x10 ou 1,6x1,0 e é dividida em
três partes na horizontal e três na vertical e composta por quatro linhas.
Diesel afirma que designers de games precisam conhecer mais sobre as
proporções divinas e as regras dos terços e aprender a aplicá-las em games.
A intersecção entre as quatro linhas cria quatro pontos focais que são
pontos perfeitos para centrar a atenção dos olhos e criam uma harmonia
para a cena e fazem-na confortável para os olhos.
ILUSÃO DO INALCANÇÁVEL
É uma técnica para criar uma sensação de estar em um ambiente de grande
escala que muitos games utilizam. Basicamente consiste em criar um objeto
gigantesco e imponente longe do jogador que dá a sensação que nunca
poderá ser alcançado. Segundo Diesel, em Bootcamp o elemento utilizado
para dar esta sensação é a chaminé da indústria (figura 90). Ao longo do
jogo o objeto vai ficando cada vez maior e, quando menos se espera, o
jogador está junto do objeto. Esta técnica é utilizada com o edifício gigante
em Half-Life 2 e a Death Mountain em Legends of Zelda. (figura 91)
172
Figura 90 - A chaminé dá a sensação do inalcançável em Bootcamp
Esta técnica é interessante porque proporciona uma sensação de mundo real
e estimula a exploração do mundo do jogo. O interessante desta técnica é
que inicialmente o objeto está ao longe e não passa de um gráfico simples
na borda do terreno do nível de jogo. Depois é substituído por objetos mais
complexos na medida em que o jogador aproxima-se através de cada nível
de jogo. Foi assim no exemplo de Legends of Zelda e foi assim em
Bootcamp. Inicialmente, no nível de jogo da floresta, a chaminé é apenas
uma imagem no horizonte. No nível de jogo da indústria ela é um objeto
gigante no meio do terreno.
Figura 91 – O edifício em Half-Life 2 e a Death Mountain em Legends of Zelda
MODELAGEM
Todos os componentes podem ser criados separadamente e organizados
dentro do Unity enquanto a jogabilidade é testada. Quando tudo estiver
pronto, então passa-se à iluminação e ao processo de otimização.
Antes da versão 3 do Unity era necessário calcular a iluminação em outros
softwares e não se podia mudar nada depois, sob risco de ter que fazer
tudo de novo se algo fosse modificado pois os “lightmaps” já estavam
prontos. A partir da versão 3 temos alguns novos elementos que facilitam o
trabalho, transformando o Unity no que Diesel chama de “Level design tool”,
uma ferramenta para o design de níveis de jogo.
Em Bootcamp todos os elementos, incluindo paredes e outras estruturas
importantes, foram criados e colocados dentro de “prefabs” individuais e
distribuídos em um terreno dentro do Unity e podem beneficiar-se do “light
mapper” e do sistema de “occlusion culling”59. Tudo é feito dentro do Unity.
ESCALA DAS TEXTURAS
Diesel afirma que quando estamos definindo as texturas para um nível de
jogo é importante definirmos uma escala segundo o mundo real para fazêlo. Chegou à proporção ideal de 1cm2 X 1px2 entre tamanhos no real e
tamanhos de objetos nos mundos virtuais para a criação de texturas
eficientes nos jogos.
A maioria dos designers acha que quanto maior a resolução, melhor. Isto
não é verdade, em primeiro lugar porque compromete-se mais recursos
como memória de vídeo e o tamanho do arquivo é maior e, em segundo
lugar, texturas maiores não significam texturas de maior qualidade. Se a
59
De acordo com a documentação do Unity, “occlusion culling” é a habilidade de
desabilitar a renderização de objetos que estão atrás de outros objetos. O
“occlusion culling” inclui o que se chama de “frustum culling” que é consiste na
desabilitação da renderização dos elementos que estão fora da área de visão de
uma câmera no jogo. Estes dois servem para aliviar as exigências de recursos do
computador e fazer com que o jogo fique mais rápido evitando a renderização de
objetos que não sejam necessários naquele momento do jogo.
174
textura é maior do que o espaço que ela utiliza na tela, mipmaps 60
aparecerão. E os mipmaps não são precisos, então, a aparência da textura
parecerá borrada, às vezes mais borrada do que se tivéssemos utilizado
uma textura pequena.
Os first person shooters e third person shooters normalmente têm esta
escala de 1cm2 X 1px2 aproximadamente. Foi esta escala que foi utilizada
em Bootcamp.
VEGETAÇÃO REALISTA
O Unity possui um editor de vegetação que permite o desenho de diversos
tipos de vegetação. Para o Bootcamp foi possível recriar 20 tipos diferentes
de árvores. Para poder criar árvores de qualidade é importante prestar
atenção no formato dos caules ou troncos e nas texturas das folhas.
Figura 92 - Dicas para a criação de vegetação realista
As árvores reais têm ramos em forma de “V” e editando manualmente os nós
dos segmentos do caule é possível criar árvores bastante complexas no
editor de árvores do Unity. Uma dica para conseguir árvores realistas é
trabalhar com cuidado as texturas dos ramos das folhas. Fazer ramos
menos densos pode dar mais trabalho, mas produz um resultado muito
melhor (figura 92).
60
Um mipmap é uma sequência de texturas, cada uma das quais uma
representação em menor resolução progressiva da mesma imagem. A altura e a
largura de cada imagem, ou nível, do mitmap é a potência de dois menor que a do
nível anterior. Mipmaps não precisam ser quadrados. Um mipmap de alta-resolução
é usado para objetos que estão mais próximos do usuário. Imagens de baixa
resolução são utilizadas quando o objeto parece mais longe. A utilização do
“Mipmapping” melhora a qualidade das texturas renderizadas ao custo do uso de
mais memória. Explicação do site mdsn.microsoft.com.
ILUMINAÇÃO
No mundo real, a luz do dia possui dois tipos de luz: a luz do sol que é uma
luz direta e a luz do céu que é uma luz difusa formada pelos raios refletidos
do sol. Os fótons incidem sobre as superfícies e são refletidos. Assim
podemos ver as texturas. Para reproduzir a luz do dia real, utilizamos no
Unity um sol artificial e um céu artificial para produzir efeitos semelhantes.
A questão é quais as cores que estas duas fontes devem ter. Se
gerenciarmos as cores destas duas fontes de luz a iluminação dos nossos
projetos será bastante convincente.
Figura 93 - Temperaturas de cor e sensações que provocam
A iluminação refere-se principalmente à temperatura das cores (figura 93).
Se olharmos o exemplo abaixo, vemos que na sombra, os tons brancos são
voltados para o azul, por causa do tom da cor do céu. Se olharmos o
cimento onde incide a luz do sol, os tons brancos são voltados para o
amarelo por causa da luz do céu (figura 94). Curiosamente são cores
complementares, ou opostas, mas é assim que funciona no mundo real e o
efeito é muito convincente no Unity. Tudo tem a ver com contraste.
176
Figura 94- Contraste produzido com as sobras
Boa iluminação é combinar cores opostas e tons diferentes. Para conseguir
bons resultados é preciso combinar uma série de elementos como o
contraste entre escuro X claro, cores frias X cores quentes, sombra X luz.
São estas que proporcionam aos jogadores as sensações entre o azul, da
calma, do frescor e da estabilidade e o vermelho do calor, da excitação e da
instabilidade. Estas são as sensações da vida real que definitivamente
devem ser trabalhadas por meio da iluminação dentro de um game.
Finalizando os comentários sobre a apresentação de Amilton Diesel, as
técnicas utilizadas na Aquiris para a criação de ambientes são dicas
fundamentais para qualquer projeto de metaverso. Procuraremos utilizá-las
na criação do Metaverso do Projeto Pirarucu-Gente. Agora voltaremos nossa
atenção para outros aspectos do Projeto Pirarucu-Gente para podermos
continuar nossa análise.
UM OLHAR SOBRE A METODOLOGIA DA PESQUISA-AÇÃO
Agora vamos nos debruçar um pouco sobre a metodologia que é utilizada
pelo Projeto Pirarucu-Gente no trabalho off-line com os membros do
projeto. Vamos procurar entender a metodologia da pesquisa-ação para
melhor podermos planejar como inserir o trabalho com o metaverso dentro
da dinâmica de trabalho do grupo.
Segundo Thiollent (1996), a pesquisa-ação é um tipo de pesquisa social
com base empírica concebida e realizada em estreita associação com uma
ação ou com a resolução de um problema coletivo e no qual os
pesquisadores e os participantes representativos da situação ou do
problema estão envolvidos de modo cooperativo ou participativo.
O termo foi inicialmente cunhado pelo professor Kurt Lewin 61 , do MIT Massachussets Institute of Technology - em 1944 em seu artigo “Action
Research and Minority Problems” (A pesquisa ação e problemas de
minorias). Ele descreveu a pesquisa-ação como
“uma pesquisa comparativa das condições e efeitos de várias formas
de ação e pesquisa social direcionadas à ação social” que utiliza “
uma espiral de passos, cada um dos quais composto por um ciclo de
planejamento, ação e identificação dos resultados desta ação.”62
Trata-se de uma metodologia que está em contínua discussão e que, de
modo algum, é uma unanimidade entre cientistas sociais e profissionais das
diversas áreas. Alguns, como Thiollent, dizem que existe uma diferença
entre a pesquisa-ação e a pesquisa-participativa, sendo que a primeira seria
a mais abrangente, pois além da participação, “supõe uma forma de ação
planejada de caráter social, educacional, técnico ou outro, que nem sempre
se encontra em propostas de pesquisa participante” (THIOLLENT, 1996).
Tanto a pesquisa-ação como a pesquisa-participante são alternativas ao
padrão
de
pesquisa
convencional,
cuja
preocupação
principal
é
a
quantificação de resultados empíricos. Numa pesquisa convencional “não há
61
Wikipedia - http://en.wikipedia.org/wiki/Kurt_Lewin
62
No original: “a comparative research on the conditions and effects of various
forms of social action and research leading to social action” that uses “a spiral of
steps, each of which is composed of a circle of planning, action, and fact-finding
about the result of the action”.
178
participação dos pesquisadores junto com os usuários ou pessoas da
situação observada” (THIOLLENT, 1996 p. 19). No mais, sempre há uma
grande distância entre os resultados de uma pesquisa convencional e
possíveis decisões ou ações decorrentes. Em pesquisas convencionais as
pessoas que são objeto de estudo são para o pesquisador somente
informantes de uma dada situação. Já na pesquisa-ação, pressupomos a
participação e a ação efetiva daqueles que são objeto de estudo, sendo que
estes são considerados “atores” dentro de um contexto específico e a
metodologia permite que seja estudada a dinâmica do relacionamento entre
os diversos tipos de atores em um dado contexto.
Se existe uma distinção básica entre a pesquisa-participativa e a pesquisaação seria esta: toda pesquisa-ação é de tipo participativo: pois a
participação das pessoas implicadas nos problemas é absolutamente
necessária. Por outro lado, a pesquisa-participativa não inclui uma ação
efetiva junto a um grupo. Neste tipo de pesquisa os pesquisadores
estabelecem comunicação e relação com os membros de um grupo mas
limitam-se apenas a observar e participar do grupo, mas não realizam
nenhuma ação que ocasione alguma modificação naquele contexto.
Do ponto de vista da área de atuação, o alcance da pesquisa-ação limita-se
a um nível microssocial, isto é, baseado na atuação sobre indivíduos e
pequenos grupos, em contraposição a outras disciplinas e metodologias que
operam
em
um
nível
macrossocial,
trabalhando
com a
sociedade,
movimentos e entidades de âmbito nacional ou internacional. Também não
se trata de uma metodologia para o tratamento do indivíduo em si, como é
o caso da psicologia individual. Deste modo, “a pesquisa-ação é apenas um
instrumento de trabalho de investigação com grupos, instituições e
coletividades de pequeno ou médio porte” (THIOLLENT, 1996, p.9). Por
frequentemente tratar de problemas sociais que precisam de soluções
urgentes, a pesquisa-ação possui um caráter mais voltado às questões
sócio-políticas do que propriamente às questões psicológicas das relações
interpessoais, mas isto não significa que estes últimos não sejam
importantes para o seu trabalho.
Os temas e problemáticas tratados pela pesquisa-ação têm início no
contexto da pesquisa com base empírica, ou seja, com base na descrição de
situações concretas e na intervenção e ação direcionadas para a solução de
problemas específicos detectados nos grupos estudados. Isto não quer dizer
que a pesquisa teórica seja desprezada, mas que o ponto de partida é o
lado empírico, como observação e ação em meios sociais delimitados. O
trabalho de teorização é progressivo, a partir da observação e descrição de
situações concretas.
Alguns partidários da metodologia convencional às vezes criticam a
pesquisa-ação, considerando-a um rebaixamento da exigência acadêmica.
Se por um lado existem riscos e exageros efetivos na concepção e
organização de pesquisas alternativas, como o abandono do ideal científico,
manipulações políticas, entre outros, tais riscos, que também estão
presentes em outros tipos de pesquisa, são superáveis mediante um
embasamento metodológico adequado e quadros teóricos bem definidos.
Muitos restringem a concepção e o uso da pesquisa-ação a uma orientação
de ação emancipatória das classes menos favorecidas, sendo uma
metodologia exclusivamente para este fim. Tal é a sua utilização
principalmente na América Latina e em outros países em desenvolvimento
em que possui uma forma de engajamento sócio-político muito forte. No
entanto, a pesquisa-ação pode assumir outras formas em áreas técnicoadministrativas com outros tipos de compromissos sociais e ideológicos,
por exemplo, em exercícios de melhoria organizacional em empresas e
outras instituições.
A
metodologia
pode
ser
utilizada
em
uma
gama
de
áreas,
não
necessariamente voltadas para a questão social. Como diz Thiollent:
“Existe uma grande diversidade entre as propostas de caráter
militante, as propostas informativas e conscientizadoras das áreas
educacional e de comunicação e, finalmente, as propostas “
eficientizantes” das áreas organizacional e tecnológica.” (THIOLLENT,
1999, p. 14)
A pesquisa-ação é um tipo de metodologia voltada para os problemas da
coletividade, seja para questões acerca da organização do trabalho em um
determinado contexto, falta de acesso à terra ou a problemas nas condições
de produção e comercialização de produtos, enfim, a pesquisa-ação procura
fazer um levantamento da situação, formular estratégias e ações práticas
que representem saídas para determinadas situações problema. As soluções
são selecionadas em função de diferentes critérios conforme os interesses
dos atores desta coletividade.
Trabalhamos até agora com os conceitos de pesquisa-ação e pesquisaparticipativa, entretanto, o tipo de pesquisa-ação que desenvolveremos
durante o Projeto Pirarucu-Gente é o da pesquisa-ação participativa.
O
180
termo pesquisa-ação participativa refere-se mais especificamente ao tipo de
pesquisa-ação preconizado por Paulo Freire e amplamente utilizado por
diversas universidades e comunidades ao redor do mundo. A pesquisa-ação
participativa baseia-se na pedagogia de Paulo Freire como uma crítica aos
modelos tradicionais de educação em que o professor levanta-se como o
detentor de um saber que precisa ser despejado sobre os estudantes,
considerados simples receptáculos passivos deste saber.
No caso do Projeto Pirarucu-Gente, os trabalhos em pesquisa-ação terão
duas faces: a da questão social, que busca auxiliar pescadores, piscicultores
e trabalhadores rurais de base familiar a melhorar suas condições de vida e
de ganhos por meio de práticas agroecológicas e inclusão social e digital, e
a segunda, que objetiva aperfeiçoar as estruturas organizacionais das
associações de pescadores e de trabalhadores rurais no sentido de melhorar
seus serviços e profissionalizar sua atuação.
A CRIAÇÃO DO METAVERSO DENTRO DE UM CONTEXTO
COLABORATIVO E REFLEXIVO
A pesquisa-ação é por natureza uma atividade colaborativa muito utilizada
em pesquisas de caráter sociológico, educacional e mesmo corporativo em
ambientes da vida real. Sem a colaboração dos diversos atores ela seria
impossível.
Por outro lado, o trabalho de desenvolvimento de games e metaversos
constitui-se em uma atividade altamente reflexiva e colaborativa per se. Se
levarmos em conta o que diz Petry:
“Os
trabalhos
tridimensionais
de
modelagem
interativos,
tais
tridimensional
como
para
engines
de
ambientes
games
e
metaversos, são atividades reflexivas de alto nível. Enquanto
atividade o ato de modelar um objeto digital equivaleria ao ato de
pensar a coisa enquanto tal, isto em sua constituição de coisa digital,
o que equivaleria a dizer, em uma linguagem filosófica, que
consistiria
em
pensar
a
coisa,
no
próprio
processo
de
desenvolvimento coisico.” (PETRY, 2003)
Em outras palavras, Petry preconiza que, ao modelarmos um mundo virtual
por meio da modelagem de objetos 3D, estamos pensando o objeto em si e
como ele se insere no mundo. No contexto da pesquisa-ação isto revestese de importância maior ainda, pois a pesquisa-ação parte de um ponto
importante de reflexão sobre a realidade dos atores que fazem parte da
pesquisa e procura retrabalhar e agir sobre esta realidade para provocar
mudanças. Ora, o fato de recriar um mundo virtual baseado no mundo real,
mas como uma alternativa melhorada dele, é exatamente o processo que a
pesquisa-ação pretende realizar no mundo real. No mais, equivale ao
processo descrito por Paulo Freire como “distanciar-se de uma realidade”
para poder melhor pensar sobre ela e depois agir sobre ela. São processos
de reflexão análogos, paralelos e não excludentes. O real determina e
modifica o virtual e, por sua vez, o virtual modifica o real.
Um metaverso para o Projeto Pirarucu-Gente poderia ser muito útil do ponto
de vista colaborativo se:
a) Criarmos um metaverso que seja um local virtual de encontro e de
referência, no qual os participantes possam ter acesso a um
condensado de todas as atividades, simulações, materiais didáticos
virtuais (vídeos, etc.) produzidos pelo Projeto. O metaverso deve
dispor de tais recursos para que os sujeitos das instituições parceiras
possam replicar suas práticas em ações de assessoria técnica e
extensão rural, de modo que as demais instituições, agricultores,
pescadores e piscicultores que não participaram do projeto possam
ser alcançados.
b) Pudermos sistematizar o processo de implantação do metaverso para
que outras entidades e organizações possam realizar projetos de
natureza semelhante com outros grupos e em áreas do conhecimento
diferentes.
c) Pudermos fazer do metaverso, juntamente com o site do projeto,
uma base de conhecimento pública que apresente resultados de todo
o trabalho do Projeto Pirarucu-Gente, de modo que o material seja
útil para outras associações e entidades preocupadas com a
sustentabilidade da agricultura, pesca e piscicultura.
d) Pudermos beneficiar a comunidade acadêmica (de pesquisa e
formação). Para criar o metaverso foi organizada uma equipe que
será
responsável
por
todas
as
suas
implicações
técnicas
e
conceituais, impulsionando a pesquisa e o ensino no âmbito da
universidade, inclusive a capacitação de alunos e professores do
Departamento de Engenharia de Pesca e Aquicultura da UNIR na
utilização de softwares 3D para a criação dos elementos e simulações
3D.
182
GAME DESIGN DOCUMENT DO METAVERSO PIRARUCU-GENTE
Departamento de Engenharia de Pesca e Aquicultura
Universidade Federal de Rondônia
por Maigon Pontuschka
Versão # 1. 0
25 de janeiro de 2012
HISTÓRICO DO PROJETO
Este documento pretende registrar o histórico do processo de criação
do Metaverso Pirarucu-Gente, de suas versões e os aperfeiçoamentos feitos
em cada uma delas.
P ROTÓTIPO V ERSÃO 0.1
A Versão 0.1 é uma primeira experimentação com a criação de um
terreno no Unity com diversos tipos de relevo como colinas, um rio, bem
como elementos de vegetação. Foi também uma primeira iniciativa no
sentido de entender o mecanismo de funcionamento da navegação em
primeira pessoa sobre o terreno criado. O protótipo versão 0.1 constitui
uma versão jogável inicial somente para reconhecimento do terreno e das
possibilidades de movimentação sobre ele.
Figura 95 - Primeiro teste de navegação em terceira pessoa. À direita está o mapa do terreno.
A Versão 0.2 é uma primeira experimentação de navegação em
terceira pessoa e uma tentativa de criação de terreno baseada em dados de
satélite sobre um relevo real. Um relevo do interior do Estado de São Paulo
pegando um segmento do Rio Paraná foi escolhido para a experiência. A
navegação em terceira pessoa utilizou um avatar de exemplo do Unity, um
trabalhador. O protótipo versão 0.2 constitui uma versão jogável de
exemplo de como um avatar pode se deslocar pelo terreno.
184
Figura 96 - Aspecto do terreno da Versão 0.3
A Versão 0.3 retoma o terreno criado na versão 0.1 e procura
aperfeiçoá-lo com novos elementos. Utilizamos elementos 3D importados
da Demo do Unity versão 3.3 intitulada “Bootcamp” como uma ponte, uma
casa e um prédio de três andares e o elemento de movimentação de água
do rio. Inserimos, também, sons de natureza e de água para criar uma
ambientação mais realista. Incluímos mais árvores e vegetação rasteira
abundante. A velocidade de movimentação do elemento de navegação em
primeira pessoa foi aumentada para que o deslocamento fosse mais rápido
e foi lhe dada também uma capacidade de “super pulo”, que permite
visualizações aéreas do terreno.
O protótipo versão 0.3 constitui uma
versão jogável que permite uma experiência um pouco mais sofisticada de
imersão que as versões anteriores e foi a versão mostrada no início dos
trabalhos com os pescadores, agricultores rurais, representantes das
associações de trabalhadores e entidades de aperfeiçoamento das condições
de agricultura, pesca e aquicultura de Rondônia.
A Versão 0.4 já inclui um novo terreno baseado nos trabalhos
desenvolvidos com a equipe do Projeto Pirarucu-Gente. Trata-se de uma
recriação estilizada do Território Central da Cidadania de Rondônia,
incluindo 11 municípios do estado. A criação deste terreno baseou-se em
dados de satélite e modificações segundo mapas políticos da região. A
versão
também
permitindo
que
inclui
as
duas
primeiras
ou
mais
experimentações
pessoas
possam
multijogador,
conectar-se
concomitantemente e deslocar-se pelo terreno. Para a criação desta versão
trabalhamos com a equipe do Projeto Pirarucu-Gente para a delimitação do
terreno e o desenho básico das estradas e cidades onde estão cada um dos
membros do projeto.
VISÃO GERAL DO METAVERSO
F ILOSOFIA
Diferentemente de outros metaversos centrados na questão do
entretenimento, o Metaverso Pirarucu-Gente vem cumprir uma função
ligada à questão social e ao trabalho de pesquisa acadêmica na área de
engenharia de pesca, agricultura, aquicultura e práticas ecologicamente
sustentáveis no campo. Nos metaversos temos a interação entre indivíduos
reais por meio de seus avatares e esta interação pode provocar mudanças
significativas no mundo real como no digital. Quando utilizados em projetos
de cunho social, os metaversos podem ter a capacidade de potencializar
mudanças e introduzir seus participantes em novos mundos que permitem,
por sua vez, abrir novas perspectivas no mundo real. É nesta perspectiva
que o Metaverso Pirarucu-Gente será desenvolvido.
O projeto também se alinha com as ideias propostas por Jane
McGonigal em seu livro “Reality is Broken: why games make us better and
how they can change the world” e com o movimento “Games for change”. O
Projeto pretende trabalhar com agricultores rurais, aquicultores, alunos e
pesquisadores da universidade além das associações de trabalhadores rurais
e entidades de desenvolvimento rural utilizando novas tecnologias que
podem promover a inclusão social e digital.
Q UESTÕES
MAIS FREQUENTES
O QUE É O JOGO ?
Não se trata somente de um jogo, mas de um metaverso. Metaversos
são mundos virtuais tridimensionais imersivos nos quais as pessoas
186
interagem entre si e com agentes de software, usando a metáfora do mundo
real, mas sem suas limitações físicas. O Metaverso Pirarucu-Gente pretende
ser um mundo virtual multijogador em que pessoas interessadas em boas
práticas em agroecologia, engenharia de pesca, agricultura e aquicultura
possam se encontrar, encontrar uma biblioteca de boas práticas em cada
uma destas áreas e desenvolver trabalhos colaborativos.
P OR QUE CRIAR ESTE JOGO ?
Diversos fatores contribuíram para que entendêssemos que um
metaverso no Projeto Pirarucu-Gente poderia enriquecer, e até mesmo
redimensionar, o trabalho que estava em andamento no Projeto PirarucuGente. Um metaverso proporcionaria o enriquecimento da convivência e, por
recriar a realidade de modo visual e lúdico, poderia ser de utilidade para
trabalhar com pessoas que não tivessem muito domínio da linguagem
escrita ou acadêmica, caso dos agricultores, pescadores e piscicultores. Um
metaverso pode trazer informações e ensinar de maneira visual e prática, o
que serviria para o propósito de inclusão digital. O Projeto Pirarucu-Gente já
incluía treinamentos em informática para que os participantes pudessem
utilizar
o
computador,
acessar
a
Internet
e
desenvolver
controles
financeiros. A introdução de um metaverso enriquece ainda mais estas
práticas. Outro fator foi que o metaverso apresenta a oportunidade ideal
para juntar em um mesmo ambiente virtual os parceiros de diferentes áreas
do estado, alguns a mais de 400km de distância dos outros, e criar uma
comunidade virtual. Fora isso, o metaverso, associado à criação de um
website do Projeto Pirarucu-Gente, pode ampliar o alcance do projeto
permitindo que qualquer pessoa tenha acesso ao material produzido. No
metaverso serão criados mini games que trabalharão questões importantes
nas áreas do projeto que divertirão ao mesmo tempo em que instruirão os
jogadores em boas práticas.
O NDE O JOGO ACONTECE ?
O jogo recria de modo estilizado a região denominada Território
Central da Cidadania de Rondônia e visa mostrar suas problemáticas,
soluções factíveis para estas problemáticas e boas práticas para o
desenvolvimento da região.
O QUE EU CONTROLO ?
Cada jogador poderá fazer o login no Metaverso Pirarucu-Gente e
escolher um avatar masculino ou feminino para si. É possível customizar
este avatar com diversos tipos de cabelo, blusas, calças e sapatos. Com ele,
poderá percorrer o mundo virtual e encontrar-se com outras pessoas por
meio de seus avatares, conversar por meio de chat e visitar os mini games
sobre boas práticas nas diversas áreas do mundo virtual.
Q UAL É O FOCO PRINCIPAL DO JOGO ?
O foco do metaverso é proporcionar um local de encontro e de
cooperação para pessoas das áreas de interesse do projeto. Adicionalmente,
cada mini game terá o seu objetivo específico. Por exemplo, um mini game
trabalhará a questão da formação de preço final para o pescado. Mostrará
como o pescador pode contabilizar todos os seus custos, seja com gelo,
combustível, eletricidade, funcionários etc. para compor o seu preço final de
venda. Outros mini games trabalharão questões ecológicas como o
reflorestamento e recuperação de matas ciliares, mostrando técnicas e
plantas reais da região que podem ser utilizadas para isso.
E M QUE ESTE PROJETO É DIFERENTE ?
Não conhecemos nenhum outro projeto que esteja utilizando games
ou metaversos de uma maneira tão prática e aplicada à questão do campo.
Este metaverso pode ser usado de maneira lúdica por diversas instituições
preocupadas com a questão ecológica e a questão da qualidade de vida no
campo.
CARACTERÍSTICAS
C ARACTERÍSTICAS G ERAIS
Quanto à topografia geral do metaverso, a equipe pretende fazer a recriação
estilizada da região do Território Central da Cidadania de Rondônia.
188
Figura 97 - O Território da Cidadania Central em Rondônia
Anfiteatro para encontros e reuniões
Além dos prédios destinados às entidades, está prevista a criação de um
“Centro Virtual de Pesquisa dedicado ao ensino e extensão do Projeto
Pirarucu-Gente”. Um dos modelos pensados é o de um anfiteatro virtual,
como o utilizado pelo Slactions [2011] no Second Life. Sua finalidade é
reunir os avatares dos usuários do metaverso para debates, assembleias,
palestras, aulas, assessorias e capacitações. No centro virtual será possível
encontrar material didático como cartilhas, textos, imagens e vídeos
produzidos no projeto, para consulta on-line ou download.
Levantamento fotográfico para a criação conceitual de elementos 3D
Cada uma das organizações fotografará a sua realidade local, incluindo suas
sedes, a sua região e vegetação para que possamos escolher os elementos
mais representativos de cada um dos treze municípios que serão
representados, conforme a abordagem aprendida no trabalho da Aquiris
(LONGONI et al. 2010). O trabalho de coleção de referências já começou
(figura 98).
Figura 98 - Primeiras fotos para o levantamento de referências mostrando castanheiras, buritis e
aspectos da região.
Projetos de vivências técnicas virtuais
Quanto às boas práticas agroecológicas, o projeto prevê a criação de
“vivências técnicas virtuais”, que seriam diversos cenários interativos que
possibilitem atividades lúdicas e didáticas por meio de simulações 3D de
boas práticas em agronomia, piscicultura e outras atividades agroecológicas
sustentáveis. Os temas destes cenários serão definidos conforme os
trabalhos dos módulos. Alguns cenários iniciais propostos são:
1) Mapeamento georreferenciado das nascentes de rios recuperadas no
estado e exemplos práticos virtuais de como fazer esta recuperação;
2) Formas de recuperação de matas ciliares mostrando a recriação de
ambientes semelhantes aos reais com espécies de plantas nativas da região;
3) Exemplos de “quintais agroecológicos” que consistem em um sistema
circular que possui um tanque de criação de peixes no centro e culturas de
190
diversos tipos de hortaliças ao redor e que aproveita a água e outros
recursos de forma otimizada;
4) Exemplos de sistemas agroflorestais e tecnologias socioambientais em
desenvolvimento na região;
5) Um jogo lúdico que ensina técnicas de aproveitamento e tratamento do
couro de peixe para a produção de bolsas, sapatos e outros utensílios;
6) Um jogo lúdico que auxilia pescadores no cálculo de custo de produção
para determinar o preço final de vendas.
C ARACTERÍSTICAS M ULTIJOGADOR
Até 100 jogadores simultâneos
Utilizará o Motor Multijogador Photon Cloud
Customização de avatar masculino ou feminino
Chat em texto inicialmente, mas posteriormente queremos adicionar Voip
(Voice Over IP) para que os jogadores possam falar entre si.
J OGABILIDADE
A definir.
O MUNDO DO JOGO
V ISÃO G ERAL
O mundo retratado será uma recriação da realidade da situação do
campo em Rondônia e das problemáticas e das soluções para estas
problemáticas. É por isso que recriamos exatamente o Território Central da
Cidadania como terreno do jogo.
R ECRIAÇÃO
DAS CIDADES
Recriaremos as cidades dos municípios do Território Central de modo
estilizado. Não serão cópias das cidades reais nem estarão em escala, mas serão
uma representação
simplificada
destas cidades com características básicas
semelhantes às das cidades reais.
E STRADAS
Recriaremos as estradas na mesma conformação e traçado das
estradas reais do Território Central a partir de mapas do Google Maps e
outros mapas políticos.
Figura 99 - Mapa político do Território Central da Cidadania e fotos de satélite do Google Maps
exatamente da mesma região e na mesma escala
Figura 100 - Processo de elaboração do terreno da versão 0.4
Localização das cidades e locais das organizações que participam do Projeto
Para a organização do espaço, cada entidade criará um prédio virtual, no
qual ficam registradas a evolução de suas práticas, atividades e registros.
Neles pode-se visualizar textos, gráficos e imagens que apresentam cada
192
instituição, suas metas de ação no projeto, as ferramentas de diagnóstico e
planejamento participativo e de projeto de futuro de cada uma delas. Serão
expostos, por exemplo, diagramas de Venn, gráficos de análise de
envolvimento institucional e projeto estratégico, entre outros documentos e
gráficos. Todos estes elementos constituirão um histórico de todo o
processo, do começo ao fim. Cada entidade está trabalhando com a equipe
de 3D para escolher o design de seu espaço digital, participando inclusive
de laboratórios de criação.
Atualmente, o grupo discute a situação da
inserção dos prédios virtuais na topografia digital do metaverso, suas
relações espaciais e de comunicação e trânsito para os seus usuários.
Figura 101 - Participantes do Projeto marcando as localidades das suas entidades no mapa
V EGETAÇÃO
Recriaremos aos poucos a vegetação local de Rondônia, começando
pelas árvores e plantas mais comuns, como o Buriti, as Castanheiras e a
vegetação rasteira. Utilizaremos a ferramenta de criação de vegetação do
Unity bem como outros aplicativos de modelagem.
Para estudarmos a distribuição da
vegetação no terreno e podermos
recriar
a
situação
desmatamento
atual
da
de
região
pegamos um mapa político e
sobrepusemos a uma imagem de
satélite que mostra com clareza
as
áreas
de
mata
ainda
preservadas e as vastas regiões
desmatadas. Isto será recriado no
metaverso.
Figura 102 - Estudo da distribuição da vegetação
L OCAIS CHAVE
Além das cidades, serão locais chave a representação dos Campi da
Universidade Federal de Rondônia e as sedes das instituições participantes
do Projeto Pirarucu-Gente
L OCOMOÇÃO NO JOGO
Os jogo será em modo de terceira pessoa, isto é, o jogador verá a si
mesmo de costas e aos outros avatares com quem conversar. Além de andar
a pé, haverá um sistema de locomoção que permitirá aos avatares
locomoverem-se de uma cidade à outra de carro ou ônibus.
E SCALA
O mundo será em escala menor do que a real para que as distâncias
não fiquem longas demais entre as cidades.
O BJETOS
(a completar)
194
C ONDIÇÕES ATMOSFÉRICAS
O
metaverso
terá
um
sistema
que
modificará
as
condições
atmosféricas. Será possível termos condições de chuva, de sol e de dia
encoberto.
D IA E NOITE
No metaverso sempre será dia.
T EMPO
O tempo será exatamente igual ao tempo real.
S ISTEMA
DE
R ENDERIZAÇÃO
V ISÃO G ERAL
(A completar)
R ENDERIZAÇÃO 3D
(A completar)
C ÂMERA
V ISÃO G ERAL
(A completar)
M OTOR
DE J OGO
V ISÃO G ERAL
Utilizaremos o Unity 3D como motor de jogo.
Á GUA
Haverá necessariamente água por conta das atividades de pesca e de
aquicultura e o motor de jogo precisa lidar com sua simulação com
qualidade.
D ETECÇÃO DE COLISÃO (C OLLISION D ETECTION )
(A completar)
M ODELOS
DE I LUMINAÇÃO
V ISÃO G ERAL
(A completar)
P ERSONAGENS
DO J OGO
V ISÃO G ERAL
(A completar)
C RIANDO UMA P ERSONAGEM
(A completar)
I NIMIGOS E A DVERSÁRIOS
(A completar)
A I NTERFACE
DO
U SUÁRIO
V ISÃO G ERAL
(A completar)
F ERRAMENTAS
E ARMAS
V ISÃO G ERAL
(A completar)
M ÚSICA
E
E FEITOS S ONOROS
V ISÃO G ERAL
(A completar)
196
3D S OUND
(A completar)
S OUND D ESIGN
(A completar)
S INGLE -P LAYER G AME
V ISÃO G ERAL
(A completar)
N ARRATIVA
(A completar)
M ULTI -P LAYER G AME
V ISÃO G ERAL
(A completar)
N ÚMERO MÁXIMO DE J OGADORES
100 jogadores simultâneos.
S ERVIDORES
O jogo funcionará no modelo cliente-servidor.
C USTOMIZAÇÃO
(A completar)
P ERSISTÊNCIA
O mundo será persistente, como um metaverso deve ser.
S ALVAR E C ARREGAR UM J OGO
Não é possível propriamente salvar e carregar um jogo. Uma vez que
um usuário esteja registrado, sempre que voltar ao jogo, reaparecerá no
mesmo local onde saiu.
R ENDERIZAÇÃO
DE PERSONAGENS
V ISÃO G ERAL
(A completar)
E DIÇÃO
DO
M UNDO
V ISÃO G ERAL
O jogo não possuirá um editor do mundo.
O UTRAS Q UESTÕES
V ISÃO G ERAL
(A completar)
“A PÊNDICE DE O BJETOS ”
(A completar)
“A PÊNDICE DE INTERFACE DE USUÁRIO ”
(A completar)
“A PÊNDICE DE N ETWORKING ”
(A completar)
198
CONSIDERAÇÕES FINAIS E CONCLUSÕES
Chegando ao final de nossa pesquisa é importante retomarmos algumas
questões que colocamos em nosso trabalho e verificarmos o quanto
caminhamos desde então, e o quanto o que pudemos vivenciar durante a
pesquisa modificou a nossa perspectiva sobre os metaversos e as suas
formas de implantação.
Nossa proposta inicial era analisar aspectos para a criação conceitual de
metaversos
e
também
a
questão
da
implantação
do
componente
multijogador em rede.
No capítulo 1 apresentamos um painel que procurou colocar o quadro
teórico da questão dos metaversos e uma perspectiva histórica do seu
advento. O capítulo 2 discutiu os rudimentos das redes de computadores,
que são os elementos base dos games multijogador em rede e dos
metaversos, enquanto a questão da criação conceitual dos metaversos e
uma proposta para o Metaverso Pirarucu-Gente foi discutida no capítulo 3.
Trabalhamos ainda a perspectiva de Janet Murray e de seus três pontos
principais sobre os metaversos, a saber, a imersão, a agência e a
transformação. A nossa conclusão é que, apesar de todos serem
fundamentais, o absolutamente essencial, na perspectiva do objeto de nossa
pesquisa, é a imersão. A imersão é o fator responsável pelo sucesso ou não
de qualquer metaverso. Sem ela, sem o “viver dentro e junto”, qualquer
metaverso é fadado a fracassar. Em última instância, a imersão é o fator de
engajamento que determina o sucesso ou não de um game. Nesse sentido,
agência e transformação deveriam ser pensados como componentes que se
desenrolam no interior de uma imersão que é tomada como base ou
fundamento.
Em seguida apresentamos a perspectiva de Jane McGonigal, que adiciona
um componente social importantíssimo à questão dos games, mostrando
um viés dos games voltado para a modificação do mundo real, para uma
relação colaborativa entre o exercício e experiência dentro do mundo digital
e as estruturas sociais, econômicas, ideológicas e vivências do mundo e da
vida. A visão de McGonigal é revolucionária e libertadora em relação à visão
preconceituosa do senso comum a respeito dos games e dos gamers como
pessoas alienadas. McGonigal apresenta uma forma inteligente de refletir
sobre a realidade ao criar games vinculados tematicamente com a realidade
200
do século XXI, buscando uma alternativa a partir da proposta dos chamados
“alternate reality games”.
Com Sherry Turkle apresentamos uma pesquisadora que trabalha a questão
da identidade na era da internet e a incidência do digital sobre o sujeito
humano. Com seu livro “Life on the Screen” (TURKLE, 1997) analisa o quanto
a interação homem-computador produziu modificações expressivas no
modo de ser e de pensar do homem a ponto de gerar uma mudança
qualitativa de “o que o computador pode fazer para nós” para “o que ele faz
em nós”, em nossas relações e “nossas formas de pensar sobre nós
mesmos”. Recentemente, em seu livro “Alone Together” (TURKLE, 2011), a
autora afirma que chegamos a um ponto de saturação de tanto estarmos
conectados e que isto produz um fenômeno de estarmos todos juntos online, mas essencialmente e emocionalmente sozinhos. Afirma que é
necessário termos um regime que nos dê o balanço entre nossa vida pessoal
privada e nossa vida online.
Complementarmente a esses importantes pontos, ainda dentro do capítulo
1, realizamos um breve périplo pela história dos videogames buscando os
elementos que foram essenciais e que formaram a base para a emergência
do conceito e técnica dos metaversos. Vimos inicialmente que games
multijogador e games em rede não são sinônimos e que podemos ter games
multiusuário
em
rede
e
games
multiusuário
sem
rede.
Vimos
as
contribuições desde os primeiros jogos multijogador, como o “Tennis for
Two”, passando pelos primeiros jogos de aventura em texto monojogador
aos MUDs, já de caráter multijogador. Caminhamos até chegarmos aos
jogos multijogador em rede e a jogos que inovaram na questão da narrativa
e na questão gráfica como Zork Nemesis (1996) e Myst (1993), levando a
um novo patamar de sofisticação que finalmente conduziria à criação dos
MMOs e MMORPGs, nos quais jogos poderiam também se colocar como
metaversos, tais como WoW e Myst Online Uru Live.
No final do capítulo 1 apresentamos algumas estatísticas recentes que
mostram que os metaversos e mundos virtuais vieram para ficar e que estão
gerando mudanças significativas no mundo real nas mais diversas áreas,
seja social, legal, comportamental ou financeira. Inicialmente apresentando
uma curva ascendente impressionante, os mundos virtuais prometiam
imaginariamente na mídia o impossível para o seu tempo e sua sociedade. A
partir de seu ocaso, eles estabilizam-se e tornam-se uma tendência que se
firma em uma taxa crescente, demonstrando assim que são uma importante
perspectiva de ação humana e interatividade que deixará profundas marcas
no século XXI. Nesse sentido, podemos observar que um mundo digital
massivo – um metaverso pleno, não necessita ser conhecido por “toda a
gente” para poder existir e ser incrivelmente utilizado. Enquanto o Second
Life conta com uma afluência muito menor do que no seu período de maior
popularidade, ainda segue firme adiante, sendo utilizado principalmente por
universidades e empresas para a realização de cursos e treinamentos. Já o
Myst Online Uru Live tem, em média, de 10 a 20 jogadores simultâneos online. Entretanto o Myst Online Uru Live não possui o mesmo status dentro da
mídia e, com isso, passa para muitos, inclusive “pesquisadores”, como se
não existisse. Nossa pesquisa mostrou que em um mundo globalizado, no
qual o ciberespaço torna-se a chave para muitas perspectivas, tal situação
não pode nos parecer espantosa. Ela é, até certo ponto, trivial.
No capítulo 2 estudamos o Modelo OSI e como os dados são enviados por
meio de pacotes de um computador para o outro por meio de protocolos
TCP/IP
nas
redes
atuais
fazendo
os
jogos
multijogador
em
rede
funcionarem. Estudamos algumas variáveis importantes para estes games
como latência, largura de banda, compressão de dados e sincronização.
Depois passamos aos trabalhos de Mark Hergaarden sobre como instalar o
componente multijogador em rede no motor de games Unity 3D e testamos
os seus scripts fazendo-os funcionar. Depois estudamos as técnicas e os
serviços da Exit Games com o Photon Socket-Server e sua opção para
computação em nuvem e testamos três cases diferentes de games
multijogador: um FPS e dois MMOs.
No capítulo 3 voltamos à origem das nossas indagações sobre os
metaversos
buscando
elementos
teóricos
e
práticos
para
darmos
continuidade ao trabalho de criação conceitual e montagem do Metaverso
Pirarucu-Gente. Para isso, revisitamos o projeto que nos serviu de
inspiração inicial, o Game Acadêmico Ilha Cabu procurando extrair alguns
pontos-chaves
que
pudessem
nos
auxiliar
na
criação
conceitual.
Revisitamos também uma palestra dada pela equipe da Aquiris durante o
Unite 2010 sobre as suas técnicas de criação gráficas. A Aquiris é uma
empresa brasileira que, demonstrando o exemplo do potencial existente no
Brasil e dos que realmente trabalham, criou o primoroso Demo Técnico
Bootcamp para o Unity 3.3. Em seguida, retomamos a metodologia original
do Projeto Pirarucu-Gente, a pesquisa-ação participativa (off-line) para
tentarmos entendê-la melhor e verificar como os metaversos poderiam ser
inseridos neste contexto de pesquisa ou poderiam modificá-lo. Por último,
começamos a esboçar um Documento de Design de Jogo, em inglês, Game
202
Design Document, que possa ser significativo para os trabalhos no Projeto
Pirarucu-Gente.
Conclusões gerais de nosso trabalho:
Na introdução de nossa dissertação colocamos que a nossa intenção era
sistematizar o processo de criação de um metaverso, tornando-o inteligível
mesmo a pessoas que não fossem ligadas à área de informática ou games,
de modo que pudessem participar e ajudar na criação de um metaverso
significativo que ajudasse a modificar sua realidade, coisa que coaduna com
as concepções de McGonigal. A ideia era fazer, em um sentido metafórico,
uma espécie de caminho das pedras da criação de um metaverso
multiusuário que fosse útil para outros grupos de outras áreas que
quisessem fazer projetos semelhantes e que estes pudessem ser utilizados
na pesquisa acadêmica.
Em primeiro lugar, a nossa perspectiva do trabalho de criação dos
metaversos foi radicalmente modificada ao longo da pesquisa. Pudemos
perceber que este trabalho não é uma questão que pode ser reduzida
apenas ao âmbito das Ciências Exatas, na Computação ou Matemática, e
que se resuma simplesmente em código de programação ou em um
caminho único de desenvolvimento. Existe um outro lado deste processo de
criação e implantação que é essencialmente e visceralmente ligado às
Ciências Humanas, à Arte, à Música, à Narrativa e a questões psicológicas
por demais profundas para serem enfocadas a partir do escopo da presente
pesquisa.
É claro que existem diversas ferramentas que podem ser utilizadas para a
criação e desenvolvimento de metaversos, mas nenhuma destas ferramentas
per se garante um projeto de metaverso bem feito ou de qualidade.
Descobrimos que, apesar de todos os projetos de criação de metaversos
compartilharem algumas fases em comum, não existe uma receita pronta ou
um caminho das pedras definido. Existem algumas linhas gerais ou
taxonomias de trabalho com hipermídias, a exemplo dos pontos abordados
por Sergio Bairon e Arlete dos Santos Petry, a partir dos quais é possível
criar-se um trabalho novo, inédito e profundo. Assim como não é possível
fazer uma receita para escrever um livro, não é possível fazer uma receita de
como criar um metaverso. O trabalho de criação é indissociável das pessoas
que o estão criando, de quem são, do momento e das referências que estão
utilizando.
No capítulo 2 vimos as bases para a implantação de metaversos, isto é, a
questão multijogador em rede. Uma das perguntas que nos fazíamos no
início de nossa pesquisa era se existia uma maneira mais fácil de implantar
um metaverso, por exemplo, para que pessoas que não fossem da área de
informática, ciência da computação ou games pudessem fazê-lo. Nos
perguntávamos, por exemplo, se uma pessoa que não fosse de uma destas
áreas ou áreas afins conseguiria criar e gerir um metaverso de sucesso.
Depois de estudar todo o material de Hergaarden, o material da Exit Games
e o processo de produção do Game Acadêmico Ilha Cabu, a nossa conclusão
é esta: mesmo que se procure criar formas didáticas e mais fáceis para
implantação de metaversos, se desejarmos ter um produto final de
qualidade
realmente
é
necessário
termos
bons
conhecimentos
em
informática, ciência da computação ou em criação de games. Não somente
isso, precisamos também ter conhecimentos em arte, narrativa, psicologia e
organização de projetos. O trabalho de elaboração de games, em especial
de metaversos, não é uma tarefa fácil. Para ser bem feito requer não apenas
que a pessoa seja especialista em um tema, mas também que diversos
especialistas em diversos temas estejam envolvidos. Como disse a Profa.
Arlete Petry:
“A produção colaborativa. Essa tem sido uma característica necessária
na construção de hipermídias, dada a complexidade e a diversidade
dos conhecimentos com os quais ela lida. Além de necessária, nós a
percebemos como uma possibilidade bem vinda, pois torna visível o
processo de construção do conhecimento, com sua multiplicidade de
pensamentos e vozes que se cruzam.” (PETRY, Arlete 2010, p. 129)
Isto ficou bastante claro a partir do estudo do processo de criação da Ilha
Cabu, em que ficou enfática a divisão do trabalho de criação a partir dos
pontos fortes de cada membro da equipe. Ora, os pontos fortes são
formados em parte pelo talento pessoal que alguma pessoa tem, mas
também pelo grau de conhecimento que esta pessoa possui em uma
determinada área de conhecimento. Deste modo, concluímos que, mesmo
sendo salutar fazer com que as explicações e os tutoriais sejam cada vez
mais claros, não devemos ser tão ingênuos a ponto de achar que qualquer
pessoa sem experiência ou sem o apoio de uma equipe possa, sozinha,
desenvolver do zero um metaverso de qualidade. O trabalho de criação de
metaversos requer, sim, uma série de habilidades e conhecimentos prévios,
sem os quais o trabalho ficará muito primário, sem profundidade e sem
chances de produzir a tão desejada imersão.
204
Por outro lado, observamos que a nossa pesquisa que culminou na presente
dissertação pode ajudar pessoas que não são ligadas à área de informática
ou games a entenderem os conceitos e a forma de trabalho de modo que
participem e ajudem, de fato, a criar um metaverso de qualidade,
entendendo como o processo se dá. Entretanto, certamente será necessário
que um ou mais autores principais saibam como direcionar o trabalho de
concepção e criação do metaverso conforme as ideias de um roteiro.
Existem diversos produtos que prometem ajudar as pessoas a criarem seus
próprios metaversos. Na verdade, estes são variações customizadas de um
produto já criado e não a criação de um metaverso novo.
Quanto à possibilidade de criar um metaverso significativo que ajude a
modificar uma realidade específica, nossa pesquisa mostrou diversas novas
facetas e possibilidades que não havíamos aventado. O tipo de trabalho que
tínhamos em mente com o
Metaverso do Projeto Pirarucu
estava
inicialmente relacionado apenas a dois aspectos dos metaversos, um é a
capacidade “enciclopédica” dos metaversos, que permite juntar diversos
elementos em um mesmo ambiente de modo organizado em um espaço
(MURRAY, 2003 p.88), e a possibilidade de pessoas de diversos locais
diferentes acessarem e poderem interagir entre si em um ambiente virtual.
Entretanto, as ideias de Jane McGonigal trouxeram novos elementos que
podem nos levar a novas direções.
McGonigal mostrou que é possível criar jogos que estejam diretamente
relacionados a problemas específicos que coloquem os jogadores em um
estado de discussão que possibilite a criação de novas alternativas para que
se possa sair de uma dada situação problema com várias soluções a serem
experimentadas. O MMORPG “World Without Oil” (MCGONIGAL, 2011 p.302)
é um exemplo disso. Cria uma situação problema e “imerge” os jogadores
dentro dela para que descubram soluções para ela. O interessante é que
estes jogos de McGonigal são, na verdade, tratados como experimentos e
têm um período breve e específico de vida. No caso de “World Without Oil” o
jogo durou 6 semanas, ao final das quais diversas “soluções incrivelmente
criativas” por parte dos jogadores haviam sido postadas em blogs, vídeos e
fóruns como resultado do jogo (MCGONIGAL, 2010). Resta saber se as
soluções serão um patrimônio para a humanidade ou um tópico de patente
de uma grande multinacional que ficará esperando pelo fim das reservas de
petróleo para ser então colocado à prova. Questões como essa são
realmente essenciais para todos, e não simplesmente discursos de
“pretensos revolucionários” que são, na verdade, “novos reacionários” que
não veem a hora e a sua vez de controlar o sistema e repetir a história, tal
como muito bem nos mostra Marx no XVIIIº Brumário de Luiz Bonaparte e
Lampedua em Leopardo.
No caso de McGonigal, não sabemos ainda por meio de resultados
publicados se as “soluções incrivelmente criativas” foram depois trabalhadas
ou como foram trabalhadas, mas este é um exemplo claro de produção de
conhecimento
que pode
e
deve
ser
promovido
e
estudado
pelas
universidades. Estas “soluções incrivelmente criativas” são, na verdade,
possíveis boas práticas em relação a algum problema específico que
precisam ser testadas e estudadas para poderem constituir-se como base
de conhecimento para novas pesquisas.
Nosso relato nos faz pensar em outras possibilidades para o Metaverso
Pirarucu-Gente. Ao invés de utilizá-lo apenas como local de encontro para
discussões via chat e como local para “visitas técnicas” a exemplos 3D de
boas práticas em agroecologia, agricultura, pesca e aquicultura (levantados
nas discussões off-line), seria possível criarmos outros tipos de jogos que
selecionem
uma
problemática
e
que
permitam
discussão
on-line
aproveitando toda potencialidade dos MMORPGs e dos outros tipos de
interação que a web 2.0 proporciona, principalmente no que tange à
produção de conteúdo por parte do jogador na forma de textos, imagens e
vídeos em blogs, fóruns de discussão e no YouTube.
De qualquer modo, entendemos que é necessário estudarmos mais a fundo
os jogos criados por McGonigal e pela equipe do movimento “Games for
Change”, pois acreditamos que esta pode ser uma técnica a ser usada na
área da pesquisa-ação nas mais diversas áreas de estudo. Fica este assunto
para pesquisas posteriores.
Como último ponto de nossa conclusão, vemos uma necessidade enorme de
narrativas e missões nos metaversos plenos ou MMOs e também a falta de
uma narrativa básica no Metaverso Pirarucu Gente como um problema que
precisa ser resolvido. Explicando melhor, a questão da imersão e do
engajamento em um metaverso passa necessariamente pelo modo como o
jogador “vive” a sua estada no metaverso. Começamos a pensar esta
questão ao passear pelas vastas ilhas vazias do Second Life (2012) e ao
meditar nos textos que falam sobre sua suposta “morte” (LIVINGSTONE,
2011). Em contraste, percebemos como nos engajávamos em diversas
missões ao entrarmos no Entropia Universe (2012), o que nos dava um
senso de direção e de metas a cumprir e como isto nos deixava mais alertas
para com os detalhes. No mais, percebemos que até a equipe do Myst
206
Online Uru Live (2012) percebeu este problema. Há alguns meses, ao
entrarmos neste MMO belíssimo baseado na série Myst, passeávamos pelo
espaço, assim como queria seu criador original. O problema é que a falta de
uma narrativa que servisse como fio condutor de nossos passos e de nossa
atenção fazia com que nos desestimulássemos logo. Foi o que aconteceu
depois de explorarmos um pouco o Uru Live. Curiosamente, ao entrarmos
no metaverso recentemente notamos uma mudança interessante. Foi criada
uma nova “era” que aparece logo no início do jogo, um cenário de deserto
do Novo México em que fica claro que devemos procurar sete pistas. Esta já
é uma meta que nos faz seguir adiante. Enquanto encontramos algumas
pistas, outros elementos de uma narrativa interessante começam a surgir,
contando do Reino de D’ni no subsolo e de outros detalhes que procuram
engajar o jogador na história. Somente depois que a sétima pista é
descoberta somos levados às “eras” tradicionais do Uru Live. Pois bem, esta
modificação neste MMO fez toda a diferença no sentido de nos engajar em
uma narrativa dentro do metaverso por meio do uso de uma meta, ou uma
missão.
Voltando ao Metaverso Pirarucu-Gente, creio que corremos o risco de criar
um metaverso que fique vazio, assim como o Second Life ficou, se não
tivermos uma série bem organizada de missões ou metas bem estabelecidas
sobre uma narrativa principal. Nossa conclusão é que precisamos criar uma
narrativa que possa ajudar a engajar os jogadores e que sirva como linha
central de toda a atividade no Metaverso Pirarucu-Gente.
REFERÊNCIAS
Active Worlds Educational Universe (2012) metaverso [online] Disponível em
http://www.activeworlds.com/edu/awedu.asp [Acessado em 08/01/2012]
AGRA, Lúcio (2004) História da arte do século XX: ideias e movimentos. São Paulo.
Editora Anhembi Morumbi. 1a edição. ISBN: 8587370146 - ISBN-13:
9788587370143;
ANDERSON,
Tim
(1985)
The
History
of
Zork
[online]
Disponível
em:
http://www.csd.uwo.ca/Infocom/Articles/NZT/zorkhist.html [Acessado em
19/01/2012].
ARMITAGE, G.; Claypool, M.; Branch, P. (2006) Networking and online games:
understanding and engineering multiplayer Internet games. England: John
Wiley & Sons.
ASF (2010) Metaverse Roadmap: Pathways to the 3D web – Glossary: Metaverse
[online]
Acceleration
Studies
Foundation
Disponível
http://www.metaverseroadmap.org/inputs4.html#glossary
em
[Acessado em
13/11/2011]
AUMONT, Jacques (2004) A Imagem. São Paulo: Papirus - 9a edição.
AZEVEDO, Eduardo coord. (2005) Desenvolvimento de Jogos 3D e aplicações em
realidade virtual. São Paulo. Editora CAMPUS. ISBN: 8535215697;
BAINBRIDGE, William S. (2007) The Scientific Research Potential of Virtual Worlds.
Science
317,
472
[online]
Disponível
em
http://files.harc.edu/WWW/About/Internships/2007/ScienceArticle.pdf
[Acessado em 20/01/2012]
BAIRON, Sérgio & Petry, Luís C. (2000) Hipermídia, psicanálise e história da cultura.
Caxias. EDUCS. 2000;
BARBOSA, P e Petry, Luís C. (2008) Ópera Quântica Eletrônica AlletSator [online]
Disponível
em
http://www.telepoesis.net/alletsator
[Acessado
em
17/11/2011]
BARKER, Kim (2011) MMORPGing: The Legalities of Game Play. BILETA British and
Irish Law Education and Technology Association 26 th Annual Conference
[online]
Disponível
em
http://www.law.mmu.ac.uk/wp-
content/uploads/2011/04/MMORPGing-The-Legalities-of-Game-Play.pdf
BARTLE, Richard (1990) MUD History: who invented MUDS? [online] Disponível em
http://www.livinginternet.com/d/di_major.htm
.
[Acessado
em
19/01/2012]
BASAGOITI-RODRÍGUEZ, M. et al. (2008) IAP de Bolsillo [online] Asociación para la
Cooperación con el Sur. Disponível em: http://www.pirarucugente.com.br.
BRITO, A. (2010) Blender 3D 2.49 Architecture, Buildings, and Scenery: Create
photo-realistic 3D architectural visualizations of buildings, interiors, and
environmental scenery with Blender. Birmingham: Packt Publishing.
208
BUSH, Vannevar. (1945) “As we may think” ln: Nelson, Theodor. Literary Machines.
Sausalito, Mindful Press
CANUTO, J. C. (2009) Metodologia da pesquisa participativa em agroecologia.
Embrapa. Disponível em: http://www.pirarucugente.com.br. [Acessado em
28/07/2011]
CAPURRO,
Rafael
(2009)
Contribuições para uma ontologia
digital. Texto
apresentado no III Colóquio Internacional de Metafísica (CIM) 20-24 de
abril,
2009,
Natal,
Brasil.
Disponível
http://www.capurro.de/ontologiadigital_pt.html
em
[Acessado
em
18/11/2011]
CERTEAU, Michel de (2000) A invenção do cotidiano. Volume 1. Petrópolis. Vozes.
DANNAN,
Lorna
(2011)
Grande
Caverna
D’ni
[online]
Disponível
em
http://www.grandecaverna.com [Acessado em 26/12/2011]
DAVIS, Alanah et al. (2009) Avatars, People, and Virtual Worlds: Foundations for
Research in Metaverses, Journal of the Association for Information Systems:
Vol.
10:
Iss.
2,
Article
1.
Disponível
em
:
http://aisel.aisnet.org/jais/vol10/iss2/1 . [Acessado em 07/09/2011].
DAVIS, Phillip J. e HERSH, Reuben (1988) O sonho de Descartes. São Paulo: Editora
Francisco Alves - 1ª Edição.
DETERCO, J. e ALCÂNTARA, P. R. (2004) “O Mundo virtual como ferramenta
interativa no ensino-aprendizagem colaborativo" Comunicar, 23, Grupo
Comunicar,
Hueva,
Espanha,
pp.77-81.
Disponível
http://redalyc.uaemex.mx/pdf/158/15802313.pdf
em
[Acessado
:
em
23/10/2011].
Dwell on it (2012) Second Life Statistical
Charts [online] Disponível em:
http://dwellonit.taterunino.net/sl-statistical-charts/
[Acessado
em
08/01/2012]
Electroserver
5
network
Engine
(2011)
Electrotank.
Disponível
em
http://www.electrotank.com/docs/es5/manual/index.html?video_tutorials.
htm [Acessado em 07/09/2011]
Entropia
Universe
(2012)
metaverso.MindArk.[online]
Disponível
em
http://www.entropiauniverse.com [Acessado em 28/01/12]
Exit Games (2011) [online] http://www.exitgames.com [Acessado em 22/12/2011]
EXPÓSITO-VERDEJO, M. (2003) Diagnóstico rural participativo: Uma guia práctica.
Centro Cultural Poveda, Santo Domingo, República Dominicana. Disponível
em:
http://www.centropoveda.org/IMG/pdf/Diagnostico_Rural_Participativo.pdf
. [Acessado em 28/07/2011]
FONSECA FILHO, Cléuzio (2007) História da computação [recurso eletrônico]: O
Caminho do Pensamento e da Tecnologia. Porto Alegre: EDIPUCRS. [online]
Disponível
em
http://pt.scribd.com/doc/12934547/Historia-Da-
Computacao [Acessado em 14/01/2012]
FREIRE, A. C. (2000) [online] A Interpretação dos Sonhos de Sigmund Freud,
1899/1900:
Cem
anos
de
inconsciente.
Disponível
em
http://www.comciencia.br/resenhas/sonhos.htm
[Acessado
em
15/11/2011]
FREIRE, Paulo (1983) Pedagogia do Oprimido. 13.ed. Rio de Janeiro, Paz e Terra.
Coleção O Mundo Hoje, vol. 21.
____________ (1999) Educação como prática da liberdade, Rio de Janeiro: Paz e Terra.
FREUD, Sigmund (1905) Três ensaios sobre a teoria da sexualidade. Vol. 7 - Obras
completas de Freud. Rio de Janeiro: Eduitora Imago
GADAMER, Hans G. (2008) Verdade e Método, Volume 1 São Paulo: Editora Vozes 10a edição - ISBN: 8532617875 - ISBN-13: 9788532617873
GARTNER
Research
Inc.
(2012)
Hype
Cycles
[online]
Disponível
em
http://www.gartner.com/technology/research/methodologies/hypecycle.jsp [Acessado em 23/01/2012]
GILSON, Etienne (2010) Introdução às artes do belo. São Paulo: Editora E Realizações
- 1a. edição - ISBN: 8588062976 - ISBN-13: 9788588062979
HERGAARDEN, M. (2011) Ultimate Unity Networking Project [online] M2H Game
Studio, Holanda Disponível em http://forum.unity3d.com/threads/75385Ultimate-Unity-Networking-project-Add-multiplayer-to-your-game-today
HIGINBOTHAM, W. A. (1958) Tennis for Two. Jogo eletrônico. Brookhaven National
Laboratory, Upton, New York.
HIRATA, Andrei Inoue (2011) Desenvolvendo Games com Unity 3D Rio de Janeiro:
Ciência Moderna.
Ilha Cabu (2010) [online] jogo eletrônico. Pontifícia Universidade Católica de São
Paulo.
Disponível
em:
http://www.ilhacabu.com.br.
[Acessado
em
26/01/2012].
JERZ, Dennis G. (2007) Somewhere Nearby is Colossal Cave: Examining Will
Crowther's
Original
"Adventure"
in
Code
and in
Kentucky.
Digital
Humanities Quarterly Summer 2007 Volume 1 Number 2 [online]
Disponível
em
http://www.digitalhumanities.org/dhq/vol/001/2/000009/000009.html
KAPP, K. M. (2007) Defining and Understanding Virtual Worlds [online] ASTD
website. The American Society for Training and Development. Disponível
em
:
http://www.astd.org/LC/2007/0507_kapp.htm
[Acessado
em
02/11/2011].
___________ (2009) Another proposed definition of Game
[online] ASTD website.
The American Society for Training and Development. Disponível em :
http://www.astd.org/LC/0611_kapp.htm [Acessado em 02/11/2011].
KLASTRUP, L. (2003) A Poetics of Virtual Worlds. Proceedings of Melbourne
DAC2003.
Melbourne.
http://hypertext.rmit.edu.au/dac/papers/
Disponível
Klastrup.pdf.
em:
[Acessado
em
07/09/2011].
KZero worldwide (2011) Slideshare Universe presentation, Q4 2011, 6 jan 2012.
Disponível em http://www.slideshare.net/nicmitham/kzero-universe-q42011 . [Acessado em 10/01/2012]
210
LÉVY, Pierre (1999) Cibercultura. São Paulo: Ed. 34 – 3ª edição – 2010.
LIVINGSTONE, D. (2011). “Second Life Is Dead, Long Live Second Life?” In: EDUCAUSE
Review
(46:2).
[online]
Disponível
em:
http://www.educause.edu/EDUCAUSE+Review/EDUCAUSEReviewMagazineV
olume46/SecondLifeIsDeadLongLiveSecond/226180
[Acessado
em
28/07/2011]
LONGONI, Maurício et al. (2010) Bootcamp Postmortem: Developing AAA games in
Unity 3 [online] vídeo, Unite 10 Unity Developer Conference, 10-12
novembro
de
2010,
Montreal,
Canadá.
Disponível
em
http://unity3d.com/support/resources/unite-presentations/bootcamppostmortem [Acessado em 06/09/2011]
M2H Website (2011) [online] http://www.m2h.nl [Acessado em 15/12/2011]
MANOVICH, Lev (2002) The Language of New Media Boston: MIT Press ISBN:
0262632551 ISBN-13: 9780262632553
MCGONIGAL, Jane (2010) Jane McGonigal: gaming can make a better world. [online]
TED
talks.
Disponível
em
http://www.ted.com/talks/jane_mcgonigal_gaming_can_make_a_better_wo
rld.html [Acessado em 17/01/2012]
______________ (2011) Reality is broken: why games make us better and how they
can change the world. New York The Penguin Press. ISBN 9781594202858
MORIMOTO, Carlos E. (2011) Redes: Guia Prático. Porto Alegre: Sul Editores
MURRAY, Janet H. (2003) Hamlet no holodeck: o futuro da narrativa no ciberespaço.
São Paulo. UNESP.
Myst (1993) videogame. Cyan.
Myst
Online
Uru
Live
(2012)
metaverso.
Cyan
[online]
Disponível
em
http://mystonline.com [Acessado em 28/01/2012]
OGDEN, Steve (1999) Advancing game graphics: a War of escalation. ACM SIggraph
Vol
33
n.
4
–
November
1999
[online]
Disponível
em
http://www.siggraph.org/publications/newsletter/v33n4/columns/gaming
.html [Acessado em 22/01/2012]
PETRY, Arlete S. (2009). Metaverso Ilha Cabu: relato de uma produção em processo.
in
Revista
TecCog,
número
02.
In:
http://www.pucsp.br/pos/tidd/teccogs/dossies/teccogs_n2_2009_dossie_
meta_petry_a.pdf
______________ (2010) O Jogo como condição da autoria e da produção de
conhecimento: análise e produção em linguagem hipermídia. Dissertação
de Doutorado, Pontifícia Universidade Católica de São Paulo.
PETRY, Luís C. (2001). “Traumdeutung: 100 anos de interatividade”. In: A
Interpretação dos sonhos: várias leituras. Rosa Jr, N.C & Correia, S.
(Organizadores). São Leopoldo. Editora UNISINOS. ISBN: 8574310964
___________ (2003) Topofilosofia: o pensamento tridimensional na hipermídia. Tese
de Doutorado no Programa de Pós-Graduação em Comunicação e
Semiótica. São Paulo, PUCSP
___________. (2009) Estruturas cognitivo-ontológicas dos Metaversos. Slactions
2009
Disponível
em
http://www.topofilosofia.net/textos/F_Onto_Metaverso_Port_LCPetry_002.
pdf [Acessado em 02/11/2011].
___________ (2011) Por uma ontologia dos metaversos e games. Lisboa: Revista
Comunicação & Linguagens. CECL. Volume 47 (no Prelo)
PETRY, Luís C.; BARBOSA, Pedro (2007), “AlletSator: aspectos fenomenológicos da
produção de mundos e objetos tridimensionais na Ciberópera, 1”, In Rocha,
Cleomar
Encontro
(org.),
Nacional
da
ANPAP
-
Arte
limites
e
contaminações, Anais do 15º Encontro Nacional da ANPAP, Salvador.
Photon Network Engine and Development Framework (2011) [online] Exit Games.
Disponível
em
http://www.exitgames.com/Photon
[Acessado
em
07/09/2011]
POLACK, Trent (2002) Focus On 3D Terrain Programming. Boston. Ed. Premier Press
Thomson Course Technology PTR; 2002. ISBN: 1-59200-028-2; Disponivel
em
https://www.docstoc.com/pass?download=1&doc_id=39772780
PONTUSCHKA, Maigon e PETRY, Luís C. (2011) Metaversos, construção de
conhecimento e
SBGames
mudança social:
2011,
o
caso
“Projeto
Salvador.
Pirarucu-Gente”.
Disponível
em
http://www.pirarucugente.com.br/paper_sbgames_Pirarucu_Gente.pdf
Projeto Pirarucu-Gente website, (2011) [online] Universidade Federal de Rondônia.
Disponível
em:
http://www.pirarucugente.com.br.
[Acessado
em
07/09/2011]
RABIN, Steve (2010) Introduction to Game Development – Second edition. Boston:
CENGAGE Learning.
Red
Light
Center
(2012)
metaverso
[online]
Disponível
em
http://www.utherverse.com [Acessado em 28/07/2011]
Return to Zork (1993) videogame. Infocom.
RICO, M. et al. (2009) A HighSchool Educational Platform based on VirtualWorlds
Proceedings of the 2nd Workshop on Methods and Cases on Computing
Education
[online]
Disponível
em
:
http://pt.scribd.com/doc/14226792/MCCE-2009-Proceedings
ROBERTS, Steve. Character Animation in 3D: Use traditional drawing techniques to
produce stunning CGI animationI. Amsterdam. Focal Press; Bk&CD-Rom
edition. 2004. ISBN: 0240516656;
SANCHEZ-CRESPO,
D.
(2003)
Core
Techniques
and
Algorithms
in
Game
Programming. Indianapolis, New Riders Publishing
SANTAELLA, Lucia (2001) Matrizes da linguagem e pensamento sonoro, visual,
verbal. São Paulo, Iluminuras.
_____________ (2003) Culturas e artes do pós-humano: da cultura das mídias à
cibercultura. São Paulo: Ed. Paulus, 2003
212
SCHELL, J. (2008) The Art of Game Design: a abook of lenses. Burlington, EUA:
Morgan Kaufman.
SCHLEMMER, Eliane e BACKES, L., (2008) Metaversos: novos espaços para
construção do conhecimento. [online] Revista Diálogo Educacional, Curitiba
v.8
n.
24,
519-532
maio/ago
2008.
Disponível
em:
http://www2.pucpr.br/reol/index.php/DIALOGO?dd1=2038&dd99=view
SCHLEMMER, Eliane et al. (2006) ECoDI: a criação de um espaço de convivências
digital virtual. In: SIMPÓSIO BRASILEIRO DE INFORMÁTICA NA EDUCAÇÃO,
17., 2006, Anais. Brasília:
____________ (2009). The Metaverse: Telepresence in 3D Avatar-Driven DigitalVirtual Worlds. [online] @tic. revista d’innovació educativa. (nº 2) Disponível
em
http://dialnet.unirioja.es/servlet/fichero_articulo?codigo=3083273&orden
=0 [Acessado em 07/09/2011]
SCHUYTEMA, Paul. (2008) Design de Games: uma abordagem prática. São Paulo:
Cengage Learning.
Second Life (2011) metaverso. [online] Disponível em: http://secondlife.com.
[Acessado em 27/01/2012].
SEVERINO, Antonio J. (2007) Metodologia do Trabalho Científico, 23a. edição, São
Paulo: Cortez.
Shadow of the Colossus (2005) videogame. Sony Computer Entertainment Inc.
SILVA, Josenildo S. (2009) Diagnóstico e planejamento participativo na perspectiva
de manejo sustentável dos recursos naturais e da biodiversidade Disponível
em: http://www.pirarucugente.com.br. [Acessado em 28/07/2011]
Slactions (2011) [online] Disponível em: http://slactions.org. [Acessado em
28/07/2011].
SMART, J.M., Cascio, J. and PAFFENDORF, J.(2007), Metaverse Roadmap Overview.
Accelerated
Studies
Foundation.
[online]
http://metaverseroadmap.org/inputs4.html#glossary
Disponível
em
[Acessado
em
07/09/2011].
SMED, Jouni et al. (2002) A Review on Networking and Multiplayer Computer Games
TUCS – Turku Centre for Computer Science Technical Report n. 454 – April
2002
ISBN
9521209836
[online]
http://staff.cs.utu.fi/~jounsmed/papers/TR454.pdf
Disponível
[Acessado
em
em
20/01/2012]
SOROM, T. (2010) The Year in Virtual Goods by the Numbers. TechCrunch,
December
31[online]
Disponível
em
:
http://techcrunch.com/2010/12/31/the-year-in-virtual-goods-by-thenumbers/ [Acessado em 28/12/2011].
STEPHENSON, N. (1994) Snow Crash. Viking Adult publisher, England.
______________ (2008). Nevasca. São Paulo. Editora Aleph. ISBN: 8576570548 ISBN13: 9788576570547
Tale of Tales (2005). The Endless Forest [online] jogo eletrônico. Bélgica. Disponível
em: http://www.taleoftales.com [ Acessado em 28/07/2011].
__________ (2009) The Path [online] jogo eletrônico.
Bélgica. Disponível em:
http://www.taleoftales.com. [Acessado em 28/07/2011].
The
Doom
wiki
Doom
(2011)
networking
component
[online]
http://doom.wikia.com/wiki/Doom_networking_component [Acessado em
26/12/2011]
THIOLLENT, M. (2007) Metodologia de pesquisa-ação. 15a. ed. São Paulo: Cortez.
TONÉIS, Cristiano N. (2010) A lógica da descoberta nos jogos digitais. Dissertação
(Mestrado em Tecnologia da Inteligência e Design Digital, Orientação do
Prof. Dr. Luís Carlos Petry). São Paulo. Pontifícia Universidade Católica de
São Paulo.
TURKLE, Sherry (1997) La vida em la pantalla: la construcción de la identidad en la
era de Internet. Barcelona: Paidós.
_____________(2011) Alone Together: why we expect more from technology and less
from each other. New York: Basic Books.
UNITY 3D (2011) [online] Disponível em: http://unity3d.com. [Acessado em
28/07/2011].
WARDRIP-FRUIN, N. e HARRIGAN, P. (orgs), (2004) First Person: New Media as Story,
Performance and Game, Cambridge: MIT Press.
WASKO, Molly et al. (2011) Stepping into the internet: New Ventures in Virtual
Worlds. MIS Quarterly Vol. 35 No. 3 pp. 645-652/September 2011
WILLIAMS, R. (2011). O campo e a cidade na história e na literatura. São Paulo:
Companhia das Letras.
WILSON, Tracy (2011) How MMORPGs Work [online] How Stuff Works website.
Disponível
em
http://electronics.howstuffworks.com/mmorpg.htm
WOOLLEY D.R. (1994) PLATO: The Emergence of Online Community
Disponível
em
http://thinkofit.com/plato/dwplato.htm
[online]
[Acessado
em
Disponível
em
11/12/2011]
World
of
Warcraft
(2012)
MMORPG.
Battlenet.
[online]
http://us.battle.net/wow/en/ [Acessado em 28/01/2012]
Zork: Nemesis (1996) videogame. Activision.
214
ÍNDICE DE FIGURAS
Figura 1 - SimCity 2000 .............................................................................. 9
Figura 2 - Janet Murray: autora de Hamlet no Hollodeck ............................ 11
Figura 3 - Jane McGonigal: autora de "Reality is Broken" ............................ 14
Figura 4 - Sherry Turkle: autora dos livros "Life on the Screen" e "Alone
Together" .................................................................................................. 16
Figura 5 - Metaverso Friendshangout ........................................................ 19
Figura 6 - Alletsator: um protometaverso. ................................................. 23
Figura 7 – La Ville de Tiroirs – Salvador Dalí ............................................... 33
Figuras 8a e 8b - A correlação entre o arame e a imagem. Imagem
“xicaras_4.jpg” Fonte: (PETRY 2001) ........................................................ 34
Figura 9 - A sala de James Owen - imagem renderizada – (PETRY, 2001) ... 35
Figura 10 - Alguns jogos multijogador não são jogos em rede. Este é o caso
de jogos esportivos como o Don King Boxing para o NIntendo WII. ............ 40
Figura 11 - W. Higinbotham o inventor do jogo eletrônico multiusuario
Tennis for Two. ......................................................................................... 41
Figura 12 - O osciloscópio que servia como dispositivo de saída para o jogo.
................................................................................................................. 42
Figura 13 - William Higinbotham também criou o primeiro joystick da
história por ocasião do projeto Tennis for Two. ......................................... 42
Figura 14 - O primeiro jogo de computador multiusuario foi o Spacewar do
MIT em 1961. A foto da direita mostra o mainframe em que era baseado. . 43
Figura 15 - Um terminal do PLATO V em 1981 com uma tela do Game
Empire baseado na série Jornada nas Estrelas ............................................ 45
Figura 16 - Colossal Cave Adventure: o primeiro jogo de aventura em texto
na tela de um terminal do mini-computrador PDP-10. .............................. 46
Figura 17 – Tela inicial do jogo Colossal Cave Adventure ........................... 46
Figura 18 - Tela de um dos primeiros MUDs, semelhante a Adventure e
Zork. ......................................................................................................... 50
Figura 19 - Topologia cliente/servidor básica utilizada pelos MUDs iniciais.
Os terminais eram contectados a uma rede, mas todo o processamento era
feito no servidor, um mainframe ou mini-computador. (Fonte: Armitage et
al. 2006 p.10) ........................................................................................... 51
Figura 20 - Computer Space, de 1971, foi o primeiro jogo multiusuário por
computador usado comercialmente como máquina de fliperama. .............. 52
Figura 21 - Pong - O primeiro jogo de fliperama multiusuário de sucesso 53
Figura 22 – O Atari Football para 2 jogadores e para 4 jogadores. ............. 53
Figura 23 - Tela inicial de Doom ............................................................... 55
Figura 24 - Doom foi o game multijogador em rede que deu início ao
“boom” dos jogos multijogador em rede. .................................................. 55
Figura 25 – As camadas de software e hardware do Doom, jogo multijogador
em rede baseado em uma rede Novell. ...................................................... 56
Figura 26 - As topologias possíveis utilizadas pelo Doom. (a) computadores
conectados a uma LAN Ethernet, cada um como um “peer” do Doom. (b)
computadores conectados via modem, também cada um como “peer”. ..... 56
Figura 27 - Capa do SimCity Classic de 1989 ............................................ 57
Figura 28 - Aspecto do Sim City Classic .................................................... 58
Figura 29 - As capas do SimCity 2000 e SimCity 2000 network edition ..... 60
Figura 30 - No SimCity 2000 a sensação de tridimensionalidade foi
aperfeiçoada em relação ao SimCity I ........................................................ 61
Figura 31 - Capa de Return to Zork ........................................................... 63
Figura 32 Em Return to Zork era possivel utilizar diferentes tons de humor
para falar com as personagens e obter informações. ................................. 64
Figura 33 - Capa de Zork Nemesis ............................................................ 65
Figura 34 - Momento mais chocante de Zork Nemesis: cortar a cabeça de
um cadáver e fazê-la falar. ........................................................................ 67
Figura 35 - Myst (1993) ............................................................................ 68
Figura 36 - Myst Online Uru Live: um metaverso pleno.............................. 69
Figura 37 - Second Life - o metaverso mais conhecido ............................. 74
Figura 38 - World of Warcraft - MMORPG de maior sucesso ...................... 77
Figura 39 – Dados de janeiro de 2012 com o total de contas registradas em
mundos virtuais por idade em milhões. Fonte: Kzero Worldwide................ 79
Figura 40 - Prognóstico dos lucros dos mundos virtuais. Fonte Kzero
Worldwide ................................................................................................. 80
Figura 41 - Média de visitantes ao Second Life por semana de maio de 2006
a dezembro de 2011 Fonte: Dwell on it website (2012) ........................... 80
Figura 42 - Metodologia dos Hype Cycles da Gartner Research Inc. ........... 81
Figura 43 - Hype Cycle de Tecnologias Emergentes de Julho de 2011 Gartner Research ....................................................................................... 83
Figura 44 - Modelo de referência OSI da ISO - Fonte: (RABIN, 2010, p.608)
................................................................................................................. 92
Figura 45 - As arquiteturas de comunicação possíveis para jogos
multijogador: a) somente um computador utilizado por todos os jogadores
e tela b) peer-to-peer c) cliente-servidor d) híbrido de peer-to-peer e
cliente-servidor e) rede de servidores. (Fonte: ARMITAGE et al. 2006 p.16) 98
Figura 46 - Aspecto da tela do Tutoria1 1 de Hergaarden mostrando um
servidor desconectado e depois conectado como servidor. ...................... 102
Figura 47 - Tutorial 2A1 em funcionamento. A janela da esquerda está com
o servidor conectado. A da direita e a inferior estão com clientes
216
conectados. Quando a janela do servidor está selecionada podemos
movimentar o cubo com as setas do teclado. As janelas dos clientes
acompanham a movimentação do cubo no servidor. ................................ 105
Figura 48 - No mesmo contexto da figura anterior, o cliente que estava na
janela inferior foi desconectado. Neste caso, somente o cliente que continua
conectado (direita) acompanha a movimentação do cubo do servidor
(esquerda). .............................................................................................. 107
Figura 49 - Na tab “inspector” do Unity definimos como deve ser o estado
da sincronização da comunicação de dados com a rede via Network View
para
um
dado
objeto.
As
opções
disponíveis
são
“reliable
delta
compresssed”, “unreliable” e “off”. ........................................................... 107
Figura 50 - Tela do jogo multijogador em rede “CrashDrive 3D”. Depois de
feita a conexão com um servidor o chat aparece no canto inferior esquerdo.
............................................................................................................... 124
Figura 51 - Um servidor mestre consiste em uma interface que mostra uma
lista com grupos de clientes que estão conectados a um mesmo servidor. Os
servidores são, na verdade, as salas de jogos disponíveis. Casa “sala” mostra
a quantidade de jogadores alocados em cada uma e quantas pessoas no
total podem participar de cada uma delas. .............................................. 124
Figura 52 - Menu do servidor master do game “Surrounded by death”. .... 127
Figura 53 - Aspecto do GUI do servidor master do jogo “Surrounded by
Death”, mostrando um servidor já com 2 jogadores à espera. .................. 128
Figura 54 - O lobby do ponto de vista do criador do servidor. O jogador que
cria a sala determina qual é o número máximo de participantes e tem a
autoridade para começar o jogo quando desejar. .................................... 129
Figura 55 - O lobby do ponto de vista de um dos jogadores que aguarda o
início do jogo. ......................................................................................... 129
Figura 56 - Jogo multijogador sem tela inicial de configuração e alocação de
servidor. .................................................................................................. 131
Figura 57 - Site da Exit Games com o seu carro chefe, o Photon. ............. 133
Figura 58 - Arquitetura de alto nível do Photon. ...................................... 135
Figura 59 - Conjunto de arquivos do Photon 3 - SDKs de servidor e de
clientes e licenças de uso ........................................................................ 139
Figura 60 - É necessário definir o diretório onde o Photon deverá ficar em
seu computador. ..................................................................................... 139
Figura 61 - O conteúdo do pasta "deploy". .............................................. 140
Figura 62 - O arquivo Photon Control.exe instala o Photon. .................... 140
Figura 63 - O menu de controle do Photon 3.0. ....................................... 141
Figura 64 - O Testclient em funcionamento, simulando 100 jogadores em
25 jogos. ................................................................................................. 141
Figura 65 - Os logs do Photon. ............................................................... 142
Figura 66 - Página de download do Photon Viking Demo. ....................... 143
Figura 67 - Janela de conexão com o Photon Cloud por meio de uma APP ID.
............................................................................................................... 144
Figura 68 - Interface inicial do Photon Viking Demo ................................ 144
Figura 69 - Experimento com o Photon Viking Demo .............................. 145
Figura 70 - Página de download do Photon Bootcamp FPS Demo ............. 146
Figura 71 - O menu do Photon 2.6 é ligeiramente diferente do da versão 3.0
............................................................................................................... 147
Figura 72 - Interface de escolha de nome e de entrada de sala no Photon
Bootcamp Demo ...................................................................................... 147
Figura 73 - Teste com o Photon Bootcamp Demo com três jogadores ..... 148
Figura 74 - Teste da ilha básica do Unity com Photon ............................. 148
Figura 75 - Mensagens de atualização da Island Demo para a versão do
Unity 3.4 ................................................................................................. 149
Figura 76 - Mensagens de erro do compilador do Unity 3.4 para o Island
Demo ...................................................................................................... 150
Figura 77 - Teste da ilha básica do Unity com Photon e três jogadores
simultâneos ............................................................................................ 151
Figura 78 - O Game Acadêmico Ilha Cabu ............................................... 154
Figura 79 - Mapa da Ilha Cabu ................................................................ 157
Figura 80 - Parametrização do puzzle da canoa na Ilha Cabu .................. 162
Figura 81 - Fluxograma do puzzle da canoa. .......................................... 163
Figura 82 - As fases do jogo Bootcamp como planejadas inicialmente .... 165
Figura 83 - Story boards são importantes para o planejamento ............... 166
Figura 84 - A palheta de cores na linha do tempo do jogo Bootcamp ...... 167
Figura 85 - Do lado esquerdo estão as fotos de lugares reais. Do lado
direito, os ambientes de Bootcamp.......................................................... 168
Figura 86 - A semelhança entre a foto original e os ambientes recriados é
notável. ................................................................................................... 168
Figura 87 - Correlacionar cada objeto com o local onde estará dentro do
jogo para criar um nível de jogo .............................................................. 169
Figura 88 - Composição que usa a perspectiva com um ponto focal........ 170
Figura 89- Utilização de proporções divinas e regra dos terços na
composição ............................................................................................. 171
Figura 90 - A chaminé dá a sensação do inalcançavel em Bootcamp........ 172
Figura 91 – O edifício em Half-Life 2 e a Death Mountain em Legends of
Zelda....................................................................................................... 172
Figura 92 - Dicas para a criação de vegetação realista............................. 174
Figura 93 - Temperaturas de cor e sensações que provocam .................. 175
Figura 94- Contraste produzido com as sobras ....................................... 176
218
Figura 95 - Primeiro teste de navegação em terceira pessoa. À direita está o
mapa do terreno...................................................................................... 183
Figura 96 - Aspecto do terreno da Versão 0.3 ......................................... 184
Figura 97 - O Território da Cidadania Central em Rôndônia................... 188
Figura 98 - Primeiras fotos para o levantamento de referências mostrando
castanheiras, buritis e aspectos da região................................................ 189
Figura 99 - Mapa político do Território Central da Cidadania e fotos de
satélite do Google Maps exatamente da mesma região e na mesma escala
............................................................................................................... 191
Figura 100 - Processo de elaboração do terreno da versão 0.4 ................ 191
Figura 101 - Participantes do Projeto marcando as localidades das suas
entidades no mapa .................................................................................. 192
Figura 102 - Estudo da distribuição da vegetação ................................... 193
ÍNDICE REMISSIVO
3D, 1, 2, 3, 8, 11, 20, 21, 22, 23,
Bootcamp, 146, 147, 148, 152,
24, 25, 34, 36, 37, 39, 61, 67,
153, 164, 167, 168, 169, 171,
69, 100, 101, 124, 133, 148,
172, 173, 174, 184, 200, 209
149, 181, 184, 188, 189, 192,
broadcast, 57, 99
196, 206, 208, 210, 211, 212
Brøderbund, 59
Activision, 65, 66, 212
buffer, 96, 111, 121
Adventure, 46, 47, 48, 49, 50, 208
buffering, 96
agência, 11, 24, 61, 63, 75, 76,
Bushnell, Nolan 51, 52
198
Camada de Aplicação, 96
agricultores, 4, 5, 6, 181, 184,
185, 186
Camada de Apresentação, 95
Camada de Enlace de dados, 93
Agroecologia, 5
Camada de Rede, 93
Alletsator, 23, 25
Camada de Sessão, 94
Alone Together, 17, 199, 212
Camada de Transporte, 93
alternate reality games, 15, 199
Camada Física, 92
ambientes virtuais, 2, 18, 34, 35,
chat, 20, 43, 44, 49, 123, 124,
75
128, 130, 187
apontar-e-clicar, 64, 67
ciberespaço, 1, 7, 16, 18, 26, 28,
Apple II, 49
31, 32, 71, 72, 209
Aquiris, 152, 164, 200
ciência da computação, 8
game studio, 146, 153
Ciências Exatas, 16
Arcade Games, 51
Ciências Humanas, 16
Aristóteles, 28, 29
Commodore 64, 49, 57
Arlete Petry, (ver Petry, Arlete)
compressão de dados, 90, 95
ARPAnet, 47, 91
Computer Space, 51, 52
arquitetura
cliente-servidor,
51,
98, 99
arquitetura híbrida, 99
Asimov, Isaac, 27
assessoria técnica rural, 5, 6
Asset Store Unity, 101, 143
conhecimento, 2, 3, 4, 27, 28, 31,
181, 209, 211
controlador de terceira pessoa,
143
criação conceitual, 6, 8, 153, 156,
157, 161, 188, 198, 200
Atari, 44, 49, 52, 53, 97
criptografia, 95
avatares, 2, 3, 4, 11, 19, 22, 28,
Crowther, Will, 47, 208
45, 63, 74, 75, 185, 187, 188
Bairon, Sérgio 38, 155, 158, 201,
206
biblioteca virtual, 3
boas práticas, 5, 6, 186, 187, 189
Boole, 37
Demo Plays, 70
Descartes, René 26, 207
Design de Jogo, 200
Deterco e Alcântara, 21, 23
220
Diesel, Amilton, 164, 165, 166,
169, 171, 173
games, 1, 2, 3, 7, 8, 11, 13, 15,
17, 23, 25, 26, 28, 30, 32, 39,
dispositivos móveis, 3, 21, 133
43, 44, 45, 46, 47, 49, 50, 58,
DnD, 44, 50
65, 66, 67, 69, 70, 75, 87, 92,
Doom, 17, 45, 55, 56, 57, 69, 70,
96, 101, 122, 124, 133, 143,
71, 72, 212
DUNGEN, 48, 49
146, 153, 154, 160, 180, 185,
186, 187, 206, 209, 210
Dungeons & Dragons, 44
games multijogador, 39
educação a distância, 2
games em rede, 8, 40, 199
Empire, 44, 45, 49
Games for Change, 12, 15, 204
encriptação de dados, 96
games imersivos, 28
End User License Agreements, 87
games multijogador, 7, 40, 198,
engines, 30, 180
Entropia Universe, 24, 25
204, 207
espaço navegável, 11, 18, 25, 68,
71
199, 200
games multijogador em rede, 7, 8,
92, 198
Gartner Inc., 80, 81, 82, 83, 208
God Games, 61
estatísticas, 7, 78, 80
GPS, 21
Ethernet, 56, 57, 93
GUI, 102, 103, 125, 128
etimologia, 2, 19
Heidegger, 30, 31, 32
eu virtual, 13
Heim, Michael, 26, 28, 31
EULAs, 87
Hergaarden, M. 100, 101, 102,
Everquest, 45
104, 108, 109, 111, 118, 119,
Exit Games, 133, 134, 138, 142,
122, 123, 126, 127, 130, 131,
143, 146, 147, 200, 202, 207,
210
fenomenologia, 31, 32
ficção científica, 2, 18, 27, 74
133, 134, 142, 200, 202, 208
hermenêutica, 30, 31, 32
Higinbotham, William 41, 42, 52,
208
FINEP, 1
hiperlink, 39
first person shooters, 45, 133,174
hipermídia, 33, 38, 39, 209
fluxogramas, 159
hipertexto, 38, 39
Football, 53, 97
Hype Cycle, 80, 81, 82, 83
FPS, 45, 55, 111, 113, 130, 142,
ID Software, 55
146
identidade, 13, 16, 34
Freire, Paulo, 5, 180
identidades, 13, 17, 74
Freud, Sigmund 33, 36, 37, 207
Ilha Cabu, 23, 25, 153, 154, 155,
Game Design Document, 8, 153,
182, 200
gamers, 11, 12, 14, 15, 83
156, 158, 159, 160, 161, 162,
200, 202, 208, 209
iluminação, 81, 82, 173, 175, 176
imersão, 11, 21, 24, 34, 62, 63,
67, 68, 75, 76, 160, 161, 184,
198, 202, 204
informática, 3, 6, 186
Institute for the Future, 15, 20
interativo, 21, 25, 71
internet, 2, 3, 11, 16, 18, 21, 38,
39, 44, 55, 78, 92, 103, 136,
147, 212
IPX, 55
185, 186, 187, 188, 192, 206,
210
Metaverso, 8, 19, 25, 153, 182,
183, 185, 186, 187, 209, 210
Metaverso do Projeto Pirarucu, 8,
203
Metaverso Pirarucu Gente, 204
Metaverso
Pirarucu-Gente,
185,
198, 200, 204, 205
metaversos, 2, 3, 4, 6, 7, 8, 10,
Island Demo, 148, 149
11, 13, 16, 17, 18, 20, 21, 22,
jogadores simultâneos, 54, 73,
23, 24, 25, 26, 27, 28, 30, 31,
128, 145, 146, 151, 190
32, 39, 41, 49, 55, 60, 63, 74,
jogos eletrônicos, 1, 7, 39, 40, 51
75, 78, 82, 83, 86, 87, 88, 89,
KZero Worldwide, 78, 79, 80, 84,
100, 124, 153, 154, 180, 185,
85
lag, 114, 117
187, 198, 199, 200, 201, 202,
203, 204, 210
Leibniz, 26, 27, 31
mipmaps, 174
Lévy, Pierre 18, 19, 208
MIT, 43, 47, 160, 177, 209, 212
licença do Photon, 136
MMO, 24, 137, 142, 143, 148,
Life on the Screen, 15, 199
linguagem, 6, 27, 30, 31, 34, 37,
38, 49, 180, 186, 209, 210
linguagem elétrica, 27, 31
Link direto, 90
204
MMORPG, 24, 74
MMORPGs, 17, 45, 67, 73, 74, 75,
77, 86, 199, 204, 212
MMOs, 2, 8, 12, 17, 39, 67, 73,
lobby, 125, 127, 128, 129, 130
75, 77, 133, 134, 142, 143,
M2H, 101, 105, 108, 110, 112,
199, 200, 204
113, 114, 123, 126, 131, 208,
modelagem, 173
209
modelo de atualização, 97
mainframe, 40, 43, 44, 45, 51
modelo OSI, 7, 91, 92
Manovich, Lev 18, 69, 70, 71, 72,
Modelo OSI, 91, 92, 200
209
Master server, 124
modelos de comunicação, 7, 89,
100
Maxis, 9, 58, 59
Modelos de conexão, 97
McGonigal, Jane 12, 13, 14, 15,
mônadas, 27, 31
185, 198, 201, 203, 204, 209
monojogador, 25
Metafísica, 29, 207
morphing, 37, 76
Metaverse Worldmap, 20, 22
MUD, 49
metaverso, 2, 3, 4, 6, 8, 17, 18,
MUDs, 13, 16, 17, 45, 46, 49, 50,
19, 20, 21, 23, 24, 27, 28, 30,
69, 74, 89, 100, 133, 153, 181,
51, 68, 74, 99, 199
222
multijogador, 4, 6, 7, 8, 15, 22,
palheta de cores, 166, 167
23, 24, 25, 39, 40, 41, 43, 44,
Paulo Freire, 5, 180
51, 52, 53, 54, 56, 57, 89, 92,
PDP-10, 48, 49
97, 98, 100, 101, 113, 123,
peers, 56, 57, 98, 99
124, 125, 127, 130, 131, 132,
peer-to-peer, 56, 98, 99
133, 134, 142, 143, 146, 147,
pescadores, 4, 5, 6, 180, 181,
149, 185, 186
multiusuário, 2, 4, 23, 24, 25, 41,
43, 44, 50, 52, 53, 101
mundo real, 4, 10, 12, 13, 15, 17,
19, 21, 22, 23, 24, 25, 32, 33,
63, 75, 78, 88, 181, 185, 186
mundos virtuais, 1, 7, 10, 13, 15,
17, 18, 21, 23, 24, 25, 33, 62,
63, 73, 78, 79, 80, 82, 83, 86,
87, 185
Murray, Janet 4, 11, 17, 32, 61,
62, 72, 75, 76, 77, 198, 203,
209
184, 186, 190
pesquisa-ação, 3, 4, 5, 8, 177,
178, 179, 180, 212
pesquisa-ação participativa, 3, 4,
5, 179, 200
Petry, Arlete 153, 154, 155, 156,
157, 158, 159, 160, 161, 201,
202, 209
Petry, Luís C. 2, 3, 18, 23, 26, 27,
28, 29, 30, 31, 32, 33, 34, 35,
36, 37, 38, 153, 206, 209, 210,
212
Photon, 100, 133, 134, 135, 136,
Myst, 17, 25, 64, 65, 67, 68, 69,
137, 138, 139, 140, 141, 142,
70, 71, 72, 199, 200, 204, 209
143, 144, 145, 146, 147, 148,
Myst Online Uru Live, 25, 69, 199,
200, 204, 209
149, 151, 153, 190, 200, 210
Pirarucu-Gente, 6, 8, 153, 154,
navegador, 20, 151
155, 181, 182, 183, 185, 186,
Nemesis, 17, 65, 66, 67, 212
187
Network Address Translation, 103
piscicultores, 4, 6, 180, 181, 186
Network View
Platão, 29
Unity 3D, 105, 106, 107, 108,
PLATO, Sistema, 43, 44, 45, 46,
109, 115, 118
49, 212
Neuromancer, 18
Playstation, 1
novas tecnologias, 18, 33, 185
Pong, 52, 53, 97
NPCs, 24, 28, 65
pontos fortes, 13
objeto, 30, 34, 35, 37, 39, 64, 65,
problematização, 5
70, 104, 106, 108, 112, 115,
117, 118, 123, 178, 180
ontologia, 28, 29, 31, 207, 210
ontológica, 18, 26, 27, 28, 29, 31,
32
Projeto Pirarucu-Gente, 3, 4, 6, 8,
15, 179, 180, 181, 184, 186,
188, 200, 210
proporções divinas, 170, 171
protometaversos, 7, 23
pacote de dados, 56, 89
protótipo, 51, 183, 184
pacote de rede, 90
puzzle, 50, 159, 160, 162
puzzles, 47, 50, 64, 65, 66, 68, 69
Spacewar, 43, 51
realidade aumentada, 20
spawn, 111, 114, 115
rede
Stephenson, Neal, 2, 19, 20, 211
games em rede, 39
storyboard, 165
redes, 1, 2, 6, 7, 18, 55, 57, 89,
streaming, 96
98, 100, 104, 134, 198, 200
Redes
com
comutação
Superstruct, 15
de
circuitos, 90
Redes com comutação de pacotes,
90
tablets, 21
TCP
protocolo, 45, 93
TCP/IP, 55, 92, 200
regras de composição, 169, 170
Telnet, 45, 51
Remote Procedure Calls, 109
Tennis for Two, 41, 42, 208
Right, Willl, 58, 59
Testclient, Photon 141
Russell, Steve, 43
texturas, 34, 167, 169, 173, 174,
Santaella, Lúcia, 38, 210
SDK, 134, 136, 138, 139, 141,
149
Second Life, 2, 24, 25, 78, 80,
188, 207, 209, 211
servidor autorizador, 114, 116,
117, 130
servidor master, 127, 128, 130
servidor mestre, 99, 122, 124,
125, 127, 128, 129, 132
175
third person shooters, 174
topofilosofia, 7, 23, 30, 34, 210
topologia, 23, 56, 71, 92
Topologia cliente/servidor, 51
topologia de rede, 56
transformação, 11, 15, 24, 37, 62,
63, 75, 76, 78, 106, 108, 198
tridimensional, 1, 21, 30, 31, 34,
35, 36, 37, 38, 180, 209
servidor não autorizador, 130
TRS-80, 49
Servidores autorizadores, 113
Turkle, Sherry 1, 13, 15, 16, 17,
Shadow of the Colossus, 24, 25,
211
SimCity, 9, 10, 11, 17, 57, 58, 59,
60, 61, 62, 63
sincronização, 7, 90, 95, 97, 106,
107
Sistema PLATO, 43
50, 199, 212
Tutorial, 102, 103, 104, 105, 106,
107, 108, 109, 110, 111, 112,
113, 114, 115, 117, 118, 119,
123
UDP 93, 94, 135, 138
Unity, 8, 89, 100, 101, 102, 104,
smartphones, 21
105, 106, 107, 108, 109, 110,
Snow Crash, 2, 19, 211
112, 113, 114, 116, 122, 123,
Sockets, 94
124, 126, 133, 142, 143, 145,
socket-server, 133, 134
146, 148, 149, 151, 153, 154,
Socket-Server, 200
162, 183, 184, 208, 209, 212
Software Development Kit, 134
universo digital, 7, 28
sonho, 26, 33, 34, 35, 36, 37, 38,
usuários concomitantes, 136, 147
207
224
vegetação, 174, 183, 184, 188,
192
Wiki, 14, 40
William Gibson, 18
vetores, 1, 21, 34
Woods
vida real, 2, 10, 11, 12, 13, 16,
Don, 47
180
videogame, 12, 52, 209, 210, 211,
212
World of Warcraft, 13, 14, 17, 45,
74
World Without Oil 15, 203
videogames, 7, 12, 13, 77
WoW, 13, 14, 25, 199
Viking Demo, 142, 143, 144, 145
Zeug, 31
vitória épica, 14
Zork, 17, 46, 47, 48, 49, 50, 63,
web 1.0, 39
web 2.0, 39, 70, 204
Wii, 1, 40, 97
64, 65, 66, 67, 206, 210, 212
Zork Nemesis, 199
ANEXOS
226

Untitled

Transcrição

Documentos relacionados

GAME DA RESPONSABILIDADE SOCIAL FAMATH

PDF document Portuguese Version

brilhantemente ganho pelos Pittsburgh Steelers, lembrei-me

Projeto Primeira Habilitação: Desenvolvimento de Jogos

Guitar Hero 5 para Xbox 360 Geral • Modo de

jogos de azar - Juegos Miami

Amigos no mundo virtual, brasileiros se encontram na

Ambiente de Ensino de Química Orgânica Baseado em Gamificação

Boas Férias Poucos mas bons

Êxito de Veloso e Djaló será... o do Sporting!!!