Yarrdachi: Sprite sheet generation.

I moved my dev db to the local r710 so I could more rapidly develop, generating pets was getting to be a long wait due to the amount of queries that needed to be fired. I think I need to make a little note here to streamline these queries a bit. I think I can fire them all in one function and perhaps not need to fire some of them at all.

Before I go about optimization, which would be premature and probably cause problems down the road I will be building the sprite sheet generator today, it's basically the exact same code as the static sprite generator but with different paths so... depending on how large the sprites get I could keep it all in the same process or if need be I could spool up another and close it at the end.

However, if I were to do that I would have a lot of repeat code. I could do that now as a future proofing thing and break off all the code as functions now, doing the refactoring early but I feel like it would be easier to debug any unexpected errors if I just have this be in it's own function for now as a big ol' chunk of copy paste. If I have to change things across them of course this slows me down but it will be quicker to debug. Not sure where I lose more time here so I am just going to err on the side of debugging being the main bulk of my work for this (aside from the actual animation of the sprites, anyway.).

Aside from this I need to decide how many frames I want to start with. I would prefer to keep it simple because every frame I add is an exponential amount of work per sprite. This wont be as big of a problem down the road and given that the sprites will just be sprite sheets rather than individual images it wont be as hard to deal with. The only thing that need be different from the static generator is the paths. So I will in interests of saving time and allowing myself to get the code mostly done and not pushing my wrist to the point of losing grip again I will start with 2 frames.

Two frames is faithful to the primary inspiration of this project. Tamagotchi as I recall when I was a whipper snapper had two frame animations. There's also something about two frame animations that feels kind of nice to me so I might just keep it that way. I remember the old Final fantasy idle animations were 2 frames. Besides, it was my wrist that went wonky and postponed toghairm and I would rather not repeat this, of course my laptop dying didn't help. That was pretty depressing, hate leaving things unfinished once I have committed.

Alright, so first up... making a copy of the static sprite and editing the base and all the parts with two frame animations. Then I have to write a hook at the end of the static generator to generate the sprite sheet and write the function to do so. Luckily I will have the data unpacked already in the payload processor and the code is already basically written, in theory this should go smoothly.

I could either export the sheet like this or export the layers individually like I did for the static sprite. (I wish I knew this was here before. Why didn't I think to mess around with aseprite's export settings sooner!?)

I will look for a quick and dirty way to break the image up.

Thanks Isometric8, you saved me having to export the sprite with JSON then write a script to programmatically do this for me based on the JSON. Sure I could use it to name the files for me and save a little time but this saves me more time for today. I will probably have to write the aforementioned script eventually as it will save me time but for now... this'll do.

Now to rename and place them in the right folders on the generator.

Alright, I tested it on one of my first little experiment pets and Jib came through in one piece it looks like.

I could increase the size of the sprites, probably should really. Just double it, the still is quadroupled so... yeah probably.

Of course the front end will have to handle the animations, I can either write my own renderer in JS or just use some game engine or graphics library I am sure many have solved this problem already.

Next I just guess I have to animate all the rest of the sprites. Luckily these guys are all pretty simple so it should be pretty straight forward. I will also add one more conditional generator where a marking can skip the coloring phase of generation. This further increases the variance of pets and allows me to make static markings like if I wanted a rainbow band or a bandolier or something for watever reason.

But first; lunch.

Alright I have added the code to handle markings that do not get recolored and finished doing some rough 2 frame animations for all the pet parts I have created so far. I went and generated 11 pets at once just to make sure they would all work as intended. We seem to be good. Doesn't look like I misnamed or put anything in the wrong folder.

I might do some constraining on the color generators at some point, sometimes I end up with things being a little too similar. I suppose I could darken eyes and stuff, though. I'll cross that bridge when I get to it though, for now I need to make a test marking that doesn't change color.

A couple of generated sprites, giffed.

I will have to write a script that will generate and name all these things for me in the future. I can see this workflow definately needs improvement. Anyway, I made a belt to test the non-recolored marking feature.

Now we need to generate a pet with it.

Well, that's looking like all my todos are done for the day. Time to get some crap done around the place.

Cheers