Discussion :

[Aspic]

Salut à tous,

Vu que je ne fête pas Noel, j'en ai profité pour continuer à bosser ,mon livre sur les patterns et à refactorer mon code (ouais je sais je suis un gros Geek y'a pas 2 débiles qui font de la programmation le jour de Noel...)

J'utilise maintenant Doxygen pour générer de la doc....... en anglais ! Et vu mon niveau d'anglais ca craint ^^ Enfin, j'espère que vous comprendrez quand même !
Elle se trouve dans le répertoire doc à la racine.

J'ai aussi mis un MakeFile pour linux (celui de LittleWhite Merci), et j'ai mis la lib Allegro (version 4.2.3) dans le dossier lib, espérons que cette fois ci je n'ai pas fais de bêtise et que ca compilera du premier coup sous Linux.

Voilà la nouvelle hiérarchie des classes dans le répertoire src :

+ api/Allegro => gère l'init et le deinit de la lib Allegro, c'est un singleton
+ api/ImageManager => Charge et décharge les ressources en mémoire (Bitmaps), c'est un singleton
+ api/AllegroRenderer => Se charge de dessiner les sprites à l'écran et gère le double buffer. Hérite de la classe abtraite IRenderer

+ core/Game => Gère le jeu en lui même
+ core/GameEngine => Gère le moteur de jeu (fps, et cie...)
+ core/InputJoystick => Gère le joystick. Hérite de l'interface Input.
+ core/InputKeyboard => de même pour le clavier
+ core/InputManager => Se charge de loader/delete les différentes I/O possibles (clavier et joystick dans mon cas)
+ core/IRenderer => Interface qui gère l'affichage des sprites
+ core/ISprite => Interface qui gère un Sprite de base (position, taille, image...)
+ core/Input => Interface qui gère les I/O

+ game/AnimatedSprite => Gère un Sprite animé
+ game/ClassicalSprite => Gère un Sprite classique
+ game/World => Gère la zone de jeu. Une zone de jeu est composé de sprites qui sont tous issus d'interface ISprite.

+ tools/Logger => le logger de LittleWhite (il va finir par me dire que je lui vole tout )
+ tools/Color => Gère la couleur avec le rgba
+ tools/Functor => Foncteurs utilisés pour libérer les ressources des conteneurs de la STL
+ tools/Rect => Gère un rectangle simple
+ tools/Vect2D => Gère un vecteur 2D
+ tools/Size2D => Gère une taille en 2D

Afin de simplifier les écritures, j'ai défini des macros pour les classes Singletons :
---> AL pour la classe Allegro
---> IM pour la classe ImageManager.

De plus, afin de séparer au maximum Allegro du moteur de jeu, j'utilise des identifiants pour les images qui sont stockés dans une map de la classe ImageManager. J'ai donc créé des méthodes permettant de récupérer la vraie image en fonction de son ID.

Niveau fonctionnalités :
Pas d'inquiétude pour l'instant, le jeu ne déplace qu'un personne dans les 8 directions possibles sans controles des bords, c'est rustique je sais ^^

Maintenant, le fameux lien :
http://www.tutoworld.com/temp/zelda_version_2.zip

Voilà, comme d'habitude, j'espère avoir des retours sur cette nouvelle conception, j'essaye au maximum de mettre en œuvre ce que j'ai appris mais c'est loin d'être facile. J'ai bien envie d'utiliser le pattern stratégie pour gérer les Behaviours possibles des entités mais je ne sais pas si c'est une bonne idée.

Difficile quand on est seul de se donner une idée sur la qualité de sa vision de la conception, surtout quand on est nul en Uml et cie

PS : Pour ceux qui arrivent en cours de route, je rappelle que le lien de la Démo est disponible ici :
http://www.tutoworld.com/temp/projet_zelda_2011.zip

PPS : Avec le recul, j'en reviens pas d'avoir codé cela avec un design aussi... comment dire.... pourri !

Merci à vous, bon Noël

[LittleWhite]

Bonjour,

N'oubliez pas que Linux, contrairement à Windows est sensible à la casse. Du coup GCC/G++ il n'aime pas trop vos includes qui ne sont pas totalement correct, exemple :

In file included from src/core/InputKeyboard.h:4,
from src/core/GameEngine.cpp:5:
./src/core/Input.h:11:26: error: inputManager.h: Aucun fichier ou dossier de ce type

Dans le fichier des foncteurs, j'ai un peu de mal avec:

Code :

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

template <class T> void operator ()(T*& p) const

notamment, la partie T*& pEn fait, vous avez besoin de la référence, pour mettre le pointeur à NULL. Mais au final, si vous supprimer tous les pointeurs d'un std::vector car il est détruit, alors il n'est pas vraiment utile de les mettre à NULL, car le std::vector devrait subir un clear() par la suite.
Ou encore, un élément mis à NULL devrait être enlevé d'office du std::vector (du moins, très souvent).

La pré-définition des couleurs devraient être soit en static dans la classe Color (pour un accès du style Color::black) ou dans un namespace. Il est peu recommandé de laisser de telle définition dans le namespace global.

Le Singleton est souvent considéré comme un anti pattern. L'usage le plus approprié (alors qu'il est très controversé) c'est le Logger. Pour ce cas là, je n'ai pas grand chose à dire, mettre la surcouche d'une bibliothèque en singleton, peut être, mais avec des réserves. Notamment, si un jour vous voulez utiliser d'autres bibliothèques, ou plusieurs bibliothèques à la fois.

