Discussion :

[Disixlis]

Bonjour tout le monde, j'ai une petite question au niveau de la conception de deux classes.
J'ai une classe Player et une classe Bullet, Player contient un vecteur de Bullet. J'ai une méthode pour dessiner le joueur, elle s'appelle draw(). Je veux respecter le principe SOLID donc es que draw devrait aussi dessiner les Bullet ? Gérer leur destruction lorsqu'il sont hors écran ? Gérer leur update de position ? Je pense que non mais d'un autre côté je me dis que faire une classe du genre BulletSystem (pour gérer les Bullet) ne serait pas mieux.

Un peu de code pour illustrer :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
 
 
class Player
{
 
   ...
   private:
 
   tl::Shape           p_shape;
   std::vector<Bullet> p_bullets;  /// A chaque fois que le player tir, un nouveau Bullet est créer
 
   ...
   private:
   void draw();
 
}
 
class Bullet
{
 
   ...
   private:
 
   tl::Shape b_shape;
   tl::Angle b_angle;
   float     b_speed;
 
   ...
   private:
   void draw();
 
}

Merci de votre aide

[foetus]

Je lance une idée, mais attends plus de réponses

C'est normal que tu aies du mal ... c'est parce que tu as mis un tableau de balles (ballons ????) dans ton joueur.

Il faut se rapprocher plus du modèle Entity–Component–System (ECS) (<- lien wiki)
Tu vas avoir 2 entités (joueur et balle) au moins 3 composants (player_shape, ball_shape, ball_direction) et 1 système pour faire vivre tout cela (et prendre en charge quand on affiche, quand les objets sont créés et détruits, ...)

[ternel]

chaque joueur a sa propre liste de balles?
pourquoi ne pas simplement partager les balles dans une liste commune?

[Disixlis]

Je lance une idée, mais attends plus de réponses

C'est normal que tu aies du mal ... c'est parce que tu as mis un tableau de balles (ballons ????) dans ton joueur.

Il faut se rapprocher plus du modèle Entity–Component–System (ECS) (<- lien wiki)
Tu vas avoir 2 entités (joueur et balle) au moins 3 composants (player_shape, ball_shape, ball_direction) et 1 système pour faire vivre tout cela (et prendre en charge quand on affiche, quand les objets sont créés et détruits, ...)

En réalité je n'ai pas mit de vector de Bullet, c'était juste pour l'exemple et ton idée me parait la plus adapté

Bon par contre pour le "liage", c'est un peu vague. Imaginons que je dispose d'une classe EntitieSystem qui contient un vecteur de joueur et de balles, le joueur devrait avoir une méthode shoot() mais du coup je ne vois pas trop comment ajouter un bullet à mon vector... ou alors j'ai une autre solution, je crée ma classe EntitieSystem et je crée un vecteur dans mon main et la méthode shoot renverrai un Bullet que "j'enregistre encore dans un nouveau vecteur à l'intérieur de EntitieSystem ? Je n'ai jamais fait ce genre de chose et l'ECS je maîtrise pas encore x). Dans tout les cas je vais me documenter mais pour l'instant je n'ai pas une bonne conception pour ce genre de chose

[Bousk]

Et donc quand un joueur disparait toutes les balles qu'il a lancé disparaissent aussi ?

[koala01]

Salut,

De manière générale, le joueur et les balles doivent agir de manière totalement indépendante : une fois que le joueur a lancé une balle (dans une direction et avec une force donnée, cela va de soi), il en perd totalement le controle : elle continuera sur sa lancée jusqu'à ce qu'un événement quelconque (sortie de l'écran, "collision" avec "autre chose", ...) l'oblige à faire autrement

Il n'y a donc aucune raison que le joueur dispose directement d'un tableau de balles. Au mieux, il dispose d'une information permettant d'identifier (dans un ensemble de balles données) celles qui lui appartiennent et qu'il peut décider de lancer (ou le nombre de balles qu'il peut encore lancer)

Mais, quoi qu'il en soit, la gestion des balles proprement dite (et surtout leur maintien en mémoire une fois qu'elles ont été créées, avant même d'avoir été lancées) n'est absolument pas du domaine du joueur, mais plutôt de ... ce qui maintient également le joueur en mémoire (voir de ce qui maintient en mémoire ce qui maintient le joueur en mémoire )

En plus, c'est sans doute à ce niveau là que tu pourras commencer à repérer les différentes interactions qui peuvent exister entre une balle ou un joueur donné et son "environnement immédiat" (celui qui risque d'influer sur le comportement de la balle ou du joueur)

[Mat.M]

Je veux respecter le principe SOLID donc es que draw devrait aussi dessiner les Bullet ? Gérer leur destruction lorsqu'il sont hors écran ? Gérer leur update de position ? Je pense que non mais d'un autre côté je me dis que faire une classe du genre BulletSystem (pour gérer les Bullet) ne serait pas mieux.

pour faire un jeu de balles mettons une simulation de tennis, ce que je ferais plutôt c'est une classe joueur , une classe balles et une classe jeu.
Dans la classe jeu je mettrais à jour l'écran avec une méthode Update qui parcourt la liste des balles et appelle chaque méthode individuelle draw().
Pour faire une mise à jour de l'écan , concrétement il faut un timer..
ensuite cette classe jeu permet aussi de gérer l'écran, le "clipping" des entités