Finishing Blades of Rogue
I've decided to make a push to finish my BoA scenario 'Blades of Rogue' this week. I've not worked on it for several months because of the bug which Windows testers reported which I could not reproduce on my own Windows system, and which doubt I could fix if I could see. I've decided to ignore that and get the thing finished.
The basic idea was one that a number of people had suggested before: To use BoA to dynamically generate an environment at run time. However the game has some major limitations which make this quite tricky. The esteemed Arancaytar made the first serious start at building such a scenario last summer and was making good progress. I was inspired by his work, thought I might be able to offer some improvements, and so when he got busy with other things and let it languish I stepped up my own work seriously.
The main problem is that Avernumscript refuses to execute more than 8000 consecutive instructions at a time, as it decides that any script which tries to do more must contain an infinite loop1. This is fine for simple AI scripts and the like, but no good for a scitp which must make repeated passes over a two dimensional array of several thousand items, as this is exactly what the floor and terrain grids used by the game are.
Aran's method was to exploit that the stament limit is on a per script state2 and the game ececutes several different states in a certain order when the starting up; namely the scenario LOAD_SCEN_STATE, town INIT_STATE, and town START_STATE. He was doing his computation in these and using the 'Stuff Done Flag'(SDF)3 matrix. Aran later began employing the town's START_STATE to launch a new step of the calculation each turn of the game. Lazarus suggested launching the code from terrain scripts' INIT_STATEs, which is not very practical in and of itself as the order in which the scripts initialize is not guaranteed (although I bet they just go in the order they were placed in the editor); however, by having the initalizing scripts call a launcher state in the town script which uses an SDF to keep track to which steps should be executed and do them in order.
I just have to note that it was at this point that Terrors Martyr provided useless instructions without regard for technical problems. I think I could actually do most of what he specified based on what I know now, but I'm doubtful that anyone, most of all he could have done it at the time.
I'm rather proud of my own solution as it stands; by using Aran's and Laz' ideas I was able to generate each level in a single turn in place (using only the town grids themselves to store the terrains and floors). Tedious optimization of the wall, item, and creature definitions made the code for placing them compact enough to be feasible, although some of it I optimized and did not comment tot he point that I ended up having to run a simulation to figure out again exactly what it did. Some finishing touches like adding traps, teaching the player's characetr new spells during the course of the game and providing means to identify artifacts have gotten it to the point that I now enjoy playing it fairly well. I'm hoping to finish upa few new features, do some testing, and ship it this coming weekend.
-
Not a bad assumption when the only type of loop supported is
whilewhen most of the time sripters wish they could usefor. Forgetting to increment the loop variable is a very common source of dumb errors. ↩ -
States in Avernumscript are like functions, but not. They might be called procedures according to some systems; they're just snippets of statements that get run together. One state can jump to the start of another, but they can't return values, there is no call stack, and they can have no local variables. ↩
-
SDFs are the game's persistant memory which is recorded in the player's savefile. Useful for things like tracking which rewards the party has gotten, which dialogue options have been explored, which traps set off, and so on. ↩