However, Tsorthan Grove is correct: all licenses on OpenGameArt allow for resale. This is by necessity. Saying "you can't resell it" creates unintended legal entanglements that make the assets effectively unusable. Unfortunately, specifying "you can sell it within a game, just not by itself" doesn't resolve it.
The good news is, it is already pretty difficult for someone to resell them by themselves; The license, CC-BY 4.0, requires that a potential reseller must credit you and link to this page (or your home page). Anyone who might want to buy the assets from the reseller would see that it is available for free and not bother paying the reseller.
With that in mind, would you be willing to forego the "no reselling" restriction? Until then, I must mark it as having a licensing issue to prevent people from using it in a way you may not approve of.
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.
Neat. This appears to be a hexagram, though.
I love your work, Idylwild.
FYI:EDIT: Fixed, thanks! :)
Excellent textures!
However, Tsorthan Grove is correct: all licenses on OpenGameArt allow for resale. This is by necessity. Saying "you can't resell it" creates unintended legal entanglements that make the assets effectively unusable. Unfortunately, specifying "you can sell it within a game, just not by itself" doesn't resolve it.The good news is, it is already pretty difficult for someone to resell them by themselves; The license, CC-BY 4.0, requires that a potential reseller must credit you and link to this page (or your home page). Anyone who might want to buy the assets from the reseller would see that it is available for free and not bother paying the reseller.With that in mind, would you be willing to forego the "no reselling" restriction? Until then, I must mark it as having a licensing issue to prevent people from using it in a way you may not approve of.EDIT: Fixed, thanks! :)
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.
Lol! You can mark it as spam if you want to. But it's not actual spam. Just pretend spam making fun of spammers as an April fools joke.
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.
Pages