Core, uma nova tecnologia experimental para criar videogames

 (github.com/damn)
2 pontos por GN⁺ 2024-09-09 | 1 comentários | Compartilhar no WhatsApp

  • O que é coreCore

    • coreCore é uma forma experimental de criar videogames no formato de uma ferramenta e engine de criação de jogos Action-RPG, com editor de propriedades
    • Usa um sistema simples de componentes, e os componentes são vetores Clojure no formato [keyword value]
    • As várias entidades são compostas por mapas Clojure
    • Os efeitos colaterais dentro do jogo são tratados como componentes como [:tx/foo param], em uma estrutura semelhante à do Datomic
    • Todo o estado do jogo é armazenado em um único atom chamado app/state, e as entidades também existem como atoms dentro do atom principal
    • Todo o conteúdo da aplicação é armazenado em resources/properties.edn, validado com malli-schemas e pode ser editado por GUI

  • Capturas de tela

  • Como começar o desenvolvimento

    • Digite o seguinte comando:
      • lein dev
    • A aplicação será iniciada e também fará o seguinte:
      • Inicia o servidor NREPL
      • Ao encerrar a aplicação (ESC no menu principal), clojure.tools.namespace recarrega os arquivos alterados e reinicia o app
      • Se ocorrer um erro, basta corrigir o erro e chamar dev-loop/restart! sem precisar reiniciar a JVM
      • No VIM, é possível usar vinculando o comando a seguir à tecla F5: nmap <F5> :Eval (do (in-ns 'dev-loop)(restart!))

  • Licença do código

    • Fornecido sob a licença MIT

  • Licença dos assets

Resumo do GN⁺

  • coreCore é uma ferramenta para criar jogos Action-RPG com facilidade, usando um sistema simples de componentes para gerenciar o estado do jogo
  • Todo o estado do jogo é armazenado em um único atom, e as propriedades podem ser editadas por GUI, o que é útil para desenvolvedores
  • É fornecido sob a licença MIT, mas os assets usados são proprietários
  • Ferramentas com funcionalidades semelhantes incluem RPG Maker e Unity

Leituras relacionadas

1 comentários

 
GN⁺ 2024-09-09
Opiniões do Hacker News

  • Legal. Nunca lancei um jogo, mas sempre gosto de ver abordagens diferentes para desenvolvimento de jogos
    Até agora, o Bevy parecia bom no começo, mas podia ter muitos problemas de implementação e acabar ficando bagunçado; já no Unity, a abordagem de gameobjects e componentes composicionais era a mais prática, o motor não atrapalhava e era fácil evitar espaguete
    Não gostei do Godot. Uma hierarquia ruim de orientação a objetos, uma linguagem embutida fraca, e os “signals”, que deveriam reduzir espaguete, acabaram aumentando ainda mais. O Pygame é bem bom para projetos pequenos, e dá para colocar por conta própria uma camada orientada a objetos ou funcional sobre uma base procedural
    Não conheço Clojure, mas é interessante a tentativa de uma implementação funcional em uma área que tipicamente parece combinar bem com orientação a objetos

    • Como desenvolvedor profissional de jogos que criou produtos reais tanto com Unity quanto com Godot, discordo totalmente da avaliação sobre Godot e Unity
      Os signals do Godot são um grande avanço em relação à falta de modularidade das classes embutidas do Unity. Godot e Unity têm basicamente o mesmo modelo de scene/node/component, mas acho que o Godot faz isso melhor
      As vantagens do Unity são o renderizador 3D, o PhysX embutido, o backend il2cpp para C#, o profiler, o desempenho geral em execução e o suporte a consoles. Já o design do Godot é mais coeso, enquanto o Unity parece ter se dividido em 10 direções desde mais ou menos 2018
    • Não sou desenvolvedor de jogos, mas o design orientado a objetos do Godot foi um dos melhores que já usei
      Hoje trabalho mais com C++ embarcado, então não uso tanto orientação a objetos, mas aprendi a programar em C#, então estou acostumado com herança
    • Godot é excelente e, em uns 5 anos, acho que será o Blender da criação de jogos. A versão 4 é viável para uso real e dá conta da maioria dos projetos indie
      Onde o Unity está à frente é no nível “Triple I” e “Double A”, porque tem recursos de 3D/desempenho, ferramentas e add-ons melhores. Para projetos AAA, nenhum dos dois é a melhor opção
      Para jogos 2D e 3D simples, agora não vejo motivo para usar Unity, e acho que o Godot vai ultrapassá-lo aos poucos, enquanto a participação do Unity continuará caindo
    • Como desenvolvedor comercial, eu usava Unity antes e agora uso Godot. Concordo com as críticas a GD Script e signals, e evito isso usando tratamento de eventos em C#
      O mais frustrante são as coisas em nodes e no editor que não dá para saber se são bugs ou funcionalidades, e é forte a sensação de que ele foi feito inicialmente para projetos “pequenos”
      Por isso, quase não uso o editor além de compor scenes e definir uma hierarquia aproximada. Minhas ferramentas do dia a dia são Emacs+C# LSP; para depuração, VS Code; e, para ajustar a scene tree, o editor do Godot
    • Usei Godot de forma bem séria e até tenho motivos para não gostar dele, mas GDScript não é um deles
      Basicamente é Python com semântica de slot/emit integrada ao editor, então é até bom. É melhor que isso esteja dentro da linguagem do que em um sistema de build, metadados e arquivos de configuração externos com uma integração complexa

  • Dizem que dá para simplificar o desenvolvimento de jogos, mas jogam um monte de jargões como Clojure vectors, datomics, atoms, transactions e malli schemas. Alguém consegue explicar?

    • Reformulando a introdução, Core é uma ferramenta experimental que tenta simplificar a criação de RPGs de ação
      Ela representa elementos e propriedades do jogo como estruturas de dados simples, e armazena todo o estado do jogo em um único contêiner (app/state), facilitando o gerenciamento e a atualização
      Também oferece uma GUI para editar o conteúdo do jogo armazenado em um único arquivo (resources/properties.edn), tornando-o mais acessível a não programadores; e usa schemas Malli para validar os dados, visando manter a consistência do conteúdo e reduzir erros
    • Para ser justo, ele só está perguntando se o desenvolvimento de jogos pode se tornar mais simples. A resposta provavelmente é “não”
    • O obrigatório “simplicidade não é o mesmo que facilidade”: https://www.youtube.com/watch?v=SxdOUGdseq4
      Um vector de Clojure é basicamente mais próximo de uma lista. Um atom é uma referência mutável para uma estrutura de dados imutável, e pode ser visto como um ponteiro com uma semântica específica de atualização
      Uma transaction é parecida com uma transação de banco de dados: altera várias estruturas de dados ao mesmo tempo, mas só faz commit se todas as operações tiverem sucesso; se falharem, faz rollback ou tenta de novo
      Um Malli schema é uma forma de fazer verificação de tipos em uma linguagem de tipagem dinâmica, e Datomic é uma implementação de banco de dados não SQL baseada em estruturas de dados imutáveis, que não sobrescreve mudanças de forma destrutiva, apenas acrescenta, permitindo voltar a qualquer ponto no passado
    • A linguagem Clojure tem um modelo de gerenciamento de estado embutido, e este projeto é uma tentativa de aplicar esse modelo ao desenvolvimento de jogos
      Acho que a melhor forma de aprender esse modelo é assistir à palestra “Are we there yet”, de Rich Hickey, criador do Clojure
    • Um vector de Clojure é uma estrutura de dados embutida na linguagem e se parece com [1 2 3]
      Eu o uso para compor efeitos colaterais como [:tx/foo 3], e chamo isso de transaction, de forma parecida com o Datomic. Aqui, :tx/foo é uma keyword e identifica de forma única o comportamento de um componente

  • Sinceramente, acho que este projeto fracassou na prática. É uma confusão superprojetada, sem uma estrutura clara
    O maior problema é que não há nenhuma especificação. Ou não criaram uma história para o jogo, ou talvez tenham achado que o jogo não precisava de história. Então simplesmente se divertiram programando em Clojure e codaram feito loucos

    • Para ser justo, entre os projetos bem-sucedidos também há muitos que são confusões superprojetadas e sem estrutura clara
      É bom que tenham tentado algo interessante, e é uma área que interessa a muita gente
    • Só de admitir que foi apenas um hobby divertido e que talvez não seja tão simples quanto alegaram, já está à frente de muita gente. Espero que tenham aprendido bastante com o projeto

  • Como desenvolvedor de jogos, esse GitHub parece ridículo. É quase uma paródia da autoindulgência acadêmica que desenvolvedores de jogos detestam. As capturas de tela feias são a cereja do bolo.

    • Então isso não é meio incompatível com este site? O Hacker News geralmente trata de novas ideias interessantes, não só de melhorias incrementais em C++ e Unity.
      Consigo pensar em alguns jogos que saíram desse tipo estranho de autoindulgência acadêmica. O Jonathan Blow, mencionado no comentário irmão, é um caso, e assim que vi este projeto pensei em Braid.
      Geração procedural também já foi um tema de torre de marfim, e todos os avanços em gráficos 3D começaram como artigos totalmente irrealistas em conferências. Muitas coisas que hoje são mainstream em jogos já foram ideias acadêmicas de nicho.
    • Não acho que as capturas de tela sejam “feias”, mas concordo que o README é funcionalmente inútil. Não há documentação nem exemplos, nem explicação de por que alguém deveria usar.
      Ele falha no passo básico de comunicar o que faz.
    • Também há valor em criar algo intelectualmente estimulante. Mesmo que você gaste 100 horas criando datomics em Clojure e apenas 1 hora criando conteúdo de fases, 1 hora ainda é mais que 0.
      Se, por tédio, você não teria criado nada, isso é um ganho. É parecido com a lógica do Jonathan Blow usando Jai no desenvolvimento indie.
    • Está escrito que é experimental.

  • É surpreendente que tenha surgido tanta conversa mesmo com tão pouca documentação neste repositório. Olhando o código, parece mais um projeto do que um motor de jogo.
    O property editor é interessante, mas acho que este post está sendo recomendado mais pelo título do que pelo conteúdo.

  • Legal. Fico feliz em ver um desenvolvedor fazendo desenvolvimento de jogos em Clojure, como eu. Às vezes a gente acaba dificultando a própria vida :)
    No momento estou desenvolvendo um shooter TPS multiplayer 3D em Clojure. Se houver interesse, a demo está aqui: https://prototype-game.pages.dev
    Em breve também pretendo publicar um post de blog sobre a jornada de desenvolvimento.

    • Um dos meus momentos favoritos na internet é quando várias pessoas entram em um espaço virtual, começam a correr por ali espontaneamente e usam o chat dentro do jogo.

  • Eu gosto de Clojure, mas uma linguagem funcional que usa estruturas de dados imutáveis não é uma escolha meio estranha para desenvolvimento de videogames?

    • É totalmente possível, e há trade-offs interessantes.
      Estes são alguns textos de que gosto sobre desenvolvimento de jogos funcional:
      https://prog21.dadgum.com/228.html
      https://prog21.dadgum.com/23.html
      https://prog21.dadgum.com/24.html
      https://prog21.dadgum.com/25.html
      https://prog21.dadgum.com/26.html
    • Parece bastante natural. Como Clojure é baseado na JVM, este projeto usa libgdx internamente, pode ser distribuído para todas as plataformas e conta com um ecossistema grande de bibliotecas.
      No restante, dá para fazer praticamente qualquer coisa com Lisp. Graças à forma como Clojure lida com estruturas de dados imutáveis e ao ótimo sistema de protocol (https://www.freshcodeit.com/blog/clojure-protocols-and-the-e...), foi fácil dividir o jogo inteiro em componentes separados.
    • Tim Sweeney também parece estar apostando nessa direção com Verse no UEFN. Verse está mais para uma versão mais acessível de Haskell.
    • Não é tão estranho assim. O próximo jogo AA ou AAA provavelmente não vai usar isso, mas a imutabilidade aparece com frequência até em áreas muito interativas, como reducers do React ou Redux.
      Clojure tem mais potencial de desempenho do que Ruby ou Python, e ambos já foram usados de fato em jogos indie comerciais.
    • Programação funcional quase nem foi devidamente tentada no desenvolvimento de jogos. Falta interseção entre a indústria de jogos e a academia.
      Naturalmente, os estúdios evitam riscos e preferem estratégias familiares, como orientação a objetos ou ECS para grandes multidões.
      Pessoalmente, acho que programação funcional pode se encaixar bem, mas antes é preciso encontrar uma arquitetura que resolva problemas reais de desenvolvimento de jogos. É preciso começar com pequenos experimentos, e game jams são perfeitas para isso.

  • Já existe uma plataforma comercial de criação de jogos chamada Core, que roda sobre Unreal Engine 4.
    https://en.wikipedia.org/wiki/Core_(video_game)

  • Acho que escolheram mal o nome. Ele já é usado nessa área: https://www.coregames.com/create

    • Também foi a primeira coisa em que pensei. Especialmente porque lá você cria jogos dentro do jogo, então também poderia ser visto como uma “nova” forma de escrever jogos.

  • Seria interessante analisar os dados de “tempo/complexidade investidos no motor de jogo” versus “complexidade/interesse do jogo resultante”.
    Como desenvolvedor de jogos, eu esperaria que o retorno de novos jogos vindos de sistemas simples de templates/motores seguisse uma curva logarítmica decrescente.
    Em outras palavras, quanto melhor você torna a máquina de fazer biscoitos, menor fica a variedade dos biscoitos.