[C/C++][SFML][Algo & conception] Conception - RPG 2D SFML/C++

[AlastorS]

Bonjour,

Je créer ce post a des fin particulière qui vont me servir, mais pourrons servir aussi a d’autre je pense..

Bref, j’avais commencé l’année dernière en décembre un RPG 2D en C++/SFML..
J’aimerais qu’il reste du C++/SFML brut, donc pas de script lua, etc.

J’ai mis mon projet en stand by depuis le mois de janvier par manque de motivation mais aussi comme je me trouve dans une impasse..

J’ai un moteur de jeux stable, qui fonctionne par état ( pas franchement avancé comme méthode mais bon ca marche ^^ ), qui gèrent la GUI sans problème, j’ai aussi déjà pas mal de fonction, de classes implémenté …

Mais la ou je bloque, c’est sur ce que j’appellerais le moteur de carte..
Avoir un moteur capable de sauvegardé, éditer et créer des cartes 2D like un éditeur a la sauce RPG Maker, mais aussi pouvant être réutilisé dans mon jeux pour charger, géré les maps, les events qui y sont associé, les PnJ, avec des pointeurs vers les monstres que l’on peut rencontrer, etc.

Bref j’ai déjà une bonne idée de a quoi cela pourrait ressembler …
4 std ::vector qui contiendrais des classes fille de sf ::Sprite, avec contenu dans ces classe fille les info : bool colision, int posX, int posY, etc..
1 std ::vector qui contiendrais des classes events qui aurait aussi des info du genre : quel type d’event, ce qu’il fait, bool unique, etc ..
1 std ::vector qui contiendrais les PNJ ..
Plus : les fichiers en eux même nécessaire à la map comme les tileset, les son …

En gros je voudrais disposer d’un fichier Map unique … sans avoir besoin des sources ( image, son, etc ) nécessaire à coté =)
Et ce n’est encore qu’a l’état de schéma dans ma tête..

C’est pour quoi je viens vous demandé.. Non pas de le faire a ma place mais de bien vouloir me guidé a travers mon projet …
Je sais que mon moteur de jeux est loin d’être parfait =x Que d’utilisé des état et loin d’être optimisé..
Et comme j'envisage de réécrire en entier mon programme,
J'aimerais éviter de refaire certaines erreur ^^

Donc en gros je demande :
-
si l'utilisation de "state" et pas trop lourd vu qu'a chaque fois il doit test toutes les valeur via un switch ...
Si y'a mieux on peut m'expliquer quoi s'il vous plait ^^

- qu'on maide au niveau de mon moteur de carte .. genre comment on ajoute et gère dans mon fichier ".map" une image, un son, comment on y sauvegarde des vector .. et comment on les recharge ...

( 5 mois de break ca fait mal ^^ )

Voilà, désolé d'avoir pondu un pavé :P Mais sa montre que je mets pas se post pour rien ^^
Et j'éspère que je n'aurais que des réponse constructif .. qui on pour but de critiqué en bien ou en mal mon projet ... mais constructivement ( copyright by me pliz x_x ) quoi xD

PS : si je me suis mal exprimé a certains endroit :x désolé j'essairais d'eclaircir ca en rentrant :/

[Gabriel]

Bonjour,

Serait il possible que tu fasses (ou fournisses) un schéma décrivant ta conception actuelle ? (UML ou autre) afin que ta vision des choses soit plus facile à comprendre, merci.

En gros je voudrais disposer d’un fichier Map unique … sans avoir besoin des sources ( image, son, etc ) nécessaire à coté =)
Et ce n’est encore qu’a l’état de schéma dans ma tête..

Je vois pas l'intérêt de tout regrouper dans un fichier unique au lieu de faire des chemins relatif vers les données, pourrais tu développer ton idée derrière ça ?. Un premier problème de ce genre de solution qui me passe par la tête est le fait qu'une ressource ne soit pas forcément utile et elle sera charger inutilement. Un deuxieme problème plus génant est la duplication de ressource, effectivement un son ou autres ressources identique dans 10 cartes différentes sera dupliquer 10 fois.

