Éditeur

[ghost]

Je me tourne vers vous afin de déterminer les compétences de chacun afin de réaliser l'éditeur.

On part sur quelle techno ?

• Si c'est du C#, va falloir partir sur du WPF car c'est un peu chaud en WinForms ou GTK#. Il faut continuer à creuser pour savoir sur quoi on part. Ou alors, on peut faire un level editor intégré au jeu (plus pratique pour les enfants) ? Dans ce cas, il nous faut un bon framework d'UI. Je n'en connais pas de gratuit. XNA nous permet également d'utiliser les contrôles WinForm/WPF.
• Je ne connais pas vraiment d'autre technologie, mais il en faudrait une qui soit (si possible) cross platform, avec un bon framework d'UI et qui permettrait à chacun de créer ses niveaux, sans trop de compétence en dev.
• Un bon level editor existant personnalisable ? Tiled ?

Après, on a besoin à priori d'une grille 2D redimensionnable dans laquelle on place des tiles correspondant aux objets 3D. Dans un prototype de jeu, j'avais des fichers Excel que je parsais avec un script Python afin de le convertir en fichier de niveau. C'est pas terrible, mais ça peut être une solution en attendant (je suis pas trop pour mais c'est une idée qui me passe par la tête).

---

Edit 1 : Bat' a commencé un éditeur en Node.JS/Electron ici.

[A-312]

Je considère l'éditeur comme une fonctionnalité secondaire, on risque de se perdre si on le fait avant d'avoir un affichage du terrain quasi-définitif.

Pour l'instant je ne pense pas que ça soit indispensable ou bloquant dans la continuité du développement.

Je ne souhaite pas dépenser trop de temps sur un éditeur, ni réinventer la roue.

[ghost]

Je ne suis pas d'accord, créer un éditeur nous permettrait de bien cerner nos besoins quant au format du fichier de niveau par exemple.

[A-312]

Je ne suis pas trop sûr de connaître le résultat qu'on souhaite atteindre. C'est pour ça que je vote en touche.

Il serait intéressant de faire cahier des charges sur le résultat à atteindre, quitte à avoir quelques différences. A part ça : https://lite6.framapad.org/p/algoquid et ce qu'on a dit en #22, je ne suis pas sûr de savoir ce que l'éditeur va faire.

Si je dois résumer : Pour le terrain on part sur un plane, où on définit plusieurs cartes de jeu à taille variable _x_ * _y_, avec sur ce quadrillage orthogonal des éléments :

• Des obstacles qui sont de simple rocher en coordonnée [x, y] de taille [x, y].
• Des éléments à ramasser/collecter de coordonnée [x, y].

C'est bien ça ?

[ghost]

Voilà.

[A-312]

On peut très bien utiliser l'affichage de niveau actuel, et rajouter un petit menu.

Côté code, il suffit de rajouter quelques events, et fonction de placement d'objet.

[elegaanz]

Comme je l'ai dit sur le chat, je connais pas mal WPF donc je veux bien faire l'éditeur avec du ça vous convient. Après je peux aussi partir sur du Électron, ça sera peut-être plus simple et ça sera multiplateforme.

[A-312]

Si ça ne pose de problème d'intégration ou de complication pour la #26.

Et que vous vous sentez capable de mener à bien un éditeur externe fonctionnel, je n'ai aucune objection à ta propostion Bat41.

[elegaanz]

Il faudra juste qu'on ait les modèles 3D présents dans le jeu, et après avec électron et du WebGL ça doit le faire sans soucis. Et je ne vois pas bien pourquoi ça gênerait pour la #26 ...

[A-312]

Ce que je voulais dire c'est ne pas devoir configurer spécialement le fichier pour pouvoir le rendre compatible à l'éditeur.

[elegaanz]

Alors pas de problème ! :smile: Je commence dès que j'ai un peu de temps. Je vais partir sur du Electron comme je l'ai dit. Donc si vous vous y connaissez un peu en JS et que vous voulez aider, pas de problèmes.

On ferme du coup ?

[A-312]

On utilise un autre dépôt ou celui la ?

https://github.com/Silly-Machines/Algoquid.Editor

[elegaanz]

Celui qui existe déjà va très bien. Je pense que je vais pouvoir commencer un peu ce soir, mais je sais pas si je vais push quoi que ce soit ...

[ghost]

@Bat41, est-il vraiment utile de faire un éditeur avec rendering des éléments du jeu en 3D ? Autant faire un bête tile-based editor avec des sprites 2D. C'est plus simple.

[elegaanz]

Ben ça oblige à convertir les objets 3D en sprites, et il faut en faire 4 pour chaque modèle, puisqu'on peut changer la rotation des objets. Franchement, je trouve que c'est plus simple comme ça.

[ghost]

Qui a parlé de conversion ? Non, un sprite déjà existant (domaine public) illustrant ce que l'on veut. Après fais comme tu veux, j'y connais rien en JS, mais ça risque d'être de la perte de temps et d'être coûteux en performances.

[elegaanz]

Ben ça risque d'être moche, alors que là on a vraiment une vision de comment ça sera dans le jeu. Et franchement, les modèles Blender se convertissent en deux clics vers du THREE.js, donc ça ne pose vraiment aucun problème.