Love to see it! And obviously excited to work on the new art :) 

Some minor visual feedback from watching the trailer:

- The way the arrows fly looks very strange. It would be great if you could implement some kind of visual arc and have the arrows rotate in the air, something like this: https://stackoverflow.com/questions/38692488/how-to-calculate-initial-ve...

- Obviously there are no animations for falling trees or breaking rocks; I wonder if you could hide that by having a little puff of smoke when the rock/tree disappears; then, after the smoke clears, the wood/ore is there behind it. Breath of the Wild does something similar I believe when you chop downed trees into wood, or when you hunt animals.

I also think it's very amusing that when you hunt those snakes in the cave, they drop drumsticks labeled "chicken" :p 

Hi FiveBrosStopMosYT, thanks! There is definitely a chance! Although it's not high on my priority list at the moment.

Next up for this set is to revisit some of the trees that are in a pretty different style (e.g. the trees from Jetrel/Zabin) and make them more consistent with the LPC, plus draw trees that are similar style but more visually distinctive (for instance, birch, poplar, sycamore, maple). More similar to what I did with the fruit trees.

Eventually, I would like to have more robust seasonal variations (e.g. part-orange/part-gree trees for fall, with leaves on the ground, maybe flowering variants for some), as well as snowy, leafless ones. In the meantime, you could use the "dead" versions from this pack, or the conifers from here https://opengameart.org/content/lpc-conifers which have snowy versions.

I'm happy to discuss commissioned improvements/expansions for any of my sets---just send me a private message if you are interested.

This is awesome! Nice work!

Eliza, I can probably help with the hair---we can use JaidynReiman's scripts to do the positioning to the male base and the recoloring.

I can also add the positions for this base to the scripts, so we can adapt the other hairstyles.

Good points all. Appreciate the comments about indexed palettes and alpha transparency. Another disadvantage of indexed PNGs is they are not supported by all editing software (for instance, PyxelEdit which I mostly like).

pvigier, could you share your get_palette , get_indices , and apply_palette scripts? I don't see them in your repo, but they would be helpful.

This way I am sure that I don't have wrong/obsolete recolored images that live somewhere. There is only one truth for the indices.

Perhaps I'm misunderstanding, but I think that can be solved by having a "source" directory where the shape/index images and palettes live, and an "output" (or "build" or "bin" or whatever) where generated images live. Images in "output" never get directly edited.

I'll have to mess around with ImageMagick, Pillow/Numpy, and PyPNG and decide what works best. May be a combination of all three, depending on the specific task. If I end up using any of the original Ruby scripts, I'll probably port them to Python so there are not too many languages at play. Slow is not the end of the world, but it depends how slow and how often the images need to be "re-built". If an artist can edit something that looks somewhat like the final product, then only infrequently re-build the derived/output images, it's fine if the scripts are kind of slow. But if every time you save, you have to run the scripts, speed will matter more.

I would advise against make, I can't say anything about other build systems, since I'm not familiar with them.
The best thing about make is that it only builds what changed.

Yes, that is exactly the advantage. I imagine a set of shell tools that implement the verbs I described above. Then a Makefile (or similar, not married to Make specifically), combined with a standard set of index/shape input images, which calls the shell tools to generate all the output images (producing a collection of layer-able spritesheets, similar to those in castelonia's current generator). If someone wants to do something different, they can call the shell tools directly, or create a fork with a different Makefile.

The only thing I don't like about pvigier's approach is that the shapes/indices (https://gitlab.com/vagabondgame/lpc-characters/-/tree/master/indices) cannot be edited directly in a practical way (one would have to convert them to RGBA, then convert the edited RGBA back to indexed; not impossible, but kind of a pain). By contrast, the hair shapes in https://github.com/jrconway3/Universal-LPC-spritesheet/tree/master/_buil... are RGBA images, but they use a standardized palette so they are directly viewable/editable. That standardized palette can differ for different types of images (so for instance, I could use a different palette for the shields than for hair). I think I like this solution better.

My tool does currently not support multiple palettes, but it should work if multiple palettes get concatenated with cat beforehands. It also currently discards information about what index is transparent.

Sorry, what I was thinking about was taking one index/shape image and making say 10 different recolors with 10 different palettes.

I haven't figured out how we should handle objects with multiple "materials" (e.g. several independent color palettes). For instance, the base bodies and their eyes, or the helmets that ElizaWy just posted and their red plumes. I suppose an advantage of the JSON palettes here is that different materials could have different standard palettes, which could be concatenated unambiguously.