Sunday, June 25, 2017

rules.gam

Plus proche de nous, mais en partie lié avec ce nouveau projet "behaviour editor",il y a le besoin de pouvoir utiliser un seul même fichier pour définir certains morceaux des scripts qui décrivent les niveaux. Ce n'était pas trop un soucis avec Apple Assault, un jeu dont les "règles" était assez simples, mais qui devient plus pénible à gérer avec School Rush.

Un niveau de School Rush décrit plusieurs types de choses: des resources (map, planches de sprites), des personnages (à travers les fichiers .cmd de comportement à charger), les positions et paramètres des personnages (définis par l'éditeur de niveau) et ce que j'appelle "les règles du jeu": réactions quand un compteur arrive à zéro, valeur initiale des compteurs (p.ex. le nombre de point de vie restant pour le joueur) et les propriétés des blocs spéciaux.

Pour l'instant, ces règles sont répétées à chaque niveau, et plus le projet avance, plus le risque augmente d'avoir un niveau ou p.ex. il est impossible de reprendre de la vie parce qu'il y a un bug dans les règles dans ce niveau-là.

Et le nombre d'animations pour les bonus augmente encore la pression sur ce point chatouilleux.

Extraire tout ça en un fichier qui serait "importé" par chaque niveau devrait être possible sans trop de difficultés, de la même façon que les machines d'états ne sont décrites qu'une seule fois et importées dans les niveaux où on a besoin d'elles. Par contre, pour pouvoir continuer à utiliser les indices graphiques dans l'éditeur de fichier, il faut qu'il sache qu'il doit y chercher les descriptions des blocs spéciaux.

Cela dit, en refaisant un peu d'exploration dans les sources de LEDS, j'ai noté que c'est simplement sur base de l'extension de fichier (.spr, .map, .cmd) que le code destiné à charger le niveau décide de ce qu'il va faire de chaque "fichier supplémentaire renseigné par le script du niveau). On devrait donc pouvoir utiliser un autre type d'extension (.gam ?) pour que l'éditeur de niveau s'y retrouve. Tout simplement.



1 comment:

PypeBros said...

Block est à la fois la classe de base, et un conteneur singleton (via les fonctions static).

Dans un autre design au bureau, j'ai gardé des fonctions static de XXX pour manipuler "l'ensemble des XXX", mais dans le fichier d'implémentation, j'ai un objet YYY séparé, instancié en un exemplaire, et les fonctions static XXX::%() sont en réalité des trampolines vers YYY::%(). Je trouve que ça fait plus propre. Et ça permet (si on répartit bien les fonctions) d'offrir si nécessaire une implémentation différente de YYY (pour des tests, p.ex.)