Derniers messages
Dernier message par Lyne - 10 Avril 2025 à 21:45:55
Cliquez pour afficher le message
Compte-rendu du point hebdo du 10/04/2025
Lyne
Au regard des derniers votes, je décide arbitrairement en accord avec moi-même na même que, que l'AG aura lieu le samedi 17 mai à 21h
Et dès que j'aurai fait chauffer le thé, j'enverrai un message à toutes les inscrites de la mailing list, pour justifier l'existence d'une mailing list en les prévenant de la dite date
(NdR : Mail envoyé entre la fin du point et la publication du compte-rendu. Surveillez vos boites mail si vous êtes inscrite à la Newsletter)
aleajactaest
Toujours sur la partie serveur, je suis tombé sur un bogue et je regarde
Lyne
Au regard des derniers votes, je décide arbitrairement en accord avec moi-même na même que, que l'AG aura lieu le samedi 17 mai à 21h
Et dès que j'aurai fait chauffer le thé, j'enverrai un message à toutes les inscrites de la mailing list, pour justifier l'existence d'une mailing list en les prévenant de la dite date
(NdR : Mail envoyé entre la fin du point et la publication du compte-rendu. Surveillez vos boites mail si vous êtes inscrite à la Newsletter)
aleajactaest
Toujours sur la partie serveur, je suis tombé sur un bogue et je regarde

Dernier message par Lyne - 04 Avril 2025 à 21:58:56
Cliquez pour afficher le message
Compte-rendu du point hebdo du 03/04/2025
aleajactaest
De mon côté, j'avance sur la partie serveur
YannK
J'ai juste bossé un peu sur l'architecture, mais rien encore à vous montrer.
aleajactaest, tu connais Bevy ? C'est un moteur de jeu en Rust qui est en plein boom
https://bevyengine.org/
Il n'est pas du tout prêt à faire de la prod (ils le déconseillent d'ailleurs)
Mais tu y trouveras peut-être des idées
Je l'ai découvert car je me disais qu'on aurait peut-être intérêt à penser Entity Component Systems et Bevy est justement pensé pour une telle archi, qui me semblerait vraiment pas mal pour tout ce qui est serveurs
On va rester avec Godot même pour ceux-ci car de toute façon, on n'a pas les moyens humains de bosser en Rust et quoiqu'il arrive on pourra toujours se servir de Godot comme de template si jamais on a ensuite besoin de passer à du code plus performant
aleajactaest
De mon côté, j'avance sur la partie serveur
YannK
J'ai juste bossé un peu sur l'architecture, mais rien encore à vous montrer.
aleajactaest, tu connais Bevy ? C'est un moteur de jeu en Rust qui est en plein boom
https://bevyengine.org/
Il n'est pas du tout prêt à faire de la prod (ils le déconseillent d'ailleurs)
Mais tu y trouveras peut-être des idées
Je l'ai découvert car je me disais qu'on aurait peut-être intérêt à penser Entity Component Systems et Bevy est justement pensé pour une telle archi, qui me semblerait vraiment pas mal pour tout ce qui est serveurs
On va rester avec Godot même pour ceux-ci car de toute façon, on n'a pas les moyens humains de bosser en Rust et quoiqu'il arrive on pourra toujours se servir de Godot comme de template si jamais on a ensuite besoin de passer à du code plus performant
Dernier message par Lyne - 27 Mars 2025 à 23:26:30
Cliquez pour afficher le message
Compte-rendu du point hebdo du 27/03/2025
YannK
J'ai continué à bosser sur l'architecture, je pense que j'ai fait assez de tests sur ce dont on a besoin en gros pour nos envies
J'ai commencé à tracer quelques schémas avec draw.io, mais il y a encore du taf
J'ai aussi joué un peu avec les grammaires génératives sous Godot : https://kloud.khaganat.net/s/Wyk3PF2BkpH2F5w
Ce que vous voyez, c'est du texte généré aléatoirement avec une grammaire qui intègre des contextes (les tags à droite) pour aller sélectionner les éléments dans lesquels ensuite choisir au hasard.
Je me suis dit que ça serait intéressant pour les PNJs et dans l'idée d'essayer de faire de l'émergence, c'est une première étape
Là c'est juste un prototype basique, je vais en faire une classe propre qu'on pourra instancier avec une grammaire et un context pour obtenir un texte. Et ça sera une des bases narratives du jeu
tycho
Je n'ai rien fait cette semaine, mais ayant été absent au dernier point je n'ai pas pu dire que j'avais mis en place un uptime-kuma afin de surveiller certains et certificats de sécurité
https://uptime.numenaute.org/
niveau admin il n'y a malheureusement qu'un seul compte et pas de possibilité d'en créer d'autres
il y a une page de statut spécial khaganat : https://uptime.numenaute.org/status/khaganat
aleajactaest
De mon côté, toujours sur la partie serveur, la j'ai étudier le rechargement à chaud des certificats
Zatalyz
Je copie vite fait mon blabla
J'ai voulu mettre en place un site perso, et du coup j'ai testé la doc, trouvé des erreurs, corrigé... ce qui va être mieux pour les prochains ! Et sinon le-dit site est une bêtise mais carrément dans l'objet de l'asso Khaganat. Bien qu'il n'y aie aucun rapport avec Khanat. Je vous ferais découvrir ça... dans quelques jours. Ça me prend un temps que je ferais mieux de passer sur plus utile, mais je m'amuse follement, alors voilà ! (et je laisse la parole au suivant)
K'Deed
a mis 2 fois Forgejo à jour 10.0.2 et 10.0.3
Lyne
J'ai fait les comptes du mois
Il me reste à les publier sur le Kloud
(NdR : publication faite entre le point hebdo et la rédaction du compte-rendu)
YannK
J'ai continué à bosser sur l'architecture, je pense que j'ai fait assez de tests sur ce dont on a besoin en gros pour nos envies
J'ai commencé à tracer quelques schémas avec draw.io, mais il y a encore du taf

