A Abordagem Chaos Goblin para Desenvolvimento de Jogos em Unity

Um dos sentimentos mais paralisantes ao iniciar qualquer projeto de desenvolvimento de jogos é aquele que você obtém logo após terminar o design inicial do jogo, sejam algumas ideias anotadas em guardanapos para um game jam ou o design tradicional de 10 páginas documento.

Porque depois que você decide que seu jogo vai ser um ROGUELITE-RTS-MMORPG, você tem mesmo que construir a coisa, viu?

E digamos que você decidiu que a primeira coisa que vai construir é a parte RTS dele. Assim, você anota a história do usuário, as tarefas ou qualquer unidade de trabalho que usa para se organizar.

Então, digamos que o primeiro item dessa lista seja “Implementar mapa rolável”.

E opa! Você nunca implementou um mapa rolável. Mas não se preocupe, Google para o resgate, estou certo?

Mas o que acontece se a solução que você encontra online não faz exatamente o que você precisa? Ou a solução que você encontra tem 15 anos? Ou há muitos comentários abaixo dizendo o quão ruim é a solução, mas sem um único especificando uma melhor [^0]?

Portanto, você não consegue encontrar uma referência de código para o que quer que esteja tentando construir. O que um desenvolvedor de jogos deve fazer?

A resposta é entrar no modo Chaos Goblin.

Entrando no Modo Caos Goblin

Para aqueles que não estão familiarizados com os goblins, eles são uma raça frequentemente apresentada em várias obras de fantasia, normalmente retratados como um primo menor do orc ou hobgoblin mais sério. Em algumas outras propriedades, eles são descritos como sendo mecanicamente proficientes de uma maneira muito específica. E esse caminho não é confiável. O que significa que as coisas que os goblins fazem às vezes funcionam, não tanto porque são bem projetadas ou feitas, mas sim por pura engenhosidade e teimosia.

Essa é a essência da abordagem Chaos Goblin para o desenvolvimento de jogos. Agora, tenho certeza que estou começando a te perder um pouco aqui, então deixe-me voltar e resumir a essência do Chaos Goblin:

Para ilustrar ainda mais esse ponto, deixe-me falar sobre o Presidential Metro Head de Fallout 3 (você pode ler a história completa aqui ). A essência disso é que, durante uma cena do jogo em que o jogador pensa que está dentro de um metrô, o capacete do jogador foi substituído pelo modelo de um vagão do metrô, e é o próprio modelo do jogador que está se movendo em um pista predeterminada.

Alguns jogadores podem ler isso e pensar que os desenvolvedores estão sendo preguiçosos. Mas a verdade é que os desenvolvedores fazem esse tipo de coisa o tempo todo.

E é precisamente esse tipo de prática que forma os princípios do modo Chaos Goblin, que são os seguintes.

O que o jogador não sabe não pode prejudicá-lo

Digamos que em uma parte do seu jogo, o jogador está dentro de uma torre de castelo e está atirando flechas em um dragão que está voando do lado de fora. De vez em quando o dragão se aproxima e enfia a cabeça pela janela para tentar morder o jogador.

Agora, no que diz respeito ao jogador, o dragão está realmente voando lá fora. Mas nós, como desenvolvedores de jogos, poderíamos ter empregado alguns truques para ajudar com essa ilusão e otimizar a situação.

Algumas coisas que podem ser feitas são as seguintes:

• Use diferentes modelos dependendo de quão longe o dragão está do jogador. O jogador só consegue ver os detalhes do dragão quando ele está próximo, então por que não substituir o modelo 3D do dragão por algo que tenha menos detalhes, mas que também ocupe menos espaço na memória?

  
  

• Desligue o dragão quando o jogador não estiver olhando para ele. Ao acompanhar para onde o jogador está olhando, podemos ativar e desativar seletivamente os modelos 3D para economizar na renderização.

  
  

• Evite que o jogador veja o trabalho inacabado. Digamos que, por qualquer motivo, a arte do ambiente fora da torre esteja inacabada. Portanto, se o jogador pisar na borda da janela, não verá nada. Para ajudar com isso, os designers do jogo decidiram que a borda da janela se tornaria um ponto de morte instantânea. Então, quando o jogador estiver na borda, um som de 3 segundos do rugido de um dragão será reproduzido e a tela do jogador começará a escurecer. Terminado o som de 3 segundos, reproduzimos uma animação rápida do dragão comendo o jogador (talvez reutilizando uma que já tínhamos). No que diz respeito ao jogador, a saliência é apenas um lugar onde o dragão pode pegá-lo; eles não precisam saber que foi feito para evitar que vejam o trabalho inacabado.

  
  

