Murder é um motor de jogos ECS em pixel art em C#

Artigo original ↗ Discussão no Hacker News ↗

Um novo motor de jogos 2D em pixel art e código aberto, em C#, construído em torno de uma arquitetura Entity Component System (ECS), está a receber elogios pelo design limpo, pelo forte fluxo de trabalho no editor e pelo uso de tecnologias familiares como MonoGame. Os comentadores comparam a sua abordagem ECS e o comportamento do garbage collection em C# com Unity e Godot, debatendo se ECS é exagero para pequenos títulos em pixel art ou uma forma útil de estruturar jogos complexos com muitas entidades. O nome provocador do projeto, “Murder”, também gera debate sobre capacidade de pesquisa, mau gosto percebido e se a marca agressiva é uma desvantagem ou um não-problema para ferramentas de desenvolvimento.

Impressões gerais

  • Muitos comentadores elogiam a aparência do motor, o estilo do editor e o foco em pixel art.
  • Os tutoriais de pixel art ligados por um dos contribuidores são elogiados como alguns dos melhores disponíveis, especialmente por serem concisos e bem escritos.
  • Vários jogos de jam feitos com o motor são partilhados e descritos como impressionantes para tempos de desenvolvimento curtos.

Nome e marca do motor

  • Um debate significativo gira em torno do nome “Murder”.
  • Preocupações:
    • SEO fraco devido à palavra genérica e muito usada.
    • Perceção de mau gosto ou de uma agressividade desnecessária, especialmente tendo em conta a violência no mundo real.
    • Receio de que plataformas (por exemplo, YouTube/Google) possam rebaixar o conteúdo.
  • Contra-argumentos:
    • Pesquisar por “murder engine” já apresenta o projeto.
    • Outros motores e ferramentas amplamente usados também têm nomes genéricos ou “esquisitos”.
    • Alguns consideram as objeções exageradas ou “pearl-clutching” e apreciam o tema de “murder of crows”.
  • O gosto é apresentado como algo subjetivo; não se chega a consenso.

Arquitetura ECS e implementação

  • Várias pessoas confundem inicialmente “ECS” com o chipset da Amiga; outras esclarecem que significa “Entity Component System”, uma arquitetura de jogos orientada a dados.
  • O ECS interno (“Bang”) é discutido:
    • Os componentes são structs simples; os sistemas são classes acionadas por interfaces implementadas.
    • Os filtros definem que entidades um sistema processa.
    • Os source generators criam métodos auxiliares (por exemplo, TryGetVelocity), provavelmente por desempenho/ergonomia.
    • As entidades armazenam componentes em dicionários; isto não é um ECS por archetype/SoA, favorecendo a simplicidade em vez da velocidade máxima.
    • Permanecem questões sobre ordenação de sistemas, múltiplas queries num único sistema e o comportamento quando componentes são adicionados/removidos a meio do tick.

ECS é exagero para jogos 2D em pixel art?

  • Uma perspetiva: a maioria dos jogos em pixel art é pequena e não precisa de ECS; OOP pode ser mais simples.
  • Respostas:
    • ECS pode ajudar a gerir grandes quantidades de entidades (por exemplo, jogos tipo “bullet hell” ou de automação).
    • Melhores padrões de acesso à memória podem melhorar o desempenho e a duração da bateria.
    • Alguns consideram ECS conceptualmente mais limpo como “mutação controlada”, independentemente do desempenho.

C# e garbage collection

  • São levantadas preocupações sobre pausas de GC no desenvolvimento de jogos em C#.
  • Várias respostas argumentam:
    • Os GCs modernos do .NET têm bom desempenho se as alocações forem controladas (object pooling, minimização de alocações por frame).
    • Os problemas são especialmente pronunciados no Unity porque usa um GC antigo do Mono; outros motores baseados em .NET têm melhor desempenho.
    • As estratégias incluem pré-alocação, pooling, desativar certos modos de GC ou chamar explicitamente GC.Collect() em momentos controlados.
  • Há discussão a comparar GC por tracing com contagem de referências (por exemplo, Swift, GDScript do Godot), observando trade-offs entre determinismo, overhead e adoção em plataformas.

Comparação com Unity, Godot e MonoGame

  • O ECS do Unity é descrito como complexo devido à coexistência com GameObjects e a um fluxo de trabalho separado de “authoring”; a depuração visual é limitada.
  • O ECS de Murder é descrito como “apenas C#” com menos camadas: componentes e sistemas são adicionados diretamente, e as entidades do editor ficam imediatamente utilizáveis.
  • MonoGame é apresentado como uma reimplementação madura e estável do XNA, usada em vários jogos indie conhecidos, situando-se entre bibliotecas de baixo nível e motores completos.
  • Godot é mencionado pelo uso de contagem de referências e como alternativa cuja integração com .NET está a melhorar.

Experiência de utilização e questões em aberto

  • Um desenvolvedor que experimentou tanto o ECS do Unity como o de Murder relata que o ECS de Murder é muito mais fácil de aprender e usar, especialmente no editor.
  • O C# é amplamente descrito como agradável e legível.
  • Surge uma pergunta sobre usar F# com o motor, mas não é respondida no tópico, pelo que o suporte entre linguagens permanece pouco claro.