já faz algum tempo que começamos uma série de posts sobre a entrevista feita com a equipe de desenvolvimento do Super Mário Bros. Retomando essa série, vejam que interessante a abordagem utilizada na época para a função de projeto de níveis e a gigante preocupação e importância que teve que ser dada para a falta de memória e limitações do hardware existente na época.

Então… vamos lá!

O projeto de níveis em conjunto

Tezuka: Não estamos falando de um game show sobre compras, mas precisamos impor limites no game. Os novos colaboradores não tem bom senso para trabalhar com limites.

Iwata: Nos dias de hoje, se alguém pede para você fazer algo com 30 bytes de memória, você não consegue fazer nada. Mas naquele tempo, era possível. “Uau, são mais 10 objetos no game!” (Risos)

Miyamoto: Nós gostávamos… Isso não nos abalava.

Tezuka: É isso aí!

Iwata: Tezuka, você entrou para o time como um artista. Você gostava de todas essas restrições tecnológicas também?

Tezuka: Era realmente divertido. Eu havia acabado de entrar para a companhia e ficava sempre perguntando quais eram as restrições que tínhamos para desenvolver o projeto.

Iwata: Isso foi divertido para mim também. Na época, eu ficava muito feliz quando alguém chegava para mim e dizia: – Estou com problemas porque não há memória suficiente. Isso fazia com que o programador se destacasse resolvendo este tipo de situação.

Miyamoto: Se nós deixássemos para o Iwata resolver, ele resolveria.

Iwata: Eu gostava do jeito que eu trabalhava.

Nakago: (Folheando alguns documentos) Por exemplo, este castelo foi assim.

Nakago: No início o castelo é pequeno. No final da fase, o castelo é grande. Mas se pararmos para analisar o castelo é o mesmo. Usamos muito reaproveitamento de códigos.

Tezuka: Na verdade, o que fizemos foi pegar o topo do castelo grande que já estava pronto e colocamos ele no início como um castelo pequeno.

Nakago: Se olhar atentamente para o andar superior, vai ver que tem uma porta, mas para nós aquilo é uma janela. (risos)

Iwata: (risos)

Nakago: Estávamos sempre pensando em alternativas de viabilizar o game.

Iwata: O objetivo era fazer o game ficar muito rico com pouca quantidade de dados pois nossa memória era muito limitada.

Nakago: Suamos muito para fazer muito com pouco espaço de memória.

Iwata: Nakago, você começou a fazer o Super Mario Bros e implantou vários artifícios chaves de jogos anteriores. Qual foi o ponto que você acha que realmente seria inovador?

Nakago: Quando fizemos o plano de fundo do game.

Iwata: Quando trocaram o fundo preto para o céu azul?

Nakago: Sim!

Miyamoto: (Pegando um folheto de planejamento) Aqui está.

Nakago: Oh… lá está o Mario.

Iwata: Tezuka, foi você que desenhou este draft?

Tezuka: Eu acho que foi o Miyamoto.

Iwata: Miyamoto, foi você?

Miyamoto: Eu desenhei isso? Hum… Sim, fui eu. Eu assinei este draft.

Iwata: (Olhando para a data) Está assinado em 28 de fevereiro de 1985, apenas uma semana depois das primeiras especificações.

Miyamoto: Não é que eu trabalho rápido mesmo? (risos)

Iwata: (risos)

Miyamoto: No canto direito superior tem uma paleta de planejamento de cores. Usamos muito isso para trabalhar as cores dos objetos semelhantes.

Iwata: A vegetação e as nuvens são feitas com um mesmo objeto apenas trocando as cores.

Miyamoto: Tudo isso em função das restrições de capacidade do hardware que estavamos usando na época – Famicom.

Iwata: Foi um grande quebra-cabeça fazer o Super Mario Bros.

Miyamoto: Foi divertido fazer.

Nakago: Com certeza foi.

Miyamoto: Foi divertido para nós fazer o game. E, o projeto de níveis ficou interessante para os jogadores. Os níveis de dificuldade ficaram divertidos.

Iwata: Quem projetou os níveis?

Miyamoto: Tezuka e eu.

Tezuka: Nós projetamos em conjunto.

Miyamoto: E mais ninguém. Fomos nós dois.

Nakago: É verdade, foram somente eles.

Miyamoto: Projetamos todos os níveis em conjunto usando traços das nossas personalidades. Incorporamos isso no projeto de níveis para que ficasse interessante.

Iwata: Tezuka, o que você tinha em mente na época sobre o posicionamento de inimigos? Mesmo 25 anos depois, todos reconhecem que o posicionamento dos inimigos no game é algo muito interessante. Como esse mapeamento foi feito?

Tezuka: Hum…

Iwata: “Por acaso” (risos)

Tezuka: Não foi por acaso. (risos) Eu projetava um nível, simulava como o jogador iria jogar e as possibilidades que ele tinha e mostrava para o Miyamoto.

Iwata: Entendi!

Tezuka: Eu pensava: “O jogador vai provavelmente fazer isso aqui. Quando um inimigo aparecer aqui o jogador vai correr dessa forma. Mas ele pode bater a cabeça do Mario aqui se for fazer aquilo. …” Então íamos consertando o que não estava bom.

Iwata:  Tezuka, você comentou sobre alguns mapas que o Miyamoto fez. Certo?

Tezuka: Eu?

Miyamoto: (risos)

Iwata: Ou foi o Miyamoto – o mestre? Não lembro.

Tezuka: Ele era o mestre. Naquela época só era possível ver a versão do trabalho uma vez por dia.

Iwata: Ah, sim. Essa era outra restrição do projeto. Na época não tínhamos todas as ferramentas que temos hoje e não podíamos testar a cada item novo inserido no game. Então montávamos um mapa de tudo no papel primeiro.

Tezuka: Quando me perguntasse, achei realmente que eu tinha feito isso.

Iwata: Desculpe. (risos)

Miyamoto: O trabalho era duro!

Fim da parte 4

Então pessoal, o que acharam? Não tem como negar que a criatividade faz milagres. Quando maiores as limitações, mais criativo o game developer deve ser. Quais seriam as maiores limitações que encontramos hoje? São as mesmas de antigamente? Comentem …

fonte:Entrevista Iwata_asks Mario 25th

Trago hoje a terceira parte da entrevista com o time de desenvolvedores orginais de Super Mario Bros. Nesta parte da entrevista é interessante perceber as dificuldades que a equipe passava com o hardware da época, e as soluções mágicas que cada um encontrou para criar o que se tornaria um marco dos games.

Parte 3  – O ponto culminante

Iwata - Miyamoto, você poderia nos dizer como a história de 25 anos de Super Mario Bros começou?

Miyamoto - Claro que sim. Cerca de dois anos antes de Super Mario Bros, eu fiz uma versão arcade do Mario Bros, mas a tela não rolava, o fundo era preto, e uma espécie de planície. Então eu decidi testar algo como Mario Bros, mas que rolava, tinha um fundo brilhante e personagens maiores em movimento.

Iwata – Foi isso que você mencionou anteriormente, a versão de teste com o quadrado em movimento.

Miyamoto - Certo. Acho que foi um quadrado, mas de qualquer maneira, foi uma simples imagem. Eu queria que a tela pudesse rolar, assim, eu desisti de um jogo para dois jogadores.

Iwata - Oh, Eu sei. Duas pessoas poderiam desfrutar de jogar Mario Bros, mas não deslocar-se lateralmente simultâneamente. Não com a tecnologia daquela época.

Miyamoto - Certo. Mas, em Devil World, já havíamos alcançado alguns bons resultados.

Iwata - Em outras palavras, você trouxe a tecnologia de rolagem parcial de Excitebike, o que permitiu-lhe deslocar uma parte da tela. E a tecnologia de dois personagens de Devil World.

Miyamoto - Certo. Foi uma combinação de elementos dos jogos anteriores.

Nakago - Mais detalhadamente, os membros SRD que tinham feito, por exemplo, os Pula-pulas em Donkey Kong Jr., foram também participação importante no projeto Super Mario Bros.

Iwata - Olhando para essas especificações, elas dizem, “Adicionar refinamentos focando em encostas de Donkey Kong, elevadores, esteiras e escadas; cordas de Donkey Kong Jr, troncos, molas, inimigos de Mario Bros, plataformas congeladas e blocos de POW“.

Miyamoto - Então… realmente foi um ponto culminante de outros jogos. Foi um ano antes do Disk System e nós pretendíamos que ele fosse o último jogo lançado em um cartucho. Eu queria colocar o máximo possível de inteligência para fazer as pessoas pensarem e causar um … “Como eles fizeram isso?”

Iwata - Dado o poder global dos jogos de consoles atuais, nós podemos mostrar qualquer coisa, por isso só um profissional pode olhar para um jogo de hoje e saber responder à pergunta “Como eles fizeram isso?”. Mas na época dos jogos Famicom, as restrições de hardware foram muito severas, e não havia muito o que pudéssemos fazer. Mas trabalhano em torno dessas restrições e buscando algo novo, nós podíamos alcançar o “Como eles fizeram isso?”

Miyamoto - Isso mesmo. Tentamos puxar bons elementos de uma variedade de jogos, mas talvez o mais importante foi Excitebike. Por exemplo, a idéia de warps (links entre fases descontínuas) veio de lá.

Iwata - Como assim?

Miyamoto - A versão arcade de Excitebike tinha três níveis, e você poderia escolher onde queria começar a jogar. Isso era porque pensamos que jogadores experientes, gostariam de começar em níveis avançados de imediato. Claro, se você começou no World 7 em Super Mario Bros, seria muito difícil, mas nós pensamos que seria bom se jogadores experientes pudessem facilmente ir de um mundo para a outro.

Iwata - Ah, então é aí que a ideia de warps surgiu.

Miyamoto - Certo. Todo o tempo, você tinha que jogar desde o início. Então fizemos as warps possíveis para as pessoas que quisessem jogar já no fim. Se os jogadores descobrirem as manhas, eles podem pular para o World 8 de imediato. Isso era como você escolher a fase para começar no Excitebike.

Iwata - Ah, então Super Mario Bros foi o ponto culminante de um grande número de diferentes tecnologias.

Miyamoto - Nós fizemos isso propositadamente para ser um game único.

Iwata - Quando você fez Super Mario Bros, você usou uma memória de 256 kbits em primeiro lugar.

Miyamoto - Isso mesmo. Os personagens ficaram em 64 kbits.

Iwata - Durante a transição para o Disk System o espaço de armazenamento em disco era um megabit. E você queria colocar tudo dentro da memória.

Miyamoto - Certo. Mas só eu que pensava dessa forma? Nakago-san, você pretendia embalar toda a tecnologia dos jogos anteriores neste cartucho?

Nakago - Bem, nós sempre tínhamos muito trabalho com isso, como um corte no visual em um determinado local para reforçar a programação em outra.

Miyamoto - Você tinha bastante know-how nessa área.

