Développement de Web Game Editor (Précédemment nommer HeroonEngine)

Ok merci.

Donc le serveur fonctionne comme celui de RC. Zafari est en train d'essayer d'inverser le système, de façon à ce que ce soit le serveur qui pilote tout.

Le serveur peut anticiper/prévoir des déplacements au cas de lag, mais il ne peut pas inventer le déplacement des personnages. C'est obligatoire que le client envoie les données vers le serveurs et les renvois à tout les clients connecter, c’est comme ca que ca fonctionne quelque soit le serveur.

Le serveur que j'ai fait pilote le déplacement des joueurs en renvoyant juste des données en Json, les données sont envoyez par un client. Quand le client reçois les données, il met à jour les positions des perso, exécute les animations et autres. Si c'est le serveur qui met a jour les données de position et animation plutôt que le client, cela alourdi le serveur de beaucoup je trouve. Pour moi un serveur est plus rapide si il n'a que de petite donnée a renvoyez comme {x:12, y:2, z:35}, plutôt que de lourde tache à exécuter comme actor.position = Vecor3(x, y, z);

Je ne suis pas sûr que cela soit une si bonne idée de vouloir inverser le système pour que le serveur pilote tout, car il exécute des taches au lieux de renvoyez de petite données, ce qui est pas pareil. Pour ma part je préfère que cela soit le client qui exécute des taches et laisser le serveur recevoir et renvoyez de petites donnée json. éventuellement le serveur peut exécuter de légère tache avant de renvoyez, mais je n'en vois pas l’intérêt, le client est plus puissant pour exécuter des taches que le serveur qui doit l’exécuter pour plusieurs client.

Je pense que la méthode RCS, RCP est bonne et est la plus rependu aussi. Il manquais peut être le faites que le serveur de RC puisse anticiper des déplacements au cas de lag, mais c’est pas simple a réaliser.

Enfin ce n’est que mon point de vue, peut être que certaine chose m'échappe encore.

Ne t'inquiète pas, je ne suis pas plus avancé que toi sur le sujet ^^
Je n'ai pas d'avis tranché sur la question.

Je posais juste la question, histoire de connaitre le fonctionnement de ton serveur.

Pas de soucie. j'ai penser que tu verrais cela mieux que le serveur pilote le déplacement, alors, moi je m'interrogeais sur le bienfait de cette solution.

Mais voila, mon serveur fonctionne comme ca, comme beaucoup d'ailleur. sauf que j'ai pousser le truc plus loing avec NodeJS, car il faut savoir que Javascript est simple-thread , mais avec mon système cluster, j'ai du multi-thread. Sachant que Javascript est tres rapide en simple-thread, alors avec du multi...

Bref, je voulais juste dire que je ne suis pas sûr que zafari est choisis la bonne option pour faire le serveur de cette façons, mais ca dépend aussi de la programmation derrière, donc à voir.

j'ai déjà l'habitude avec RC qui fonctionne comme ça en simple thread et comme ça tourne pas mal du tout, avec peu de personnes et hébergé localement, j'ai confiance en ton système.
Pour Zafari, comme il recode tout le serveur en C++ , faudra voir.

Hello,

Je pense que je vais repousser la sortie que je pensais pour février ou mars. J'ai eu des idées pour améliorer l'onglet zone du GE en ajoutant des fonctionnalité utiles.

Je prévois d'ajouter:

• [fait]- 3 mode de camera pour voler (mode actuel), marcher sur le terrain en vue FPS tout en éditant, et pouvoir être en orbite autour d'un objet sélectionner.
  
• [fait]- Pouvoir sélectionner plusieurs objets et les déplacer tous ensemble ou encore de créer un groupe ou les fusionner.
  
• [fait]- Pouvoir copier un objet sélectionner en le clonant ou en créant une instance de l'objet.
  
• - Pouvoir créer des actions sur des objets par fichier d'add-on, qui permettrons de créer des interactions comme des interrupteur, des leviers, ou exécuter du code scripter ou autres...
  
