Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 6 sur 15 PremièrePremière 1234567891011121314 ... DernièreDernière
Affichage des résultats 151 à 180 sur 448
  1. #151
    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.

  2. #152
    Citation Envoyé par Esotsm Voir le message
    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.
    Dernière modification par L-F. Sébum ; 01/11/2011 à 17h26.

  3. #153
    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.

  4. #154
    Citation Envoyé par Esotsm Voir le message
    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.

  5. #155

  6. #156
    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.

  7. #157
    Citation Envoyé par L-F. Sébum Voir le message

    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.

  8. #158
    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

  9. #159
    Citation Envoyé par Azerty Voir le message


    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.

  10. #160
    Citation Envoyé par Tomaka17 Voir le message
    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.)

  11. #161
    Ce topic était compréhensible avant ton arrivée (Møgluglu, je t'aime quand même)
    Citation Envoyé par Snakeshit Voir le message
    Mais comme on me l'a appris dans la Marine, plus les choses sont automatisées, moins ça consomme de cases plus vous en avez de libre pour choses utiles, comme penser à des filles dénudées .

  12. #162
    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.


  13. #163
    Citation Envoyé par gregounech Voir le message
    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).

  14. #164
    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.
    Windows 10 64 bits – Stardew Valley, an I / Dota Underlords / Fantasy General II

  15. #165
    Citation Envoyé par lian Voir le message
    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*".
    Citation Envoyé par Smoke It Voir le message
    je suis flexitarien, en plus c'est à la mode !

  16. #166
    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.

  17. #167
    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 ?

  18. #168
    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.
    Rust fanboy

  19. #169
    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.

  20. #170
    Fais voir ton implémentation de "player.cs", et la manière dont elle échange des données avec PlayerStats ?
    Manuscrit : ça parle bouquins, et c'est tout. Aujourd'hui Ask Maïa ! ou la preuve qu'au moins une bloggueuse sait écrire.

  21. #171
    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.
    Dernière modification par Belhoriann ; 07/11/2011 à 17h23.

  22. #172
    Citation Envoyé par Belhoriann Voir le message
    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 ?

  23. #173
    Citation Envoyé par lian Voir le message
    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.

  24. #174
    Citation Envoyé par LaVaBo Voir le message
    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.

  25. #175
    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
    Rust fanboy

  26. #176
    Citation Envoyé par Belhoriann Voir le message
    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.

    Citation Envoyé par Belhoriann Voir le message
    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.

  27. #177
    Citation Envoyé par Tomaka17 Voir le message
    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...)

  28. #178
    Citation Envoyé par Belhoriann Voir le message
    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.

  29. #179
    Citation Envoyé par LaVaBo Voir le message
    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 :


  30. #180
    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.

Page 6 sur 15 PremièrePremière 1234567891011121314 ... DernièreDernière

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •