Discussion :

[Norris]

Bonjour !
Sous ce titre un peu vague, se cache une question de conception. Je travaille sous VB.Net 2008 et j'essaye de créer mon moteur de jeu 3D sous OpenGL (sans prétentions hein, juste un prétexte à l'apprentissage). Ca m'a amené à essayer de développer un éditeur visuel afin de construire des jeux/maps sans avoir à les coder et surtout sans avoir à recompiler le moteur pour chaque jeu (un peu comme UDK ou Unity). Et je me pose beaucoup de questions quand à la bonne architecture à adopter.

Dans mon idée, le moteur de jeu est l'application finale (appli console qui lance une fenêtre OpenGL), et elle serait compilée une fois pour toutes. Chaque jeu serait fourni au moteur sous forme de DLL. Cette dernière contiendrait une méthode à implémenter obligatoirement afin de l'initialiser dans le moteur (chargement des niveaux / meshes / scripts / ressources ....).
Chaque jeu serait en quelque sorte comme un plugin "consommable" par le moteur.

Pourquoi utiliser une dll pour stocker mes maps et ressources et pas simplement de simples fichiers XML ou la sérialisation binaire me direz-vous ?
Jusqu'à maintenant, je procédais ainsi en stockant chaque mesh dans un fichier XML. Chaque map/level était aussi dans un fichier XML.
Ce système me permet de décrire simplement mes objets 3D et la scène les contenant.
Pourtant j'imagine que ce système aura ses limites. En effet j'aurais surement besoin d'attacher des scripts/comportements à mes objets (chaque jeu ayant des comportements différents).Le format XML ou binaire ne me parait pas trop adapté, étant surtout "descriptif".

Avec une DLL, j'imagine qu'il serait beaucoup plus simple de décrire une scène ou définir des comportements scriptés sous forme de code (VB/C#) grâce à une API perso fournie par le moteur, plutôt qu'en XML.

Autre avantage que j'y vois ... avec une DLL, je pourrais y stocker/compiler toutes mes ressources (meshes / textures / fichiers audio ...). Non seulement ça permet de ne pas avoir 50000 fichiers pour créer un jeu et on évite d'éventuels problèmes d'architecture de dossiers, mais j'imagine aussi qu'il est bien plus rapide de charger une DLL que de parser 50000 fichiers XML !

Désolé pour la longueur de ce post, mais étant simple amateur, j'ai un peu de mal à imaginer la structure d'un tel projet et surtout, quelle technologies/principes utiliser avec .Net. J'aimerais beaucoup avoir votre avis sur mon idée, et aussi savoir comment vous procéderiez. Mon idée est-elle bonne ou pas du tout ?

[Skalp]

Ça va dépendre pas mal du nombre de fichiers "externes" à gérer.
Tu nous dis 50000, je crois que c'est un peu exagéré, non ?

Et ne serait-ce que pour une question pratique : il faudrait trouver une solution automatique pour incorporer tous ces fichiers externes en tant que ressource.

[Norris]

Bonjour Skalp et merci de t'attarder sur mon problème.
Evidemment, je n'aurais pas 50000 fichiers à charger, mais il se peut qu'il y en ai quelques uns tout de même (meshes, scripts, textures ...).

Pour ce qui est d'inclure automatiquement ces ressources dans ma DLL, ce serait le boulot de l'application "éditeur".

Si j'ai pensé à ce système, ce n'était pas à l'origine pour améliorer la praticité, ni compiler mes ressources, mais bien pour pouvoir créer créer du code qui me permettra de reconstruire ma scène et définir des comportements pour mes objets.

Je me convainc de plus en plus que l'idée à du potentiel, et je me lance dans l'étude de CodeDom et des applis modulables par plugins.

[Skalp]

Je me convainc de plus en plus que l'idée à du potentiel, et je me lance dans l'étude de CodeDom et des applis modulables par plugins.

Attention toutefois au temps de chargement de ces DLL.
Plus il y aura de choses embarquées dans la DLL, plus elle mettra du temps à se charger initialement... Mais peut-être est-ce un mal pour un bien : elles seront probablement accessibles plus rapidement pendant l'exécution.
A confirmer...