Level Editor vs new engine

Mes cogitations pour rénover la gestion des maps dans mon moteur DS commence à porter ses fruits, au point que je peux commencer à réfléchir à l'impact que ça aura sur l'éditeur de niveaux. ça me tient à coeur parce qu'avec le système actuel, je ne vois de bonne solution pour réaliser les cours d'eau souterrains que mon frère avait mis dans les niveaux historiques de la Grande Aventure.

Je me dirige vers un système avec uniquement un byte par tile de 8x8 pixels, et quatre grande classes de blocs:
- les morceaux de blocs interactifs, provoquant des collisions auxquelles le personnage doit réagir (pics, bloc-question, bonus, portes ...)
- les zones non-solides mais succeptibles d'affecter le comportement de certains morceaux de code (eau, échelles, courant d'air ...), dites "medium"
- les blocs de "sol" (solides) qui encodent la forme des pentes
- les blocs solides qui encodent les propriétés physiques (friction, déplacement forcé, etc.)

With about 2 more months to think about a better tiled engine, I start having fewer questions and more plans. I'll migrate away from 4-bit-palette being used as tile type and opt for an 8-bit type information per 8x8 tile. I'd have fewer (64 instead of 256) unique codes for "special/interactive" blocks, but the code to handle them would scale to 24x24 or 32x32 pixels blocks easily. I would have 64 different slope-type identifiers and it would be much easier to write the slope-handling code than initially planned.

And to make sure I have required flexibility, I'll split physics-hinting tiles from slope-angle-tiles. Some part of the code will read the pixel immediately under the character's feet and find the angle, while other part of the code will read past the slope and figure out whether we're on ice, solid ground or mud.

ça signifie que la petite palette de blocs utilisée dans LEDS va devenir plus complexe, avec un bouton "montrer les autres options", et que je pourrais bien en avoir trois tranches plutôt qu'une seule pour éviter les opérations de navigation fastidieuses.

ça signifie aussi que c'en est fini de l'encodage de petits "0" et "2" dans la map pour former un code entre 1 et 256 en base 4: l'éditeur de niveau ne pourra plus proposer que les blocs qui auront été décrits, ce qui devrait au passage rendre les choses plus lisibles et plus faciles pour des gens qui auraient envie d'utiliser LEDS pour leur propres projets (on peut rêver, non?)

LEDS will have to adapt this, of course. I won't have to enter digits and cross fingers with hope I remember correctly the codes for a bumper or a spike. The editor will have to know them, now. And it will have to be able to set 'medium' flags individually or pick appropriate slope types. I don't know yet how I'll handle all that.

Autre truc intéressant: puisque l'information concernant un bloc spécial (mettons des briques cassables) n'est plus encodée que sur 1 tile, je vais avoir besoin de tiles qui disent "suite du bloc, cf. à droite" ou "suite du bloc, cf. en haut", etc. Chose qui devrait être plus simple à étendre à des blocs interactifs de 24x24 ou 32x32 si le besoin s'en fait sentir...