JeuWeb - Crée ton jeu par navigateur
Micromanagement - Comparer nos solutions - Version imprimable

+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : Micromanagement - Comparer nos solutions (/showthread.php?tid=4004)

Pages : 1 2 3 4


RE: Micromanagement - Comparer nos solutions - keke - 03-06-2009

Perso, l'un de mes développeurs fonctionnaient ainsi ... mais c'est assez vite le bordel. Dès que ce développeur a quitté le projet, je me suis empressé d'assainir la situation ^^.

Perso, je préfère une table relationnelle entre bâtiments et espèces. (Rel_sympathie_batiment_espece par exemple). Niveau code, c'est un poil plus long, mais pour le reste, c'est aussi rapide et en même temps plus clair à la lecture du schéma de donnée.

Kéké qui retrouve les interrogations qu'il a du solutionner pour sa propre économie dans le jeu ^^.


RE: Micromanagement - Comparer nos solutions - barst - 03-06-2009

+1

Pour les relations 1-n, il faut une table intermédiaire de jointure même si tes opérations binaires fonctionnent, tu dois perdre en lisibilité dans tes requêtes.

Sinon j'aurais besoin de précision :
- tes bâtiments peuvent satisfaire plusieurs besoins ou un seul ?
- où est défini la limite de PNJ par bâtiment ?


RE: Micromanagement - Comparer nos solutions - Roworll - 03-06-2009

Citation :- tes bâtiments peuvent satisfaire plusieurs besoins ou un seul ?
C'est donné dans l'énoncé : Ces bâtiments permet de satisfaire un ou plusieurs besoins de base
Certains bâtiments comblent donc 1 seul besoin, d'autres 2, et certains, 3.
Citation :Où est défini la limite de PNJ par bâtiment ?
Pour le moment dans la table batiment_joueur, les bâtiments pouvant évoluer en fonction des recherches effectuées par le joueur.

Je cherche une solution efficace en consommation de ressources sur le serveur. L'attribution de bâtiments se faisant, je le rappelle, lors du décompte en fin de chaque 'tour'.


RE: Micromanagement - Comparer nos solutions - lcfseth - 04-06-2009

Une idée pour simplifier les calculs :
Une fois un PNJ casé, il ne quitte le batiment que si il a assouvi son besoin ou alors si un autre besoin atteint un seuil critique.
Normalement cela devrait diminuer au moins de moitié le nombre de PNJ/Places. Ensuite c'est simplement le probleme du marchand de sable. Un probleme largement traité.

Une autre solution, mais qui n'est probablement pas la meilleure, s'apparente à de la physique newtonienne. Chaque batiment emet une aura attractive dont la nature et l'intensité dependent du nombre de places libres et de la nature du besoin. Les PNJ emettent eux aussi une aura semblable. Cette methode est assez simple à implementé pour des jeux desktop ( elle l'a d'ailleurs été, mais je sais plus dans quel jeu). Mais je ne pense pas que ce soit l'idéale pour un browser game. C'est une piste comme une autre.


RE: Micromanagement - Comparer nos solutions - wild-D - 04-06-2009

si vous trouvez qu'il est mieux de faire une table de relation pour les races, ça veut dire que vous faites logiquement pareil pour les besoins (un batiment pouvant satisfaire 1-n besoin).
eprso je vois pas pourquoi il ferais pas une table avec 4 attributs races (binaire), et 6 attributs besoins; ça éviterait quand même bien des jointures. Après le coup du ID_race agrégateur, bof.

question:
- t'as pas parlé de distance donc je suppose que ça n'entre pas en ligne de compte ou si ?
- autre point important c'est l'impact des besoins ? est-ce qu'il y a un seuil létal ? bref, ça fait quoi sur les PNJ d'avoir des besoins plus ou moins satisfait (c'est quoi les critères d'optimisations).

Tu ne donne aucun critère d'optimisation (vaut mieux optimiser la réponse au besoins moyen - quitte à avoir des PNJ "mort" ou l'inverse ?).
Ou alors s'agit justement de remplir le max de batiments le plus vite possible, les PNJ sont stupide, donc peut importe comment (un peu comme les chaises musicales, au final, les PNJ s'en foute de la couleur de la chaise... le premier critère est de trouver une chaise et pas rester debout => donc voir tout ses besoins augmenter et aucun diminuer). En gros l'idée c'est de compter sur l'effet moyen comme régulateur/optimisateur.

