Outros

Se eu (Junior_Djjr) acredito que Unreal 5 é a melhor engine do mundo, por que eu ainda recomendo você, um desenvolvedor indie, a escolher usar Unity? Ou Godot?

Sou co-fundador da equipe indie 2nibble, produtor do jogo IMPUNES, uso Unity há vários anos, mas eu comecei a focar somente nos últimos 4 anos, e não pretendo mudar.

Muitas pessoas me perguntam sobre isto, então decidi explicar aqui a minha visão sobre qual engine você deve escolher para começar a desenvolver jogos indies.

Unreal 5 é a melhor engine do mundo

…Para os jogos triple-A, pois para indies, na minha opinião, Unity é a melhor.

Pronto, isto foi um TLDR, mas vamos continuar…

Eu não preciso explicar os motivos da Unreal, principalmente a Unreal 5, ser uma engine de jogos tão incrível, pois a internet inteira faz esse trabalho e com certeza você já está enjoado de ver gente falando disso.

No entanto, há algumas coisas específicas que se destacam mais e são muito noticiadas pela mídia: Nanite, Meta Human e Lumen…

Nanite

Nanite é realmente uma tecnologia muito impressionante que será cada vez mais comum vermos engines de jogos usando algo similar a isto, mas eu tenho alguns “poréns” para fazer.

Esta imagem demonstra um uso onde Nanite é realmente útil.

A grosso modo, possibilita o uso de modelos 3D com bilhões de polígonos sem muito impacto no desempenho. Funciona com um incrível algoritmo que consegue definir quais polígonos precisam ou não precisam renderizar. Por exemplo, se um polígono é menor que 1 pixel, ou está sendo ocluído por algo, ele não precisa ser renderizado. Você também não precisa fazer vários níveis de LOD pois os polígonos automaticamente se ajudam nisto…

…Ou precisa? Afinal, LOD não é só diminuir a quantidade de polígonos. Por exemplo, um prédio, de perto ele é HD, highpoly, janelas com profundidade etc. De muito longe, ele pode ser representado simplesmente por um cubo com uma textura tiling de 64px com o desenho da parede e janelas, tudo isso num único material, única mesh, única textura, através de LOD. O Nanite não vai fazer isto para você, o modelo continuará renderizando bastante polígonos (ainda menos que de perto), o que é visualmente superior, mas de muito longe você nunca notará diferença comparado com um cubo com textura lowres, que é sempre muito mais performático. E você ainda pode usar um shader mais simplificado para ser usado de longe etc.

Em geral, soluções de otimização manuais acabam se sobressaindo em comparação com soluções automáticas, e as soluções automáticas acabam sendo melhores em casos específicos, ou como “atalhos” para diminuir a carga de trabalho do desenvolvedor.

O que é mais performático? Um algoritmo que está constantemente tentando otimizar a quantidade exagerada de polígonos do seu jogo, ou, simplesmente, os polígonos e draw calls não existirem?

Sim eu sei que Nanite é mais que otimizar os polígonos de uma mesh, mas perceba que esta tecnologia é um caso de uso muito específico que, na real, não substitui totalmente o método convencional e só é útil para jogos extremamente highpoly, tanto que essa tecnologia normalmente é apresentada em uso de meshes exageradamente highpoly, como 3D scans com milhões de polígonos, ou seja, casos de uso que jogos normalmente não fazem e provavelmente também não será o seu caso.

Você vai fazer um jogo deste nível? Sim? E realmente é mais performático do que um bom uso de LOD? Então ok, vai lá. Mas se não é o seu caso de uso, não faz sentido você usar a existência desta tecnologia para decidir qual engine escolher.

E ainda falando sobre o uso de LOD, sempre que as pessoas compararam Nanite com LOD, usam demonstrações claramente ruins de uso de LOD. Neste sentido, Nanite realmente ajuda, no entanto, um LOD muito bem criado é mais performático, e com qualidade visual muito próxima do Nanite.