si l'utilisation de "state" et pas trop lourd vu qu'a chaque fois il doit test toutes les valeur via un switch ...
Si y'a mieux on peut m'expliquer quoi s'il vous plait ^^

Souvent, c'est pas le modèle de conception qu'on utilise qui est mauvais mais l'implémentation, je trouve que l'utilisation de "game state" (j'ai compris que tu utilisais ceci) est tout à fait adapté, après la manière dont tu l'as implémenté est peut être à revoir, pour cela, il nous faudrait ton code actuel + schéma si tu as pas mal de classes (pour faciliter la compréhension).
Mais l'utilisation de game state ne passe pas forcément pas un switch.

- qu'on maide au niveau de mon moteur de carte .. genre comment on ajoute et gère dans mon fichier ".map" une image, un son, comment on y sauvegarde des vector .. et comment on les recharge ...

Pour ta carte, déjà tu pourrais regarder au niveau de la persistence des objets (sérialisation/désérialisation). Après il faudrait que tu développes un peu plus ta conception actuelle comme dit plus haut, et dire tes contraintes techniques aussi.
Une solution assez classique pour gérer les ressources dans des fichiers, c'est de faire des chemins relatifs vers ces données, qui, après son charger par les différents gestionnaires de ressources. La sauvegarde d'un vecteur, ça dépend énormement, mais tu peux imaginer des données du type :

Code: Tout sélectionner

1 5 1 54 87 92
3 9 1 5 87 3
10 5 1 6 87 2
1 5 1 5 87 9
2 4 1 5 87 9


Ici, une garde 6x5 "tiles", ou chaque nombre est un identifiant vers une ressource détaillé dans le fichier (savoir quelle image charger, quel son charger, quel script utiliser, etc.)

[AlastorS]

Je vais essayé de te faire quelques choses de propres pour demain ^^
Bonjour Gab au faite, ca fait longtemps que je suis pas venu sur le chan irc ^^

[Mokona]

Hello,

4 std ::vector qui contiendrais des classes fille de sf ::Sprite, avec contenu dans ces classe fille les info : bool colision, int posX, int posY, etc..

Ici, je vois un problème de conceptualisation. Ces classes filles (appelons les GameEntity), ne sont pas des sf::Sprite mais utilisent des sf::Sprite. En ce sens, il n'est pas bon de dériver GameEntity de sf::Sprite.

Fait plutôt du sf::Sprite un membre de GameEntity.

Le jour où tu auras besoin qu'une GameEntity manipule deux sprites ou plus suivant son état, tu seras bien content.

Et sinon, pourquoi 4 std::vector ?

En gros je voudrais disposer d’un fichier Map unique … sans avoir besoin des sources ( image, son, etc ) nécessaire à coté =)

Pour répondre à Gabriel, ceci peut-être utile si on veut livrer une map indépendamment des autres.

Mais comme le dit Gabriel, cela pose un problème de redondance de données entre les maps.

Si tu veux vraiment éviter la multitude de fichiers, pousse le concept plus loin et mets toutes tes données dans un seul gros fichier.

Cela nécessite une couche d'accès à ce gros fichier en tant que système de fichier virtuel. C'est du boulot.

- si l'utilisation de "state" et pas trop lourd vu qu'a chaque fois il doit test toutes les valeur via un switch ...

Je ne comprends pas bien de quel "state" il s'agit.

Par contre, tester un switch à chaque fois, dans beaucoup de cas en C++, est un mauvais signal.

[teto]

Avoir la map dans un seul fichier, ca se fait facilement tu le zippes
Sinon tu peux utiliser ca:
http://www.sfml-dev.org/wiki/fr/tutoriels/formatdat

Mais ca peut etre genant pdt le dév donc je te conseillerai de faire ça à la fin plutot, une fois que le systeme de map.

Tu peux essayer de regarder les sources de HolySpirit (autre projet C++/SFML), doit y avoir des choses sympa dedans au niveau de la carte.

Utiliser un langage de script peut te faciliter certaines taches (ca evite de tt recompiler à chaque fois et la gestion des evenements peut se faire bien plus facilement/souplement) mais bon c toi qui voit.

