Exploration: character randomizer

[manuq]

Hi,
In pull request #1801 I'm exploring how to create characters dynamically from a set of body parts. In the current aesthetics of threadbare is tricky, but still possible. My main goal is to replace townies of the Void quest, but it can be generalized to any amount of stacked body parts. I simplified a lot to avoid drawing too much:

• Only an "idle" animation with just 3 frames (like the ones proposed in the template).
• Not too many layers: body contains hands, "legs" contains pelvis and shadow.

Update: I started redrawing all the parts today, and couldn't finish animating them. So the 3 frames of the "idle" animation are the same. So you'll have to use your imagination and believe me that these static characters can be in motion.

Here is how the townie character can be randomized in a test scene (the scene is playable here):

Grabacion.de.pantalla.desde.2025-12-31.17-00-13.webm

Here is how the townie character scene looks. This implementation uses an AnimatedSprite2D per body part:

Grabacion.de.pantalla.desde.2025-12-31.16-59-30.webm

And here is how the Aseprite file looks:

Grabacion.de.pantalla.desde.2025-12-31.16-57-52.webm

Limitations

The animations of each part has to be coordinated (played at the same time). Works fine for a single "idle" animation, but what about having multiple animations like "walk" or "defeated"? The solution could be to use an AnimationPlayer node with one track per part.

The existing RandomFrameSpriteBehavior can't be used, so character_randomizer.gd duplicates some code. This could be improved by having a new behavior that works for an array of sprites.

Other things tried

While doing this I found that Godot has a Texture2DArray, and I thought that it could be used to keep all parts in the same SpriteFrames, in a single AnimatedSprite2D. But it doesn't work: SpriteFrames animations need a Texture2D, and Texture2DArray is not a subclass of it. I was able to build such texture from multiple images (body parts), but that's how far I went.

Texture2D may still be built by blitting images at runtime, and this would allow to treat all parts at once, and for instance using RandomFrameSpriteBehavior, or being a drop-in replacement for the existing characters, which use a single AnimatedSprite2D for the visuals. So this option is worth being explored, while probably very bad at performance. The advantage of my nodes-based exploration is that each body part is a node, so is easier to understand by inspecting the scene in the Godot editor.

I learned a lot while doing this, including some scripting in Aseprite with Lua. Here is a script to export all the body parts as sprite sheets in PNG.

[wjt]

I wrote some notes about this in January, somewhere, but apparently never pressed "submit" and now they are lost. :(

I think this a really cool lightweight way to make the townies/unnamed characters in the game have a bit more, well... character. It's a nice complement to providing opportunities for contributors to draw their own unique art. For example, I suggest that we could replace the sprites for the 5 static NPCs (Farmer, FarmersPartner, GardenerA, GardenerB, and the tutorial Talker) with this randomised art.

What complicates this a little bit is that I think you should be able to talk to all of them. So I'm not quite sure what the scene structure would be here.

1. Do we do as you have done in the test scene and manually attach the TalkBehavior & InteractArea to each one?
2. Do we change the talker scene (or a new "random townie" scene?) to use character_randomizer.gd script, and add a dialogue property to it which gets propagated down to the TalkBehavior? (Actually you have most of the same code from talker.gd copied into character_randomizer.gd already.)
3. Does the character_randomizer.gd script live somewhere down inside the hierarchy of the townie scene, at which point we either need to do the same thing for an exported seed property at the top of the scene?
4. Or do we use editable children to set the dialogue? (Personally I don't like editable children because it's too hard to see what has been changed and clutters the parent scene tree with yellow nodes you don't care about.)

My money is on 2. It's a little bit of code duplication in one place, but makes it easy to drop new townies you can chat to into any scene.

[manuq]

@wjt I replaced the NPCs that you mentioned in Fray's End as you suggested, great idea. Maybe we can do the same with the Void townies, buttons collector and monk?

I couldn't find a good way to change the talker scene without breaking the existing references. So I think I'm going to merge it as-is and then we can explore option 2 separately.

I dedicated a couple hours today to fine-tune the drawings and animate an idle pose. It is very time consuming to animate each part, so I tried something simple (like in the "no edit" egg guy).

[manuq]

This exploration is in the main game now! Closing.