Por exemplo, você tem resultados altamente otimizados com o uso de LOD hierárquico para jogos de mundo aberto grandes (GTA V por exemplo usa esse método) e uso de LODs “impostores” para objetos mais complexos, como vegetação: funciona usando uma única face com um algoritmo que converte o ângulo de visão para uma parte da textura, aumenta um pouco a VRAM mas é muitíssimo otimizado com excelente resultado visual, nós usamos no IMPUNES.

Nota: poderia ser um único triângulo, mas algo mais redondo é bom para cortar os pixels inúteis de passar pelo shader.

Detalhe que a versão chinesa da Unity já tem a sua própria “Nanite” (e Lumen também). Ainda não é esperado que chegue pra versão “normal” da Unity, mas eu acredito que tudo é questão de tempo.

Outra, Nanite tem limitações, só funciona em geometrias estáticas (sem nenhuma deformação), não pode ser usado em geometrias finas como cabelos, gramas, também não suporta faces que são muito próximas umas das outras e não suporta bem o uso de transparência. Mesmo que essas limitações sejam resolvidas no futuro, ainda assim, o meu ponto é que a mídia divulga ela como sendo uma tecnologia perfeita e que será usada em todos os jogos.

Em suma, Nanite é uma tecnologia incrível e de fato há utilidade, tanto que jogos triple-A começaram a usar recentemente, mas as pessoas têm que entender que não é perfeita e o uso dela é mais específico do que você imagina. Isto não te possibilitará criar um jogo mal otimizado, ligar um botão e automaticamente tudo é otimizado sem precisar criar LODs, não é assim que as coisas funcionam.

Meta Human

Com o Meta Human você pode criar personagens altamente realistas do jeito que você quiser…

…Ou não? Se você já tentou copiar uma pessoa real pro Meta Human, você vai notar que, na real, é a beira do impossível, pois é extremamente limitado e genérico.

Eu, sinceramente, não entendo o hype que se criou em torno do Meta Human. Reallusion Character Creator é muito superior, e consegue criar (muito bem) qualquer estilo de personagem, não só humanos realistas, mas também outros humanoides de horror, fantasia, cartoon etc.

No momento custa 300 dólares (1500 reais), enquanto Meta Human é grátis exclusivo para Unreal Engine, mas se você está criando um jogo do nível que precisa de personagens deste nível de qualidade, eu tenho certeza que você tem esse dinheiro para investir (e não estou sendo patrocinado). Além de poder usar em outras aplicações e engines. Perceba como que você tem algo melhor que Meta Human pra Unity.

Mas falando nisto… Você realmente está criando um jogo que requer este nível de qualidade para precisar de algo como Meta Human ou Reallusion Character Creator? Se sim, ok, vai lá, mas antes teste se o Meta Human realmente consegue te satisfazer, pois ele é bem genérico (tanto que eu já vi muitas pessoas reclamando que claramente dá pra ver quando um jogo foi criado com Meta Human, pois os personagens parecem mais genéricos do que devia). Mas se você não pretende criar jogos desse nível de realismo e detalhes, a existência do Meta Human não é motivo para você escolher Unreal, ou melhor, como eu expliquei, Reallusion Character Creator é melhor, e nele não importa qual engine você escolha.

Eu duvido que você viu alguém divulgando o Reallusion, mas você já viu muitos divulgando o Meta Human, certo? Por que isso acontece?

Só 1 ponto que eu critico muito: A licença dele, até o momento, não permite o uso para criadores de personagens in-game, algo que no Meta Human eu acredito que permita.

Lumen

Eu tenho alertas sobre Nanite, e críticas sobre Meta Human, mas Lumen eu tenho praticamente só elogios. E eu, e muitas pessoas por volta da comunidade indie da Unity, também adoraria que Unity trouxesse algo como Lumen.

No entanto, ainda dou um alerta: não existe almoço grátis, Lumen é muito mais pesado que outros métodos convencionais de iluminação, mas em geral, se você quer gráficos, vale a pena. Em geral, qualquer grande sistema assim há custo de desempenho e complicações de implementação, não há como você querer tudo ao mesmo tempo. Mas Lumen é um bom substituto para a iluminação por raytracing.

