The only problem will be remembering who made the assets, as I would spend hours some nights downloading stuff just trying to find the perfect assets just so I could express to any future artist what I'm kind of looking for. Hard to keep track when you download a ton around the same time. But due credit is important so I will just spend time on that when I get it all set up.
Two things that help with this:
1) I always download assets into a folder named by the last part of the OGA url, e.g. I would download https://opengameart.org/content/lpc-ship into a folder called "lpc-ship", that I way I can find it again.
2) If you go to your user page, there is a hidden collection called "My Downloads" which you can use to see all the assets you have downloaded. This is helpful if you remember downloading something but can't find where it came from. Super helpful feature of OGA that I think most users are unaware of.
Obviously there will be scenarios where these tricks don't work, but I have found them helpful temporary solutions.
The scaled image has been anti-aliased; you did not enable nearest neighbor/disable filtering when scaling.
Zoom in on the image. Notice that instead of 5 distinct colors there are many shades of grey. This is due to anti-aliasing applied by the scaling algorithm. It makes the image not really look like pixel art anymore.
FYI, even with nearest neighbor scaling, you often need to hand-edit pixel art when you scale it. Prototype 2 looks better than 1 for this reason, although it still has anti-aliasing on the internal parts of the fish.
I'd be happy to keep giving feedback on this and/or other sprites, but maybe we should move the conversation to a different thread?
Looks nice! I would just scale it down in whatever program you usally use (I use PyxelEdit for pixel art, Aseprite is also good; GIMP would work too, but make sure to set the interpolation mode to "None" or "Nearest Neighbor" so you don't get aliasing).
I am making a fishing animation for one of this month's commissions on my Ko-fi page; this will go nicely together! https://ko-fi.com/bluecarrot16
More like this (I only edited the first frame for each direction). Very minor edit, but I think it makes the light source more clear and the object look more 3D as a consequence.
re: adding extra death animations, what would you suggest we do instead Evert? Just add jump, run, etc. as we go below the death animation? Again, I don't plan on implementing a more complicated layout system or support multiple images within the generator website (I already did that within lpctools, so I don't think it's a big burden to use that on the resulting images if you want a different layout)... so unless someone else adds that, if there's going to be any support for more animations in the generator it will probably have to be by stacking them in one big image.
re: colors, this looks like a good start! I would suggest previewing them on the character bases to be sure they look right; hard to tell from the palette whether they have quite enough contrast. Should be easy to do with lpctools and imagemagick, let me know if you need help.
Eliza posted this guide on Discord somewhere for her then-latest version of the Liberated palette, which names the color ramps she uses for skin, clothes, and hair; might be helpful to you.
What about the wolfman/boarman colors? Ben used a few of the hair color palettes to make several different wolfman colors here https://opengameart.org/content/lpc-wolfman ; they could apply equally well to the boarman and potentially other furry/hairy creatures I think. Do you want to include them in this set?
Thanks so much for posting this, Hyptosis! I love the way the floor tiles imply so much texture, but they're borderless so you can mix and match. Very effective. Also the giant anvil is so cool, lots of personality there.
Looks like there is some banding in the preview image, but it's not present in the actual download.
Looks nice! Maybe adjust the shading so that it implies more of a 3/4 perspective than top-down? E.g. move the light-gray shading from the middle more towards the top.
Thanks YuriNikolai! That is a great idea to focus on foragable plants. I found this Wikipedia article (which is not very comprehensive), as well as this neat website. (I definitely referenced that Wikipedia article on culinary fruits, as well as the List of Vegetables page while working on my Foods pack :p). Still seems like a huge list, I would love it someone could help prioritize for me ;-)
FiveBrosStopMosYT, that is great, exactly what I was thinking! Now you just need a biting/tugging animation (maybe?). And maybe it needs different directions, or maybe it just gets rotated in-engine?
Good discussion here, thanks for contributing everyone. Not sure we're any closer to a consensus, but it's helpful to talk it out. Sorry if this is a bit pedantic, I'm just trying to think thru the best structure to make our lives easier going forward.
w/r/t file layout: Ben's proposed scheme (${body_type}/${head_type}/${animation}/${category}/${subcategories}/${object}/${variant}.png) is elegant in that it goes from broadest to narrowest category. It also means you could easily identify all objects available for a given base and remove entire bases/bodies that you don't use. However I see three related issues:
spritesheets for same object (e.g. a hat) on different bases (or head types) are very similar. (In the case of hat, hair, etc. they are probably derived from the same source image(s)). But this scheme puts them in very distant folders. This means that when someone adds/edits an asset, they have to touch multiple distant folders and also update the CREDITS.csv file in probably very distant places. This would be a minor but very practical annoyance.
this scheme requires duplicating a rather large and deep file hierarchy, i.e. the categories/subcategories of every object, across all body_types and head_types and animations. As opposed to duplicating body_type/head_type/animation for each object, if the scheme were more like ${category}/${subcategories...}/${object}/${body_type}/${head_type}/${animation}/${variant}.png , which I'm beginning to think I favor. It seems more likely that the folder hierarchies would end up "out of sync" (i.e. we end up with female/human/torso/jacket but male/human/torso/clothes/jacket, just by accident). Enforcing a scheme like ${category}/${subcategories...}/${object}/${body_type}/${head_type}/${animation}/${variant}.png with a "linting" script would be relatively simpler; you just check that every path ends in ${body_type}/${head_type}/${animation}, with a list of permissible values for each (perhaps derived from elsewhere in repo, e.g. body_type can be the name of any of the subdirectories of bodies/
some objects may use the same spritesheet for different body_types. For example, hair for female and pregnant can mostly use the same images. The generator JSON system allows this (you just mention the same file path for the two different body_types). But it seems somewhat less intuitive in this scheme... there would have to either be a) both female/human/universal/hat/tricorne.png and pregnant/human/universal/hat/tricorne.png, or b) you would have to know to search for some pregant assets in the female directory, i.e. you would need to parse the JSON files anyway, negating the advantage of having all assets for a given body_type in one directory, or c) you would need top-level directories for various combinations of body_types, e.g. female_and_pregnant, male_and_muscular, etc. All of these solutions seem somewhat inelegant to me.
w/r/t separate vs. combined sheets: agreed w/ Herodom that a single combined sheet is easier for the generator web page; we'd have to re-write a lot of things to accommodate separate images per animation, and I don't think anyone is really too eager to do that given how previous efforts to revamp the generator from scratch have all fizzled out. I also get Evert's point that making the sheet longer and longer is not optimal, but I feel like introducing some kind of packing scheme other than "animations arranged top-to-bottom, N/E/S/W" is too complicated for the generator. If someone wants to pack sheets more tightly, they can use a sprite atlas packer, or even lpctools.
What if we add space for the other directions of the hurt animation (i.e. add two blank rows after "shoot", then the current south-facing hurt animation, then another blank row), then start adding new animations below that, in the order they are added to the generator? We adapt the generator to assume the assembled image will be 832x1536px (current "universal" layout is 832x1344px, add 3*64px height for the other directions of the hurt animation) or taller, and align all layers to the top-left corner? That would be a fairly minor change I think. Adding support for new animations to the generator would just mean telling it which named animation comes next, which would be simple. After scaling everything for the missing death animations (a one-time operation that could be done with lpctools), we wouldn't have to edit any of the existing images until someone drew the new animations for them.
A final alternative, that might (??) please everyone: we separate each animation into distinct images, but then also programmatically assemble a universal stacked layout (as I described above) offline using lpctools as part of the build process. So every asset has ./cast/*.png, ./thrust/*.png, ... ./jump/*.png, and ./universal/*.png. It could also have ./legacy/*.png which would use the old layout (i.e the single-direction death animation); perhaps we re-name the "universal" layout to "stacked" or "universal-stacked" or something like that. The generator website only needs to support the growing universal stacked layout, but if someone wants to use the collection of images in their game, they can work from the individual animations if they prefer.
w/r/t separate heads necessary? @Herodom/Castelonia: agreed we could easily start by replacing the bases with these ones, that is definitely most practical. However it will not produce very useful results; many of the bases (e.g. lizard, wolf, probably minotaur?) will not work well with existing clothing assets since the head overlaps with the torso more than the human head, so the chin will be covered by shirt collars, etc. So we definitely need an ability to add heads on a separate layer and we should figure out how to do that.
w/r/t adding any head to any body, the more I think about it the solution seems to be to name the head_types human-male, human-female, human-child, orc-male, orc-female, etc. rather than just "human", "orc", etc.
The head variant (i.e. color) should be linked to the body variant by default. I think we can add a field in the JSON file called "match_variant_to_body" or something, and for layers where that is `true`, if the variant of the body changes then the variant of that layer will be changed as well. Heads would obviously have this propery, so would ears, noses, wings (if we add them), tails, etc., anything that follows a skin color.
One final issue to consider is that many assets won't care about the head_type (e.g. shirts, pants, etc.). So maybe they get a folder in the hierarchy that is just head_type=all, e.g. torso/clothes/longsleeve/male/all/universal/green.png , or maybe the head_type subdirectory is optional, e.g. torso/clothes/longsleeve/male/universal/green.png . The former seems more consistent and therefore probably better.
So in summary, I think I vote for ${category}/${subcategories...}/${object}/${body_type}/${head_type}/${layout}/${variant}.png , where "layout" is either the name of an animation, or a composite layout such as "universal" or "legacy". The individual animations are the ground truth and the composite image is assembled using lpctools as part of the build process.
Two things that help with this:
1) I always download assets into a folder named by the last part of the OGA url, e.g. I would download https://opengameart.org/content/lpc-ship into a folder called "lpc-ship", that I way I can find it again.
2) If you go to your user page, there is a hidden collection called "My Downloads" which you can use to see all the assets you have downloaded. This is helpful if you remember downloading something but can't find where it came from. Super helpful feature of OGA that I think most users are unaware of.
Obviously there will be scenarios where these tricks don't work, but I have found them helpful temporary solutions.
Simple but useful and well-executed. Nice! Maybe diagonal directions next? ;-)
The scaled image has been anti-aliased; you did not enable nearest neighbor/disable filtering when scaling.
Zoom in on the image. Notice that instead of 5 distinct colors there are many shades of grey. This is due to anti-aliasing applied by the scaling algorithm. It makes the image not really look like pixel art anymore.
FYI, even with nearest neighbor scaling, you often need to hand-edit pixel art when you scale it. Prototype 2 looks better than 1 for this reason, although it still has anti-aliasing on the internal parts of the fish.
I'd be happy to keep giving feedback on this and/or other sprites, but maybe we should move the conversation to a different thread?
Looks nice! I would just scale it down in whatever program you usally use (I use PyxelEdit for pixel art, Aseprite is also good; GIMP would work too, but make sure to set the interpolation mode to "None" or "Nearest Neighbor" so you don't get aliasing).
I am making a fishing animation for one of this month's commissions on my Ko-fi page; this will go nicely together! https://ko-fi.com/bluecarrot16
More like this (I only edited the first frame for each direction). Very minor edit, but I think it makes the light source more clear and the object look more 3D as a consequence.
re: adding extra death animations, what would you suggest we do instead Evert? Just add jump, run, etc. as we go below the death animation? Again, I don't plan on implementing a more complicated layout system or support multiple images within the generator website (I already did that within lpctools, so I don't think it's a big burden to use that on the resulting images if you want a different layout)... so unless someone else adds that, if there's going to be any support for more animations in the generator it will probably have to be by stacking them in one big image.
re: colors, this looks like a good start! I would suggest previewing them on the character bases to be sure they look right; hard to tell from the palette whether they have quite enough contrast. Should be easy to do with lpctools and imagemagick, let me know if you need help.
Eliza posted this guide on Discord somewhere for her then-latest version of the Liberated palette, which names the color ramps she uses for skin, clothes, and hair; might be helpful to you.
What about the wolfman/boarman colors? Ben used a few of the hair color palettes to make several different wolfman colors here https://opengameart.org/content/lpc-wolfman ; they could apply equally well to the boarman and potentially other furry/hairy creatures I think. Do you want to include them in this set?
Thanks so much for posting this, Hyptosis! I love the way the floor tiles imply so much texture, but they're borderless so you can mix and match. Very effective. Also the giant anvil is so cool, lots of personality there.
Looks like there is some banding in the preview image, but it's not present in the actual download.
Looks nice! Maybe adjust the shading so that it implies more of a 3/4 perspective than top-down? E.g. move the light-gray shading from the middle more towards the top.
Thanks YuriNikolai! That is a great idea to focus on foragable plants. I found this Wikipedia article (which is not very comprehensive), as well as this neat website. (I definitely referenced that Wikipedia article on culinary fruits, as well as the List of Vegetables page while working on my Foods pack :p). Still seems like a huge list, I would love it someone could help prioritize for me ;-)
FiveBrosStopMosYT, that is great, exactly what I was thinking! Now you just need a biting/tugging animation (maybe?). And maybe it needs different directions, or maybe it just gets rotated in-engine?
Good discussion here, thanks for contributing everyone. Not sure we're any closer to a consensus, but it's helpful to talk it out. Sorry if this is a bit pedantic, I'm just trying to think thru the best structure to make our lives easier going forward.
w/r/t file layout: Ben's proposed scheme (${body_type}/${head_type}/${animation}/${category}/${subcategories}/${object}/${variant}.png) is elegant in that it goes from broadest to narrowest category. It also means you could easily identify all objects available for a given base and remove entire bases/bodies that you don't use. However I see three related issues:
w/r/t separate vs. combined sheets: agreed w/ Herodom that a single combined sheet is easier for the generator web page; we'd have to re-write a lot of things to accommodate separate images per animation, and I don't think anyone is really too eager to do that given how previous efforts to revamp the generator from scratch have all fizzled out. I also get Evert's point that making the sheet longer and longer is not optimal, but I feel like introducing some kind of packing scheme other than "animations arranged top-to-bottom, N/E/S/W" is too complicated for the generator. If someone wants to pack sheets more tightly, they can use a sprite atlas packer, or even lpctools.
What if we add space for the other directions of the hurt animation (i.e. add two blank rows after "shoot", then the current south-facing hurt animation, then another blank row), then start adding new animations below that, in the order they are added to the generator? We adapt the generator to assume the assembled image will be 832x1536px (current "universal" layout is 832x1344px, add 3*64px height for the other directions of the hurt animation) or taller, and align all layers to the top-left corner? That would be a fairly minor change I think. Adding support for new animations to the generator would just mean telling it which named animation comes next, which would be simple. After scaling everything for the missing death animations (a one-time operation that could be done with lpctools), we wouldn't have to edit any of the existing images until someone drew the new animations for them.
A final alternative, that might (??) please everyone: we separate each animation into distinct images, but then also programmatically assemble a universal stacked layout (as I described above) offline using lpctools as part of the build process. So every asset has ./cast/*.png, ./thrust/*.png, ... ./jump/*.png, and ./universal/*.png. It could also have ./legacy/*.png which would use the old layout (i.e the single-direction death animation); perhaps we re-name the "universal" layout to "stacked" or "universal-stacked" or something like that. The generator website only needs to support the growing universal stacked layout, but if someone wants to use the collection of images in their game, they can work from the individual animations if they prefer.
w/r/t separate heads necessary? @Herodom/Castelonia: agreed we could easily start by replacing the bases with these ones, that is definitely most practical. However it will not produce very useful results; many of the bases (e.g. lizard, wolf, probably minotaur?) will not work well with existing clothing assets since the head overlaps with the torso more than the human head, so the chin will be covered by shirt collars, etc. So we definitely need an ability to add heads on a separate layer and we should figure out how to do that.
w/r/t adding any head to any body, the more I think about it the solution seems to be to name the head_types human-male, human-female, human-child, orc-male, orc-female, etc. rather than just "human", "orc", etc.
The head variant (i.e. color) should be linked to the body variant by default. I think we can add a field in the JSON file called "match_variant_to_body" or something, and for layers where that is `true`, if the variant of the body changes then the variant of that layer will be changed as well. Heads would obviously have this propery, so would ears, noses, wings (if we add them), tails, etc., anything that follows a skin color.
One final issue to consider is that many assets won't care about the head_type (e.g. shirts, pants, etc.). So maybe they get a folder in the hierarchy that is just head_type=all, e.g. torso/clothes/longsleeve/male/all/universal/green.png , or maybe the head_type subdirectory is optional, e.g. torso/clothes/longsleeve/male/universal/green.png . The former seems more consistent and therefore probably better.
So in summary, I think I vote for ${category}/${subcategories...}/${object}/${body_type}/${head_type}/${layout}/${variant}.png , where "layout" is either the name of an animation, or a composite layout such as "universal" or "legacy". The individual animations are the ground truth and the composite image is assembled using lpctools as part of the build process.
Pages