Como nós criamos um jogo em 9 dias?

Atualização 2:
Veja o vídeo mostrando a reação do organizador da game jam, um resumo do gameplay, cena do plot twist final e um making-of de 15 minutos mostrando imagens e vídeos de como foi o desenvolvimento deste jogo do início ao fim:

No texto abaixo, neste artigo, você encontra informações mais profundas.

Atualização 1:
Nós vencemos a game jam como "Melhor qualidade técnica"!

E ao contrário do que o Amdré pensou, nós não usamos assets kkk
Postagem na MixMods aqui.

Nós da equipe 2nibble criamos um jogo open world em somente 9 dias!

Ele é parte de uma game jam (Game Jaaj 3) com tema "Nem tudo é o que parece". O quê? Termine o jogo para entender!

Já está disponível para download aqui:

gamejolt.com/games/npd/427758

Postagem na MixMods aqui.

Eu vou falar um pouco (quer dizer, muito) sobre como foi o desenvolvimento desse jogo, e suas curiosidades e dificuldades que passamos — o que aprendemos, o que erramos...

Se você está aqui só para entender o final do jogo, vá para o final do artigo.

Se você não nos conhece:
Eu sou o Junior_Djjr, criador do atual maior site de GTA da América Latina (MixMods), e quem mais criou mods para GTA no mundo até hoje (Workshop).
Meck é um excelente designer 2D e 3D, e Vitor Kuhn tem foco em 3D (principalmente na parte arquitetônica), e Farias é um programador e modelador que trabalha profissionalmente com Unity e Microsoft Hololens.

Como a ideia surgiu?

Meio-dia do dia 12 foi liberado o tema da game jam, "Nem tudo é o que parece".

Foi justamente o tema que eu (ou nós) mais reclamei, pois qualquer jogo que não seja um Tetris tem isto em algum momento...

Depois de pensar durante algumas horas, eu tive a ideia de um jogo de enigmas que trabalha com múltiplos cenários onde nada é o que parece.

Um exemplo: Você está num plano branco, mas encontra um ponto preto, e quando chega naquilo, você descobre que na verdade você era um ser microscópico numa folha de papel.

Depois de adaptações, saiu a ideia final.
Atualização: eu assisti as lives dos 50 melhores jogos e aparentemente ninguém pensou nisto que eu pensei, uau, era uma ideia legal também.

Eu vou falar melhor sobre a ideia do jogo no final do texto, pois não quero dar spoiler agora.

Como começamos?

O organizador, Amdré Young (sim, com M), recomendou as pessoas pensarem 2 dias na ideia e organização do projeto antes de, de fato, começar a trabalhar no jogo.

No nosso caso foi diferente, no final da tarde nós já estávamos começando o jogo, e ainda tirando mais ideias. De início este gameplay de entregar pizzas seria só parte do jogo, mas rapidamente decidimos que o jogo todo será isto.

Como já devem saber, nós utilizamos Unity Engine para a criação de nossos jogos.

Eu comecei a modelar a base do mapa no Sketchup 8 (nós usamos esta versão pois é grátis para uso comercial).

Nós pensamos em um gráfico cartoon, mas ainda ficção científica, como Cyberpunk, mas era muito trabalho adicional.

Foi escolhido um gráfico lowpoly art pois é o tipo de jogo mais fácil de ser criado e ter bons resultados.

Sério, se você está afim de criar um jogo 3D, tente o estilo lowpoly art, você notará o quão é fácil conseguir bons resultados gráficos!

E o estilo cartoon nos possibilita não se preocupar com escalas, assim podemos criar prédios e casas grandes que ocupam maior espaço, assim sendo mais fácil de preencher o cenário.
Também, nós gostamos muito do estilo cartoon, principalmente os carros — e eles ficaram ótimos! Muito bonitinhos.

Eu fiquei encarregado da base do mapa e algumas poucas construções. Vítor Kuhn ficou encarregado de modelar todas as casas e prédios, além dos props. Eu só ia dirigindo as coisas.

Foi também eu que posicionei todos os objetos no mapa, além de cuidar do gráfico do jogo e projeto da Unity em geral.
Farias trabalhava em um projeto da Unity separado, e assim depois de um tempo nós juntávamos os dois projetos num só. Foi interessante fazer assim em vez de usar ferramentas git pois não nos preocupávamos com organização nenhuma, assim o projeto ficou mais desorganizado, mas por outro lado, mais ágil por se tratar de algo em curto prazo.

Trânsito e carros

Farias fez um trabalho fenomenal com a programação do jogo.