J'ai aussi joué un peu avec les grammaires génératives sous Godot : https://kloud.khaganat.net/s/Wyk3PF2BkpH2F5w
Ce que vous voyez, c'est du texte généré aléatoirement avec une grammaire qui intègre des contextes (les tags à droite) pour aller sélectionner les éléments dans lesquels ensuite choisir au hasard.
Je me suis dit que ça serait intéressant pour les PNJs et dans l'idée d'essayer de faire de l'émergence, c'est une première étape
Là c'est juste un prototype basique, je vais en faire une classe propre qu'on pourra instancier avec une grammaire et un context pour obtenir un texte. Et ça sera une des bases narratives du jeu

tycho
Je n'ai rien fait cette semaine, mais ayant été absent au dernier point je n'ai pas pu dire que j'avais mis en place un uptime-kuma afin de surveiller certains et certificats de sécurité
https://uptime.numenaute.org/
niveau admin il n'y a malheureusement qu'un seul compte et pas de possibilité d'en créer d'autres
il y a une page de statut spécial khaganat : https://uptime.numenaute.org/status/khaganat
aleajactaest
De mon côté, toujours sur la partie serveur, la j'ai étudier le rechargement à chaud des certificats
Zatalyz
Je copie vite fait mon blabla

K'Deed
a mis 2 fois Forgejo à jour 10.0.2 et 10.0.3
Lyne
J'ai fait les comptes du mois
Il me reste à les publier sur le Kloud
(NdR : publication faite entre le point hebdo et la rédaction du compte-rendu)
Dernier message par Lyne - 20 Mars 2025 à 22:35:14
Cliquez pour afficher le message
Compte-rendu du point hebdo du 20/03/2025
Lyne
Je crois que je vais de ce pas mettre un rappel sur le marronnier pour qu'on fixe la date de l'AG
https://khaganat.net/forum/index.php?topic=809.msg3314#new
Si j'en crois : https://framadate.org/tkdn1aK44aDsfqZ3, on partirait pour l'instant sur le 17 mai, ou un week-end de juin
Personnellement, le 17 mai m'irait bien : comme ça, c'est fait
Mais il y a des membres qui n'ont pas voté (on a 6 votes pour 10 membres. Non, je ne dénoncerai pas ici)
https://carnets.numenaute.org/p/Khaganat_AG_2025
Et y'a un appel à volontaires aussi : qui veut être au Collège l'an prochain ?
YannK
De mon côté, cette semaine, j'ai réparé des détails dans le prototype, cassés avec le passage à Godot 4.4, rien de grave. J'ai aussi avancé sur le système de compétences, mais il va falloir que je mette par écrit un peu l'archi pour aller plus loin je pense. Même moi je vais finir par m'y perdre
Mais bon, notre testeuse semble contente du petit test de compétence de saut
https://kloud.khaganat.net/s/B2sZePHRKSCeYRA
J'ai aussi trouvé un moyen pour importer environ 2600 motion captures dans Blender. J'ai des tas d'animations brutes à réutiliser (elles sont libres, contrairement à celles de Mixamo, c'est la Carnegie Mellon University qui avait fait les captures il y aune vingtaine d'années). Il y a de tout, des activités diverses, des déplacements, du mime, de la danse, des acrobaties. Même des acrobaties ratées ou du ménage (oui il y a du balayage, plusieurs versions
). De quoi s'amuser pour nos émotes je pense. Mais ce n'est que le début, il va falloir les appliquer à notre mannequin pour voir un peu mieux ce que ça donne et ensuite il faudra reprendre toutes celles qui nous intéressent pour qu'elles fonctionnent en jeu correctement.
Je proposerai peut-être un atelier Mécékoidon cette animation au prochain AFK
aleajactaest
De mon côté toujours sur la partie serveur, j'ai un peu avancé sur protobuf (mise en place un peu de partout dans le code
Lyne
Je crois que je vais de ce pas mettre un rappel sur le marronnier pour qu'on fixe la date de l'AG
https://khaganat.net/forum/index.php?topic=809.msg3314#new
Si j'en crois : https://framadate.org/tkdn1aK44aDsfqZ3, on partirait pour l'instant sur le 17 mai, ou un week-end de juin
Personnellement, le 17 mai m'irait bien : comme ça, c'est fait
Mais il y a des membres qui n'ont pas voté (on a 6 votes pour 10 membres. Non, je ne dénoncerai pas ici)
https://carnets.numenaute.org/p/Khaganat_AG_2025
Et y'a un appel à volontaires aussi : qui veut être au Collège l'an prochain ?
YannK
De mon côté, cette semaine, j'ai réparé des détails dans le prototype, cassés avec le passage à Godot 4.4, rien de grave. J'ai aussi avancé sur le système de compétences, mais il va falloir que je mette par écrit un peu l'archi pour aller plus loin je pense. Même moi je vais finir par m'y perdre


