Rive Blog

State machines make iteration a breeze

Rive’s State Machine makes it easy for designers to iterate without requiring devs to re-implement each version.

-

Tuesday, September 13, 2022

Rive Blog

State machines make iteration a breeze

Rive’s State Machine makes it easy for designers to iterate without requiring devs to re-implement each version.

-

Tuesday, September 13, 2022

Rive Blog

State machines make iteration a breeze

Rive’s State Machine makes it easy for designers to iterate without requiring devs to re-implement each version.

-

Tuesday, September 13, 2022

Visual state machines let designers build interactive components that actually work. They're not mockups or prototypes; they're functional assets ready to ship.

In the Rive Editor, designers define parameters (called inputs) using Rive's State Machine. Inputs can change at runtime (either with a listener, code, or a no-code tool like Framer). When an input's value changes, the state machine evaluates the logic created by the designer and displays the correct state.

Iterating on a loading component

For example, this state machine is driven by two inputs called Downloading and Percentage (get the file here). When Downloading is true, the graphic starts animating through a sequence of states to inform the user that something has started downloading. Changing the Percentage input from 0-100 makes the water move up. Once it hits 100, the sequence completes.

To implement this component, a developer loads the file (with Rive's runtime libraries) and sets the values for the Downloading and Percentage inputs.

The design team can now continue iterating on the visuals, animations, and interactions without needing more dev effort. Provided the inputs stay the same, everything else about the state machine can change. The design, animations, states, layers, transitions, and listeners can be wildly different, and the component will still work.

In the example above, we updated the loading animation to show a path with some trees growing as the download progresses (get this file here). The Downloading and Percentage inputs continue to drive the functionality, even though the graphics, animations, states, and transitions are different.

To implement this new design at runtime, we just need to replace the old file with the new one. No further effort or handoff has to happen!

Dive deeper into the concepts we covered

The example above hopefully shows how easy it is to iterate on interactive graphics created with Rive. The State Machine empowers designers to think more like devs without writing code. At the same time, it frees up engineering resources, not requiring a dev to be involved in re-implementing every iteration.

Without a state machine, all the interactions and logic would need to be written in code. And each iteration would require a dev to update the code, which would need to be prioritized against other engineering efforts. This is why custom animations and interaction designs are often scrapped from production timelines, or designers must settle on imperfect implementations. Instead, Rive makes it easy to deliver polished custom interactions and animations while making it a breeze for designers and developers to work together.

🧑‍🎨 How we created a star rating component using Rive's State Machine.
📺 Animation mixing video. The State Machine can do more than just play one animation at a time – it can blend and mix multiple animations at the same time.
📖 Runtime documentation. You can control more than just state machine inputs with code. Read our documentation to see what's possible with our runtime API.

Visual state machines let designers build interactive components that actually work. They're not mockups or prototypes; they're functional assets ready to ship.

In the Rive Editor, designers define parameters (called inputs) using Rive's State Machine. Inputs can change at runtime (either with a listener, code, or a no-code tool like Framer). When an input's value changes, the state machine evaluates the logic created by the designer and displays the correct state.

Iterating on a loading component

For example, this state machine is driven by two inputs called Downloading and Percentage (get the file here). When Downloading is true, the graphic starts animating through a sequence of states to inform the user that something has started downloading. Changing the Percentage input from 0-100 makes the water move up. Once it hits 100, the sequence completes.

To implement this component, a developer loads the file (with Rive's runtime libraries) and sets the values for the Downloading and Percentage inputs.

The design team can now continue iterating on the visuals, animations, and interactions without needing more dev effort. Provided the inputs stay the same, everything else about the state machine can change. The design, animations, states, layers, transitions, and listeners can be wildly different, and the component will still work.

In the example above, we updated the loading animation to show a path with some trees growing as the download progresses (get this file here). The Downloading and Percentage inputs continue to drive the functionality, even though the graphics, animations, states, and transitions are different.

To implement this new design at runtime, we just need to replace the old file with the new one. No further effort or handoff has to happen!

Dive deeper into the concepts we covered

The example above hopefully shows how easy it is to iterate on interactive graphics created with Rive. The State Machine empowers designers to think more like devs without writing code. At the same time, it frees up engineering resources, not requiring a dev to be involved in re-implementing every iteration.

Without a state machine, all the interactions and logic would need to be written in code. And each iteration would require a dev to update the code, which would need to be prioritized against other engineering efforts. This is why custom animations and interaction designs are often scrapped from production timelines, or designers must settle on imperfect implementations. Instead, Rive makes it easy to deliver polished custom interactions and animations while making it a breeze for designers and developers to work together.

🧑‍🎨 How we created a star rating component using Rive's State Machine.
📺 Animation mixing video. The State Machine can do more than just play one animation at a time – it can blend and mix multiple animations at the same time.
📖 Runtime documentation. You can control more than just state machine inputs with code. Read our documentation to see what's possible with our runtime API.

Visual state machines let designers build interactive components that actually work. They're not mockups or prototypes; they're functional assets ready to ship.

In the Rive Editor, designers define parameters (called inputs) using Rive's State Machine. Inputs can change at runtime (either with a listener, code, or a no-code tool like Framer). When an input's value changes, the state machine evaluates the logic created by the designer and displays the correct state.

Iterating on a loading component

For example, this state machine is driven by two inputs called Downloading and Percentage (get the file here). When Downloading is true, the graphic starts animating through a sequence of states to inform the user that something has started downloading. Changing the Percentage input from 0-100 makes the water move up. Once it hits 100, the sequence completes.

To implement this component, a developer loads the file (with Rive's runtime libraries) and sets the values for the Downloading and Percentage inputs.

The design team can now continue iterating on the visuals, animations, and interactions without needing more dev effort. Provided the inputs stay the same, everything else about the state machine can change. The design, animations, states, layers, transitions, and listeners can be wildly different, and the component will still work.

In the example above, we updated the loading animation to show a path with some trees growing as the download progresses (get this file here). The Downloading and Percentage inputs continue to drive the functionality, even though the graphics, animations, states, and transitions are different.

To implement this new design at runtime, we just need to replace the old file with the new one. No further effort or handoff has to happen!

Dive deeper into the concepts we covered

The example above hopefully shows how easy it is to iterate on interactive graphics created with Rive. The State Machine empowers designers to think more like devs without writing code. At the same time, it frees up engineering resources, not requiring a dev to be involved in re-implementing every iteration.

Without a state machine, all the interactions and logic would need to be written in code. And each iteration would require a dev to update the code, which would need to be prioritized against other engineering efforts. This is why custom animations and interaction designs are often scrapped from production timelines, or designers must settle on imperfect implementations. Instead, Rive makes it easy to deliver polished custom interactions and animations while making it a breeze for designers and developers to work together.

🧑‍🎨 How we created a star rating component using Rive's State Machine.
📺 Animation mixing video. The State Machine can do more than just play one animation at a time – it can blend and mix multiple animations at the same time.
📖 Runtime documentation. You can control more than just state machine inputs with code. Read our documentation to see what's possible with our runtime API.

Start building beautiful interactive graphics

Get Started

© 2022 Rive, Inc. All rights reserved.

All trademarks, logos, and brand names are the property of their respective owners.

© 2022 Rive, Inc. All rights reserved.

All trademarks, logos, and brand names are the property of their respective owners.