• [fait]- Une petite boussole sur la fenêtre d’édition de scene (utiles pour ce repérer pour placer ses objets)
  
• [fait]- Des paramètres d'ombre supplémentaire comme les différent filtre et la resolution de la shadow map ainsi que de pourvoir régler la distance de vue de ombres et désactiver celle éloigner pour optimiser la scene.
  
• [fait]- Ajouter sur les propriété d'objet si une ombre est static ou dynamique (les objets interieur de maisons peuvent être statique et cela optimiseras la scene. les ombre extérieur pourrons être dynamique)
  
• [fait]- Pouvoir renommer le nom des objets.
  
• [fait]- Ajout de post-process près fait pour chaque zone (FXAA, black and white, HDR, Blur, SSAO, Cell Shading)
  
  

Et c’est tout pour les quelque idées que j'ai eu. Je pense que cela est nécessaire et tres utiles et amélioreras grandement l’éditeur pour créer des scènes encore plus cool. Mais ca vas me prendre un peut de temps pour ajouter tout ca. Donc je pense que je sortirais HeroonEngine pour avril ou mai, voir plus si je suis pas satisfait. Je veux pas me mettre de pression pour sortir une première version, je veux que cela soit impeccable, même si je sais qu'il y auras forcement des bugs, je voudrais qu'il y en ai le moins possible et que toutes les fonctionnalités soit présente (pas de version alpha). Donc plutôt que de donner une date ou un mois de sortie, je préfère dire dans l'année 2017 (printemps ou été).

Tout compte fait, pour le système d'action, je ne le ferais pas par plugin. J’intégrerais cela par des fonctions de script directement. Il suffiras de créer un script rattacher a un objet et de coder une action. cela permettras plus de possibilité aux utilisateurs.

C'est quoi les actions concrètement ?

Exemple 1 : imaginer un interrupteur et une lumière dans une maisons, vous voulez allumer la lumière. Mais le joueur doit savoir qu'une action est possible, chaque actions créer permette de transformer le curseur de souris en pointer (comme les lien html) quand on pointe sur l'objet.
l'action permet de créer sur l'interrupteur, pour l'exemple, un type d'interaction (par click par exemple ou par hover, double click et autres) pour exécuter un type d'action comme changer la valeur d'un autre objet (la lumière pour mon exemple) sur la propriété intensité.

Les actions permettes aussi de démarrer ou stopper des animations, des sons et plein d'autre chose.

Exemple 2:
Imaginer un levier qui lève un pont. On créer une action sur le levier avec un type d'action qui lance une animation sur le pont. Au click sur le levier, l'action joue une petite animation de bascule, puis exécute l'animation du pont qui ce lève et on peut enchainer en jouant un son quand le pont et totalement lever et enchainer en déclenchant des particules ou ce que vous voulez seulement en cliquant une fois sur le levier.

En faite avec les actions, vous pouvez les combiner, ajouter des conditions, créer des enchaînements d’exécution comme faire ceci, puis cela et enfin ca. C’est vraiment quelque chose de tres puissant permettant des interactions illimité dans vos jeu. Je simplifierais cotée script pour que vous puissiez en réaliser.

J'en réaliserais quelques une dans la démo que je ferais et je ferais une bonne documentation sur le sujet.

J'ai terminer le système d'action dans les scripts. Voila ce que cela donne pour les utilisateurs coté programmation :

code a écrit:var action = ACTION.CreateAction(mesh); // Crée une action sur un objet
action.AddActionSetValue("OnPickTrigger", light, intensity, 0); // ajoute une action qui édite une propriété
action.RegisterActions(); // On enregistre l'action

Dans cette exemple, un objet modifie la propriété intensité a 0 sur une lumiere. Ça peut pas être plus simple. Un autre exemple avec plusieurs action qui s’enchaîne:

code a écrit:var action = ACTION.CreateAction(mesh); //Crée une action sur un objet
action.AddActionSetValue("OnPickTrigger", light, intensity, 0); // action 1: ajoute une action qui édite une propriété
action.AddActionPlayAnimation("OnPickTrigger", pont, 0, 30, false); // action 2: Ajoute une autre action qui joue lance animation
action.RegisterActions(); // enregistre les deux actions