Se já é incrível um sistema de trânsito ser criado em 9 dias, o que dizer de um jogo todo, que inclui o sistema de trânsito?

Realmente, nós não compramos um sistema de trânsito pronto, o trânsito foi programado nos primeiros dias de desenvolvimento — isto explica alguns bugs, mas para uma game jam, está ótimo na nossa opinião.

Eu fiquei encarregado de posicionar os pontos (nodes) do caminho onde os carros serão spawnados e irão andar. Mesmo com o Farias criando um simples editor para agilizar as coisas, só isto demorou quase 2 dias (junto com os nodes do GPS).

Em detalhes ficou até caprichado demais para uma game jam — há até diferentes regiões com diferentes veículos.

Os carros foram modelados pelo Meck, num estilo lowpoly cartoon — tetos altos, rodas pequenas, encurtados — e a física dos veículos é a Randomation Vehicle Physics, que pagamos 240 reais na época, mas agora é grátis...
Eu a configurei para ter uma dirigibilidade relativamente ágil, de alta aceleração e baixa velocidade máxima, para evitar o jogador atingir altas velocidades num mapa desse tamanho.

Todos os veículos do jogo têm dirigibilidades diferentes, com diferentes pesos e velocidades. Inicialmente foi pensado em poder escolher qual carro usar (podendo assim liberar, e cada um com sua velocidade e cabe uma quantia de caixas, sendo um jogo mais tático na escolha), mas depois esta ideia foi deixada de lado. De fato, todos os carros do jogo podem ser controlados pelo jogador, na teoria (mas eles não têm portas).

GPS

O sistema de GPS também foi programado pelo Farias durante a game jam. E foi incrivelmente rápido! Em poucas horas tudo já estava funcionando.
Normalmente sistemas de GPS usam o próprio caminho dos carros como base, mas houve dificuldades nisso e decidimos usar um caminho próprio independente, também porque nem todos os caminhos terá carros. Isto explica o motivo do GPS não ser tão preciso, pois ele tem baixa definição, há poucos pontos definidos, para agilizar as coisas.

Desempenho

Um dos maiores problemas de desempenho que o jogo tem no momento é o fato de não criarmos LOD (Level Of Detail), sendo assim, mesmo se você estiver do outro lado do mapa, todos os detalhes dos modelos serão renderizados, em vez de renderizar um modelo de baixa definição.

Nós iremos lançar uma nova versão com isto corrigido!

Atualização: Nós fizemos os LODs e o FPS subiu em torno de 30%. A nova versão pós-game jam já inclui esta otimização.

O mapa visto de cima, totalmente completo na tela, tem em torno de 900 mil triângulos; 1,5 milhões de vértices.

Parece muita coisa, mas mesmo assim o desempenho é bom para números tão altos, pois o número de draw calls é somente 2,6 mil — ok, também não é um número tão baixo, visto que é quase metade de uma cena comum do GTA V, e é a média de ruas principais do GTA SA, mas poderia ser muito maior.

Para quem não sabe, draw calls é algo extremamente importante para o desempenho em placas de vídeo modernas, pois tais placas hoje conseguem renderizar milhões de vértices facilmente, mas ainda não gostam de interrupções, e o draw calls é, à grosso modo, interrupções de renderização.

Logo após eu terminar a base do mapa (que é o chão com ruas)...

...Eu primeiramente adicionei na Unity utilizando um material para cada cor.

Resultado:
4000 draw calls
200 FPS

Em seguida, eu o alterei para utilizar uma textura de paleta, ou seja, o mapa todo foi renderizado em somente 1 material, e cada cor era 1 pixel desta textura.

Resultado:
30 draw calls (!!!)
4000 FPS

Sim, o 20 vezes mais FPS!!!

Não é um mistério, com qualquer pesquisa básica sobre criação de jogos lowpoly art você aprenderá que se deve usar texturas de paleta, e eu aproveitei este projeto para fazer o teste, e sinceramente eu não esperava uma diferença tão grande assim.

Isto acontece porque, se você tem uma mesh utilizando o mesmo material, normalmente (depende shaders e luzes) será renderizado em somente 1 draw call — de uma vez só. Caso contrário adicionará mais draw calls.

A textura usada para o mapa acima é a seguinte:

Ops, eu acho que vai ser difícil enxergar assim, vamos dar um zoom de 32 vezes:

Ou seja, cada cor, um pixel da paleta. Isto é legal pro desempenho mas impossibilita a troca de texturas, como já tentaram por mod:

