Discussion :

[peijnoob]

Bonjour à tous,

Je suis actuellement en train de m'entrainer au développement de jeux, parce que j'aime ça, que j'ai quelques idées, et que je veux me préparer à les mettre en oeuvre.

Enfin, je commence par faire des petits jeux.

J'ai déjà fait un mini jeu en c#. Un écran fixe, un personnage, des ennemis qui arrivent des 4 côtés de l'écran à éviter.

Ca m'a aidé à apprendre un minimum à gérer l'affichage des sprites et les collisions.

Enfin, j'arrête de raconter ma vie

Je suis actuellement sur un petit projet, un mini jeu de plate-formes style Mario.
Vu que je connais déjà pas mal le c#, je me suis orienté là dessus, couplé avec la SDL, version .Net.

Enfin, mes questions s'orientent plus sur l'organisation des classes de mon projet. Je m'explique :

J'aimerais organiser mon programme de façon à pouvoir facilement faire évoluer et réutiliser les différents éléments dans de futurs projets (pas comme mon 1er jeu fait un peu à l'arrache ^^)

J'ai donc pensé à :
- Une classe principale, qui gère le fonctionnement principal du jeu (chargement du menu, des différents niveaux, création des objets principaux, etc.).
- Une classe pour la gestion de la physique (classe générique, que je pourrais réutiliser)
- Une classe pour la gestion des collisions.
- Une classe pour la gestion de l'affichage (un mini moteur graphique 2D)
- Diverses classes, spécifiques au jeu, elles, qui définissent mes objets et leur comportement (les personnages du jeu et les niveaux).

Pour les personnages du jeu, toutes mes classes sont dérivées d'une classe elle même dérivée de l'AnimatedSprite de la SdlDotNet, qui est fort pratique.

Enfin, je me demandais un peu comment organiser et interconnecter le tout afin de pouvoir atteindre mes objectifs, qui sont principalement efficacité, clareté et réutilisablité du code.

J'ai pensé à tout faire dans l'évènement SDL Tick, en utilisant un délégué.
En gros à chaque tick :
- je passe mes objets au moteur physique pour calculer les déplacements de mes objets ;
- je passe ensuite mes objets au gestionnaire de collisions ;
- je passe mes objets au moteur graphique afin d'afficher le tout à l'écran.

Je pense que la structure générale est plutôt bonne, mais je tique énormément au niveau de la partie gestion des collisions. Je ne vois vraiment pas comment faire quelque chose de réutilisable, tant les situations de collisions sont importantes, et induisent un comportement de mes objets vraiment spécifique à leur nature, et, par extension, à la nature du jeu.

Enfin, que pensez-vous de la structure générale de mon programme ? Est-ce que je me dirige dans la bonne direction ?

Avez-vous des conseils à me donner en particulier pour pour les interactions entre le gestionnaire de collisions et mes objets ?

Avez-vous des conseils d'ordre plus général à me donner pour ne pas partir du mauvais pied ?

Merci à tous

[fearyourself]

A part que j'ai une tendance à bouger un objet, regarder les collisions et passer au suivant, c'est la même chose.

Il faudra juste que tu détermine ce qui arrive lorsqu'il y a une collision entre deux objets de même importance (deux monstres par exemple).

Mais sinon, cela me semble pas mal.

Jc

[peijnoob]

Merci pour cette réponse.

En effet, gérer les collisions juste après avoir modifié la position de l'objet me paraît plus simple.

Enfin, après avoir fait quelques recherches, je suis tombé sur un document parlant des GameStates.
Je ne connaissais pas cette méthode de développement, mais ça a l'air fort pratique, donc je pense qu'en fait, je vais m'orienter là dessus.

Pour ceux que ça intéresse : Managing Game States in C++

Bon, c'est en C++, mais c'est facilement adaptable à n'importe quel langage objet.

Ca remet pas mal en cause ma vision des choses, mais bon, c'est du bon ^^