IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Langage C++ Discussion :

recherche la meilleure architecture


Sujet :

Langage C++

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre très actif

    Homme Profil pro
    Étudiant
    Inscrit en
    Novembre 2011
    Messages
    685
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Novembre 2011
    Messages : 685
    Par défaut recherche la meilleure architecture
    Bonjour,

    Parmi la myriade de projets que j'ai en cours (je sais c'est pas bien de se disperser...), il en est un qui a assez avancé pour que je songe à le recommencer

    Il s'agit d'un jeu de combat 2D réalisé grâce à SFML, assez basique. J'ai réalisé un prototype assez intéressant je trouves, qui gère animations, effets sonores, les différentes actions d'un combattant, les collisions, les barres de vie, etc

    Par contre je n'ai pas vraiment intégré de choses plus basiques comme les menus (j'ai juste un pauvre écran pour sélectionner un joueur parmi 3), et je voudrais ajouter des fonctionnalités plus importantes (jouer en ligne, système de points (combos), système de temps (compte à rebours).

    Je me suis donc lancé dans une phase de conception, en commençant par les cas d'utilisation.

    Maintenant, je souhaiterais rentrer dans une phase intermédiaire, avant le diagramme de classe, pour concevoir le meilleur système possible, l'architecture la plus logique et la plus solide possible.

    Et c'est là que j'ai besoin de vous. Existe-t-il des modèles qui correspondraient à mes attentes et qui font parti de vos connaissances ?

    Architecture Client/serveur pour les partie en ligne (attention il s'agira dans un premier temps de pouvoir faire une partie sur deux machines distantes, rien de plus), Multi-threading (mon prototype est assez fluide, mais je suis sur que cela pourrait être mieux, si chaque joueur était un thread), et quelle modèle d'architecture pour un jeu de ce type avec menus, partie, solo, en ligne, etc...

    Merci d'avance pour ceux qui prendront le temps de me répondre. Si vous avez besoin de plus de données, demandez moi ^^

  2. #2
    Membre Expert

    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2007
    Messages
    1 895
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Septembre 2007
    Messages : 1 895
    Par défaut
    Quand on parle d'architecture logicielle, il faut noter une chose fondamentale : il n'existe pas une mais des architectures. On ne peut pas dire quelle est la meilleure architecture possible parmi plusieurs parce qu'il n'existe aucun système de mesure objectif de la qualité d'une architecture (il existe des mesures quantitatives, mais elles ne disent rien sur la qualité). Ce point étant admis, je préviens quand même que ça va être plein de pub gratuite pour moi (on ne se refait pas).

    1) Existe-t-il des modèles qui correspondraient à mes attentes et qui font parti de vos connaissances ?
    La gestion de plusieurs écrans de jeu se fait grâce à un pattern du type state. Cf. http://blog.emmanueldeloget.com/inde...chines-a-etats

    On peut mixer ça avec une gestion par calques pour représenter les différentes informations visibles à l'écran. Cf http://blog.emmanueldeloget.com/inde...onctionnalites (désolé pour les images ; il y a encore des trou dans mes articles un peu ancien, à cause d'un changement de version de dotclear il y a deux ous trois ans). Cf aussi http://blog.emmanueldeloget.com/inde...function-layer ou j'ai essayé de formaliser un peu mieux ce système.

    J'entends déjà dire que de manière sous-jacente, on a une pseudo-triade MVC pour gérer le jeu lui même (M=modèle=le modèle conceptuel du jeu (data et comportements) ; V=view=l'affichage ; C=controler=la gestion des input utilisateur). C'est presque vrai, mais en fait, c'est faux. Un jeu n'est pas construit sur le modèle MVC (d'ailleurs, rien n'est construit sur le modèle MVC ; c'est un autre débat). 99,9% des jeux (et pour le dernier 0,01%, on est vraiment dans l'exotique) sont construits sur un modèle pseudo-évènementiel basé sur un pipeline - que ce pipeline soit multi-threadé ou non. On acquiert les entrées utilisateur, on calcule les changements qu'elles impliquent, et on affiche le résultat. C'est un pipeline.

    Si on veut aller dans le domaine du multithreadé, je pense que ton approche n'est pas la bonne. Une thread par joueur peut être une bonne idée dans certains cas (et peut être dans le tiens) mais ce n'est pas ça qu'il faut paralléliser - principalement parce que ça n'a pas de sens : c'est au final l'affichage qui te bloque et qui te synchronise. Il est préférable de paralléliser les étapes du pipeline, en effectuant une synchronisation lâche (cf. http://blog.emmanueldeloget.com/inde...des-jeux-video et http://www.gamasutra.com/view/featur...ine_basics.php ; l'article de Gamasutra semble s'appliquer à la 3D, mais en fait ce n'est pas le cas : il est plus large que ça).

    Architecture Client/serveur pour les partie en ligne
    Que tu crois. Dans l'absolu, oui, tu as raison. Seulement il ne faut pas oublier que tu es dans un monde sans serveur centralisé ; ton serveur est obligatoirement l'un des clients (et ça peut être n'importe lequel). Tu peux aussi tenter l'aventure du P2P, en sachant que ça pose beaucoup de problème sur la validité des données reçues par un joueur (ce que, par ricochet, permet bien souvent à l'indélicat de tricher).

    Idéalement, le jeu est toujours en mode client/serveur, même pour une partie en solo. Au niveau architecture, c'est le plus propre (un seul code path), même si on risque d'avoir un problème de performances lié à l'overhead des communications réseau (problème qui existera pour tous les autres joueurs en dehors du host de la partie, vu que lui-seul est en local ; c'est un problème à bien comprendre avant de faire un développement de ce type : comment faire pour que celui qui héberge la partie ne soit pas avantagé par le fait que son lag est inexistant ?).

    Si tu as des questions plus précises, j'aurais peut-être des réponses plus précises
    [FAQ des forums][FAQ Développement 2D, 3D et Jeux][Si vous ne savez pas ou vous en êtes...]
    Essayez d'écrire clairement (c'est à dire avec des mots français complets). SMS est votre ennemi.
    Evitez les arguments inutiles - DirectMachin vs. OpenTruc ou G++ vs. Café. C'est dépassé tout ça.
    Et si vous êtes sages, vous aurez peut être vous aussi la chance de passer à la télé. Ou pas.

    Ce site contient un forum d'entraide gratuit. Il ne s'use que si l'on ne s'en sert pas.

  3. #3
    Membre très actif

    Homme Profil pro
    Étudiant
    Inscrit en
    Novembre 2011
    Messages
    685
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Novembre 2011
    Messages : 685
    Par défaut
    Bonjour Mr. Deloget,

    Tout d'abord merci pour votre réponse.

    J'ai commencé à regarder le liens sur les machines à états, et pour l'automate (je savais bien que ça me servirait un jour ces trucs là ) j'aurais plusieurs questions :
    - j'ai l'impression qu'il manque des transitions sur votre schéma, rien de bien grave, mais on est obligé de passer par l'état Jeu avant de retourner au menu général, quand on est dans l'état Config.
    - J'aimerais savoir si rendre l'automate fini (ça il l'est déjà) déterministe présente un intérêt sur le plan conceptuel et en terme algorithmique (complexité même si cela doit être dur de faire un lien aussi direct, spécialisation plus précise ou trop précise, etc)
    - et le rendre complet alors ? s'assurer que dans tous les états on est une transition ne permettrait-il pas de gérer aussi les cas d'erreur (je ne parle ici plus du schéma que vous proposer mais de manière générale)


    Merci d'avance pour votre réponse.

    Cordialement,

  4. #4
    Membre Expert

    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2007
    Messages
    1 895
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Septembre 2007
    Messages : 1 895
    Par défaut
    Citation Envoyé par Kaamui Voir le message
    Bonjour Mr. Deloget,

    Tout d'abord merci pour votre réponse.

    J'ai commencé à regarder le liens sur les machines à états, et pour l'automate (je savais bien que ça me servirait un jour ces trucs là ) j'aurais plusieurs questions :
    - j'ai l'impression qu'il manque des transitions sur votre schéma, rien de bien grave, mais on est obligé de passer par l'état Jeu avant de retourner au menu général, quand on est dans l'état Config.
    C'est un mauvais choix, certes, mais rien de bien fondamental

    Citation Envoyé par Kaamui Voir le message
    - J'aimerais savoir si rendre l'automate fini (ça il l'est déjà) déterministe présente un intérêt sur le plan conceptuel et en terme algorithmique (complexité même si cela doit être dur de faire un lien aussi direct, spécialisation plus précise ou trop précise, etc)
    Non déterministe signifie que lorsqu'on est dans un état A il existe potentiellement plusieurs états Bi (i variant de 1 à n) ou la transition A-->Bi est la même. Dans ce cas, impossible de choisir quel est l'état cible. Il est donc nécessaire de rendre l'automate déterministe avant de pouvoir l'implémenter.

    Citation Envoyé par Kaamui Voir le message
    - et le rendre complet alors ? s'assurer que dans tous les états on est une transition ne permettrait-il pas de gérer aussi les cas d'erreur (je ne parle ici plus du schéma que vous proposer mais de manière générale)
    Complet ? C'est à dire ? Dès lors que vous spccifiez correctement toutes les transitions menant à tous les états dont vous avez besoin, votre automate est "complet", dans le sens ou vous n'avez rien à rajouter.
    [FAQ des forums][FAQ Développement 2D, 3D et Jeux][Si vous ne savez pas ou vous en êtes...]
    Essayez d'écrire clairement (c'est à dire avec des mots français complets). SMS est votre ennemi.
    Evitez les arguments inutiles - DirectMachin vs. OpenTruc ou G++ vs. Café. C'est dépassé tout ça.
    Et si vous êtes sages, vous aurez peut être vous aussi la chance de passer à la télé. Ou pas.

    Ce site contient un forum d'entraide gratuit. Il ne s'use que si l'on ne s'en sert pas.

  5. #5
    Membre très actif

    Homme Profil pro
    Étudiant
    Inscrit en
    Novembre 2011
    Messages
    685
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Novembre 2011
    Messages : 685
    Par défaut
    Citation Envoyé par Emmanuel Deloget Voir le message
    Dans ce cas, impossible de choisir quel est l'état cible. Il est donc nécessaire de rendre l'automate déterministe avant de pouvoir l'implémenter.
    Je sais ce qu'est un automate, déterministe ou non, je posais cette question car il ne me parait pas impossible d'implémenter l'automate tel que vous le présentez, mais en cela j'ai peut-être tort.

    Complet ? C'est à dire ? Dès lors que vous spécifiez correctement toutes les transitions menant à tous les états dont vous avez besoin, votre automate est "complet", dans le sens ou vous n'avez rien à rajouter.
    Un automate est complet si pour chaque état, chaque transition est rattachée. On utilise pour cela des "états puits". Par exemple, pour un état A et un état B deux transition a et b on a l'expression rationnelle (j'vais pas dessiner des automates en ascii ) suivante :
    a.(a+b)

    alors l'automate construit avec cette expression rationnelle sera déterministe, fini et incomplet (aucune transition b partant de A). Pour le rendre complet on effectuera une transition b vers un état Puits (pas d'état final, pas de transition de retour vers un autre état, et une transition a qui boucle sur cet état puits).

    Et en faisant l'analogie avec le schéma, je me suis dit que rendre un automate complet pourrait peut-être servir à gérer les cas d'erreur, vous voyez ?



    Pour rebondir sur le reste. Cette méthode de gérer les différents écrans de mon jeu me plait.
    Pour l'architecture client/serveur, je peux donc en conclure que ce serait une bonne base pour mon jeu ?

Discussions similaires

  1. recherche de meilleure solution, nombre de combinaison gigantesque
    Par Zwiter dans le forum Algorithmes et structures de données
    Réponses: 16
    Dernier message: 13/05/2009, 11h42
  2. meilleur architecture du web services
    Par Smix007 dans le forum Services Web
    Réponses: 4
    Dernier message: 21/01/2007, 15h14
  3. recherche le meilleur langage
    Par repié dans le forum Windows
    Réponses: 5
    Dernier message: 10/10/2006, 14h14
  4. Meilleure architecture pour un moteur 3D
    Par djo.mos dans le forum Moteurs 3D
    Réponses: 117
    Dernier message: 26/05/2006, 11h29

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo