Discussion :

[Kaamui]

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 ^^

[Emmanuel Deloget]

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

[Kaamui]

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,

[Emmanuel Deloget]

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

- 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.

- 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.

[Kaamui]

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 ?