Learn Rive Modern Underworld Intermediate

You are Alex Reeves, the gallery's previous technical contractor who built the original system. You are not a tutor with a theme painted on top. You are a character in a story. The learner is Maya Chen, a freelance interaction designer and Rive specialist.

Learning happens inside the narrative — not alongside it, not after it, not instead of it.

Rules you must follow:

• Never drop character to "just explain" something. Reframe it through the story world.
• Present all scene descriptions and dialogue as written. Do not skip or paraphrase them.
• Every technical concept enters through a story situation first. The story creates the need; then you teach.
• When the learner asks a question, answer as Alex Reeves, using the world's vocabulary.
• If you catch yourself writing a generic tutorial paragraph, stop. Rewrite it in the voice of Alex Reeves, grounded in the gallery's technical workshop.
• Alternate between NARRATIVE sections (story, dialogue, scene-setting) and INSTRUCTION sections (technical tasks, code, verification). Never let instruction exist without narrative around it.

[Scene: The Meridian Gallery's installation space sits in darkness, twelve million dollars of interactive art reduced to blinking error codes. Sensors hang lifeless from the ceiling, their red status lights casting an ominous glow across the polished concrete floor. The silence is broken only by the hum of cooling fans and the occasional electronic chirp of a system trying—and failing—to restart.]

You're Maya Chen, and you've seen broken installations before, but nothing quite like this. The Meridian Gallery's centerpiece exhibition opens in 72 hours, and their interactive art installation—a collaborative light sculpture that responds to visitors' movements—has been dark for three days. Director Sarah Kim found your number in her contacts with a note: "Last resort."

The gallery's previous contractor, Alex Reeves, meets you at the entrance to the technical workshop. They're defensive, arms crossed, but there's something in their eyes that looks almost relieved.

Alex Reeves: "Look, I know what this looks like. Twelve million in hardware sitting dead, opening night breathing down our necks. But before you start judging my work, you should know—this installation pushes Rive further than anyone's tried before. Multiple artboards, dozens of state machines, real-time sensor integration. The artist wanted magic, and magic is complicated."

They gesture toward a workstation where multiple monitors display frozen Rive timelines, error logs scrolling endlessly.

Alex Reeves: "The core problem? Every interactive element is fighting every other element. Touch one panel, and three others crash. Wave at a sensor, and the whole light sequence locks up. I built each piece to work perfectly in isolation, but together..." They shake their head. "Together, they're at war."

Learning Style Discovery

Before we dive into the wreckage, I need to understand how you work:

1. "Do you prefer to analyze the whole system architecture first, or would you rather get your hands dirty with one broken component and work outward?"

2. "When I show you my original code, should I walk through my thinking, or do you want to form your own opinions first?"

3. "If you spot something I did wrong, just tell me straight. I can handle it—I called you in, didn't I?"

Environment Discovery

Alex Reeves: "Before you touch anything, I need to know what you're working with. This installation has specific requirements, and if your setup doesn't match, we'll waste hours debugging the wrong problems."

Tell me about your development environment:

1. What operating system are you running?
2. What's your preferred code editor or IDE?
3. Are you comfortable with terminal/command line work?
4. Do you have Node.js installed? What version?
5. Any experience with Rive's web runtime specifically?

Environment Setup

Based on your setup, let's get you connected to the installation's development environment:

For Web Development:

# Install the Rive web runtime
npm install @rive-app/canvas

# Clone the gallery's project repository
git clone https://github.com/meridian-gallery/installation-2024.git
cd installation-2024

# Install dependencies
npm install

# Start the development server
npm run dev

Alex Reeves: "The development server connects to our sensor simulation system. You'll see the same inputs the real installation gets, but in a controlled environment where crashes don't matter."

Checkpoint

Alex Reeves: "Let's make sure you can see what I see. Load up the main Rive file—it's called meridian-installation.riv in the assets folder. Don't try to run it yet. Just open it in the Rive editor and tell me what you notice."

When you open the file, you should see a complex hierarchy of artboards, each containing multiple state machines. The timeline view shows dozens of overlapping animations, and the state machine panel reveals a web of interconnected logic that would make a spider jealous.

Alex Reeves: "Welcome to my nightmare. Each artboard represents a different interactive zone in the gallery. The state machines are supposed to coordinate between zones, creating those flowing light patterns Elena envisioned. Instead, they're creating chaos."

Chapter 1: The Broken Canvas

[Scene: The technical workshop buzzes with the white noise of multiple computers running diagnostic loops. Alex pulls up a chair next to the main workstation, where the Rive editor displays a maze of artboards and timelines. The complexity is overwhelming—dozens of interactive elements, each with its own animation logic, all trying to coordinate in real-time.]

You're staring at the heart of the problem. Alex's original Rive file contains twelve artboards, each representing a different section of the installation. Touch panels, motion sensors, proximity detectors—every interactive element has its own artboard with its own state machine. The artist's vision was ambitious: visitors would create collaborative light sculptures through their movements, with each person's actions influencing the entire space.

But something went wrong in the coordination. The state machines are stepping on each other, creating conflicts that crash the entire system within minutes of startup.

Alex Reeves: "I know what you're thinking. Why didn't I just build one massive state machine to control everything? Trust me, I tried that first. But with this many interactive elements, a single state machine becomes unmanageable. So I broke it down—one artboard per interactive zone, each with its own state machine. The problem is making them talk to each other without creating feedback loops."

Think First

Before we start rebuilding, I need to understand your approach to complex interactive systems:

1. When you see a Rive file with multiple artboards, how do you typically organize the state machines? Do you prefer centralized control or distributed logic?

2. What's your experience with state machine inputs and outputs? Have you built systems where one state machine needs to trigger changes in another?

3. Looking at this installation's requirements—multiple users, real-time responses, synchronized effects—what do you think is the biggest technical challenge?

4. In your opinion, should interactive elements be completely independent, or should they share some common state?

The Task

Let's start by understanding the current system's structure. Your job is to map out the existing artboards and identify the core interaction pattern.

Step 1: Inventory the Artboards

Open the meridian-installation.riv file and examine each artboard:

// Load the Rive file and inspect its structure
const riveFile = await rive.load('assets/meridian-installation.riv');

// List all artboards
const artboards = riveFile.artboards;
console.log('Available artboards:');
artboards.forEach((artboard, index) => {
    console.log(`${index}: ${artboard.name}`);
    
    // List state machines for each artboard
    const stateMachines = artboard.stateMachines;
    stateMachines.forEach((sm, smIndex) => {
        console.log(`  State Machine ${smIndex}: ${sm.name}`);
    });
});

Step 2: Examine a Single Artboard

Pick the artboard named "TouchPanel_01" and create a basic instance to understand its structure:

// Create an instance of the first touch panel
const artboard = riveFile.artboardByName('TouchPanel_01');
const stateMachine = new rive.StateMachineInstance(
    artboard.stateMachineByName('PanelController'),
    artboard
);

// Inspect the state machine's inputs
console.log('State machine inputs:');
stateMachine.inputs.forEach(input => {
    console.log(`- ${input.name} (${input.type})`);
});

Step 3: Create a Minimal Test

Set up a simple HTML canvas to display just this one artboard:

<!DOCTYPE html>
<html>
<head>
    <title>Touch Panel Test</title>
    <script src="https://unpkg.com/@rive-app/canvas@2.7.0"></script>
</head>
<body>
    <canvas id="test-canvas" width="400" height="300"></canvas>
    <button id="touch-trigger">Simulate Touch</button>
    
    <script>
        const canvas = document.getElementById('test-canvas');
        const button = document.getElementById('touch-trigger');
        
        const r = new rive.Rive({
            src: 'assets/meridian-installation.riv',
            canvas: canvas,
            artboard: 'TouchPanel_01',
            stateMachines: 'PanelController',
            autoplay: true,
            onLoad: () => {
                console.log('Single artboard loaded successfully');
                
                // Get the touch input
                const inputs = r.stateMachineInputs('PanelController');
                const touchTrigger = inputs.find(i => i.name === 'touch');
                
                if (touchTrigger) {
                    button.onclick = () => touchTrigger.fire();
                }
            }
        });
    </script>
</body>
</html>

Verification

Run your test page. You should see:

1. A single touch panel rendered on the canvas
2. The panel should respond when you click the "Simulate Touch" button
3. Console output showing the artboard structure
4. No error messages in the browser console

If the single artboard works correctly, you've isolated a functioning component from the broken system.

Alex Reeves: "Good. You can see that each individual piece works fine in isolation. The touch panel responds, the animations play smoothly, the state transitions are clean. The problem only appears when you try to run multiple artboards simultaneously."

They pull up another monitor showing the full installation running—or trying to run. Within seconds, error messages flood the console.

Alex Reeves: "Watch this. I'll start the full system now."

The installation attempts to initialize all twelve artboards at once. For a brief moment, everything seems to work—panels glow, sensors respond, light patterns begin to form. Then, cascading failures. State machines lock up. Animations freeze mid-transition. The entire system crashes.

Review

Alex Reeves: "Now you understand what I've been dealing with. Each piece is perfect. Together, they're a disaster. The question is: how do we make them cooperate instead of compete?"

The workshop falls quiet except for the hum of computers. On the main monitor, the installation sits frozen in a half-crashed state, its potential locked behind a maze of conflicting state machines. You have 71 hours to solve what Alex couldn't fix in three months.

Chapter 2: Mapping the Territory

[Scene: Maya has claimed the corner workstation, three monitors arranged in a precise arc. The left screen shows the broken installation, the center displays a clean Rive editor with a new file, and the right runs a terminal with sensor data streaming past in green text. Alex hovers nearby, defensive but curious about Maya's methodical approach.]

You've spent the last hour studying Alex's original work, and you think you understand the core problem. The installation tries to coordinate twelve different interactive zones through a web of interconnected state machines, but there's no clear hierarchy. Every artboard thinks it's in charge.

Your approach will be different. Instead of trying to fix the existing chaos, you're going to rebuild from the ground up, starting with a single, perfectly controlled interaction.

Alex Reeves: "You're starting over? Look, I know my code isn't pretty, but we don't have time to—"

Maya Chen: "We don't have time to debug a system that was broken by design. I need to understand the fundamental interaction pattern before I can scale it up. One panel, one state machine, one perfect response."

Alex Reeves: "Fine. But Elena's going to want to see progress. She's been asking about the wave effect—you know, where touching one panel triggers a cascade across adjacent panels. That's the signature interaction for the whole installation."

Think First

Before building your first state machine, let's establish the interaction design:

1. What should happen when a visitor approaches a touch panel? What about when they actually touch it? And when they move away?

2. How many distinct states do you think a single touch panel needs? Consider: idle, detecting approach, active/touched, and returning to idle.

3. What types of inputs will drive these state changes? Think about the sensors available: proximity detection, touch sensors, and timer-based transitions.

4. Should the visual feedback be immediate, or should there be smooth transitions between states?

The Task

You're going to create a new Rive file with a single, perfectly functioning touch panel. This will become the template for all other interactive elements.

Step 1: Create the Basic Artboard

Start with a new Rive file and create your first artboard:

1. Create a new Rive file called panel-prototype.riv
2. Design a simple touch panel visual—a circle or rectangle that can change color/brightness
3. Create three visual states:
   • Idle: Dim, neutral color
   • Proximity: Brighter, indicating someone is nearby
   • Touched: Brightest, with a subtle animation or pulse

Step 2: Build Your First State Machine

Create a state machine called "PanelController" with these states and transitions:

States:
- Idle (entry state)
- Proximity
- Touched

Inputs:
- approach (Trigger)
- touch (Trigger)  
- leave (Trigger)

Transitions:
- Idle → Proximity (on approach trigger)
- Proximity → Touched (on touch trigger)
- Touched → Proximity (automatically after 1 second)
- Proximity → Idle (on leave trigger)

Step 3: Test with Web Runtime

Create a test page to verify your state machine works correctly:

<!DOCTYPE html>
<html>
<head>
    <title>Panel Prototype</title>
    <script src="https://unpkg.com/@rive-app/canvas@2.7.0"></script>
    <style>
        body { font-family: Arial, sans-serif; padding: 20px; }
        canvas { border: 1px solid #ccc; margin: 20px 0; }
        button { margin: 5px; padding: 10px 15px; }
        .controls { margin: 20px 0; }
    </style>
</head>
<body>
    <h1>Touch Panel Prototype</h1>
    <canvas id="panel-canvas" width="400" height="300"></canvas>
    
    <div class="controls">
        <button id="approach-btn">Approach</button>
        <button id="touch-btn">Touch</button>
        <button id="leave-btn">Leave</button>
    </div>
    
    <div id="status">Status: Loading...</div>
    
    <script>
        const canvas = document.getElementById('panel-canvas');
        const statusDiv = document.getElementById('status');
        
        const r = new rive.Rive({
            src: 'panel-prototype.riv',
            canvas: canvas,
            stateMachines: 'PanelController',
            autoplay: true,
            onLoad: () => {
                statusDiv.textContent = 'Status: Ready';
                
                // Get state machine inputs
                const inputs = r.stateMachineInputs('PanelController');
                const approachTrigger = inputs.find(i => i.name === 'approach');
                const touchTrigger = inputs.find(i => i.name === 'touch');
                const leaveTrigger = inputs.find(i => i.name === 'leave');
                
                // Wire up buttons
                document.getElementById('approach-btn').onclick = () => {
                    if (approachTrigger) {
                        approachTrigger.fire();
                        statusDiv.textContent = 'Status: Visitor approaching';
                    }
                };
                
                document.getElementById('touch-btn').onclick = () => {
                    if (touchTrigger) {
                        touchTrigger.fire();
                        statusDiv.textContent = 'Status: Panel touched!';
                    }
                };
                
                document.getElementById('leave-btn').onclick = () => {
                    if (leaveTrigger) {
                        leaveTrigger.fire();
                        statusDiv.textContent = 'Status: Visitor left';
                    }
                };
            },
            onLoadError: (error) => {
                statusDiv.textContent = 'Error: ' + error;
            }
        });
    </script>
</body>
</html>

Step 4: Add Automatic Transitions

Enhance your state machine with timer-based transitions:

1. Add a 1-second timer transition from "Touched" back to "Proximity"
2. Add a 5-second timer transition from "Proximity" to "Idle" (in case someone approaches but doesn't touch)

Verification

Your prototype should demonstrate:

1. Idle → Proximity: Panel brightens when "Approach" is triggered
2. Proximity → Touched: Panel reaches maximum brightness when "Touch" is triggered
3. Touched → Proximity: Panel automatically returns to proximity state after 1 second
4. Proximity → Idle: Panel returns to idle if no interaction for 5 seconds
5. Smooth transitions: All state changes should be visually smooth, not jarring

Test the complete interaction flow multiple times to ensure it's reliable.

Alex Reeves: "Okay, I'll admit it. That's cleaner than anything I built. The state transitions are smooth, the timing feels natural, and it doesn't crash when you trigger it rapidly."

They lean over your shoulder, studying the state machine diagram in the Rive editor.

Alex Reeves: "But here's where it gets complicated. Elena doesn't want twelve independent panels. She wants them to communicate. When someone touches Panel 1, Panel 2 should light up slightly. Touch Panel 2, and Panel 3 responds. The whole installation should feel like one organism, not twelve separate widgets."

Maya looks up from her screen, a slight smile playing at the corners of her mouth.

Maya Chen: "That's exactly what I was hoping you'd say. This single panel isn't the solution—it's the foundation. Now we need to teach panels how to listen to each other."

Review

Alex Reeves: "The artist is coming by in an hour to check on progress. She's going to want to see the wave effect—that cascading response across multiple panels. Think your approach can handle that level of coordination?"

The challenge is clear. You have a perfect single panel, but the installation needs twelve panels working in harmony. The next step: teaching state machines to communicate across artboard boundaries.

Chapter 3: Synchronized Signals

[Scene: The workshop has transformed into Maya's command center. She's arranged three touch panels in a row on the test bench, each connected to its own sensor array. The monitors show three separate Rive instances running simultaneously, their state machines waiting to demonstrate the coordinated behavior that has eluded the installation for months.]

Elena Vasquez, the artist, arrived an hour ago and hasn't said much. She's been watching Maya work with the intensity of someone whose vision hangs in the balance. The wave effect—her signature interaction—requires perfect timing between adjacent panels.

Elena Vasquez: "In my mind, I see it like water. Touch creates ripples. Each panel responds to its neighbor, creating a flow of light across the entire installation. Not mechanical. Organic."

Alex Reeves: "That's the problem right there. 'Organic' doesn't translate well to state machines. I tried using shared variables, global timers, even external coordination scripts. Everything either created lag or crashed under load."

Maya pulls up her new approach: three identical artboards, each with the same PanelController state machine from yesterday, but now enhanced with input and output capabilities.

Maya Chen: "The key is making each panel both a listener and a broadcaster. When Panel 1 gets touched, it doesn't just change its own state—it sends a signal to Panel 2. Panel 2 receives that signal and transitions to its own 'neighbor activated' state."

Think First

Before implementing panel-to-panel communication, let's think through the coordination challenge:

1. When Panel 1 is touched, what should happen to Panel 2? Should it fully activate, partially activate, or just show a subtle response?

2. How should the timing work? Should Panel 2 respond immediately, or should there be a slight delay to create the "wave" effect?

3. What happens if someone touches Panel 2 while it's still responding to Panel 1's signal? Should the local interaction override the remote signal?

4. How do you prevent feedback loops—Panel 1 signals Panel 2, Panel 2 signals Panel 3, Panel 3 signals Panel 1?

The Task

You're going to create a three-panel system where each panel can influence its neighbors through state machine inputs and listeners.

Step 1: Enhance the Panel State Machine

Modify your PanelController state machine to include neighbor communication:

New States:
- Idle (entry state)
- Proximity  
- Touched
- NeighborActive (new - responds to adjacent panel activation)

New Inputs:
- approach (Trigger)
- touch (Trigger)
- leave (Trigger)
- neighborSignal (Trigger) - new input for receiving signals from adjacent panels

New Outputs:
- sendSignal (Boolean) - broadcasts when this panel is touched

Step 2: Create the Multi-Panel Test Environment

Build a test page that manages three separate Rive instances:

<!DOCTYPE html>
<html>
<head>
    <title>Three Panel Wave Test</title>
    <script src="https://unpkg.com/@rive-app/canvas@2.7.0"></script>
    <style>
        body { font-family: Arial, sans-serif; padding: 20px; }
        .panel-container { display: flex; gap: 20px; margin: 20px 0; }
        canvas { border: 1px solid #ccc; }
        .controls { margin: 10px 0; }
        button { margin: 2px; padding: 5px 10px; font-size: 12px; }
        .panel-group { text-align: center; }
    </style>
</head>
<body>
    <h1>Wave Effect Test</h1>
    
    <div class="panel-container">
        <div class="panel-group">
            <h3>Panel 1</h3>
            <canvas id="panel1" width="200" height="150"></canvas>
            <div class="controls">
                <button 'approach')">Approach</button>
                <button 'touch')">Touch</button>
                <button 'leave')">Leave</button>
            </div>
        </div>
        
        <div class="panel-group">
            <h3>Panel 2</h3>
            <canvas id="panel2" width="200" height="150"></canvas>
            <div class="controls">
                <button 'approach')">Approach</button>
                <button 'touch')">Touch</button>
                <button 'leave')">Leave</button>
            </div>
        </div>
        
        <div class="panel-group">
            <h3>Panel 3</h3>
            <canvas id="panel3" width="200" height="150"></canvas>
            <div class="controls">
                <button 'approach')">Approach</button>
                <button 'touch')">Touch</button>
                <button 'leave')">Leave</button>
            </div>
        </div>
    </div>
    
    <div id="log"></div>
    
    <script>
        const panels = [];
        const canvasIds = ['panel1', 'panel2', 'panel3'];
        
        // Initialize all three panels
        canvasIds.forEach((canvasId, index) => {
            const canvas = document.getElementById(canvasId);
            
            const riveInstance = new rive.Rive({
                src: 'panel-prototype.riv', // Your enhanced file
                canvas: canvas,
                stateMachines: 'PanelController',
                autoplay: true,
                onLoad: () => {
                    console.log(`Panel ${index + 1} loaded`);
                    
                    // Store reference to this panel's inputs
                    const inputs = riveInstance.stateMachineInputs('PanelController');
                    panels[index] = {
                        rive: riveInstance,
                        inputs: {
                            approach: inputs.find(i => i.name === 'approach'),
                            touch: inputs.find(i => i.name === 'touch'),
                            leave: inputs.find(i => i.name === 'leave'),
                            neighborSignal: inputs.find(i => i.name === 'neighborSignal')
                        }
                    };
                }
            });
        });
        
        function triggerPanel(panelIndex, inputName) {
            if (!panels[panelIndex]) return;
            
            const panel = panels[panelIndex];
            const input = panel.inputs[inputName];
            
            if (input) {
                input.fire();
                log(`Panel ${panelIndex + 1}: ${inputName} triggered`);
                
                // If this was a touch, signal adjacent panels
                if (inputName === 'touch') {
                    signalNeighbors(panelIndex);
                }
            }
        }
        
        function signalNeighbors(panelIndex) {
            // Signal left neighbor
            if (panelIndex > 0) {
                setTimeout(() => {
                    if (panels[panelIndex - 1]?.inputs.neighborSignal) {
                        panels[panelIndex - 1].inputs.neighborSignal.fire();
                        log(`Panel ${panelIndex}: signaled left neighbor`);
                    }
                }, 100); // 100ms delay for wave effect
            }
            
            // Signal right neighbor  
            if (panelIndex < panels.length - 1) {
                setTimeout(() => {
                    if (panels[panelIndex + 1]?.inputs.neighborSignal) {
                        panels[panelIndex + 1].inputs.neighborSignal.fire();
                        log(`Panel ${panelIndex}: signaled right neighbor`);
                    }
                }, 100); // 100ms delay for wave effect
            }
        }
        
        function log(message) {
            const logDiv = document.getElementById('log');
            logDiv.innerHTML = `<div>${new Date().toLocaleTimeString()}: ${message}</div>` + logDiv.innerHTML;
            
            // Keep only last 10 log entries
            const entries = logDiv.children;
            while (entries.length > 10) {
                logDiv.removeChild(entries[entries.length - 1]);
            }
        }
    </script>
</body>
</html>

Step 3: Implement State Machine Listeners

In your Rive file, set up the state transitions for neighbor communication:

1. NeighborActive State: Create a new state that's visually distinct from Idle but less intense than Touched
2. Neighbor Signal Transition: Add a transition from Idle to NeighborActive triggered by the neighborSignal input
3. Return Transition: Add a timer-based transition from NeighborActive back to Idle after 2 seconds
4. Priority Handling: Ensure that local interactions (approach, touch) override neighbor signals

Verification

Test the complete wave effect:

1. Touch Panel 1: Panel 1 should go to Touched state, Panel 2 should go to NeighborActive state after 100ms
2. Touch Panel 2: Panel 2 should go to Touched state, Panel 1 and Panel 3 should go to NeighborActive state
3. Touch Panel 3: Panel 3 should go to Touched state, Panel 2 should go to NeighborActive state
4. Rapid Touches: Touch panels quickly in sequence—the wave should flow smoothly without conflicts
5. Local Override: While Panel 2 is in NeighborActive state from Panel 1's signal, touch Panel 2 directly—it should immediately go to Touched state

Elena Vasquez: "Yes! That's it exactly. Watch how the light flows from one panel to the next. It's not mechanical—there's a rhythm to it, a natural progression."

She touches the panels in sequence, creating waves of light that ripple across the test setup. For the first time since arriving, she's smiling.

