← Project Management · Visual Information

Case Study

One File That Travels

A 20 Below character is a single file. It moves between the Character Creator, the Battle Tracker and the character sheet in Owlbear Rodeo, and it gets passed around the table. When characters needed pictures, the picture had to travel the same way: inside that one file, shown the same way in every tool, and safe to open whoever made it. It was asked for, built, tested and released in one morning. The study is also honest about the part it didn’t reach.

Role

Producer: the request, the decision and the release ruling.

Team

Claude (AI assistant).

Timeline

One morning, 28 September 2026: asked at 08:11, released at 10:35.

Result

A character’s picture travels inside its file, to the Creator, the Battle Tracker and the Owlbear sheet, released in four tools at once.

The Problem

I was setting up an Owlbear Rodeo room for a portfolio video shoot. The Battle Tracker’s button for putting a character on the map placed nothing, even after a reload. The tokens had to be drawn, uploaded and linked by hand. That bug was logged as its own task instead of being fixed mid-shoot, but it raised a better question. Why doesn’t a character already carry its own picture?

The tracker could already pair an image with a character file when both were picked together, Wolf.json beside Wolf.png. But that means two files picked at once, every time, and the picture reached only the tracker. Nothing in the Creator or the Owlbear sheet knew what a character looked like.

Analysis: Who It’s For

My question at 08:11 was simple: “Is it possible to bundle icons with the JSONs and have the extension load them? … Automatically?” Four options were weighed. Five minutes later, the decision was one sentence: “Build the Portrait field.”

Design Decisions

One file carries the character

The portrait lives inside the character file, set once in the Creator on the Name & Concept step or beside the sheet’s heading. Wherever the file goes, the picture goes with it. The Battle Tracker shows it in its Catalog and its encounters from the file alone. Saved encounters and exports carry it too. The Owlbear sheet shows it beside the name. Nobody has to pick a second file.

Any picture in, the same portrait out

A player can pick any picture, of any shape. Every place a portrait appears is a circle or a small square, so the Creator keeps the centred square and re-encodes it at 256 by 256 pixels. That’s more than twice the largest size any tool shows it at, so it stays sharp on a high-density screen. One source picture serves every size, from 96 pixels on the Creator’s first step down to 34 in a tracker row. With no portrait, each tool falls back to the character’s initials.

A file from the table is untrusted

Character files are made by players and passed around, and each tool puts the portrait straight onto the screen. So one shared check decides what counts as a portrait. It accepts PNG, JPEG, WebP or GIF image data, up to 400 kB. It refuses:

• SVG, which can carry more than a picture;
• a link to a picture on someone else’s server;
• text that only claims to be an image;
• anything too large.

Anything refused counts as no portrait, and the file still opens. A picture picked in the Creator is re-encoded even when it’s already small, so what the Creator writes is always a plain image and nothing else.

What was chosen on purpose still wins

The old pairing wasn’t removed. If a GM picks a picture alongside a character file, that picture is used, because someone chose it deliberately. The portrait inside the file fills in only when nothing else was given.

Say where it stops

Two things were left out, on purpose, and said out loud.

• Map tokens. A token on Owlbear’s map needs its picture as an Owlbear asset, not an image tucked inside a file. That morning’s answer was that an extension couldn’t get it there. While writing this study, a check of Owlbear’s own extension API showed that it can, through an import dialog the player confirms. That route is now the plan for the token fix. Until it’s built, a portrait becomes a token by uploading it once and linking it in the tracker.
• The printed character sheet. Its artwork is a designed page, so a portrait on it would need a design change. That wasn’t made without a design ruling.

How the Work Ran

• About ten minutes from decision to tested. One shared check, the Creator’s crop, and the portrait in all three tools. Then browser tests of the crop, a non-image file, a portrait from the file alone, and a hostile file refused everywhere.
• Held for review. Screenshots of all three tools went to me first, and nothing was committed until I’d seen them.
• A bug logged, not chased. The broken token button that started this became its own task instead of widening the feature.
• Released everywhere at once. The Character Creator v0.12.34, the Battle Tracker v0.3.4 and both Owlbear extensions went out by 10:35, the same morning as the retirement of the Novice tier. That shared release is where two parallel workstreams overlapped, told in The Rung That Made Players Worse.
• A wrong answer corrected in the open. The claim that map tokens were out of reach was checked against Owlbear’s extension API while this study was being written, and it was wrong. The correction changed the token fix’s plan.

Outcome

A character now carries its own picture. It’s set once in the Creator, framed the same way everywhere, and shown in the Creator, the Battle Tracker and the Owlbear sheet with no second file. A file from the table can’t slip anything but a plain picture onto the screen. The part that isn’t done, map tokens, has a named route and a task behind it.

What this doesn’t show yet is players using it. The next sessions will show whether portraits get set, and whether the GM’s tracker reads faster for them.

Credits

The request, the decision and the release ruling	Me, as producer
Options, Package Deliverables, tests and figures	Claude (AI assistant), checked by me