I am working on a slight re-organization of the assets in castelonia's generator https://github.com/sanderfrenken/Universal-LPC-Spritesheet-Character-Gen... which has number of duplicates, inconsistently-named assets, and some folder structures that don't make sense to me (for example, why is a formal coat torso/chain/formal/formal_iverness.png nested within the chain mail directory?)

After that, I'd like to re-introduce the scripts from JaidynReiman (aka jrconway3)'s fork https://github.com/jrconway3/Universal-LPC-spritesheet/tree/master/_build to recolor and auto-generate hair sprites. I have a few similar scripts for generating hats and shields.

I'd then like to carefully review several other adaptations which have attempted to fix some bugs in the animations, namely:

• ElizaWy's work here https://github.com/OpenGameArt/LiberatedPixelCup/tree/master/sprite/char...
• pvigier's work here https://gitlab.com/vagabondgame/lpc-characters.
• Basto's work here https://opengameart.org/content/lpc-modular-bodies-and-heads

and make sure their work is merged into the generator/spritesheet repo.

After that, I'll probably set up a system for programmatic recolors of the other clothing assets, based on the work from others.

I have other thoughts about the tilesets I'll post separately.

The frame 2 of the shoot animation has the same issue as the frame 2 of the thrust animation. I adapted a part of the clothing to my changes.

I plan to write a script to detect inconsistencies between the west and east directions in clothing. I already fixed some and I suspect there may be more.

Though I am not useful for doing the art my self (I also don't aspire to), I am very much willing to help and can help out also for example by commissioning part of the work you all aspire to (BenCreating and I are for example already in touch for a commission on completing the muscular base).

Also I would be very much interested in expanding the base animations with some basic actions like Lumberjacking, Farming and/ or Smithing, and create some new basic set of assets (clothes, hair etc) to accompany them (as I hypothesize that reusing any of the existing animations will be sub optimal for this purpose).

I have a few LPC character stuff that I've been working on in various stages of completion.

I merged the "unified spritesheet" with some of the extra animations, specifically the existing "grab" animation, the "run" animation and the "jump" animation. I've done some work on fitting shoes/trousers/shirts on those too. I'm not much of a pixel artist, let alone an animator, so it takes me a while to get something that looks ok, but I can certainly post those as a starting point to proceed from (they're not fully done; I keep thinking I'll have more time to work on it but things keep coming up). I also have a "carry" and "push" animation based on the normal walk cycle. The "grab" animation can work as a transition to the "push" animation.

I guess the things that I would like to see from the LPC bases fall in two categories: additional animations, and additional flexibility so it's easier to derive new sprites from them.

Number one on my wish-list and what I would really like to see and what I think would vastly improve the usability of the whole collection are separated layers for the different animations: head, torso, front arm, back arm, front leg, back leg. By ordering layers properly it becomes much easier to build up a complicated sprite. No need for special cut-outs for weapons, just layer them properly. No headache where the cutout of one item of clothing doesn't play nice with another item and you need to fiddle with the order (I can't remember what I had that issue with; might have been capes but it was a couple of years ago). It'll also be easier to make small changes to the animation, or build new animations by starting with moving body parts around.
This isn't particularly hard to do (I've done part of it anyway), but it is tedious.

What I would like next is a clearly documented set of instructions. Things like: what frame does the head bob on? How many pixels? What is the intended framerate for each animation? What frames are identical between different frames? What frames are simply mirrored? What things are there to look out for? Right now that is scattered in many different places.

Third on my wish-list is a more universal approach between the different bases. I think male and female heads are different? It's really silly to have a male and female version for the same headgear, even though it's easy to automate it. I find hands and feet similarly annoying. Is it possible to get at least hands and feet the same across the different bases, at least barbarian/male/female/pregnant/skeleton so they can all use the same weapon and footwear sprites?

