Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Specification for frame animations #183

Open
andreas-volz opened this issue Aug 13, 2024 · 4 comments
Open

Specification for frame animations #183

andreas-volz opened this issue Aug 13, 2024 · 4 comments

Comments

@andreas-volz
Copy link

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
Copy link
Owner

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
Copy link

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
Copy link
Author

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants