Développez Couché, saison 1 : le topic officiel

**Esotsm** · 01/11/2011, 12h02

Les ennuis commencent dès le premier numéro. Au moment d'enregistrer le nouveau projet appelé "Canardage", il me dit un truc du style "Accès au registre interdit" et une fois le projet ouvert, je n'ai pas "Solution "Canardage" (2 projets)" mais seulement "Solution "Canardage" (1 projet)"...

Des idées ? J'ai essayé en normal et en mode administrateur. Sinon, j'attendrais le prochain numéro pour prendre le fichier en téléchargement.

**L-F. Sébum** · 01/11/2011, 14h55

Envoyé par Esotsm

Les ennuis commencent dès le premier numéro. Au moment d'enregistrer le nouveau projet appelé "Canardage", il me dit un truc du style "Accès au registre interdit" et une fois le projet ouvert, je n'ai pas "Solution "Canardage" (2 projets)" mais seulement "Solution "Canardage" (1 projet)"...

Des idées ? J'ai essayé en normal et en mode administrateur. Sinon, j'attendrais le prochain numéro pour prendre le fichier en téléchargement.

Bizarre.
Va dans "programmes et fonctionnalités" dans le panneau de configuration et essaye de "réparer" VC# et XNA. Ca ressemble à une installation merdée.

J'uploaderai le code (et les fichiers nécessaires pour le prochain épisode) demain, mais je doute que ça marche si ton installation déconne.

**Esotsm** · 01/11/2011, 15h40

Ok, je vais faire ça, merci. J'ai vu après seulement l'installation de VC# qu'il fallait se contenter d'installer ça et pas tous les autres trucs proposés. Cela pourrait peut-être venir de là... Bon, à l'ancienne, on désinstalle et on réinstalle.

**L-F. Sébum** · 02/11/2011, 16h04

Envoyé par Esotsm

Ok, je vais faire ça, merci. J'ai vu après seulement l'installation de VC# qu'il fallait se contenter d'installer ça et pas tous les autres trucs proposés. Cela pourrait peut-être venir de là... Bon, à l'ancienne, on désinstalle et on réinstalle.

N'oublie pas non plus de bien installer toutes les mises à jour que te proposes Windows Update après avoir installé VC# ET après avoir installé XNA.

Sinon, ayé, le code source et les fichiers nécessaires à la leçon 1 sont uploadés.

**Belhoriann** · 02/11/2011, 18h13

Wokay merci Sebum

**Esotsm** · 02/11/2011, 18h59

Bon, ça marche pas. J'ai désinstallé les noooombreux trucs installés avec Visual et XNA, réinstallé mais c'est toujours le même problème. Pas grave, je regarderai ça de loin et dès que j'ai un nouveau pc, je m'y remettrai. Merci Sebum en tous cas. Cette idée de rubrique est super.

**Azerty** · 03/11/2011, 12h54

Envoyé par L-F. Sébum

LIENS UTILES :

NIVEAU DÉBUTANT :
- Un excellent cours d'introduction au C# par Serge Tahé, prof à l'université d'Angers. Lien (PDF, 20 mégas) (en français)

Entrée en matière, page 8

Ci-dessus le littéral 3 est par défaut de type C# int, donc de type .NET system.Int32. Cette structure a une méthode GetType() qui rend un objet encapsulant les caractéristiques de type de données Sytem.Int32.
Parmi celles-ci, la propriété FullName rend le nom complet du type. On voit donc que le littéral 3 est un objet plus complexe qu'il n'y paraît à première vue.

Bon, je vais aller chercher des cours de prog de CM2, çà ira peut-être.

En tout cas, bravo pour cette nouvelle rubrique, une super idée.

**yourykiki** · 03/11/2011, 13h54

Un minimum de précision n'a jamais fait de mal, mais si tu ne retiens pas ce genre de paragraphe ce n'est à mon avis pas super grave :0) Le jour où tu atteindras les limites d'un int, tu te souviendras peut-être de ce paragraphe :D

Avoir la connaissance du tableau au dessus de ce paragraphe suffit pour passer à la suite

**L-F. Sébum** · 04/11/2011, 14h42

Envoyé par Azerty

Yep, ce cours là n'est pas destiné aux GRANDS débutants (ceux qui n'ont jamais programmé avant). Commence plutôt par celui du site du zéro.

Je vais modifier la première page pour que ce soit plus clair.

**Møgluglu** · 04/11/2011, 16h57

Envoyé par Tomaka17

Les technical notes sont un peu vides par contre, j'aimerais bien savoir pourquoi il n'y a pas de FPU par exemple, ça me paraît simple à faire comparé au reste
Un peu comme si tu disais "j'ai construit une maison tout seul mais je n'ai pas mis de poignées aux portes"

HS, mais si, c'est super dur. Reproduire le comportement de la FPU x87, même en C ça demande dans les 15000 ou 20000 lignes écrites par quelqu'un qui comprend ce qu'il fait (i.e. quelqu'un qui sait expliquer sans hésiter la différence entre l'exception underflow et le flag denormal), et c'est très lent.
Et ça n'apporte rien de plus, car le Linux qui tourne dans l'émulateur supporte l'émulation de la FPU en soft. (Bon, du coup, on passe de très lent à monstrueusement lent, et ça c'est avant qu'on traduise tout en Javascript. Mais c'est un peu le postulat de départ.)

**war-p** · 04/11/2011, 17h23

Ce topic était compréhensible avant ton arrivée

(Møgluglu, je t'aime quand même)

**gregounech** · 05/11/2011, 00h55

Petite question, comment on fait pour en plus d'afficher a chaque frame notre image gros_lapin, pour jouer en boucle un son (ajouté dans le projet par la meme facon que gros_lapin).

Car je veux un gros_lapin qui chante Exile Vilify.

**olih** · 05/11/2011, 10h48

Envoyé par gregounech

Petite question, comment on fait pour en plus d'afficher a chaque frame notre image gros_lapin, pour jouer en boucle un son (ajouté dans le projet par la meme facon que gros_lapin).

Car je veux un gros_lapin qui chante Exile Vilify.

Ça doit être pour la leçon 4 ou 5 ça (ou pour la toute fin va savoir).

**lian** · 07/11/2011, 09h24

Bonjour, j'ai commencé les leçons (je dois être niveau quasi débutant puisque j'ai suivi des UV informatiques dans mes études - genre le jour de la présentation du programme, je ne sais pas où est le bouton on/off de l'ordi) mais il faudrait peut-être préciser dans le magazine où se situe "la section Développé Couché du site". Parce qu'une recherche ne donne pas de résultat rapide et je n'ai pas pensé que ça pourrait être caché dans le forum.

**Anonyme32145** · 07/11/2011, 09h28

Envoyé par lian

Bonjour, j'ai commencé les leçons (je dois être niveau quasi débutant puisque j'ai suivi des UV informatiques dans mes études - genre le jour de la présentation du programme, je ne sais pas où est le bouton on/off de l'ordi) mais il faudrait peut-être préciser dans le magazine où se situe "la section Développé Couché du site". Parce qu'une recherche ne donne pas de résultat rapide et je n'ai pas pensé que ça pourrait être caché dans le forum.

En cherchant "Développez couché" plutôt que "Développé couché", dans la fonction recherche du forum, tu tombes directement sur le résultat. Difficile de faire plus simple.

P.S. : Dans le doute, ça marche aussi en cherchant "Développ* couch*".

**Belhoriann** · 07/11/2011, 12h48

J'ai une petite question :

J'ai commencé il y a maintenant 3 semaines à développer mon propre petit jeu en mode autodidacte. En gros je voudrais faire un shooter spatiale en 2D (vue top-down) avec beaucoup de grinding. Au final j'aimerai un jeu dont le déroulement se rapproche de The Last Stand (le mode coop de DoW II pour ceux qui connaissent) : on affronte des vagues d'ennemies de plus en plus forts, on gagne de l'XP et des points en les affrontant, et quand on crève on retourne à l'écran de customisation du vaisseau (dépense de points d'XP etc...). De cet écran on peut relancer le jeu et affronter de nouveau les vagues successives.

