How It Was Built

Building a living mansion

The technologies, the processes, and the custom tools behind Mosferatu.

A cutaway view of the rooftop conservatory: a glass roof, planters, a central fountain and a red-carpeted staircase.
The rooftop conservatory, at the top of every descent. Art-review view, with the interface and discovery fog hidden.

01 / The toolchain

What this was actually built with.

Mosferatu was made by one person working as a studio: a small set of services, a larger set of purpose-written tools, and a full-time job and a life running alongside it. Every generation was reviewed before it entered the game. This page describes the whole toolchain, so I will name it plainly first.

Godot 4The engine, with all game code written in GDScript. Both camera layers, every system and every developer tool on this page run inside it.
BlenderRigging, weight repair and authoring animation on generated meshes, driven headless from scripts.
Meshy.aiImage-to-3D generation. Meshy turned a written brief and its reference image into the geometry, textures and skeleton for characters, creatures, props and architecture.
OpenAI image generationThe image model that produced concepts, textures, UI art and cover artwork from the written briefs, through the OpenAI API.
OpenAI Codex, Sol and AstraThe coding agents and models that wrote much of the game code, tests and tooling, under the studio's direction.
SunoMusic generation. Twenty-one tracks were generated and then selected, one at a time, for the house.
ElevenLabsSound effects and voiceover, through the ElevenLabs API, covering both the in-game audio and the trailer narration.
Headless ChromeRenders the art book to PDF at print size, and drives the layout probe that gates the export.
FFmpegEverything downstream of capture: encoding the album, and cutting, mixing and mastering the trailer.
DeepSeekModels used to write and orchestrate the project's tooling.

Some of those tools wrote code, and others made pictures, models and sound. The reaction to each is not the same. Writing code is creative work and it is somebody's job, and coding agents are trained on other people's code just as image and music models are trained on art. It attracts less objection partly because the work is less widely understood as creative, and partly because agents are still seen as assisting a developer rather than replacing one. That second reading is only partly true.

Art and music are treated as innately human in a way that code is not, and those are the jobs being displaced in the most visible way. Where all of this ends is not clear. The tools exist, and so does the ability to tell stories with them. They can widen who gets to make things, or they can be used to take from the people who already do.

Chapter two is about which parts of this are human.

02 / Who made what

The concept is a person's. So is every decision.

This page names a lot of generation services, so being exact about what they did and did not do is necessary. No service designed this game. The mansion, the two-layer structure, the descent, the blood-and-Focus economy, the decision to make feeding a rhythm game against a heartbeat, the choice that being seen should break a solved puzzle. Those are a person's ideas, and they are the reason the game is worth playing.

What the services supplied was material. A written brief became an image, an image became a mesh, a brief became a sound effect. Some of that material was itself machine-written: the coding agents wrote much of the game code, most of the automated tests and capture tools, and a good share of the documentation. What none of them did was decide what any of it should do. The architecture, the mechanics, the generation rules and the art direction were specified by a person and checked by one. The agents are prosthetic hands; the direction is not.

The selecting is where the character of the work lives, and it never stopped. Meshy returned a mesh for every image it was given, and the ones that were usable still had to be rigged, repaired, re-weighted, retextured to a budget and checked against a contract before the game could place them. ElevenLabs returned a performance for every brief, and each effect was auditioned against its brief and regenerated if it failed. Suno returned tracks, and someone listened to them and chose twenty-one. Someone also had to decide the spider should be faceless, the cat should be orange because a black cat is invisible in a dark room, and that a guest bedroom may never open directly into another one, and then write that rule down so the generator would obey it.

Using these services does not make a project less authored. It changes which parts are authored, and that distinction is easy to lose. The judgement moves up a level. Instead of drawing a chair, you specify what a chair must be, generate twelve, and know which one is right. The work does not disappear. It becomes selection, direction and refusal, and it is still a month of work around a day job, every spare second of it. It got to the point where sleep meant rotating inside a room, looking for the way out. That is why the rejected results are kept beside the accepted ones, and why the reason for a rejection is written down as carefully as the brief that started it.

