There was one annoying thing with the scripts while adding n-up was that I had to add the new rules in every level. This is the kind of things that should be written only once, and as far as the script parser is concerned, it could be written once, in the “rules.gam” file. The problem is, this file would be ignored by the level.editor, and thus is not used so far.
And unfortunately, there are some design flaws in the way LEDS’ own parser is written, making any change in that part pretty tricky to do right. It would be nice to refactor that a bit, but such a refactory with no easy way to test things would be errors-prone. My next move must be towards testable LEDs logic.
And I realised my first idea for the tests, with modified readers and all, was over designed. Instead, it would be interesting to have two simple programs that run checks on parsed levels (eg. what are the coordinates of game object #42 , or how to display special block#3) or that do simple changes and then write back the result. Test cases are then simple shell scripts combining calls to those tools and to standard file comparison tools.
What I still need to figure out is how I’ll extract specific information (e.g. what gob another gob links to) out of the full data. And how to compare the extracted data.
Bouli's Homebrew Blog 