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?
Right? I shot water into my ear with a pressure-washer and this is exactly what it sounded like.
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?
Pages