A build-activity chart: one row per repository, one cell per day, shaded by how many commits that day carried. The game row is filled almost end to end, while the art book and website rows fill only at the far right.
The shape of the work. One cell per day, shaded by how many commits that day carried, across the game, the art book and this website. Sustained and uneven rather than a single burst: the art book and the site land in the closing stretch as the game settles.

Tens of thousands of lines of game code, three hundred automated tests, seventy-two capture tools and ninety-odd documents are not a claim about authorship. They are a description of how much has to exist before a game of this size stands up, and they are the reason one person can now finish something that would previously have needed a team. What a person supplied was the concept, the direction, and the refusal.

The clearest example is the art book, where every caption was checked by hand against the source that could settle it, and the ones that could not be supported were marked as such. That audit was done by a person, not generated, and it exists because the writing a model produces is fluent and plausible whether or not it is true. It is also why the claims on this page can be taken as read.

03 / Where it came from

The name came first.

Before any of the toolchain above, there was a word. Mosferatu, a play on Nosferatu, and from that word the whole shape of the thing followed. If the vampire is the monster of the house, then the smallest thing in the house is the mosquito, and a mosquito has exactly one business with a body.

So the concept arrived almost whole: an ordinary mosquito gets into a gothic mansion, feeds on the people inside it to survive, and works its way down through the floors until it reaches the vampire lord buried at the bottom. Drink that blood and the mosquito becomes immortal. The absurdity is the point. It is a small, mundane, deeply irritating animal setting out to take the oldest monster in fiction apart one bite at a time.

Part of the appeal was how little company there was. Looking for other games built around a mosquito turns up one classic, Mister Mosquito, and a handful of others that use the insect in some way. None of them takes a mosquito through a gothic mansion, feeding on its inhabitants to survive the descent. Vampires, mansions and the road down into a crypt are well-worn ground, and doing it at the scale of an insect, with feeding as the whole spine of the game, is not.

04 / The game

A mosquito in a house built for people.

Mosferatu is a seeded gothic puzzle-action roguelike. You are an ordinary mosquito that comes in through the upper windows of a vampire mansion, and you feed your way down through its floors to reach the vampire buried at the bottom. Drink its blood and you become immortal.

The whole game is built on one idea: information is what you are short of, and feeding is what costs you it. It is played in two layers over the same 3D rooms.

In the overview, an orthographic camera looks into a cutaway of the room. Most of the floor is under fog. You scout it with two senses drawn from the insect itself. A carbon-dioxide pulse maps a wide area around any breath or flame. A thermal ping briefly resolves a body's posture and the places on it worth biting. Perches are the surfaces a mosquito can rest on and cross to. You chain them into a route and hold Travel to slow time while you read the room. Household routines run on continuous seeded schedules, so a sleeping person is a pattern you can learn and plan around.

Then the strike takes over. Committing a route that ends on a person drops you out of the plan and into first person, along a banked swing-dive from the last perch into the body. The person keeps whatever pose they were in, and at that scale the body is terrain: breath moves like weather, a hand is a wall, and skin is something you have to cross. Feeding is pulsed to the heartbeat, one beat at a time, and every extra beat is more blood and more risk. Get seen and the routine breaks. People wake, search, fetch tools and warn each other, and the puzzle you had solved stops being solvable in advance.

That reversal is the design centre. While you are hidden the house behaves like clockwork. Once it is awake, it behaves like a house with a mosquito in it.

The sensory premise is stylised, but it is grounded in published mosquito host-seeking research into how the insects combine carbon dioxide, odour plumes and thermal cues to find a body. The game leans on that combination rather than inventing a sense.

2layers, one shared 3D scene
6–8generated floors per run
3parts of a body to aim at
100points of blood and Focus

05 / Building the mansion

A house that generates itself, floor by floor.

