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 !
Journal Problème de conception pour un jeu
24
juin
2004
# Question claire
Posté par Obsidian . Évalué à 0.
[^] # Re: Question claire
Posté par jemore . Évalué à 5.
Non, la tu commences par la fin :) !
[^] # Re: Question claire
Posté par gc (site web personnel) . Évalué à 3.
[^] # Re: Question claire
Posté par Miair Patreau . Évalué à 3.
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 norbs . Évalué à 2.
# Re :
Posté par Damien Metzler . Évalué à 10.
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 Florent C. . Évalué à 2.
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 Damien Metzler . Évalué à 2.
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 norbs . Évalué à 1.
[^] # Re: Re :
Posté par norbs . Évalué à 1.
> 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 Wawet76 (site web personnel) . Évalué à 1.
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 norbs . Évalué à 1.
> 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 Miair Patreau . Évalué à 2.
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 norbs . Évalué à 1.
> 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 Frédéric Lopez . Évalué à 1.
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 Bière Drabo . Évalué à 1.
[^] # Re: MVC pour un jeu ?
Posté par norbs . Évalué à 1.
Est-ce vraiment le bon pattern à utiliser dans mon cas ?
[^] # Re: MVC pour un jeu ?
Posté par Bière Drabo . Évalué à 1.
[^] # Re: MVC pour un jeu ?
Posté par norbs . Évalué à 1.
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 Bière Drabo . Évalué à 1.
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 Bière Drabo . Évalué à 1.
[^] # Re: MVC pour un jeu ?
Posté par Frédéric Lopez . Évalué à 1.
> 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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.