Then we get to additional animations.
I like the idea of "lumberjack"/"chop", "farming", "smithing" animations (I guess a sideways and a forward two-handed smash as with an axe or a hammer could cover the first and the latter). Improved running/jumping animations would be neat as well.
Obviously I have a use for grab/push/carry animations, but I could also use a "pull" animation. The grab animation can serve as a transition to the "push" and "carry" animations, although the latter is a bit jerky. I use the third or fourth frame of the "cast" animation as a sleep "animation" (it's only a single frame, so...) There's probably something I forgot to add.
Oh, yes: swimming and sitting (mentioned above).

There are a few sets of "facial expressions" around that let you change the nose or mouth, or emote the eyes. I find none of them very convenient and satisfactory to use.

It would be neat of some of the more elaborate hair pieces were less static and things like braids actually swayed. Oh, and I've wanted a comically huge and long beard for ages (I suppose "Santa Claus beard" would be an adequate description, although "Panoramix" is a better one for those who know what I mean).

Finally: it's cool that work is already being done to extend the child bases to a full set of animations. I always figured they could be used to make dwarves as well, but I only ever got to the one frame as a proof-of-concept to myself.

Anyway, that's a long wall of text. Would it be convenient to organise what everyone is suggesting/working on and see who is willing to do what and in which order? I don't have a budget to spend on commissioning things, and as mentioned I'm not much of an artist and have limited time, but I'm willing to help as I can.

I'm generally -1 on anything that requires revising all existing assets, unless it can be done automatically (which I suspect is not the case for most modifications).

I think new animations are fine, but they will require a significant investment of work to build out items. We would benefit from someone doing careful experimentation to make animations that are useful for multiple purposes. Evert, could you share your work on this so far? (I know you posted it in another thread somewhere but I can't find it...)

Or someone making a concerted effort to draw optimal tool/weapon/object sprites to implement new animations (for instance, I think the axe chop animation that pvigier proposed could work well using the slash animation played in reverse, as long as someone drew the axe in proper perspective and with motion blur etc). IMO any new animations should use the absolute minimum number of frames possible. It sucks that the current walkcycle is like 12 frames... the last thing we need is a 20-frame run cycle---it will never get any clothes drawn because it will take forever :p

This conversation is making me think automatic recolors and spritesheet generation (e.g., take 4 directions of hair and a "hurt" animation and generate a full spritesheet) is very important, since it will allow many items to be adapted to different bases. I'll mention again that these tools already exist for hair, helmets, and shields, they just need to be re-integrated into the current file structure. Obviously it will never help for things like shirts, which depend on the underlying size/shape of the torso, not just the position of the head/hands.

Evert, can you also elaborate on your thoughts about separate layers? I'd strongly echo BenCreating's comment that requiring separate layers is a big hassle that may not be necessary. The only place i have encountered this conflict is with hats, where I've found it sufficient to have an "under-weapon" and an "over-weapon" layer, and even then it was only an issue for the south-facing "shoot" animations.

So, I have some thoughts on the LPC set, after having worked on them for a while.

1. The LPC Character set and the LPC Asset set don't really... necessarily go together. As in, I can choose another character sprite and use the LPC terrain / houses, and provided the colors worked, it'd do just fine. The same is true in reverse. So we can probably split any LPC discussion in two. Assets and Characters.

(I'm going to leave all non-character stuff to other creators. It's much too big for me, and my best work has always been focused on characters. That said, I do have some color palette work going on, so more on that in a bit.)

2. The LPC set was designed to be easy to create for, easy to replicate, easy to use. There is nothing dynamic about it. The bodies don't twist. We don't use dope sheets, and barely any smears.

Unfortunately, this lack of twisting puts a high focus on precision that maybe shouldn't be there. If nothing's twisting, then the blouse should stay perfectly still and even the slightest change upsets it. But the thing is-- a twisting body has way more leeway than a static one for nitpicky details. The important thing is to animate the seam lines and centerlines consistently. And that's something that can be templated.

The downside is-- smears, dope sheets, twisting poses aren't as accessible to beginners. On the other hand, I don't think adding a lot of new animations (which we desperately need for this set to continue to expand its versatility) are beginner friendly either. Sticking to a palette is also a branch off from the standard LPC set.

3. ...Well. I was going to wait a bit longer to announce this (I'm recovering from a long-term illness and it makes me unreliable), but... ah well.

I'm working on a complete LPC character overhaul. My current working title for it is LPC Revised.

LPC Revised Preview: https://imgur.com/a/iZs3mZq

I'm also planning on a two handed swing, a two-handed thrust, a lunge, a hit/impact animation, and maybe sprucing up the base walk a bit. The important part, however, will be those animated center / seam lines I'm showing on the run animation. Those will be the guides to adding in new apparel smoothly. Where the arm starts and stops has already been animated for you. I may do the same for drapery-- animated lines for long hair movement, cloaks and long coats.

Also, dope sheets are kind of required. There's a few 3-frame holds on that one-handed swing animation. I'm also using 24fps as my base.

The palette is also very much a WIP, and it's a bit less gaudy than some of the originals. I'll be revising it and tweaking it as I use it moving forward.

4. This is what I'm doing, but obviously no one else needs to adopt my standards. The head / body split will make it easy for someone using the original LPC set to plunk the old head onto my bodies and add my animations to projects that use the old sprites. Which should work just fine, though the change in style might stand out a bit.

It's so good to see you are still working on LPC ElizaWy! As always, I am amazed by the work you did :O

The previews you posted are so much alive, it really looks like a great improvement or a new start.

I am wondering how you would see that. Say, the animations you mention are there, and this new base sheet is finished. Then all the existing character assets are not usable anymore. Correct?
I don't think that is necessarily a bad thing. As you mention, all flora/ fauna/ buildings whatever still go with both the old and the new characters.

So then in essence, we are potentially looking at a "LPC2.0", with respect to the characters that is.
Maybe adapting existing assets for the LPC1.0 to the LPC2.0 can be done without too much effort (EG the shields, helmets and hairstyles, as long as there are proper scripts to generate the sheets from a couple of base images.

Personally, I would support an LPC2.0 set, I could even think about financing a new event like how the LPC1.0 started in 2012. But I am no expert, and for this to be a success (like LPC1.0) I think it should be supported by many if not all of us here.

In addition, I am still working intensively on Herodom, and I saw that knight armour you are working and I fell completely in love right away. It reminds me of the old lego knights like these:

https://img.bricklink.com/ItemImage/ML/cas250.png

Melancholia kicking in there.. Anyways, I would be very much interested in commissioning to finish that armour set with helmet for the current character sheet. I don't know if you would be interested in that, but if so, let me know:)

@castelonia - You know, I would be interested in doing that armor on commission. I designed it to be modular, with each piece independent and removeable from the others. I also have four more finished helms that I didn't preview. Shoot me a PM? :)

It's true that existing character assets won't line up to the new animations-- but the old idle and the first frame of the new idle will match, so the original designs can remain. Hair and helms will need to be altered as well, as I've taken a few pixels off the head to make it smaller. (Though since I'm separating the head from the body, including the old head as an option will be easy.)

When I do finish these, I'll be releasing it with a how-to guide, dopesheets, a color palette, and at least a few outfits. I've also been repurposing and redesigning a hair set as well, aiming for variety. That should be enough to get people started.

I think ElizaWy's new animations look nice, and I welcome her efforts. I'm looking forward to seeing her completed set of base animations.

But I'll reiterate my opinion that re-doing everything is probably the wrong direction for the community. I think the "easy to create for" is a very important value, for a community project. As ElizaWy mentioned, it also looks like the new animations would be more complicated to animate, raising the barrier to new contributions. It doesn't look to me like adapting the existing assets would be easy either, which means this would require mostly new art. I think it would be a shame to "lose" compatibility with all the existing art. (Of course, the old art doesn't go away, it just doesn't benefit from any improvements that ElizaWy or other "Revised LPC" contributors make).

Just my take. Again, nothing wrong with ElizaWy experimenting or going in a totally different direction---this is the point of free culture :) But if we're talking about working "as a community" on the project of the LPC characters, I think retaining existing contributions (as much as possible) and keeping things easy-to-contribute-to are important values.

@ElizaWy I will PM you right away :) Cool stuff you are working on, can't wait to see more of it.
With just some basic clothing and base sheets, maybe one can already make for example some designated lumberjacking villagers. In such a. way, one can combine LPC characters from the current set together with yours in one game for example

@Bluecarrot I think you have a very good point. I just went for designing some new enemies for Herodom, and noticed the incredible variety of characters built over the last 10(!!) years. Orcs, Skeletons, reptiles.. It's all there. It would be a shame to loose all that, so maybe some hybrid form as I describe above would still make Eliza's set useful in a game using both LPC base sets. Let's see what happens!

What we could do Bluecarrot (I see "we", but merely I would function again as just the useless commissioner..), as I think you thought about this well already and the subject keeps coming back, is work together on an improved axe weapon, and use the existing frames to create a nice chop animation as well for it. For example, a reverse slash as you mention. Or any other combination of existing frames: As long as we document properly which combination should be used, we can adapt the generator to generate the proper entries in the sheet, or one can opt to do it in-game instead. Would you like to take that on soon?

You know, would anybody be interested in a Discord server for the LPC set? We could share WIP and concept work directly pretty easily that way.

@BenCreating: good point about separate layers for new assets may be more of a hassle for creating new assets (or adopting existing ones). I was thinking that it would be ideal if it wasn't available just for base assets, but also for things like clothing, but perhaps that's false. Let me elaborate though.

What I personally look for is modularity and adaptability. I'm not a pixel artist, and modifying art for my specific purpose is easier if it's modular. Example: I made a "carry" animation from the walk cycle but with the arms raised. That was a bit of a hassle because I had to cut out the existing arms first and figure out what the torso should look like with the arms removed. It would have been easier if the arms had been on a separate layer to begin with. Having the arms separated also makes it easier to quickly make a mockup for a new animation, because you can just cut up the arms and move pixels around without worrying about fixing up the torso. Obviously, if all animations anyone could ever want were available by a proper pixel artist, that's not an issue, but realistically that's not going to happen.
I guess what I'd really like is something like an "open source library of pixel art", which to me means having not just the final sprites, but also to different layers the original author (may have) used to build the final sprite so that I can build on their work more easily.
From that perspective, I guess it's not so important to have arms on separate layers for each and every asset, as long as I have an easy way to tell the computer how to stack different layers and to tell it what pixels belong to the arms and which don't, so that I can layer a weapon (say) in front of the torso but behind the arm. I want to worry about what pixels go into my weapon, not what pixels I need to cut out in every frame to make it show up properly.

So for me personally, having arms, legs, heads and torsos available as separate layers from the base sprite would be really useful. Having it for cloting I would find nice, but optional and is probably impractical at best.

What I really like, and hadn't appreciated that I missed until now, are the coloured guides ElizaWy has on her new animations. Having those, perhaps in addition to some really basic clothing options (basic single colour ramp shading, no fluff or fine details) that show how things should animate would really help with making tweaks or additions.

Now, bluecarrot16 makes a good point about existing assets and new animations. It'd be a shame if it all had to be redone (probably not going to happen), but at the same time there are no assets available for things like the jump and running animations (this one: https://opengameart.org/content/lpc-runcycle-and-diagonal-walkcycle) partly because they're not part of the standard set and no one seems interested enough to add those in. So we're now getting to the situation where the extra animations are not useful because there are no clothing assets that work with them (and adjusting existing assets is a bit of a pain) and there's little point in making clothing assets work with those animations, because they're not standard or used as much.

One more thought to finish this novel off on. It's true that there can be multiple LPC characters that will work with the LPC tiles (in fact, there already are: https://opengameart.org/content/one-more-lpc-alternate-character; I thought there was more from this set, but perhaps not) and as such there is no reason not to have a "1.0" and "2.0" version. I will also say that having a set of more basic animations for enemy/NPC sprites and a more richly animated set of animations intended for player characters is not unreasonable. On the other hand, dividing resources (available artist time) over multiple sets rather than having a single good set is not good, and it's probably better to have one set with better variety. I guess I'm not sure what I think about that.

Ok, I see I didn't really reply to bluecarrot16 in my last message.

My desire for separate layers in part has to do with layering assets, but also to make it easier for someone else to work on the animations more later. I think of it as having the "source" to the final sprite.

Having tools to help automate things like spritesheet creation or taking things like hats and hair and putting them in the correct position is extremely important, but personally I sometimes find these to be unreasonably restrictive. A certain piece of headgear might be labelled "female only" and then I can't put it on a male sheet in the generator just to get an idea for how it looks and make modifications afterwards, so I find that I tend to just use the Gimp anyway.

I will also say that having a set of more basic animations for enemy/NPC sprites and a more richly animated set of animations intended for player characters is not unreasonable. On the other hand, dividing resources (available artist time) over multiple sets rather than having a single good set is not good, and it's probably better to have one set with better variety.

My thoughts exactly!

What I personally look for is modularity and adaptability. I'm not a pixel artist, and modifying art for my specific purpose is easier if it's modular ... Having the arms separated also makes it easier to quickly make a mockup for a new animation, because you can just cut up the arms and move pixels around without worrying about fixing up the torso.

I see. That may or may not be feasible depending on the specific part, but we could make it a goal. I do see now how the arms could be an issue when they are raised above the head (e.g. such that they overlay a helmet or hair). Hmm, let's think about that. I definitely think Basto's modular heads are an improvement, so arms/legs is the next logical step...

Another application would be having the arms move somewhat independently of the legs; like, you could have a walking thrust animation, or a person walking with their arms raised, just combining the existing upper- and lower-body animations...

Having tools to help automate things like spritesheet creation or taking things like hats and hair and putting them in the correct position is extremely important, but personally I sometimes find these to be unreasonably restrictive. A certain piece of headgear might be labelled "female only" and then I can't put it on a male sheet in the generator just to get an idea for how it looks and make modifications afterwards, so I find that I tend to just use the Gimp anyway.

There's two separate issues here:

1) the scripts can handle differences in male/female (as feasible); for example, the current hair scripts generates both a male and female version, which differ only slightly in the offsets and cutouts that are used. Cases where this couldn't be overcome include the example you gave above, where you're trying to generate a cutout but the shape of the cutout is variable depending on the piece that's being cut out... Hmm, I'm starting to come around to your idea that the arms should be on different layers...