• Talvez, quando o dragão colocar a cabeça pela janela, substituamos o modelo completo do dragão por um modelo de cabeça menor, porém mais detalhado. Isso nos permitiria liberar memória de um modelo que não estamos usando e, ao mesmo tempo, proporcionar ao jogador uma experiência aprimorada.

  
  

Se você está na indústria de jogos há algum tempo, provavelmente reconhece as práticas acima como padrão, mas houve um tempo em que essas técnicas eram consideradas truques inteligentes e bastante inovadores.

Agora cabe a você criar novas maneiras de induzir seus jogadores a pensar que há muito mais do que eles estão vendo.

A melhor solução é aquela que está funcionando atualmente

Muitos desenvolvedores de jogos ficam presos porque tentam encontrar soluções que cubram todos os cenários futuros possíveis. Essa atitude pode ser valiosa nas circunstâncias certas, mas quando você está no modo Chaos Goblin, o objetivo é fazer algo funcionar o mais rápido possível.

Um adendo a isso:

Um protótipo defeituoso é mais valioso do que qualquer obra-prima inacabada

Semelhante ao ponto acima, muitos desenvolvedores ficam paralisados ao tentar implementar um recurso porque tentam otimizar muito cedo.

A otimização deve ser deixada até que o projeto precise ser executado em máquinas fora do controle dos desenvolvedores[^1].

Quanto preciso saber antes de fazer X? A resposta é, qualquer quantidade de conhecimento que você tenha agora é suficiente

Este é outro obstáculo que muitos desenvolvedores de jogos iniciantes encontram. Ele vai adiar a implementação de um recurso para fazer apenas mais um curso, mais um tutorial online, assistir a mais um vídeo e, assim, estará pronto para implementar seu jogo.

Eu sou particularmente culpado disso e sei o quão insidioso pode ser.

Para dar um exemplo mais concreto, digamos que você tenha a tarefa de programar um jogo Pong do zero.

Dependendo do que você sabe ou não, pode haver diferentes abordagens para isso:

• Se você estiver familiarizado com o sistema de física do Unity, é um esforço relativamente simples. Você pode apenas usar um par de corpos rígidos e colisores, aplicar forças e velocidades, usar um material físico para quicar a bola e é isso. Um clone de Pong barebones.

  
  

• Mas digamos que você não esteja familiarizado com o sistema de colisão do Unity, você só sabe como usar os componentes de transformação do Unity, então tudo o que você pode obter é a posição e o tamanho de um objeto.

  • Mas! Isso é o suficiente para implementar o Pong, você pode escrever um script que rastreie a posição e o tamanho da bola e a compare com a posição e o tamanho da raquete para verificar se há uma colisão.

    
    

• Ou talvez você nem conheça o Unity, tudo o que você sabe é C++ e como imprimir no console.

  • Mas isso também é o suficiente! Você pode usar truques de terminal para imprimir linhas e colunas de símbolos para representar a bola, raquetes e área de jogo. Isso, juntamente com o conceito de um loop de jogo, é suficiente para programar uma IU atualizada que responde à entrada.

    
    

• Ou você nem tem formação em Ciência da Computação ou não fez curso de C++ e só conhece Javascript?

  • Sem problemas! Você pode usar o Phaser , que usa JS como linguagem principal e vem com componentes de renderização e físicos.

    
    

• Não sabe nem programar? Absolutamente nenhum problema.

  • O Gamemaker é um mecanismo de jogo comercial com uma versão gratuita e possui uma opção sem código.
  • O GDevelop é um mecanismo de jogo gratuito de código aberto com uma opção sem código também.

Você já descobriu onde quero chegar com isso, certo?

Não há projetos fracassados, apenas pilhas de sucata esperando para serem reutilizadas

A maioria dos desenvolvedores de jogos geralmente tem um ou dois (ou 10.000) projetos abandonados em algum lugar. Não faz sentido desperdiçá-los. Se houver um código como um sistema de pausa, reutilize-o. Não faz sentido reescrever a mesma coisa. Mesmo que você se lembre exatamente como escrevê-lo, copie-o; se for difícil de adaptar, reitere-o para que seja mais fácil da próxima vez.

Talvez você até tenha um projeto de workshop[^2] que tenha vários bits de código que você pode reutilizar.

Vê uma coisa brilhante? Pegue uma coisa brilhante

Precisa de um sistema de diálogo? Localize um de código aberto e reutilize-o. Ele atende a todos os seus requisitos? Não? Atende a mais de 50%? Sim? Então vale a pena usá-lo em vez de criar um novo do zero.

Sistema de Inventário? Encontre um jogo de código aberto no itch.io e adote seu sistema.

Precisa de uma câmera em primeira pessoa? Utilize um recurso pré-construído para lidar com isso [^3].

Existem muitos desenvolvedores de jogos brilhantes por aí, sem dúvida mais proficientes do que você ou eu.

A menos que você tenha um motivo específico, tudo deve ser considerado um candidato para usar um sistema pré-construído. No entanto, existem exceções sensatas, como: Não use código que você apenas copiou e colou como a espinha dorsal do seu jogo (pelo menos certifique-se de entendê-lo, limpá-lo e comentá-lo) e evite usar um módulo que tem uma década, com seu autor presumivelmente descansando em algum lugar tropical, bebendo Mai Tais com Elvis, Tupac e Marilyn Monroe em um paraíso livre de paparazzi.

Na dúvida, copie

Se você não tiver certeza sobre a implementação de um recurso, encontre um jogo que tenha feito algo semelhante ao que você deseja e imite-o.

Por “cópia”, quero dizer os aspectos de design, como manipulação de controle, visualizações de câmera e mecânica, em vez do estilo de arte, história ou personagens.

Por exemplo, qual deve ser a velocidade do pergaminho em nosso agora esquecido hipotético ROGUELIKE-RTS-MMORPG?

Em vez de adivinhar, você pode ver como outro RTS conseguiu. Suponha que você observe o Age Of Empires II (um RTS historicamente significativo) e descubra que ele permite que os usuários controlem a velocidade do movimento do cursor. Você pode até colocar seu jogo lado a lado com o AoEII e ajustar o cursor até que pareça equivalente. Você ficaria surpreso com a quantidade de desenvolvedores que dependem de soluções simples e de baixa tecnologia como essa para atingir seus objetivos.

Pensamentos de despedida

Então, o que você deve fazer depois de concluir suas travessuras do Chaos Goblin? Bem, respire fundo, faça uma xícara de chá e retorne ao seu código mais tarde.

Depois de permitir que seu código descanse (sob uma toalha úmida se o tempo estiver muito seco), você deve enfeitá-lo um pouco e compartilhá-lo. Sim! Compartilhe-o, idealmente, com um desenvolvedor sênior, um colega, um colega de estudo ou, na pior das hipóteses, com uma comunidade online[^4].

Por que você está compartilhando? Porque ser um Chaos Goblin não é criar algo durável ou ótimo; trata-se de construir algo que FUNCIONE. Não precisa funcionar perfeitamente ou ficar bonito, só precisa FUNCIONAR. Esse tipo de desenvolvimento produz resultados, mas os resultados raramente estão imediatamente prontos para produção. Portanto, consultar alguém para fornecer feedback é extremamente importante.

Dependendo do estágio do seu projeto, você pode não ter tempo para implementar os comentários dessa pessoa imediatamente. Se for esse o caso, você deve pelo menos documentar esses comentários no código[^5].

E é isso! Agora você possui a técnica nº 1 usada por desenvolvedores de jogos profissionais em todo o mundo para resolver problemas.

Sugiro que é hora de uma segunda xícara de chá, não é?

Notas

[^0] - Este é um fenômeno surpreendentemente comum e é denominado “A Parábola de Denver”, para mais informações, consulte o seguinte artigo acadêmico .

[^1] - Isso é um pouco generalização e, como a maioria das generalizações, pode não ser tão útil quanto uma análise completa dos requisitos do seu projeto. No entanto, é uma boa regra adiar a otimização até que ela seja genuinamente necessária. Hoje em dia, otimizar videogames é consideravelmente menos assustador do que costumava ser. Algumas empresas de mecanismos de jogos, como a Unity, podem até se oferecer para ajudá-lo com consultas gratuitas. Afinal, é do interesse deles que você inicie seu jogo com sucesso.

[^2] - O workshop é um dos katas ou práticas que uso para aumentar minha compreensão da Unidade. Você pode ler mais sobre isso e outras técnicas aqui .

[^3] - Você pode encontrar um pacote de controlador FPS realmente bom junto com outras ferramentas úteis neste artigo

[^4] - Isso traz uma ressalva de que aproximadamente 95% dos comentários que você receberá online podem ser inúteis, incompletos, desatualizados ou refletir as crenças profundamente pessoais do autor, sejam elas quais forem. Portanto, sempre aborde esse feedback com certo ceticismo. Tente procurar comentários úteis, desconsidere ou elimine o resto e faça um esforço genuíno para encontrar alguém com quem possa compartilhar seu código.

[^5] - Equipes diferentes mantêm normas diferentes sobre onde manter sua documentação de código, e você deve aderir a isso. No entanto, geralmente, eu defendo que a documentação do código resida adjacente ao próprio código. Se isso não for viável, considere usar um submódulo git ou seu equivalente no sistema de controle de versão de código escolhido. Se a documentação não puder estar no repositório principal, ela deve pelo menos residir no submódulo git.