Algo engraçado é que às vezes nos víamos discutindo se vamos usar textura de 4 ou 6 pixeis. Tipo, quê? São só 2 pixeis! Discussões assim dificilmente acontecem entre 512 e 1024 pixeis, e estávamos discutindo 4 ou 6!!!

Ah, e se você pensa em criar um jogo assim, lembre-se de desativar a filtragem e compressão na textura, visto que não faz o menor sentido e a filtragem irá criar degradês entre os pixeis — até pode ser útil para criar por exemplo todo o arco-íris, mas não é uma prática tão boa confiar na maneira que uma filtragem funciona na sua placa de vídeo, pior ainda se a pessoa querer forçar a ativação ou desativação do anisotropic filtering, ou mesmo qualquer tipo de filtragem.

E sobre colisão... Nós nem iríamos usar primitivos, mas nos últimos dias mudamos de ideia — erro meu, eu tava fazendo drama demais, no fim das contas foi muito fácil e rápido.

É excelente usar primitivos como colisão em vez de mesh collision, por causa do desempenho, mas isto (principalmente porque tudo foi feito rapidamente) impossibilitou o personagem entrar nas casas, subir as escadas, andar corretamente nos tetos etc. — pra quê? Não era necessário pro gameplay, o desempenho valeu mais a pena.

Cores

Algo que certamente deu um toque especial ao jogo.

Para variar a cor das casas e prédios, para o mapa não ficar repetitivo, bastou criar um simples script que altera a cor (no caso, a textura de paleta) daquele prédio ou casa. Então, sendo que o jogo é cartoon, por que não deixá-lo todo colorido?

Desde o início o gráfico do jogo nos lembrou The Simpsons Hit & Run (também conhecido como "GTA dos Simpsons").

As cores não foram por acaso, eu utilizei o site paletton.com para escolher combinações de cores harmônicas no modo "triad".

Cada prédio e casa usa uma textura de paleta 2x2 pixeis, mas normalmente são só duas cores, e a cor do teto.

Assim existe 8 variações cada prédio, e outras 8 cada casa.

O mesmo princípio é usado na variação de cor dos carros.

Personagem

O personagem "sem nome" foi modelado pelo Meck

Houve uma certa inspiração no modelo de pessoas do jogo RollerCoaster Tycoon 3.

As animações de movimento são do site Mixamo — um excelente site!!! As animações foram editadas pelo Meck.
De início estávamos preocupados pelas animações serem "realistas demais" para um jogo cartoon, mas na prática ficou excelente.
Há também variações de textura para roupas, saia com cabelo longo, e boné, já pensando na adição de pedestres, mas infelizmente não houve tempo de adicionar sistema de pedestres no jogo — eu acho que precisávamos de mais uns 2 dias, considerando que também seria necessário posicionar cada node de caminho nas calçadas.

Sistemas

Até mesmo o sistema de movimentação do personagem foi programado pelo Farias completamente durante a game jam, assim como a câmera. Ambos não perfeitos, mas impressionantes para um projeto grande de pouco tempo.

O gameplay de entrega, de início, era simplesmente entregar e mais nada, e iríamos usar um carro, mas depois foi decidido usar uma caminhonete pickup onde as caixas de pizza ficam na caçamba, com física, e este seria um dos desafios do jogo. Foi uma excelente decisão, pois o gameplay ficou muito mais divertido e tático — há até a técnica de estacionar, ir na traseira e ficar apertando F (não tão rápido) para reorganizar as caixas caso elas estejam prestes a cair.

Eu gostei muito pois acontece casos interessantes onde você perde todas as caixas e fica puto, ou todas as caixas sobem alto e caem corretamente e você se sente um ninja.

E sim, a primeira entrega ser do outro lado da ponte foi de propósito para os jogadores aprenderem a física da pior maneira!

O trem é outra coisa que ficou muito marcante no jogo, além de bonito por ser todo colorido, a ideia foi muito boa para fechar aquele lado do mapa.
A ideia inicial era de uma rodovia com caminhões passando em alta velocidade, do Meck, na qual ele mesmo em seguida disse que poderia ser trem mas não fazia muito sentido. Discordei, faz muito, e gostei muito do resultado!
O sistema de trem infinito é na verdade muito simples, é simplesmente 60 vagões criados e guardados num array, onde quando o primeiro passa do ponto, ele é teleportado para trás.
O som dele segue a câmera na coordenada X (leste-oeste) — não deu tempo da gente pesquisar por uma maneira mais correta, mas esta solução funcionou perfeitamente bem.

