Jeux et temps réel : Quel philosophie ?

Bonjour,

J'ai été un peu surpris en lisant un exemple de code dans la documentation d'introduction de SFML concernant la gestion du temps dans cette bibliothèque. J'ai une expérience du temps réel, mais pas des jeux, aussi je me demande dans quelle mesure cet exemple est typique ou pas dans ce domaine...

En gros, le code tournait aussi vite que possible, mesurait le temps qu'il avait mis à s'exécuter, et mettait à jour sa simulation en tenant compte d'un pas d'intégration variable.

Le mécanisme que j'ai plus souvent vu en temps réel était de faire tourner le programme à un pas de temps fixe, en s'assurant de ne pas avoir de débordements de temps (ou le moins possible, quitte à simplifier les calculs si on ne tient pas), en faisant attendre le système entre deux pas de temps, et en utilisant un pas de temps fixe dans la simulation.

A priori, je vois les avantages suivants à la première méthode :
- Moins de soucis à gérer les configurations un peu faiblardes.
- Possibilité d'afficher des fps à 4 chiffres dans les benchs

Et les avantages suivants à la seconde :
- La plupart des méthodes d'intégration numérique marchent mieux à pas fixe
- Moins de sollicitation du hard (et donc de la batterie pour du développement sur portable, mais aussi bruit de ventilateurs sur une machine classique, réchauffement climatique...)

Qu'est-ce qui est utilisé généralement dans un jeu de nos jours ?
Question annexe : Y a-t-il généralement une seule boucle, ou bien des boucles par sous-systèmes (affichage, IA, moteur physique...) pouvant donc avoir leur propres rythmes (par exemple, une IA à 10Hz, mais un affichage à 60Hz).

Merci de satisfaire ma curiosité !

Bonjour,

Je trouve ridicule de faire une boucle d'affichage ou une boucle d'IA avec une fréquence supérieur à la fréquence d'affichage ( 60 Hz) et encore...

Pour l'IA je ne pense pas qu'on ai besoin de recalculer ses actions à effectuer plus de 2 à 5 fois par secondes.

Par contre en cas de lags, je pense qu'il faut distinguer deux types de jeux :
- les jeux en lignes ;
- les jeux hors-lignes.

Pour les jeux en lignes, c'est surtout le serveur qui importe, et là on va essayer d'avoir aucun débordement de temps, si on se rapproche trop de la limite, on bloque les nouvelles connexions.

Pour le client en 2D, quelques petits débordements de temps ne devraient pas être bien visible vu qu'il se synchronise régulièrement avec le serveur. Si il y a de trop gros débordements de temps, ce ne sera pas jouable de toute façon.

Après pour la boucle de rendu dans un jeu 3D, on va généralement activer la vsync puis par dessus on calcule certaines positions (ex : caméra) en fonction du temps car on a un temps non-constant qui peut varier assez vite dès qu'on fait de la 3D ( je crois que Irrlicht le fait).

Pour les jeux hors-lignes, je pense qu'il faudrait avoir plus de précision sur le type de jeux et de la boucle qui a un débordement de temps.
Pour un tetris par exemple, je doute qu'on se soucie vraiment d'un débordement de temps.

Pour les boucles, cela va dépendre du jeux, personnellement j'ai une boucle de rendu avec Irrlicht et une boucle avec boost pour tout le réseau et gestion des timers côté client.
Côté serveur principal, j'ai une boucle pour accepter les connexions entrantes et un ensemble de thread pour traiter les données reçues.

Chez moi c'est locké à 60 fps coté client et 100 coté serveur(chiffre totalement arbitraire pour le serveur), mais les calculs se font bien sûr en prenant en compte le temps entre chaque frame.

dans mon moteur de jeu, l'affichage et la physique tournent au même rythme, d'autres composants(mise à jour de certains calculs, ia,...) peuvent tourner à leur propre rythme(soit dans un thread séparé, soit dans la mainloop avec un modulo sur le nombre de frame).