Nakago - Naquela época, nós brigávamos por memória livre. Por exemplo, um bloco era de 3 bytes, talvez dois, portanto, se houvesse 20 bytes livres, você poderia colocar 10 blocos. Miyamoto dizia: “Eu quero colocar em 10 blocos”, mas vamos ficar sem memória rapidamente desse jeito, né? Então, Kondo-san queria fazer o final, então eu perguntei: “Quantos bytes você precisa?”

Kondo - Isso mesmo! (Risos)

Nakago - Ele disse que poderia colocar um som em loop com 40 bytes. E os 20 bytes que sobraram foram para Miyamoto que disse: “Vamos fazer uma coroa!”

Miyamoto - Eu queria fazer uma coroa como uma recompensa para as pessoas que tivessem dez ou mais vidas extra. (Risos)

Nakago - Nós colocamos isso em todo final de mundo.

Miyamoto - Normalmente você iria deixar cerca de 100 bytes, como precaução contra erros que talvez precisem ser corrigidos, mas estávamos chegando ao final de desenvolvimento e não parecia ter algum bug, por isso, começou a utilizar o espaço de sobra, e no fim, disse: “Há oito bytes livres, há algo que você deseja colocar dentro?” e (parecendo extremamente feliz) eu respondi: “Eu realmente queria colocar alguns blocos aqui!” (Risos)

Todos - (Risos)

Miyamoto - Então, quando finalizou, era como se todos os erros aparecessem. Foi divertido ficar indo e voltando arrumando tudo.

Nakago - Realmente foi.

Fim da parte 3

Outro ponto que me chamou muito a atenção foi que Miyamoto, apesar de ser até hoje considerado sozinho o criador de Mario, ele deve muito de seu sucesso aos colegas de equipe. A história teria sido outra se o time não estivesse focado em entregar o projeto da forma como estava. Vocês concordam?

Até a próxima parte deste interessante arco de entrevistas.

Neste início de ano focamos um pouco mais em mostrar o que acontece atrás dos bastidores da produção de um game. A coluna Jogo Aberto, vinha trazendo informações, técnicas e conceituais, de produções nacionais. Porém, hoje inauguramos as análises de games estrangeiros, e com um símbolo da indústria, SUPER MARIO BROS.

Super Mario Bros foi lançado para o console Famicon em 1985, até hoje é considerado um game divertido. Poucos imaginavam que um “simples”  sidescrolling, poderia ser, poucos anos depois, o ícone de toda uma milhonária indústria. Ano passado Mario completou 25 anos (puxa,  estou ficando velho) e para comemorar a data, a Nintendo lançou uma edição especial do game, além de versões do Wii e Nintendo DS tematizadas com o bigodudo. Dentre as festividades, uma reunião com os desenvolvedores originais do game me chamou a atenção. Nela estavam presentes o gênio Shigeru Miyamoto, Koji Kondo – Analista de Entreternimento e famoso compositor, Takashi Tezuka – Gerente Geral de Software e Desenvolvimento, Toshihiko Nakago – Presidente de Pesquisa e Desenvolvimento. A entrevista foi conduzida por ninguém menos que Satoru Iwata, atual presidente da empresa. Vamos então conhecer a primeira parte de um arco de posts sobre os segredos por trás de Super Mario Bros.

Parte 1 – Utilizando o Controle Direcional para Pular

Iwata - Para a minha entrevista final desta comemoração do 25º aniversário do Super Mário Bros, eu reuni a equipe original de desenvolvimento. Quatro homens que continuam na ativa de codificação da série. Eu gostaria de perguntar como Super Mário Bros surgiu e porque tantas pessoas continuam amando a série até hoje, 25 anos após o seu nascimento? Obrigado por todos terem vindo hoje.

Todos - O prazer é nosso.

Iwata - A propósito… quem trouxe todos esses documentos secretos colocados aqui mesa?

Nakago - Fui eu!

Iwata - “Nakago-san”… da mesma maneira como da última vez, você desenterrou alguns documentos preciosos (risos).

Nakago - Sim (risos).

Miyamoto - Tenha certeza que ele é bom em manter as coisas.

Nakago - Estas são as primeiras especificações do Super Mário Bros. São de Miyamoto.

Nakago -  Naquela época nós escrevíamos tudo a mão e o selo é do departamento de criatividade.

Iwata - O selo desta seção existia antes da divisão de Análise de Entretenimento e Desenvolvimento, e a data é  20 de Fevereiro de 1985. Isso significa que foi escrito no mesmo ano do lançamento do Super Mário Bros original.

Miyamoto - Nós escrevemos as especificações em 20 de Fevereiro e seis meses depois nós codificamos na ROM.

Iwata - Isso é que é um trabalho rápido (risos).

Miyamoto - Na verdade, eu tinha escrito algumas especificações de teste antes, em Dezembro de 1984.

Nakago – Essas eu não consigo achar. Já procurei por tudo.

Miyamoto – Se bem me lembro… a primeira coisa que eu disse foi que teríamos que fazer uma grande figura com o personagem pulando dela.

Iwata - E, foi assim que o Super Mário surgiu pela primeira vez.

Miyamoto - Por volta de Dezembro de 1984, eu queria ver algo parecido com um salto do Mário, algo que fosse o dobro do que utilizamos em Mário Bros (1). Então pedi aos programadores da SRD (2), para fazer uma versão teste, algo em que, quando você pressionar um botão, o Mário pulava, e se você ficasse pressionando repetidamente, ele iria saltar no ar. E isso acabou sendo muito bom.

