I will also say that having a set of more basic animations for enemy/NPC sprites and a more richly animated set of animations intended for player characters is not unreasonable. On the other hand, dividing resources (available artist time) over multiple sets rather than having a single good set is not good, and it's probably better to have one set with better variety.
My thoughts exactly!
What I personally look for is modularity and adaptability. I'm not a pixel artist, and modifying art for my specific purpose is easier if it's modular ... Having the arms separated also makes it easier to quickly make a mockup for a new animation, because you can just cut up the arms and move pixels around without worrying about fixing up the torso.
I see. That may or may not be feasible depending on the specific part, but we could make it a goal. I do see now how the arms could be an issue when they are raised above the head (e.g. such that they overlay a helmet or hair). Hmm, let's think about that. I definitely think Basto's modular heads are an improvement, so arms/legs is the next logical step...
Another application would be having the arms move somewhat independently of the legs; like, you could have a walking thrust animation, or a person walking with their arms raised, just combining the existing upper- and lower-body animations...
Having tools to help automate things like spritesheet creation or taking things like hats and hair and putting them in the correct position is extremely important, but personally I sometimes find these to be unreasonably restrictive. A certain piece of headgear might be labelled "female only" and then I can't put it on a male sheet in the generator just to get an idea for how it looks and make modifications afterwards, so I find that I tend to just use the Gimp anyway.
There's two separate issues here:
1) the scripts can handle differences in male/female (as feasible); for example, the current hair scripts generates both a male and female version, which differ only slightly in the offsets and cutouts that are used. Cases where this couldn't be overcome include the example you gave above, where you're trying to generate a cutout but the shape of the cutout is variable depending on the piece that's being cut out... Hmm, I'm starting to come around to your idea that the arms should be on different layers...
2) whether the specific generator software allows you to make "illegal" combinations just to test something out. I think we could easily permit that.
You know, would anybody be interested in a Discord server for the LPC set? We could share WIP and concept work directly pretty easily that way.
Personally, I'd rather discussion stay on OGA as much as possible---makes it more likely that information is preserved. But maybe I'm just a dinosaur who doesn't want to use a different platform :)
I think ElizaWy's new animations look nice, and I welcome her efforts. I'm looking forward to seeing her completed set of base animations.
But I'll reiterate my opinion that re-doing everything is probably the wrong direction for the community. I think the "easy to create for" is a very important value, for a community project. As ElizaWy mentioned, it also looks like the new animations would be more complicated to animate, raising the barrier to new contributions. It doesn't look to me like adapting the existing assets would be easy either, which means this would require mostly new art. I think it would be a shame to "lose" compatibility with all the existing art. (Of course, the old art doesn't go away, it just doesn't benefit from any improvements that ElizaWy or other "Revised LPC" contributors make).
Just my take. Again, nothing wrong with ElizaWy experimenting or going in a totally different direction---this is the point of free culture :) But if we're talking about working "as a community" on the project of the LPC characters, I think retaining existing contributions (as much as possible) and keeping things easy-to-contribute-to are important values.
I'm generally -1 on anything that requires revising all existing assets, unless it can be done automatically (which I suspect is not the case for most modifications).
I think new animations are fine, but they will require a significant investment of work to build out items. We would benefit from someone doing careful experimentation to make animations that are useful for multiple purposes. Evert, could you share your work on this so far? (I know you posted it in another thread somewhere but I can't find it...)
Or someone making a concerted effort to draw optimal tool/weapon/object sprites to implement new animations (for instance, I think the axe chop animation that pvigier proposed could work well using the slash animation played in reverse, as long as someone drew the axe in proper perspective and with motion blur etc). IMO any new animations should use the absolute minimum number of frames possible. It sucks that the current walkcycle is like 12 frames... the last thing we need is a 20-frame run cycle---it will never get any clothes drawn because it will take forever :p
This conversation is making me think automatic recolors and spritesheet generation (e.g., take 4 directions of hair and a "hurt" animation and generate a full spritesheet) is very important, since it will allow many items to be adapted to different bases. I'll mention again that these tools already exist for hair, helmets, and shields, they just need to be re-integrated into the current file structure. Obviously it will never help for things like shirts, which depend on the underlying size/shape of the torso, not just the position of the head/hands.
Evert, can you also elaborate on your thoughts about separate layers? I'd strongly echo BenCreating's comment that requiring separate layers is a big hassle that may not be necessary. The only place i have encountered this conflict is with hats, where I've found it sufficient to have an "under-weapon" and an "over-weapon" layer, and even then it was only an issue for the south-facing "shoot" animations.
I am working on a slight re-organization of the assets in castelonia's generator https://github.com/sanderfrenken/Universal-LPC-Spritesheet-Character-Gen... which has number of duplicates, inconsistently-named assets, and some folder structures that don't make sense to me (for example, why is a formal coat torso/chain/formal/formal_iverness.png nested within the chain mail directory?)
Thanks Medicine :) And I don't mean to be a jerk to anyone here---I just want to focus on solving this specific problem, and there are many other discussion rabbit holes we can go down...
Please keep discussion here focused on attributions for the LPC character sprites. If you want to talk about better ways to make recolors, please start a separate thread.
@Kuranyem, we now have a chart listing the "prices" (attribution) of all items in our "grocery store". We also have a visual tool where you can pick items and it tells you the "prices" (attribution instructions), as well as (IMO) clear instructions in the project README. What more do you want? Nobody is advocating for the ridiculous grocery store you suggested. That was the situation before we started, but I think it's improved significantly.
If you have any other suggestions about how to make this information clearer or more useful, I'd be happy to hear it. But I feel like you are arguing against a position that nobody here is taking.
@Basto, Kuranyem: I think the issue of recolors is simpler than you are making it. Here is how CC defines "Adapted Material" (this is the term used in CC 4.0, equivalent to "derivative work" in other licenses):
Adapted Material means material subject to Copyright and Similar Rights that is derived from or based upon the Licensed Material and in which the Licensed Material is translated, altered, arranged, transformed, or otherwise modified in a manner requiring permission under the Copyright and Similar Rights held by the Licensor
I don't see anything here that would prevent a recolor from meeting that definition. Someone makes a recolored image, they are creating a derivative work, they need to grant a license to use that work and they get credit. The CC licenses have no notion of a "trivial" modification Practically speaking, it's important to track credit in order to make sure the asset is still free. For example, if you make a recolor of an asset that is under a non-Share-Alike license (e.g. CC-BY), technically, you are not required to release the recolored asset under a free license (as long as the original author is properly credited). So we need to know who made the recolor and under what license.
Philosophically, even if a color palette cannot be copyrighted, in my opinion there is clearly creative effort involved in selecting colors to produce an artistic effect. It's also practically useful to many developers, even if you personally don't find it useful because you want to do recolors by changing HSL. There was a long discussion about the legal status of fonts in another post... I'd rather not get into that here. The point is, the conservative position is to keep track of who made recolors and be sure they are licensed appropriately. If you want to make your own fork of the spritesheet generator where you do all the recolors automatically from an indexed palette---fine, knock yourself out.
I don't think the scenario where the engine produces recolors requires you to distribute 281 trillion images or whatever. Nobody is asking for that. If your engine is recoloring a CC-BY-SA asset, you can't prevent someone from using one of your HSL-recolored images under that original license (with credit to you), including "circumventing effective technological measures" to do so. But again, that's not the problem we need to address here. We have a discrete number of recolored assets and need to attribute them. I think the most straightforward thing to do (and this is what I have done) is to figure out who made the original, figure out who made the recolor, and credit both.
- The new fruits and veggies; added >100 new sprites (highlighted with purple box), notably beans, cereals, and herbs, as well as more of basically every other kind. Several sprites also edited or re-drawn to match the crops or trees. I also have ~10 new breads and a handful of new meats (not shown here). The same basic format as the original, with 4 sprites per item (1 item, few items, many items, and items to go in a box/container)---I'm just showing the single item here for simplicity. Let me know if you can think of anything to add---I'm pretty much out of ideas!
- Some "meals"/"dishes" I've been working on with castelonia; this is a modular set of prepared foods that can be combined to make various dishes. The preview image is made entirely by layering in Tiled.
Agreed with everything MedicineStorm said; we were probably typing at the same time :p
One other point you reminded me of: the only way we can KNOW an asset is free to use is if we KNOW :
who made it
under what license they released it
that it was not copied or adapted from another non-free source (i.e. that we know the entire provenance of the asset)
So even if Kuranyem thinks properly crediting OGA art is too much work for most people, it's imperative for the people who DO want to use it (and are willing to abide by the terms of the licenses, i.e. provide credit) to KNOW where it came from.
Some of the people on that reddit thread may have been more happy to use the assets and willing to provide proper credit, but were turned off because the amount of research they would have needed to do to figure out those credits was unreasonable. Hopefully this effort has helped that group.
Kuranyem, thanks for taking the time to write up your thoughts. I appreciate your perspective, even if I disagree with some of your points. Let's keep the discussion here focused on attribution of the LPC character spritesheets and how to make the sprites/credits easy for developers to use. If you would like to start a broader discussion about how to make the OGA website better or more useful, please start a separate thread.
First, I'll reiterate that I think properly crediting artists for their work is non-negotiable. It's a legal requirement of the licenses and it's the right thing to do, in honor of the huge amount of work that artists are giving away for free here. Think of that as the price for using the assets---if providing that credit is too much work, developers can always decide not to use that assets. However, that's exactly the situation I am trying to avoid. I want to make it easier for developers to give proper credit. You're right that some people will still refuse to give credit, just like some people choose to pirate commercial software or cheat on their taxes---we can have a separate discussion about whether it's worth trying to chase down and punish people for that. That's not what I'm trying to do here---I'm trying to make it as easy as possible for people to credit the art that they want to use in their game.
I'll address some of your specific points:
Should you really use CSV? And not an open-source alternative, or easy to open with another open-source editor since this seems to be advocated most of the time for anything coming out of here?
CSV itself is a very simple file format, easily edited by many FOSS and commercial software. It's human-readable as plain text (not ideal, but possible). There are also libraries to parse it in nearly every programming language imaginable, and failing that, it's not difficult to write your own parser. This is why I chose it. However, if you think there is a better option, I'd be happy to hear it.
As for the "schema" of the CSV file (i.e., how the columns describe the relevant metadata), I agree it's not great---I don't love the "url1", "url2", "url3" columns, whereas the "authors" column is itself a comma-separated list. But there doesn't seem to be a standard schema for attributing art/data (the closest I could find was the Creative Commons RDFa schema; however, it's much more complicated, not human-readable, and does not seem to be supported by many tools. We could consider implementing it if there's interest). Again, I'd be happy to hear suggestions that would be more elegant or easier to use
In my opinion a third-party using anything from oga would rather have a single link so that they can point "I use things from this place from various artists, if you're interested just go have a look by yourself."
The file CREDITS.csv lists the authors, license(s), and links to the original URL(s), for each image in spritesheets. If you generate a sprite using this tool, you must credit all the authors. You can do this one of two ways:
Distribute the entire CREDITS.csv file along with your project.
Based on the layers you use, copy the appropriate rows from CREDITS.csv into a new file and distribute that file with your project.
Either way, make sure this credits file is accessible from within your game or app and can be reasonably discovered by users (for instance, show the information on the "Credits" screen directly, or provide a visible link). If you don't want to show the entire credits file directly, should include a statement like this on your credits screen:
Sprites by: David Conway Jr. (JaidynReiman), Nila122, Johannes Sjölund (wulax), Stephen Challener (Redshrike), Luke Mehl, bluecarrot16, Thane Brimhall (pennomi), laetissima, Michael Whitlock (bigbeargames), Matthew Krohn (makrohn), Rhimlock, Benjamin K. Smith (BenCreating), Sander Frenken (castelonia), kheftel, Marcel van de Steeg (MadMarcel), kirts, Mark Weyer, Lanea Zimmerman (Sharm), Manuel Riecke (MrBeast), Charles Sanchez (CharlesGabriel), Zi Ye, William.Thompsonj, drjamgo@hotmail.com, dalonedrau, ElizaWy, Evert, Daniel Eddeland (daneeklu), Carlo Enrico Victoria (Nemisys), Mandi Paugh, Joe White, Barbara Riviera, Tracy, DarkwallLKE, thecilekli, Stafford McIntyre, PlatForge project, Shaun Williams, Tuomo Untinen (reemax), Pierre Vigier (pvigier), Lori Angela Nagel (jastiv), tskaufma, gr3yh47, LordNeo, XOR, pswerlang, Inboxninja Sprites contributed as part of the Liberated Pixel Cup project from OpenGameArt.org: http://opengameart.org/content/lpc-collection License: Creative Commons Attribution-ShareAlike 3.0 http://creativecommons.org/licenses/by-sa/3.0/ Detailed credits: [LINK TO CREDITS.CSV FILE]
So basically, if a developer wants to use these assets and REALLY doesn't want to go to any more trouble, they can copy-and-paste the above statement in their credits and link to CREDITS.csv on their credits screen.
The reddit link you posted bluecarrot16 is, in my opinion, exactly what happens when people consider using things from the LPC, or anything from oga, but eventually give up. To quote the relevant things :
- "How would I know the names of the artists? Is it just better to credit all the artists who contributed instead? It's a hassle to look for which artist did which asset."
This is a little unfair. Those comments were from before castelonia and I did all the work to add credits to the generator. Now the generator makes an attribution statement for you and there is a clear statement about the license with a list of all authors---both for the entire project, and broken down per-file---linked in the README. A few weeks ago, the answer to that question in the reddit thread was "well, you have to go search on OGA and figure out who made each spritesheet, then credit them; sorry about that... good luck!" Now the answer is "check out the README and CREDITS.CSV; you need to credit the authors for all files you use, but the information is all in CREDITS.CSV. Let us know if you have any questions." I think that's a big improvement.
Are most people even going to bother with it, especially when the list has reached such a big state?
This is the problem we are trying to solve. I can't really convince people to "bother" with it, but I can try to make it easy/possible for them. I'll again mention that AAA games routinely list hundreds or thousands of people in their credits. Frankly, if someone can't be bothered to make the effort of copying-and-pasting some text into their game's credits, well, I'm not sure what I can do for them. See my comments above.
I also think that LPC, while being big, still isn't as useful as you people might think. But again, that's subjective, and I don't want you to think that I only want to speak ill of things in the discussion so I won't go into detail. Unless you are interested.
I would actually be interested in hearing what you have to say about this. But please make a separate thread. If you look at my portfolio on this site, a lot of my work has been collecting art into stylistically consistent, themed sheets that are directly usable in a game. I also always include a human-readable CREDITS.txt file that can be copied directly alongside the work. For my recent LPC victorian town decorations submission, I made a large preview map in Tiled, using art from several of my OGA submissions; even though this draws upon dozens of OGA submissions from numerous artists, putting together the credits for the scene only took about 5 minutes, because it was just a matter of pasting in the CREDITS file. Would it have been easier if everything had been CC0 (like Kenney's art)? Sure, but not every artist is okay with that, and I have to respect the terms of the licenses they set. So yeah, I'd be happy to hear your thoughts (in a separate thread) on how to make the LPC set more useful. To my view, it's one of the largest and most comprehensive collections of free art on the internet, and I'd like to see it used.
And in fact, the problem is mostly solved now. You'll have to re-build your assets in the generator, but now it can automatically show you the credits for a given sprite (make your character, then click "Credits for this sprite"). You can combine each of those CSV files and include them on your credits screen. There's some more specific guidance here: https://github.com/sanderfrenken/Universal-LPC-Spritesheet-Character-Gen... . Take a look at that and let us know if you still have questions.
My thoughts exactly!
I see. That may or may not be feasible depending on the specific part, but we could make it a goal. I do see now how the arms could be an issue when they are raised above the head (e.g. such that they overlay a helmet or hair). Hmm, let's think about that. I definitely think Basto's modular heads are an improvement, so arms/legs is the next logical step...
Another application would be having the arms move somewhat independently of the legs; like, you could have a walking thrust animation, or a person walking with their arms raised, just combining the existing upper- and lower-body animations...
There's two separate issues here:
1) the scripts can handle differences in male/female (as feasible); for example, the current hair scripts generates both a male and female version, which differ only slightly in the offsets and cutouts that are used. Cases where this couldn't be overcome include the example you gave above, where you're trying to generate a cutout but the shape of the cutout is variable depending on the piece that's being cut out... Hmm, I'm starting to come around to your idea that the arms should be on different layers...
2) whether the specific generator software allows you to make "illegal" combinations just to test something out. I think we could easily permit that.
Personally, I'd rather discussion stay on OGA as much as possible---makes it more likely that information is preserved. But maybe I'm just a dinosaur who doesn't want to use a different platform :)
I think ElizaWy's new animations look nice, and I welcome her efforts. I'm looking forward to seeing her completed set of base animations.
But I'll reiterate my opinion that re-doing everything is probably the wrong direction for the community. I think the "easy to create for" is a very important value, for a community project. As ElizaWy mentioned, it also looks like the new animations would be more complicated to animate, raising the barrier to new contributions. It doesn't look to me like adapting the existing assets would be easy either, which means this would require mostly new art. I think it would be a shame to "lose" compatibility with all the existing art. (Of course, the old art doesn't go away, it just doesn't benefit from any improvements that ElizaWy or other "Revised LPC" contributors make).
Just my take. Again, nothing wrong with ElizaWy experimenting or going in a totally different direction---this is the point of free culture :) But if we're talking about working "as a community" on the project of the LPC characters, I think retaining existing contributions (as much as possible) and keeping things easy-to-contribute-to are important values.
I'm generally -1 on anything that requires revising all existing assets, unless it can be done automatically (which I suspect is not the case for most modifications).
I think new animations are fine, but they will require a significant investment of work to build out items. We would benefit from someone doing careful experimentation to make animations that are useful for multiple purposes. Evert, could you share your work on this so far? (I know you posted it in another thread somewhere but I can't find it...)
Or someone making a concerted effort to draw optimal tool/weapon/object sprites to implement new animations (for instance, I think the axe chop animation that pvigier proposed could work well using the slash animation played in reverse, as long as someone drew the axe in proper perspective and with motion blur etc). IMO any new animations should use the absolute minimum number of frames possible. It sucks that the current walkcycle is like 12 frames... the last thing we need is a 20-frame run cycle---it will never get any clothes drawn because it will take forever :p
This conversation is making me think automatic recolors and spritesheet generation (e.g., take 4 directions of hair and a "hurt" animation and generate a full spritesheet) is very important, since it will allow many items to be adapted to different bases. I'll mention again that these tools already exist for hair, helmets, and shields, they just need to be re-integrated into the current file structure. Obviously it will never help for things like shirts, which depend on the underlying size/shape of the torso, not just the position of the head/hands.
Evert, can you also elaborate on your thoughts about separate layers? I'd strongly echo BenCreating's comment that requiring separate layers is a big hassle that may not be necessary. The only place i have encountered this conflict is with hats, where I've found it sufficient to have an "under-weapon" and an "over-weapon" layer, and even then it was only an issue for the south-facing "shoot" animations.
I am working on a slight re-organization of the assets in castelonia's generator https://github.com/sanderfrenken/Universal-LPC-Spritesheet-Character-Gen... which has number of duplicates, inconsistently-named assets, and some folder structures that don't make sense to me (for example, why is a formal coat torso/chain/formal/formal_iverness.png nested within the chain mail directory?)
After that, I'd like to re-introduce the scripts from JaidynReiman (aka jrconway3)'s fork https://github.com/jrconway3/Universal-LPC-spritesheet/tree/master/_build to recolor and auto-generate hair sprites. I have a few similar scripts for generating hats and shields.
I'd then like to carefully review several other adaptations which have attempted to fix some bugs in the animations, namely:
and make sure their work is merged into the generator/spritesheet repo.
After that, I'll probably set up a system for programmatic recolors of the other clothing assets, based on the work from others.
I have other thoughts about the tilesets I'll post separately.
Thanks Medicine :) And I don't mean to be a jerk to anyone here---I just want to focus on solving this specific problem, and there are many other discussion rabbit holes we can go down...
BenCreating recently posted a thread which would be a great place to discuss the palette issues, etc: https://opengameart.org/forumtopic/improving-lpc
Please keep discussion here focused on attributions for the LPC character sprites. If you want to talk about better ways to make recolors, please start a separate thread.
@Kuranyem, we now have a chart listing the "prices" (attribution) of all items in our "grocery store". We also have a visual tool where you can pick items and it tells you the "prices" (attribution instructions), as well as (IMO) clear instructions in the project README. What more do you want? Nobody is advocating for the ridiculous grocery store you suggested. That was the situation before we started, but I think it's improved significantly.
If you have any other suggestions about how to make this information clearer or more useful, I'd be happy to hear it. But I feel like you are arguing against a position that nobody here is taking.
@Basto, Kuranyem: I think the issue of recolors is simpler than you are making it. Here is how CC defines "Adapted Material" (this is the term used in CC 4.0, equivalent to "derivative work" in other licenses):
I don't see anything here that would prevent a recolor from meeting that definition. Someone makes a recolored image, they are creating a derivative work, they need to grant a license to use that work and they get credit. The CC licenses have no notion of a "trivial" modification Practically speaking, it's important to track credit in order to make sure the asset is still free. For example, if you make a recolor of an asset that is under a non-Share-Alike license (e.g. CC-BY), technically, you are not required to release the recolored asset under a free license (as long as the original author is properly credited). So we need to know who made the recolor and under what license.
Philosophically, even if a color palette cannot be copyrighted, in my opinion there is clearly creative effort involved in selecting colors to produce an artistic effect. It's also practically useful to many developers, even if you personally don't find it useful because you want to do recolors by changing HSL. There was a long discussion about the legal status of fonts in another post... I'd rather not get into that here. The point is, the conservative position is to keep track of who made recolors and be sure they are licensed appropriately. If you want to make your own fork of the spritesheet generator where you do all the recolors automatically from an indexed palette---fine, knock yourself out.
I don't think the scenario where the engine produces recolors requires you to distribute 281 trillion images or whatever. Nobody is asking for that. If your engine is recoloring a CC-BY-SA asset, you can't prevent someone from using one of your HSL-recolored images under that original license (with credit to you), including "circumventing effective technological measures" to do so. But again, that's not the problem we need to address here. We have a discrete number of recolored assets and need to attribute them. I think the most straightforward thing to do (and this is what I have done) is to figure out who made the original, figure out who made the recolor, and credit both.
Hi there, just a quick preview of a few things:
- The new fruits and veggies; added >100 new sprites (highlighted with purple box), notably beans, cereals, and herbs, as well as more of basically every other kind. Several sprites also edited or re-drawn to match the crops or trees. I also have ~10 new breads and a handful of new meats (not shown here). The same basic format as the original, with 4 sprites per item (1 item, few items, many items, and items to go in a box/container)---I'm just showing the single item here for simplicity. Let me know if you can think of anything to add---I'm pretty much out of ideas!
- Some "meals"/"dishes" I've been working on with castelonia; this is a modular set of prepared foods that can be combined to make various dishes. The preview image is made entirely by layering in Tiled.
Agreed with everything MedicineStorm said; we were probably typing at the same time :p
One other point you reminded me of: the only way we can KNOW an asset is free to use is if we KNOW :
So even if Kuranyem thinks properly crediting OGA art is too much work for most people, it's imperative for the people who DO want to use it (and are willing to abide by the terms of the licenses, i.e. provide credit) to KNOW where it came from.
Some of the people on that reddit thread may have been more happy to use the assets and willing to provide proper credit, but were turned off because the amount of research they would have needed to do to figure out those credits was unreasonable. Hopefully this effort has helped that group.
Kuranyem, thanks for taking the time to write up your thoughts. I appreciate your perspective, even if I disagree with some of your points. Let's keep the discussion here focused on attribution of the LPC character spritesheets and how to make the sprites/credits easy for developers to use. If you would like to start a broader discussion about how to make the OGA website better or more useful, please start a separate thread.
First, I'll reiterate that I think properly crediting artists for their work is non-negotiable. It's a legal requirement of the licenses and it's the right thing to do, in honor of the huge amount of work that artists are giving away for free here. Think of that as the price for using the assets---if providing that credit is too much work, developers can always decide not to use that assets. However, that's exactly the situation I am trying to avoid. I want to make it easier for developers to give proper credit. You're right that some people will still refuse to give credit, just like some people choose to pirate commercial software or cheat on their taxes---we can have a separate discussion about whether it's worth trying to chase down and punish people for that. That's not what I'm trying to do here---I'm trying to make it as easy as possible for people to credit the art that they want to use in their game.
I'll address some of your specific points:
CSV itself is a very simple file format, easily edited by many FOSS and commercial software. It's human-readable as plain text (not ideal, but possible). There are also libraries to parse it in nearly every programming language imaginable, and failing that, it's not difficult to write your own parser. This is why I chose it. However, if you think there is a better option, I'd be happy to hear it.
As for the "schema" of the CSV file (i.e., how the columns describe the relevant metadata), I agree it's not great---I don't love the "url1", "url2", "url3" columns, whereas the "authors" column is itself a comma-separated list. But there doesn't seem to be a standard schema for attributing art/data (the closest I could find was the Creative Commons RDFa schema; however, it's much more complicated, not human-readable, and does not seem to be supported by many tools. We could consider implementing it if there's interest). Again, I'd be happy to hear suggestions that would be more elegant or easier to use
That's the reason we added the CREDITS.CSV option to the spritesheet generator, along with this statement here in the project README::
So basically, if a developer wants to use these assets and REALLY doesn't want to go to any more trouble, they can copy-and-paste the above statement in their credits and link to CREDITS.csv on their credits screen.
This is a little unfair. Those comments were from before castelonia and I did all the work to add credits to the generator. Now the generator makes an attribution statement for you and there is a clear statement about the license with a list of all authors---both for the entire project, and broken down per-file---linked in the README. A few weeks ago, the answer to that question in the reddit thread was "well, you have to go search on OGA and figure out who made each spritesheet, then credit them; sorry about that... good luck!" Now the answer is "check out the README and CREDITS.CSV; you need to credit the authors for all files you use, but the information is all in CREDITS.CSV. Let us know if you have any questions." I think that's a big improvement.
This is the problem we are trying to solve. I can't really convince people to "bother" with it, but I can try to make it easy/possible for them. I'll again mention that AAA games routinely list hundreds or thousands of people in their credits. Frankly, if someone can't be bothered to make the effort of copying-and-pasting some text into their game's credits, well, I'm not sure what I can do for them. See my comments above.
I would actually be interested in hearing what you have to say about this. But please make a separate thread. If you look at my portfolio on this site, a lot of my work has been collecting art into stylistically consistent, themed sheets that are directly usable in a game. I also always include a human-readable CREDITS.txt file that can be copied directly alongside the work. For my recent LPC victorian town decorations submission, I made a large preview map in Tiled, using art from several of my OGA submissions; even though this draws upon dozens of OGA submissions from numerous artists, putting together the credits for the scene only took about 5 minutes, because it was just a matter of pasting in the CREDITS file. Would it have been easier if everything had been CC0 (like Kenney's art)? Sure, but not every artist is okay with that, and I have to respect the terms of the licenses they set. So yeah, I'd be happy to hear your thoughts (in a separate thread) on how to make the LPC set more useful. To my view, it's one of the largest and most comprehensive collections of free art on the internet, and I'd like to see it used.
And in fact, the problem is mostly solved now. You'll have to re-build your assets in the generator, but now it can automatically show you the credits for a given sprite (make your character, then click "Credits for this sprite"). You can combine each of those CSV files and include them on your credits screen. There's some more specific guidance here: https://github.com/sanderfrenken/Universal-LPC-Spritesheet-Character-Gen... . Take a look at that and let us know if you still have questions.
Pages