ici, je reprend le premier code qui éteint la lumière et j'ai ajouter une action d'animation qui démarre a la frame 0 jusqu’à 30 et qui n’est pas en boucle. On peut ajouter jusqu’à 10 actions à enchainer (je pense que cette limite est suffisante). J'aurais pu aussi utiliser: action.AddActionCombine() qui permet de combiner plusieur actions.
Maintenant si vous voulez ajouter une condition sur ce second exemple de code. voila quelque chose de plus complet :

code a écrit:var action = ACTION.CreateAction(mesh); //Crée une action sur un objet
var condition = SCRIPT.CreateCondition(action,  light, intensity, 1.0, "IsEqual"); // Créer une condition
action.AddActionSetValue("OnPickTrigger", light, intensity, 0, condition); // On ajoute la condition créer
action.AddActionPlayAnimation("OnPickTrigger", pont, 0, 30, false); // action 2: Ajoute une autre action qui joue lance animation
action.RegisterActions(); // On enregistre les deux actions avec la condition

Ici j'ai ajouter une condition qui vérifie que l'intensité de la lumiere est égale à 1.0. Ensuite j'ajoute cette condition dans le AddAction. Cela permet d’exécuter l'action (intensity à 0) que si la condition est remplie (intensity == 1.0)

Voila on a fait le tour. Alors, compliquer ? je pense que c’est tres simple, rapide à créer et vraiment cool pour les jeux. J'aimerais votre avis pour savoir si c’est compréhensible pour vous, même si je vais pas pouvoir faire plus simple.

Liste des types actions :

code a écrit:CreateAction() // Permet d'attacher une action sur un objet
CreateCondition() // Permet de créer une condition avec comme operator: IsEqual, IsDifferent, IsGreater, IsLesser
AddActionSwitchBoolean() // Une valeur d'une propriété passe de true à false et de false a true
AddActionSetValue() // Edite une propriété
AddActionIncrementValue() // Incrémente une valeur
AddActionPlayAnimation() // Joue une animation
AddActionStopAnimation() // Stop une animation
AddActionCombine() // Combine des actions
AddActionExecuteCode() // Exécute du code
AddActionSetParent() // Rend un objet parent d'un autre
AddActionInterpolateValue() // Diminution progressive d'une propreté
RegisterActions() // Permet d'enregistrer 1 a 10 actions qui s'enchaîneront

Liste des types de trigger:

code a écrit:OnPickTrigger // Click simple
OnPickDownTrigger // Click enfoncer
OnPickUpTrigger // Click relâcher
OnPickOutTrigger // Click puis sortir de l'objet
OnLeftPickTrigger // Click gauche
OnRightPickTrigger // Click droit
OnCenterPickTrigger // Click centre
OnLongPressTrigger // Long click enfoncer
OnPointerOverTrigger // Souris qui pointe sur l'objet
OnPointerOutTrigger // Souris qui sort de l'objet pointer
OnIntersectionEnterTrigger // Objet qui entre en contacte avec un autre objet
OnIntersectionExitTrigger // Objet qui entre sort du contacte avec un autre objet
OnKeyDownTrigger // Evénement du clavier quand on appuis sur une touche
OnKeyUpTrigger // Evènement du clavier quand on relâche une touche

Personne pour me dire si c’est compréhensible le code ci dessus ? Ça m'aiderais a savoir si je doit continuer sur le même chemin ou si je doit simplifier encore.

Sinon, je voulais vous montrer cette démo. Regarder le compteur de personnage animer qui augmenter et regarder les FPS qui reste toujours au alentour des 58, 60 FPS. avec une 100 ene de personnage en mouvement, je suis a 60FPS, sachant que le personnage est pas optimiser en poly et nombres d'os. Je vais utiliser cette optimisation sur le jeu en plus des autres.