Autre point que tu ne précise pas c'est quel est l'efficacité des batiments (on sait que les besoins augmentent de 1à6 par tour, mais un batiment à quoi comme échelle d'effet ? -3.5 , -35 ? Et un PNJ peut-il avoir un besoin négatif ? (un peut le principe du PNJ qui mange trop donc grossi, si t'as des seuils létaux voudrait dire que tes PNJ peuvent mourir aussi bien de trop manger que de pas assez).


RE: Micromanagement - Comparer nos solutions - Roworll - 04-06-2009

Je n'ai pas voulu rentrer dans les détails pour justement éviter de trop compliquer le problème mais je crois que le moment est venu d'en dire un peu plus.

J'essaye de simuler un comportement "naturel" pour une populations de PNJs.
Les besoins donnés en début de sujet évoluent de 100 (besoin satisfait) à 0 (need graaave !)
Un PNJ commence à ressentir un manque lorsque son besoin passe sous la barre des 80.
Il se met alors à la recherche d'une structure lui permettant de satisfaire ce besoin (la distance n'entre pas en ligne de compte)

Lorsque plusieurs PNJs sont en état de manque pour un même besoin, ils sont placés dans les structures en fonction de l'urgence. Les PNJs avec un gros besoin sont prioritaires et ont donc accès aux structures comblant ce manque le plus efficacement.

Supposont deux PNJs ayant faim après l''évolution de leurs besoins.
Anthres à un niveau de besoin [faim] à 70
Bedric à un niveau de besoin [faim] à 55

Prenons le cas ou je n'ai qu'un seul distributeur de nourriture remontant le niveau de faim de 10 pts,
Tour 1 : Bedric est prioritaire et utilise le distributeur. Sa Faim remonte à 65 (55+10)
Tour 2 : les besoins évoluent. Anthres tombe à 68 (-2), Bedric à 64(-1). Il reste donc prioritaire pour utiliser le distributeur et son besoin remonte à 74 (64+10)
Tour 3 : nouvelle érosion des besoins, Anthres arrive à 66 (-2) et Bedric à 72 (-2).
Anthres prend donc la place de Bedric pour ce tour.
etc

Autre cas avec deux distributeurs. Le premier comble 5 pts de faim et le 2e 13
Tour 1 : Bedric prend le meilleur distributeur. Sa faim remonte à 68 (55+13) Celle d'Anthres remonte à 75 (70+5)
Tour 2 : les besoins évoluent. Anthres tombe à 73 (-2), Bedric à 67 (-1). Bedric reste donc dans le meilleur distributeur. A la fin du tour, Bedric à 80 (67+13) en faim et Anthres 78 (73+5)
Tour 3 : nouvelle érosion des besoins, Anthres arrive à 76 (-2) et Bedric à 78 (-2).
Les deux PNJs, toujours affamés échangent alors leurs places dans leurs structures respectives.
etc

Si un PNJ a deux besoins en manque, il essaye de combler en premier celui qui lui fait le plus défaut, l'idéal pour lui étant bien sur de trouver une structure comblant de multiples besoins à la fois.

Les Besoins sont maxés à 100. Pas de danger en cas de dépassement.
Descendre sous le seuil des 80 pousse le PNJ à rechercher un moyen de satisfaire son besoin.
Sous la barre des 60, un PNJ avec un besoin non satisfait commence à perdre du moral (l'échelle de perte n'est pas encore définie) et à véhiculer une image négative du joueur (perte de réputation).
Arrivé à 0 pts de moral, le PNJ quitte le service du joueur (en lui ruinant sa réputation au passage).

Voici un tableau résumant grosso modo les évolution moral/réputation en fonction des besoins du PNJ.

Code :
Besoin | En structure | Hors structure
-------|--------------|----------------
80-100 | N/A          | Moral +
       |              | Réputation +
