Core, une nouvelle technologie expérimentale pour créer des jeux vidéo

 (github.com/damn)
2 points par GN⁺ 2024-09-09 | 1 commentaires | Partager sur WhatsApp

  • Qu’est-ce que coreCore ?

    • coreCore est une méthode expérimentale d’écriture de jeux vidéo sous la forme d’un outil et moteur de création de jeux d’action-RPG, avec un éditeur de propriétés
    • Il utilise un système de composants simple, où les composants sont des vecteurs Clojure de la forme [keyword value]
    • Les différentes entités sont composées de maps Clojure
    • Les effets de bord dans le jeu sont traités via des composants comme [:tx/foo param], dans une structure similaire à Datomic
    • L’état global du jeu est stocké dans un unique atom appelé app/state, et les entités existent elles aussi comme des atoms à l’intérieur de l’atom principal
    • L’intégralité du contenu de l’application est stockée dans resources/properties.edn, validée avec des schémas Malli et modifiable via une interface GUI

  • Captures d’écran

  • Comment démarrer le développement

    • Saisir la commande suivante :
      • lein dev
    • L’application démarre et effectue aussi les opérations suivantes :
      • démarrage du serveur NREPL
      • à la fermeture de l’application (ESC dans le menu principal), clojure.tools.namespace recharge les fichiers modifiés et redémarre l’application
      • en cas d’erreur, il suffit de corriger le problème et d’appeler dev-loop/restart! sans avoir à redémarrer la JVM
      • dans VIM, on peut lier la touche F5 à la commande suivante : nmap <F5> :Eval (do (in-ns 'dev-loop)(restart!))

  • Licence du code

    • Fourni sous licence MIT

  • Licence des assets

Résumé de GN⁺

  • coreCore est un outil permettant de créer facilement des jeux d’action-RPG, en gérant l’état du jeu avec un système de composants simple
  • Le stockage de tout l’état du jeu dans un seul atom et l’édition des propriétés via une interface GUI en font un outil utile pour les développeurs
  • Il est proposé sous licence MIT, mais les assets utilisés sont propriétaires
  • Parmi les outils aux fonctionnalités similaires, on peut citer RPG Maker ou Unity

À lire aussi

1 commentaires

 
GN⁺ 2024-09-09
Commentaires sur Hacker News

  • Excellent. Je n’ai jamais sorti de jeu, mais j’aime toujours voir des approches différentes du développement de jeux.
    Jusqu’ici, Bevy m’a semblé séduisant au début, mais avec beaucoup de problèmes d’implémentation et un risque de devenir brouillon ; Unity, avec son approche par gameobjects et composants composables, était la plus pratique : le moteur ne se mettait pas en travers et il était plus facile d’éviter le spaghetti.
    Je n’ai pas aimé Godot. Une mauvaise hiérarchie orientée objet, un langage intégré médiocre, et les « signals », censés réduire le spaghetti, en ajoutaient au contraire. Pygame est plutôt bien pour les petits projets, et permet de superposer soi-même des couches orientées objet ou fonctionnelles sur une base procédurale.
    Je ne connais pas Clojure, mais je trouve intéressant d’essayer une implémentation fonctionnelle dans un domaine qui semble typiquement bien adapté à l’orienté objet.

    • En tant que développeur de jeux professionnel ayant créé de vrais produits avec Unity comme avec Godot, je suis en total désaccord avec cette évaluation de Godot et Unity.
      Les signals de Godot sont un grand progrès par rapport au manque de modularité des classes intégrées d’Unity. Godot et Unity reposent fondamentalement sur le même modèle scène/nœud/composant, mais je trouve que Godot le fait mieux.
      Les points forts d’Unity sont son moteur de rendu 3D, PhysX intégré, le backend il2cpp pour C#, le profiler, les performances d’exécution globales et la prise en charge des consoles. En revanche, la conception de Godot est plus cohérente, tandis qu’Unity donne l’impression, depuis environ 2018, de s’être fragmenté dans dix directions.
    • Je ne suis pas développeur de jeux, mais la conception orientée objet de Godot fait partie des meilleures que j’aie utilisées.
      Aujourd’hui je travaille plutôt en C++ embarqué, donc je n’utilise pas beaucoup l’orienté objet, mais j’ai appris à programmer en C#, donc l’héritage m’est familier.
    • Godot est excellent, et je pense que dans environ cinq ans il deviendra le Blender de la création de jeux. La version 4 est utilisable en production et peut couvrir la plupart des projets indépendants.
      Là où Unity garde l’avantage, c’est sur les productions de niveau « Triple I » et « Double A », grâce à de meilleures fonctionnalités 3D/performance, de meilleurs outils et add-ons. Pour les projets AAA, aucun des deux n’est le meilleur choix.
      Pour les jeux 2D et 3D simples, je ne vois désormais plus de raison d’utiliser Unity, et je pense que Godot va lentement prendre le dessus tandis que la part d’Unity diminuera régulièrement.
    • En tant que développeur commercial, j’utilisais Unity autrefois et j’utilise Godot aujourd’hui. Je comprends les critiques envers GD Script et les signals, et je les contourne avec la gestion d’événements en C#.
      Ce qui me frustre le plus, ce sont les nœuds et les comportements de l’éditeur dont on ne sait pas s’il s’agit de bugs ou de fonctionnalités ; on sent fortement qu’il a été conçu au départ pour de « petits » projets.
      Du coup, j’utilise très peu l’éditeur en dehors de la composition des scènes et de la mise en place approximative de la hiérarchie. Mes outils habituels sont Emacs + C# LSP, VS Code pour le débogage, et l’éditeur Godot pour ajuster le scene tree.
    • J’ai utilisé Godot assez sérieusement, et j’ai des raisons de ne pas l’aimer, mais GDScript n’en fait pas partie selon moi.
      C’est essentiellement du Python avec une sémantique slot/emit ajoutée et une intégration à l’éditeur, donc c’est plutôt correct. Je préfère que ce soit dans le langage plutôt que dans un système de build, des métadonnées ou une intégration compliquée via des fichiers de configuration externes.

  • On annonce qu’on peut simplifier le développement de jeux, puis on balance une pile de jargon comme Clojure vectors, datomics, atoms, transactions et schémas malli. Quelqu’un peut expliquer ?

    • En reformulant l’introduction, Core est un outil expérimental visant à simplifier la création d’action-RPG.
      Il représente les éléments de jeu et leurs propriétés sous forme de structures de données simples, et stocke tout l’état du jeu dans un seul conteneur (app/state) afin d’en faciliter la gestion et la mise à jour.
      Il fournit aussi une GUI pour éditer le contenu du jeu stocké dans un fichier unique (resources/properties.edn), afin de le rendre accessible aux non-programmeurs, et vise à assurer la cohérence du contenu et à réduire les erreurs grâce à une validation des données avec des schémas Malli.
    • Pour être juste, il ne fait que demander si le développement de jeux peut être simplifié. La réponse est probablement « non ».
    • L’inévitable « simple ne veut pas dire facile » : https://www.youtube.com/watch?v=SxdOUGdseq4
      Un vector Clojure est fondamentalement proche d’une liste. Un atom est une référence mutable vers une structure de données immuable, qu’on peut voir comme un pointeur doté d’une sémantique de mise à jour particulière.
      Une transaction ressemble à une transaction de base de données : elle modifie plusieurs structures de données en même temps, mais ne commit que si toutes les opérations réussissent ; en cas d’échec, elle rollback ou réessaie.
      Un schéma Malli est une manière de faire de la vérification de types dans un langage à typage dynamique, et Datomic est une implémentation de base de données non-SQL fondée sur des structures de données immuables : au lieu d’écraser destructivement les changements, elle ne fait qu’ajouter, ce qui permet de revenir à n’importe quel moment dans le passé.
    • Le langage Clojure possède un modèle de gestion d’état intégré, et ce projet tente d’appliquer ce modèle au développement de jeux.
      À mon avis, la meilleure manière d’apprendre ce modèle est de regarder la conférence « Are we there yet » de Rich Hickey, le créateur de Clojure.
    • Un vector Clojure est une structure de données intégrée au langage, qui ressemble à [1 2 3].
      Je m’en sers pour composer des effets de bord comme [:tx/foo 3], et je les appelle transactions, de manière similaire à Datomic. Ici, :tx/foo est un keyword qui identifie de façon unique le comportement d’un composant.

  • Honnêtement, je pense que ce projet a échoué en pratique. C’est un fouillis surconçu, sans structure claire.
    Le plus gros problème est l’absence totale de spécification. Soit l’histoire du jeu n’a pas été écrite, soit on a peut-être pensé qu’un jeu n’avait pas besoin d’histoire. Résultat : le développeur a simplement codé frénétiquement parce que coder en Clojure était amusant.

    • Pour être juste, beaucoup de projets réussis sont aussi des fouillis surconçus sans structure claire.
      C’est bien d’avoir essayé quelque chose de cool, et c’est un domaine qui intéresse beaucoup de monde.
    • Le simple fait de reconnaître que c’était juste un hobby amusant, et que ce n’est peut-être pas aussi simple que ce qui était affirmé, le place déjà devant beaucoup de gens. J’espère que le projet lui aura beaucoup appris.

  • En tant que développeur de jeux, ce GitHub me paraît ridicule. C’est presque une parodie de l’auto-absorption académique que les développeurs de jeux détestent. Les captures d’écran moches parachèvent le tout.

    • Dans ce cas, ce site n’est-il pas plutôt mal adapté ? Hacker News traite généralement de nouvelles idées intéressantes, pas seulement d’améliorations incrémentales de C++ et Unity.
      Je peux penser à quelques jeux issus de ce genre d’étrange auto-absorption académique. Jonathan Blow, mentionné dans un commentaire frère, en est un exemple, et ce projet m’a immédiatement fait penser à Braid.
      La génération procédurale aussi était autrefois un sujet de tour d’ivoire, et toutes les avancées de la 3D ont commencé par des articles de conférence totalement irréalistes. Beaucoup de choses aujourd’hui courantes dans les jeux ont un jour été des idées académiques de niche.
    • Je ne trouve pas les captures d’écran « moches », mais je suis d’accord pour dire que le README est fonctionnellement inutile. Il n’y a ni documentation ni exemples, ni explication de pourquoi on devrait l’utiliser.
      Il échoue à l’étape la plus élémentaire : communiquer ce que ça fait.
    • Il y a aussi de la valeur à créer quelque chose de stimulant intellectuellement. Même si l’on passe 100 heures à faire des datomics en Clojure et seulement 1 heure à créer du contenu de niveau, 1 heure vaut mieux que 0.
      Si l’alternative était de ne rien faire du tout par ennui, c’est plutôt un gain. C’est similaire à la logique de Jonathan Blow utilisant Jai dans le développement indé.
    • C’est bien indiqué comme expérimental.

  • Je suis surpris qu’une conversation aussi fournie soit née alors que la documentation de ce dépôt est si maigre. En regardant le code, ça ressemble davantage à un projet qu’à un moteur de jeu.
    Le property editor est intéressant, mais j’ai l’impression que ce billet est recommandé davantage pour son titre que pour son contenu.

  • Bien. Ça fait plaisir de voir un développeur qui fait du développement de jeux en Clojure comme moi. Même si parfois on se complique la vie soi-même :)
    En ce moment, je développe un shooter TPS multijoueur 3D en Clojure. Si cela vous intéresse, la démo est ici : https://prototype-game.pages.dev
    Je publierai bientôt aussi un billet de blog sur mon parcours de développement.

    • Le moment où plusieurs personnes entrent dans un espace virtuel, se mettent spontanément à courir partout et utilisent le chat en jeu est l’une de mes scènes préférées sur Internet.

  • J’aime Clojure, mais un langage fonctionnel utilisant des structures de données immuables n’est-il pas un choix un peu étrange pour le développement de jeux vidéo ?

    • C’est tout à fait possible, avec des compromis intéressants.
      Voici des articles que j’aime sur le développement de jeux fonctionnel :
      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
    • Ça me paraît assez naturel. Comme Clojure repose sur la JVM, ce projet utilise libgdx en interne, peut être déployé sur toutes les plateformes, et bénéficie d’un grand écosystème de bibliothèques.
      Pour le reste, on peut faire à peu près n’importe quoi avec Lisp. Grâce à la manière dont Clojure gère les structures de données immuables et à son excellent système de protocols (https://www.freshcodeit.com/blog/clojure-protocols-and-the-e...), il a été facile de diviser tout le jeu en composants distincts.
    • Tim Sweeney semble lui aussi parier sur cette direction avec Verse dans UEFN. Verse ressemble davantage à une version plus accessible de Haskell.
    • Ce n’est pas si étrange. Le prochain jeu AA ou AAA ne l’utilisera sans doute pas, mais on voit souvent l’immuabilité dans des domaines très interactifs comme les reducers de React ou Redux.
      Clojure a un potentiel de performance supérieur à Ruby ou Python, et ces deux langages ont déjà été réellement utilisés dans des jeux indés commerciaux.
    • La programmation fonctionnelle n’a quasiment jamais été sérieusement essayée dans le développement de jeux. Il y a trop peu de recouvrement entre l’industrie du jeu et le monde académique.
      Les studios sont naturellement réticents au risque et préfèrent des stratégies familières comme l’orienté objet ou l’ECS pour les grandes foules.
      Personnellement, je pense que la programmation fonctionnelle pourrait bien convenir, mais il faut d’abord trouver une architecture qui résolve de vrais problèmes de développement de jeux. Il faut commencer par de petites expérimentations, et les game jams sont parfaites pour cela.

  • Il existe déjà une plateforme commerciale de création de jeux appelée Core, qui fonctionne sur Unreal Engine 4.
    https://en.wikipedia.org/wiki/Core_(video_game)

  • Le nom me semble mal choisi. Il est déjà utilisé dans ce domaine : https://www.coregames.com/create

    • C’est aussi la première chose à laquelle j’ai pensé. Surtout que, là-bas, il s’agit de créer des jeux à l’intérieur d’un jeu, ce qui peut aussi être vu comme une « nouvelle » façon d’écrire des jeux.

  • Il serait intéressant d’analyser les données « temps/complexité consacrés au moteur de jeu » par rapport à « complexité/intérêt du jeu produit ».
    En tant que développeur de jeux, je m’attendrais à ce que le rendement des nouveaux jeux issus de simples systèmes de templates/moteurs suive une courbe logarithmique décroissante.
    Autrement dit, plus on améliore la machine à fabriquer des cookies, moins les cookies sont variés.