Discussion :

[LittleWhite]

Bonjour à tous,

J'ai remarqué que certains nouveaux programmeurs (nouveaux dans le domaine du jeu vidéo) ne comprenait pas toujours ce qu'est la boucle de jeu. Ainsi, j'ai voulu faire le point pour poser cette base de la programmation d'un jeu.

Bonne lecture.

[LandReagan]

Salut,

Excellent tutoriel, simple et très bien expliqué!

Pour aller (un peu) plus loin : http://gameprogrammingpatterns.com/game-loop.html

[CodeurPlusPlus]

Ah ben du coup j'ai lu les deux. Ils sont très bien.

[jwar0]

Merci pour ce cours.
J'étais resté à la programmation grand papy ou tout le monde possède la même machine, sans prendre en compte la disparité des configs.
Du coup je viens de réaliser certaines choses

[Guildem]

Merci pour cet article intéressant !

Juste une remarque : dans les bout de pseudo code, dommage qu'il y ait du mélange français/anglais ("tempsDebut = time()" par exemple) et des fautes de français ("aCliquerSurLaCroixRouge()" qui doit se lire je pense "à cliqué sur la croix rouge").

[Kropernic]

Hello,

Merci pour l'article, c'est intéressant. Je m'étais essayé à XNA il y a quelques temps pour découvrir la programmation de jeux en tentant de faire un genre de candy crush et ça m'aurait bien aider d'avoir ça à l'époque.

Sinon, j'ai relevé ceci :

Si tout va bien, notre boucle de jeu s'exécute 60 fois par seconde. Donc la position en X de l'élément se sera déplacée de 60 * vitesse en une seconde. Cela est totalement convenable lorsque « tout va bien ». Mais si, pour une raison ou une autre, le programme ralentit, nous ne sommes plus sûrs de toujours avoir 60 images par seconde. Si on tombe à 30 images par seconde, en une seconde notre élément se sera déplacé de 30 * vitesse. Le déplacement aura été deux fois moins lent.

Ce ne serait pas deux fois plus lent par hasard ? Ou alors il y a encore quelque chose qui échappe au novice que je suis.

[Ikrial]

Bonjour,

Je suis en train de m'intéresser au développement de jeux vidéo justement en ce moment, notamment à Unity étant développeur C#, et cet article m'a beaucoup plu, il est clair et complet à la fois.

Petite question : y'en a-t-il d'autres de prévu du même style, sur des points précis de développement de jeux ?

Merci en tout cas.

[LittleWhite]

Merci à tous pour vos retours !

Juste une remarque : dans les bout de pseudo code, dommage qu'il y ait du mélange français/anglais ("tempsDebut = time()" par exemple) et des fautes de français ("aCliquerSurLaCroixRouge()" qui doit se lire je pense "à cliqué sur la croix rouge").

C'est corrigé. Par contre, pour la fonction time() (et delay()), je les laisse en anglais car ce sont des fonctions provenant des bibliothèques que l'on utile. Les fonctions en français sont celles que l'on doit surement faire nous-même. Sachant que time() est une fonction qui existe vraiment sous Linux et qui fait relativement la même chose que ce que nous espérons dans le tutoriel et delay() se réfère à SDL_Delay() par exemple (pour la SDL).

Cela permet de simplifier la recherche dans une documentation, je pense.

Ce ne serait pas deux fois plus lent par hasard ? Ou alors il y a encore quelque chose qui échappe au novice que je suis.

En effet, j'ai du inversé ma logique en cours de route. Corrigé

Petite question : y'en a-t-il d'autres de prévu du même style, sur des points précis de développement de jeux ?

Oui, je compte faire une petite série dans ce style. Malheureusement, je ne peux pas prévoir quand. Mais j'aimerai bien poser toutes les bases de la construction d'un jeu (si possible indépendamment du langage ou de la bibliothèque).

[Ikrial]

C'est parfait merci, et bon courage !

[codec_abc]

Tutoriel sympa pour les débutants mais qui peut véhiculer des idées pas forcément judicieuses.

Je m'explique :

1-Les différents pseudo-codes imposent que le rendu et la mise à jour des modèles du jeu soient purement séquentiel. Une petite remarque comme quoi le rendu peut être fait en parallèle de la mise à jour du modèle serait la bienvenue.

2-La partie "Avoir la même vitesse de jeu sur toutes les machines" me pose problème. Elle donne l'exemple d'un calcul de physique qui est pour moi problématique. En gros, l'idée est de faire du calcul intégral (ça fait sérieux dit comme ça) pour mettre à jour le modèle physique (qui est ici vraiment basique). Dans l'exemple, le pas d'intégration est variable, or d'expérience les simulations physiques avec des pas d'intégrations variables donnent des résultats non reproductible et aussi moins stable. Pour ceux qui veulent un peu plus de détail il y a un post sur gamedev.stackexchange qui aborde le sujet. De plus, dans l'approche proposé la physique est couplé au framerate ce qui est généralement déconseillé.

Bon je critique, mais au fond j'apprécie l'initiative

[Kannagi]

2-La partie "Avoir la même vitesse de jeu sur toutes les machines" me pose problème. Elle donne l'exemple d'un calcul de physique qui est pour moi problématique. En gros, l'idée est de faire du calcul intégral (ça fait sérieux dit comme ça) pour mettre à jour le modèle physique (qui est ici vraiment basique). Dans l'exemple, le pas d'intégration est variable, or d'expérience les simulations physiques avec des pas d'intégrations variables donnent des résultats non reproductible et aussi moins stable. Pour ceux qui veulent un peu plus de détail il y a un post sur gamedev.stackexchange qui aborde le sujet. De plus, dans l'approche proposé la physique est couplé au framerate ce qui est généralement déconseillé.

Je suis assez d'accord , mais il est ou courant vu que c'est ce que je lui est dit mais apparemment il tenait absolument a cette méthode que je trouve complétement inutile dans notre cas et que difficile a mettre en place surtout qu'il faudrait faire l'implémentation partout ou il dépendrait du framerate (comme l'animation en général) , et que ce tutoriel s'adresse a un débutant donc avant qu'il met un CPU a genou.
Pour ma part je pousserait plus a faire une optimisation au programmeur pour garantir une framerate constant que d'essayé ce genre de méthode.

[LittleWhite]

@codec_abc :
Entièrement d'accord avec vous. Pour votre premier point, je ne veux pas rentrer dans le cas du multithread (qui est pointé dans les points supplémentaires à approfondir si on veut aller plus loin), car ce n'est pas un truc de débutant.
Pour le second point, je suis aussi d'accord avec vous. Le moteur physique est un truc aussi qui n'est pas de débutant et personnellement, si je commence à m'occuper d'un moteur physique, je vais aussi commencer à utiliser un vrai moteur de jeux (Unity/Godot/Unreal Engine...). Mais ça, c'est mon avis personnel.

Dans ce tutoriel, je n'ai pas cherché à être exhaustif (contrairement au lien donné au-dessus), notamment en prenant le partie de vouloir faire un truc simple et plus orienté pour ceux qui veulent faire des jeux simples.
J'espère, par la suite, que la rubrique accueillera un tutoriel un peu plus complet, pour compléter cette "introduction" si on peux dire.

Après, comme j'en ai déjà discuté avec Kannagi, je suppose (pour mes développements) qu'il est impossible d'assurer à 100 % un framerate stable. Il suffit d'avoir Windows

[Kannagi]

Après, comme j'en ai déjà discuté avec Kannagi, je suppose (pour mes développements) qu'il est impossible d'assurer à 100 % un framerate stable. Il suffit d'avoir Windows

Ce cas est relativement rare pour ne pas le prendre comme généralité ou meme le prendre on compte , sur Windows je n'ai pas vu de FPS qui change (pour mes développements ,oui a la limite de 1 fps des fois) , et je suis sur que personne ne vois la différence entre une version Windows et Linux en terme de framerate.

[LittleWhite]

Votre PC est un cas unique. Le problème, c'est lorsque le ralentissement il arrive. Chez moi, tous les jeux sont ralentis au moins une fois par semaine : Windows Update (souvent), des fois, ce sont mêmes pour des raisons inconnus.
Et puis, le ralentissement peut être provoqué pour tricher. Un bon touhou (shoot em up) dans Wine, est bien plus facile, que sous Windows

[MoDDiB]

Il y a pas mal de trucs qui me dérangent mais avant tout ceci :

delay(16 - (tempsFin - tempsDebut))

delay c'est bien une référence à la fonction sleep sur windows ? Car dans ce cas on n'attend pas (16 - (tempsFin - tempsDebut)) ms
mais au minimum 16 - (tempsFin - tempsDebut) et ça change beaucoup.....

[LittleWhite]

Sleep() ou tout autre fonction. Cela dépend du système.
Toutefois, toutes les fonctions de sleep() ont une attente au minimum du temps indiqué (ce qui est logique). On pourrait aussi récupérer le temps vraiment attendu afin de faire en sorte de le comptabiliser dans la boucle.

Il y a pas mal de trucs qui me dérangent

Je serai bien heureux de les entendre.

[Sodium]

Tutorial intéressant, par contre je pense qu'il aurait été utilise de mentionner que l'on ne va généralement pas utiliser une boucle while pour la boucle d'un jeu.
Généralement, les moteurs de jeu ont une fonction bien spécifique appelée au rafraîchissement de l'image. Ne pas utiliser celle-ci peut sérieusement nuire aux performances. En javascript par exemple on utiliser plutôt la fonction "requestanimationframe" qui est appelée à chaque mise à jour l'affichage, permettant ainsi au système de ne pas gaspiller de ressources en effectuant des calculs plus souvent que nécessaire.

[LittleWhite]

La boucle while() existe bel et bien, sauf que dans les moteurs de jeux vidéos elle n'est pas accessible. Par contre, dans les moteurs de jeux vidéo, on vous propose juste de remplir les méthodes render() et update(), qui seront appelées dans la boucle while().
Je suppose qu'il en est de même pour la fonction requestanimationframe() (qui correspond à render()). Enfin, c'est mon hypothèse.

[alves1993]

Excellent tutoriel pour un ultra-débutant comme moi dans le domaine du développement de jeux vidéo

Vraiment Merci pour ce tuto .

[codec_abc]

@codec_abc :
Entièrement d'accord avec vous. Pour votre premier point, je ne veux pas rentrer dans le cas du multithread (qui est pointé dans les points supplémentaires à approfondir si on veut aller plus loin), car ce n'est pas un truc de débutant.

Je suis passé à coté de la remarque donc je retire ma critique sur le point 1.

Pour le second point, je suis aussi d'accord avec vous. Le moteur physique est un truc aussi qui n'est pas de débutant et personnellement, si je commence à m'occuper d'un moteur physique, je vais aussi commencer à utiliser un vrai moteur de jeux (Unity/Godot/Unreal Engine...). Mais ça, c'est mon avis personnel.

Dans ce tutoriel, je n'ai pas cherché à être exhaustif (contrairement au lien donné au-dessus), notamment en prenant le partie de vouloir faire un truc simple et plus orienté pour ceux qui veulent faire des jeux simples.
J'espère, par la suite, que la rubrique accueillera un tutoriel un peu plus complet, pour compléter cette "introduction" si on peux dire.

Après, comme j'en ai déjà discuté avec Kannagi, je suppose (pour mes développements) qu'il est impossible d'assurer à 100 % un framerate stable. Il suffit d'avoir Windows

Je ne suis qu'à moitié d'accord. La volonté de faire un tutoriel simple me parait une très bonne chose. Il est souhaitable de ne pas surcharger les débutants d'informations sinon on risque de les perdre et au final cela s’avère peu constructif. Mais (oui il y a toujours un mais) que l'on prône une approche simple (ou pas) il me parait judicieux de donner quelques informations sur les limites de l'approche choisi. Sinon, on risque de véhiculer l'idée que cette approche est parfaite et qu'il n'y a pas de raison de faire autrement. Or c'est faux, en informatique il y a rarement une approche parfaite pour résoudre un problème dès que celui devient un tant soit peu complexe.