+- 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 : Boucle UPDATE, RAND (/showthread.php?tid=7787)
RE: Boucle UPDATE, RAND - Xenos - 29-03-2017
Je crois que je peux difficilement est plus (+) d'accord avec Ter Rowan...
Citation :pour éviter de mettre un RAND(), je crée une colonne "priorité" ...C'est exactement ce que faisait l'ajout d'une colonne supplémentaire & le UPDATE... RAND() de l'exemple, tu choisis après ce que tu mets comme règles là-dedans (et, oui, rien ne t'oblige à re-exécuter ce UPDATE à chaque simulation si c'est inutile). A voir si un INDEX là dessus est intéressant ou non (ie: le temps d'UPDATE de l'INDEX face au temps d'utilisation dans le INSERT ... ON DUPLICATE...).
Citation :pas traiter toute la population individuellementC'est exactement ce que j'entendais par tu as un soucis dans l'objectif général du jeu ou dans ton modèle. Un autre possibilité est de ne pas considérer le moral par catégorie de population, mais globalement. Tu peux alors conserver 1 enregistrement (1 ligne) par personnage (même si c'est complètement redondant), et avoir 1 ligne pour le moral général de toute la population du joueur. Ce moral se calcul alors simplement par un UPDATE joueur_stats INNER JOIN joueur_ressources ON joueur_ressources.id_joueur = joueur_stats.id_joueur SET moral = IF((SELECT SUM(eat) FROM population WHERE population.id_joueur = joueur_stats.id_joueur) >= joueur_ressources.quantite, moral + 20, moral - 20) ou autre règle proportionnelle (MySQL est plutôt véloce quand il s'agit de sommer les données sur un index).
Pour info, l'approche sur ECLERD est un mix des deux: la population est stockée par catégorie (par tranche d'âge & corps de métier), et le moral (les troubles à l'ordre public type Emeutes) sont stockées globalement pour toute la population d'une région. Une simple moyenne permet d'avoir les troubles d'un pays.
PS: l'histoire des autres SGBD, c'était plus ironique qu'autre chose: peu importe le système que tu vas choisir, je doute que tu puisses réaliser une telle masse de calculs sans un financement adéquat pour le serveur, que ce soit en faisant des requêtes dans le PHP ou dans le SGBD via des procédures.
RE: Boucle UPDATE, RAND - Keltaïnen - 29-03-2017
Je pense que Metallique a déjà pas mal d'infos pour avancer donc je ne vais pas m'étendre sur le sujet mais il y a quand même un point qui me gène :
(28-03-2017, 06:35 PM)Xenos a écrit : C'est surtout l'affirmation arbitraire de "10000 lignes" que je voulais contrer.
Ce n'est pas une information arbitraire. C'est vrai, c'est arrondi car je n'ai pas déterminé la valeur exacte qui doit être plus proche de 8000 pour une conf standard (et ça dépend aussi du nombre de champs, bien sûr). Et si tu ne veux pas t'amuser à faire du tuning MySQL c'est ce genre de limites auxquelles j'ai toujours été confronté et ça fait 13 ans que je fais du MySQL.
Évidemment j'ai eu des cas où je pouvais charger par paquets de 50 000 mais ça nécessite de savoir paramétrer un serveur MySQL (et d'avoir accès à la conf) et tu n'a qu'un gain de x10 par rapport à des blocs de 5 000 (valeur que je j'utilise en général) qui est déjà une bonne optimisation par rapport à des INSERT unitaires. De toutes façons tu ne peux pas te permettre de ne pas connaitre la taille des blocs que tu insères si ton volume est trop variable (un jour tu te réveilles ton serveur est planté car tu as doublé la taille et hop, ça ne passe plus en RAM). Rien n'empêche de mettre le nombre de lignes en paramètre et l'augmenter par la suite quand ça s'avèrera indispensable.
Et puis bon le terme "contrer", ça sonne un peu bizarre dans ce contexte.
A titre d'info pour avoir également bossé avec Oracle, MariaDB et Postgres :
- Oracle : il est plus robuste et plus complets en terme de fonctionnalités. J'ai bossé 5 ans dessus et je n'en ai pas fait le tour, le coût pour un particulier doit être costaud (mais je n'ai pas vérifié)
- MariaDB : je n'ai pas remarqué de différence notable avec MySQL au niveau technique, je pense que la différence est surtout dans la licence (voir Wikipédia)
- Postgres : je le vois comme un mix en MySQL et Oracle. Il a plus de fonctionnalité que MySQL mais n'a pas la robustesse d'Oracle. Je le trouvais pas mal quand il n'y avait pas de triggers/procédures stockées en MySQL.
RE: Boucle UPDATE, RAND - niahoo - 29-03-2017
(28-03-2017, 02:52 PM)niahoo a écrit : ça fait quoi le moral au juste pour les citoyens ?
Je m'autoquote car je pense que tu ne pars pas forcément dans la bonne direction. Généralement dans les jeux ou on gère une large population il n'est pas très intéressant pour le joueur de gérer individuellement ces citoyens. Bien que ça ne soit pas une règle absolue.
RE: Boucle UPDATE, RAND - MeTaLLiQuE - 29-03-2017
(29-03-2017, 03:17 PM)niahoo a écrit :(28-03-2017, 02:52 PM)niahoo a écrit : ça fait quoi le moral au juste pour les citoyens ?
Je m'autoquote car je pense que tu ne pars pas forcément dans la bonne direction. Généralement dans les jeux ou on gère une large population il n'est pas très intéressant pour le joueur de gérer individuellement ces citoyens. Bien que ça ne soit pas une règle absolue.
Oups, oublié de te répondre...
Il y a plusieurs choses qui constituent le moral... Si on perd ou on gagne une guerre, si les populations ont tous été correctement nourries ou pas et selon leur taux de taxation...
Plus le moral est elevé (sur la moyenne générale), et plus les populations produiront, a contrario, plus leur moral est faible, moins elles produiront.
Quand leur moral arrivera au plus bas, ils quitteront le domaine. Ce qui entraînera une perte de production, donc une perte de revenu, etc. ...
Si a un moment donné, le jeu devient trop lourd à gérer, j'aviserai et je grouperai selon les catégories pour faire un ensemble. (ce que j'aimerais éviter au maximum...)
RE: Boucle UPDATE, RAND - Ter Rowan - 30-03-2017
(29-03-2017, 04:49 PM)MeTaLLiQuE a écrit : Si a un moment donné, le jeu devient trop lourd à gérer, j'aviserai et je grouperai selon les catégories pour faire un ensemble. (ce que j'aimerais éviter au maximum...)
hello, à mon sens tu as tord pour quatre raisons peut-être même six(n'y vois aucune agression)
1) le GamePlay sera inutilisable pour la plupart des joueurs (ou pire, le GamePlay ne montrera aucune différence avec une gestion par "ensemble")
2) tu n'as pas les compétences en BDD suffisante pour un tel dispositif, suffit de voir la question posée initialement (t'inquiète, moi non plus je ne saurais pas faire bien)
3) tu n'utilises pas le langage le mieux adapté pour ces calculs (il faudrait voir dans les logiques floues et autres, des langages dédiés à ce genre de problème)
4) revenir en arrière quand tu seras dans le mur ("si à un moment donné") sera particulièrement coûteux (refaire des développements, moral en berne vu les efforts, etc...)
5) (peut-être) les ressources d'infrastructure seront coûteuses pour une expérience agréable par le joueur (à mon sens le risque de ne pas avoir assez de retour sur investissement est trop important)
6) (peut-être) les compétences en intelligence artificielle / réseau de neurones, etc... te seront nécessaires si tu veux arriver à quelque chose de performant.
pour ma part j'avais essayé (sur le papier) à construire un modèle de ce genre, mais on voit vite une explosion des calculs. Mon idée était que chaque élément pouvait interagir avec les autres et donc adaptés son comportement. J'ai vite explosé en vol malheureusement.
Après si j'ai tord et que tu réussis, très bien, et je serais particulièrement content de reconnaitre mon erreur et d'apprendre de ton expérience (et j'aurais alors plein de questions à poser parce que ce sujet est vachement intéressant)
RE: Boucle UPDATE, RAND - Xenos - 30-03-2017
Citation :Si a un moment donné, le jeu devient trop lourd à gérer, j'aviserai et je grouperai selon les catégories pour faire un ensemble.Pour moi, t'y es déjà (enfin, quand t'auras des joueurs; je te le souhaites, mais je doute quand même qu'un jeu au démarrage ait des milliers de joueurs actifs... et une centaine de joueurs actifs amènent des millions de ligne de BDD, je pense que tu peux revoir ton modèle/ton gameplay, qui ne sont pas adaptés à tes moyens)
Le problème n°1 de Ter Rowan est le plus pertinent à mon sens, car même si tu réussissais à coder une telle structure, alors ce ne sera pas jouable et pas joué.
Perso, j'ai l'impression que t'es dans les mêmes rails qu'ECLERD, le mot "moral" est juste remplacé par "Manifestations, Emeutes, Guerre Civil" (ouep, 3 niveaux de moral différents, c'était vraiment une idée de génie >.>). Je confirme ce que dis Ter Rowan: la quantité de calcul explose (même si j'avais trouvé cela marrant à faire, niveau résultat final et jeu jouable, bof bof) et la jouabilité s'effondre.
Pour ma part, j'avais implémentée le moral par catégorie d'habitants (~12 tranches d'âge et ~6 corps de métiers = 72 catégories, ce qui fait déjà par mal). Là, c'est gérable niveau code. Niveau joueur, c'est autre chose. Par exemple, des spirales dépressives apparaissent (et pas que chez le créateur!): j'ai une baisse de ressources, donc le moral de la population baisse (car elle mange moins), donc sa productivité baisse (cf règles) donc la quantité de ressources baisse... Et 72 catégories, pour savoir laquelle est dépressive et ce qu'il faut donc faire, c'est cramé.
@Keltaïnen Pour MySQL, si tu charge des centaines de millions de lignes, c'est par un fichier qu'il te faut passer via LOAD DATA INFILE. Ici, je parle d'UPDATE. Il n'y a pas de limite "en dur aux alentours de 8k-10k". Dans l'exemple ci-dessous, la table est une liste de 524k vaisseaux, avec un id "type". Les valeurs indiquées montrent une durée linéaire, avec certes un "flottement", mais à 80k (sur mon poste maison, MySQL 5.7.14, avec un PRIMARY sur id et un INDEX sur type).
UPDATE vaisseaux SET `type` = `type`-1 WHERE id < 50000
-- Tout 524k -> 15s
-- Where 500k -> 15s
-- WHERE 300k -> 10s
-- WHERE 200k -> 7.7s
-- WHERE 100k -> 5.6s
-- WHERE 50k -> 1.5s
-- WHERE 10k -> 0.3s
-- Where 1k -> 0.03s
En revanche, ce que j'accorde sans problème, c'est la lenteur des requêtes préparées de PHP. Passé les 100 voire 1000 élément, c'est juste immonde (faute à une complexité non-linéaire).