Iwata - E o céu azul já estava na versão de teste?

Nakago - Não, ainda não.

Miyamoto - Hã? O céu não era azul?

Nakago - Não, ele ainda estava escuro.

Iwata - Mas em conversa anterior comigo, sobre o Novo Super Mário Bros Wii, você disse que quando viu que o céu azul na tela, você estava surpreso com o brilho e o visual produzido para o FAMICOM.

Nakago - Isso foi depois que nos tornamos capazes de fazer o background se movimentar para os lados.

Iwata - No início, apenas o Mário se movimentava?

Tezuka - Não, apenas um objeto quadrado.

Iwata - Então, você começou os experimentos com algo se movendo ao redor de um quadrado.

Miyamoto - Sim. Primeiro nós movimentamos algo em trono de um quadrado então
disse: “Em seguida, vamos fazer algo parecido com isto”, e fizemos outras coisas.

Nakago - O que fizemos depois dessa experiência?

Miyamoto - Eu acho que nós criamos a base para “The Legend of Zelda” (que seria lançado em Fevereiro de 1986).

Nakago - Ah, isso mesmo.

Miyamoto – Sim, Sim, eu me lembro agora. Depois de fazer o experimento com as formas quadradas do Super Mário Bros, começou o experimento com o que se tornou a base para o “The Legend of Zelda”. E, eu escrevi estas especificações, em Fevereiro do próximo ano?

Iwata - Sim, em Fevereiro.

Miyamoto - Eu escrevi essas especificações sob pressão. Eu escrevi toda especificação de uma vez e quando ví, os movimentos já estavam em uma versão de testes feitos em Dezembro.

Nakago - O Mário era quadrado e os botões do controlador eram quadrados também.

Iwata - Os botões não estavam definidos ainda, certo? Para movimentar, se bem me lembro, você disse que deveríamos apertar para cima no controle direcional para pular!

Miyamoto – Ah, hum …

Nakago - Você está certo!

Iwata - O botão A é o de atacar com itens … Isso era do “The Legend of Zelda”?

Nakago - Hã?

Miyamoto - Isso é estranho. O documento diz, “Pressione o controle direcional esquerdo e direito para controlar Mario em duas velocidades …”

Nakago - Não, isto é para o Super Mario Bros.

Tezuka - (Risos)

Iwata - E diz que o botão é para chutar quando Mário está de mãos vazias e também para utilização de um fuzil e uma outra arma de raio.  Isto é realmente do Super Mário Bros? (Risos)

Todos - (Risos)

Miyamoto - Ele usaria uma arma de raio quando voava em uma nuvem.

Iwata - Desde o início, você imaginava ele voando no céu?

Miyamoto - Sim. Mas na época, não era sobre uma nuvem, mas em um foguete.

Iwata - Hã? O Mário iria voar em um foguete? (Risos).

Miyamoto - Decidi dividir as ações entre a terra eo céu. Eu acho que eu ainda estava confundindo isso. Mesmo que fosse apenas seis meses antes da conclusão (Risos).

Iwata - Ainda assim, estou surpreso que desde o início você não usaria o botão A para saltar.

Miyamoto - Eu não me lembrava disso!

Todos - (Risos)

Fim da parte 1

E ai pessoal, o que acharam da primeira parte? Eu Achei muito legal saber de todos estes detalhes. E o melhor ainda está por vir.

Até a próxima!

Pois é, mais um ano começa e estamos de volta trazendo mais informações e dicas da indústria de games para vocês.

O Blog inicia o ano contando com mais um colaborador para a equipe. Rafael Rodrigues, gerente de projetos com experiência em desenvolvimento de games há mais de 5 anos, irá comentar sobre padrões de desenvolvimento (SCRUM) e nos trará um panorama do mercado nacional.

O primeiro Post do ano será uma matéria da coluna Jogo Aberto. Seguindo o nosso arco de produções nacionais, falaremos hoje sobre a série  “Burger Island” da Paranaense TechFront.

Ficha Técnica
Categoria: Casual
Título: Burger Island 1 e 2
Plataforma: PC e Wii
Gênero:Time/Task Manager (Gerenciador de Tempo e Tarefas)
Desenvolvedor: TechFront (Curitiba-Paraná)

Burger Island é um jogo do tipo gerenciamento de tempo, o objetivo do jogador é fazer um quiosque de lanches funcionar e dar resultado. Os lanches devem ser preparados dentro de um tempo determinado e, mais importante que isso, de forma correta, com todos os seus ingredientes colocados na ordem da receita.

A partir do momento que o jogador vai avançando nas fases, novas receitas vão sendo liberadas para compra do jogador (com o dinheiro – pontos, das fases anteriores) e incorporadas no quiosque para venda.

O jogo casual foi o primeiro desenvolvido pela empresa TechFront. O tempo de desenvolvimento da primeira versão foi em torno de seis meses e contou com a colaboração de uma equipe composta por oito pessoas, entre elas, produtores, artistas, game designers, áudio designers, testadores e programadores. A equipe de desenvolvimento utilizou o Adobe Flash como a principal ferramenta para criação. Já a segunda versão ocupou a equipe durante oito meses e oferece muitos mais recursos ao jogador.

Com uma mecânica simples, o “Burger Island” é bem divertido e desafiador, o jogador sempre fica com vontade de ganhar mais pontos (dinheiro) para fazer o seu quiosque crescer e atender mais clientes.

Os gráficos do jogos são bem interessantes – principalmente os da segunda versão – com cores bem adequadas ao contexto do jogo.