No momento, no IMPUNES a gente usa LUMINA, uma iluminação indireta global em tempo real que utiliza voxels (à grosso como, é como se fosse um raytracing de pixels 3D, sem o uso de baking estático e lightmaps) e é relativamente bem performática. Inferior ao Lumen, mas dá pro gasto.

Geralmente projetos de iluminação global realtime pra Unity usam Enlighten, que é também muitíssimo usada em jogos da Unreal. Ou seja, em outras palavras, a iluminação da Unity e Unreal podem ser basicamente iguais (tanto que muita gente pensava que IMPUNES era Unreal, pois a gente usava Enlighten). No momento o foco da Unity está no APV, que é uma iluminação bem melhor, ainda muito limitada, mas extremamente otimizada inclusive para mobile. Possivelmente usaremos como opção para PCs fracos no IMPUNES.

Demonstração do APV da Unity, não tão avançado e dinâmico quanto Lumen, mas é super performático.

Algo engraçado também é que a Unity sempre é ruim em escolher nomes para o marketing. Você consegue imaginar um vídeo no Youtube chamado “CONHEÇA O ADAPTATIVE PROBE VOLUMES DA UNITY!”? O nome “Lumen” é muito melhor!

No entanto, isto assim como outras features, é só questão de tempo até que a Unity ou a própria comunidade crie. Pois são baseadas em tecnologias, conhecimento tecnológico geralmente não patenteado (Lumen se baseia no SDF).

Só é importante sempre ter em mente que as comparações podem enganar. Lumen não tem uma diferença de iluminação tão diferente assim do Enlighten, mas de fato é um pouco mais realista e lida super bem com objetos dinâmicos (a iluminação passa em tempo real quando uma porta se abre etc), além de simplificar o desenvolvimento do jogo não precisando de baking e separação do que é estático e dinâmico, e por isso que realmente é tão superior.

Unreal é “open source”

Primeiramente, não é. Ela é “código-fonte disponível”, não é aberto, mas tanto faz.

O real ponto é que, Unreal Engine pode ser recompilada para fazer alterações no núcleo de como a engine funciona, e empresas triple-A gostam disso pois eles têm grandes mentes que podem expandir ou melhorar a engine para casos específicos de determinado projeto de jogo.

Você, um indie que está começando ou tem uma equipe pequena, realmente sente a necessidade de alterar o funcionamento da Unreal Engine e tem habilidade pra isto? Sim? Então ok, legal, mas se a resposta é “não”, isto não é motivo nenhum para você escolher Unreal.

Como eu disse, isto é muito útil para triple-A, muito raramente algum indie usará este benefício, e se usar, será algo mais voltado ao estudo técnico e não pela produtividade de um produto.

Outro ponto, Unity também é, em grande parte, “código-fonte disponível”, só não é do nível que você consegue recompilar a engine, mas você consegue sim alterar o funcionamento de grande parte dela, principalmente gráficos.

Falando nisso, mesmo sem alterar o código fonte da engine, você consegue criar novos pipelines para fazer o jogo renderizar do jeito que você quiser (o que é muito útil se você está fazendo um jogo com gráficos muito específicos, mais conceitual ou procura uma extrema otimização cortando e simplificando pedaços da engine gráfica).

Unity tem melhores taxas que Unreal

É difícil acreditar que as pessoas erram tanto quanto falam sobre este assunto, pois você encontra estas informações muito facilmente com segundos de pesquisa. Ou isto é preguiça, ou é desonestidade para vender a Unreal (por exemplo, quem vende cursos, enquanto eu vendo nada pra Unity, então não há motivos pra eu ser desonesto aqui).

Unreal: 5% após 1 milhão de dólares no ano.

Unity 6: 2,5% após 1 milhão de dólares no ano. No máximo.

Ou seja, a taxação da Unity é metade da Unreal, e nas versões anteriores a taxa é 0.

E vai mais fundo que isto: na Unity, existe 2 cálculos, o de vendas e o de engajamentos, e o que você vai pagar é o menor deles, não o maior.

