Godot: Bi-directional Visual to Text: an other paradigm to write code.

[Gurigraphics]

Problem 1
I can add the "camera2D" functionality in the character, for example, just by attaching a Node to the character.

I also can create a "playerMove" node, for example, and never again rewrite this code, nor locate in an external place how to do this.

However, the process of creating a node requires configuration files, external icons and this is done outside the Engine.
http://docs.godotengine.org/en/stable/tutorials/making_plugins.html

Problem 2
A "page of code" is like a book without sumary. You do not know what's inside without opening and searching. And even worse when the programmers no insert comments.

Problem 3
When I add the node "camera2D", for example, I do not have access to the contents of this node. It is a black box. The implementation is done in a traditional way, outside the Engine.

---

This is the current reality

This is other possibility

Once that the user can easily create and edit nodes the productivity increases about 10x. Because, using nodes in this way is like create behaviors in Stencyl. This only changes the name: node to behavior. Lastly, the index for navigation of example above, It's no different from how everything is done within Godot.

Visual programming is great for sort and organize.
And writing programming is great for copying, pasting and editing.
So we have the best of both worlds.

What ultimately matters is more organization, more productivity, more quality and more result. And how this all can or will be improved, I have presented something to consider.

[bojidar-bg]

@Gurigraphics Would you mind explaining the original problem (not just its solution and how it is better than everything devised before), since it otherwise falls under this point of the FAQ?

[Gurigraphics]

Ok. @bojidar-bg
Updated

[Warlaan]

I am sorry for being so harsh, but it is pretty apparent that you haven't really understood the systems used in Godot yet.

Godot uses several different languages: GDscript, scene files (which are a visual declarative language) and C++ are the most important ones. Writing modules in C++ is working IN the engine, it's not "outside the engine".

Yes, you do not immediately see the implementation of a node class, it's a basic principle of object orientation called encapsulation. Of course you don't know what's inside unless you open the files, but once you do you will appreciate it if the file is written in a language that is suited for writing such "black box" code (i.e. library code), because it has an extra summary (a.k.a. header file), because it has keywords that tell you which part of the code is interesting from the outside and which is meant as an implementation detail, because it can rename types to better reflect what is going on etc.. That's why Godot uses C++ for backend code rather than GDscript, a language that is optimized for high-level game code.

Also the paradigm that you are proposing has severe issues that would need to be resolved first.
What's the scope of variables inside one of these code blocks? Can I have one block that declares variables and another one that uses them? If so what happens when two blocks declare variables of the same name?If not then what's the difference between these code blocks and methods?

Either way I am getting the impression that you are suggesting to move away from object orientation because you didn't really understand it.

[Gurigraphics]

Writing modules in C++ is working IN the engine, it's not "outside the engine".

I wrote "outside the Engine" because outside the Editor what we have is a Framework which "does not encapsulate" code.

Also the paradigm that you are proposing has severe issues that would need to be resolved first.
What's the scope of variables inside one of these code blocks? Can I have one block that declares variables and another one that uses them? If so what happens when two blocks declare variables of the same name?If not then what's the difference between these code blocks and methods?

I'm not proposing to reinvent the wheel. The different blocks types can be sorted by shape, color, icons. That's what does Scratch, Stencyl, Google Blockly, etc.

Either way I am getting the impression that you are suggesting to move away from object orientation because you didn't really understand it.

And I'm sure you guys do not understand. The Scratch blocks logic is based on Smalltalk. So I'm really moving away from Object Orientation to Purely Object Orientation.

Anyway, I just shared it because I thought it was a good idea. If this does not follow the Engine Philosophy, then I can create an external code editor as only I have an interest in it. Sorry to bother.

[Warlaan]

I don't mean to discourage you from creating such a tool, I just want you to be aware of what Godot currently does have. The engine has already grown too fast in the past which led to a rising number of bugs, and with version 3.0 coming it will already add C# and visual scripting, so before we think about adding something new we should first see how these additions affect the community and the engine.

[Gurigraphics]

Certainly this idea is not urgent. I only prefer the visual system of Blocks than Blueprints like Unreal. Because it's not just beginners they prefer to use. Blocks inside blocks it really is faster and more organized. Godot chose the other way. But, as long as there is someone who has interest in develop this, there is no problem at all.

[bojidar-bg]

@Gurigraphics Note that you can already kind-of fake such a system by not using scripts directly, but attaching them to Node-type nodes in a hierarchy.