Code :

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

bool initAllegro(USize2D s);

Vous devez (c'est préférable) utilisez une référence constante (pour tous ce qui est autre que les types de bases).

Ah, j'ai trouvé un problème de gestion d'erreur
Dans votre main, vous avez:

Code :

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

1
2
3
4
5
if (!AL->initAllegro(resolution))
    {
        LError << "Fail to init ALLEGRO";
        return EXIT_FAILURE;
    }

Il n'y a pas de nettoyage.
Pourquoi je dis cela, c'est qu'en voyant votre fonction init, on remarque trois initialisation (keyboard / joystick / timer). Si l'un d'entre elle échoue, les autres ne sont pas proprement arrêtées.

Pourquoi la classe Allegro a une BITMAP, si AllegroRenderer en a un aussi ?
_DrawingManager ne serait pas inutile maintenant ?

Sinon, mais ceci est a prendre avec des pincettes, selon ce que vous voulez vraiment faire. En théorie, lorsque l'on fait un jeu et que l'on espère en faire un deuxième, on va créer une base de code qui soit réutilisable et surtout, qui ne soit pas attaché à une dépendance qui pourrait gênait (imaginez, vous voulez supporter la GP2X (donc nécessité de la SDL) sans pour autant touché à beaucoup de morceaux dans votre code). Actuellement, il y a une classe Allegro, qui serte, recouvre la bibliothèque Allegro, mais qui ne sépare pas clairement et efficacement la partie application de la partie bibliothèque. Du coup, il faudra changer des choses dans le main (et autres classes) afin de pouvoir avoir la SDL. En théorie c'est ce que l'on essaie d'éviter -> on veut que le changement de bibliothèque est un impact minime sur le reste du jeu. C'est l'objectif qu'il y a dans OpenAWars avec le NEngine.
Sauf que vous, vous brisez ce principe, en présentant des choses (types / fonctions) qui sont spécifiques à Allegro, mais qui ce retrouve dans le reste du code. La classe Allegro, mais aussi les BITMAP*.
Après, je ne peux pas vous dire de refaire un NEngine, car cela dépend de ce que vous voulez vraiment faire.
(Pour éviter d'avoir BITMAP qui se trimballe dans le code, il faut une classe de recouvrement, comme je l'ai fait pour le NEngine, recouvrant SDL_Surface).

Comme me l'avait fait remarquer gbdivers, les types qui sont utilisés dans le moteur, doivent se retrouvé dans le moteur. Soit, le NEngine utilise les types Size / Rect. Du coup, les fichiers .h de ces types se retrouvent dans le dossier du NEngine.

Le fichier InputJoystick.cpp inclut allegro.h . Ce fichier n'étant pas dans le dossier api, j'imagine qui se doit d'être indépendant d'une quelconque API. Du coup, l'include vous casse se principe.

Il en est aussi du GameEngine, il ne devrait pas être aussi dépendant des trucs d'Allegro. Sinon, pour moi, il devrait se retrouver dans le dossier API.

ISprite est utilisé un peu étrangement (hérité par AnimatedSprite). L'héritage pouvait être justifié, si les méthode de dessin son identique. Car, l'héritage peut laisser la possibilité d'avoir l'AnimatedSprite dessiner pour un simple ISprite et du coup, on verra le sprites sheet, non?
Sinon

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
 
bool AnimatedSprite::update(int directions, int buttons)
{
    if (directions != Core::InputManager::D_NONE)
    {
        if (Core::InputManager::isPressed(directions, Core::InputManager::D_RIGHT))
        {
            dir = 2; // right
            pos.x++;
        }
        if (Core::InputManager::isPressed(directions, Core::InputManager::D_LEFT))
        {
            dir = 0;
            pos.x--;
        }
        if (Core::InputManager::isPressed(directions, Core::InputManager::D_UP))
        {
            dir = 3;
            pos.y--;
        }
        if (Core::InputManager::isPressed(directions, Core::InputManager::D_DOWN))
        {
            dir = 1;
            pos.y++;
        }
 
        // mis à jour de l'animation
        animate();
    }
 
    return true;
}

Cela voudrait dire, que tout sprite animé réagirai aux commandes du clavier ?
De plus, vos sprite ne sont pas animé par rapport au temps, mais au mouvement. Alors oui, c'est possible, mais que faites vous si les deux sont possibles ? (indice: Surement un design pattern )
Qui, rapidement, pourrait remplacer la lourde implémentation AnimatedSprite / ClassicalSprite, pour d'autre chose, plus joli et plus paramétrable.
Pour moi (dans OpenAWars), un AnimatedSprite ayant juste un carré dans la sprite sheet fera exactement ce que fait mon sprite de base. Actuellement, dans le code, il n'y a que des AnimatedSprite, alors que je n'ai aucun sprite animé comme fichier image. Donc j'oserai dire que le ClassicalSprite, à part le comportement est identique au AnimatedSprite.

Et, nous en venons au monde, qui subit donc les conséquence des problèmes précédents. En effet, vous avez une liste de Sprite. Mais en fait, dans un jeu, ce n'est pas vraiment une liste de Sprite, mais une liste d'entité, qui possède un Sprite et que chaque Entité à un comportement différent. Ce que je veux dire là, c'est que vous ne séparez pas la représentation graphique de votre jeu, avec sa représentation dans le modèle et son comportement au sein du jeu.
Du coup, si vous voulez implémentez un nouveau monstre, avec un nouveau comportement, il vous faudra faire en sorte d'hériter encore de ISPrite et de réimplémenter une partie de AnimatedSprite ... et on ne sait pas quoi d'autre. C'est lourd, je trouve.

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
World::World()
{
    entities.clear();
 
    // chargement du sprite via le ImageManager
    int i = IM->loadImage("data/link_mouvement.bmp");
 
    // création d'un sprite
    if (i != LOAD_FAILED)
    {
        entities.push_back(
        new AnimatedSprite(
            IM->getImageSizeById(i),
            IVect2D(100,10), i, USize2D(32*3,32*3), 10));
    }
}

La question que j'adore : "Et si ça fail ?" (crash ?).
J'ai eu faut, pas de crash, mais pas de retour utilisateur. Sachant qu'un sprite est important, il faut peut être faire en sorte que s'il en manque un (non chargé) on stoppe le jeu avec un joli message.

Voilà,
Je vous conseille de ne pas partir dans tout les sens. Lorsque l'on créer ce style de programme, on fait bloc par bloc. Pour l'instant il est de faire le bloc API / moteur natif. Une fois validé et testé avec des cas simple, vous pourrez faire votre World et toute autre gestion du monde / interactions.

Bon courage

[Aspic]

N'oubliez pas que Linux, contrairement à Windows est sensible à la casse. Du coup GCC/G++ il n'aime pas trop vos includes qui ne sont pas totalement correct, exemple :

Oups désolé, c'est vrai il y a des petites problèmes de casse

Dans le fichier des foncteurs, j'ai un peu de mal avec:

Code :

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

template <class T> void operator ()(T*& p) const

notamment, la partie T*& pEn fait, vous avez besoin de la référence, pour mettre le pointeur à NULL. Mais au final, si vous supprimer tous les pointeurs d'un std::vector car il est détruit, alors il n'est pas vraiment utile de les mettre à NULL, car le std::vector devrait subir un clear() par la suite.
Ou encore, un élément mis à NULL devrait être enlevé d'office du std::vector (du moins, très souvent).

Bah en fait, j'ai récupéré le code de la FAQ :
http://cpp.developpez.com/faq/cpp/index.php?page=STL#STL_delete_sequence

Après, je ne sais pas trop quoi en pense
Effectivement, je confirme la plupart du temps, il y a un vector.clear() derrière mais pas tout le temps...

La pré-définition des couleurs devraient être soit en static dans la classe Color (pour un accès du style Color::black) ou dans un namespace. Il est peu recommandé de laisser de telle définition dans le namespace global.

Oki

Le Singleton est souvent considéré comme un anti pattern. L'usage le plus approprié (alors qu'il est très controversé) c'est le Logger. Pour ce cas là, je n'ai pas grand chose à dire, mettre la surcouche d'une bibliothèque en singleton, peut être, mais avec des réserves. Notamment, si un jour vous voulez utiliser d'autres bibliothèques, ou plusieurs bibliothèques à la fois.

