Dev journey

How a programmer who can't paint makes game art

This is the longer story behind the studio: where the ideas come from, why they used to stay ideas, and the tools I built so they don't have to anymore.

Lots of ideas, one missing skill

I'm a software engineer, with a computer science background. Writing code is the part of making games I'm comfortable with: systems, rules, tools, the stuff that has to work. I also have more game ideas than I'll ever have time for. Some of them took months to get from a note to a prototype, some of them years.

What always stopped me was the art. I can sketch a pose, a shape, a rough idea of a character. I can't turn that into a finished picture, and a game needs hundreds of them: enemies, cards, rooms, icons, each one in the same style as the others.

Sketch first, always

Every character still starts the old way, as a scribble: the pose, the props, what it's supposed to feel like. That part stays mine. Then it goes through the steps below, and comes out the other end as pixel art that sits in the game next to everything else.

The art engine

The art engine is my own tool. It runs on my own computer, and it's where my sketches and ideas get turned into game assets. It works in two halves:

1. From scribble to a detailed picture. An AI image model takes the sketch and the idea and paints a detailed version. I trained a small style model on art I had already approved for the game, so new pictures come out looking like they belong. It makes a few candidates, and I pick one or send it back.
2. From picture to pixel art. Then my own pixel art converter takes over. It isn't AI, just image processing I wrote: one pixel size for each kind of art, one colour palette measured from the main character, a limit on colours, one dark outline, and clean-up of stray pixels. It also checks its own work, for example that thin parts like a staff, a tail or a bow string didn't get lost when the picture got smaller.

The split matters. AI is good at detail and bad at consistency: ask it twice and you get two different styles. Code is the opposite. So the AI does the painting, and the programming makes sure every sprite has the same pixel size, the same palette and the same finish, whether it was made in the first month or last week.

A real example: Halvard

Halvard runs the shop in Bone Parish: a man slowly turning into a skeleton, and not entirely sane about it. The idea was a shopkeeper halfway between alive and dead, talking to a skull. The engine painted a few versions; I picked the first one, and the converter turned it into the sprite you see in the game.

→

It's not "press a button, get a game". Most of the work is still deciding what something should look like, throwing away the versions that don't fit, and fixing what the tools get wrong. The engine just means that an idea doesn't have to wait for a skill I don't have.

The people who play it first

A small group of friends and family test everything. They play builds that are unbalanced, half-finished or simply broken, and they tell me so. Their honest notes are a big part of how the game moves forward.

What's next

Dancing Tree Studio is official now. Bone Parish is in closed alpha in the browser, and versions for Steam and Android are coming. After that, the next idea gets its turn. The goal isn't one big game every few years; it's a steady line of smaller ones, each finished properly.