EDJ - Editeur de Jeu !

There aren't any users online.

• kriss: oui.. je dois faire des demandes pour que google refasse des analyse du site afin de "voir" s'il est tjr malveillant
  Dcembre 08, 2011, 22:47:27
• Leopold: Cool! Mais Firefox me le déclare toujours malveillant...
  Dcembre 08, 2011, 22:30:32
• kriss: réouverture du forum !
  Dcembre 06, 2011, 00:48:58
• Fabien: Coucou facto!! Trop bon de repasser ici
  Septembre 25, 2011, 18:06:22
• Krän: aye ! ^^
  Aot 21, 2011, 23:43:29
• RPG-Man: lol manu
  Aot 20, 2011, 00:24:00
• RPG-Man: JE SUIS REVENU MOUHAHA
  Aot 20, 2011, 00:22:26
• Manucyan: Ca dit quoi un ivrogne dans le noir ? "hé... t'es qui là ?"
  Mai 07, 2011, 18:11:20
• Krän: Il est 2h46 et tout est calme !
  Mai 05, 2011, 01:47:01
• Manucyan: La tronche du bestiaire ? Un pokédex !
  Avril 30, 2011, 21:18:09
• Manucyan: désolé je pensais que tout le monde connaissait le phénomène du rickroll (cf wikipédia)
  Avril 30, 2011, 14:08:48
• kriss: ca merite un ban pour ce lien oO
  Avril 30, 2011, 12:29:51
• RPG-Man: Sale vilain
  Avril 30, 2011, 11:26:31
• Krän: Never gonna give u up, never gonna let u dooowwwn ...
  Avril 28, 2011, 20:29:20
• kriss: en effet mais ce n'est pas normal.. il y a un bug que je dois trouver ^^
  Avril 25, 2011, 10:30:16
• Leopold: Pour la mise à jour, on peut cliquer sur "Refresh" (deux flèches vertes) ou sur "History" (pendule).
  Avril 22, 2011, 21:31:57
• RPG-Man: Manque plus qu'elle se mette à jour toute seule quand on ajoute un message et c'est le must !
  Avril 21, 2011, 20:29:39
• RPG-Man: le shootbox CAY LE BIEN
  Avril 21, 2011, 20:29:14
• kriss: on appel ca une shootbox
  Avril 18, 2011, 16:47:13
• Manucyan: hé mais c'est marrant !
  Avril 17, 2011, 18:03:46

[King Kadelfek]

Je suis en train de reprendre tout l'Editeur 3D de façon à le rendre plus indépendant de RM.

J'en profite pour développer l'EDJ (Editeur de Jeu), qui servira à mapper les décors en 2D ET en 3D.
Grâce à ça, on n'aura plus la contrainte des superpositions de RM.

Un test rapide de ce qu'on peut faire actuellement :



Il convient de dire qu'il s'agit d'un maping graphique. Il pourra être différent du maping physique (avec obstacles).

Les cubes n'ont pas forcément la même taille. Les textures sont automatiquement agrandies / rétrécies.
Les pentes ne sont pas encore faites.
Les cylindres sont faits.
On pourra utiliser la roulette.

Cet EDJ me permettra aussi de faire le MG3D (Moteur Graphique 3D) tant attendu pour RM.
Le MG devrait régler les problèmes de positionnement de l'ombre (enfin !).

L'affichage en vue "à la Zelda" (vue RMXP classique) sera un cas spécial du moteur graphique 3D.
Il y aura une différenciation entre les sols et les volumes.

Exemples :
Un sol sera un simple carré de 32*32.
Une plateforme volante sera un cube de 32*32*10.
Un arbre sera une image de 110*150 MAIS sera verticale.

Pour comprendre facilement : regardez la table devant vous.
- le sol, c'est une feuille de papier posée sur la table
- la plateforme, c'est un objet (genre canette)
- l'arbre, c'est l'écran plat de votre PC

La canette peut passer devant ou derrière l'écran. En étant toujours sur la feuille de papier.
De cette façon, vous voyez que les trois types d'éléments pourront coexister dans une même map.



Quelques screens des nouvelles fonctionnalités :


Des cubes semi-transparents sont possibles :