Alors comment faire pour encapsuler les fonctions de la librairie Allegro ? faire une classe et déclarer toutes les fonctions statiques ?

Code :

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

bool initAllegro(USize2D s);

Vous devez (c'est préférable) utilisez une référence constante (pour tous ce qui est autre que les types de bases).

Qu'est ce que cela change concrétement ?

Ah, j'ai trouvé un problème de gestion d'erreur
Dans votre main, vous avez:

Code :

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

1
2
3
4
5
if (!AL->initAllegro(resolution))
    {
        LError << "Fail to init ALLEGRO";
        return EXIT_FAILURE;
    }

Il n'y a pas de nettoyage.
Pourquoi je dis cela, c'est qu'en voyant votre fonction init, on remarque trois initialisation (keyboard / joystick / timer). Si l'un d'entre elle échoue, les autres ne sont pas proprement arrêtées.

Oui exact

Pourquoi la classe Allegro a une BITMAP, si AllegroRenderer en a un aussi ?
_DrawingManager ne serait pas inutile maintenant ?

C'est exact mais c'est déjà le cas ^^, c'est pour cela qu'il y a un underscore dans le nom du fichier, ca veut dire que ce fichier n'est plus utilisé dans le projet

Sinon, mais ceci est a prendre avec des pincettes, selon ce que vous voulez vraiment faire. En théorie, lorsque l'on fait un jeu et que l'on espère en faire un deuxième, on va créer une base de code qui soit réutilisable et surtout, qui ne soit pas attaché à une dépendance qui pourrait gênait (imaginez, vous voulez supporter la GP2X (donc nécessité de la SDL) sans pour autant touché à beaucoup de morceaux dans votre code). Actuellement, il y a une classe Allegro, qui serte, recouvre la bibliothèque Allegro, mais qui ne sépare pas clairement et efficacement la partie application de la partie bibliothèque. Du coup, il faudra changer des choses dans le main (et autres classes) afin de pouvoir avoir la SDL. En théorie c'est ce que l'on essaie d'éviter -> on veut que le changement de bibliothèque est un impact minime sur le reste du jeu. C'est l'objectif qu'il y a dans OpenAWars avec le NEngine.

Alors oui je suis d'accord mais dans tous les cas (même dans votre moteur de jeu) si vous souhaitez utiliser Allegro, il faudra modifier le main et d'autres classes, ne serais ce que pour appeler les fonctions d'init/deinit

Je pense que si on voulait vraiment faire bien les choses, il faudrait créer un manager d'API graphique, avec une interface commune et dont toutes les implémentations différeraient selon la librairie mais c'est galère à faire et puis pour vous dire la vérité, je ne compte pas utiliser d'autre librairie qu'Allegro
Néanmoins, je ne suis pas contre une architecture souple

Sauf que vous, vous brisez ce principe, en présentant des choses (types / fonctions) qui sont spécifiques à Allegro, mais qui ce retrouve dans le reste du code. La classe Allegro, mais aussi les BITMAP*.
Après, je ne peux pas vous dire de refaire un NEngine, car cela dépend de ce que vous voulez vraiment faire.
(Pour éviter d'avoir BITMAP qui se trimballe dans le code, il faut une classe de recouvrement, comme je l'ai fait pour le NEngine, recouvrant SDL_Surface).

Normalement le type BITMAP* (et autres types d'Allegro) sont déjà encapsulés dans la classe ImageManager, il ne devrait pas y avoir de BITMAP* dans une classe extérieure au dossier API...
Le rôle du ImageManager c'est d'associer une BITMAP à un identifiant, comme ca dans les classes, on se balade avec des int et non des BITMAP*

Donc, j'ai du mal à comprendre ce que vous avez voulu dire

Comme me l'avait fait remarquer gbdivers, les types qui sont utilisés dans le moteur, doivent se retrouvé dans le moteur. Soit, le NEngine utilise les types Size / Rect. Du coup, les fichiers .h de ces types se retrouvent dans le dossier du NEngine.

OK mais concrétement ca change quoi ?

Le fichier InputJoystick.cpp inclut allegro.h . Ce fichier n'étant pas dans le dossier api, j'imagine qui se doit d'être indépendant d'une quelconque API. Du coup, l'include vous casse se principe.

Alors là c'est une erreur de ma part, de même que pour InputKeyboard en fait ces deux classes doivent aller dans le répertoire API puisqu'elles sont spécifiques à Allegro.

Il en est aussi du GameEngine, il ne devrait pas être aussi dépendant des trucs d'Allegro. Sinon, pour moi, il devrait se retrouver dans le dossier API.

Oui mais j'arrive pas à séparer la partie gestion du fps qui utilise les timer d'allegro du reste du moteur, mais dans l'absolu je suis d'accord.

ISprite est utilisé un peu étrangement (hérité par AnimatedSprite). L'héritage pouvait être justifié, si les méthode de dessin son identique. Car, l'héritage peut laisser la possibilité d'avoir l'AnimatedSprite dessiner pour un simple ISprite et du coup, on verra le sprites sheet, non?

Pas compris
Les méthodes de dessin ne sont pas les mêmes car pour un sprite normal, on dessine la totalité de l'image et dans le cas d'un sprite Animé, on dessine seulement une partie (choisie à partir de la Sprite Sheet)

Sinon

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
 
bool AnimatedSprite::update(int directions, int buttons)
{
    if (directions != Core::InputManager::D_NONE)
    {
        if (Core::InputManager::isPressed(directions, Core::InputManager::D_RIGHT))
        {
            dir = 2; // right
            pos.x++;
        }
        if (Core::InputManager::isPressed(directions, Core::InputManager::D_LEFT))
        {
            dir = 0;
            pos.x--;
        }
        if (Core::InputManager::isPressed(directions, Core::InputManager::D_UP))
        {
            dir = 3;
            pos.y--;
        }
        if (Core::InputManager::isPressed(directions, Core::InputManager::D_DOWN))
        {
            dir = 1;
            pos.y++;
        }
 
        // mis à jour de l'animation
        animate();
    }
 
    return true;
}

Cela voudrait dire, que tout sprite animé réagirai aux commandes du clavier ?

Justement c'est faux, il y a deux types de sprites animés : en fonction du temps et en fonction des commandes clavier/joystick
Mais comment faire ca ? Créer une autre classe dérivant de ISprite ? à mon avis ce n'est pas une bonne idée

De plus, vos sprite ne sont pas animé par rapport au temps, mais au mouvement. Alors oui, c'est possible, mais que faites vous si les deux sont possibles ? (indice: Surement un design pattern )
Qui, rapidement, pourrait remplacer la lourde implémentation AnimatedSprite / ClassicalSprite, pour d'autre chose, plus joli et plus paramétrable.

Les deux types d'animation en même temps, ce n'est pas possible (enfin je crois) en tout cas dans un Zelda, ca n'existe pas (enfin je crois ).

Alors un pattern, euh.... un pattern stratégie ? avec comme "client" ISprite et une interface IComportementAnimation avec deux implémentations concrètes, une en fonction du temps et une autre en fonction des contrôles clavier/joystick ? (d'ailleurs dans ce cas là, les paramètres à passer ne seront pas les mêmes car dans un cas on a besoin de rien du tout et dans l'autre on a besoin des touches qui ont été pressées, donc comment faire ?)

Pour moi (dans OpenAWars), un AnimatedSprite ayant juste un carré dans la sprite sheet fera exactement ce que fait mon sprite de base. Actuellement, dans le code, il n'y a que des AnimatedSprite, alors que je n'ai aucun sprite animé comme fichier image. Donc j'oserai dire que le ClassicalSprite, à part le comportement est identique au AnimatedSprite.

Sauf que dans Zelda, il y a trois types de sprites : ceux qui bouge pas (pas d'animations), ceux qui bougent grâce au clavier/joystick, et ceux qui bougent en fonction du temps.

Et, nous en venons au monde, qui subit donc les conséquence des problèmes précédents. En effet, vous avez une liste de Sprite. Mais en fait, dans un jeu, ce n'est pas vraiment une liste de Sprite, mais une liste d'entité, qui possède un Sprite et que chaque Entité à un comportement différent. Ce que je veux dire là, c'est que vous ne séparez pas la représentation graphique de votre jeu, avec sa représentation dans le modèle et son comportement au sein du jeu.
Du coup, si vous voulez implémentez un nouveau monstre, avec un nouveau comportement, il vous faudra faire en sorte d'hériter encore de ISPrite et de réimplémenter une partie de AnimatedSprite ... et on ne sait pas quoi d'autre. C'est lourd, je trouve.

C'est exact mais justement comment faire un système souple de gestion des entités (ayant des comportements différents) ?

Je vous conseille de ne pas partir dans tout les sens. Lorsque l'on créer ce style de programme, on fait bloc par bloc. Pour l'instant il est de faire le bloc API / moteur natif. Une fois validé et testé avec des cas simple, vous pourrez faire votre World et toute autre gestion du monde / interactions.
Bon courage

Je suis d'accord avec vous, allons-y doucement ^^
Après pour le tester, je ne vois pas trop comment on pourra faire mais bon

Je vais uploader une version modifiée d'ici au milieu d'aprem je pense avec les corrections

Merci

[LittleWhite]

Le Singleton est souvent considéré comme un anti pattern. L'usage le plus approprié (alors qu'il est très controversé) c'est le Logger. Pour ce cas là, je n'ai pas grand chose à dire, mettre la surcouche d'une bibliothèque en singleton, peut être, mais avec des réserves. Notamment, si un jour vous voulez utiliser d'autres bibliothèques, ou plusieurs bibliothèques à la fois.

Alors comment faire pour encapsuler les fonctions de la librairie Allegro ? faire une classe et déclarer toutes les fonctions statiques ?

Il faut faire une classe du genre CApi qui proposera les fonctions que vous voulez rendre visible par votre moteur. Cette classe est virtuelle pure. Ensuite, cette classe sera hérité par CAllegro, par exemple, qui aura effectivement les fonctionnalités données par Allegro.
Le jour ou vous voudriez changer, il suffira de créer une nouvelle CApi, avec une nouvelle bibliothèque.

Alors oui je suis d'accord mais dans tous les cas (même dans votre moteur de jeu) si vous souhaitez utiliser Allegro, il faudra modifier le main et d'autres classes, ne serais ce que pour appeler les fonctions d'init/deinit

Je pense que si on voulait vraiment faire bien les choses, il faudrait créer un manager d'API graphique, avec une interface commune et dont toutes les implémentations différeraient selon la librairie mais c'est galère à faire et puis pour vous dire la vérité, je ne compte pas utiliser d'autre librairie qu'Allegro
Néanmoins, je ne suis pas contre une architecture souple

Non, en fait, j'ai juste un appel à changer. Celui qui fait que je construit le CAllegro, par exemple. Si je veux autre chose, je construit un CSDL par exemple. Et le reste du code ne change pas, car le reste repose sur CAPI (et utilise juste l'interface).
(Ce qui me permet entre autre, de pouvoir changer d'API à la volée (ou presque)).

Normalement le type BITMAP* (et autres types d'Allegro) sont déjà encapsulés dans la classe ImageManager, il ne devrait pas y avoir de BITMAP* dans une classe extérieure au dossier API...
Le rôle du ImageManager c'est d'associer une BITMAP à un identifiant, comme ca dans les classes, on se balade avec des int et non des BITMAP*

Donc, j'ai du mal à comprendre ce que vous avez voulu dire

En effet, j'avais compris, un peu trop tard.

Toute fois, cela ne fonctionnera pas.
Prenons la ligne du ImageManager:

Code :

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

std::map<int, BITMAP*> data; // les ressources BITMAP du jeu

On remarque que l'ImageManager utilise BITMAP*. Sauf que le jour ou vous devez changer de bibliothèque, comment allez vous faire ?
Il vous faut une interface au dessus de BITMAP. Regarde dans OpenAWars, j'ai bien une interface et mon ImageManager utilise que cette interface (chez moi, cela s'appelle ImageLoader ).

Comme me l'avait fait remarquer gbdivers, les types qui sont utilisés dans le moteur, doivent se retrouvé dans le moteur. Soit, le NEngine utilise les types Size / Rect. Du coup, les fichiers .h de ces types se retrouvent dans le dossier du NEngine.

OK mais concrétement ca change quoi ?

Que le jour où je veux exporter mon moteur, les types sont bien à l'intérieur. Sinon, ça compile pas (en cas d'export du moteur uniquement). Et puis le moteur, logiquement, se doit d'être indépendant du jeu et donc ne pas avoir de dépendance comme avec les types, dans le jeu.

Qu'est ce que cela change concrétement ?

Voir la FAQ C++
Le USize2D fait une copie complète de la structure (8 octets). Le const USize2D, utilise une référence constante (une sorte de pointeur sans certains désavantages) et donc ne copie que la taille d'un pointeur et non la structure entière. Le cas le plus flagrant de perte de performances, c'est avec des std::string (regardez Back 2 Roots (projet de fearyourself), il a eu le problème )

Oui mais j'arrive pas à séparer la partie gestion du fps qui utilise les timer d'allegro du reste du moteur, mais dans l'absolu je suis d'accord.

Faites une interface autour des pointeurs d'Allegro alors

Pour l'histoire des animations de vos sprites, c'est assez compliqué...
Je pense à une solution du type, un AnimatedSprite permet l'animation du sprite (et son affichage). Dans le sens, il calcul le rectangle à afficher. Simplement (sans faire beaucoup plus, même pas d'update).
Et après, vous pouvez utilisez deux autres classes, pour les comportements
Qui eux, implémenteront la méthode update().
Le problème reste sur les paramètres, qui sont différents entre les deux, donc ma solution n'est pas encore parfaite. Mais dans tout les cas, mieux vaut faire un AnimatedSprite encore plus simple / généraliste que dans OpenAWars, et implémenter des comportements par la méthode update (un héritage ?)