[Mokona]

Ah oui, sinon, pour aller chercher indifféremment de la source des fichiers (zip, fichier séparés), on peut utiliser ça : http://icculus.org/physfs/

[AlastorS]

Ouaa x'D
Je suis entrains de repondre a tout le monde dans un unique post x'D évité de repondre entre temps x'D

Je vais voir apres ton liens Mokona =x

[teto]

Merci pr le lien mokona, ca rox ta lib

[valentin]

Ouaa x'D
Je suis entrains de repondre a tout le monde dans un unique post x'D évité de repondre entre temps x'D

Je vais voir apres ton liens Mokona =x

Punaise, elle doit commencer à être longue la réponse .

[AlastorS]

Nan juste que j'ai un irl chargé ...
Une VDM ...

Mais je rep sur un fichier .txt que je copierais quand j'aurais finit x_x ...
Désolé d'être long .. mais bon ..

[AlastorS]

@ Gabriel : Flemme de faire un UML x)
Je code seul donc sa me sert a rien ^^

Bref :
-Pour les fichiers uniques : J'avoue que tu a raison pour ce qui est des chemins relatifs .. Lourd, parfois on s'en sert pas .. donc oui mieux vaut au pire rassemblé toutes mes ressources dans un fichier type ".big" comme fait EA .. du genre : Image.dat, Audio.dat ...
Ce que je cherchais avant tout, c'était empêcher que les fichiers puissent être modifier .. Et puis surtout que je voulais apprendre a faire des fichiers uniques capable de fonctionné indépendamment les uns des autres ...
Mais je vais faire comme tu la suggéré =)

-Pour les games states : Pourrait tu me faire une implémentation de ce que tu appellerais correct ??
Parce que en gros je fait une boucle infini qui ne s'arrête que lorsque le switch appelle une fonction StopGame();
Donc dans le switch, je test un state_valeur, et en fonction de ce state_valeur, j'apelle tels ou tels fonction ... par exemple :

Code: Tout sélectionner

Switch state
{
case 1:
MenuMainGUI();

case 2:
MenuLoadGUI();

case 4:
MapGUI();

case 5:
MenuGameGUI();

case 6:
StopGame();
}

Bon ce n'est qu'un exemple, mais en gros sa ressemble a ca ... :/

-Au niveau de la Map : Bon en gros c'est une map like RPG Maker, 4 couche pour la map ... Dont une pour les Event, PNJ .. et trois pour les couche paysage ...
De plus j'aimerais pouvoir géré des changement d'heure, météo, etc .. avec un basculement jour nuit ... 'fin bref pas mal de boulot j'implementerais ca quand j'aurais de bonne base qui fonctionne ..

@Mokona : L'idée des GameEntity ... je retiens
Je vais essayé de développer ton idée ca peut etre intéressant mais dois je faire de sf::sprite un membre public ou priver ??
Parce que ca m'obligerais a faire des fonctions pour modifier ou recuperer le sf::sprite en private .. :/

J'ai décrit les 4 std::vector au dessus 4 Couche like RPGMaker ...

Pour ce qui est du fichier uniques .. je vais me tourné vers ca mais sur plusieurs fichier uniques qui contiennent chacun un type de ressource ( img, audio, etc )

Pour le switch ... tu peux le voir au dessus si tu a quelques choses de mieux a me proposé Je suis preneur et j'aime bien apprendre de nouvelle chose :P

@teto : Pas envie de zippé, et j'ai déjà ce tuto ...
Mais il ne traite pas d'un fichier unique avec des sous dossier ..
Et au vue de mon niveau actuel, vu que j'ai appris tout seul, ne me permets pas encore de résoudre ce genre d'interrogation sans grande perte de temps et performance ^^

Et oui je sais que les scripts facilite les choses mais voila si javai voulu faire quelques choses de basique je serais pas la et j'aurais déjà finit je pense ^^
J'ai déjà réalisé des touts piti mini jeux pour mes petits frères et sœurs ^^

