Discussion :

[skamy]

Bonjour à tous !

Je suis désolé de venir posté ici mais j'ai eu beau me casser la tête en cherchant sur google et autres je reste démuni face à mon problème. Il paraitra (je l'espère pour avoir une réponse tout du moins ) surement un peu simpliste à vos yeux mais je vous assure que j'y ai passé des heures entières dessus.

Pour remettre ceci dans le cadre, j'ai pour projet dans mon école de développer un équivalant au jeu Bomberman en c++. Etant plutôt doué pour le Java (évitez les tomates et les oeufs pourris ) et ayant un cours restreint (1 semaine) de c++ (qui plus est mal fait) je me retrouve comme un poussin avec un brosse à dent autorotative à air comprimé (non ne cherchez pas je doute que ça existe).

Voici comment j'ai abordé le problème à l'heure actuelle :

Classe Bombe qui prends comme params une portée (int) et des coordonées (classe que je fais).

Classe Coordonnées qui prends comme params x/y.

Classe Jeu qui prends en params le nombre de joueurs et le nombre de parties.

Classe Joueur qui prends en params des coordonnées de départ.

La liste n'est pas complète, je ne vais pas vous balancer tout mon projet à la figure comme un malpropre non plus. Donc pour résumer, mon idée était d'instancier les joueurs selon le nombre donné dans la création de la classe Jeu dans une méthode initGame(). Cette méthode instancie les joueurs sans soucis, et je le fais comme qui suit :

Code :

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

1
2
Coordonates startPlayer4(1,1);
Player * player4 = new Player(startPlayer4);

Par contre, une fois dans mon main, si j'ai le malheur d'essayer de caler un player4->dropBomb() pour poser une bombe, voilà que le compilateur m'insulte car il me dit ne pas connaître de player4. Par contre si je crée un player4 dans le main de la même manière, aucun soucis il me crée la bombe. Mais à nouveau, même soucis pour la bombe, une fois crée dans la méthode de la classe, elle n'existe plus dans le main, ou tout du moins je n'y ai pas accès.

Voilà mon super premier problème !

Mais j'ai un autre sushi ! (Ca serait pas drole sinon )

Sachant que tous les joueurs posent des bombes, ils passent tous par la méthode dropBomb() de la classe Joueur. Je cherche donc à pouvoir instancier un nombre illimité (40 en fait mais le problème reste quasi le même) de bombes et de pouvoir ensuite récupérer le temps qu'il leur reste avant d'exploser et là ... je coince aussi.

Merci à tous ceux qui sont arrivés jusqu'ici (C'est déjà un miracle ) et encore plus merci à ceux qui pourront m'aider


Votre humble serviteur skamy

[hijackMe]

Salut skamy !

Donc pour résumer, mon idée était d'instancier les joueurs selon le nombre donné dans la création de la classe Jeu dans une méthode initGame(). Cette méthode instancie les joueurs sans soucis, et je le fais comme qui suit :

Code :

Code :

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

1
2
Coordonates startPlayer4(1,1);
Player * player4 = new Player(startPlayer4);

Par contre, une fois dans mon main, si j'ai le malheur d'essayer de caler un player4->dropBomb() pour poser une bombe, voilà que le compilateur m'insulte car il me dit ne pas connaître de player4.

Alors pour ce problème, et d'après ce que j'ai pu comprendre, ton problème vient du fait que tu instancies player4 dans une méthode sans retourner l'adresse de cette instance. De ce fait le main ne peut pas connaître player4. Ce qui explique d'ailleurs pourquoi cela marche lorsque tu instancies cet objet directement dans le main.

Le code de ta méthode pourrait donc être du style :

Code :

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

1
2
3
4
5
6
7
8
9
Player *initGame()
{
    ...
    //Instanciation de l'objet de type Player :
    Coordonates startPlayer4(1,1);
    Player * player4 = new Player(startPlayer4);
    //retour de l'objet :
    return player4;
}