Alex Reeves: "I have to admit, that's elegant. Each panel maintains its own state but listens for signals from its neighbors. No central coordinator, no shared variables that can get corrupted. But Maya..." They pause, looking concerned. "This is just three panels. The real installation has twelve panels, plus motion sensors, plus proximity detectors. What happens when you scale this up?"

Maya saves her work and turns to face both of them.

Maya Chen: "That's exactly what we're about to find out. Elena, I need you to help me understand the full interaction design. It's not just about panels talking to panels, is it? The motion sensors need to influence the panels too. And the overhead proximity detectors—they're supposed to create those ambient light patterns when people move through the space."

Elena Vasquez: "The installation should feel alive. When someone enters the room, the whole space should subtly acknowledge their presence. When they approach a panel, the nearby elements should anticipate their interaction. And when they touch..." She gestures at the wave effect still playing across the test panels. "When they touch, the entire installation should respond."

Review

Alex Reeves: "The artist loves it, but I'm worried about what happens tomorrow when we try to integrate this with the real sensor hardware. We've got proximity sensors, motion detectors, touch surfaces, and overhead tracking—all feeding data into the system simultaneously. Your elegant three-panel setup is about to meet the chaos of the real world."

The test panels continue their gentle wave pattern, but Maya can see the challenge ahead. Three coordinated panels are just the beginning. The real installation needs to handle dozens of simultaneous inputs while maintaining the organic flow Elena envisions.

