Before I learned how to program, I used this software called "Klik&Play", later replaced by "Multimedia Fusion". This was over 20 years ago, but apparently the software still exists and works in a similar way:
For the logic, you get a table where every column is essentially a class, and each row is an if-then construct. The first column can be a condition, implicitly called once per frame, or an event with an optional condition. In each cell you can add actions that should be called on the instances of the class for its column. Everything is selected through simple dialogs.
For example, you'd make a condition/event like "Bullet collides with enemy", then add an action "Destroy" under "Bullet" and "Enemy" classes, something like "Play 'boom.wav'" under the "Sound" class, and "Add 1" to some "Counter" class. If I recall correctly that is.
This ended up getting me into programming, because I was able to quickly achieve results while being able to start experimenting with the UI before reading a single tutorial or any sort of document. I think discoverability is the killer feature. I could easily see that instead of destroying an entity, I could spawn another one. Or I could create an entity at the point of the collision, so I'd animate an explosion effect. But the explosion would just stay around, so I looked around what I could do... found an "Animation ended" event, so I simply made another rule that would destroy the explosion object when its animation ended. And so on.
I think another reason is that game logic is messy yet simple. So you don't want a lot of boilerplate code or having it scattered across lots of files, otherwise you're not getting a good overview. But I can't vouch for modern visual programming languages to solve that problem since I haven't really tried them.
Ha, I also started with programming using Klik&Play when I was around 9! I only had the free shareware version, and if I recall correctly, it was not possible to use custom variables or if/then/else constructs in the free version. You had to be creative to somehow store the game state using only the position of objects, and then using collisions to decide on an action. Since you could spawn objects at arbitrary locations, you could use this to do primitive geometrical if/then/else branching. I also remember that you could generate a single exe file which you could give to your friends. I created so many DynaBlaster clones and other Jump&Run games.
A while later I accidentally stumbled over the BASIC interpreter of DOS and was amazed how easy everything was there - you could just store a number in a variable and directly do stuff depending on its value!
For anyone interested, here is a (bad quality) video from the 90ies explaining the software on Windows 3.1:
GameMaker (version 4… in 2001, man I’m getting old) had a similar system. It’s also what got me into programming, as I could also attach my own scripts to event triggers (and sets of event triggers, in a linear visual GUI logic way), and so I learned GML as my first programming language.
Klik&Play was awesome. Must have made at least 30 dumb games with it when I was around 12-13.
I definitely never got anywhere typed code wise around the same time even though I really wanted to make games, all the options just approached you as if you had a comp sci degree.
For the logic, you get a table where every column is essentially a class, and each row is an if-then construct. The first column can be a condition, implicitly called once per frame, or an event with an optional condition. In each cell you can add actions that should be called on the instances of the class for its column. Everything is selected through simple dialogs.
For example, you'd make a condition/event like "Bullet collides with enemy", then add an action "Destroy" under "Bullet" and "Enemy" classes, something like "Play 'boom.wav'" under the "Sound" class, and "Add 1" to some "Counter" class. If I recall correctly that is.
This ended up getting me into programming, because I was able to quickly achieve results while being able to start experimenting with the UI before reading a single tutorial or any sort of document. I think discoverability is the killer feature. I could easily see that instead of destroying an entity, I could spawn another one. Or I could create an entity at the point of the collision, so I'd animate an explosion effect. But the explosion would just stay around, so I looked around what I could do... found an "Animation ended" event, so I simply made another rule that would destroy the explosion object when its animation ended. And so on.
I think another reason is that game logic is messy yet simple. So you don't want a lot of boilerplate code or having it scattered across lots of files, otherwise you're not getting a good overview. But I can't vouch for modern visual programming languages to solve that problem since I haven't really tried them.