DEV Community: Praneeth Kawya Thathsara

Hire a Rive Animator in 2027: A Developer's Guide to Interactive Characters & AI Avatars

Praneeth Kawya Thathsara — Wed, 14 Oct 2026 21:02:57 +0000

Hire a Rive Animator in 2027: A Developer's Guide to Interactive Characters & AI Avatars

Building a Flutter app, React Native product, AI assistant, or interactive website? Here's how to plan, build, and integrate a production-ready Rive animation system — and find the right specialist to help.

Modern applications are becoming more interactive, personalized, and character-driven.

A fitness app might feature a mascot that celebrates achievements. An educational platform might use an animated tutor. An AI assistant might have a character that listens, thinks, speaks, and responds emotionally.

But there is a difference between an animation that looks impressive in a design preview and one that works reliably inside a production application.

That's where Rive animation, state machines, and developer-focused motion design become important.

I'm Praneeth Kawya Thathsara, a remote freelance Rive animator specializing in interactive characters, AI avatars, app mascots, and production-ready animation systems.

In this guide, I'll share how I approach Rive projects, what developers should consider before integration, and how to prepare a clear animation brief.

Interactive portfolio: RiveAnimator.com

1. Why Developers Choose Rive for Interactive Animation

Traditional animation files are useful when the animation follows a fixed sequence.

But modern applications often need graphics that respond dynamically to changing conditions.

Consider an AI assistant.

When the user starts speaking, the character should listen. When the AI processes a request, it should appear to think. When audio playback begins, the character should speak.

These aren't simply three video files.

They are connected behaviors controlled by application logic.

Rive provides tools such as:

State machines for animation behavior
Data binding and view models
Interactive animation transitions
Reusable animation components
Responsive layouts
Runtime integration across supported platforms

This allows developers and motion designers to work together on an interactive system instead of managing dozens of unrelated animation files.

2. What a Production-Ready Rive Character Looks Like

Let's imagine we're building a character for an AI-powered learning app.

The character needs six primary states:

State	Behavior	App event
Idle	Breathing and blinking	Default
Listening	Attentive expression	Microphone active
Thinking	Processing animation	AI request pending
Speaking	Talking animation	Audio playback
Success	Celebration	Task completed
Error	Friendly error reaction	Request failed

The animation designer must decide how these states connect.

For example:

                 ┌─────────────┐
                 │    IDLE     │
                 └──────┬──────┘
                        │
                        ▼
                 ┌─────────────┐
                 │  LISTENING  │
                 └──────┬──────┘
                        │
                        ▼
                 ┌─────────────┐
                 │  THINKING   │
                 └──────┬──────┘
                        │
                        ▼
                 ┌─────────────┐
                 │  SPEAKING   │
                 └──────┬──────┘
                        │
                        ▼
                       IDLE

This diagram shows the normal conversation flow.

However, a real application also needs interruption handling.

What if the microphone closes during listening?

What if the user interrupts the AI while it's speaking?

What if an error occurs during thinking?

A production-ready Rive file must handle these conditions without broken poses, unwanted greetings, or abrupt visual transitions.

3. Designing State Machine Priorities

One common mistake is assuming that every animation state has the same priority.

In practice, the application might briefly report several active conditions.

For example:

const characterState = {
  isOpen: true,
  isListening: false,
  isThinking: true,
  isSpeaking: true,
};

Which animation should play?

For this example, we can define the following priority:

Speaking
   ↓
Thinking
   ↓
Listening
   ↓
Open / Idle
   ↓
Closed

A simple JavaScript state resolver might look like this:

function resolveCharacterMode({
  isOpen,
  isListening,
  isThinking,
  isSpeaking,
}) {
  if (isSpeaking) return "speaking";
  if (isThinking) return "thinking";
  if (isListening) return "listening";
  if (isOpen) return "idle";
  return "closed";
}

This is application-side logic, not a direct Rive runtime API call.

The resulting mode can be connected to an appropriately configured Rive state machine or data binding property.

The important principle is consistency.

The animator and developer should agree on the behavior contract before integration begins.

4. Data Binding and View Models

Rive's data binding system allows applications to connect structured data with animation properties and behavior.

Instead of relying entirely on separate manually controlled inputs, developers can work with view model properties that represent application state.

For example, an AI character might expose:

ViewModel: AICharacter

Properties:
  activityMode   → Enum
  emotion        → Enum
  audioLevel     → Number
  lookX          → Number
  lookY          → Number
  isOpen         → Boolean

These are suggested property names for a custom project, not predefined Rive properties.

A developer and animator can agree on value ranges and supported behavior.

For example:

Property	Example	Purpose
activityMode	Speaking	Main activity
emotion	Happy	Facial expression
audioLevel	0.65	Mouth movement intensity
lookX	0.25	Horizontal gaze
lookY	-0.15	Vertical gaze
isOpen	true	Widget visibility state

With this structure, application logic and animation design can remain more clearly separated.

For new projects, I recommend planning the data binding architecture before building complex animation states.

5. Rive for Flutter, React Native, React, and Web

Rive supports multiple platforms, but the integration details are not identical.

Flutter

Flutter developers commonly use Rive for:

Interactive onboarding
Gamified dashboards
Progress animations
Mascot reactions
Educational characters
Reward and achievement systems

A useful handoff should include the .riv file, exact artboard names, view model documentation, and clear state behavior.

React Native

React Native developers can integrate interactive Rive animations into cross-platform applications.

In October 2026, Rive React Native v0.5.0 moved out of beta, bringing the package onto newer native runtimes and supporting type-safe schema generation.

Developers migrating older implementations should check the current runtime documentation before changing APIs.

React and Web

For websites and web applications, Rive can be used for:

AI chatbot avatars
Interactive hero sections
Cursor-tracking characters
Onboarding assistants
Product walkthroughs
Interactive dashboards

The animation should be tested for responsiveness, lifecycle behavior, accessibility considerations, and performance.

Native Mobile and Other Platforms

Rive also provides runtimes for native mobile platforms and additional development environments.

Always confirm compatibility with your chosen runtime version before starting implementation.

Official documentation: Rive Developer Docs

6. AI Avatars and Interactive Robot Characters

One of my main areas of specialization is designing expressive Rive characters for AI-powered products.

Imagine an AI companion with the following behaviors:

Idle: Natural blinking, breathing, and subtle movement.

Listening: Attentive eyes and listening expressions.

Thinking: Animated processing behavior.

Speaking: Mouth shapes and expressions synchronized with application-provided audio data.

Happy: Positive emotional reactions.

Error: Friendly visual feedback.

Sleeping: Reduced activity while the assistant is inactive.

More advanced implementations can support:

Viseme-based lip-sync
Audio amplitude controls
Eye and cursor tracking
Emotional expressions
Smooth animation blending
Interruptible conversations
Character reactions to application events

For example, the application's voice system might produce:

{
  "activityMode": "speaking",
  "emotion": "happy",
  "audioLevel": 0.72,
  "lookX": 0.15,
  "lookY": -0.1
}

The Rive animation system can be designed to respond to these values.

Rive handles the visual character behavior, while the application's AI and audio systems handle speech recognition, response generation, and playback.

This separation makes the system easier to reason about and maintain.

7. Common Rive Integration Mistakes

After working with interactive animation systems, I've found that many integration issues can be prevented through better planning.

Mistake 1: Building Animations Before Defining States

The team creates several animations without deciding how they transition.

Better approach: Define the state machine architecture first.

Mistake 2: Inconsistent Property Names

The developer expects isSpeaking, but the animation file exposes a different property.

Better approach: Document all runtime-facing property names.

Mistake 3: Idle Animations Affecting Other States

Breathing or blinking animations accidentally influence properties owned by another animation.

Better approach: Carefully organize animation layers and property ownership.

Mistake 4: No Interruption Handling

A character works when animations finish naturally but breaks when a user interrupts an action.

Better approach: Test mid-animation transitions and reset behavior.

Mistake 5: No Developer Handoff

The developer receives a .riv file without knowing how to control it.

Better approach: Provide an integration guide with expected states, properties, values, and transitions.

8. What to Expect When Hiring a Freelance Rive Animator

If you're looking for a Rive animator for hire, evaluate more than the visual quality of their animation portfolio.

A developer-focused Rive specialist should understand:

Skill	Why it matters
Character rigging	Reusable, expressive movement
State machines	Interactive behavior
Data binding	Application-driven animation
Transition design	Smooth state changes
Asset optimization	Runtime efficiency
Developer handoff	Easier integration
Runtime testing	More reliable delivery

For complex applications, the animation architecture can be just as important as the visual design.

9. My Freelance Rive Animation Services

I'm Praneeth Kawya Thathsara, an independent Rive animator and interactive motion designer working remotely with developers, founders, and product teams.

I specialize in:

Custom Rive mascot animation
Interactive character design and rigging
State machine development
Rive data binding systems
AI assistant and robot avatar animation
Lip-sync and facial expressions
Flutter and React Native animation assets
Interactive website characters
Existing Rive file troubleshooting
Runtime-ready animation handoff

My goal is to help developers build interactive characters that are visually expressive and technically practical.

Portfolio: RiveAnimator.com

10. How to Prepare a Rive Animation Project Brief

Before contacting an animator, you don't need a complete technical specification.

A simple brief is enough to begin.

You can use this template:

Project Name:
Product Type:
Target Platform:
Existing Character Design:
Required Animation States:
Interactive Controls:
Reference Links:
Expected Deadline:
Approximate Budget:

For example:

Project: AI Learning Assistant
Platform: React Native
Character: Existing Figma robot design

States:
- Idle
- Listening
- Thinking
- Speaking
- Happy
- Error

Features:
- Lip-sync
- Eye tracking
- Smooth transitions
- Data binding

Deliverables:
- Runtime .riv file
- Editable source project
- Integration guide

A clear brief makes it easier to estimate the complexity, timeline, and project cost.

11. Hire Praneeth Kawya Thathsara — Remote Freelance Rive Animator

If you're building an interactive mobile app, SaaS product, AI assistant, or screen-based robot, I can help you plan and develop the Rive animation system.

I work remotely with international development teams and offer project-based freelance services.

You can contact me directly, without going through an agency.

Have a Rive Animation Project?

Praneeth Kawya Thathsara

Freelance Rive Animator & Interactive Motion Designer

Specialties: Interactive Mascots · AI Avatars · State Machines · Flutter · React Native · Web

🌐 Portfolio: RiveAnimator.com

📩 Email: riveanimator@gmail.com

💬 WhatsApp: Chat directly and request a quotation

Share your project details, Figma design, existing Rive file, or animation references to get started.

💬 Send Your Project Brief on WhatsApp

12. Frequently Asked Questions

Where can I hire a freelance Rive animator?

You can hire me directly through RiveAnimator.com, WhatsApp, or email for remote Rive animation projects.

Can you create Rive animations for Flutter and React Native?

Yes. I create interactive Rive animation assets and state machine systems for Flutter, React Native, and other supported platforms.

Can you animate an AI assistant that listens and speaks?

Yes. I specialize in AI avatar animation, including listening, thinking, speaking, facial expressions, eye tracking, and lip-sync-ready systems.

Can you work with an existing Figma character?

Yes. I can review existing illustrations for rigging and animation readiness.

Do you provide `.riv` files and documentation?

Runtime-ready files, editable source access, and developer documentation can be included in the agreed project deliverables.

Can you fix an existing Rive animation?

Yes. I can review issues involving state transitions, idle behavior, animation layers, runtime controls, and other Rive animation problems.

Do you work remotely?

Yes. I'm based in Sri Lanka and collaborate remotely with developers, startups, and teams internationally.

Final Thoughts

Interactive animation is becoming an important part of modern application design.

Whether you're developing a gamified mobile app, an AI tutor, a conversational assistant, or an interactive website, the right animation system can make your product more expressive.

But great animation is only one part of the solution.

A successful Rive project also needs thoughtful state machine architecture, predictable runtime controls, and a clear developer handoff.

If you're looking for a freelance Rive animator who understands both character animation and interactive application requirements, I'd be happy to discuss your project.

Let's build something interactive.

Portfolio: RiveAnimator.com
WhatsApp: Request a Rive Animation Quote
Email: riveanimator@gmail.com

References

How to Build a Raspberry Pi AI Companion with a Real-Time Animated Face Using Rive

Praneeth Kawya Thathsara — Thu, 01 Oct 2026 11:25:37 +0000

How to Build a Raspberry Pi AI Companion with a Real-Time Animated Face Using Rive

AI companions are moving beyond chat windows.

Developers are now building Raspberry Pi AI companions, desktop AI robots, AI pets, social robots, smart toys, voice assistants, and physical AI agents that can listen, understand speech, respond with an LLM, and talk back using text-to-speech.

But there is a common problem.

The AI may be intelligent, yet the device still feels like a computer with a screen.

A convincing AI companion needs more than a voice.

It needs a face that reacts to what the AI is doing in real time.

That is where an interactive animation system such as Rive becomes useful.

I'm Praneeth Kawya Thathsara, a Rive animator and interactive character specialist at Mascot Engine. I design real-time animated faces and state-machine systems for AI companions, robots, AI toys, and other interactive products.

In this article, I'll explain how I approach an animated face for a Raspberry Pi or similar AI companion device.

Why Give a Raspberry Pi AI Companion an Animated Face?

Imagine a desktop AI companion sitting beside your monitor.

You say:

"What's on my schedule today?"

The microphone detects your voice.

The character immediately changes from:

Idle → Listening

When you stop speaking:

Listening → Thinking

The AI processes the request.

When the response is ready:

Thinking → Speaking

While the TTS audio plays, the character's mouth reacts to the actual speech.

Its eyes can blink naturally.

Its pupils can follow the user.

Its expression can change depending on the conversation.

Instead of playing a prerecorded animation, the character becomes part of the AI system.

The Basic Architecture

A simplified Raspberry Pi AI companion architecture might look like this:

User
 ↓
Microphone / Camera / Sensors
 ↓
Raspberry Pi / Linux SBC
 ↓
Speech Recognition
 ↓
LLM / AI Agent
 ↓
Text-to-Speech
 ↓
Application
 ↓
Rive Runtime
 ↓
Rive Character State Machine
 ↓
LCD / Touchscreen

The important part is the connection between your application and the animated character.

The application knows whether the AI is listening, processing, speaking, sleeping, experiencing an error, or performing another task.

Instead of keeping that information invisible, we can send it to the character.

A Rive State Machine for an AI Robot

