Bonjour, dans le cadre d'un projet semestriel, mon équipe et moi devons présenter un jeu de stratégie en 2D.

Ce dernier se jouera en tour par tour. Nous avons décidé qu'il comportera différentes cases ayant des propriétés propres. Type Advance Dual Strike, Age of Empire, Civilisation,...
Étant tous des débutants en Java, nous ne savons pas trop comment faire pour créer les cases et les lier à la carte.

Nous souhaitons commencer par la création de la carte et la mettre en relation avec une IHM que nous avons déjà créée. Pour la carte, nous pensions faire c'est réaliser un tableau 2 dimensions d'objet de type Case.

Nous avons quelques restrictions, comme par exemple l'utilisation d'Eclipse obligatoirement pas le droit d'utiliser des éditeurs de carte...

Donc mes questions sont :

 Auriez vous des conseils à nous donner ?

 Auriez vous des exemples sur lesquels ont pourraient s'appuyer ?

 Comment lier la classe Carte à la classe Case ?

Merci d'avance

-
Edité par Vick.F 26 mai 2016 à 10:03:29

Salut,

Utiliser un tableau 2D pour une map est un bon début

Avoir une classe Map/Carte qui contient les cases est aussi une tres bonne solution (en meme temps votre map est composee de cases, donc logique que l'un contienne l'autre ^^)

Une possibilité :

public class Carte {
 private final Cases[][] cases = Cases[10][10];

 //constructeur
 //getter / setter
}


//autre fichier
public class Cases {
 // variable de l’unité qui se trouve sur la case (batiment, soldat, vide...)

 //constructeur
 //getter / setter
}

J'allais conseiller de mettre le plus de variable possible en private final et utiliser l'initialisation dans le constructeur.

Bon courage !

Tout d'abord, merci de ta réponse ! Je n'étais pas trop loin de cette solution

Nous souhaitons créer différents types de cases, par exemple, forêt, ville, montagne, plaine, ces dernières sont dans notre classe Cases. Faut-il que ce soient des variables ou des méthodes ?

Autre question, comment dire que notre tableau d'objet de type case est composé de différentes cases ? Enfin comment faire pour que les cases de notre tableau prennent les types de cases en compte ?

Ensuite nous avons créer beaucoup de classes qui répondent aux besoin de notre programme comme par exemple Unités, Batiment, Tour (du joueur), IHM. Si on veut les spécifier par exemple donné plusieurs unités faut-il créer des classes en plus ?

Merci d'avance !

-
Edité par Vick.F 26 mai 2016 à 16:29:05

Pour ta question sur les cases, tout dépend de ce que vous voulez.

Par exemple tu dis qu'une case peut être de type Foret, ou autre. Quel serait l'impact d'une case de type Foret?

Car tu peux avoir par exemple 2 solutions :

1)  Je dis n'importe quoi, mais imaginons que n'importe quelle case doit avoir la méthode action(), et que cette méthode est différente pour une case "Foret", différente pour une case "Ville", etc... Dans ce cas, il faut que "Case" soit une classe abstraite ou une interface (tout dépend encore de ce que représente une case pour vous. Par exemple si une case a un attribut Pion, peu importe le type de la case, alors "Case" peut être une classe abstraite. Si par contre "Case" ne contient que des méthodes à implémenter selon le type de la case, alors c'est une interface). De ce fait, il te faudra créer une classe "Foret", une classe "Ville", etc... qui héritera (ou implémentera) la classe (ou l'interface) "Case".

2) Si ce que j'ai dit en 1) ne correspond pas à tes besoins, peut-être que tu pourrais simplement créer une énumération par exemple "TypeCase" ou dedans tu mets tous les types possibles. Ensuite tu ajoutes un attribut "TypeCase" dans la classe "Case".

Le mieux serait que tu détailles ce que doit faire une Case, et ce que dois faire une Foret, une Ville, etc.. et pourquoi tu as besoin de types de case