[quote)Aspic]C'est exact mais justement comment faire un système souple de gestion des entités (ayant des comportements différents) ?

Une classe généraliste avec une méthode update() virtuelle pure dans une classe Entité. Tout truc qui peut bouger (ou doit changer d'état) héritera de cette classe. Le world contient une liste d'Entite et aura une fonction update mettons à jour toutes les Entité.

Voilà

[Aspic]

Voilà une nouvelle version prenant en compte les remarques précédentes :
http://www.tutoworld.com/temp/zelda_version_3.zip

J'ai corrigé les problèmes de casse sous Linux, j'espère qu'il n'en reste pas (testé sous mon Ubuntu ca fonctionne )

J'ai aussi réussi à séparer la partie Allegro dans le GameEngine grâce à la classe AllegroTimer qui gère odnc les Timers

De même pour le ImageManager, j'ai créé une interface IImageManager pour "encapsuler les BITMAP". cette classe est un singleton (car j'en ai besoin un peu partout pour loader des ressources... à mon avis c'est pas bien ce que j'ai fais )

Pour les sprites, je suis resté sur cette implémentation qui me semble correcte :

+ Interface ISprite
----+ AnimatedSprite => sprites animés via le clavier/joysticks
----+ AnimatedSpriteIA => Sprites animés via l'IA (donc automatiquement) pas besoin des touches
----+ ClassicalSprite => Sprite qui est fixe (pas d'animation)

Je sais que ce n'est pas top mais je n'ai pas trop compris ce que vous entendiez par ca :

Pour l'histoire des animations de vos sprites, c'est assez compliqué...
Je pense à une solution du type, un AnimatedSprite permet l'animation du sprite (et son affichage). Dans le sens, il calcul le rectangle à afficher. Simplement (sans faire beaucoup plus, même pas d'update).
Et après, vous pouvez utilisez deux autres classes, pour les comportements
Qui eux, implémenteront la méthode update().
Le problème reste sur les paramètres, qui sont différents entre les deux, donc ma solution n'est pas encore parfaite. Mais dans tout les cas, mieux vaut faire un AnimatedSprite encore plus simple / généraliste que dans OpenAWars, et implémenter des comportements par la méthode update (un héritage ?)