Ou seja, se o cálculo com base em engajamentos seja um custo menor do que o de vendas, você vai pagar menos de 2,5%, até mesmo, 0!

Pra você ter noção o quão superior a Unity é neste sentido, se você fizer 10 milhões de dólares em lucros com o seu jogo, mas o seu jogo tiver menos de 1 milhão de engajamentos (num caso hipotético de um jogo muito lucrativo mas de poucos jogadores, o que pode acontecer num aplicativo caro para empresas por exemplo), na Unreal você vai pagar 500 mil reais de taxa, na Unity, você vai pagar 0. Sim, literalmente zero de taxa.

E se você usa a versão antiga (antes da Unity 6), a taxa sempre será 0, tendo de pagar só 11 mil reais (pois quando você lucra demais, te obriga a fazer upgrade pra versão Pro).

Geralmente a única crítica que a comunidade Unity ainda faz é que esse negócio de “engajamentos” é estranho e confuso, algo que poderia só tirar da jogada, mas lembrando, isto não foi criado para possivelmente cobrar mais, mas sim, para possivelmente cobrar menos.

Se você ainda não entendeu, Unity tem uma calculadora super amigável.

Espere… Por que você continua lendo isto? Você realmente acha que você fará mais de 1 milhão de dólares por ano com o seu jogo??

Toda essa discussão não tem importância nenhuma para pequenos desenvolvedores indies. Na verdade, essa é só uma técnica para engines lucrarem com jogos de alto sucesso, e inclusive, é muitíssimo apoiada por pequenos desenvolvedores, pois isto faz com que a engine busque a criação de maiores sucessos na indústria.

Eu, e muita gente, prefere que a engine cobre esses 2,5% do que cobrar nada, pois eu sei que não serei diretamente afetado, mas a engine tem maiores incentivos de evoluir em busca de criar grandes sucessos, portanto a própria engine melhora com esta visão de mercado. A não ser que eu faça um gigante sucesso, mas 2,5% não seria uma preocupação quando se tem 1 milhão de dólares por ano.

Há meio ano atrás, durante só 1 semana, o antigo CEO da Unity (ele era da EA, o que esperar dele, né?), anunciou que iria cobrar não por vendas, mas sim por instalações, uma ideia completamente idiota que faria a Unity cobrar por jogos grátis (é tão absurdo que, enquanto eu acompanhava esse “boom”, alguns caras da Unity respondiam que não, e outros que sim, nem eles estavam entendendo essa decisão). Detalhe, mesmo que tenha sido muito criticado, ainda era uma taxa muito menor que Unreal, o único problema foi cobrar por instalação e não por vendas, e que queria cobrar por jogos anteriores também (algo que devs de sucesso ficaram furiosos, pois não assinaram isto).

Uma ideia idiota que em só 1 semana voltaram atrás, o CEO foi expulso (ou ele mesmo saiu) e tudo se resolveu, mas até hoje pessoas pensam que Unity ainda está com essa ideia, que durou só 1 semana e levou a troca de CEO. Sendo que, na realidade, a ideia de taxa atual da Unity é melhor que a da Unreal, e o novo CEO da Unity é o cara da Red Hat, ex-presidente da IBM, algo que animou muito eu e a comunidade de desenvolvedores da Unity, inclusive a Unity 6 demonstra ótimo potencial (por exemplo o uso de I.A. para gerar o código da I.A. do seu jogo, sim, você pode digitar como um NPC deve reagir e a Unity gera a programação pra você) e anda sofrendo muitas mudanças que focam mais em jogos e menos em filmes etc. O novo CEO é um cara focado em open source, pode ser que com o passar do tempo a Unity foque mais nesse lado, e eu acredito que open source é o melhor caminho da evolução tecnológica.

O facão contra o canivete-suíço

Unreal: Um facão. Para casos específicos, você resolve tudo numa só facada.

Unity: Um canivete-suíço. Você pode ter dificuldade em alguns casos, mas consegue fazer de tudo.

Eu tenho certeza que você já notou que jogos indies conceituais geralmente são criados na Unity, e jogos realistas focados em gráficos, são criados na Unreal.