2) whether the specific generator software allows you to make "illegal" combinations just to test something out. I think we could easily permit that.

You know, would anybody be interested in a Discord server for the LPC set? We could share WIP and concept work directly pretty easily that way.

Personally, I'd rather discussion stay on OGA as much as possible---makes it more likely that information is preserved. But maybe I'm just a dinosaur who doesn't want to use a different platform :)

Here's the swing in more detail-- note that it's not finished yet! I also haven't drawn my seam / center guidelines yet.

8 unique images, anticipation, action, and recovery marked. For fast repeated blows, the first two images can be omitted.

Attached are some of the modifications I made to the LPC sheets. These are flat PNG images, which aren't so useful, but I can't upload the GIMP .xcf files as attachment here, so I'll have to put those up elsewhere and provide a link.

The first is a "push" animation that continues on from the "grab" animation (I don't remember of the top of my head where that's from, but it's here in the LPC collection somewhere). It's just a walkcycle with changed arm positions.

The second is a work-in-not-so-much-progress for a dwarf based on the child base. I think the most relevant thing here are the beard and maybe the modified helmet. I don't think I touched the base itself.

The third is what my "standard" spritesheet looks like with the additional animations in there. I stuck them to the right because I don't like having a "narrow" spritesheet very much and also I didn't want to re-order any of the existing animations.

The fourth is the lift/carry animation I mentioned earlier; it looks like I made this not by modifying the actual base, but by modifying the finished sprite, which is stupid if true.

I'll come back with the "source" later.

a more consistent color palette, especially in the generators
Tilesets should have that problem, too. I think Skorpio deviates in his original sci-fi submission quite a bit. And my space tileset takes the colors of the original one instead of LPC's.

For Spritesheet stuff the following unified palettes would be very practical:

• Skin colors (so far I used ElizaWy's)
• Hair colors
• Clothing colors (fabric, leather)
• Metal colors (for amor)

If all use the same amount of colors and similar color distances within a palette set, it should be possible to swap palettes (just loading a different palette) without any manual work needed.

Somebody skilled in drawing should probably redesign the reptilean heads, their lighting does not fit with the rest.

I think the tilesets have a lot of issues of combining chairs, tables, cupboards, shelves and objects which are meant to be put on them.

extending the animation set to include new actions, such as swimming, sitting, or alternate attacks

Other classical RPG animations, we currently lack, are climbing, push/pull (stone block or something) and jumping (zelda has all of these)

I also have a "carry" and "push" animation based on the normal walk cycle.

I think I too might have some attempt on that lying around somewhere.

Basxto's work here https://opengameart.org/content/lpc-modular-bodies-and-heads

This does not fix animations, it just generalizes them by splitting bodies into several images and using cut masks (hand in front of head). If I remember correctly, I had to change a few things in the sprites to make automation easier. This submission is all about automation.
So far, I left out animations which cover the head since those get complicated if head forms differ too much.
Especially head wear could be easily automated in a similar way, it just needs a variation for each direction of each head. Long hear and everything that gets in front or behind the body is more complicated.
Clothing that gets in front of the head, would need specific head masks.

A lot of automated moving around, copying and cutting can be done with Image Magick, but that ruins the color order of indexed PNG, which makes palette swapping impossible.

Automating as much as possible also allows to propagate changes, made to the base sprites, more easily. On the other hand it makes a few things look worse, since you try to create as many similarities between frames as possible.

So far I did not dare to also dive into clothing automation, so I don't know how good it'll work.

By ordering layers properly it becomes much easier to build up a complicated sprite.

Head shadow on the upper body also heeds it's own layer.

I could try doing a new version of modular bodies, where I chop them up even more. But maybe with a different build process this time, which can be used by other people more easily ^^'.

It's basically interesting, because it would allow peg legs, hook hands, cyborg prothesis and such nice things.

What I would like next is a clearly documented set of instructions.

This could be automatically generated if you already have that animation in a machine readable form (which would be the case if spritesheets get assembled automatically)

I think male and female heads are different?

Take a look at my modular bodies, they are only partly different. The top is the same, so hats are universal, the jaw line of females is narrower. What you most likely ran into is the fact, that female heads are often a pixel lower than male ones.

There are a few sets of "facial expressions" around

Yep. they are hard to do. The eyes are small and the mouth isn't drawn at all. They could be integrated into modularized human heads. But they would be completely incompatible with other heads (wolf, ogre, drake).

Oh, and I've wanted a comically huge and long beard for ages

And that's where layering starts to get a bit more complicated.

I'm not much of an artist and have limited time

Me neither and I'm currently more in my low-level-C-phase than my pixelart-remix-phase.

Needing to split every new submission into pieces adds a complexity that we may not want.

On the other hand that makes it a lot easier to extend for others. If it does not contain duplicate frames, it should be a lot easier to create new assets. You just have to draw the torso once and then do the different arm parts, otherwise you will end up drawing the same thing again and again if you are not careful. If I use the Base animations as an example: the walking animation includes the same frame (legs parallel) twice and compared to standing they only have different legs and feet, the rest is the same. Also all animations start with the standang (same) frame. Deduplication definitely needs scripts for composition or at least documentation which frames have to be reused. Automation scripts (also script for creating gifs) can be a help for figuring out how to use the sheets ingame.

Like Evert, I definitely have more of a coder's view than an artist's. "Redundancy reduction". The less I have to repeat tasks, the better.

Also, I think more/better tools to automatically adapt items from one base to another would smooth this process out a lot.
This needs layering, though.

the last thing we need is a 20-frame run cycle

It is okay if >10 frames are just duplicates of other animations

LPC Revised Preview: https://imgur.com/a/iZs3mZq

Maybe you should use the dark brown for outlines (like the head) when other body parts are covered, as opposed to the dark gray used for the silhouette (EDIT: I was wrong, the base assets do it just like that)

I guess, LPC will just continue to fork and fragment more like it's often the case in Open Source Software. But that is again in my eyes an argument for layering, since it's easier to port stuff if you can easily figure out which parts you can reuse. The more spritesheets fragment, the more interesting it gets to do automated sheet generation.

I don't think that is necessarily a bad thing. As you mention, all flora/ fauna/ buildings whatever still go with both the old and the new characters.

Brave Nude World

Personally, I would support an LPC2.0 set, I could even think about financing a new event like how the LPC1.0 started in 2012.

A new Liberated Pixel Cup would be nice indeed, maybe a 10 Years Liberated Pixel Cup next year or something.

I think it would be a shame to "lose" compatibility with all the existing art.

afaik that's already the case, because there are various variations of the base sprites around and clothing submissions might be based on different versions.
But like castelonia said, you can always combine different base sprites. NPCs only have to stand and maybe around, so they can use the original sprites. And NPCs are probably what needs most clothing variations.

You know, would anybody be interested in a Discord server for the LPC set?

I don't like discord "server"s, it's very unfree and centralistic.
It's not publically accessible and everything will be lost if Discord gets discontinued. OGA can be archived with archive.org
Thouh, it should rather be a group within the OGA "server".

but at the same time there are no assets available for things like the jump and running animations (this one: https://opengameart.org/content/lpc-runcycle-and-diagonal-walkcycle)

I'd never include them, since I did not like the animations, but yes, every animation not part of the Base Assets is not covered by all

Some animations which where created during the cup are widely adopted, like wulax's thrust and bow animations. Skorpio's two handed gun animation on the other hand was widely ignored, despite also being an original cup submission.

TL;DR: I'm in general very interested in quantity over quality automatization. Aggressive automation needs layers in seperate PNGs for automatic composition and indexed 8bit PNGs with standardized color orders for palette swapping. If palettes of different materials share colors, palette swapping also might need subpalettes or different material being separated into different layers.

...maybe I gonna do modularized bodies 2.0 with some basic clothings, depending on where my procrastinating makes me end up. In either case it would be more a technical demo like the first one. Maybe just with GNU Make, GNU core utilities, shell scripting, Image Magick, gifsicle and loadpgl (python3+pypng) this time.

head, torso, front arm, back arm, front leg, back leg

That's probably the best idea.

And I just counted the frames of original assets (walkcycle, slash, hurt, spellcast), they have 94 frames, of which are 40 either duplicates or mirrored versions of other ones.

Since I can't add any zips here and since modular bodies is already a git repository, I think I gonna tinker with it on github: https://github.com/basxto/lpc-modular-characters

I don't think I start using more layers yet, but I'll try to improve the build process a bit. I'll just play around with the original walk cycle and layers in a temporary directory.

but I feel like the work of modifying the existing animations and creating new ones comes out about the same. Either way, someone will have to modify old assets to fit, so I don't think we should rule out updating the animations altogether.

That's not quite fair---if it's X hours to create a new run cycle and also X hours to re-do the walk cycle, all things equal I'd prefer we spend the time to make a run cycle, since we already have a walk cycle, where as a run cycle creates new gameplay possibilities (even if not all clothing is adapted right away). Plus, the changes proposed above to "fix bugs" in the bases (even if propagating the changes to all the other assets) are trivial in comparison to completely re-drawing all assets, which is what ElizaWy's new animations would require. Finally, I'll mention that if we are updating the existing animations, I would like to see them go in the opposite direction---fewer frames (the walkcycle being the most egregious example), minimal extranous motion, frames re-used where possible, etc., to make it as easy to contribute as possible.

Yes, a simplified animation set for enemies would be amazing! Especially if it could share enough frames with the player set that assets would be easy to adapt between them.

I think the idea was that the simplified set would be a proper subset of the full set. For instance, an NPC might only need walk, or walk/slash/hurt.

I think it would be a shame to "lose" compatibility with all the existing art.

afaik that's already the case, because there are various variations of the base sprites around and clothing submissions might be based on different versions.

No, I don't think that's right---the majority of clothes/weapons work with at least the male and female adult human bases; most work with the various humanoids that just have different heads (lizard, wolfman, orc), or could be made to work with small modifications. If you're talking about differences between the "vanilla" base sprite and the "bug-fixed" versions that Evert, BenCreating, pvigier, et al. have been sharing, those are tiny changes in comparison to completely re-drawing.

Say ElizaWy's "LPC 2.0" bases are released. If someone makes a new shirt, drawing all the animations on that base---that new shirt can't be used on any of the existing bases or their animations. By contrast, if we tidy up the existing bases, remove trivial differences, build some good tools to reduce the amount of duplication necessary, etc., then a "new" shirt can be mixed and matched with dozens of "old" pants, hats, swords, belts, etc.---for human, orc, lizard-people, etc. Further, if we agree on a new animation that otherwise uses the existing base, then thousands of assets can be adapted to that base just by drawing the new animation. Perhaps I'm belaboring the point.

I also have a feeling that even if we make any drastic changes, at least some of the old animations would still be used quite a bit, just not for their original purposes.

This is a good point, which is why I suggested a careful study of all existing animations (and proposed new animations), to see that as much as possible could be re-used across multiple animations/applications (for example, if designing a new push/pull/grab animation, it would be great if many frames were shared). This approach might require some compromises, compared to drawing bespoke animations from scratch. But I think the underlying principle should be that contributing items is as easy as possible---meaning the animations have the minimum number of frames necessary, variation between the bases is minimized (where possible), and so on.

Here is a draft list of possible new "motions"/"actions", based on some suggestions in this thread. I would propose we think about which ones would be most useful and whether/how they could be combined into a minimum set of animations.

• Run (TheraHedwig and ElizaWy have prototypes)
• Jump (MuffinElZangano and Durrani: https://opengameart.org/content/lpc-male-jumping-animation-by-durrani)
• Chop (chopping trees/wood, mining with pickaxe, etc.)
• Climb
• Push
• Pull (could also be used to pull vegetables out of the ground?)
• Grab
• Carry
• Give/present/hand object to
• Swim
• Sleep
• Sit
• Alternate sword/spear attack (parry?)
• Guard/block
• "Craft"/"Interact"/"Work"? (I'm thinking things like crafting, cooking, etc.; something where the character moves their arms to interact with a waist-high object in front of them)
• Throw (overhead, or one-handed)
• One-handed shoot (pistol)
• Two-handed shoot (rifle)
• Handshake

Finally, I'll reiterate that my goal is not to dissuade ElizaWy from working on whatever she wants! But I'd encourage others who are on the fence to continue building on what we have instead. The amount of effort to re-create the existing art would be measured in the hundreds or thousands of hours (much of which would need to be done by more experienced animators, whereas a lot of the tweaking and bug-fixing we're talking about can be done by beginners or programmers who dabble in art). And that's just to bring us to the space of gameplay possibilities we have now. Why would we not invest that effort towards new possibilities instead?

I think the tilesets have a lot of issues of combining chairs, tables, cupboards, shelves and objects which are meant to be put on them.

I'm definitely interested in working on this. It's one of my priorities for the furniture set, and I think we can come up with a good solution.

I would like to see them go in the opposite direction---fewer frames

I first switch my build system to what I used for the portraits. Then I'll update the heads, wanna include Ben's new wolf head and if possible the zombie. Then I'll try to split stuff into layers, I need that for (bow) shooting animation anyways, that's why I stopped last time. If that worked, I gonna see how hard it is to build/port clothings based on that.
And then I'll see what animations can be achieved by recombining the frames in new ways, well that's what the modular set is about ... creating new variation with as little as effort as possible. Maybe I can even get back to my superhero stuff, I stopped because it became annoyingly repetitive.

• One-handed shoot (pistol)
• Two-handed shoot (rifle)

As said, [LPC] Skorpio's SciFi Sprite Pack has a shooting animation. I looked into it again, it's two handed pistol _and_ two handed rifle in one. It's the walking animation with different hands, so this should benefit from layering, since only the arms have to be redone. (and we could easily make one handed shooting by giving the other hand a different animation)

I think I will continue using the simple csv format, which I used for positioning heads. It's just tile id, x-offset, y-offset. I will extend it so that a negative id means it's mirrored, but aside from that it should be sufficient. Are there any other formats around?

https://github.com/basxto/lpc-shell-tools/blob/master/animation/head/fem...

I'm done splitting the walkcycle.
I modified it a bit here and there.
I'll also attach a gif and recombined spritesheet.
But I have yet to playe around with this and clothings.

EDIT:

The mapping rules are located here

Any ideas which clothing submissions are best for testing? Something in fabric (flexible) as well as metal (stiff) and with few (maybe just standing) animations supported as well as many (original animations and wulax's) would be practical, I guess.

EDIT2: I expanded the mapping syntax a bit. index;; defaults to index;0;0 and there are now multiple ways of defining the index. :row:column, #column (with current row in csv), -index mirrors the tile and can be combined with : and #, otherwise the index is just counted left to right, top to bottom. (the last notation is impractical if the image width is expected to change) # is practical if the image is organized in 4 rows, each for a direction. : is practical for mirroring left direction for getting right direction.

EDIT3: I guess I'll go with:

• flexible few: character1 or agent1 from [LPC] Skorpio's SciFi Sprite Pack
• stiff few: Xeon from Four characters: My LPC entries
• flexible many: peasant from [LPC] Medieval fantasy character sprites
• stiff many: knight from [LPC] Medieval fantasy character sprites

Regarding the animations:

The grab animation is from Daneeklu's LPC submission, which was resubmitted as [LPC] Farming tilesets, magic animations and UI elements
I guess we need different kinds of push/pull, depending on the size of an object? Pushing a wheelbarrow is quite different from push a man-high rock in a.

Is sleeping more than standing facing down and combining it with closing eyes from spellcast?

Swimming is probably just the upper body and keeping everything under water hidden?

Chopping should also be waist high, biggest difference towards crafting is probably dual-wielded tool usage. This overlaps somewhat with the tileset reworking of tables and objects you can put on them, since the animation will interact with those objects.

Carry shares, at least if it's overhead, problems with bow shooting and every other gesture that would press arms or hands against the head. It would only work for the human heads and has to be redone for every differently sized head.

Handshakes are also highly problematic, it would pretty much be restricted to bare handed characters since every glove would need cut outs for every other glove. Or I'm overthinking this.

EDIT: This animation also does exist, I have no idea how that should be called [LPC] caeles' art, but some frames could be reused for crafting.

(all what I say about animations is only about male)

Frame duplicates and mirrors (if you ignore the head) are nice indeed, also for transitioning to standing pose or a different animation. Walkcycle has two frames, which can transition to to standing, so it's never more than 3 frames away from standing. This is especially for actions which are very likely interruptible like walking and running, it should also not look too bad if somebody decides to directly switch to standing. It would probably also be good if you can transition from walking to running and back every frame.

But there are also other ways of reuse, you don't have to duplicate the frame, just legs, torso or arms helps already a lot. You don't have to completely redraw and instead just reposition and draw the transitions between body parts. Thrust animation uses this a lot. From food wear perspective it's 2-3 new frames per direction, despite having 5 completely unique frames. One frame of the sideways animation is nearly the same in thrust and bow shooting, only the wrist rotation is different.

I think the original cup submissions should be definitely streamlined since they were developed in parallel. Drag and thrust sideway animations could be more similar. Gun shooting does not really look good, I think some parts of bow shooting could be merged into it. Both utilize outflung arms, but they are drawn differently.

And maybe we should produce some visual manual on how to draw the frames, what can be reused etc. Guidance to which frames (the least covered version like frame 10 from bow shooting) should be drawn first, since they can be reused in other frames. Or even the production of dummy frames derived from my layered stuff to ease drawing of parts, which are reused but also covered a lot. Layers could also help to build visualizations where duplicate parts are tinted red.

This would help showing new contributors how much work has to be done. I only once drew something for the sprite sheets and remember that I drew a lot of duplicates, but only realized that when it was too late.

I haven't yet started playing with layered clothes, but while looking through the existing animations, I realized that won't be enough. I'll also need to make cut outs and make sure that body part transitions aren't cut out. Shoulder should be behind the head, but the forearm and hand in front of it. Shoulder of the back arm should be infront of the torso (I think armor needs this) but the rest has to be behind the body. The big pro for automating clothes is that you can easily apply retextures like my Major Triumph shield to the base frames and immediately have a full spritesheet.

Another huge problem with LPC is information distribution. Whatever we agree on in here will be unknown to new contributors. I think ideally we should link the LPC Collection, add an extended art guide for the animations, maybe even integrate or link some sprite generators on lpc.opengameart.org. The code is open source, the linked repo has vanished, but https://github.com/OpenGameArt/LiberatedPixelCup does still exist.

I imagine swimming could be something like this, reusing three frames from spellcasting.
The guy would do dry swimming and the water is added with an overlay to cover clothings (shirts, but not belts or pants), this would allow to use the spellcast clothings as is. Only four new arms have to be drawn per direction

For something like the walk cycle, I wouldn't want to see any modifications that change the outline. It would break compatibility with old assets, without adding a lot of value. Small changes to the shading, maybe, but nothing beyond that.

True that, I think I accidentially changed the outline in one frame and on purpose on the side walking torsos. I have to do a image diff later and see how bad it is. I got a bit lazy lazy with the sideway torsos at some point.
The common animations shouldn't change their basic shape: original assets and wulax, for the rest it probably does not matter much, there it's better if new ones are easy to create/port

Each color is a torso shape

I don't know how you define shape, but I know that in sidewalking the second (not black) torso is one pixel shorter in height than the first. the fourth and sixth (this one is marked as duplicate, but isn't one) one have definitely different shapes, the right side of them have different angles (that's the thing I changed in mine) and they also all have different textures even with same shape, since the nipples are moving to indicate a slight torso rotation as well as arm shadows.
And I'd expect thrust to use both torsos of slash, since it uses both feet from there and feet, so they probably have the same rotation.

Speaking of automation, I'd really like to see tools with a UI. The shell scripts we have are great, but in my experience, many artists won't use anything without a visual interface.

I think that's an argument for well decumented and easy to parse mapping format, so that various tools can be built for it.

It would most likely be a one button application, unless you want to support multiple clothings at a time. But you could visualize which original part went where in the final spritesheet, which would be probably very nice.
I should keep in mind to make the steps I take as easy to implement as possible and not use too much magic from Image Magic.

Scripts are a lot faster to develop and change, so I don't think an GUI makes before we are sure what steps and layers we need. My focus is indeed more on batch processing huge quantities, even though the current script is quite slow in doing that. duplimap.sh is awfully slow :/. And you also can always build GUI applications, which wrap some cli-only stuff, but that would be probably very ineffective in this case.

I'm also thinking about whether could be handled differently, theoretically one could draw some shadow mask and let all shadowed pixels climb in the palette/colormap, since that seems how shadow is often drawn. (arm over torso, head over torso and such)

I attached the mapped torso spritesheet, not sure how obvoious it is how different some are and where I cheated. (did not attach them before since that blows up everything a lot)

And I'm thrilled to see your take on the swimming stuff.

I'm gonna add one frame from slash and shoot to my tests, since they have have nice head related overlaps. But aside from that I'll stick to walkcycle for now until I've found a satisfying format for mapping, layering and cutting. It's hard to separate torso and arms, because of the shadow cast by arms and all the stuff going on around the sholders.

• Climb
  • Are there any LPC ladders that this would need to match?

"mountains, cliffs, walls, and slopes" from original assets has latters, but I would not make an animation for the diagonal ones

• Hurt/impact
  • The first few frames of this should be the guard/block animation. Otherwise, we would need a second version of this for blocking.

We are not required do animations really sequentially, we can start with two different transition frames that guides guard and stand to the same animation.

• Punch
  • We can likely just use the lunge/stab, or the slash if we use Eliza's.

If this is a separate animation, we should probably just change the hands compared to stab, that way only gloves have to be redrawn.

• Shoot, two-handed (rifle)
  • Possibly use the thrust arm position for carrying, and move it to the bow position for firing.

It would be desirable if Skorpio's guns or repositioned versions of them can be used with it.

Regarding the swimming animation there should be a new frame between first and second, where hands are really pressed together and pointing forward like the hand gesture some japanese people do when bowing. He has to part the water somehow. Third frame can work, we have to see how this looks in animation. Second and third probably need a different different hands, but it absolutely makes sense to take that one fram from grabbing.

I attached an example for how sleeping could be done. The arms are from standing, the legs are from walking, the torso has a new deformation (belly and chest one pixel higher, but it's basically from the walking frame) and the head has a new perspective, but it could also be used with the regular heads, they have the same outline after all. Especially if the head is resting on a pillow it would be plausible if the head is more angled. Lying on the side probably needs more modifications

Hey! I keep slowly fixing issues with items. I just finished reworking the spear and the shovel for male and female characters (fixed the thrust animation and rework the walking animation, see the joined gifs).

Where do you want me to upload the reworked spritesheets? In a new submission on OGA? Here? In a particular git repo? In all cases, I will upload them on my repo.

The spear should probably overlap the hand a bit and make it look like it's being hold, similar to how it's done in the thrust animation

Okay, I don't think the layering doesn't make that much sense in general, I don't see a general way of doing it, body parts behave differently in different animations.

I definitely want to split all as many heads as possible, so that I can easily use them with different heads.

For some animations we would benefit from splitting things. Splitting arms and torso/legs in walkcycle would make sense, sine that's reused quite a bit. The current gun shooting animation and Evert's push only change the arms. So for the creation of new assets it's helpful to have a base that only has to be modified a little here and there. And animations like bow shooting, where torso and legs are often unchanged. And maybe body parts which are reused a lot.

I attached a spritesheet with all animations, I currently downloaded...
Are those all animations which are currently released?
I automatically fixed the color accidents of wulax's animations.
For Skoprio's and the original animations I changed the transparent pixels only.
Fixed a few black pixels in grab.
Where are the animation fixes located? And what exactly did they fix.
I want to do update all to their newest versions and then make first sure colors are right everywhere and remove differences between frames and body parts who should be the same.
I added an overlay with notes for myself what are [D]uplicated and [M]irrored tiles (ignoring head reflection). [R]eused is for tiles which only differ in a few pixels, I just used it once and have no clear definition for it yet.

Okay, I don't think the layering doesn't make that much sense in general, I don't see a general way of doing it, body parts behave differently in different animations.

I'm confused :p Are you saying the layering is a bad idea? If I understood Evert's original comment, the layering would solve two problems:

1. Sometimes the arms go over the head/face, so right now you need a "cutout" on hats, hair, etc. so the arms can show through. If the front arm was on a separate layer, that cutout wouldn't be necessary. Relatedly, for the bow shoot animation (and others), in frames where only one arm is moving, the artist wouldn't have to re-draw the torso
2. You could combine the upper body and lower body from two different animations (e.g. as you pointed out, for Skorpio's two-hand gun animation, artists could just replace the torso and arms and the shell tools could fill in the lower body with frames/layers from the walk animation)

Where are the animation fixes located? And what exactly did they fix.

Here is BenCreating's draft of the female base: https://opengameart.org/comment/89342#comment-89342

Where do you want me to upload the reworked spritesheets? In a new submission on OGA? Here? In a particular git repo? In all cases, I will upload them on my repo.

pvigier, please upload to a new submission on OGA; that will make attribution/record-keeping much easier. We should probably set up a git repo for this little project so we can have a "working copy" of the animations and don't branch off/duplicate work accidentally.

Tools

Speaking of automation, I'd really like to see tools with a UI. The shell scripts we have are great, but in my experience, many artists won't use anything without a visual interface.

Pretty much agree with Basto about this. I envision two sets of tools:

• Command-line "build" tools, which take a partial spritesheet and construct a full spritesheet (possibly with multiple layers) with all animations, duplicated/mirrored images, etc. These would be descendents of JaidynReiman's ruby scripts and/or Basto's code for the heads
• Graphical "character creator" tools, which assemble multiple spritesheets (possibly in layers) for a base, clothing, weapon, etc. These would be more similar to guarav0/JaidynReiman/castelonia's generators. It might be helpful if there was a command-line version of these as well, which could be incorporated into a build process. Refactoring such that the logic for assembling sheets is contained in a small node.js module that can be built for browser would be one solution.

I think it's most important that the "build" can be used to really quickly iterate/preview designs. So it might be helpful if it could also generate GIF previews.

Animations list

This is a great conversation. A few more thoughts:

• Swim:
  • We could also use the lower body from the "run" animation for this, combined with arms as Basto and BenCreating have proposed; TheraHedwig's run animation has the torso tilted diagonally forward, and the legs slowed down could be kinda kicking for swimming. That way it would work for underwater levels, or with a semitransparent overlay for swimming at the surface.
• Push/Pull:

  • I think these should be for heavy objects. The character really needs to lean into/away from the object to make this feel right. Like pushing a block in a Zelda game.

    At least for the "push", this could also borrow from the "run" animation---maybe the torso and lower body are the same and the arms are just held out in front of the character, pushing. Not sure about pulling.

• Grab:
  • I'm having a hard time understanding Daneeklu's/BenCreating's animation here... Can you show an example of how it would be used?

And just to add more chaos, a few more possibilities:

• Nod
• Look up (could potentially use same frames as "nod")
• Shake head ("no")

I'm reticent about these three, because they would require a lot more animation of the hair/hats, which currently don't need to be animated much at all (although animating hair for the run animation would be nice, it's not mandatory right now).

• Dig/hoe: this could probably be accomplished with the current thrust animation, though I haven't tried yet

Okay, I added the running animation und updated the post above. (I will keep it updated, I don't see a reason to post it multiple times)

Also, the left-facing bow and thrust animations have the wrong head.

I only converted all animations to the attached palette and fixed issues arising from doing that. I kept the heads as wrong as wulax created them. I will create a new sheet for the edited versions, with markings on [E]dited frames.

Are you saying the layering is a bad idea?

At least the layering, how I did it, wasn't a good idea.
I made those layers foremost for reassembling the bodies correctly, that alone makes it more complicated. I tried to reuse parts for several frames, which also required to draw some pixels which aren't visible. I had a layer for front/back arms/legs, but the left/right arm/leg was always completely on one layer. It does not work that way.

What might work is: (I see sholders as part of the arm)

1. arm parts below torso
2. torso with legs
3. arm parts below head
4. head
5. arm parts above head

This does not allow to use left and right hand separately, well neither was it really possible before. But that could also be interesting. Like a walking animation where one arm has less motion because it's carrying a spear/bow. It could make it easier to draw weapons, but it's only worth it if there is not many clothing pixels that have to be redrawn, or even better if none have to.

that will make attribution/record-keeping much easier.

I agree in pvigier's case, but at least for the characters bases we should aim for one submission with multiple authors/maintainers. We can still specify per animation attribution in a markdown or text file and from this threads history we should know who did what. I'd expect that to make it a lot easier for those want to create new clothings.

Command-line "build" tools, which take a partial spritesheet and construct a full spritesheet (possibly with multiple layers) with all animations, duplicated/mirrored images, etc.

But I agree with BenCreating there, those who upload submissions have to use them, that includes being able/feeling comfortable to do so.

Basto's code for the heads

I used it only for heads, but it was never limited to them.

So it might be helpful if it could also generate GIF previews.

If this is relating the the build/shell tools, that can easily be done with short makefile:

%.gif: %.png
magick convert -background none -delay 16 $< -crop 64x +repage -set dispose background -loop 0 -layers optimize -compress LZW $@

It might be helpful if there was a command-line version of these as well, which could be incorporated into a build process.

Well, for that you can backport my cli-version of the character creator, which runs with nodejs.

Regarding the animations: I used a looking up head in my lying down sketch, but in general I don't think they are a good idea. People who can't really draw won't be able to port old assets to new animations, if they use new perspectives resulting from tilting/rotating. The sideways heads are already a pain, the original "hurt" animation as well. I would actually prefere to have a running animation based on the jumping (third and fourth frame) animation, which does not tilt heads. That's why I tend to forget that there is already a running animation.

And please write me basxto in ASCII. If I'd rename myself, links to my account would break.

On a related topic, I'd like to see the tools have more support for exporting separate animations, instead of having everything in a single image.

I always create separate images per animation, all my mapping rules are targeting that.

The big image I posted a few posts above is for getting an good overview and make it easier for me to find.
Aside from that I only concatenate images when I upload them to reduce the amount of images, they are always combined with "magick montage -mode concatenate -tile 1x -background none " or something similar.

My character generator also uses a canvas per animation in contrast to sanderfrenken's. In my eyes those character generators are only previews and combining and palette swapping should be done by the engine, there is no reason to have more than one color of everything. Modular bodies does create one big sheet in the last step, but sheets per animation in the second last one.

That's also why I wouldn't attribute any submission, which just replaces the palette with another already existing one or who concatenate or reorder other submissions. That edit does not get past the threshold of originality needed by copyright law, I can easily recreate that in a minute or so.

Color palettes themself are also not copyrightable, but I credit them out of respect (not the considerate one, but the one with high esteem).

but it discourages adding new animations because modifying the sheet breaks compatibility with existing assets.

There are some defacto standards of arranging the animations. I put the die/hurt animation first, since it's usually added as last, which is bad compatibility wise.

It's interesting to see how many similar ideas there are going around.

I'd thought about using the cast animation as a basis for a swim animation, but I hadn't considered mixing in frames from the grab animation. I think that works quite nicely as a place-holder at least.

I think I made my overhead-carry animation by just taking the arms from the first (idle) frame and flipping them.

I use the 5th frame of the sideways thrust animation as a "present" or "give" frame. It works ok for that, but the front facing frame really doesn't.

I like having the arms in a separate layer also because that's almost always the first thing I do when I want to make modifications or additions: cut out the arms so I can easily animate them separately. Perhaps that's specific to my workflow though.
One neat thing about having arms separate in order to compose something: it doesn't only allow you to combine "walking" and "attacking" (say), it'll also be useful for riding animations (I guess that's really a solved problem, but one of the reasons I personally find these a bit of a hassle is that this separation isn't standard).

About the shake head animation bluecarrot16 mentioned above: one thing I wanted to try but didn't get around to yet is to see how using the head from the neighbouring directions would look. So use the left and right facing heads on the front facing animation. There's a caveat with the backward frame (you need to change the order in which the layers are stacked), and I suspect it will not work well for the side facing frames at any rate.

Two other thoughts:
Some of the animation sequences are long, which is tedious, but personally I really like the 8-frame walk animation. Certainly compared to the most common alternative, which is a 4-frame walk cycle. I don't think that looks very good on higher resolution pixel art.
The shoot animation seems overly long, but part of that is the lead-in and repeat/recover animations. I always find myself having to look up how to use those correctly in the original submission. I'd be nice if there was some uniformity between different animations in this regard (I think the "shoot" and "thrust" animations have leadin/repeat cycles, but the other ones don't).

Do we want to change the layout of the spritesheets?
I like having each animation and direction clearly separate from the other animations and directions, however, I really don't like that the spritesheets turn into these tall and narrow images. I always worry that I'm going to run into some limitation on texture size if these are too far off (then again, spritesheets get loaded into a texture atlas at runtime anyway; I probably worry too much).
It's probably worth thinking and talking about before we end up with different incompatible layouts.

Attached are two quick tests for a crouch animation (the first three frames of the "death" animation with the normal head) and for a shake/turn head animation.
The first I think looks decent enough (but we only have the one direction). The second doesn't work as well with the body angled to the side. With the body facing front I actually think it looks ok-ish. Certainly for being a simple head-swap.
There are "diagonal" walk/run cycles that have heads in intermediate positions, perhaps those would work better or improve the animation - if there were assets for them.

I always worry that I'm going to run into some limitation on texture size

I'm currently at 2368px hight and since modern systems should be fine handling HD textures, I don't think we'll hit limitations there. But I never worked with textures or games on modern hardware.

May platform of choice is only capable of fitting 32 64x64 tiles into sprite VRAM without further packing and deduplication. You wouldn't use LPC there, since it's in general way too big. But 32 tiles is already the full thrust animation

I guess in the end you have to see what your target engine/platform can handle.

If you really have to crunch down on size, just write a tool for packing it. On gameboy games don't store duplicate 8x8 tiles and for sprites they even remove mirrored duplicates (original gameboy can only mirror sprites, but not background tiles). That also reduces the overall size of a game, which is pretty irrelevant these days.

I attached a manually packed spritesheet. But you can certainly do that easier automated, just split your original image into a packed image and a 2D array representing the original image (aka LookUp Table), where each value is an index of the packed image (counted left to right, top to bottom). You can throw out full duplicates and empty tiles like I did in the manually packed one, you just use the same index at multiple positions within the array. And you just tell your packer to make width and height as close to each other as possible.

The lawnmower animation also has diagonal heads, but only top-left and top-right are new heads. And the heads have in general different lighting. https://opengameart.org/content/lpc-caeles-art

This is my first proposal for fixing thrust and bow shooting.

Everything with an E in the top right corner was edited compared to wulax's version.

Second row of thrust and bow shooting just have the light reflections fixed.
The edit in the first row of bow shooting just changes one pixel to make two tiles full duplicates.

For the first row of thrust I changed more, the second and third frame are now full duplicates of the ones from bow shooting, even though moved by one pixel. For that I had to also change the feet of all following frames, but I think that looks better than before and matches the downward direction. And there are not many changes needed for currently existing assets, foot wear can just copy the already drawn foot from the third frame, it's the same shape. The changes in the third frame will impact weapons, since the arm moved down by one pixel.

A little bit sketching around.

The first 6 rows (Die, Jump, Run) are about tilted heads. Jumping and running use tilts which are already included in "hurt", the each second row is the streamlined one.

I added the new eyes to "hurt" but kept it's shape because of compatiblity. They look more alive this way, so that should be useful for kneeling and other animations who reuse frames from this. The eyes who lose their shine are interesting for dying, though. Both versions should be usable alongside, since they only differ in the eye pixels, that should affect no current assets.

The next two rows (Run) are about how running works. It's not in sync with walking, which I dislike aside from the new head tilts. Just doing a more extreme motion like it's done it jumping should work, I don't think we need to tilt the torso that much. I don't even think you'd tilt that much while running, but it is certainly tilted a bit.

For Thrust and Bow I composed a new second frame, which is nearly a copy of a frame from spellcast, just the hand in the background and the eyes are different. This would certainly be incompatible with all old assets, but for clothings you just need to merge it with the frame from spellcast and the weapons would need a bit different cutout. But this would save us one unique arm angle for clothings.

Last is my first try of rebuilding the gun animation with arms from walking and two frames from bow shooting, yet again to get to less different arm poses, that have to be drawn. Well, the original back arm doesn't look good at all.

But I haven't tested any of those with weapons, yet.

Edit: My changes for thrust and bow shooting seem to work with weapons, I just had to duplicate a few pixels. But the gun shooting pose needs more work.

Edit2: I played around with the guns and attached the second draft. I'm not content, though. The stretched out arm and/or the guns have to definitely change more.

A few thoughts--

1. If you use TheraHedwig's run, you will either need to replace the tilted head or redraw every hair, hat, and head accessory asset. I have tried to make that run work before, and I've always had problems with it, particularly some over-shading that breaks from the style of the rest of the set. It also doesn't read well.

2. As far as I know, no assets have been released for TheraHedwig's run or jump yet, so you're in the 'no assets available' realms already, and changes can still be made freely to the bases.

3. I HEAVILY advise you to preview animations before you spend any significant amount of time with them, and ideally as you work with them. I've tried mixing key poses from other sets before, and the result wasn't pretty. Or even clear what it was supposed to be. In the end, I've found it would have been better looking and easier to draw things from scratch.

4. My LPC project has switched to a unisex base, based off Redshrike's female, and I've made the breasts an asset than can be added or omitted. This has saved a ton of effort, and might be worth consideration.

5. I suggest splitting the sprite sheet into different sprite sheets, one per animation. I'd even recommend splitting the idle from the walk cycle. Most people don't seem to realize that the 'walk' rows are actually a standing frame and then an eight-frame walk, and what you get is a nine-frame animation where the legs stutter and splay out every cycle.

What's more, if LPC is expanded on, you're going to make LPC suitable for, say, platformers as well as RPGs. A platformer dev might have no use for the casting or thrusting animations, and might not want to include them. Worth thinking about.

6. I can't recommend an off-site version control system enough, with some strict guidelines, and animated gifs demonstrating the animation. It's easy to recolor an asset sheet. It's easy to correct an error on an asset sheet. It's hard to correct the same error on ten asset sheets in ten different colors. Have a master set, in one tone.

Thanks Eliza, these are all really good points.

1 and 2. You're totally right about the tilted head; I think as a general rule we should avoid the number/amount of head tilts, since right now hair and hats can be added only drawing the 3 directions plus the "hurt" cycle.

3. Agreed about previewing the animations; I'd like to add gif generators to the shell tools and the "character creator."

Something that our more code-inclined colleagues could help with: a very simple HTML5 game where you can upload different versions of the spritesheets and then control the character moving around the environment, triggering the different animations. Basically a very simple sandbox to get a feel for the different animations working together

4. I think this is a really good idea. Are there any substantive differences other than the breast sheet between "male" and "female" bases? (I know there are various 1px differences in the head position and such that are probably accidental). It would be nice if everything other than shirts could just be unisex. We could apply the same logic to the pregnancy bases I think, where they are just unisex with an overlay.

5. This is a fine idea. Ideally we can make tools to do this (and also to stitch sheets back together)? I think we should agree on a standardized file naming convention and a standard single-file assembly order as well (like the current standard), but this will give some flexibility.

6. Off-site version control would be good, we need someone to take charge of this though and enforce those guidelines. File/folder naming conventions will also be important. I can take a stab at it, starting with castelonia's generator as a base.

6.5 I agree that we should switch to making automatic recolors; that will just require a bit of code and some curation.

#4 - The head positions are substantially different between the male and female swing animation, in particular. If we're dealing with the original vanilla LPC base sheets, the male top-facing stand / walk is one pixel higher, the left facing shoot on the female set is one pixel to the side and not perfectly mirrored to the right, the first two frames of the top-facing thrust animation are off for the female, and she bobs differently than the male base during her walk cycle. She's also off to the side during two or three frames in the Hurt animation. The only true match is the magic animation.

I did fix some of these issues in my own curated set, but it also means people using the original base's assets will jitter if combined.

I advertised this as a 'teen' base, but it's perfectly in line with the female animations, aside from the breasts. Might be worth considering? https://opengameart.org/content/lpc-teen-unisex-base-clothes

#5 - Naming each animation would be good. Especially if we're adding guns in-- "Shoot" might not cut it anymore, and we should probably rename "Hurt" to something like 'Knockout'. Hurt should probably be a flinch when damage is taken.

#7 - As long as we're talking about writing scripts, a head / hair accessory placement script would be an absolute godsend. It's consistent (save with the closed eyes during magic for the base and the Hurt/Knockout animation.

As far as I know, no assets have been released for TheraHedwig's run or jump yet

Only the original ones + wulax's have a bigger pool of assets

I HEAVILY advise you to preview animations

Yes, that's in general a good idea, I guess. I haven't really looked at all available one yet.

Or even clear what it was supposed to be. In the end, I've found it would have been better looking and easier to draw things from scratch.

Most people don't seem to realize that the 'walk' rows are actually a standing frame and then an eight-frame walk, and what you get is a nine-frame animation where the legs stutter and splay out every cycle.

That's true, but all original animations start with a standing frame. Walking isn't the only one. Thrusting, bow shooting and jumping start with a modified version of it.

Are there any substantive differences other than the breast sheet between "male" and "female" bases?

The jaw lines of heads are difinitely different, so are the brow line related shadows. Ear angle is different.
Male sholders are broader, which results in completely different arm angles.
Male legs are farther apart, which again results in completely different angles.
Female torse has a more accentuated waist than the male one, which is combined with thicker looking thighs. To make the thighs thicker, the lower parts of the legs are thinner. Males appear to be positioned one pixel higher, probably to make them look taller.

The only thing, which is the same, is the upper half of the head.

This is a fine idea. Ideally we can make tools to do this

General image manipulation tools like Image Magick can easily do that already. But you can also do it with mappings, for splitting you just have two maps and one source image, but that's a bit misappropriation.

off-site version control system

It's a bit tricky to decide on what to use, since git won't work well and svn being very centralized, which can be very impractical if the repo gets deserted and dies. Images are binary data, which works badly with diff-based tools like git. But when git or such is used, it would be a lot more handy for version control to have an image per frame. It's easier to sew which frames were changed in commits, it's easier to merge commits and image diffs are harder to see in bigger images. This is a lot harder to work with drawing-wise, though.

a head / hair accessory placement script would be an absolute godsend

My scripts should be able to that, they come with head position mappings for the original and wulax's animations. It would just have to have the same layout as my heads, which covers all 15 unique heads. The four directions + special angles for "hurt" + closing eyes from casting. I positioned male and female heads so, that the upper half of the head is at exactly the same position, so hats should work for both. But it does not include anything to handle hands/arms which overlap the head.

a standard single-file assembly order as well

I think so, too. The order matters, we should place the most important animations at first. If somebody starts to draw and loses mativation/interest, only the first animations will be covered. The die/hurt animation is usually packed at the end, because it only colors one direction, but I would put that at top to increase compatibility.
I would give higher priority to animations which are needed for NPCs like idle, walking, running and maybe jumping. And lower proriety to those who are era/theme dependant like bow shooting, gun shooting and spell casting. Slash and thrust should work in any era ... clubs, swords, spears, iron pipes, laser swords and practically any longer blunt object.

#4 - hm; well, things like the absolute position being 1px off can be fixed for all assets with scripts. Some of the differences in head positioning we can also probably fix with a combination of Basto's scripts and the below. I think for "version 2" (or maybe "version 1.5"), we should try and eliminate as many of these trivial differences as possible.

However, I think the bigger issue is that, like Basxto points out, the shoulders and legs of the "male" base are much broader than "female" and "teen"/"androgynous". I'm not sure that can be solved with an overlay (at least not in a way which is very useful).

#7 exists! https://github.com/jrconway3/Universal-LPC-spritesheet/tree/master/_build , documented here https://github.com/jrconway3/Universal-LPC-spritesheet/blob/master/Editi... . It takes (at minimum) images in each direction (north, south, east/west, and hurt frames) and applies them to all the animations in appropriate positions, makes cutouts for the arms as appropriate, and generates automatic recolors. You can even override specific frames/animations (e.g. if you wanted to mostly use the same image, but draw bespoke animations for certain frames). It's not infinitely flexible, but it works pretty well. I was even able to adapt it to work for shields, with a different set of overlays.

I'd like to incorporate these scripts (or similar) first into a set of command line tools, then into a big Makefile (or similar) to build full sheets and recolors from a minimal set of images.

Here's the set of utilities/functions I'm envisioning:

- slice: splits a spritesheet containing multiple animations into multiple files, each containing a single animation
- concatenate: opposite of slice

- coerce: takes an RGBA image and a palette (in .gpl, JSON, or PNG format), and produces an indexed PNG image which only uses colors from the palette (optionally, could force "nearby" but non-matching colors to use those from the palette)
- recolor: takes an indexed image and applies a palette (or set of palettes)
- collapse_recolors: takes a set of images (that are recolors of one another) and produces a list of palettes, such that each recolor can be generated from the base image with `recolor`

- distribute: basically does what https://github.com/jrconway3/Universal-LPC-spritesheet/blob/master/Editi... and what basxto's https://github.com/basxto/lpc-shell-tools/blob/master/duplimap.sh do: takes a small number of images and arranges them into a full sheet for each animation
- collapse: opposite of `distribute`: takes a full animation and collapses it into a minimal number of images, as well as a map of offsets.

- offset: offsets each frame in an animation by specified amount(s) (for fixing bugs)
- cutout: makes cutout on the appropriate layers
- stack: arranges several items in layers, according to a prescribed Z-order (e.g. behindbody > base > arms
torso > hair > hat > weapon > over_hat > over_hair > over_arms)

- preview: makes a gif from an animation (or custom sequence of frames)

It could be interesting to minimize the differences between males and females, but that could break compatibility.

big Makefile (or similar)

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.

I started with a makefile in modular bodies.
There were two things, I perceived as big downsides:

1. You have to know what you can build, there is no way for listing all options, as it chooses the rules based on the path you give it
2. It only allows the placeholder % once, which means if you allow costum item names, you have to manually add a rule for each animation, each recolor and actually each possible combination of both

That's why I started to switch to simple build script for my portaits remix.

I used --usage to tell people the naming scheme it expects.

--list semi-dynamically lists all posibillities by directly getting file names from folders.

I reused parts of --list for a --random paramater, that just randomly picks a possible combination. I used that for generating previews, but that is more relevant when you can select a lot of variations.

- coerce: takes an RGBA image and a palette (in .gpl, JSON, or PNG format), and produces an indexed PNG image which only uses colors from the palette (optionally, could force "nearby" but non-matching colors to use those from the palette)

I did not start to implement such a thing, but I thought about it a bit. I think you'd want it to warn you if there are colors in the image, which are not part in the palette. Ideally it should also be possible to produce an image with all colors, who are off.

There is one big downside of indexed PNGs: it does not allow semi-transparency. So shadows have to be either be in a different image or you need a script that can convert those to RGBA PNGs again and make all #322125 60% opaque.

The shadows shouldn't be of interest for the spritesheets, since I don't think it's used there. But it is significant if you try to use it with tilesets.

- recolor: takes an indexed image and applies a palette (or set of palettes)

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.

- collapse_recolors: takes a set of images (that are recolors of one another) and produces a list of palettes, such that each recolor can be generated from the base image with `recolor`

Extracting the color index from an image and dumping it into .gpl shouldn't be much work. Doing this with RGBA images or images with differently ordered indices would be a lot harder to (near) impossible. Especially images who effectively use multiple palettes and share colors between those will be a problem, since you don't know what color you should map it to.

The base assets are actually an example for that, since they have skin and eye colors. I did not split them in my submissions yet.

- collapse: opposite of `distribute`: takes a full animation and collapses it into a minimal number of images, as well as a map of offsets.

Yep, it might be handy to detect duplicates, mirrors and shifted versions of them. Not a hard problem, since you will mostly just trim transparent pixels and maintain a dictionary, but neither that trivial.

- offset: offsets each frame in an animation by specified amount(s) (for fixing bugs)

You could just autogenerate a mapping for that.