Et re @Mokona :
J'ai ouvert ta page
C'est en anglais ^^ je suis pas trop nul mais bon flemme x'D
Si je montre trompe pas, c'est pour utilisé des Zip non ??
Mais je veux créer mon propre type de fichier ..
Je pense quand même que je pourrais y trouvé quelques truc intéressant ...

--------------------------------------------

Désolé d'avoir tardé a rep
Imprévu la semaine dernière ... un poto d'Alsace et redescendu et a passé la semaine chez moi ^^
Du coup carnage ^^

Voilou les gens
Merci pour vos réponse :P

[valentin]

Juste au passage, le zip n'est pas obligé d'être compressé, ce qui facilite énormément sa lecture, et tu peux facilement te faire une toc de ce qu'il contient pour acceder direct à la ressource dont t'as besoin.

[Mokona]

@ Gabriel : Flemme de faire un UML x)
Je code seul donc sa me sert a rien ^^

Tu n'es pas obligé de faire de l'UML pour tout ce que tu fais tout seul. Par contre, pour communiquer tes idées, c'est pratique.

Une idée, pour montrer des schémas de ce que tu as déjà fait, c'est d'utiliser un éditeur (genre BoUML) et de faire du Reverse sur ton code. Reste alors à arranger ce que tu veux montrer.

Ce que je cherchais avant tout, c'était empêcher que les fichiers puissent être modifier ..

Je t'arrête tout de suite dans cette voie : tu peux rendre difficile la modification des fichiers. Mais tu ne peux pas l'empêcher si ceux-ci se trouvent sur la machine du joueur.

En fait, même si les fichiers sont chargés à distance sur un serveur, il est possible (pas trivial, mais possible) de les modifier (sans toucher au serveur).

Donc dans le switch, je test un state_valeur, et en fonction de ce state_valeur, j'apelle tels ou tels fonction ...

La façon de faire classique, pour éviter les gros switch très rapidement illisibles, est d'avoir une classe abstraite "State" avec une virtuelle pure "void Process();" que tu spécialises pour chacun de tes states.

Ton switch se transforme alors en : currentState->Process();

Voici un petit code de base, qui fonctionne même si c'est juste une base :

Code: Tout sélectionner

#include <iostream>

class State;

class StateManager
{
public:
    StateManager()
        : currentState(NULL)
    {}

    void Step(); // Implemented below State

    void SetNextState(State * nextState)
    {
        currentState = nextState;
    }

    State * GetCurrentState() const
    {
        return currentState;
    }

private:
    State * currentState;
};

class State
{
public:
    State(StateManager * _stateManager)
        : stateManager(_stateManager)
    {}
    virtual ~State() {}

    virtual void Process() = 0;

protected:
    StateManager * stateManager;
};

void StateManager::Step()
{
    if (currentState)
    {
        currentState->Process();
    }
}


class FirstState : public State
{
public:
    FirstState(StateManager * _stateManager)
        : State(_stateManager)
        , nextState(NULL)
        , endState(NULL)
        , callCount(0)
    {}
    virtual ~FirstState() {}

    void SetNextState(State * _nextState)
    {
        nextState = _nextState;
    }

    void SetEndState(State * _nextState)
    {
        endState = _nextState;
    }

    virtual void Process()
    {
        std::cout << "In the first State\n";
        ++callCount;

        if (callCount == 10)
        {
            stateManager->SetNextState(endState);
        }
        else
        {
            stateManager->SetNextState(nextState);
        }
    }

private:
    State * nextState;
    State * endState;
    int callCount;
};

class SecondState : public State
{
public:
    SecondState(StateManager * _stateManager)
        : State(_stateManager)
        , nextState(NULL)
    {}
    virtual ~SecondState() {}

    void SetNextState(State * _nextState)
    {
        nextState = _nextState;
    }

    virtual void Process()
    {
        std::cout << "In the second State\n";
        stateManager->SetNextState(nextState);
    }

private:
    State * nextState;
};

class EndState : public State
{
public:
    EndState(StateManager * _stateManager)
        : State(_stateManager)
    {}
    virtual ~EndState() {}

