Data model: group related assets for different body types

[bluecarrot16]

I'd like to propose changing the structure of data in sheet-definitions.json:

• in Sander's generator, even though male and female pants (for example) use different images, they are treated as the same "asset;" that is, they share the same JSON metadata file in sheet_definitions and represent a single entry in the tree on the left side of the generator. A different image is applied depending on the selected body type. https://github.com/sanderfrenken/Universal-LPC-Spritesheet-Character-Generator/blob/master/sheet_definitions/legs_pants.json#L6-L9 (It is also possible that one image is used for multiple or even all body types; for example, the "female" shoes are used for female, teen, and pregnant body types).
  • The main advantage: if you have red pants selected on a male character and you change the body type to "female", the character updates automatically and keeps their red pants, but adapted to the female body. In this generator, when you do the same thing... actually the body type changes but the character keep their male pants, which seems like a bug :p Anyway I think Sander's behavior is more desirable.
• in this generator, male pants and female pants are treated as separate metadata entries https://github.com/BenCreating/LPC-Spritesheet-Generator/blob/main/resources/sheet-definitions.json#L439-L489 and there doesn't seem to be a clear connection between them.
  • This generator should allow for a more flexible system of constraints, e.g. certain assets could be declared mutually exclusive on criteria other than body type.

There's a related issue with credits: in Sander's generator, credits are assigned to each image. In Ben's generator, they are assigned to the asset. In a lot of cases, one person draws the "male" version of the asset and someone else adapts it to the "female" (and other) version(s), so the credits for the male and female version of an asset are overlapping but not identical. In Ben's current setup, this situation kinda requires any two objects that have separate attributions to be separate "assets" (i.e. separate entries in resources/sheet-definitions.json.

I would propose that this generator adopt a model of "one asset, multiple images", similar to Sander's generator. In fact, perhaps we can (ab)use the notion of layers to implement this model, and create a "cascading" series of definitions: category > asset > layer:

• Each category (e.g. https://github.com/BenCreating/LPC-Spritesheet-Generator/blob/main/resources/category-definitions.json) contains zero or more assets, which are mutually exclusive. The category has some default properties (e.g. z_order, tags, perhaps others)? that apply to any assets in that category, but that can be overridden by assets or layers.
• Each asset contains one or more layers. The asset can have properties such as excluded-by, credits, tags, palettes, etc.; if given, those properties will serve as defaults for all layers within the asset.
• Each layer has properties like excluded-by, credits, tags, palettes, etc. If given, these override properties with the same name from the asset.
• An asset is selectable in the generator as long as one or more of its layers is selectable, i.e. it is not excluded by any tags used by any other assets (at least, I think that is how the excluded-by key is supposed to work; put another way, an asset is selectable if at least one of its layers is not excluded).
• Credits are assembled for a sheet by combining the credits for all layers in use.
  • within a layer, the credits block would by default overwrite the credits for the asset. However, the layer credits block can have an append key, which, if true, causes any authors and links given to be appended to those for the asset. For example, it is often the case that someone draws an original asset for the male body type, then someone else adapts it to the female body. So the credits for the female version are (credits for the male version) + (additional author and/or URLs). (licenses probably shouldn't work this way, since the rules about when more licenses can be added to a derivative work are complicated.)

Example:

"cape": {
    "solid": {
      "tags": [],
      "credits": {
        "authors": [
          "bluecarrot16",
          "David Conway Jr. (JaidynReiman)",
          "Nila122"
        ],
        "licenses": [
          "CC-BY-SA 3.0",
          "GPL 3.0"
        ],
        "links": [
          "https://opengameart.org/content/lpc-curly-hair-elven-ears-white-cape-with-blue-trim-and-more",
          "https://opengameart.org/content/lpc-roman-armor",
          "http://opengameart.org/content/lpc-clothing-updates"
        ],            
      },
      "palettes": [
        "cloth"
      ],
      "layers": {
        "male": {
          "excluded-by": [
            "child",
            "muscular",
            "female",
            "teen"
          ]
        },
        "female": {
          "excluded-by": [
            "child",
            "muscular",
            "male"
          ],
          "credits": {
            "append": true,
            "authors": [
              "someone_else_who_made_the_female_version"
            ],
            "links": [
              "http://opengameart.org/content/lpc-special-clothing-modifications"
            ],
          }
        },
        "solid_behind": {"z_position": 5 }
      }
    }
  }

[BenCreating]

I think this may be two related issues:

1. Switch between equivalent assets when changing body type
2. Simplify the management of attribution/licensing information by minimizing redundancy for related assets

1. Switching between equivalent assets

I'd prefer to add the concept of variants rather than trying to cram this into layers. This could be handled by either listing all information for each variant in a single asset as you suggest, or alternatively by only listing the names of equivalent items.

The second option would require duplicating the list of variants for each asset definition.

"cape-male": {
  "solid": {
    "tags": [],
    "credits": {
      "authors": [...],
      "licenses": [...],
      "links": [...],            
    },
    "palettes": [...],
    "layers": {
      "solid_behind": {"z_position": 5 }
    }
    "variants": [
      "cape-female",
      "cape-muscular",
      "cape-child"
    ]
  }
}

A third option with less duplication would be a single "parent" asset that only has the variants array.

I don't feel strongly about any of these options. There are advantages and disadvantages to each.

2. Managing attribution

I'm seeing three cases here:

1. The assets are essentially the same item (e.g. pants for the male and female bases)
2. An asset is derived from another, but the two are not interchangeable (e.g. the character base itself and any clothing item)
3. An asset is derived from multiple sources

I propose that instead of a boolean append key, that it should be an array. We can then give it the names for any other assets, and append the authors and links from all of them.

We would need to settle on a standard format for referring to the assets, since at the moment names are only guaranteed to be unique within a category. Maybe the format category/asset, or an object with named keys { category: "body", name: "male" }