Overcoming Challenges in Creating a Dynamic 2D Character System in Spine & Unity

Game development is full of unexpected hurdles, and working with Spine animations in Unity can be challenging. When we first started implementing our dynamic 2D character system, everything seemed straightforward—importing the skeletons, setting up animations, and letting the magic happen. But as we pushed deeper, we ran into a series of roadblocks that forced us to rethink how we structured our Spine data, handled modular character parts, and optimized performance.

In this post, we’ll share details about how we have been approaching adding dynamic characters in Dark Discard!

TL;DR: We built a dynamic 2D character system with Spine & Unity by standardizing naming conventions, using Skins for structural variations, leveraging IK and gravity for smooth animation, and optimizing performance with efficient asset management.

1. The Spine File Data Problem: Incomplete Skeleton Data

At the core of our animation system, we work with a single dynamic enemy character model that can change boob size, butt size, hair, and skin tones. While the rig remains the same across variations, differences in attachments and skins introduce unexpected complexities. Initially, our Unity integration relied on the first loaded Spine file to determine animation data. We had an idle position that gave a good amount of details that would define characters.

This worked fine initially, but as more character variations were introduced, the animation system broke due to inconsistencies in slot and attachment references. The problem was apparent—our code struggled to locate the correct body parts across different Spine files, leading to missing limbs or incorrect attachments.

Solution: Whole-Body Data & Standardized Naming Scheme

To solve this, we formalized a whole-body naming approach that covers the whole character rig before creating rigs in Spine. The naming scheme covers things you’d expect:

• Head (Face, Hair, and Skin Variations)
• Upper Torso (Boobies and Nipples)
• Lower Torso (Butt, Hips and Waist Attachments)
• Left & Right Arms (Mirrored Constraints for Symmetry)
• Left & Right Legs (Mirrored Constraints for Symmetry)

We adopted a strict naming convention for all slots and attachments, ensuring the code could always locate the correct body part. For example:

Slot Name: left_arm
Attachment Name: left_arm_variant_01

This structured approach resolved issues with missing attachments and ensured that every character variation functioned correctly across all Spine files.

2. Managing Modular Character Parts & Skin Variations

One of the biggest challenges was handling boob types—since different boob types required different bone structures, simple attachment swaps wouldn’t work. Usually, we use attachments for body part variations like butt and hair, but attachments are limited to a single bone structure. We used Spine Skins instead of standard attachments to allow for different rigging configurations.

Solution: Using Spine Skins for Structural Variations

We created three distinct Spine Skins specifically for boob types. Since Spine Skins allow different bones and constraints, this method lets us animate different boob structures without breaking the rig. We continued using attachments for other customizable parts like hair since they do not require separate bone setups.

3. Spine-to-Unity Integration: Handling Multiple Spine Files

Initially, we tested the system with a single Spine file with an idle position, and it worked fine. However, we intend on having many sex animations (H-scenes) and the code started breaking as more scenes and character variations were introduced. The primary issue was that our animation c# classes weren’t correctly identifying body parts across different Spine files. There were lots of exceptions per file, and we needed to standardize everything in a forward-looking way.

Solution: Code Refactoring & Dynamic Body Part Identification

We restructured our code to work with our standardized naming pattern to fix this. This ensured that every attachment could be reliably located across different Spine files. A back-and-forth communication process between our brave developer and artist/animator was crucial to refining this system.

We also leveraged SkeletonAnimation instead of SkeletonMecanim in Unity since SkeletonAnimation supports mesh features, allowing more fluid 2D-to-3D movement. This ensured smoother and more natural-looking animations.

4. Performance Optimization: Avoiding Frame Drops & Load Issues

Performance concerns have been minimal since we only have one active character on-screen at a time. However, we still took precautions to optimize asset management.

• Texture Atlasing: We initially explored multi-texture atlases to reduce texture clutter, but a single texture atlas per character proved sufficient for our needs.

• Efficient Asset Loading: We load assets usually instead of preloading since Spine’s performance remains stable.

5. Animation Blending & Character Physics

Spine’s gravity feature has been a game-changer for realism. Instead of painstakingly animating small secondary movements, gravity was applied to specific body parts like hair and breasts, making the movements more natural and reducing the animation workload. As a small team, having this feature in Spine really makes our speed of animation delivery workable.

We also use IK constraints for limb movement, ensuring smooth animation transitions without unexpected distortions. Spine’s animation blending system handles transitions well, eliminating the need for extensive procedural animation. We <3 Spine… usually.

6. Lessons Learned & Future Improvements

• Skins vs Attachments: Choosing when to use Spine Skins vs. standard attachments is crucial. Skins allow for different bone structures, while attachments are best for simple swaps within a single rig.

• Consistent Naming Conventions: This was the key to correctly getting a Spine-to-Unity workflow. Establishing a structured slot and attachment system made everything more manageable. Animation Events: While we don’t currently use animation events extensively, they will be helpful as we introduce reactive animations based on Staying Power, Lust Points, and other interactions during sex in the future.

Final Thoughts

Building a dynamic, modular 2D character system in Spine & Unity required iteration and persistence. We think we’ve created a flexible animation system to support diverse characters and character customization through structured data organization, optimized attachment swapping, and performance-conscious design.

Thanks for checking out this post! Spine is an excellent animation tool that really brings 2D Unity games to life. Was this kind of post interesting? Let us know in the comments below. If any developers making dynamic characters in Unity are tackling similar challenges, we’d love to hear how you approached them!

• Chat with the team on our Discord Server: https://discord.gg/vkhdzYqtpH
• Support us on Patreon: https://www.patreon.com/darkdiscard
• Try out Dark Discard: Use the download links below! https://team-peachy.itch.io/dark-discard