Présentation sur HN : mon moteur de jeu devient open source

 (github.com/moddio)
2 points par GN⁺ 2023-12-22 | 1 commentaires | Partager sur WhatsApp

Moteur de jeu Moddio 2

  • Moddio est un moteur de jeu conçu avec le multijoueur comme priorité.
  • Il intègre du code réseau à autorité serveur, l’interpolation par instantanés et des mécanismes de compensation côté client.
  • Il prend en charge plus de 50 joueurs simultanés ou plus de 300 objets en mouvement sur une VM à 5 dollars par mois.

Démo

  • Inclus d’emblée : moteur physique Box2D, code réseau à autorité serveur, système d’inventaire et d’objets, attributs intégrés (HP, énergie, etc.) et leur taux de régénération, système de dialogue, boutique, contrôle des unités, projectiles avec prédiction côté client et déplacement des unités, IA des unités et pathfinding A*, contrôles mobiles, etc.

Comment lancer le jeu

  • Node 18 ou version ultérieure est requis.
  • Après avoir configuré le dépôt, allez dans le répertoire /src, renommez game-sample.json en game.json, revenez au répertoire racine et lancez le serveur.
  • Vous pouvez ensuite jouer au jeu sur http://localhost:80.

Comment créer un nouveau jeu à partir de zéro

  • Les jeux Moddio sont créés et modifiés avec l’éditeur de jeux Moddio disponible sur https://www.modd.io.
  • Après avoir créé un jeu, vous pouvez exporter un game.json utilisable dans une installation locale.
  • Renommez le JSON du jeu exporté en game.json et déplacez-le dans le répertoire ./src.

Comment contribuer

  • Moddio est entièrement gratuit et open source sous licence MIT.
  • Pour savoir comment devenir contributeur, consultez la page expliquant comment contribuer.

Crédits

  • Isogenic Game Engine, Phaser, PlanckJS, uWebsocket, Box2D, assets Kenney, Hero Icons, etc. sont utilisés.

Avis de GN⁺

  • Le moteur de jeu Moddio est spécialisé dans le développement de jeux multijoueurs et offre des fonctionnalités puissantes permettant de prendre en charge de nombreux joueurs à faible coût.
  • Open source, il continue d’évoluer grâce aux contributions de la communauté, ce qui le rend aussi accessible aux ingénieurs logiciels débutants.
  • Il intègre de nombreuses fonctionnalités nécessaires au développement de jeux, offrant aux développeurs un environnement où ils peuvent créer rapidement des prototypes et les tester.

À lire aussi