Bon, passons aux bombes.
Connaissant le jeu bomberman je suppose que les 40 bombes ne vont pas apparaître en même temps, donc chaque bombe à un timer différents qui décompte les secondes de manière indépendant les un des autre.
Dans cet ordre d'idée je pense que tu devrais faire un tour du côté des threads... D'un autre coté, 40 threads ça risque de faire beaucoup pour de simples petites bombe... Sans compter ceux nécessaires au déplacements des joueurs...
La meilleure idée serait peut être de créer une "horloge globale" qui à chaque seconde décrémente le timer des bombes posés sur le plateau...

J'espère t'avoir aidé

[skamy]

Tout d'abord merci hijackMe pour ta réponse !

De mémoire, une méthode ne peut retourner qu'une valeur non ? Alors comment retourner l'adresse de mes 4 joueurs instanciés ?
De mémoire, il suffisait d'utiliser justement des pointeurs pour retourner plusieurs méthodes et c'est ce que j'ai essayé de faire.

Au niveau des bombes, mon problème n'est pas (encore) au niveau des timers mais plutôt au niveau de leur création. Il y a 4 joueurs qui ont 4 coordonnées différentes. Pour pouvoir les instancier, j'ai crée une méthode dropBomb() dans ma classe Player qui peut récupérer Player::getFireRange() et Player::getCurrentCoordonates() car mon protoype du constructeur de Bomb est de type Bomb::Bomb(int _fireRange, Coordonates _bombCoordonates).

Mon soucis est de savoir quoi foutre dans dropBomb() afin que je puisse faire dans mon main player->dropBomb() 10 fois à la suite sans qu'il me recrée le même objet. Et après ça, savoir comment pouvoir chopper le getTimeToExplose() pour pouvoir la faire exploser quand il vaut 0.

En fait, j'ai l'impression de prendre le problème des bombes complètement à l'opposé de ce que je devrais :s

Dernière question : J'aurai voulu savoir si il y avait un moyen de voir si un objet est instancier ou n'existe pas encore. J'ai essayé (player == null) mais en y réfléchissant ça devrait être plutôt (*player = null, non ?)

Encore merci pour tes éclairecissements !

[Syl_20]

Tout d'abord merci hijackMe pour ta réponse !

De mémoire, une méthode ne peut retourner qu'une valeur non ? Alors comment retourner l'adresse de mes 4 joueurs instanciés ?
De mémoire, il suffisait d'utiliser justement des pointeurs pour retourner plusieurs méthodes et c'est ce que j'ai essayé de faire.

Au niveau des bombes, mon problème n'est pas (encore) au niveau des timers mais plutôt au niveau de leur création. Il y a 4 joueurs qui ont 4 coordonnées différentes. Pour pouvoir les instancier, j'ai crée une méthode dropBomb() dans ma classe Player qui peut récupérer Player::getFireRange() et Player::getCurrentCoordonates() car mon protoype du constructeur de Bomb est de type Bomb::Bomb(int _fireRange, Coordonates _bombCoordonates).

Mon soucis est de savoir quoi foutre dans dropBomb() afin que je puisse faire dans mon main player->dropBomb() 10 fois à la suite sans qu'il me recrée le même objet. Et après ça, savoir comment pouvoir chopper le getTimeToExplose() pour pouvoir la faire exploser quand il vaut 0.

En fait, j'ai l'impression de prendre le problème des bombes complètement à l'opposé de ce que je devrais :s

Dernière question : J'aurai voulu savoir si il y avait un moyen de voir si un objet est instancier ou n'existe pas encore. J'ai essayé (player == null) mais en y réfléchissant ça devrait être plutôt (*player = null, non ?)

Encore merci pour tes éclairecissements !

J'ai l'impression qu'en plus des problèmes de c++ tu as des problèmes de conceptions:
Tu pourrais faire une class CPlayerManager qui a pour role de gerer tes 4 joueurs. Cette classe a 4 instance de class CPlayer. Comme ça tu gère la présence ou non de joueurs, leur points, vie... sans utiliser de pointeur.