Avec l'aide des tutos de PHstudios, j'ai pu partir d'une base fonctionnelle avec un vaisseau qui tire et des ennemies qui se dirigent vers le joueur en tirant.
J'ai donc construit mon jeu sur cette base, en implémentant un système de santé, d'XP, de vagues d’ennemies, de mouvements inertiels... J'ai aussi un menu "Game Over" qui apparaît quand on meurt et depuis lequel on peut relancer le jeu (On relance la classe PlayScreen en gros.). Voici donc mon problème = Comment puis-je faire pour que la valeur d'XP accumulée pendant une partie ne retombe pas à zero quand on meurt et qu'on relance une partie ? En gros j'aimerai avoir un système de mise en mémoire des stats du joueurs, sans forcément faire un système de sauvegarde traditionnel.
Dois-je faire une classe qui n'hérite de personne dans laquelle je "stock" mes valeurs au moins aussi longtemps que le jeu est lancé ?

Voici l'architecture de mon jeu, si tant est que celui puisse vous éclairer

Merci d'avance pour votre aide.

**gros_bidule** · 07/11/2011, 13h06

Coin,
une manière d'aborder le problème (parmi tant d'autres) :
Si tu veux garder l'XP en mémoire tout au long de la partie, pourquoi ne pas créer une classe associée au joueur (ha, je vois que tu as déjà une classe Player ? Que fait-elle ?), classe qui ne sera instanciée qu'une seule fois, et possédant un compteur d'XP que tu ne fera qu'incrémenter partie après partie. Idéalement, tu peux associer Player au joueur humain, donc tu n'en as qu'une seule instance lorsque tu lances le jeu. Tu n'a aucune raison de la recréer/supprimer entre deux partie, vu que c'est toujours le même joueur.
Si tu veux stocker l'XP lorsque le jeu est éteint...tu n'as pas vraiment le choix : une sauvegarde s'impose. Fichier local dans un format spécifique ? Sérialisation de la classe gérant l'XP (et donc désérialisation de celle-ci au lancement du jeu) ? Sauvegarde sur un serveur en ligne ? Code ?

**Tomaka17** · 07/11/2011, 13h10

Si tu veux que l'XP reste quand tu quittes complètement le jeu (le programme) et que tu le redémarres, t'es obligé de faire un espèce de système de sauvegarde
Pour ça t'es pas obligé de mettre un bouton "sauvegarder" et "charger", tu peux tout bêtement écrire dans un fichier sans rien dire à l'utilisateur, puis le recharger au démarrage

Si c'est juste pour pas perdre l'XP au game over, pourquoi ne pas tout simplement mettre le jeu en pause au moment du game over, puis enlever la pause quand le joueur clique sur continuer

De manière générale il faut bien comprendre un truc quand tu développes un jeu, c'est que tu n'es pas obligé d'avoir une structure du programme qui correspond à ce que tu vois à l'écran
Par exemple c'est pas parce qu'un vaisseau est détruit que tu dois détruire l'objet "vaisseau" qui correspond, c'est pas parce que tu es game over que l'objet "partie en cours" doit être détruit, etc.

**Belhoriann** · 07/11/2011, 13h27

Merci pour vos réponse. En cadeau voici une vidéo du jeu :

Dans un premier temps ce que je veux c'est en effet conserver l'XP entre 2 morts du joueur.

J'ai assayé de créer une classe PlayerStats avec un variable totalXP se mettant à jour en même temps que l'XP normal du joueur. J'ai ensuite appelé la valeur totalXP dans le calcul de l'XP du joueur mais l'XP était toujours 0 après la mort.

Comme j'aimerai avoir d'autres variables que l'XP à conserver (comme des crédits, des ressources (métal, or, energie...)), j'aimerai avoir un système simple et flexible. Et je pense que mettre l'écran en pause à chaque mort est une bonne idée. Voici pour l'instant ce qu'il se passe dans la classe GameOverScreen :

