26-02-2013, 09:01 PM
Salut,
J'ai eu une nouvelle idée de jeu il y a quelques jour, je suis pas encore décidé si je lui donne suite (déjà 2 autres idées en attente, et un autre projet à finir). Mais bon pour l'instant je suis en phase de réflexion, et j'ai quelques petites question techniques.
Le contexte, en simplifiant :
- Le jeu se déroule sur une carte à cases hexagonales.
- Chaque joueur dispose d'unités "customisées" (différentes de celles des autres joueurs).
- Chaque case peut contenir des unités de plusieurs joueurs en même temps.
- Ces unités combattent, sont produites et se déplacent vers d'autres cases "automatiquement" à chaque tour (en fonction des ordres que le joueur a donné).
- Les tours sont courts (c'est pas encore fixé mais ça sera moins d'une heure, voir seulement quelques minutes si les performances suivent). Bien sur pour cette durée on demande pas au joueur de se connecter à chaque tour, il donne des ordres qui sont suivis à chaque tour jusqu'à ce qui les change.
Par exemple :
-Il y a 20 unités du joueur A sur une case donnée (et X du joueur 2, Y du joueur 3 etc.).
-Elles combattent et 7 meurent (je détaillerais pas l'algo derrière ici, sachez juste qu'il nécessite de récupérer les stats de l'unité dans la bdd) => 13 unités
-3 sont produites => 16 unités
-Le joueur a donné l'ordre aux unités de cette case d'aller au Nord, 6 y vont => 10 unités
-3 arrivent du sud et 5 du nord-est => 18
-On recommence au tour suivant.
C'est le changement de tour qui me pose problème, la méthode bourrine consisterais à lancer un script à chaque changement de tour, cependant le script prendra du temps (compter quelques milliers à quelques dizaines de millier de cases, un algo de combat pas forcément très gourmand en ressources mais répété autant de fois que de cases, et la nécessité de charger toutes les infos de la base de donnée : nombre d'unité par cases, statistiques des unités, ordres de déplacement...).
Du coup avec cette méthode bourrine, le temps que le script tourne le serveur sera indisponible. Seulement, avec des tours qui se veulent court, il n'y a pas possibilité de faire le changement à 4h du mat et de déconnecter tous les joueurs présents.
Mon idée pour contourner le problème serait de calculer l'état du tour N+1 pendant le tour N, et non d'attendre la fin du tour. Ainsi on aurais deux fois l'état du serveur dans la base de donnée, une fois l'état actuel, et une fois l'état au tour suivant. Et au changement de tour il n'y a qu'à switcher d'un état à l'autre. En gros ça se déroulerais comme ça :
-Début du tour N, les joueurs voient "l'état du serveur à t=N."
-On calcule les résultats des combats/production qu'il va y avoir lors de la transition tour N=>tour N+1, on écrit dans la base de donnée "l'état du serveur à t=N+1."
-Si un joueur change un ordre (de déplacement) d'une case déjà calculée, on met à jour "l'état du serveur à t=N+1." en conséquence.
-Le tour N se termine, lorsque les visiteurs rechargeront la page ils verront "l'état du serveur à t=N+1."
Voilà où en est ma réflexion actuellement. Mes questions :
-Voyez vous une meilleure manière de faire?
-Auriez vous des conseils sur les technologies à utiliser (ou ressources/tutos qui traitent un problème similaire)? Par exemple, comment éviter de saturer la Bdd? Comment "lisser" et optimiser l'utilisation des ressources serveurs de manière à éviter des lags côté client (en lançant plusieurs processus? en mettant des taches en attente? ce genre de choses...)? J'avoue avoir de très vagues idées de ce qu'il est possible de faire, mais vraiment vagues.
J'ai eu une nouvelle idée de jeu il y a quelques jour, je suis pas encore décidé si je lui donne suite (déjà 2 autres idées en attente, et un autre projet à finir). Mais bon pour l'instant je suis en phase de réflexion, et j'ai quelques petites question techniques.
Le contexte, en simplifiant :
- Le jeu se déroule sur une carte à cases hexagonales.
- Chaque joueur dispose d'unités "customisées" (différentes de celles des autres joueurs).
- Chaque case peut contenir des unités de plusieurs joueurs en même temps.
- Ces unités combattent, sont produites et se déplacent vers d'autres cases "automatiquement" à chaque tour (en fonction des ordres que le joueur a donné).
- Les tours sont courts (c'est pas encore fixé mais ça sera moins d'une heure, voir seulement quelques minutes si les performances suivent). Bien sur pour cette durée on demande pas au joueur de se connecter à chaque tour, il donne des ordres qui sont suivis à chaque tour jusqu'à ce qui les change.
Par exemple :
-Il y a 20 unités du joueur A sur une case donnée (et X du joueur 2, Y du joueur 3 etc.).
-Elles combattent et 7 meurent (je détaillerais pas l'algo derrière ici, sachez juste qu'il nécessite de récupérer les stats de l'unité dans la bdd) => 13 unités
-3 sont produites => 16 unités
-Le joueur a donné l'ordre aux unités de cette case d'aller au Nord, 6 y vont => 10 unités
-3 arrivent du sud et 5 du nord-est => 18
-On recommence au tour suivant.
C'est le changement de tour qui me pose problème, la méthode bourrine consisterais à lancer un script à chaque changement de tour, cependant le script prendra du temps (compter quelques milliers à quelques dizaines de millier de cases, un algo de combat pas forcément très gourmand en ressources mais répété autant de fois que de cases, et la nécessité de charger toutes les infos de la base de donnée : nombre d'unité par cases, statistiques des unités, ordres de déplacement...).
Du coup avec cette méthode bourrine, le temps que le script tourne le serveur sera indisponible. Seulement, avec des tours qui se veulent court, il n'y a pas possibilité de faire le changement à 4h du mat et de déconnecter tous les joueurs présents.
Mon idée pour contourner le problème serait de calculer l'état du tour N+1 pendant le tour N, et non d'attendre la fin du tour. Ainsi on aurais deux fois l'état du serveur dans la base de donnée, une fois l'état actuel, et une fois l'état au tour suivant. Et au changement de tour il n'y a qu'à switcher d'un état à l'autre. En gros ça se déroulerais comme ça :
-Début du tour N, les joueurs voient "l'état du serveur à t=N."
-On calcule les résultats des combats/production qu'il va y avoir lors de la transition tour N=>tour N+1, on écrit dans la base de donnée "l'état du serveur à t=N+1."
-Si un joueur change un ordre (de déplacement) d'une case déjà calculée, on met à jour "l'état du serveur à t=N+1." en conséquence.
-Le tour N se termine, lorsque les visiteurs rechargeront la page ils verront "l'état du serveur à t=N+1."
Voilà où en est ma réflexion actuellement. Mes questions :
-Voyez vous une meilleure manière de faire?
-Auriez vous des conseils sur les technologies à utiliser (ou ressources/tutos qui traitent un problème similaire)? Par exemple, comment éviter de saturer la Bdd? Comment "lisser" et optimiser l'utilisation des ressources serveurs de manière à éviter des lags côté client (en lançant plusieurs processus? en mettant des taches en attente? ce genre de choses...)? J'avoue avoir de très vagues idées de ce qu'il est possible de faire, mais vraiment vagues.