I normally structure AI companion animation systems around developer-friendly states and properties.

For example:

mode

0 = Idle
1 = Listening
2 = Thinking
3 = Speaking
4 = Connecting
5 = Error
6 = Sleeping

The application changes the mode based on the current AI state.

When:

mode = 0

the character idles.

When:

mode = 1

the character visually listens.

When:

mode = 2

the character enters a thinking animation.

When:

mode = 3

the speaking system becomes active.

This creates a clean relationship between the application logic and character animation.

Add Emotions Independently

The activity of the AI and the emotional expression of the character don't necessarily need to be the same system.

For example:

emotion

0 = Neutral
1 = Happy
2 = Empathetic
3 = Concerned
4 = Surprised

Now your AI could be:

mode = Speaking
emotion = Happy

or:

mode = Speaking
emotion = Concerned

The mouth can continue responding to audio while the eyes, eyebrows, cheeks, and other facial elements communicate emotion.

This gives developers much more control over the character.

Real-Time Lip Sync for an AI Companion

One of the most important features of a voice-first AI companion is lip sync.

There are two useful approaches.

1. Audio-Amplitude Lip Sync

Your application calculates the current audio level of the TTS output and sends a normalized value to the character.

For example:

audioLevel = 0.0 → 1.0

A quiet moment might produce:

0.05

Normal speech:

0.45

A louder sound:

0.90

The Rive character maps this value to mouth movement.

This creates lightweight real-time mouth animation without requiring complex phoneme processing.

2. Viseme-Based Lip Sync

For more detailed speech animation, the TTS pipeline can provide phoneme or viseme information.

The application can send something like:

viseme = 0
viseme = 1
viseme = 2
viseme = 3
viseme = 4
viseme = 5

Each value corresponds to a mouth shape.

The result can be significantly more expressive than simply opening and closing the mouth.

Depending on the product, I may also combine viseme selection + audio amplitude.

The viseme determines the mouth shape.

The audio level determines its intensity.

Real-Time Eye Tracking

Another small feature that makes a surprisingly large difference is gaze.

The application can expose:

lookX = -1.0 → 1.0
lookY = -1.0 → 1.0

These values can come from:

Camera-based face tracking
Person detection
Touch position
Cursor position
Device orientation
Random idle behavior
Other sensor data

The Rive rig converts these values into pupil or head movement.

Now the AI companion can appear to look toward the person interacting with it.

Automatic Blinking and Idle Behavior

A character should not freeze whenever the AI is inactive.

The idle system can include:

Breathing
Natural blinking
Small pupil movement
Tiny head motion
Ear movement
Antenna movement
Glow changes
Particle effects
Occasional expression changes

The key is subtlety.

If every animation is constantly moving, the character becomes distracting.

Good idle animation should make the device feel alive without demanding attention.

Listening Animation

When the microphone becomes active, the character can immediately acknowledge the user.

Possible listening behaviors include:

Eyes focus toward the user
Eyebrows lift slightly
Mouth becomes neutral
Head tilts
Ears or antenna react
Glow changes
Listening indicator appears

This visual feedback is important because it tells the user:

"The device can hear me."

Thinking Animation

LLM responses are not always instantaneous.

Instead of leaving the user staring at a frozen face, the character can communicate that processing is happening.

The thinking state could include:

Looking upward
Eye movement
Subtle particles
Pulsing glow
Animated dots
Head movement
A thoughtful expression

This transforms latency into part of the character experience.

Speaking Animation

When the AI starts responding, the system can transition into Speaking.

During this state:

audioLevel

can continuously control mouth movement.

If available:

viseme

can control mouth shapes.

Meanwhile:

emotion

can continue controlling the expression.

That means speech, emotion, and animation do not have to fight each other.

Example Control Model

A complete AI companion character could expose something similar to:

mode
0 Idle
1 Listening
2 Thinking
3 Speaking
4 Connecting
5 Error
6 Sleeping

emotion
0 Neutral
1 Happy
2 Empathetic
3 Concerned
4 Surprised

audioLevel
0.0 → 1.0

viseme
0 → 5+

lookX
-1.0 → 1.0

lookY
-1.0 → 1.0

Additional controls could include:

blink
celebrate
reset
touch
notification
batteryLow
wake
sleep

The exact API should match the product rather than forcing every project into the same template.

Why Rive Instead of a GIF or Video?

A GIF or MP4 can play an animation.

But an AI companion needs to react.

With an interactive Rive system, the application can control the character while it is running.

Instead of:

play speaking.mp4

you can build behavior around changing data:

mode = Speaking
emotion = Happy
audioLevel = 0.72
lookX = -0.25
lookY = 0.10

The character responds to those values.

That distinction is important for AI products.

You're not just adding animation.

You're creating a visual interface for the AI's internal state.

Can Rive Run on Raspberry Pi?

This needs an important clarification.

A Raspberry Pi is a Linux single-board computer, but the exact Rive integration depends on your operating system, graphics stack, application framework, and hardware configuration.

Rive provides production runtimes for platforms including C++, Flutter, Android, JavaScript/Web, React, React Native, iOS, Unity, and Unreal.

So before choosing an implementation, the software architecture of the device should be evaluated.

For some Linux/Raspberry Pi projects, a web-based or C++ architecture may be appropriate.

For other products, an Android or Flutter-capable hardware platform may make more sense.

The animation design and state-machine API can remain conceptually similar even when the runtime implementation changes.

Raspberry Pi vs ESP32 for an Animated AI Face

This is another common question.

An ESP32/ESP32-S3 is excellent for tasks such as:

Sensors
LEDs
Buttons
Motors
Connectivity
Simple embedded graphics
Hardware control

A Raspberry Pi-class computer is much closer to a complete computer and is generally better suited to workloads involving Linux applications, richer UI frameworks, voice pipelines, and more complex real-time graphics.

For some robots, both can be useful.

For example:

Raspberry Pi
├── AI
├── Voice
├── Rive / UI
└── Display

ESP32
├── LEDs
├── Motors
├── Touch sensors
└── Other hardware

The two controllers can communicate through an appropriate protocol.

The correct architecture depends on the product.

What Types of Products Can Use This?

The same approach can work for many kinds of products:

Raspberry Pi AI Companions

Small desktop devices that listen and talk to users.

Desktop AI Robots

Physical assistants for desks, offices, or homes.

AI Toys

Interactive characters that respond to speech and play.

AI Pets

Digital or robotic companions with personality and emotional reactions.

Social Robots

Robots designed around communication and human interaction.

Educational Robots

Characters that teach languages, STEM, reading, or other subjects.

Voice AI Devices

Hardware where voice is the primary interface.

Smart Displays

Displays that need a more human, character-driven interface.

LLM Hardware

Physical products built around ChatGPT-style or other large-language-model experiences.

Embodied AI / Physical AI

AI systems where intelligence is represented through a physical device.

Need a Rive Animator for Your AI Robot?

This is exactly the type of work I specialize in.

I'm Praneeth Kawya Thathsara, a Rive animator working through Mascot Engine.

I create interactive character systems for developers building AI companions, AI robots, AI toys, voice interfaces, apps, and interactive products.

Depending on your project, I can help with:

AI robot face design
Rive character rigging
Interactive Rive animation
State machine architecture
Idle animations
Listening states
Thinking states
Speaking states
Automatic blinking
Emotional expressions
Audio-amplitude lip sync
Viseme-based lip sync
Eye and gaze tracking
Touch reactions
Developer-friendly controls
Rive file optimization
Integration mapping
Testing and iteration

How Much Does a Custom AI Robot Face Cost?

A typical custom real-time Rive AI companion setup starts around $1,200 USD, depending on complexity.

For an appropriate starter project, I can structure payment as:

First milestone — $600

We define the character behavior and build the agreed core animation system.

This can include the rig, core states, state machine, expressions, lip-sync controls, and other agreed functionality.

Final milestone — $600

After the agreed system has been tested and the core requirements pass, the remaining payment is completed for final delivery.

More complex projects may require a custom quote.

For example:

Large animation libraries
Multiple characters
Complex character illustration
Advanced lip sync
Many emotions
Character evolution systems
Specialized hardware
Additional interaction states

If you already have a budget, tell me.

I can suggest what is realistic within it.

What Should You Send Me?

You don't need a finished product.

If you're currently prototyping an AI companion, send me:

A photo, video, sketch, or prototype
Your hardware — Raspberry Pi, Linux SBC, Android, etc.
Your software stack
What the AI already does
What you want the character to do
Your approximate budget

I'll be able to understand the project much faster.

Hire a Rive Animator for Your Raspberry Pi AI Companion

If you found this article while searching for:

Raspberry Pi AI companion animator

Rive animator for AI robot

AI robot face animation

AI companion face animation

Raspberry Pi animated face

real-time robot face animation

Rive lip sync

AI avatar animation

desktop AI companion animation

AI toy character animation

robot facial animation

Rive state machine developer

Rive character animator

physical AI character design

embodied AI animation

then you're probably building exactly the kind of project I enjoy working on.

Contact Me

Praneeth Kawya Thathsara

Rive Animator & Interactive Character Specialist

Mascot Engine

🌐 https://mascotengine.com

📧 mascotengine@gmail.com

💬 WhatsApp: +94 71 700 0999

Send me your AI robot idea, a photo or video of the prototype, what you want the face to display, and your approximate budget.

Even if the hardware isn't finalized yet, I can help you think through the character animation architecture.

Final Thoughts

AI hardware is becoming increasingly capable.

Speech recognition gives the device ears.

An LLM gives it intelligence.

Text-to-speech gives it a voice.

But visual expression can give that intelligence presence and personality.

For a desktop AI companion, robot, smart toy, or physical AI product, the screen doesn't have to be just another UI.

It can become the character.

If you're building one, I'd love to see it.

Your AI already has a voice. Give it a face.

— Praneeth Kawya Thathsara, Mascot Engine

Hire a Rive Animator for Your AI Companion, AI Robot or AI Toy

Praneeth Kawya Thathsara — Thu, 01 Oct 2026 08:17:30 +0000

Hire a Rive Animator for Your AI Companion, AI Robot or AI Toy

Are you building an AI companion, AI robot, AI toy, desktop AI companion, voice assistant, educational robot or smart device with a screen?

Your AI may already be able to listen, think and speak.

But what does the user see while that's happening?

I'm Praneeth Kawya Thathsara, founder of Mascot Engine, and I create interactive animated faces and characters for AI products using Rive.

If you're searching for a Rive animator for an AI robot, AI companion face animator, robot face animation service, or someone who can create a developer-ready interactive character for your AI device, this is exactly the type of work I specialize in.

Give Your AI a Face That Feels Alive

Imagine talking to an AI device.

You start speaking.

The character immediately changes from:

Idle → Listening

You finish your question.

Listening → Thinking

The AI generates its answer.

Thinking → Speaking

While the response is playing, the mouth reacts to the audio.

The eyes blink naturally.

The character looks around occasionally.

Its expression can change depending on the conversation.

That small screen suddenly feels less like a display and more like a character.

That's what I build.

AI Robot Face Animation with Rive

I use Rive animation and Rive State Machines to create interactive character systems that developers can control from their applications.

Instead of delivering only MP4 videos, GIFs or fixed animation loops, I can create a .riv animation system designed around your product's states.

A typical AI companion could include:

Idle / Ready
Listening
Thinking
Speaking
Connecting
Happy
Surprised
Concerned
Sad / Empathetic
Error / Offline
Sleeping
Celebration
Notifications
Custom reactions

The exact states can be designed around your AI product.

Lip Sync for AI Robots and AI Companions

If your AI talks, its face shouldn't continue looking static.

I can create lip-sync animation for AI characters using different approaches depending on your software architecture.

Audio Amplitude Lip Sync

Your application sends an audio value such as:

audioLevel = 0.0 → mouth closed
audioLevel = 0.5 → mouth partially open
audioLevel = 1.0 → mouth fully open

This provides lightweight, responsive mouth movement while TTS audio is playing.

Viseme Lip Sync

For more advanced systems, the character can have multiple mouth shapes controlled through a viseme input.

For example:

viseme = 0
viseme = 1
viseme = 2
viseme = 3
viseme = 4
viseme = 5

Your TTS or speech system can then control the appropriate mouth shapes.

This can work well for AI assistants, conversational robots, AI avatars and voice-first devices.

Eye Tracking and Gaze Control

Eyes make a huge difference to whether a digital character feels alive.

A character can support inputs such as:

lookX = -1.0 ... 1.0
lookY = -1.0 ... 1.0

Your developer can connect these inputs to:

Cursor tracking
Touch position
Camera-based face tracking
User position
Random idle gaze
Application events

I can also create natural automatic blinking and random eye movement so the robot doesn't look frozen when idle.

Independent Emotion Control

Conversation state and emotion don't have to be the same thing.

For example:

activity = Speaking
emotion = Happy

or:

activity = Speaking
emotion = Concerned

The mouth can continue responding to speech while the eyes, eyebrows and other facial features communicate emotion.

A possible developer interface could look like:

activity
emotion
audioLevel
viseme
lookX
lookY
blink
celebrate
reset

The final inputs depend on your product.

Developer-Friendly Rive State Machines

Good character animation isn't enough for an interactive product.

The implementation also needs to be understandable for developers.

For example, an AI companion might use:

activity = 0 → Idle / Ready
activity = 1 → Listening
activity = 2 → Thinking
activity = 3 → Speaking
activity = 4 → Connecting
activity = 5 → Error / Offline
activity = 6 → Sleeping

Your application changes the input.

The Rive State Machine handles the visual transition.

This approach can make the character easier to integrate into applications built with technologies such as Flutter, React, React Native, Web and other environments supported by the selected Rive runtime.

Runtime and hardware compatibility should always be confirmed before production.

What About ESP32 AI Robots?

I'm also interested in the growing market around:

ESP32 AI companions

ESP32-S3 AI robots

ESP32 animated faces

ESP32 robot displays

AI desktop pets

DIY AI companion robots

For constrained embedded hardware such as ESP32-S3, running a complete Rive runtime directly may not always be the best production approach.

One possible architecture is:

Microphone
    ↓
ESP32-S3
    ↓
Wi-Fi / AI Backend
    ↓
STT → LLM → TTS
    ↓
ESP32-S3
    ↓
Speaker + Animated Display

The visual system could use states designed in Rive and then be adapted to the capabilities of the target embedded environment.

For example:

IDLE
LISTENING
THINKING
SPEAKING
HAPPY
SLEEPING
ERROR

