I am working on a game with lots of collectible characters, that all use one of two possible skeletons. I have run into some issues and am wondering if I'm doing something wrong or there is a better way.

Here is my use case as simply as possible...
- I have 2 skeletons, male and female, every characters uses 1 of these.
- I have 2 spine projects, 1 for each skeleton, all the characters exist as skins within either project.
- I export individual skins using the texture packer, and flatten the paths to just the attachment names.
- I export each skeleton once, remove all skins but 1, rename it to default, and flatten the attachment paths here as well.
- In the project, I create a folder for each character with a; SkeletonDataAsset (which references the shared skeleton json and the 1 skin atlas that this character needs), the mat, AtlasAsset, pack json, and texture.
- At runtime I instantiate a single "SpineCharacter" prefab, assign the SkeletonDataAsset for the character (loaded from asset bundle) and reload.

This "works", but there are some weird hiccups in the editor that are problematic...

- I can't use a single SkeletonDataAsset because this will reference every skin that Skeleton uses, which will pull everything into one massive asset bundle which isn't feasible for loading/updating a game.

- Spine auto-generates Assets when importing data

Is it possible to opt-out of Auto-Generating Assets from imported data files (atlases and skeletons)? This is not particularly helpful as I have to use Spine's naming conventions or new assets will be constantly generated each time a data asset is re-imported. I don't want to use that naming convention the names are very very long. Also, I am sharing data objects between many assets and this is creating things I don't want or need. This is also going to create phantom diffs or pollute our version control with meaningless assets that won't go into a build (or shouldn't but the environment is now more human error prone).

- Spine pops up a big warning that it can't import things which scares the other devs.

In order to avoid the auto generation I've been exporting atlases as just "whatever.txt" instead of "whatever.atlas.txt" I'm also not sure this would definitely solve the problem because the skeletons are stored in separate folders anyway, only have skins named "default" and there are no real atlases named "default" in the project.

Any thoughts or ideas about ironing out these wrinkles?
  • Posts: 1


Thanks for the feedback.

We can easily add disabling automatic asset generation in the preferences window. You can look forward to that.

As for using a single SkeletonDataAsset, having one skin at a time (or maybe exporting skins as a separate data asset); that's something we don't have out of the box.

But if you were already doing some strange things like deleting every skin except one and re-exporting, there's probably one solution where you export one version of the skeleton with all the skins, and then one version without any. Then the version without skins can be the singular SkeletonDataAsset you can load. The skins can be extracted from the other one as a separate asset type/ScriptableObject that you can load from later or include separately in asset bundles.

Skins are just containers for attachments, and a Dictionary that map them to the correct slot and placeholder name.
You can store that same 1. attachment data and 2. the dictionary information in your own format.
Loading them would amount to mimicking what the skin loader does but using the ScriptableObject as the source rather than the json/binary.

You may need to dive into some of the documentation if you need to familiarize yourself with the structure:
Runtime Architecture - Spine Runtimes Guide: Class diagram
Spine Runtimes Guide

You may be too far along development to switch workflows but this may give you some ideas too:
Spine-Unity Mix and Match
User avatar
  • Posts: 5366

Return to Unity