Derniers messages
Dernier message par aleajactaest - 05 Juillet 2023 à 22:20:45
Cliquez pour afficher le message
Je vous soumets ma vision sur l'architecture.
Bon évidemment il s'agit d'une réflexion sur le sujet, tout remarque/analyse est bonne.
[Merci de détailler pourquoi]
Je me focalise sur la partie serveur, qui va recevoir les communications et centraliser les actions.
Lexique :
Client : programme lancé sur les postes permettant d'interagir dans l'univers (avec plus ou moins des fonctionnalité suivantes : déplacement, communication instantané, 3D, ...)
Serveur : il s'agit d'une (ou plusieurs machines) utilisé pour contenir des processus (programmes) qui gèrent la communication avec les Clients
Bot : programme qui simule un joueur
Je pars du postulat suivant:
1- Le serveur a toujours raison [idiot comme paradigme, mais il faut choisir entre les clients et le serveur, notez que je dis les clients mais lesquels à raison parmi eux]
2- Minimiser les éléments entre les clients et le serveur (afin de réduire au maximum la latence)
3- Avoir la scalabilité (capacité à continuer de manière normale avec l'augmentation du nombre de personne connecté, bon il faudra voir aussi les limite car suivant les moyen on devra limiter le nombre de machine serveur)
4- Avoir de la redondance (être capable de fonctionner avec la perte d'une partie de l'infrastructure, possibilité de reconnexion rapide, voir le pire bascule complet sur un autre site, bon les délais de bascule varie en fonction du problème)
5- Avoir le moins d'interaction avec la base de donnée [évite des écriture intempestive, relation trop complexe dans la base, éviter les traitements post-séance]
6- Avoir un système d'équité sur l'utilisation de la bande passante réseau (ne pas avoir que le joueur 1 qui répond et agit sans de retour du joueur 2, bref des mécanismes permettant de réguler l'activité de façon équitable [tant que le temps de réponse reste raisonnable pour tout le monde])
7- Gestion des "Bots", ici on rentre plus dans comment gère t-on cela car cela va arriver.
* avoir une API claire avec une identification qu'il s'agit d'un BOT
* avoir la localisation des sources/données/version utilisé pour démarrer le BOT
* Licence qui me semble doit être identique au notre (voir plus ouvert)
* savoir si le Bot est autoriser à s'exécuter dans l'environnement de Prod ou Dev (utile pour les testeurs et claire pour ceux qui font volontairement des erreurs)
* Comment doit-on gérer les personne qui utilise un Bot comme étant un joueur réel?
* Faut-il mettre des différence entre Joueur/Bot?
- Je dirais que oui: concernant la durée d'utilisation un Bot travail 24h, pour un humain s'est impossible
( caractéristiques différentes ?, temps de réponse différent ?)
Ma première idée de séparer les processus de communication serveur pour chaque fonction.
Certaine comme le déplacement sont tout le temps sollicité, à l'inverse l'inventaire auront une activité plus faible.
En séparant les activités, on permet de se séparer d'un étage d'agrégation/compression, et aussi de pouvoir lancer sur une machine différente les processus gourmands en cpu/mémoire ou réseau.
Le problème est que l'on augmente la surface d'attaque sur le serveur.
Le deuxième problème est que certain joueur n'aurait pas la possibilité de communiquer avec plusieurs serveur (problème de firewall), dans ce cas je propose de mettre un processus d'agrégation pour eux (seule eux sont impacté)
J'avais aussi imaginé pouvoir faire une communication en multicast, avantage pour le déplacement des joueurs, pas besoin de renvoyer la même information plusieurs fois. Idée difficile à mettre en place si la partie réseau [que l'on ne maîtrise pas] n'ouvre pas ce type de flux.
Processus:
1- Authentification
2- Gestion de la position
3- Gestion de l'inventaire
4- Gestion des quêtes
5- Gestion des actions en cours [ici on pensera à écrire dans la Base de Donnée l'heure de début, facile ensuite à savoir si l'action est fini en comparant avec l'heure actuelle]
6- Gestion des discussions
7- Éléments présents (décors, object amovible, ...]
8- Caractéristique/Compétence/Faculté/...
9- Identification des noms des personnage (propre à chaque joueur)
X- certaine une fonctionnalité que j'ai oublié
La gestion des positions devrait se faire en plusieurs étapes, avec plusieurs cercles autour du joueur pour connaitre les mouvements des autres.
A savoir que l'on a besoin de savoir si notre voisin le plus proche s'est déplacé d'un mètre, par contre celui qui est à 1km, pas besoin d'avoir l'information à chaque pas (que l'on ne verra pas à l'écran car imperceptible)
Bref, il me semble qu'il faudra un processus pour géré un nombre limité de joueur, et des processus réceptionnant ces info pour gérer les masses de joueurs (et échanger entre eux ces mouvements)
Pour la base de donnée, une simple base de donnée clef/valeur me semble plus "simple" à gérer.
Autre point, certainement information ont une durée de vie très courtes (comme la position), privilégié la mémoire, et d'autre très long (comment l'inventaire), ici on pourrait par exemple se reposer sur un fichier.
Le processus d'authentification aura pour fonction de démarrer/attribuer les processus utilisable pour le client (avec un identifiant/clef pour chaque processus)
La redondance des processus, un primaire et un secondaire (le primaire donnant les info au secondaire), en cas de crash du premier, le secondaire devient primaire et un processus de supervision relance un autre processus (afin d'avoir un deuxième processus actif)
La réplication sur un autre site demandera plus un processus intermédiaire pour copier les info avec durée moyen/longue sur le site distant (aucun intérêt pour les données à durée courte)
@+
AleaJactaEst
PS.:
Fichier PlantUML pour ceux qu'ils veulent reprendre et améliorer.
arch-eclate.txt
Bon évidemment il s'agit d'une réflexion sur le sujet, tout remarque/analyse est bonne.
[Merci de détailler pourquoi]
Je me focalise sur la partie serveur, qui va recevoir les communications et centraliser les actions.
Lexique :
Client : programme lancé sur les postes permettant d'interagir dans l'univers (avec plus ou moins des fonctionnalité suivantes : déplacement, communication instantané, 3D, ...)
Serveur : il s'agit d'une (ou plusieurs machines) utilisé pour contenir des processus (programmes) qui gèrent la communication avec les Clients
Bot : programme qui simule un joueur
Je pars du postulat suivant:
1- Le serveur a toujours raison [idiot comme paradigme, mais il faut choisir entre les clients et le serveur, notez que je dis les clients mais lesquels à raison parmi eux]
2- Minimiser les éléments entre les clients et le serveur (afin de réduire au maximum la latence)
3- Avoir la scalabilité (capacité à continuer de manière normale avec l'augmentation du nombre de personne connecté, bon il faudra voir aussi les limite car suivant les moyen on devra limiter le nombre de machine serveur)
4- Avoir de la redondance (être capable de fonctionner avec la perte d'une partie de l'infrastructure, possibilité de reconnexion rapide, voir le pire bascule complet sur un autre site, bon les délais de bascule varie en fonction du problème)
5- Avoir le moins d'interaction avec la base de donnée [évite des écriture intempestive, relation trop complexe dans la base, éviter les traitements post-séance]
6- Avoir un système d'équité sur l'utilisation de la bande passante réseau (ne pas avoir que le joueur 1 qui répond et agit sans de retour du joueur 2, bref des mécanismes permettant de réguler l'activité de façon équitable [tant que le temps de réponse reste raisonnable pour tout le monde])
7- Gestion des "Bots", ici on rentre plus dans comment gère t-on cela car cela va arriver.
* avoir une API claire avec une identification qu'il s'agit d'un BOT
* avoir la localisation des sources/données/version utilisé pour démarrer le BOT
* Licence qui me semble doit être identique au notre (voir plus ouvert)
* savoir si le Bot est autoriser à s'exécuter dans l'environnement de Prod ou Dev (utile pour les testeurs et claire pour ceux qui font volontairement des erreurs)
* Comment doit-on gérer les personne qui utilise un Bot comme étant un joueur réel?
* Faut-il mettre des différence entre Joueur/Bot?
- Je dirais que oui: concernant la durée d'utilisation un Bot travail 24h, pour un humain s'est impossible
( caractéristiques différentes ?, temps de réponse différent ?)
Ma première idée de séparer les processus de communication serveur pour chaque fonction.
Certaine comme le déplacement sont tout le temps sollicité, à l'inverse l'inventaire auront une activité plus faible.
En séparant les activités, on permet de se séparer d'un étage d'agrégation/compression, et aussi de pouvoir lancer sur une machine différente les processus gourmands en cpu/mémoire ou réseau.
Le problème est que l'on augmente la surface d'attaque sur le serveur.
Le deuxième problème est que certain joueur n'aurait pas la possibilité de communiquer avec plusieurs serveur (problème de firewall), dans ce cas je propose de mettre un processus d'agrégation pour eux (seule eux sont impacté)
J'avais aussi imaginé pouvoir faire une communication en multicast, avantage pour le déplacement des joueurs, pas besoin de renvoyer la même information plusieurs fois. Idée difficile à mettre en place si la partie réseau [que l'on ne maîtrise pas] n'ouvre pas ce type de flux.
Processus:
1- Authentification
2- Gestion de la position
3- Gestion de l'inventaire
4- Gestion des quêtes
5- Gestion des actions en cours [ici on pensera à écrire dans la Base de Donnée l'heure de début, facile ensuite à savoir si l'action est fini en comparant avec l'heure actuelle]
6- Gestion des discussions
7- Éléments présents (décors, object amovible, ...]
8- Caractéristique/Compétence/Faculté/...
9- Identification des noms des personnage (propre à chaque joueur)
X- certaine une fonctionnalité que j'ai oublié
La gestion des positions devrait se faire en plusieurs étapes, avec plusieurs cercles autour du joueur pour connaitre les mouvements des autres.
A savoir que l'on a besoin de savoir si notre voisin le plus proche s'est déplacé d'un mètre, par contre celui qui est à 1km, pas besoin d'avoir l'information à chaque pas (que l'on ne verra pas à l'écran car imperceptible)
Bref, il me semble qu'il faudra un processus pour géré un nombre limité de joueur, et des processus réceptionnant ces info pour gérer les masses de joueurs (et échanger entre eux ces mouvements)
Pour la base de donnée, une simple base de donnée clef/valeur me semble plus "simple" à gérer.
Autre point, certainement information ont une durée de vie très courtes (comme la position), privilégié la mémoire, et d'autre très long (comment l'inventaire), ici on pourrait par exemple se reposer sur un fichier.
Le processus d'authentification aura pour fonction de démarrer/attribuer les processus utilisable pour le client (avec un identifiant/clef pour chaque processus)
La redondance des processus, un primaire et un secondaire (le primaire donnant les info au secondaire), en cas de crash du premier, le secondaire devient primaire et un processus de supervision relance un autre processus (afin d'avoir un deuxième processus actif)
La réplication sur un autre site demandera plus un processus intermédiaire pour copier les info avec durée moyen/longue sur le site distant (aucun intérêt pour les données à durée courte)
@+
AleaJactaEst
PS.:
Fichier PlantUML pour ceux qu'ils veulent reprendre et améliorer.
arch-eclate.txt
Dernier message par YannK - 29 Juin 2023 à 22:07:04
Cliquez pour afficher le message
Bonjour à toutes, je propose qu'on se serve de ce fil pour organiser le travail en asynchrone pour le client Khanat développé sous Godot.
Le lien vers le document de Game Design (non achevé) : https://khaganat.net/wikhan/fr:gamedesign:khanat:start
Quelques liens vers des sujets toujours valides en 2023 (a priori).
Programmation :
Gameplay
Pipelines
Graphisme
Le lien vers le document de Game Design (non achevé) : https://khaganat.net/wikhan/fr:gamedesign:khanat:start
Quelques liens vers des sujets toujours valides en 2023 (a priori).
Programmation :
Organisation des dépôts au sein du groupe MMORPG Khanat-> sujet clos car changement de forge depuis Gitlab -> Forgejo- Architecture des services
Exécutables et partages structurels-> fusionné avec le sujet précédent- Godot et réseau
Gameplay
- Khompétences, Khapacités et KhasesSignifier le HRP
- Plateforme ou non
- Intégrer le vol en jeu ?
- XMPP en jeu et au-delà ?
- (télé)(konta?)pathie, silence et rêve dans la communication ra
Pipelines
Graphisme
Dernier message par Zatalyz - 19 Mai 2023 à 21:11:30
Cliquez pour afficher le message
Vas-y !
Dernier message par YannK - 19 Mai 2023 à 08:31:07
Cliquez pour afficher le message
Pour l'instant, nous avons sur le Gitlab un sous-groupe de Khaganat qui est dédié à tout ce qui a trait au jeu à venir : MMORPG Khanat.
Je pense qu'il serait bon qu'on y crée encore un sous-groupe, tu type « Godot Khanat » où nous mettrions tous les projets qui généreront les exécutables tels que proposés dans Exécutables et partages structurels. Cela permettra d'avoir des paramètres de groupe pour les CI, des accès globaux pour les développeuses etc.
Je propose de le mettre en place avec un dépôt pour tester les fonctionnalités de base nécessaires dans la CI pour la gestion des changelog tel que je l'ai envisagé sur le dépôt Bareto. Cela fera partie des fonctionnalités de base pour nos dépôts. Une fois cela fait, j'effacerai mes tests et je mettrai en place le premier dépôt, pour le client 3D, faisant encore une fois référence au schéma proposé. Si c'est possible pour notre Gitlab, je créerai un template de dépôt. Dans le cas contraire, je ferai un dépôt exemple pour se simplifier la tâche à l'avenir. On verra également avec les développeuses si nous commençons le dépôt « Khanat Core » dès maintenant ou pas.
Je verrai aussi comment avoir une gestion pratique des tickets et une fois tout cela testé et validé, je compléterai le guide de développement pour indiquer la marche à suivre pour contribuer.
Je pense qu'il serait bon qu'on y crée encore un sous-groupe, tu type « Godot Khanat » où nous mettrions tous les projets qui généreront les exécutables tels que proposés dans Exécutables et partages structurels. Cela permettra d'avoir des paramètres de groupe pour les CI, des accès globaux pour les développeuses etc.
Je propose de le mettre en place avec un dépôt pour tester les fonctionnalités de base nécessaires dans la CI pour la gestion des changelog tel que je l'ai envisagé sur le dépôt Bareto. Cela fera partie des fonctionnalités de base pour nos dépôts. Une fois cela fait, j'effacerai mes tests et je mettrai en place le premier dépôt, pour le client 3D, faisant encore une fois référence au schéma proposé. Si c'est possible pour notre Gitlab, je créerai un template de dépôt. Dans le cas contraire, je ferai un dépôt exemple pour se simplifier la tâche à l'avenir. On verra également avec les développeuses si nous commençons le dépôt « Khanat Core » dès maintenant ou pas.
Je verrai aussi comment avoir une gestion pratique des tickets et une fois tout cela testé et validé, je compléterai le guide de développement pour indiquer la marche à suivre pour contribuer.
Sans veto dans la semaine qui vient, je m'attaquerai à ces tâches.
Dernier message par Zatalyz - 06 Mars 2023 à 10:08:54
Cliquez pour afficher le message
Ce qui a été remonté (je note ici pour ne pas oublier, en principe faut en faire des tickets mais... ben... quand je m'y mettrais !) :
- Édition des messages :
- Ajouter un bouton pour inclure une vidéo (mais pas forcément youtube) ? Demande probablement de coder un mod.
- L'icone pour "spoiler" n'apparait pas. Elle existe, pourtant... voir comment ça se fait appeler, je sens que ça va être agaçant.
- "Images, Fichiers joints et autres options" => discuter de la configuration (quels extensions, quelle taille max, quel rangement, etc). Lié à des risques de sécurités, mais à tout prendre je préfère limiter les appels aux sites externes.
- Changer "Soumettre" en "Publier"
- "Icône du message" en anglais ici mais en français sur le forum de test, voir ce qui est différent... Accessoirement prévisualiser l'image dans la liste serait bien, quitte à garder ce truc.
- Changement de thème : j'ai hacké un peu salement un truc déjà sale, va falloir bosser dessus. Dans les trucs déjà repéré :
- Le rendre accessible
- Le nom du thème "khbb", c'est pas très parlant (=> ajouter des descriptions aux thèmes ?)
- Bug : il ne change que si on l'active depuis la page d'accueil.
- Position (chez Lyne) : "Et sur mon écran fenêtré (à la c**, je sais), la flèche de la liste déroulante des thèmes se retrouve sur l'ascenseur de la fenêtre. Donc si je veux voir la liste des thèmes... je descends dans la fenêtre 😅"
Je me demande d'ailleurs si ça ne serait pas mieux que je fasse un bouton "changer de thème" qui emmène sur une page à part, où on pourrait voir la liste des thèmes, une description et une vignette. Ce qui me demande de reprendre vraiment le mod mais, de toute façon, il n'est pas top...
- Édition des messages :
- Ajouter un bouton pour inclure une vidéo (mais pas forcément youtube) ? Demande probablement de coder un mod.
- L'icone pour "spoiler" n'apparait pas. Elle existe, pourtant... voir comment ça se fait appeler, je sens que ça va être agaçant.
- "Images, Fichiers joints et autres options" => discuter de la configuration (quels extensions, quelle taille max, quel rangement, etc). Lié à des risques de sécurités, mais à tout prendre je préfère limiter les appels aux sites externes.
- Changer "Soumettre" en "Publier"
- "Icône du message" en anglais ici mais en français sur le forum de test, voir ce qui est différent... Accessoirement prévisualiser l'image dans la liste serait bien, quitte à garder ce truc.
- Changement de thème : j'ai hacké un peu salement un truc déjà sale, va falloir bosser dessus. Dans les trucs déjà repéré :
- Le rendre accessible
- Le nom du thème "khbb", c'est pas très parlant (=> ajouter des descriptions aux thèmes ?)
- Bug : il ne change que si on l'active depuis la page d'accueil.
- Position (chez Lyne) : "Et sur mon écran fenêtré (à la c**, je sais), la flèche de la liste déroulante des thèmes se retrouve sur l'ascenseur de la fenêtre. Donc si je veux voir la liste des thèmes... je descends dans la fenêtre 😅"
Je me demande d'ailleurs si ça ne serait pas mieux que je fasse un bouton "changer de thème" qui emmène sur une page à part, où on pourrait voir la liste des thèmes, une description et une vignette. Ce qui me demande de reprendre vraiment le mod mais, de toute façon, il n'est pas top...
Dernier message par Zatalyz - 02 Mars 2023 à 10:56:52
Cliquez pour afficher le message
La mise en prod va être utile pour voir tout ce qui ne va pas (et j'en vois, des choses...).
Quoi qu'il arrive, faut que je note cela quelque part. Lors de l'installation du thème, il y a des trucs à faire pour que ça marche :
- aller dans configuration > fonctionnalités et options > choisir la source locale pour Jquery et empêcher la minification du css.
- Configuration > Thèmes et dispositions > réglage des thèmes > modifier khbb. Et là, indiquer les bons chemins (url, etc). C'est assez nul que ça ne soit pas bien configuré par défaut.
Quoi qu'il arrive, faut que je note cela quelque part. Lors de l'installation du thème, il y a des trucs à faire pour que ça marche :
- aller dans configuration > fonctionnalités et options > choisir la source locale pour Jquery et empêcher la minification du css.
- Configuration > Thèmes et dispositions > réglage des thèmes > modifier khbb. Et là, indiquer les bons chemins (url, etc). C'est assez nul que ça ne soit pas bien configuré par défaut.
Dernier message par Zatalyz - 19 Novembre 2022 à 21:05:55
Cliquez pour afficher le message
Aujourd'hui, je pense avoir passé un gap...
Le nouveau thème me semble relativement mature. Il y a des choses qui ne vont pas mais :
- soit je n'ai pas trouvé l'idée du siècle (comme pour le menu ou le pied de page)
- soit je n'ai pas les compétences (comme pour la liste de sélection des thèmes ou l'abonnement aux forums)
- soit je n'ai pas encore trouvé la foi pour m'y remettre (les icones... ça va pas, vraiment pas).
- soit c'est dans un coin et je ne l'ai pas vu.
Accessoirement, je crois aussi qu'il faut que je me calme sur le perfectionnisme.
Donc, la prochaine étape est de pousser tout ça sur Git. Comme ça d'autres pourront participer. Une fois les icones faites, on le mettra sur le vrai forum, aussi.
Concernant le tour d'horizon :
- Sur bureau, ça marche plutôt bien
- Sur mobile aussi. J'ai testé quelques résolutions intermédiaires, on aura des trucs qui se révèleront à l'usage.
- Côté accessibilité :
- en principe les contrastes sont bons sans tuer les yeux des gens qui sont plus sensibles aux contrastes,
- le forum reste lisible pour les diverses particularités optiques (les couleurs sont secondaires donc même en niveau de gris, ça reste compréhensible)
- la navigation au clavier va "à peu près", j'ai droit à encore 2-3 soucis mais qui demandent que quelqu'un de compétent en JS s'y penche
- Sur la navigation par lecteur d'écran, il va falloir tester ; j'ai fait ce que j'ai pu mais je ne suis pas très confiante. Cependant j'ai une idée, si jamais ça se révèle trop pourri
- la navigation en mode texte (via votre terminal favori) est franchement hyper nulle. Prenez un navigateur graphique
plus sérieusement, pareil, j'ai une idée pour ça mais c'est un autre job
Je précise que tout cela est vrai sur les pages principales. La partie pour s'enregistrer demande encore du travail (plein d'erreurs liées à l'accessibilité, fonctionnelle sinon), et il y a probablement plein de pages derrière les fagots que j'ai oublié. Mais vous pouvez consultez le forum avec ce thème.
Le nouveau thème me semble relativement mature. Il y a des choses qui ne vont pas mais :
- soit je n'ai pas trouvé l'idée du siècle (comme pour le menu ou le pied de page)
- soit je n'ai pas les compétences (comme pour la liste de sélection des thèmes ou l'abonnement aux forums)
- soit je n'ai pas encore trouvé la foi pour m'y remettre (les icones... ça va pas, vraiment pas).
- soit c'est dans un coin et je ne l'ai pas vu.
Accessoirement, je crois aussi qu'il faut que je me calme sur le perfectionnisme.
Donc, la prochaine étape est de pousser tout ça sur Git. Comme ça d'autres pourront participer. Une fois les icones faites, on le mettra sur le vrai forum, aussi.
Concernant le tour d'horizon :
- Sur bureau, ça marche plutôt bien
- Sur mobile aussi. J'ai testé quelques résolutions intermédiaires, on aura des trucs qui se révèleront à l'usage.
- Côté accessibilité :
- en principe les contrastes sont bons sans tuer les yeux des gens qui sont plus sensibles aux contrastes,
- le forum reste lisible pour les diverses particularités optiques (les couleurs sont secondaires donc même en niveau de gris, ça reste compréhensible)
- la navigation au clavier va "à peu près", j'ai droit à encore 2-3 soucis mais qui demandent que quelqu'un de compétent en JS s'y penche
- Sur la navigation par lecteur d'écran, il va falloir tester ; j'ai fait ce que j'ai pu mais je ne suis pas très confiante. Cependant j'ai une idée, si jamais ça se révèle trop pourri
- la navigation en mode texte (via votre terminal favori) est franchement hyper nulle. Prenez un navigateur graphique
plus sérieusement, pareil, j'ai une idée pour ça mais c'est un autre jobJe précise que tout cela est vrai sur les pages principales. La partie pour s'enregistrer demande encore du travail (plein d'erreurs liées à l'accessibilité, fonctionnelle sinon), et il y a probablement plein de pages derrière les fagots que j'ai oublié. Mais vous pouvez consultez le forum avec ce thème.
Dernier message par Zatalyz - 26 Octobre 2022 à 11:37:28
Cliquez pour afficher le message
J'ai un souci avec les items suivants dans le menu :
- "Messages récents", que j'ai renommé "Derniers messages", car ce n'est pas "récent", ça affiche juste les 100 derniers messages. Accessible même sans être connecté.
- "Messages non lus" : On doit être co. Les messages nouveaux sur l'ensemble du forum depuis la dernière fois, qu'on les suive ou non.
- "Sujets mis à jour" : On doit être co, ET avoir initié le sujet. Voilà, c'est les seuls qui seront listés ici : les sujets qu'on a initié soit et qui ont eu une réponse.
- Notifications : On doit être co. De base ça s'appelait "Alertes", je ne suis pas convaincue par mon renommage. Affiche la liste des messages sur les sujets où on est abonné. C'est à dire que s'il y a eu 10 réponses au même message, ça affiche 10 liens.
Un point important : bien différencier le message (la réponse d'une personne) du sujet (l'ensemble du fil).
Autant dire que 1) ce n'est pas clair 2) ce n'est pas très pratique.
Je pense déjà renommer (encore) "Notifications" en "Abonnements" ou "Suivi". Ou si vous avez une meilleure idée ?
Les 100 derniers messages, ok, tant que je n'ai pas mis et paramétré le plugin... ça fait son taf, surtout renommé en "Derniers messages".
Reste les deux derniers autres. Je renomme ? Comment ? Je vire ?
Je pourrait aussi faire un seul lien renvoyant sur une page listant diverses façons de parcourir les "derniers" messages (suivant si on les suit, si on les a initié, etc).
Edit :
ha j'ai trouvé une façon d'afficher tous les sujets non lus (pas juste les siens) ! Mais en fait, le forum considère que tu peux ne pas avoir lu le sujet, mais avoir lu les messages...
Alcyone a proposé
- "Messages récents", que j'ai renommé "Derniers messages", car ce n'est pas "récent", ça affiche juste les 100 derniers messages. Accessible même sans être connecté.
- "Messages non lus" : On doit être co. Les messages nouveaux sur l'ensemble du forum depuis la dernière fois, qu'on les suive ou non.
- "Sujets mis à jour" : On doit être co, ET avoir initié le sujet. Voilà, c'est les seuls qui seront listés ici : les sujets qu'on a initié soit et qui ont eu une réponse.
- Notifications : On doit être co. De base ça s'appelait "Alertes", je ne suis pas convaincue par mon renommage. Affiche la liste des messages sur les sujets où on est abonné. C'est à dire que s'il y a eu 10 réponses au même message, ça affiche 10 liens.
Un point important : bien différencier le message (la réponse d'une personne) du sujet (l'ensemble du fil).
Autant dire que 1) ce n'est pas clair 2) ce n'est pas très pratique.
Je pense déjà renommer (encore) "Notifications" en "Abonnements" ou "Suivi". Ou si vous avez une meilleure idée ?
Les 100 derniers messages, ok, tant que je n'ai pas mis et paramétré le plugin... ça fait son taf, surtout renommé en "Derniers messages".
Reste les deux derniers autres. Je renomme ? Comment ? Je vire ?
Je pourrait aussi faire un seul lien renvoyant sur une page listant diverses façons de parcourir les "derniers" messages (suivant si on les suit, si on les a initié, etc).
Edit :
ha j'ai trouvé une façon d'afficher tous les sujets non lus (pas juste les siens) ! Mais en fait, le forum considère que tu peux ne pas avoir lu le sujet, mais avoir lu les messages...
Alcyone a proposé
CitationNotifications => Suivi, ça me parait bien, court et compréhensible.
Derniers messages => nickel
Sujets mis à jour => Mes sujets, peut-être ? Vu que ça groupe au final tous les sujets du profils connecté ordonnés selon la réponse la plus récente si j'ai bien compris
Dernier message par Zatalyz - 25 Octobre 2022 à 20:22:46
Cliquez pour afficher le message
Merci pour ce retour, YannK ! Testons ça, on verra bien si ça marche.
L'entrée à la contribution est de toute façon haute quand on parle de rigging et d'animation ; l'enjeu sera aussi sur notre capacité à transmettre aux intéressées. Et, comme tu le dis, il n'y a pas tant de monde qui va oser y aller de toute façon... donc, je parie que celles qui tenteront l'expérience auront déjà soit un certain niveau d'expertise, soit cette folie douce qui nous caractérise et qui nous fait nous lancer dans des trucs trops gros
L'entrée à la contribution est de toute façon haute quand on parle de rigging et d'animation ; l'enjeu sera aussi sur notre capacité à transmettre aux intéressées. Et, comme tu le dis, il n'y a pas tant de monde qui va oser y aller de toute façon... donc, je parie que celles qui tenteront l'expérience auront déjà soit un certain niveau d'expertise, soit cette folie douce qui nous caractérise et qui nous fait nous lancer dans des trucs trops gros
Dernier message par YannK - 25 Octobre 2022 à 18:15:24
Cliquez pour afficher le message
Bonjour à toutes,
pour celles qui ont eu la joie de bosser un peu dans les dépôts d'assets de Ryzom, il est certainement apparu qu'il est complexe d'organiser les choses pour que la contribution artistique soit aisée et les manipulations fluides d'un bout à l'autre de la production, depuis la création par l'artiste jusqu'à l'intégration en jeu. La cohérence des versions utilisées pour générer les objets finaux est souvent complexe (voir par exemple les différentes armatures incompatibles entre elles utilisées pour les humanoïdes dans Ryzom). C'est un sujet très épineux pour beaucoup de studios, d'autant que les compétences nécessaires pour appréhender ces questions ne sont pas si fréquentes, surtout pour les animations.
Richard Lico, ce héros
Pour notre plus grand bonheur, un vétéran de l'industrie extrêmement talentueux (Richard Lico, le sus-nommé) a décidé de prendre la question à bras le corps. Il s'agissait pour lui de faciliter la gestion des données d'un bout à l'autre du pipeline, avec le moins de maintenance possible. Et de chercher une façon pour que les animatrices soient les plus libres possible tout en ayant une rapidité de travail décuplée. D'un autre côté, il n'avait pas le choix, il venait de devenir indépendant et se retrouvait tout seul sur de nombreux aspects pour un gros projet
(le jeu Moss pour les curieuses, qui lui a donc valu de nombreuses récompenses.)
Aparté : Si certaines sont intéressées, deux conférences où il parle de son travail sur Moss, justement : Animating Quill: Creating an Emotional Experience (sur lequel il y aurait d'autres choses à dire, mais j'y reviendrai à un autre moment) et Animation Workflow Siggraph 2018
Brad Clark, ce héros (parce que lui aussi le vaut bien)
Sur ce, Brad Clark un gars devenu référence mondiale dans son domaine (le rigging) depuis des années (le genre qui a bossé sur le motion capture de Gollum pour « Le seigneur des anneaux » il y a 20 ans...), et qui a décidé de se plonger dans Blender parce qu'il s'est dit qu'il y avait du potentiel inutilisé (vous avez deviné pourquoi il me plaît tant ?
), s'est dit qu'il faudrait trouver comment pousser ce genre de pratique. Et il fait alors la connaissance de deux frangins, qui se sont dits dans leur coin que ce serait cool d'avoir des outils de ce type dans un addon Blender (Rig On the Fly). Et paf, voilà, ça veut dire que Blender peut le faire et qu'en plus des gens planchent à rendre ça plus aisé.
Aparté : une vidéo revient sur ce processus de rencontres qui s'est fait peu à peu : Meet The Expert: BRAD CLARK (Rigging Dojo)
Tout cela m'a semblé extrêmement intéressant pour nous, qui n'avons pas les moyens de créer et de maintenir un pipeline de production trop lourd, ni de créer plein d'outils pour toutes les contributrices qui pourraient venir de temps en temps.
Ce que je vais dire ci-dessous l'est dans un contexte où ce sont les animations qui sont concernées, mais il faudrait voir comment l'étendre peut-être à d'autres pans de la contribution artistique, à étudier.
Le premier point est de simplifier le plus possible la gestion des ressources. Donc l'idée (du moins pour tout ce qui est résultat d'un workflow destructif, comme l'est l'animation) est de n'avoir qu'un format à gérer, celui qui est nécessaire au moteur (à savoir glTF dans notre cas). Le but d'une contributrice est donc de fournir un fichier glTF qui contient une animation pour l'armature de déformation d'un objet animé. Seule l'armature de déformation, et le skinning du mesh correspondant, ont besoin d'être fournis et versionnés. Vu que le rig de contrôle est ce qui est le plus complexe à faire, et le plus difficile à s'approprier et parfois s'avère limitant pour certaines opérations souhaitées par l'animatrice, on n'a plus à se préoccuper de sa maintenance et de sa cohérence tout au long du pipeline. Ainsi, ajouter un nouvel emplacement dans le dos pour fixer un sac ne pose pas de souci, c'est juste un bone dans l'armature de déformation. Pas besoin de reprendre tout le travail préalable où celui-ci n'est pas inclus et de le propager partout pour maintenir la cohérence du rig de contrôle, cet ajout sera simplement pris en compte lors du prochain import avec les scripts habituels afin d'être pris en charge. Car dans l'approche professée par Richard Lico, le rig de contrôle est généré à la volée par l'animateur via des scripts personnalisés (d'où l'intérêt de l'addon Rig on the Fly qui en fournit un certain nombre prêts à l'emploi), depuis l'armature de déformation, en se basant sur les keyframes déjà en place. Du coup, on a directement la ressource utile et on repart toujours toujours d'elle quand on veut faire des modifications, peu importe comment on fait cette dernière et les modifications qu'elle a pu connaître entretemps, on a forcément toujours la dernière version d'édition entre les mains.
Le seul gros point noir à cette façon d'opérer est que l'animation demande alors quand même pas mal de connaissances théoriques en rigging et en scripting, ou au moins une très grande aisance avec l'outil qu'on utilise. Ce qui veut dire que la marche d'entrée pour contribuer me semble un peu plus haute. Mais son gros avantage est que celles qui contribueront perdront moins d'énergie à maintenir des outils plus ou moins adaptés (voire à les adapter au nouvelles venues) et bien plus à réellement fabriquer du contenu, ce qui est plus motivant. Par ailleurs, on peut plus rapidement obtenir des résultats de très bonne qualité.
J'ai étudié la façon dont on pourrait déployer ça dans notre pipeline Blender > Godot et je pense avoir trouvé comment faire pour que les animations puissent être réalisées une par une pour un même modèle et les importer séparément comme ressource dans Godot. J'ai commencé à noter ça dans le Guide de développement. On testera ça in vivo pour le premier client dès que Godot 4 sera un peu stabilisé.
Si vous avez des avis, des remarques, des questions...
pour celles qui ont eu la joie de bosser un peu dans les dépôts d'assets de Ryzom, il est certainement apparu qu'il est complexe d'organiser les choses pour que la contribution artistique soit aisée et les manipulations fluides d'un bout à l'autre de la production, depuis la création par l'artiste jusqu'à l'intégration en jeu. La cohérence des versions utilisées pour générer les objets finaux est souvent complexe (voir par exemple les différentes armatures incompatibles entre elles utilisées pour les humanoïdes dans Ryzom). C'est un sujet très épineux pour beaucoup de studios, d'autant que les compétences nécessaires pour appréhender ces questions ne sont pas si fréquentes, surtout pour les animations.
Richard Lico, ce héros
Pour notre plus grand bonheur, un vétéran de l'industrie extrêmement talentueux (Richard Lico, le sus-nommé) a décidé de prendre la question à bras le corps. Il s'agissait pour lui de faciliter la gestion des données d'un bout à l'autre du pipeline, avec le moins de maintenance possible. Et de chercher une façon pour que les animatrices soient les plus libres possible tout en ayant une rapidité de travail décuplée. D'un autre côté, il n'avait pas le choix, il venait de devenir indépendant et se retrouvait tout seul sur de nombreux aspects pour un gros projet
(le jeu Moss pour les curieuses, qui lui a donc valu de nombreuses récompenses.)Aparté : Si certaines sont intéressées, deux conférences où il parle de son travail sur Moss, justement : Animating Quill: Creating an Emotional Experience (sur lequel il y aurait d'autres choses à dire, mais j'y reviendrai à un autre moment) et Animation Workflow Siggraph 2018
Brad Clark, ce héros (parce que lui aussi le vaut bien)
Sur ce, Brad Clark un gars devenu référence mondiale dans son domaine (le rigging) depuis des années (le genre qui a bossé sur le motion capture de Gollum pour « Le seigneur des anneaux » il y a 20 ans...), et qui a décidé de se plonger dans Blender parce qu'il s'est dit qu'il y avait du potentiel inutilisé (vous avez deviné pourquoi il me plaît tant ?
), s'est dit qu'il faudrait trouver comment pousser ce genre de pratique. Et il fait alors la connaissance de deux frangins, qui se sont dits dans leur coin que ce serait cool d'avoir des outils de ce type dans un addon Blender (Rig On the Fly). Et paf, voilà, ça veut dire que Blender peut le faire et qu'en plus des gens planchent à rendre ça plus aisé.Aparté : une vidéo revient sur ce processus de rencontres qui s'est fait peu à peu : Meet The Expert: BRAD CLARK (Rigging Dojo)
Tout cela m'a semblé extrêmement intéressant pour nous, qui n'avons pas les moyens de créer et de maintenir un pipeline de production trop lourd, ni de créer plein d'outils pour toutes les contributrices qui pourraient venir de temps en temps.
Ce que je vais dire ci-dessous l'est dans un contexte où ce sont les animations qui sont concernées, mais il faudrait voir comment l'étendre peut-être à d'autres pans de la contribution artistique, à étudier.
Le premier point est de simplifier le plus possible la gestion des ressources. Donc l'idée (du moins pour tout ce qui est résultat d'un workflow destructif, comme l'est l'animation) est de n'avoir qu'un format à gérer, celui qui est nécessaire au moteur (à savoir glTF dans notre cas). Le but d'une contributrice est donc de fournir un fichier glTF qui contient une animation pour l'armature de déformation d'un objet animé. Seule l'armature de déformation, et le skinning du mesh correspondant, ont besoin d'être fournis et versionnés. Vu que le rig de contrôle est ce qui est le plus complexe à faire, et le plus difficile à s'approprier et parfois s'avère limitant pour certaines opérations souhaitées par l'animatrice, on n'a plus à se préoccuper de sa maintenance et de sa cohérence tout au long du pipeline. Ainsi, ajouter un nouvel emplacement dans le dos pour fixer un sac ne pose pas de souci, c'est juste un bone dans l'armature de déformation. Pas besoin de reprendre tout le travail préalable où celui-ci n'est pas inclus et de le propager partout pour maintenir la cohérence du rig de contrôle, cet ajout sera simplement pris en compte lors du prochain import avec les scripts habituels afin d'être pris en charge. Car dans l'approche professée par Richard Lico, le rig de contrôle est généré à la volée par l'animateur via des scripts personnalisés (d'où l'intérêt de l'addon Rig on the Fly qui en fournit un certain nombre prêts à l'emploi), depuis l'armature de déformation, en se basant sur les keyframes déjà en place. Du coup, on a directement la ressource utile et on repart toujours toujours d'elle quand on veut faire des modifications, peu importe comment on fait cette dernière et les modifications qu'elle a pu connaître entretemps, on a forcément toujours la dernière version d'édition entre les mains.
Le seul gros point noir à cette façon d'opérer est que l'animation demande alors quand même pas mal de connaissances théoriques en rigging et en scripting, ou au moins une très grande aisance avec l'outil qu'on utilise. Ce qui veut dire que la marche d'entrée pour contribuer me semble un peu plus haute. Mais son gros avantage est que celles qui contribueront perdront moins d'énergie à maintenir des outils plus ou moins adaptés (voire à les adapter au nouvelles venues) et bien plus à réellement fabriquer du contenu, ce qui est plus motivant. Par ailleurs, on peut plus rapidement obtenir des résultats de très bonne qualité.
J'ai étudié la façon dont on pourrait déployer ça dans notre pipeline Blender > Godot et je pense avoir trouvé comment faire pour que les animations puissent être réalisées une par une pour un même modèle et les importer séparément comme ressource dans Godot. J'ai commencé à noter ça dans le Guide de développement. On testera ça in vivo pour le premier client dès que Godot 4 sera un peu stabilisé.
Si vous avez des avis, des remarques, des questions...