Un nouveau type de positionnement des blocs en hauteur est disponible :





Voilà, c'est tout pour le moment.

[Atom]

Cool tout ça ! Je ne sais pas comment on s'y prend pour mapper graphiquement, doit-on sélectionner le tile dans le tileset pour qu'il serve de texture, est-ce une image séparée, comment différencier ces textures de sprites fixes (qui nous feront toujours face) ? Mais c'est très prometteur pour la suite, fusionner le mapping graphique et physique facilitera grandement la conception des maps.

[kriss]

Encore une fois c'est du boulot d'acharné pour notre plus grand plaisir








Longue vie au moteur
Gloire à l'usine

[King Kadelfek]

> Atom

On aura une espèce de boîte à image à gauche de l'écran où sélectionner le cube 3D :



Pour fabriquer les cubes 3D, pour l'instant, il faut éditer un fichier txt :

1 : etg3_top, etg2_side2, etg5_top, etg3_side3, etg5_side4
2 : arbre2

Oui, ce sont les deux blocs qu'on voit.

Plus tard, on pourra aussi définir les dimensions.
Et plus tard, on aura même un mini éditeur pour fabriquer ses propres blocs.

Il y aura sûrement un onglet dans la boîte à images pour passer des cubes 3D au tileset sol et un autre onglet pour le tileset sprites debouts (genre arbre).
(ce sera en fait le même tileset, sauf que les sprites placés seront soit couchés soit debouts)

Je pense reprendre directement un tileset RMXP dans cette boîte à image.
Peut-être redécoupé pour des raisons de taille, en attendant de pouvoir utiliser Rubygame comme librairie graphique.

J'ai besoin du retour de MGC pour en parler avec lui.

Longue vie au moteur
Gloire à l'usine

Gloire à l'usine !

[Atom]

J'ai pas tooout compris le concept de boite à image. Les textures sont donc dans un fichier différent de tileset ?

Dans le doute j'ai commencé à réfléchir sur une interface la plus simple possible, je sais pas si c'est encore optimal mais tu vas me dire ce que tu en penses.

Voici comment ça se présente :


J'ai donc rajouté toute une colonne à gauche, l'idéal serait de pouvoir dépasser la résolution de 640*480 pendant l'édition mais pour l'instant j'ai empiété sur la map (donc c'est pas très pratique, on ne vois plus beaucoup de map ni de tileset...).

De haut en bas dans cette colonne :

- 3 onglets permettant de choisir le type de tile : le classique à plat (le sol), en volume (cube, comme dans l'exemple), ou en vertical (sprites d'arbres).
- vue du cube généré
- tileset

Pour générer son cube, il suffirait de faire glisser des tiles du tileset sur les faces du cube au dessus. C'est surement un peu chaud à faire, alors la deuxième solution serait de sélectionner une face du cube et ensuite de sélectionner le tile.

Pour les autres onglets de mapping, sprites horizontaux et verticaux, il n'y aurait plus que le tileset dans la colonne de gauche, et les options classiques pourraient être différentes (plus de volumes au profit de réglages spécifiques, par exemple rotation des sprites verticaux ou pas pendant la rotation de map).

[King Kadelfek]

L'EDJ est disponible dans la version complète du projet, le DMK Megazord :

http://rpgmakerxp-factory.net/forum/index.php?topic=13269.0



> Atom
T'as exactement fait l'interface que je voulais faire.
(Désolé si je me suis mal exprimé.)

Ton idée de faire des cubes personnalisés est plutôt bonne. Le problème, c'est que plus il y a de cubes différents dans une map, et plus ça prend de RAM.

J'ai estimé qu'on peut monter à 180 cubes, ce qui devrait prendre pas loin de 200 Mo de RAM.
Donc ce qui va poser problème, c'est qu'à chaque fois que le maker va faire un nouveau cube, ça va prendre un peu plus de place en mémoire.
Attention, ça ne fait pas ramer (coût en CPU), ça prend de la RAM (coût en RAM).

Oui, le précalculé est la seule solution à l'affichage de 3D.


Puisque ça doit être mieux contrôlé, je pense plutôt à un onglet dans la BD de l'EDJ genre onglet chipset dans lequel on fabriquerait ses propres cubes. De façon plus facile que dans le petit écran sur le côté gauche.

