search

sanderfrenken / Universal-LPC-Spritesheet-Character-Generator

Character Generator based on Universal-LPC-Spritesheet
https://sanderfrenken.github.io/Universal-LPC-Spritesheet-Character-Generator/
GNU General Public License v3.0
392 stars 147 forks source link

Specification for frame animations #183

Open andreas-volz opened 4 weeks ago

andreas-volz commented 4 weeks ago

I ported my own animation framework to support ULPC animations. First I added a converted to my own format and I plan a specific godot addon. As base I needed to specify the frame order and did this in a JSON format:

https://github.com/andreas-volz/SATF/blob/main/LPC-Converter/lpc-spec.json

A python script could parse this JSON and generate my own engine format: https://github.com/andreas-volz/SATF/blob/main/LPC-Converter/LPC-Converter.py

My request is if it may be a good idea to integrate this lpc-spec.json in a more generic way into your code base? I had to get those animation frame values out of your source_index.html.

sanderfrenken commented 4 weeks ago

Hi there! You could make a PR to add such as spec in the form of documentation. Alternatively, if you like to do it in code, feel free as well to submit a proposal in the form of a PR :)

jrconway3 commented 4 weeks ago

Not sure what you're asking here? I did add some documentation for adding specific animations, but if you wish to include new documentation that works as well.

Another one we've used in the past is lpctools by bluecarrot, but I think its outdated now.

Oh, I see. You're converting assets from here to your own format. Yeah, that's cool.

I think my only real concern here would be if the base models are slightly off in your version compared to this one. That can happen sometimes. As long as they're consistent, it should work well.

andreas-volz commented 2 weeks ago

Yeah, the main idea was not to fork all the data but align with a common data structure for my application as much as possible. In case the format changes I'll just change my importer.

jrconway3 commented 2 weeks ago

The idea I have when expanding is just to expand the sheet further down, or potentially add in additional frames to the right side (I really want to avoid this, but when there's very narrow segments, that's when I might consider it).

I don't intend on retroactively changing the existing format. One reason I was concerned with my placement of climb was this exactly--what if we ever add alternate climb (or even "down" / "die" directions?), however, nobody seems interested in adding these, and the idea of adding "side" climb animations seem unlikely, let alone "south" climb animations (which is nigh-impossible to pull off anyway). Typically, in top-down RPG style games, climbing only happens when moving north due to perspective.

But yeah, if eventually new animation styles are added, they'd be added to the bottom of the list so as to not disturb older assets. As such, it shouldn't break your importer either.

As for your specs, I think I misunderstood. Perhaps you can add a markdown readme file, or even just drop your spec json file, into a new subdirectory.

Notably, I did the same thing with palettes. I added a "palettes" subdirectory with json converter files to convert one palette into another (for usage in lpctools) and I've been expanding it over time, and using README files to determine which assets use which palettes. If a new asset includes a custom palette, I add that into custom.

Perhaps you can create a subdirectory similar to this called "animations," drop your spec file in there, and write a small readme file explaining the animation positioning and what the purpose of your spec file is for. Then I can update it further by noting the purpose of each animation in the readme file.