bref, regardez cette démo, ca rame pas d'un poile. Imaginer le nombre de perso sur un zone...

http://www.babylonjs.com/Demos/SIMD/

Pour le moment, ça m'a l'air compréhensible, il me faudra un peu de temps pour m'habituer au langage mais c'est jouable à mon niveau ^^

La démo est pas mal, c'est propre, le client gère bien.
Maintenant faudra voir côté serveur combien de bande passante bouffera un perso et combien il pourra en gérer en même temps sur une même map (point noir de RC)

Merci, Cool si ca reste compréhensible. Oui, tu t’habitueras vite a ce langage qui est pas compliquer. ca change du basic, mais ca reste simple et ce langage est vraiment agréable. Et moi je simplifie autant que je peut pour les scripts.

Ça devrais le faire au niveau du serveur et perso. je ferais un crash test pour voir la limite max et je vous montrerais ce que ca donne. Je vais optimiser au maximum cotée serveur pour qu'il ne souffre pas et sur les persos, mais je suis confiant, le moteur vraiment parfait sur tout les points.

Tu as un outil pour mesurer la bande passante au cas où?

Sur RC, je sais qu'un fichier actor ne doit pas dépasser les 200ko et là tout fonctionne impec'. (Moi, j'essaye de tenir mes persos à moins de 100ko).
Mais ils recommandent de ne pas avoir plus de 50 actors (joueurs et NPC confondus) par zone.
Je sais aussi par expérience, que si la map est trop grande (et donc le risque d’accueillir trop de joueurs en même temps en plus), le serveur part en vrille et affiche parfois n'importe quoi aux autres joueurs. ^^


De mémoire Solstar avait optimisé le serveur de façon à ce qu'il ne renvoie les information qu'aux joueurs à proximité de nous (et non plus à tous les joueurs connectés en même temps), ça avait réduit la consommation de bande passante de plus d'un quart.

Non je n'ai pas d'outil pour mesurer la bande passante, mais j'en ai d'autre intégrer au navigateur qui font tout comme et je le verrais avec la chute des FPS quand j'atteindrais la limite.

La taille des perso n'auras pas trop d'importance, car le moteur charge tout et le stock en lui et une fois la scene charger il ne manipule que des objets JSON (super rapide) et non du code binaire comme les programme écrit en c++ ou basic, c#... Je pense que l'on pourras avoir une 100 ène d'acteurs par zone PNJ confondu, car j'ai dans le code plusieurs type d'optimisation comme octree, SIMD, web worker, sceneOptimizer, Frustum clipping, Hardware scaling, instance, merge et autres. Je peut aussi geler des objets, materiaux et plein d'autre chose... bref, le moteur est super optimiser et j'utilise tout ce qu'il permet au maximum pour créer des grande scènes sans lag avec des FPS entre 50 et 60 constamment.

Je pense que cela pourrais être aussi une bonne idée d'envoyer les informations qu'au joueurs a proximité. je vais y réfléchir. Ca pourras être une amélioration future si besoin. Mais je peut te dire que le moteur dépasse largement celui de RC, même graphiquement et au niveau des possibilités que je trouve hallucinante. Ça fait plus de 3 ans que j'utilise le moteur tout les jours et j'en découvre encore tellement il évolue vite. c’est le meilleur moteur que je connais après en avoir tester surement entre 10 et 15 en 10 ans. je suis donc assez confiant avec ce qu'il à dans le ventre.

En tout cas je fait tout pour que les performances soit optimum, mais le moteur fait déjà une grande partie du travaille et le serveur que j'ai fait en multi thread devrais lui aussi garantir de bonne réception et renvoi.

Oui je n'en doute pas et je te fais confiance.

Voila 2 nouvelle image. Une pour le formulaire de connexion et une pour la creation du personnage avant de rentrer dans le jeu. j'ai encore des petits ajustements à faire, mais ca fonctionne.

http://www.babylon.actifgames.com/Connexion.jpg
http://www.babylon.actifgames.com/CharacterSet.jpg

La scène de création de personnage pourras être modifier pour créer la votre, cela pourras être changer dans le SDK simplement en renseignant le nom de la nouvelle scene.

Bientôt je vous montrerais une image plus sympas, celle du terrain qui serviras pour la démo. j'ai debugger toutes la partie de l’éditeur de terrain qui fonctionne, je vais pouvoir commencer à réaliser une première zone et verifier que tout les enregistrements ce passe bien car j'ai tout automatiser, vous n'aurez aucun bouton pour enregistrer. Toutes les modifications dans le GE sont enregistrer en temps réelle (sauf pour les particules et les scripts).

Pour la peinture du terrain, il n'y a pas de limites. vous avez 9 slots de textures pour passer d'une textures a une autres, mais vous pouvez les modifier comme vous voulez pour peindre le terrain et utiliser 20 textures différente si besoin. Vous pouvez avoir comme ca, différente textures de neiges (de la propre, de la sale), différente textures d'herbes, de terre, de montagne. Bref, aucune limite.
C’était je trouve dans RC quelque chose de vraiment chiant leur limite de 6 textures. Du coup pour passer outre cette limite, j'utilise une textures dynamique qui peut être peinte et cette textures est enregistrer en tant qu'image et recharger comme un texture diffuses (cela fait que une texture a charger pour le terrain, donc rapide). Vous avez 4 modes de création de terrain, chacune à ses avantages. La plus complete est par l'import a partir du logiciel de modélisation, mais créeras un fichier plus lourd à charger par rapport aux autres méthodes.

Voila, a bientôt.

C'est cool Dad, tu sais si tu as la possibilité de diversifier un peu plus la customisation des persos?
Genre possibilité de choisir et changer la couleur des cheveux, de la peau, des habits avec une palette de couleurs?
Éventuellement, modifier la taille, la largeur du corps etc... Pour s'éloigner du système trop limité de RC?

Oui, j'avais vue quelqu'un faire quelque chose comme ca sur le forum de Babylon, mais il avais bien galérer de ce que j'avais compris. C'est possible, mais beaucoup de travaille.

La sur mon système on peut modifier la couleurs des cheveux et de la barbe. pour la peau et les vêtements j'utilise des textures, donc difficile de changer la couleur vue que le canal diffuseTexture est utiliser, il ne prend pas en compte le canal diffuseColor du coup. La texture a le dessus sur la couleur. Soit j'utilise des couleurs soit des textures. j'ai préférer les textures.

La j'ai fait simple, car je voudrais faire une base de départ fonctionnelle. Mais ca seras sur ma liste de chose a compléter par la suite pour offrir plus d'option.

Pour ce qui est de la taille, ce genre de modification pourrait entraîner des erreurs. Il vaux mieux définir la taille avant dans le GE.

Enfin, pour le moment je ne touche pas trop a cette partie. je l’améliorerais à l'avenir. Ce n'est pas une partie sur la quelle je voudrais m’attarder tellement il me reste de travaille cotée jeu. Oh, et Vous utilisateurs/developpeurs pourrez modifier cette partie de creation de perso car tout est dans le SDK, la creation de la scene et la création du perso, vous pouvez recréer totalement cette partie si besoin. J'imagine que certain partagerons leurs modifications sur le forum de HeroonEngine ou aiderons à le modifier, le compléter.

Salut, 

J'ai ajouter au serveur le système de zone d’intérêt (messages qu'aux joueurs à proximité de nous)

Comment cela fonction en theoris:

En gros il s'agit de room. Le personnage sur un terrain, défini une room par un rayon autour de lui (la zone d’intérêt). Chaque fois que un autres joueurs entre dans cette zone, il joint la room. le serveur renvoie ensuite tout les message aux joueurs qui sont dans cette room (zone d’intérêt). Si le joueurs sort de cette zone, il quitte la room pour entrer dans un autre a condition que d'autre joueur ce trouve dans son rayon d'intérêt.

Il me reste encore a faire cotée client, le rayon qui définie la room par utilisateurs. Je pense que un rayon de 350 a 400 max devrais être bon. Cela devrais fonctionner et permettra un plus grand nombres de joueurs encore sur un même terrain.

J'ai également corriger/améliorer pas mal de chose sur l’éditeur et le SDK. j'ai commencer a créer une zone, mais il y avais quelque bug bien cacher et j'ai du revoir tout mon système d'enregistrement de terrain et de chargement. le système est maintenant impeccable, plus de bug de ce cotée et l'enregistrement est optimiser pour créer des fichier plus petit (diviser par deux leur taille).

J'ai aussi pas mal galérer sur un truc qui n’était pas pris en charge dans le moteur Babylon sur les collisions. Je voulais que chaque joueurs puisse détecter les collisions avec les objets de la scènes, mais pas les détecter entre eux même. Chaque joueur peut passer au travers l'autres si cela est définie dans le GE. Ça n'a pas été simple, il a fallut ajouter un système de collisionFilter au moteur pour que cela fonctionne. C'est en attente d’approbation sur github pour que cela soit intégrer au moteur.

