Sur Isometry, par exemple, j'ai
Pour l'initialisation du type de case (tu remplaces ça par des glands, c'est pareil). Bon, comme dit, à l'initialisation, l'aléatoire peut passer (de même que forger manuellement la carte). L'avantage de ne pas en user, c'est que:
• Je peux exécuter ce script en local et en prod, j'aurai forcément le même résultat (plutôt pratique pour éviter les surprises au déploiement), ce qui est franchement top
• Je peux rendre périodique la carte (intéressant pour éviter le "premier arrivé, premier bien placé"), ou apériodique (plus riche en choix, mais donc, favorisant potentiellement certains joueurs), suivant ma volonté de game designer
• Concevoir les choses aléatoirement pousse parfois à se reposer sur les statistiques pour avoir un jeu équilibré; le déterministe a l'avantage de permettre de forger manuellement/par l'aléatoire/par une fonction bien choisie sa carte (ie: les probas n'interviennent pas pour équilibrer le jeu)
• SQL peut faire d'énormes optimisations en considérant une fonction déterministe (après, on peut "bluffer" et dire qu'une fonction stockée ayant un RAND() est en fait déterministe, cela revient à dire "pour cette requête, RAND() sera toujours identique si les entrées de la fonction sont les mêmes"; c'est un peu tordu, mais envisageable; une fonction purement et classiquement déterministe n'a alors pas cet aspect tordu)
Au fond, on pourrait me rétorquer "il suffit de générer un seed aléatoire (initialisation) et de l'utiliser après dans toute la partie". C'est un peu l'idée: les choses sont alors rejouables (déterministes), et ça, ce sera très souvent utile à un moment donné (ie: rejouer un scénario où le joueur s'est fait défoncer, pour comprendre pourquoi et ré-équilibrer le gameplay). C'est un peu pareil pour le Doodle Challenge, qu'on peut alors rejouer. Et ça m'a été demandé aussi pour le Thunderbolt generator et pour le planet generator.
On peut me rétorquer que "ouais, c'est pas pareil, c'est pas des jeux", mais à mon sens, la même chose devrait se faire sans problème dans un jeu, à une échelle simplement différente.
En revanche, pendant la partie, c'est là où je doute... Sur Flux, j'ai justement un aléatoire pour placer les villes, les faire apparaitre ou non, ajouter des voitures entre deux villes, etc. Au final, cela crée des parties très chiantes pour certaines, d'autres très difficiles, d'autres trop faciles... Rendre les choses prédictibles pour le serveur, cela simplifie quand même vachement le boulot de création (ce que je ferait dans Flux en créant des scénarios, éventuellement construits à partir de seed puis sélectionnés pour ne retenir que ceux qui sont intéressants/faciles/etc), sans forcément flinguer l'expérience du joueur (ce n'est peut-être pas prédictible du joueur car il n'a pas toutes les informations requises).
Mais bon, après, chacun son jeu.
Citation :UPDATE map AS m
LEFT JOIN map_building AS mb ON mb.id_case = m.id
SET m.`type` = IF(
mb.id_building IS NULL AND (SIN(0.3*m.x+0.1*m.y) + SIN(0.6*m.x-0.4*m.y) + 0.6*SIN(0.2+0.1*m.y*m.x) - 0.25*SIN(0.4-2*m.y+1.5*m.x)) < -0.3, 'MER', 'PLAINE')
;
Pour l'initialisation du type de case (tu remplaces ça par des glands, c'est pareil). Bon, comme dit, à l'initialisation, l'aléatoire peut passer (de même que forger manuellement la carte). L'avantage de ne pas en user, c'est que:
• Je peux exécuter ce script en local et en prod, j'aurai forcément le même résultat (plutôt pratique pour éviter les surprises au déploiement), ce qui est franchement top
• Je peux rendre périodique la carte (intéressant pour éviter le "premier arrivé, premier bien placé"), ou apériodique (plus riche en choix, mais donc, favorisant potentiellement certains joueurs), suivant ma volonté de game designer
• Concevoir les choses aléatoirement pousse parfois à se reposer sur les statistiques pour avoir un jeu équilibré; le déterministe a l'avantage de permettre de forger manuellement/par l'aléatoire/par une fonction bien choisie sa carte (ie: les probas n'interviennent pas pour équilibrer le jeu)
• SQL peut faire d'énormes optimisations en considérant une fonction déterministe (après, on peut "bluffer" et dire qu'une fonction stockée ayant un RAND() est en fait déterministe, cela revient à dire "pour cette requête, RAND() sera toujours identique si les entrées de la fonction sont les mêmes"; c'est un peu tordu, mais envisageable; une fonction purement et classiquement déterministe n'a alors pas cet aspect tordu)
Au fond, on pourrait me rétorquer "il suffit de générer un seed aléatoire (initialisation) et de l'utiliser après dans toute la partie". C'est un peu l'idée: les choses sont alors rejouables (déterministes), et ça, ce sera très souvent utile à un moment donné (ie: rejouer un scénario où le joueur s'est fait défoncer, pour comprendre pourquoi et ré-équilibrer le gameplay). C'est un peu pareil pour le Doodle Challenge, qu'on peut alors rejouer. Et ça m'a été demandé aussi pour le Thunderbolt generator et pour le planet generator.
On peut me rétorquer que "ouais, c'est pas pareil, c'est pas des jeux", mais à mon sens, la même chose devrait se faire sans problème dans un jeu, à une échelle simplement différente.
En revanche, pendant la partie, c'est là où je doute... Sur Flux, j'ai justement un aléatoire pour placer les villes, les faire apparaitre ou non, ajouter des voitures entre deux villes, etc. Au final, cela crée des parties très chiantes pour certaines, d'autres très difficiles, d'autres trop faciles... Rendre les choses prédictibles pour le serveur, cela simplifie quand même vachement le boulot de création (ce que je ferait dans Flux en créant des scénarios, éventuellement construits à partir de seed puis sélectionnés pour ne retenir que ceux qui sont intéressants/faciles/etc), sans forcément flinguer l'expérience du joueur (ce n'est peut-être pas prédictible du joueur car il n'a pas toutes les informations requises).
Mais bon, après, chacun son jeu.