Bonjour, je suis en équipe sur un projet de jeu point & click à la Machinarium, je dois le coder en C++ avec la SDL.
 
Bon je vais essayer d'être le plus clair possible ; ma question est la suivante :
 
"Comment programmer le plus aisément ?"
 
J'ai plusieurs solutions mais je ne sais pas comment m'y prendre :
 
1. Soit je crée une classe Game englobant toutes les classes d'un jeu point & click (Sprites, Personnage, Room, Dialogue, Item, j'en passe...) afin d'insérer un pointeur SDL_Surface attribut contenant l'écran où je blitterai toutes mes images au fur et à mesure...
 
2. Soit je crée les classes précédentes à part et indépendantes entre elles, mais le problème c'est qu'il me faut le pointeur SDL_Surface et donc à n'importe quelle fonction graphique je serai toujours obligé de l'envoyer en paramètre, ce qui peut être lourd et ennuyeux. En fait je me demande si ya pas mieux que de devoir créer 50 fonction sous la forme :
 

 
Je verrais plus proprement un truc du genre :
 

 
Ce qui me fait bien sûr penser à ça c'est pour maximiser à fond l'orientation objet du main.cpp et faire en sorte que la SDL soit gérer toute seule dans les méthodes.
 
Je sais pas si je suis clair dans mon explication, si vous voulez des précisions n'hésitez pas
 
Merci, à bientôt.

Au lieu d'avoir un objet pour chaque concept du jeu (Sprite, Perso, etc...) et de le forcer à tout faire lui même (donc à savoir s'afficher, donc à avoir du code de blit de la SDL dans tout tes objets). Il y a une autre méthode, qui te fera avoir bien moins de duplication de code, en gros :

// C'est pas comme le Sprite dont tu parle, il est utilisé par tout types d'affichage
class Sprite {
    SDL_Surface* texture;
    int x, y;
    int layer;
    public:
    void draw(SDL_Surface* surface) {
        // peint la surface texture à la position (x, y)
        SDL_BlitSurface(texture, blahblah..., surface, blahblah...);
    }
    // Ca c'est pour trier tout les sprites dans le bon ordre et dans un ordre
    // efficace pour l'affichage...
    bool operator<(const Sprite& that) {
        // On met les plus petits layers (les plus au fond) en premier
        if (layer >= that.layer) return false;
        // On essaie ensuite de trier les textures dans l'ordre pour mieux utiliser le cache
        if (texture >= that.texture) return false;
        // On se fiche de x et y, donc on compare simplement l'identite
        // pour avoir un ordre complet
        if (this >= &that) return false;
    }
};
 
class Game {
    std::list<Sprite> sprites;
    Personage personage;
    SDL_Surface* default_texture;
    public:
    std::list<Sprite>::iterator new_sprite(const char* texture_file) {
        // avec SDL_Image
        SDL_Surface* texture(IMG_Load(texture_file));
        // Si on trouve pas le fichier, on a une texture par defaut avec une grosse croix rouge
        // C'est mieux qu'une segfault...
        if (!texture) texture = default_texture;
        return new_sprite(texture);
    }
    std::list<Sprite>::iterator new_sprite(SDL_Surface* texture) {
        sprites.push_back(Sprite(texture, 0, 0, 0));
    }
    void delete_sprite(std::list<Sprite>::iterator sprite) {
        sprites.erase(sprite);
    }
    
    void prepare_draw() {
        std::sort(sprites.begin(), sprites.end());
    }
    void draw(SDL_Surface* surface) {
        // pour chaque element de la liste des sprites :
            sprite.draw(surface);       
    }
    
};
 
class Personage {
    Game& game_;
    std::list<Sprite>::iterator head_;
    std::list<Sprite>::iterator body_;
    public:
    Personage(Game& game)
        : game_(game)
        , head_(game.new_sprite("hero_head.png" ))
        , body_(game.new_sprite("hero_body.png" )) {
    }
    ~Personage() {
        game_.delete_sprite(head);
        game_.delete_sprite(body);
    }
    void move_left() {
        // Si tu veux faire du joli objet, tu fais des accesseurs et tout ca...
        head_->x += 2;
        body_->x += 2;
    }
    void move_right() {
        head_->x -= 2;
        body_->x -= 2;
    }
};
 
