DaFool wrote:
Next topic, I have finished defining the squares for my biggest battle map, and I notice a slowdown when the characters are walking... as if the engine "stops and thinks" everytime the character nudges to the adjacent square. It's not really so much of a problem but it's no longer a smooth walking animation when the character slows down and speeds up like that. I'm thinking it's because I have a lot of areas which are only 1-2 squares wide or otherwise unpassable if there's another character blocking the way.
I doubt it, because all the calculations as to which path to take are done before the character starts moving at all; it's more likely to be a thing I introduced when I did animation-state-transitions in an attempt to be cleverer than they perhaps need to be; it's something I've been looking into myself recently as well. Try commenting out the two transition calls in engine-display.rpy on lines 207 and 220 (approx.) and see if that helps.
(I'll try to mitigate the slowdown between steps before removing them entirely - for example, I'm not checking in that method whether the fighter is already in the state it's being told to change to - which I really should - meaning that steps taken in a straight line still have those transition gaps between them...)
DaFool wrote:
Are destructible scenery elements implemented yet?
Not yet, no - I've been getting some of the big-ticket items (like hex maps) out of the way first.
I'm also still considering how best to go about stuff like that - the simplest answer is just to have the scenery behave very much like a regular Fighter, so they have X Health and once that health is gone, they're destroyed and no longer block LoS/movement. But as you've suggested, there are lots more semi-common cases that it would be nice to take into account.
I'm thinking it's probably best done as a multi-state Fighter, so the game-designer can set the multi-state Fighter up to look at a particular stat (in this case, and probably the default, Health) and then say "for health between 100 and 50, use this Fighter instance; for health between 50 and 0, use this instance; for health below 0, use this other instance" and each of those instances can be entirely different; different sprites, different behaviours, etc. Like that, one could create a "Sci-Fi Defence Shield" Scenery item which blocks move but not LoS when it's undamaged, goes opaque and blocks both when it's damaged, and then smokes a lot and blocks LoS but not move when it's destroyed.
The other benefit to this kind of approach is that the same multi-state Fighter can be used to create those stereotypical multi-stage bosses, where their attacks get more powerful as they get low on health. ;-)
DaFool wrote:
Is there a 'RemoveScenery' function defined somewhere that I haven't seen yet? I noticed when I was using RemoveRect and RemoveSpace that the squares removed this way will permanently remove LoS in the battle map. So those two methods only work on the fringes of my map, but not in the middle since I still require LoS. Besides, I can only define them prior to battle.
Actually, there's no caching of paths or LoS in the engine, so you should be able to use those methods during battle as well, it's just trickier 'cause you might have people standing in the squares that get removed, or even pre-calced paths if for some reason you do it after having looked up a move/LoS and before having used it.
DaFool wrote:
Since my map consists of ravines and destroyable bridges, I defined my ravines as empty Scenery (using "empty.png"), with BlocksPosition=True and LoS=True so that units can fire at each other across the gaps but cannot jump nor walk across if there's no bridge. It would be nice if I can just pass a 'None' or an empty displayable to the AddScenery function.
On one hand, I'd hope you could - I was sure I'd added code to cope with that a while back. Is it not working for you? I'll add it to my list to look into...
On the other hand, I'm intending to make a richer set of map-editing commands once I add position-properties (stuff like "it takes you X MP to move through this marshy square" and so on); when I do that, I'll also add blocks-LoS and blocks-Move to positions, so that (for example) you can have a no-LoS square you can walk through (dense greenery?) and a no-Move square you can see through (like your ravines) without having to define Scenery for it. I guess my goal is to make it such that you only need Scenery for things-which-might-change-easily (e.g. destroyable fences) and things-which-need-a-sprite.
DaFool wrote:
Each bridge is where I have a hard time defining. It is an inverse destroyable unit (meaning, when destroyed, BlocksPosition will go from False to True, not vice versa). So maybe that's something to consider in implementing destroyable scenery.
It's on my list!
DaFool wrote:
Another thing is that I want the scenery to cooperate with dummy enemy units.
Well - if you have destroyable bridges which block movement when they're killed, this will all play well with the regular functions to check movement and LoS paths, so presuming your hypothetical enemy is going to check for movement the same way existing Fighters do, then it should Just Work.
As to destroying bridge supports underneath it, I guess that's up to the Scenery itself; I'll bear this kind of case in mind when I get to the Scenery stuff; I'm vaguely thinking of a behaviour function similar to Items and Skills - maybe literally Skills, even - which can be assigned to various things like 'when this Fighter dies', which could be used for (for example) killing everything on a Bridge scenery when it gets destroyed.
DaFool wrote:
How about when scenery is repairable? Will it work similar to the Resurrection function?
Actually, making sure that Scenery doesn't behave exactly like dead fighters and allow things like Resurrection spells and healing potions to be used on it is one of the challenges of damageable scenery! Certainly I intend to make it possible to have 'repair scenery' skills, but it might just come down to healing skills which have a different effect based on target attributes - after all, it might be that you also want to have a Druid character who can re-grow damaged trees and bushes but can't do anything with man-made things like walls or bridges!
DaFool wrote:
How does one implement sequential mission objectives? Should I just create all the WinConditions and add them all as extras in one go, each with a priority rating? Or should I just define one WinCondition at a time, then restart the battle based on the last turn positions but with the subsequent WinCondition?
At the moment, this is really left entirely as an exercise for the reader - I've got a long-term ToDo item of "make more varied win conditions", but I've not put much thought into it, really. If you have any suggestions, then suggest away, and if it's holding you up in any way then let me know and I can re-prioritise it.
But yes - generally, I would expect win conditions of any sort to be added as an Extra. If you want to have a set which are literally sequential, then I would expect you'd probably just want to have one Extra, maybe with a set of subordinate classes of its own, so the class can control which objective is currently 'active'?