Tu as raison polak91, je vais vous dire ce qu'on a sur notre cahier des charges se sera surement plus clair. Donc je reprends :

Nous souhaitons créer un jeu de stratégie en 2D qui se joue en tour par tour. Nous avons un travail de conception orienté objet au préalable. Il y aura différents types d'unité, une IHM, de la musique, et autres dans notre programme, mais je ne m'occupe pas de ça.

Ma partie consiste à créer un plateau de jeu, j'ai donc créé un tableau d'objet dans une classe Carte. Et des cases de différents types, j'ai donc créé, une classe Case.

Je me retrouve donc avec deux classes, Case et Carte, mais j'aimerais entrer en ligne de compte différents types de cases. Chaque type de case (forêt, ville, montagne, plaine), donneraient un pourcentage défensif aux unités présentes dessus, consommerait un nombre de déplacement au unité voulant se déplacer à travers ou sur ces dernières.
Nous n'avons pas le droit d'utiliser des logiciels autres que Eclipse pour développer notre programme.

Lorsque que j'aurais tout créé, on souhaite l'afficher et le lié avec notre IHM et essayer d'afficher les unités.

Mais pour le moment, si vous pouvez m'aider, ou me donner quelques conseils sur la façon de réaliser ma carte, mes cases et la possibilité d'afficher le tout, ça m'aiderait vraiment.

Merci d'avance pour vos réponses. 

Salut,

A ce moment la il te faut utiliser l’héritage. Tes cases Foret, Plaines etc... sont des Cases, donc elles hériteront de cette dernière. Comme l'a dis polak en 1) : la mettre en abstract est une bonne idée comme cela chaque cases fille va implémenter a sa manière des morceaux de code :

public class Virtual {

	public static void main(String[] args) {
		Case c0 = new ForetCase();
		c0.displayVitesse(); //50%
		Case c1 = new PlaineCase();
		c1.displayVitesse(); //10%
	}

}

abstract class Case {
	public abstract int getVitesse();

	public void displayVitesse(){
		System.out.println("Vitesse de deplacement :" + getVitesse() + "%");
	}
}

class ForetCase extends Case {
	public int getVitesse() {
		return 50;
	}
}

class PlaineCase extends Case {
	public int getVitesse() {
		return 10;
	}
}

La je reprend ton exemple de déplacement. La classe Case implémente displayVitesse qui va utiliser l’implémentation des classes filles pour getVitesse() (car Case est abstract, elle ne peut pas être directement implémentée. Elle laisse donc l’implémentation de getVitesse aux filles).

Un point important a faire : il faut que tes Cases possèdent une variable Unites qui dira quel type d’unité se trouve sur cette case (null si rien, sinon Tour, Batiment, Homme...)

Salut Babc, merci pour ce tuyau, donc j'ai réaliser 4 classe filles (ForestCase, CityCase, PlainCase, MountainCase) qui extends de Case.

Tout fonctionne lors de l'affichage texte de ces classes.

Nous disposons d'une classe batiment, car la CityCase a un comportement particulier, vu que cette dernière peut etre capturer par un joueur, est ce que c'est viable de dire que la classe Batiment extends CityCase ou faut il que j'utilise une variable ?

Par rapport à ta remarque sur la variable Unité, on dispose déjà d'une classe Unit, comment faire pour mettre ces deux classes en relation ?

Je pense que vu notre niveau, nous sommes partit trop loin avec mon équipe :/

Ce qu'on voudrait avoir au final, c'est un affichage d'une carte de jeu, qui comporte plusieurs types de cas, avec des carateristiques différentes. On souhaiterais qu'il y ai une interaction entre le joueur et la fenêtre, qu'il puisse par exemple bouger une unité et que cette dernière voit ses caractéristiques changer en fonction de la case sur laquelle elle est arrivée.

Salut,

Comme l'a dit Polak, l'idée c'est de réfléchir à chaque fois à ce que tu attends d'une fonctionnalité. Si on prend les Bâtiments que tu évoques :