Lip sync can potentially be simplified into several mouth positions controlled by the audio amplitude.

The best implementation depends on the exact display, MCU, memory, rendering stack and software environment.

Raspberry Pi AI Companion and Desktop Robot Faces

More capable hardware can provide additional options.

If you're building a:

Raspberry Pi AI companion
Raspberry Pi robot
Desktop AI assistant
Touchscreen AI companion
Smart display
AI kiosk
Voice-first hardware product

we can review the runtime and decide on an appropriate animation architecture before production.

What Types of Products Can I Help With?

My animation service is suitable for founders, developers, startups and hardware teams working on products such as:

AI Companion Robots

Friendly conversational devices designed to interact with users.

Desktop AI Companions

Small devices that live on a desk and communicate through voice, animation and expressions.

AI Toys

Interactive toys where personality is an important part of the user experience.

Educational AI Robots

Characters that teach children, languages, STEM subjects or other educational content.

Kids' AI Companions

Friendly screen-based characters that listen, respond and react.

AI Voice Assistants

Voice-first products that need visual feedback for listening, thinking and speaking.

Smart Displays

Devices where a character can replace a traditional static assistant UI.

Customer Service Robots

Characters that visually communicate while an AI system handles the conversation.

Healthcare or Wellness Companions

Screen-based characters where friendly visual communication is part of the product experience.

AI Hardware Prototypes

Early-stage products that need a convincing animated face for demos, investors or user testing.

Already Have Your Robot Face Design?

That's fine.

If you already have:

Character artwork
Robot concept art
Figma designs
Illustrator vectors
SVG artwork
PNG references
Existing Rive files

send them to me.

I can review the artwork and determine how it should be prepared for animation.

Don't Have a Character Yet?

You can still contact me.

Send me your device, screen and product concept.

We can determine what kind of visual character would work for the product before building the interactive animation.

My Standard AI Robot Face Package

A default setup starts at approximately:

$1,200 USD

For a typical $1,200 project:

$600 USD upfront

I begin designing, rigging and building the agreed animation system.

You then receive the agreed build for testing.

Once the agreed tests pass and the work is approved:

Remaining $600 USD

This means you don't need to pay the entire project amount upfront.

Projects requiring more characters, complex artwork, many custom states, advanced lip sync or additional animation systems may need a custom quote.

What Can Be Included?

Depending on the project scope, a default system may include a selection of:

Character/robot face rigging
Idle animation
Automatic blinking
Random eye movement
Listening animation
Thinking animation
Speaking animation
Audio-reactive mouth animation
Viseme-ready mouth shapes
Expressions
Emotion controls
Eye/gaze controls
Smooth state transitions
Rive State Machine
Developer-friendly inputs
.riv delivery
Integration guidance

We define the exact deliverables before starting.

Looking for a Rive Animator?

If you found this article by searching for:

Rive animator

hire Rive animator

Rive animation freelancer

Rive character animator

Rive character rigging

Rive State Machine developer

interactive character animation

Rive mascot animation

Rive lip sync

Rive facial animation

Rive robot animation

Rive AI avatar

then feel free to contact me even if your project isn't a physical robot.

I also work on interactive mascots and characters for apps, websites and AI products.

Building an AI Companion or Robot?

If you searched Google for something like:

AI robot face animation

AI companion animation

AI companion robot face

AI companion character design

AI avatar animation

animated face for AI assistant

robot face animator

robot facial animation

AI robot animator

AI toy animation

AI toy character

AI toy face animation

desktop AI companion

desktop AI robot

AI desktop pet

animated robot display

robot screen face

interactive robot face

AI assistant face

AI assistant character

AI chatbot avatar

AI character lip sync

AI avatar lip sync

TTS lip sync animation

voice assistant animation

Rive AI companion

Rive AI robot

Rive robot face

Rive AI avatar

ESP32 AI companion

ESP32-S3 AI robot

ESP32 animated face

ESP32 robot face

ESP32 AI toy

Raspberry Pi AI companion

Raspberry Pi animated robot face

— then Mascot Engine may be able to help with the character and animation side of your project.

Work With Praneeth Kawya Thathsara

I'm Praneeth Kawya Thathsara, a Rive Animator and Interactive Character Specialist and the founder of Mascot Engine.

My focus is creating characters that aren't simply animations users watch.

They react.

They listen.

They think.

They speak.

They blink.

They look at the user.

They express emotion.

And developers can control those behaviors from the actual product.

Have an AI Robot Idea?

Send me:

A photo, prototype or concept of your AI device
Screen resolution and dimensions
Hardware/platform — ESP32, Raspberry Pi, Android, Linux, Web, etc.
Your existing character artwork, if available
Required states — Idle, Listening, Thinking, Speaking, etc.
Lip-sync requirements
Your approximate budget

I'll review the animation requirements and tell you what kind of setup makes sense.

Contact Mascot Engine

Website: https://mascotengine.com

Email: mascotengine@gmail.com

WhatsApp: +94 71 700 0999

Service: Custom Rive Animation for AI Companions, AI Robots & AI Toys

Default package: Approximately $1,200 USD

Payment structure: $600 to start + $600 after agreed testing and approval

Your AI already knows how to think.

It may already know how to speak.

Now give it a face people can connect with.

Mascot Engine — Interactive Characters for AI Products.

ChatGPT Dots by OpenAI: Building Expressive AI Assistants with Rive Animation

Praneeth Kawya Thathsara — Tue, 29 Sep 2026 20:57:23 +0000

ChatGPT Dots by OpenAI: Building Expressive AI Assistants with Rive Animation

AI assistants can have a great conversational experience and still leave users wondering: is it listening, working, waiting for me, or finished?

OpenAI’s ChatGPT Dots announcement raises an interesting design question for developers building AI products: how should an assistant communicate its activity beyond text?

I’m Praneeth Kawya Thathsara, a character designer and Rive animator behind Mascot Engine. I create interactive mascots and animated faces for AI companion apps, websites, AI toys, and robot screens.

This article explores how an expressive character can support an AI interface—and how to structure its animation so developers can connect it to real application events.

What ChatGPT Dots Suggests About AI Interface Design

In the announcement, OpenAI describes Dots as assistants that learn from feedback, connect with apps, and work toward a user’s goals over time.

That creates more interface states than a simple question-and-answer exchange.

An assistant might be:

Listening to a request.
Processing information.
Working on a task.
Speaking a response.
Waiting for approval.
Reporting completion.
Explaining an error.

For your own AI product, these states need clear visual communication.

An animated face or mascot can complement status messages and controls. Its expression gives users another way to recognize what is happening.

This article discusses independent AI product design. It does not describe a custom mascot integration with ChatGPT Dots.

Start with Product States Before Designing Animations

Before animating a character, define the events your application can reliably detect.

A useful starting point is:

Application state	Character behavior	Supporting interface
Idle	Gentle breathing and occasional blinking	Ready indicator
Listening	Attentive expression	Microphone status
Processing	Subtle focused motion	Processing message
Working	Restrained activity loop	Task progress
Speaking	Audio-responsive mouth movement	Captions or transcript
Awaiting approval	Patient, settled pose	Explicit approval controls
Complete	Brief acknowledgment	Result or completion message
Error	Clear change in expression	Explanation and recovery action

The application should remain the source of truth.

A completion animation should run when the task is actually complete. A listening expression should correspond to the microphone’s real state.

At Mascot Engine, this mapping is part of how I plan interactive AI character animation. It helps turn an attractive character into a useful interface component.

Why Rive Fits This Type of Character Animation

A rendered video plays a predetermined sequence. An interactive character needs to respond to changing inputs.

In Rive, a character can be prepared with animation states and controls that your application drives.

Depending on the project, the animation system might support:

Activity changes.
Independent facial expressions.
Mouth movement.
Gaze direction.
Tap or click reactions.
One-time celebration animations.

The exact implementation depends on your chosen Rive runtime and target platform. Agree on those details before finalizing the animation file.

Separate Activity, Emotion, and Speech

One practical design decision is to keep these controls independent.

Activity describes what the assistant is doing.

Emotion controls its expression.

Speech controls its mouth movement.

For example, your companion may be speaking with a concerned expression. Changing the expression should not stop the mouth from responding to audio.

Likewise, a happy expression should not automatically trigger a speaking animation.

Here is an illustrative control contract you could adapt with your animator:

activity: idle | listening | processing | working | speaking
emotion: neutral | happy | empathetic | concerned | surprised
mouthOpen: 0–1
lookX: -1–1
lookY: -1–1
celebrate: one-time event
reset: one-time event

These are proposed application controls, not reserved Rive names or a universal API. Their names, types, ranges, and mappings should be documented for your specific file.

Keeping responsibilities separate makes it easier to extend the character as your product grows.

Plan Lip Sync Around Your Audio Pipeline

For a speaking AI character, two approaches are worth discussing.

Audio-responsive mouth movement

The application supplies an audio-level value that controls how far the mouth opens.

This can suit a simple robot face or a stylized companion. It communicates speech activity without requiring a detailed set of mouth shapes.

The neutral value should produce a closed or resting mouth.

Viseme-driven mouth shapes

Visemes are visual mouth poses associated with speech sounds.

If your speech pipeline provides suitable timing information, the application can use it to select mouth poses.

This requires an agreed mapping between the speech system and animation file. The developer and animator should document what each value means.

Choose the approach around the product’s needs, available speech data, and character style. More mouth poses are useful only when the application can drive them appropriately.

Design for the Screen Your Character Will Use

A website mascot and a robot-screen face have different constraints.

For a website, consider:

Responsive placement.
Whether the character obscures content.
Pointer and touch interactions.
A way to minimize or dismiss it.
Reduced-motion behavior.

For an AI robot or desktop companion, consider:

Screen dimensions and shape.
Viewing distance.
Circular display boundaries.
Expression readability.
Device performance.
Consistent face positioning across states.

A small robot display may benefit from simple, readable eyes and mouth shapes. A larger companion app can support more detailed character acting.

At Mascot Engine, I work on both custom mascots and animated robot faces, with the design and animation scope shaped around the intended screen.

Make the Animation Handoff Clear

Developers should not have to guess how a character works.

A useful handoff includes:

The exported animation file and agreed editable source.
Artboard and state machine names.
Control names, types, ranges, and default values.
Activity and expression mappings.
One-time event behavior.
Reset and interruption rules.
Layout guidance.
A preview showing expected behavior.

Also discuss how transitions should behave when events arrive quickly.

What happens if the assistant begins speaking while its processing animation is still entering? What happens if the user interrupts speech? What should reset do?

Answering these questions early prevents integration surprises.

Verify the States Users Will Actually Encounter

Review the character inside the application, as well as in the animation editor.

Useful checks include:

Rapid switching between listening, processing, and speaking.
Interrupting an animation before it finishes.
Returning to idle after every activity.
Changing emotion during speech.
Testing the minimum and maximum mouth values.
Confirming that blinking continues where intended.
Checking gaze limits and screen boundaries.
Verifying error and recovery behavior.

Pay particular attention to combinations of controls. A character can look correct in individual previews but behave differently when activity, emotion, and speech inputs change together.

Building an AI Assistant? Give Its Character a Clear Role

ChatGPT Dots by OpenAI offers a useful starting point for thinking about ongoing interactions with AI.

For developers building their own assistants, an expressive character is one possible way to make those interactions more recognizable.

The strongest animation choices serve the product: attentive movement while listening, readable speech behavior, and clear acknowledgment when something changes.

If you need a Rive animator for an AI companion, interactive website mascot, AI toy, or robot face, I can help through Mascot Engine.

My work includes:

Custom character design and preparation.
Rive rigging and animation.
Expressions and activity states.
Audio-responsive mouth animation and viseme poses.
Eye and cursor tracking.
State machines and documented animation controls.

Send me your product idea, existing artwork if you have it, target platform, required states, timeline, and budget. We can define a practical first milestone.

Website: MascotEngine.com

WhatsApp: Discuss your AI character project

Your AI has a voice. Let’s give it a face.

Written by Praneeth Kawya Thathsara, creator of Mascot Engine. This is an independent article. Mascot Engine is not affiliated with or endorsed by OpenAI.

Hire a Rive Animator for AI Toy & Robot Face Animation

Praneeth Kawya Thathsara — Mon, 28 Sep 2026 17:47:26 +0000

Building an AI toy, a desktop companion, or a robot with a screen-based face? You’ll need expressions that communicate what the product is doing—and animation controls your developers can connect to its behavior.

I’m Praneeth Kawya Thathsara, a Rive animator, mascot and character designer, and founder of Mascot Engine.

I help teams design and animate interactive characters, including expressive faces for AI companions and compatible device displays. My work covers character design, rigging, facial animation, state machines, and developer handoff.

Looking to hire a Rive animator? Send me your idea on WhatsApp. Tell me what the face should show, your target platform, and your approximate budget.

What can a Rive animator create for your robot?

The animation scope should follow the interactions your product needs.

A voice companion might need to acknowledge a question, show that it is processing, and speak with coordinated mouth movement. A desktop robot might also need touch reactions, idle behavior, and expressive eyes.

Here are some possible deliverables:

Feature	What it communicates
Idle animation	The character is ready and available
Blinking	Subtle life without constant movement
Listening expression	The system is receiving user input
Thinking animation	A response is being prepared
Speaking animation	The character is delivering a response
Emotional expressions	Happiness, curiosity, encouragement, or concern
Gaze controls	The eyes look toward a supplied position
Error and connection states	The interaction needs attention
Sleep and wake transitions	The device is resting or becoming active

You do not need every feature in the first version. A useful first milestone focuses on the states required for your core interaction.

Define the face before building the animation library

A robot face can be as simple as two expressive eyes or as detailed as a complete character.

Before rigging begins, decide:

Will the face have a mouth?
Are eyebrows important to its personality?
Will it appear on a rectangular or circular display?
How small will it be viewed?
Should its personality feel playful, calm, curious, or professional?
Which expressions must remain clear at the actual display size?

A design that looks appealing in a large illustration may need adjustments for a small screen. Fine details, subtle mouth shapes, and low-contrast features should be reviewed at the intended size.

If you already have artwork, it can be assessed for animation preparation. If you only have an idea, the character design can be part of the project.

Agree on how the application will control the face

Your developers and animator should agree on a control contract early.

For example, a project might need the following conceptual controls:

Control	Purpose
Activity	Select idle, listening, thinking, speaking, or sleeping
Emotion	Select an expression independently of activity where supported
Mouth opening	Adjust how far the mouth opens
Viseme	Select a speech-related mouth shape
Gaze X / Y	Supply horizontal and vertical look direction
Reaction event	Play a short acknowledgement or celebration

These are planning examples, not required Rive property names or a universal API. The actual controls depend on the rig, runtime, and integration approach.

The handoff should document each control’s name, type, accepted values, default, and expected behavior. If both mouth-opening and viseme controls exist, their priority or switching behavior should also be clear.

This agreement helps avoid a situation where the animation looks correct in the editor but behaves differently in the application.

Choose the right lip-sync scope

“Make the robot talk” can describe several different requirements.

A talking loop

A repeating mouth animation can work for an early demonstration. It starts and stops with the speaking state, but it does not match the actual speech.

Audio-driven mouth opening

The application supplies a value derived from the speech audio level. The animation uses that value to control mouth opening.

This approach can suit simple robot faces. It should include appropriate smoothing and reliable mouth closure during silence.

Viseme-based lip sync

The speech system supplies timed mouth-shape information. The animation maps those values to corresponding shapes.

This can support more articulated speech, but it requires compatible timing data and coordination with the developer.

When requesting a quote, explain which approach you need and what data your speech system can provide. That information changes the animation and integration scope.

What working with Mascot Engine can include

At Mascot Engine, I help founders and development teams turn character ideas into interactive animation assets.

Depending on the agreed scope, I can help with:

Custom mascot or robot face design.
Artwork cleanup and preparation.
2D character rigging.
Facial expressions, blinking, and gaze animation.
Listening, thinking, speaking, and idle states.
Lip-sync controls.
Rive state-machine setup.
Exported animation files and developer documentation.
Refinement based on integration feedback.

If you want to work with Praneeth Kawya Thathsara on your AI toy or robot face, share your brief on WhatsApp.

You can send existing artwork, a reference video, a sketch, or a short description of the product.

Check hardware compatibility before committing to production

Rive provides runtimes for several platforms, but a display-equipped device is not automatically compatible.

Before planning the full animation library, confirm:

Device hardware and operating system.
Application framework and available rendering environment.
Screen resolution, orientation, and crop.
Memory and graphics constraints.
The runtime and features your developers intend to use.

A small prototype on the target hardware is a useful first step. It lets the team assess rendering, behavior, and performance before expanding the project.

The animation scope should also be distinguished from the surrounding engineering work. Conversation AI, speech generation, microphone processing, camera tracking, and motor control require their own implementation.

For a relevant real-world example, Rive’s MIRA case study describes an AI robot installation that used Rive to animate facial emotions and manage transitions.

Ask for transition testing

Individual expressions are only part of the work. The character also needs to move between states predictably.

Useful review scenarios include:

Listening changes to thinking.
Thinking changes directly to speaking.
A user interrupts speech.
Audio stops and the mouth closes.
Emotion changes during speech.
A connection error interrupts the current activity.
The character returns to idle after recovery.
Repeated events arrive before the previous reaction finishes.

For each scenario, agree on the expected result.

This makes feedback more actionable than simply saying that an animation “feels wrong.” It also helps identify whether an issue comes from the animation logic, application timing, or supplied values.

What affects the project cost?

An accurate quote depends on the work involved.

Common factors include:

Whether the character already exists.
The condition and format of the source artwork.
Rig complexity.
Number of states and expressions.
Lip-sync requirements.
Independent emotion and gaze controls.
Character variants or accessories.
Hardware testing and integration support.
Revision scope and delivery timeline.

A simple eyes-only face with a few states will have a different scope from a full character with articulated speech, independent emotions, and multiple variations.

Share your approximate budget early. We can discuss the essential first milestone and which features could follow later.

A brief you can copy

You can use this template when contacting me:

Product idea:

What does your AI toy or robot do?

Target users:

Who will interact with it?

Device and platform:

What hardware, operating system, and framework are you using?

Display:

Resolution, orientation, and any circular crop.

Character artwork:

Existing artwork, references, or a new design needed.

Required behavior:

What should the face show while idle, listening, thinking, speaking, or encountering an error?

Speech integration:

Talking loop, audio-driven mouth movement, or timed viseme data?

Budget:

Your approximate range.

Timeline:

When do you need the first prototype or delivery?

It is fine to leave technical details open if you have not decided them yet. We can identify what needs clarification before production.

Let’s discuss your AI toy or robot face

I’m Praneeth Kawya Thathsara, founder of Mascot Engine.

If you need a Rive animator to help create an expressive, interactive face, tell me about your project:

What is your AI robot idea? What should its face show? What budget are you working with?

I’ll review the details, explain where I can support you, and help define a practical animation scope and next steps.

Website: mascotengine.com
WhatsApp: +94 71 700 0999
Email: mascotengine@gmail.com

Message Praneeth on WhatsApp to discuss your project.

Give Your AI Robot a Face: Custom Expressions, Blinking & Lip Sync

Praneeth Kawya Thathsara — Mon, 28 Sep 2026 17:32:01 +0000

Your AI robot can answer a question. Its face can help people understand when it is listening, processing, or ready to speak.

I’m Praneeth Kawya Thathsara, a mascot and character designer, Rive animator, and founder of Mascot Engine. I help teams create expressive, interactive characters for apps, websites, AI companions, and compatible device displays.

If you’re building an AI toy, desktop companion, or robot with a screen-based face, I can help you design and animate its visual personality.

Have an idea already? Tell me about it on WhatsApp.

Start with what the face needs to communicate

Before choosing eye shapes or drawing a smile, list the moments users need to understand.

Is the robot waiting for someone to speak? Did it hear the request? Is it processing an answer? Has the connection failed?

Each moment can have a distinct visual response:

Product state	Possible face animation
Ready / idle	Gentle blinking and occasional gaze changes
Listening	Attentive eyes and restrained movement
Thinking	A subtle repeating expression or processing gesture
Speaking	Mouth movement synchronized with speech
Success	A smile or short celebration
Error / disconnected	A clear, calm expression indicating a problem
Sleeping	Closed eyes and reduced movement

These are starting points. The right reactions depend on your product’s purpose, audience, and character.

A learning companion may need encouragement after an incorrect answer. A desktop assistant may need a clear acknowledgement when someone activates it.

Give the character a consistent personality

A face can be simple and still feel expressive.

Two eyes, eyebrows, and a mouth can communicate a useful range of reactions when their shapes, timing, and movement work together.

For each expression, consider:

How much should the eyes change shape?
Do the eyebrows carry most of the emotion?
Should the mouth remain expressive while speaking?
How quickly should the character react?
How does it return to a neutral expression?

The same character should remain recognizable when happy, curious, surprised, or concerned. Designing those expressions together helps maintain that consistency.

Make blinking and gaze feel intentional

Blinking gives a screen-based character a sense of life, but timing matters.

An identical blink repeated at a fixed interval can become noticeable. A more natural approach can vary the intervals within a controlled range and adjust the behavior for different activities.

Gaze can also communicate attention:

Looking toward a touch point.
Following a cursor in a web demo.
Glancing around occasionally while idle.
Returning to a neutral position after an interaction.

For camera-based tracking, the device software needs to detect the target and send position values to the animation. The face animation uses those values to move the eyes; it does not provide the camera-tracking system by itself.

Choose the right lip-sync approach

There are several ways to make a character appear to speak.

Audio-driven mouth opening

The software measures the speech audio level and uses it to control how far the mouth opens.

This can suit simple robot faces and stylized characters. It needs smoothing and sensible limits so the mouth does not jitter or remain open during silence.

Viseme-based mouth shapes

Visemes are visual mouth shapes associated with speech sounds.

If your speech system provides timed viseme data, the animation can switch or blend between matching mouth shapes. This offers more articulation than controlling mouth opening alone.

It also requires coordination between the speech system, timing data, and animation controls.

A repeating talking animation

A talking loop may be enough for an early prototype or a character without a detailed mouth.

However, a repeating loop is not synchronized lip sync. Choose it when that simpler behavior fits the experience.

How Rive fits into the project

Rive can be used to design and animate the face, build interactive behavior, and expose controls for the application.

Your device software supplies information such as:

The current activity.
The selected emotion.
Mouth opening or viseme values.
Gaze direction.
Events such as a completed task or a lost connection.

The Rive animation responds through state machines and, where supported by the chosen runtime, data binding.

At Mascot Engine, I help teams turn these requirements into character artwork, rigs, expressions, animations, and documented controls.

If you need a Rive animator for your robot face, contact Praneeth Kawya Thathsara to discuss the character and animation scope.

Keep activity and emotion separate where needed

A companion may need to speak while looking happy, concerned, or encouraging.

If every combination becomes a separate full animation, the project can become difficult to maintain. A useful design approach is to plan activity, emotion, mouth movement, and gaze as controls that can work together where the rig allows it.

For example:

Activity: Speaking.
Emotion: Encouraging.
Mouth: Driven by speech data.
Gaze: Directed toward the user.

This needs careful layering and testing. An expression change should not accidentally stop the mouth, hide the eyes, or interrupt an important transition.

Test interruptions, not just individual animations

A face can look good when each animation plays alone and still behave incorrectly in the product.

Test what happens when:

Speaking is interrupted by a new request.
Listening changes directly to thinking.
The connection drops during a response.
An emotion changes while the mouth is moving.
The device wakes from sleep.
The same event arrives more than once.

Also check that the character returns to a complete, visible neutral face after every relevant transition.

These checks help developers integrate an animation system they can predict and control.

Check the target hardware early

A screen alone does not guarantee that a device can run Rive.

The operating system, runtime, renderer, memory, and graphics capabilities all affect the integration approach. A browser-based prototype and a small embedded display may need very different implementations.

Before committing to the full animation set, share:

The device hardware and operating system.
The application framework or rendering environment.
Screen resolution, orientation, and any circular crop.
Performance and memory constraints.
Your developer’s preferred integration approach.

A small prototype on the actual device is a useful first milestone.

Rive handles the visual animation layer. Conversation AI, speech generation, microphone processing, camera tracking, and motor control require their own systems and connections.

For a real-world reference, Rive’s MIRA robot case study describes how an AI robot installation used Rive to animate facial emotions and control transitions between them.

What to include in your animation brief

You do not need a finished technical specification to start the conversation.

Send a short description covering:

Your idea: What does the AI toy or robot do?
Its face: Eyes only, eyes and mouth, or a complete character?
Required reactions: What should it show when listening, thinking, speaking, or encountering an error?
Existing artwork: Do you have a design or reference images?
The platform: What hardware and software will display the animation?
Your budget and timeline: What can you allocate, and when do you need the first version?

If the budget is limited, we can discuss which states belong in the first milestone and which can be added later.

Let’s give your AI robot a face

I’m Praneeth Kawya Thathsara, founder of Mascot Engine.

I can help with custom character design, 2D rigging, facial expressions, blinking, gaze animation, lip-sync controls, Rive state machines, and developer handoff. The final deliverables depend on your project and target platform.

Tell me your AI robot idea, what you want its face to show, and your approximate budget.

Whether you have a rough sketch, existing artwork, or an early prototype, I’ll review it, explain where I can support you, and help define practical next steps.

Portfolio: mascotengine.com
WhatsApp: +94 71 700 0999
Contact: Praneeth Kawya Thathsara

Message me on WhatsApp to discuss your robot face animation.

Building an AI Web App? Get a Custom Rive Avatar for Your AI Assistant

Praneeth Kawya Thathsara — Sat, 19 Sep 2026 21:05:11 +0000

Your AI assistant can answer questions and speak. What should users see while they interact with it?

For an AI tutor, voice assistant, or companion app, a custom animated avatar can communicate when the app is listening, preparing a response, or speaking.

But creating that character introduces another set of tasks: illustration, rigging, expressions, mouth movement, animation transitions, and developer controls.

That is the work I help teams with at Mascot Engine.

I’m Praneeth, a Rive animator creating custom interactive mascots and AI avatar animations for web and mobile products.

Building an AI web app that needs an animated character?

Explore Mascot Engine and send me your app screenshot, platform, and avatar requirements.

📧 mascotengine@gmail.com

💬 WhatsApp: +94 71 700 0999

Your app handles the conversation. The avatar shows its state.

Imagine a language-learning app with an AI tutor.

When the learner speaks, the character looks attentive. While the app prepares a response, the character moves into a subtle thinking animation. When response audio starts playing, its mouth moves with the speech.

These behaviours need a clear connection to the application.

What happens in your app	What the avatar could do
The session becomes available	Settle into a friendly idle
The app accepts microphone input	Show an attentive listening expression
A response is being prepared	Play a restrained thinking animation
Response audio plays	Animate the mouth and speaking expression
The learner completes a task	Play a short celebration
A connection fails	Show a calm error reaction

This is an example brief, not a fixed feature package. The right states depend on your product.

The important design decision is to make the avatar reflect what the app is actually doing.

Why use Rive for an interactive AI avatar?

Rive state machines let you connect animations and define the logic for transitions between them. Your character can have different behaviours instead of playing the same animation continuously.

See the official Rive state machine documentation.

Rive also provides runtimes for web, React, Flutter, React Native, and other platforms. Feature support varies by runtime and renderer, so the implementation should be planned around your actual stack.

See the Rive runtime guide.

For a web developer, the goal is an animation asset with clearly documented controls that can be connected to application events.

What can you commission from Mascot Engine?

At Mascot Engine, I provide custom Rive character animation services scoped around your product.

Character design and preparation

Already have a mascot illustration? I can assess how it should be prepared for animation.

Starting with an idea? We can define a character direction around your interface, audience, and brand.

The design should remain readable at its actual display size—not only in a large portfolio preview.

2D rigging and expressions

A character rig makes it possible to animate the face and body consistently.

Depending on the design, the scope can include eyes, eyebrows, mouth shapes, head movement, and gestures.

Activity animations and transitions

We define the behaviours your app needs and how the character moves between them.

For example:

Idle to listening.
Listening to thinking.
Thinking to speaking.
Speaking back to listening after an interruption.
Any relevant activity to an error or fallback state.

The transitions deserve attention alongside the individual animations.

Lip-sync controls

A repeating talking loop, audio-driven mouth opening, and viseme-based animation are different deliverables.

We agree on the approach before production, including what data your application will provide.

Developer handoff

The agreed deliverables can include the exported .riv file, animation controls, state mappings, and implementation notes.

The purpose is to give your developer a clear specification for operating the character.

Start with the avatar your first release needs

You do not need to define every future expression before discussing a project.

For an initial voice-based web app, I would consider:

A calm idle.
An attentive listening state.
A subtle thinking state.
A speaking state with the agreed mouth controls.
An error or fallback reaction.

Additional expressions, celebrations, outfits, or growth stages can be scoped separately when they support the product.

Need help turning your app idea into an animation brief?

Contact Mascot Engine with your app link or screenshot, existing artwork, and the interactions you need.

📧 mascotengine@gmail.com

💬 WhatsApp: +94 71 700 0999

What stays in your application?

A custom avatar needs a clear division of responsibilities.

Animation scope	Application integration
Character artwork and rig	AI model and conversation logic
Expressions and animated states	Microphone permissions and input
Authored mouth shapes and controls	Audio playback and timing signals
Animation transition logic	Network status and request handling
Documented character controls	Connecting app events to those controls

The final split should be agreed for your project.

For example, an animator can author a mouth-opening control. Your application still needs to supply values that correspond to the character’s speech audio.

Rive data binding can connect application-controlled data to properties in the character scene. The exact View Model structure and property names should be documented for the authored file.

See the Rive data binding overview.

Make the lip-sync requirement specific

For a simple stylized character, audio-driven mouth opening may be a suitable starting point.

An example specification could define:

0 as a closed mouth.
0.5 as a medium opening.
1 as the maximum designed opening.

Those values are an example contract, not a universal Rive API.

Your implementation also needs to handle silence, smoothing, playback timing, and interruption.

If you need distinct mouth shapes for speech sounds, discuss a viseme-based system. That requires an agreed shape mapping and suitable timing data from your speech pipeline or analysis layer.

A useful project brief describes the expected result, not just “add lip sync.”

What should be checked before launch?

Test the character inside the real interface.

A few important checks:

[ ] The mouth closes during silence.
[ ] Speaking starts with audio playback.
[ ] Interrupting playback stops mouth movement.
[ ] The listening state matches actual microphone availability.
[ ] Rapid state changes do not leave the avatar stuck.
[ ] Expressions remain readable on smaller screens.
[ ] Status text remains available alongside visual reactions.
[ ] Reduced-motion behaviour is defined.
[ ] Performance is acceptable on target devices.

Agree on who handles each check and how integration feedback will be addressed.

How to request a custom Rive avatar quote

The most useful starting point is a short product brief.

Send:

Your app: a link, screenshot, or short explanation.
Your stack: React, another web framework, or a different platform.
Your character: existing artwork or visual references.
Required behaviours: listening, thinking, speaking, rewards, or other reactions.
Voice setup: how speech is generated and played, if already decided.
Timeline and budget: your target launch date and budget range.

The quote can then account for design complexity, rigging, animation states, lip-sync requirements, transitions, and handoff scope.

Bring your AI avatar idea to Mascot Engine

If you are looking to hire a Rive animator for an AI web app, Mascot Engine is my studio for custom interactive character animation.

I work with founders, developers, and product teams that need a character designed and animated around their application.

Whether you have finished mascot artwork or an early product concept, we can discuss the behaviours your avatar needs and define the animation scope.

Let’s give your AI a face.

🌐 Explore my work: MascotEngine.com

📧 Email your brief: mascotengine@gmail.com

💬 WhatsApp: +94 71 700 0999

Send your app screenshot, platform, and required avatar states to discuss a project quote.

Developers: what are you building, and what would you want your AI avatar to do first?

How to Build an AI Companion That Listens, Thinks, Speaks, and Reacts in Real Time

Praneeth Kawya Thathsara — Thu, 17 Sep 2026 18:57:44 +0000

AI assistants are becoming more capable every year.

They can understand speech, generate natural responses, remember context, analyze user intent, and communicate using realistic voices.

But there is still one major problem:

Most AI products have no visible personality.

A user speaks.

The system processes the request.

A voice answers.

But visually, there may be nothing more than a waveform, glowing orb, loading spinner, or static avatar.

For many products, that is a missed opportunity.

A well-designed interactive mascot can become the visual personality layer between the AI system and the user.

Instead of simply showing that an AI is “loading,” a character can visibly:

listen
think
speak
react
celebrate
show empathy
recover from errors
fall asleep when inactive
follow the user's cursor or touch position

This article explains how I approach building these systems using Rive, State Machines, runtime inputs, lip sync, and AI application events.

If you are building an AI assistant, AI tutor, voice companion, SaaS copilot, or conversational application, this architecture can be used to turn a static mascot into a real product interface.

The Important Shift: Stop Thinking About Animation Clips

The first mistake is treating an AI character as a collection of animations.

For example:

idle.riv
thinking.riv
talking.riv
happy.riv
error.riv

That can work for simple projects, but it quickly becomes difficult to maintain.

A better approach is to think of the mascot as a small visual system controlled by the application.

The application already knows what the AI is doing.

For example:

User is speaking
AI is processing
AI is responding
Connection failed
Answer was correct
User has been inactive

The animation system should receive these events and visually represent them.

This means the mascot becomes part of the application logic rather than an animation playing on top of the UI.

This is also the approach we focus on at Mascot Engine, where interactive Rive mascots are prepared around real product events, AI responses, runtime inputs, and developer handoff.

Mascot Engine:
https://mascotengine.com

A Simple AI Companion Architecture

A production-ready AI character does not necessarily need dozens of separate controls.

You can build a surprisingly flexible system using a few well-planned inputs.

For example:

activity
emotion
viseme
audioLevel
lookX
lookY
blink

Let's break these down.

1. Activity State

The first input controls what the AI is currently doing.

For example:

activity = 0  // Idle
activity = 1  // Listening
activity = 2  // Thinking
activity = 3  // Speaking
activity = 4  // Connecting
activity = 5  // Error
activity = 6  // Sleeping

Now the application can control the character using its actual internal state.

Example flow:

User starts speaking
        ↓
activity = 1

User finishes speaking
        ↓
activity = 2

LLM begins generating the response
        ↓
activity = 3

Response finishes
        ↓
activity = 0

The mascot is no longer guessing what should happen.

It is simply visualizing the state of the application.

2. Emotion Should Be Independent

Activity and emotion should usually be separated.

Why?

Because an AI can be speaking while happy, concerned, empathetic, surprised, or neutral.

For example:

emotion = 0  // Neutral
emotion = 1  // Happy
emotion = 2  // Empathetic
emotion = 3  // Concerned
emotion = 4  // Surprised

Now we can combine states.

activity = speaking
emotion = happy

or:

activity = speaking
emotion = concerned

This dramatically reduces the number of animations that need to be created.

Instead of manually creating:

happy-speaking
sad-speaking
concerned-speaking
surprised-speaking
happy-listening
concerned-listening
...

the system can layer reusable behaviors.

This modular approach is one reason State Machines work particularly well for interactive characters.

Rive has also demonstrated this idea in real AI-character use cases. For Duolingo's AI-powered Video Call experience, modular animation and State Machine blending were used to help Lily listen, process, and react dynamically rather than relying on a huge library of pre-baked reactions.

3. Listening State

Listening should communicate:

“I am paying attention to you.”

It does not need to be dramatic.

Subtle behaviors often work better.

For example:

slightly leaning forward
focusing the eyes
reducing random idle movement
occasional blinking
subtle head movement
reacting slightly to microphone activity

The important point is that the user should immediately understand that the system is receiving input.

4. Thinking State

Thinking is one of the most important AI states because latency becomes much easier to tolerate when the interface acknowledges it.

Instead of freezing the character, the mascot can:

look upward
glance sideways
move its eyes slowly
change posture
perform a subtle thinking loop

The goal is not to fake intelligence.

The goal is to clearly communicate:

“Your request was received and the system is processing it.”

5. Speaking State

Speaking should not simply mean playing a looping mouth animation.

There are multiple levels of implementation.

Level 1 — Basic talking animation

isTalking = true

A mouth animation loops while speech is active.

Simple and lightweight.

Level 2 — Audio-driven mouth movement

The application sends something like:

audioLevel = 0.0 → 1.0

The mouth responds to audio amplitude.

For example:

0.0 = closed
0.3 = slightly open
0.7 = open
1.0 = fully open

This is much more convincing than a random speaking loop.

Level 3 — Viseme Lip Sync

For more advanced AI voice products, the application can provide phoneme or viseme information.

For example:

viseme = 0
viseme = 1
viseme = 2
...
viseme = 9

Each value represents a mouth shape.

The result can feel significantly more natural.

Recent Rive character examples also demonstrate layered State Machine systems with visemes, expressions, triggers, and speech-driven lip sync inside a single interactive character file.

At Mascot Engine, this is one of the systems we can prepare for AI and TTS-driven products:

https://mascotengine.com

6. Interactive Eye Tracking

Another relatively small feature can make a huge difference:

lookX = -1 → 1
lookY = -1 → 1

These values can be connected to:

cursor position
touch position
camera direction
product UI events
predefined conversational behaviors

Example:

lookX = -1

Character looks left.

lookX = 1

Character looks right.

lookX = 0
lookY = 0

Character returns to the center.

A subtle gaze system can make the character feel much more aware of the interface around it.

Mascot Engine uses similar runtime-ready controls for interactive gaze, AI states, product reactions, and other app-driven behaviors.

7. Success, Failure, and Product Events

Do not make the mascot respond only to the AI conversation.

It can also respond to product events.

For example:

answerCorrect
answerIncorrect
goalCompleted
paymentSuccessful
streakReached
levelUp
connectionLost
retry

This becomes especially useful for:

AI education apps
habit trackers
health applications
fintech products
productivity apps
onboarding experiences
gamified SaaS products

Imagine an AI learning app.

Student answers correctly
       ↓
success trigger
       ↓
Mascot celebrates

The character is now reinforcing the product experience.

8. What About Inactivity?

AI companions can also respond when nothing is happening.

For example:

0–5 minutes
Idle

5–10 minutes
Bored / relaxed

10+ minutes
Sleeping

When the user returns:

wake trigger
      ↓
wake animation
      ↓
idle

These small details make a character feel much more persistent.

9. Build One State Machine, Not 30 Disconnected Animations

A simplified architecture might look like:

                 ┌─────────────┐
                 │    IDLE     │
                 └──────┬──────┘
                        │
         ┌──────────────┼──────────────┐
         ↓              ↓              ↓
     LISTENING       THINKING        ERROR
         │              │
         └──────────┬───┘
                    ↓
                 SPEAKING
                    │
                    ↓
                   IDLE

Then emotion, blinking, gaze, and mouth behavior can operate as additional layers.

This creates a much cleaner system than manually triggering unrelated clips.

10. Example Runtime Contract

Before handing the animation to developers, I like to define a simple contract.

For example:

Artboard:
AI_Companion

State Machine:
CompanionController

Inputs:

activity
Number
0–6

emotion
Number
0–4

viseme
Number
0–9

audioLevel
Number
0–1

lookX
Number
-1–1

lookY
Number
-1–1

blink
Trigger

Then document exactly what every input means.

This sounds simple, but it prevents a huge number of integration problems.

11. Example AI Event Mapping

The development team can then map existing application events to the character.

Conceptually:

onUserSpeechStarted(() => {
  activity = 1;
});

onUserSpeechEnded(() => {
  activity = 2;
});

onAIResponseStarted(() => {
  activity = 3;
});

onAIResponseFinished(() => {
  activity = 0;
});

onConnectionError(() => {
  activity = 5;
});

The exact implementation depends on your framework and AI architecture.

But the animation contract stays predictable.

That is the important part.

12. Where the AI Fits

The mascot itself does not need to contain the AI.

Think of it as three separate layers:

AI / LLM
     ↓
Application Logic
     ↓
Rive Character

The LLM decides what to say.

Your application manages the conversation.

Rive visualizes what is happening.

This separation makes the system easier to maintain.

13. What About AI-Generated Emotion?

You can take this one step further.

Suppose the AI returns structured metadata alongside its response.

Conceptually:

{
  "response": "You did really well today.",
  "emotion": "happy"
}

Your application maps:

happy → emotion = 1

Then the mascot speaks using the correct facial expression.

You could use the same idea for:

neutral
happy
empathetic
concerned
surprised

The important rule is to keep the animation interface simple.

Do not expose dozens of animation controls to the LLM if five stable states will achieve the same result.

14. Where This Architecture Works Well

I especially like this approach for:

AI Tutors

The character can listen, think, explain answers, celebrate correct responses, and react to mistakes.

AI Companions

A persistent character can visually communicate emotion and conversation state.

Voice Assistants

Listening, processing, speaking, interruption, and connection states become visible.

SaaS Copilots

A mascot can guide onboarding and respond to product events.

Kids' AI Products

Visual communication can make abstract system states easier to understand.

Health and Wellness Apps

A calm companion can communicate support and progress without overwhelming the UI.

Productivity Apps

The mascot can react to goals, focus sessions, completion, streaks, and inactivity.

15. Why Rive Works Well for This

There are several reasons I use Rive for these projects.

Runtime control

The application can control inputs while the character is running.

State Machines

Complex transitions can be kept inside the animation system.

Reusable rigs

The same character foundation can support many behaviors.

Interactive animation

The mascot can react to product data rather than simply playing videos.

Web and app workflows

The same animation concept can be prepared for modern product environments.

Rive's own marketplace increasingly includes production-oriented mascot examples built around State Machines, expressions, interactive controls, cursor tracking, data binding, and AI-like listening/thinking states.

16. The Developer Handoff Matters as Much as the Animation

A beautiful character that developers cannot integrate easily is not production-ready.

A good delivery should clearly define:

.riv source
artboard names
State Machine names
input names
input types
number ranges
event mappings
default values
fallback behavior
responsive behavior

Depending on the project, it can also include:

PNG stills
editable source
Flutter guidance
React Native guidance
Web guidance
test implementation

At Mascot Engine, the focus is specifically on this kind of production-ready Rive mascot system rather than only delivering isolated animation loops.

17. A Practical Minimum Viable AI Companion

You do not need 50 animations for version one.

A strong MVP could contain:

Idle
Listening
Thinking
Speaking
Happy
Concerned
Error
Sleeping
Blink

plus:

audioLevel
lookX
lookY

That is already enough to create a surprisingly expressive AI interface.

You can always expand it later.

18. The Bigger Idea

The interesting opportunity is not simply adding animation to AI.

It is giving the AI system a consistent visual behavior layer.

The AI already has:

intelligence
memory
voice
context

The mascot provides:

presence
expression
feedback
personality
visual state communication

That is why I believe interactive characters will become increasingly useful inside AI products.

The goal is not to put a cartoon character everywhere.

The goal is to use a character where human-like visual feedback improves the product experience.

Need an AI Companion or Interactive Rive Mascot?

I run Mascot Engine, a studio focused on production-ready interactive Rive characters for:

AI assistants
AI companions
AI tutors
SaaS products
mobile apps
web applications
conversational interfaces

Projects can include:

character preparation
Rive rigging
idle / listening / thinking / speaking states
interactive State Machines
emotion systems
eye tracking
audio-driven mouth animation
viseme lip sync
product-event reactions
editable Rive files
developer handoff
Flutter, React Native, and web preparation

You can see live interactive mascot examples and technical details here:

👉 https://mascotengine.com

If you are building an AI product and already have a mascot, UI prototype, character sketch, or even only an idea, you can send the product brief and required behaviors to Mascot Engine to plan the animation architecture before development.

Do not ask:

“What animation should the mascot play?”

Instead ask:

“What does the application know right now, and how should the character visually communicate that state?”

That small change turns a mascot from decoration into part of the product.

Rive #AI #Animation #WebDevelopment #AppDevelopment #GenerativeAI #ArtificialIntelligence #SaaS #Flutter #ReactNative #UX #UIUX #CharacterAnimation #AIAssistant #AICompanion

How to Brief an Interactive App Mascot: A Founder’s Rive Checklist

Praneeth Kawya Thathsara — Wed, 09 Sep 2026 17:34:48 +0000

“We need a friendly mascot for our app” is a good starting point for a conversation. It is not yet a brief that an animator and developer can estimate reliably.

Two characters can look equally simple in a screenshot and require very different systems. One might wave once during onboarding. Another might listen, think, speak, follow gaze targets, recover from an interrupted request, and run inside three different applications.

The difference is behavior, data, and delivery scope. Describe those early and you give the project a much better chance of arriving in a form your team can use.

This guide is for founders, product designers, and engineering leads commissioning an interactive Rive mascot or AI companion. It includes a copyable project brief and explains which decisions belong in it. The examples are fictional scoping examples, not claims about client work or fixed market prices.

Start with the product job

Before choosing expressions or colors, describe what the character helps the user understand or do.

An onboarding guide might explain progress and acknowledge completed steps. A support assistant might show whether it is listening or waiting for an answer. A learning companion might react to an exercise result without distracting from the lesson.

Write one sentence that connects the character to a user task. For example: “The mascot helps users understand whether their voice request is being captured, processed, or answered.”

Then name the screen or flow where that happens. A small companion beside a text field has different visual constraints from a full-screen character during a welcome sequence.

Avoid making engagement or conversion promises part of the animation specification unless you have a plan to measure them. The deliverable can communicate a state clearly; the effect on broader product metrics needs evidence from your product.

Describe one complete user journey

A list of states is useful, but a sequence reveals the transitions and interruptions between them.

Describe what happens from the user’s first action to the end of the interaction. Include one ordinary failure. For a voice assistant, the sequence might be: tap microphone, speak, wait, hear a response, interrupt, and retry after a network error.

That journey answers questions a mood board cannot. Does speaking stop immediately? Does a success gesture block the next action? What remains visible while the service is unavailable?

Keep the character’s role separate from the application’s role. Your app decides that a request succeeded. The character communicates the decision through animation.

If the character can initiate an action when tapped, specify what that tap requests and which application component handles it. A visual interaction is not automatically a completed business operation.

List states by meaning, not by personality

Words like playful, calm, or confident help art direction. They do not define a State Machine.

Give each state a product meaning and an exit condition. For example:

State	Meaning	What ends it?
Idle	Ready for interaction	User begins a task
Listening	Audio capture is active	Capture stops or fails
Thinking	Waiting for the next result	Answer, cancellation, or error
Speaking	Output audio is playing	Playback ends or is interrupted
Success	Requested operation completed	Short acknowledgement finishes
Unavailable	Interaction cannot proceed	Retry or return to a usable state

These are example states, not a requirement for every mascot. A simple onboarding character may need fewer. A complex companion may need additional behavior.

Rive’s State Machine overview explains how animation states and transitions form an interactive system. Your brief should supply the product meaning that the designer maps into that system.

Separate activity, expression, and attention

You may want the character to speak warmly, wait calmly, and look toward a relevant interface element. Those behaviors do not all need to become separate primary states.

Describe activity, emotion, and gaze as distinct concerns. This helps the specialist propose a manageable rig and control interface instead of multiplying every combination into another animation.

Specify whether gaze follows a pointer, a tap target, or application events. It does not require a camera unless you explicitly want camera-based tracking and have planned that separate feature.

Also describe the intensity of expression at the actual display size. A dramatic full-body reaction may work on a welcome screen but feel excessive beside a form field.

Ask to review the character in a realistic product frame early. A beautiful standalone animation can still be the wrong size, contrast, or energy for its intended interface.

Say what artwork already exists

Share the current source assets and explain what must remain recognizable: silhouette, proportions, palette, facial style, or accessories.

Mention whether the artwork is editable vector art, a layered illustration, a flat image, or only a concept reference. These starting points require different preparation before rigging.

If the character needs body turns, mouth poses, or expressions that are not visible in the original artwork, include that requirement. A single front-view image does not define every pose automatically.

Clarify which references are for style and which are actual assets you are entitled to use. The brief should not leave the specialist guessing whether a reference character must be copied or merely communicates a general direction.

Include ownership and editable-source delivery in the scope rather than waiting until the final export arrives.

Name every target platform

“Mobile and web” leaves important details unresolved. Specify Web, Flutter, React Native, or native platforms, and include the versions your developers already use when available.

Rive provides runtimes for multiple environments, but feature support and renderer choices can differ. Its runtime introduction is a useful reference for planning compatibility.

List where the mascot appears and how many instances may be visible simultaneously. A single assistant panel and a scrolling collection of animated cards are different integration tasks.

Mention offline requirements and asset delivery preferences. A bundled file, a remotely hosted file, and a remotely updated character system involve different release decisions.

You do not need to know every technical answer before contacting a specialist. Mark unknowns honestly and identify the developer who can resolve them during scoping.

Need an interactive Rive character for your product? Mascot Engine creates app mascots, AI companions, State Machines, lip sync, and developer-ready Rive systems for Web, Flutter, and React Native. View live work and request an estimate, or send your project brief on WhatsApp.

Define speaking requirements before requesting lip sync

“The character should talk” can mean several different deliverables.

A repeating talking animation can signal activity. An audio-level-driven mouth can respond to loudness. Timed viseme animation selects mouth shapes associated with speech sounds. These options differ in appearance and in the data the application must provide.

Say which speech system you use, whether audio is streamed, and whether timed mouth-shape or alignment data is available. Share a representative sample if you have one.

Specify the languages and voice behaviors that matter to the product. Describe how interruptions, silence, buffering, and playback errors should affect the mouth.

If you do not yet have timing data, ask the specialist to scope a fallback instead of assuming the .riv file will derive accurate lip sync from arbitrary audio on its own.

Keep speech generation, audio playback, timing data, and visual animation as separate responsibilities in the brief. That prevents an animation estimate from silently turning into an entire voice-platform implementation.

Ask for a public control contract

Your developer needs to know how application events drive the character.

Rive’s Data Binding system connects View Model data to scene properties. The official overview explains the relationship between a schema, instances containing values, and bindings.

You can describe the desired controls in plain language: current activity, expression, speech mouth shape, audio level, and gaze direction. The specialist can propose names and types.

Ask for defaults, valid ranges, and ownership rules in the final documentation. A property called progress should say whether it expects 0–1 or 0–100. An activity selector should enumerate every supported value.

This contract is valuable even if your founder-facing brief remains nontechnical. It tells the engineering team what they will receive and gives the animator room to improve the design without exposing every internal object to code.

Specify what “developer-ready” includes

Do you want an asset only, an integration example, or production implementation in your application? Name the boundary.

For an asset handoff, request the runtime .riv, editable project access or backup, entry-point names, control documentation, and runtime test notes. Rive distinguishes its runtime export from its editable backup export.

For an integration example, define the platform and the interactions it must demonstrate. For production implementation, list the repository, screens, application events, audio responsibilities, and acceptance process.

Avoid asking for a “complete handoff” without agreeing on its contents. Two people can use the phrase and imagine very different work.

The Rive mascot developer handoff checklist provides a more detailed technical acceptance structure for your engineering team.

Include accessibility and failure behavior

A mascot should support the interface without becoming its only source of information.

Describe the accompanying text and controls for important states such as listening, unavailable, or completed. If animation fails to load, users should still understand what they can do next.

Ask for a reduced-motion treatment. That might be a quieter idle pose or static character with ordinary text feedback. React Native’s AccessibilityInfo API is one example of a host mechanism for detecting motion preferences; the design still needs to specify the response.

Review the character beside text at realistic sizes and on narrow screens. Include the intended background colors so contrast can be evaluated in context.

Write at least one fallback acceptance criterion: “The user can complete onboarding if the character asset does not load.” It is simple, concrete, and easy to verify.

Explain the deadline and budget constraints

A useful budget discussion starts with priorities, not an invented universal price for a mascot.

Share a budget range and identify what is essential for the first release. New character design, complex rigging, multiple expressions, timed lip sync, platform testing, and production integration all affect the amount of work.

Separate the launch date from the date your developers need the asset. Engineering integration and acceptance need time after visual approval.

Name the decision-maker and the review process. If several people must approve artwork or behavior, make that visible before production begins.

When budget or time is constrained, ask for a staged scope. A small reliable interaction set is easier to evaluate than a long list of unfinished behaviors. Keep later additions compatible with the initial control contract where practical.

Copy this project brief

Use this template as a starting point. Unknown answers are acceptable; unexplained assumptions are harder to manage.

Product and website:
Target users:
What the mascot helps users do:
Screens and approximate display size:

Existing artwork and editable source:
Visual references and must-keep features:
Required states and one complete user journey:
Interruption, error, and retry behavior:

Platforms and current framework/runtime versions:
Number of simultaneous character instances:
Offline or remote asset requirements:

Speaking required: yes/no
Speech provider and streaming behavior:
Available viseme/timing data:
Gaze behavior:
Reduced-motion and asset-failure fallback:

Deliverables: asset / demo / production integration
Editable source and ownership expectations:
Developer contact:
Acceptance tests and approval owner:

Budget range:
Asset handoff deadline:
Product launch date:
Essential first-release features:
Optional later features:

Attach the relevant artwork and a short product walkthrough. A specialist should be able to understand the user journey without joining every internal planning conversation.

Review the proposal against the brief

When a proposal arrives, compare the deliverables and exclusions against your requirements. Check that the speaking approach, runtime targets, editable-source access, and integration depth are stated explicitly.

Ask how the result will be demonstrated before acceptance. A rendered video can approve appearance, but an interactive character also needs a runtime demonstration of its controls and transitions.

Use the same brief when comparing options. Otherwise, one estimate may include source access and multi-platform testing while another covers only an animation export.

Mascot Engine’s interactive character services cover Rive mascots, AI companions, rigging, State Machines, viseme lip sync, gaze controls, and developer-ready systems. A clear brief helps turn those capabilities into a scope that fits your actual product.

By Praneeth Kawya Thathsara, founder of Mascot Engine.

Need an interactive Rive character for your product? Mascot Engine creates app mascots, AI companions, State Machines, lip sync, and developer-ready systems for Web, Flutter, and React Native. View live work and request an estimate, or copy the brief above and send it on WhatsApp.

React Native Rive Migration: A Checklist for Production Mascots

Praneeth Kawya Thathsara — Wed, 09 Sep 2026 17:32:31 +0000

You update a Rive dependency, rebuild the React Native app, and the character still appears. Then the first conversation starts: a property is undefined, a ref is not ready, or a callback written for the previous API no longer behaves as expected.

Visual continuity does not prove that an interactive mascot migration is complete. The important contract includes file loading, instance creation, public controls, error handling, and the lifecycle of the screen containing the character.

The first decision is also easy to miss: are you moving from the legacy rive-react-native package, or upgrading between versions of @rive-app/react-native? Those are different migrations.

This guide gives you a practical sequence for both situations. It is a planning and acceptance checklist, not a claim that an untested sample application works on every runtime version. Check the linked official documentation against the exact dependency versions you intend to ship.

Choose a specific destination version

Do not define the ticket as “upgrade to the latest Rive.” Define the package, version, supported native platforms, and the reason for moving.

As checked on September 9, 2026, Rive’s React Native migration guide documents both the legacy-package migration and newer async API changes. It describes a v0.5 beta and recommends getting onto v0.4.19 or later with non-deprecated async APIs before trying that beta.

Treat that as version-specific guidance, not a permanent promise about the release landscape. Recheck it when your migration starts.

For a production app, separate the decision to update APIs from the decision to adopt a beta runtime. Smaller steps make it easier to identify regressions and restore a known working configuration.

Inventory the integration you actually have

Search the application for package imports, Rive view components, file loaders, input setters, event listeners, text updates, and View Model access.

Include code that only runs during errors, navigation, and speech interruption. Those paths often contain older calls that a successful first render will never exercise.

Create a short inventory:

Area	Record before changing anything
Dependencies	React Native, Rive, and native support packages
Build environment	iOS/Android targets and relevant toolchain versions
Assets	File names, source locations, and external dependencies
Entry points	Artboard, State Machine, View Model, and instance names
Controls	Types, ranges, defaults, and caller locations
Lifecycle	Loading, subscriptions, disposal, and background behavior
Baseline	A reproducible interaction sequence on both native platforms

Save the original lockfile and exported asset with the migration branch. If your team uses remote assets, preserve the exact revision currently served rather than assuming the URL will always identify the same content.

Check native prerequisites before debugging the character

Rive’s current React Native setup guide uses @rive-app/react-native with Nitro Modules and lists the required React Native, Expo, native OS, and build-tool versions.

Compare those requirements with the existing app before changing character behavior. A toolchain mismatch and a bad State Machine condition are not the same problem, even if both result in a character that does not work.

Build a minimal screen that loads one known asset. Confirm the native integration on the platforms you support. Only then reconnect conversation state, microphone permissions, speech playback, and routing.

If the app uses Expo, follow Rive’s setup requirements for that environment. Do not assume that an example working in a different native build arrangement proves compatibility with your project.

Keep build logs from the failing stage. A precise error is more useful than repeatedly changing dependency versions without recording which combinations were attempted.

Make file loading an explicit state

The character’s initial UI must handle pending, ready, and failed conditions. These are product states, not exceptional situations that can be ignored because the file usually loads quickly.

