Conception objet d'un Mario-like

**alex6891** · 12/09/2006, 16h34

Bonjour,

Je souhaite me lancer dans la création "propre" d'un jeu de plate-forme dans le style Mario en 2D avec affichage de sprites, tiles, scrolling, succession de niveaux, etc.

Avant de me lancer tête baissée dans le code, j'aimerais y voir un peu plus clair et c'est pourquoi je veux faire une petite étude objet avec deux ou trois diagrammes UML pour m'aider.

Je vous demande comment vous verriez l'organisation orientée objet d'un tel type de jeu.

Merci pour votre aide,

Alex

mat.M · 12/09/2006, 19h26

Faire une étude UML rien que pour animer un perso c'est un peu lourd et tu risques de perdre ton temps bien plus qu'autre chose...

Pour mettre au point un jeu surtout l'affichage graphique les animations il faut souvent bidouiller et tes diagrammes UML vont bien vite rester dans un coin..

UML c'est bien pour une appli de gestion genre système de réservation d'une compagnie aérienne ou il y a des milliers de classes et entités pas pour un petit jeu 2d...

Mais après tout si tu y tiens...tout le monde est libre...

**alex6891** · 12/09/2006, 20h30

NoN je ne souhaite pas faire de la conception UML pour faire de l'UML à tout prix

Je m'en passe volontiers si je n'en ai pas besoin au final mais j'aimerais que le découpage de mon jeu soit propre, pas uniquement du "bidouillage" comme j'aurais tendance à faire à la va-vite !

**MrDuChnok** · 12/09/2006, 20h59

Bonsoir,

Moi au contraire je dirai que c'est une bonne initiative de ta part. Bon pas forcément le coup de l'UML, comme tu dis faire de l'UML pour de l'UML, bof bof. Mais je te conseillerais plutôt de bien mettre à plat toutes tes idées. En commençant par les généralités. C'est à dire de quoi sera composé ton application : plusieurs niveaux, des ennemis, des bonus, un personnage, ...
Ensuite tu spécialise un peu le tout, tu regroupe tout ce qui peux allé ensemble.
Par exemple ton personnage et les ennemis possèdent tous les deux des caractéristiques communes...
Si tu fais de la programmation objet, tu pourra utiliser l'heritage pour te simplifier la chose.
Essaye de voir tous ce doit pouvoir faire un personnage ou un ennemi.
Qui peut interagir avec qui, sur qui, comment...
etc etc
Ainsi tu te retrouvera avec un bon petit cahier des charges, et ton projet te paraitra moins bidouillage comme ça peut être.

Bon après tu verra y'a toujours des trucs à la con auxquels tu n'avais pas pensé... mais bon ^^

Ca doit pas trop répondre à ta question, mais j'espère que ça t'aurai tout de même aidé un tout petit peu ;-)

**ash.ice.loky** · 13/09/2006, 05h47

A vrai dire je suis pas trop pour UML.
C'est pratique pour une explication, presentation ou cahier technique mais pas pour de la programmation a ce niveau.
Ton cas fait parties de la liste, tu souhaites comprendre comment fonctionne un jeu du coup quelques diagrammes (de classes seulement) peuvent aidé.

Si tu cherches bien dans le forum ou sur le site, section jeux, tu trouveras des infos sur des problemes similaire.

Que te fasses un morpion correctement ou ou jeux MMORPG l'idée est la meme.

Brievement, un jeu possede un moteur de jeu, lui meme composé de sous moteurs, tel moteur d'affichage, IA, script, son, IO, physique, ...

Ensuite certain sont plus ou moins complexes suivant tes ambitions.

Pour ma part je commence toujours par le moteur de script, ainsi le developpement des autres est plus rapides, puis comme beaucoup direction le moteur d'affichage

voila bonne chance

**fearyourself** · 13/09/2006, 09h32

Envoyé par ash.ice.loky

A vrai dire je suis pas trop pour UML.
C'est pratique pour une explication, presentation ou cahier technique mais pas pour de la programmation a ce niveau.
Ton cas fait parties de la liste, tu souhaites comprendre comment fonctionne un jeu du coup quelques diagrammes (de classes seulement) peuvent aidé.

Si tu cherches bien dans le forum ou sur le site, section jeux, tu trouveras des infos sur des problemes similaire.

Que te fasses un morpion correctement ou ou jeux MMORPG l'idée est la meme.

Brievement, un jeu possede un moteur de jeu, lui meme composé de sous moteurs, tel moteur d'affichage, IA, script, son, IO, physique, ...

Ensuite certain sont plus ou moins complexes suivant tes ambitions.

Pour ma part je commence toujours par le moteur de script, ainsi le developpement des autres est plus rapides, puis comme beaucoup direction le moteur d'affichage

voila bonne chance

Je suis d'accord, il te faut juste avoir l'idée de quelles classes seront présentes pour faire ton jeu :

Une classe Moteur pour récupérer les entrées utilisateurs et tout le reste et le passer aux autres classes.