A ce propos, on ne pourra utiliser la nouvelle librairie graphique (et dépasser allègrement le 640 par 480 et les 40 FPS) que lorsque MGC aura fait en sorte que l'on puisse utiliser sa DLL dans un programme Ruby (hors RMXP).


Atom, si tu veux réfléchir à un moyen de fabriquer ses propres cubes, un genre de "petit atelier de construction", ça m'intéresse beaucoup.
Tu peux faire des schémas, sachant que la place disponible est de 640x480, avec des sous-fenêtres si besoin est.

N'hésite pas, ascenseurs, listes déroulantes, onglets, comme dans une vraie application.
Zeus81 commencé à me filer un sacré coup de main de ce côté-là, on aura bientôt tous les composants qu'il nous faut.

J'aime beaucoup ce que tu as fait là.
Et c'est sacrément plus joli que mes schémas à moi. 

[Krän]

J'avais pensée à un truc ...
Au lieu d'avoir à gérer des cubes, ne pourrait-on pas gérer que des faces ?
On gère des faces qu'on assemble : c'est à dire on va faire toutes les images d'une face tournée et on assemble ces images pour former un cube, au lieu de calculer directement un cube entier.
L'intérêt est peut être minime mais on peut y gagner un peu :

Je pensais un peu au système de Roller Coaster Tycoon.

[Atom]

Construire les cubes dans un autre onglet, voila qui laisse de la place ^^ (presque un peu trop)

Je pense que le plus simple serait de mapper les cubes comme on le fait sur une carte : on sélectionne le tile dans le tileset à gauche et on clique sur la face du cube (ici en éclaté) pour le mettre en texture.



Dans cette configuration, les tiles s'orientent automatiquement sur la vue éclaté, par exemple le mur qui est vertical dans le tileset se retrouve vue horizontalement dans la vue éclaté. Il faudrait peut-être prévoir deux autres boutons si l'on souhaite réorienter les textures manuellement.

[RPG-Man]

A propos de l'utilisation de la RAM :
L'important, c'est que ce ne soit pas l'utilisation du CPU qui soit affectée! La RAM, je pense que presque tous les PC ont au moins 512 Mo, et en plus, tout ce qui se vend maintenant fait 1 ou 2Go de RAM au minimum, donc, c'est pas un gros problème tant qu'on ne dépasse pas une certaine limite.

-> Kran
C'est 4 faces à calculer mais pour UN cube! Et en plus un cube a 6 faces!!!
Moi, ce que je pense, c'est qu'il faut donner un numéro à chaque Tile, et que pour un cube, on donne un numéro pour chaque face (comme fait RM pour la disposition des Tiles je pense, et en reprenant la technique de Kran pour les faces).
Sur la RAM, il n'y aura donc que les textures utilisées + les numéros des Tiles de chaque face, peut être codées comme ça:

Code:

X, Y, Z cube( n°face_1, n°face_2, n°face_3,n°face_4, n°face_5, n°face_6)

Ou, pour prendre moins de place comme ça:

Code:

X, Y, Z cube( n°faces_1+6, n°faces_2+4, n°faces_1+3)

Avec X, Y, Z : coordonnées du cube (par case?)
n°face_x numéro du Tile utilisé pour les faces (défini dans un ordre)
Dans le cas n°2, les faces 1 et 6; 2 et 4; 1 et 3 sont parallèles.
Donc, on aurait par exemple:

Code:

2, 21, 3 cube ( 25, 11, 36)

