PUBLICIDADE

Topo

Histórico

Por Trás do Jogo: Desenvolvimento de jogos dentro dos limites

Thais Weiller

07/04/2020 14h30

Depois da apresentação das áreas de desenvolvimento de jogos, eu convidei diferentes profissionais para falarem da sua área diretamente aqui no Blog. Hoje temos Arthur Zeferino, programador de jogos há mais de 10 anos, co-criador do GAMESFODA e atualmente trabalhando no Fish Person Shooter.

Se você jogou o primeiro Resident Evil, tanto o original de 1995 quanto o remake, você deve se lembrar das portas, que abriam lentamente e aumentavam a tensão do jogo. Sem saber o que você ia encontrar por trás de cada uma, a animação de alguns segundos parecia levar horas. Se você acha que isso foi intencional, bom, você está parcialmente certo. 

Resident Evil (Capcom 1996)

As portas lentas deixavam o jogo mais assustador e são lembradas até hoje por isso, mas elas também foram um efeito colateral das limitações técnicas da época usadas de forma inteligente pelos designers e programadores do jogo.

O leitor de CDs do PlayStation era lento, e carregar cada sala nova da mansão demorava. O time da CAPCOM podia muito bem só ter usado uma tela tradicional com um "LOADING" no meio e talvez uma barrinha, mas eles resolveram aproveitar a oportunidade pra incluir algo que contribuísse pra ambientação do jogo.

Desenvolver jogos é trabalhar com muitas limitações técnicas, e a maneira como a equipe lida com essas limitações pode fazer muita diferença no produto final. Outro exemplo clássico é o do Metal Gear original, de 1987 para o MSX2. A Konami queria um jogo de ação frenético, cheio de tiros e explosões, mostrando todo o potencial do MSX2 e capitalizando em cima de filmes como RAMBO que estavam em alta na época. O jogo mudou (literalmente) quando a equipe descobriu que o MSX2 era capaz de mostrar no máximo 8 sprites em uma linha por vez. Com cada personagem precisando de 2 sprites e uma sprite pra bala, não ia ser um jogo de ação muito empolgante. Veio então a ideia de um jogo de ação com poucos inimigos, em que a dificuldade estava em se esconder deles. Assim nasceu Metal Gear e talvez até um gênero novo de jogos. 

Metal Gear (Konami 1987)

Hoje, os computadores evoluíram muito e esse tipo de limitação enorme não existe mais. Mas o tamanho dos jogos e a expectativa criada em cima deles também cresceu. Uma parte importante do trabalho dos programadores, designers e artistas é saber conciliar estas expectativas com as limitações que existem.

Você deve ter jogado algum jogo recente que, em algum momento, você sai de uma área grande, entra em um corredor e sai em outra área grande. Existe uma chance bem alta de aquele corredor só existir porque as 2 áreas não cabem na memória ao mesmo tempo e o jogo precisa de um tempo pra descarregar a área anterior e carregar a nova. O corredor faz basicamente o que a porta do Resident Evil fazia, só que sem parar o jogo, mas enquanto você está andando por ele, várias coisas estão acontecendo no background pra garantir que você não perceba a sua verdadeira função.

Metroid Prime (Nintendo/Retro 2002) usava muito essa técnica de corredor como área de transição

Esse tipo de coisa muitas vezes é vista como responsabilidade só da programação, mas a verdade é que se você quer que essas limitações sejam parte do jogo como nesses exemplos, todo o time tem que estar envolvido nisso.

Só nesse exemplo do corredor: os level designers precisam projetar as 2 áreas de acordo com o que cabe na memória do console, também precisam projetar o corredor de forma que possa cumprir essa função (não adianta nada o corredor ser ainda maior que uma das áreas), os artistas precisam colocar seus modelos 3D ou sprites 2D de forma que não sobrecarregue ainda mais o hardware, às vezes reutilizando modelos nas 2 áreas pra que esse carregamento possa ser feito mais rápido –note, inclusive, como um corredor desses normalmente tem poucos detalhes e coisas pra fazer. Aliás, já que não há muito o que fazer no corredor, uma maneira inteligente de distrair o jogador, muito utilizada atualmente, é colocar diálogos nessas partes, trabalho do designer de narrativa, que ainda aproveita pra colocar uma coisinha a mais.