    virtual void Process()
    {
        std::cout << "Bye bye.\n";
        stateManager->SetNextState(NULL);
    }

private:
    State * nextState;
};

int main()
{
    StateManager * stateManager = new StateManager();
    FirstState * firstState = new FirstState(stateManager);
    SecondState * secondState = new SecondState(stateManager);
    State * endSate = new EndState(stateManager);

    firstState->SetNextState(secondState);
    firstState->SetEndState(endSate);
    secondState->SetNextState(firstState);

    stateManager->SetNextState(firstState);

    while (stateManager->GetCurrentState())
    {
        stateManager->Step();
    }

    return 0;
}



Parce que ca m'obligerais a faire des fonctions pour modifier ou recuperer le sf::sprite en private .. :/

La question est : est-ce que tu as besoin de le récupérer ? pour en faire quoi ?

(j'imagine bien les réponses, mais il faut se poser les question pour choisir s'il doit être public ou privé... en sachant qu'il devrait être privé )

Si je montre trompe pas, c'est pour utilisé des Zip non ??

Oui et non. C'est pour utiliser une série de fichiers de type packés (dont zip) ou des morceaux de ce qu'il y a sur le système de fichiers directement et fournir une vue unique au programme à partir de tous ces morceaux.

Mais je veux créer mon propre type de fichier ..

Si tu veux faire des recherches sur ce sujet, pourquoi pas, oui.

[Gavos]

Si j'étais toi AlastorS je ne me prendrais pas la tête comme ça. Fais d'abord un RPG qui marche bien avec des cartes en clair (et éventuellement dans plusieurs fichiers). Ça te permettra d'avancer en plus ce sera plus facile de débugguer en cas de soucis.

Puis une fois arrivé au bout, essaie de trouver une solution pour rendre difficile la modification de ces maps en les mettant dans un fichier, en cryptant, etc.

[Mokona]

Très bonne suggestion.

Que je pousse un peu plus loin en te donnant une idée pour préparer le terrain : fait-toi un système d'accès aux fichiers (c'est-à-dire, n'appelle pas d'ouverture/lecture de fichier directement).

Ce système d'accès, dans un premier temps, cache juste les appels direct aux fichiers.

Dans un second temps, tu pourras brancher derrière un système avec fichiers compactés, cryptés,... comme tu veux. Sans avoir à modifier ton programme.

[AlastorS]

Merci pour ton bout de code Mokona =)
J'ai compris comment je devais m'y prendre

Pour les fichiers .. Je me doute que de toute manière ils seront forcement modifiable ^^
Je voudrais juste que ca ne soit pas simple ^^

Pour les sf::sprites,
Oui j'ai besoin d'y avoir un accès direct seulement pour l'éditeur de map a la rigueur.
Vu que dans le jeu en lui même, on ne nécessite que de vérifier les membres de GameEntity genre "bool collision", etc.

Donc en gros, dans le GameEntity j'aurais simplement besoin d'une fonction qui renverrais mon Sprite dans le jeu, du genre :

Code: Tout sélectionner

pWindow->Draw( GE->GetSprite() );

Code de démonstration hein ^^
Et donc tout ce qui est info de mon sf::Sprite serait contenu dans mon GameEntity ... et au moment ou j'apelle GetSprite(), j'initialiserais mon sf::Sprite ??

@ Gavos : J'avais commencé a faire mon RPG comme ca =)
la v0.2 ... mais voila, j'ai laissé tombé, j'avancais assez vite sans pour autant faire ce que j'attendais de moi =x
Donc j'ai recommencé ^^
Tout ce qui est fonctions pour géré les Item, Combat, etc. sont déjà prête ... bon pas top optimisé mais fonctionne déjà ...
La seul truc dont j'ai besoin now c'est de mon moteur de carte =)

Il me reste quelques rares petites classe et fonction a implémenté =)
Du genre gestion Save/LoaD ou encore pour affiché les dialogues ...
Rien de bien méchant =)

Des que mon moteur de carte et son éditeur fonctionneront, je serais a même de vous fournir une petite démo avec deux map ... des combats ( avec le PJ principal et trois classes de monstres déjà implémenté ) .. des marchands, dialogues ou autres action ^^

