Architecture Editeur

[Lightning]

Je reprends ce que nous a envoyé Ulrich.



CEditorApplication : Classe principale (MAIN) qui hérite des propriétés de QT pour permettre de créer et de gérer l'interface (GUI)
CEditorTools : Pour la création des éléments de l'interface (bouton, liste déroulante, etc) propre à nos besoins, cette classe permettra de centraliser leur création.
CEditorRenderer : Affiche le rendu de la scène à l''aide d'Ogre3D
COgeEngine : est la classe qui permet d'initialiser le moteur Ogre3D
CEditorCamera : pour pouvoir pivoter, bouger, etc, cette classe gére le comportement de la caméra créée par Ogre3D
CGameObjectManager : L'ensemble des objets 3D seront gérer par cette classe qui les stockera dans un dictionnaire (<map>).
Ce "manager" manipule, la création, la supression et les changements d'état des objets.
CObject : C'est la classe interface qui initialise la position d'un objet dans la scène d'Ogre (postion, Orientation, taille, etc)
CObjectStatic : Ici, on gérera le comportement des éléments non animé en implémentant uniquement la collision de l'objet
CObjectAnimated : L'animation de l'objet
CObjectStatistics : Chaque objet aura des caractéristiques (vie, mana, force, dextérité, etc) qui seront gérés dans cette classe.
IAxisManipulator : Interface pour utiliser l'affichage des outils de rotation, de déplacement, etc


Bien sur l'architecture du jeu reprendra la majeure partie du code qui va etre fait pour l'éditeur.

Les différences seront au niveau de l'interface Qt peut etre absente au profit d'une interface ingame avec CEGUI, une gestion différentes des controles et l'intégration du moteur du jeu.

[Lightning]

Bon alors je lance la chose avec mes remarques.

D'abord sur le plan général, je conseillerais de suivre le pattern MVC (plus d'infos ici : http://java.sun.com/blueprints/patterns/...ailed.html )
Ce design pattern est trés bien adapté à un rendu de jeu parce qu'il est trés interessant que le controlleur agisse directement sur les données et que la vue est une vision en 'lecture seule' des données. La meilleur raison est qu'un rendu 3D est juste un thread qui va aller récupérer X fois par seconde (FPS ) les données et les afficher.
Donc tant que personne n'a l'idée qui révolutionne ce pattern il faut mieux le suivre de facon trés restrictive.
C'est d'ailleurs ce qu'Ulrich fait à qques détails près que je vais essayer de faire remonter.

Derniere remarque générale : Pensez simple mais bien fait. Ne pas essayer de gérer tous les cas mais faire du code qui pourra facilement se complexifier.

Je vais commencer par les classes et la partie 'Data' :
CGameObjectManager :
on peut pas nommer ca CObjectsManager tout simplement ?
Sinon remarque plus importante, attention au <map>, il faut qu'on puisse parcourir de facon la plus rapide possible le tableau des objets à afficher ! Si la map STL offre la possibilité de se parcourir comme un simple tableau pas de probleme. D'un autre coté, un map sera surement nécessaire pour aller traiter l'objet par exemple selectionné dans la vue.
Peut etre doit on avoir une map et un tableau plus classique pointant vers les memes objets.

Pour la hierarchie des objets, ca m'a l'air d'etre un bon début. Par contre ne descend pas trop dans les détails pour l'instant .. genre un sous objet arbre, batiment, avatar, monster. Pour l'instant j'en resterais à Animé / statique avec comme seul réelle différence une fonction 'animate' avec une implémentation vide pour les objets statiques.
D'ailleurs il serait ptet interessant de remonter CObjectAnimated au niveau de CObjectStatic ... ou de fusionner CObject et CObjectStatic (la question à se poser est : est-ce que l'heritage sert vraiment ?).

La partie 'Vue' :
CEditorCamera .. je la généraliserais à CCamera .. En 3D une caméra reste le meme type d'objet que ce soit pour l'éditeur et le jeu c'est juste le 'point de vue' qui change

COgreEngine tu fais une 'composition' ? c'est ptet juste un détail mais clairement pour moi c'est une relation 1 - 1.

CEditorRender : Ok. On peut le différencier d'un CGameRender qui aura par exemple des options graphiques différentes.

CEditorApplication : Attention pour moi la on arrive dans la classe 'main' de l'editeur. Je rajouterais une classe CEditorGUI qui contiendrai la gestion de l'interface Qt.

J'en viens au plus important : la liaison CEditorRender et CEditorGUI. Vu que j'ai déjà bosser sur ce genre de liaison je conseille de rendre indépendant le Render de la GUI. La GUI agira sur les parametres de Rendu qui ira chercher les infos dans la partie Data. La GUI agira directement sur les données sans passer le Render ! En gros le Render est juste une vue de Rendu de la GUI.

Derniere remarque : pour CEditorTools je vois pas trop. Pour moi clairement on aura un ensemble de classes lié à CEditorGUI qui permettront de mieux architecturer l'interface Qt;

