13-02-2013, 12:39 AM
Effectivement, la puissance va te poser soucis:
- La complexité des algos, comme l'a souligné Sorens, au sens de "complexité d'exécution" et non "conception compliquée" (autrement dit, les algorithmes seront leeeeeeents*)
- La masse de données dans la DB (des millions d'entrées, pas de soucis pour MySQL... mais si chaque entrée fait 100 octets, tu te retrouve avec des BDD qui montent rapidement à des centaines de Mo, et tu seras forcé de prendre un hébergement "lourd", un dédié ou un VPS: bye bye le mutualisé pas cher qui permet de démarrer presque sans frais)
Le principe de n'exécuter l'algo que si un joueur fait un changement dans sa ville ne sera probablement pas une solution miracle, car cela fera quand même des masses importantes de données à traiter. De plus, si tu pars là dessus, attention à ne pas faire (comme j'ai fait...) attendre le joueur 10 ou 20 secondes le temps de simuler ta ville. Crois-moi, après expérience réelle ("IRL"), les joueurs ne restent pas sur ton jeu s'il mets 20 secondes avant d'afficher une page...
L'asynchrone ne résoudra pas grand chose car le joueur aura des données obsolètes tant que la simulation ne sera pas faite (en synchrone: j'envoie un ordre, le serveur mouline, et il me répond avec un résultat actuel; en asynchrone: j'envoie un ordre, le serveur mouline, je continue à jouer avec les données de "avant l'ordre", le serveur me répond plus tard: pendant un laps de temps, j'ai joué avec des données obsolètes).
Si tu pars sur des millions de citoyens, il vaut mieux, à mon avis, revoir la conception et constituer des "intelligences collectives" plutôt que de faire des IA individuelles. Par exemple, au lieu de dire "je vais considérer l'attribut 'santé' pour chaque citoyen, tu peux considérer une valeur de santé pour tous les citoyens, et définir une fonction de répartitions de la santé entre tous les citoyens, c'est à dire une fonction qui à x, "l'identifiant" du citoyen, associe f(x), sa santé. Cette fonction aura une "aire" égale à la santé totale de ta population, mais au lieu de manipuler 10.000 valeurs de santé indépendantes, tu manipules uniquement une fonction avec un minimum (le citoyen le plus faible, osef de qui c'est) et un maxima (le plus en forme).
Bref, à mon avis, simuler chaque unité indépendamment aura l'inconvénient d'être trop lourd pour le serveur, et n'aura pas l'avantage d'une étude statistique sur toute la population (en d'autres mots, que tu simules chaque citoyen ou que tu simule tout le groupe de citoyen avec des outils mathématiques et statistiques, tu auras les mêmes résultats, à un pet de lapin près qui ne justifiera pas la puissance de calcul déployée).
*: Exemple pour une ville de 2*N habitants: N hommes, N femmes.
Un homme cherche une femme. Il a N choix.
Un autre cherche une autre femme, il a "grosso modo" N choix aussi (N-1 en pratique, mais si N est grand, exemple 10.000, alors N-1~=N car 10.000, c'est "pas loin" de 9.999; la notion de "pas loin" simplifie les calculs et se justifie mathématiquement).
Si, pour chaque homme, tu "teste" si une femme peut lui plaire, alors, pour chaque homme, tu va faire N tests.
Comme il y a N hommes, tu vas faire N² tests. Et donc, si N=10.000, tu te retrouves avec 100.000.000 de tests à faire: pour php, ca va dérouiller le serveur...
Tu risques donc d'avoir une difficulté de puissance de calcul, PHP ne sera probablement ps adapté, et il faudra se tourner vers du C au moins.
- La complexité des algos, comme l'a souligné Sorens, au sens de "complexité d'exécution" et non "conception compliquée" (autrement dit, les algorithmes seront leeeeeeents*)
- La masse de données dans la DB (des millions d'entrées, pas de soucis pour MySQL... mais si chaque entrée fait 100 octets, tu te retrouve avec des BDD qui montent rapidement à des centaines de Mo, et tu seras forcé de prendre un hébergement "lourd", un dédié ou un VPS: bye bye le mutualisé pas cher qui permet de démarrer presque sans frais)
Le principe de n'exécuter l'algo que si un joueur fait un changement dans sa ville ne sera probablement pas une solution miracle, car cela fera quand même des masses importantes de données à traiter. De plus, si tu pars là dessus, attention à ne pas faire (comme j'ai fait...) attendre le joueur 10 ou 20 secondes le temps de simuler ta ville. Crois-moi, après expérience réelle ("IRL"), les joueurs ne restent pas sur ton jeu s'il mets 20 secondes avant d'afficher une page...
L'asynchrone ne résoudra pas grand chose car le joueur aura des données obsolètes tant que la simulation ne sera pas faite (en synchrone: j'envoie un ordre, le serveur mouline, et il me répond avec un résultat actuel; en asynchrone: j'envoie un ordre, le serveur mouline, je continue à jouer avec les données de "avant l'ordre", le serveur me répond plus tard: pendant un laps de temps, j'ai joué avec des données obsolètes).
Si tu pars sur des millions de citoyens, il vaut mieux, à mon avis, revoir la conception et constituer des "intelligences collectives" plutôt que de faire des IA individuelles. Par exemple, au lieu de dire "je vais considérer l'attribut 'santé' pour chaque citoyen, tu peux considérer une valeur de santé pour tous les citoyens, et définir une fonction de répartitions de la santé entre tous les citoyens, c'est à dire une fonction qui à x, "l'identifiant" du citoyen, associe f(x), sa santé. Cette fonction aura une "aire" égale à la santé totale de ta population, mais au lieu de manipuler 10.000 valeurs de santé indépendantes, tu manipules uniquement une fonction avec un minimum (le citoyen le plus faible, osef de qui c'est) et un maxima (le plus en forme).
Bref, à mon avis, simuler chaque unité indépendamment aura l'inconvénient d'être trop lourd pour le serveur, et n'aura pas l'avantage d'une étude statistique sur toute la population (en d'autres mots, que tu simules chaque citoyen ou que tu simule tout le groupe de citoyen avec des outils mathématiques et statistiques, tu auras les mêmes résultats, à un pet de lapin près qui ne justifiera pas la puissance de calcul déployée).
*: Exemple pour une ville de 2*N habitants: N hommes, N femmes.
Un homme cherche une femme. Il a N choix.
Un autre cherche une autre femme, il a "grosso modo" N choix aussi (N-1 en pratique, mais si N est grand, exemple 10.000, alors N-1~=N car 10.000, c'est "pas loin" de 9.999; la notion de "pas loin" simplifie les calculs et se justifie mathématiquement).
Si, pour chaque homme, tu "teste" si une femme peut lui plaire, alors, pour chaque homme, tu va faire N tests.
Comme il y a N hommes, tu vas faire N² tests. Et donc, si N=10.000, tu te retrouves avec 100.000.000 de tests à faire: pour php, ca va dérouiller le serveur...
Tu risques donc d'avoir une difficulté de puissance de calcul, PHP ne sera probablement ps adapté, et il faudra se tourner vers du C au moins.