Lemma Soft Forums

Ah , yes that's true.


Yay for uniform sprites ! =P

But yep, I feel your pain, it's real work making these.

I missed that edit, it's really great news !

I'm just linking to this small software, because it's relevent to the issue of making spritesheets from different images =)

Good thing is it creates a .txt file with the name of the original sprites and their position, so one can map them easily with Filmstrip.animation in Renpy.

http://spritesheetpacker.codeplex.com/

Given how frustrating it's been over the last couple of days, I'm pretty happy with it myself!

The good news is that after half an hour of my lunch break, I've pretty much finished. The bad news is that it seems to exacerbate the Ren'Py crash which DaFool mentioned on the Mac; I just have to start the game, pan left once and then go to close it, and the error occurs. I'm still pretty sure it's a problem with the implementation of either Ren'Py or (more likely) Python on OSX, so I'm interested to see what happens in 6.11.

(Thanks for the spritesheet link, I'll have a look later!)

_________________

And that is why almost everyone ends up with tanks for their first tactics games, they're the easiest to draw!!!

Actually, Jake, if it makes life a little easier, I'm only planning to really use panning for the World Map (which is a top-down battlemap without any enemies and movement costs set to infinity). I already have all my battle music composed, and 8 of about a dozen total machines modelled and textured in Blender. I could probably easily do isometric using that link blakjak gave, but as you mentioned it's best to cycle in simple stages so right now I'd be most happy with working top-down battles. There is nothing really in my tactics that requires the use of isometric perspective, so to me isometric is when I want to work extra hard for the art assets (like a 3D game). I happen to use 3D since it's surprisingly a timesaver when modelling mechanical objects and fractal-generated landscapes. For now I'm going to be a total minimalist and just have bobbing, bouncing, sliding, and rotating sprites.

I think you're on the right track, because unless you're a seasoned 2d sprite animator, it takes unholy amounts of time to make convincing iso sprites. Like you I'm doing them in 3d. There not as nice as 2D ones but I'm a one man team so...
btw, do you know about the Dofus/Wakfu games ? They're anime-like french made MMORPGs and they're tactical turn by turn iso too. From what I gather, they're also making their sprites of 3d models :

http://mmohut.com/wp-content/gallery/wa ... combat.jpg

A review in english :

http://mmohut.com/editorials/wakfu-prev ... mpressions

As it goes: I didn't make another release because I found some problems with arbitrary panning - that is, panning whenever you want - which aren't going to go away until 6.12 of Ren'Py. This has eaten up a bit too much of my time (well, that and work has got pretty busy in the last week), so I've not got much else done, just some [hopefully] unnoticeable structural changes, really.

Basically, it seems that if Ren'Py is in the middle of doing something and you interrupt it with a pan, then that thing sometimes never finishes. So for example - you've just hit someone and the little damage number is bouncing up and down, and you immediately pan to the side; it's quite possible that the bouncing number stops mid-bounce and the code which started it bouncing never returns, so the game effectively hangs.

I expect that the part where the number stops mid-bounce is the fault of the way I'm doing panning, 'cause I'm replacing the Transform mid-move, so I understand that. However, I'm not sure why Ren'Py then fails to continue executing the code that started the bounce. It could be a bug, but since we're unlikely to see any bug fixes either 'til 6.12 is out, there doesn't seem much point working on isolating and testing that instead of writing more features when there'll be a much better way to do the panning once 6.12 is along, with xoffset and yoffset properties on the Transform that I can use.

_________________

I regret you have focused most of your efforts on something that ends up not working. I hope you're not sick of working on the engine, sometimes it happens that when things don't go my way I freak out... =D I really hope it gets fixed with 6.12, but in the meantime, I've got my hands full with getting a demo working, with figuring out the customizing and designing the graphics, so I'm in no hurry. The pan problem is not even gonna affect me right now since I was already working on smaller tiles.

Oh, it's not a problem - the more I try the more I learn about what does and what doesn't work in Ren'Py, so it's not completely lost time! I'm still looking forward to some of the other development, and I'm pretty confident that I'll be able to fix up the panning pretty easily once 6.12 is available to work against, from what PyTom's said. ;-)

Also:

:3

_________________

Is it wrong to find that little doodle guy cute ? >_<;

Animation is really good !

Wow, he looks so cute. I think your battle engine is amazing. I can tell it took a lot of work and was probably very frustrating. Thanks for sharing it with us, I really appreciate it.

_________________
Development blog

Absolutely not! ;-)



You're welcome - I hope it's useful to some people!


This lunchtime I managed to finish off the methods to add and remove arbitrary rectangles of land from the grid:

In the above example, I've added three extra squares between (1, -1) and (3, -1), and removed a single square at (1, 2).

As you can see, as with the a1 release, the grid isn't drawn on by the engine, it's part of the pre-made background, so the added and missing squares aren't so obvious; hopefully I'll get the grid [optionally] drawn by the engine fairly soon, I'm just thinking about the most efficient way to do it.

I've also added the transparent-scenery code I talked about before, but it's a bit hard to see... if you set the required flag when you create your Scenery, then the engine will draw it opaquely on the BG layer, and then transparently on the Fighters layer - which will give the effect of being able to see characters through Scenery as if the scenery item is semi-transparent, without seeing the whole background through the scenery or having to bake it into your backgrounds.

_________________

This is great, so now it will be much easier to have a non diamond grid, I'm so happy =)



Lovely ! I'm thrilled by the progress so far, its like being updated so fast. May you have many more lunch breaks =P

Will it be possible to have the red dots that indicate possible fighter moves, also influenced by the new transparent-scenery code as to appear faded if behind the tree in your example ?

If you want this to happen, then probably the best thing would be to subclass the UIProvider and override the PickTargetPosition method; you could even copy the one from the parent class, since the main thing that you'd need to modify is the layer that it draws to. Presently, all the UI methods draw to the 'UI' layer, which is by default positioned above the 'Fighters' layer. This will be easier to do in the next release, since one of the things I've added since a1 is a 'CustomSchema' object, so you can do something like:


instead of having to also create yourself a new Schema object as well.

_________________

Allright thanks for the pointers !

btw, is the little guy's frame speed matching the one from the fighterclass' movement ?