Tramway SDK – a união profana entre os motores de Half-Life e Morrowind

• Tramway SDK é um pacote gráfico/framework/motor de jogo desenvolvido nos últimos 3 anos, com foco em ser um motor leve que se opõe aos altos requisitos e ao fluxo de editor monolítico dos motores mainstream
• Considera que motores populares como Unity e Godot exigem hardware excessivo até para jogos low-poly simples, e mira como alvo de execução até hardware dos últimos 15 anos e rasterização por software
• Em vez de alternar entre uma GUI de nós e código, o método de desenvolvimento consiste em escrever código por meio de herança da classe Entity e usar apenas os editores necessários
• A criação de níveis usa um fluxo de trabalho de brushes no estilo Quake, aproveitando conversor de .map, lightmaps, sombreamento Gouraud e um sistema de entrada/saída no estilo Source
• Embora tenha como objetivo streaming de mundo aberto e um framework de RPG mais próximo de um RPG Maker 3D, ainda está em estágio inicial de desenvolvimento, então é preciso considerar API instável e elementos não implementados

---

O problema que o Tramway SDK quer resolver

• Tramway SDK é um pacote gráfico, framework e motor de jogo, e também usa a grafia em estilo heavy metal “T̈ra̦m̊ẅa̦ÿ SD̈K”
• A crítica aos motores mainstream se concentra no Turbobloat
  • Considera que o Unity exige hardware muito potente e muito consumo de energia
  • Considera que o Godot é um pouco melhor que o Unity, mas ainda requer hardware relativamente capaz
  • Defende que jogos como um simulador deckbuilder roguelite de terror low-poly deveriam rodar tranquilamente em hardware de 15 anos atrás
• O Tramway SDK afirma que, por não ter Turbobloat, pode rodar em quase qualquer hardware dos últimos 15 anos
  • Pode até alternar para rasterização por software para funcionar sem placa gráfica
  • Chega a citar exemplos de exibir gráficos em dispositivos como torradeiras ou geladeiras
• À objeção de que “é só comprar um computador melhor”, responde com três razões
  • A questão da acessibilidade de compra: muita gente não tem condições de adquirir hardware potente
  • A questão do lixo eletrônico: a produção de chips de computador faz mal ao meio ambiente, e se o software não fosse inchado, só seria necessário comprar hardware novo quando o antigo quebrasse e não pudesse ser reparado
  • A posição de que, se já existe um computador que funciona bem, não há motivo para comprar outro novo por causa do Turbobloat de terceiros

Método de desenvolvimento e recursos

• O método de desenvolvimento baseado em nós é criticado por exigir lidar com “várias coisas que parecem uma só” e por obrigar a alternar entre GUI de nós e código
• No Tramway SDK, basta escrever código herdando da classe Entity e depois criar o nível no editor de níveis
  • Não usa nós, e sim uma estrutura centrada em entidades
  • Evita o fluxo de ficar indo e voltando entre código e GUI de nós
• O editor monolítico dos motores mainstream também é visto como um problema
  • Considera-se que é preciso esperar o editor inteiro carregar, inclusive com recursos que você nem usa
  • Todos os editores do Tramway SDK são opcionais
  • Se quiser usá-lo só como framework, é possível usar apenas o runtime em C++
  • Se só precisar criar níveis, é possível usar apenas o editor de níveis
  • Os arquivos de dados usam um formato de valores separados por espaço, então também podem ser editados manualmente sem editor
• No aspecto gráfico, as imagens de exemplo podem ser feitas apenas com lightmaps e sombreamento Gouraud
  • Esses exemplos podem ser renderizados até no pipeline de função fixa de uma placa gráfica de nível Direct3D 7
• A criação de níveis oferece suporte a um fluxo de trabalho baseado em brushes da família Quake
  • O Tramway SDK fornece um conversor de arquivos .map, transformando brushes em malhas triangulares
  • Mostra um fluxo em que o nível é criado no Trenchbroom e configurado no editor de níveis do Tramway SDK
  • O nível com lightmaps aplicados é renderizado dentro do motor
  • Com um sistema de entrada/saída semelhante ao do Source, é possível configurar interações entre entidades dentro do nível
  • No futuro, planeja implementar todas as logic entities do Source para permitir scripting visual dentro do editor de níveis
• Do lado de RPG, considera interessante como ferramentas como RPG Maker e mods/total conversions baseados em Morrowind permitem criar muita coisa apenas alterando dados
  • O Tramway SDK tem uma extensão de framework de RPG próxima de um RPG Maker para 3D
  • O motor foi projetado desde o início para suportar streaming de níveis, e considera que isso pode tornar a criação de jogos de RPG em mundo aberto mais rápida e fácil
