Discussion :

[stopviolence]

Bonjour,

Je voudrais savoir si le pattern modèle-vue-contrôleur a sa pertinence pour la programmation d'un jeu vidéo,

Mettons que je fasse un pong, on rangerait dans le modèle des classes balle-raquette-scores, dans la vue le moteur graphique et audio, et le contrôleur synchronise tout ça avec le gameplay (et les input clavier je sais pas si il faut les mettre dans le contrôleur ou dans la vue)

bon en fait mes jeux sont déjà structurés comme ça sauf que je range pas le bazar dans trois dossiers

grosso modo c'est ça ? dites si je me plante

[ohnomorejmmings]

Je voudrais savoir si le pattern modèle-vue-contrôleur a sa pertinence pour la programmation d'un jeu vidéo

Complètement car un jeu vidéo c'est un logiciel comme un autre. Comme autre patron/motif un classique c'est le singleton.

Mettons que je fasse un pong, on rangerait dans le modèle des classes balle-raquette-scores, dans la vue le moteur graphique et audio, et le contrôleur synchronise tout ça avec le gameplay (et les input clavier je sais pas si il faut les mettre dans le contrôleur ou dans la vue)

La vue c'est l'IHM mais si ma mémoire est bonne c'est plus logique d'utiliser le contrôleur pour les entrées. En plus on parle de contrôles aussi à la manette, souris…

bon en fait mes jeux sont déjà structurés comme ça sauf que je range pas le bazar dans trois dossiers

On est libre de ce côté là tant que ça reste bien organisé. Pour un petit projet ma préférence va à des fichiers à la racine. Quand ça se complexifie là on hiérarchise. Après ça reste une bonne pratique de toujours respecter telle ou telle méthode…

[PilloBuenaGente]

Comme autre patron/motif un classique c'est le singleton.

A utiliser avec beaucoup de parcimonie, il donne souvent du code peut modulaire, ne doit être utilisé que pour les entités qui ne seront jamais dupliquées.

La vue c'est l'IHM mais si ma mémoire est bonne c'est plus logique d'utiliser le contrôleur pour les entrées. En plus on parle de contrôles aussi à la manette, souris…

J'aurais plutôt pensé que les contrôleurs avaient pour rôle la réception des valeur envoyées par la vue dont on pourrai vouloir s'abstraire;
A la place des flèches directionnelles, on pourrait vouloir une IA, cela impliquerais sans doute duplication de code et "refactorisation".

Après ça reste une bonne pratique de toujours respecter telle ou telle méthode…

D'ailleurs si je peux aussi conseiller le pattern SOLID et RAII (merci à ceux qui les ont scandés sur ces forums )

[ohnomorejmmings]

Au temps pour moi la vue se charge bien de gérer les évènements. Par contre ça reste possible d'en séparer l'affichage. Quant à une IA tout dépend de ce qu'elle fait. Je pense par exemple au contrôle d'une vue en mode démo même si c'est pas l'usage auquel on pense en premier.

[stopviolence]

Intuitivement j'aurais aussi rangé les contrôles dans la vue parce que ça me semble plus cohérent de mettre au même endroit ce qui gère les périphériques enfin je dis ça mais ptête qu'on se plante.

Sinon le singleton je sais pas c'est un truc que j'utilise presque jamais, si je veux une classe qui fait pas des bébés je fais juste une classe statique. Le singleton je dois m'en servir quand j'ai besoin d'une classe mère et profiter de ses props d'instance. Bon donc j'ai pas dù bien comprendre le principe.

[PilloBuenaGente]

Sinon le singleton je sais pas c'est un truc que j'utilise presque jamais, si je veux une classe qui fait pas des bébés je fais juste une classe statique. Le singleton je dois m'en servir quand j'ai besoin d'une classe mère et profiter de ses props d'instance. Bon donc j'ai pas dù bien comprendre le principe.

La différence avec un static, c'est qu'avec un singleton tu peux contrôler la durée de vie de ton instance.
(Quand je disais : "ne doit être utilisé que pour les entités qui ne seront jamais dupliquées", c'est d'un point de vue pratique et non technique.)