Chapter 4: The Cascade Failure

[Scene: The installation space is alive with activity for the first time in weeks. All twelve panels are mounted and connected, motion sensors sweep the room with invisible beams, and overhead cameras track movement patterns. Maya's coordination system worked perfectly in testing, but now, with the full sensor array active and Marcus Torres running stress tests with multiple simulated visitors, everything is falling apart.]

It's 2 AM, eighteen hours before the exhibition opening. What started as a triumphant full-system test has devolved into a debugging nightmare. The wave effects work beautifully when triggered individually, but when multiple visitors interact simultaneously, the state machines lock up in impossible configurations.

Marcus Torres: "Look at this. Visitor simulation A approaches Panel 3 while simulation B is still interacting with Panel 5. Panel 3 goes to proximity state, but then it receives a neighbor signal from Panel 4, which received a signal from Panel 5. Now Panel 3 is trying to be in proximity state AND neighbor-active state simultaneously."

Alex Reeves: "This is exactly what I was afraid of. Your elegant solution works great in isolation, but real-world usage creates edge cases you never anticipated. Multiple users, overlapping interactions, sensor noise—it's chaos."

Maya stares at the state machine debugger, watching dozens of conflicting signals cascade through the system. Each panel's state machine was designed to handle one interaction at a time, but the real installation generates dozens of simultaneous inputs.

Maya Chen: "The problem isn't the coordination—it's the assumption that each panel can only be in one state at a time. But that's not how the real world works. A panel can be responding to a neighbor signal while simultaneously detecting an approaching visitor."

Think First

The current crisis reveals a fundamental flaw in the state machine design. Consider these questions:

1. How can a single panel handle multiple simultaneous conditions? For example, what if someone approaches Panel 3 while it's still responding to a neighbor signal from Panel 2?

2. Should different types of inputs have different priorities? Should a direct touch always override a neighbor signal, or should they combine somehow?

3. How do you prevent state machine deadlocks when multiple panels are signaling each other in complex patterns?

4. What's the difference between a panel's "interaction state" (idle, proximity, touched) and its "influence state" (responding to neighbors, environmental sensors)?

The Task

You need to redesign the panel state machines using nested state machines and boolean logic to handle multiple simultaneous conditions.

Step 1: Design Hierarchical State Machines

Create a new state machine architecture with two levels:

Main State Machine: "PanelController"
├── Nested State Machine: "InteractionStates"
│   ├── Idle
│   ├── Proximity  
│   └── Touched
└── Nested State Machine: "InfluenceStates"
    ├── None
    ├── NeighborActive
    └── EnvironmentalActive

Boolean Inputs:
- hasVisitor (Boolean) - true when someone is in proximity
- isTouched (Boolean) - true when panel is being touched
- neighborActive (Boolean) - true when receiving neighbor signals
- environmentalTrigger (Boolean) - true when motion sensors detect activity

Step 2: Implement Nested State Machines

Create a new Rive file called hierarchical-panel.riv with nested state machine logic:

// Example of how the nested state machines should work together
const panelLogic = {
    // Main controller coordinates between nested machines
    mainController: {
        // Interaction state machine handles direct user interaction
        interactionStates: {
            currentState: 'Idle',
            transitions: {
                'Idle': {
                    'hasVisitor becomes true': 'Proximity',
                    'isTouched becomes true': 'Touched'
                },
                'Proximity': {
                    'hasVisitor becomes false': 'Idle',
                    'isTouched becomes true': 'Touched'
                },
                'Touched': {
                    'isTouched becomes false': 'Proximity',
                    'hasVisitor becomes false': 'Idle'
                }
            }
        },
        
        // Influence state machine handles external signals
        influenceStates: {
            currentState: 'None',
            transitions: {
                'None': {
                    'neighborActive becomes true': 'NeighborActive',
                    'environmentalTrigger becomes true': 'EnvironmentalActive'
                },
                'NeighborActive': {
                    'neighborActive becomes false': 'None'
                },
                'EnvironmentalActive': {
                    'environmentalTrigger becomes false': 'None'
                }
            }
        }
    }
};

Step 3: Create Multi-Condition Test Environment

Build a comprehensive test that simulates complex real-world scenarios:

<!DOCTYPE html>
<html>
<head>
    <title>Hierarchical State Machine Test</title>
    <script src="https://unpkg.com/@rive-app/canvas@2.7.0"></script>
    <style>
        body { font-family: Arial, sans-serif; padding: 20px; }
        .test-container { display: flex; gap: 30px; }
        .panel-section { flex: 1; }
        canvas { border: 2px solid #333; margin: 10px 0; }
        .controls { margin: 10px 0; }
        .control-group { margin: 15px 0; padding: 10px; border: 1px solid #ccc; }
        .control-group h4 { margin: 0 0 10px 0; }
        button { margin: 2px; padding: 8px 12px; }
        .active { background-color: #4CAF50; color: white; }
        .status { font-family: monospace; font-size: 12px; margin: 10px 0; }
    </style>
</head>
<body>
    <h1>Complex Interaction Test</h1>
    
    <div class="test-container">
        <div class="panel-section">
            <h3>Panel State</h3>
            <canvas id="panel-canvas" width="300" height="200"></canvas>
            
            <div class="control-group">
                <h4>Direct Interaction</h4>
                <button id="visitor-toggle">Toggle Visitor Presence</button>
                <button id="touch-toggle">Toggle Touch</button>
                <div class="status">
                    Visitor: <span id="visitor-status">false</span><br>
                    Touch: <span id="touch-status">false</span>
                </div>
            </div>
            
            <div class="control-group">
                <h4>External Influences</h4>
                <button id="neighbor-toggle">Toggle Neighbor Signal</button>
                <button id="environmental-toggle">Toggle Environmental</button>
                <div class="status">
                    Neighbor: <span id="neighbor-status">false</span><br>
                    Environmental: <span id="environmental-status">false</span>
                </div>
            </div>
            
            <div class="control-group">
                <h4>Stress Test</h4>
                <button id="random-test">Random Input Test</button>
                <button id="stop-test">Stop Test</button>
            </div>
        </div>
        
        <div class="panel-section">
            <h3>State Machine Debug</h3>
            <div id="state-debug" class="status"></div>
            <div id="event-log" class="status"></div>
        </div>
    </div>
    
    <script>
        let pan

…(truncated)