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. Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 3 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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 5 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. Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 7 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! Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 9 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. Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 11 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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 13 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”. Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 15 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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 17 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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 19 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.” Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 21 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 e Jogos Digitais Multijogador | Maigon Pontuschka | 23 “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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 25 é 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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 27 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. Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 29 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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 31 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. Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 33 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) Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 35 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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 37 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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 39 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. Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 41 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. Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 43 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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 45 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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 47 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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 49 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. Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 51 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. Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 53 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. Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 55 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). Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 57 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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 59 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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 61 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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 63 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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 65 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. Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 67 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. Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 69 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) Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 71 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. Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 73 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. Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 75 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. Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 77 “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. Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 79 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: Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 81 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. Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 83 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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 85 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. Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 87 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. Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 89 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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 91 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. Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 93 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. Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 95 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. Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 97 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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 99 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. Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 101 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, Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 103 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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 105 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. Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 107 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 /* 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. */ function Update(){ if(Network.isServer){ //Only the server can move the cube! var moveDirection : Vector3 = new 1*Input.GetAxis("Vertical"), 0,Input.GetAxis("Horizontal")); var speed : float = 5; transform.Translate(speed * moveDirection * Time.deltaTime); } } Vector3(- Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 109 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: /* 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 private var lastPosition : Vector3; function Update(){ if(Network.isServer){ //Only the server can move the cube! var moveDirection : Vector3 = new 1*Input.GetAxis("Vertical"), 0,Input.GetAxis("Horizontal")); var speed : float = 5; transform.Translate(speed * moveDirection * Time.deltaTime); 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. Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 111 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: /* 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. */ 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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 113 "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: /* 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. */ 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")); var speed : float = 5; transform.Translate(speed * moveDirection * Time.deltaTime); } } 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 /* 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. */ 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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 115 //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 } function OnPlayerDisconnected(player: NetworkPlayer) { 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 Network.RemoveRPCs(player); Network.DestroyPlayerObjects(player); } function OnDisconnectedFromServer(info : NetworkDisconnection) { 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; if(Network.isServer){ //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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 117 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); var speed : float = 5; transform.Translate(speed * moveDirection * Time.deltaTime); } } @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); var speed : float = 5; transform.Translate(speed * moveDirection * Time.deltaTime); } 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. Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 119 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); Network.RemoveRPCs(player); Network.DestroyPlayerObjects(player); Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 121 } //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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 123 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: /* 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 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. Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 125 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 } (...} Código completo disponível somente na Asset store da Unity – Ultimate 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 /* 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 Awake(){ //RE-enable the network messages now we've loaded the right level Network.isMessageQueueRunning = true; if(Network.isServer){ 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(); } } } function OnDisconnectedFromServer(info : NetworkDisconnection) { if (Network.isServer) { Debug.Log("Local server connection disconnected"); }else { if (info == NetworkDisconnection.LostConnection) Debug.Log("Lost connection to the server"); else Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 127 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); } function OnPlayerDisconnected(player: NetworkPlayer) { 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. Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 129 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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 131 ● 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. Código completo disponível somente na Asset store da Unity – Ultimate 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; } } } Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 133 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. Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 135 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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 137 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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 139 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. Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 141 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/ Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 143 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. Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 145 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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 147 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. Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 149 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, Terrain.activeTerrain.terrainData); Linha 31: Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 151 UnityEditor.TerrainLightmapper.UpdateTreeColor(tex, Terrain.activeTerrain.terrainData); Modificação: // UnityEditor.TerrainLightmapper.UpdateTreeColor(tex, Terrain.activeTerrain.terrainData); 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: Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 153 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”. Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 155 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.” (PETRY, Arlete, 2010, p. 215) 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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 157 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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 159 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; Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 161 “- 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.” (PETRY, Arlete, 2010, p. 236) 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. Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 163 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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 165 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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 167 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. Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 169 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). Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 171 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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 173 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. Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 175 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. Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 177 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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 179 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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 181 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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 183 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. P ROTÓTIPO V ERSÃO 0.2 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 P ROTÓTIPO V ERSÃO 0.3 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. P ROTÓTIPO V ERSÃO 0.4 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, Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 185 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. Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 187 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). Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 189 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. Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 191 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. Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 193 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. Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 195 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. Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 197 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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 199 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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 201 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. Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 203 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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 205 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. Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 207 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 [Acessado em 20/01/2012] 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. [Acessado em 28/07/2011] 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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 209 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 [Acessado em 06/09/2011] 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 [Acessado em 19/01/2012] 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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 211 ___________. (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 [Acessado em 07/09/2011] 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 [Acessado em 27/01/2012] 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 [Acessado em 13/11/2011] 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 [Acessado em 07/09/2011] 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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 213 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 [Acessado em 07/09/2011] 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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 215 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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 217 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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 219 Í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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 221 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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 223 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 Metaversos e Jogos Digitais Multijogador | Maigon Pontuschka | 225 ANEXOS 226