Si vous avez un exemple d'une meilleure implémentation dans mon cas, je suis preneur

Sinon, j'ai tenté de faire une première implémentation du déplacement des entités :

+ Interface IEntity
----+ Class MovableEntity => entité qui se déplace
----+ Class NonMovableEntity => entité qui ne se déplace pas

De même, j'ai tenté d'implémenter un comportement de déplacement : le player se déplace avec les controles clavier/joystick, les ennemies se déplacent automatiquement. Pour cela :

+ Interface IMoveBehaviour => interface pour le déplacement des entités
----+ Class AutoMoveBehaviour => pour les déplacements automatiques controlé par l'IA (pour les ennemies par exemple)
----+ Class ManualMoveBehaviour => pour le joueur, déplacement "manuel"
----+ Class NoMoveBehaviour => pour ceux qui ne se déplacent pas

Pour aller plus vite, j'ai implémenté les fonctions dans les fichiers headers (c'est pas bien je sais), mais ca sera séparé par la suite dès validation

Voilà, dites moi ce que vous en pensez...

Merci

PS : je n'ai pas vu de ImageLoader dans votre projet OpenAWars

[LittleWhite]

De même pour le ImageManager, j'ai créé une interface IImageManager pour "encapsuler les BITMAP". cette classe est un singleton (car j'en ai besoin un peu partout pour loader des ressources... à mon avis c'est pas bien ce que j'ai fais )

