a more consistent color palette, especially in the generators
Tilesets should have that problem, too. I think Skorpio deviates in his original sci-fi submission quite a bit. And my space tileset takes the colors of the original one instead of LPC's.
For Spritesheet stuff the following unified palettes would be very practical:
Skin colors (so far I used ElizaWy's)
Hair colors
Clothing colors (fabric, leather)
Metal colors (for amor)
If all use the same amount of colors and similar color distances within a palette set, it should be possible to swap palettes (just loading a different palette) without any manual work needed.
Somebody skilled in drawing should probably redesign the reptilean heads, their lighting does not fit with the rest.
I think the tilesets have a lot of issues of combining chairs, tables, cupboards, shelves and objects which are meant to be put on them.
extending the animation set to include new actions, such as swimming, sitting, or alternate attacks
Other classical RPG animations, we currently lack, are climbing, push/pull (stone block or something) and jumping (zelda has all of these)
I also have a "carry" and "push" animation based on the normal walk cycle.
I think I too might have some attempt on that lying around somewhere.
This does not fix animations, it just generalizes them by splitting bodies into several images and using cut masks (hand in front of head). If I remember correctly, I had to change a few things in the sprites to make automation easier. This submission is all about automation.
So far, I left out animations which cover the head since those get complicated if head forms differ too much.
Especially head wear could be easily automated in a similar way, it just needs a variation for each direction of each head. Long hear and everything that gets in front or behind the body is more complicated.
Clothing that gets in front of the head, would need specific head masks.
A lot of automated moving around, copying and cutting can be done with Image Magick, but that ruins the color order of indexed PNG, which makes palette swapping impossible.
Automating as much as possible also allows to propagate changes, made to the base sprites, more easily. On the other hand it makes a few things look worse, since you try to create as many similarities between frames as possible.
So far I did not dare to also dive into clothing automation, so I don't know how good it'll work.
By ordering layers properly it becomes much easier to build up a complicated sprite.
Head shadow on the upper body also heeds it's own layer.
I could try doing a new version of modular bodies, where I chop them up even more. But maybe with a different build process this time, which can be used by other people more easily ^^'.
It's basically interesting, because it would allow peg legs, hook hands, cyborg prothesis and such nice things.
What I would like next is a clearly documented set of instructions.
This could be automatically generated if you already have that animation in a machine readable form (which would be the case if spritesheets get assembled automatically)
I think male and female heads are different?
Take a look at my modular bodies, they are only partly different. The top is the same, so hats are universal, the jaw line of females is narrower. What you most likely ran into is the fact, that female heads are often a pixel lower than male ones.
There are a few sets of "facial expressions" around
Yep. they are hard to do. The eyes are small and the mouth isn't drawn at all. They could be integrated into modularized human heads. But they would be completely incompatible with other heads (wolf, ogre, drake).
Oh, and I've wanted a comically huge and long beard for ages
And that's where layering starts to get a bit more complicated.
I'm not much of an artist and have limited time
Me neither and I'm currently more in my low-level-C-phase than my pixelart-remix-phase.
Needing to split every new submission into pieces adds a complexity that we may not want.
On the other hand that makes it a lot easier to extend for others. If it does not contain duplicate frames, it should be a lot easier to create new assets. You just have to draw the torso once and then do the different arm parts, otherwise you will end up drawing the same thing again and again if you are not careful. If I use the Base animations as an example: the walking animation includes the same frame (legs parallel) twice and compared to standing they only have different legs and feet, the rest is the same. Also all animations start with the standang (same) frame. Deduplication definitely needs scripts for composition or at least documentation which frames have to be reused. Automation scripts (also script for creating gifs) can be a help for figuring out how to use the sheets ingame.
Like Evert, I definitely have more of a coder's view than an artist's. "Redundancy reduction". The less I have to repeat tasks, the better.
Also, I think more/better tools to automatically adapt items from one base to another would smooth this process out a lot.
This needs layering, though.
the last thing we need is a 20-frame run cycle
It is okay if >10 frames are just duplicates of other animations
Maybe you should use the dark brown for outlines (like the head) when other body parts are covered, as opposed to the dark gray used for the silhouette (EDIT: I was wrong, the base assets do it just like that)
I guess, LPC will just continue to fork and fragment more like it's often the case in Open Source Software. But that is again in my eyes an argument for layering, since it's easier to port stuff if you can easily figure out which parts you can reuse. The more spritesheets fragment, the more interesting it gets to do automated sheet generation.
I don't think that is necessarily a bad thing. As you mention, all flora/ fauna/ buildings whatever still go with both the old and the new characters.
Brave Nude World
Personally, I would support an LPC2.0 set, I could even think about financing a new event like how the LPC1.0 started in 2012.
A new Liberated Pixel Cup would be nice indeed, maybe a 10 Years Liberated Pixel Cup next year or something.
I think it would be a shame to "lose" compatibility with all the existing art.
afaik that's already the case, because there are various variations of the base sprites around and clothing submissions might be based on different versions.
But like castelonia said, you can always combine different base sprites. NPCs only have to stand and maybe around, so they can use the original sprites. And NPCs are probably what needs most clothing variations.
You know, would anybody be interested in a Discord server for the LPC set?
I don't like discord "server"s, it's very unfree and centralistic.
It's not publically accessible and everything will be lost if Discord gets discontinued. OGA can be archived with archive.org
Thouh, it should rather be a group within the OGA "server".
I'd never include them, since I did not like the animations, but yes, every animation not part of the Base Assets is not covered by all
Some animations which where created during the cup are widely adopted, like wulax's thrust and bow animations. Skorpio's two handed gun animation on the other hand was widely ignored, despite also being an original cup submission.
TL;DR: I'm in general very interested in quantity over quality automatization. Aggressive automation needs layers in seperate PNGs for automatic composition and indexed 8bit PNGs with standardized color orders for palette swapping. If palettes of different materials share colors, palette swapping also might need subpalettes or different material being separated into different layers.
...maybe I gonna do modularized bodies 2.0 with some basic clothings, depending on where my procrastinating makes me end up. In either case it would be more a technical demo like the first one. Maybe just with GNU Make, GNU core utilities, shell scripting, Image Magick, gifsicle and loadpgl (python3+pypng) this time.
Changing the palette of an image is for me similar to changing the font of a book.
But I think in pixel art and by now especially in the way it's handled on gameboy color, where the image and the palette are very disconnected things. So it might be different for other art forms.
But automatic recoloring does very likely not count as a derivative work, meaning it can't be separately copyrighted. Also color palettes themself can't be copyrighted afaik.
It is different if you edit an image to fit a new palette.
I also think that a game is usually not seen as just one work and instead each asset as well as the code are considered separately. Otherwise you wouldn't be able to combine assets with different licenses.
I have to read this thread yet. (Sorry I rarely visit the forums)
> these are impressive tools that showcase the work of this community. However, near as I can tell, none are properly attributing the art that is used.
My fork was exactly focusing on attribution generation https://basxto.github.io/lpc-spritesheet-collection/
It's unfinisihed and I already put quite some work into it to clean up some spritesheets to allow palette swapping.
EDIT1: (read first post, omg I hate reading)
I see, you found my little fork.
I start to remember a few things and wanna write them down before I forget about it:
I guess the main problem was that I tried to do two things at once, which overwhelmed me pretty quickly. I 1) wanted to do generate useful attributions because I hate all those generators and atlases and 2) I wanted to change colors with palette switching. I wasn't able to implement proper palette in JS, because browsers suck, instead only managed to replace colors by value. That only works if palettes don't share colors.
I wanted to do palette swapping to increase usability of the spritesheets without generating a color mess and another reason was to get rid of submission who just did some palette swapping. That would just litter the attribution file.
But for that you basically have to, aside from tracking down attributions, add remix submission for a lot of stuff. For meaningful palette swapping all assets have to use the same base palette (all hair blond, all metal gold etc.). And you also have to clean up dirty submissions, who use an insane amount of unique but similar colors.
I think I started with roman helmets and the knight helmets, they are still lying around somewhere. I quickly realized how hard it is to get incompatible submissions onto the same base palette. The lighting etc. has to work the same for both. That's where I gave up.
EDIT2:
OGA's attribution files are unnecessarily lengthy and incomplete.
And I remember that my attribution generator is inclomplete. Skorpio's MaleWalkShoot is a remix.
My plan was to track dependencies, since a lot of submissions are based on the same stuff. This would allow to draw an attribution tree, which would avoid listing authors multiple times and therefore make everything shorter and more readable.
And that already neglegts that you actually have to list what exactly you changed in a remix, pretty much no submissions does that. (neither do mine)
Even though that could at least be auto generated for palette swaps.
> A place on the web where all their names and work are visible and all the submissions are gathered.
I don't consider myself an artist, but there are definetely a few LPC-related submissions, I don't wanna be associated with. (aforementioned true color accidents or submissions who don't fit LPC style in my eyes). I want people to judge me by my own botched submissions.
The biggest issue with atlases and generators is, that you can't easily find the original submissions. Which is important when I want to remix something, or ask the author something or see new versions (some updates did not propagate) or see remixes based on it or check if the attribution is even correct or see usage examples. The last point is more relevant for tilesets.
EDIT3:
> a recolor is definitely creating a derivative work and requires attribution
Depending on how it's done, it might not even be copyrightable. If it's trivial you can easily replace it with generated recoloring.
And it would be extremely useful if there was something to preview tilesets (switch floors, walls, puzzle cupboards together etc.), but I did not come up with a good idea of doing that, yet.
EDIT4:
Even though my werewolf wasn't used ... yes, my script recolors. I think it uses switchpalette.sh from https://github.com/basxto/lpc-shell-tools
Especially in those modular submissions, I try to avoid redundancy.
Oh, I missed this challenge.
So I'm adding https://opengameart.org/content/lpc-portraits-remix retroactively.
I did not create it for this challenge, but I think it fits it well. I moved it to one of my favorite palettes, the hair and skin tone palettes of LPC.
@Sharm:
No, those are too many colors.
Transparent is counted as a color, so it's using 5 colors.
But my demake of tiny16 explicitly targets cgb/dmg: https://opengameart.org/content/tinygb-characters
I haven't tested the newly added animations though. Couldn't get myself to implement character animation into my game yet. But the basic walking animation is unchanged.
I used black shadows on humanoid for cgb compatibility, since white is transparent, light grey is skin color and dark grey is clothing/hair color.
All characters in my game are from or based on tiny16, but the tileset is zoria.
@withthelove:
Sounds like a good workflow.
I think you'll need automatic color translation mostly for getting to your final palette translation, which then can be automatically applied.
I think batch processing is especially useful with stuff from open game art.
If you take assets and manually adapt them and the original submission gets updated, you'll have no benefit from that.
If you do it automated, you can just replace it with the updated version.
Switching to an extended version only works if it keeps the original format. Unless you also automatically change the tile format.
Tip for treating parts of the spritesheet differently:
I sometimes add new (duplicate) colors to the palette, then lock all colors in mtPaint but the one I want to replace, select an area and fill it with the new color. The image itself does not change, since I change only changed the used index, but not the associated color.
You can do that too. You could allow to select an area and then show all colors used in that area and allow the user to split off one of the colors. With that you would have duplicate colors in virtual palette, but the colors could have a different context.
And regaring CLI version:
Maybe you wanna take a look at my fork of https://github.com/basxto/Universal-Spritesheet-Character-Generator
It allows to change the palettes (hardcoded palettes for skin, clothes, metals etc.) both in the browser and in the terminal (node.js)
a more consistent color palette, especially in the generators
Tilesets should have that problem, too. I think Skorpio deviates in his original sci-fi submission quite a bit. And my space tileset takes the colors of the original one instead of LPC's.
For Spritesheet stuff the following unified palettes would be very practical:
If all use the same amount of colors and similar color distances within a palette set, it should be possible to swap palettes (just loading a different palette) without any manual work needed.
Somebody skilled in drawing should probably redesign the reptilean heads, their lighting does not fit with the rest.
I think the tilesets have a lot of issues of combining chairs, tables, cupboards, shelves and objects which are meant to be put on them.
Other classical RPG animations, we currently lack, are climbing, push/pull (stone block or something) and jumping (zelda has all of these)
I think I too might have some attempt on that lying around somewhere.
This does not fix animations, it just generalizes them by splitting bodies into several images and using cut masks (hand in front of head). If I remember correctly, I had to change a few things in the sprites to make automation easier. This submission is all about automation.
So far, I left out animations which cover the head since those get complicated if head forms differ too much.
Especially head wear could be easily automated in a similar way, it just needs a variation for each direction of each head. Long hear and everything that gets in front or behind the body is more complicated.
Clothing that gets in front of the head, would need specific head masks.
A lot of automated moving around, copying and cutting can be done with Image Magick, but that ruins the color order of indexed PNG, which makes palette swapping impossible.
Automating as much as possible also allows to propagate changes, made to the base sprites, more easily. On the other hand it makes a few things look worse, since you try to create as many similarities between frames as possible.
So far I did not dare to also dive into clothing automation, so I don't know how good it'll work.
Head shadow on the upper body also heeds it's own layer.
I could try doing a new version of modular bodies, where I chop them up even more. But maybe with a different build process this time, which can be used by other people more easily ^^'.
It's basically interesting, because it would allow peg legs, hook hands, cyborg prothesis and such nice things.
This could be automatically generated if you already have that animation in a machine readable form (which would be the case if spritesheets get assembled automatically)
Take a look at my modular bodies, they are only partly different. The top is the same, so hats are universal, the jaw line of females is narrower. What you most likely ran into is the fact, that female heads are often a pixel lower than male ones.
Yep. they are hard to do. The eyes are small and the mouth isn't drawn at all. They could be integrated into modularized human heads. But they would be completely incompatible with other heads (wolf, ogre, drake).
Oh, and I've wanted a comically huge and long beard for ages
And that's where layering starts to get a bit more complicated.
Me neither and I'm currently more in my low-level-C-phase than my pixelart-remix-phase.
On the other hand that makes it a lot easier to extend for others. If it does not contain duplicate frames, it should be a lot easier to create new assets. You just have to draw the torso once and then do the different arm parts, otherwise you will end up drawing the same thing again and again if you are not careful. If I use the Base animations as an example: the walking animation includes the same frame (legs parallel) twice and compared to standing they only have different legs and feet, the rest is the same. Also all animations start with the standang (same) frame. Deduplication definitely needs scripts for composition or at least documentation which frames have to be reused. Automation scripts (also script for creating gifs) can be a help for figuring out how to use the sheets ingame.
Like Evert, I definitely have more of a coder's view than an artist's. "Redundancy reduction". The less I have to repeat tasks, the better.
It is okay if >10 frames are just duplicates of other animations
Maybe you should use the dark brown for outlines (like the head) when other body parts are covered, as opposed to the dark gray used for the silhouette (EDIT: I was wrong, the base assets do it just like that)
I guess, LPC will just continue to fork and fragment more like it's often the case in Open Source Software. But that is again in my eyes an argument for layering, since it's easier to port stuff if you can easily figure out which parts you can reuse. The more spritesheets fragment, the more interesting it gets to do automated sheet generation.
Brave Nude World
A new Liberated Pixel Cup would be nice indeed, maybe a 10 Years Liberated Pixel Cup next year or something.
afaik that's already the case, because there are various variations of the base sprites around and clothing submissions might be based on different versions.
But like castelonia said, you can always combine different base sprites. NPCs only have to stand and maybe around, so they can use the original sprites. And NPCs are probably what needs most clothing variations.
I don't like discord "server"s, it's very unfree and centralistic.
It's not publically accessible and everything will be lost if Discord gets discontinued. OGA can be archived with archive.org
Thouh, it should rather be a group within the OGA "server".
I'd never include them, since I did not like the animations, but yes, every animation not part of the Base Assets is not covered by all
Some animations which where created during the cup are widely adopted, like wulax's thrust and bow animations. Skorpio's two handed gun animation on the other hand was widely ignored, despite also being an original cup submission.
TL;DR: I'm in general very interested in quantity over quality automatization. Aggressive automation needs layers in seperate PNGs for automatic composition and indexed 8bit PNGs with standardized color orders for palette swapping. If palettes of different materials share colors, palette swapping also might need subpalettes or different material being separated into different layers.
...maybe I gonna do modularized bodies 2.0 with some basic clothings, depending on where my procrastinating makes me end up. In either case it would be more a technical demo like the first one. Maybe just with GNU Make, GNU core utilities, shell scripting, Image Magick, gifsicle and loadpgl (python3+pypng) this time.
> Unrelated, does LPC even have an official color palette now that I think about it?
https://lpc.opengameart.org/static/lpc-style-guide/styleguide.html#light... (near the end of that section)
Changing the palette of an image is for me similar to changing the font of a book.
But I think in pixel art and by now especially in the way it's handled on gameboy color, where the image and the palette are very disconnected things. So it might be different for other art forms.
But automatic recoloring does very likely not count as a derivative work, meaning it can't be separately copyrighted. Also color palettes themself can't be copyrighted afaik.
It is different if you edit an image to fit a new palette.
I also think that a game is usually not seen as just one work and instead each asset as well as the code are considered separately. Otherwise you wouldn't be able to combine assets with different licenses.
I have to read this thread yet. (Sorry I rarely visit the forums)
> these are impressive tools that showcase the work of this community. However, near as I can tell, none are properly attributing the art that is used.
My fork was exactly focusing on attribution generation https://basxto.github.io/lpc-spritesheet-collection/
It's unfinisihed and I already put quite some work into it to clean up some spritesheets to allow palette swapping.
EDIT1: (read first post, omg I hate reading)
I see, you found my little fork.
I start to remember a few things and wanna write them down before I forget about it:
I guess the main problem was that I tried to do two things at once, which overwhelmed me pretty quickly. I 1) wanted to do generate useful attributions because I hate all those generators and atlases and 2) I wanted to change colors with palette switching. I wasn't able to implement proper palette in JS, because browsers suck, instead only managed to replace colors by value. That only works if palettes don't share colors.
I wanted to do palette swapping to increase usability of the spritesheets without generating a color mess and another reason was to get rid of submission who just did some palette swapping. That would just litter the attribution file.
But for that you basically have to, aside from tracking down attributions, add remix submission for a lot of stuff. For meaningful palette swapping all assets have to use the same base palette (all hair blond, all metal gold etc.). And you also have to clean up dirty submissions, who use an insane amount of unique but similar colors.
I think I started with roman helmets and the knight helmets, they are still lying around somewhere. I quickly realized how hard it is to get incompatible submissions onto the same base palette. The lighting etc. has to work the same for both. That's where I gave up.
EDIT2:
OGA's attribution files are unnecessarily lengthy and incomplete.
And I remember that my attribution generator is inclomplete. Skorpio's MaleWalkShoot is a remix.
My plan was to track dependencies, since a lot of submissions are based on the same stuff. This would allow to draw an attribution tree, which would avoid listing authors multiple times and therefore make everything shorter and more readable.
And that already neglegts that you actually have to list what exactly you changed in a remix, pretty much no submissions does that. (neither do mine)
Even though that could at least be auto generated for palette swaps.
> A place on the web where all their names and work are visible and all the submissions are gathered.
I don't consider myself an artist, but there are definetely a few LPC-related submissions, I don't wanna be associated with. (aforementioned true color accidents or submissions who don't fit LPC style in my eyes). I want people to judge me by my own botched submissions.
The biggest issue with atlases and generators is, that you can't easily find the original submissions. Which is important when I want to remix something, or ask the author something or see new versions (some updates did not propagate) or see remixes based on it or check if the attribution is even correct or see usage examples. The last point is more relevant for tilesets.
EDIT3:
> a recolor is definitely creating a derivative work and requires attribution
Depending on how it's done, it might not even be copyrightable. If it's trivial you can easily replace it with generated recoloring.
And it would be extremely useful if there was something to preview tilesets (switch floors, walls, puzzle cupboards together etc.), but I did not come up with a good idea of doing that, yet.
EDIT4:
Even though my werewolf wasn't used ... yes, my script recolors. I think it uses switchpalette.sh from https://github.com/basxto/lpc-shell-tools
Especially in those modular submissions, I try to avoid redundancy.
And ehrm ... the description of https://github.com/sanderfrenken/Universal-LPC-Spritesheet-Character-Gen... still links to the old generator
Where is the toilet from?
There are https://opengameart.org/content/tiny-16-expanded-character-sprites and https://opengameart.org/content/tiny-16-more-character-animations
Another quick and dirty one: https://opengameart.org/content/tinygb-portraits-remix
Zoria palette with Game Boy Color restrictions (4 colors per 8x8)
Oh, I missed this challenge.
So I'm adding https://opengameart.org/content/lpc-portraits-remix retroactively.
I did not create it for this challenge, but I think it fits it well. I moved it to one of my favorite palettes, the hair and skin tone palettes of LPC.
@Sharm:
No, those are too many colors.
Transparent is counted as a color, so it's using 5 colors.
But my demake of tiny16 explicitly targets cgb/dmg: https://opengameart.org/content/tinygb-characters
I haven't tested the newly added animations though. Couldn't get myself to implement character animation into my game yet. But the basic walking animation is unchanged.
I used black shadows on humanoid for cgb compatibility, since white is transparent, light grey is skin color and dark grey is clothing/hair color.
All characters in my game are from or based on tiny16, but the tileset is zoria.
@withthelove:
Sounds like a good workflow.
I think you'll need automatic color translation mostly for getting to your final palette translation, which then can be automatically applied.
I think batch processing is especially useful with stuff from open game art.
If you take assets and manually adapt them and the original submission gets updated, you'll have no benefit from that.
If you do it automated, you can just replace it with the updated version.
Switching to an extended version only works if it keeps the original format. Unless you also automatically change the tile format.
For characters the base and clothings should be seperated like in many LPC submissions, though. If that's not the case it won't work nicely, like it's the case with tiny16 since skin and hair share colors.
The naked guy would work, though. You should be easily able to switch from a dark skinned https://opengameart.org/content/tiny-16-basic to https://opengameart.org/content/tiny-16-expanded-character-sprites or https://opengameart.org/content/tiny-16-more-character-animations
Tip for treating parts of the spritesheet differently:
I sometimes add new (duplicate) colors to the palette, then lock all colors in mtPaint but the one I want to replace, select an area and fill it with the new color. The image itself does not change, since I change only changed the used index, but not the associated color.
You can do that too. You could allow to select an area and then show all colors used in that area and allow the user to split off one of the colors. With that you would have duplicate colors in virtual palette, but the colors could have a different context.
And regaring CLI version:
Maybe you wanna take a look at my fork of https://github.com/basxto/Universal-Spritesheet-Character-Generator
It allows to change the palettes (hardcoded palettes for skin, clothes, metals etc.) both in the browser and in the terminal (node.js)
Pages