Code:

public class GameOverScreen : MenuScreen
    {
        MenuEntry playagain, quit;

        public GameOverScreen()
        {
            playagain = new MenuEntry(this, "Game Over - Play Again?");
            quit = new MenuEntry(this, "Quit Game");

            TransitionOnTime = TransitionOffTime = TimeSpan.FromSeconds(1);

            Selected = Color.Yellow;
            NonSelected = Color.White;
        }

        public override void Initialize()
        {
            playagain.SetPosition(new Vector2(350, 200), true);
            playagain.Selected += new EventHandler(PlayagainSelect);
            quit.SetRelativePosition(new Vector2(0, SpriteFont.LineSpacing + 5), playagain, true);
            quit.Selected += new EventHandler(QuitSelect);
            MenuEntries.Add(playagain);
            MenuEntries.Add(quit);

        }

        public override void LoadContent()
        {
            ContentManager content = ScreenManager.Content;
            SpriteFont = content.Load<SpriteFont>("Fonts\\Menu");
        }

        void PlayagainSelect(object sender, EventArgs e)
        {
            ExitScreen();
            ScreenManager.AddScreen(new PlayScreen());
        }

        void QuitSelect(object sender, EventArgs e)
        {
            ScreenManager.Game.Exit();
        }

    }

Je suppose qu'il faudrait plutôt que j'appelle la classe PauseScreen quand on crève, et que celle ci enlève la pause et relance les Waves quand on click sur play, plutôt que de relancer carrément un nouveau PlayScreen comme dans la classe GameOverScreen.

**ElGato** · 07/11/2011, 15h27

Fais voir ton implémentation de "player.cs", et la manière dont elle échange des données avec PlayerStats ?

**Belhoriann** · 07/11/2011, 15h34

Arf, désolé j'ai tout viré, je suis en train d'essayer la méthode de pause entre 2 séquence de jeu. Mais je dois avouer que j'en chie aussi, noob inside.

EDIT : J'ai réussi à mettre en pause le jeu lorsque le joueur meurt (la classe GameOverScreen met en pause le jeu au lieu de le "casser"). Il ne faut plus maintenant que je trifouille un truc pour que le joueur respawn et que les vagues d'ennemis se relancent quand on enlève la pause.
Je me dis quand même que j'aimerai bien que certaines données soit enregistrées comme une espèce de score total qui permettrait de débloquer de nouveaux vaisseaux.

**LaVaBo** · 07/11/2011, 17h53

Envoyé par Belhoriann

Arf, désolé j'ai tout viré, je suis en train d'essayer la méthode de pause entre 2 séquence de jeu. Mais je dois avouer que j'en chie aussi, noob inside.

EDIT : J'ai réussi à mettre en pause le jeu lorsque le joueur meurt (la classe GameOverScreen met en pause le jeu au lieu de le "casser"). Il ne faut plus maintenant que je trifouille un truc pour que le joueur respawn et que les vagues d'ennemis se relancent quand on enlève la pause.
Je me dis quand même que j'aimerai bien que certaines données soit enregistrées comme une espèce de score total qui permettrait de débloquer de nouveaux vaisseaux.

Ca ne devrait pas poser de problème.

D'après moi, ta galère c'est parce que tu recrées une instance de ta classe Player en revenant en arrière, par exemple dans la method Initialize d'une de tes classes screen. Si tu trouves où est-ce que l'XP est remise à 0, tu te débloques.
Et tu évites les effets de bord du gameover en faisant une pause, parce qu'il faut que tu réinitialise certains paramètres lors de la partie suivante. Pas celui de l'XP, mais par exemple la fréquence d'apparition des ennemis ou leur puissance. En gros, va te falloir une initialisation la première fois, et une autre les fois après le game over.

Bon, sinon rien à voir, mais

Code:

ScreenManager.AddScreen(new PlayScreen());