Mass Effect (2007 EA/BioWare) usava elevadores com essa função e aproveitava pra incluir diálogos que enriqueciam os relacionamentos dos personagens.

E de um modo mais geral, fazer um jogo rodar em 1080p ou 4k e em 30 ou 60 quadros por segundo também depende de como o time lida com as limitações do hardware em que eles estão trabalhando.

E eu nem vou entrar no mérito de jogos pra Nintendo Switch e smartphones, que têm um hardware mais limitado, ou VR, que requerem uma resolução mais alta e uma taxa de quadros mais alta.

Talvez você esteja pensando: "Mas isso é nos jogos AAA, eu sou um desenvolvedor independente que só quer fazer uns jogos em pixel-art sem me preocupar com restrições de memória e processamento."

Bom, nesse caso você provavelmente vai ter outras 2 restrições muito grandes: tempo e dinheiro.

Você não pode ficar desenvolvendo o seu jogo pra sempre e nem tem dinheiro infinito pra gastar, então você vai ter que dar um jeito de terminar isso aí.

Muitos jogos independentes optam por um estilo de arte simples e minimalista. E muitas vezes o resultado é mais bonito do que jogos AAA mega-caros, mas o custo e o tempo que se leva pra fazer uma arte mais simples pesa muito, então se você está pensando em fazer um jogo foto-realista, talvez seja bom pensar melhor.

Não que não existam jogos de times pequenos com gráficos foto-realistas. Eles existem e normalmente têm algum tipo de compensação: um mapa pequeno, fases repetitivas, nenhum modelo de ser humano e por aí vai.

Stories Untold (Devolver/No Code 2017) foi desenvolvido por um time pequeno com gráficos realistas, porém é um jogo curto com poucas áreas e nenhum modelo humano com animações complexas

Se você segue jogos independentes, já deve ter notado como de uns anos pra cá houve um boom de jogos com mapas procedurais. Jogos como Minecraft, Binding of Isaac e Dead Cells, em que as fases são geradas por um algoritmo, garantindo um mapa diferente a cada nova partida. Muitos desenvolvedores usam geração procedural pra tentar diminuir o trabalho de criação de levels, já que, teoricamente, o algoritmo pode gerar uma variedade gigantesca de mapas. E isso é quase sempre um erro porque algo totalmente aleatório nunca funciona direito e os designers e programadores acabam tendo que passar muito tempo ajustando os algoritmos que criam esses mapas pro resultado ficar bom.

Também é comum hoje em dia jogos em que o desenvolvedor se impõe limitações pra criar algo que pareça um jogo antigo. Casos como Sonic Mania, que tenta simular um jogo de Mega Drive, Shovel Knight, que tenta se assemelhar a um jogo de NES, e Return of The Obra Dinn, que tem visuais inspirados em jogos do Macintosh 128K.

Return of The Obra Dinn (Lucas Pope, 2018) usa técnicas bastante complexas e sofsticadas pra atingir um visual monocromático que lembra um computador antigo.

Por simples questões físicas, por mais que os computadores evoluam, sempre existirá algum tipo de limitação técnica no desenvolvimento de jogos. E no melhor caso, mesmo que as leis da física mudem, ainda haverá alguma limitação humana. E é importante que todos os envolvidos no desenvolvimento estejam cientes das limitações pra fazer o melhor jogo possível com elas.

Sobre a autora

Thais Weiller é mestre pela ECA-USP pesquisando game design, com uma dissertação que virou um livro e um blog. Ela trabalhou em games como “Oniken”, “Odallus”, “Finding Monsters”, “Rainy Day” entre outros, e também fundou, junto com Danilo Dias, a desenvolvedora JoyMasher. Atualmente, Thais dá aulas de design de jogos na PUC do Paraná.

Sobre o Blog

Quais os mitos e fantasias que influenciam nosso comportamento e afetam nossa paixão pelos games? Neste espaço, Thais vai trazer a perspectiva dos pesquisadores e desenvolvedores de jogos para nos ajudar a entender os games de uma maneira diferente.