Core, una nueva tecnología experimental para crear videojuegos

 (github.com/damn)
2 puntos por GN⁺ 2024-09-09 | 1 comentarios | Compartir por WhatsApp

  • ¿Qué es coreCore?

    • coreCore es una forma experimental de crear videojuegos en formato de herramienta y motor para juegos Action-RPG, además de un editor de propiedades
    • Usa un sistema simple de componentes, y los componentes son vectores de Clojure con la forma [keyword value]
    • Las distintas entidades están compuestas por mapas de Clojure
    • Los efectos secundarios dentro del juego se manejan con componentes como [:tx/foo param], similares a la estructura de Datomic
    • Todo el estado del juego se almacena en un solo atom llamado app/state, y las entidades también existen como atoms dentro del atom principal
    • Todo el contenido de la aplicación se guarda en resources/properties.edn, se valida usando esquemas de Malli y puede editarse desde una GUI

  • Capturas de pantalla

  • Cómo empezar a desarrollar

    • Ingresa el siguiente comando:
      • lein dev
    • La aplicación se inicia y también realiza las siguientes tareas:
      • Inicia el servidor NREPL
      • Al cerrar la aplicación (ESC en el menú principal), clojure.tools.namespace recarga los archivos modificados y reinicia la app
      • Si ocurre un error, no hace falta reiniciar la JVM; basta con corregirlo y llamar a dev-loop/restart!
      • En VIM, puedes vincular la tecla F5 al siguiente comando: nmap <F5> :Eval (do (in-ns 'dev-loop)(restart!))

  • Licencia del código

    • Se ofrece bajo la licencia MIT

  • Licencia de los assets

Resumen de GN⁺

  • coreCore es una herramienta para crear fácilmente juegos Action-RPG y usa un sistema simple de componentes para gestionar el estado del juego
  • Almacena todo el estado del juego en un solo atom y permite editar propiedades mediante una GUI, lo que resulta útil para desarrolladores
  • Se ofrece bajo licencia MIT, pero los assets utilizados son propietarios
  • Herramientas con funciones similares incluyen RPG Maker y Unity

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-09-09
Opiniones en Hacker News

  • Genial. Nunca he lanzado un juego, pero siempre me gusta ver enfoques distintos para el desarrollo de juegos.
    Hasta ahora, Bevy me ha parecido bueno al principio, pero con muchos problemas de implementación y propenso a volverse desordenado; Unity, con su enfoque de gameobjects y componentes composables, ha sido lo más práctico: el motor no estorba y es más fácil evitar el spaghetti.
    Godot no me gustó. Una mala jerarquía orientada a objetos, un lenguaje integrado flojo, y las “signals”, que supuestamente reducen el spaghetti, terminaron aumentándolo. Pygame es bastante bueno para proyectos pequeños, y sobre una base procedimental puedes montar tus propias capas orientadas a objetos o funcionales.
    No conozco Clojure, pero me parece interesante que hayan intentado una implementación funcional en un campo que típicamente parece encajar bien con la orientación a objetos.

    • Como desarrollador profesional de juegos que ha creado productos reales tanto con Unity como con Godot, me cuesta estar de acuerdo con esa evaluación de Godot y Unity.
      Las signals de Godot son un gran avance frente a la falta de modularidad de las clases integradas de Unity. Godot y Unity tienen básicamente el mismo modelo de scene/node/component, pero creo que Godot lo hace mejor.
      Las ventajas de Unity son su renderer 3D, PhysX integrado, el backend il2cpp para C#, el profiler, el rendimiento general de ejecución y el soporte para consolas. En cambio, el diseño de Godot es más cohesivo, mientras que Unity se siente como si desde alrededor de 2018 se hubiera fragmentado en 10 direcciones.
    • No soy desarrollador de juegos, pero el diseño orientado a objetos de Godot me pareció de los bastante buenos entre los que he usado.
      Hoy trabajo más en C++ embebido, así que no uso mucho orientación a objetos, pero aprendí a programar con C# y estoy bastante acostumbrado a la herencia.
    • Godot es excelente, y creo que en unos 5 años será el Blender de la creación de juegos. La versión 4 ya es usable en producción y puede manejar la mayoría de los proyectos indie.
      Donde Unity lleva ventaja es en los niveles “Triple I” y “Double A”, porque tiene mejores funciones 3D/de rendimiento, herramientas y add-ons. Para proyectos AAA, ninguno de los dos es la mejor opción.
      En juegos 2D y 3D simples ya no veo razón para usar Unity; creo que Godot lo irá superando poco a poco y la cuota de Unity seguirá bajando.
    • Como desarrollador comercial, antes usaba Unity y ahora uso Godot. Comparto las críticas a GD Script y a las signals, y las evito usando manejo de eventos en C#.
      Lo más frustrante son los nodos y esas cosas que uno no sabe si son bugs del editor o features; da mucho la sensación de que al principio fue hecho para proyectos “pequeños”.
      Por eso casi no uso el editor salvo para componer scenes y configurar una jerarquía aproximada. Mis herramientas habituales son Emacs+C# LSP, VS Code para depurar, y el editor de Godot para ajustar el scene tree.
    • He usado Godot con bastante seriedad y tengo razones para no gustarme, pero no creo que GDScript sea una de ellas.
      Básicamente es Python con semántica de slot/emit e integrado con el editor, así que más bien está bien. Prefiero que esté dentro del lenguaje antes que integrarlo mediante un sistema de build, metadatos y archivos de configuración externos complejos.

  • Dicen que pueden simplificar el desarrollo de juegos, pero luego lanzan un montón de jerga como Clojure vectors, datomics, atoms, transactions y malli schemas. ¿Alguien puede explicarlo?

    • Si pulimos un poco la introducción, Core es una herramienta experimental que intenta simplificar la creación de action RPGs.
      Representa los elementos del juego y sus propiedades como estructuras de datos simples, y guarda todo el estado del juego en un único contenedor (app/state) para facilitar su gestión y actualización.
      Además, ofrece una GUI para editar el contenido del juego almacenado en un único archivo (resources/properties.edn), de modo que sea más accesible para no programadores, y busca validar los datos con schemas de Malli para mantener la consistencia del contenido y reducir errores.
    • Para ser justos, solo están preguntando si el desarrollo de juegos puede simplificarse. La respuesta probablemente sea “no”.
    • El obligatorio “simplicidad no es lo mismo que facilidad”: https://www.youtube.com/watch?v=SxdOUGdseq4
      Un Clojure vector es básicamente algo parecido a una lista. Un atom es una referencia mutable que apunta a una estructura de datos inmutable; se puede ver como un puntero con una semántica de actualización específica.
      Una transaction es similar a una transacción de base de datos: cambia varias estructuras de datos al mismo tiempo, pero solo hace commit si todas las operaciones tienen éxito; si fallan, hace rollback o reintenta.
      Un Malli schema es una forma de hacer verificación de tipos en un lenguaje de tipado dinámico, y Datomic es una implementación de base de datos no SQL basada en estructuras de datos inmutables: en lugar de sobrescribir cambios de forma destructiva, solo agrega datos, lo que permite volver a cualquier punto del pasado.
    • El lenguaje Clojure tiene un modelo de gestión de estado integrado, y este proyecto intenta aplicar ese modelo al desarrollo de juegos.
      Creo que la mejor forma de aprender ese modelo es ver la charla “Are we there yet” de Rich Hickey, el creador de Clojure.
    • Un Clojure vector es una estructura de datos integrada del lenguaje y se ve como [1 2 3].
      Yo la uso para construir efectos secundarios como [:tx/foo 3], y a eso lo llamo transaction, de forma parecida a Datomic. Aquí :tx/foo es una keyword que identifica de forma única el comportamiento de un componente.

  • Sinceramente, creo que este proyecto fracasó en la práctica. Es un desorden sobrediseñado y no tiene una estructura clara.
    El mayor problema es que no hay ninguna especificación. No hicieron una historia para el juego, o quizá pensaron que un juego no necesita historia. Así que simplemente se divirtieron programando en Clojure y se pusieron a codear como locos.

    • Para ser justos, muchos proyectos exitosos también son un desorden sobrediseñado y no tienen una estructura clara.
      Está bien que hayan intentado algo interesante, y es un área que le interesa a mucha gente.
    • Con solo reconocer que fue un hobby divertido y que quizá no sea tan simple como afirmaban, ya están por delante de mucha gente. Ojalá hayan aprendido mucho del proyecto.

  • Como desarrollador de juegos, este GitHub me parece ridículo. Es casi una parodia de la autoabsorción académica que los desarrolladores de juegos odian. Las capturas feas son la cereza del pastel.

    • Entonces, ¿no será que no encaja muy bien con este sitio? Hacker News suele tratar ideas nuevas e interesantes, no solo mejoras incrementales de C++ y Unity.
      Se me ocurren varios juegos que salieron de esta extraña autoabsorción académica. También está Jonathan Blow, mencionado en el comentario hermano, y en cuanto vi este proyecto pensé en Braid.
      La generación procedural también antes era un tema de torre de marfil, y todos los avances en gráficos 3D empezaron al principio como papers completamente poco realistas salidos de conferencias. Muchas cosas que hoy son mainstream en los juegos alguna vez fueron ideas académicas de nicho.
    • No creo que las capturas sean “feas”, pero sí estoy de acuerdo en que el README no sirve funcionalmente. No hay documentación ni ejemplos, ni explicación de por qué uno debería usarlo.
      Falla en el paso básico de comunicar qué hace.
    • También tiene valor crear algo intelectualmente estimulante. Aunque pases 100 horas haciendo datomics en Clojure y solo hagas 1 hora de contenido de niveles, 1 hora es más que 0 horas.
      Si por aburrimiento no habrías hecho nada, entonces sales ganando. Es parecido a la lógica de Jonathan Blow usando Jai en el desarrollo indie.
    • Igual dice que es experimental.

  • Me sorprende que haya generado tanta conversación aun con tan poca documentación en el repositorio. Viendo el código, parece más un proyecto que un motor de juegos.
    El property editor es interesante, pero creo que este post recibe votos más por el título que por el contenido.

  • Está bueno. Me alegra ver a otro desarrollador que hace desarrollo de juegos con Clojure, como yo. A veces uno se complica la vida a propósito :)
    Ahora estoy desarrollando un shooter TPS multijugador 3D en Clojure. Si les interesa, la demo está aquí: https://prototype-game.pages.dev
    Pronto también voy a publicar un artículo de blog sobre el recorrido de desarrollo.

    • Uno de mis momentos favoritos de internet es cuando varias personas entran a un espacio virtual, empiezan a correr improvisadamente y usan el chat dentro del juego.

  • Me gusta Clojure, pero ¿no es una elección algo rara para desarrollar videojuegos usar un lenguaje funcional con estructuras de datos inmutables?

    • Es totalmente posible y tiene trade-offs interesantes.
      Estos son algunos de mis textos favoritos sobre desarrollo de juegos 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
    • Se siente bastante natural. Como Clojure corre sobre la JVM, este proyecto usa libgdx internamente, se puede desplegar en todas las plataformas y además cuenta con un ecosistema grande de bibliotecas.
      Para lo demás, con Lisp se puede hacer casi cualquier cosa. Gracias a la forma en que Clojure maneja las estructuras de datos inmutables y a su excelente sistema de protocols (https://www.freshcodeit.com/blog/clojure-protocols-and-the-e...), pude dividir fácilmente todo el juego en componentes separados.
    • Tim Sweeney también parece estar apostando por esa dirección con Verse en UEFN. Verse es más bien como hacer Haskell más accesible.
    • No es tan raro. El próximo juego AA o AAA no lo va a usar, pero la inmutabilidad aparece mucho incluso en ámbitos muy interactivos como los reducers de React o Redux.
      Clojure tiene más potencial de rendimiento que Ruby o Python, y ambos se han usado realmente en juegos indie comerciales.
    • La programación funcional casi ni se ha intentado en serio en el desarrollo de juegos. Falta superposición entre la industria del desarrollo de juegos y la academia.
      Es natural que los estudios eviten riesgos y prefieran estrategias conocidas, como la orientación a objetos o usar ECS para grandes cantidades de entidades.
      Personalmente creo que la programación funcional podría encajar bien, pero primero hay que encontrar una arquitectura que resuelva problemas reales del desarrollo de juegos. Hay que empezar con experimentos pequeños, y las game jams son perfectas para eso.

  • Ya existe una plataforma comercial de creación de juegos llamada Core, que funciona sobre Unreal Engine 4.
    https://en.wikipedia.org/wiki/Core_(video_game)

  • Creo que eligieron mal el nombre. Ya se usa en este ámbito: https://www.coregames.com/create

    • Fue lo primero que se me vino a la mente también. Sobre todo porque en ese caso se trata de crear juegos dentro de un juego, así que también podría verse como una “nueva” forma de escribir juegos.

  • Sería interesante analizar datos sobre “tiempo/complejidad invertidos en el motor de juego” frente a “complejidad/interés del juego resultante”.
    Como desarrollador de juegos, esperaría que el rendimiento de nuevos juegos surgidos de sistemas simples de plantillas/motores fuera una curva logarítmica con rendimientos decrecientes.
    En otras palabras, cuanto mejor haces la máquina de cortar galletas, menos variedad tienen las galletas.