I would like to say a few things about the idea and some comments above (and hope I'm not too harsh):

• The idea doesn't follow OOP principles IMO, though it is still cool as an idea. Something similar might be implemented in OOP by just.. I guess, splitting the code between multiple classes and having some container-like class that calls them at appropriate times, similar to what I said above. I once did something similar to this here.
  
  
  
  • Thinking about it, are you sure it isn't aspect-oriented programming?
  
  
• If by "Purely Object Orientation" you mean having primitive values be objects as well, GDScript already mostly treats them as such (but there are no methods defined on int/float classes yet).
• Modular code is still battled by many people and many languages, and it is something everyone wants. E.g. here is the wikipedia page for it.
• "The different blocks types can be sorted by shape, color, icons. That's what does Scratch, Stencyl, Google Blockly, etc." -- We are not planning to turn GDScript into a visual scripting language, just like python 4.0 is unlikely to be done via an official drag and drop editor.
• You can already define new types of blocks for VisualScript, and just connect them in .vs files. (not completely sure how, but it must be possible, since that was part of the idea)
• "..And I'm sure you guys do not understand." -- Nice try. Strange why Java/C# are still hailed as the most-OOP languages, and they don't really provide this feature.

[Gurigraphics]

Okay. Maybe this can be used to create a editor like sublime and only this.

About the discussion this may interest you:

"Smalltalk is an object-oriented, dynamically typed, reflective programming language.
In Smalltalk everything is an object: numbers, classes, methods, code blocks, etc. There are no primitive types, unlike other object-oriented languages; Strings, numbers, and characters are implemented as classes in Smalltalk, so this language is considered purely object-oriented. Technically, every element of Smalltalk is a first-order object".(Wikipedia)

Good job.

[bojidar-bg]

@Gurigraphics Funny, I read the same while composing my comment above. And I can't see how your proposal gets us closer to Smalltalk.

[nhydock]

Not really following most of the debate going on here, but something stuck out to me with that second image. In terms of IDE functions, it would be nice for the script editor to have things like a structure tree like you find in IntelliJ or being able to declare regions like in C# so you can hop to sections of the code faster. However, since this is primarily scripting and not system architecture, typically if you script gets long enough to need such IDE features I'd recommend splitting it up instead. I think adding that would probably alleviate most of OP's concerns

[eon-s]

In the perfect environment, the programmer is the one that makes plugins, the designers just tweak them and is easy with basic gdscript, tool mode and plugins (all reusable stuff made with the engine).
Programmers can make visual script blocks with the game needs for designers to use without breaking anything too.

---

I don't see the problem in 1, look at different FSM implementations on the asset lib, all are easy to use, some almost pure node based.

For 2, tell your programmer to write a good code and document if needed (the design should specify most of the code flow anyway), visual scripting don't bring anything good to this problem (just can make it worse).

For problem 3, the inspector shows everything the engine can offer to the user, and if you need something extra, use export if possible or tell your programmer to modify the engine and expose something else, that is the way game programmers should work for the different designers on the team.

---

If this is to just present the code in the form of visual "solid" blocks, Visual Script already does that, maybe making it more flexible and allowing stacked blocks like Stencyl to look more legible (while avoiding stencyl paradigm issues), it may be just a matter of a new Control with the same functions as the GraphEdit and GraphNode but stacked in a compact way.

[Gurigraphics]

@nhydock Can be. I'll list only the characteristics that do not alter any paradigm of language.

1- This allows you to use "fake classes" in any language. Because it is the editor that mounts the code according to the order of nodes.
2- This replaces the system of folder and "independent files" by system of nodes and "related files".
3- This replaces the creation of snippets by creating nodes.
4- This adds the possibility to reorder snippets of code visually.
5- This replace the function of hiding snippets of own code that are in all big ones editors by indexes navigation.
6- This enable indexes navigation that is usually only available in debugging.

This provide another code writing experience. The theory does not is the that help to understand the pragmatic advantages of this. The other possibilities what did I mention, I will not trying more to explain. Because this arise naturally when the person begins to use this and think outside the box. And also there is no problem who has no interest in this.

[Einlander]

This proposal sounds like a super verbose version of scratch :/

[kubecz3k]

I'm revisiting old issues, I will close this one since there was no interest in this in twelve months. If there will be any fresh interest we will reopen.