J'avouerais que j'ai limite honte de buté sur les cartes =x

EDIT : Par contre j'avoue que je suis toujours indécis quant a la réalisation de mon éditeur de map :/
Qu'elle outils utilisé ... Flemme d'apprendre QT .. alors que je connais GTK .. mais GTK ne peut pas utilisé l'interface de la SFML ..
>.< manque de motiv je vais dire ^^

EDIT 2 :
"Que je pousse un peu plus loin en te donnant une idée pour préparer le terrain : fait-toi un système d'accès aux fichiers (c'est-à-dire, n'appelle pas d'ouverture/lecture de fichier directement)"
Tu pourrais développer que je vois si oui ou non j'ai compris x')

[Mokona]

Donc en gros, dans le GameEntity j'aurais simplement besoin d'une fonction qui renverrais mon Sprite dans le jeu, du genre :

Code: Tout sélectionner

pWindow->Draw( GE->GetSprite() );

Pourquoi pas. Il y a d'autres solutions.

Et donc tout ce qui est info de mon sf::Sprite serait contenu dans mon GameEntity ... et au moment ou j'apelle GetSprite(), j'initialiserais mon sf::Sprite ??

Je ne suis pas très fan de ce genre de choses.

Par contre j'avoue que je suis toujours indécis quant a la réalisation de mon éditeur de map :/
Qu'elle outils utilisé ... Flemme d'apprendre QT .. alors que je connais GTK .. mais GTK ne peut pas utilisé l'interface de la SFML ..

J'aurais tendance à dire : utilise ce que tu connais. Mais je ne connais pas les limitations actuelles de SFML.

Pour SFML, quel est le problème ?

"Que je pousse un peu plus loin en te donnant une idée pour préparer le terrain : fait-toi un système d'accès aux fichiers (c'est-à-dire, n'appelle pas d'ouverture/lecture de fichier directement)"
Tu pourrais développer que je vois si oui ou non j'ai compris x')

Par exemple, une classe abstraite "FileSystem" avec comme méthode "CreateFile" "DeleteFile" "OpenFile" qui respectivement renvoient ou utilisent un objet "File".

Une classe abstraite "File" avec les méthodes "Read" "Write".

Dans ta première implémentation, "FileSystem" est en fait une instance de "DirectFileSystem" dont les trois méthodes appellent les fonctions d'accès aux fichiers de l'OS et qui manipulent des "DirectFile" dont les méthodes font de même.

Une encapsulation toute simple.

Plus tard, tu pourras créer "ArchiveFileSystem" et "ArchiveFile" qui accèderont de la manière dont tu as décidé à ton ou tes fichiers "aggrégés".

Un code exemple complet est un poil plus long à écrire que pour les states, donc je m'arrête là.

[Gavos]

Donc en gros, dans le GameEntity j'aurais simplement besoin d'une fonction qui renverrais mon Sprite dans le jeu, du genre :
Code:
pWindow->Draw( GE->GetSprite() );

Tu peux aussi demander au GameEntity de s'afficher, et alors la GameEntity affichera son sprite.

Code: Tout sélectionner

void GameEntity::Draw()
{
   window->Draw(sprite); // "sprite" est membre de GameEntity
}

C'est dommage d'initialiser le sprite sur un Get, ça veut dire que tu pourrais manipuler des GameEntity qui ne sont pas "complets" jusqu'au premier appel au Get. Or il est important de pouvoir être sûr de l'état de tes objets à tout moment. Initialise ton sprite à la construction du GameEntity, ou bien avec une méthode dédiée appelée explicitement.

[AlastorS]

Je note ta solution Mokona =)

Et ok ^^ Mauvaise idée d'initialiser mon sprite au moment du Get() ^^

Je n'ai pas encore vu qu'on pouvais utilisé GTK pour affiché du SFML :/
Je veux dire on peut intégrer la SFML au module d'affichage de QT ... alors que GTK il me semble que non ...

Je plancherais sur ton développement Mokona x')
Même si j'avoue que j'ai toujours pas saisie ^^