Tu peux aussi faire une classe CBombManager qui va gérer tes bombes implémenter dans des class CBomb qui a un timer.
CBombManager gère le temps et décrémente le timer de chaque bombe présente à chaque mise a jour du programme et fait sauter celles qui arrive à 0.

CPlayerManager CBombManager serrai par exemple singleton(voir sur le site comment implémenter de design patern singleton, c'est facile)

ce qui donnerai dans dropBomb() un truc du genre

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
 
 
CPlayer::dropBomb()
{
   CBomb() l_bomb;
    CBombManager::Instance().AddBomb(l_bomb);
}
 
// dans CBombManager
 
CBombManager::AddBomb(CBomb i_bomb)
{
   if (vectorBomb.size < MAX_BOMB ) // MAX_BOMB  le max de bomb sur le plateau
   {
        vectorBomb.push_back(i_bomb);
   }
}

[hijackMe]

De mémoire, une méthode ne peut retourner qu'une valeur non ? Alors comment retourner l'adresse de mes 4 joueurs instanciés ?

Alors une des solutions possible serait de créer un tableau de pointeur où chaque case pointe vers un Player.
Il te suffirait alors de retourner le tableau !

Code :

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

1
2
3
4
5
6
for(int i=0; i<4; i++)
{
   Player *monPlayer = new Player();
   monTableau[i] = monPlayer;
}
return monTableau;

Mon soucis est de savoir quoi foutre dans dropBomb() afin que je puisse faire dans mon main player->dropBomb() 10 fois à la suite sans qu'il me recrée le même objet. Et après ça, savoir comment pouvoir chopper le getTimeToExplose() pour pouvoir la faire exploser quand il vaut 0.

Pour pouvoir créer dynamiquement des objets, tu peux utiliser la même méthode que celle utilisée plus haut.
A savoir :

Code :

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

Bomb *myBomb = new Bomb(myFireRange, myCoordonates);

A toi par la suite de stocker les différentes adresses des objets et les manipuler pour accéder a leurs méthodes...

Pour le test d'existence, je ne suis pas sûr mais le test de nullité devrait fonctionner sans le *...

EDIT : +1 syl_20

[skamy]

Encore merci pour tous ces éclairecissements !

Oui j'ai des gros problèmes de conception. Hormis quelques bouts de code par ci par là, c'est la première fois que je code réellement en c++. Habitué au java j'ai pas à faire des .h et des .cpp, pas de soucis de pointeurs, pas de références, rien de tout ça. Ce sont des notions super nouvelles pour moi et ça m'embète bien :/

Voilà mon code qui instancie les joueurs dans initGame() :

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
switch(Game::getNumberOfPlayers()) {
		case 4 : {
			Coordonates startPlayer4(1,1);
			Player * player4 = new Player(startPlayer4); 
			cout << "Player 4 created, Coordonates : " << endl;
			player4->getCurrentCoordonates().display();
		}
		case 3 : {
			Coordonates startPlayer3(2,2);
			Player * player3 = new Player(startPlayer3);
			cout << "Player 3 created, Coordonates : " << endl;
			player3->getCurrentCoordonates().display();
		}
		case 2 : {
			Coordonates startPlayer2(3,3);
			Player * player2 = new Player(startPlayer2);
			cout << "Player 2 created, Coordonates : " << endl;
			player2->getCurrentCoordonates().display();
 
			Coordonates startPlayer1(4,4);
			Player * player1 = new Player(startPlayer1);
			cout << "Player 1 created, Coordonates : " << endl;
			player1->getCurrentCoordonates().display();
		}
	}

Malgré ça, si je passe un return player4; hors du switch(en ayant changé le type de return de ma méthode bien sur), il le connait pas non plus. Il me sort le magnifique :

1>c:\users\max\documents\projet dev\bomberman\game.cpp(24) : error C2065: 'player4'*: identificateur non déclaré

Pareil, quand j'essaye dans mon initGame() de voir si les joueurs sont instancier pour les remettre à leur emplacement de départ (pour une deuxième partie par exemple) :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
if(*player1 != NULL) {
		switch(Game::getNumberOfPlayers()) {
			case 4 : {
				player4->setCurrentCoordonates(1,1);
			}
			case 3 : {
				player3->setCurrentCoordonates(2,2);
			}
			case 2 : {
				player2->setCurrentCoordonates(3,3);
				player1->setCurrentCoordonates(4,4);
			}
		}
	}

Que je mette * ou pas devant player, il veut pas me faire ce test, il me ressort le truc du dessus.


Syl_20, en ce qui concerne ta réponse j'ai l'impression que je pourrais en apprendre énormément, mais les termes sont trop techniques et je pige pas la moitié des trucs :s De ce que je pense avoir compris, tu me conseilles de créer deux classes managers dans lesquelles j'instancierai les joueurs et les bombes respectivement et que j'aurai à instancier une seule fois dans mon main c'est bien cela ?

Qu'est censée faire cette ligne ? Et à quoi correspond exactement ton vectorBomb ?

Code :

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

CBombManager::Instance().AddBomb(l_bomb);

Je m'excuse de vous embêter avec tout cela car ça doit vous paraître enfantin, mais je suis vraiment pommé et l'année se joue la dessus. J'ai beau essayer pendant des heures des idées qui me traversent la tête mais plus j'avance et plus je vois que les choses me dépassent.

En tout cas encore une fois un grand MERCI pour toute cette précieuse aide

[Syl_20]

Oui j'ai des gros problèmes de conception. Hormis quelques bouts de code par ci par là, c'est la première fois que je code réellement en c++. Habitué au java j'ai pas à faire des .h et des .cpp, pas de soucis de pointeurs, pas de références, rien de tout ça. Ce sont des notions super nouvelles pour moi et ça m'embète bien :/

Normalement que tu code en Java ou en C++ la conception est la même. Si tu connait UML les diagrammes sont les mêmes. Le rest qui t'enbete n'est que l'implémentation

Syl_20, en ce qui concerne ta réponse j'ai l'impression que je pourrais en apprendre énormément, mais les termes sont trop techniques et je pige pas la moitié des trucs :s De ce que je pense avoir compris, tu me conseilles de créer deux classes managers dans lesquelles j'instancierai les joueurs et les bombes respectivement et que j'aurai à instancier une seule fois dans mon main c'est bien cela ?

une classe pour manager les joueurs:

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
 
CPlayermanager
{
private:
//... des trucs ici pour le singleton
public:
    CPlayer m_player1;
    CPlayer m_player2;
    CPlayer m_player3;
    CPlayer m_player4;
};
 
#include <vector>
CPlayerManager
{
private:
//... des trucs ici pour le singleton
public:
    void AddBomb(CBomb i_bomb);
    void UpDateTimer();
protected:
    std::vector<CBomb> m_bombVector; // vector=> vecteur de la STL
};

Qu'est censée faire cette ligne ? Et à quoi correspond exactement ton vectorBomb ?

Code :

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

CBombManager::Instance().AddBomb(l_bomb);

BombManager::Instance() => recherche singleton sur developpez.com

Je m'excuse de vous embêter avec tout cela car ça doit vous paraître enfantin, mais je suis vraiment pommé et l'année se joue la dessus. J'ai beau essayer pendant des heures des idées qui me traversent la tête mais plus j'avance et plus je vois que les choses me dépassent.

J'ai l'impression que tu par en live mod panique sans savoir faire du tout un bomber man. Même en Java tu a l'air mal parti.

Je te conseil d'abord de faire ta conception sans penser au langage avec un diagramme genre UML. Et une fois que tu sais quoi faire passe à la programmation: Java ou C++ . J'ai fais un peu de Java et le codage sera pas plus compliqué.

[hijackMe]

e te conseil d'abord de faire ta conception sans penser au langage avec un diagramme genre UML. Et une fois que tu sais quoi faire passe à la programmation: Java ou C++ . J'ai fais un peu de Java et le codage sera pas plus compliqué.

Je plussoie allègrement Syl_20 !

Pose toi devant une feuille et un papier, stylo en main et réfléchit déjà en français à ce que tu veux faire. Utilise des phrases simple qui ont un but précis, tel que "initialiser la partie" ou "poser la bombe".
Un logiciel ou un JV se conçoit tout d'abord par une représentation textuelle. Le langage n'est qu'une simple traduction de ce que tu auras définit à tête reposée.

Et ne panique pas non plus, une fois bien pensé un logiciel est codé en très peu de temps !

[zeeboub]

Ahhhhh l'analyse, il n'y a que ça de vrai

[skamy]

Oui et non.

Oui dans le sens où on nous colle devant le fait accompli et que ce sont mes premières lignes de c++. C'est logique qu'on fasse un peu de freestyle

Non dans le sens où on y a réfléchi, tout paraissait clair. Les diagrammes d'uml ont été écrit etc ...

Maintenant, là où je me disais "Ouais ici j'instancie ça pour pouvoir récupérer ça" je me dis "Mais zut, pourquoi il me dit que le pointeur existe pas ?".

Disons que sur quelque chose qui avait l'air pas mal foutu (du moins pour notre niveau), arrivé au code jme suis pris une baffe magistrale dans la tronche.

Et disons que le java simplifiait à mon avis pas mal de trucs. J'ai plus les codes qu'on a fait en tête mais pour les bonus un simple fichier enum suffisait. En c++, ça existe, mais j'ai aucune idée d'où ça se calle et comment on s'en sert vraiment. J'ai relu les codes du Pacman fait en cours par la prof. Le code est (à mes yeux immonde et illisible), elle instancie des objets nommés "l". Allez relire un l.machin() :/

Si je devais essayer de reformuler comment se passait le jeu dans ma tête je dirais que :

Le joueur arrive sur le menu en lançant le jeu, il choisit le nombre de joueurs, le nombre de tours et lance la partie. Ici hop, Game::initGame() regarde si les joueurs existent (donc si des rounds ont été joués précédemments) et si non, il les crée. Il crée ensuite le plateau de jeu. Ceux ci posent des bombes via une méthode Player::dropBomb() qui instancieles bombes. Ces dites bombes ont un attribut timeToExplose qui est initialisé à time +5s dans le constructeur. Une fois que timeToExplose = time(NULL), la fonction Bomb::explose() est appelée.

Tout ça est placé par la classe Coordonnées qui permet de tout placer, un basique x et y. La classe Map permet de créer le labyrinthe.

Player possède un attribut won et tant que !hasWon() est vrai, la partie continue. Quand un joueur gagne, won passe à 1 et son compteur de victoire s'incrémente. Puis won est remis à 0 dans l'initGame, les coordonnées réinitialisées et une autre partie redémarre.

Tout ça a été traduit en UML. Notre claque vient de notre limite de connaissances du langage. Je vais dès demain me renseigner sur cette histoire de singleton et essayer de voir ce que je pourrais changer en implémentant ces classes pour manager les bombes et les joueurs.

Mais je ne le dirai jamais assez, merci !!!

A défaut d'avoir un jeu qui marche à la deadline j'aurai l'air moins con lors de la soutenance orale et je me serai enrichi la dessus :p

Ca risque de me servir car je vais être stagiaire pour une grosse entreprise pour développer des applis en c#. Tout ça est bon à prendre

[zeeboub]

AMHA le formalisme du langage C++ n'était pas l'os dans ton problème. Je pense que si tu avais essayé de traduire ton UML en Java, tu aurais eu également des soucis Mais peu importe, tu commences à regarder les choses d'un peu plus haut, tu sembles t'intéresser aux patterns. C'est une bonne chose car les problèmes (et solutions apportées) de conception sont très souvent transverses aux langages Et si tu veux faire de la programmation, outre le fait de maîtriser Java, C#, C++ ou le reste du monde (qui finalement n'est que de l'ordre du détail... ), tu vas devoir apprendre à concevoir et (surtout) analyser.

En tout cas, bonne continuation en C#