Voilà, j'espère que j'ai apporté une petite aide... (même si je ne m'y connais pas trop) 

[Krän]

Ben ... en fait le problème vient pas vraiment de la façons dont on stocke les cube mais plutôt les images.
King fait du précalculé : Il enregistre sur la ram différentes images de son cube avec des degrés différents : 0°,5°,10° ... 350°
Donc pour disposer les cubes il lui suffit de choisir un cube, un degré, et d'afficher l'image correspondante.
Ce que je lui propose c'est d'utiliser à la place des images de cubes, des images de faces et de les assembler pour faire des cube.
Pour résumer on précalcule des faces au lieu de précalculer des cubes.

Et en plus un cube a 6 faces!!!

Pas dans le système de king. (il ne gère pas la face du dessous dans un cube)

[kriss]

Je suis resté dans le coma 6 ans? j'arrive et pouf j'en prend plein les yeux...

Bon je vais dl évidemment.

J'ai parcouru ton topic anglais. En théorie ce genre de post devrait etre saturé de "woo excellent" , incroyable comment c'est possible etc mais je n'ai vu qu'un "ca fait déjà 4x que je vois ca, tu spam?" et un "pour quand une démo?"

Bref je pense sincérement que les makeurs ne sont pas encore pres pour recevoir cet editeur, pour plusieurs raisons :
- c'est un gros pavé à lire (ce n'est pas de ta faute... c'est le contenu qui veut ca) et on sait que la moyenne d'age est basse.
- ca parait tellement hors des limites de rm xp que ca fait "fake", n'oublie pas la réaction de Mod qui n'est pourtant pas un "jeune"
- les makeurs ne semblent pas intéressés au point de répondre car à partir du moment où ils ont mis la main sur rm, ils savaient pertinemment les contraintes du logiciel et toi tu les fait voler en éclat, donc personne "n'attend" cet éditeur (dans le sens où tout les makeurs ont un jeu en cours qui est cadré dans les limites du logiciel de base); dans le même esprit , combien utilisent le script plate forme de MGC qui est pourtant + simple d'acces ?

Je dis que les makeurs ne sont pas pres, ce n'est pas pour autant qu'ils ne s'en serviront pas : ils y a peut etre trop d'information technique et pas assez pratique
Si j'écris ca , c'est parceque si j'étais à ta place je serais un peu désapointé des réactions (ou plutot de manque de réaction), je prend donc les devant en donnant mon humble avis
Je pense donc qu'il faudrait une présentation bcp plus succincte voir énigmatique:  tu parle en gros des choses possibles (un zelda à la sauce mario car on peut tomber et sauter, modifier les textes dans les messages grâce à un .txt) et c'est tout !
Pour étayer la présentation il faut une démo jouable du gameplay.
Apres bien sur ils vont regarder comment c'est fait et ouch ils vont rien capter.. c'est là qu'un 2e post intervient le lendemain pour entrer plus en détail afin de parler de l'editeur 3D.
Je peux peut etre me tromper , mais les makeurs ne sont pas trop intéressé par comment mapper, ils preferent savoir ce qu'ils pourront faire en jeu

[King Kadelfek]

Je suis resté dans le coma 6 ans? j'arrive et pouf j'en prend plein les yeux...

C'est vrai que sortir tout ça d'un coup, c'est waw ! 

En théorie ce genre de post devrait etre saturé de "woo excellent" , incroyable comment c'est possible etc mais je n'ai vu qu'un "ca fait déjà 4x que je vois ca, tu spam?" et un "pour quand une démo?"
[...]
Si j'écris ca , c'est parceque si j'étais à ta place je serais un peu désapointé des réactions (ou plutot de manque de réaction), je prend donc les devant en donnant mon humble avis

Le secret, c'est de ne jamais rien espérer de la part des makers. En plus de ça, je me dis qu'ils l'auront bien mauvaise quand j'aurais repompé tous leurs jeux pour les proposer en version supérieure au grand public.
Tiens, récemment, j'ai pu hacker Laxius Power 4 (le RGSSAD est tombé).
Si je voulais, je pourrais traduire le jeu en français et le proposer aux joueurs français, mais ce serait malhonnête. 

-------------------

Je pense qu'en fait, un jour... pouf, y'aura moins de monde sur RM parce qu'ils seront passés sur un autre logiciel.
Je suis en concurrence avec plusieurs autres gros projets. Mais je pense que je finirai par être premier. 
J'ai encore plus de chances si on se tient tous la main et qu'on chante la chanson de l'amitié !! 

Etant donné le monde qui travaille dessus maintenant, je vais même commencer à dire "nous".
Moi, Zeus81, MGC, Lufia, Moumou, Neo_Sephiroth, Roys (bientôt), et peut-être aussi Krän et Atom, dont le boulot (étude et prog) va bientôt être intégré à DMK MZ.

Je vais peut-être renommer ça RPG Maker MZ ?
Pour RPG Maker Megazord*.

*copyright SABAN
 


> Krän

J'avais totalement oublié que l'on pouvait reprendre des faces déjà calculées si les faces d'un cube sont identiques.
C'est pourtant ce que j'utilisais autrefois avant les textures.

Mais ce n'est possible que si la face supérieure est monochrome, ou au moins symétrique horizontale et verticale.
Parce que la face supérieure tourne sur elle-même.


Après, en ce qui concerne ton idée de ne gérer que des faces, l'assemblage va nécessiter des calculs (même si ces calculs sont précalculés pour chaque angle), et ça va bouffer en CPU.
Et ce ne serait rentable que s'il y avait plusieurs fois la même face sur un cube.
On ne jette pas l'idée, mais il y a peu de chances qu'elle serve. Je m'en souviendrai tout du moins.

Une façon plus intéressante de l'utiliser, ce serait de maper directement des faces sur la carte au lieu de maper des cubes.

On a déjà des faces horizontales (le sol) et verticales (les arbres).
Il y aurait aussi des faces latérales (gauche et droite) et derrièrales (derrières ).

Là c'est intéressant je trouve.

Je pensais aux plaques (on va les appeler comme ça) pour gérer de la 2D, mais c'est intéressant pour la 3D aussi.

Imaginez que vous vouliez mettre une fresque murale sur un mur : c'est bien plus pratique de directement placer une plaque issue du tileset que de fabriquer X blocs.

------------

Partons maintenant du principe qu'il sera possible de maper en plaçant soit des cubes, soit des plaques (par le biais des onglets).

3 types de plaques. Sol, et 2 murs.
On peut voir les plaques de dos, ce qui fait qu'une plaque droite et une plaque gauche ne sont pas différentes en réalité.

------------

Krän, pour l'interface, tu peux regarder un peu le code de "E3D Fen_Com" et "E3D Fen_Tel" dans le projet principal, tu verras comment sont créées mes fenêtres grâce à la GUI.
Exerce-toi un peu durant les vacances.



> Atom

Les cubes pourront être de dimensions autres que 32*32*32.
Dont il faut 3 sélecteurs d'entiers pour choisir les dimensions :



Des noms pour les trois dimensions ? Longueur, largeur et hauteur, mais je trouve que ça ne parle pas beaucoup...


Autre chose, les textures ne proviennent pas forcément du tileset, mais aussi de fichiers séparés. De dimensions hétéroclites.
La prévisualisation peut être désactivée avec une case à cocher.
Plutôt placée en dessous de la prévisualisation, pour ne pas gêner l'oeil lors du trajet entre la prévisualisation et la partie "choix de ressource" (tileset ou image libre).

Qu'importe la taille de l'image / tileset par rapport au cube, les images sont redimensionnées comme il le faut.
Il sera possible de sélectionner plusieurs cases sur le tileset (se fait avec la souris, pas besoin de boutons).

Il sera possible de faire une sélection au pixel près sur l'image / le tileset. Dans ce cas, une fenêtre s'ouvre (à côté du tileset) comme une loupe pour permettre de choisir au pixel près où on clique.
La sélection au pixel près se choisit en cochant l'option "sélection au pixel" quelque part près du tileset.

Si c'est une image qui est affichée à gauche, les options sont les suivantes :
1- toute l'image
Toute l'image est utilisée pour servir de texture.

2- sélection taille face sélectionnée
2-a sélection au pixel
2-b sélection par case

Pour 2-b, comprenez que l'image est alors découpée en cases de dimension (c'est un exemple) 32*32, comme un tileset.


Je reprends toute cette partie :

1- sélection
1a- toute l'image
1b- taille de la face du cube sélectionné
1c- libre
1d- définie : width * height

Ensuite, il y a le positionnement : il s'agit des cases virtuelles pour aider à la sélection (coin supérieur gauche de la sélection).
Dans un tileset RM, c'est 32*32. Dans un charset, c'est width/4 et height/4.


2- positionnement

2a - libre
2b - défini : width * height
2c - taille de la face du cube sélectionnée


Pour un tileset, c'est automatiquement 1d (32*32) et 2b (32*32) qui sont choisis.

Ces options sont cachées et visualisables en cliquant quelque part, ou à l'approche de la souris d'une zone.


Description du fonctionnement de l'application

C'est uné méthode informatique simplifiée. Faites pareil pour vos descriptions.

Le fonctionnement de l'application :

U = l'Utilisateur
S = le Système

S affiche la page de création des cubes

S affiche le dernier type d'image choisi pour la gauche (par défaut tileset)

S sélectionne les dernières options choisies (par défaut 1d et 2b)

S sélectionne la dernière face sélectionnée du cube (par défaut la supérieure)

U sélectionne la texture à gauche

S applique la texture à la face du cube sélectionnée

U valide

S ajoute ce cube à la liste des cubes créés

S affiche la page des cubes déjà créés

Note : il faut un écran où on visualise tous les cubes déjà créés !


Cas spéciaux :
- U sélectionne une autre face
La prochaine texture sélectionnée sera affectée à cette face.

- U sélectionne d'autres options
La prochaine texture sélectionnée le sera suivant ces options.

- U modifie les dimensions du cube
S redessine le cube suivant les nouveaux paramètres.

- U quitte l'écran sans avoir validé
S n'ajoute pas le cube à la liste de ceux créés.
S affiche la page des cubes déjà créés.

- U n'a pas sélectionné de textures pour toutes les faces
S affecte une texture par défaut (transparente, monochrome noire ?) aux faces sans textures.


Voilà, il faut traiter en fait tous les cas qui créent des modifications dans le déroulement du programme.
Il faut aussi sous-détailler la partie "U sélectionne d'autres options".

Ça permet d'avoir une approche à la fois scientifique et assez vague du comportement de l'application.
En théorie, on ne doit implémenter que ce qui est décrit ici.

[filsduloup]

woaw, magnififique !!

mais pour le moment ca me parait compliquer, car comme le dis certain c'est très technique, est-ce que tu a prévu un tutoriel ou un mode d'emplois. Créé un outils puissant c'est bien, créé un outil puissant facile a utiliser c'est mieux !

N'oublie pas que beaucoup de gens créé leur jeux avec rmxp pour ça simplicité. Peut être que tu pourrait ouvrir un topic d'explication pour le moment l'edj pour les nulles (comme filsduloup)
A première vu ton éditeur parait complexe ça peut rebuté les makers !

Maintenant je suis pas un expert en informatique et je ne cherche pas n'ont plus la facilité mais un outil qui répond a mes besoin ! (renpy pour les vn) je bidouille, si tu écrit un tutoriel pense au personne qui te liront et qui utiliseront ton outil de making.

King il suffit pas de créé un programme et pouf, non il faut encore a simplifier son utilisation au gens.

Cela dit  je télécharge la demo et je teste sur le champs !

[Atom]

Pour le fichier contenant les cubes déjà créés, je propose d'ajouter un onglet "bibliothèque".
Il y a comme ça un onglet d'édition pour éditer des blocs et un onglet bibliothèque pour les archiver.

Voici la nouvelle interface comprenant les nouvelles données :



J'avais oublié de le dire, mais le petit menu avec "cube" sert à sélectionner la forme du volume. Les cylindres et les pentes pour les autres possibilitées.

[King Kadelfek]

Vois plutôt cette page comme une fenêtre par dessus les autres onglets.
Disons que là, on n'a pas de bouton annuler, donc on ne sait pas vraiment quand on quitte l'édition d'un bloc.

De plus, tu as placé la case à cocher "aperçu" justement sur le trajet visuel, alors qu'il faut l'éviter.
Inconsciemment U va lire ça à chaque fois que son regard va passer dessus, ça va être fatiguant.

> Filsduloup

Un utilisateur normal n'aura que le tileset et les dimensions normales.
Le reste sera déblocable en choisissant "activer l'interface avancée pour la création de cubes" dans un écran d'options.

Les interfaces avancées seront activables séparément pour chaque partie de l'application.
Ça permettra au maker d'avancer petit à petit dans l'utilisation du logiciel.

Et de faire un jeu sans se casser la tête avec uniquement les options par défaut, sans être effrayé par tout ce qu'il y a.