Presumably because most of their other skills aren't in range!DaFool wrote:However, this makes the enemies passive... when equipped with the Skip() skill, they prefer to use that instead.
I'll have a look at optimising some of the movement stuff - or rather, the base functions which the movement code uses an awful lot - next, once I've got the XP code more or less working. Am I going to see the same slowdowns as you if I just make myself a big 20x20 square battlefield and place - say - five fighters in two factions, or do I need more than that? What kind of move distances do your AI fighters have?
It's not the number of fighters on the battlefield, since even with just 2 enemies each enemy took its sweet time (unless alwaysMove=False). The factions were just on two opposite ends of the map, with some passageways only 1-person wide. My fighters have movement ranges of 6-8.Am I going to see the same slowdowns as you if I just make myself a big 20x20 square battlefield and place - say - five fighters in two factions, or do I need more than that? What kind of move distances do your AI fighters have?
It's not the number of people on the enemy side which would increase the times, it's the number of people on the other (player) faction. Basically, the algorithm for movement works something like this:DaFool wrote: It's not the number of fighters on the battlefield, since even with just 2 enemies each enemy took its sweet time
- Find spaces within range (inefficient, takes longer than it should, takes longer for longer ranges)
- For each space:
- For each enemy:
- Find range between enemy and this space (inefficient, takes longer than it should, takes longer for longer ranges)
- Compare range to 'ideal' ranges and come up with desirability rating
- Add rating to running total
- combine each enemy's total into total for square
- For each enemy:
- compare total for each square, pick 'best' one to move to
I'm considering adding diagonal modes (diagonal = True) since I already have the set of sprites... the question is if this will increase the calculation times without really adding much to the tactical aspect? It's only purpose is for a more natural path rather than the zig-zagging that is currently occuring. The downside is that I'm also considering adding a Rotate command to the end of the Move command so that the character can choose to reorient the facing direction. (With an Attack command of course the character has to turn to face the target) The damage is greater when you're attacking someone's back and less when you're facing the enemy unit (Can even add a probability for the enemy to counterattack). I'd prefer that over a standard Defend command.
Right now, it'll probably increase calculation times. In the long run, once I've finished optimising the path/range-finding algorithm, it shouldn't so much.DaFool wrote: I'm considering adding diagonal modes (diagonal = True) since I already have the set of sprites... the question is if this will increase the calculation times without really adding much to the tactical aspect? It's only purpose is for a more natural path rather than the zig-zagging that is currently occuring.
Basically, the first implementation of the path/range-finding algorithm is a ridiculous depth-first search which makes no sense and I honestly can't even remember why I wrote it like that. So currently there's every chance it'll explore a path which goes [L, L, L, U, R, R, R] before it explores a path which goes ... I think you can see where that's going. A breadth-first search makes a lot more sense for this kind of thing - the first paths it explores will be , [D], [L] and [R], then [U, L], [U, U], [U, R], [L U], [L, L]... and so on. Hopefully I'll have a bit of time to get to this over the weekend - work's been busy lately, so I've not had so much of my usual lunchtime coding time.
(Of course, if you want natural-looking paths, you should really use hexes! :3)
As to rotate - I'd certainly agree it makes sense, but you'll probably need to modify the AI a bit to get it to use it intelligently, if you want that to happen (not that there haven't been successful and fun games where the AI doesn't make intelligent use of facing at all, mind).
- Slightly fixed-up engine-battlefields.rpy
- (45.13 KiB) Downloaded 32 times
I've been meaning to ask, how do you get an incapacitated state? It should be a simple question but the only reference I remember is when using the Resurrect skill and that was for an invisible fighter. I change a fighter's image set to 'dying' but blocksposition seems to be false and other characters can step on it, then its graphic disappears of course since it's occupying the same display layer even without the Hide function. I see in other places that you've declared states dead=True and even Corpses but I can't find where these parameters are put to full use. Ideally I want to be able to have some form of temporary death/incapacitated function that changes the fighter into a scenery element (e.g. a frozen statue) until it is resurrected (Or perhaps even call forth new allies from the scenery as reinforcements, such as zombies.)
I'm also not sure how to turn a Player into AI and vice-versa without changing Factions, such as for the situation when a character becomes out of control. There are two different ways to register the skills for a Player-controlled character versus an AI-controlled character, so I don't know how to go about that save for actually declaring two different fighters and having one switch over the other when the moment is right.
As in, the same offset-in-y-per-increase-in-x and offset-in-x-per-increase-in-y modifiers that the grid has to allow you to do iso versions?blakjak wrote:Is it possible to have an iso hex grid for diagonal movement ?
It's certainly possible - I left it out for two reasons, and neither of them are particularly good ones! ;-)
- I couldn't be bothered to work out exactly how to skew the grid image to get the hexagons to line up properly with the battlepositions
- I figured that really, since hexagons offer a pretty good uniformity of movement distance in each direction, it wouldn't really matter what the scenery looked like underneath them (unlike with a square grid) you could probably get away with using the one orientation of hexagons for all hex battlefields.
If it's something you want, it should be easy enough to add those parameters and have them work the same way as for the iso square grids; I'll add it to my to-do list.
Thank you, no rush though I'm still working on my sprites, but it just occured to me that it could look more "natural" to have iso diagonal movement if it's on a hex grid. On a side note, I happen to think it can look very cool too =DIf it's something you want, it should be easy enough to add those parameters and have them work the same way as for the iso square grids; I'll add it to my to-do list.
Thanks. You mean for the airship movement vid right ? I'll have to see if it's also the best mode in case the hex grid is skewed.DaFool wrote:blackjak -> the isometric blend script has two modes: 2:1 isometric and "true" isometric. I use true isometric for square grids and 2:1 isometric for hex grids.
Huh yeah, because I was speaking of hexes but actually I wanted octogons, so much for not listening in math class...
- Posts: 161
- Joined: Tue Feb 15, 2011 8:00 pm
- Projects: Mutagen : Journey to Haven's Landing
Mutagen : Journey to Haven's Landing Facebook Page
Follow our Twitter feed too : TK Games
Users browsing this forum: Bing [Bot]