Não é atoa que jogos como Viewfinder são criados na Unity, pois, não só a engine, mas toda a comunidade é muito focada em um lado mais conceitual, enquanto Unreal tem uma engine e comunidade mais focada em realismo, uma busca incansável ao triple-A.

A comunidade é algo tão importante quanto a engine em si, pois é da comunidade que você encontrará ajudas, dicas, snippets, assets, inspirações etc. Você não vai criar seu jogo como se estivesse sozinho dentro de uma caverna.

Sempre que eu busco inspiração, eu entro no Reddit da Unity, e você pode perceber como a comunidade é conceitual, gosta de experimentar novas ideias. Às vezes eu fico horas olhando tudo. Alguns dias estão melhores que outros, mas sempre interessantes.

Em comparação, dê uma olhada no Reddit da Unreal, geralmente são só demonstrações cosméticas, eu sinceramente não me atraio por comunidades assim, mas pessoas são diferentes, provavelmente você vai se identificar mais com esse lado do game dev.

Mesmo que seja algo muito criticado, Unity tem uma separação de gráficos: HDRP, focado em gráficos realistas, e URP, focado em desempenho. Ignorando um pouco as críticas (válidas) desta decisão, há pontos positivos, pois o URP é uma maneira muito otimizada de criar jogos que não são altamente focados em gráficos (nós usamos no IMPUNES, mas falta muitas features que nos obrigam a comprar assets gráficos, o que indiretamente aumenta o custo do jogo). No entanto, HDRP, que teoricamente são os gráficos para competir com Unreal, mesmo que consiga excelentes resultados, tem menos otimização que Unreal, o que é mais outro motivo para escolher Unreal se o seu foco realmente são gráficos.

A real é que mesmo em questão de gráficos, Unity é muito forte. Sons Of The Forest, por exemplo, é um dos jogos atuais de gráficos mais incríveis, e é Unity.

Isto acontece principalmente porque Unity não atrai muitos desenvolvedores focados no lado cosmético, atrai mais programadores, e os experts em gráficos acabam preferindo Unreal.

Mas em geral, eu me sinto muito melhor em torno da comunidade da Unity do que Unreal, pois eu me interesso mais por ideias, conceitos, do que a luta incansável pelo triple-A-like.

Isto também tem muita influência pelos assets disponíveis. Afinal, qualquer jogo minimamente grande, vale mais a pena você economizar os custos comprando assets que são considerados secundários, e a Unity Asset Store é muito vasta, com muita coisa modular para diferentes ideias.

Um comentário à parte, a UI da Unity é muito mais bonita, limpa, moderna e organizada.

Oportunidades de trabalho

Não existe a menor dúvida de que há muito mais oportunidade de trabalho com Unity do que Unreal, principalmente quando o assunto é programação ou o uso geral da engine.

Unreal é uma engine quase que exclusivamente para jogos 3D realistas, você consegue fazer outras coisas com ela, mas não foi feita com foco naquilo. Não só a engine, mas a comunidade também não tem foco naquilo.

Enquanto com Unity você pode trabalhar com jogos realistas 3D ou 2D, estilizados 3D ou 2D, também tem ótimo suporte para o trabalho com animações / film maker em tempo real (sem a necessidade de renderização), muito usada não só para jogos mas mesmo aplicativos desktop ou mobile, mixed reality (AR/VR) e tal. PC, consoles ou mobile, Unity foca muito em multiplataforma, tanto que você portar um jogo para todas as plataformas, se o seu jogo não é tão complexo, é muito fácil e rápido, e Unity tem muito foco em que todas as features da engine funcionem em todas as plataformas, então se você está criando um jogo para PC mas que também quer para mobile, não precisa se preocupar tanto.

Por exemplo, nós da 2nibble ano passado fizemos um trabalho de VR para ser usado para treinar profissionais da saúde, e mesmo que possa ser feito com Unreal, o suporte de VR, e otimização da Unity pra isto é excelente comparado com Unreal.