-------|--------------|----------------
60-79  | Moral +      | Moral =
       | Reputation + | Réputation =
-------|--------------|----------------
40-59  | Moral +      | Moral -
       | Réputation + | Réputation -
-------|--------------|----------------
20-39  | Moral +      | Moral --
       | Réputation = | Réputation -
-------|--------------|----------------
1-19   | Moral +      | Moral --
       | Réputation = | Réputation --
---------------------------------------

Le seul besoin ayant un impact sur la vie d'un PNJ est son indice de santé. Arrivé a 0, le PNJ meurt.
Si un autre besoin tombe à 0 le PNJ partira tout simplement.


RE: Micromanagement - Comparer nos solutions - Shao - 04-06-2009

Aie aie aie, la gestion des priorités va être un vrai casse-tête ! Confused
Je pense qu'il manque un exemple qui permettrait de mieux décortiquer l'algo à produire : Tu nous as montré un cas avec un besoin, je voudrais savoir ce qu'il se passe avec 2 besoins sur 2 PNJs avec déjà un distributeur puis 2 fournissant 2 besoins.
Exemple :

Toto a un niveau de besoin [faim] à 70 et un besoin [hygiène] à 60
Tutu à un niveau de besoin [faim] à 55 et un besoin [hygiène] à 70
(je fais exprès d'inverser les 2 valeurs)
Un seul distributeur donnant 10 points de faim et 10 points d'hygiène.
Tutu est prioritaire sur le besoin [faim] donc normalement ça devrait être lui qui devrait l'emporter.
Pourtant Tutu est prioritaire sur le besoin [hygiène] donc lui aussi est prioritaire pour ce lieu.
L'ordre de priorité est défini par un critère externe du coup non ? (le moral par exemple)

De même je reprend le même cas particulier mais avec deux distributeurs dont le premier est similaire au premier exemple mais le second donne uniquement 10 points de faim.
L'un des deux va choisir un distributeur qui sera plus intéressant qu'un autre puisque l'un des deux PNJ bénéficiera d'un bonus dans les deux besoin alors que l'autre n'en aura qu'un seul mais quelle est le critère pour déterminer qui aura le meilleur distributeur.
Du coup il faut là aussi un autre critère externe je pense.

Sinon autre question qui pourrait complexifier encore plus le problème actuel : Est ce que le joueur peut définir des préférences entre un PNJ et des fournisseurs ( ex : je veux que toto par défaut choisisse le fournisseur avec les deux besoin plutôt que le premier par défaut ), cela pourrait être notre critère externe (remplaçant le moral).

Voilà sinon pour une idée simple est pas trop chère, je sais pas si ça vaut le coup de séparer chacun des besoins dans une table "BonusBesoin" qui contiendrait les bonus en rapport avec un fournisseur et un besoin spécifique , ou alors rajouter un attribut dans la table des Fournisseurs pour expliciter le fait que ce fournisseur peut fournir des besoins multiples.
Cela permettrait de simplifier la recherche pour les PNJs ayant des besoins multiples.

Sinon une autre idée, c'est que tu partes du fait que tout les jours tu construis le parcours des pnj à l'avance au lieu de le faire à la fin de chaque tour. A une heure précise tu calcules le chemin de chaque pnj. Le soucis de ce truc c'est que tu ne vis pas dans un univers déterministe vu que un pnj perd un nombre de points dans chacun de ses besoin de manière aléatoire. Du coup l'algo est pas vraiment réaliste et devra se baser sur des bornes d'intervalles.

Une dernière idée (je sais j'en ai beaucoup même si elles sont pas forcément bonnes), c'est de classer tes fournisseurs dans des "foyers" de besoins avec des critères précis (ce foyer accepte que les pnjs ayant entre 60 et 80 de faim), l'avantage étant de faire rentrer un pnj dans un foyer et de le faire sortir que quand il n'est plus dans les critères de ce foyer. Ces derniers peuvent être également construit en début de journée puis par la suite reconstruit et remanier tout les jours à chaque fois.
Du coup ton algo est plus simple car dans un premier temps tu fais entrer/sortir les PNJ des foyers dans lesquelles ils n'ont plus besoin d'être, puis dans un second temps tu fais tourner les pnj dans chacun des foyers.
L'inconvénient de cette idée, c'est cette fameuse construction de foyer qui peut être gênant pour certains fournisseurs car on ne sait pas trop où les placer.


RE: Micromanagement - Comparer nos solutions - keke - 04-06-2009

Ca me semble plus complet comme ça ^^.

Un autre point à prendre en compte est il le besoin face à la demande ? Souhaites-tu mettre en place un système de bourse pour que les PNJ/PJ puissent choisir un batiment plutôt qu'un autre ?

S'il n'y a pas assez de place dans un batiment pour accueillir tout le monde ? Peut-il y avoir une pénurie ? Ton problème ressemble de plus en plus à mon système de bourse élastique. Je suis content que l'on se rejoigne dans ces problèmes d'algorithmie ^^.
Les questions à se poser sont :
- Y'a-t-il compétition des magasins ?
- le PNJ/PJ a-t-il une conscience globale du marché ? Ou une vision très limitée.
- peut-on imaginer un système contenant des pertes ?
- l'économie est-elle en pénurie de marché ou en abondance ? Faut-il traiter l'un et l'autre cas de manière distinctes ou suivre un modèle mathématique qui atténuerait la courbe.

Bon courage pour ton projet ... j'ai passé près d'un an à mettre en place mes algos, les tester, ne pas en être fier, etc ... et dès que je voulais complexifier le biniou, ça m'obligeait à refaire une bonne partie du code ^^.

kéké qui n'en garde pas un bon souvenir !


RE: Micromanagement - Comparer nos solutions - comg - 05-06-2009

Je ne sais pas si vous connaissez (probablement :$) mais je me permet de vous proposer ce lien :

http://www.lesforges.org/afficher.php?art=26

Un trés bon article sur le commerce dans les RPG.

En tout cas bon courage, c'est un aspect fascinant d'un RPG à mes yeux !


RE: Micromanagement - Comparer nos solutions - lcfseth - 05-06-2009

Une autre question que l'on pourrait se poser, est celle de la persistance de l'univers. Calculer l'évolution des PNJ sur une durée d'un tour n'est pas trés compliqué, mais que se passe-til si le joueur abondonne son jeu pour une durée d'une semaine ( qui je l'imagine equivaut à plus d'une centaine de tours ). Faire une simulation au tour par tour ruinerait completement le serveur.

Je pense qu'il faut partir sur une base probabilistique : J'ai tant de besoin, tant d'offre, je peux donc degager que sur un tour on va avoir une augmentation globale de X en besoin de type 1. Ensuite il faut une fonction de distribution. J'ai N PNJ avec une valeur Vi en besoin, Une moyenne de M en besoin, je dois distribuer X points de besoin, donc chaque PNG aura environ X/N + f(M-Vi).
f est une fonction de M-Vi (l'ecart à la moyenne ) heuristique censé simuler l'aspect prioritaire . Normalement l'integrale de F doit etre nulle sur l'interval [MaxVi,MinVi] pour pouvoir retrouver un resultat correcte. ( Je sais, parler d'integrale sur un ensemble discret n'est pas correcte, En fait c'est la somme des f(M-Vi) pour tout i ).
On peut aussi inserer une fonction aleatoire, mais son impact devra etre minime.

Je sais pas si c'est clair, ni même si c'est appliquable pour plusieurs besoins. La difficulté etant de trouver une fonction f valide, mais l'avantage est que l'on peut etendre la durée à plus d'un tour.

Une autre idée completement hors de propos serait de laisser au joueur le soin de determiner les priorités des besoins, un vrai casse tête à faire en code ( enfin si on cherche l'optimisation bien sur, sinon suffit de definir un ordre de priorité arbritraire ).

Aussi, j'aime pas trop l'idée d'avoir un seule critère de jugement ( le moral des PNJ ), ca limite les possibilités des joueurs. Relié chaque besoin des PNJ au besoin du joueur ( PNJ qui a faim = PNJ qui recupere mal, PNJ fatigué = PNJ qui ne travail pas... ) me parait mieux, mais ce n'est qu'un point de vue.