• Em resumo, o Tramway SDK é um motor de jogo baseado em entidades no estilo Quake/Source, com extensões opcionais como streaming de mundo aberto e framework de RPG
• O estado do desenvolvimento ainda é muito inicial
  • A API é instável
  • Recursos podem estar quebrados ou não funcionar
  • Ainda há muitos elementos não implementados
  • O projeto afirma estar melhorando rapidamente
• Repositório no GitHub: racenis/tram-sdk

[GN⁺]

Opiniões no Hacker News

• Há quem diga “é só comprar um computador melhor”, mas concordo totalmente que, por isso mesmo, comprar um computador melhor é ruim. Muita gente, especialmente em países em desenvolvimento, não tem condições de comprar hardware para rodar Turbobloat, e a produção de chips tem impacto ambiental negativo.
  Se o software moderno não fosse tão inchado, as pessoas só comprariam outro quando o hardware existente quebrasse e não pudesse ser consertado. Não há motivo para comprar um computador novo por causa do software inchado de outra pessoa quando você tem um computador funcionando perfeitamente; com esse dinheiro, daria até para comprar 1000 latas de Dr. Pepper. É um projeto realmente bom, então espero que continuem publicando atualizações sobre o progresso.

  • Dizem “resoluções de tela de 320x200 a 800x600”, mas resoluções mais altas não foram inventadas só por causa do Turbobloat.
  • Mesmo dizendo isso, o engine parece exigir uma GPU OpenGL 4, embora os gráficos pareçam estar num nível que até uma placa Voodoo conseguiria rodar.
  • Não sei o que é Turbobloat. Pelo contexto, parece “tecnologia gráfica de que eu não gosto”, mas não fica claro até onde vai o Turbobloat.
  • Construir e entregar computadores novos pode valer a pena no longo prazo, porque melhorias de desempenho e eficiência energética podem compensar o impacto ambiental com o tempo.
    Claro que, para entretenimento, é difícil julgar, e um Game Boy antigo pode ser mais divertido do que um PC gamer moderno de 1000 W.

• A frase “Uma coisa deve ser uma coisa. Não várias coisas fingindo ser uma. Se você usa nós, precisa fingir que várias coleções são uma coisa” soa muito Terry Pratchett, e é ótima.
  Gosto dela porque parece algo que Sam Vimes pensaria durante uma investigação complicada, e espero que continue evoluindo. Ainda não experimentei pessoalmente, mas tenho uma ideia para usar no meu projeto de IA.

  • Olhando só para essa frase isoladamente, acho que ela é obviamente errada. Nós pensamos o tempo todo em coleções de várias coisas como uma só.
    Um ser humano é uma coleção de partes do corpo; partes do corpo são coleções de substâncias químicas; substâncias químicas são coleções de moléculas; moléculas são coleções de átomos, e ainda assim vemos cada nível como uma coisa. Não faz sentido impedir isso. Ainda assim, o projeto parece legal.
  • Imagino Sam Vimes dizendo isso e depois, por causa de Sybil, passando por um crescimento doloroso até admitir a contragosto que “às vezes uma coisa talvez precise ser mais do que uma coisa”.
    E o sistema entidade-componente de Vetinari parece complicado, mas funciona direito e mantém a maldita cidade funcionando.
  • Essa frase parece direcionada a quem já tentou outras soluções e não gostou delas, mas, para alguém que nunca usou um motor de jogo, seria bom ter uma explicação simples de como nós se relacionam com “várias coleções fingindo ser uma coisa”.
    Fico pensando se a ideia é que a experiência de usuário de um editor de nós induz você a atribuir propriedades e relações a coisas como Vector de Fingers, mas no fim Vector é apenas uma “coleção de coisas”, não um “tipo” com comportamento próprio, então fica difícil anexar código a ele.
    Fico curioso se “tudo é Entity e basta escrever código” significa criar uma classe Hand que contém Fingers e tem seu próprio estado e comportamento, em vez de um Vector. Ou talvez signifique herdar novamente de uma subclasse de Entity para torná-la mais específica, em vez de criar uma instância de nó que já agrupa certos valores estáticos e membros de relacionamento.
  • O parágrafo logo seguinte é interessante: “Ao criar algo com nós, você precisa ficar alternando constantemente entre a GUI de nós e o código”.
    A composição Node/GDScript do Godot pode ser vista como uma espécie de resposta a essa afirmação. É uma tentativa de tornar esse “vai e vem” o mais fluido e integrado possível, com coisas como o operador $ e autocompletar. Ainda assim, no fim você precisa lançar o jogo, então acho que a mentalidade de “uma coisa é uma coisa” vence no final.
  • Infelizmente, tudo é uma coleção de coisas fingindo ser uma coisa, até mesmo uma coisa singular. O melhor que podemos fazer é fingir assim ou evitar sermos pegos.

• Com o tempo, fico com a impressão de que existe uma força externa que reduz a qualidade dos motores de jogo. Em tecnologia em geral, o que se espalha amplamente costuma ser aquilo para o qual é fácil montar um currículo.
  Editores baseados em nós, como o Unity, têm uma estrutura perfeita para ser explicada ao longo de várias aulas. Por outro lado, um motor como o raylib pode ser entendido em uma tarde, então é difícil existir uma disciplina universitária de raylib. Com isso, cria-se um ciclo em que escolas no estilo bootcamp formam desenvolvedores amadores que só conhecem Unity/Unreal, empresas contratam gente de Unity/Unreal, e as universidades voltam a ensinar isso. É parecido também com a popularidade do Java.
  Além disso, como cada empresa tem requisitos diferentes para projetos em Unity, a Unity, enquanto empresa com fins lucrativos que lida com clientes, e não com um único programador cheio de reclamações, precisa continuar adaptando o motor, e no fim ele vira Turbobloat. Os motores de Half-Life e Morrowind surgiram de uma situação peculiar em que programadores apaixonados eram pagos para desenvolver o que achavam legal, resultando em tecnologia excelente e em motores mínimos adequados a desenvolvedores profissionais de jogos.
  Este projeto parece ficar em algum ponto entre raylib e Unity. Tenho receio de que não seja suficiente para atrair programadores amadores e, ao mesmo tempo, faça coisas demais para programadores que querem um motor pequeno. Espero estar errado, e o desempenho e o acabamento parecem bons. Há claramente desenvolvedores cansados do Unity, e, com o ciclo da nostalgia chegando aos anos 2000, existe de fato demanda para jogar e criar jogos que não sejam graficamente mais complexos que Half-Life 2. O design do site e o tom da documentação também são bons

  • Também é importante o fato de que, quando o jogo e o motor são feitos juntos, um pode se ajustar ao outro. Em Doom, não era possível colocar um piso sobre outro piso; isso era uma limitação do motor vinda das restrições de CPU, e os level designers criavam truques para fazer parecer que era possível.
    Quando os dois são projetados juntos, dá para aproveitar ativamente os recursos adicionados e evitar os recursos em que o motor não é bom, ou até adaptar o estilo de arte ao motor. Os mobs pixelizados e angulosos de Minecraft combinam bem com o motor, mas, se você começa a torná-los mais sofisticados, acaba caindo no vale da estranheza, onde parecem mais antiquados e desajeitados que Minecraft até serem renderizados decentemente com polígonos suficientes
  • Lembro que alguém que trabalhou em Bioshock, talvez o lead designer, disse em uma entrevista: “Para testar uma ideia nova na empresa, é preciso montar uma equipe e passar pelo menos um mês até ter algo em que se possa mexer. Em casa, por outro lado, consigo criar uma campanha inteira de Doom em uma única noite”
  • Gosto de desenvolvimento de jogos baseado em bibliotecas, como raylib ou libgdx, mas há um motivo para um jogo como Slay the Spire ter passado pelo Unity e ido para Godot na sequência.
    Não acho que as pessoas usem Unity porque aprenderam errado com professores que gostam de complexidade
  • Jogos antigos eram realmente nítidos, enquanto jogos atuais rodam uma bagunça, travam, exigem 150 GB de download e levam 150 anos para abrir. Se jogássemos por causa dos gráficos, um dos MMOs mais populares não seria baseado em um jogo de navegador de 2002; para começo de conversa, jogaríamos a realidade, não jogos.
    Basta ver o que a Epic Games fez com Fortnite. Ela matou um jogo centrado em cena competitiva que rodava suavemente por causa de gráficos Turbobloat e skins
  • O fenômeno de “saírem programadores que só conhecem Unity/Unreal, empresas contratarem gente de Unity/Unreal, e universidades voltarem a ensinar isso” também aparece de forma parecida com ArcGIS

