Lemma Soft Forums

I'd like to report that using alwaysMove=False for the enemies dramatically shortens their response time, so the issue is indeed with the Move calculations. However, this makes the enemies passive... when equipped with the Skip() skill, they prefer to use that instead. Might be useful for a heavily defended / infiltration mission, though.

Presumably because most of their other skills aren't in range!

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.

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:

• 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
• compare total for each square, pick 'best' one to move to

So the time taken will increase as the move range of the AI fighter increases, and will increase exponentially as the number of player fighters or the distance between the enemy and the player fighters increases. On the other hand, it should be relatively easy to write a more-efficient algorithm for range-finding, so hopefully it'll be a fairly quick fix once I get to it. ;-)

_________________

Yep I had a 5 vs 2 battle just to test things out. I was getting a bit worried because my ultimate aim is something like 10 vs 15 battle, and I don't want each enemy unit's turn to take 1 whole minute at the current rate.

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.

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 [U]... 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 [U], [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).

_________________

DaFool: Try replacing the engine-battlefields.rpy in your game folder with the attached version. I've not optimised it as much as I can, but I reproduced your problem and just implementing a more-appropriate range-finding algorithm for square- or hex-grid battlefields (replacing the previous look-in-all-directions-and-count-the-squares approach with a simple geometric approach) reduces the wait time in my test scenario from 30+ seconds to unnoticeable, so hopefully this'll be good as a stopgap until the next release is ready.

_________________

Ah, many thanks. Combined with shortened pauses (I practically halved most of the timings), the battles are now fast-paced and (dare I say), fun. I did notice an instance where the auto-panner panned away to another point of interest even before a caster finished a spell so I ended up retiming the casting session to be much shorter. In any case, faster is better!

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.

Is it possible to have an iso hex grid for diagonal movement ? I'm asking because I didn't see it in alpha 5 but i don't see why it wouldn't be possible. Or is it just a regular iso square grid with diagonal movement enabled and a skewed hex grid drawn on top ?

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?

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.

_________________

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.

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 =D


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.

Actually I found a quick way of doing it by simply drawing skewed octogons on top of a square battle grid with diagonal move enabled. ^ ^;

Huh yeah, because I was speaking of hexes but actually I wanted octogons, so much for not listening in math class...

I apologize for dragging this thread from the depths of the graveyard, but is there any news on a potential update?

_________________
Visit my game development group's Facebook page : Timekeeper Games
Mutagen : Journey to Haven's Landing Facebook Page
Follow our Twitter feed too : TK Games

There is, you can subscribe to a dedicated newsletter there :

http://www.eviscerate.net/newsletter/subscriptions