diff --git a/content/ADR-155-scene-triggers-custom-animations.md b/content/ADR-155-scene-triggers-custom-animations.md new file mode 100644 index 00000000..a1946df8 --- /dev/null +++ b/content/ADR-155-scene-triggers-custom-animations.md @@ -0,0 +1,73 @@ +--- +layout: adr +adr: 156 # replace this number for the PR or ISSUE number +title: Scene triggers custom animations +date: 2022-12-15 +status: Draft # pick one of these +type: RFC # pick one of these +spdx-license: CC0-1.0 +authors: + - nearnshaw # this is your github username +# remove the following line! it exists to render the template nicely +slug: /adr/scene-triggers-custom-animations +--- + +## Abstract + + + +This is a proposal to add a feature to the SDK to allow scene creators to include custom avatar animations as part of a scene’s content and to trigger these animations on players. The scene will then be able to use these whenever they make sense in a scene’s mechanics. + +## Context, Reach & Prioritization + + + +In most Decentraland experiences, you can see other players standing still even if they’re actively engaging with the scene, just standing motionless. This limits a lot of the social aspects of playing with others. It also makes you wonder if other players are even playing, if they’re not even at the keyboard, or if they’re just confused trying to understand the rules. + +While playing alone, these customized animations can also bring a lot more fun into a scene by making our actions more lively and leaving less to our suspension of disbelief. + +## Solution Space Exploration + + + +Discuss the potential alternatives, their impact, which ones are being considered, their benefits, their costs (team resources, money, time frames), and mitigations for any drawbacks. + +## Specification + + + +It should be possible for content creators to upload files that include instructions for an avatar animation, following the same limitations as the uploaded files for NFT emotes. These animations, however, won’t be NFTs but animations that the scene can trigger on any player visiting it. + +The scene can trigger these animations on players whenever they make sense in the game’s mechanics. For example, Wondermine could play a “swing” animation whenever a player is mining a meteor, or the casinos could play a “show-cards” animation whenever the player plays their hand in a poker game. A fighting game could include animations for throwing punches, animations for receiving damage, and animations for dying. + +As happens currently with all player animations, other players around seeing them; the scene creator doesn’t need to do anything extra for this to happen. + +As with the triggering of default animations today, the scene should include special permissions to allow it to trigger emotes on an avatar. + +Since the animations are downloaded together with the scene's content, there's a corner case that needs to be handled gracefully: Player A sees Player B far away but has not downloaded the scene where Player B is standing. The scene triggers an animation on Player B, but Player A doesn't have that animation downloaded. In this scenario, it's acceptable that Player A can't see the animation, as Player A is also not seeing the scene that gives that animation context. + + +**Syntax and semantics** + +This could be implemented via a component added to the player entity. It could be used to trigger animations from the default list of them or any animation file uploaded with the scene. + +**Open questions** + +- Should the scene also be able to control the avatar locomotion animations? For example, replace the default walk, run or jump animations with crawling, skating, holding a gun, or whatever makes sense in the scene. Is this easy to achieve? +- Can scene custom animations also be able to spawn images or geometries? Like the hearts or the clap icons from default animations. + +## RFC 2119 and RFC 8174 + +> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.