I guess the advantage of the JSON format (or similar) with canonical palettes is that it is an explicit mapping from one color to another, so it is not dependent on the colors being in an arbitrary order.
For instance, basxto has run into issues with ImageMagick sorting its indexed palettes and thus messing up the mapping from one color to another. Relatedly, if you have (for example) a 6-color metal palette and you create an image with 5 additional colors (for plumage), you have to ensure the two palettes stay properly sorted (e.g. the first 6 colors in the palette are metal, the next 5 are plumage), and the recolor script has to know this, and is has to never be messed up by any tooling in between. On the other hand, with the JSON mapping solution, as long as the canonical palettes for plumage and metal use different colors, there is no confusion and no possibility of tools screwing up the ordering of the palette.
So I guess I'm talking myself into having canonical palettes per-material and then mapping between those canonical palettes (using JSON or another format; for instance, a 2 x n pixel PNG image, where n is the number of colors in the palette).
I haven't thought about the issues of forking with git LFS... I'm not sure how that works. OTOH, LFS might not be necessary... castelonia's current character creator repository is only ~100 mb, which is not terrible. GitHub has nice tools for visual diffs between binary images. I'm happy to consider other alternatives if you have ideas, but git/GitHub still seems like the most obvious solution for the time being...
Good points all. Appreciate the comments about indexed palettes and alpha transparency. Another disadvantage of indexed PNGs is they are not supported by all editing software (for instance, PyxelEdit which I mostly like).
pvigier, could you share your get_palette , get_indices , and apply_palette scripts? I don't see them in your repo, but they would be helpful.
This way I am sure that I don't have wrong/obsolete recolored images that live somewhere. There is only one truth for the indices.
Perhaps I'm misunderstanding, but I think that can be solved by having a "source" directory where the shape/index images and palettes live, and an "output" (or "build" or "bin" or whatever) where generated images live. Images in "output" never get directly edited.
I'll have to mess around with ImageMagick, Pillow/Numpy, and PyPNG and decide what works best. May be a combination of all three, depending on the specific task. If I end up using any of the original Ruby scripts, I'll probably port them to Python so there are not too many languages at play. Slow is not the end of the world, but it depends how slow and how often the images need to be "re-built". If an artist can edit something that looks somewhat like the final product, then only infrequently re-build the derived/output images, it's fine if the scripts are kind of slow. But if every time you save, you have to run the scripts, speed will matter more.
I would advise against make, I can't say anything about other build systems, since I'm not familiar with them.
The best thing about make is that it only builds what changed.
Yes, that is exactly the advantage. I imagine a set of shell tools that implement the verbs I described above. Then a Makefile (or similar, not married to Make specifically), combined with a standard set of index/shape input images, which calls the shell tools to generate all the output images (producing a collection of layer-able spritesheets, similar to those in castelonia's current generator). If someone wants to do something different, they can call the shell tools directly, or create a fork with a different Makefile.
The only thing I don't like about pvigier's approach is that the shapes/indices (https://gitlab.com/vagabondgame/lpc-characters/-/tree/master/indices) cannot be edited directly in a practical way (one would have to convert them to RGBA, then convert the edited RGBA back to indexed; not impossible, but kind of a pain). By contrast, the hair shapes in https://github.com/jrconway3/Universal-LPC-spritesheet/tree/master/_buil... are RGBA images, but they use a standardized palette so they are directly viewable/editable. That standardized palette can differ for different types of images (so for instance, I could use a different palette for the shields than for hair). I think I like this solution better.
My tool does currently not support multiple palettes, but it should work if multiple palettes get concatenated with cat beforehands. It also currently discards information about what index is transparent.
Sorry, what I was thinking about was taking one index/shape image and making say 10 different recolors with 10 different palettes.
I haven't figured out how we should handle objects with multiple "materials" (e.g. several independent color palettes). For instance, the base bodies and their eyes, or the helmets that ElizaWy just posted and their red plumes. I suppose an advantage of the JSON palettes here is that different materials could have different standard palettes, which could be concatenated unambiguously.
#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`
- 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)
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.
It's a big improvement, for sure! I still think the motion blur is necessary for the chop animations---you're just trying to convey dramatic movement in very few frames, so without motion blur, the animation will always look pretty choppy---like a game running at low FPS. You're right it will need to be different for each weapon, but it's not that hard. I'd be happy to give it a try if you'd like. Castelonia was also interested in this.
Do you think I should make a submission for these animations at this state or I wait the definitive version?
EDIT: Is anyone interested in the script I used to generate the animation?
Yes! Submit early, submit often! You can always update, and use the Bump Requests thread to move the submission back to the homepage if you make a major improvement. Definitely upload the script(s) too if you can.
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.
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
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.
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.
Hi Medicine, can you bump this submission: https://opengameart.org/content/lpc-food ? Roughly doubled the number of sprites included, and significantly reorganized.
Awesome ideas!
Any suggestions/ideas for craft shops?
I guess the advantage of the JSON format (or similar) with canonical palettes is that it is an explicit mapping from one color to another, so it is not dependent on the colors being in an arbitrary order.
For instance, basxto has run into issues with ImageMagick sorting its indexed palettes and thus messing up the mapping from one color to another. Relatedly, if you have (for example) a 6-color metal palette and you create an image with 5 additional colors (for plumage), you have to ensure the two palettes stay properly sorted (e.g. the first 6 colors in the palette are metal, the next 5 are plumage), and the recolor script has to know this, and is has to never be messed up by any tooling in between. On the other hand, with the JSON mapping solution, as long as the canonical palettes for plumage and metal use different colors, there is no confusion and no possibility of tools screwing up the ordering of the palette.
So I guess I'm talking myself into having canonical palettes per-material and then mapping between those canonical palettes (using JSON or another format; for instance, a 2 x n pixel PNG image, where n is the number of colors in the palette).
I haven't thought about the issues of forking with git LFS... I'm not sure how that works. OTOH, LFS might not be necessary... castelonia's current character creator repository is only ~100 mb, which is not terrible. GitHub has nice tools for visual diffs between binary images. I'm happy to consider other alternatives if you have ideas, but git/GitHub still seems like the most obvious solution for the time being...
Good points all. Appreciate the comments about indexed palettes and alpha transparency. Another disadvantage of indexed PNGs is they are not supported by all editing software (for instance, PyxelEdit which I mostly like).
pvigier, could you share your get_palette , get_indices , and apply_palette scripts? I don't see them in your repo, but they would be helpful.
Perhaps I'm misunderstanding, but I think that can be solved by having a "source" directory where the shape/index images and palettes live, and an "output" (or "build" or "bin" or whatever) where generated images live. Images in "output" never get directly edited.
I'll have to mess around with ImageMagick, Pillow/Numpy, and PyPNG and decide what works best. May be a combination of all three, depending on the specific task. If I end up using any of the original Ruby scripts, I'll probably port them to Python so there are not too many languages at play. Slow is not the end of the world, but it depends how slow and how often the images need to be "re-built". If an artist can edit something that looks somewhat like the final product, then only infrequently re-build the derived/output images, it's fine if the scripts are kind of slow. But if every time you save, you have to run the scripts, speed will matter more.
Yes, that is exactly the advantage. I imagine a set of shell tools that implement the verbs I described above. Then a Makefile (or similar, not married to Make specifically), combined with a standard set of index/shape input images, which calls the shell tools to generate all the output images (producing a collection of layer-able spritesheets, similar to those in castelonia's current generator). If someone wants to do something different, they can call the shell tools directly, or create a fork with a different Makefile.
The only thing I don't like about pvigier's approach is that the shapes/indices (https://gitlab.com/vagabondgame/lpc-characters/-/tree/master/indices) cannot be edited directly in a practical way (one would have to convert them to RGBA, then convert the edited RGBA back to indexed; not impossible, but kind of a pain). By contrast, the hair shapes in https://github.com/jrconway3/Universal-LPC-spritesheet/tree/master/_buil... are RGBA images, but they use a standardized palette so they are directly viewable/editable. That standardized palette can differ for different types of images (so for instance, I could use a different palette for the shields than for hair). I think I like this solution better.
Sorry, what I was thinking about was taking one index/shape image and making say 10 different recolors with 10 different palettes.
I haven't figured out how we should handle objects with multiple "materials" (e.g. several independent color palettes). For instance, the base bodies and their eyes, or the helmets that ElizaWy just posted and their red plumes. I suppose an advantage of the JSON palettes here is that different materials could have different standard palettes, which could be concatenated unambiguously.
#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)
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.
It's a big improvement, for sure! I still think the motion blur is necessary for the chop animations---you're just trying to convey dramatic movement in very few frames, so without motion blur, the animation will always look pretty choppy---like a game running at low FPS. You're right it will need to be different for each weapon, but it's not that hard. I'd be happy to give it a try if you'd like. Castelonia was also interested in this.
Yes! Submit early, submit often! You can always update, and use the Bump Requests thread to move the submission back to the homepage if you make a major improvement. Definitely upload the script(s) too if you can.
Hi, could you bump this submission? https://opengameart.org/content/lpc-crops Added 17 new animated crops.
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)
Here is BenCreating's draft of the female base: https://opengameart.org/comment/89342#comment-89342
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
Pretty much agree with Basto about this. I envision two sets of tools:
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:
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.
And just to add more chaos, a few more possibilities:
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).
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.
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.
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.
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.
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'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.
Hi Medicine, can you bump this submission: https://opengameart.org/content/lpc-food ? Roughly doubled the number of sprites included, and significantly reorganized.
Pages