Do you need to code to make a game?

Pick from a menu. The tool ships with a set of behaviours and you assemble a game out of them. Fastest to start, and it has a hard ceiling shaped exactly like the menu — you can build what the authors anticipated and nothing else.

Wire up a graph. Visual scripting: nodes and connections instead of text. Much higher ceiling, because the pieces compose. The catch is that this is programming with a different notation, so you have taken on the conceptual work you were trying to avoid.

Have a model write it. You describe the behaviour and real script goes into the project. No menu means no ceiling from the menu, and the cost is that the code is written rather than assembled, so getting it right takes a round or two.

Design. Whether the corridor is boring, whether the enemy is threatening or just annoying, whether the jump feels right at this height. Those questions decide whether the game is good and there is no tool that answers them.

Playing your own work honestly. This is genuinely difficult, and it is more important than anything technical. The person who has finished one small bad game and played it properly knows more than the person with three months of design notes.

Building the world, if your game has one. A landscape is spatial taste and there is no correctness test for it. Describing it precisely takes longer than shaping it.

If programming interests you, yes, and Godot with GDScript is one of the friendlier places to start. Nothing on this page argues otherwise, and a tool that writes the code for you removes exactly the practice you would be trying to get.

If it does not interest you, learning it in order to make a game is now a detour rather than a prerequisite. That is a genuine change, and it is recent.

The middle position is common and reasonable: do not learn it first, and pick some up later because you got curious about what the code in your own project is doing.

It means you do not write the code. That is the whole of it.

It does not mean you cannot judge the result. You play the game and decide whether it is right, and that judgement is the input the whole process runs on. Any tool that treats not-writing-code as a reason to shield you from decisions has misunderstood who you are.

Being handed work back — play this, is it right, what should change — is the normal loop rather than a failure. It is the only mechanism by which a game gets good, and you are the only one who can do it.

Stage Engine is the third option above. Director 1 writes GDScript into your project when you describe what should happen, and there is no behaviour list anywhere in the product. The engine is Godot, open source, bundled inside a desktop app for Mac and Windows.

The world is your hands: terrain, water, weather, buildings and characters built directly in a builder. The game runs locally on the bundled Godot at your machine's framerate.

You can read the code — it is a normal Godot project on your disk — and nothing requires it. Building needs an internet connection; playing what you built does not. The download is free with a free plan, and Indie at $10 a month and Pro at $50 buy more usage rather than a different engine.