Three practical jobs AI and AI-adjacent techniques can do for a solo developer, and the checks you owe your game before shipping any of them.
This is the section guide for AI in game development, not a single tutorial: it sorts the field into three jobs you can actually use this month and points you to the deeper posts for each.
“AI” covers a lot of ground in games. Some of it is decades-old technique, like state machines and seeded random numbers. Some of it is newer, like image models that run on your own computer. This page treats both as tools, not magic, and it is honest about what you cannot know in advance.
The rule that comes first
Your game must still run if the model is absent.
That means no feature that only works when a model is installed, reachable, or affordable. Models get retired, services change terms, and players run your game on machines you never tested. Anything a model makes should end up as an ordinary file in your project, or the feature should fall back to plain code.
Keep that rule in mind for all three jobs below.
Job 1: A local image as a concept starting point
An image model running on your own computer can give you rough concept images to react to. Think of it as a mood board you can steer, not as finished art.
What it is good for: exploring color, shape, and mood before you commit. Seeing ten variations of “mossy stone tower at dusk” in a few minutes, then sketching your own version of the one that clicks.
What to do with the output: use it as reference. Redraw, repaint, or model from it. Keep the generated image in a reference folder, not in your shipping assets folder, unless you have checked that you are allowed to ship it.
What you cannot verify from here:
- Whether a given model produces good results for your style. Try it yourself.
- Whether a model you read about is still available, or what it costs to run.
- Whether the model’s weights and outputs are licensed for commercial use.
- How the model was trained, and whether that matters to you or your players.
This page does not name a model as current, because that would go stale fast. When you pick one, read its model card and its license yourself. The model card tells you what the model was built for and its known limits. The license tells you what you are allowed to do with it and what it makes. If either is missing or unclear, treat the output as reference only.
Store platforms may also ask you to disclose AI-generated content. Check the current rules for wherever you plan to publish.
Job 2: NPC behavior with no language model
Most good NPC behavior in shipped games uses no language model at all. It uses clear, predictable logic that you can debug.
Start with a finite state machine. An NPC has a few states, such as Idle, Patrol, Chase, and Return. Each state has simple rules for what to do and when to switch. A guard patrols between points, switches to Chase when it sees the player, and returns to Patrol when it loses them.
Add pieces as your game needs them:
- Navigation: your engine’s built-in pathfinding moves the NPC around obstacles.
- Senses: a sight cone and a hearing radius decide when the NPC notices the player.
- Timers: a short delay before chasing makes the NPC feel fair rather than psychic.
- Behavior trees: when a state machine gets tangled, a behavior tree organizes the same decisions into a readable hierarchy.
Why this is the right default: it runs on any machine, costs nothing per player, behaves the same way every time you test it, and you can fix it when it breaks. Players read predictable NPCs as smart when the rules are clear.
If you later want dialogue from a language model, build it as an optional layer on top. The NPC should patrol, chase, and talk with written lines when the model is not there.
Done means: you can describe every state your NPC has and what moves it between them, and a playtester can learn to sneak past it.
Job 3: A seeded level
Procedural generation builds levels from rules instead of by hand. The key word for a solo developer is seeded.
A seed is a number you feed your random number generator. The same seed gives the same level every time. That makes generated levels testable, shareable, and debuggable. When a playtester hits a broken room, they tell you the seed, and you can load that exact level.
A practical starting approach:
- Hand-build a small set of room templates. Each one has marked doorways.
- Use the seed to pick and connect templates. Start room, a few middle rooms, an end room.
- Check the result. Can the player reach the end? Is every door connected? If not, reject it and try the next seed.
- Log the seed. Show it in a debug overlay or save it with every run.
This gives you variety while keeping the quality of handmade rooms. You control the pieces. The generator only arranges them.
What to avoid early: generating everything from noise with no templates. It can work, but it is much harder to make fun, and harder still to debug alone.
Done means: you can enter a seed, get the same level twice, and every level the generator accepts can be finished.
Checks before you ship anything a model made
Before any model-made content goes into a build, run through this list:
- Read the model card. Know what the model was meant for and its stated limits.
- Read the license. For the weights, the outputs, and any service you used. Look for commercial use terms specifically.
- Record what you used. Model name, version, date, and settings, in a note in your project.
- Check store rules. Follow the current disclosure rules for each storefront.
- Test with the model removed. Uninstall it or turn it off, then play your game start to finish.
If you cannot answer the license question with confidence, do not ship the output. Use it as reference, or replace it.
What this page does not claim
This page makes no claims about which model is best, how fast any model runs, or what it costs. Those change too quickly, and they depend on your hardware and your use. Test on your own machine with your own content and judge the results yourself.
Where to go next in this section
The site has deeper posts on each job: AI-assisted level design, seeded room templates, NPC behavior in Unity and Godot, debugging an NPC patrol, and procedural generation tools. Pick the one that matches the job you want this week, and build the version that works without a model first.