Game loop en javascript

[Maks]

Eh bien normalement setInterval devrait donner quelque chose de constant non? Sinon faudrait que j'utilise le delta time et que je rappelle la fonction avec un setTimeOut. ( En espérant que ce dernier marche mieux que setInterval )

Il me semble que RAF est plus constant que setInterval justement (explications à retrouver, une histoire de frame de mémoire). Oui il faut utiliser le deltatime à chaque fois que tu dois incrémenter une variable (les coordonnées d'un joueur par exemple). Pour Box2D je sais pas comment ça se passe, peut être qu'ils ont prévu quelque chose ? Ou alors c'est à toi de t'en occuper avec leur API.

Pour les webworkers, tres bonne idée, donc en gros je ferais tourner le moteur physique dans un thread a part?

Tout à fait, c'est parfait pour les gros calculs. Sur l'exemple que je t'ai donné il utilise ça pour son raycasting. il D'autant plus que si tu utilises WebGL pas de soucis pour utiliser les Web Workers niveau compatibilité donc faut pas t'en priver ^^

Sinon, j'utilise three.js pour ma part, les rendus sont un peu plus long a mon avis. (Meme pour du low poly).
Je n'ai pas pu tester grits car apparement aucun serveur n'est dispo. Mais d'après la video, c'est a peu près le gameplay.

Surtout regarde la vidéo comprendre comment ça marche et le code source, c'est le même cas d'utilisation que toi : WebGL, websockets et moteur 2D
Dans la vidéo ils donnent vraiment des astuces indispensables pour ce genre de jeu assez ambitieux (la 3D + collisions = beaucoup plus de problèmes à gérer ^^)

pour le fiddle ca risque d'etre compliqué, mais pour le moment, ca peut être accessible sur http://213.251.147.29/ si on a lancé le serveur
(id: visiteur1 mdp: visiteur) Si ca se connecte pas, essayez avec visiteur2

J'ai essayé c'est un bon début j'aime bien les robots Mais sinon ça saccade un peu en effet

Questions en vracs:
Replacer un joueur toutes les 200ms ne serait pas déja suffisant? (a 32 ms il y aurait pratiquement meme pas besoin de moteur physique coté client).

Sur BuildNewGames, va sur l'article Realtime Multiplayer HTML5 il donne les fréquences exactes (45 ms je crois, je suis plus sur). Mais 200ms ça sera beaucoup trop long à cause des collisions des attaques par exemple.

Tes packets ressembleront à ça avec un moteur 2D :

var state = [{

id: 0,

transform: {

position: {

x: 15.290663048624992,

y: 2.0000000004989023,

z: -24.90756910131313

},

rotation: {

x: 0.32514392007855847,

y: -0.8798439564294107,

z: 0.32514392007855847,

w: 0.12015604357058937

}

}

}, {

id: 1,

transform: {

position: {

x: 7.490254936274141,

y: 2.0000000004989023,

z: -14.188117316225544

},

rotation: {

x: 0,

y: 0.018308020720336753,

z: 0.1830802072033675,

w: 0.9829274917854702

}

}

}];

(à optimiser bien sur)

Tu préconise une seule boucle (calcul physique et affichage dans la meme?) ? Donc du séquentiel plutôt que du parallèle, pourquoi?

Si tu fais deux timers, ils ne s’exécuteront pas en parallèle, ils s'exécuteront à la suite après avoir été pushé dans la queue des events, c'est dans la nature de JS. C'est la même chose pour tes calculs, ils ne s’exécuteront pas en parallèle, il faut que tu utilises les web workers