Hitchhiker Avatars are animated, speakable characters (Marvin, Ford, Zaphod, Trillian, a Vogon clerk, a BabelFish, or entirely new Hitchhiker originals) that can deliver guidance, explain tools, narrate lessons, and host “guided journeys” through the Hitchhiker universe and projects.
The goal is not “a mascot video” but a reusable character system: one avatar can appear across many pages, episodes, and contexts, with consistent voice, look, and behaviour.
We take inspiration from the emerging “avatar production studio” idea (treating avatars like a serious creative pipeline: design, staging, performance, direction, operations) and translate it into a federated, local-first Hitchhiker Studio workflow that many Guide Writers can use without needing to be VFX specialists - unit1.studio 
# The core shift
Instead of “one team makes one video”, we build “one character system that many writers can script”. A Guide Writer should be able to fork an episode page, edit a short scene script, press render, and get a shareable video clip that can be embedded back into the wiki.
This implies we treat avatars as shared infrastructure: character packs, voice packs, motion packs, scene templates, and a small scripting language that sits comfortably inside Federated Wiki pages.
# Federated avatar factory
A practical architecture for a federated Hitchhiker Studio looks like this: - A wiki page is the source of truth for each character, episode, and scene. - Assets live in the wiki “assets” system (images, rigs, audio, motion, backgrounds, fonts, subtitles). - A renderer (local machine, homelab box, or community render node) turns a page’s script + assets into a video. - The resulting MP4/WebM/GIF is stored back as an asset, and the page embeds it as the canonical clip.
This is the same “many authors, many forks, one shared method” philosophy as the rest of Hitchhikers, but applied to moving characters.
# What we borrow from others
Unit1 positions avatar performance as an end-to-end craft: realistic avatar creation, staging, creative direction, and the operational reality of repeated shows - unit1.studio
We adopt the *structure* rather than the exact production style: treat avatars as “performers” with repeatable stagecraft, so our guides feel coherent across many clips, and so Guide Writers can focus on writing and direction rather than reinventing the pipeline each time.
For context on how this idea is being framed publicly (avatar concerts, lifelike performers, reduced cost/time via modern VFX and AI-enhanced CGI), see - thestage.co.uk
# Minimum “Avatar Pack” Every Hitchhiker Avatar should ship as a small, versioned pack with a clear contract. - Character bible (tone, catchphrases, taboo lines, emotional range, how they address “the reader”). - Model or rig (2D puppet, 3D rig, or stylised sprite set). - Voice (recorded voice set, a community voice actor, or a synthesised voice with explicit consent). - Motion set (idle, point, shrug, walk-in, laugh, “Marvin sigh”, etc.). - Scene skins (transparent background, cockpit, classroom, wiki-lab bench, starfield). - Subtitle style (font, size, safe margins for mobile). A pack must be remixable by forks, but also “stable enough” that old episodes still render in the future.
# Guide Writer workflow A Guide Writer experience can be as simple as this. - Fork an episode page (or start a new one). - Choose an avatar and a scene template. - Write a short scene script (dialogue + actions + camera notes). - Preview as animatics (fast low-res render). - Render final video (higher quality). - Publish by embedding the clip back into the wiki page. The important design constraint is that writing stays inside the wiki page, so the creative work remains forkable, reviewable, and remixable.
# Tiny scripting format We want something that feels like stage directions, not programming. Here is one possible “Hitchhiker Scene Script” style. - Scene metadata: avatar, background, duration target, subtitle on/off. - Dialogue lines: “who says what”. - Simple actions: look-at, gesture, enter, exit, pause, emote. - Camera hints: wide, medium, close, pan-to, hold. The renderer translates this into whatever engine we use (2D puppet system, Blender/Unreal timeline, or a video-generation backend), but the writer never has to see that complexity.
# Federation: how avatars evolve without breaking everything Because this is federated, different pods will improve the same character in different ways. We need a gentle rule set. - Episode pages pin the exact Avatar Pack version they were rendered with. - New pack versions are opt-in upgrades (a writer can re-render if they want the new look). - Packs can declare compatibility (v1.2 is compatible with v1.0 scripts). - Pods can maintain “official” packs (stable) and “experimental” packs (wild). This lets the culture stay playful without turning the archive into a rendering graveyard.
# Rights, ethics, and safety If we use characters from The Hitchhiker’s Guide, we must be careful: names, likenesses, and recognisable designs can be protected by copyright and trademark, and permissions may be needed for anything public-facing or commercial. A safe starting path is to create “Hitchhiker-adjacent originals” (new Guide characters) and treat canonical characters as internal prototypes until licensing is resolved. For voices and faces, we need an explicit consent standard. No cloning of a living person’s voice, and no “archival reconstruction” of a dead performer, without documented permission and governance. We can still build wonderful avatars using original designs and volunteer voice actors.
# First prototype: one character, three templates, forty-two scripts A good first build is deliberately small. - One avatar (a brand-new Hitchhiker Guide character). - Three scene templates (transparent, cockpit, classroom). - A micro motion set (idle, point, nod, shrug, sigh). - 42 tiny scripts written by Guide Writers (so we test the writing workflow, not just the tech). - A “render-back” loop that stores the video as a wiki asset and updates the page.
Once that loop works, adding more characters becomes culture and craft rather than a new engineering project each time.
# See - Guide Writers and Field Researchers