Thanks for those answers!
If you need exact realtime visual replica of the character (with animations etc.) then reasonable option is to render it to a separate viewport and use it as a texture in all places needed.
Yes! This looks the kind of solution I was looking for. Maybe you would have some pointers to more details about it? (else... well I can try :) ) I wonder also if I should expect a significant perfs overhead? I would need say 50 to 500 such instances, each with their own viewport. (The size if each texture should stay reasonably small, about 100x100)
You could also put that scene into a wrapper scene and then instance that wrapper scene. This'll get rid of all eventual code duplication.
I did not understand this one.
If that still doesn't work for you, perhaps post the entire scene structure and how you configure it to represent different characters. Then it'd be easier to suggest more specific solution.
Sure! Simplifying a bit, my scene representing one character looks as follow:
CharacterNode: 2DNode
Sprite characterImage
Sprite weapon
Node2D lifebar
HBoxContainer iconsContainer // containing several sprites displaying lasting effects
The state of weapon, lifebar and iconsContainer may change during the game ( eg character.TakeDamage() would modify the lifebar )
I have a lot of instances of this scene, representing different characters.
They are all displayed on a viewport showing the main map. One (but not always the same) should also be displayed on a UI container.
Maybe I could also add the solution I have been thinking to since yesterday:
I suppose I could use some kind of "Observer" pattern, where I would have a non-displayable character Node, with a method to spawn a new instance of a Node2D which "observes" this node. The character node would send messages whenever its state changes. The Node2D would have a script to listen to those messages, and update their own graphic elements as required. This way I can "simply" spawn several nodes observing the same character.
Only issue I foresee with this method: it adds one layer of indirection (posting && receiving the messages) to every state change on the character, which makes it a bit slower to dev.