AI sandbox game maker: systems that surprise their author
A sandbox is not a big empty map. It is a handful of systems that talk to each other, and the good ones do things their author did not plan.
The interaction is the game
Sandbox games are usually described by their freedom, which is a result rather than a cause. What produces the freedom is a small number of systems that touch each other. Fire spreads, and there is wind, and there is dry grass, and now you have a mechanic nobody designed.
That is the target. Not a longer list of things the player can do, but fewer things that combine in more ways. Games with fifty unconnected features feel emptier than games with six connected ones.
Building for that means being able to add a system, play with it, and change how it interacts with the others without the cost of a rewrite each time. Which is exactly what changes when the code is written for you.
Adding systems cheaply
Director 1 writes GDScript into your Godot project. Physics interactions, placement and building, resource flow, growth and decay, weather effects, creature behaviour, tools and their consequences. Each one arrives as working code and you play it immediately.
The interesting request in a sandbox is usually the second-order one: not add fire, but make fire care about the wind you already have. Those are the requests that produce emergence, and they are cheap to try here.
You will throw a lot away. That is the correct way to build a sandbox, and it is only affordable if each attempt is inexpensive.
The world you set it in
You build the world by hand in the builder, and the first decision is which world. Making a project asks 2D or 3D, shown as two pictures, with no default and nothing created until you pick. Pick 3D and the hand work is terrain, water, weather and structures. In a sandbox the world is the stage the systems perform on, and its shape decides what they can do. A valley that catches water behaves differently from a plateau that does not.
Placing that yourself is also how you discover what your systems need. You will put a river somewhere and immediately want to know what happens when it floods, which is a better source of design than a planning document.
Pick 2D instead and the stage changes shape without changing its job. A side-on sandbox is a native fit here rather than a consolation: ground is painted, you drag to lay tiles and drag to erase them, and the tiles, the edges and the collision all fall out of which cells are ground, so a shelf you dragged out a moment ago is already something to stand on and climb to. Water and weather stay on the 3D side, because neither has anything to describe without depth. What a flat world gives you instead is a stage cheap enough to redraw between playtests, which is the thing a sandbox actually needs.
It runs on your machine
Flockbay is a desktop app for Mac and Windows that ships with Godot inside it. Sandbox games simulate a lot at once, and running locally is what gives you the headroom to do it. There is no browser version and no streaming.
Building needs an internet connection since Director 1, asset generation and world data come over the network. Playing what you built does not.
Free to download, and building the world by hand costs nothing. Indie at $10 a month unlocks the AI assistance: gameplay logic from Director 1, plus texture, sound, prop and rig generation.
Giving the player something to do with the freedom
The most common failure in sandbox design is not a lack of tools. It is a lack of any reason to pick one up. A player dropped into a world with total freedom and no pressure usually wanders for ten minutes and then leaves, having enjoyed none of the systems you spent months on.
The usual fix is a light frame around the freedom. Something scarce, something that decays, a distant goal, a threat on a timer. Not a quest log, just a reason to act. Once the player has one, every system you built becomes a possible answer, and the freedom starts to mean something.
That frame is quick to add here, because it is a rule and rules are what Director 1 writes. It is also the thing most worth prototyping first, before you invest in the depth. A shallow sandbox with a good reason to act tests better than a deep one without.
Performance is a design constraint
Simulating a lot of things at once is the defining technical problem of a sandbox, and it will shape your design whether you plan for it or not. A hundred creatures each running full behaviour every frame is a very different proposition from a hundred that only think when the player is nearby.
Running locally on your own machine gives you real headroom, and it is one of the main reasons this is a desktop app. It does not remove the problem. Test with the world full rather than with the world empty, because an empty sandbox runs beautifully and tells you nothing.
Questions
- Can players build in the world?
- Yes. Placement, snapping, inventory and destruction are all systems Director 1 can write. How deep it goes is decided by how far you iterate.
- Voxel or mesh based?
- Either is possible in Godot. Voxel worlds are a substantial engineering project in any engine, so expect that to be a longer road than placing objects on terrain.
- How large can the world be?
- Large worlds are the intended shape, and the practical limit is your own hardware since the game runs locally.
- Do I write any code?
- No. You build the world and decide what the systems should do. The GDScript is written into your project for you.
- What does it cost?
- The builder is free. Indie at $10 a month unlocks the AI assistance, and you can try those features on the free plan first.
- How do I stop the world feeling empty?
- Usually by adding pressure rather than content. Test that first, because it is cheap, and it often turns out that the world was fine and the player had no reason to engage with it.
Related
Free to download for Mac and Windows. Build systems that talk to each other.
Download Flockbay free