Social emotes shape: Interaction, animation and replication

[QThund]

Pull Request Description

What does this PR change?

It implements the full sequence of an interaction among 2 avatars:

• Start animation + audio clip + prop animation.
• Outcome animation of the receiver + audio clip + prop animation.
• Outcome animation of the initiator.
• Movement of the receiver's avatar to the position and rotation of the initiator.
• Renaming of the Armature of the receiver's avatar so the animation clip that refers to "Armature_Other" can find the objects.
• Replication in both clients.
• Ability to trigger the emote by clicking on the avatar when it is playing start animation.
• Animation cancelation.

Created the SocialEmoteInteractionManager, where the state of all active interactions is registered.

Please ignore all the Log calls, they are necessary to keep improving the feature.

See the docs: https://www.notion.so/decentraland/Social-Emotes-22d5f41146a5809dbe8ff69a9682f353

The sequence (main path):

The sequence (all paths)

Test Instructions

2 clients are required, only one of the players have a social emote.
The social emote should have:

• Start animation + prop + audio (loop).
• Outcome animation + prop + audio.

Client A plays the social emote

• The avatar plays start animation.
• The sound should play.
• The prop should be animated.
• Client B sees the animation.

Client A cancels the start animation (by moving or triggering another emote)

• The start animation finishes.
• Client B sees that the animation finishes.
• Client B can not interact after that.
• Client A avatar can move normally in both clients.

Client B can hover and click on the other avatar that is playing start animation

• Putting the mouse cursor on the Client A avatar shows INTERACT tooltip.

Client B plays the outcome animation

• Clicking on the Client A avatar that is playing start animation initiates the outcome animation of the Client B avatar.
• The animation of Client B avatar is visible in Client A.
• Client B avatar moves to the position of Client A avatar. Its orientation is correct.
• Client B avatar movement is visible in Clienat A.
• The prop and the audio clip play.

Client A plays the outcome animation

• When Client B avatar plays outcome animation, Client A avatar plays its outcome animation too.
• The animation of Client A avatar is visible in Client B.
• The prop and the audio clipsplay.

Client B cancels the social emote while playing outcome animation (by moving or triggering another emote)

• The animation of Client B avatar finishes.
• The animation of Client A avatar finishes.
• Both can move normally afterwards in both clients.
• It is possible to restart the sequence.

Client A cancels the social emote while playing outcome animation (by moving or triggering another emote)

• The animation of Client B avatar finishes.
• The animation of Client A avatar finishes.
• Both can move normally afterwards in both clients.
• It is possible to restart the sequence.

Client C sees the complete sequence

• The animations of Client A and B avatars are correct.
• The animations of the props are correct.
• The sounds are correct.

[github-actions]

New build in progress, come back later!

[claude]

Claude finished @QThund's task —— View job

---

Automated Code Review Analysis

Todo List

• Read core ECS system files and analyze against CLAUDE.md standards
• Check component design and mutation patterns
• Review performance implications and allocation patterns
• Identify missing error handling and potential runtime issues
• Compile findings with specific locations and fixes needed

---

Issues Requiring Fixes

1. Singleton Anti-Pattern Violation

Location: SocialEmoteInteractionsManager.cs:13-14
Problem: Uses [Singleton] attribute creating a global singleton, which violates CLAUDE.md guidelines about avoiding singletons in ECS systems
Fix: Remove the singleton pattern and pass this as a dependency through system constructors
Why: Violates ECS principles and creates hidden dependencies that are hard to test and reason about

2. Missing Component Mutation Safety

Location: SocialEmoteInteractionSystem.cs:44,48-49,69-79
Problem: Accessing and modifying components without using ref keyword
Fix: Change to ref CharacterController characterController and ref CharacterEmoteComponent emoteComponent in query methods
Why: CLAUDE.md requires ref var for component mutations to ensure proper ECS lifecycle management

3. Unsafe Component Access Without Null Checks

Location: SocialEmoteInteractionSystem.cs:40,62,91
Problem: Accessing SocialEmoteInteractionsManager.Instance.GetInteractionState() without null checks on the result
Fix: Add null validation before accessing interaction properties
Why: Could cause NullReferenceException at runtime

4. System Constructor Visibility Violation

Location: SocialEmoteInteractionSystem.cs:21-23
Problem: Constructor is public instead of internal as required by CLAUDE.md
Fix: Change public SocialEmoteInteractionSystem(World world) to internal SocialEmoteInteractionSystem(World world)
Why: CLAUDE.md explicitly requires system constructors to be marked internal

5. Performance Issue: Missing World Access Caching

Location: SocialEmoteInteractionSystem.cs:40,62,91
Problem: Repeatedly accessing singleton instance in hot paths without caching
Fix: Cache the interaction manager reference in constructor and use throughout
Why: Singleton access in Update loops creates unnecessary overhead across multiple world executions

6. Exception Handling Missing for Async Operations

Location: MultiplayerEmotesMessageBus.cs:72,88
Problem: UniTask.Forget() calls without exception handling
Fix: Use SuppressToResultAsync() pattern as required by CLAUDE.md async guidelines
Why: Unhandled exceptions in detached tasks can crash the application silently

7. Debug Logging in Production Code

Location: Multiple files with ReportHub.LogError(ReportCategory.EMOTE_DEBUG, ...)
Problem: Debug category logging scattered throughout production systems
Fix: Remove or gate behind conditional compilation directives
Why: Performance impact and log noise in production builds

8. Pool Resource Leak Risk

Location: SocialEmoteInteractionsManager.cs:134-142
Problem: Pool cleanup in StopInteraction() could leak if dictionary operations throw
Fix: Add try-finally block to ensure interactionPool.Release(interaction) always executes
Why: Resource leaks if exceptions occur during dictionary manipulation

9. Component State Inconsistency

Location: CharacterEmoteComponent.cs:47-59
Problem: Reset() method doesn't reset EmoteUrn and CurrentAnimationTag
Fix: Add EmoteUrn = URN.Empty; and CurrentAnimationTag = 0; to Reset method
Why: Incomplete state cleanup can cause logic errors in subsequent emote operations

10. Unnecessary Object Allocation in Hot Path

Location: EmotePlayer.cs:91-95
Problem: GetComponentsInChildrenIntoPooledList<Transform>() creates allocations in Update path
Fix: Cache transform children list or move this logic outside hot path
Why: CLAUDE.md requires allocation-free Update() methods

---

Critical Path Forward

1. Immediate: Fix component mutation safety issues (Evaluate World Streaming #2, Create a bridge between CRDT and ECS #4)
2. High Priority: Remove singleton dependencies (Test #1, Implement CRDT Protocol #5)
3. Production Readiness: Add exception handling (Implement ECS Messages Deserialization #6, Game Object Creation #8) and remove debug logging (Game Objects Life Cycle #7)
4. Performance: Address allocation issues (Transform Parameters Application #10) and state consistency (Transform Parenting #9)

The most critical issues affect ECS system integrity and runtime safety. The singleton pattern particularly violates core ECS architecture principles outlined in CLAUDE.md.

---