Oh, that's very interesting. No mention of number of frames, (intentionally, I assume) so the frame count can vary as required; the width of the image will simply be wider if more frames are needed. I can't speak to other dev's needs, but I am a Dev, not an Artist, and I can say for me personally those 5 convention rules would make it quite easy for me to dynamically load animations, without the need for custom sprite-specific code handling.
If frame[i].X + frame[i].width > spritesheet.width Or frame[i].isAllTransparentPixels { set LastFrame = i - 1 }
I also agree with size optimization needs being a developer task, not an artist task. sprite-packing is highly engine-specific, so trying to pre-empt that step is more likely to increase work for the developer.
True. That's a problem for all conventions we've discussed so far. What about a JSON file included with each monster's spritesheet(s)? The JSON file would indicate what animations are supported, regardless of composite- (single file) or separate- (multiple file) animation spritesheet conventions. If separate data files give you the ick, how else would a game engine dynamically recognize the presence or absence of an animation? And would that be less cumbersome?
I think I understand now. In which case, it seems like any animation that could possibly be optional should be a separate file. However, I can imagine monsters where even the "move" animations are optional: ie a poison spine shooting killer plant. Doesn't move, but has a ranged attack. This is a fringe example, admittedly, but it does make me wonder: what animations, if any, should be together in a single file, then?
- Idle: Not really necessary for the most part, but it could be a simple bob. - Taking Damage: ...it can be reflected with a red overlay or something like that as well. We don't necessarily need a "I took a hit" animation. - Death/defeat: ...Typically enemies just "fade away" when being defeated. This is not necessary and completedly optional. - Spellcasting/Special Attack: ...A special attack isn't really all that necessary. - Optional Auxiliry Action: I'd argue this would be the "Special Attack". Not sure what else would fit this category. - 4-directional:... isn't necessary.
Well, yeah. Any action can be represented simpler than the standarts suggest they could be. The only thing neccessary for a monster "animation" is a single frame of the monster. Idle: that one frame. Taking damage: That same frame replicated, but flash it white on the second frame. Death: Same frame, but red, or with a code-side dissolve effect. Movement? Just use the one frame, but implement code that bounces the one frame along like a south-park character.
I don't think these standards are defining the minimum complexity that each monster should have, are they? Artists aren't required to do extra work to fill out every animation action slot for every monster just because the slot is there, are they? I assumed these standards would just be a common outline for how the monsters should be organized. On the other hand, anybody that wants more animations/actions than the standards account for would be breaking standards. Meaning, any developer wanting to use that non-standard monster would have to go rework their code because they coded their animation engine according to standards that don't account for anything but the bare minimum. For example: The original LPC guidelines don't account for climbing, archery, jumping, etc. I'm not suggesting we rework all LPC assets to include those neccessarily, but they have since been popular requested additions, and it has caused a lot of difficulty incorporating them retroactively (such as to ULPCG) because there's no standard place for such additions.
"Special attack" isn't going to be used by all monsters, but there will certainly be enough monsters that do have more than one attack. If a given monster doesn't use it, just replicate the "Basic Attack" frames in that slot. Similar situation for "Auxiliary Action". It could be a 3rd attack, or it could be a special mutation animation for Boss monsters: "this isn't even my final form!" It's just a catch-all slot for anything the monster concept needs but the standards don't otherwise have a place for it.
The reason I was suggesting more than was neccessary is because making animations simpler than the standards allow is much easier than making animations more complex than the standards allow later.
I think there is a concept for enemy sprite sheets, but it may not be a very robust concept. The LPC enemies generally do not need any equipment or clothes, as Guarav says, so they are generally simple animations + North,South,East,West facing frames. To illustrate Guarav's point: Non-humanoid LPC monsters
A few other enemy spritesets are more involved, such as William's wolf but, as Guarav says, most of the more complex enemies are humanoid, like a goblin or minotaur which are modifications of the LPC character base. Not a bad thing, but also not the kind of enemy that adds a lot of diversity to the foe list.
I don't have very good answers to these questions, but I am very interested in the discussion:
Standards, yes! but I suspect it will be difficult to have any sort of dimension standars since "enemy" implies such a huge variety of sizes. Some monsters being very long, but not tall, and vice versa. If there is a standard size, it would have to be very large, and all smaller enemies would fit within it... Or there would need to be a separate third standard for huge boss enemies, yes?
Animations:
Moving North,
Moving South,
Moving East/West (mirror? this works for humanoid characters because we're a symmetrical species. Not so all monsters.),
Moving West (if assymeterical)
Idle,
Taking Damage,
Death/defeat,
Basic Attack,
Spellcasting Special Attack,
Optional Auxiliry Action (just a slot for an additional attack or atypical feature. many monsters won't use this slot but it's available if needed)
As implied by my suggested animation list above, I think there should be all four cardinal directions for enemies to be truly compatible with LPC. Although full 4-directional movement animations are not usually necessary for turn-based JRPG style combat, that is hardly the only system the LPC assets are being applied to. The LPC characters move around in 4 directions. For the enemies to fully exist in the same world, they must also be able to move around in 4 directions, IMHO.
I cannot imagine incorporating non-humanoid enemies into the character generator. I agree about the needless restrictions that would impose. It seems like it would be far less work to create a separate "enemy spritesheet generator" considering how weird these non-humanoid enemeies are compared to the humanoid characters. Or even humanoid enemies that are very diverse in size: Cyclops, Ettin, Leprichaun, Brownie,.. Centaur?! Do all the weird Greek mythological half-human crossbreeds count as "humanoid"?
Maybe they're safe. They're certainly more likely to be safe, but I can't agree they are difinitively safe enough to create assets and share them on OGA just yet. I hope that will be the case soon.
That revisits a concern I had from earlier in the thread:
"It would only infringe on the copyright if the asset is too similar to the original asset."
Be careful with this. Similarity is not the reason something is infringing copyright. It is just the most common tool in determining if copying took place. Copying can still take place, and therefore be copyright infringement, even when the result of the copying looks very dissimilar from the original. It's just usually very hard to prove copying took place when the original and the new work look dissimilar.
I have seen someone get DMCA'd (and lost) because he used Chrono Trigger character sprites as a basis for his characters. He morphed the sprites multiple tiimes, tweaking them over a long period. Eventually, the characters were not recognizable as coming from Chrono Trigger at all. He appealed the DMCA saying there was no similarity betwen them and therefore it was not copying. The lawyers cited his dev-log, where he chronicled the entire process of copying Chrono Trigger assets and adjusting them until they were unrecognizable compared to the original assets. It was proof enough that copying did occur, despite a lack of similarity. Because his assets would not have existed without first coming from copyrighted content, they were deemed infringing.
If the end work is so dissimilar from what you're using as a base that you don't really even recognize the original base at all; then you should not use the original base at all.
If you still want to use the original base because it's easier and serves as a helpful guide; then you are benefitting from the effort of another artist without their consent: possible infringement.
On the contrary, this is distinct from using other art as inspiration. If you look at Chrono Trigger sprites, and that gives you some good ideas, then you stop looking at the copyrighted sprites, then begin to create your own sprites in roughly the same shape and animation style based on your own learned skills plus what you recall from the inspiring source, but are not actually repeatedly referencing, or overlaying, or tracing, or clipping any parts of the original, that is not infringement. It's inspiration. As stated above, this is what all artists do all the time. I'm not sure it's what AI's do at all, though. And that's the crux of the uncertainty.
Looking forward to when/if there is a fully openly-trained model some day. That being said, I do feel there is a distinction between generative AI and transformative AI. the asset rotation tool is not generating artwork nor adding features to the artwork that weren't in the original (which would mean the features were being added from the learned dataset) but are only transforming the existing art based on what the AI observed from other artwork. That seems more like inspiration or skills-learning rather than derivation from other works. Perhaps that is a specious distinction, I don't know. I'll have to dig into that more.
Oh, that's very interesting. No mention of number of frames, (intentionally, I assume) so the frame count can vary as required; the width of the image will simply be wider if more frames are needed. I can't speak to other dev's needs, but I am a Dev, not an Artist, and I can say for me personally those 5 convention rules would make it quite easy for me to dynamically load animations, without the need for custom sprite-specific code handling.
If frame[i].X + frame[i].width > spritesheet.width Or frame[i].isAllTransparentPixels {set LastFrame = i - 1}I also agree with size optimization needs being a developer task, not an artist task. sprite-packing is highly engine-specific, so trying to pre-empt that step is more likely to increase work for the developer.
True. That's a problem for all conventions we've discussed so far. What about a JSON file included with each monster's spritesheet(s)? The JSON file would indicate what animations are supported, regardless of composite- (single file) or separate- (multiple file) animation spritesheet conventions. If separate data files give you the ick, how else would a game engine dynamically recognize the presence or absence of an animation? And would that be less cumbersome?
Looks like option #2 is off your page
Edit: ah ok. That explains it.
?? Why not just download it from the download link on this page?
Also, Kenney's page does download the assets as well. When you click the purple download button, it gives two options:
Which is pretty standard.
I think I understand now. In which case, it seems like any animation that could possibly be optional should be a separate file. However, I can imagine monsters where even the "move" animations are optional: ie a poison spine shooting killer plant. Doesn't move, but has a ranged attack. This is a fringe example, admittedly, but it does make me wonder: what animations, if any, should be together in a single file, then?
Well, yeah. Any action can be represented simpler than the standarts suggest they could be. The only thing neccessary for a monster "animation" is a single frame of the monster. Idle: that one frame. Taking damage: That same frame replicated, but flash it white on the second frame. Death: Same frame, but red, or with a code-side dissolve effect. Movement? Just use the one frame, but implement code that bounces the one frame along like a south-park character.
I don't think these standards are defining the minimum complexity that each monster should have, are they? Artists aren't required to do extra work to fill out every animation action slot for every monster just because the slot is there, are they? I assumed these standards would just be a common outline for how the monsters should be organized. On the other hand, anybody that wants more animations/actions than the standards account for would be breaking standards. Meaning, any developer wanting to use that non-standard monster would have to go rework their code because they coded their animation engine according to standards that don't account for anything but the bare minimum. For example: The original LPC guidelines don't account for climbing, archery, jumping, etc. I'm not suggesting we rework all LPC assets to include those neccessarily, but they have since been popular requested additions, and it has caused a lot of difficulty incorporating them retroactively (such as to ULPCG) because there's no standard place for such additions.
"Special attack" isn't going to be used by all monsters, but there will certainly be enough monsters that do have more than one attack. If a given monster doesn't use it, just replicate the "Basic Attack" frames in that slot. Similar situation for "Auxiliary Action". It could be a 3rd attack, or it could be a special mutation animation for Boss monsters: "this isn't even my final form!" It's just a catch-all slot for anything the monster concept needs but the standards don't otherwise have a place for it.
The reason I was suggesting more than was neccessary is because making animations simpler than the standards allow is much easier than making animations more complex than the standards allow later.
I think there is a concept for enemy sprite sheets, but it may not be a very robust concept. The LPC enemies generally do not need any equipment or clothes, as Guarav says, so they are generally simple animations + North,South,East,West facing frames. To illustrate Guarav's point: Non-humanoid LPC monsters
A few other enemy spritesets are more involved, such as William's wolf but, as Guarav says, most of the more complex enemies are humanoid, like a goblin or minotaur which are modifications of the LPC character base. Not a bad thing, but also not the kind of enemy that adds a lot of diversity to the foe list.
I don't have very good answers to these questions, but I am very interested in the discussion:
SpellcastingSpecial Attack,Maybe they're safe. They're certainly more likely to be safe, but I can't agree they are difinitively safe enough to create assets and share them on OGA just yet. I hope that will be the case soon.
That revisits a concern I had from earlier in the thread:
Be careful with this. Similarity is not the reason something is infringing copyright. It is just the most common tool in determining if copying took place. Copying can still take place, and therefore be copyright infringement, even when the result of the copying looks very dissimilar from the original. It's just usually very hard to prove copying took place when the original and the new work look dissimilar.
I have seen someone get DMCA'd (and lost) because he used Chrono Trigger character sprites as a basis for his characters. He morphed the sprites multiple tiimes, tweaking them over a long period. Eventually, the characters were not recognizable as coming from Chrono Trigger at all. He appealed the DMCA saying there was no similarity betwen them and therefore it was not copying. The lawyers cited his dev-log, where he chronicled the entire process of copying Chrono Trigger assets and adjusting them until they were unrecognizable compared to the original assets. It was proof enough that copying did occur, despite a lack of similarity. Because his assets would not have existed without first coming from copyrighted content, they were deemed infringing.
On the contrary, this is distinct from using other art as inspiration. If you look at Chrono Trigger sprites, and that gives you some good ideas, then you stop looking at the copyrighted sprites, then begin to create your own sprites in roughly the same shape and animation style based on your own learned skills plus what you recall from the inspiring source, but are not actually repeatedly referencing, or overlaying, or tracing, or clipping any parts of the original, that is not infringement. It's inspiration. As stated above, this is what all artists do all the time. I'm not sure it's what AI's do at all, though. And that's the crux of the uncertainty.
Looking forward to when/if there is a fully openly-trained model some day. That being said, I do feel there is a distinction between generative AI and transformative AI. the asset rotation tool is not generating artwork nor adding features to the artwork that weren't in the original (which would mean the features were being added from the learned dataset) but are only transforming the existing art based on what the AI observed from other artwork. That seems more like inspiration or skills-learning rather than derivation from other works. Perhaps that is a specious distinction, I don't know. I'll have to dig into that more.
Pages