Pour tout ce qui chiffrable comme les maximum des jauges, les temps des actions, les seuils, etc..., ça devrait venir de fichiers de configuration, dès le départ.

Cela permet de ne pas avoir de valeur en dur, et comme c'est paramétrable dès le début, on ne fera pas d'assertions "à la con" interdisant un équilibrage du bidule.

Faire en sorte que les classes soient les plus génériques et flexibles possibles. Tu nous bombardes de détails qui peuvent/doivent évoluer au cours de la conception du jeu, donc tes classes doivent être le plus indépendant de ces "détails".

>quand ils mangent et décrémente à chaque Frame

Nope, pas de comportement fonction de "Frame", sinon, ils mourront de faim sur une machine rapide et deviendront obèses sur des machines lentes. Utilisez un cadre temporel "fixe", pas fonction de la puissance de la machine.

>A la fin de chaque action il faut tester si ils ont faim / soif / sommeil

Pourquoi "à la fin", vous ne devriez pas tester à un moment "spécial", mais calculer "quand" les seuils seront franchis (toute chose identique par ailleurs)=> file d'évènements.

>si la jauge nourriture est en dessous de 3000 ils commence à avoir faim, et à 0, le personnage meurt

Même pour un prêtre "zombi" ou une liche ? Vous ne devriez pas avoir ce genre de règle en dur dans votre code.

>si le personnage est au travail, il retourne à la maison pour manger / boire / dormir

Le genre de truc à rendre paramétrable via des diagrammes d'états sérialisés dans des fichiers de configuration.

>Alors je compte créer une classe Action et des classes dérivées : Drink, Eat, Sleep, Move, Work.

Assez étrange de faire "d'actions" des objets, généralement, c'est plus implémenté via des méthodes.

Ça peut être des objets dans le cadre de Design Pattern évolués, mais comme vous n'évoquez rien qui y ressemble comme des file d'évènements observables, chaîne de responsabilité, etc ... ; c'est louche.

>Et puis une classe personnage.

Là, ça sent bien la conception objet du millénaire passé.

Ça passera peut-être si votre jeu n'ai pas trop complexe mais les architectures ECS ont montrées leur efficacité en terme de résistance à la charge aussi bien dans les moteurs de jeu que dans les jeux eux-mêmes.

>Après il y aura des personnages spécialisés ( guerrier, prêtre qui mangeront différemment, de la viande et de la bière ) mais dans la première version, je n'implémente pas, juste à garder en tête aussi.

C'est un bon réflexe de regarder "un peu avance" mais c'est mieux d'avoir une vue d'ensemble.

Si votre jeu n'a aucun intérêt si vous n'avez pas de "personnages spécialisés", n'attendez pas la saint glinglin pour implémenter cette fonctionnalité. Vous devez le faire au plus vite, pour avoir une "tranche" du jeu et voir s'il est fun ou pas et pas trop investir de temps inutilement sur un jeu 'pas fun".

=> Je pense qu'il doit exister des outils de RAD pour jeu pour faire des validations de concept en amont.

>Est ce que cela vous parait bien ?

Ça sent une approche un peu trop "naïve", avez-vous fait une revue "bibliographique" pour avoir l'état de l'art sur le sujet ?

>Est ce qu'il y a déjà des architectures de ce type qui existent dont je pourrais m'inspirer ?

Ah, bin non du coup, pas de revue "bibliographique".

>J'ai demandé à chatgpt,

Putain, en temps que boomer, je m'y ferais jamais : demander au champion du monde du pipotage, cornaqué par des kenyans à 2$ de l'heure, des conseils.

Je vous conseille donc de faire une revue "bibliographique" "classique" : jetez un coup d'œil au code source de framework d'aide à la création de jeu, au code source de jeu ou de prototype de jeu eux-mêmes, Il doit en avoir pas mal en Open Source.

Je ne peux pas dire ce qui est bien ou pas en fonction du type de jeu que vous voulez implémenter mais inspirez-vous de codes récents.

-
Edité par bacelar 7 février 2024 à 21:50:25

Pour tout ce qui chiffrable comme les maximum des jauges, les temps des actions, les seuils, etc..., ça devrait venir de fichiers de configuration, dès le départ.

Cela permet de ne pas avoir de valeur en dur, et comme c'est paramétrable dès le début, on ne fera pas d'assertions "à la con" interdisant un équilibrage du bidule.

> Pour l'instant je fais un prototype, j'aurais peut être plus de 50 ressources si je finalise le projet, mais là je teste avec 3 ou 5 ressources, pour valider le concept, c'est amplement suffisant, et donc pas besoin d'optimiser prématurément cette partie pour l'instant je pense ... Je n'en suis pas au stade de l'équilibrage du jeu ...

Faire en sorte que les classes soient les plus génériques et flexibles possibles. Tu nous bombardes de détails qui peuvent/doivent évoluer au cours de la conception du jeu, donc tes classes doivent être le plus indépendant de ces "détails".

