Discussion :

[Romaiiin]

Bonjour,

Avant de me lancer dans mon projet tête baissée je souhaite m'investir dans le développement d'éditeurs qui me permettront d'aller plus vite dans mes futurs développements, et m'apprendront beaucoup de choses par la même occasion.

J'en ai trois en tête :

• Editeur de Map 2D ISO ( + d'autre technos par la suite) avec gestion des colissions, choix du type de la caméra et peut être plus, je n'ai pas encore une vision global de ce qui doit être fait.
• Editeur de sprite, sur lequel on colorie un pixel pour le point chaud et pour le point d'action, sélection plus précise des zones de collisions. J'aurais aussi aimé faire quelque chose pour gérer le positionnement, la profondeur ... d'objets qui ont une action avec ce sprite (vêtement, monture), (ex: pour le sprite 1 avec le vêtement 1 celui ci doit se positionner ici, faire cette taille, et à cette profondeur). Est-ce une méthode viable, ça fait quand même un gros tableau pour chaque sprite on stock pour chaque vêtement ses coordonnée etc...
• Editeur dans le lequel on charge des images, textes, on sélectionne un ou plusieurs effets voulu (déjà prog en back) on peu donc modifier ces effet à l'aide de scrools bars, bouttons ... Déterminer l'ordre de déclanchement des effets (en même temps, l'un aprés l'autre).

J'ai donc plusieurs questions :

• La première MonoGame est il une techno adaptée pour ce type de projet ou devrais-je me tourner plus simplement sur un WindowsForm ?
• Que retourne un éditeur de ce type une fois le travail effectué, qu'est ce qu'on enregistre ? Un JSON qui doit être dé-sérialisé dans le code au moment voulu ? C'est à dire que au lieu d'initialiser mon objet à la main, je le désérialise, j'éxécute sa méthode LoadContent pour charger ses données puis je balance ses methodes Draw(), Update() dans la boucle du jeu ?
• Par exemple pour le sprite la méthode d'approche est celle - ci, on charge le sprite, en back on enregistre à la propriété path le chemin vers cette image, ensuite on clique simplement sur l'image pour lui assigner un PC et un PA qui seront enregistrés dans les propriétés respectives de l'objet. Du coup à chaque utilisation du sprite je devrais désérialiser le json du sprite généré par l'éditeur ? Idem pour les deux autres éditeurs même principe. Mais cela signifie que mon jeu et l'éditeur doivent posséder exactement les même classes (un gros copier coller en résumé), est-ce vraiment comme cela que ça fonctionne ?

C'est encore assez flous dans ma tête je manque encore de connaissance, c'est pourquoi je suis ici. Tout n'est que spéculation, j'aurais besoin de votre aide pour confirmer, valider mes idées, afin de ne pas me lancer dans un projet perdu d'avance.
Je vous remercie d'avance du temps que vous m'accorderez, bonne journée

[LittleWhite]

Bonjour,

En effet, il y a du flou, mais ce n'est pas une chose honteuse. Ce que je conseillerai, c'est de commencer à faire un jeu, ou au minimum, un projet minimaliste mettant en oeuvre les techniques qui seront dans le jeu (par exemple une animation, affichage d'une carte 2D...). Ainsi, vous verrez ce que l'éditeur devra faire et les besoins réels que vous aurez.

Pour le chargement des ressources : la désérialisation doit être effectuée qu'une seule fois, pendant le chargement du jeu (ou du niveau). Le résultat est conservé en mémoire.

MonoGame est assez bien adapté, notamment car on peut utiliser du .NET pour faire l'interface de l'éditeur.
On peut enregistrer un JSON, ou du binaire ou n'importe quoi d'autre. Vous aurez des exemples avec l'outil Tiled. Il existe déjà des formats "classiques" que l'on retrouve souvent.

Pour ne pas avoir une copie du code, il suffit de faire une bibliothèque exposant les données et les fonctions de sérialisation et désérialisation. Ainsi, on charge cette même bibliothèque dans le jeu, comme dans l'éditeur. Il ne faut "jamais" faire de copie de code .

[Romaiiin]

Bonjour, tout d’abord merci de ta réponse

Pour le chargement des ressources : la désérialisation doit être effectuée qu'une seule fois, pendant le chargement du jeu (ou du niveau). Le résultat est conservé en mémoire.

Oui c'est ce que je voulais dire je me suis mal exprimé.

MonoGame est assez bien adapté, notamment car on peut utiliser du .NET pour faire l'interface de l'éditeur.
On peut enregistrer un JSON, ou du binaire ou n'importe quoi d'autre. Vous aurez des exemples avec l'outil Tiled. Il existe déjà des formats "classiques" que l'on retrouve souvent.

Alors oui je souhaitais justement utiliser la bibliothéque Json.NET qui est plutôt puissante.
Cependant j'ai un problème, qui m'a arrêté dans mon développement. J'ai finis de développement l'affichage de la grille qui peut avoir une taille infini (fin très grande). Qui pour chaque cases affichées à l'écran, affiche les texture de celles ci pour chaque layer. J'ai aussi implémenté un système de scroll vertical ainsi que horizontal. Un systeme de zoom en utilisant le scale. Bref ça marche bien cependant .. ça RAME

En faite à chaque déplacement de la grille ou de zoom/de-zoom il chope la position de la première cellule en haut à gauche à affiché à l'aide des valeurs des scrolls puis avec la taille de la fenêtre et celle des cellules (qui varie avec le scale) détermine le nombre de cellules à afficher. Je pense mon code correct cependant rien ne va. Au bout de 5 mins d'utilisation (même moins) en bougeant les scrolls en faisant des zooms, de-zoom l'application RAME clairement et on voit une consommation de celle-ci de plus de 1GO

Je ne comprend pas ce qui se passe peut être que je fais trop d'instanciations. Mais je trouve le résultat trop énorme il doit y avoir autre chose. Pourtant la méthode à suivre c'est bien celle-ci ? Je précise que je suis sur un Windows form qui utilise un composant GraphicsDevice. Du coup je pense recommencer sur une autre techno qui je pense est plus au point : Qt.

Mais ça m’embête de ne pas comprendre ce qui se passe. Aurais tu une idée ?

Merci.

[LittleWhite]

Bonjour,

Je pense que ce problème aura réponse dans le forum .NET ou Windows Forms de Developpez.com. De mon expérience, le scale cause la création d'une version agrandie (deux fois plus de pixels) de l'objet et la garde en mémoire. Si on scale trop ... hum hum, ça prend énormément de mémoire car l'objet "grossit". Enfin, ce cas là, je l'ai eu dans une autre technologie et sur une image mais peut être ça vous donne une piste.
Finalement, en théorie le rendu de votre éditeur devrait être effectuée par le moteur de rendu de votre jeu (donc, en théorie, par MonoGame). Ainsi, pas de duplication du code (si on utilise une bibliothèque).