(all what I say about animations is only about male)
Frame duplicates and mirrors (if you ignore the head) are nice indeed, also for transitioning to standing pose or a different animation. Walkcycle has two frames, which can transition to to standing, so it's never more than 3 frames away from standing. This is especially for actions which are very likely interruptible like walking and running, it should also not look too bad if somebody decides to directly switch to standing. It would probably also be good if you can transition from walking to running and back every frame.
But there are also other ways of reuse, you don't have to duplicate the frame, just legs, torso or arms helps already a lot. You don't have to completely redraw and instead just reposition and draw the transitions between body parts. Thrust animation uses this a lot. From food wear perspective it's 2-3 new frames per direction, despite having 5 completely unique frames. One frame of the sideways animation is nearly the same in thrust and bow shooting, only the wrist rotation is different.
I think the original cup submissions should be definitely streamlined since they were developed in parallel. Drag and thrust sideway animations could be more similar. Gun shooting does not really look good, I think some parts of bow shooting could be merged into it. Both utilize outflung arms, but they are drawn differently.
And maybe we should produce some visual manual on how to draw the frames, what can be reused etc. Guidance to which frames (the least covered version like frame 10 from bow shooting) should be drawn first, since they can be reused in other frames. Or even the production of dummy frames derived from my layered stuff to ease drawing of parts, which are reused but also covered a lot. Layers could also help to build visualizations where duplicate parts are tinted red.
This would help showing new contributors how much work has to be done. I only once drew something for the sprite sheets and remember that I drew a lot of duplicates, but only realized that when it was too late.
I haven't yet started playing with layered clothes, but while looking through the existing animations, I realized that won't be enough. I'll also need to make cut outs and make sure that body part transitions aren't cut out. Shoulder should be behind the head, but the forearm and hand in front of it. Shoulder of the back arm should be infront of the torso (I think armor needs this) but the rest has to be behind the body. The big pro for automating clothes is that you can easily apply retextures like my Major Triumph shield to the base frames and immediately have a full spritesheet.
Another huge problem with LPC is information distribution. Whatever we agree on in here will be unknown to new contributors. I think ideally we should link the LPC Collection, add an extended art guide for the animations, maybe even integrate or link some sprite generators on lpc.opengameart.org. The code is open source, the linked repo has vanished, but https://github.com/OpenGameArt/LiberatedPixelCup does still exist.
Is sleeping more than standing facing down and combining it with closing eyes from spellcast?
Swimming is probably just the upper body and keeping everything under water hidden?
Chopping should also be waist high, biggest difference towards crafting is probably dual-wielded tool usage. This overlaps somewhat with the tileset reworking of tables and objects you can put on them, since the animation will interact with those objects.
Carry shares, at least if it's overhead, problems with bow shooting and every other gesture that would press arms or hands against the head. It would only work for the human heads and has to be redone for every differently sized head.
Handshakes are also highly problematic, it would pretty much be restricted to bare handed characters since every glove would need cut outs for every other glove. Or I'm overthinking this.
EDIT: This animation also does exist, I have no idea how that should be called [LPC] caeles' art, but some frames could be reused for crafting.
I'm done splitting the walkcycle.
I modified it a bit here and there.
I'll also attach a gif and recombined spritesheet.
But I have yet to playe around with this and clothings.
Any ideas which clothing submissions are best for testing? Something in fabric (flexible) as well as metal (stiff) and with few (maybe just standing) animations supported as well as many (original animations and wulax's) would be practical, I guess.
EDIT2: I expanded the mapping syntax a bit. index;; defaults to index;0;0 and there are now multiple ways of defining the index. :row:column, #column (with current row in csv), -index mirrors the tile and can be combined with : and #, otherwise the index is just counted left to right, top to bottom. (the last notation is impractical if the image width is expected to change) # is practical if the image is organized in 4 rows, each for a direction. : is practical for mirroring left direction for getting right direction.
I would like to see them go in the opposite direction---fewer frames
I first switch my build system to what I used for the portraits. Then I'll update the heads, wanna include Ben's new wolf head and if possible the zombie. Then I'll try to split stuff into layers, I need that for (bow) shooting animation anyways, that's why I stopped last time. If that worked, I gonna see how hard it is to build/port clothings based on that.
And then I'll see what animations can be achieved by recombining the frames in new ways, well that's what the modular set is about ... creating new variation with as little as effort as possible. Maybe I can even get back to my superhero stuff, I stopped because it became annoyingly repetitive.
One-handed shoot (pistol)
Two-handed shoot (rifle)
As said, [LPC] Skorpio's SciFi Sprite Pack has a shooting animation. I looked into it again, it's two handed pistol _and_ two handed rifle in one. It's the walking animation with different hands, so this should benefit from layering, since only the arms have to be redone. (and we could easily make one handed shooting by giving the other hand a different animation)
I think I will continue using the simple csv format, which I used for positioning heads. It's just tile id, x-offset, y-offset. I will extend it so that a negative id means it's mirrored, but aside from that it should be sufficient. Are there any other formats around?
head, torso, front arm, back arm, front leg, back leg
That's probably the best idea.
And I just counted the frames of original assets (walkcycle, slash, hurt, spellcast), they have 94 frames, of which are 40 either duplicates or mirrored versions of other ones.
I don't think I start using more layers yet, but I'll try to improve the build process a bit. I'll just play around with the original walk cycle and layers in a temporary directory.
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.
(all what I say about animations is only about male)
Frame duplicates and mirrors (if you ignore the head) are nice indeed, also for transitioning to standing pose or a different animation. Walkcycle has two frames, which can transition to to standing, so it's never more than 3 frames away from standing. This is especially for actions which are very likely interruptible like walking and running, it should also not look too bad if somebody decides to directly switch to standing. It would probably also be good if you can transition from walking to running and back every frame.
But there are also other ways of reuse, you don't have to duplicate the frame, just legs, torso or arms helps already a lot. You don't have to completely redraw and instead just reposition and draw the transitions between body parts. Thrust animation uses this a lot. From food wear perspective it's 2-3 new frames per direction, despite having 5 completely unique frames. One frame of the sideways animation is nearly the same in thrust and bow shooting, only the wrist rotation is different.
I think the original cup submissions should be definitely streamlined since they were developed in parallel. Drag and thrust sideway animations could be more similar. Gun shooting does not really look good, I think some parts of bow shooting could be merged into it. Both utilize outflung arms, but they are drawn differently.
And maybe we should produce some visual manual on how to draw the frames, what can be reused etc. Guidance to which frames (the least covered version like frame 10 from bow shooting) should be drawn first, since they can be reused in other frames. Or even the production of dummy frames derived from my layered stuff to ease drawing of parts, which are reused but also covered a lot. Layers could also help to build visualizations where duplicate parts are tinted red.
This would help showing new contributors how much work has to be done. I only once drew something for the sprite sheets and remember that I drew a lot of duplicates, but only realized that when it was too late.
I haven't yet started playing with layered clothes, but while looking through the existing animations, I realized that won't be enough. I'll also need to make cut outs and make sure that body part transitions aren't cut out. Shoulder should be behind the head, but the forearm and hand in front of it. Shoulder of the back arm should be infront of the torso (I think armor needs this) but the rest has to be behind the body. The big pro for automating clothes is that you can easily apply retextures like my Major Triumph shield to the base frames and immediately have a full spritesheet.
Another huge problem with LPC is information distribution. Whatever we agree on in here will be unknown to new contributors. I think ideally we should link the LPC Collection, add an extended art guide for the animations, maybe even integrate or link some sprite generators on lpc.opengameart.org. The code is open source, the linked repo has vanished, but https://github.com/OpenGameArt/LiberatedPixelCup does still exist.
https://opengameart.org/content/lpc-animated-water-and-fire, https://opengameart.org/content/lpc-full-plate-golden-armor-0 and https://opengameart.org/content/lpc-skorpios-scifi-sprite-pack is missing
Regarding the animations:
The grab animation is from Daneeklu's LPC submission, which was resubmitted as [LPC] Farming tilesets, magic animations and UI elements
I guess we need different kinds of push/pull, depending on the size of an object? Pushing a wheelbarrow is quite different from push a man-high rock in a.
Is sleeping more than standing facing down and combining it with closing eyes from spellcast?
Swimming is probably just the upper body and keeping everything under water hidden?
Chopping should also be waist high, biggest difference towards crafting is probably dual-wielded tool usage. This overlaps somewhat with the tileset reworking of tables and objects you can put on them, since the animation will interact with those objects.
Carry shares, at least if it's overhead, problems with bow shooting and every other gesture that would press arms or hands against the head. It would only work for the human heads and has to be redone for every differently sized head.
Handshakes are also highly problematic, it would pretty much be restricted to bare handed characters since every glove would need cut outs for every other glove. Or I'm overthinking this.
EDIT: This animation also does exist, I have no idea how that should be called [LPC] caeles' art, but some frames could be reused for crafting.
I'm done splitting the walkcycle.
I modified it a bit here and there.
I'll also attach a gif and recombined spritesheet.
But I have yet to playe around with this and clothings.
EDIT:
The mapping rules are located here
Any ideas which clothing submissions are best for testing? Something in fabric (flexible) as well as metal (stiff) and with few (maybe just standing) animations supported as well as many (original animations and wulax's) would be practical, I guess.
EDIT2: I expanded the mapping syntax a bit. index;; defaults to index;0;0 and there are now multiple ways of defining the index. :row:column, #column (with current row in csv), -index mirrors the tile and can be combined with : and #, otherwise the index is just counted left to right, top to bottom. (the last notation is impractical if the image width is expected to change) # is practical if the image is organized in 4 rows, each for a direction. : is practical for mirroring left direction for getting right direction.
EDIT3: I guess I'll go with:
I think this can be used for a edge-like game
I first switch my build system to what I used for the portraits. Then I'll update the heads, wanna include Ben's new wolf head and if possible the zombie. Then I'll try to split stuff into layers, I need that for (bow) shooting animation anyways, that's why I stopped last time. If that worked, I gonna see how hard it is to build/port clothings based on that.
And then I'll see what animations can be achieved by recombining the frames in new ways, well that's what the modular set is about ... creating new variation with as little as effort as possible. Maybe I can even get back to my superhero stuff, I stopped because it became annoyingly repetitive.
As said, [LPC] Skorpio's SciFi Sprite Pack has a shooting animation. I looked into it again, it's two handed pistol _and_ two handed rifle in one. It's the walking animation with different hands, so this should benefit from layering, since only the arms have to be redone. (and we could easily make one handed shooting by giving the other hand a different animation)
I think I will continue using the simple csv format, which I used for positioning heads. It's just tile id, x-offset, y-offset. I will extend it so that a negative id means it's mirrored, but aside from that it should be sufficient. Are there any other formats around?
https://github.com/basxto/lpc-shell-tools/blob/master/animation/head/fem...
That's probably the best idea.
And I just counted the frames of original assets (walkcycle, slash, hurt, spellcast), they have 94 frames, of which are 40 either duplicates or mirrored versions of other ones.
Since I can't add any zips here and since modular bodies is already a git repository, I think I gonna tinker with it on github: https://github.com/basxto/lpc-modular-characters
I don't think I start using more layers yet, but I'll try to improve the build process a bit. I'll just play around with the original walk cycle and layers in a temporary directory.
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.
Horizontally, some have 2 pixels more on the right than on the left.
Pages