Le nom est horrible. Je pense que ce serait mieux d'appeler ça, juste "IImage".
Ah non, même pas. Le truc, c'est que vous devez n'avoir qu'un seul ImageManager, qui gère toutes les images (qu'elles soient des images Allgero, ou SDL, ou je ne sais pas quoi). Du coup, c'est pour cela qu'il faut une IImage qui cache l'implémentation réelle des images.
Si on allait plus loin, en fait, le ImageManager hériterai d'un simple Manager, en ajoutant quelques fonctionnalités.

Comme tout autre élément, afin de changer facilement de bibliothèque, il vous faudra une interface aussi pour les Timer.

+ Interface ISprite
----+ AnimatedSprite => sprites animés via le clavier/joysticks
----+ AnimatedSpriteIA => Sprites animés via l'IA (donc automatiquement) pas besoin des touches
----+ ClassicalSprite => Sprite qui est fixe (pas d'animation)

ça ne va pas, car AnimatedSprite et AnimatedSpriteIA possède deux fois la même fonction. Et l'une des règles de programmation est de ne jamais faire de copier / coller.
Mais comme je n'ai pas de bonne façon de faire pour votre problème, je suis un peu perdu.

Et ce que j'essayais de dire, c'est qu'un sprite animé, auquel on lui donne une seule image (ou un seul rectangle, de toute l'image) aura un comportement identique à un simple sprite (il affichera normalement, le sprite).

