Level design modular (e como a pré-produção pode te salvar a vida)

Na prática, fazer jogos significa fazer e refazer.

Primeiro me deixa explicar sobre o que é o jogo em que eu estou trabalhando, já que isso tem tudo a ver com level design.

Strike Squadron Caracará é um jogo de combate espacial 2D baseado em missões. Não é um shoot ‘em up onde você desvia de uma enxurrada de balas e mata milhares de inimigos que por acaso voam seguindo sempre o mesmo padrão. Você voa missões de escolta, ataque, etc, ao lado de alas, como em Wing Commander, Starlancer e Freespace.

Mas a história não é sobre uma Terra unificada ou um governo super tecnológico que lembra muito os EUA no espaço. É sobre uma aliança de países latinos e africanos fazendo o que pode com o que tem. Eles operam de estações espaciais emprestadas, o que significa que não têm a base de operações móvel típica da maioria dos simuladores espaciais. Por enquanto guarde essa informação.

Muito antes de decidir largar meu emprego e freelas para fazer meu próprio jogo eu fiz um protótipo usando o Scirra Construct 2, incluindo missões cheias de arte “emprestada” da internet. Avançando meses no tempo, eu já tinha conseguido algumas definições que afetariam a produção, a principal delas sendo que eu usaria peças modulares para montar as fases.

Você provavelmente já ouviu ou leu por aí algo sobre o assunto: para reduzir o custo de produção e o tempo de carregar o jogo reusa-se os mesmos objetos para se montar as fases de um jogo. Já tive uma experiência semelhante antes em outros jogos em que trabalhei, então não tinha porque não seguir essa premissa. Uma vez eu decidi contratar um artista 2D para meu projeto, eu já sabia que a primeira coisa que ele ou ela faria seriam peças modulares para estações espaciais.

Meu primeiro passo aí foi listar esses objetos. Como eu já tinha experiência com esse tipo de coisa, chegar a uma primeira lista foi fácil. Procurei referências pela internet, em outros jogos e arte conceitual. Cheguei a uma lista de 10 peças.

Quando contratei o artista tivemos uma conversa rápida sobre o que eu esperava dessas peças. Ele fez um rascunho rápido do que seriam essas peças, e eu usei o poder do Photoshop para construir alguns exemplos do que eu gostaria de construir com elas.

A primeira coisa que essa brincadeira me disse foi que eu precisaria de mais peças, especialmente um domo/disco menor, e que minha ideia original de usar fatias do disco principal não daria certo do jeito que eu imaginei.

Foi também quando o artista entendeu minha visão (nunca se esqueça de mostrar exemplos do que você quer fazer para aqueles com quem você trabalha, tanto artistas quanto programadores!). Após algumas idas e vindas, ele me mandou o passo seguinte do processo, um desenho já com várias peças, inclusive algumas que ele criou por conta própria. Por que não, né? Na verdade eu acho isso um dos melhores aspectos de trabalhar com outras pessoas: eles sempre têm algo a adicionar (ou melhorar) no projeto.

Depois de mais algumas idas e vindas, chegamos a uma versão final das peças! Com elas construí as primeiras estações espaciais e substituí as artes “emprestadas”. Mas, claro, tinha um problema enorme: a forma com que eu montei o jogo (em termos de código) tornava impossível usar peças isoladas da forma em que eu imaginei.

Bom, assim, eu ainda podia usar as peças para construir dezenas de estações espaciais diferentes, mas eu precisaria fazê-lo no Photoshop, fora da engine. Ou seja, as vantagens de reduzir o tamanho do arquivo e o tempo de carregar o jogo seriam jogas fora.

A razão para isso tudo tem muito a ver com como funciona o Scirra Construct 2, o engine que eu escolhi para o projeto.

Em resumo, o Construct usa Layouts (o mapa da fase em si, onde você coloca objetos e comportamentos básicos) associados à Event Sheets (onde você coloca o código em si).

Em Strike Squadron Caracará eu queria que cada missão tivesse o jogador passando por várias áreas. Era como no jogo Starlancer: a missão começa do lado de fora da sua nave-mãe, então você salta para outra área onde enfrenta alguns inimigos, depois salta para outra área onde há uma estação espacial, depois de volta à nave-mãe.