> Ben oui ça je sais, c'est justement sur ce point que j'aurais aimé avoir quelques idées ...

Nope, pas de comportement fonction de "Frame", sinon, ils mourront de faim sur une machine rapide et deviendront obèses sur des machines lentes. Utilisez un cadre temporel "fixe", pas fonction de la puissance de la machine.

> Ben ça revient au même, si ils font tout plus vite, marcher plus vite, manger plus vite, travailler plus vite ... ET c'est le principe de la vitesse fois 2 3 5 10 ...

Pourquoi "à la fin", vous ne devriez pas tester à un moment "spécial", mais calculer "quand" les seuils seront franchis (toute chose identique par ailleurs)=> file d'évènements.

> Je vais y réfléchir, mais il y a pas tant d’événement possible que ça faim / soif / sommeil / repos, si je teste et gère une file d’événements ça va revenir au même. Si j'avais 50 événements possibles ok, mais là, pas sûr que ça soit rentable ... ( à tester cependant )

Même pour un prêtre "zombi" ou une liche ? Vous ne devriez pas avoir ce genre de règle en dur dans votre code.

> Oui c'est le principe, si les besoins ne sont pas remplis, le perso meurt ... Pas de squelette qui partent au travail ...

Le genre de truc à rendre paramétrable via des diagrammes d'états sérialisés dans des fichiers de configuration.

> Je n'utilise pas de moteurs, ni de bibliothèques, donc oui probablement diagramme d'états, mais c'est moi qui vais devoir les coder ...

Assez étrange de faire "d'actions" des objets, généralement, c'est plus implémenté via des méthodes.

> Oui mais ça marche aussi très bien et si ça simplifie le code.

Ça peut être des objets dans le cadre de Design Pattern évolués, mais comme vous n'évoquez rien qui y ressemble comme des file d'évènements observables, chaîne de responsabilité, etc ... ; c'est louche.

> Ben oui, vu la complexité, je suis obligé de passer par des Patterns, mais je suis pas un grand spécialiste du domaine ...

>Et puis une classe personnage.

Là, ça sent bien la conception objet du millénaire passé.

Ça passera peut-être si votre jeu n'ai pas trop complexe mais les architectures ECS ont montrées leur efficacité en terme de résistance à la charge aussi bien dans les moteurs de jeu que dans les jeux eux-mêmes.

> Je connais pas trop ECS qui me parait bien pour rajouter des sorts magiques et des équipements à un personnage, mais là je n'en vois pas trop l'utilité ...

Si votre jeu n'a aucun intérêt si vous n'avez pas de "personnages spécialisés", n'attendez pas la saint glinglin pour implémenter cette fonctionnalité. Vous devez le faire au plus vite, pour avoir une "tranche" du jeu et voir s'il est fun ou pas et pas trop investir de temps inutilement sur un jeu 'pas fun".

> Ca sera pas la partie la plus dure à faire je pense 

=> Je pense qu'il doit exister des outils de RAD pour jeu pour faire des validations de concept en amont.

RAD C'est quoi ?

Ça sent une approche un peu trop "naïve", avez-vous fait une revue "bibliographique" pour avoir l'état de l'art sur le sujet ?

J'ai essayé de trouver des codes de city builder en effet, mais tous n'ont pas les même concepts que moi, sim city ne me convient pas, on ne peut pas cliquer sur les personnages qui déambulent et leur associer une profession ... Faut juste que j'en trouve du code, ce qui n'est pas si évident, car les problématique sont rarement exactement les mêmes ...

>Je ne parle pas d'optimisation mais de faire en sorte de rendre l'exploration des possibilités rapides, indispensable lors du prototypage.

>Le fait de pouvoir ajouter ou supprimer facilement une ressource est un point très important du prototypage.

Ben ça revient au même ...

> Non, c'est le ton programme qui doit maitriser la vitesse, pas ta carte graphique.

mais il y a pas tant d’événement possible que ça faim / soif / sommeil / repos ...

> Je pense que t'es un peu naïf.

Oui c'est le principe

>Faut pouvoir s'en affranchir si cela peut faire des trucs "fun", prototypage, tout ça tout ça.

Je n'utilise pas de moteurs, ni de bibliothèques,...

>Vous perdez du temps à réinventer la roue, prototypage, tout ça tout ça.

Oui mais ça marche aussi très bien et si ça simplifie le code.

>Ouais, je suis dubitatif, c'est en opposition avec la conception objet "orthodoxe". Des exemples SVP ?

Je connais pas trop ECS ...

> Vous sous estimez très très grandement l'impact d'un ECS.

Ca sera pas la partie la plus dure à faire je pense

>Alors comment expliques-tu le taux d'échecs de ce type de produit ?

RAD C'est quoi ?

>Développement rapide d'applications — Wikipédia (wikipedia.org)

>Outils de prototypage, comme les moteurs et librairies que vous snobez.

car les problématique sont rarement exactement les mêmes

>Tu connais la fable du Héron de La Fontaine ?

>city-builder · GitHub Topics · GitHub