Boucle & tick coté server NodeJS?

[Ter Rowan]

@Ter Rowan: c'est ce que je pensais faire, mais il y avait des cas type "je cherche une date dans le passé ayant uniquement la date réelle en BDD", donc une fois le changement K effectué, la date IG passée correspondant à la date réelle passée n'est plus la même. Ayant l'hypothèse cachée "K ne changera pas", ces algos qui regardent le passé étaient fonctionnel. Mais du coup, K ne peux implicitement pas changer.

Sans compter que je perdais des infos comme la durée totale de jeu (réelle ou ingame, puisque les dates 0 ont changées), et il me semble qu'elle servait ailleurs...
[/quote]

bah dans ce cas la tu fais une table d'historique de ces 3 variables (data 0 etc...), et modifies les méthodes de calcul enfin tu es assez malin pour résoudre le truc si tu le souhaites :p

[Xenos]

Oui, le problème est solvable, mais il entraine des modifications un peu partout dans le code. C'est justement pour cela qu'on (parce que je n'ai pas l'air d'être le seul) dit qu'avoir une variable Dt dans la méthode de simulation, qui peut prendre une valeur quelconque, sera plus robuste dans le temps que de rester sur un système de tick élémentaire et constant.

Après, j'ai tout refondu pour faire plus méthodique et supprimer toutes ces "tentacules" qui trainent un peu partout dans mon mauvais code procédural...

[Argorate]

Mais c'est pas du tout la même conception, c'est ce que j’essaie de faire passer comme message^^

Dans le cas où vous passer à la boucle un delta t qui correspond au temps réel écoulé et faite les calcules, ça signifie que vous essayez de calquer le temps réel de l'univers à votre jeu.

Dans la conception que j'avance, c'est pas du tout ça. L'univers du jeu n'est pas vraiment en temps réel, on associe arbitrairement un nombre "d’arrêt sur image", de tick, pour chaque seconde. Et en dehors de ces instants, l'univers du jeu n'existe pas. C'est fondamentalement différent !
On décompose l'univers et le temps du jeu en plusieurs frame static, mais qu'on anime vite les une à la suite des autres, un peu comme les dessins au bords des pages d'un livre, qu'on fait ensuite défiler pour faire l'illusion d'un film, il s'agit un peu de la même chose pour simuler le temps réel...

Je sais pas si ça passe mieux, expliqué ainsi?

[niahoo]

Non, le delta time ça sert juste à dire "j'ai un tick toutes les X millisecondes, le dernier tick à pris moins de X ms donc j'attend Yms avant de commencer le tick suivant" afin d'avoir un écart constant sans utiliser setInterval.

Mais faire ça t'oblige à implémenter d'une certaine manière. Et cette manière te force à utiliser des coefficients pour tes calculs (par exemple distance parcourue par tick), ce qui te permet facilement de changer à volonté la durée de chaque tick mais également de changer ces coefficients.

En soi, utiliser un delta n'a rien à voir avec le "vrai" temps. C'est juste un moyen d'être à la fois souple et d'avoir des ticks réguliers sans erreurs.

Edit : Et ça colle parfaitement à ce que tu veux faire.

Hmmm par contre faut vraiment expliquer plus pourquoi tu veux que de l'affichage côté client soit géré par des ticks côté serveur ... le tout via TCP/IP ...

[Xenos]

Donc toute ta timeline ingame est en "ticks" (genre, vitesses en XXX/tick et accélérations en XXX/ticks² au lieu de XXX/sec et XXX/sec²). Quand tu va vouloirs passer de 30 à 100 ticks/secondes (ou le contraire), ça va se passer comment?

[Argorate]

@niahoo : je comprends, mais il n'y a pas besoin du delta pour faire ça. Rien empêche de faire un système avec un boolean dans le setInterval qui assure que si un tick n'a pas fini dans le temps imparti, on ne lance pas le suivant, et lancer le suivant à la fin du tick en cours en espérant qu'il rattrape le retard pour le tick suivant (si ce n'est toujours pas le cas, le même procédé aura lieu).

@xenos: et bien tout sera augmenter, puisque tu augmentes le nombres de tick. Donc il semble peu judicieux de passer de 30 à 100, ça n'a pas de sens. Mais si vraiment tu devais le faire, le jeu irait plus vite, et si tu veux le ralentir sans ralentir le nombre de tick (pourquoi?!), tu es obligé de diminuer les valeurs de vitesses. Mais je pense pas que ça soit une bonne chose de s'amuser à ça du coup...

[Xenos]

Bon, admettons. Perso, il me semble que si ton univers est en XXX/ticks, cela finira par te coincer; en XXX/sec me semble plus judicieux puisque le jeu est quand même lié au temps réel. D'autant que le scénario de Sephi me semble très probable: 60ticks/secondes sera peut-être idéal au début avec peu de monde, puis tu passeras à 30 puis 20 pour pouvoir tenir la charge.


Je serai curieux de voir comment tu implémentes ton boolean, il me semble plus complexe que le

Code :

var DT = ...;
function looping() {
  var t0 = (new Date()).getTime();
  simulate();
  var dt = DT - ((new Date()).getTime() - t0);
  setTimeout(looping, dt);
}

D'ailleurs, je ne vois pas comment tu fais cela avec un booleen... Un int comptant les ticks ratés, peut-être...

[Argorate]

C'est très simple :

Code :

function tick()
{
    if(app.tick_in_progress) return;
    app.tick_in_progress = true;

    //traitement...

    app.tick_in_progress = false;
}

Pour ce qui est de lancer le tick en cas de dépassement, c'est tout aussi simple, il suffit que le setInterval intérompu mette une autre variable à true, pour signaler qu'un tick aurait du se lancer et qu'il n'a pas pu, et du coup ajouter le lancement à la fin du tick en cours :

Code :

function tick()
{
    if(app.tick_in_progress) return false;
    app.tick_in_progress = true;
    app.tick_missed      = false;

    //traitement...

    app.tick_in_progress = false;
}

function main()
{
   if(!tick()) app.tick_missed = true;
   else if(app.tick_missed) setImediate(tick);
 }

setInterval(function(){
   main();
}, 30);

Mais bon, ça c'est le détails technique pour traiter un cas qui n'est pas supposé arrivé. Donc il faut le faire car il faut traité le cas, au cas où... mais il ne faut pas le légitimé en le prenant en compte comme si c'était normal.

[niahoo]

T'es au courant que toutes les opérations I/O sont asynchrones en javascript ? Là ça ne va pas du tout ...

[Xenos]

Tu peux rater plus d'un tick, genre une dizaine à cause d'une latence réseau type connexion à la DB. Moi, la présence d'un objet global "app" me déplait, ça sépare la logique de ce qu'on veut faire en deux (à un endroit, on définit le app.* et à un autre, on s'en sert). Bon, c'est pas la mort, mais j'aime bien éviter ce genre de chose.



Je pousse un peu pour la beauté de la question: est-il possible que deux tick() soient lancés en même temps, que le gardien "if (...) return;" soit exécuté sur l'un puis sur l'autre et qu'enfin seulement, le tick_in_progress soit définit à true? Ce qui ferait que le contenu des 2 ticks s'exécuterait en parallèle.

Autrement demandé: si setInterval() est parallèle (ce qui me semble être le cas), un gardien "if" comme celui-là protège-t-il à 100% de l'exécution de deux tick() en parallèle?

---

Je crois que Niahoo vient de répondre ^^