O som, é outro elemento que torna o jogo legal e divertido, possui um ritmo contagiante e foi desenvolvido exclusivamente para o projeto.

Um dos pontos mais curiosos sobre o projeto foi a questão do aprendizado que a empresa adquiriu ao fornecer a versão para diversas plataformas. Inicialmente sendo um jogo para console, o game foi publicado no Sônico onde recebeu uma imensa receptividade. Após isso, Orkut e MySpace receberam versões, e logo, logo, uma versão para o facebook será lançada, diz Inaê Ribeiro – responsável pelo Marketing da empresa.

Tendo em vista esta abordagem de sucesso, Burger Island 2 foi lançado diretamente para Web e PC.

O que funcionou: a contextualização, gráficos, desafios e mecânica do jogo simples proporcionam aos jogadores bons momentos de diversão.

O que não funcionou: a escolha do nível de dificuladade inicial (kiddle size, regular, jumbo size) não aparentam serem realmente níveis de dificuladade diferenciados. Foi notado uma sensível mudança na velocidade dos pedidos, mas nada que justifique esses nomes de níveis impactantes.

Gostou? Quer conhecer melhor os games?

Burger Island 1 Comprar ou Experimentar

Burger Island 2 Comprar ou Experimentar

Ficha Técnica
Categoria: Advergame
Título: Fiat Uno Color Race
Plataforma: IPhone
Gênero: Corrida 3D
Desenvolvedor: OvniStudios (Nacional)

O Jogo foi desenvolvido em Unity3D durante dois meses e meio pela equipe da Ovni. Uma única pessoa projetou, programou e fez a gestão do projeto. O restante da equipe ficou dedicada a parte gráfica e ao som do game. O curto tempo, a capacidade de desenvolver com um time reduzido e a grande marca por traz do jogo mostram a maturidade da OvniStudios no desenvolvimento de jogos para dispositivos móvies.

Misturando corrida com estratégia, o objetivo é dirigir seu Fiat Uno em uma cidade incolor e dar uma volta em cada quadra da cidade. Ao fazer isto, a quadra ganha as cores e o estilo do seu Uno, que pode ser customizado no início do jogo.

O Jogo consiste de 20 fases. As primeiras são bastante fáceis e servem como tutoriais, porém as fases subseqüentes aumentam gradativamente a dificuldade do jogo.

A interface e os controles são bastante simples e intuitivos. Existem dois pedais onde o jogador pode acelerar e freiar o seu carro, enquanto a direção é controlada movimentando o próprio Iphone.

A a partir da fase 3, alguns “inimigos” são enviados para atrapalhar o jogador, porém só foi possível percebê-los na fase nove. Eles só se tornam um desafio nas fases finais.

Nas últimas fases, onde a área que deve ser “pintada” é bastante grande, é bastante fácil se perder, um mini-mapa mostrando as áreas restantes seria de grande valia.

O que não funcionou: Ao meu ver, a principal falha do jogo (que é um Advergame) está no fato de não reforçar a marca suficientemente. Após a primeira tela, onde o jogador pode customizar o seu carro, é possível  esquecer que está dirigindo um Uno depois de alguns minutos de jogo.

O que funcionou: Fiat Uno Color Race é um jogo com um objetivo e controles simples, com uma interface bastante coerente e o mais importante, divertido. Este jogo definitivamente mostra a maturidade da OvniStudios e consequentemente da industria nacional.

Abaixo confiram o vídeo de divulgação do game.

Em 2008 eu tive a oportunidade de participar de uma equipe que ajudou a mudar este conceito. Através de uma excelente parceria entre Gestum – Tecnologia Educacional, professores/técnicos da Universidade Federal do Rio Grande do Sul (UFRGS), Universidade Federal de Ciências da Saúde de Porto Alegre (UFCSPA) e Instituto Federal Sul Riograndense de Pelotas, em julho deste ano foi apresentado à FINEP o produto final de um dos projetos produzidos para atender a um Edital de fomento a jogos educacionais. Trata-se do Química Aplicada, jogo que será utilizado para motivar os alunos do ensino médio a estudar Química Orgânica. Com isso, embora não fosse um objetivo do edital, consolidou-se uma parceria integrando empresa e universidade, a qual deverá ter continuidade em outros projetos.

O Game narra as aventuras e desafios de um repórter, que recebe informações sobre uma grande explosão em uma ilha, ao sul do Brasil. Mostra a pauta a seu editor chefe, o qual identifica as coordenadas como o local onde ocorrem pesquisas com Química Orgânica. Será que houve algum acidente? Será que há risco de contaminação ambiental na região? Será que haverá novas explosões? No percurso do jogo, o personagem deverá enfrentar vários desafios na ilha, entre eles: resolver uma emergência química no laboratório destruído; utilizar vários itens como um palmtop e um maçarico; passar por labirintos protegidas por sistemas de segurança; e até descobrir a combinação de combustíveis necessários para mover uma lancha e abandonar a ilha.

Chegada do repórter na ilha

O professor Eric Klopfer, do MIT, conta que os críticos dos games educacionais costumam chamá-los de brócolis cobertos de chocolate. A este respeito, a equipe de coordenação do Química Aplicada considera que um dos principais diferenciais deste jogo é exatamente a busca do equilíbrio entre a jogabilidade (o chocolate) e as exigências do conteúdo educacional (o brócolis). O fator mais trabalhado no Projeto de Jogo foi a forma como o conteúdo seria entregue ao aluno. Normalmente jogos educacionais deixam este evento bastante explícito, quebrando o ritmo do jogo. O segredo foi criarmos um contexto envolvendo o conteúdo, tornando-o parte da narrativa.