Farias, da nossa equipe, trabalha há muitos anos com parceiros da Microsoft, hoje MVP da Microsoft, com Hololens 2, é claro, usando Unity.

Se você quer se aprofundar numa engine focando em oportunidades de trabalho, Unity é muito melhor, a não ser que você realmente queira se aprofundar especificamente em um trabalho mais voltado ao cosmético/artístico (o tal “facão” que eu expliquei), daí sim Unreal é melhor para você, mas você provavelmente trabalhará mais pro lado de freelancing e venda de assets.

Programação

Não importa se você é um programador experiente, iniciante ou nunca programou na vida, eu realmente recomendo Unity quando o assunto é programação.

Se Unreal é a engine perfeita para os designers gráficos de realismo, Unity é a engine perfeita para os programadores.

Não só pela engine e comunidade, mas eu sinto que a própria empresa demonstra bastante atenção aos programadores, enquanto eu sinto que a Epic Games pensa mais em investidores e marketing. Isto é muito notável quando se compara as apresentações anuais de ambas as empresas, a Epic Games normalmente apresenta Unreal mostrando os jogos que usaram ela, enquanto a Unity é uma apresentação muito mais técnica para desenvolvedores. Chega a ser até estranho a quantidade de tutoriais de programação que a Unity faz no canal do Youtube.

Unreal usa a linguagem de programação C++, alguns programadores mais nerds devem preferir, mas mesmo que prefira, vamos lembrar que C++ requer muito mais trabalho, muitas mais linhas de código, e portanto dificulta mais a produtividade comparação à Unity, que usa C#.

C# é uma excelente programação, pois é uma evolução mais “high level” do C++.

Para não causar confusões, “high level” se refere ao nível humano, não que necessariamente é melhor ou pior que as programações low level (nível de máquina).

Isto é, se em C++ você faz isto:

if (str.find(“example”) != std::string::npos)

Em C# você faz isto:

if (str.Contains(“example”))

Em geral, C# é uma programação muito mais amigável, humanamente falando, é muito mais agradável e simples de se programar, enquanto C/C++ é algo mais “cru”, ao nível de máquina, ainda muito preferida por programadores mais “raiz”, mas cada vez mais sendo deixada pra trás por soluções mais modernas.

Mas então por que C++ ainda é tão usada nas engines de jogos? A RAGE, da Rockstar Games, assim como muitas engines, também são C/C++. Isto é porque C/C++ lhe dá um acesso melhor ao nível de máquina, o que possibilita toques finos de otimização. Em geral, C/C++ é bem mais performático que C#.

Então Unity é menos performático que Unreal porque não é C/C++? Não, quem disse que Unity não é C/C++? A engine é, enquanto C# é só o código do seu próprio jogo.

Em outras palavras, toda a engine é altamente otimizada com o C/C++, mas seu jogo é escrito em C# para simplificar o seu trabalho, e com o uso de bons métodos de compilação (Burst, IL2CPP), o seu código será tão otimizado quanto o próprio C/C++ (especialmente com o IL2CPP), com a vantagem de uma programação bem mais amigável de se trabalhar.

E se você imagina que o código do seu jogo será menos otimizado por ser C#, vou tentar abrir a sua mente: Se você está criando um jogo tão grande e complexo, você dificilmente vai ter tempo para ficar otimizando o seu C++, enquanto no C#, você terá menos esforços para programar, um esforço este que lhe aumentará as oportunidades de você procurar otimizar o seu código, seja durante ou depois.

Em outras palavras, a diferença da performance de um código C++ e C# é muito pequena, e no final das contas, o que mais importa é a otimização do seu próprio código que você escreveu. Não bote culpa no fogão por você ter feito comida ruim, mas com um fogão mais agradável de se trabalhar, há mais chances de você fazer comida melhor.

E olha que ainda não chegamos no DOTS, ein? Mais baixo do post você vai aprender que, na verdade, Unity consegue ter um desempenho de programação muito melhor que Unreal.

Mas então quer dizer que desenvolvedores da Unreal programam os jogos em C++?

