Discussion :

[kelepoc]

Bonjour à tous.
Je ne pense pas poster dans la bonne section, mais je n'en ai pas vraiment trouvé de plus appropriée.
Alors voila. Ca fait un petit moment que je code quelques jeux et applications par-ci par-la, mais j'envisage maintenant de coder un petit moteur pour ensuite coder un RTS simpliste (expérience personnelle).
Cependant je me pose quelques questions:

1) Concernant les threads.
Admettons que plusieurs batiments soient construits, chaque batiment doit gérer une file d'attente pour la création d'unités par exemple. En plus de ca, plusieurs unitées sont crées, chacune suivant son chemin. Comment gérer tout ca? Suis-je obligé de créer un thread pour chaque batiment, unité, etc.. ?

2) Concernant la gestion de la map.
Comment est réalisé le scrolling de la map ? Est-elle chargée en mémoire, puis affichée petit à petit? ou est-elle chargée au fur et a mesure?

Je crois que c'est à peu près tout pour mes questions.
Merci d'avance pour vos réponses.
Cordialement,
Baptiste.

[nikko34]

Pour ton exemple, je ne pense pas qu'il y ait de threads spécifiques pour chaque action qui devrait avoir lieu en parallèle.

Je pense qu'il y a un thread général qui gère l'avancée du temps, et chaque fois que cette horloge avance, elle prévient tous les éléments et ils font ce qu'ils ont besoin de faire.

Pour la Map, c'est l'API graphique qui gère l'affichage, par contre le moteur du jeu lui connait la map entière et ce qu'il s'y passe

[Klaim]

1) A la base, tu n'as pas besoin de threads pour ça. Ton jeu est rythmé par un "tick", un moment régulier où l'état du jeu est mis à jour. A partir de là, tu peux incrémenter les temps de construction a chaque tick par exemple.

2) Ca dépends totalement de ton jeu. Mais que ce soit en 2D ou en 3D, il y a toujours du partitionnement de l'espace graphique mis en place pour avoir un minimum de données graphiques a envoyer à la carte graphique selon ce qu'il y a dans le frustum de la caméra.

edit> J'ajoute que les API graphiques de base (Direct3D et OpenGL) ne font pas ce partitionnement de l'espace. C'est à toi de le faire, adapté à ton jeu. Ou alors tu utilises un moteur graphique comme Ogre3D et dans ce cas il y a des scene manager déjà pret. La plupart du temps ça sera suffisant mais parfois (un jeu de course par exemple) un scene manager spécialisé pour ton jeu peut être beaucoup plus efficace.

[Mac LAK]

Pour le "tick", tu as deux solutions principales :

• Un tick fixe (ex : toutes les 30 ms), qui va forcément cadencer les FPS réelles du jeu.
  Le problème majeur est qu'en cas de charge ponctuelle, tu vas avoir un gros freeze.
  
  
• Un tick adaptatif, qui s'exécute à intervalles variables tout en se basant sur une horloge système pour obtenir une base temporelle. Dans ce cas, si tu as de la puissance supplémentaire disponible, tu peux peaufiner l'affichage (effets, animations, etc.) de façon à avoir un jeu plus beau. Tu peux ainsi également augmenter les FPS du jeu.
  
  Dans ce cas, l'idéal est d'utiliser des machines à états pour chaque entité de ton jeu (bâtiments, unités, etc.) ayant une interface commune, donc dérivant d'une classe mère permettant l'évolution d'une entité au travers du mécanisme de tick. Tu as besoin de savoir si une unité est disponible, morte, occupée, d'avoir sa position, qu'elle sache s'afficher et, enfin, qu'elle sache avancer d'une étape dans son évolution (c'est ça, la machine à états).
  
  L'idéal pour conserver une progression temporelle fiable est d'utiliser le principe des [ame="http://en.wikipedia.org/wiki/Earliest_deadline_first_scheduling"]deadlines[/ame]. C'est très facile à implémenter via des objets, au pire je posterais le code d'une classe gérant ça.

Dans tous les cas, l'idéal est d'avoir un thread gérant l'évolution des unités (thread prioritaire, bien sûr), un thread de communication retournant l'état des unités des autres joueurs (dans le cas d'un jeu multi-joueur réseau), un thread d'affichage, et enfin un thread gérant les actions du joueur.

Chaque thread utilise des structures globales décrivant le "monde", et tous agissent suivant leur rôle. Par exemple, le thread d'affichage ne faisant que lire, il n'est pas nécessaire d'utiliser un mutex si tu prends bien soin d'être le plus atomique possible lors de la modification des entités du jeu.
De même, le thread moteur ne gérant que les unités du joueur, il est donc le seul habilité à écrire / modifier ces entités : pas besoin, là aussi, de mutex.

Il vaut mieux utiliser un système de mise à jour des entités (donc, des classes) via un système de messages (une bête FIFO correctement protégée contre les accès concurrents), de façon à ne JAMAIS appeler directement une méthode d'une autre classe : cela pourrait bloquer l'appelant, ou produire des effets de bords indésirables.
L'avantage, c'est que côté jeu en réseau, ça permet d'expédier directement ça sur le réseau (et donc vers le destinataire) au lieu de l'envoyer vers la classe locale, ce qui évite des mises à jour / synchros pénibles.