• Est-ce que tu peux avoir plusieurs Bâtiments par case ?
• Quels sont leurs effets sur la case ?
• Peuvent-ils accueillir des unités ? (Type PNJ vendeur, gardes etc ...)
• ...

Une fois que tu as fait ce travail (pour chacun des éléments que tu souhaites ajouter), tu auras une idée plus précise du boulot à réaliser .. Se lancer dans un gros projet c'est avant tout une grosse partie d'analyse et de spécification pendant laquelle tu ne vas pour ainsi dire écrire aucune ligne de code, si tu ne fais pas ça, tu risques de te retrouver dans le meilleur des cas avec le célèbre "code spaghetti", dans le pire des cas, rien ne marchera.

Si tu es à l'aise en anglais, je te conseille de regarder quelques conférences sur le Clean Code sur Youtube, qui illustrent bien l'importance de cette partie d'analyse. Parmi les points les plus importants : Organiser son code de telle façon que les changements soient faciles à implémenter, sans avoir à modifier le comportement de tout son code... Sur 1000 lignes au total ça va, sur 10 000 c'est plus dur. Alors les gros projets "pros" qui atteignent les centaines de milliers ...

Pour reprendre les bâtiments, je le vois comme ça :

• N'importe quelle case peut contenir un ou plusieurs bâtiment, avec une limite définie par la case
• Chaque bâtiment peut contenir différents types d'unités

Avec un exemple "Alakon", ça donnerait quelque chose comme ça :

public abstract class Case {
	
	List<Batiment> batimentsCase;
	
	public abstract int getLimiteBatiments();
	
	public void addBatiment(Batiment b) {
		if (batimentsCase.size() >= getLimiteBatiments())
			throw new IllegalArgumentException("Limite atteinte");
		batimentsCase.add(b);
	}

}

public abstract class Batiment {
	
	List<Unite> unitesPresentes;
	
	public abstract int getLimiteUnites();
	
	public void addUnite(Unite u) {
		if (unitesPresentes.size() >= getLimiteUnites())
			throw new IllegalArgumentException("Limite atteinte");
		unitesPresentes.add(u);
	}
}

Ici, tu peux facilement créer un nouveau type de Case qui peut avoir X bâtiments maximum, ou un nouveau type de Bâtiment pouvant abriter Y unités maximum, tu peux éventuellement rajouter une méthode abstraite "getTypeAutorise()" pour interdire l'ajout de certains Bâtiment ou Unités .. (Exemple : Pas de vendeur dans un château etc ..)

-
Edité par Kodvir 27 mai 2016 à 10:44:10

Vous êtes la pour apprendre

Tres bien pour les différents types de Case.

Que représente Batiment ? son rôle ?

Tu peux faire une méthode isCatchable qui retourne un boolean si oui ou non la case peut être capturée.

La classe Unit doit être une variable de Case, qui est soit null, soit la référence vers l’unité qui se trouve sur la Case. (mon point de vue).

Effectivement on voit que ma spécification pose problème : Je n'ai pas pensé à la possibilité d'avoir des unités sur une case, sans pour autant être liés à un bâtiment.

Comme quoi, l'analyse, c'est important 

Salut Kodvir, on a eu cette démarche à réaliser, on a du mené une description de notre projet, avec les différents diagrammes de la conception (séquences, classes, communication).

Mais c'est la première fois que nous avons un projet de cette ampleur et nous avons était un peu laché la dedans avec très peu d'aide, uniquement un cours général mais pas spécifique à la création d'un jeu...