Sur les différents développements professionnels sur lesquels j'ai pu intervenir j'ai toujours vu les calculs en fonction du temps.
Ça n’empêche pas d'avoir un pas fixe, c'est toujours une valeur sur pour avoir un comportement strictement identique pour des replays par exemple.
Enfin oui, les taux de rafraîchissement sont souvent différents suivant les systèmes, par exemple l'ia des boss la plus réactive d'Islands of Wakfu avait un taux de rafraîchissement de 50ms, alors que la plupart des ennemis était de 200ms.

Si vous faites des calculs en fonction du temps, comment vous y prenez vous pour faire de l'intégration numérique ? Vous vous limitez à des méthodes à un pas de temps, ou alors vous connaissez des méthodes à pas de temps multiple où les pas de temps peuvent être fixés arbitrairement ?

Bonjour,

personnellement, j'ai toujours travaillé avec des pas de temps variables pour mes boucles de jeu. Ce pas est égale au temps passé depuis la dernière frame, clampé à l'intervalle [16ms,500ms] (16ms car c'est parfois dans le cahier des charges d'un jeu, et 500ms en cas de lag pour ne pas perturber le joueur). Après je n'ai jamais programmé de jeu en réseau, je ne sais pas comment gérer le temps dans ce cas.

Dans les jeux les plus simples, tous les objets sont mis à jour à la même fréquence, et l'on a rarement besoin d'optimiser la boucle de jeu en ce sens.

Une exception cependant : la physique est TOUJOURS gérée avec un pas de temps fixe, cela pour ne pas perturber la stabilité de la simulation. En effet, si par exemple un ralentissement de 250ms se produit pendant le jeu et que la physique est simulée selon le pas de temps variable, le résultat sera catastrophique. On verra apparaître de nombreux bugs de collisions, le joueur rentrera dans un mur ou pire.

Il n'y a pas de règle absolue, mais une évidence simple : sur les plate-formes au hardware entièrement connu (consoles, certains smartphones), c'est assez facile de travailler avec un pas fixe après avoir décidé du framerate attendu - en général 30 fps, 60 fps est plus rare. La boucle de jeu est donc asservie au framerate...
Sur PC, vue la diversité des configurations, la méthode à pas variable est beaucoup plus souple, même si elle est légèrement plus difficile à implémenter. Ça n'est donc pas vraiment surprenant qu'un moteur "générique" comme SFML le retienne.

Il n'y a pas vraiment de raison de se dire qu'on implémente une boucle à pas de temps fixe pour économiser du temps CPU : un processeur fait forcément quelque chose de toute façon, au pire il exécute un nop ! Si le jeu vidéo avait pour vocation d'économiser de la puissance de calcul, ça se saurait...


En ce qui concerne le réseau je n'y connais pas grand-chose ; en revanche, pour tout le reste (gestion des entrées, physique, etc.) une boucle de jeu qui fonctionne le plus rapidement possible permet d'avoir un jeu réactif ; ça participe énormément au plaisir de jouer.
Et pour ça, il vaut mieux s'affranchir de l'affichage, qui reste le truc qui consomme le plus. Surtout sur consoles, d'ailleurs.
Au passage c'est à mon sens l'une des grosses faiblesses de beaucoup de FPS sur console, et la raison pour laquelle seuls quelques-uns s'en sortent honorablement : ce sont les plus réactifs et ils n'hésitent pas à sacrifier, en qualité d'affichage - en baissant la résolution - au nom de la réactivité.


Cet article est plutôt bien foutu, il débat de plusieurs implémentations. La conclusion à laquelle il parvient : le meilleur compromis reste une boucle de jeu indépendante du framerate ; du coup on se retrouve avec un pas variable, la règle générale est l'interpolation et la prédiction.

Merci pour le lien, je vais lire ça.

Pour l'aspect : Un processeur fait toujours quelque-chose, ce n'est pas vraiment vrai. En fonction de ce qu'on lui demande, il tourne à fréquence variable, et consomme plus ou moins de courant.

Et en terme d'expérience utilisateur, même si je suis d'accord que la réactivité en fait partie, le fait pour un jeu de ne pas trop en demander sans que ça se voit est aussi un plus. Il y a des jeux auxquels j'ai moins de plaisir à jouer à cause du boucan que se mettent à faire mes ventilateurs dès que je le lance, même sur l'écran d'accueil de de menu, allant jusqu'à couvrir les sons d'ambiance du jeu...