Static Parent and Nested Artboard Properties
Static Parent Property
Proposal:
Introduce the ability for an artboard to recognize its parent. This would enable the artboard to use targets such as joysticks, groups, or bones from a well-known artboard within the same Rive file.
Use Cases:
1. Interactive Controls:
An artboard containing interactive controls (e.g., joysticks) can directly influence animations or properties in another artboard, enhancing the interactivity and responsiveness of animations within the same project.
2. Complex Animation Coordination:
Allows for the creation of complex animations where multiple artboards need to be synchronized. For example, a character’s body artboard can dynamically respond to changes in a face artboard’s expressions. Biding parent bones to nested paths for shinning mechanism, and more.
3. Reusable Components:
Enables the reuse of artboards as modular components that can interact with parent artboards, promoting better organization and maintainability of animation projects.
Static Nested Artboard
Proposal:
Allow an artboard to recognize and modify its child artboards. This would enable modifications or animations of group positions, bones, and other properties within the nested artboard without affecting its overall structure. Essentially, this feature would act as modifiers for the instance within the parent artboard. Just like how Unity Prefabs work.
Use Cases:
1. Dynamic Sub-Animations:
Parent artboards can dynamically adjust the properties of nested artboards, such as changing colors or triggering specific animations in response to user interactions or events within the parent artboard.
2. Enhanced Animation Control:
Offers finer control over nested artboards, allowing for complex hierarchical animations. For instance, a parent artboard representing a robot can control nested artboards representing different parts of the robot, ensuring seamless and coordinated animations.
3. Customization and Variations:
Facilitates the creation of customizable animations where the parent artboard can apply variations to nested artboards, such as changing outfits, accessories, or other visual elements without needing to duplicate entire artboards.
These features would significantly enhance the flexibility and power of Rive, allowing for more sophisticated and interactive animations while maintaining a clean and organized project structure.
I think this is a bad idea from a programmers perspective. The issue is that it results in a constraint where the child artboard is now restricted to using the parent artboard that has whatever targets it requires. This is a dependency that's flowing in the incorrect direction (from the child to the parent). It makes the Rive file less flexible and more resistant to future changes.
I'm curious though, what problems would this solve for you?
It seems like all the advantages you described are already possible with Rive naturally?
Another thought, I actually think this might not be a bad idea, but I still think that the child shouldn't have dependencies on the parent, that's just a bad design. I think a better way could be that the parent can have "Nested artboard presets" which can be applied to any child artboards and contain logic that operates on that nested artboard's exposed inputs. The presets would designate what inputs must exist on the nested artboard, and in order to apply the preset to a nested artboard, you must first enable that preset on the artboard itself, thereby ensuring that it has the required exposed inputs.
I am presenting two different ideas:
Static Parent
While the concept of Static Parent may initially feel counterintuitive, it is actually very handy and not a rare design pattern. Currently, I am developing a game using Flutter and Rive (I am a developer, not a designer), but I am struggling with skinning. The reason is that in order to create a skin for a character, I have two options:
• Using a Solo object with all the “skin objects”: This allows me to animate all skins correctly, but it increases the size of the main artboard and makes it difficult to maintain an organized file. It’s almost intuitive that those skins should live as separate artboards, leading me to the next point.
• Using separate nested artboards: This might sound like a good option, but as soon as you start implementing the skin, you hit an impossible wall. You can’t access the parent’s bones to animate the nested artboard. This makes it unsuitable for flexible designs where fine control over deformation is needed. It is also impossible to set targets on parent objects, making it difficult to create useful constraints.
I checked all available sample files, and all use the Solo approach.
As a developer, I also look for a separation of concerns. This feature can be as good or bad depending on how it is implemented, but it is a shot that I think is worth taking.
Static Nested Artboard (Preset)
This, for me, is a no-brainer. I can bet that this is already planned somewhere in the Rive team’s backlog 😁. This feature is already implemented in most platforms under various names such as presets, prefabs, components, etc. The ability to modify nested artboards as instances is huge.
If both features are implemented, combined they could make Rive a perfect platform for no-code games, interface design, and much more.