J'ai aussi trouvé un moyen pour importer environ 2600 motion captures dans Blender. J'ai des tas d'animations brutes à réutiliser (elles sont libres, contrairement à celles de Mixamo, c'est la Carnegie Mellon University qui avait fait les captures il y aune vingtaine d'années). Il y a de tout, des activités diverses, des déplacements, du mime, de la danse, des acrobaties. Même des acrobaties ratées ou du ménage (oui il y a du balayage, plusieurs versions

Je proposerai peut-être un atelier Mécékoidon cette animation au prochain AFK

aleajactaest
De mon côté toujours sur la partie serveur, j'ai un peu avancé sur protobuf (mise en place un peu de partout dans le code

Dernier message par Lyne - 20 Mars 2025 à 22:31:02
Cliquez pour afficher le message
Après deux mois de vote, c'est la date du 17 mai 2025 qui semble se dessiner. (Oui, techniquement, le 14 et le 21 juin ont le même nombre de votes, mais j'ai envie d'avancer. Donc : 17 mai. Na.)
Si vous n'avez pas voté, et surtout si cette date ne vous convient pas, vous avez jusqu'au point hebdo de la semaine prochaine, à savoir le 27 mars, pour vous exprimer (sur la date. Sur le contenu, vous avez jusqu'au 17 mai).
Pour la suite, il reste à mettre le pad en forme : https://carnets.numenaute.org/p/Khaganat_AG_2025
Vous pouvez y rajouter vos questions, envies, propositions, etc.
Et postuler au Collège si ça vous intéresse.
Si vous n'avez pas voté, et surtout si cette date ne vous convient pas, vous avez jusqu'au point hebdo de la semaine prochaine, à savoir le 27 mars, pour vous exprimer (sur la date. Sur le contenu, vous avez jusqu'au 17 mai).
Pour la suite, il reste à mettre le pad en forme : https://carnets.numenaute.org/p/Khaganat_AG_2025
Vous pouvez y rajouter vos questions, envies, propositions, etc.
Et postuler au Collège si ça vous intéresse.
Dernier message par YannK - 14 Mars 2025 à 12:20:08
Cliquez pour afficher le message
Citation de: YannK le 14 Mars 2025 à 10:52:07- avez-vous des idées de niveau d'avantage/coût/budget pour des niveaux de brique ? Il n'y a aucun urgence sur ce point, mais cela fera partie des nécessités d'équilibrage du gameplay.
Pour vous donner une idée, pour mon test, j'ai prévu de faire payer la baisse du cooldown 2 points, la hauteur améliorée 2 points aussi et le niveau de Saut 1 donne une brique qui permet d'avoir -3 sur son total (en échange de dépense d'endurance, à déterminer). Ce qui veut dire qu'à ce niveau, pas possible d'avoir la hauteur améliorée ET le cooldown amélioré, il faut choisir...
Dernier message par YannK - 14 Mars 2025 à 10:52:07
Cliquez pour afficher le message
Salut à toutes,
je commence à regarder comment implémenter un premier jet de compétences pour le prototype et je m'inspire de celui de Ryzom comme prévu.
Je bosse sur le saut comme sujet de test. L'idée est donc de fabriquer une compétence de «Saut». Celle-ci aura un niveau, en fonction duquel on aura accès à des briques constitutives de plus en plus efficaces (il faudra «acheter» ces briques, hein, comme dans Ryzom, mais ce n'est pas la question là).
Le but est d'ensuite équilibrer les briques qui donnent la capacité (hauteur et cooldown dans notre cas) avec un budget déterminé d'un trait possédé par l'utilisatrice. Ce pourrait être l'endurance dans notre cas (ce qui veut dire qu'on aurait une gestion de ce trait pour les créatures).
Je résume donc, pour le saut on pourrait avoir comme briques qui apportent un effet de compétence :
Et l'avantage octroyé par ces deux briques serait déterminé par un budget défini par une autre brique :
Dans Ryzom, l'assemblage est toujours assez délicat et l'équilibrage demande toujours des arbitrages, ce que je trouve assez sympa pour la joueuse.
Donc mes questions :
- êtes vous ok pour que je parte sur cette base ?
- avez-vous des idées de niveau d'avantage/coût/budget pour des niveaux de brique ? Il n'y a aucun urgence sur ce point, mais cela fera partie des nécessités d'équilibrage du gameplay.
je commence à regarder comment implémenter un premier jet de compétences pour le prototype et je m'inspire de celui de Ryzom comme prévu.
Je bosse sur le saut comme sujet de test. L'idée est donc de fabriquer une compétence de «Saut». Celle-ci aura un niveau, en fonction duquel on aura accès à des briques constitutives de plus en plus efficaces (il faudra «acheter» ces briques, hein, comme dans Ryzom, mais ce n'est pas la question là).
Le but est d'ensuite équilibrer les briques qui donnent la capacité (hauteur et cooldown dans notre cas) avec un budget déterminé d'un trait possédé par l'utilisatrice. Ce pourrait être l'endurance dans notre cas (ce qui veut dire qu'on aurait une gestion de ce trait pour les créatures).
Je résume donc, pour le saut on pourrait avoir comme briques qui apportent un effet de compétence :
- la hauteur qu'on peut sauter
- le cooldown après un saut
Et l'avantage octroyé par ces deux briques serait déterminé par un budget défini par une autre brique :
- l'endurance consommée par le saut
Dans Ryzom, l'assemblage est toujours assez délicat et l'équilibrage demande toujours des arbitrages, ce que je trouve assez sympa pour la joueuse.
Donc mes questions :
- êtes vous ok pour que je parte sur cette base ?
- avez-vous des idées de niveau d'avantage/coût/budget pour des niveaux de brique ? Il n'y a aucun urgence sur ce point, mais cela fera partie des nécessités d'équilibrage du gameplay.
Dernier message par Lyne - 13 Mars 2025 à 22:08:01
Cliquez pour afficher le message
Compte-rendu du point hebdo du 13/03/2025
YannK
J'ai continué le prototypage : https://kloud.khaganat.net/s/PFnGT34EQjN9NCz
J'ai un système basique d'inventaire qui permet de passer les objets d'un contenant à l'autre et les menus d'interaction peuvent dynamiquement changer
Prochaine étape : les compétences. En fait j'en ai besoin pour l'artisanat et un peu tout, donc autant commencer à poser des trucs. je pense que je vais implémenter le saut avec une brique, justement
Et je me suis dit que comme premier véhicule j'essaierai peut-être le hamac, qu'on pourrait faire osciller quand on est allongé dessus
K'Deed
J'ai mis la CI en route pour avoir des clients à tester à chaque jeudi :p
J'ai mis à jour les nextclouds
Je test toujours mes scripts dans le client de YannK
aleajactaest
De mon côté, toujours sur le serveur la migration vers protobuf (pour les messages interne du serveur), bref j'avance doucement mais j'avance.
Et le chef a commencé à cagetter des plans de chef
YannK a commencé à étudier la narration procédurale et se disait qu'il aimerait bien un Game Narrative Service
L'idée serait de rendre possible l'observation des actions des joueurs pour engendrer procéduralement des actions de PNJs, des rumeurs et des histoires voire des quêtes émergentes
Je commence à voir des pistes à étudier pour voir comment le faire
J'ai lu ce bouquin : https://www.routledge.com/Procedural-Storytelling-in-Game-Design/Short-Adams/p/book/9781138595309
Il y a plein de choses intéressantes dedans et en croisant avec quelques autres articles, je commence à envisager un système à tenter
Enormément de boulot, mais en gros l'idée est d'extraire du contenu objectif d'interaction gameplay pour en faire une data qui peut ensuite muter en passant d'un acteur à l'autre
Ça rejoint l'idée qu'on avait eue qu'un personnage puisse apprendre des compétences en voyant d'autres ra les utiliser. On est au niveau technique un peu dans la même logique finalement
Le contenu objectif est de toute façon logué par certains services pour des besoins techniques (Un Global Positioning Management Service pour gérer les collisions et le pathfinding par exemple), donc on peut tout à fait passer ça à un autre service qui bâtira dessus
Mais dans un des articles, ils expliquaient qu'en analysant la présence de joueurs à un endroit précis et qu'ils en revenaient avec des minerais, ça permet au système de comprendre que c'est leur mine -> des PNJs peuvent être spawn pour venir leur acheter leur marchandise, ou un fonctionnaire vérifier s'ils ont leur permis dûment tamponné par le kagnivo
Et là-dessus, vu que ce sont des signaux qu'on formate nous, on a une grammaire bien définie, qui peut donc ensuite être interprétée et transformée par d'autres agents, d'autres méthodes...
YannK
J'ai continué le prototypage : https://kloud.khaganat.net/s/PFnGT34EQjN9NCz
J'ai un système basique d'inventaire qui permet de passer les objets d'un contenant à l'autre et les menus d'interaction peuvent dynamiquement changer
Prochaine étape : les compétences. En fait j'en ai besoin pour l'artisanat et un peu tout, donc autant commencer à poser des trucs. je pense que je vais implémenter le saut avec une brique, justement
Et je me suis dit que comme premier véhicule j'essaierai peut-être le hamac, qu'on pourrait faire osciller quand on est allongé dessus

K'Deed
J'ai mis la CI en route pour avoir des clients à tester à chaque jeudi :p
J'ai mis à jour les nextclouds
Je test toujours mes scripts dans le client de YannK
aleajactaest
De mon côté, toujours sur le serveur la migration vers protobuf (pour les messages interne du serveur), bref j'avance doucement mais j'avance.
--o-§-o--
Et le chef a commencé à cagetter des plans de chef
YannK a commencé à étudier la narration procédurale et se disait qu'il aimerait bien un Game Narrative Service

L'idée serait de rendre possible l'observation des actions des joueurs pour engendrer procéduralement des actions de PNJs, des rumeurs et des histoires voire des quêtes émergentes

Je commence à voir des pistes à étudier pour voir comment le faire

J'ai lu ce bouquin : https://www.routledge.com/Procedural-Storytelling-in-Game-Design/Short-Adams/p/book/9781138595309
Il y a plein de choses intéressantes dedans et en croisant avec quelques autres articles, je commence à envisager un système à tenter
Enormément de boulot, mais en gros l'idée est d'extraire du contenu objectif d'interaction gameplay pour en faire une data qui peut ensuite muter en passant d'un acteur à l'autre
Ça rejoint l'idée qu'on avait eue qu'un personnage puisse apprendre des compétences en voyant d'autres ra les utiliser. On est au niveau technique un peu dans la même logique finalement
Le contenu objectif est de toute façon logué par certains services pour des besoins techniques (Un Global Positioning Management Service pour gérer les collisions et le pathfinding par exemple), donc on peut tout à fait passer ça à un autre service qui bâtira dessus
Mais dans un des articles, ils expliquaient qu'en analysant la présence de joueurs à un endroit précis et qu'ils en revenaient avec des minerais, ça permet au système de comprendre que c'est leur mine -> des PNJs peuvent être spawn pour venir leur acheter leur marchandise, ou un fonctionnaire vérifier s'ils ont leur permis dûment tamponné par le kagnivo
Et là-dessus, vu que ce sont des signaux qu'on formate nous, on a une grammaire bien définie, qui peut donc ensuite être interprétée et transformée par d'autres agents, d'autres méthodes...
Dernier message par Lyne - 06 Mars 2025 à 23:05:32
Cliquez pour afficher le message
Compte-rendu du point hebdo du 06/03/2025
tycho
Et bien j'ai... fait un post sur le forum pour présenter une technologie à considérer pour le serveur (et par répercution sur le client) \o/
https://khaganat.net/forum/index.php/topic,811.msg3325.html#msg3325
Lyne
J'ai causé de Natca avec Zat, et mis les logs sur le forum pour continuer la discussion avec celles que ça intéresse
YannK
J'ai peu avancé, juste passé le code à Godot 4.4
Et tout marche sans souci
J'ai testé le plugin Git pour Godot, qui est plutôt sympa pour gérer les commits, mais je ne suis pas convaincu pour un usage plus complet.
Il ne permet pas les rebase, par exemple
Donc ça veut dire qu'il faut utiliser un autre client Git à côté au moins pour les push/pull et gestion des remote
Ça n'est pas forcément facile à appréhender, donc j'espérais que ça faciliterait un peu pour les contributrices. Mais je ne le trouve aps assez abouti pour que ça soit vraiment utile
aleajactaest
https://partage.jabberfr.org/OEF58vaokt9KGt3vY6t17Jar/client-serveur.png
De mon côté j'avance sur la migration de mon code en utilisant protobuf (client fait, et la je travail sur la partie serveur - message transitant en interne)
Et ici une petite capture d'écran du client que j'ai fait (uniquement pour tester la communication avec le serveur)
Et une autre capture sur mon outil de test fonctionnel.
https://partage.jabberfr.org/kd2FOwKETZm5OsJUkn1yMp88/qa.png
J'ai fait les deux pour protobuf dans le serveur (Rust) et le client (GDscript)
Alcyone
Moi j'ai rien fait à part lire les discussions mais pas trouvé l'énergie de répondre
K'Deed
J'ai commencé à porter mes scripts sur la base de YannK pour voir si j'y arriverai. Et voir si ça va, ou si c'est à jeter donc
J'ai mis la feature de "thème", même si les thèmes que j'ai fait sont moches mais ça fonctionne
J'ai juste mis une fenêtre "quit" comme sur ryzom
J'ai voulu utiliser aujourd'hui le runner de forgejo mais j'ai dû le deban et là j'ai encore une erreur pour lancer docker sans doute une permission oublié.
Ah oui, je suis sur le mapping des touches mais j'ai encore pas mal de bug
tycho
Et bien j'ai... fait un post sur le forum pour présenter une technologie à considérer pour le serveur (et par répercution sur le client) \o/
https://khaganat.net/forum/index.php/topic,811.msg3325.html#msg3325
Lyne
J'ai causé de Natca avec Zat, et mis les logs sur le forum pour continuer la discussion avec celles que ça intéresse
YannK
J'ai peu avancé, juste passé le code à Godot 4.4

Et tout marche sans souci
J'ai testé le plugin Git pour Godot, qui est plutôt sympa pour gérer les commits, mais je ne suis pas convaincu pour un usage plus complet.
Il ne permet pas les rebase, par exemple
Donc ça veut dire qu'il faut utiliser un autre client Git à côté au moins pour les push/pull et gestion des remote
Ça n'est pas forcément facile à appréhender, donc j'espérais que ça faciliterait un peu pour les contributrices. Mais je ne le trouve aps assez abouti pour que ça soit vraiment utile
aleajactaest
https://partage.jabberfr.org/OEF58vaokt9KGt3vY6t17Jar/client-serveur.png
De mon côté j'avance sur la migration de mon code en utilisant protobuf (client fait, et la je travail sur la partie serveur - message transitant en interne)
Et ici une petite capture d'écran du client que j'ai fait (uniquement pour tester la communication avec le serveur)
Et une autre capture sur mon outil de test fonctionnel.
https://partage.jabberfr.org/kd2FOwKETZm5OsJUkn1yMp88/qa.png
J'ai fait les deux pour protobuf dans le serveur (Rust) et le client (GDscript)
Alcyone
Moi j'ai rien fait à part lire les discussions mais pas trouvé l'énergie de répondre
K'Deed
J'ai commencé à porter mes scripts sur la base de YannK pour voir si j'y arriverai. Et voir si ça va, ou si c'est à jeter donc
J'ai mis la feature de "thème", même si les thèmes que j'ai fait sont moches mais ça fonctionne
J'ai juste mis une fenêtre "quit" comme sur ryzom
J'ai voulu utiliser aujourd'hui le runner de forgejo mais j'ai dû le deban et là j'ai encore une erreur pour lancer docker sans doute une permission oublié.
Ah oui, je suis sur le mapping des touches mais j'ai encore pas mal de bug
#10
Programmation / SpacetimeDB
Cliquez pour afficher le message
Bonjour,
Comme vous le savez, faire un MMORPG capable de supporter du monde est difficile, très difficile. Récemment je suis sur un projet qui pourrait simplifier l'affaire et qui, malgré ses défauts, vaut sans doute le coup qu'on le regarde d'un peu plus prêt : SpacetimeDB.
Il s'agit d'une projet un peu spécial qui se présente comme une base de données sur-boostée spécialisée dans les MMORPG et autres applications multi-utilisatrices à haute performance, mais qu'à titre personnel je vois plus comme un serveur générique paramétrable qui intègre une base de données. Le principe est assez simple : on écrit des sortes d'extensions pour SpacetimeDB et ça en fait un serveur de jeu complet avec d'excellentes performances et qui est fait pour « scaller » de manière très simple. Il est prévu de pouvoir écrire ces extensions dans plusieurs langages, dont Python, mais à l'heure actuelle seul Rust est supporté pour le serveur.
Bien entendu, afin de communiquer avec le serveur il faut que le client soit compatible. Il y a des des bibliothèques disponibles dans différents langages. À l'heure actuelle, seuls Rust, C# et Typescript sont supportés, mais il est prévu d'ajouter Python, C++ et Lua.
Enfin, il y a un soucis avec la licence. Dans la mesure où la société derrière SpacetimeDB commercialise une offre d'hébergement en infonuagique, elle n'a pas super envie que d'autres entreprises utilisent la liberté du logiciel pour leur faire directement concurrence. De base, SpacetimeDB est donc sous une licence privatrice qui ressemble cependant à une licence libre mais ajoute 2 restrictions : la possibilité de n'avoir qu'une seule instance en production et l'interdiction de s'en servir pour faire une offre en infonuagique. Il est important de noter que la licence change automatiquement 4 ans après la release afin de devenir l'AGPL.
À titre personnel je ne suis pas fan des licences privatrices, mais je peux comprendre le mouvement ici car sur d'autres logiciels libre il y a eu des abus qui ont fait que la société fournissant tout le travail perdait des parts de marchés face à des concurrents peu scrupuleux qui revendaient leur solution moins cher et sans les financer ni contribuer en retour. Ici je trouve que la bascule automatique vers l'AGPL est très appréciable.
Pour en apprendre plus, voici un certain nombre de ressources en anglais :
Comme vous le savez, faire un MMORPG capable de supporter du monde est difficile, très difficile. Récemment je suis sur un projet qui pourrait simplifier l'affaire et qui, malgré ses défauts, vaut sans doute le coup qu'on le regarde d'un peu plus prêt : SpacetimeDB.
Il s'agit d'une projet un peu spécial qui se présente comme une base de données sur-boostée spécialisée dans les MMORPG et autres applications multi-utilisatrices à haute performance, mais qu'à titre personnel je vois plus comme un serveur générique paramétrable qui intègre une base de données. Le principe est assez simple : on écrit des sortes d'extensions pour SpacetimeDB et ça en fait un serveur de jeu complet avec d'excellentes performances et qui est fait pour « scaller » de manière très simple. Il est prévu de pouvoir écrire ces extensions dans plusieurs langages, dont Python, mais à l'heure actuelle seul Rust est supporté pour le serveur.
Bien entendu, afin de communiquer avec le serveur il faut que le client soit compatible. Il y a des des bibliothèques disponibles dans différents langages. À l'heure actuelle, seuls Rust, C# et Typescript sont supportés, mais il est prévu d'ajouter Python, C++ et Lua.
Enfin, il y a un soucis avec la licence. Dans la mesure où la société derrière SpacetimeDB commercialise une offre d'hébergement en infonuagique, elle n'a pas super envie que d'autres entreprises utilisent la liberté du logiciel pour leur faire directement concurrence. De base, SpacetimeDB est donc sous une licence privatrice qui ressemble cependant à une licence libre mais ajoute 2 restrictions : la possibilité de n'avoir qu'une seule instance en production et l'interdiction de s'en servir pour faire une offre en infonuagique. Il est important de noter que la licence change automatiquement 4 ans après la release afin de devenir l'AGPL.
À titre personnel je ne suis pas fan des licences privatrices, mais je peux comprendre le mouvement ici car sur d'autres logiciels libre il y a eu des abus qui ont fait que la société fournissant tout le travail perdait des parts de marchés face à des concurrents peu scrupuleux qui revendaient leur solution moins cher et sans les financer ni contribuer en retour. Ici je trouve que la bascule automatique vers l'AGPL est très appréciable.
Pour en apprendre plus, voici un certain nombre de ressources en anglais :