Et j'ai pas mal avancer sur le moteur de jeu. La base est faite, mais il reste encore pas mal de chose a faire. Cette partie est assez minutieuse, car il faut que je créer des ponts/liaisons entre le GE, le SDK et le moteur de jeu. mais ca avance petit a petit.

J'ai aussi commencer le siteweb et le système de licence. Je prévoie une version gratuite pour une utilisation non commercial, sans le SDK et sans le système collaboratif et je prévoie aussi une version complete avec abonnement annuel ou mensuel a 7.50 par mois ou 75 par années (2 mois offert a l'année) Mais comme promis, j'offre la version complete a Giuliani et Denti avec une licence pour 1 ans pour m'aider a tester la version complete.

C'est tout bon, ça s'annonce bien Dad.

Merci pour la version complète, c'est vraiment gentil de ta part. La licence pour un an c'est un abonnement pour la 1ere année? Qu'est ce que ça comprend?
Sans abonnement, on peut continuer à utiliser le logiciel ou il faudra reprendre un abonnement derrière?

Merci d'avance

La licence pour 1 ans c’est l'abonnement pour 1 ans et ca comprend la version complete pour 1 ans.
Ensuite, dès que la licence expire, tu peut toujours utiliser la version gratuite sans perdre ce que tu a fait avec la version complete et sans avoir à telecharger l'une au l'autre version. l’éditeur se configure de lui même suivant la version utiliser). La licence gratuite, n'est pas limiter dans le temps par contre.

Rien n’est perdu donc, même les modifications du SDK. Avec la version free, le SDK est crypter et reste donc sur votre serveur, mais est inutilisable et des que un abonnement est pris, le SDK est décrypter et tout le code modifier et recuperer.

Donc non tu ne sera pas obliger de reprendre un abonnement derrière, il te suffiras juste de cliquer sur un bouton pour utiliser la version free, surtout si ton projet n’est pas commercial et que tu a pas besoin du SDK. Mais avec un projet commercial, les 7.50€/mois serons facilement amortis.

Arf, je vais avoir un probleme avec mon système de peinture du terrain. ca fonctionne bien, mais quand on est proche du sol, les textures pixelise énormément, ce qui ne me plait pas. Je vais devoir revoir ma méthode de peintures et peut être meme ma méthode de creation du terrain ou même carrément reprendre de zéro la creation de terrain, et de peintures de texture du sol. Je veux peut être abandonner l'idée de creation par 4 mode de creation de terrain séparer et faire un seule mode tout en un. car je me facilite pas la tache. J'ajouterais peut être un système de plugin pour ajouter d'autre mode de creation de terrain qui sera séparer. bref, si je doit recommencer ca, autant réfléchir a faire mieux.

Ça m'enchante pas, mais j'ai pas le choix, ca pixelise trop. je ne sais pas combien de temps ca vas me prendre de modifier tout ca, mais je veux que ca soit parfait. je risque de décaler encore sa sortie du coup.