Enfin on finit par la partie Controller qui est toujours plus floue :
autant pareil il faut bien séparer la partie controle des données .. autant la frontiere de code entre Vue et Controler est plus délicate. Tes classes IAxisManipulator en sont le meilleur exemple ... d'un coté ca ressemble à un controlleur autant ta description en fond plus un simple object graphique.
Je pense que l'idée est d'avoir une classe 'Controlleur' avec un objet graphique de type 'Vue' associé qui permettra d'avoir un retour visuel sur les controlles.

Voila si j'ai le temps je ferais un schéma

[Nktug]

Alors question longue, réponse longue

Lightning a écrit :D'abord sur le plan général, je conseillerais de suivre le pattern MVC

C'est l'objectif !!

Lightning a écrit :Derniere remarque générale : Pensez simple mais bien fait. Ne pas essayer de gérer tous les cas mais faire du code qui pourra facilement se complexifier.

C'est le cas vu qu'il manque beaucoup de classes et que je ne suis pas rentré dans les détails.

Lightning a écrit :CGameObjectManager :
on peut pas nommer ca CObjectsManager tout simplement ?

Question de libellé donc libre de choisir

Lightning a écrit :Peut etre doit on avoir une map et un tableau plus classique pointant vers les memes objets.

MAp oui mais pas de tableau car pas de methode d'accès rapide

Lightning a écrit :Pour la hierarchie des objets, ca m'a l'air d'etre un bon début. Par contre ne descend pas trop dans les détails pour l'instant .. genre un sous objet arbre, batiment, avatar, monster. Pour l'instant j'en resterais à Animé / statique avec comme seul réelle différence une fonction 'animate' avec une implémentation vide pour les objets statiques.

On reste simple mais il va bien falloir descendre dans les détails.
L'idée tend comme même à aller dans ce sens.

Lightning a écrit :D'ailleurs il serait ptet interessant de remonter CObjectAnimated au niveau de CObjectStatic ... ou de fusionner CObject et CObjectStatic (la question à se poser est : est-ce que l'heritage sert vraiment ?).

Je l'ai expressement mis à ce niveau car je souhaite gérer la collision sur l'objet static. C'est un choix perso mais si je l'animation n'hérite pas de cette classe, des propriétés et methodes seront gérés en double.

Lightning a écrit :La partie 'Vue' :
CEditorCamera .. je la généraliserais à CCamera .. En 3D une caméra reste le meme type d'objet que ce soit pour l'éditeur et le jeu c'est juste le 'point de vue' qui change

Je peux le gérer dans le RENDER mais pour une meilleur lecture, j'ai voulu le séparer.

Lightning a écrit :COgreEngine tu fais une 'composition' ? c'est ptet juste un détail mais clairement pour moi c'est une relation 1 - 1.

Là je t'avoue que je ne maîtrise plus trop l'UML (faut que je revois mon cours)

Lightning a écrit :CEditorRender : Ok. On peut le différencier d'un CGameRender qui aura par exemple des options graphiques différentes.

Question de libellé, j'ai mis "Editor" et non "Game" car c'est le code de l'éditeur.

Lightning a écrit :CEditorApplication : Attention pour moi la on arrive dans la classe 'main' de l'editeur. Je rajouterais une classe CEditorGUI qui contiendrai la gestion de l'interface Qt.

Non ! Ce n'est pas la classe "MAIN". C'est la classe principale de Qt pour gérer l'interface = je dirai plus que c'est le centre du modèle.

Lightning a écrit :La GUI agira sur les parametres de Rendu qui ira chercher les infos dans la partie Data.

Pour la partie DATA, on y est pas encore car faut trouver la classe qui ira chercher les infos dans le XML pour charger et sauvegarder.

Lightning a écrit :Derniere remarque : pour CEditorTools je vois pas trop. Pour moi clairement on aura un ensemble de classes lié à CEditorGUI qui permettront de mieux architecturer l'interface Qt;

CEditorTools = CEditorGUI si tu préfères.
Mauvais choix de libellé

Lightning a écrit :Enfin on finit par la partie Controller qui est toujours plus floue :

Ici on n'implémentera pas la partie controleur car c'est Qt qui le gère automatiquement avec la classe QtWidget

Lightning a écrit :Voila si j'ai le temps je ferais un schéma

J'attend cela sinon moi j'avance pour ne pas prendre de retard.

[Lightning]

Schema rapide :

[Nktug]

Ok ! Super le nouveau schéma. J'aurais effectivement le faire de manière générale façon module pour faciliter la compréhension.

Faut donc qu'on essaie de sortir un diagramme fonctionnel détaillé et un autre plus orienté classe Objet.

On a trouvé ton talent Light ! Je crois que va plus bosser là dessus et nous faire des beaux schémas avec des explications derrière.

= > A mettre dans le wiki dev merci

[Lightning]

La partie object :



Je reprends l'exemple du mail dés que possible

[motarion]

Tu peux attacher l'image au forum tu sais, se sera mieux et plus rapide pour afficher le forum. Pixfrag lag pas mal :/