The central technical problem was the house. A run descends six to eight floors from the upper bedrooms to a vampire's sanctum, and it has to be a different house each time without ever producing an impossible or nonsensical one. Generating rooms at random does not achieve that. It produces houses with bedrooms opening into each other and kitchens adrift from anywhere food is kept.

So generation starts from meaning rather than geometry. Each floor is first described as a small graph of rooms and the connections between them, and the grammar of that graph is where the architecture lives. Corridors come first and are single continuous spaces rather than chains of segments. Private rooms open onto corridors, and two guest bedrooms are never allowed to adjoin. Dining rooms stand next to kitchens. Chapels are permitted to conceal stairs down to the crypt. The crypt leads through a guarded antechamber to the sanctum. Depth has rules too: ordinary sleeping guests near the top, social floors of awake guests and servants below them, then a forbidden wing, then the underhouse and service passages, then the crypt, and finally the sanctum. Late supernatural spaces are never placed above the ordinary household, and the sanctum is never missing.

Once the graph exists, rooms are given walls, openings and furnishings. Furnishing is the part that would be most visible if it were done carelessly, so it is not done by scattering objects into slots. Each room archetype has a small number of complete arrangements, and an arrangement rotates to face the room's main door so that the relationships still read: a bed's headboard meets a far wall with its nightstand beside it, a wardrobe takes a side wall, seats face the table they belong to, pews face the altar. Every face of every room is classified as exterior or interior once the shape is settled, which is what decides whether a door or a window can open through it. Windows then follow both the room's purpose and its depth, with tall glass in public rooms, stained glass in chapels, dormers in attics, barred openings under the house.

A final dressing pass fills wall, corner and tabletop slots with ornaments, and it is deliberately restricted. Decoration cannot block a doorway, sit in front of a window, or occupy a human's route or a mosquito's flight path. How much goes in follows the scale of the room: one or two pieces in a guest bedroom, three to five in a master room, six to nine around the edge of a ballroom with the floor left clear.

That restraint is a production decision as much as an artistic one. The house is dressed from a small kit of reusable families (framed art, statues, urns and plants, reliquaries, and one modular fireplace) which can take muted materials or damage as they go deeper without needing a new model each time. It is the difference between a mansion that looks varied and a mansion that required three hundred unique objects to build.

It also keeps the house plausible: a wardrobe standing in front of a window is not a room anyone would design, and a hidden door only works if the space behind it could physically exist. Those checks are what made the restraint possible rather than merely cheap.

The balance between generated and authored was found by generating rooms and then auditing them for plausibility, over and over. A wardrobe blocking a window is one kind of failure. Another is a furnishing arrangement that a character cannot actually walk around, which is why the arrangements are placed deterministically rather than scattered. Both kinds of problem were caught by purpose-built debug tools rather than by eye, and both are the reason the rules are as specific as they are: each one exists because something failed without it.

The Mansion Generation Lab showing one generated floor as a 3D cutaway beside a panel of seed, difficulty and blueprint controls.
The generator under inspection. One generated floor rendered as a cutaway beside the controls that produced it: seed, difficulty, floor selection, and isolation for a single room. The readout confirms what the run actually contains.

06 / Start with a brief

A written brief becomes the artwork.

Much of what you see in the house began as a description. Prompts, generation records and the assets they produced are kept together in the project, so a result can be read against the request that produced it.

The work is organised into sixty production queues, each named for what it produces: a set of character materials, a party of guests, a family of hidden-room objects. Between them they hold forty-seven written briefs. Each queue also keeps a record of the run that made it, including which model produced what, at which size and quality, and which brief every asset came from.

The briefs are production documents. A single sound effect is specified closely enough to be judged:

Not every brief succeeded. One character-material run was stopped outright, and the reason is recorded: “skin softened without enough new surface detail. Rollout stopped; no runtime use.”

The brief is the input

The clearest example is a predator. A source reference for a spider was written as a full specification, not a mood but the anatomy the model would be built from: eight separated articulated legs, a neutral resting pose, negative space between the legs so a rig can read them, and a deliberately featureless face stated as a constraint rather than left to chance.