1 commentaires

 
GN⁺ 2023-12-22
Avis sur Hacker News

  • Dans l’écran d’inscription de l’app Android, on demande de saisir le nom d’utilisateur et le mot de passe Google dans ce qui ressemble à un formulaire web à l’intérieur de l’app, et l’utilisateur n’a aucun moyen de savoir si l’app espionne son mot de passe.
    D’habitude, il me semble que les apps utilisent un flux qui redirige vers un écran de connexion puis revient dans l’app ; je me demande si ce pattern est difficile à implémenter. Je me demande aussi si c’est un problème lié au support cross-platform.

    • En principe, ce n’est pas particulièrement difficile. En travaillant avec des constructeurs automobiles, nous devons faire en sorte que l’utilisateur se connecte avec un compte OEM ; en théorie, ils disent tous être conformes, mais en pratique beaucoup de choses ne fonctionnent pas et les corrections prennent longtemps.
      Cela dit, la méthode décrite plus haut ne devrait vraiment pas arriver, et je pensais que Google l’avait déjà interdite.
    • Ça s’appelle OAuth 2.0, et c’est simple à implémenter avec quelque chose comme Okta.

  • Faire adopter un moteur de jeu par les utilisateurs n’est jamais facile, et c’est encore plus difficile s’il est closed source.
    À voir la galerie de jeux sur le site, ils semblent s’en être plutôt bien sortis jusqu’ici ; je me demande si ce sont quelques amis qui les ont créés, ou s’il existe une communauté assez active.

    • La combinaison de bonnes fonctionnalités, d’un apprentissage facile et d’une faible barrière à l’entrée peut mener assez loin.
      Il faut imaginer une structure où l’on peut obtenir un résultat significatif en y consacrant seulement quelques jours, voire quelques heures, de manière casual. Il suffit de se souvenir de Flash.
    • Il y a une communauté active, qui crée 150 à 300 nouveaux jeux chaque jour.
      Le fait que la barrière à l’entrée soit basse, aussi bien pour les développeurs de jeux que pour les joueurs, aide clairement. Pas besoin de téléchargement ni d’inscription.

  • Rien qu’au titre, je n’aurais pas deviné qu’il s’agissait de modd.io. C’est un framework/une plateforme populaire pour créer des jeux IO.

    • Je joue beaucoup et j’ai même déjà vendu des jeux par le passé, mais je n’ai jamais entendu ce terme. C’est quoi, un jeu IO ?

  • Je suis allé sur un serveur Brains et je voulais voir à quoi ressemblait l’expérience avec une cinquantaine de joueurs. Comme on pouvait s’y attendre avec des WebSockets, les mouvements étaient un peu saccadés, et comme je construis quelque chose de similaire, je me posais aussi des questions sur la compression réseau.
    Je ne suis pas sûr que la seule compression LZ-string suffise. Avec 50 joueurs, ça consomme environ 20 Ko par seconde, alors que Warzone n’utilise qu’environ 48 Ko par seconde pour 150 joueurs. Si les données ne sont pas illimitées, les coûts de bande passante cloud peuvent vite grimper.
    C’était aussi étonnant de voir que le buffer d’octets compressé ressemblait à 埒愑䣔橤㤰゙㟍稦獦ঙ惝䓇強栛䳌۬䌃̩佼. Je ne sais pas si c’est normal pour le résultat d’une compression LZ-string, mais ça paraît assez inhabituel.
    Quoi qu’il en soit, pour réduire les coûts potentiels, il y a beaucoup de marge d’amélioration côté networking. L’ensemble du projet est très impressionnant et très bien réalisé.

    • Chez nous, avec les WebSockets, les mouvements sont assez réactifs : https://gooberdash.winterpixel.io/
      La clé, ce sont la prédiction côté client et un algorithme de networking avec rollback. L’état de notre jeu fait environ 1 Ko à 30 Hz, donc il tient généralement dans un seul paquet, et les WebSockets ne sont donc pas si mauvais. Bien sûr, un protocole non fiable serait préférable.
    • Peux-tu expliquer un peu plus ce que tu entends par « comme on pouvait s’y attendre avec des WebSockets, les mouvements étaient un peu saccadés » ? J’ai essayé quelques « jeux IO » et, à part certains joueurs avec une forte latence de temps en temps, ça m’a semblé assez fluide.
      J’ai fait quelques tests avec WebSockets il y a quelques mois, et d’après ce que j’ai compris, utiliser TCP pour des communications sensibles à la latence, comme dans les jeux, présente de sérieux inconvénients. L’en-tête TCP est plus de deux fois plus gros que celui d’UDP, il y a des paquets de contrôle supplémentaires, et l’envoi de nouvelles données est retardé pendant que d’anciennes données sont retransmises. WebSockets fonctionne aussi au-dessus de TCP, donc il a les mêmes inconvénients.
      Malgré cela, on dit que TCP garantit la livraison des messages WebSocket, mais j’ai réussi à reproduire des pertes de paquets. Au final, les inconvénients restent, et si l’on a vraiment besoin d’une livraison garantie, il faut construire quelque chose soi-même par-dessus ; dans ce cas, on aurait aussi bien pu le faire dès le départ au-dessus d’UDP uniquement pour les messages qui en ont besoin.
      Je n’ai presque pas de connaissances ni d’expérience en networking, à part quelques essais, donc à prendre avec des pincettes.
    • Les caractères CJK représentent une très grande part des caractères Unicode imprimables. [1] Les deux plus grands blocs incluent U+3400 à U+4DBF et U+4E00 à U+9FFF.
      La chaîne en question se décode en \u57d2\u6111\u48d4\u6a64\u3930\u3099\u37cd\u7a26\u7366\u0999\u60dd\u44c7\u5f37\u681b\u4ccc\u06ec\u4303\u0329\u4f7c.
      [1] https://en.wikipedia.org/wiki/CJK_Unified_Ideographs

  • Le moyen le plus sûr de ne jamais terminer un jeu, c’est de commencer par écrire un moteur.
    Créer sa propre technologie est tout à fait possible, mais à chaque étape, cette technologie doit être adaptée à son propre projet, pas à une plateforme de jeu généraliste.

    • Il faut que je lance un blog !
      Par « lancer un blog », j’entends créer un nouveau moteur de blog entièrement from scratch.
    • Peux-tu préciser de quelle partie de modd.io tu parles ? Tu veux dire que c’est le résultat d’une tentative ratée de créer un jeu ?
    • La plupart des personnes qui utilisent un moteur veulent probablement, dès le départ, non pas vraiment créer un jeu, mais en réalité créer un moteur.

  • J’ai déjà vu des backends multijoueurs basés sur Node.js finir par ralentir au point de se traîner quand le nombre de connexions augmente. Je me demande comment ce problème a été résolu ici
    Dans ce cas, une alternative comme Go ne serait-elle pas meilleure ?

    • Je ne vois pas très bien pourquoi. Côté connexions, grâce à la boucle d’événements de Node, le blocage des E/S sur les requêtes/réponses HTTP ne devrait pas poser problème
      Je ne pense pas non plus que le backend fasse de lourds calculs de physique pour le frontend
    • On utilise uWebSockets(https://github.com/uNetworking/uWebSockets). C’est écrit en C, mais il existe une interface utilisable depuis NodeJS
      Dans des tests simples, les performances étaient nettement meilleures que celles d’autres bibliothèques WebSocket populaires qui ralentissent rapidement
    • Dans la plupart des jeux .io, le goulot d’étranglement est probablement les E/S. Le nom du genre vient du domaine de premier niveau, même si ça ressemble à un jeu de mots
      Donc Node me semble être un bon choix
    • La scalabilité peut effectivement être un vrai sujet, surtout avec beaucoup de connexions. Dans notre cas, nous avons optimisé le backend pour gérer efficacement un nombre important de connexions simultanées
      Chaque partie est limitée à 64 joueurs au maximum, mais lors de tests avec plus de 100 connexions, nous n’avons pas observé de problème de performances. Chaque partie s’exécute dans un conteneur isolé

  • Je suis curieux de connaître la motivation derrière la création d’un nouveau moteur
    À lire le README, il intègre des choses assez spécifiques comme un système d’armes (corps à corps/projectiles), une boutique, la prédiction côté client pour les projectiles et les déplacements d’unités
    Je me demande pourquoi avoir intégré tout cela directement dans le moteur, plutôt que d’en faire des plugins copiables. Bien sûr, beaucoup de jeux n’ont pas besoin de ces fonctionnalités : est-ce vraiment un moteur de jeu ? Ou un moteur pour FPS/RPG/autres genres spécifiques ?
    Je n’ai rien contre la technologie elle-même, mais la question du « pourquoi ? » demeure. À quoi ça sert ? Pourquoi devrais-je utiliser ça plutôt que Three.js et mon propre serveur ?

    • Merci pour la question. Nous avons consciemment décidé de rendre le moteur plus opinionated que d’autres alternatives modulaires, parce que nous voulons permettre de développer des jeux multijoueurs 2D extrêmement rapidement
      Par exemple, nous avons créé un MMORPG simple en 2 heures : https://www.youtube.com/watch?v=GZVsxkALR5U
      Selon nous, il existe un compromis inverse entre la facilité d’utilisation et le niveau de personnalisation. Nous avons choisi la première option pour réduire l’écart entre les jeux multijoueurs, réputés difficiles à créer, et les développeurs de jeux casual
    • « À quoi ça sert ? »
      Je ne pense pas que ce soit fait pour vous, mais plutôt pour les gens qui veulent créer ce type précis de jeux. Tous les moteurs n’ont pas besoin d’être généralistes

  • J’avais quelques projets perso qui auraient sans doute bien collé avec ça. Je sais coder, mais quand je travaille sur un projet hobby, il y a des moments où je n’ai pas envie de m’y plonger autant, donc le low-code et un éditeur interactif me semblent intéressants pour les développeurs amateurs
    Ce qui m’enthousiasme le plus, personnellement, c’est la génération de cartes et de mondes. J’ai l’impression que la meilleure méthode serait d’exporter le jeu en JSON, de le modifier par programme, puis de le réimporter ; je me demande si c’est bien le cas
    Cela dit, c’est un peu intimidant. Le monde du tutoriel non modifié fait 3 500 lignes de JSON, donc il y a beaucoup de choses à comprendre
    La première approche qui me vient à l’esprit serait de faire volontairement des modifications dans l’éditeur et de voir comment le JSON change. Il faudrait aussi que je trouve un bon visualiseur de diff JSON. Ça devrait m’aider à repérer les parties que je veux toucher. Les assets et les tuiles de carte, je les rassemblerais probablement dans l’éditeur interactif
    Je me demande si cette approche est raisonnable, et s’il existe des outils utiles pour ça

    • Je ne recommande pas de modifier directement le JSON. Il est assez difficile à lire et très verbeux. modd.io propose des actions permettant de modifier directement les cartes
      Un créateur de notre communauté génère dynamiquement des cartes avec ChatGPT. Il travaille sur un jeu de cache-cache : il envoie un prompt demandant de générer du JSON pour une carte 2D, puis charge cette carte à chaque nouveau round. Comme ce n’est pas encore public, il est difficile de partager le jeu
      Un autre membre de la communauté développe aussi un interpréteur pour notre JSON de jeu. Exemple : https://pypi.org/project/pymodd/

  • C’est agréable de voir davantage de projets open source comme celui-ci apparaître. Je suis surpris qu’il ait moins de 100 étoiles GitHub

    • Ne le prenez pas mal, je pose vraiment la question par curiosité : pourquoi est-ce surprenant qu’il ait moins de 100 étoiles GitHub ?
    • C’est peut-être parce qu’il vient tout juste d’être publié