En tout cas je me rend compte que j'ai encore pas mal de chose a apprendre =P
Merci de m'aidé en tout cas

[Mokona]

J'ai trouvé ça pour SFML/GTK+, je ne sais pas si ça peut être un point de départ.

http://www.sfml-dev.org/wiki/en/sources/gtksfmlwidget

[AlastorS]

Effectivement gtkmm semble être une version GTK pour C++ ...
Et aussi une bonne base a travaillé ...

Donc y'aura surement des différence a noté :/
Limite je me mets a QT quoi :/

Je vais y réflechir ^^

[AlastorS]

Une petite interrogation :

Code: Tout sélectionner

#ifndef MAINSTATE_HPP
#define MAINSTATE_HPP

#include "State.hpp"
#include "../manager/StateManager.hpp"

class MainState : public StateClass
{
public:
    MainState(StateManager*);
    virtual ~MainState() {};

    void SetNextState(StateClass*);

    void SetEndState(StateClass*);
#
    virtual void Process()
    {
        stateManager->SetNextState(nextState);
    }
#

private:
    StateClass* nextState;
    StateClass* endState;
};

#endif


Code: Tout sélectionner

#include "MainState.hpp"
#include "../manager/StateManager.hpp"
#include <iostream>

MainState::MainState(StateManager* _stateManager) : StateClass(_stateManager)
{
    nextState = NULL;
    endState = NULL;
}

void MainState::SetNextState(StateClass* _nextState)
{
    nextState = _nextState;
}

void MainState::SetEndState(StateClass* _nextState)
{
    endState = _nextState;
}

#
virtual void MainState::Process()
{
    stateManager->SetNextState(nextState);
}
#


Les parties concerné sont entre "#" ...
Je veux dire que quand je déclare Process() dans le header je n'ai aucun problème ...
Par contre si je le déclare dans le source ...
Il refuse de compiler :

Code: Tout sélectionner

-------------- Build: Debug in World of Fantasy ---------------

Compiling: state\MainState.cpp
C:\Users\Alastor\Documents\CodeBlock\Projet WoF\WoF_0501\World of Fantasy\state\MainState.cpp:23: error: virtual outside class declaration
C:\Users\Alastor\Documents\CodeBlock\Projet WoF\WoF_0501\World of Fantasy\state\MainState.cpp:23: error: no `void MainState::Process()' member function declared in class `MainState'
Process terminated with status 1 (0 minutes, 0 seconds)
2 errors, 0 warnings
 

Je ne me souviens plus .. mais je devrais pouvoir normalement non ??

[valentin]

retire le mot virtual dans le .cpp

[AlastorS]

OMG :

Code: Tout sélectionner

-------------- Build: Debug in World of Fantasy ---------------

Compiling: state\MainState.cpp
C:\Users\Alastor\Documents\CodeBlock\Projet WoF\WoF_0501\World of Fantasy\state\MainState.cpp:23: error: no `void MainState::Process()' member function declared in class `MainState'
Process terminated with status 1 (0 minutes, 0 seconds)
1 errors, 0 warnings

Mais c'est parce que je doit quand même definir :

Code: Tout sélectionner

virtual void Process();

Dans le .hpp !
x'D S'te honte
Je viens juste de réalisé ... --'
Marre de faire des oublis de noob :x
Marsii Valentin ^^

[AlastorS]

Bon voilà viens de finir l'ossature de mon jeux =)

En gros : un StateManager comme conseillé, qui gère deux states :
GuiMenuState / InGameState

Chacun de ces deux states possédant leur propres ScreenManager qui, vous l'aurez compris, vont eux géré les écran a affiché ( MainGui ou MapGui par exemple )
Je me servirais des ScreenManagers pour contrôlé ou en est le programmes ...

J'ai déjà écrit les deux classes States ainsi que les trois classes Screen de GuiMenuState ...

Je vais surement attaqué le côté moteur de carte maintenant =)
Je me tâte ^^
Enfin bon je sais déjà comment l'intégrer au mon programme ...
Il sera dans le MapScreen ... Une sorte de MapManager quoi ^^

Voilà je vous tiens au courant =)