• Concordo totalmente com o problema da turbo-obesidade. As máquinas de hoje são muito mais potentes, mas a maioria dos programas, na verdade, parece mais lenta do que antes.
  O projeto também é muito legal, e o design do site é nota A+

  • A afirmação de que “a maioria dos programas é mais lenta que antes” me parece verdadeira só para quem teve a sorte de usar hardware um pouco potente demais em determinada época.
    Da perspectiva de quem usava hardware comum na era Windows 98/2000/XP, rodar Windows 10/11/KDE/Gnome etc. em um notebook moderno barato com SSD é muito mais responsivo, mesmo executando web apps considerados inchados, como vscode ou Slack
  • Não entendo o termo Turbobloat. Já fiz jogos, mas nunca ouvi falar; o autor também não definiu, e, ao pesquisar no Kagi, só aparece o post enviado, enquanto no Google não há resultados relacionados.
    Fico imaginando se significa apenas “muito inchado”. Lendo mais o site, também há expressões como “simulação física hiper-realista”, então parece que, no fim, quer dizer “muito inchado”

• A visão de que “a maioria dos jogos em Unity parece muito ruim mesmo usando shaders vistosos, normal mapping e outras técnicas” parece estar ficando cada vez mais comum entre uma certa geração.
  É certo que algum tipo de tecnologia de mapeamento de texturas desapareceu. Os cenários de Ikaruga são melhores do que precisariam ser, especialmente o efeito simples de floresta no começo. Alguns simuladores de trem da era PS2 também conseguiam fazer isso.
  Mas esse método desmorona quando uma fonte de luz direcional forte como o sol ilumina objetos brilhantes e o jogador se move. Se o ambiente for nublado e não houver absolutamente nenhum objeto dinâmico, dá para contornar bastante os truques modernos.

  • Sim. O problema é que alguns jogos modernos são nublados e nem têm iluminação dinâmica, mas ainda assim usam Lumen. Foi o caso do remake de Silent Hill: roda muito devagar, fica pior no PS5 Pro, e a grama também parece inferior à de jogos antigos.
    A ambientação do Silent Hill original foi criada justamente para justificar truques de otimização. Para facilitar o gerenciamento dos objetos na tela, eles mantinham um espaço permanentemente enevoado, um “espaço de neblina”, mas o remake desperdiça uma quantidade enorme de processamento tentando criar neblina realista em vez de uma neblina com aparência sobrenatural.
  • Jogos bonitos feitos em Unity não “parecem jogos de Unity”, então as pessoas não os lembram como exemplos de “como é a aparência de um jogo em Unity”. Por isso, o estereótipo de jogo em Unity continua sendo “bem tosco”.
    As habilidades artísticas para deixar algo bonito não desapareceram de forma alguma; elas só são distribuídas de maneira muito desigual. Uma equipe com bons modeladores, artistas de textura, animadores e competência em programação visual consegue fazer algo bonito em Unreal, Unity ou em um motor próprio.
  • Existe uma teimosia em achar que materiais sozinhos conseguem compensar texturização e normal mapping insuficientes. Isso não é verdade; é resultado de slogans de marketing de coisas como Unreal Engine sendo mal interpretados ou distorcidos.
    Em Super Mario Sunshine, as sombras “nítidas” que o GameCube não conseguia renderizar de fato usavam meshes planos. Em Delfino Plaza, a sombra sob o toldo perto do Shine Gate não é uma textura, é uma mesh. Por outro lado, a praça de ladrilhos sobre a qual essa sombra de mesh fica parece boa não por causa de uma única textura enorme, mas porque dezenas de texturas de 128x128 px foram devidamente mapeadas por UV.
    Um jogo moderno provavelmente usaria duas texturas de tijolo e um padrão de ruído para misturá-las, todas as três em 2048x2048 px, enquanto as sombras teriam bordas nítidas por ray tracing. Ironicamente, embora a VRAM e a velocidade do barramento tenham aumentado, escolhemos texturas maiores em vez de mais texturas. O mesmo vale para normal mapping: em vez de usá-lo junto com modelos mais subdivididos, há a ilusão de que normal maps são antiquados e que modelar todos os detalhes de verdade é o caminho tecnicamente mais avançado. Uma esfera menos facetada é ok, mas modelar de fato cada rachadura e arranhão da esfera é burrice e desperdício computacional.
  • Com algo como Unity, dá para fazer algo funcionar bem rápido, mas para deixá-lo realmente bonito são necessárias habilidades separadas e polimento.
    Mesmo um jogo “2D” como Factorio tem uma diferença enorme de polimento entre o lançamento inicial, a versão 1.0 e a versão atual. Essa diferença também fica clara em jogos com mods: os assets de mods geralmente “servem”, mas não parecem tão refinados quanto os do jogo base.

