Wish list for future versions of BoA

[Ishad Nha]

A wish list for changes to BoA that we won’t be seeing any time soon.

 

For something really different how about line thickness walls? Walls that occur exactly halfway between two squares. This is tricky, the walls would be situated on the lines between squares, not the squares themselves. They would not fill a square, thus leaving it free for terrain. Walls would become a third terrain type along with terrain and floors. Walls would include doors, windows and gates too.

 

If the town is N*N, this approach would require (2*N^2) + 2*N slots per town. Currently BoA town records have sizes of 21,466 or 27,866 or 36,826 bytes. An extra 1,024 or 2,304 or 4,096 bytes won’t make much difference.

 

At one byte per slot that would leave 255 possible types of wall. You could have four types of wall per town. You could also have provision for one – way walls&&.

[Callie]

-It'd be cool if there were item descriptions (non-generic ones I mean) like there were in Exile, customizable ones of course.

 

-I think BoA needs some major touch-ups to the way it handles cutaways. It looks goofy sometimes, and that probably drives some designers to change things around because of it.

 

-This probably wouldn't help much in most instances, but it'd be cool if the limit on items and NPCs in a town was increased

 

-BoA needs a better method to port scenarios, which you've already addressed. Most of the BoE scenario designers aren't around anymore, though.

 

Originally Posted By: Ishad Nha

At one byte per slot that would leave 255 possible types of wall. You could have four types of wall per town. You could also have provision for one – way walls&&.

Extra sets of walls can be solved by custom graphics (which is an even worse idea when you're using a lot of custom graphics). I did that once, but the cutaway didn't work too well, so I used the set for a decorative thingamabob.

[Ishad Nha]

I think even Nethergate: Resurrection has something like custom item descriptions, I see an "it_itemdesc = #" in the corescendat2 file.

 

Cutaways just don't have it visually.

 

Maybe have the number of fields, items and monsters vary according to the need for them, currently they have a fixed number occuring whether or not they are used. Even if you don't often need to exceed the limit it is nice to know that you can do it if you need to.

 

While we are at it, the Avernum games 1 thru 3 had custom terrain slots for each town, ditto the Exile ones. For some reason this feature didn't make it into BoE or BoA. The idea was that each town had 16 custom terrain slots, if you only needed a terrain type for one town it only needed to occur in one town. Terrain slots are finite in number.

[Niemand]

Quote:

While we are at it, the Avernum games 1 thru 3 had custom terrain slots for each town, ditto the Exile ones. For some reason this feature didn't make it into BoE or BoA. The idea was that each town had 16 custom terrain slots, if you only needed a terrain type for one town it only needed to occur in one town. Terrain slots are finite in number.

As I've pointed out before, there may be finite limitations, but they could be very easily raised to unreachably huge levels. It would be far more practical to remove the artificial 512 terrain limit in favor of using terrain numbers at least up to 32000. (After all terrain numbers are already using 3 bytes, and actually taking up 4, so why not use all of all 4 bytes?) This approach would both give designers far more flexibility and, I think, would be a far easier change to make to the game engine.

A similar approach could be used to expand the numbers of creatures and items in a town, although this would mean extensive changes to the scenario and savefile format, as the per-town data chunk would no longer be constant (or one of three constants) length. This is by no means an insurmountable problem.

I'm curious to know, what is it you two dislike so about cutscenes? Aside from a few minor issues I can think of, like not being able to display missile animations, the cutscene system pretty much offers you the full power of the game engine to do whatever you want. What's still missing?

As to the changes I'd like to see:
-Use PNG graphics for all images. I'm assuming that on both platforms the OS gives the programmer libraries to handle these (I know Mac OS does), and this would give easy access to millions of colors and partial transparency as desired.
-Allow items to call back to script states on striking a foe (arrows, swords, etc.) or on the wearer being struck (armor, rings, etc. )
-(Maybe) Allow items carried between scenarios to carry necessary snippets of script with them, provided certain constraints are met. For instance, the code would be required to access no SDFs. (I'm not sure if this could work, and it would certainly be a bit complicated, but would be simply awesome. I'll have to think about it some more.)
-Avernumscript needs more thorough calls to read and in some cases write variables. For example I want to be able to read elemental immunities by creature type, find out what direction a creature is facing, find out the party's location in the outdoors, and clear the automap for a town. All of these examples should be trivial to implement.
-Allow true custom spells, with multiple targets. This could be as simple as adding space for for spell buttons at the bottom of each of the spell selection dialogs, calls very similar to those for defining custom abilities, and a mechanism so that when a multi-target custom spell is cast, the relevant script state is called once for each target. Ideally it should be possible to define how many targets each custom spell has at each level, this could be done by requiring it to be a linear function and allowing the designer to specify the slope and intercept. (If you wanted to keep all arithmetic integer in script and require that spells can only gain targets with increasing levels, let negative slopes be converted from additive inverses to multiplicative inverses for spells to take more than one level to gain a target.
-Fix behavior of NPCs attached to the party so that they really run their creature script normally.

[Xaiya]

A better error detection thing. Seriously. The current one sucks.

[Ishad Nha]

By "cutaway" I meant the cutaway view of terrain, not cutscenes. This sometimes looks pathetic, a totally impassable gate becomes a handful of bars sticking out of the ground. (I don't know what Excalibur meant.)

Avernumscript just does not have it. If you really know C well then you can't use that knowledge in BoA.

 

For every variable in the programme need at least three calls: "get_variable", "set_variable" and "alter_variable". Here "set" would decree a new absolute value while "alter" would vary the existing value by the given amount (+2, -3&). By variable in the game I mean things like town visibility, creature attitude, distance to location, current time &&&

[Niemand]

Your last point there is similar to what I was getting at with my 4th point above. However, I would point out that your 'alter' prefixed commands would be unnecessary and would create far more work (to add) and confusion (to use). Also, it's far more important to have accessor functions than mutators, although having both would be preferable. (Some things probably don't need to change at runtime. I would dearly love to know what creature type X's immunity to fire is, but I doubt I would ever want to change it.)

 

As to pointing out the shortcomings of Avernumscript compared to C, I think this is something to not go overboard making demands about. There are some aspects that are much tougher than others to implement, and there appear to be very few good ways to expand Avernumscript's current interpreter. I've been tinkering for several months with my own interpreter implementation, and I assure you that it's a great deal of work to do right. For one thing, an interpreter built to be used in a game engine must be bullet-proof; there should be no way to write a script that can crash the game. Trying to stick to this requirement makes many of the features of C, like arrays and pointers, range from highly nontrivial to impossible. (Arrays are a lot of work. I'm currently considering pointers impossible.)

[Dahak]

Originally Posted By: Niemand

-(Maybe) Allow items carried between scenarios to carry necessary snippets of script with them, provided certain constraints are met. For instance, the code would be required to access no SDFs. (I'm not sure if this could work, and it would certainly be a bit complicated, but would be simply awesome. I'll have to think about it some more.)

At the very least if I make 2 identical items in 2 scenarios then I want the engine to recognize them as the same item.

Originally Posted By: Niemand

-Fix behavior of NPCs attached to the party so that they really run their creature script normally.

There is a semi-fix for this. Won't work outdoors, but it can allow creatures to run normally indoors. Still, it would be nice for Jeff to fix this anyways.

[Ishad Nha]

Currently a wall segment blocks the entire square to other terrains. I was thinking about having walls lie on lines between squares so the squares would not be blocked to other terrain types. This requires that they be a third terrain type along with floors and terrain. Unless a new call is created: is_wall().

 

I don't know if BoA uses arrays and pointers. If it does not then that is one less problem.

[Niemand]

Yes, all terrain and similar data are stored in C arrays. I don't exactly see how this is considered to be a problem, or what exactly your proposed is_wall() function would do.

 

More to the point, I think that this idea is simply too drastic change for the engine; while it might have been nice if the engine had been designed for this in the first place, but it wasn't, and we can live without it.

 

EDIT: Dahak, I'm aware of the NPC fix you refer to, and it is a very fine piece of scripting. A fix to the game engine would ultimately be very ice to have, however.

 

As to identical items, this could be handled fairly well, I think, by checking a party's items on entry to a scenario and for each item either marking it as an external custom item type, or by replacing it with the local type to which it is identical, with identity being measured with a simple comparison of all traits other than type number. Definitions of external custom items should be stored in a specially numbered set of definitions, kept in the savefile. (A party can only carry a maximum of 160 unique items, and will probably have far fewer, so the table would be small.) That way, a designer could manipulate the party's items without fear of destroying artifacts from other scenarios, although not necessarily knowing what the item types being manipulated were. This last could be addressed with better accessor functions, such as get_it_variety(int item_type) which could be used to allow a script to differentiate between, say potions and non-potions, even including items not native to the scenario.

[Thralni]

Originally Posted By: Ishad Nha

Currently a wall segment blocks the entire square to other terrains. I was thinking about having walls lie on lines between squares so the squares would not be blocked to other terrain types. This requires that they be a third terrain type along with floors and terrain. Unless a new call is created: is_wall().

I don't know if BoA uses arrays and pointers. If it does not then that is one less problem.

This can be very easily by-passed: import the wall as a new terrain number in your scenario's datascript, and use te_second_icon to place another icon over it. That way you can "place" terrain on spaces with walls. Ephesos does it in Shades of Gray, and I'm doing it in TNS/ Except that it takes up some terrain slots, it *does* work well.

[Enraged Slith]

I'd like a little cheer + stat screen (total time, # towns, etc.) to appear whenever you finish a scenario.

[Dahak]

I wish Jeff would bring back the old floor height adjustment where the actual displayed height of the floor actually changed rather than just the party height.

[Celtic Minstrel]

Originally Posted By: Dahak

I wish Jeff would bring back the old floor height adjustment where the actual displayed height of the floor actually changed rather than just the party height.

Huh?