An NPC is behaviour, not a portrait

There is no shortage of tools that produce an NPC: a name, a portrait, a profession, three personality traits and a secret. They are pleasant to read and they do not move. Put one in a game and you still have a character standing perfectly still in a doorway.

The gap is behaviour. What makes an NPC feel alive is that it walks somewhere at a plausible time, reacts when you approach, notices when the weather turns, and does something other than exist. That is code, and no amount of biography substitutes for it.

So the useful question is not how to generate a character sheet. It is how a person who does not write code gets that behaviour into a running game.

That is the interface. You say the blacksmith works the forge in daylight, walks to the tavern at dusk, and stops what he is doing if the player draws a weapon within a few metres. Director 1 writes the GDScript that does it, in your project, where you can read it if you want to.

The same applies to guards with patrol routes, animals that flee, merchants with stock that changes, crowds that react to a fight. None of it requires you to know what a state machine is, and all of it is ordinary code that Director 1 produces and revises.

Then you play it. If the blacksmith walks through a wall, or the guard notices you from an absurd distance, you say so and it changes. Judging that is your job and it does not require reading a line of the implementation.

This is why the builder matters for NPCs specifically. Behaviour is relative to a place: this door, that market square, the road between the two villages. You place the character and its landmarks by hand, in a 3D view, because pointing at where something goes is faster and better than describing it.

The world itself carries terrain, water and weather, so a character can respond to conditions that already exist rather than ones you had to invent for it.

Appearance comes from generation, from the web, or from your own assets. Geometry can be built directly when that is the honest fastest route to something you can play.

Director 1 writes code while you build. It is not sitting inside your finished game improvising dialogue for players. What ships is GDScript in a Godot project, running locally, deterministic and inspectable.

That is a feature rather than a shortfall. Behaviour written as code can be tested, repeated and fixed. It also costs nothing to run and does not need a connection while someone plays.

Building does need an internet connection, because Director 1, asset generation and world data all come over the network. Playing what you built does not.

Stage Engine is a desktop app for Mac and Windows with Godot bundled inside it. It is a download, not a browser tool.

Free to download with a free plan. Indie is $10 a month and Pro is $50. Paid plans buy more usage, not a different engine.

One well-behaved character is convincing. Twenty identical characters standing in a square are worse than none, because the repetition tells the player the world is a set. Variety is what sells a populated place, and variety is mostly small differences in behaviour rather than in appearance.

Different walking speeds, different destinations, different reactions to the same event, a few who are doing something unusual. Those are cheap to describe and they do most of the work.

Because the game runs locally on your own hardware rather than being streamed, the number of characters you can simulate is a question about your machine rather than a bandwidth budget. That is a large part of why a populated world is a reasonable thing to attempt here.