• Rejoguei Half-Life 2 recentemente e fiquei surpreso com o quanto ele ainda é bonito hoje, mesmo sem pacote de texturas em alta resolução.

  • Acho que isso se deve a uma escolha extremamente inteligente do estilo artístico do jogo. Há muitas superfícies difusas em que iluminação pré-calculada funciona bem, e o céu nublado permite luz ambiente difusa em vez de iluminação direcional que forçaria sombreamento dependente do ângulo e contornos de sombras fortes e de alto contraste.
    As superfícies brilhantes também, em sua maioria, não são excessivamente lustrosas, o que ajuda. Essas escolhas combinam bem com um mundo velho, ocupado e extremamente distópico, tornando-o convincente, e as texturas de cores sóbrias amarram tudo.
  • Por isso acho que uma direção de arte realmente boa sempre vence desempenho gráfico bruto. Source já era impressionante na época, mas o que envelheceu bem foi o cuidado com que ambientes e modelos foram projetados.
    A Valve concentrou recursos em inserir detalhes dentro das limitações técnicas e extrair o máximo delas; 20 anos depois, o jogo ainda parece coeso e bem projetado.
  • Half-Life 2 recebeu várias atualizações de sombreamento e nível de detalhe depois do lançamento, então está um pouco melhor do que na época em que saiu. Ainda assim, no lançamento já era um jogo visualmente impressionante.
  • Rejoguei Half-Life 2 há menos de uma semana e acabei pensando que “mesmo que os níveis não sejam tão cheios de detalhes quanto os jogos modernos, a direção artística dos gráficos e do level design é melhor do que a de muitos designers modernos com orçamentos maiores”.
  • Black Mesa, o remake de HL1 no motor de HL2, também vale a pena. Joguei durante a pandemia e não me arrependi.

• Trabalhando em uma equipe pequena que faz um jogo low poly em Godot, isso é legal.
  As frases “quando você constrói algo com nós, precisa ficar alternando entre a GUI de nós e o código” e “motores mainstream têm um único editor de jogo gigantesco, e você precisa esperar 10 minutos até tudo carregar, qualquer que seja o recurso que vá usar” bateram forte. Mesmo no Godot, quase não usamos recursos sofisticados, mas o loop de depuração parecia muito mais lento do que quando programo em outros ambientes.
  Também gosto da ideia de vários editores funcionando em conjunto em torno de uma especificação única de arquivo de dados. Uma IDE integrada facilita que vários desenvolvedores criem conflitos de merge; editores com finalidades mais específicas também podem ajudar desenvolvedores de cada função a limitar o escopo e a natureza das mudanças. Estou curioso para ver como o motor vai evoluir.

  • No hackathon do mês passado, fiquei bem orgulhoso de ter descoberto como fazer desenvolvimento orientado a testes de módulos em C# sem abrir o Unity.
    Consegui contribuir com a minha parte mesmo em um netbook fraco. Eu nunca tinha escrito uma linha de C#, mas não pretendia abrir mão de TDD na linha de comando. Descobri que era possível e, no fim, fiz funcionar. Todo mundo achou que eu estava louco, e o pessoal de relações com desenvolvedores dos patrocinadores não ajudou em nada.
    O maior atrito daquele fim de semana continuou sendo o fato de que o melhor computador tinha de gastar uma eternidade ligando e religando a maldita IDE do Unity. É impressionante as correntes que as pessoas aguentam.

• Ele usa “Turbobloat” e diz que os motores são “inchados”, e até certo ponto isso faz sentido. Mas vale explicar o que isso significa para ele, quais recursos ele considera inchaço e o que foi removido do projeto Tramway.
  Por exemplo, para algumas pessoas, incluir um framework de RPG também poderia parecer inchaço, e o Tramway tem isso.

  • Por isso ele foi incluído como extensão opcional. Faz parte do projeto maior do motor, mas é totalmente opcional.
    Gosto do princípio do C++ de “você só paga pelo que usa”.

• Diz que é “como usar o framework para iniciantes que têm medo de C++ ou simplesmente não sabem C++”; eu estou no segundo grupo e fiquei grato pela página Getting Started
  O bule apareceu, e entendi coisas que achei que não entenderia. Agora só tenho 30 minutos de horário de almoço e não dá para terminar o tutorial, mas o fato de eu ter ficado com vontade de continuar mostra bem como esta documentação é divertida e acessível

• Alguém encontrou a página Design Patterns? É um placar com meta de 100%, e eu gostei demais

  • Está linkada na página inicial: “82% dos padrões de design usados. Quando todos os padrões forem usados, o projeto será apagado e reescrito em Rust. Sem orientação a objetos”
  • Procurei um tempão e ainda não encontrei