We're making a game using Pixi and Spine, utilizing the pixi-spine library (which is built off the spine-ts library). The game is quite simply a character creator.
Something we've been chewing on: asset management. Part of our game involves having a character that can have many hundreds if not thousands of different, say, hats, tshirts, shoes, etc.
One strategy involved color - we've already found a solution in export all assets as white and simply tinting them. Done, custom avatar coloring.
Now we need to figure out a good way to have pages upon pages of possible hats, tshirts, whatever.
One solution: Having a spine character with a "tshirt" slot and "hat" slot with hundreds of attachments. Works, simply setAttachmentByName('hat', 'hatWithSkull') or whatever, fairly straightforward. However, our designers are telling us it's obnoxious to create a bunch of new attachments, that they have to manually reposition the attachment by hand for every new attachment, I guess it's not as simple as a texture swap? (if this isn't the case, I'm happy for advice on this front). Furthermore, this results in, one way or another, a monolithic character.png, character,atlas, character.json. We're trying to look into splitting this up, but we can't figure out any way of paginating - all solutions we've found, split or otherwise, require ALL assets available from the get-go (the creation of the Spine asset, before it's rendered onto the page).
Another solution: Arbitrary texture swaps, using hackTexture or code like the following:
this.gerald.gerald.skeleton.findSlot('hat').sprites['cool/hatRed'].texture =
PIXI.Texture.from('/hatBlue.png');
This seems... okay. It allows us to pull a given png in whenever we need it (i.e. make the above an async response to the request of fetching the hatBlue.png). However, the designers are saying this is also relatively obnoxious to ensure is placed correctly, and is a mild burden in the same vein upon the engineers. It also further restricts the variability of the assets - they must all generally be reskins, or we have to make a lot of hatBig, hatSmall, hatBigWithFeather type slots. Still, as far as we can tell, this is the only solution that doesn't require a monolith (one way or the other) atlas file + png + json.
Another solution we've just started investigating came from this post: http://esotericsoftware.com/forum/Animations-synchro-in-the-previews-and-in-the-engine-11563?p=51901&hilit=spine+skins+view#p51901
Basically, a character with tons of different skins/skin placeholders, which refer to different attachments/slots. The designers are loving this because they say they don't have to re-place assets manually when they add new ones, but as far as we can tell this doesn't solve the monolith problem.
The only solution we've come up with outside arbitrary texture replacement involves creating many-skinned (or attachment'd) separate character spine assets, but with only "hat" or "tshirt" textures/attachments. Then, creating these invisibly, and stealing their attachments off using methods like findSlot('hat').setAttachment(attachmentFromInvisibleOtherSpine). This I guess works but feels hacky.
So, what sort of workflows have other found to work when potentially needed tens of thousands of assets to be swapped in/out on a whim, needing pagination for assets, etc?
