Discussion :

[Invité]

Bonsoir,

Je travaille actuellement sur un remake du célèbre Space Invaders. Celui-ci sera codé en C++ à l'aide de différentes librairies, et doit me permettre d'améliorer mes compétences et de les approfondir.
Le Game Design Document étant bien avancé, je commence à me poser quelques questions concernant la conception. Bien que le projet puisse paraitre simple aux premiers abords, je veux le rendre le plus modulaire et propre possible pour qu'il puisse facilement être repris.

Etant donné que j'utilise plusieurs librairies, je compte donc dans un premier temps créer un moteur de jeu 2D (un peu comme le Unreal Engine ou le CryEngine dans la 3D). Il portera le nom de 2DBytz Engine et doit me permettre de développer des applications 2D en un minimum de temps.

Celui-ci sera basé sur les librairies suivantes :

• Graphisme / Fenêtrage : SFML
• Son : FMOD Ex
• Réseau : RakNet
• Utilitaires : des librairies maisons, ajoutées au fur et à mesure selon les besoins

Je souhaiterai donc faire un lien entre ces librairies et faciliter leur utilisation au travers de mon moteur.
Seulement je ne vois pas trop comment m'y prendre pour le moment :

• Chaque module peut-il être utilisable indépendamment ?
• Cela a-t-il un réel intérêt (bien que le moteur puisse servir à de multiples projets) ?
• Comment relier tout ceci ?
• Comment avoir un niveau élevé d'abstraction ?

J'ai juste besoin du déclic et de remarques pour débuter l'analyse (UML), puis la conception (programmation).

Merci d'avance pour votre participation !

Qui sait, ce moteur pourra peut-être vous servir

[Invité]

Après quelques réponses sur le SdZ, j'ai débuté l'analyse du moteur. Pour le moment je n'intègrerai pas la partie réseau, inutile pour un Space Invaders.

Je vous met ci-dessous les différents diagrammes établis pour le moment, en espérant avoir quelques retours (critiques) dessus








Communication inter-modules (pattern Observer) :

[Invité]

Aucune réponse avec les informations fournies.
Ça fait si peur que ça ?


Edit :

Sinon je bute actuellement sur l'analyse de la partie Graphics du moteur.
Celle-ci gère les affichages, les effets graphiques , la création des entités... Mon architecture change pas mal, ce qui je pense est normal durant la phase d'analyse.
Je vous met le graphique ci-dessous.



Comment indiquer que les entités sont rendues dans la RenderWindow ?
Je ne vois pas quelle type de relation utiliser, et si il en faut bien une.

[bruno_pages]

bon, puisqu'il faut que quelqu'un si mette