Une classe Jeu pour gérer les régles de ton jeu (changement de niveau, nombre de vies, nombre de pièces, avancement dans le jeu...).

Une classe Objet pour les différents personnage avec éventuellement trois sous-classes : Perso, Ennemi, Boîte

Une classe Physique pour gérer les collisions et la gravité (pour faire retomber un joueur lorsqu'il tombe).

Et je pense que tu aurais déjà pas mal de choses pas mal là...

Bon c'est à froid mais bon...

Jc

**Matthieu Brucher** · 13/09/2006, 10h27

Je pense que ça ne peut pas faire de mal. Pour un projet plus gros, il faudra passer par là de toute manière, autant se faire les crocs sur un projet plus petit pour se familiariser avec un outil, voir si ça aide, ...
Maintenant, si tu es capable de faire le diagramme de tête, à savoir organiser tes différents diagrammes avec différents pattern dans la tête, ne te gêne pas.
Pour te donner un exemple, je suis en train de faire plusieurs use cases et après le diagramme de classe correspondant à une simple fenêtre de visualisation d'une image médicale 3D. Ca paraît tout con à faire, c'est sans doute beaucoup plus simple qu'un jeu même 2D - moins de perso, pas de factory d'ennemis, de décors, ... -, et pourtant, ça aide à faire qqch de modubale car cet objet a pour vocation de travailler dans un logiciel autrement plus complexe.

**Ti-R** · 13/09/2006, 11h10

Personnellement je me fait des fiches (j'en ai des tonnes

)
Dès que j'ai une idée de programmation, de principe, de classe, je la note.

Pour faire une application, je pars toujours du tronc, pour monter dans les branches.

Je défini bien le projet, les classes à utiliser, ce qui va interagir, comment interagir, et parfois commencer à mettre sur papier l'interaction des objets, fonctions membres, et variables membres. Parfois cela permet de détecter en avance des problèmes de conceptions.

Et quand tu as une branche de faite et indépendante, il suffit de s'y "coller".

Donc les branches sont comme cela a été résumé, les IO, IA, le moteur physique, affichage etc...

**Matthieu Brucher** · 13/09/2006, 11h16

Ca a du bon, cette approche, parfois il faut s'en éloigner pour partir des branches vers le tronc - cf http://conception.developpez.com/livres/#L2212091117 pub inside -

**Franck.H** · 13/09/2006, 11h16

Tiens tiens, super post qui va pas mal m'aider pour un jeu que j'ai dû recommencer (je m'y suis toujours pas collé, j'espère juste que je vais réussir à le faire un jour

) ! Je vais noter tout ca

**Cheps** · 13/09/2006, 12h29

N'écoute surtout pas ceux qui te disent de ne pas faire de shéma UML.
Pas besoin de faire quelque chose de très compliqué avec toutes les classes, les méthodes, etc.

Je te conseil de juste griffoner sur une feuille un schéma des classes principales(par exemple, comme suggéré plus haut, le moteur du jeu, le moteur graphique, les objets, etc), ainsi que les interactions entre les classes principales(savoir que la classe A contient des objets de classe B et C, que la classe D va utiliser la classe B qui elle-même doit avoir accès à la classe C qui est static, etc).

Ca t'oblige à réfléchir et à te demander ce que tu veux vraiment, mais sans devoir entrer dans des détails du genre "quelles armes aura le héro" ou "combien y'aura-t-il de niveaux".

**alex6891** · 13/09/2006, 14h04

Ok merci à tous ça me permet d'avancer un peu

Ma conception prends forme petit à petit...

La où je bloque c'est pour situer le moteur graphique par rapport au reste : comment mon jeu va savoir quoi afficher et où lorsque je vais lui donner l'ordre de rendre la scène ?

**Franck.H** · 13/09/2006, 14h25

Oui je suis dans le même cas, pour le moment je me suis fait des schéma sous forme d'arbre (sur papier) pour essayer d'avoir une vue globale et en fait je part d'un moteur qui inclu tout le reste (IO, Timer, Collision, Affichage) ... mais si c'est une bonne chose ca j'en sais rien, c'est juste que ca me paraît logique donc si y'a des avis, suggestions, je prend aussi

Endehors du moteur mais au même niveau se trouverais ma structure principale d'un niveau qui englobe d'autres structures d'objets, cette structure d'objet servira de base à tout autre objet (Hero du jeu, ennemis, objets, plateformes)

Voilà, ca c'est ma vision des choses

**fearyourself** · 13/09/2006, 14h28

Envoyé par alex6891

Ok merci à tous ça me permet d'avancer un peu

Ma conception prends forme petit à petit...

La où je bloque c'est pour situer le moteur graphique par rapport au reste : comment mon jeu va savoir quoi afficher et où lorsque je vais lui donner l'ordre de rendre la scène ?

Ton jeu saura quoi dessiner car il aura toutes les informations nécessaires :

Il doit avoir un lien vers une classe qui gére les objets par exemple
- Permet de demander à chaque objet de se dessiner à leur position
- Les objets gérent donc eux-mêmes leurs animations...

Il doit avoir un lien vers une classe qui gére l'image de fond par exemple
- Il doit savoir comment se dessiner par rapport à la position du perso principal

La fonction d'affichage ressemblera donc à :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
void MoteurGraphique::dessine()
{
Objet &perso = GestionnaireObjets.getPerso();
 
Reinitialiser le fond
 
//Dessiner le fond par rapport à la position du perso
fond.dessine(perso)
 
Pour chaque objet o
   o.dessine();
}

Ou un truc similaire bien sûr...
Jc

mat.M · 13/09/2006, 16h56

je n'aurais pas tout à fait procédé ainsi ; les objets on les dessine en parcourant une liste par exemple std::list ou std::vector

class MoteurGraphique
{
std::vector liste_objets<objet>;
dessine();

}
void MoteurGraphique::dessine()
{
//Effacer le fond
//Parcourir la liste des objets
//copier les bitmaps dans le tampon écran arrière
//copier les bitmaps de Mario dans le tampon écran arrière
//Copier tampon écran arrière ->écran principal
}

Il doit avoir un lien vers une classe qui gére l'image de fond par exemple
- Il doit savoir comment se dessiner par rapport à la position du perso principal

Technique classique du "clipping" de l'écran

Je me sens presque obligé de faire un tutoriel

**Matthieu Brucher** · 13/09/2006, 17h01

Si tu y tiens tant

**fearyourself** · 13/09/2006, 17h09

Envoyé par mat.M

je n'aurais pas tout à fait procédé ainsi ; les objets on les dessine en parcourant une liste par exemple std::list ou std::vector

La seule différence avec ma méthode est que tu géres l'affichage des objets à partir de ta MoteurGraphique (bien sûr c'est très variable sur comment tu vas t'y prendre)...

Moi je dis juste que chaque objet contiendra son code pour faire le dessin, le moteur a juste besoin de dire quand et où dessiner.

Les deux méthodes sont, je le pense, équivalentes... C'est une question de positionnement du code d'affichage.

Ta méthode est discutable dans le sens où le moteur graphique doit savoir comment dessiner les objets si ce ne sont pas de simples bitmap à copier coller.

Bien que je devrais tenter de trouver un exemple pour montrer que cela complique quelque chose

Bien sûr ma méthode est discutable dans le sens où l'objet devient "aware" de comment il faut dessiner les choses. Cela peut bien sûr poser des problèmes si on veut faire un jeu qui a plusieurs API de rendu DirectX/OpenGL...

Technique classique du "clipping" de l'écran

Je me sens presque obligé de faire un tutoriel

Si t'es tenté, tu peux le faire et me contacter par mp, c'est un sujet intéressant je trouve pour les gens qui veulent faire un mario-like.
(Surtout si tu le fais en SDL

)

Jc

**Ti-R** · 13/09/2006, 17h27

Envoyé par fearyourself

...
Bien sûr ma méthode est discutable dans le sens où l'objet devient "aware" de comment il faut dessiner les choses. Cela peut bien sûr poser des problèmes si on veut faire un jeu qui a plusieurs API de rendu DirectX/OpenGL...
...
Jc

Personnellement je mets mon code d'affichage dans l'objet, et les méthodes utilisées pour dessiner sont réécrites en DirectX ou OpenGL si besoin, sinon c'est dessiné par des objets de plus haut niveau indépendant du moteur de rendu.

D’ailleurs j’essaye de privilégier un maximum l’option 2 pour n’avoir à écrire qu’une seul fois le code, mais si c’est vraiment trop spécifique, faut splitter le code en 2.

Le mieux étant de faire des briques communes aux 2 API graphiques, et réutiliser ces briques de bases pour dessiner tes objets.

**Matthieu Brucher** · 13/09/2006, 17h36

Normalement, l'affichage demande aux enfants de se dessiner, et ces enfants font appel au moteur pour accéder aux éléments necessaires. Après, l'affichage affiche le résultat.

mat.M · 13/09/2006, 18h32

Envoyé par fearyourself

Ta méthode est discutable dans le sens où le moteur graphique doit savoir comment dessiner les objets si ce ne sont pas de simples bitmap à copier coller.

Bien sûr ma méthode est discutable dans le sens où l'objet devient "aware" de comment il faut dessiner les choses.

Non mais c'est certain toutes les méthodes sont bonnes à prendre ; il n'y a pas une méthode mais plusieurs...

Si t'es tenté, tu peux le faire et me contacter par mp, c'est un sujet intéressant je trouve pour les gens qui veulent faire un mario-like.
(Surtout si tu le fais en SDL

)

J'aimerais mais j'ai malheureusement pas assez de temps libre..

Envoyé par Miles

Si tu y tiens tant

Re commentaire précédent ; je suis sur un projet perso qui consomme énormément de temps