G0dot without Coding works?

At the risk of drawing the ire of the Mods for mentioning the "competition", Scratch may be exactly what the OP needs.

http:://scratch.mit.edu

vexymous don't know why there is no sad reacts, dang it

All tears have been shed over the lack of visual programming in another thread.

Visual programming in Godot made it easier to change the code, but not to create it. It was intended for those in the development team who are not very good at programming — artists, screenwriters. So that they could modify the code that was already ready. But creating this code, was a bit more difficult than writing in a programming language.

vexymous I was trying to help the OP, idiot, you're just trying to make me look bad.

ADMIN EDIT: This is totally rude and uncalled for. You've been warned.

xyz I'd genuinely be interested in hearing from the op if Godot's visual scripting meets their criteria of "without coding"

Perhaps I missed something, but I didn't see where visual programming is labelled as "without coding".

This is its main purpose:

• Programmers working in a team that want to make part of the game logic available to Artists or Game Designers in order to offload some of their work.

There is certainly a great deal of slyness in the reasons for rejection:

According to our most recent poll (with more than 5000 respondents), only 0.5% of the user base has used VisualScript as their main engine language.

Visual programming, by definition, cannot be the main engine language. It is precisely an aid to fine-tuning game parameters.

Godot has a very huge problem right now. Creating games is a fusion between programming and artistry. Godot leans towards the convenience of programmers — their comfort is a priority. Artists are much more difficult. As an example, it was the shader window that was made floating, not the animation editor, which is more important for artists.

According to this concept, visual programming really seems insignificant.

As a consequence, there are no games with outstanding graphics on Godot, and therefore one should not worry about excessive realism in games using Godot.

GodotBeginnerRich idiot, you're just trying to make me look bad.

I'm starting to feel like I'm on Russian sites.

So to answer the OP, you cannot use Godot without code. Visual scripting is gone from Godot 4 and it was poor and never well supported anyhow. Not because visual script is bad (whole AAA games have been made in Unreal with Blueprints) but because the Godot implementation was poor and not documented or supported.

What they want is GDevelop, which is a pretty good engine for someone who doesn't know how to code. You still need to understand logic and math, but it's easier than visual scripting.

https://gdevelop.io/

Tomcat xyz I'd genuinely be interested in hearing from the op if Godot's visual scripting meets their criteria of "without coding"

Perhaps I missed something, but I didn't see where visual programming is labelled as "without coding".

I was responding to vexymous who suggested visual scripting as a direct answer to OP's question of "can I make a game without coding?"

To elaborate a bit further on visual scripting. I think it's one of those things that sound good in theory but are a total failure in practice. The intended purpose you cited (make aspects of game logic available to non-programmers on a team) really makes no one happy. Programmers will have to deal with cumbersome point-and-click programming, and non-programmers will still need to think like programmers if they want to make any significant edits to visual scripts. And the reason they shy away from coding in the first place is precisely that they don't like or want to think like programmers.

If you have programmers and non-programmers on a team, better to let programmers make flexible parametric systems, and simply expose properties (or gui controlled rigs) for non-programmers to play with, tweak and configure. Much better than forcing visual scripting down everyone's throat.

To conclude, if you're interested in programming aspects of making games, you'll need to learn coding. If on the other hand you're primarily interested in non-programming stuff, you'll have to team up with a programmer or two. Otherwise, your game won't happen, regardless of how much visual scripting or other such gimmicks you throw at it.

xyz The intended purpose you cited (make aspects of game logic available to non-programmers on a team) really makes no one happy.

No one is happy? Really? Well, that quote mentioned that visual programming was used. Note the wording — "main engine language". How visual programming can be a main engine language is a mystery to me, but if reworded like "Was visual scripting used in your project?" — the result could be quite different. In any case — a certain proportion of developers used it.

And the reason they shy away from coding in the first place is precisely that they don't like or want to think like programmers.

The problem is mirrored. Programmers, for the most part, are not artists. That's why designers, looking at the design of games created by programmers for programmers, turn grey and lose the last vestiges of their hair. Any means of engaging artists to create games and furnish them with a comfortable atmosphere in this is justified.

Much better than forcing visual scripting down everyone's throat.

That's probably a viable option. But apparently each approach has its own niche. And why substitute concepts and use the term "forcing"? Choice is good; no choice is bad.

Otherwise, your game won't happen, regardless of how much visual scripting or other such gimmicks you throw at it.

Blueprint disagrees with you.

Personally, I've made a conclusion for myself and am trying to learn programming, but getting artists involved as much as possible is the main goal. And, of course, the question of how best to organize the joint work of characters so different mentally and in terms of experience, but very similar in terms of extreme individualism, is extremely relevant.

Godot is fundamentally different from all other engines in that it is ideal for learning programming.

For many of these users, Godot is a tool to learn programming instead.

Yup, GDScript is a simple and straightforward language. But, keeping it visually coded could help the student to learn, if the teacher could show the effect of the functions and variables. (Such a request has been made in this forum.) It could also help students learn how to work collaboratively. This is a niche where Godot has little competition. Today's students, introduced to programming through Godot, could participate in its development in the very near future. It's an investment — you don't forget your first love. And throwing away such a gold mine is, in my opinion, not very witty.

Designer vs. programmer

I haven't figured out how to embed a video and it's not showing up for me. That's why it's duplicated by a heavy .gif. If the video is visible, the gif can be removed to save space.

Przepraszam. Maybe I'm very paranoid, but I have the impression that the degree of discussion rises a little, so I'll leave it at this point.

There's apparently some HTML in this thread that's messing up the browser's rendering.
Notice in the screenshot that the thread display overlaps the top of the window. This does not occur with other threads. This happens with Firefox, but not with Chromium. Maybe it's a Firefox bug.