Não, justamente pelos motivos que eu falei, não é tão amigável, principalmente para iniciantes em programação, e portanto eles preferem programar usando programação visual: blueprints.

Se você nunca programou antes, você provavelmente vai se sentir atraído pela programação visual, mas acredite em mim, e não só em mim (ele dá bons motivos lógicos aqui), em longo prazo, não vale a pena.

Há inclusive quem diga que o programador de programação visual nem sequer pode ser considerado um programador, na minha opinião, pode sim ser considerado um programador, mas obviamente é num nível bem diferente de um programador que trabalha em texto.

É como discutir se turismo espacial é considerado astronauta, até pode ser, mas é bem diferente do cara que trabalha na ISS, né?

@2nibble

Jogo IMPUNES: Física balística (tiros)

♬ original sound – 2nibble

Eu sei que é assustador, ainda mais em programações low-level, como C/C++, mas Unity, com seu C#, deixa tudo menos assustador, e você, com certeza, vai gostar de programar em texto C# pra Unity, em pouco tempo não sentirá nenhuma falta de programação visual.

Mas sim, Unity também tem programação visual, mas a gigantesca maior parte da comunidade prefere o bom e velho (mas não tão velho) C#, sentindo pouca necessidade do uso da programação visual, e em longo prazo, a curva de aprendizado te leva às alturas.

Quais features da Unity são melhores que Unreal?

Como eu expliquei no início da postagem, muitas features interessantes da Unreal são altamente divulgadas pela mídia, mas por algum motivo, as features interessantes da Unity, não são.

Está certo que Unreal há muito mais features interessantes (mas detalhe que muitos vídeos são na verdade assets criados pela comunidade para a Unreal, não é a Unreal), mas cadê a Unity nisso tudo?

Não vou falar muito de SpeedTree pois, mesmo que seja, de longe, o melhor criador de vegetação do mundo, muitíssimo usado por jogos triple-A, mesmo que SpeedTree seja da Unity, ele pode ser usado em outras engines, então não entra neste assunto. Se bem que, de novo, cadê a mídia falando do SpeedTree? Ele está sempre inovando com features incríveis a cada ano que passa, não é atoa que tantos triple-A usam, mas a mídia está mais preocupada em mostrar um chão de lama/neve afundando na Unreal 5 (algo que não é novidade há décadas).

Se você curte o uso de I.A., Unity foca muito nisso, e novas versões você pode programar usando um assistente de IA que conhece o seu projeto, portanto você realmente consegue pedir coisas avançadas que uma espécie de GPT gerará o código pra você, com base nas coisas específicas do seu projeto. Também o uso de geração de animações, texturas e sons por IA, gerar IA por IA… E nem citei Unity Sentis, ein?

Eu expliquei que Unity há muitas vantagens gerais, que Unity é como um canivete-suíço que é boa para qualquer tipo de projeto conceitual e diferente, mas há uma específica que os próprios desenvolvedores de Unreal sentem falta:

DOTS

É aqui que Unity se destaca neste “canivete-suíço”, mas por ser algo tão técnico, não atrai muito a mídia (um rosto realista do Meta Human é mais facilmente apresentável do que isto).

Eu vou tentar explicar da forma mais leiga que eu consigo:

DOTS é uma combinação de tecnologias para desenvolver jogos em forma de uma programação orientada à dados, e portanto, com muito mais desempenho.

ECS é uma parte do DOTS onde os elementos do jogo são controlados com um framework diferente e baseado em dados em vez de objetos e muito bem estruturado na RAM, algo que possibilita milhões de entidades (como objetos, NPCs) com baixo impacto no desempenho.

Burst Compiler compila o código do seu jogo de uma maneira extremamente otimizada para o CPU, muito útil para partes do seu jogo que utilizam muitos algoritmos matemáticos, como pathfinding, trabalhos com milhões de objetos/dados etc.

