Salut,
il te faut établir 2 lignes de temps dans ta conception: une qui est le temps de jeu, et sur laquelle tu base tous tes calculs de jeu, et une autre sur le temps réel. Tu n'auras alors plus qu'à établir la relation entre les deux échelles de temps, ici "TempsJeu = 60*(TempsRéel - TempsRéelInitial) + TempsJeuInitial".
Coté réalisation, cela signifie le remplacement de toutes les dates réelles par un "timestamp dans la timeline du jeu" (UNSIGNED INT), qui démarre à la même origine que le timestamp réel (plus simple dans le calcul car cela revient à dire TempsRéelInitial = TempsJeuInitial = 0) ou non (plus souple à l'usage). Ces dates seront donc dans le "calendrier du jeu", que tu pourras convertir en temps réel si besoin.
Pour l'avancement du temps, même principe: connaissant NOW (le temps réel actuel), tu appliques la relation de calcul inverse pour trouver le temps de jeu correspondant, et tu l'utilises dans tes formules de jeu.
Toutefois, pour un moindre impact sur l'existant (vu que tu as déjà de l'existant), il peut être plus rentable de faire le contraire: tu conserves ta façon actuelle de stocker les dates et timestamp (donc, tu continues à stocker du timestamp réel et des dates réelles), mais avant leur utilisation dans tes formules de jeu (ou avant leur affichage à l'écran), tu les convertis en "dates de jeu", via la simple formule "DateDeJeu = 60*(DateStockéeRéelle - DateRéelleInitiale) + DateDeJeuInitiale".
>> A y réfléchir, cela me semble en fait le plus simple et efficace, et c'est d'ailleurs ce que j'avais fait sur Isometry
il te faut établir 2 lignes de temps dans ta conception: une qui est le temps de jeu, et sur laquelle tu base tous tes calculs de jeu, et une autre sur le temps réel. Tu n'auras alors plus qu'à établir la relation entre les deux échelles de temps, ici "TempsJeu = 60*(TempsRéel - TempsRéelInitial) + TempsJeuInitial".
Coté réalisation, cela signifie le remplacement de toutes les dates réelles par un "timestamp dans la timeline du jeu" (UNSIGNED INT), qui démarre à la même origine que le timestamp réel (plus simple dans le calcul car cela revient à dire TempsRéelInitial = TempsJeuInitial = 0) ou non (plus souple à l'usage). Ces dates seront donc dans le "calendrier du jeu", que tu pourras convertir en temps réel si besoin.
Pour l'avancement du temps, même principe: connaissant NOW (le temps réel actuel), tu appliques la relation de calcul inverse pour trouver le temps de jeu correspondant, et tu l'utilises dans tes formules de jeu.
Toutefois, pour un moindre impact sur l'existant (vu que tu as déjà de l'existant), il peut être plus rentable de faire le contraire: tu conserves ta façon actuelle de stocker les dates et timestamp (donc, tu continues à stocker du timestamp réel et des dates réelles), mais avant leur utilisation dans tes formules de jeu (ou avant leur affichage à l'écran), tu les convertis en "dates de jeu", via la simple formule "DateDeJeu = 60*(DateStockéeRéelle - DateRéelleInitiale) + DateDeJeuInitiale".
>> A y réfléchir, cela me semble en fait le plus simple et efficace, et c'est d'ailleurs ce que j'avais fait sur Isometry