Antes tarde do que nunca: mais uma atualização sobre o progresso de desenvolvimento do nosso jogo,
Warpunk!
Antes de tudo, vamos explicar esse “atraso”:
Eu (Junior_Djjr) sempre pensei neste jogo como algo rápido, a ideia inicial era que uma versão beta seja lançada no início de 2021, mas por fim estou trabalhando no jogo praticamente sozinho, e mesmo assim, eu também comecei a recriar a MixMods no WordPress, e eu, junto com parte da equipe 2nibble, estamos iniciando um e-commerce (ainda secreto) previsto para Dezembro, portanto tudo está muito corrido, criando o site, estudando o assunto, praticando e montando o estoque. Eu até mesmo voltei para a administração do
GTA Brasil, trabalhei muitíssimo e parei de novo, e a
nova versão da CLEO+ que ficou 6 vezes maior do que a atualização da CLEO 4. Então, é, esta “demora” não foi atoa, eu nunca de fato foquei em desenvolvimento de jogos.
E ainda, recentemente eu tive uma entrevista de emprego para o cargo de Especialista em Unity Engine numa empresa brasileira que trabalha ou já trabalhou com a Globo, Folha de São Paulo, Saraiva, AVON, Abril, Valor Econômico, Philips, Honda, Mercedes-Benz… O meu cargo seria para o desenvolvimento de aplicações para Microsoft Hololens através da Unity Engine. Eu estou esperando o resultado, mas seja qual for, farei uma postagem aqui sobre isto ter me inspirado a continuar — mesmo se eu não for aceito, o que é provável pois eu não tenho experiência de trabalho, só a oportunidade já me deixou feliz.
Inclusive, eu mostrei Warpunk e IMPUNES na entrevista, isto me obrigou a antes passar uma semana polindo o jogo (se bem que eu acabei mostrando rápido demais, nem chegou perto de alguma chance de bug), assim o Warpunk hoje está com excelente estabilidade, praticamente sem bugs conhecidos (mas ainda bastante prototipado). Eu também poli o nosso outro jogo guardado na gaveta, mas nem cheguei a mostrar (pois os 8 GB de RAM aqui não aguentava 3 Unity abertas ao mesmo tempo).
Vídeo gameplay #2
Como de costume, um vídeo do gameplay atualizado!
O que foi trabalhado?
Eu estou gostando de contabilizar o tempo gasto no jogo, pois este jogo é mais como uma prática e desafio pessoal. Não faço ideia de quantos dias trabalhei neste jogo desde a última publicação. Considerei 2 meses, acredito que estamos no mês 6. Mas com certeza passou das 15 mil linhas de código (lembrando que agora foquei em polimento).
Um dos meus focos nesse meio tempo foi no sistema de construção.
Embaixo do minimapa há botões que na versão final serão preenchidos com diferentes visualizações do mapa, e um deles, faz aparecer a grade no mapa todo, para você saber onde é possível ou não construir algo.
Enquanto posicionando a construção à ser construída, caso ela precise de uma fonte de energia e/ou recursos, e não há nenhuma próxima, piscará o ícone informando a falta.
Ainda pretendo mudar, pois pisca a cada 1 segundo e pode atrasar o jogador nesta decisão, colocarei “sub-ícones” nos cantos dos quadrados, assim sempre visíveis.
No momento o pipeline URP da Unity não suporta decals ou projectors, felizmente encontrei um ótimo shader do Kink3d para isto. É screen-space (ou seja, não é renderizado no mundo, mas sim na sua tela), consegui fazer parecer ser renderizado somente no chão simplesmente alterando a ordem de renderização. Gostei do resultado.
Inspirado em vários jogos RTS, como Earth2150, as luzes no chão são indicadores de recursos disponíveis à serem coletados (quanto maior e mais brilhante, mais recursos disponíveis, e abaixam com o uso). Somente a coleta de recursos consegue ser construída em cima destas luzes.
Tais campos de recursos são bases, mas, lembre-se, isto é um jogo open world, você não é obrigado a usar aquele campo de recursos para construir sua base lá, você pode procurar por outros campos espalhados pelo mapa para utilizá-los, construir sua base principal longe do campo etc. Não existe bases fixas (pelo menos não no modo normal), e a opção de mapa procedural faz com que você nunca saiba onde estão.
O progresso de construção usará uma sequência de modelos que trocam entre si.
Foi necessário usar o método mais simples possível, não há nem animações (além do crossfade com alpha dithering), pois somos uma equipe pequena (inclusive eu tive que modelar todas as construções sozinho, exceto a de pesquisa que o Vítor fez a base), então o jogo precisa ser simples para que seja fácil de expandir.
Também preferi o alpha dithering pois é genérico, diferente de um shader dissolve que é “mágico” demais para o estilo do jogo.
Outro detalhe é que o mesmo progresso de construção é usado para a “desconstrução” durante a demolição de uma construção/estrutura destruída, com a única diferença de que os objetos de materiais de construção são ignorados. Eu acredito que o resultado ficará excelente junto com efeitos especiais de fumaça e poeira.
Também recriei o efeito especial de chuva utilizando o VFX Graph, para que seja processado na GPU.
Como sempre, a direção da chuva é influenciada pela direção do vento (assim como fumaça e vegetação).
O tema deste cenário em específico é floresta tropical brasileira, portanto, faltava casas brasileiras lá.
Lembrando que o jogo se passa num cenário apocalíptico (não confundir com pós-apocalíptico), portanto tais casas estão abandonadas. São destrutíveis.
Para poder reutilizar sem a criação de novos modelos (na verdade, eu ainda irei, mas para evitar), eu fiz um shader que possibilita a pintura de até 4 cores. Baseado nas coordenadas no mapa, a textura base e todas as 4 cores (2 na parede, 1 na porta e 1 na janela) são trocadas aleatoriamente.
Para deixar ainda mais natural, por volta da casa será gerado, aleatoriamente, props. Na imagem acima há um poço. Ainda pretendo fazer mais coisas assim.
Lembrando que, devido a existência de um editor de mapa, não pretendo focar tanto no mapa procedural, o resultado já está bem legal.
Por parte do Meck, ele modelou a unidade de construção para a raça/civilização steampunk.
Nós tivemos a ideia de usar simplesmente um caminhão que carrega recursos. A quantidade de recursos será visível na caçamba (e o número ao selecionar, é claro).
O caminhão vai até o local de construção, levanta a caçamba para “descarregar” os recursos da caçamba e assim iniciar a construção. Isto bate com a ideia da construção continuar sendo construída sem a necessidade de uma unidade de construção lá, afinal, a unidade de construção é só um transportador de recursos, e iremos preservar a simplicidade de não adicionar pessoas: não há pessoas visíveis trabalhando lá, é construído automaticamente.
Podemos aproveitar isto para possibilitar levar recursos de um local ao outro.
No momento a ideia de gameplay é um coletor de recursos, e um distribuidor deles. O distribuidor distribui recursos para construções próximas, e a unidade de construção pode reabastecer ou entregar os recursos lá quando quiser. Se você tem múltiplas bases ou é aliado à outro jogador, você pode levar estes recursos para outro local, basta fabricar várias unidades de construção, abastecê-las e fazê-las levar os recursos para um outro distribuidor, o que deixa o gameplay ainda mais open world e dinâmico.
Também já discutimos muito a ideia de incluir um trem para o steampunk, que possa viajar para entregar recursos e unidades, sobre os métodos mais simples de implementar, vantagens e desvantagens para o gameplay… Ainda não sabemos se será incluído, mas se for, será mais futuramente. Mas ainda existirá um pequeno trem para a coleta dos recursos — é obrigatório que steampunk tenha algum trem!
Prévias 3D otimizadas
Não só curiosidade técnica, mas esta dica também pode servir para outros desenvolvedores de jogos.
Anteriormente, cada prévia do modelo 3D na interface do jogo era uma renderização de uma câmera. PÉSSIMO para a performance.
Eu pesquisei por soluções de otimização e nenhuma realmente solucionava o problema, que é, a cada prévia, era necessário abrir e fechar uma nova renderização de câmera, e mesmo basicamente sem conteúdo, só o processamento da câmera já causa esse impacto.
A solução que idealizei foi simples: renderiza tudo de uma só vez, e corta a imagem final para múltiplas imagens.
Nota: objetos iguais foram renderizados separadamente pois, por testes, internamente são considerados diferentes. Eu já fiz a otimização de reutilizar objetos iguais.
Para isto, basta usar uma câmera ortográfica (isto é, sem FOV) para que todo o conteúdo, não importa a posição que está na câmera, seja renderizado igualmente, assim, posso dividir a renderização da câmera em uma grade, posicionar cada objeto em cada posição, renderizar, e cortar a imagem final.
O único problema é que se um objeto ser grande demais, ele ocupa parte do espaço do objeto vizinho, mas basta deixar uma boa margem para que isto não ocorra, e ao cortar a grade, considere essa margem, para que não fique um espaço sobrando por volta da prévia.
Isto faz com que a prévia não seja perspectiva, mas, quem liga? Deu um toque especial ao design, pois a prévia perdeu o efeito de profundidade, e eu achei que isto combinou mais com o fato da prévia estar na interface, que é 2D.
A nova performance desse método ficou abaixo comparado com renderização de poucas prévias (2 ou 3), a vantagem é, você pode renderizar dezenas de prévias que a performance continuará essencialmente a mesma (é uma complexabilidade praticamente constante).
Mas você pode pensar “ok, mas agora além de renderizar uma câmera com resolução muito maior, ainda terá que pegar esta imagem final e cortar,o corte não causa impacto negativo na performance?”.
Sim, não considerei multi threading ainda, mas por enquanto, a solução foi separar toda essa tarefa em 2 frames: nos frames ímpares, a câmera é renderizada, e nos pares, é realizado o corte, sendo assim, com o jogo em 60 FPS, a prévia será de 30 FPS (quem se importa? É só um modelo 3D rodando, ele poderia ser até estático), e nos frames que não está renderizando, o jogo usa os recursos para cortar a imagem do frame anterior.
O processo de corte é leve e rápido, mas mesmo assim foi uma ótima ideia que liberou um pouco de recursos neste outro frame, pois eu posso usar os frames pares para separar outras tarefas do jogo e assim nivelar a performance novamente, pois no momento, esta decisão fez com que os frames ímpares fossem um pouco mais lentos do que os pares (e eu sei que isto é péssimo).
No momento somente as prévias de pesquisa estão com esse novo sistema implementado, eu ainda implementarei no resto.
PunkScript
Já é mais do que provado que, uma das melhores ferramentas de modding, é a possibilidade de adição de scripts externos à linguagem interna do jogo, por exemplo, CLEO para GTA.
Pensando nisto, estava mais do que óbvio que eu (Junior_Djjr) iria implementar algo assim nos jogos que eu crio!
Warpunk haverá uma linguagem de programação interna intitulada “
PunkScript“, baseada em
Lua, interpretada por
MoonSharp.
Será programável no
Visual Studio Code (concorrente do Notepad++) utilizando uma extensão, semelhante a como mods CLEO hoje são feitos para GTA III/VC/SA.
Se linguagens de programação extremamente simples, como Sanny Builder e gta3script através da CLEO do GTA, já possibilitam mods incríveis, imagine isto com suporte oficial e utilizando Lua como base!
Lua é uma das linguagens de programação mais utilizadas no mundo, mesmo para jogos, seja total (por exemplo, World of Warcraft) ou parcial.
Não só como ferramenta de modding, mas isto também simplifica o trabalho do próprio desenvolvimento do jogo, separando a linguagem principal (no nosso caso, o C#) para uma linguagem mais simplificada para os trabalhos mais simples. Literalmente todos os GTAs, desde o 1 ao 5, usam linguagem interna para programar as missões. De Lua deve haver muitos, mas um exemplo que eu tenho em mente é Metal Gear Solid V, onde boa parte do trabalho do jogo é realizado em scripts Lua (inclusive missões?).
Ainda é um protótipo, mas muito provavelmente usaremos isto para programar o modo campanha singleplayer. Isto é, você poderá criar as suas próprias missões e modo campanha, ou baixar em forma de mod!
Não só Warpunk: Isto tudo pode ser tratado como uma versão alpha/beta de linguagens internas para os nossos próximos jogos. Se IMPUNES voltar, você pode ter certeza absoluta que também implementaremos isto nele.
Também utilizaremos para testes práticos de desenvolvimento direto na própria build. Sabe aqueles jogos que têm um console para digitar comandos? (comum em jogos da Valve) Isto, mas não só uma linha, de fato existirá uma maneira de digitar e rodar scripts inteiros, tudo in-game. Pode ser muito útil para testar gameplay no modo editor.
Lembrando que muitos jogos modernos, inclusive o nosso, basicamente não existe crash, caso algo errado ocorra o script simplesmente é interrompido com uma mensagem de erro minimamente compreensível, portanto os mods, mesmo que mal feitos, não irão destruir o seu gameplay. Ainda não tenho certeza se suportará modo de depuração.
Eu pensei em já implementar isto no
NPD, mas seria no mínimo uma semana de trabalho (desconsiderando futuros suportes e atualizações, visto que é algo novo que ainda estou experimentando) pra um jogo que quase ninguém se interessa, então eu acho que não vale a pena.
Nos siga no Facebook e Twitter para acompanhar o desenvolvimento deste e outros projetos. 