C# Job System lhe possibilita realizar o uso de multithreading (usar múltiplas threads do CPU) para otimizar o seu jogo de maneira fácil e com excelente gerenciamento de memória. Foi desta forma que eu consegui criar um tráfego de mais de 3 mil carros no IMPUNES (numa cena vazia, numa cena preenchida consegue centenas), todos eles detectando colisão e respeitando as leis de trânsito, sendo que a IA das leis de trânsito não estão inclusas no Job, mas se eu quiser eu posso incluir com um pouco mais de trabalho.

Você consegue fazer isto na Unreal, só que será mais difícil e potencialmente menos otimizado.

Perceba que isto beneficia literalmente qualquer projeto, tanto o jogo pequeno, quanto o grande (e detalhe que mesmo que você esteja criando um jogo simples para mobile, você pode usar isto para otimizar o gasto de bateria, não necessariamente o FPS).

Este é o tipo de coisa que realmente é útil para desenvolvedores indies, mas por ser técnico, não aparece na mídia, pois a mídia quer algo mais simples e bonitinho de mostrar.

Inclusive, eu me arrisco a afirmar que este é o melhor sistema de pathfinding da história dos jogos, pois usa boa parte do DOTS além de muitas features, e você só tem isto na Unity.

De novo Unity se mostrando uma ótima engine para os indies, principalmente aos programadores, ou simplesmente, produtores que estão colocando a mão na massa de como o jogo deve funcionar.

O projeto do Megacity por exemplo, que é uma demonstração do poder do DOTS, roda em torno de 5 milhões de entidades ao mesmo tempo. 5 milhões de objetos na Unreal, ativos, na CPU, com esta performance, é impossível (lembrando, objetos controlados por CPU, não estou falando de GPU instancing).

Você pode estar se perguntando por que o Cities Skylines 2, criado na Unity, que teoricamente poderia usar o DOTS para ser otimizado, não é realmente otimizado… Bem, a real é que eles quase não usaram, e o problema desse jogo é muito mais embaixo (esta análise é excelente!). Me parece que foram pressionados para lançar o jogo sem nenhuma otimização.

Aqueles jogos de estratégia com milhares ou milhões de unidades se movimentando com IA e levando tiros e explosões com física, só são possíveis com o uso do DOTS. Por exemplo Diplomacy is Not an Option.

Mas e a Godot?

Na minha opinião, eu vejo Godot como uma nova Unity que está nascendo. No entanto, ainda não tem maturidade, ainda há muitas limitações, problemas inclusive cosméticos, tem comunidade pequena mas que aparentemente é muito positiva e unida, mas é uma engine muito boa para fazer jogos bem simples.

Em geral, se você gosta de desenvolver jogos simples em engines como Game Maker e quer continuar nessa pegada, evoluindo um pouco, eu recomendo altamente o uso da Godot, pois eu acho que Unity está num nível um pouco acima do “simples”, e eu acredito no potencial de longo prazo da Godot.

Godot consegue jogos bem similares à Unity, só que Unity tem muito mais maturidade, e isto é muito importante na escolha, pois você pode ter certeza que na internet já haverá soluções para (quase) todos os seus problemas. Então qualquer jogo acima do “muito simples” eu ainda recomendo Unity.

Mas o problema é que engines de muita maturidade, como Unity e Unreal, vêm de décadas atrás, e portanto elas vêm sendo remendadas a partir de soluções arcaicas. Uma nova engine, como Godot, é uma ótima oportunidade de uma engine crescer com base em soluções modernas, menos “deprecated”.

E outras engines?

Esqueça de todas as outras opções, não faz sentido, a não ser que você seja um hipster.

Criar a sua própria engine, é legal, se você é um belo nerd que está buscando aprendizado e portfólio, mas fazer isto pensando no lado comercial de criar um jogo, é sem sentido, não reinvente a roda.

Conclusão

Escolher entre Unity e Unreal é mais complexo do que simplesmente “há features mais avançadas, então vou escolher esta”, mas simplificando bastante:

Unity é melhor para: indies; comunidade; programadores; jogos conceituais; aplicações não-jogos; multiplataforma; oportunidades de trabalho.

Godot é melhor para: indies, comunidade, programadores, jogos simples.

Unreal é melhor para: triple-A; artistas em busca do realismo cosmético.