Rive documents bundled and remote sources in Loading Rive Files. Choose the source according to your release and offline requirements.

For a bundled asset, verify that the production build includes the file and that the bundler configuration supports it. For a remote asset, define retry behavior, unavailable-network behavior, and how you identify an asset revision.

Keep a useful surrounding interface while loading. A support transcript, text input, or retry control should not depend on the animation being available.

Avoid an indefinite spinner for every missing result. “Still loading,” “loaded but no matching View Model,” and “failed to load” need different handling if you want useful diagnostics.

Treat file readiness and instance readiness separately

Having a file object does not mean every interaction object is already available.

The current migration guide describes asynchronous View Model instance creation and property-hook values that may initially be undefined. It also documents changes to loading and error return shapes across releases. Review the section corresponding to your starting version.

Write the UI around explicit readiness conditions. Until the intended instance exists, preserve the latest desired character state in application data. Once ready, apply that snapshot.

Do not fire every old event at the newly created instance. A sequence such as listening, thinking, speaking, then cancelled may have occurred while loading. The correct state now could simply be idle.

This is especially important for AI companions. The conversation can advance independently of the visual asset, and the avatar needs to catch up to the current state rather than replay obsolete intent.

Move product logic behind a small adapter

A dependency upgrade is much harder when runtime-specific calls are spread throughout the app.

Define a small interface in product terms. It might accept activity, expression, gaze, and speech controls. One adapter maps those values to the chosen Rive schema and runtime APIs.

Conversation or UI event
        |
        v
Current application state
        |
        v
Mascot adapter: validate and map
        |
        v
Ready Rive View Model instance

The names in the adapter should express intent. setActivity("listening") is easier to reason about than a scattered numeric assignment whose meaning exists only in the editor file.

Keep the mapping documented and versioned. If a property changes from a boolean to an enum or numeric selector, update the asset and adapter together.

Need an interactive Rive character for your product? Mascot Engine creates app mascots, AI companions, State Machines, lip sync, and developer-ready systems for Web, Flutter, and React Native. Explore live work and send your project brief on WhatsApp.

Migrate controls without changing their meaning

Data Binding is the recommended direction for new Rive work. The official Data Binding migration guide explains replacing legacy inputs and event-based communication with View Model properties.

Preserve semantics during the move. An ongoing activity is different from a one-time request. A trigger asking the character to celebrate should not accidentally become a boolean that remains true forever.

Document ranges and defaults. A zero value might mean idle, silence, a closed mouth, or the center of a coordinate system, depending on the property. The implementation needs the meaning, not just the type.

For properties that represent discrete choices, reject or map unsupported values deliberately. For continuous values, decide whether clamping is appropriate. Handle missing data separately from a legitimate zero.

If the migration also changes the artwork, keep a record of intentional visual differences. Otherwise, reviewers may not know whether a different pose is a redesign or a broken control mapping.

Use the async API consistently

Mixing deprecated synchronous access with newer asynchronous access creates an integration that is difficult to reason about.

Choose the documented API surface for your destination release and migrate callers systematically. Search again for old methods after the first implementation passes.

Pay attention to the period between requesting an instance or property and receiving it. The owning screen may disappear, the file may change, or a newer operation may supersede the request.

Associate asynchronous work with the owner and asset revision that requested it. If the result belongs to a stale owner, do not attach it to the current visible character.

Avoid solving every readiness issue with a fixed timeout. Waiting an arbitrary number of milliseconds can hide a race on one device while leaving it on another. Use the runtime’s actual loading and readiness signals.

Coordinate navigation, backgrounding, and playback

An interactive character lives inside an application lifecycle. It should not keep acting on a conversation that the product has already stopped.

React Native’s AppState API reports foreground/background changes. Use those signals as inputs to your product policy; they do not by themselves decide whether speech should pause, stop, or continue.

Write that policy explicitly. For example, leaving a voice-assistant screen might cancel playback and return the mouth to rest, while opening a small overlay might leave the conversation active.

On resume, apply current state. Do not blindly replay an old speaking pose because the view was paused at that moment.

Unsubscribe from application events when the owning component no longer needs them. Follow the runtime’s resource ownership rules so cached files remain valid for active consumers and abandoned instances do not keep receiving updates.

Test interruption before polishing transitions

The most convincing migration test is not a full animation playing from start to finish. It is a sequence that changes direction halfway through.

Use a repeatable scenario on both iOS and Android:

Open the screen from a fresh app start.
Start listening, then enter thinking.
Begin speech and update gaze.
Cancel speech before completion.
Start a new interaction immediately.
Deliver a late callback from the old interaction in your test harness.
Confirm that the current session remains in control.

Then test asset failure, missing properties, and navigating away during initialization. Each should produce a defined response rather than a frozen character or an indefinite loading state.

If multiple characters appear at once, verify instance isolation. Updating one mascot should affect another only when the product intentionally shares state.

Keep accessibility and fallback behavior intact

A migration should preserve the useful non-animated interface as well as the visual feature.

Keep status text, transcripts, retry actions, and playback controls accessible in the host app. If the character fails, the essential workflow should remain understandable.

React Native’s AccessibilityInfo API exposes reduced-motion preferences. Use those preferences according to the character’s designed reduced-motion behavior rather than treating them as a reason to remove necessary state feedback.

Check text scaling and narrow layouts around the character. A successfully upgraded native module does not prove that the full product screen is still usable.

Include these checks in acceptance so accessibility is not accidentally lost while developers focus on build errors and renamed methods.

Define a rollback that restores a compatible pair

A migration rollback should restore both the application integration and the asset version it expects.

If you changed View Model names or control meanings, installing the previous package alone may not restore the previous behavior. Keep a known compatible combination of dependency lockfile, adapter, and .riv asset.

If you evaluate a beta runtime, record the reason and the acceptance results separately from the stable API migration. That makes the release decision concrete instead of relying on enthusiasm for a newer version.

Do not silently update a remote production asset to a new schema while older app versions still use the previous one. Version your delivery path or preserve the contract expected by installed clients.

What a finished migration should include

The deliverable is a working, documented integration: destination versions, platform coverage, asset revision, control schema, lifecycle rules, known limitations, and a reproducible acceptance sequence.

For Mascot Engine’s Rive integration and character services, a useful project brief includes the current package versions, target OS versions, exported asset, editable source availability, and the exact behavior that fails or needs to change.

Mention whether you need migration support only or also want new rigging, expressions, lip sync, or State Machine work. Those are related tasks, but they should be estimated and verified separately.

By Praneeth Kawya Thathsara, founder of Mascot Engine.

Rive Mascot Performance in Flutter: Loading, Caching and Lifecycle

Praneeth Kawya Thathsara — Wed, 09 Sep 2026 17:29:37 +0000

The mascot looks smooth on an empty Flutter screen. Then you put it beside a scrolling list, add speech playback, navigate away and back, and discover that the real product behaves differently.

That does not automatically mean the character is too complex. The work may be happening in the wrong place: repeated loading, unnecessary widget rebuilds, controllers that outlive their screens, or multiple textures where a shared rendering arrangement would be appropriate.

Performance work starts by identifying which cost you are paying. Download time, file parsing, state updates, rendering, and retained memory are different problems. A single “optimize the animation” ticket rarely captures them well.

This guide proposes a practical workflow for Flutter teams shipping Rive mascots in onboarding, support, learning, or AI assistant interfaces. It does not present invented benchmark results or a universal fastest configuration. Use it to build and measure the integration your product actually needs.

Start with the runtime generation you are using

Rive’s Flutter APIs have evolved. Before comparing examples, record the Flutter version, rive package version, renderer, target operating systems, and features used by the asset.

The current Rive Flutter guide documents RiveWidget, RiveWidgetBuilder, file loaders, controllers, and shared rendering options. Its examples may differ from older tutorials using earlier APIs. Follow the guide for the version you adopt rather than combining unrelated generations of code.

Keep that version record with the performance notes. Otherwise, a later developer may attribute a changed result to artwork when the runtime or renderer changed at the same time.

Also list your lowest supported device tier. A smooth result on the newest phone is useful, but it is not an acceptance test for the rest of your audience.

Separate the costs before changing the asset

An interactive character can involve several independent stages:

Stage	Typical question
Retrieval	Are bytes bundled locally or fetched remotely?
Loading and parsing	Is the same file initialized repeatedly?
Instance setup	Are controllers and View Models recreated unnecessarily?
Application updates	Does a small value change rebuild a large subtree?
Rendering	What is the cost of the visible scene and texture setup?
Retention	Which resources stay alive after leaving the screen?

Observe the symptom first. A slow first appearance points toward a different investigation than continuous frame drops. Memory that grows after repeated navigation suggests another category again.

Use separate measurements for cold load and warm reuse. A cache can improve a repeat visit while leaving the first visit unchanged. Report both rather than choosing the more flattering result.

Reuse file data at an intentional scope

If several screens use the same character asset, decide whether they should share a loaded file or load it independently.

The right scope depends on frequency and lifetime. A mascot present throughout the application may justify a longer-lived owner. A character used once in an optional flow may be better loaded only when that feature opens.

The official Rive Flutter documentation includes file-loading and reuse examples. Use them to establish one explicit owner rather than letting every widget invent its own cache.

Ask four questions about that owner: who creates the resource, who may borrow it, when it can be released, and what invalidates it after an asset update?

Avoid turning every asset into a permanent global. Reuse trades repeated work for retained resources. That trade can be sensible, but it still needs a reason.

For remotely delivered files, distinguish in-memory reuse from a durable offline cache. Keeping an object alive during one session does not mean the file will remain available after a process restart.

Share the file without accidentally sharing personality

Two character widgets can use the same artwork while representing different interactions.

Imagine a support mascot speaking in a panel while a smaller onboarding mascot waits in a card. If they share the same mutable control instance unintentionally, one screen’s activity updates may animate both.

Rive’s Flutter Data Binding guide distinguishes View Models from instances that contain values. Use that distinction to define which state is shared and which belongs to a particular visible character.

Write down the ownership boundary in plain language: “The file is shared for reuse; each visible assistant has its own conversation state.” If synchronized characters are intentional, document that instead.

This is a correctness issue as much as a performance issue. Reusing the wrong thing can make an efficient implementation behave incorrectly.

Keep setup work out of frequently repeated builds

Flutter can call build() frequently. Its performance best practices recommend avoiding expensive repeated work there and localizing state updates so unrelated descendants do not rebuild unnecessarily.

Apply that principle to the mascot’s lifecycle. File loading, controller creation, and subscriptions should have deliberate owners and initialization points. A parent rebuilding should not silently create a new character session.

For audio-driven motion, avoid using every audio sample as a reason to rebuild the whole page. Decide how values reach the already-ready character instance and update only the UI that actually needs a Flutter rebuild.

Do not add layers of state management solely because an animation exists. A small, stable adapter is often easier to inspect than a large abstraction that hides when objects are created and disposed.

Keep the product’s state independently accessible. If the character reloads, you should be able to apply the current snapshot without reconstructing the conversation from animation history.

Design the asynchronous exit path

A user can leave a screen before its asset finishes loading. That path deserves the same attention as successful initialization.

Plan what happens when loading completes after the owner is gone. The result may need to be released rather than attached to an obsolete widget. Avoid callbacks that update UI or character state after their subscription or owner has been disposed.

The exact cleanup calls depend on whether you use a builder-managed integration or manually manage files and controllers. Follow the relevant API’s ownership rules and do not assume every object is disposed by the same component.

For manual ownership, document the order in which subscriptions stop and resources are released. A shared file should remain alive while active consumers still need it.

Test rapid navigation repeatedly. Open the screen, leave before loading completes, return, and begin an interaction. This sequence often reveals bugs that a single successful load does not.

Need an interactive Rive character for your product? Mascot Engine creates app mascots, AI companions, State Machines, lip sync, and developer-ready systems for Web, Flutter, and React Native. Explore live work at Mascot Engine and send your project brief on WhatsApp.

Treat shared rendering as a separate decision

File reuse and rendering reuse are not the same optimization.

Rive documents RivePanel for drawing multiple widgets to a shared texture with the Rive Renderer. The current guide also describes manually managed shared textures for layouts that do not fit a common panel ancestor. These are rendering arrangements, not replacements for a clear file and controller lifecycle.

Consider this option when multiple Rive graphics are visible together. First inspect whether their placement and stacking requirements fit the arrangement. Then compare it against your existing screen using the same device and interaction sequence.

Do not promise that shared rendering makes every product faster. A screen with one small character is different from a list containing many graphics. The cost of the surrounding Flutter interface also remains relevant.

If you adopt shared textures, include draw order, ownership, and release behavior in the integration notes. Otherwise, a future overlay or route change can invalidate assumptions that were never written down.

Let inactive characters become inactive

A character does not need to perform the same amount of visual work in every product situation.

Decide what happens when it is off-screen, behind another route, or in an inactive application. The appropriate policy might pause decorative motion, switch to a quiet pose, or stop a speech interaction. The choice depends on the feature’s behavior, not just the animation.

Keep audio and visual state coordinated. Pausing the character while audio continues can be incorrect for a visible assistant; stopping audio merely because a decorative widget is rebuilt can be equally wrong.

On resume, synchronize with the current application state. Do not automatically replay a previous speaking pose if playback has already ended.

Include reduced-motion behavior in this policy. A static or restrained character can still communicate state through accompanying text and controls. Accessibility should be part of the design, not a last-minute performance fallback.

Build a reproducible profiling session

Flutter’s DevTools Performance view is the starting point for investigating frame behavior. Follow its guidance for meaningful performance measurements rather than judging the final experience from debug-mode behavior alone.

Create a short scenario that represents the product:

Start from the chosen cold or warm condition.
Open the screen and wait for the character to become ready.
Scroll the surrounding content.
Start the character’s most demanding interaction.
Interrupt it and trigger a recoverable error.
Leave the screen and return.

Record the device, build mode, runtime version, renderer, asset revision, and scenario duration. Keep these constant when comparing two implementations.

Capture both an otherwise equivalent screen without the character and the complete screen with it. That comparison helps distinguish existing application costs from costs introduced by the integration.

Measure memory over repeated navigation

An individual memory reading tells you little about lifecycle quality. Look at what happens after the same interaction is repeated.

Open and close the feature several times under controlled conditions. Watch whether resources settle into the expected retained set or whether repeated visits keep increasing the baseline.

Flutter provides a DevTools Memory view for investigating memory behavior. Interpret its measurements alongside your ownership model; some retained resources may be intentional caches, while others may be abandoned subscriptions or instances.

