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 :)

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.

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.

Please keep discussion here focused on attributions for the LPC character sprites. If you want to talk about better ways to make recolors, please start a separate thread.

@Kuranyem, we now have a chart listing the "prices" (attribution) of all items in our "grocery store". We also have a visual tool where you can pick items and it tells you the "prices" (attribution instructions), as well as (IMO) clear instructions in the project README. What more do you want? Nobody is advocating for the ridiculous grocery store you suggested. That was the situation before we started, but I think it's improved significantly.

If you have any other suggestions about how to make this information clearer or more useful, I'd be happy to hear it. But I feel like you are arguing against a position that nobody here is taking.

@Basto, Kuranyem: I think the issue of recolors is simpler than you are making it. Here is how CC defines "Adapted Material" (this is the term used in CC 4.0, equivalent to "derivative work" in other licenses):

Adapted Material means material subject to Copyright and Similar Rights that is derived from or based upon the Licensed Material and in which the Licensed Material is translated, altered, arranged, transformed, or otherwise modified in a manner requiring permission under the Copyright and Similar Rights held by the Licensor

I don't see anything here that would prevent a recolor from meeting that definition. Someone makes a recolored image, they are creating a derivative work, they need to grant a license to use that work and they get credit. The CC licenses have no notion of a "trivial" modification Practically speaking, it's important to track credit in order to make sure the asset is still free. For example, if you make a recolor of an asset that is under a non-Share-Alike license (e.g. CC-BY), technically, you are not required to release the recolored asset under a free license (as long as the original author is properly credited). So we need to know who made the recolor and under what license.

Philosophically, even if a color palette cannot be copyrighted, in my opinion there is clearly creative effort involved in selecting colors to produce an artistic effect. It's also practically useful to many developers, even if you personally don't find it useful because you want to do recolors by changing HSL. There was a long discussion about the legal status of fonts in another post... I'd rather not get into that here. The point is, the conservative position is to keep track of who made recolors and be sure they are licensed appropriately. If you want to make your own fork of the spritesheet generator where you do all the recolors automatically from an indexed palette---fine, knock yourself out.

I don't think the scenario where the engine produces recolors requires you to distribute 281 trillion images or whatever. Nobody is asking for that. If your engine is recoloring a CC-BY-SA asset, you can't prevent someone from using one of your HSL-recolored images under that original license (with credit to you), including "circumventing effective technological measures" to do so. But again, that's not the problem we need to address here. We have a discrete number of recolored assets and need to attribute them. I think the most straightforward thing to do (and this is what I have done) is to figure out who made the original, figure out who made the recolor, and credit both.