My preference is a lazy artist is always to put everything into one file while working, since animation invariably involves copy-pasting between various frames (even between different animations). That said, it is trivial to split an image into multiple images at the end, and that seems like the most straightforward approach (combined with some documentation of the frame size/count) to make the images easily understandable. Again, I don't see how it is feasible to standardize the types of animation, number of frames, etc. at this stage. The monsters are just too diverse, like Ben said, and I don't think we have enough examples to make a useful prediction or declaration about what's needed. For the attacking missions that I drew, I used 6 to 7 frames depending on how the animation looked. The frame size for the monsters already varied from 32x32 to 128x128; I used the same frame size as the existing idle/move animation.
I recognize Gaurav's concerns regarding the complexity of storing/encoding asset metadata, optimizing file size, etc.; I'm not a game developer so I can't speak to that specifically, but I suspect it cannot be entirely solved or avoided simply by convention in a way which will be useful to everyone. I'm not persuaded that artists should change the way assets are drawn or formatted for the sake of compression ratios; that is a development concern which should be addressed using appropriate tooling (for instance using a texture atlas packer). For what it's worth, Pierre didn't seem to have any trouble using the monster animations, as I drew them, in Vagabond. I believe Pierre re-packs (using a simple script he wrote) the humanoid character LPC spritesheets to reduce empty space, and he might do something similar for the monsters. That works well with his engine and addresses his needs; others might not want/need to bother depending on their considerations. As an artist, I certainly would not want to work in this compressed format.
So to summarize, I would propose artists do the following:
1. Use a single frame size for all animations of a given monster, if possible
2. Arrange frames of a given animation left-to-right
3. For a given animation, stack different directions top-to-bottom in the following order: North, West, South, East
4. Provide one file per animation (preferred), or stack animations from top-to-bottom (rather than left-to-right)
5. Clearly document the frame size and intended animation sequence (if it is not obvious; for instance, if certain parts of the animation should loop). This can be done by means of a Tiled tsx file (my preference) and/or a description in plain text.
The character base conventions are useful because the assets are modular and can be combined in interesting ways. That’s not the case for the current enemies/monsters. You could establish some very simple conventions, like the order the animations and directions (N/E/S/W) should appear but beyond that…
I think the humanoid monsters are basically solved. You can draw new heads easily and place using lpctools (soon to all the new frames too once Jaidyn figures out the offsets). Tails, wings, etc. can be placed similarly. New body types that still have the same basic proportions (and thus can use the same weapons, accessories, etc.) are conceivable (e.g. leshen, rock elemental, etc.).
I could imagine making some modular monster assets! You could have body shapes (e.g. canine, dragon, equine, etc.), different types of heads, feet/hoofs, wings, etc. But it would probably require some thought and experimentation to figure out what could be readily combined. But might be neat to try.
Some other more complicated but not quite humanoid LPC-style enemies (in addition to the wolf):
I re-drew this hair and added to the generator in my hair mega-pack https://opengameart.org/content/lpc-hair . I didn't extract or re-draw any of the other layers.
I think essentially everything else on that list is either not really compatible (e.g. the cabbit assets are a different resolution and size), is already incorporated (e.g. my submissions), or would require some consideration on how to properly incorporate (e.g. caeles'). You can do a ctrl-F for a given URL in the generator's CREDITS.csv to see if that submission has been added.
Regarding the facial expressions, I also struggled to figure out how they would fit into the framework of the generator/universal spritesheet. One possibility I considered was adding an extra set of "idle" frames to the spritesheet without a face/head; then an expression could be placed in that slot in-engine. An alternative would be to have an entire row of idle frames to accommodate various expressions, but that would require figuring out what order to put them in... I ended up giving up and ignoring it as out-of-scope :p
Since the topic of adding additional animations has come up here (and since Jaidyn has done the heroic work of adapting many assets to Eliza's additional animations), I'll just share some thoughts: several of us (Evert, BenCreating, castelonia/Herodom, pvigier, and myself) discussed and examined the available assets extensively a few years ago, culminating in this submission https://opengameart.org/content/lpc-character-bases which standardized a bunch of minor inconsistencies between the bases and subsequently this submission https://opengameart.org/content/lpc-clothing-updates which updated all the existing clothing to match.
The basic problem is that re-drawing assets for the moving legs, hands, and torso is extremely labor-intensive, so the more animations you add, the more of a pain it is to create new assets which use them. For the most part, heads, hair, hats, etc. can be placed automatically using lpctools or similar means. In frames where the torso doesn't move much (or the asset doesn't need to move much), you can auto-place other types of assets: I did this with belts and neckwear here https://opengameart.org/content/lpc-pirates and with the "Santa" jacket trim here https://opengameart.org/content/lpc-santa .
The reason that Evert and I created the v3 run animation in this submission https://opengameart.org/content/lpc-character-bases was to minimize the amount of movement of the torso, so that more assets could be auto-placed. By contrast, Eliza's run (which undoubtedly looks nice!) has a ton of movement in the torso, so torso assets are likely to require substantial re-drawing. Ditto for her combat animations. To be fair, assets for our alternative run animation haven't really materialized either, whereas Eliza did draw a number of basic clothing items for those animations. For my part, I will not be drawing any new torso assets for the LPC Revised run or combat animations (unless someone commissions me, and it will be an expensive commission because it's lots of work! :p). I am also somewhat opposed to adding new animations which move the legs differently (and thus require drawing new pants, etc.) for the same reason. I'd also vote against adding the diagonal animations to the spritesheet generator, because frankly there is zero chance of adapting the existing assets to them.
If anything, I would prefer that new frames be added with some consideration for how they can be remixed with existing frames. For instance, the push/carry frames are meant to use the same legs as walk. I have experimented here https://opengameart.org/content/lpc-hand-tools and here https://opengameart.org/content/lpc-extended-weapon-animations with repurposing existing frames to assemble new animations. I think the results are pretty nice and at least demonstrate the principle that we could do more with less.
Very exciting as usual to see more updates to the LPC! Thanks for all your hard work on this over the last several months, and sorry I haven't been able to follow very closely. I was impressed to discover recently that you've also added additional animations for several of the torso armors and the gloves; I know how much work that must have been :)
Did you end up using lpctools or some other automated method of placing the head/hat/hair assets on the additional animation frames? If so, would you be willing to share the offsets, cutouts, and layout.json files you used? If you tried and it didn't work, can you share what issues you had? I'd be happy to troubleshoot. Feel free to reach out on Discord too if you prefer.
Thanks for making all those additions, I think it is much improved!
Thanks for explaining about the colors. I think your solution of assigning "default" palette(s) to every item which are discoverable in metadata is a good one.
I am using Safari Version 16.6.1 (16615.3.12.11.5, 16615) and still see the flickering. I don't see the flickering on Chrome Version 120.0.6099.234. Seems to occur the first few times a given animation is played with a given setting. Adding/removing a layer causes it. Switching to a new animation causes it. Switching back to an animation already played does not cause it.
A few other minor issues I noticed:
- Chainmail in the "shirt" layer seems to have too high a z-index (gets drawn over top of all armor)
- Suggest moving the "legion" and "leather" items from the "shirt" group to "overshirt/armor" group
- Slingshot "walk" animation doesn't work.
- Could you increase height (i.e. number of items shown) when a dropdown is opened?
- Could the size of the preview images within the dropdown be increased to 64x64px (seems like they are 40x40px now which results in non-integer scaling and also is a little hard to see)?
- If not too computationally intensive, could you center the non-transparent portion of the image?
- In the (now default) "Preview Multiple" mode, if you zoom in, the character is no longer centered, and scrolling is really jittery/doesn't work (i.e. I scroll down a bunch and the character just wobbles vertically in place. Sometimes eventually scrolls down, sometimes not). I appreciate you have tried to lock the scrolling between the four views which is a great idea, but something there is not working right at the moment.
- Clicking the "center" button doesn't seem to do anything for that matter.
- In the old generator, you could click the animation preview or the spritesheet to toggle between 1x and 2x zoom. This would be a nice feature IMO
- I still would like a view where all directions of all animations are shown at once ;-) It would require scrolling but there's so much whitespace at the moment
Thanks again for working on this, it's really cool and seems like a big improvement in several ways over the current generator!
Very cool, thanks so much for sharing! I am particularly impressed that you managed to/chose to adapt almost every asset in the current generator and that you have maintained the attribution information. Of course standardizing the colors, allowing the generator to make recolors "on the fly" rather than generating them all offline, and breaking apart the animations will all be big improvements for contributors.
Here are some minor issues I noticed when playing around:
- "Walk" animation should start on the second frame in the series; the first frame is just the character standing idle. Adding it to the walk cycle makes their legs splay out and looks unnatural.
- When you first select an object, the first few animation frames flicker
- To that end, it takes a few seconds to render the new animation(s) when you add/change a layer. Any optimizations to that would be welcome
- "Whip" animation uses the wrong frame size, should be 192x192px
Here are some feature requests in no particular order:
- It would be helpful to preview the animation in all directions at once like in the other generator
- For that matter, I think it would be helpful to see all animations in all directions at once
- I would like to see a preview of the item in the drop-down (I know this would require using something more complicated than an HTML <select> element)
- The whole "torso", "torso 2" thing is kind of non-intuitive to me. I understand you probably did it this way so that mutually-exclusive items can be in a single dropdown, but it's not obvious to the user that they should look in "torso" for plate armor but in "torso 2" for jackets. Likewise, I would suggest at least one more torso layer, since you could easily imagine a character with a longsleeve shirt, vest, and jacket. I would also move the armor and vest(s) to "torso 2" and make the jackets and tabard "torso 3." Alternatively, you could label the layers something intuitive like "shirt," "overshirt/armor," "jacket/tabard," etc.
- Same suggestion for "head coverings;" make bandana, hijab, etc. their own layer.
- Consider breaking some of the items within layers into groups. For example, separate the pirate hats from helmets. Even just using <optgroup> within the same <select> would be helpful as right now it's kind of a jumble, especially for categories like hat or hair with lots of assets.
- Allow downloading a file without naming it
- When an object has multiple "palettes" (e.g. the bicorne athwart admiral cockade hat you mentioned), make a tooltip over each palette
- Search function for assets (i.e. search box at the very top where I can type "bow" and see it in the appropriate tab of the UI)
- Mobile support? (on my iPhone 13, the left and right panels almost entirely cover the preview).
And a few questions:
- What method did you use to squash the colors?
- What is going on with the colors of the sprites? In the repo you linked https://github.com/vitruvianstudio/spritesheets/blob/main/clothes/torso/longsleeve/male/walk.png everything shows up as a red blob. If I open in GIMP etc. I can see they are slightly different colors of red but I don't exactly understand what's going on. I'm sure this makes your recoloring code more convenient somehow. I humbly would suggest that it will be much more convenient for contributors and users if the sprites in the repo appeared in some default palette, either as indexed or ideally plain RGB PNGs. Much lower friction to adding and editing sprites. I say this as someone who has spent probably more time than anyone adding and modifying sprites in the current generator.
- I notice in some sprites, like the "Wizard" hat or the "hood" that there are red spots which don't get recolored when you change palette. I presume this is because these assets had too many colors and you couldn't automatically squash them (or, in the case of the wizard hat, you haven't extracted a separate color palette for the stars), is that right?
- Did you use a script to transfer the metadata and attribution from Sander's generator? If so, will that process allow you to port updates relatively easily? I ask because I am in the midst of making several such updates ;-)
My preference is a lazy artist is always to put everything into one file while working, since animation invariably involves copy-pasting between various frames (even between different animations). That said, it is trivial to split an image into multiple images at the end, and that seems like the most straightforward approach (combined with some documentation of the frame size/count) to make the images easily understandable. Again, I don't see how it is feasible to standardize the types of animation, number of frames, etc. at this stage. The monsters are just too diverse, like Ben said, and I don't think we have enough examples to make a useful prediction or declaration about what's needed. For the attacking missions that I drew, I used 6 to 7 frames depending on how the animation looked. The frame size for the monsters already varied from 32x32 to 128x128; I used the same frame size as the existing idle/move animation.
I recognize Gaurav's concerns regarding the complexity of storing/encoding asset metadata, optimizing file size, etc.; I'm not a game developer so I can't speak to that specifically, but I suspect it cannot be entirely solved or avoided simply by convention in a way which will be useful to everyone. I'm not persuaded that artists should change the way assets are drawn or formatted for the sake of compression ratios; that is a development concern which should be addressed using appropriate tooling (for instance using a texture atlas packer). For what it's worth, Pierre didn't seem to have any trouble using the monster animations, as I drew them, in Vagabond. I believe Pierre re-packs (using a simple script he wrote) the humanoid character LPC spritesheets to reduce empty space, and he might do something similar for the monsters. That works well with his engine and addresses his needs; others might not want/need to bother depending on their considerations. As an artist, I certainly would not want to work in this compressed format.
So to summarize, I would propose artists do the following:
1. Use a single frame size for all animations of a given monster, if possible
2. Arrange frames of a given animation left-to-right
3. For a given animation, stack different directions top-to-bottom in the following order: North, West, South, East
4. Provide one file per animation (preferred), or stack animations from top-to-bottom (rather than left-to-right)
5. Clearly document the frame size and intended animation sequence (if it is not obvious; for instance, if certain parts of the animation should loop). This can be done by means of a Tiled tsx file (my preference) and/or a description in plain text.
The character base conventions are useful because the assets are modular and can be combined in interesting ways. That’s not the case for the current enemies/monsters. You could establish some very simple conventions, like the order the animations and directions (N/E/S/W) should appear but beyond that…
I think the humanoid monsters are basically solved. You can draw new heads easily and place using lpctools (soon to all the new frames too once Jaidyn figures out the offsets). Tails, wings, etc. can be placed similarly. New body types that still have the same basic proportions (and thus can use the same weapons, accessories, etc.) are conceivable (e.g. leshen, rock elemental, etc.).
I could imagine making some modular monster assets! You could have body shapes (e.g. canine, dragon, equine, etc.), different types of heads, feet/hoofs, wings, etc. But it would probably require some thought and experimentation to figure out what could be readily combined. But might be neat to try.
Some other more complicated but not quite humanoid LPC-style enemies (in addition to the wolf):
https://opengameart.org/content/lpc-imp-2
https://opengameart.org/content/flying-dragon-rework
https://opengameart.org/content/lpc-golem
Adaptable to LPC style:
https://opengameart.org/content/plant-and-mushroom-enemies-charset-and-battlers
https://opengameart.org/content/slime-monster-pixel-art-for-top-down-rpg
https://opengameart.org/content/pixel-predator-plant-mob-character
https://opengameart.org/content/lpc-heroine and
https://opengameart.org/content/lpc-heroine-2
I re-drew this hair and added to the generator in my hair mega-pack https://opengameart.org/content/lpc-hair . I didn't extract or re-draw any of the other layers.
I think essentially everything else on that list is either not really compatible (e.g. the cabbit assets are a different resolution and size), is already incorporated (e.g. my submissions), or would require some consideration on how to properly incorporate (e.g. caeles'). You can do a ctrl-F for a given URL in the generator's CREDITS.csv to see if that submission has been added.
Regarding the facial expressions, I also struggled to figure out how they would fit into the framework of the generator/universal spritesheet. One possibility I considered was adding an extra set of "idle" frames to the spritesheet without a face/head; then an expression could be placed in that slot in-engine. An alternative would be to have an entire row of idle frames to accommodate various expressions, but that would require figuring out what order to put them in... I ended up giving up and ignoring it as out-of-scope :p
Since the topic of adding additional animations has come up here (and since Jaidyn has done the heroic work of adapting many assets to Eliza's additional animations), I'll just share some thoughts: several of us (Evert, BenCreating, castelonia/Herodom, pvigier, and myself) discussed and examined the available assets extensively a few years ago, culminating in this submission https://opengameart.org/content/lpc-character-bases which standardized a bunch of minor inconsistencies between the bases and subsequently this submission https://opengameart.org/content/lpc-clothing-updates which updated all the existing clothing to match.
The basic problem is that re-drawing assets for the moving legs, hands, and torso is extremely labor-intensive, so the more animations you add, the more of a pain it is to create new assets which use them. For the most part, heads, hair, hats, etc. can be placed automatically using lpctools or similar means. In frames where the torso doesn't move much (or the asset doesn't need to move much), you can auto-place other types of assets: I did this with belts and neckwear here https://opengameart.org/content/lpc-pirates and with the "Santa" jacket trim here https://opengameart.org/content/lpc-santa .
The reason that Evert and I created the v3 run animation in this submission https://opengameart.org/content/lpc-character-bases was to minimize the amount of movement of the torso, so that more assets could be auto-placed. By contrast, Eliza's run (which undoubtedly looks nice!) has a ton of movement in the torso, so torso assets are likely to require substantial re-drawing. Ditto for her combat animations. To be fair, assets for our alternative run animation haven't really materialized either, whereas Eliza did draw a number of basic clothing items for those animations. For my part, I will not be drawing any new torso assets for the LPC Revised run or combat animations (unless someone commissions me, and it will be an expensive commission because it's lots of work! :p). I am also somewhat opposed to adding new animations which move the legs differently (and thus require drawing new pants, etc.) for the same reason. I'd also vote against adding the diagonal animations to the spritesheet generator, because frankly there is zero chance of adapting the existing assets to them.
If anything, I would prefer that new frames be added with some consideration for how they can be remixed with existing frames. For instance, the push/carry frames are meant to use the same legs as walk. I have experimented here https://opengameart.org/content/lpc-hand-tools and here https://opengameart.org/content/lpc-extended-weapon-animations with repurposing existing frames to assemble new animations. I think the results are pretty nice and at least demonstrate the principle that we could do more with less.
Very exciting as usual to see more updates to the LPC! Thanks for all your hard work on this over the last several months, and sorry I haven't been able to follow very closely. I was impressed to discover recently that you've also added additional animations for several of the torso armors and the gloves; I know how much work that must have been :)
Did you end up using lpctools or some other automated method of placing the head/hat/hair assets on the additional animation frames? If so, would you be willing to share the offsets, cutouts, and layout.json files you used? If you tried and it didn't work, can you share what issues you had? I'd be happy to troubleshoot. Feel free to reach out on Discord too if you prefer.
Welcome back!! Cool to see some new hairstyles being added and cool to see a new (old) contributor to the LPC!
Thanks for making all those additions, I think it is much improved!
Thanks for explaining about the colors. I think your solution of assigning "default" palette(s) to every item which are discoverable in metadata is a good one.
I am using Safari Version 16.6.1 (16615.3.12.11.5, 16615) and still see the flickering. I don't see the flickering on Chrome Version 120.0.6099.234. Seems to occur the first few times a given animation is played with a given setting. Adding/removing a layer causes it. Switching to a new animation causes it. Switching back to an animation already played does not cause it.
A few other minor issues I noticed:
- Chainmail in the "shirt" layer seems to have too high a z-index (gets drawn over top of all armor)
- Suggest moving the "legion" and "leather" items from the "shirt" group to "overshirt/armor" group
- Slingshot "walk" animation doesn't work.
- Could you increase height (i.e. number of items shown) when a dropdown is opened?
- Could the size of the preview images within the dropdown be increased to 64x64px (seems like they are 40x40px now which results in non-integer scaling and also is a little hard to see)?
- If not too computationally intensive, could you center the non-transparent portion of the image?
- In the (now default) "Preview Multiple" mode, if you zoom in, the character is no longer centered, and scrolling is really jittery/doesn't work (i.e. I scroll down a bunch and the character just wobbles vertically in place. Sometimes eventually scrolls down, sometimes not). I appreciate you have tried to lock the scrolling between the four views which is a great idea, but something there is not working right at the moment.
- Clicking the "center" button doesn't seem to do anything for that matter.
- In the old generator, you could click the animation preview or the spritesheet to toggle between 1x and 2x zoom. This would be a nice feature IMO
- I still would like a view where all directions of all animations are shown at once ;-) It would require scrolling but there's so much whitespace at the moment
Thanks again for working on this, it's really cool and seems like a big improvement in several ways over the current generator!
Hello! Would you be willing to license this submission as OGA-BY 3.0+ since wulax's original https://opengameart.org/content/lpc-medieval-fantasy-character-sprites is now licensed as such? Thank you!
Very cool, thanks so much for sharing! I am particularly impressed that you managed to/chose to adapt almost every asset in the current generator and that you have maintained the attribution information. Of course standardizing the colors, allowing the generator to make recolors "on the fly" rather than generating them all offline, and breaking apart the animations will all be big improvements for contributors.
Here are some minor issues I noticed when playing around:
- "Walk" animation should start on the second frame in the series; the first frame is just the character standing idle. Adding it to the walk cycle makes their legs splay out and looks unnatural.
- When you first select an object, the first few animation frames flicker
- To that end, it takes a few seconds to render the new animation(s) when you add/change a layer. Any optimizations to that would be welcome
- "Whip" animation uses the wrong frame size, should be 192x192px
Here are some feature requests in no particular order:
- It would be helpful to preview the animation in all directions at once like in the other generator
- For that matter, I think it would be helpful to see all animations in all directions at once
- I would like to see a preview of the item in the drop-down (I know this would require using something more complicated than an HTML <select> element)
- The whole "torso", "torso 2" thing is kind of non-intuitive to me. I understand you probably did it this way so that mutually-exclusive items can be in a single dropdown, but it's not obvious to the user that they should look in "torso" for plate armor but in "torso 2" for jackets. Likewise, I would suggest at least one more torso layer, since you could easily imagine a character with a longsleeve shirt, vest, and jacket. I would also move the armor and vest(s) to "torso 2" and make the jackets and tabard "torso 3." Alternatively, you could label the layers something intuitive like "shirt," "overshirt/armor," "jacket/tabard," etc.
- Same suggestion for "head coverings;" make bandana, hijab, etc. their own layer.
- Consider breaking some of the items within layers into groups. For example, separate the pirate hats from helmets. Even just using <optgroup> within the same <select> would be helpful as right now it's kind of a jumble, especially for categories like hat or hair with lots of assets.
- Allow downloading a file without naming it
- When an object has multiple "palettes" (e.g. the bicorne athwart admiral cockade hat you mentioned), make a tooltip over each palette
- Search function for assets (i.e. search box at the very top where I can type "bow" and see it in the appropriate tab of the UI)
- Mobile support? (on my iPhone 13, the left and right panels almost entirely cover the preview).
And a few questions:
- What method did you use to squash the colors?
- What is going on with the colors of the sprites? In the repo you linked https://github.com/vitruvianstudio/spritesheets/blob/main/clothes/torso/longsleeve/male/walk.png everything shows up as a red blob. If I open in GIMP etc. I can see they are slightly different colors of red but I don't exactly understand what's going on. I'm sure this makes your recoloring code more convenient somehow. I humbly would suggest that it will be much more convenient for contributors and users if the sprites in the repo appeared in some default palette, either as indexed or ideally plain RGB PNGs. Much lower friction to adding and editing sprites. I say this as someone who has spent probably more time than anyone adding and modifying sprites in the current generator.
- I notice in some sprites, like the "Wizard" hat or the "hood" that there are red spots which don't get recolored when you change palette. I presume this is because these assets had too many colors and you couldn't automatically squash them (or, in the case of the wizard hat, you haven't extracted a separate color palette for the stars), is that right?
- Did you use a script to transfer the metadata and attribution from Sander's generator? If so, will that process allow you to port updates relatively easily? I ask because I am in the midst of making several such updates ;-)
Thanks again for sharing!
Pages