Journal Problème de conception pour un jeu

Posté par .
Tags : aucun
0
24
juin
2004
Cher journal,

Je suis en train de réaliser un petit jeu de réflexion. Le jeu se joue à deux sur une grille. Je voudrais avoir le design le meilleur possible... Je souhaite que chacun des deux joueurs puisse être soit humain soit IA. J'ai codé le modèle du jeu, créé une vue de la grille et un contrôleur, et j'ai branché tout ça avec le pattern MVC.

Ma question est la suivante : lorsque c'est à l'ordinateur de jouer, quelle entité devrait appeler sa méthode "jouer" ?

J'ai essayé de la façon suivante : dans le cas où le joueur est automatique une vue est aussi un contrôleur, et lorsque cet objet est appelé par la méthode update du modèle, il met à jour le modèle avec le coup qu'il a calculé. Un des problèmes que j'ai est alors que cette méthode "update" est appelée à nouveau par le modèle, puis encore et encore, ce qui n'est pas très propre pour un traitement qui n'a aucune raison d'être récursif.

Voilà, j'espère que ma question est suffisament claire pour pouvoir amener des débuts de réponses...

Merci à tous !
  • # Question claire

    Posté par . Évalué à 0.

    Commençons par le début: Tu utilises quel langage ?
    • [^] # Re: Question claire

      Posté par . Évalué à 5.

      Tu utilises quel langage ?

      Non, la tu commences par la fin :) !
      • [^] # Re: Question claire

        Posté par (page perso) . Évalué à 3.

        De là à penser qu'en général les développeurs de jeux pissent du C++ avant même d'avoir réfléchi à la conception de leur programme....
    • [^] # Re: Question claire

      Posté par . Évalué à 3.

      C'est une question de design pattern (modèle de conception ?), c'est donc censé être indépendant du language employé, en tout cas avec de bons languages.

      Ya juste que c'est un modèle objet et que donc il vaut mieux employer un language orienté objet.

      (Bon, alors, c'est quoi déjà, l'idée du MVC... *Cherche* *cherche* ... Purée ça ne fait vraiment qu'un an que j'ai étudié ça ?)
    • [^] # Re: Question claire

      Posté par . Évalué à 2.

      Pour répondre à ta question, c'est du C++. Mais ce pourrait être n'importe quel langage OO.
  • # Re :

    Posté par . Évalué à 10.

    Mmmm.... pour moi un joueur IA ou un joueur normal, c'est la même chose : ce sont deux joueurs. Il doivent implémenter l'interface joueur qui demande la méthode jouer().

    Pour le joeur normal, jouer() veut dire : attendre une action de l'utilisateur et mettre à jour la vue.

    Pour le joueur IA, jouer() veut dire: calculer le coup, le jouer et mettre à jour la vue.

    Ta méthode de faire en sorte qu'une vue soit aussi un contrôleur me surpasse totalement.... Le modèle MVC sépare justement ces deux entités pour que l'on ne s'embrouille pas les pinceaux. Si tu les réunis, ça va pas aller.

    Ton MVC modélise ton interface de jeu :
    - le modèle est la représentation en mémoire de ton jeu (ta grille)
    - la vue est l'ensembe des grilles représentant le modèle (prenons un jeu de morpion par exemple)
    - le controleur est l'objet qui réagit aux actions et met à jour les données et toutes les vues qui se sont enregistrées auprès de lui.

    Les joueurs sont des objets externes au MVC mais qui vont agir sur le controleur. Et il ne faut surtout pas faire de distinction à priori en tre un joueur IA et un joueur utilisateur !
    • [^] # Re: Re :

      Posté par (page perso) . Évalué à 2.

      <mode slurp on>
      Ton commentaire est génial !
      J'y apprends le pattern MVC et c'est très bien expliqué.
      Et en même temps il montre une petite faiblesse du système de notation de linuxfr : j'aurai bien aimé t'intéressanter plusieurs fois de suite (même si c'est la première fois que le cas se présente à moi).
      <mode slurp off>
      • [^] # Re: Re :

        Posté par . Évalué à 2.

        Hum... merci ;-)

        Pour tout ce qui est programmation objet, je te conseille de trainer sur fr.comp.objet. Y'a pleins de gens qui sont prêts à donner leur commentaires sur des conceptions.

        En revanche c vrai que le traffic n'est pas encore énorme.
        • [^] # Re: Re :

          Posté par . Évalué à 1.

          Merci pour le newsgroup, je vais peut être aller y jeter un oeil.
    • [^] # Re: Re :

      Posté par . Évalué à 1.

      > Il doivent implémenter l'interface joueur qui demande
      > la méthode jouer().

      D'accord. Mais c'est là le problème. Qui va appeler la méthode jouer de l'ordinateur ?

      Si on se place avec une interface ligne de commande c'est simple, on a un objet C qui appele successivement les méthodes jouer() des deux joueurs, qu'ils soient humains ou pas.

      Maintenant avec une interface graphique, on ne peut pas faire ça puisque c'est l'interface (par le contrôleur) qui va appeler les méthodes jouer().

      >Pour le joueur IA, jouer() veut dire: calculer le coup, le jouer et
      > mettre à jour la vue.

      Dans le MVC, ce n'est pas tout à fait ça... jouer() met à jour le modèle, et le modèle appele la méthode update() de toutes les vues qui sont enregistrées.
      C'est pour cela que j'ai créé un objet à la fois vue et contrôleur : comme la vue est la seule à être prévenue d'un changement de modèle, et que le contrôleur est le seul à pouvoir mettre à jour le modèle, ça paraît cohérent.

      >Ta méthode de faire en sorte qu'une vue soit aussi un
      > contrôleur me surpasse totalement.... Le modèle MVC sépare
      > justement ces deux entités pour que l'on ne s'embrouille pas
      > les pinceaux.
      Le but est surtout de séparer le modèle de l'interface (vue+contrôleur). D'après ce que j'ai pu voir, vue et contrôleur sont souvent liés.
      • [^] # Re: Re :

        Posté par (page perso) . Évalué à 1.

        Pour moi, les joueurs (IA ou interface d'un humain) doivent implémenter une interface commune pour s'enregistrer auprès de la partie.

        Il suffit d'avoir dans cette interface une méthode pour prévenir que c'est à ton tour de proposer un coup. (ce qui n'empèche pas à l'IA de commencer à réfléchir avant son tour si tu utilises des threads)
        • [^] # Re: Re :

          Posté par . Évalué à 1.

          >Il suffit d'avoir dans cette interface une méthode pour
          > prévenir que c'est à ton tour de proposer un coup.

          Dans la méthode update() de l'IA, celle-ci vérifie si c'est son tour et dans ce cas joue. Elle met donc à jour le modèle. Le modèle appele les méthodes update() des vues et des autres IA éventuelles .C'est là qu'est mon pb :la première méthode update ne s'est pas terminée et donc on va avoir une récursivité.

          En fait si je reste dans ce schéma MVC, il faudrait que ma méthode update(), ou que les mises à jour du modèle soient asynchrones. Mais aller programmer des threads pour un jeu de morpion c'est lourdaud...
  • # Un peu de précision ?

    Posté par . Évalué à 2.

    Un pro d'algorithmique qui a déjà fait ça 30 fois comprendra peut-être immédiatement le problème, mais de mon côté, j'ai du mal à comprendre quel enchaînement logique fait que le programme "appelle la méthode update encore et encore" (quelle méthode update, encore et encore c'est combien de fois et comment.)
    Je crois que la logique de la séquence d'appels entre objets dépend beaucoup de la façon dont un 'coup' de l'IA est représentée par l'interface utilisateur (décomposé, ou alors le résultat final, point barre.) Bref, en restant général comme ça, je sais pas si quelqu'un peut répondre.

    De mon côté je séparerais quand même vue et contrôleur, en faisant en sorte que la vue ait deux comportements différents suivant que le joueur est humain ou IA (ce serait la vue du joueur IA qui appelle la méthode "jouer", bien sûr). Forcément, il y a des chances que ça implique de fournir un bon paquet d'interfaces supplémentaires entre vue et contrôle.
    • [^] # Re: Un peu de précision ?

      Posté par . Évalué à 1.

      > j'ai du mal à comprendre quel enchaînement logique fait que le
      > programme "appelle la méthode update encore et encore

      Le MVC fonctionne de la façon suivante :
      Tu as 3 types d'entités :
      - le modèle qui contient les données applicatives
      - les vues qui représentent ces données
      - les contrôleurs qui mettent à jour le modèle.

      Le modéle ne connait qu'une chose des vues : elles ont une méthode update(). Le modèle ne connait rien des contrôleurs.

      Au lancement, le modèle est créé. Les vues s'incrivent auprès du modèle (le modele possede une méthode du style register(vue)). Le modèle conserve la liste des vues qui se sont enregistrées.

      Lorsque le contrôleur fait une mise à jour du modèle, ce dernier s'en aperçoit et appele successivement la méthode update() des vues enregistrées.


      > ce serait la vue du joueur IA qui appelle la méthode "jouer",
      > bien sûr
      Donc en fait c'est un contrôleur (puisque jouer() modifie mon modèle). Tu arrives au même point que moi. Et c'est là que ça coince...
  • # MVC pour un jeu ?

    Posté par . Évalué à 1.

    Euh, tu es sûr que le paradigme MVC est bien adapté à ton cas ? En général ça s'utilise surtout dans les applis classiques avec interface graphique, car elles sont principalement gérées par événements et le système ne fait rien tant qu'il n'a pas à traiter d'événement.

    Dans le cas d'un jeu, en général le fonctionnement n'est pas basé sur une boucle d'attente d'événements, mais sur une boucle qui met à jour en permanence les différents objets. Ca ne me paraît pas trop adapté d'utiliser le MVC dans ce cadre.
    • [^] # Re: MVC pour un jeu ?

      Posté par . Évalué à 1.

      T'as pas lu très loin, c'est un jeu de réflexion, pas un jeu d'action, RTS ou autre...
    • [^] # Re: MVC pour un jeu ?

      Posté par . Évalué à 1.

      C'est une appli classique avec interface graphique. Mais ta remarque sur l'utilisation ou non du MVC est pertinente...
      Est-ce vraiment le bon pattern à utiliser dans mon cas ?
      • [^] # Re: MVC pour un jeu ?

        Posté par . Évalué à 1.

        Est-ce qu'il se passe plein de choses (notamment à l'affichage) pendant que chaque joueur a la main ? Si la réponse est non alors MVC va pile poil. Si c'est oui ce sera peut-être MVC mais mêlé à des patterns classiques de jeux (comme la gestion du temps).
        • [^] # Re: MVC pour un jeu ?

          Posté par . Évalué à 1.

          La réponse est non : Il n'y a que la grille qui soit redessinée après chaque coup.
          Est-ce que tu aurais un lien ou deux sur les patterns classques de jeux dont tu parles ? Mon pb doit être très classique a priori, et il doit bien exister quelque chose !
          • [^] # Re: MVC pour un jeu ?

            Posté par . Évalué à 1.

            Là j'en ai pas en tête, mais ton truc est très simple, je ne pense pas qu'il y ait de design pattern pour ce cas là. En général on en fait quand il y a un truc embêtant dans l'histoire. Là (à moins que j'ai loupé un truc) tu as un bon vieux classique :

            Pour chaque joueur : {
            - attente action / réflexion
            - appliquer
            - affichage
            }
            et le tout en boucle infinie.

            Sachant que ta classe joueur aura comme sous classe "joueur réel" et "ia".

            Comme tu es dans une situation où on attend le joueur, tu n'as pas de problèmes de synchro, de choses à faire tourner en parallèle (ou comme si), etc.

            Si tu as des animations, des événements qui ont lieu en permanence, il faut gérer en orienté temps, et non orienté tour. Ca revient à poser des attentes dont le temps est bien calculé, et l'attente joueur ne doit pas être bloquante. Si tu veux un exemple simple, va voir la doc SDL à propos des entrées du joueur.

            Sinon pour des patterns, voir les sites genre gamedev.net, flipcode, gamasutra, etc. tu trouveras ton bonheur.(mais c'est vaste, va falloir fouiller !).

            Et puis à propos de patterns, ne pas oublier les classiques de Gamma et al qui restent souvent pertinents dans le cas particulier des jeux.
            • [^] # Re: MVC pour un jeu ?

              Posté par . Évalué à 1.

              Je précise que ma boucle est pas forcément orientée MVC... pour le MVC faudrait l'écrire plus "orienté événement".
            • [^] # Re: MVC pour un jeu ?

              Posté par . Évalué à 1.

              > Et puis à propos de patterns, ne pas oublier les classiques de
              > Gamma et al qui restent souvent pertinents dans le cas particulier
              > des jeux.

              Voir aussi :
              http://www.gamasutra.com/patterns/(...)

              Malheureusement le forum n'est plus accessible depuis quelques mois, il y avait quelques discussions intéressantes dessus :/

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.