Pourquoi une IEntity possède une taille ?
Pourquoi elle possède aussi un flag de visibilité.

En fait, une entité pourrait être décomposé en deux sous parties, l'entité graphique (le sprite et les paramètres du sprite) et l'entité physique (bounding box, par exemple). Mais c'est juste un exemple.

L'idée des IMoveBehaviour, c'est sympa, mais pourquoi ne pas avoir utilisé les politiques ? -> http://en.wikipedia.org/wiki/Policy-based_design ou http://alp.developpez.com/tutoriels/traitspolicies/#LII

[Aspic]

Bonjour à tous !

Je déterre 5 ans après l'un de mes vieux posts

J'ai toujours été passionné par ce projet Zelda que j'ai commencé en 2010 et terminé une démo en 2012. J’ai pu relire les derniers posts et les discussions avec LittleWhite (que je remercie de m'avoir beaucoup aidé à cette époque ).

Je ne sais pas si cela intéressera quelqu'un mais j'ai à nouveau commencé un nouveau projet Zelda en janvier 2018 sauf que cette fois ci j'ai 10 ans d'expérience en C++, je maitrise le C++14, je connais mieux la conception, j'ai créé une IA sur le jeu Sokoban, j'ai appris de mes erreurs ...

Pour tout vous dire, voilà un avant goût du projet :

• Implémentation d'un moteur de jeu 2D
• Implémentation du jeu utilisant ce moteur 2D
• Environ 17 000 lignes de code réparti en 215 fichiers
• Démo prévue pour début juin 2018 !

Si des personnes sont intéressées, je détaillerai l'avancement minutieusement

PS: Je me demande si je ne vais pas créer un autre topic ?

Merci à ceux qui auront pris le temps de me lire

[LittleWhite]

Toujours intéressé (et je suis toujours là !).

Environ 17 000 lignes de code réparti en 215 fichiers

Ca me semble énorme (sans que cela soit mal, j'ai calculé, c'est une moyenne de 80 lignes par fichier). Pouvez-vous nous en dire plus sur les fonctionnalité du moteur ?

[Aspic]

Bonjour Littlewhite, ca faisait longtemps !

17 000 lignes de code ca peut paraitre beaucoup mais en fait non ce n'est pas énorme. Le découpage est le suivant : 3600 lignes pour le moteur de jeu 2D (50 fichiers) et 13 000 lignes pour le jeu (160 fichiers)

Pouvez-vous nous en dire plus sur les fonctionnalité du moteur ?

J'utilise une approche orientée données (composition) cette fois ci contrairement à une approche objet (héritage) comme il y a 7 ans. Tout le moteur de jeu est basé sur un ECS (Entity Component System), une sorte de gros design pattern bien adapté aux jeux vidéos. J'ai découvert ce concept et j'ai tout de suite voulu essayer sur un Shoot'em up que j'ai codé en 6h. J'ai vu la puissance de ce design et je me suis dis que j'allais retenter ma chance sur mon projet Zelda datant de 2011 et je ne regrette pas.

Globalement les fonctionnalités du moteur sont basiques mais suffisantes pour faire 80% des jeux 2D :

• gestion des entités (création, destruction...)
• gestion des composants (ajout, suppression)
• gestion des systèmes (ajout, suppression, activation, désactivation)
• système de filtrage des entités (un système peut agir uniquement sur certains types de composants)
• gestion mémoire par des pool d'objets (accès aux éléments en O(1))
• enregistrement d'entités spécifiques pour un accès performant (exemple : le joueur)
• possibilité d'attacher un gestionnaire de contrôle des touches (joystick, clavier...)

Concernant le jeu en lui même, je pars sur un remake de Zelda Link Awakening car c'est mon jeu préféré sur GB (avec Ocarina Of Time sur N64 !). Voici un rapide récapitulatif de l'avancement :

1) Items du jeu :

• Epée : terminée à 90%
• Bouclier : terminé à 90%
• plume : terminée à 100%
• boomerang : terminé à 100%
• grappin : terminé à 100%
• poudre magique: terminé à 100%
• bracelet de force : terminé à 100%
• bombe : terminé à 80%
• arc : terminé à 100%
• pelle : non commencé
• bottes : non commencées

2) Gestion des maps (overworld, cave et donjons) : terminée à 100% (moyennement la création des maps avec un logiciel de tilemapping)
3) Ennemies : actuellement 9 types sont implémentés

3) Donjons :

• Gestion des portes : terminée à 100%
• gestion des portes à clés : terminée à 100%
• Gestion des énigmes : 3 types d'énigmes implémentées (tuer tous les ennemies dans une salle, allumer des torches, pousser des blocs)
• carte / boussole du donjon : terminée à 100%
• clés et clé du boss : terminée à 100%
• téléporteur mi-donjon : en cours
• mini-boss : non commencé
• boss : non commencé

Et plein de petits trucs... la démo sera plus parlante

[dragonjoker59]

Je pense plutôt que c'est le 251 fichiers pour 17000 lignes, qui fait beaucoup.
17000 lignes c'est pas énorme, mon moteur en est à 16000 lignes de code executable (pour un total de 490000 lignes en 2983 fichiers)

[Aspic]

Bonjour à tous,

Comme promis, voilà la toute première démo du remake de Zelda Link's Awakening sur GameBoy.

Les contrôles se font au clavier (AZERTY) :
- W et X sont les touches action (équivalent des touches A et B sur Gameboy)
- Entrée est la touche START
- Les directions se font avec les flèches du clavier

Le jeu est un remake total du jeu original. Je ne compte pas changer le gameplay qui restera donc fidèle à l’original. Ceux n’ayant jamais joué aux Zelda sur GameBoy devront découvrir cette expérience de jeu

Évidemment le but est de le tester en faisant un peu n'importe comment. Je suis persuadé que vous arriverez à faire planter le jeu
J'ai laissé volontairement la console de log afin que vous puissiez faire une capture d'écran en cas de bug, histoire que je me repère un peu

Le lien de téléchargement :
http://codeanalysis.fr/ZeldaLinkAwak...-firstdemo.exe

Amusez vous bien !

N'hésitez pas à me donner vos avis (positifs ou négatifs) sur ce projet.

PS: Il existe pas mal de choses déjà implémentées dans le jeu mais non visible dans la démo (par exemple les items boomerang, grappin, bouclier...)

[LittleWhite]

Je ne me rappelle pas que l'on puisse accéder au menu pendant les dialogues .
La transition entre les cartes rament quelques fois, je crois que c'est lorsque c'est du bas vers le haut et de gauche vers la droite.
Dommage que les boutons A/B sont inversés par rapport à ce qui est indiqué à l'écran (genre A, à gauche alors que affiché à droite dans l'HUD)
Pour les piques qui se déplace en ligne, il y a un temps d'attente avant de foncer à nouveau sur le joueur (salle à droite de l'entrée dans le donjon). D'ailleurs, je les ai planté
Je ne peux pas quitter avec la croix.

[Aspic]

Je ne me rappelle pas que l'on puisse accéder au menu pendant les dialogues .

A vérifier, je ne me souviens plus mais en soit ce n'est pas un soucis

La transition entre les cartes rament quelques fois, je crois que c'est lorsque c'est du bas vers le haut et de gauche vers la droite.

Ah sur mon PC je n'ai jamais eu de lag. Sur quelle machine faites vous le test ? (CPU, Ram et OS). Est ce que dans la console lors de ces transitions lentes, vous avez un message du genre "*** Rendering too slow *** Need to update X times !", si oui qu'elle est la valeur de X ?

Dommage que les boutons A/B sont inversés par rapport à ce qui est indiqué à l'écran (genre A, à gauche alors que affiché à droite dans l'HUD)

Oups cela n'est pas normal, je ne m'en suis jamais rendu compte donc je le corrigerais

Pour les piques qui se déplace en ligne, il y a un temps d'attente avant de foncer à nouveau sur le joueur (salle à droite de l'entrée dans le donjon). D'ailleurs, je les ai planté

J'étais au courant de ce bug, il y a même un autre bug avec ce type d’ennemie mais je suis entrain de réfléchir à une autre manière d'implémenter leur comportement.

Je ne peux pas quitter avec la croix.

Normal, c'est la touche ECHAP pour quitter, désolé j'ai oublié de le préciser dans les contrôles. La croix devrait même être désactivée.

Merci pour ces premiers retours

PS: Oui il y a une partie de l'overworld qui n'est pas terminée, je m'en suis rendu compte un peu tard mais cela sera corrigé évidemment dans la prochaine version.

[LittleWhite]

En effet, j'ai du Rendering too slow :

Loading i data :
[ x] = [80]
[ y] = [48]
[ type] = [0]
[ idTeleport] = [3001]

*** Rendering too slow *** Need to update 12 times !
Entity LINK state changed to 0
fps = 219 - Nb entities = 86 (update 2113 / draw 9091)

À cause du chargement des données, j'imagine. Mais cela n'arrive pas sur toute les zones, notamment, je n'ai pas du tout le souci en 3,1.

La sauvegarde était bien présente, mais cela me fait recharger à la maison et sans mes objets .

[Aspic]

En effet, j'ai du Rendering too slow :

À cause du chargement des données, j'imagine. Mais cela n'arrive pas sur toute les zones, notamment, je n'ai pas du tout le souci en 3,1.

La sauvegarde était bien présente, mais cela me fait recharger à la maison et sans mes objets .

Pouvez vous me dire les performances de votre PC de test et son système d'exploitation ?

Pouvez vous faire les tests suivant ?
1) Entrer dans la zone (2, 3) peu importe la direction -> est ce que ca lag ?
2) Sortir de la zone (2, 3) peu importe la direction -> est ce que ca lag ?
3) Entrer dans la zone (2, 1) peu importe la direction -> est ce que ca lag ?
4) Entrer dans la zone (2, 0) peu importe la direction -> est ce que ca lag ?

La sauvegarde était bien présente, mais cela me fait recharger à la maison et sans mes objets

Je n'ai pas compris le soucis...

Merci

[Aspic]

Si vous souhaitez suivre l'avancement de ce projet :
http://codeanalysis.fr/zelda

J'ai sorti la version démo 1.2 qui corrige quelques bugs

[LittleWhite]

Vous produisez que des .exe (ce n'est pas un mal, j'ai utilisé Wine la dernière fois). Est-ce parce que le code n'est pas portable ?

[Aspic]

Oui je travaille sous Windows et une partie du code n'est pas portable.
A termes, je pourrais le rendre compatible Linux mais pour l'instant ce n'est pas la priorité