A faceless brown spider concept reference on a pale grey studio background, eight legs spread apart, seen from above the front.
The first reference. A faceless brown spider on a neutral studio ground, legs spread for rigging.
The same spider with a rounder black abdomen carrying a crimson hourglass marking and crimson bands at the leg joints.
After the edit brief. A rounder abdomen, black chitin and a crimson hourglass marking. The leg count, the pose, the blank face and the framing are all deliberately unchanged.

The second image is a revision, and its brief says what may change and what may not. It asks for new proportions and colour, and then protects the parts that were already correct:

Read the revision brief

“Change its body proportions and surface design into a vampiric button-spider-inspired creature. Give it a plumper, round, almost spherical abdomen and a smaller, sleek cephalothorax. Replace the brown hairy surface with smooth satin-to-gloss black chitin, with soft charcoal highlights so the dark forms remain readable.”

“Preserve its completely faceless front: no eyes, eye dots, eye sockets, mouth, teeth, skull face, or markings arranged like a face.”

“Keep EXACTLY eight articulated walking legs, four per side, in the same clearly separated neutral spread pose.… No added limbs, wings, horns, spikes, jewelry, cape, web, or props.”

The result is a concept reference. It is not a claim that the shipped creature descends directly from this image.

07 / Prompt to model

Images become assets through a staged pipeline.

Artwork alone is not a game asset. Turning a generated image into something the engine can place means geometry, surface detail, a skeleton and animation, and each of those stages wants a different balance between how an asset looks and what it costs to draw.

That work happens in stages: build the geometry, remesh it for shape, retexture it at 2K, remesh it again to a budget the game can afford to draw, rig it, animate it, and package the result for the engine to import. Each stage trades appearance against cost, and the order exists so that detail is spent where it shows.

What generation does not settle is whether the result is usable. A mesh can arrive looking splendid at two million triangles and still be the wrong asset, because a house this dense has a budget and no single prop is entitled to ignore it. So each one is remeshed down from the art version to a version the game can afford to draw, and the question that has to be answered at that point is whether it is still good enough, and whether the silhouette, the material and the detail that mattered survived the reduction. That judgement needs an understanding of how the asset is actually used: how close the player gets to it, whether it is ever seen in isolation, and what it has to do in a room.

None of this happens while the game is running. The game contacts no generation service at all: it ships finished assets, and every model in the house was built offline before it.

1,011Meshy task records
37pipeline directories
45asset contracts
47structured prompts

Nothing generated is used on trust. Every asset family is governed by a written contract recording what a finished piece must satisfy, and the contracts for walls and furniture also fix the points at which pieces are allowed to join. A chair and a wall built months apart still meet correctly, because both were built to the same stated rules rather than to each other.

Making the animation usable

Rigged assets then need motion, and this is where the gap between what a service returns and what a game can use was widest. A generated clip is a suggestion. Some of them read as something else entirely: a crawl animation ran its actor forward with the chest and stomach kept to the ground, which suggests a crab rather than a body being dragged. The clips also arrived with limb defects, wrong postures and clearances that did not hold, and with the wrong timing for the moment they were meant to fill.

So the motion was corrected rather than accepted. Clips were retargeted and re-authored, defects across the whole set were reviewed one animation at a time and fixed, and posture and contact were adjusted until they matched what a room and a piece of furniture allowed.

The Animation Lab is the tool that made that possible. It loads a character, lists every approved clip, plays any of them with frame-accurate scrubbing and bakes the result, so a clip can be judged on the real model against the moment it has to fill, before it ever reaches a room.

The Animation Lab previewing a sword-slash clip on a character, with the action list and playback controls down the left side.
Reviewing one clip at a time. The Animation Lab plays a single named action on a loaded character, with the full action set listed beside it and the clip position shown to the frame.

08 / One asset, end to end

From a brief to a guest at the party.

Every stage above is easier to follow on a single asset. This one is a visitor who appears in one scene: a living vampire lord, younger than the one the player meets first, generated for a party in the glasshouse.

It began as a written turnaround brief, which produced a three-view concept sheet. The front view was then cropped out on its own, because image-to-3D wants one unambiguous silhouette rather than three figures on a sheet.

A three-view character turnaround: a figure in a long dark brocade coat with red lining, shown from the front, the side and the back against a plain grey ground.
1. Concept. A three-view turnaround produced from the brief. Three views, one figure, on a neutral ground.
The front view cropped out of the turnaround sheet, isolating one figure on a plain background as the input for 3D generation.
2. Crop. The front view isolated. That single silhouette, not the whole sheet, is what the 3D pipeline receives.

What came back was a mesh with a skeleton in it. The rigging is a service stage, but repairing it was not. The weights around the long coat had to be corrected locally and the animation re-authored, and the record is explicit that the result is a stationary rig: the coat is not approved for locomotion, so the clips are restrained poses rather than a walk cycle.

The built 3D character with its skin, standing with arms held away from the body on a pale background.
3. Model. The generated mesh with its skin, posed with the arms held clear so the coat reads as a separate surface.
A lit glasshouse interior seen from above, with several figures in dark clothing standing around a central fountain, and the game's interface around the frame.
4. In the game. The same character among the guests in the finished glasshouse scene, under the scene lighting and behind the game interface.

Alongside it runs the animation leg built for ordinary inhabitants: seven human builds sharing one action set, 141 active clips between them, and a runtime profile that lists thirty-two animations for a single character. All of it is authored against the rig, checked on the actual model in the Animation Lab, and only then bound into a scene.

09 / Into the engine

Deciding what the house may use.

A generation service can produce hundreds of assets. A game still has to decide which of them may appear, where, and in what relation to everything else. That decision lives in nine catalogues, each covering one class of thing, from furniture and lighting to ornaments, architecture, characters, portraits, readable objects. A catalogue maps a meaning to a model: this is what a dining chair is, and this is the chair we accepted.

The mansion is then generated from those catalogues against a seed. A run produces six to eight normal floors with a guaranteed rooftop conservatory above them, and the number of rooms on each floor is derived from the difficulty. Because the generator draws only from accepted assets and a small set of authored furniture arrangements, the result varies without becoming incoherent.

The Mansion Generation Lab in map view, showing the generated floor as a schematic of connected rooms.
The same run as a schematic. Map view reduces the generated floor to connected encounter spaces. That is how the player moves through the house, and it is not a watertight architectural plan.

Testing behaviour without scenery

Inhabitants have to sense, remember, raise an alarm and pursue, and none of that is easy to judge inside a finished room. The Human AI Lab strips the scenery away and exposes the underlying variables directly (perception, reflex, aggression, tracking) so a behaviour can be isolated from the room it happens in.

The Human AI Lab showing two inhabitants and a mosquito in a room, with perception, reflex and aggression sliders on the right.
Behaviour, isolated from the room. Two inhabitants and the mosquito in an empty test space, with the personality variables that drive them on the right.

The labs are developer tools rather than game screens, and they are where a great deal of the production work happened. They are part of the finished project, and they are shown here as they are: a real tool, with its real readouts.

10 / The house in many forms

One room, many arrangements.

Variety is the point of a generated mansion, but it has to read as variety rather than noise. The generator adapts a small number of authored furniture arrangements to each room's entrances, then combines them with openings, ornament placement and the character of the floor.

Isolating a room makes the rules visible. A construction study shows the shell and simplified furniture. The runtime capture shows the same archetype finished and lit, with the game's interface in place.

An isolated guest bedroom with simplified furniture on a dark background, used as a construction study.
Construction study. Shell, openings and simplified furniture on a neutral ground.
The same guest bedroom in the running game, fully furnished and lit, seen from the cutaway overview with the game interface visible.
The same archetype in play. Furnished, lit and dressed, seen from the cutaway overview while the game runs.

11 / Seeing like a mosquito

Senses change what the room is.

A room is never simply visible. Breathing and flame within sensing range open the discovery veil over the house, and what has been revealed stays revealed. Scent and heat are not filters laid over a finished image. They are how the space becomes legible to the player at all.

Scent opens the area around a detected source. Heat makes warm bodies and flames readable through the veil without altering which areas have been discovered. Both are built to leave the other untouched, and the captures below are the same room, camera and seed at each stage.

A guest bedroom as the mosquito first arrives, lit but largely hidden behind the discovery veil.
Arrival. The room lit, with most of it still behind the discovery veil.
The same room after scent has opened the area around the sleeper, with the lit room revealed.
Scent opened. Breathing within range has opened the area around the sleeper, and it stays open.
The same room with the heatmap active, making the warm body and candle flames legible through the discovery veil.
A separate sense. Heat makes the warm body and the candle flames legible through the veil, and leaves the already discovered areas exactly as they were.

12 / The look of it

Faces left out, and a palette that means something.

A few decisions shaped everything visible in the house, and most of them were made against the obvious choice.

The characters have no faces

Every inhabitant of the mansion is featureless. The reason is not style for its own sake: the intent is that they should not read as fully human. A face invites you to read a person, and these are meant to stay strangers inside the house, recognisable by build, posture, clothing and behaviour rather than by who they are. That is what lets the house hold people whose stories unfold later, and it is why the costume changes are asked to carry so much of the characterisation.

It also solved a practical problem honestly. Faces need animation, lip sync and close-up fidelity, none of which the game needed, and the attention went instead into hands, necks, forearms and exposed skin, the surfaces the player actually has to cross to feed.

The colour language

The palette is a gothic one first: blacks and gold, with the gold doing the work that light would do in a room that has none. Red is the exception that carries meaning. It is blood, and it marks the things that matter to a mosquito, from a feeding site to an exit the current blood reserve can afford. Emerald green sits opposite the red as a regal counterpoint, keeping the mansion from collapsing into a single warm register and giving the deeper rooms their own character.

Set against that, the sensory colours are deliberately colder: a pale, desaturated register for scent and heat so the two languages never compete. The mechanical readings are quiet; the blood is not.

Scale, borrowed from two games

Two games supplied the emotional template. Shadow of the Colossus and God of War both build their fights around a small figure taking on something vastly larger, and both make the size difference the feeling rather than a statistic. A mosquito landing on a sleeping human is that idea with the volume up: the body is terrain, a hand is a wall, and the thing you are trying to bring down does not know you are there.

The story arrived while building

The narrative was not planned out first. It accumulated. The house needed a ghost, and a ghost needs an origin. The origin turned into a tragedy, and the tragedy needed to be discoverable, which produced the clues, the diaries, the portraits and the small objects that tell it. Each addition had to be placed somewhere that made sense and had to agree with everything already there, which is why the rooms are dressed as carefully as they are: much of the dressing is evidence.

13 / The sound of the house

The audio was briefed the same way.

Every sound and every line of voice in the game began as a written brief. The music was generated and then selected track by track. The sound effects and the in-game voiceover came from written briefs too, and the credits list every service used.

The audio manifest records twenty music entries with a prompt each, sixty-nine sound effects with a brief each, and eleven transitions for the Lord's encounters. Seventy-four sound effects and eighty-seven voiceover files ship in the running game.

Generating the audio was one step. Placing it was another, and that is where the pipeline had to be built rather than rented. Three purpose-written tools carry it: one turns each written brief into a finished effect, one produces voiceover from recorded lines, and one trims the silence a generator habitually leaves at each end of a take. A fourth keeps the record of every brief, the model that answered it, and the result that was accepted.

The archive runs to sixty-nine sound effects and twenty music cues for the game, plus the trailer's own mix. What none of the tools do is choose. Every effect is auditioned against its brief, and the ones that fail are discarded and regenerated.

14 / The art book

The book is built by a script.

The art book is a 108-page hardback-shaped PDF, one spread per sheet at 16 by 7.92 inches. Nothing about it was laid out by hand in a page-design program. It is an HTML document that a script turns into a PDF.

