Here are the advantages I see for both multiple and single files. Am I missing anything?
Single file:
Better compression for games that have to fit a tight file size.
Better for games where loading assets is a bottleneck.
Easier to share the animations. There's no need to create a zip to bundle everything together.
Multiple files:
Easier to pick and choose which animations you want for your game. No need to split a file if you want to save space by removing unused animations.
Non-standard animations don't need special treatment.
Automated repacking of animations into a single file with an order and animation list tailored to your specific game is easier. No code has to be written to figure out where the animations start and end, and no special cases (such as "run" being in "special attack") need to be worried about.
Encourages more variety in monster abilities.
My biggest concern with the single file approach is how to handle non-standard animations. Do they go in a slot meant for another animation? Are they added to the end after all the other animations? Do we put them in a separate file?
I believe non-standard animations will be the rule, more than the exception. An ostrich could have walk, run, and glide animations. A penguin could walk, swim, and belly slide. A dragon could have claw, bite, fire, and tail attacks. A bear can have two of every animation: once on all fours, and once standing upright. Will a single file have slots for all of these things, even though most creatures won't use them?
@Gaurav I'm happy to discuss implementation details, but I think I'd need to see your code to be of any help, and I don't want to derail the thread.
If your code plays all 5 frames (even for animations that weren't originally 5 frames long) you will have odd timing and hitches in your animations, especially animations that are meant to loop. For example, the walk animation is actually 4 frames long. The first frame is the stand/idle. Play it back with and without that frame. Which is a smoother cycle?
Putting the run in the "Special Attack" slot defeats the purpose of a standardized animation order. Your code would need a special case for it.
This should be a good compromise between the needs of flexibility and the needs of programmers to not have to keep a database of what images have what animations and where.
It seems you and I approach this problem very differently. I would use a separate image for each animation. They would be stored in a standard location. For the wolf, the file path would look something like this:
./resources/images/animations/wolf/walk.png
The only thing that ever changes in this file path is the name of the creature and the name of the animation.
My code needs to store what animations each creature has. Even if all the animations were in a single image, I would need to know that the spider has no auxiliary action, or that the wolf has a run in the special attack.
I don't have to store the number of frames in an animation. I can get that by dividing the width of the image by the frame size.
I would probably store the frame size as an integer. I'm already storing the available animations, so it's not much more effort to store that too. Though, as a side note, it would be possible to calculate it by dividing the height of the image by 4.
To be clear, I was not advocating that we make 4 frames the standard. I certainly do not think we should make every animation use the same number. There is absolutely no reason a basic idle needs as many frames as a walk cycle or an attack. The number of frames required will vary from creature to creature and animation to animation.
I think it might help to define a little terminology here. A standard is a requirement that must be met to be considered compatible with LPC. A convention is a common practice that most artists follow, but is not required.
The original LPC guidelines set standards for perspective, sprite size, and shading, but only set two standards for animations: the vertical layout of the spritesheet, and what order the directions should appear on the spritesheet. They provide example spritesheets that follow the standards, but the spritesheets themselves are not the standard.
The convention has been to use the Universal LPC spritesheet for humanoid animations, which has made it difficult for new animations to be adopted. As a convention, it has been a net good for the LPC community, but as a standard it is too restrictive.
I don't believe we should set standards for animation lists or frame counts. Those will vary based on the needs of each monster, and requirements of the artist (or the person commissioning the artist!) for their own game.
My suggestion of 4 frames was meant as a reminder that the first new monster in a category will set the convention for sprite size, frame count, and default list of animations for all derivatives. Just like making the wolf's walk cycle longer or shorter, it will require significant effort to change them later.
Other than the direction order that bluecarrot mentioned, I'd add a couple of things to the list of conventions that improve the ease of using and editing spritesheets:
Frames should be square, even for long/tall creatures.
Frame dimensions should fit evenly on a 32x32 pixel grid.
Only one animation should be in each row.
The animations required will depend heavily on the type of monster. My recommendation for the basics is: movement in all four directions, and at least one frame for dying/death.
It might be possible to create several enemies of similar size from the same base, provided they use the same type of movement. For example, with a head, tail, and color swap I think we could get an okay lion out of the wolf.
If anoyone does want to create completely new monsters, I suggest using as few frames as possible. A 4 frame walk cycle, 1 frame death, 2 frame attack, etc. Fewer frames means less effort to create a derivative, which leads to a much wider variety of creatures.
This is pretty cool! I like how you've organized the assets, and the layers export seems pretty useful.
I'm looking forward to whenever you release your source code. I've also been working on a new spritesheet generator, so I'm curious to compare how we both approached some of the features.
So it's about what I thought still. People divided between preferring classic LPC vs. Eliza's LPC styles (regardless of difference in quantity of sprites). Hence saying there's two camps
I think we all agree that Eliza's work is really nice. However, she made several changes that break compatibility with existing assets. Either all existing assets need to be modified to work with Eliza's LPC, or alternatively Eliza's LPC could be modified to work with the existing assets.
Changing everything that's already been created is not a good option. The edits required are not as trivial as bzt thinks, and none of us (except maybe Eliza) has the time.
Eliza's LPC may someday be the standard, but right now it isn't ready for that. It does not have the same wide range of assets, and the conversation that has been going on here shows that it does not yet have the required support from the community.
That's a completely unnecessary waste of resources, considering the only difference between these sheets is +/- 1 pixel shifts on certain frames. [...] It is enough to have a single "sword" spritesheet
Many of the artists who have posted in this thread have been (or currently are) involved with that project, and when it is ready I will create a fork of the style guide based on it.
I've been in communication with bluecarrot16, but they're pretty busy with a large project right now, so I wouldn't expect them to write something about tiles any time soon.
Small steps is the point of smaller certifications. I listed 4 that cover everything that exists. In small steps, the artists here would meet those certifications. With a single large certification, we are asking the artists to make big steps.
plus the ones people on the forum would really like to have.
The majority of people on the forum are artists. We would really like to have more of the animations become standard and we have the skills to do it, but the lack of a certification is not what is stopping us. The time investment is.
Nope, it is off. [...] very few submissions would need to rework the base like the head [...] only clothes-type assets need all the animations, but not the others.
The head swap is a simpler change than most clothing assets. The times I gave are lower than they would be for clothing.
most weapon-like assets do not need to be redrawn at all, just repositioned a little to fit to the guide.
I'm fully aware. My LPC Weapons took closer to 10-15 minutes per frame. A single weapon is still probably a 3 to 5 hour project.
Plus you can swap palettes with a single-click.
The palette swap was by far the easiest part of the project. It does not significantly affect the times I gave, but I don't have data about how long I spent on palettes versus other parts of the project.
Update: made "sit" optional. Now there's 6 animation (which LPC already had), plus 2 ("run", "jump"). I think nobody can say that's not reasonable.
Fair enough. I will note: the run animation is not ready to be standard. There are 6 primary character bases (Child, Female, Pregnant, Male, Muscular, and Teen) and most of them do not support the run yet.
This is probably my last post specifically about certification. I've given my opinion, and don't think there is much more I could add.
maps with tiles and objects are typically created using Tiled, which imposes no restrictions, so I'm not sure we should either.
Not every game uses hand-crafted maps. What about games with procedural generation, or a building mechanic?
Whether it is a requirement or just a suggestion, I think it would be valuable to have some of that information added to the guide. That said, the expert on LPC tiles and objects is really @bluecarrot16, so I would defer to them on what should be included here.
This specification does not stop you from releasing your art! It only demands that the "LPC-CERT" tag can be added to your submission when it's ready to be used in games, and not sooner.
Correct me if I'm wrong, but the LPC-CERT tag is intended to do two things:
Make it easier to find assets that have a complete set of animations
Encourage artists to release assets with a complete set of animations
In order to do either of those things, it has to set a standard for what is considered complete. No one likes to release unfinished art. If there is a standard for completeness, artists will wait to publish their work until they meet it, even if that means it sits on their computer forever.
You've listed 9 animations as mandatory. If an artist only needs 2 of those for their game, they will either never release their art, or never bother to meet the certification requirements. No one wins in this situation.
If we have several smaller certifications the artist will only need to create 1 or 2 additional animations to meet one, and they are much more likely to actually do it. Those are animations that would never have been created if the certification required all 9 animations.
If these small certifications have overlapping requirements (for example if LPC-MELEE-CERT requires a couple of animations that are also required for LPC-MEDIEVAL-CERT) then another artist is more likely to finish those last few animations needed for the next certification.
The disadvantage is that there is no single tag to find all LPC art that has a complete set of animations. However, there would still be many tags for smaller sets of animation which would make it easier to find art that can be used for a specific game.
I realize that for your own project, TirNanoG, that this is not the ideal situation, but I believe that many smaller certifications will lead to more assets being compatible with more animations than a single mega-certification ever will.
For reference, the standard 6 animations (cast, thrust, walk, slash, shoot, and hurt) have around 100 frames of animation after you remove all the frames that are mirrorred and duplicated. My LPC Wolfman took an average of 2.5 minutes per frame. That's 4 hours of work for a head swap and palette change. That is the simplest project you can ask for. A moderately complex project (like a new shirt, pants, or weapon) can take 2 to 3 times longer, and something more complex than that would take even longer still.
If my count is correct, the 3 new animations add 46 non-duplicated frames. That is an additional 2 hours of work. The simplest possible asset requires 6 hours to support all animations currently listed as required for the certification.
Compare that to a list of smaller certifications:
Base: Idle/Walk, Hurt (1 hour)
Combat: Thrust, Slash, Shoot (2.5 hours)
Movement: Jump, Run (1.5 hours)
Misc: Cast, Sit (1 hour)
If an artist has already created an asset with just 1 of these sets of animations, they are much more likely to create additional animations they did not need for their own project if the time commitment is small.
Here are the advantages I see for both multiple and single files. Am I missing anything?
Single file:
Multiple files:
My biggest concern with the single file approach is how to handle non-standard animations. Do they go in a slot meant for another animation? Are they added to the end after all the other animations? Do we put them in a separate file?
I believe non-standard animations will be the rule, more than the exception. An ostrich could have walk, run, and glide animations. A penguin could walk, swim, and belly slide. A dragon could have claw, bite, fire, and tail attacks. A bear can have two of every animation: once on all fours, and once standing upright. Will a single file have slots for all of these things, even though most creatures won't use them?
@Gaurav I'm happy to discuss implementation details, but I think I'd need to see your code to be of any help, and I don't want to derail the thread.
If your code plays all 5 frames (even for animations that weren't originally 5 frames long) you will have odd timing and hitches in your animations, especially animations that are meant to loop. For example, the walk animation is actually 4 frames long. The first frame is the stand/idle. Play it back with and without that frame. Which is a smoother cycle?
Putting the run in the "Special Attack" slot defeats the purpose of a standardized animation order. Your code would need a special case for it.
It seems you and I approach this problem very differently. I would use a separate image for each animation. They would be stored in a standard location. For the wolf, the file path would look something like this:
./resources/images/animations/wolf/walk.png
The only thing that ever changes in this file path is the name of the creature and the name of the animation.
My code needs to store what animations each creature has. Even if all the animations were in a single image, I would need to know that the spider has no auxiliary action, or that the wolf has a run in the special attack.
I don't have to store the number of frames in an animation. I can get that by dividing the width of the image by the frame size.
I would probably store the frame size as an integer. I'm already storing the available animations, so it's not much more effort to store that too. Though, as a side note, it would be possible to calculate it by dividing the height of the image by 4.
To be clear, I was not advocating that we make 4 frames the standard. I certainly do not think we should make every animation use the same number. There is absolutely no reason a basic idle needs as many frames as a walk cycle or an attack. The number of frames required will vary from creature to creature and animation to animation.
I think it might help to define a little terminology here. A standard is a requirement that must be met to be considered compatible with LPC. A convention is a common practice that most artists follow, but is not required.
The original LPC guidelines set standards for perspective, sprite size, and shading, but only set two standards for animations: the vertical layout of the spritesheet, and what order the directions should appear on the spritesheet. They provide example spritesheets that follow the standards, but the spritesheets themselves are not the standard.
The convention has been to use the Universal LPC spritesheet for humanoid animations, which has made it difficult for new animations to be adopted. As a convention, it has been a net good for the LPC community, but as a standard it is too restrictive.
I don't believe we should set standards for animation lists or frame counts. Those will vary based on the needs of each monster, and requirements of the artist (or the person commissioning the artist!) for their own game.
My suggestion of 4 frames was meant as a reminder that the first new monster in a category will set the convention for sprite size, frame count, and default list of animations for all derivatives. Just like making the wolf's walk cycle longer or shorter, it will require significant effort to change them later.
Other than the direction order that bluecarrot mentioned, I'd add a couple of things to the list of conventions that improve the ease of using and editing spritesheets:
The animations required will depend heavily on the type of monster. My recommendation for the basics is: movement in all four directions, and at least one frame for dying/death.
It might be possible to create several enemies of similar size from the same base, provided they use the same type of movement. For example, with a head, tail, and color swap I think we could get an okay lion out of the wolf.
If anoyone does want to create completely new monsters, I suggest using as few frames as possible. A 4 frame walk cycle, 1 frame death, 2 frame attack, etc. Fewer frames means less effort to create a derivative, which leads to a much wider variety of creatures.
This is pretty cool! I like how you've organized the assets, and the layers export seems pretty useful.
I'm looking forward to whenever you release your source code. I've also been working on a new spritesheet generator, so I'm curious to compare how we both approached some of the features.
I think we all agree that Eliza's work is really nice. However, she made several changes that break compatibility with existing assets. Either all existing assets need to be modified to work with Eliza's LPC, or alternatively Eliza's LPC could be modified to work with the existing assets.
Changing everything that's already been created is not a good option. The edits required are not as trivial as bzt thinks, and none of us (except maybe Eliza) has the time.
Eliza's LPC may someday be the standard, but right now it isn't ready for that. It does not have the same wide range of assets, and the conversation that has been going on here shows that it does not yet have the required support from the community.
Are you aware of the existing project that was inspired by last time this was all discussed on the forum? When the next update is ready (and it almost is) this will no longer be a big issue.
Many of the artists who have posted in this thread have been (or currently are) involved with that project, and when it is ready I will create a fork of the style guide based on it.
I don't have any more suggestions at the moment.
I've been in communication with bluecarrot16, but they're pretty busy with a large project right now, so I wouldn't expect them to write something about tiles any time soon.
Small steps is the point of smaller certifications. I listed 4 that cover everything that exists. In small steps, the artists here would meet those certifications. With a single large certification, we are asking the artists to make big steps.
The majority of people on the forum are artists. We would really like to have more of the animations become standard and we have the skills to do it, but the lack of a certification is not what is stopping us. The time investment is.
The head swap is a simpler change than most clothing assets. The times I gave are lower than they would be for clothing.
I'm fully aware. My LPC Weapons took closer to 10-15 minutes per frame. A single weapon is still probably a 3 to 5 hour project.
The palette swap was by far the easiest part of the project. It does not significantly affect the times I gave, but I don't have data about how long I spent on palettes versus other parts of the project.
Fair enough. I will note: the run animation is not ready to be standard. There are 6 primary character bases (Child, Female, Pregnant, Male, Muscular, and Teen) and most of them do not support the run yet.
This is probably my last post specifically about certification. I've given my opinion, and don't think there is much more I could add.
Not every game uses hand-crafted maps. What about games with procedural generation, or a building mechanic?
Whether it is a requirement or just a suggestion, I think it would be valuable to have some of that information added to the guide. That said, the expert on LPC tiles and objects is really @bluecarrot16, so I would defer to them on what should be included here.
Correct me if I'm wrong, but the LPC-CERT tag is intended to do two things:
In order to do either of those things, it has to set a standard for what is considered complete. No one likes to release unfinished art. If there is a standard for completeness, artists will wait to publish their work until they meet it, even if that means it sits on their computer forever.
You've listed 9 animations as mandatory. If an artist only needs 2 of those for their game, they will either never release their art, or never bother to meet the certification requirements. No one wins in this situation.
If we have several smaller certifications the artist will only need to create 1 or 2 additional animations to meet one, and they are much more likely to actually do it. Those are animations that would never have been created if the certification required all 9 animations.
If these small certifications have overlapping requirements (for example if LPC-MELEE-CERT requires a couple of animations that are also required for LPC-MEDIEVAL-CERT) then another artist is more likely to finish those last few animations needed for the next certification.
The disadvantage is that there is no single tag to find all LPC art that has a complete set of animations. However, there would still be many tags for smaller sets of animation which would make it easier to find art that can be used for a specific game.
I realize that for your own project, TirNanoG, that this is not the ideal situation, but I believe that many smaller certifications will lead to more assets being compatible with more animations than a single mega-certification ever will.
For reference, the standard 6 animations (cast, thrust, walk, slash, shoot, and hurt) have around 100 frames of animation after you remove all the frames that are mirrorred and duplicated. My LPC Wolfman took an average of 2.5 minutes per frame. That's 4 hours of work for a head swap and palette change. That is the simplest project you can ask for. A moderately complex project (like a new shirt, pants, or weapon) can take 2 to 3 times longer, and something more complex than that would take even longer still.
If my count is correct, the 3 new animations add 46 non-duplicated frames. That is an additional 2 hours of work. The simplest possible asset requires 6 hours to support all animations currently listed as required for the certification.
Compare that to a list of smaller certifications:
If an artist has already created an asset with just 1 of these sets of animations, they are much more likely to create additional animations they did not need for their own project if the time commitment is small.
Thanks bluecarrot!
I will make time to look these in the next day or two and let you know my opinion on your four proposed changes.
Pages