Em geral todos os sistemas apresentavam pequenos bugs ao decorrer dos testes, e foi um saco, pois ficamos até os últimos minutos da game jam trabalhando, a ponto do Farias me dar suporte por celular para corrigir os bugs, pois nas últimas horas ele estava fora de casa e havia bugs importantes para serem corrigidos antes da liberação.
Nós tivemos que liberar o jogo com alguns bugs já sabidos, como o bug de andar com o carro mesmo fora dele, algo que não deu tempo de corrigir.

O que aprendemos?

Nós não deveríamos ter escolhido algo tão grandioso, e se tivesse, devíamos ter dado AINDA MAIS foco — ou não, pois no meu caso, no dia que eu posicionei os últimos props pelo mapa eu passei muito mal, de madrugada comecei a ter dores de cabeça, tontura, e mesmo assim continuei por mais 3 horas, quando me levantei eu estava com muita tontura, barriga dura com dor, e quando fui dormir a dor só piorava, sem conseguir dormir 2 da tarde, foi horrível, e estranhamente quando eu acordei tudo sumiu.

Ou seja, acho que seria melhor realmente termos escolhido algo um pouco menor...

Mas se fizéssemos de novo, nós faríamos isto facilmente com MUITO mais! Nós adquirimos grande conhecimento com este projeto, e é este o motivo principal da existência de game jams, um desafio para você desenvolver um jogo num prazo, e você se sente forçado a apontar um objetivo até certo dia, em vez de deixar objetivos e prazos abertos, algo que lhe faz trabalhar durante anos e liberar nada...

O que funcionou para nós foi não utilizar ferramentas de produtividade! É, você leu um "não" ali.

Normalmente nós da equipe 2nibble utilizamos GTD e Scrum como metodologias de desenvolvimento, mas agora que estávamos participando de uma game jam, não usamos, e não nos arrependemos! — E provavelmente algumas pessoas espertas vão tacar pedra na gente.

Existe um fenômeno onde, se você é organizado demais, você passa mais tempo se organizando do que de fato trabalhando. Eu não lembro o nome técnico disso, mas é algo como uma procrastinação justificada.

Nos víamos entre parar tudo o que estava fazendo para criar um novo projeto no MeisterTask, ou continuar trabalhando. Melhor continuar trabalhando, não?
O projeto era pequeno e os objetivos eram muito claros:
Eu faço a base do mapa, posiciono tudo e cuido do projeto da Unity;
Farias programa tudo o que é necessário;
Meck modela carros, personagem, animações;
Vítor Kuhn modela construções e props.
Os objetivos são claros e seus sub-objetivos são feitos em somente algumas horas, portanto não sentimos a necessidade de organização de tarefas.
Na verdade, só sentimos uma necessidade do MeisterTask no final, onde listávamos os bugs, mas simplesmente usamos mensagem no Discord, onde listávamos lá mesmo. Foi ok, mas houve alguns pouquíssimos casos de bugs que não foi corrigido, na qual eu acho que se tivesse utilizado MeisterTask provavelmente isto não teria acontecido.

Ou seja, sejam organizados, mas não tanto!
Na minha opinião eu acho que coisas de curto prazo merecem menos organização. Boa organização é útil principalmente para o médio e longo prazo.

Também aprendemos o quão fácil é criar um jogo em lowpoly art, é incrível como qualquer coisa fica bonita facilmente quando você consegue uma boa configuração gráfica — e de fato você consegue somente com o Post-Processing Stack da Unity. Eu utilizei ACES como tonemap.

Todos nós da equipe adoramos o resultado, não esperávamos nem 20% do que conseguimos! Mas mesmo assim há parte que esperávamos, e não conseguimos, como os pedestres, que infelizmente não deu tempo de adicioná-los. Eles seriam inspirados no Midnight Club 3, onde simplesmente pulam desviando, não podendo atropelar (sem colisão).

Haveria também ciclo de dia e noite, mas isto não é prioridade vendo que o jogo mal tem sons e partículas, nós primeiro devíamos corrigir todos os bugs e adicionar os básicos que um jogo precisa, para só depois pensar em adicionar o ciclo de dia-noite.

Até mesmo a música tema ficou de fora. Ela seria uma versão cartoon da minha música Djjr - Drug Effects, na qual é inspirada na Tarantella, a famosa música italiana.

Abaixo há spoilers sobre o final do jogo.

Se você ainda não jogou, jogue e veja por si só! Roda em quase qualquer PC, grátis e só 23 MB...

Se você já jogou ou não está afim, continue lendo:

SPOILER

Por que "Nem tudo é o que parece?"

Recapitulando, o tema da game jam era "Nada é o que parece", ou "Nem tudo é o que parece" — nós tínhamos que fazer um jogo com este tema.

Se mesmo terminando o jogo você não entendeu, ou você não está afim de jogar, está aí a explicação:

Todo o jogo é uma metáfora:

As caixas de pizza são os bits que você entrega num processador.
É tão óbvio que está escrito "BIT" no nome da caixa — algo que fizemos questão de deixar óbvio para o jogador, para ele no final pensar "nossa, é mesmo!"

O nome da caminhonete é "RAM" em referência à memória RAM entregando os bits — o que se bate com uma caminhonete real: Dodge RAM.

É outro detalhe que deixa óbvio para o jogador, a todo o momento está na tela dele escrito "RAM" e caixas chamadas de "bit", provavelmente uns nerds percebem isto facilmente, mas quem não percebe e entende no final, fica chocado o quão óbvio isto era — foi o nosso objetivo.

Foi muito difícil balancear o óbvio do não tão óbvio. Por exemplo o escrito "RAM" é estilizado, e isto ajudou a mascarar, já que as pessoas não têm em mente que um escrito estilizado tem relação com computação.

O OVNI (objeto voador não identificado) não é tão não identificado assim: ele é uma metáfora para um vírus.

Isto fica óbvio no último segundo de jogo, onde a tela do PC fica azul com a mensagem "Vírus detectado".

O mapa do jogo, desde o início, foi criado pensando no formato de uma placa de circuitos.
Mais especificamente, a inspiração inicial veio desta imagem:

É como se cada rua fosse uma linha do circuito, como mostrado após a cena do disco voador:

É por isso que todas as ruas do jogo só foram feitas em ângulos de 0, 90° ou 45°, o mapa do jogo não tem curvas.
Foi excelente pois também facilitou a criação do mapa, possibilitando um mapa muito grande para os padrões de uma game jam.

Também, para provar que nós realmente criamos este jogo durante a game jam, eu fiz questão de fazer as ruas escrevendo o nome "GAME JAAJ III", que é o nome desta game jam.

E a cena final de revelação, onde a câmera sai de dentro do CPU e se afasta até o monitor, revelando que a todo este momento você estava dentro do CPU, e a cidade era só uma metáfora.

Originalmente não seria assim, nós queríamos colocar o menu do jogo na tela do PC, assim a câmera vai para o monitor e você termina no menu! Como se fosse um loop: você joga o jogo para enviar os bits para o menu do seu próprio PC funcionar, ou algo assim — aberto à interpretações.
É algo bem mindblow, mas já estávamos com o tempo estourado e isto poderia causar algumas complicações, como ao utilizar monitores com diferentes proporções.

Assim, decidimos simplesmente colocar a mensagem "Você entregou todos os bits!", que é a última chance do jogador entender qual era a metáfora, e em seguida "Vírus detectado" para indicar o disco voador que te abduziu, algo que também ficou legal.

Ainda há ester eggs que indicam que você não está numa cidade comum, como estas vegetações em forma de capacitador:

Dá para considerar mais coisas também: Nibble, o nome do jogo, além de vir do nome da nossa equipe (2nibble), a palavra "nibble" (nibou) significa "mordiscar" ou "mordida pequena", que combina com pizza, mas também 1 nibble é a metade de um byte (de "bite", de "morder"). Então até o nome do jogo é "Nem tudo é o que parece"! Pois você pensa que é sobre mordiscar, ou o nome da equipe, mas na verdade há bits até no nome do jogo!

Mas de onde diabos veio a ideia do jogo?
Você lembra que a ideia inicial era enigmas que se passa em diferentes cenários com diferentes escalas? Então, um dos enigmas eu idealizei como uma cidade onde você anda com um carro, e depois você descobre que aquela cidade era os circuitos do CPU.

(eu censurei uma parte pois é spoiler de outro jogo que estamos desenvolvendo)
O Farias aprimorou a ideia adicionando pizza:

E foi daí que tudo começou. Nós começamos poucas horas depois do tema da jam ser revelado. (umas 3 ou 4 horas) e trabalhamos até os últimos minutos. Ou seja, foi um tempo de trabalho de mais ou menos 8 dias e 8 horas — visto que o tempo total da jam foi de 8 dias e meio.

Continue seguindo a nossa página do Facebook para ficar por dentro de nossos próximos trabalhos:
www.facebook.com/2nibble

E é claro, o nosso site:
2nibble.com