A strategy game maker, and an honest note about the genre

In most genres you can get something enjoyable from a good space and simple behaviour. In strategy, the space is a backdrop and the enjoyment is entirely in the interlocking rules: production, cost, counters, range, vision, timing.

Worse, those rules only reveal themselves as good or bad when played against an opponent who exploits them. A number that seemed reasonable becomes the only viable opening. A unit that seemed weak turns out to invalidate three others.

So the genre demands many iterations, and the cost of an iteration is the thing that decides whether a strategy game ever gets finished by one person.

The rules are written by Director 1 as GDScript inside your project. Adding a unit type, changing a cost curve, giving a faction a different vision radius or making artillery ignore cover are all requests rather than afternoons.

That does not make the design decisions for you. Nothing can. What it does is let you take the twentieth pass, which is where strategy games actually become good, instead of stopping at the fourth because each pass cost a weekend.

You play, you notice the opening that always wins, you say so, and it changes. Not writing the code does not mean not seeing that the cavalry rush is unanswerable.

Terrain in a strategy game is not decoration, it is the argument. A chokepoint, a river crossing, a plateau with a view, a resource that sits uncomfortably far from safety — those decide how the game is played more than any unit stat.

In the builder you shape terrain directly, place water, set the weather and time, and put structures where they belong. Then you walk or fly through it and see whether the map is asking an interesting question.

It runs locally. Stage Engine is a desktop app for Mac and Windows with Godot bundled inside, so a map with many units on it is limited by your machine rather than by a browser tab.

Computer opponents in strategy games are famously unsatisfying, and it is not because the code is hard. It is because a genuinely optimal opponent is unpleasant to play against, and a weak one is boring, and the interesting band between them is narrow.

The productive approach is to describe behaviour rather than skill. This faction is aggressive early and cautious once it loses a battle. This one turtles and expands late. Those are legible to a player, which is what makes an opponent feel like a personality rather than a difficulty slider.

Expect several passes here as well. It is normal, and it is the part where your judgement as a player is the only useful instrument.

A strategy game is a set of decisions, and a decision the player cannot see is not a decision. Range, vision, threat and who is winning all have to be legible at a glance, and in 3D that is harder than on a flat board because the camera can hide things.

Practically this means camera height, unit silhouette and colour do more work than any mechanic. Two factions that look similar from above will ruin an otherwise good design, and no amount of balance work will rescue it.

Test it by playing a match and pausing at a random moment. If you cannot tell within two seconds who is ahead and what is about to happen, the problem is the presentation rather than the rules.

The realistic advice is to start small. Two factions, six unit types, one map. A finished small strategy game teaches you more than an unfinished large one and it is roughly the difference between a project and a folder.

Building needs an internet connection, because Director 1, asset generation and world data come over the network. Playing what you built does not. Your project is an ordinary Godot project on your own disk, and Godot is open source.

Free to download with a free plan, Indie $10 a month, Pro $50. Those buy usage, not a different engine.