Skip to content

The Experiment

Human-led. AI-assisted. Built in public.

GALSOV is not “AI makes a game.”

It is a human-led project where AI is used as a tool: to explain, challenge, organise, draft, code-assist, troubleshoot, and document the messy reality of learning while building.

The game matters. The method is the experiment. The question is whether AI can help a non-professional game developer build a serious strategy game without turning the result into magic, hype, or nonsense.

AI Helps With

Useful assistance

AI is a tool in the workshop, not the project owner.

AI helps me move faster, understand more, and organise work that would otherwise be overwhelming. It can suggest, explain, challenge, and draft — but it does not get final say.

  • Explaining unfamiliar code and design ideas in plain English.
  • Drafting page copy, rules notes, issue text, and test plans.
  • Suggesting implementation options and risks.
  • Helping turn messy thoughts into structured plans.
  • Spotting likely gaps, contradictions, and assumptions.
  • Helping troubleshoot bugs, build errors, and confusing behaviour.
  • Creating first-pass code that still has to be understood, tested, and approved.

AI Does Not

Human judgement stays in charge

There is no magic “make game” button here.

AI can be useful, but it can also be wrong, overconfident, vague, or too eager to please. That is why GALSOV treats AI output as something to inspect, not something to blindly trust.

  • AI does not own the idea.
  • AI does not make final design decisions.
  • AI does not replace testing.
  • AI does not get trusted because it sounds confident.
  • AI does not get to hide rules inside unexplained code.
  • AI does not decide what GALSOV is meant to be.
  • AI does not turn a rough build into a finished game by wishing hard enough.

Working Rules

The experiment has rules

Not perfect rules. Practical ones.

These rules exist to keep the project understandable, testable, and honest. They are there because “AI helped me build it” is only interesting if the result can still be explained, checked, and improved.

Human-led The project direction, priorities, and final decisions stay mine.
Explain clearly If I cannot explain a change in plain English, it is not ready.
Teach while building The process should leave me understanding more than when I started.
No magic blobs No unexplained code dumps, mystery fixes, or “trust me” shortcuts.
Evidence wins Tests, screenshots, logs, and working builds beat confident guesses.
Determinism matters The same starting conditions and choices should produce the same results.
Small steps Work should be reviewable, reversible, and not secretly become five jobs at once.
Failure is data Dead ends, mistakes, and wrong turns are part of the record, not something to hide.

Why It Matters

This is not separate from the game

The method shapes the result.

GALSOV is a strategy game about rules, consequences, information, and cause-and-effect. That means the way it is built matters too.

If a rule exists, it should be understandable. If a system changes the galaxy, it should be visible. If something breaks, it should be possible to reproduce. If AI suggests something that does not fit, it should be challenged instead of accepted because it sounded clever.

The aim is not to look flawless. The aim is to make real progress in public, with enough honesty that people can see both the promise and the mess.

The Public Record

Build in public means showing the work

Progress, mistakes, fixes, and course corrections all count.

The devlog is not only for announcements. It is where the project records useful progress, awkward problems, design shifts, dead ends, and small wins.

That matters because the experiment is not just whether GALSOV can be built. It is whether the process can stay understandable while the game grows.