This is something I've been ignoring for the moment, on the grounds that - as you say - it adds complexity. My original thought was that height could be fudged in a lot of cases by having carefully-positioned nodes (thinking along the lines of the path-based engine demo I put up a while back) which you can enter from one direction but cannot leave in that direction, but while it's workable in the confines of my original plan for that engine, it's not really a good universal solution.blakjak wrote: Can the tiles support height data ? Like having a battlefield with stairs, terraces ? My guess is this would add a lot of complexity to an already complex engine, right ?
I'm thinking of adding attributes to positions (e.g. grid squares, path nodes) which affect the way fighters interact with them, so 'height' might make an appearance there, but I couldn't promise anything. Certainly I doubt very much this engine will ever support - for example - UFO-style height layers where one fighter could stand directly above another.
As of right now: no. I've had a couple of ideas since reading the question, though, and I'm thinking that at the very least, a half-way solution (multi-tile occupancy, but still checking for walkable paths and so on as if the fighter were a single tile wide) should be quite possible. Maybe even full support for multi-tile fighters, but I wouldn't want to promise anything.blakjak wrote: Can a character sprite occupy several tiles ? Like a giant or a dragon that would occupy 4 or six tiles and would thus prevent other combattants from being able to walk on them ?
(This also opens up questions like "how much of a fighter would you have to see to claim LoS to that fighter", or "should a multi-tile attack effect which covers three tiles of a multi-tile fighter perform the attack once, three times, or one time with higher strength?"... there are game-rules considerations as well as technical ones.)
Realistically, it's left up to whoever writes the Skill class which powers the attack. It would be possible to write both. Personally, I'd be inclined to damage friendlies with area attacks, so if/when I write an example of such an attack I'll probably do it that way, but it's not a restriction.blakjak wrote: In the case of grenade-like spells or weapons that affect multiple tiles, could the player inflict friendly dammage ? Is that just an option for the game maker to customize ?
Mm... I'm also reaching the point where I'm thinking it might be useful to double everything up (again!) to allow for including or not including friendlies on the target list (e.g. you might not want to include friendlies for an 'attack' skill, but you may want to be able to target friendlies or enemies for a "change element to fire" skill). I'm wondering whether a TargetData class or something which just gets constructed with various parameters depending on what options you want might be easier, something like:blakjak wrote: Just an idea,
n - doesn't need a target
sl - targets a single fighter, requires Line-of-sight
p - targets a position, doesn't require LoS
s - targets a single fighter, doesn't require LoS
pl - targets a position, requires LoS
f - targets a whole faction
Code: Select all
targets = TargetData(fighters=True, los=True, friendlies=False)