O conhecimento de química é exigido em vários pontos do game.

“A participação da Gestum foi fundamental, garantindo a qualidade gráfica e a fluência do game, de forma envolvente e motivadora para o aluno, que realmente joga com gosto enquanto pesquisa os conteúdos de química, para resolver os desafios.” Comenta Maria Isabel Timm, Dra. em Informática na Educação pela UFRGS e principal responsável pelo projeto.

Outro fator que considero um grande diferencial do projeto, foi a autonomia dada ao professor. O docente, através de arquivos XML, pode configurar os puzzles, enredo, conteúdo e até o desfecho da história. Esta funcionalidade visa adequar o aplicativo a forma como cada professor organiza seu conteúdo na sala de aula.

Todos os puzzles possuem um contexto, o aluno quase não percebe que está aprendendo.

Uma versão-piloto do jogo já está sendo aplicada com alunos da rede pública e privada do RS, com acesso via Internet. O jogo foi adequado ao padrão SCORM, para ser acessado através de qualquer LMS (Learning Management System), e tem total flexibilidade para futuros professores modificarem ou acrescentarem material de apoio, questões e outros desafios, adequando desta forma o game a várias possibilidades de aplicação em sala de aula.

Interessados em acessar e conhecer o jogo podem fazer contato com os coordenadores do projeto, através dos e-mails:

Olá pessoal, desde que comecei a jogar videogame sempre tive curiosidade de saber como eles eram desenvolvidos, que tecnologia utilizavam, quantas pessoas seriam necessárias, e o mais importante, o que eu devo fazer para desenvolver o meu. É com o objetivo de responder à todas estas perguntas que inauguro hoje a coluna Abrindo o Jogo.  Nela vocês poderão conhecer um pouco dos segredos dos bastidores das maiores desenvolvedoras de games do mercado, focando desde a arquitetura de software até o Game Design. O Primeiro artigo apresenta detalhes técnicos sobre o desenvolvimento do game de guerra Shellshock Nam 67 (SSN 67), lançado em 10 de setembro de 2004 e desenvolvido pela Guerillha Games. Apesar da empresa ser mais conhecida hoje pelo sucesso KillZone 2, um dos principais títulos do PS3, foi durante o desenvolvimento de SSN 67 que a equipe adotou pela primeira vez novos Padrões de Projetos (Design Patterns), mais especificamente um grande conhecido meu, o MVC. Vamos saber mais sobre como isto ocorreu?

Mesmo atualmente pouco se fala sobre a arquitetura de software de um game, ao contrário de artigos sobre IA, Game Design e Física, este importante assunto recebe pouco destaque. Por exemplo, você sabia que a maioria das classes  de um game derivam de uma única? Normalmente chamada de Actor, Object ou Entity.

“A escolha de uma arquitetura adequada  é um ponto vital para a construção de um game, apesar disto não ser visível para o usuário final, más escolhas irão afetar muitos aspectos no processo de desenvolvimento. Uma boa estrutura reduzirá o risco e aumentará a eficiência da equipe.”

Foi com este pensamento que a equipe da Guerillha Games, antiga Lost Boys Games, (OK! o forte deles não seria criar nomes para a empresa) iniciou o desenvolvimento do game Shellshock Nam 67. Eles procuravam uma estrutura que fosse flexível suficiente para suportar todas as idéias e ainda assim, rígida para forçar uma única forma de trabalho. O desenvolvimento do seu primeiro jogo, Killzone 2004, foi considerado muito bom, entretanto tiveram uma boa oportunidade de analisar a estrutura e vislumbrar várias melhorias. Com a base similar a anterior, as novidades seguiriam os seguinte critérios:

• O sitema precisa ser ainda mais orientado a dados;
• Devemos utilizar o conhecido padrão MVC Model-View-Controller;
• A simulação do jogo rodará em uma frequência de update fixa para garantir comportamento consistente em todas as plataformas (PS2, XBOX and PC).

Entidades

Em SSN67 a classe base para todos os objetos do jogo é chamada de Entity(Entidade). A equipe deixou bem claro a distinção entre objetos do jogo que possuem um estado e os que não possuem. Por exemplo, a geometria estática do mundo e seu modelo de colisão não são entidades, nem tão pouco nuvens em movimento no céu. Um barril de óleo por exemplo, é uma Entidade porque quando ele explode isto pode ferir o jogador e influenciar o estado do jogo. Segundo Jorrit Rouwé, programador líder da equipe, utilizando uma definição como esta fica muito fácil separar objetos importante para o game dos que não teriam tanta relevância. O sistema de streaming do motor, por exemplo, pode baixar texturas sem afetar o estado do jogo.

Orientado à Dados

Um sistema que segue esta orientação utiliza dados ao invés de código para configurar as propriedade de um objeto. Em SSN67 eles utilizaram a classe EntityResource (Recursos da Entidade) como classe base para as propriedades de um objeto. Os recursos da entidade são definidos em um arquivo de texto e editado manualmente. O exemplo a seguir mostra como se pareceria a configuração de um NPC (Non Player Character – Personagem controlado pela máquina):

CoreObject Class=HumanoidResource
{
  Name = Ramirez
  Model = models/soldiers/ramirez
  Speed = 5
  ...
}

