manim-dsa-storytelling

Manim DSA Storytelling (brute-force vs optimized)

Relationship to manim-explainer-animations

This is a companion skill, not a replacement. Before writing any scene:

1. Read manim-explainer-animations/SKILL.md and its references/ — it owns the API surface (mobjects, animations, camera, plotting, text, advanced techniques).
2. Use this file for the story shape: how a brute-vs-optimized comparison should be beat-by-beat, which 3D solids map to which data-structure ideas, and how to stage particle-based data flow so it reads as "the algorithm thinking," not decoration.

The narrative shape (5 acts, ~45-90s total)

A DSA comparison video is a small argument, not a code dump. Every beat exists to answer one question: why does the optimized version win, and what is it doing differently?

1. Cold open — the problem, spatially. State the problem as a shape in 3D space before any code appears (e.g. an array as a row of glowing cubes on an axis, a graph as a torus/mesh of nodes). No numbers yet — just "here is the space we're searching."

Code-and-visual duality (non-optional)

The point of this format is that someone can watch it and then go reproduce the algorithm — not just enjoy an abstract animation. Every beat that demonstrates brute-force or optimized behavior MUST show the real source alongside the visualization, not describe it in prose:

• Use a Code mobject (see manim-explainer-animations/references/text-and-typography.md) loaded with the actual source — code_string= copy-pasted from the real file, not a paraphrase. If the brute-force version doesn't exist in the source repo, write a standard, idiomatic baseline and say so in an on-screen or narration note — never invent an unfaithful "optimized" version either.
• Split-screen layout: Code panel fixed in frame on one side (e.g. left third/half via add_fixed_in_frame_mobjects + to_edge(LEFT)), the 3D data-space visualization occupying the other side. Shift the 3D group (axes + solids) toward the free side so neither overlaps the code.
• Sync a highlight, don't just display static code: keep a SurroundingRectangle (or similar) over code_obj.code_lines[i] and move it to track whichever line the animation is currently acting out — the comparison line during a brute-force hop, the update line when a running value changes. The highlight is the bridge between "watching a shape move" and "understanding what the code just did."
• Swap panels between brute-force and optimized beats (FadeOut old Code, FadeIn new Code) — don't try to Transform between two different algorithms' source, it reads as morphing nonsense.
• If the code is too long to read in the time budget, trim to the relevant function only (still the real function body, not a summary) rather than shrinking font past legibility.

1. Brute force — show the search, don't just say it's slow. Animate the brute-force approach as an exhaustive particle sweep: a particle (or swarm) visiting every candidate — every pair, every subarray, every path — using nested loop-driven animations so the O(n^2) or O(n^3) cost is felt as visibly more particle-trips, not just stated in a caption.
2. The insight. A single beat, usually text + a highlighted subset of the 3D space, naming the one fact the optimized algorithm exploits (a running sum, a seen-set, a monotonic property). This is the hinge of the whole video — give it a full breath, don't rush past it.
3. Optimized — show the shortcut, same space. Re-run the same problem in the same 3D space, but the particle path is short, direct, and often single-pass. Reuse camera angle and axes from beat 1 so the contrast is legible as "same space, different path" rather than "different scene."
4. Payoff — the complexity graph. Cut to a 2D plot of both curves (O(n^2) vs O(n), or whatever applies) as input size grows. Let the optimized curve visibly separate from the brute-force curve — this is the "receipts" beat. End on the gap, held.