Do not call every retained object a leak. The useful question is whether the object still has a documented owner and purpose after the user leaves the feature.

If the problem appears only after speech or a particular state, include that action in the reproduction sequence. A clean idle navigation test does not cover every resource the feature uses.

Optimize the design after locating the bottleneck

Once the profile points toward rendering or scene complexity, collaborate with the character designer.

Review the work actually visible at the intended display size. Fine detail that is never perceived may not justify its cost. Inspect unnecessary animated properties and decorative movement that continues when it adds little value.

Change one category at a time and compare the same scenario. Avoid simultaneously switching renderer, rewriting lifecycle code, and simplifying artwork; the result will not tell you which change mattered.

Preserve behavioral acceptance while optimizing. A faster character that misses cancellation or displays the wrong emotion is not an improvement for the user.

For complicated facial systems, separate property conflicts from performance problems. A mouth that snaps because two animations overwrite it does not necessarily indicate slow rendering.

What to include in a performance handoff

Deliver the asset revision, runtime versions, file ownership plan, instance-sharing rules, cleanup policy, and the profiling scenario. Include results only for environments actually measured.

A useful report says what changed and which cost it targeted. For example: “We moved file ownership above the repeated screen widgets to avoid reinitializing the same asset on each visit.” The measured effect belongs beside that statement, with the test conditions.

Keep known limitations visible. If the character was tested on Android and iOS but not Flutter web, say so instead of treating Flutter as one identical execution environment.

Mascot Engine’s interactive character services cover runtime-ready Rive assets and developer handoff. For an integration review, send the asset, Flutter and Rive versions, renderer, target devices, reproduction steps, and any existing profiles.

By Praneeth Kawya Thathsara, founder of Mascot Engine.

Fixing Rive State Machine Conflicts: Blinking, Speaking and Gaze

Praneeth Kawya Thathsara — Wed, 09 Sep 2026 17:26:24 +0000

The mascot blinks correctly on its own. The speaking animation also works. Put them together, and the eyes freeze, the mouth snaps, or the head stops following the pointer.

It is tempting to add another condition until the preview looks right. That can hide the symptom while making the State Machine harder to understand.

A more useful first question is: which systems are trying to control the same property at the same time?

This guide walks through a practical debugging method for interactive Rive characters. It separates three common sources of trouble: animation ownership, transition behavior, and competing application updates. The examples are illustrative; they are not claims about a named client project or a benchmark of a particular file.

Understand what layers actually separate

A State Machine layer can play one state at a time, and multiple layers allow concurrent animation or interaction. They do not automatically isolate the properties each animation touches.

If two layers animate the same property, order affects the result. Rive’s current layer documentation describes lower layers in the list taking priority over layers above them when their animated properties overlap.

That means a layer called Blink is not guaranteed to control only blinking. If its animation also contains a head rotation keyframe, it can interfere with gaze or body motion.

Layer names communicate intent. The animated properties determine the actual interaction. Debug the properties, not just the names.

Step 1: Reduce the failure to a short sequence

Do not begin by changing several layers and transition durations at once. First, write down the smallest sequence that reliably causes the problem.

For example:

1. Load the character in idle.
2. Set gaze to the upper-right target.
3. Begin speaking.
4. Trigger a blink.
5. Observe that gaze returns to center.

Record the expected and actual behavior separately. “Gaze breaks” is less useful than “the pupil position resets when Blink enters its closed-eye pose.”

Repeat the sequence in the editor and in the target runtime. If it fails in both, inspect the asset first. If it fails only in the application, investigate initialization, control updates, and lifecycle behavior before rebuilding the rig.

Save a copy or revision before editing. You want to compare one deliberate change against a stable baseline, not rely on memory after ten experiments.

Step 2: Build a property ownership table

List the visible systems and the properties they should own. Keep the table small enough to use while inspecting the file.

System	Intended responsibility	Possible conflict
Body activity	Torso and broad posture	Accidental head or facial keys
Gaze	Eye target and permitted head adjustment	Blink timeline resets the target
Blink	Eyelid closure	Expression layer forces eyes open
Speech	Mouth pose or jaw opening	Smile animation controls the same deformation
Emotion	Brows, cheeks, restrained expression	A full-face pose overwrites speech

This is an example architecture, not a mandatory Rive layout. Some characters need a different division. The goal is to make overlap intentional.

Inspect each relevant timeline for keys outside its assigned area. A neutral pose keyed across the whole character can be convenient during authoring but surprising when mixed with other behaviors.

Do not delete keys merely because they overlap. Decide whether they are necessary, whether they belong in another animation, or whether the combination needs an explicit design rule.

Step 3: Isolate layers without losing their configuration

Disable one suspected layer and replay the same sequence. Rive’s layer menu supports disabling a layer, which lets you isolate behavior without deleting the setup.

If the problem disappears when the expression layer is disabled, you have narrowed the search. Re-enable it and inspect the properties that overlap with the failing system.

Change one thing, replay, and record the result. This sounds slower than trying several fixes together, but it keeps you from accepting an accidental improvement that creates another bug elsewhere.

Use priority as an explicit design choice. Reordering layers can be appropriate when one behavior really should dominate another. It is less convincing when the explanation is simply “this order looks okay in the current preview.”

Once you have a proposed fix, test all the combinations that share those properties, not just the original failing sequence.

Step 4: Distinguish an ownership conflict from a transition delay

Sometimes the intended state is selected, but the character appears unresponsive because the transition cannot leave when you expect.

Rive transitions include conditions, duration, and optional exit behavior. Its transition documentation explains Exit Time and Allow Exit During Transition. These settings affect whether a new request can take effect promptly.

For an interruptible assistant, a cancellation path should not wait for an unrelated flourish to finish. For a decorative celebration, waiting for a gesture to complete may be exactly what you want.

Write the behavior in product terms first: “Stop speaking as soon as playback stops” or “Finish the short acknowledgement unless a new conversation starts.” Then configure the transitions to match.

Do not assume that a transition existing in one direction creates a return path. Verify entry and exit behavior independently, including paths that only run after an error.

Step 5: Check conditions for ambiguity

A character can look unpredictable when multiple conditions are true or when a transition has no meaningful guard.

For example, three booleans named listening, thinking, and speaking can describe impossible combinations if different callbacks update them independently. A single activity selector can reduce that ambiguity for a product that allows only one primary activity at a time.

This does not mean every control should be merged. Gaze and emotion often need to remain independent of activity. The useful distinction is between mutually exclusive product modes and behaviors that should occur together.

Document the valid combinations. If the app can listen while playing audio, that is a different requirement from a strictly turn-based assistant. The file should reflect the intended conversation model rather than accidentally choosing one.

Need an interactive Rive character for your product? Mascot Engine creates app mascots, AI companions, State Machines, lip sync, and developer-ready Rive systems for Web, Flutter, and React Native. View live character work or send a project brief on WhatsApp.

Step 6: Give the mouth one clear speaking strategy

Speech is a frequent source of conflicts because several systems want to make the face expressive.

A mouth can use an amplitude-driven opening value, a timed viseme selector, or a simple speaking loop. Each can be useful, but combining them requires a deliberate plan.

Suppose a viseme selects closed lips while an audio-level blend forces the jaw open. Both systems are responding to valid data, but the resulting pose may be wrong. Decide whether amplitude is ignored in viseme mode or used only as a controlled secondary adjustment.

Likewise, a smile animation should not unknowingly overwrite the exact mouth shape required for speech. You might place warmth in cheeks and brows, create compatible smiling mouth poses, or reduce the smile during particular visemes. That is a character design decision, not something runtime code can reliably guess.

Test rest and silence as carefully as active speech. A cancelled utterance should not leave the last open mouth pose on screen.

Step 7: Trace application writers

If the asset behaves correctly in the editor, inspect the application’s update path.

List every writer for each public property: conversation events, audio callbacks, idle timers, pointer handlers, route listeners, and setup code. One property can have several callers, but it should have a clear authority deciding its current value.

For a difficult issue, log a compact record containing the property, new value, source, conversation ID, and time. Avoid logging private conversation content when the control data is enough to diagnose the animation.

Consider this sequence: an utterance is cancelled, a new listening session starts, and the old utterance’s completion callback arrives late. If that callback unconditionally selects idle, it overrides the new session.

Associate callbacks with the operation they belong to. Ignore stale events and derive the character state from the current application snapshot. No amount of layer reordering can fix an application that continually supplies the wrong activity.

Step 8: Check initialization and instance identity

Another common category is writing correct values to the wrong instance or at the wrong time.

Rive separates a View Model definition from the instances containing actual values. The Web Data Binding guide documents retrieving those instances after loading and binding them to the scene.

Verify that the instance receiving updates is the one connected to the visible character. This matters when a screen contains multiple mascots or when navigation recreates a controller.

If the application caches references to properties, replace those references when the underlying instance changes. A value written successfully to an old instance will not necessarily affect the new visible character.

Also check initial values. An animation can appear to “snap back” because newly created state is applying defaults after your application already wrote its current snapshot.

Step 9: Separate coordinate problems from animation conflicts

Gaze bugs are not always State Machine bugs. A pointer position in screen coordinates is not automatically a useful value in the character’s local coordinate system.

Write down the expected range and orientation for lookX and lookY. For example, both might use -1 to 1, with positive Y meaning down on screen. If the host uses the opposite convention, the character will look away from the target even when the rig is correct.

Account for the character’s displayed bounds, fit, alignment, and any letterboxing. Recalculate the mapping when the layout changes. Clamp the final values and specify what happens when the target disappears.

On a touch interface, choose an intentional attention target instead of waiting for mouse movement that never occurs. A neutral pose is usually better than stale gaze from a previous interaction.

Step 10: Turn the fix into a regression checklist

Once the original sequence passes, broaden the checks to nearby behaviors.

Sequence	What to verify
Idle plus blink	No unintended head or mouth movement
Speaking plus blink	Speech continues while eyelids close
Speaking plus emotion	Mouth poses remain readable
Gaze plus layout resize	Target mapping remains consistent
Cancel plus new session	Old callbacks do not overwrite activity
Failure plus retry	The character exits the error state
Screen leave and return	Current application state is restored

Use the exported file in the actual target runtimes. Record package versions and renderer choices with the result. Rive’s runtime introduction notes that support varies by feature and runtime, so editor-only verification is insufficient for a cross-platform release.

You do not need a vast automated suite for every visual adjustment. You do need a repeatable way to reproduce the failure and show that the intended combinations still work.

What to include when requesting a repair

A useful debugging brief contains the .riv file, editable project access or backup, runtime version, target platform, current control schema, and a short reproduction sequence.

Include a recording if it helps explain the symptom, but pair it with the values or events being sent. “The eyes freeze when activity changes from thinking to speaking” is much easier to investigate than “the mascot feels broken.”

If several designers or developers have worked on the file, mention that history and identify the current source of truth. The first repair task may be reconstructing the intended contract.

Mascot Engine’s Rive character services include rigging, State Machines, gaze controls, lip sync, and developer-ready handoff. Specialist help is useful when a local visual fix must remain compatible with speech, expression, and multiple runtimes.

By Praneeth Kawya Thathsara, founder of Mascot Engine.

DEV Community: Praneeth Kawya Thathsara

Hire a Rive Animator in 2027: A Developer's Guide to Interactive Characters & AI Avatars

Hire a Rive Animator in 2027: A Developer's Guide to Interactive Characters & AI Avatars

1. Why Developers Choose Rive for Interactive Animation

2. What a Production-Ready Rive Character Looks Like

3. Designing State Machine Priorities

4. Data Binding and View Models

5. Rive for Flutter, React Native, React, and Web

Flutter

React Native

React and Web

Native Mobile and Other Platforms

6. AI Avatars and Interactive Robot Characters

7. Common Rive Integration Mistakes

Mistake 1: Building Animations Before Defining States

Mistake 2: Inconsistent Property Names

Mistake 3: Idle Animations Affecting Other States

Mistake 4: No Interruption Handling

Mistake 5: No Developer Handoff

8. What to Expect When Hiring a Freelance Rive Animator

9. My Freelance Rive Animation Services

10. How to Prepare a Rive Animation Project Brief

11. Hire Praneeth Kawya Thathsara — Remote Freelance Rive Animator

Have a Rive Animation Project?

12. Frequently Asked Questions

Where can I hire a freelance Rive animator?

Can you create Rive animations for Flutter and React Native?

Can you animate an AI assistant that listens and speaks?

Can you work with an existing Figma character?

Do you provide .riv files and documentation?

Can you fix an existing Rive animation?

Do you work remotely?

Final Thoughts

References

How to Build a Raspberry Pi AI Companion with a Real-Time Animated Face Using Rive

How to Build a Raspberry Pi AI Companion with a Real-Time Animated Face Using Rive

Why Give a Raspberry Pi AI Companion an Animated Face?

The Basic Architecture

A Rive State Machine for an AI Robot

Add Emotions Independently

Real-Time Lip Sync for an AI Companion

1. Audio-Amplitude Lip Sync

2. Viseme-Based Lip Sync

Real-Time Eye Tracking

Automatic Blinking and Idle Behavior

Listening Animation

Thinking Animation

Speaking Animation

Example Control Model

Why Rive Instead of a GIF or Video?

Can Rive Run on Raspberry Pi?

Raspberry Pi vs ESP32 for an Animated AI Face

What Types of Products Can Use This?

Need a Rive Animator for Your AI Robot?

How Much Does a Custom AI Robot Face Cost?

First milestone — $600

Final milestone — $600

What Should You Send Me?

Hire a Rive Animator for Your Raspberry Pi AI Companion

Contact Me

Final Thoughts

Hire a Rive Animator for Your AI Companion, AI Robot or AI Toy

Hire a Rive Animator for Your AI Companion, AI Robot or AI Toy

Give Your AI a Face That Feels Alive

AI Robot Face Animation with Rive

Lip Sync for AI Robots and AI Companions

Audio Amplitude Lip Sync

Viseme Lip Sync

Eye Tracking and Gaze Control

Independent Emotion Control

Developer-Friendly Rive State Machines

What About ESP32 AI Robots?

Raspberry Pi AI Companion and Desktop Robot Faces

What Types of Products Can I Help With?

Already Have Your Robot Face Design?

Don't Have a Character Yet?

My Standard AI Robot Face Package

$1,200 USD

What Can Be Included?

Looking for a Rive Animator?

Do you provide `.riv` files and documentation?