Each spread is a container roughly the proportions of the printed sheet, and every measurement inside it (type size, gutters, figure heights, the width of a caption cell) is a percentage of that container rather than a fixed value. The screen layout and the printed sheet are therefore the same design at different scales, which means the browser preview is a genuine proof of the page and the export needs almost no geometry overrides.

The spreads are generated rather than laid out by hand. A catalogue of the furniture, ornament and lighting pieces the generator can place is held as data, and a builder writes those spreads into the document. It has to do arithmetic to do it: the cell size in a furniture grid depends on how many rows it has and how much room a caption needs, and an early version of that calculation clipped the last row of every four- and five-row grid. The fix went into the generator rather than into the four spreads it had damaged, because the next build would have reintroduced them.

The floor plans are generated too, drawn as vector diagrams from the generator’s own output. The loop diagram checks the connections it draws against that output first, so it cannot illustrate a route the mansion does not actually contain.

A schematic floor plan: labelled rooms as rectangles joined by corridors, drawn in bronze and cream on a dark ground.
Generated, not drawn. A floor plan built as vector artwork from the generator's own floor data.
A schematic floor plan with two routes highlighted between the same two rooms: one dashed through the corridor, one solid through a direct arch.
A verified route. Two ways through the same floor (one by corridor, one through a direct arch), each checked against the exported graph before being drawn.

The export is a headless browser rendering the document at print size, but only after a layout check has measured every sheet and refused to produce a file if any text is clipped by the edge of a page or overlapping other text. Each sheet hides its own overflow, so a caption running past the edge is silently cut off and never shows up as a page-level problem. The same measurement gates the export and the review, so a page cannot pass review and still export.

A two-page spread of the art book showing eight pieces of furniture photographed on a dark ground, each captioned with its family and name.
A finished spread. One of the book's catalogue pages as laid out for print: pieces photographed on a dark ground, each captioned with its family and name.

15 / The trailer

A trailer assembled by command line.

The trailer is 64 seconds long and was never opened in a video editor. The footage was captured first, then the edit, the voice, the music and the sound effects were each assembled by script and combined into a master.

Capture came from the game's own tooling. Rather than recording someone playing, the team drove the game through its production systems (staging an encounter, running a predator's attack, triggering a feeding sequence) and rendered frames directly. Each take came out as a numbered sequence of images, which was then encoded to video at 1080p and 24 frames per second. Doing it that way means a shot can be re-rendered exactly rather than re-performed, and it keeps the discovery fog and the interface in the state the shot needs.

The footage was then treated as material to be cut, not played. The edit describes each shot by name, start time and duration, and building it means extracting those ranges, retiming some of them (the opening is slowed to a quarter speed to leave room for narration) and joining the results. One line of the edit list is the whole film. Because that list is data, changing the pace of the trailer is editing a set of numbers and rebuilding.

A cutaway bedroom in the running game with most of the room still under fog, the mosquito small in the middle of the floor.
Where it starts. The opening leads with a continuous exploration: a room mostly under fog, then scent and heat revealing it.
A generated bedroom seen from above with a figure asleep on the bed and the game's interface around the edge of the frame.
The turn. The feeding sequence, staged as a production encounter rather than played live.

The narration was cast rather than assigned, and it took two rounds of auditions. The first compared three restrained storytellers reading the same short excerpt so they could be judged against each other. All three were generated with the same model, the same fixed seed and the same text, so the only variable was the voice.

That round settled the direction without settling the part, so a second round auditioned three more against it, this time with stronger dramatic direction and the emphasis pushed onto a single word. Six performances were compared in total, and the choice fell to Matthew Schmitz as an ancient vampire lord.

The mix is assembled from parts:

A predator closing on the mosquito in a cramped interior, with the evade prompt visible against the frame.
Pressure. A predator encounter, using the production attack logic and the game's own evade prompt.
The mosquito caught in a lit spider web inside a dark room.
Scale change. The web encounter, where the mosquito is no longer the hunter.
A tall figure standing in a candlelit chamber with arms flung wide, surrounded by a ring of lit candles.
The far end of the house. The final chamber, staged with the game's active combat logic. Encounters are arranged to be shown, though, so it deliberately stops short of the outcome.

