Sunday, Bloody Sunday

I am a digital designer. Screens are my native habitat. I know how pixels work, how RGB color spaces behave, how a design scales across breakpoints. I have been doing this professionally for years. And for most of that time, print has quietly terrified me.

Not in a way I'd admit out loud. Just a low-grade avoidance. Bleed. Safe area. DPI. CMYK. Resolution at scale. These words would surface and something in me would find a reason to hand the file to someone else or just not engage. Print felt like a different discipline with its own arcane rules, and I had enough discipline already.

Today that ended. The first custom tile order for Blue Prince Board Game shipped from BoardGamesMaker.com. 110 unique room tiles, 40×40mm, matte smooth finish, double-sided. And it turns out I didn't die getting there.

Why print is hard for digital designers

Most designers who work in print came up through print. They learned the vocabulary before they learned the tools. For them, "bleed" isn't a concept to understand — it's just the thing you always do. The fear of getting it wrong is already baked out of the process.

Digital designers run the reverse path. We come up through screens, where there is no physical substrate, no cutting machine, no margin for error on a press run. When something looks wrong on a screen, you fix it in seconds. When something is wrong on a print run, you've already paid for it and it's already sitting in a box on your doorstep.

That asymmetry — the irreversibility of print — is where the intimidation lives. It's not the concepts themselves. Once you actually sit with them, they make complete sense. It's the stakes.

The source art problem

Blue Prince Board Game's tile images come from the video game. Dogubomb built a gorgeous game with beautiful room art — but it was designed for screens, not print. Screen art lives at 72–96 pixels per inch. Print needs 300.

When we extracted the tile images from a PDF, they came out at 512×512 pixels. That's a 40mm tile at roughly 300dpi — technically sufficient — but those 512 pixels were screen-resolution pixels. The underlying detail was designed for a much smaller display context. There's a ceiling on how sharp this art can be at physical size, and we hit it.

The half-pixel problem

While trying to align tiles in Figma, something happened that I've noticed for years and never had a satisfying explanation for. The tile image wouldn't align cleanly to my guide boxes. It sat slightly off — not by a full pixel, but by what looked like half a pixel. No matter what I did, it wouldn't snap flush.

The explanation, it turns out, is simple and has been baffling digital designers forever. When an image has an odd pixel dimension — say, 457px — and you place it inside a frame with an even dimension, or position it at a coordinate that doesn't land on a whole number, the rendering engine has to decide what to do with the edge. It can't light up half a pixel. So it anti-aliases: it blends the edge pixel with whatever is behind it, splitting the color value across two pixel rows. The result looks like a soft, slightly-off edge that you cannot align cleanly, because there is literally no whole-pixel position that resolves it.

The underlying cause here was the source tiles from the PDF — they weren't square, and they weren't even pixel dimensions. Placing them into square Figma frames was producing a fractional remainder that the renderer had to absorb somehow. The fix wasn't alignment — it was stopping the fight entirely. Python crops the tiles, resizes them to exact square dimensions using Lanczos resampling, and outputs clean integers. No Figma, no half-pixels, no unsolvable alignment puzzle.

If you've ever had a design element that looked ever-so-slightly blurry or wouldn't snap no matter what you tried — this is probably why. Check whether your object dimensions and position coordinates are all whole numbers. If anything is fractional, round it. The renderer is not lying to you. It's doing math you can't override by dragging.

This is not a complaint about the source material. It's a structural reality of adapting a screen-native game to physical form. Every time we think the art problem is solved, we discover another layer of it. The upscaling is the best available answer given the source. We made peace with it and moved on.

The technical pipeline

Here's exactly what it took to get 110 tiles from source PDFs to a print-ready file upload, for the record.

The bleed number — 50px — deserves a note. At 660px = 40mm, the conversion is 16.5px per mm. BGM requires 3mm bleed, which is 49.5px — rounded to 50. That 50px border on all four sides brings the submitted file from 660px to 760px, representing 46×46mm total (40mm tile + 3mm bleed on each side). The cutting machine trims back to the 40mm tile area. The bleed exists only as insurance.

One thing the pipeline does not change: the door notches on the tile edges are correct. The notches sit flush to the tile edge at x=0 — which means they land exactly on the cut line. The bleed border extends the background color outward beyond that. If the cut is slightly off, the background color absorbs the error. The notch geometry stays correct relative to the cut line.

BoardGamesMaker.com — an honest assessment

BGM is a real option for small-run indie game production. No minimum order, no setup charges, surprisingly competitive pricing — 110 unique custom tiles shipped for under $50. That number opens possibilities.

Their system is archaic. The online designer is old software. The workflow of dragging images one at a time onto numbered slots is tedious. The product configurator is confusing about what size you're actually configuring. The template downloads are for Adobe Illustrator. I hadn't opened Illustrator since school.

Worth it. Once you understand the system, it works. And the pricing — if the quality matches — changes the calculus for what you can afford to iterate on in physical form.

What's not on these tiles yet

This order is fronts only. The tile back is an open design problem — and a more interesting one than I expected. The working spec for the back includes three elements: a QR code linking to a mobile room reference page, the gem cost for drafting that room, and a category tag for setup sorting. But those three things require 110 unique QR codes pointing to 110 pages that don't all exist yet. That's a separate build, and a separate order.

The fronts ship first. You playtest with what you have. The backs come when the system is ready. This is not a compromise — it's the right sequencing. Trying to build everything at once is how you ship nothing.

The thing I didn't expect to feel

Somewhere in the middle of this session — somewhere between the third Python script and the moment BGM confirmed the order — I looked at a blank tile template for poker cards on their website and felt something I wasn't prepared for. Not relief. Something more like possibility.

There is a whole world of physical game components that can be made at small scale, cheaply, with reasonable quality. Tiles. Cards. Dice. Boxes. Mats. Each one has its own template, its own bleed requirement, its own quirks. And none of them are as hard as they look from the outside. The intimidation is the system. Once you're inside the system, you see how it works. And once you see how it works, you start imagining what else you could make.

Most designers who work in print started there and moved to digital. I went the other direction. I came up through screens and arrived at paper late. I don't think that's worse — I think it just means I notice the translation in a way that print-native designers stopped noticing years ago. Every step in this pipeline that felt confusing was confusing for a reason. Bleed doesn't make instinctive sense until you've seen what happens when a cutter runs a millimeter off-center. DPI doesn't matter until you've printed something at the wrong resolution and seen what soft actually means on paper.