[Sheeft]

Bonsoir à tous,

Je sais que je suis pas très actif en ce moment mais je suis dit que ça pourrait être sympa de débattre un peu sur nos façons de développer un jeu ou autre… Enfin si ça vous intéresse… Mais comme ça, on pourrait échanger quelques idées non ?

Aujourd'hui j'ai pensé que ça pourrait être cool de discuter un peu de la façon dont on structurait nos niveaux, comment on faisait nos éditeurs (si on en fait) et tout ça…

Ce n'est pas une question innocente que je pose, je suis bien évidemment intéressé par ce vous pourriez répondre.

Ce qui semble venir en premier c'est un peu l'idée des tiles mais est-ce que ça permet vraiment de faire des trucs super variés ?
Je pense que oui mais ça a des limites donc je voulais savoir quels étaient les alternatives.

Pour ma part, dans Scape j'utilisais des fonds fixes (un par monde donc pas super variés) et j'y ajoutais ensuite les quelques éléments qui flottaient par dessus…

Sinon, je pensais aussi à du "vectoriel", y'en a qui font ça ? Je veux dire dessiner des formes pour planter le décors ce qui permet d'avoir des zones non rectangulaires…

Finalement je pose pas mal de questions, je veux pas non plus vous voler vos méthodes hein ? Juste lancer un petit débat sur lequel je me posais des questions récemment.

A bientôt.

[EvilTroopa]

Alors... tout dépend du jeu !

Pour NanoMechas, je commençais par un level design rapide sur un cahier. Ensuite, je refaisais ça au "propre" sur 'toshop (en fait juste les contours de mon niveau) que j'envoyais à mon graphiste pour qu'il en fasse quelque chose de joli. Comme les niveaux avaient des fonds non répétitifs, pas vraiment besoin d'un éditeur.

Pour un petit test de RPG sur Wii, à base de tiles, j'avais fait un éditeur vite fait direct avec le moteur du site.

Pour les jeux en 3D, j'utilisais le soft Maya et j'avais intégré de nouvelles fonctionnalités en Python. Cela me permettait de placer mes éléments dans mon environnement 3D. Je n'avais plus qu'à exporter les positions/rotations/scales de tous mes objets dans un fichier texte que j'importais ensuite dans mon jeu.

Pour la démo "Balls of steel", l'éditeur de niveau c'était une image en noir et blanc que je remplaçais

Et le reste du temps, je fais des trucs dégueulasses en dur dans le code.

[t4ils]

Perso je fonctionne en Tiles

Mais je suis vite limité à des niveaux rectangulaires sachant que je ne maîtrise pas les tiles pentu :/ (je veux bien qu'on me redirige vers un quelconque tuto la dessus  )

Sinon pour mes éditeurs de niveaux, toujours le même layout : zone de dessin au milieu, tiles/sprites sur le côté en sélection et on dessine à l'écran

Derrière, je sauvegarde habituellement le tableau de tiles en mode texte (à l'arrache ), et récemment je me suis mis à rendre le tout XML pour stocker plus facilement les objets du niveau (joueur, sprites, décor ...).

Chaque fois que je fais un platformer, je refais un éditeur de niveaux ... C'est pas forcément des plus pratiques (et rapide ), mais je peux faire des tests en temps réel, c'est pratique

[EvilTroopa]

Mais je suis vite limité à des niveaux rectangulaires sachant que je ne maîtrise pas les tiles pentu :/ (je veux bien qu'on me redirige vers un quelconque tuto la dessus  )

J'avais un début de projet sur Wii avec des tiles losanges, je vais voir si je retrouve le code que j'ai utilisé

[smealum]

Alors moi dernièrement je fais mes éditeurs moi même, en C# avec des fenêtre opengl pour le rendu graphique (via le Tao framework). Ce qui est cool c'est que comme ça c'est assez rapide de se faire un truc qui marche et qui a de la gueule. Après, j'aime pas vraiment le C# donc c'est méga crade et jamais je ne montrerais le code à qui que ce soit (à la limite si ma vie en dépendait... et encore)
Du coup je fais au cas par cas. En même temps j'ai fait que deux jeux qui avaient vraiment besoin d'un éditeur de niveaux adapté (arsenal et dawnseekers). En fait le truc la plupart du temps avec les éditeurs pour moi, c'est que à la limite c'est pas nécessaire de se faire un éditeur pour vraiment créer le contenu en soi, c'est surtout pour placer toutes les entités, ie ennemis, portes, waypoints... Ce serait cool d'avoir un éditeur qui puisse faire ça de façon générale, avec des scripts pour exporter vers un format perso, mais à l'époque j'avais cherché sans rien trouver. Du coup pour dawnseekers, l'éditeur sert juste à convertir des données et ajouter des entités, tout le contenu de base était créé par Lobo sur 3DSmax.
Pour Legion j'avais pas besoin de grand chose, du coup j'avais utilisé un éditeur de tilemaps "généraliste". Pour placer mes entités je m'étais démerdé en faisant plusieurs couches, genre une couche pour les ennemis (où le numéro de la tile c'était l'id du type d'ennemi), une couche pour déterminer l'altitude etc. (si je me souviens bien, j'avais utilisé ça : http://tilemap.co.uk/mappy.php)

Éditeur arsenal :


Éditeur dawnseekers :


Ah et je sais pas si ça compte, mais DScraft a un éditeur de niveaux intégré !
(enfin au fond c'est rien de plus qu'un éditeur de niveaux donc bon)

[Zipler]

Smealum, tes éditeurs ont l'air über-cools!

[sebskater29]

Moi je fais mes éditeur en VB.
Une zone de dessin, une zone de sélection de tuile et différentes options de dessin, et je sauvegarde le tout dans un fichier texte.
Alors mes éditeurs ne sont pas réactifs, mais tant que c'est fonctionnel

[PypeBros]

Perso je fonctionne en Tiles

Mais je suis vite limité à des niveaux rectangulaires sachant que je ne maîtrise pas les tiles pentu :/ (je veux bien qu'on me redirige vers un quelconque tuto la dessus  )

en attendant un tuto sur dev-fr, je peux te proposer mes p'tits articles là-dessus.

Sinon, tiles aussi pour moi, et édition directe sur DS. Idem pour les sprites et les animations. Parce que je le vaux bien
-- --
Bon, ça demande un peu plus de bidouille pour partager les infos, mais les structures de données sont directement adaptées au traitement par la console, j'ai directement les bonnes couleurs (Gimp est pénible à utiliser en 5 bits/couleur), les bonnes dimensions, etc. Et je peux le faire chez mes beaux-parents si je veux.

J'ai tendance à utiliser un fichier texte pour "le reste" (position des monstres, actions/réactions), essentiellement parce que cette partie-là est appelée à pas mal évoluer au fil du développement. Ca me permet aussi de faire des tests avant d'avoir développé un éditeur adapté.

En 2000, j'avais fait un petit shoot'm'up en assembleur, pour une démoparty, où les niveaux étaient déclarés avec des macros assembleur du genre

Code:

line 180
spacemine 120
line 200
ufo 20, normal
ufo 60, angry
ufo 120, normal|powerup
line 300
ziktrack speedy

chaque ligne était directement convertie en séquence de bytes qui représentait les évènement, assemblés assez facilement (moins de 3 seconde) et liée au projet. A peine plus long qu'une sauvegarde, en fait.

J'ai tendance à faire beaucoup de design/brainstorming papier, parce que j'aime bien dessiner sur papier, mais quand je démarre vraiment le niveau, c'est entièrement sur l'éditeur, de préférence tel que le joueur le verra, en "free style" et selon l'inspiration du moment. Les p'tits gars du temps de l'Amiga proposaient carrément que l'éditeur fasse partie du moteur de jeu pour pouvoir déplacer des monstres, etc. pendant qu'on joue au jeu.

[t4ils]

Ha merci, bien sympa ces articles

C'est exactement comme ça que je comptais le faire, mais je pensais que c'était une méthode à l'arrache Faut croire que c'est la bonne technique au final

Merci

edit : voilà de mon coté l'éditeur que j'utilise pour un développement en cours
C'est de la technologie web

[Sheeft]

C'est sympa de voir ce que vous faîtes

(On pourrait se faire quelques petits débats partages dans le genre non ?)

Sinon, pour qu'un éditeur de niveau soit adapté aux joueurs vous le feriez différemment que pour vous même donc ?

Je me demandais comment étaient fait les niveaux de world of goo par exemple…
Du coup j'ai regardé, et c'est assez intéressant, on place des images et puis des éléments de bases (carrés ou cercles) pour créer les collisions etc. C'est intéressant.

[EvilTroopa]

Joli éditeur T4ils

[PypeBros]

Dans la série, l'éditeur du jeu "Soul Bubble" en action.
http://www.youtube.com/watch?v=MS9kqrGt_bM

C'est vraiment le moteur de jeu combiné à une interface de manipulation des structures de données

[t4ils]

Il pète le feu leur éditeur dis donc

Merci Evil
Habituellement, mes éditeurs je les fais à l'arrache, y'a que moi qui comprends comment ça marche. Mais comme je pense le diffuser par la suite, autant qu'il soit propre dès le début (et Cladil veut des trucs propres tout de suite donc je l'écoute )

[PypeBros]

Bien vu pour l'éditeur online. A mon avis, c'est quelque-chose qui est appelé à devenir de plus en plus fréquent ... et si en plus il est compatible tablettes...

Sinon, je ne sais pas comment tu définis "à l'arrache". Je pense que ce genre d'éditeurs, c'est inévitablement des prototypes. La priorité doit être de pouvoir ajouter facilement le support de telle ou telle fonction (portes liées entre elles, bonus cachés ...) qui feront que le jeu sera intéressant. L'ergonomie est importante aussi -- nettement plus que la courbe d'apprentissage, imho -- parce que s'il te faut 10 clicks pour passer d'un mode à l'autre, tu vas faire la faignasse et le level design s'en ressent.

Dans le cas où faire une édition complète du niveau pendant qu'on joue n'est pas envisageable (dur pour un tile-based, par exemple, ou si tu as un moteur de jeu qui demande un pre-processing un peu conséquent du niveau comme les quadtrees), permettre au moins de "scribouiller" des modifications (à la "Lapinou Jumps" ?) à faire dans le niveau fera gagner énormément de temps au niveau du testing.

[t4ils]

Ma définition de l'arrache, c'est un éditeur pas pensé pour une utilisation publique
Le fonctionnement est obscure et compréhensible seulement par le créateur
Aucun check de problème de level design qui va bloquer dans le code n'est fait, sachant que je fais les niveaux moi même donc je sais ce que je dois éviter.

Sinon mes éditeurs de niveaux sont inspirés de trackmania, à savoir t'appuies sur une touche et tu test direct (pas de temps réel, mais du semi réel on va dire)
Ça permet de voir si tout se goupille bien, tester la faisabilité d'un saut rapidement, des trucs du genre

Tiens, ça me fait pensé du coup à ajouter une fonctionnalité de test de niveau à l'emplacement de la souris, ainsi pas besoin de déplacer le spawn pour tester une portion du niveau