25-11-2015, 10:50 AM
Je ne comprends toujours pas comment tu veux faire ta fonction de calcul du monde sans lui transmettre d'information sur la durée réelle de tes ticks. Si ta fonction de calcul de l'univers de jeu veux déplacer un objet, elle va se baser sur sa vitesse. Si t'as pas la durée écoulée depuis le dernier déplacement, tu vas coincer.
Soit t'as un X = x0 + dt * v et donc là, je ne vois pas pourquoi passer un dt constant (dt=1tick) ou un dt variable (dt=durée écoulée depuis le dernier calcul) te gène/augmente la complexité.
Soit t'as un X = x0 + dv et donc là, si tu changes la durée d'un tick/ta valeur de setInterval, le jeu accélèrera/ralentira (car la timeline du jeu se base sur les ticks, donc si la conversion tick/temps réel change, le jeu accélère ou ralentit).
Et pour l'avoir fait sur Eclerd, je te garantis qu'un système de "tick fixe" est bien trop rigide dans le temps: sur Eclerd, la date de jeu est calculée par DateInGame = DateJeu0 + K*(DateReelleActuelle - DateReelle0), avec DateJeu0 la date du jeu à son ouverture (j'ai pris 1er Janv 2000), DateReelle0 la date réelle d'ouverture du jeu (admettons, 14 Sept 2011), DateRelleActuelle la date courante (25/11/2015 aujourd'hui) et K un facteur de vitesse.
Conséquence? K ne peut plus être modifié. Si j'augmente K, le jeu fait un bond dans le temps d'un coup. Si je le réduis, il part dans le passé. Je te laisse imaginer les impacts sur le vieillissement de la population et les calculs de production.
A mon avis, tu vas te retrouver dans un cas similaire si ta timeline est à base de ticks (changer la durée d'un tick en cours de partie aura de beaux effets collatéraux [parce que j'aime pas "effet de bord"]).
Soit t'as un X = x0 + dt * v et donc là, je ne vois pas pourquoi passer un dt constant (dt=1tick) ou un dt variable (dt=durée écoulée depuis le dernier calcul) te gène/augmente la complexité.
Soit t'as un X = x0 + dv et donc là, si tu changes la durée d'un tick/ta valeur de setInterval, le jeu accélèrera/ralentira (car la timeline du jeu se base sur les ticks, donc si la conversion tick/temps réel change, le jeu accélère ou ralentit).
Et pour l'avoir fait sur Eclerd, je te garantis qu'un système de "tick fixe" est bien trop rigide dans le temps: sur Eclerd, la date de jeu est calculée par DateInGame = DateJeu0 + K*(DateReelleActuelle - DateReelle0), avec DateJeu0 la date du jeu à son ouverture (j'ai pris 1er Janv 2000), DateReelle0 la date réelle d'ouverture du jeu (admettons, 14 Sept 2011), DateRelleActuelle la date courante (25/11/2015 aujourd'hui) et K un facteur de vitesse.
Conséquence? K ne peut plus être modifié. Si j'augmente K, le jeu fait un bond dans le temps d'un coup. Si je le réduis, il part dans le passé. Je te laisse imaginer les impacts sur le vieillissement de la population et les calculs de production.
A mon avis, tu vas te retrouver dans un cas similaire si ta timeline est à base de ticks (changer la durée d'un tick en cours de partie aura de beaux effets collatéraux [parce que j'aime pas "effet de bord"]).