Wow this is amazing! lovely rework!

I have a request for advice. Reading your readme, I find it hard to estimate what I should do with the generator. Should I replace the existing bodies with your new ones, or should I create additional entries?

My question comes from a backwards compatibility perspective. Imagine I replace the existing bodies with the new ones, will some combinations of existing items plus new bodies now "break"?

And moreover, imagine one creates new items, eg a new shirt, based on the new bodies you  submit here. Will that still work with the old bodies?

I can also imagine that the above scenario is applicable to some bodies (they might break with existing items), while for other adapted bodies that doesn't apply.

I hope you understand my question and give me some advice on this:)

Doing God's work; thank you!

Thanks for the explanation Ben! 

I will try to adjust the generator in the coming days, and let you know when it's done:)

Thanks again for all the great work!!!

How different are the bodies between human, orc, lizardman, and wolfman? Other than the heads, are they just recolors? 

I am wondering if we could make a headless version of each of the "primary" body types (adult male, adult female, teen, pregnant, muscular), then combine any of those body types with any of the heads (human male, human female, orc male, orc female, lizard, wolfman, boarman, minotaur, skeleton, etc.). This would essentially finish/continue what basxto has started here https://opengameart.org/content/lpc-modular-bodies-and-heads , and allow for female/pregnant boarman, muscular minotaur, teen/muscular orc,  etc. 

Minimum 9 (4 directions + 5 hurt frames), maximum 15 (6 frames in cast where the human characters close their eyes) images per head would be needed, and those images could be placed automatically with `lpctools arrange distribute`. Cutouts where the arm passes in front of the head could also be handled by lpctools.  

Of course something similar could be done for the children too, but that would probably require different (smaller) heads. 

What do you think? Looking quickly at the images, I don't see why this couldn't work, but you have spent more time with these images than I have...

After some investigating, I can tell that other than the heads, the bodies are only recolors---I am emboldened! Still interested if you can think of a reason why the modular heads would be a bad idea. So far the only think I can tell/think of is that some shirts might not like the lizardman's neck, but I'll have to experiment a bit more and see. 

Another thing I was wondering: the second frame of the north-facing thrust animation has been changed for the female and teen bases; it is now the same as the first frame, but right-shifted by 1px. Previously, the character stepped back slightly (this is still the case for the male animations). Any special reason you changed this?

Makes sense, thanks for the clarification.

I wasn't planning to mirror the E/W heads, since you went to the trouble of fixing the reflections on the scalp :p Good point about the hurt animation. 

Do you happen to still have a headless version of the bodies? I have cutout the unique heads and distributed them with lpctools, then planned to make headless bodies by deleting the corresponding regions from the bases (probably taking the union of [(human - human head) + (wolfman - wolfman head)], if that makes sense, to cover as much of the neck/shoulders as necessary). But if you already did that before, I wouldn't need to! 

Actually, same question as above for the "jump" animations, some of which I know you worked on.

I expected some cleanup/adjustment would be necessary for the necks; hopefully it's not too bad, though we'll see. Thankfully I can do the arm cutouts easily with lpctools. 

I am wondering if we could make a headless version of each of the "primary" body types (adult male, adult female, teen, pregnant, muscular), then combine any of those body types with any of the heads (human male, human female, orc male, orc female, lizard, wolfman, boarman, minotaur, skeleton, etc.).

In case you're curious: the minotaur head (from https://opengameart.org/content/lpc-faun-and-minotaur) should work properly as a modular head as well.

I wasn't planning to mirror the E/W heads, since you went to the trouble of fixing the reflections on the scalp :p Good point about the hurt animation. 

Isn't that something that could be automated using the scripts (either by having the spot as a separate highlight, or by recording what parts of the image to slide up a step along whetever colour ramp is in use)? I know it's something I tend to mess up half the time because I forget to make the adjustment after mirroring an image. ;) 

Yes! The minotaur should definitely work. And this would let you have non-muscular minotaurs too :) 

Isn't that something that could be automated using the scripts (either by having the spot as a separate highlight,

Yes, that would be possible, but it seems like more work than copying one more frame to the template :p  Trying to strike a balance... https://xkcd.com/1319/

So far, the results of the head separating were very encouraging. I generated all heads for all bases, but so far have only made headless bodies for the male. I basically did as describe above: took the auto-placed separate human heads, selected the opaque regions, and deleted those regions from Ben's the adult human male base. Then I did the same thing for the wolfman base and the lizard base (both recolored to the ivory palette, same as human) and layered all three headless versions together to create a consensus. This identified a few issues with the heads, which I adjusted. Then I went through reviewed all of the animations with the human, wolf, and lizard head. I looked briefly at the orc, but am mostly ignoring him right now since his head is wider/bigger rather than narrower than human, and thus more likely to cover up problems than to create them. 

As Ben suggested, there are several frames in the slash and shoot animation where there is disagreement between the bases about how the neck should be shaded. I noticed issues that look weird in (1-based indexes), walk-{e,w}-{6,7,8}, slash-n-5, shoot-n-5, shoot-{e,w}-{10,12}.  But honestly it's pretty minor compared to what I was expecting. The results also have slight changes in how the north-facing human neck is shaded, but I like the result just fine. I think a very slightly better consensus "headless" body is possible, with some experimentation on those frames. I also noticed a few "bugs" in the original bases as well, which I have rectified in the consensus headless base. 

Next I'll create draft headless versions of the female, muscular, and pregnant bodies to see if any further modifications need to be made to the heads themselves. If not, I will begin tweaking the consensus headless bodies, as well as testing them with all heads, including the orc, skeleton, and Evert's Minotaur.

Other possibilities down the line: adding different heads to the centaur https://opengameart.org/content/lpc-centaur-walk-cycle (would require its own set of offsets, but otherwise existing heads could be used), developing new heads (child orc, female lizard, etc.). Evert, the Frogman is probably too... different... for this treatment, huh? Unless we just spliced the head on to the human body and made him just walk like a human rather than like a frogman :p 

Thanks Ben! 

I now have a set of spritesheets for the following headless bodies:

• [adult] male
• [adult] female
• pregnant
• muscular
• teen/androgenous
• child

Each body is automatically recolored to a several color variants: ivory (white human skin), orc green, lizard green (same except for the darkest color), minotaur, wolfman/boarman. 

There are complete head spritesheets for the following heads:

• human-male
• human-female
• human-child
• orc-male
• orc-female
• orc-child (adapted from https://opengameart.org/content/lpc-children-walk-animation)
• lizard
• lizard-child (new)
• wolf
• minotaur
• boarman
• skeleton

Each head has several spritesheets with different cutouts/offsets to match each of the adult bodies (except the -child heads, which only have spritesheets for the child body). Translating the heads to all positions, making cutouts, and generating the recolors---all of this is done automatically with scripts.

A complete spritesheet can be generated by compositing a headless body with the appropriate head spritesheet, e.g. `magick convert bodies/male/lizard.png heads/lizard/male.png -gravity center -background None -layers Flatten lizard-male.png`.

I am now working on making such test images and comparing them to the cognate in Ben's set. Some comparisons are attached as animated GIFs; they cycle between diff (highlighted in red) -> Ben's version -> my version. Ignore the east-facing frames for now; I exclusively edited the body bases on the west-, north- and south-facing directions so far. I will mirror the west-facing body to get the east-facing body, once all the issues are ironed out. 

As you can see, the main issues are with the neck. The lizard west-facing walk animations are particularly problematic. I also made some changes to the necks in the south-facing frames to accommodate the minotaur head, which has a very narrow face---but it makes the neck look too thick for some of the other heads (lizard, wolf). There is also some slight disagreement in the pixeling around the neck in the west-facing lizard and wolf heads. The north-facing lizard heads ended up 1px lower in my version than Ben's; I think this is OK, because it means they are the same height as the male bases. 

In addition, I made a few intentional changes, which also show up in the comparison images.

• Re-draw shoulders in east-facing thrust animations throughout to reduce flickering
• Re-draw underarm/breast of east-facing shoot animations in female and pregnant base to reduce flickering
• Slight changes to lizard head shading

At this point, I'm in for a penny---in for a pound. I'm going to continue fiddling with the heads and headless bases and re-generating the comparison images until I'm happy with the results. It seems certain that the necks will always be a little worse than Ben's versions, because they can't be manually cleaned up... but I think the results will still be nice enough to be usable.

Ben, once these separate head versions are finished, would you like to add them to your submission here, or should I make a separate submission? I think it would be nice to have one "definitive" set of bases that everyone can work from going forward. If added here, we could of course keep your original version as well, for reference and comparison. 

Hmm, okay... I'd just like to avoid introducing another, slightly different version of the bases. The results will not be 100% identical, due to the intentional changes I have made. Do you approve of those? 

Let me look over the remaining bugs/unintentional issues again and see how many I can fix.

Would you be persuaded by updated comparison GIFs like I posted, showing that there are only minor changes to the neck?

So I was just brainstorming about having a character builder into my game (for customising the player character, as well as easily generating a procedural troup of marauding orc's), and now I'm wondering if anything new or additional has been done with these?

Basically, I was thinking about in-code recolours of the bases for different skin tones (I think there are palettes for that scattered around), having bluecarrot16's hair bases and palettes (no need to store a full sheet if we can build it from a handful of basic images with offsets per frame) and having cloting items in a few well-defined palettes that can be recoloured on the fly. I guess the latter isn't available in any form yet, and of course it won't be so easy for cloting that does something more interesting than sticking to a single 5 or 6 ramp colour range.

Is there a definitive set of masks (for body parts), offsets (for headgear) and palettes/colour ramps (for skin tones) somewhere in a form that's easily readable/documented?

I can give more details, but basically:

- AFAIK, nothing more has been done on these bases since my last comment (I certainly haven't had a chance to revisit; I've been busy with other less thankless work :p)

- I do have the minimal set of images, offsets/masks, palettes, and the scripts I used to generate the hair in my submission (and actually all hair in the spritesheet generator https://sanderfrenken.github.io/Universal-LPC-Spritesheet-Character-Gene...). I can upload them later to that submission. The same tools can be used for hats; I used them for the pirates and santa hat. I also have another set of masks and offsets, which is useful for placing things on the torso that go under the arms (e.g. I used it to make the cravat/jabot, belts, and sashes for the pirate, and for making the modified santa coat for Santa claus). However, the generated images are usually not perfect and have to be manually edited somewhat, so it's more an intermediate tool. 

- Much of the clothing in the generator is not in a well-definted palette; I have been slowly working on converting it (e.g. pants, shoes, the pirate jackets, hats more or less use a standard palette). I have a standard set of color palettes in lpctools format that I have been applying to all clothes (derived from Eliza's earlier clothing palette, but with some simplifications or changes for consistency). With lpctools, the palettes are encoded as a mapping from a standard palette to several alternative palettes. Colors that aren't in the given palette are left as-is. There is also an option to give multiple such mappings for different materials and create all combinations (e.g. for the pirate hats, I used one set of palettes for the fabric and another to generate the trim). This generates a huge number of images though, so it's kinda unwieldy... probably better to separate those objects out into separate sheets in the future where possible. I'd suggest having a few sets of palettes for different objects, e.g. cloth, metal, maybe wood? And also not every object needs to have infinite recolors... idk that anyone is really asking for a green/blue/pink peg-leg :p

- I don't have any kind of palette for skin. Eliza has proposed several, and there are a few overlapping styles in the generator right now. 

- Finally, none of the art in the generator has been updated to use the bases on this page. All of my offsets, masks, etc. also use the old bases (those in the generator right now). It would not be hard to update these tools, but I have been delaying doing so until the existing assets in the generator are updated, since I don't want to create two parallel sets of assets that can't be used together (Eliza is already doing that with her projects...). Updating the existing assets in the generator to use the new bases, especially the female bases, is somewhat daunting because anything that touches the legs or arms will need a few frames to be re-drawn. The male assets will need to be updated too, but those are just 1px pixel shifts which can be easily accomplished by lpctools. 

- As a logical set of next steps and to minimize duplication of work, personally I would propose the following order: 1) finish the headless bases and separate heads I posed above posted here, working out any remaining bugs around the neck etc.; 2) automatically update the male and most female assets to the new bases 3) manually update the relevant female bases to the new bases, 4) adapt all assets (if possible) to one of the standard palettes mentioned above, then introduce a set of scripts to the generator to build the full set of spritesheets and re-colors from those source images. (The scripts would be straightforward, since lpctools provides all the necessary functionality; I've mostly delayed because I'd like to make the scripts use GNU make or similar, because running shell script to generates EVERYTHING, even if unchanged, takes a long time---even the ones I wrote for the pirates and hair were getting really unwieldy... but I'm not too familiar with make and it's kind of a confusing tool). 

- However, if you don't care about updating the bases and are going to re-color things to a standard palette, please share your work :p. Using the same standard source palette as me (even if you choose different one(s) for your recolors) would be appreciated obviously. Ideally, make a PR against the generator repository. The credits are all worked out there, everything is pretty nicely organized, and we'll all benefit from the tedious work. 

There are two separate issue for color palettes: 1) are the assets you want to recolor in a consistent palette to start with, and 2) what palettes do you recolor to. It doesn't much matter to me what Evert or Eliza or anyone choose to do for (2), however it would benefit us all to us the same palette(s) for (1). FWIW, I've generally been using this one for fabrics: ["#1d131e", "#411e05", "#4b2b13", "#62351c", "#744b30", "#996b4a"]. All the clothing I have added to the generator recently should have that palette as the "brown" variant (e.g. collared jacket, santa hat, etc.), so if you wanted to choose a diffferent set of destination palettes (2), you could start with the "brown" version and recolor from there. 

I will share the offset and mask files and scripts I have used. The offsets for lpctools are specified as images, but it would be trivial to export them to some other format; if you need, I can easily add that functionality to lpctools. The masks, it's worth noting, are sort of situational like Ben said. For instance, the masks I have which identify the arms are really meant to cut out anything that would obscure the torso/chest.  The hair masks are different, because they are only meant to remove parts of the arm that would obscure the hair. 

It's late now, but I'll figure out how to upload the files and scripts this weekend. 

Ok, so thinking about it, I think my intended use-case is fairly specific: I want to be able to procedurally generate characters in-game. Conceptually, that means porting the spritesheet generator, but ideally in such a way that I can put, say the source images for a haircut somewhere, and the code takes care of assembling the piece and colouring it the right way. Of course, the hair generator does that already, and doing hats/eyes/ears/noses the same way isn't the hardest thing in the world. Even whole heads are doable, with some caveats to be worked out.

Cut-outs for arms (and legs) are highly situational, but very useful precicely for figuring out when an arm blocks a part of the face, or a weapon (or any other type of object you may want to hold, think lanterns and hand baskets) and masking that part out automatically. Not having to draw weapons with clever cut-outs for the hands, and then doing that again for the skeleton/female/juvenile variations (just shift a few pixels where needed) is a win.

There is one other case where I've found these to be helpful, and that is for making variant animations, like a walk cycle with the arms in a different position, say if the character is holdingor pushing something.

For recolouring, obviously everyone can pick whatever colours they like, but having a well-defined ramp available for easy recolouring gives maximum flexibility for everyone, I think. I like the idea of having a well-defined "brown" variant listed for all clothing items, I'll definitely use that as a base for whatever I manage to come up with.

I guess the first step I'll do then is to figure out what named colour-ramps have been proposed in the past (for skin/clothing/materials) and collect the various masks that are scattered around. Would it make sense to post those in a separate submission here, or put them in a repository somewhere?

Holidays are over, so it'll be slow going over the next few weeks, but hopefully I can get some things done if I have a clear idea of what I'm going to do exactly.

Forgot to mention: I haven't done hand-crafted Makefiles in ages, having switched to CMake some years ago, but I was fairly proficient with writing them at one point (arguably none of my project involved much more than %.o:%.c: $(CC) $< -o $@ though). If nothing else, I'd be happy to contribute what I can in that department.

Auto-generating character is not an esoteric use-case at all, and we should endeavor to make the assets easy to use for that purpose. This is one reason why Sander and I have re-organized the generator to try and have a more consistent file structure and added those JSON definition files to keep track of things like the indended Z-order and which assets are mutually-exclusive, so if you wanted to use that data while re-implementing the algorithm for your engine, you wouldn't have to re-invent the wheel. It's not perfect but that is the goal. (I'd argue that you are more in need of duplicating the re-color functionality than duplicating the place-and-mask (`distribute` in lpctools) functionality, but whatever floats your boat, neither are all that complicated.)

Perhaps the generator should include 3 levels of assets: "source" images (e.g. for hair: n/s/e/w, and the 4 hurt frames)---obviously not all assets would have these, just the repetitive ones amenable to auto-placement; "spritesheets" (the full set of animated frames, but only in one palette per-material); and "recolors" (recolors of spritesheets in a standard set of palettes per-material). "spritesheets" is obviously a subset of "recolors", but having it separated out might make it easier for someone like you who wants to incorporate their own in-engine recolors to just take what they want. 

Anyway, I uploaded the scripts, palettes, and source images I used to build the pirate clothing, along with pretty detailed instructions/explanation, to that submission: https://opengameart.org/content/lpc-pirates . I can do the same for hair after work or tomorrow, but the principle is exactly the same as for the pirate hats. 

Ideally the generator repo would be a place to converge on a set of assets in a standard palette, as well as a build process for generating the repetitive ones (hats, hair, neckwear, etc., plus re-colors). If you find/make other offset/mask images, palettes, etc. that are not useful for that purpose but seem useful for something else, I would suggest to post them on OGA. 

That type of Makefile incantation is exactly why I have been putting this off. I can infer from context what it does but would not have been able to write it out :p If you would help translate build.sh in that pirate directory to a Makefile, it would be very helpful for the sake of the generator. 

re: weapons, we have been trying to implement a system where there is a "behind" and a foreground layer for weapon walk animations, see e.g. https://github.com/sanderfrenken/Universal-LPC-Spritesheet-Character-Gen..., so that no cut-outs are needed. Someone asked about that and I added it to all the weapons here https://opengameart.org/content/lpc-extended-weapon-animations . But point taken, it's another place to think about how to not-repeat-ourselves. 

Ok, here's where I am and what I think I'm going to be doing in the next couple of weeks.

• I found some well-defined and named colour ramps in an old post by Eliza. I'm going to check how those compare to other existing ramps and whether they're all still current.
• I like the idea of splitting things up in a "source" and multiple "outputs", as bluecarrot16 suggested.
• Not re-inventing the wheel, so I will reuse everything I can and am aware of.
• I'm going to cut up the universal spritesheet and split it out again in individual animations. I love the convenience of a single big spritesheet to work with, but it engenders some stagnation as well, because...
• ... there are several animations out there that are not in the universal spritesheet, and I want to treat those as equal citizens. There's (Eliza's improved) jump animation, a running animation, the recent sitting frames, animations that are frankensteined from existing animations, the grab animation and a few I did myself (carry, push) based on other animations. Some of these have a (limited) selection of hair/clothing, some don't, but we'll get there when we get there.
• Cut those down to single sets of colourramps for skin and eye colour.
• Assemble things like eyes, noses, expressions and the like. Some of these are in the generator, some aren't, but they should all be constructable from a few source images, just as the hairpieces are.
• Wrap that up in a nice build system where you run some configure/make and it all automagically works (on *nix systems anyway; no clue about Windows).
• Once I have the recolouring and assembling of the character bases, facial features and hair in place, I'll worry about handling the clothing. Hopefully that will be relatively straightforward once these are done (and I can probably just re-use what's already in the generator anyway).

Great! I'm glad you are going to work on this! 

I have uploaded the individual images, offsets/masks, and palettes I used for all hair in the generator to this branch and specifically this folder. I'll hold off on a pull request to the main repo until we are satisfied with the structure of the build process. Check out _build/hair/build.sh , which is the simple script that's used to build all the hair sheets and recolors. I didn't include too many comments or instructions since it should be straightforward, but check out the discussion in the pirates submission build download for more exposition.

_build/hair/palettes.json defines the color ramps I used for the hair. They are based on a combination of the different ramps that were in the old generator previously, plus Eliza's ramps (not the Liberated palette, but ones she had created in the interim). I put some thought into choosing a good, coehsive set of palettes that provided lots of options but didn't overlap too much (and also naming them clearly), so I'd suggest starting there for hair palettes if you like. (By the way, the source palette I used for hair is different than that for clothing, it's defined in that palettes.json file and is kinda orange. This was chosen to have good contrast but be kind of race-neutral and to look reasonable on different skin colors). 

To reiterate, the named destination color ramps I have used for clothing are in the pirates build download, and are based on Eliza's older palettes (for instance used in the jump or women's shirt submissions) but with some edits to remove very similar colors and to increase the contrast for many palettes (so they look good with 4- and 5-color objects in addition to 6-color). So if doing clothing I'd humbly suggest you start there. 

I haven't done anything similar for skin, Eliza's palettes are probably the way to go there. Let me know if you need help converting them into a format that lpctools can understand. 

A few other points:

I'm going to cut up the universal spritesheet and split it out again in individual animations. I love the convenience of a single big spritesheet to work with, but it engenders some stagnation as well, because...

lpctools can do this for you:

lpctools arrange repack --input tests/arrange_files/male.png --from universal --to cast thrust walk slash shoot hurt --output-dir tests/arrange_files/individual_animations

(You can use any image, male.png is just an example included with the distribution) In general --from and --to can be names of any layouts understood by lpctools (use lpctools arrange repack --help to see which layouts it knows about). There's not currently a way to specify a new layout in a file, but I can add one. By the way, the layouts can be arbitrary 2D arrangements of animation frames; they don't have to be stacked like the universal layout. For instance, you'll notice a layout called "evert", which includes the animations you proposed a while ago with push and a few other things over on the right side. 

Assemble things like eyes, noses, expressions and the like. Some of these are in the generator, some aren't, but they should all be constructable from a few source images, just as the hairpieces are.

Eyes, Ears (with one exception), and Noses are in the generator already, as far as the assets I'm aware of, see e.g.: https://sanderfrenken.github.io/Universal-LPC-Spritesheet-Character-Gene...

Here are the available face-related assets that are not in the generator (that I'm aware of)

• https://opengameart.org/content/lpc-long-ears
• https://opengameart.org/content/lpc-emotion
• https://opengameart.org/content/lpc-base-character-expressions
• https://opengameart.org/content/four-characters-my-lpc-entries (bauldric's goatee and those amazing eyebrows)
• https://opengameart.org/content/cyclops-and-his-eye

Wrap that up in a nice build system where you run some configure/make and it all automagically works (on *nix systems anyway; no clue about Windows).

Amazing! Would be awesome if the target (or one possible target) of this build process would be assets for the generator. Even if not, I'm sure we'll benefit from your work on this. And yeah I wouldn't worry about Windows if I were you; Windows users can use WSL to run the same scripts as *nix if need be. lpctools does run on Windows, but via WSL is my recommended method anyway. 

Once I have the recolouring and assembling of the character bases, facial features and hair in place, I'll worry about handling the clothing. Hopefully that will be relatively straightforward once these are done (and I can probably just re-use what's already in the generator anyway).

The straightforward but tedious part will be putting the existing assets into a consistent source color palette. The straightforward and easy part will be making the automatic recolors. The not straightforward part will be adapting any existing clothing to new bases and/or animations :p

To that end, now seems like a good time for me to revisit the headless bases/heads on this page. There are a few obvious outstanding issues but I think they are close to good. Once we are satisfied with those, I can begin the work I described above of bringing the updated bases (and separate heads) into the generator, and adapting the existing clothing to the updated female bases. 

Just a quick update to say I've made another pass through the female and pregnant bases and I think fixed the issues there to the best of my ability, including improving the necks throughout. I think the female and pregnant bases now look good with all the heads. I identified a few issues that were relevant to the male bases too and applied changes there, but male still needs another pass on a few other problems.

I haven't tackled the jump animations at all, mainly because they aren't in the generator and they don't fit cleanly into the "universal" spritesheet layout used by the generator. Heads are all the same so it should just be a matter of making headless bases and new masks/offsets. 

Remaining work to-do on the bases themselves:

• Review tests of male headless base with all heads to fix remaining neck issues
• Review tests of teen headless base with all heads (uses same offsets and masks as female; if I've correctly copied forward the changes, shouldn't require many tweaks)
• Finish headless child base and test with the child heads (human, orc, lizard, wolf)

After that, next steps would be:

• Update this submission
• Figure out how to incorporate selectable heads into the generator
• Write scripts to adapt all muscular and pregnant assets in the generator (1px shifts as described above)
• Write scripts to adapt most frames for all female assets in the generator (1--2px shifts)
• Manually edit all other affected frames for all female assets in the generator. Will definitely affect all pants, shoes, and shirts.  Try to avoid turning this part into a huge project of re-drawing lots more stuff.
• At this point, the work may start to overlap with Evert's project, since I'll obviously only want to manually edit one color variant
• Re-generate hair and hats/helmets, which might be slightly affected by changed cutouts. Hopefully something resembling a build process will be in place by then.
• Post comments all over OGA linking here and begging that nobody make new assets using the old bases :p 

OK, I have finished reviewing the headless male, female, pregnant, muscular, teen, and child bases, each in combination with the human (male/female), lizard, wolf, and orc (male/female) heads. I have compared all of these with the originals Ben uploaded here---see comparison gifs below. Basically, I think all remaining differences are either intentional (e.g. slight changes to shading of arms in E/W and S-facing shoot frames), fix small mistakes (e.g. movement of orc head in thurst animation), neutral changes where the new version is more consistent (e.g. north-facing lizard head is shifted 1px up, putting it at same level as human male head; male orc head moves more consistently with the human male head), or are slightly different but acceptable (e.g. minor changes to shading around the neck, where manual edits to the generated spritesheets and/or more detailed special cases would be necessary  to recapitulate Ben's version).

There are new combinations possible, e.g. {child, teen, muscular} {orc, wolf, lizard, minotaur, boarman} that are not shown here, but which I also tested and I think they look good. 

I also started working on the jump animation (creating offsets, masks, and headless bases). I noticed some of the heads are different (e.g. the last frame heads aren't exactly the same as the cast-frame heads. This is fine, but those will need to be drawn for the orc, lizard, wolf, etc. base. I also noticed that the heads squish a little bit on some of the north-facing frames. I will probably remove this effect for simplicity (it won't be reflected in the hair anyway unless all the hairstyles have another frame drawn. I'll have to see how well the lizard head in particular works with the jump, where the head is displaced somewhat compared to the body. That one might need to be handled specially. 

I also haven't decided whether/how the skeleton and zombie should be included in this scheme... 

I'll try to finish a draft of the jump animation and then figure out somewhere to upload this so others can explore. Ben, if these look good to you, could I upload the heads, headless bases, and final assembled sheets to this submission?

Thanks! I think they're ready? I believe if you edit this submission and add me as a collaborator I should be able to upload the files directly. Or if you prefer I can DM you a Dropbox link or something and you can upload them here. 

For jump, you're right, the south-facing head is clearly adapted from the death/hurt animation, but doesn't quite match. I'll experiment a bit to see if I can make it work. I am guessing the hair from that frame will work fine, but I'll test that too. The north-facing squished head doesn't seem to be from anywhere else (and the hairstyles would cover it anyway), so I'd still favor replacing that one with the regular-sized head. I'll upload an example later. 

For the skeleton and zombie---I wasn't proposing to re-draw them for the other body types, but just trying to figure out whether there was a way to make useful adaptations within this same general scheme. For example, I already cut out the skeleton and made a headless skeleton base. If someone wanted to make a skeleton orc or skeleton minotaur or whatever, they'd just have to draw a new head.  Seems useful? I don't really see a use case for combining the skeleton head with any of the existing bodies, or putting the other heads on the skeleton body, but maybe someone wants to do that?? I guess if someone wanted to draw a female skeleton, they could re-use the head? Perhaps there's utility combining the skeleton head with the zombie body? (Although your wounds already cover varying states of decay pretty well)

For the zombie, I re-colored the non-wound parts back to the ivory palette, which produced an interesting effect that might also be useful. The zombie body has the same silouette as the male, so making a headless zombie is trivial; if someone wanted zombies with different heads, they could make them. Interestingly, if I delete the outlines and slap this overlay on the muscular base, it looks pretty good as well, so free muscular zombie I guess? Doesn't look good on the female or teen base, so I'll definitely ignore that one be for the moment. 

Just trying to figure out whether those combinations might be useful/how to make them useful...

Thanks Ben. I'm working on the jump animations, once those are done I'll upload everything. The file organization will be slightly different, to accommodate the additional possibilities. 

I also decided to do child heads for the boarman and minotaur, and boy am I glad I did; look at the little minotaur child---it's adorable!! Tried to make the child wolf and boar less intimidating-looking too. 

That baby Minotaur is amazing! Also, that poor dude in your previous comment looks like he went through a war! :)

OK, I have finished making the jump animations for all the bodies. Now I'm hung up on a silly minor organizational issue... wondering if any/either of you have any thoughts. 

To recap, the new version of this submission will include

• six "body types": male, female, child, teen, muscular, or pregnant, 
• six "head types": orc (male, female, child), human (male, female, child), lizard (male, female, child), wolf (male, female, child), minotaur (adult, child), boar (adult, child)

I propose that head_type be promoted to a new layer in the generator, so any combination of head and body type is permitted, and appropriate recolors of the bodies and heads be added as well, based on the palette(s) that Evert comes up with. I'm not tackling that here, just providing a minimal set of recolors of the bodies to match the heads. 

For the generator, we settled on this folder structure: ${category}/${subcategories...}/{object}/${body_type}/${variant}.png , where body_type would be one of male, female, muscular, etc. listed above (at present, more could be added), and variant would be the recolor or other variety. hat/pirate/tricorne/male/black.png. For many assets there is now also ${category}/${subcategories...}/{object}/${body_type}.png , i.e. the asset in a standardized palette, which is used to generate the recolors, e.g. {body_type}/{variant}.png . So the rule of thumb is that the variant is at the deepest file nesting, then the body type, then the object type/group. (Of course, not every object has a unique spritesheet for every body type; most only have male and female, and some only male or female. The JSON definition files clarify if a given asset can be used with multiple body types (for instance, male hair can be used with the muscular base, etc.))

The goal of having a consistent file structure was to make it clear where to put new stuff, to make it obvious where to find existing assets, and to make repetitive assets amenable to generating with scripts. For example, since hats would be auto-placed according to body type, then subsequently recolored, it kinda fits the workflow to make hat/pirate/tricorne/male.png first, then recolor that to create hat/pirate/tricorne/male/{black,brown,green,...}.png . 

With adding these bodies with modular heads, three complications are introduced:

1) How to incorporate animations/layouts into this heirarchy: The jump animations do not fit on the "universal" spritesheet layout. Several people have expressed a desire to have sheets split up by animation, which would have a few advantages. Splitting and combining spritesheet layouts is trivial with lpctools, so I'm not opposed to introducing this, but I'm trying to figure out the most sensible way to organize things. Should it be ${category}/${subcategories...}/${object}/${body_type}/${animation}/${variant}.png ? Or ${category}/${subcategories...}/${object}/${animation}/${body_type}/${variant}.png ? 

2) Likewise, by introducing the modular heads, there are now various body_type/head_type combinations. For example, head_type could be human, lizard, wolf, orc, boar, minotaur, skeleton, etc. For assets that involve the head, a different head_type might require using a different spritesheet (for example, human hair may need to be masked differently than orc hair). Or there might be assets that are unique to a particular body_type/head_type combination, e.g. https://opengameart.org/content/lpc-lizard-headgear . I'm not worried about adapting every single asset to every single body_type/head_type combo, but just figuring out the structure... should it be ${category}/${subcategories...}/${object}/${body_type}/${animation}/${head_type}/${variant}.png ?${category}/${subcategories...}/${object}/${body_type}/${head_type}/${animation}/${variant}.png ?
${category}/${subcategories...}/${object}/${animation}/${body_type}/${head_type}/${variant}.png ? 

3) Finally, how should cross-sex body_type/head_type combinations be handled? Take the orc head for example; the "male" orc head is much different from the "female" orc head. But there's no reason why the male orc head couldn't be placed on the "female" body. So do we have something like head/female/orc/female/green.png , for placing the female head on the female body, and head/female/orc/male/green.png , for placing the female head on the male body? or should the heads just be named e.g. head/orc-female/female/green.png (female head on female body), head/orc-female/male/green.png (female head on male body), etc.? The latter scheme seems clearer to me. But for other objects (such as hats or hair)... it seems like they should be organized by body_type then head_type, e.g. hat/pirate/bandana/female/orc-female/black.png . Still not sure where ${animation} should go in all this if you all still want those separated out...

Ideally I want it to be clear to someone who just downloads the whole repo what combinations are possible/make sense. But anyway I am clearly just bikeshedding with myself and going in circles about this pretty unimportant issue... please help me make a decision so I can upload everything :p 

Love the minotaur kid... calf? Really like the flexibility the modular heads provide.

Progress this week has been slower than anticipated. We were in quarantine, so I expected that to free up some time, but it seems to have done the opposite.

I've been thinking how to set up the build system. It's going to depend on lpc-tools, which only makes sense (reuse what you can), but beyond that I'm finding it tricky to make up my mind how to go about it. The thing is, something like Make expects to generate "filename.output" from some "filename.input", but the way files are organised now, it needs to build, say, "output/body/male/purple.png" from "source/body/male.png" and that's more tricky. You can write an explicit rule for it easily enough, but really I want something that requires a little bit less maintenance, so I can just tell it that "source/body/male.png" exists and it will figure out what outputs it can generate from that. I may end up wanting to overhaul the directory structure. So it is very sensible to think about a canonical organisation for the files.

I'll probably try to stay with plain Make. I did look at something like CMake, but that has more build-in assumptions about the relation between source (input) and output that make it less convenient.

Not sure this counts as constructive thoughts on organising the spritesheets. I suppose whatever we come up with can be changed later anyway. When in doubt, I am a proponent for picking something that is more convenient for humans to work with, since computers are supposed to work for us rather than the other way around.

Oh, final thoughts about the jump animation: I agree with nuking the special-case head if it's not crucial, it's not as if it breaks tons of existing assets and if it makes adapting other assets even marginally easier, that's a win. For my project, I extended the universal spritesheet to be 1152 pixels wide and stuck the jump animation next to the shoot animation. Not saying that's the best place for it to go, but I would argue against trying to stick it at the bottom of the existing universal spritesheet (say) and would prefer "loose" animations instead, but that's just me personally.

Nice developments!

I think there are ups and downs for all possibilties, but let me spit some considerations.

Having one universal sheet that includes the jump animation below the death animation I think would be from the generator perspective the least effort. You can add the bodies including the jump frames already. I/ we can adjust the preview animations easily. Exporting the sheet will remain the same (just a bit larger the exported image will be). Hereafter, one can organically update existing spritesheets by adding the jump animation frames. 

Enabllng the generator to handle separate animation sheets will be considerable more work. It does give the most flexibility though. But I also think we should refrain from overengineering the generator's capabilities. Personally, I prefer to have as output from the generator the complete sheet, which I can preprocess in my game engine before bundling it into the binary.

But let's imagine you would build the generator around the separate animations, how would you handle exporting the image? Would one select which animations to export, and will the selected animations be bundled into one image? Or will there be n-output images, for all n-amount of selected animations? I guess most developers would prefer one image with all the frames. But then it would also be preferable to have the ability to indicate which animation should be drawn at which row. And that introduces quite some complexity to the generator.

Either way, I think it is indeed inevitable to have a head_type as well. Although for starters you could merge the new bases and heads already without it, and add this property later. I also think we should adjust the generator in such a way that it auto-selects a fitting head if the body is changed. But the structure is dependent on whether to separate the animations or not.

Wrt adding the option to add any head to any body.. I would skip those thoughts now and focus on the other actions first. If we have those sorted out, we will (or will not) find a suitable to support it (even though I don't fully understand the usecase yet).

I think it would make the most sense to have the option to download either the "legacy" universal spritesheet, a given animation, and perhaps a behemot file with all available animations in one file.

Personally I don't like adding stuff below the death animation, because it breaks the "every four rows is a new animation ordered NWSE" pattern. The death animation does that anyway, but it's the last one in the sheet, so it gets a pass. I also don't like working with "tall" sheets and prefer working with more square files. I guess because my display isn't tall.

All of that is of course neither here nor there, software can be made to handle anything...

Good discussion here, thanks for contributing everyone. Not sure we're any closer to a consensus, but it's helpful to talk it out. Sorry if this is a bit pedantic, I'm just trying to think thru the best structure to make our lives easier going forward.

w/r/t file layout: Ben's proposed scheme (${body_type}/${head_type}/${animation}/${category}/${subcategories}/${object}/${variant}.png) is elegant in that it goes from broadest to narrowest category. It also means you could easily identify all objects available for a given base and remove entire bases/bodies that you don't use. However I see three related issues:

1. spritesheets for same object (e.g. a hat) on different bases (or head types) are very similar. (In the case of hat, hair, etc. they are probably derived from the same source image(s)). But this scheme puts them in very distant folders. This means that when someone adds/edits an asset, they have to touch multiple distant folders and also update the CREDITS.csv file in probably very distant places. This would be  a minor but very practical annoyance.
2. this scheme requires duplicating a rather large and deep file hierarchy, i.e. the categories/subcategories of every object, across all body_types and head_types and animations. As opposed to duplicating body_type/head_type/animation for each object, if the scheme were more like  ${category}/${subcategories...}/${object}/${body_type}/${head_type}/${animation}/${variant}.png  , which I'm beginning to think I favor. It seems more likely that the folder hierarchies would end up "out of sync" (i.e. we end up with female/human/torso/jacket but male/human/torso/clothes/jacket, just by accident). Enforcing a scheme like ${category}/${subcategories...}/${object}/${body_type}/${head_type}/${animation}/${variant}.png with a "linting" script would be relatively simpler; you just check that every path ends in ${body_type}/${head_type}/${animation}, with a list of permissible values for each (perhaps derived from elsewhere in repo, e.g. body_type can be the name of any of the subdirectories of bodies/
3. some objects may use the same spritesheet for different body_types. For example, hair for female and pregnant can mostly use the same images. The generator JSON system allows this (you just mention the same file path for the two different body_types). But it seems somewhat less intuitive in this scheme... there would have to either be a) both female/human/universal/hat/tricorne.png and pregnant/human/universal/hat/tricorne.png, or b) you would have to know to search for some pregant assets in the female directory, i.e. you would need to parse the JSON files anyway, negating the advantage of having all assets for a given body_type in one directory, or c) you would need top-level directories for various combinations of body_types, e.g. female_and_pregnant, male_and_muscular, etc. All of these solutions seem somewhat inelegant to me. 

w/r/t separate vs. combined sheets: agreed w/ Herodom that a single combined sheet is easier for the generator web page; we'd have to re-write a lot of things to accommodate separate images per animation, and I don't think anyone is really too eager to do that given how previous efforts to revamp the generator from scratch have all fizzled out. I also get Evert's point that making the sheet longer and longer is not optimal, but I feel like introducing some kind of packing scheme other than "animations arranged top-to-bottom, N/E/S/W" is too complicated for the generator. If someone wants to pack sheets more tightly, they can use a sprite atlas packer, or even lpctools. 

What if we add space for the other directions of the hurt animation (i.e. add two blank rows after "shoot", then the current south-facing hurt animation, then another blank row), then start adding new animations below that, in the order they are added to the generator? We adapt the generator to assume the assembled image will be 832x1536px (current "universal" layout is 832x1344px, add 3*64px height for the other directions of the hurt animation) or taller, and align all layers to the top-left corner? That would be a fairly minor change I think. Adding support for new animations to the generator would just mean telling it which named animation comes next, which would be simple. After scaling everything for the missing death animations (a one-time operation that could be done with lpctools), we wouldn't have to edit any of the existing images until someone drew the new animations for them. 

A final alternative, that might (??) please everyone: we separate each animation into distinct images, but then also programmatically assemble a universal stacked layout (as I described above) offline using lpctools as part of the build process. So every asset has ./cast/*.png, ./thrust/*.png, ... ./jump/*.png, and ./universal/*.png. It could also have ./legacy/*.png which would use the old layout (i.e the single-direction death animation); perhaps we re-name the "universal" layout to "stacked" or "universal-stacked" or something like that. The generator website only needs to support the growing universal stacked layout, but if someone wants to use the collection of images in their game, they can work from the individual animations if they prefer. 

w/r/t separate heads necessary? @Herodom/Castelonia: agreed we could easily start by replacing the bases with these ones, that is definitely most practical. However it will not produce very useful results; many of the bases (e.g. lizard, wolf, probably minotaur?) will not work well with existing clothing assets since the head overlaps with the torso more than the human head, so the chin will be covered by shirt collars, etc. So we definitely need an ability to add heads on a separate layer and we should figure out how to do that.

w/r/t adding any head to any body, the more I think about it the solution seems to be to name the head_types  human-male, human-female, human-child, orc-male, orc-female, etc. rather than just "human", "orc", etc. 

The head variant (i.e. color) should be linked to the body variant by default. I think we can add a field in the JSON file called "match_variant_to_body" or something, and for layers where that is `true`, if the variant of the body changes then the variant of that layer will be changed as well. Heads would obviously have this propery, so would ears, noses, wings (if we add them), tails, etc., anything that follows a skin color. 

One final issue to consider is that many assets won't care about the head_type (e.g. shirts, pants, etc.). So maybe they get a folder in the hierarchy that is just head_type=all, e.g. torso/clothes/longsleeve/male/all/universal/green.png , or maybe the head_type subdirectory is optional, e.g. torso/clothes/longsleeve/male/universal/green.png . The former seems more consistent and therefore probably better. 

So in summary, I think I vote for ${category}/${subcategories...}/${object}/${body_type}/${head_type}/${layout}/${variant}.png , where "layout" is either the name of an animation, or a composite layout such as "universal" or "legacy". The individual animations are the ground truth and the composite image is assembled using lpctools as part of the build process. 

I like your final suggestion! As long as the generator can continue to work with the universal sheet, I think we are good. Reserving spots for the missing death animation orienations is trivial indeed. I am in.

Creating the universal sheets should be done before pushing the repo to remote, so we could make it a git prepush hook for example. And it should be easy to run the job, preferably without the need for a local configuration of your machine, or make a script to rollout the needed configuration locally.

Maybe I mis expressed myself: I didn't want to suggest to not do the separate heads. I fully understand the need and usefulness here (and we can add it easily by adding it as a new object including json definition etc). Currently some of the bodies have an additional layer already to draw the head over at a higher zpos, eg for the wolfman:

https://github.com/sanderfrenken/Universal-LPC-Spritesheet-Character-Gen...

That we would need to clean up as well then (easy task).

But I meant the usecase for putting a child head on a muscular base for example. Is that even possible? I can imagine the neck of the muscular body is too large for the small head. But indeed if so, we can just change the name of the head from "human" to "human-child" etc etc :) That should work out!

Personally, I don't think it makes sense to waste space on other directions for the death animation if we don't intend to fill them in; it actually makes using the spritesheets a tick more cumbersome in that you have to special-case the death animation explicitly (which I personally don't do - I just detect that if I try to extract all directions, I go off the edge of the spritesheet and end up re-using the last valid set).

Anyway, I've gone through the various colour options that are in the generator and list the different palettes. If there are a couple that seem like they are intended to be the same, I merged them. I ended up with the following set:

From top to bottom these are: light=white=ivory, tanned=peach, olive, dark, dark 2, brown, black, dark elf, dark elf 2, zombie, reptile light, reptile dark and orc. I based the names on the male/child bases, the pregnant bases seem to follow a completely different naming scheme.

The options "tanned" and "peach" seem to be exactly the same. White/peach/olive/brown/black originate from Eliza's skin tone pack; I think they're slightly different but very similar to her Liberated Palette. I left out "tanned 2" because... well, I didn't like it and it seemed pointless?

If a set seemed close to what is in the Liberated Palette, I went with that, but notably the tanned/peach, dark elf and various greens are different. They're mostly between two colour ramps and I couldn't decide which one to pick. I have to say I'm not a fan of the greens, I think they're too flat, but then again, I'm not entirely sold on the greens in the Liberated Palette either.

I guess my question is whether you all think it's useful to keep all these, and whether there are any colours that seem to be missing?

My next step will be to make sure I have consistent sets in one colour (probably "white") and then automate the recolouring of them.

re: adding extra death animations, what would you suggest we do instead Evert? Just add jump, run, etc. as we go below the death animation? Again, I don't plan on implementing a more complicated layout system or support multiple images within the generator website (I already did that within lpctools, so I don't think it's a big burden to use that on the resulting images if you want a different layout)... so unless someone else adds that, if there's going to be any support for more animations in the generator it will probably have to be by stacking them in one big image.

re: colors, this looks like a good start! I would suggest previewing them on the character bases to be sure they look right; hard to tell from the palette whether they have quite enough contrast. Should be easy to do with lpctools and imagemagick, let me know if you need help.

Eliza posted this guide on Discord somewhere for her then-latest version of the Liberated palette, which names the color ramps she uses for skin, clothes, and hair; might be helpful to you.

What about the wolfman/boarman colors? Ben used a few of the hair color palettes to make several different wolfman colors here https://opengameart.org/content/lpc-wolfman ; they could apply equally well to the boarman and potentially other furry/hairy creatures I think. Do you want to include them in this set? 

Isn't it nice how there are as many preferences as there are people (or more even)? :D

Clearly there's no single way to do it that will be ideal to everyone, so picking one and being as consistent as possible (and documenting it) is probably the way to go.

I will say though that yes, I do indeed think having (the option for) independent images from the generator is the way to go. It seems to me that the generator mostly stacks images in a well-defined order, and doesn't need to know if it's stacking a walkcycle, cast, slash, run, jump or universal spritesheet. On the other hand, I haven't looked at the code in any detail but I'm clearly not volunteering at this stage to implement that. Obviously stacking them one below the other will work fine, and it's better than a more compact sheet for general distribution (I mean, I have trouble remembering where the buildup, repeat and recover frames go in the shoot animation and half the time I forget that the first frame in the "walk" animation is actually an idle frame rather than part of the walkcycle).

I actually used recolours of Eliza's test image when building up the palette set to see how they work (or kept hers); I'll post those up here in addition to the palette above (I have it as a set of layers in Gimp, so it's not immediately convenient to post).

Good point about the wolfman; I'll add the fur colours from those.

Hi everyone, the conversations here https://opengameart.org/content/lpc-revised-character-basics and here https://opengameart.org/forumtopic/about-a-new-well-defined-lpc-specific... have motivated me to finally return to and complete my earlier work on these assets.

To summarize my work up until now:

• I made headless versions of all six "body types" in this submission ([adult] male, [adult] female, teen/androgynous, muscular, pregnant, and child).
• I cut out the heads for each body and used lpctools scripts to place them on the headless bodies
• I added minotaur and boarman heads from other submissions, child versions of lizard and orc from previous submissions, and drew new child minotaur and child boarman heads. 
• I edited all the headless bodies for consistency with the modular heads.
• I did this for all the animations in the "universal" sheet (cast, walk, slash, thrust, shoot, hurt), as well as for the "jump" animation.

Until now, the adult male and adult female bases have slightly different head positions. (Note that the positions of the female, pregnant, and teen heads are the same; the male and the muscular heads are the same as one another but different from the other three. Children are totally different). I sought to discover whether the (non-children) head positions could be unified. As argued by bzt and others, this would simplify some things since modular heads could be freely swapped between sexes, hair and hats could be used for both male and female bodies, etc. I am considering four changes to accomplish this:

1. Match female head positions to the male head position (changes the walk, slash, thrust, and hurt animations, but only the walk and slash require further changes). 

For the most part, moving the female heads to the same positions as the male heads works well, even for animations (hurt, thrust) where the positions were previously different. I was surprised to find this works well for the lizard and wolf heads too. See example attached. There are still a few very minor issues but the big ones are addressed below:

Two places where the female heads do not look good in the male positions: the east/west-facing walk animation, and the south-facing slash animation.

2. Adapt the chest in the female walk animation so movement of the torso matches movement of the head. This will require a 1px pixel shift of existing torso objects which can be automated. This will also bring the female walk in line with Eliza's female walk. 

For the walk animation, the problem is that the torso bobs in different places than the head. The solution that Eliza used here https://opengameart.org/content/lpc-revised-character-basics was to make the female torso move similarly to the male torso and thus keep the torso fixed in relation to the head; I think this is a good solution. It will require shifting existing torso assets by 1px on two frames, but that can be easily automated. 

3. Adapt the chest in (0-indexed) frame 1 of the south-facing female slash animation, moving it and the head slightly upward. This would likely require manual edits to all female torso assets.

For the slash animation, in the first non-idle frame, the female body crouches down further than the male; if the female head is placed in the male position, the neck looks abnormally long. I don't know that there is a good way to keep the existing female torso while moving the head to the same position as the male. 

4. Move the hands/arms in (0-indexed) frames 1, 3, 4, 5 of the south-facing female slash animation, bringing them in line with the male slash animations. This only tangentially related to the heads, but since we are talking about modifying the south-facing slash animation... This is the only animation in any direction where the hand positions differ significantly between the male and female bases. Harmonizing them would require manual edits to all female torso assets.

This is probably the most work, but it would also yield some immediate dividends, since a number of slash weapons were never specifically adapted to the female base (those in the "slash oversize layered" group in the generator); likewise the hand tools I recently uploaded don't look quite right for female bases. 

#1--3 seem like pretty clear winners. I'm most conflicted about #4. It would be a decent amount of work, but if it's going to happen, seems like now's the time to do it... What do you think? Have you noticed other incompatibilities between the male and female bases that should be addressed at this juncture?

To be clear, I am committed to updating all relevant assets in the generator to match these updated bodies;  I'll be moving swiftly to do so once we agree that the new bases are in good shape. 

Questions:

• Does these bases have standardized hand positions? (E.g. no need for female sword and male sword, one common sword sheet works for all).
• Are you planning to create guidelines out of these animations? (Contour, centerline, necklace line, pants line etc.)
• Are you planning to add further optional animations? (Most notably "sit", "jump", "run", "climb", "push")

If you answer "yes" to these questions, then I would gladly use this submission as a base for the spec instead of Eliza's guidelines.

Cheers,
bzt

Yes, we are working on all of those aspects, although obviously the current download does not have them. The plan is that the next release will. Several of us have been working hard on making improvements to this set behind the scenes for some time.  I will post a more detailed update soon showing that progress, but in brief:

- Headless bodies + Modular heads (done)

- All bodies except child share the same head positions as "male" body (done)

- Female, teen, and pregnant bodies updated to share hand positions with male and muscular bodies (done, we are in the process of updating and testing existing clothing assets with these updated bodies (this is a substantial effort and will take some time)

- Guidelines for the bodies (in progress, mostly done for the male body but still being tested and refined)

- Developing a run animation for all bodies (in progress)

- Adapting the sit and idle animations for all bodies (in progress)

The overarching goal is to preserve compatibility with as many existing assets as possible while making it easy for new assets to be developed. This is slow and tedious work though and will take some time yet to be finished. Anyone interested in contributing substantively to the art, feel free to send me a PM. 

@bluecarrot16: this is excellent news!

"All bodies except child share the same head positions as "male" body (done)"

Perfect!

"Female, teen, and pregnant bodies updated to share hand positions with male and muscular bodies"

Awesome!

This means no more duplicated assets! You have no idea for how long I've been waiting for this!

"Developing a run animation for all bodies" and "Adapting the sit and idle animations for all bodies"

IMHO these are nice to have, but not so important as the standardized positions.

"Anyone interested in contributing substantively to the art, feel free to send me a PM."

Sadly I'm no designer, what I can help with is to collect all of your work and make a clear and easy to follow compatibility specification of it. Also I can offer a converter tool that automatically converts old sheets into the new ones (for all assets except for clothes). I can also offer to use that tool and convert all the handheld assets and hats, so that only the clothes has to be redrawn by you.

This is really great news! When you have the guidelines (at least the contour and at least for the male), please share it and I'll update the spec with those! (Eliza's guidelines are really great, my only issue is that it's unfinished, there's no "cast", "splash", "thrust" animations. Here you're saying you already have these. Even if it's just for the male body, since the hands and head positions are standardized that means I can finally finish the spec and my converter tool using that one guide.)

Cheers,
bzt

Here's the mass sprite sheet converter tool I've promised.

Unfortunately I cannot provide a ready-to-use old sheet to new sheet conversion CSV for you until I get at least one full guideline, but you can try it out and play with it, there's an example identity mapping CSV. (Dependency-free, portable executable, pre-compiled for Linux and Windows.)

Hope this will be useful!

Cheers,
bzt