c'est normal (noob du C# inside) ? Ca crée pas whatmille instances de PlayScreen sans détruire les précédentes, si on perd et qu'on rejoue plein de fois de suite ?

**L-F. Sébum** · 07/11/2011, 18h54

Envoyé par lian

Il faudrait peut-être préciser dans le magazine où se situe "la section Développé Couché du site". Parce qu'une recherche ne donne pas de résultat rapide et je n'ai pas pensé que ça pourrait être caché dans le forum.

C'est marqué en gros, dans chaque numéro, sous le bandeau de titre de la rubrique.

**Belhoriann** · 07/11/2011, 20h49

Envoyé par LaVaBo

Ca ne devrait pas poser de problème.

D'après moi, ta galère c'est parce que tu recrées une instance de ta classe Player en revenant en arrière, par exemple dans la method Initialize d'une de tes classes screen. Si tu trouves où est-ce que l'XP est remise à 0, tu te débloques.
Et tu évites les effets de bord du gameover en faisant une pause, parce qu'il faut que tu réinitialise certains paramètres lors de la partie suivante. Pas celui de l'XP, mais par exemple la fréquence d'apparition des ennemis ou leur puissance. En gros, va te falloir une initialisation la première fois, et une autre les fois après le game over.

Bon, sinon rien à voir, mais

Code:

ScreenManager.AddScreen(new PlayScreen());

c'est normal (noob du C# inside) ? Ca crée pas whatmille instances de PlayScreen sans détruire les précédentes, si on perd et qu'on rejoue plein de fois de suite ?

Juste pour préciser, le code de GameOverScreen et des autres screens vient des tutos de PHstudios.
Pour ce qui est du fonctionnement du jeu, via le menu principal on lance la classe PlayScreen qui Update toutes les classes et dessine tout ce qu'il y a à dessiner. Ça initialise donc tous les objets qui composent le gameplay, dont le joueur (classe Player). Quand on crève, ça détruit l'instance PlayScreen et ouvre le GameOverScreen, c'est pour ça que cette dernière comporte la ligne "ScreenManager.AddScreen(new PlayScreen());", qui relance le jeu quand on sélectionne "Play Again" en recréant une instance PlayScreen. C'est pour ça que les stats du joueurs sont remises à 0 quand on relance une partie.

Tu vois donc qu'avec cette architecture il est, il me semble, impossible d'initialiser le joueur au début et ne pas le faire au moment de faire "Play Again", puisque dans les deux cas on relance la classe PlayScreen qui initialise le joueur.
Soit je change drastiquement de méthode, ce qui peut être chiant, long et décourageant pour un débutant comme moi, soit je passe par l'astuce de lancer qu'une seule fois PlayScreen et le mettre en pause quand le joueur meurt, ce qui implique de réinitialiser la position du spawn, la vie du joueur, les ennemies... quand on relance la partie.

Cela dit, je me rend compte que le plus frustrant quand on débute c'est de devoir adapter le gameplay de son jeu à ses connaissances techniques.

**Tomaka17** · 07/11/2011, 21h24

Je ne sais pas comment font les studios pro, mais pour ma part je sépare systématiquement données du jeu et affichage

C'est à dire que j'ai une classe "EtatDuJeu" qui contient la position de tous les objets et ce genre de choses, et une classe "AffichageDuJeu" qui va écouter l'instance de "EtatDuJeu" afin de faire l'affichage correspondant
(bon en réalité j'utilise un système d'entités/composants pour représenter l'état du jeu, sinon c'est un peu bordélique)
De cette façon tu peux faire du split screen, tu peux lire l'état du jeu selon une interface commune peu importe si c'est une partie en local ou en multi, tu peux afficher le menu principal tout en continuant à faire tourner le jeu en arrière-plan, etc.

Évidemment t'es pas obligé de faire pareil, mais si ça peut te donner des idées

**LaVaBo** · 08/11/2011, 10h45

Envoyé par Belhoriann