Pour simplifier notre jeu, nous pensions à faire comme un Dual Strike War (voir l'image) sans la vue isométrique et en un peu plus simplifier.

Le rôle de batiment qui serait sur une case, serait de fournir des fonds au joueur qui le detient. Il peut etre capturé, peut etre neutre au départ.

Une seule unité par case, je voyais donc plus une référence à la classe Unité pour les cases.

Question bête, par curiosité: Qu'est-ce qu'une unité? Est-ce un bâtiment? Un joueur? Toutes les cases peuvent-elles avoir une unité?

Il n'y a pas de questions bêtes je pense, elles portent toutes à réfléchir
Alors une unité, c'est un entité qui peut se déplacer, attaquer et capturer, elle est controlé par un joueur durant son tour. Toutes les cases peuvent avoir une unité, mais une seule, pas de possibilité d'empiler les unités sur une même case.

D'accord. Donc si on résume : 

• Tu as une classe Carte qui possède un tableau 2D de type Case. Dans cette classe, tu auras la méthode qui affiche la carte (avec les joueurs etc...) sur console (avant de passer à l'IHM).
• Tu as une classe Case qui est abstraite car il existe plusieurs types de case : Foret, Ville, etc... Case a 2 méthodes abstraites : une pour donner un % défensif et une autre pour consommer un nb de déplacement à une unité. Une case a aussi une unité
• Tu as une classe Unité qui possède des méthodes comme "déplacer", "attaquer" et "capturer". Si une unité appartient à un joueur, alors une unité a un attribut joueur.

Si je me suis trompé quelque part, n'hésite(z) pas à me le dire. Et surtout, si il y a quelques choses que tu n'as pas compris, vaut mieux le dire maintenant avant de continuer (par exemple sur l'abstraction etc..., si ce n'est pas clair n'hésites pas à le dire).

Maintenant abordons ta question sur "Batiment".

Est-ce que une case de type "Ville" a obligatoirement un bâtiment? Peut avoir 0 ou 1 bâtiment? Peut avoir 0 ou plusieurs bâtiments?

Je ne pense pas qu'un bâtiment = une ville. Donc pour ta question "est-ce qu'on peut faire Batiment extends Ville", la réponse est non !

Tu as dis que Batiment peut être capturé. Par hasard, est-ce que un Batiment est une Unité? Si oui, Unité est alors une classe abstraite, et Batiment extends Unité.

J'ai bien compris l'histoire des classes abstraites et ce que l'on a fait jusqu'à maintenant. Merci pour ce résumé polak91

Une case n'a pas obligatoirement une unité, elle peut être vide, sauf lorsqu'une unité s'y déplace dessus.

Par rapport aux batiments :

La classe CityCase = un batiment capturable qui rapportera de l'argent au joueur qui le detient, je pense que se sera plus simple. Je ne pense pas que Batiment est une unité car on ne peut pas déplacer un batiment, pour moi les batiments sont à part.

Après je ne sais pas quelle solution est plus viable qu'une autre..

Effectivement dans ce cas un bâtiment n'est pas une unité.

Est-ce qu'il existe d'autre type d'objet comme le batiment, mais pour les autres cases (par exemple Foret) ?

Car une solution "propre" et modulable pourrait être :

• Créer une classe abstraite CatchableObject avec les méthodes comme "isCatchable" (si dans certains cas les objets ne sont pas capturables), une méthode qui effectuerait l'action lorsque l'objet est capturé (donner de l'argent au joueur pour le batiment), etc...
• Créer une classe Batiment qui hérite de CatchableObject
• Dans la classe Case, ajouter un attribut CatchableObject (ou si une case peut avoir plusieurs CatchableObject, alors une liste ou set ou autres)
• Dans la classe CityCase, dans le constructeur ou dans une méthode d'initialisation, faire en sorte qu'il est possible d'y ajouter un Batiment en tant que CatchableObject

-
Edité par polak91 27 mai 2016 à 12:16:12

Non il n'y a que Batiment pour la classe CaseVille

Voici mon code pour le moment et mes classes Carte, Case, CaseVille, et batiment :

public class Carte {
	
	public final static int BOARD_SIZE = 20;
	
	protected Case[][] cases;
	

	private Case[][] genererCarte()
	{
		Case[][] cases = new Case[BOARD_SIZE][BOARD_SIZE];
		return cases;
		
	}
	
	public Case[][] getCases() 
	{
		return cases;
	}


	public void setCases(Case[][] cases) 
	{
		this.cases = cases;
	}


	public void creer() 
	{
		// TODO - implement Carte.creer
		throw new UnsupportedOperationException();
	}

	public void afficherMap() {
		// TODO - implement Carte.afficherMap
		throw new UnsupportedOperationException();
	}

}

abstract class Case 
{

	public abstract int getVitesse();
	
	public abstract int getDefense();
	
	public void displayVitesse()
	{
		System.out.println("Vitesse de deplacement : " + getVitesse() + "%");
	}

	public void displayDefense()
	{
		System.out.println("Vitesse de deplacement : " + getDefense() + "%");
	}
	
}

public class CaseVille extends Case{

	@Override
	public int getVitesse() {
		// TODO Auto-generated method stub
		return 50;
	}

	@Override
	public int getDefense() {
		// TODO Auto-generated method stub
		return 75;
	}

}

public class Batiment extends CaseVille {

	public Batiment(int deplacement, int defense)
	{
		super();
		// TODO Auto-generated constructor stub
	}

	public boolean isCatchable()
	{
		return true;
	}
	
	public void supprimer() {
		// TODO - implement Batiment.supprimer
		throw new UnsupportedOperationException();
	}

	
	public void changerJoueur() {
		// TODO - implement Batiment.changerJoueur
		throw new UnsupportedOperationException();
	}
}

Qu'en dites vous ?

A ce compte là, si tu n'as qu'un bâtiment par CaseVille, ça vaudrait presque le coup de considérer directement CaseVille comme étant un bâtiment..

Par contre ça veut dire que tu ne pourras pas avoir de case possédant plusieurs bâtiments. Et si tu gardes cette architecture et que tu veux avoir plusieurs bâtiments dans une CaseVille, ta CaseVille contiendra plusieurs instances d'elle-même, ce qui est .. Etrange.

Je vois, je pense que le mieux serait d'inclure Batiment dans CaseVille, je ne souhaite avoir qu'un seul batiment sur une case ville. C'est une vision simpliste des choses, à la façon d'un jeu type Advance War ou Age of Empire.

Vick.F a écrit:

 à la façon d'un jeu type Advance War

Ah voila c'est ce jeu que je cherchais

Le bâtiment peut être non capturé ou capturé par le joueur X. Donc oui CityCase et Batiment ne font qu'un

Je serais tout de même d'avis de faire une classe à part. Imaginons que d'ici deux mois et X milliers de lignes de codes, vous vous rendez compte que vous voulez créer une case "Métropole" qui peut inclure plusieurs bâtiments (ou autre réalisation du même type).

Si on part du principe que CityCase et Batiment ne font qu'un, vous devrez probablement modifier une grande partie du code déjà existant pour permettre ceci. (Quelle vitesse sur la case métropole ? Vitesse de la case ? Du premier bâtiment ? Du deuxième ? ...). Alors que si une classe abstraite Batiment existe, il n'y aura qu'à mettre en attribut de classe une liste (ou autre structure de données) de Batiment.

Pensez long terme

BabC a écrit:

Ah voila c'est ce jeu que je cherchais

C'était l'image juste au dessus

Comment faire alors, pour dire qu'un batiment appartient à un joueur et qu'il gagne le revenu de cette case batiment ?

-
Edité par Vick.F 27 mai 2016 à 14:06:12

public abstract class Batiment {

    protected Joueur proprietaire;

    public void changeProprietaire(Joueur newProprio) {
        this.proprietaire = newProprio;
    }

    // Override dans chaque classe héritant de Batiment
    // Exemple : Caserne donne plus de troupes au propriétaire
    // Marché plus d'or etc
    public abstract void doStuff();

}

Merci Kodvir, mais peux tu m'expliquer pourquoi tu as créer une méthode doStuff() ? Et pourquoi tu as mis la classe Batiment en abstract ?

Vick.F a écrit:

BabC a écrit:

Ah voila c'est ce jeu que je cherchais

C'était l'image juste au dessus

-
Edité par Vick.F il y a environ 1 heure

Oui mais je retrouvais plus le nom

En tout cas merci, pour toute vos réponses, et explications !

Mais maintenant arrive la question de : Comment je peux faire afficher ma magnifique Carte, qui est un tableau d'objet de type Case qui comporte différentes cases ? Si je veux créer une carte fixe, mais qui s'affiche, comment je dois m'y prendre ?

Pour le moment je cherche uniquement à avoir un affichage console de ma carte, je verrais plus tard avec surement une utilisation d'application graphique pour l'affichage liée avec l'IHM.

-
Edité par Vick.F 29 mai 2016 à 11:29:13

Tu parse ton tableau de case, tu affiche le type de chaque case et son contenu :

Forest(null) Forest(null) Plain(Unit) City(null) Forest(null)
Plain(Unit) City(null) Forest(null) Forest(null) Forest(null)
...

Le plus simple est de mettre le toString qui donne le type de case et l'unite present dessus (utilise des "\t" pour faire une tabulation et avoir un affichage correct )

-
Edité par BabC 30 mai 2016 à 9:04:51

Salut BabC merci de ta réponse, je peux décrire le contenu de mon tableau dans ma classe Carte ? Et utiliser la méthode toString je peux la mettre dans ma classe Carte ?

Pour le moment j'ai :

public class Carte {
	
	
	public final static int BOARD_SIZE = 20;

	protected Case[][] cases;

	
	private Case[][] genererCarte()
	{
		Case[][] cases = new Case[BOARD_SIZE][BOARD_SIZE];
		return cases;
		
	}


	public Case[][] getCases() 
	{
		return cases;
	}


	public void setCases(Case[][] cases) 
	{
		this.cases = cases;
	}


	public void creer() 
	{
		// TODO - implement Carte.creer
		throw new UnsupportedOperationException();
	}


	public void afficherMap() {
		// TODO - implement Carte.afficherMap
		throw new UnsupportedOperationException();
	}

}

*****************************************

abstract class Case 
{

	public abstract int getVitesse();
	
	public abstract int getDefense();
	
	public void displayVitesse()
	{
		System.out.println("Vitesse de deplacement : " + getVitesse() + "%");
	}

	public void displayDefense()
	{
		System.out.println("Vitesse de deplacement : " + getDefense() + "%");
	}
}

// Après j'ai les différentes cases Ville, Montagne, Foret et Plaine

Comme cela :

    public void afficherMap() {
       for(int i = 0 ; i < cases.length ; i++){
        for(int j = 0 ; j < cases.length ; j++){
         System.out.print(cases[i][j].getClass().toString() + " " + cases[i][j].displayVitesse() + "\t"); // ou autre methode
 }
System.out.println();
 }

    }

La magie du polymorphisme marchera car tu aura définit auparavant le comportement des méthodes de chaque cases :

public class Virtual {

	public static void main(String[] args) {
		Case c0 = new ForetCase();
		Case c1 = new PlaineCase();

		Case[] cases = { c0, c1 };
		for (int i = 0; i < cases.length; i++) {
			cases[i].displayVitesse();// 50 puis 10
		}
	}

}

abstract class Case {
	public abstract int getVitesse();

	public void displayVitesse() {
		System.out.println("Vitesse de deplacement :" + getVitesse() + "%");
	}
}

class ForetCase extends Case {
	public int getVitesse() {
		return 50;
	}

}

class PlaineCase extends Case {
	public int getVitesse() {
		return 10;
	}
}

Il te faut quelque part generer ta Map par contre ! Car Case[][] cases = new Case[BOARD_SIZE][BOARD_SIZE]; t'initialise bien le tableau, mais tes cases seront null. Il te faut faire  a un moment (aleatoirement par exemple) cases[i][j] = new ForestCase(); //ou Plain, ou City etc...

-
Edité par BabC 30 mai 2016 à 11:08:19