Erf. Pas grave, prends ton temps.

Merci. je reviendrais vous monter ca quand j'aurais réussi quelque chose de parfait. je travaille sur deux piste que j'ai. mais y a du taf, c’est un gros morceau comme changement.

a bientôt donc.

Ca me gave, je ne parvient pas a faire un truc qui me convienne. Sur le forum de Babylon, on me dit qu'il faut que je créer un shader pour faire ce que je veux et je ne sais pas les faires (ca a pas changer ca, c’est chaud a faire).
J’ai donc une dernière solution qui pourrait éventuellement convenir et qui permettras d'allez plus loin. mais j'aimerais ton avis la dessus Giuliani et Denti si tu passe par là.

Si vous créer vos terrains avec votre logiciel de modélisation 3ds max ou blender que vous exporter pour l'importer ensuite dans HeroonEngine, est ce que cela vous poserait un probleme ?

En faite a partir du logiciel de modélisation vous pouvez créer comme vous voulez le terrain avec peinture comme un modèle 3d en faite et HeroonEngine ce charge derrière de reconstruire votre terrain.

Bien sûr, une fois importer, vous pouvez ajouter des objets à la scène a partir de HeroonEngine, vous ajouterez les portails, de l'eau et autres. Votre logiciel de modélisation vous permettras de faire et le terrain et les modeles qui vont dessus.

En faisant ainsi, cela permettras de créer avec plus d'outils que je ne pourrait en faire, cela offre plus de liberté que je ne pourrais offrir. Vous pourrez a tout moment éditer a partir de 3ds max ou blender les terrains pour mettre a jour sur HeroonEngine si besoin.

En gros, je compte retirer tout les outils d’édition de terrain de HeroonEngine et mettre un système d'import de terrain tout fait texture incluse. Que pensez vous de cette solutions ? est ce que vous trouvez que cela peut être un probleme ? J'ai pas vraiment d'autre solution potable et celle ci me parait plutôt bien. 

Bref, merci pour votre avis sur la question.

Bon je sais pas ce que vous en pensez, j’espère que cela ne vous posera pas de probleme, mais je l'ai fait. Vous pourrez créer un terrain avec 3ds max ou blender et l'exporter pour l'importer dans HeroonEngine.

Vous pourrez a partir de votre logiciel de modélisation (3ds max ou blender) créer le terrain avec la taille que vous voulez sans pour autant faire du démesuré (2000*2000 max est le max, ca fait 4 Km², c'est enorme, mais vous n'êtes pas limiter). Vous pouvez faire des terrains carrer, rectangle, rond, en L en U, faire vos montagnes, rivière, plateau, ramp, troue, bref, tout ce que vous voulez. Niveau textures, vous pouvez ajouter des texture diffuse, bump, specular... et sans limite en nombres de textures, bref, cela offre vraiment plus de liberté de personnalisation pour faire des super terrain. Vous pouvez même ajouter des objets, des lumières, des actions sur ce terrain directement avant de l'exporter. je trouve ca en faite vraiment plus cool, on peut faire ce que l'on veux.

HeroonEngine ce chargeras d'importer votre terrain au complet avec les éventuelles modèles que vous aurez mis dessus et ensuite de pouvoir les repositionner de nouveau si besoin dans HeroonEngine et éditer leurs propriétés ainsi que compléter votre scene. J’espère que vous trouverez ca bien.

Je suis maintenant en cours de creation d'un système de modules/addons qui permettras d'ajouter des fonctionnalités a l’éditeur ou des petit gadget (comme faire un screenShot de sa zone par exemple). Comme ca si plus tard je veux ajouter un système d’édition de terrain par exemple, je pourrais le créer a part et qu'il soit ajouter comme addon a l’éditeur et ceux qui n'en voudrons pas, ne l'ajouterons pas. Ce système pourras permettre de faire évoluer facilement l’éditeur pour les utilisateurs et peut être même que des addons pourrons être fait par la communauté qu'il partagerons. Ça serait plutôt cool suivant les besoins des un et des autres.