Juste pour préciser, le code de GameOverScreen et des autres screens vient des tutos de PHstudios.
Pour ce qui est du fonctionnement du jeu, via le menu principal on lance la classe PlayScreen qui Update toutes les classes et dessine tout ce qu'il y a à dessiner. Ça initialise donc tous les objets qui composent le gameplay, dont le joueur (classe Player). Quand on crève, ça détruit l'instance PlayScreen et ouvre le GameOverScreen, c'est pour ça que cette dernière comporte la ligne "ScreenManager.AddScreen(new PlayScreen());", qui relance le jeu quand on sélectionne "Play Again" en recréant une instance PlayScreen. C'est pour ça que les stats du joueurs sont remises à 0 quand on relance une partie.

Tu vois donc qu'avec cette architecture il est, il me semble, impossible d'initialiser le joueur au début et ne pas le faire au moment de faire "Play Again", puisque dans les deux cas on relance la classe PlayScreen qui initialise le joueur.
Soit je change drastiquement de méthode, ce qui peut être chiant, long et décourageant pour un débutant comme moi, soit je passe par l'astuce de lancer qu'une seule fois PlayScreen et le mettre en pause quand le joueur meurt, ce qui implique de réinitialiser la position du spawn, la vie du joueur, les ennemies... quand on relance la partie.

Tu peux initialiser la classe Player indépendamment de l'écran de jeu sur lequel tu te trouves, si tu instancies la classe à l'endroit où tu instancies les classes xxxScreen, et pas dans une de ces classes xxxScreen. Par contre là faut qu'un connaisseur précise, n'ayant jamais touché au C#, je ne sais pas quel est ce conteneur.

Envoyé par Belhoriann

Cela dit, je me rend compte que le plus frustrant quand on débute c'est de devoir adapter le gameplay de son jeu à ses connaissances techniques.

C'est pas faux, mais c'est bien classe ton projet, d'après la vidéo, pour quelqu'un qui débute complètement.

**Belhoriann** · 08/11/2011, 12h16

Envoyé par Tomaka17

Je ne sais pas comment font les studios pro, mais pour ma part je sépare systématiquement données du jeu et affichage

C'est à dire que j'ai une classe "EtatDuJeu" qui contient la position de tous les objets et ce genre de choses, et une classe "AffichageDuJeu" qui va écouter l'instance de "EtatDuJeu" afin de faire l'affichage correspondant
(bon en réalité j'utilise un système d'entités/composants pour représenter l'état du jeu, sinon c'est un peu bordélique)
De cette façon tu peux faire du split screen, tu peux lire l'état du jeu selon une interface commune peu importe si c'est une partie en local ou en multi, tu peux afficher le menu principal tout en continuant à faire tourner le jeu en arrière-plan, etc.

Évidemment t'es pas obligé de faire pareil, mais si ça peut te donner des idées

Pour l'instant la structure de mon jeu est la suivante (toujours tirée des tuto de PHstudios) :

J'ai une classe GameplayObject qui s'occupe de définir des status (Active, Dying, Dead... Ça sert à définir des logic quand par exemple un ennemi est en train de crever) ou des méthodes du genre :

Code:

Vector2 position = Vector2.Zero;
        public Vector2 Position
        {
            get { return position; }
            set { position = value; }
        }

Toutes mes classes destinées à créer des objets du jeu (Player, Ennemies, Lasers...) héritent de cette classe. Ca permet de créer une liste dans la classe PlayScreen du genre :

Code:

static List<GameplayObject> addedObjects = new List<GameplayObject>();

        public static void Add(GameplayObject newGameObject)
        {
            addedObjects.Add(newGameObject);
        }

On update tout ça comme ça (dans la partie Update) :

Code:

for (int i = 0; i < currentGameObjects.Count; i++)
                {
                    if (currentGameObjects[i].Status == ObjectStatus.Dead)
                        gameObjects.Remove(currentGameObjects[i]);
                    else
                        currentGameObjects[i].Update(gameTime);
                }

Ainsi, on peut afficher facilement tout le contenu de la liste dans la partie Draw :

Code:

spriteBatch.Begin();
                for(int i = 0; i < gameObjects.Count; i++)
                {
                    gameObjects[i].Draw(gameTime, spriteBatch);
                }

Mais je viens de voir que dans la partie LoadContent il y a ça :

Code:

gameObjects.Add(player);

Faudrait-il que je modifie les choses pour éviter que le joueur se retrouve dans la liste générale où se trouve les ennemies pour pouvoir le gérer indépendamment ? (mmh la réponse est dans la question...)

**LaVaBo** · 08/11/2011, 12h33

Envoyé par Belhoriann

Pour l'instant la structure de mon jeu est la suivante (toujours tirée des tuto de PHstudios) :

J'ai une classe GameplayObject qui s'occupe de définir des status (Active, Dying, Dead... Ça sert à définir des logic quand par exemple un ennemi est en train de crever) ou des méthodes du genre :

Code:

Vector2 position = Vector2.Zero;
        public Vector2 Position
        {
            get { return position; }
            set { position = value; }
        }

Toutes mes classes destinées à créer des objets du jeu (Player, Ennemies, Lasers...) héritent de cette classe. Ca permet de créer une liste dans la classe PlayScreen du genre :

Code:

static List<GameplayObject> addedObjects = new List<GameplayObject>();

        public static void Add(GameplayObject newGameObject)
        {
            addedObjects.Add(newGameObject);
        }

On update tout ça comme ça (dans la partie Update) :

Code:

for (int i = 0; i < currentGameObjects.Count; i++)
                {
                    if (currentGameObjects[i].Status == ObjectStatus.Dead)
                        gameObjects.Remove(currentGameObjects[i]);
                    else
                        currentGameObjects[i].Update(gameTime);
                }

Ainsi, on peut afficher facilement tout le contenu de la liste dans la partie Draw :

Code:

spriteBatch.Begin();
                for(int i = 0; i < gameObjects.Count; i++)
                {
                    gameObjects[i].Draw(gameTime, spriteBatch);
                }

Mais je viens de voir que dans la partie LoadContent il y a ça :

Code:

gameObjects.Add(player);

Faudrait-il que je modifie les choses pour éviter que le joueur se retrouve dans la liste générale où se trouve les ennemies pour pouvoir le gérer indépendamment ? (mmh la réponse est dans la question...)

Laisse-le dans la liste si tu dessines en la parcourant.
De toute façon, tu peux accéder directement à l'instance avec la variable player, donc cumuler les 2 aspects : listes des objets du jeu et accès direct aux données de player.

**Belhoriann** · 08/11/2011, 12h39

Envoyé par LaVaBo

Laisse-le dans la liste si tu dessines en la parcourant.
De toute façon, tu peux accéder directement à l'instance avec la variable player, donc cumuler les 2 aspects : listes des objets du jeu et accès direct aux données de player.

Ouep tu as raison. Mais ce que j'ai fait hier c'est créé un nouvel état spécial pour le joueur appelé PlayerDead. De cette manière je différencie la mort du joueur et la mort de tous les autres GameplayObjects. Finalement ça me permet d'éviter d'enlever le joueur de la liste puisque l'état considéré pour cela est l'état Dead :

Code:

 for (int i = 0; i < currentGameObjects.Count; i++)
                {
                    if (currentGameObjects[i].Status == ObjectStatus.Dead)
                        gameObjects.Remove(currentGameObjects[i]);
                    else
                        currentGameObjects[i].Update(gameTime);
                }

La programmation objet c'est formidable, mais si on n'est pas assez attentif ou qu'on utilise du code créé par quelqu'un d'autre on se retrouve rapidement comme lui :

**TheToune** · 08/11/2011, 12h52

Pour moi, d'un point de vue conception objet, si ton jeu posséde des caractéristiques persistances entre parties c'est qu'elles n'appartiennent pas à la classe Player.
Par contre rien n’empêche ta classe player d'aller influencer ou utiliser ces variables en allant les chercher dans une classe "Jeu" par exemple.

Discussion: Développez Couché, saison 1 : le topic officiel

Outils de la discussion

Règles de messages