class Text {
      std::list<Sprite>::iterator text_texture_;
      public:
 
      // constructeur destructeurs, etc...
 
      void set_text(const std::string& text) {
            // en vrai y'a l'ancienne texture a liberer...
            text_texture_->texture = TTF_RenderText_Solid( ta_font, text, ta_couleur);
      }
      void set_text_position(int x, int y) {
            // Et la si t'es courageux, tu ajoute des proprietes d'alignement
            // et tu fais tes calculs en fct de la taille de la texture
            text_texture_->x = x;
            text_texture_->y = y;
      }
};

Bref, l'idée c'est que tes différents objets gèrent tous un ou plusieurs objets Sprite (si ils ont des trucs à afficher), mais ne font que changer ses propriétés, quand vient le moment de tout afficher, c'est game qui le fait d'un coup, de manière efficace. (Par exemple il peut au passage décider de ne pas blitter les éléments hors-écran...)
T'auras aussi des objets de plus haut niveau : la classe Dialogue par exemple, qui elle contiendra des objets Text, les positionnera, les ajoutera et les supprimera au fil du dialogue, sans jamais avoir besoin de savoir quel est le code pour réellement afficher ce text.

Alors merci beaucoup pour le message, ça va effectivement être plus aisé de faire comme ça, c'est vrai que le découpage du projets, des classes et surtout de leur méthode donc est pas facile, donc merci.
 
Par contre il y a des notions que je ne saisie pas bien, les layers notamment, je sais pas trop ce que signifie le mot-clé iterator, mais j'ai tout le temps d'apprendre ces choses.
 
Le plus important c'est que je vois à peu près la manière dont je devrais m'y prendre.
 
Je viens à une nouvelle question ^^ :
 
Est-ce qu'il serait plus pratique de créer des tableaux dynamiques de chaque classe en référence aux éléments que je crée :
 

 
Si ça te dit quelque chose, je voudrais faire comme dans le logiciel AGS, c'est-à-dire contrôler mes objets avec différents tableaux où entrer l'ID de chaque élément (perso1.ID = 0, perso2.ID = 1, etc...), ce qui permettrait de les contrôler nettement plus facilement par le biais d'une boucle et de m_Count (automatiquement recalculé), ainsi si je veux faire une commande pour tous mes objets, une boucle de la commande et c'est réglé.
Sauf que je sais pas trop où mettre le tableau de références ?
Et pour attribuer tous les personnages créés je doit faire appel à une fonction ? De quelle classe ? Game ou Personnage ?
 
Moi ma philosophie de programmation c'est d'essayer d'avoir le plus possible de manipulation d'objet (donc comme tu l'as souligné, je fais beaucoup d'accesseurs) dans le main.c jusqu'à ne pas avoir à toucher la SDL si on peut, ce qui impliquerait la gestion des évènement ailleurs que dans le main.c
 
Je suis convaincu qu'un plan de programmation impérialement structuré permet de faire très facilement le jeu (quitte à ce que les méthodes soient très lourdes).

Ce que j'ai appelé layer, j'aurais pu aussi l'appeller profondeur (même si tu fais un jeu en 2D), ou z-index (si t'as fait du web ça doit te dire quelque chose ça), c'est juste une valeur pour savoir quand t'as 2 sprites lequel doit être dessiné par dessus l'autre. Par exemple le background aura la valeur 0, les objets dans le décor des valeurs entre 1 et 1000, ton personage la valeur 1000 et ton interface des sprites avec une valeur encore plus grande. Comme je trie tout les sprite par numero de layer avant de les dessiner, je suis sur quand je dessine tout les sprite de peindre le background en premier et l'interface en dernier.

L'iterator c'est plus embétant que tu comprenne pas, il te manque un gros bout de C++, c'est pas un mot clef c'est un type, et ça sert à naviguer dans les collections d'objet comme std::list

C'est en gros ce que je fais là. std::list<Sprite> dans Game pour stocker les objets. std::list<Sprite>::iterator qui sert d'identifiant pour accéder à l'objet, puis pour le détruire quand on en a plus besoin. tu peux faire une autre liste, de personages de la même manière.

Typiquement dans ton main tu pourrais avoir quelque chose de la forme :

int main(int argc, char** argv) {
    SDL_Init(SDL_INIT_VIDEO);
    SDL_Surface* screen = SDL_SetVideoMode(640, 480, 0, SDL_HWSURFACE | SDL_DOUBLEBUF);
    Game game;
    Uint32 time = SDL_GetTicks();
    while (!game.finished()) {
        SDL_Event event;
        while(SDL_PollEvent(&event)) {
            switch (event.type) {
                case SDL_MOUSEMOTION:
                    game.on_mouse_move(event.motion.x, event.motion.y);
                    break;
                case SDL_MOUSEBUTTONDOWN:
                    game.on_mouse_down(event.button.button, event.button.x, event.button.y);
                    break;
                case SDL_MOUSEBUTTONUP:
                    game.on_mouse_up(event.button.button, event.button.x, event.button.y);
                    break;
                case SDL_KEYDOWN:
                    game.on_key_down(event.key.sym);
                    break;
                case SDL_KEYUP:
                    game.on_key_up(event.key.sym);
                    break;
            }
        }
        
        Uint32 new_time = SDL_GetTicks();
        // Tres utile si t'as des animations...
        game.advance_time(new_time - time);
        time = new_time;
        
        game.prepare_draw();
        game.draw(screen);
        
        SDL_Flip(screen);
    }
    SDL_Quit();
    return 0;
}

Donc avec quasiment (à part la gestion de la texture des Sprite et le dra) tout le code spécifique à la SDL dans ton main.

Ensuite dans Game, tu réagis aux clicks/clavier/etc... dans les fonctions on_* qui font avancer l'état du jeu, jusqu'au moment où tu fais quelque chose qui fait que game.finished() retourne true, et le jeu se ferme.

Un mot : merci !!        
 
Et je suis même heureux d'apprendre l'intérêt de l'iterator ! Pour les layers effectivement c'est essentiel, bon par contre j'ai jamais touché au web script  
J'apprends le C++ sur le site du zéro donc étant pour des amateurs le tuto ne peut pas être le plus complet et pourtant cette notion est supère importante la preuve !!
J'irai voir sur Developper.com ou ici si y a des tutos
Et franchement merci pour le code, ça m'oriente beaucoup, donc ya de la SDL juste pour l'initialisation et les évènements.
C'est peut être une question idiote mais créer une fonction game.Init() pour regrouper les lignes 2 et 3 est possible ou la SDL sera quittée dès que la fonction sera terminée ?
 
 

C'est possible, (la SDL ne quitte qu'au moment de SDL_Quit), mais ça n'apporte rien :
- tu va agrandir Game, qui est déjà une classe bien chargée
- ça va faire plus de code, sans gagner en maintenabilité ou flexibilité
- tu va éloigner le SDL_Init du SDL_Quit, alors que les deux vont logiquement ensemble
- tu augmente les responsabilités de Game pour rien, il n'a pas besoin de savoir créer sa propre surface pour faire son boulot, si tu y tiens tu peux avoir un objet qui s'occupe de gérer la surface (et même du coup, de changer de surface à la volée, pour entrer/sortir d'un mode fullscreen par exemple), mais là encore, pas la peine de forcer Game à tout faire.

OK, Game était un exemple, je comptais faire une classe System voire SDL, avec les méthodes Init() et Quit() et pourquoi pas un changement de mode de résolution :3
 
Moi personnellement je trouve ça plus qu'inutile pour les mêmes raisons, mais dans un projet un équipe, je pense vraiment qu'une aisance de lecture de code s'impose pour éviter la démotivation, les commentaires ne suffisent pas toujours. En fait le fait d'englober les deux fonctions permettra d'indiquer aux programmeurs (qui apprennent actuellement la SDL) que les trois fonctions sont liées (les deux premières dans le Init et la fonction Quit() dans la méthode Quit()).
 
Encore une fois, grand merci à toi, je viendrai sûrement toquer pour plus d'info.
Bon j'ai commencer à lire ton lien sur l'iterator, Mon Dieu j'ai l'impression qu'il me manque des masses