(je n'ai pas été voir sur SdZ)

juste pour être sure : le 1er diagramme indique bien que Audio Game etc sont des sous packages d'Engine (je pose cette question à cause du second diagramme) ?

second diagramme, que signifie pour vous la notion d'héritage entre packages ?

le pattern observer/observable à des avantages mais il a aussi un gros défaut coté performance, on sait qu'il c'est passé quelque chose, mais pas quoi, et il faut ensuite aller à la pêche pour le savoir. En ajoutant un paramètre à update il est possible de dire 'quoi' et d'accélérer le mouvement.

il faudrait en savoir un peu plus sur les classes, leur but (même si leur nom donne même un idée de la chose), le fait qu'elle soit ou non des singletons, et quelques opérations pouraient être utiles

[Invité]

Déjà merci pour votre réponse Je commençais à désespérer
Alors pour reprendre vos questionnements point par point :

1. En fait je voulais montrer que l'Engine est composé de différents modules.Il établit une communication entre eux et fourni un interface publique.

2. Aucun, ce graphique est maintenant obsolète. Je l'ai laissé histoire qu'il y ait une trace, un suivi. Le premier diagramme correspond mieux à la vue globale du moteur.

3. Finalement je ne sais pas si je vais utiliser ce pattern dans un premier temps.
Tout d'abord car je ne l'ai jamais utilisé et qu'il est peut être trop complexe à mettre en oeuvre.
Peut-être un EventManager qui se chargera de gérer les événements (avec une classe Event de laquelle dérive les classes nécessaires) ?

4. Je n'ai pas mis d'opérations pour ne pas surcharger les diagrammes, et surtout car je n'en ai pas des masses pour le moment. De même je n'ai pas réfléchi aux classes qui seront Singleton (mais je sais déjà que TOUT les manager le seront).

Merci pour votre aide

[bruno_pages]

Edit :

Sinon je bute actuellement sur l'analyse de la partie Graphics du moteur.

je ne l'avais pas vu car vous l'avez fait pendant que je répondais, il vaut mieux ne pas modifiez pas une réponse longtemps après son ajout

faire une modélisation disant qu'il y a des fenêtres avec du texte et des images n'apporte pas à grand chose présentée comme cela, et la partie graphique sera très dépendante de la couche graphique que vous utiliserez, l'avez-vous choisi ?

[Invité]

Oui, pour la partie graphique j'utilise la SFML.
Par la suite, je verrais si je peux m'en défaire pour créer mes propres classes. Mais en attendant, autant se baser sur une source stable et simple d'utilisation qui plus est.

[Invité]

Voyant que je m'éparpillais un peu par manque d'organisation, je reprends donc mon analyse de zéro en commençant par le diagramme des Cas d'Utilisation.
Je le soumets à vos critiques.

Par la suite, je ne sais pas si celui devra être encore plus détaillé ou si je peux entamer le Diagramme de Packages.
Je n'ai pas encore complètement l'habitude de modéliser (de petit trucs par si par là en temps normal), d'où ces questionnements.

Merci d'avance





N.B : par Graphique, je fais référence aux Graphismes d'un jeu en général. Je viens jsute de m'apercevoir que le nom n'est pas tout à fait correct.

[Invité]

J'ai changer d'hébergeur pour les images, Imageshack semblant avoir quelques soucis.
Sinon personne n'a de critique à donner ? C'est parfait ?

[bruno_pages]

puisque vous chez les ennuis, pas de problème, je suis là

plus sérieusement :

• le diagramme est beaucoup trop compliqué, il faut donc le découpé en plusieurs, chaque diagramme d'UCs doit resté simple
• il y a une seule relation entre l'acteur et un UC, d'une certaine façon cela indique qu'il y a qu'un UC dans tout votre système, et que la seule chose qu'on peut faire c'est de creer le jeu, ce qui est évidemment faux. => Découpage
• attention, une dépendences include signifie que l'UC inclue est obligatoitrement exécuté, ce qui n'est pas le cas
• vous êtes sure que vos uses ne devraient pas être remplacé par des extends (attention au sens de la flèche des extends) ?

[Invité]

Tant que ce sont ces ennuis de ce type, ça me va

• Pas de soucis, j'avoue qu'il est assez chargé. Dois-je replacer l'acteur à chaque diagramme ou bien il ne peut y avoir que des UC, ne montrant seulement les relations entre eux ?
• Je ne comprend pas trop. Dans le cadre du moteur de jeu, le Développeur ne peut que l'utiliser non ? Quoi que... Ah ! En effet il peut utiliser les différentes parties du moteur. Enfin je sais pas, je suis assez perplexe...
• Dans ce cas, un <<uses>> serait donc plus adapté si je comprend bien.
• Disons que dans le cas de la Gestion Graphique, par exemple, le gestionnaire peut utiliser le gestionnaire de shaders. Ce n'est donc pas, je pense, tellement un <<extends>>, dans le sens où il... Quoi que finalement si, il étend bien les possibilités du gestionnaire graphique. Vous avez raison

Merci encore pour votre aide.
Comme quoi la modélisation n'est pas si simple à appréhender au début (ou alors je suis une quiche ).

[bruno_pages]

Dans le cadre du moteur de jeu, le Développeur ne peut que l'utiliser non ?

mais 'utiliser' ce n'est pas assez précis, car ce genre de chose s'applique aussi à une voiture par exemple, or on n'utilise pas une voiture comme votre soft.

par exemple dans le cas de la voiture il y a une foule d'UC différents :
démarrer (contact), arrêter (au sens éteindre), passer une vitesse, accélérer, freiner, allumer les feux, éteindre les feux, tourner etc

vos UCs indiquent ce que l'on pourra faire avec votre soft, chaque UC est une partie du 'quoi'

[Invité]

J'ai suivi ce que vous m'avez dit plus haut et listé les UC que je pense assez haut niveau, pour chaque partie du moteur.

Mais je reste assez perplexe sur l'analyse.
Le but est de créer une librairie C++, pas un programme au sens d'exécutable. Donc je ne sais pas si l'analyse doit être appréhendée de la même manière.