Quando estes arquivos textos são lidos pelo sistema de serialização deles, os objetos correspondentes são automaticamente criados e cada variável é mapeada para um atributo. Após uma EntityResource ser carregada eles validam o tipo de cada atributo e verificam se todas elas juntas formam uma configuração válida. Se as informações não forem válidas, uma mensagem de erro é mostrada e o game não roda. Em SSN67 eles não permitem entidades serem criadas sem um EntityResource. Pois isto garante que um objeto específico aja da mesma forma em todos os níveis, reduzindo significativamente a ocorrência de bugs. O Padrão de Projetos Factory (Fábrica) foi responsável por criar uma Entidade através de sua EntityResource. Isto significa que bastaria entregar uma EntityResource a fábrica para obter a Entidade correspondente, pronta para ser usada no jogo. Isto foi feito através de um  plugin para o Maya. Level Designers (Projetistas de Fases), podiam criar uma Entidade e posicioná-la em um fase apenas selecionando o arquivo da EntityResource correspondente. Entidades que necessitam de um comportamento especifico, mais dinâmico, poderiam ser criadas através da linguagem de Script LUA.

O MVC (Model-View-Controller)

O Padrão de Projetos MVC (padrão de arquitetura) é utilizado em várias áreas, desde um processador de texto há um aplicativo web. Ele basicamente define que um objeto deva ser dividido em três entidades distintas, relacionadas entre si: o Modelo, a Visão e o Controlador. Esta arquitetura encaixa como uma luva para o desenvolvimento de jogos. Compartilhando desta visão, a equipe da Guerrilha adotou o padrão relacionando o Model à Entity, a View a uma classe chamada EntityRepresentation e o Controller permaneceu com a mesma nomenclatura. Vamos ver com mais detalhes como a empresa trabalhou com cada uma delas:

O Modelo (Entity)

As Entidades devem armazenar o mínimo de estados possíveis de um objeto. Qualquer estado que for necessário apenas para a visualização, não será armazenado no Modelo. Grande parte das Entidades em SSN67 são simples máquinas de estados. Entidades por definição não deveriam saber nada sobre animações, porém infelizmente muitas animações interferem no volume de colisão do objeto e consequentemente no estado do game.  No game um Humanoid caminhando por exemplo, olha em seu EntityResource a velocidade máxima de caminhada, ao invés de observar a animação para obter esta informação. A EntityResource pré-calcula a velocidade da animação de forma que o Modelo esteja alinhado com o que o usuário esta vendo na tela, gerado pela EntityRepresentation. A equipe ainda considera que há como reduzir ainda mais a relação da Entidade com as animações

A Visão (EntityRepresentation)

A EntityRepresentation é responsável por desenhar a Entidade e todos seus efeitos. Exemplos de tarefas executadas por uma EntityRepresentation:

• Modelos 3D
• Partículas
• Decals
• Filtros de Tela
• Som

Uma EntityRepresentation, apesar de dar esta impressão, não muda o estado de uma Entidade. Ela na verdade baseia-se neste estado para criar o seu próprio. Porém há algumas exceções onde esta informação não é suficiente. Por exemplo, quando um humano é atingido o jogador espera visualizar o sangue vindo de tal ferimento. Simplesmente olhando a quantidade de energia anterior e a atual, não seria possível saber onde o personagem foi atingido. Nestes casos eles usaram um sistema de mensagens muito utilizado no MVC. Todas as mensagem derivam de uma classe chamada EntityEvent, a qual contém um Id que indica o tipo de mensagem. A Mensagem de “Ser Atingido” contém o tipo, quantidade de dano e onde o personagem foi causado. Para atingir um realismo maior, o sincronismo dos efeitos é normalmente crítico e precisa bastante código para ser gerenciado. Separando este código da lógica essencial do jogo, a equipe reduziu o risco de bugs. Uma vantagem importante desta arquitetura é se todos os objetos seguirem as regras, o estado do jogo não fica dependente da representação, ou seja, o jogo pode rodar sem elas. Este princípio pode ser muito útil para criar servidores multiplayers onde a parte visual não é necessária.

O Controlador (Controller)

O Controlador prove abstração de entrada (input) para uma Entidade. Tendo isto como premissa, a equipe criou para cada Entidade  uma classe base que define as partes controláveis. A partir desta versão eles puderam derivar um Controlador para A.I. e um para o player. Por exemplo, um Humanoid tem um HumanoidController que serve de Super Classe para HumanoidAIController e HumanoidPlayerController. A versão do player ainda poderia dividir-se entre prover suporte a mouse e teclado (PC) ou joystick (XBOX e PS2). O objetivo do Controlador é especificar o que a Entidade deverá fazer, porém não pode mudar diretamente seu estado. A cada update o Controlador é requisitado pela Entidade e ela tenta seguir suas instruções. Por exemplo, ele nunca iria chamar o método MoveTo() em um Humanoid, mas sim o Humanoid iria sondar o método GetDesiredSpeed() (pegar velocidade desejada) do Controlador e então tentar alcançar esta velocidade enquanto executa a detecção de colisões para ter certeza que não esbarrará contra uma parede. Para fazer um Humanoid interagir com uma arma, por exemplo, o HumanoidController implementa a função chamada GetUseObject(). Esta função é acionada a cada update pelo Humanoid. Para um NPC, a A.I. usa o raciocínio para determinar se isto é benéfico ou não. Já para o player, o HumanoidPlayerController detecta que o objeto está ao alcance e dispara a lógica do menu de uso. A HUD [1] encarrega-se de desenhar as opções na tela. Após o jogador selecionar uma opção, esta informação retornará através do GetUseObject() na próxima requisição do Humanoid ao HumanoidController (o próximo pulso).

[1] HUD (Head Up Display) É um instrumento inicialmente desenvolvido para utilização em aeronaves visando fornecer informações visuais ao piloto sem que este tenha que desviar os olhos do alvo. No mercado de games ele refere-se as informações que estão dispostas na tela para o jogador, como por exemplo: Energia, Tempo, Número de Vidas, etc.

Um Simples Exemplo

Imaginemos o conceito de MVC aplicado a um Tanque. Primeiramente ele seria dividido em Entity (Tank), EntityRepresentation (TankRepresentation) e um Controller (TankController). O TankController tem funções como GetAcceleration(), GetSteerDirection(), GetAimTarget() e Fire(). A I.A. guia o tanque usando um TankAIController e o jogador através de TankPlayerController. A classe Tank acompanha o estado físico do veículo, os danos e direção. A TankRepresentation além de desenhar o tanque, cria as partículas de fumaça quando o tanque atira e reproduz um rastro onde o veículo passou. Também é comum a View tratar dos sons, neste exemplo ela trataria do som correspondente quando o tanque colide por exemplo. Uma curiosidade comentada pela equipe é que a representação teria uma certa independência da Entidade para movimentos de rotação, como adequar-se a um terreno irregular, desde que isto não interfira no volume de colisão do tanque.

Simplificação do Estado de Jogo

Vamos, através de um exemplo,  entender melhor como a Guerrilha desenvolveu o sitema de estados de SSN 67. Quando um Humanoid atira com uma arma, o game mostra a bala saindo do cano, porém esta simples ação pode representar problemas. Cada arma tem sua própria animação, ligeiramente diferente. Pistolas ficam na altura dos ombros, escopetas na linha da cintura, e armas mais pesadas, como rifles e bazucas, precisam ser apoiadas em algo para serem utilizadas. Estas diferenças podem levar a inconsistencias do cálculo de posições feitos pela AI. Por exemplo, um NPC pretende encontrar um posição coberta para poder atirar, a AI faz o cálculo envia o agente para logo atrás de uma pedra, que por sua vez possui metade de seu tamanho. Se a arma utilizada for uma pistola, não haverá problema, porém se for uma escopeta, a bala deveria atingir a pedra quando utilizada. Para solucionar este problema eles separaram o algoritimo de atirar da parte visual. As balas de todas as armas agora saem de um ponto fixo (próximo ao ombro), baseado somente na posição corrente e postura do Humanoid. O rastro é manipulados pela EntityRepresentation e sai do cano da arma (como na animação) movendo-se na mesma direção. Os dois cálculos, animação e lógico, lentamente convergem para o ponto de impacto.

O Frame Work Completo

O Diagrama abaixo apresenta o framework completo utilizado em SSN67.

Diagrama de Classe demonstrando a relação entre cada objeto

O EntityManager é um container para todas as Entidades, ele dispara uma atualização para todas elas em um frequência fixa. Todas as Entidades que participam do game devem estar cadastradas no EntityManager, que dentre várias funções, facilita a procura por elas. A equipe definiu que Entidades pudessem ser atualizadas por outras Entidas em alguns casos especiais, onde a ordem de update fosse relevante. Quando um jogador prepara-se para atirar, é fundamental que o player seja atualizado depois da arma. Caso contrário o sistema apresentará um jitter[2]. Nestes casos a arma pode setar uma flag no jogador para que ele não receba atualizações de pulso da EntityManager. O RepresentationManager mantém todas as EntiyRepresentations em uma hierarquia espacial que torna fácil e rápido a definição do que está ou não visível. Ele recebe uma notificação do EntityManager logo que uma Entidade é adicionada ou removida, com isto cria ou destrói a Representação correspondente. Quando recebe um pulso de frame, a RepresentationManager desenha todas as GameViews. A GameView é responsável por desenhar o mundo para um jogador, ela acompanha a câmera ativa e usa a hierarquia espacial da RepresentationManager para desenhar todas EntityRepresentations visíveis, além de desenhar também as Não-Entidades, como o mundo estático e a HUD sobreposta a todos eles. O  SSN67 poderia possuir o modo multiplayer com a tela dividida, porém esta feature não foi desenvolvida por questões de tempo.

[2] Jitter é uma variação, um retardo na entrega de dados criando uma inconsistencia, termo também muito utilizado em redes de computadores.

Conclusão

Eu ouvi falar em Model View Controller pela primeira vez em 2004, nesta época eu já havia desenvolvido o motor que a empresa utilizava para construir nossos Serious Games. Porém quando fiquei a par das vantagens que esta arquitetura traria ao desenvolvimento, não pensei duas vezes, comecei a construir outro Engine do zero utilizando seus conceitos. Atualmente não consigo imaginar como seria desenvolver um game sem utilizar a arquitetura MVC. Fiquei muito contente em saber que na mesma época uma grande empresa como a Guerrilha Games estava pensando a mesma coisa, percebendo as grandes vantagens deste ótimo Padrão de Projeto. Segundo Jorrit Rouwé, esta nova arquitetura inclusive facilitou o gerenciamento de prazos da equipe, já que induziu a divisão das tarefas em blocos de código menores e intuitivos. Eles afirmam que utilizam esta arquitetura em todos seus projetos, inclusive no atual grande sucesso da empresa, o “sucessor” de Gears of War, KillZone 2.

Um abraço e até a próxima matéria da Abrindo o Jogo. Não esqueçam de deixar seus comentários e críticas

Ilustrações: Inara Cavichioli

Referências Bibliográficas: