DaFool wrote:Jake, will diagonals be allowed in the future version? It will feel more natural than walking in a zig-zag fashion, but I'm guessing the path-finding must be more difficult.
Diagonals are already allowed, and since I use a very generic graph for my pathfinding rather than having written an algorithm specifically for a squared grid, it's no harder or less hard with them enabled. Just take a look at grid_demo.rpy - pass "diagonals=True" instead of "diagonals=False" when constructing the GridBattlefield and it'll allow movement across the diagonals. Presently it costs exactly the same to move left one square as it costs to move diagonally up and left one square, because I've not introduced any kind of movement costing yet, but when that does come along I'll also include an optional 'diagonal cost' parameter that allows you to choose how much extra it costs (if anything) to move diagonally.
(I turned diagonals off for the demo just because I liked having quite a few MP for play-around testing and giving people 5MP on such a small map
and allowing diagonals basically meant "pick where you want to stand". I realised when I did it that a lot of my favourite tactics games don't actually allow diagonal movement anyway. ;-)
Just bear in mind that if you want to use facings, the default for a grid is N, S, E and W; you'll need to pass your new facings into the GridBattlefield constructor as well, in a dictionary mapping a string facing name to a tuple with the start and end of the arc that facing describes.
The default for GridBattlefield is this:
Code: Select all
facings={'N':(-45, 45), 'E': (45, 135), 'S':(135, 225), 'W':(225, 315)}
but if you wanted eight-way facings, you'd probably want to pass in something more like this:
Code: Select all
facings={'N' :(-22.5, 22.5),'NE' :(22.5, 67.5),'E' :(67.5, 112.5),'SE' :(112.5, 157.5),'S' :(157.5, 202.5),'SW' :(202.5, 247.5),'W' :(247.5, 292.5),'NW' :(292.5, 337.5)}
You can see a practical example if you change line 191 of grid_demo (in alpha 2) to read as follows:
Code: Select all
battlefield = GridBattlefield(fieldSprite, origin=(362, 441), gridSize=(6,5), spaceSize=(75, -38), offsets=(-75, -38), diagonals=True, facings={'N' :(-22.5, 22.5),'NE' :(22.5, 67.5),'E' :(67.5, 112.5),'SE' :(112.5, 157.5),'S' :(157.5, 202.5),'SW' :(202.5, 247.5),'W' :(247.5, 292.5),'NW' :(292.5, 337.5)})
DaFool wrote:
Also, it's neat that you were able to cut down the walkcycle to 6 frames. I tried that also and the result wasn't too bad. I started off with frames 1-15 (the 16th frame is the same as frame1) and ideally would cut down to frames 1-7(8th frame same as first), but with an odd number of frames it must not divide evenly when calculating the speed that the animation should slide around.
I'm not sure what you mean 'divide evenly'... there's no requirement to use whole numbers or clean fractions at any point, so it hardly matters anyway. An 8-frame walkcycle would look a lot smoother - you could fit all the important key positions in - so hopefully you shouldn't have any trouble fitting it in; I went with six 'cause I'd animated it before and because I didn't want to spend too long on it when I could be doing more-useful coding.
(You've probably seen it before, but here's a pretty good walkcycle tutorial with an eight-frame basis:
http://www.idleworm.com/how/anm/02w/walk1.shtml
If you're really interested in animating by hand, I'd also recommend "The Animator's Survival Kit":
http://www.amazon.co.uk/Animators-Survi ... 977&sr=8-2 )
DaFool wrote:
W and S can flip to each other (provided that the pose is symmetrical) and N and E can flip to each other as well, so one only needs to animate two walkcycles
Indeed. Well, in non-iso you can still flip N/S for a starting point, it's just that you need to draw over it all still. But realistically, this only helps with animation 'cause once you start shading, even before giving the guys weapons or whatever, it's going to start looking odd.
jack_norton wrote:Once you add hex-grid and renpy 6.11 support (once reaches stable build) I'll be really interested in using it :)
Both of those things are definitely on my to-do list! Realistically, it runs fine under 6.11 already, it's just that there are some things that I could do witih 6.11 - like panning - which I've not implemented specifically because 6.11 doesn't seem stable enough to require it yet.
Hex grids are a little more tricky, I've got to figure out how best to do the algorithm to find LoS for a hex grid, and I'd also like to re-do the LoS and pathfinding and so on using more of a Visitor approach, so I (and other customisation programmers) can more-easily use the same methods for stuff like radius-effect, target-finding and so on.