O problema é que o Construct não deixa transferir objetos entre Layouts. O que isso significa é que eu não poderia transferir o jogador, NPCs e naves sendo escoltadas entre áreas sem perder os dados como vida, mísseis sobrando, etc. Tá, tinha um jeito, usando variáveis globais, mas seria mais ou menos como fazer isso aqui em código.

No protótipo a fase era montada por código. Cada vez que o jogador saltava para a próxima área, os objetos na fase eram deletados, e novos objetos eram criados.

Isso funcionava perfeitamente com objetos inteiros, mas era impossível (ou melhor, extremamente caro) replicar o processo com estações modulares, cada uma com 10+ peças que precisavam estar na posição e rotação exatas para ficar direito.

Depois de alguns testes e rabiscos, cheguei a duas opções.

Primeiro era uma variação da versão anterior. Ao invés de detelar e criar objetos, eu colocaria todos eles já na fase, mas cada área escondida em uma camada diferente do Layout. Na medida em que a missão progredia, a camada anterior seria escondida e a nova seria revelada. Funcionava... mas não era muito mais do que uma gambiarra. Eu ainda precisaria criar inimigos, torretas e minas na mão, pelo código, e havia um risco enorme de bugs caso eu não incluísse uma dezenas de ‘ifs’ ao longo do código, tipo subitamente todas as camadas se revelarem, deixando o espaço meio cheio demais.

A segunda opção era mudar o conceito do jogo. Ao invés de montar missões como em Starlancer, fazê-lo como em Wing Commander ou Freespace: cada missão era uma área (ou layout) inteira. Só que no meu jogo a base de operações é uma estação espacial, e não uma nave-mãe móvel (lembra?), então o espaço precisaria ser enorme de verdade. Isso levava ao risco do jogador se perder enquanto a missão no código seguia em frente em outro canto do mapa. Eu provavelmente também precisaria de um mapa, uma feature que eu não tinha incluído do orçamento original do projeto.

Minha experiência com simuladores espaciais 3D me diziam que mapas grandes era perigosos. Eu lembro bem quando a física começava a se desmontar na medida em que o jogador se afastava da coordenada 0,0,0. Mas minha pesquisa me dizia que isso não era um problema com o Construct. Na verdade, era uma de suas vantagens: por ser 2D e construído em HTML5, o tamanho do mapa era (quase) irrelevante. O que importava de verdade era o número de objetos únicos na fase. Agora, como eu estava construíndo estações espaciais com peças modulares...

Então resolvi fazer isso. Enquanto o mapa original tinha 3.600 pixels por 2.600, testei um mapa de 100.000 x 100.000.

Só pra explicar o drama: levei 9 minutos segurando a tecla de velocidade máxima pra cruzar o mapa de um lado ao outro.

Então, né, o que não faltava era espaço. Me deu até uma vontade de repensar o jogo todo, fazer algo com mundo aberto... Ah, não. Para! Agora não. Faço isso no próximo jogo. Pronto, resolvido. Próximo jogo vai ter mundo aberto e um monte de outras coisas legais que eu quero fazer. Mas não agora.

Agora eu estou trabalhando num jogo militar baseado em missões, e nós não queremos nossos pilotos desaparecendo em serviço enquanto o comboio que deveriam estar protegendo acaba sendo destruído.

E se eu tentasse algo misto? E é isso aqui que estou usando agora:

A estação espacial do jogador fica em um layout separado onde o jogador interage com os NPCs (de forma parecia com as cidades de Banner Saga). Quando o jogador sai em missão, ele vê suas naves decolarem e saltarem, então um novo layout é carregado. Esse novo layout vai variar de tamanho dependendo da missão em si, e já virá com o mapa todo montado. Novos elementos podem aparecer ou velhos mudar, mas o jogo será montado de forma que até possa existir alguma exploração, mas de forma controlada. De repente o jogador esbarra com contrabandistas negociando armas com piratas; talvez ele encontrei inimigos preparando uma emboscada. Quem sabe?

Por agora vou construir as missões dessa forma e ver no que dá. De repente eu acabo construíndo uma fase com uma estação modular gigantesca, de uns 50.000 x 50.000 pixels, só porque eu posso.

De qualquer forma, o esquema agora é fazer e testar. E, então, refazer se for preciso.