16 / This website

This page is generated too.

This website is one build script and six pages. There is no framework, no content management system and no third-party code of any kind: the whole site has zero dependencies, which is unusual, and it means there is nothing here that can quietly stop being maintained.

The site also produces its own assets rather than sourcing them. The soundtrack is compiled from the game’s audio masters: the script checks that every track is present and that each master is unchanged and in the expected format, then encodes a lossless album and a streaming version, confirms the lossless files decode back to exactly the original audio, and assembles the archive the download offers. The playlist on the downloads page is written from that same pass, which is why the track list cannot disagree with the files beside it. The wordmark in the header is exported from the game’s own title screen, so the lettering on the homepage is the game’s lettering rather than a redrawing of it.

Deployment is automatic: pushing to the main branch runs the build and the check and publishes the result, with no manual upload in between.

An approved page mockup showing the intended article layout: a heading and lede, a wide column of text, and a slim contents list down the right-hand side.
Designed first, then built. The approved mockup for this page. The published article kept the reading column and the contents list, though the approved design shows less than half the chapters this piece eventually needed.

17 / Built to be checked

Verification is part of the pipeline.

Knowing which generated assets are good enough to ship is the work, and that judgement had to be written down to be repeatable. So the project grew its own instruments for it: a suite of 316 automated checks, 72 of which drive the game and photograph the result. The instruments were written by the same agents that wrote the game. Deciding that they were needed, and what each one should be checking for, was not.

316test scripts
72capture harnesses
93documents
115,930lines of GDScript

Those capture tools are why this page can show the laboratories at all. They also produced the art book's plates, so the book and the site cannot disagree about what a room looks like.

The recurrence is the point. Wherever work had to be repeated it became a tool, and wherever a tool made a judgement the judgement was recorded, so it could be checked later.

That is what kept a project this size tractable. Prompts and models produced a large part of the raw material, but the material arrived in hundreds of pieces that did not fit together: 1,011 generation tasks, and 4,015 files retired into an archive once it was clear they were not part of the game.

Changing your mind is part of it too. One documented reversal explores an animation approach built on a state machine, and then records retiring it for a direct controller. Both the attempt and the reversal survive in the project's notes, which is what makes the process legible afterwards.

Automated checks only reach so far, and knowing where they stop is part of the method. They can prove that a room generates, that a mesh fits its budget and that no caption is clipped. They cannot tell you whether the house is frightening, whether the hunt reads clearly, or whether the feeding rhythm feels fair. That part was played, by hand, repeatedly, and it is the part that decided when something was finished.

18 / Why it is being given away

How these tools are used.

It is easy to look at what these services can produce and conclude either that games like this now make themselves, or that anything made with them is worthless. Both readings miss what the work actually is.

What the tools changed is the cost and time relationship. A single person with an idea that can be iterated on, and without a large budget, can now finish something that would previously have needed a team or a decade — or would simply never have been made. Anyone who has an unfinished project in a drawer should know that skill is not the barrier it appears to be. Mastering every discipline well enough to make something like this takes years, and a person can do it, but only by giving up nearly everything else. The obstacle was never ability. It was that no single life holds enough hours to do all of those jobs at once, and asking one person to try means something else has to suffer for it.

There is a version of this that looks like a shortcut and is not. With a good enough model it is now possible to produce something that resembles a game in an afternoon. What is left afterwards is everything that makes it a game: the mechanics that do not work until they are tried, the pacing, the readability, the hundred small corrections that only appear once someone is actually playing. Getting a plausible result is the easy part now. Crafting the thing is the work, and as a storyteller, it is the same work it always was.

That is also why the game is being released this way. The builds are public, and the mobile versions will be free, because the result of all this work is built on the shoulders of many.

It is a game about a mosquito seeking immortality, and the friends it doesn’t make along the way.

Art & Making OfDownload the art book