G0dot without Coding works?

Tomcat

DaveTheCoder There's apparently some HTML in this thread that's messing up the browser's rendering.

It is quite possible.

cybereality The forum works fine on Firefox.

Not always.

LibreWolf — works fine (video is displayed).
Pale Moon — not so good.

The behavior does not change when the ad blocker is turned on or off.

sammonius_s

DaveTheCoder

It's a basic human right

Like I said, it makes things harder instead of easier. I was going in the direction of "Ohh so you were seeking/avoiding this thing. In that case try...". Trying to code without writing code is like trying to communicate in only emojis. No one who knows how much better the alternative is would do it. GDScript is an extremely easy programming language.

But if you just wanna argue for the sake of arguing then that's my bad.

DaveTheCoder

cybereality The forum works fine on Firefox. But it looks like you are using NoScript or an ad blocker, which breaks the Javascript, so obviously that causes errors.

If I select the NoScript setting to disable restrictions for this page, allowing scripts to run, then the problem does not occur. I've only had to do that previously for this site occasionally, to display certain media in topics. I'll mark this as a trusted site; that should prevent the problem from reoccurring.

Megalomaniak

DaveTheCoder If I select the NoScript setting to disable restrictions for this page, allowing scripts to run, then the problem does not occur. I've only had to do that previously for this site occasionally, to display certain media in topics. I'll mark this as a trusted site; that should prevent the problem from reoccurring.

in this specific case it's an embed from 9gag via their own cdn cache:

cybereality

I believe the issue is related to how the forum resizes videos. When you upload a full size video, it only displays like a 100px high sliver of the video that expands with Javascript when you click it. But if Javascript is disabled, it likely has the default size of the video, which could be large like 720p. So it's most likely using the incorrect position/size for the CSS, which normally gets overwritten with Javascript, but cannot when using NoScript or similar plugins. That's my guess at least.

cybereality

I wasn't able to reproduce the issue, in Firefox on Ubuntu with NoScript. But it's no surprise, NoScript breaks every website on the internet.

duane

The problems with the site controls seem to go away when I allow scripts from 9cache.com (as well as godotforums.org) in noscript.

xyz

Megalomaniak In fact I think the failure with VisualScript was that it was too much straight up visual graph version of GDScript rather than higher level scene graph for bringing together different elements(nodes with attached scripts, FSMs ... maybe even push things to and pull things from databases and hooking everything up with signals and drivers/event triggers in a visual 'nodal' way.

Yeah it's just a different interface for GDScript, that's probably why it's called VisualScript 🙂

Imho, adding some sort of higher level graph would be powerful if implemented well but could considerably complexify the architecture and consequentially bog down the performance.

This reminds me of Maya where you have two types of nodes, composing two partially overlapping types of graphs. One is classic hierarchical tree of mostly displayable nodes (similar to Godot's scene tree), and the other is directed, non-hierarchical dependency graph. Dependency graph can "pass through" some nodes from the tree graph but typically employs a bunch of non displayable worker nodes that munch and spit data. This architecture is extremely flexible. That's why Maya is to this day virtually unbeaten when it comes to complex rigs and setups. You can do almost anything imaginable with it. However, as most modern 3d apps, Maya is not real-time scriptable (save for expressions), and any scriptable system would blow it out of the water in terms of flexibility. With real-time scripting you can implicitly establish any inter-node connection achievable by graphs, and then go beyond. Scripting can, for example, handle cyclical data flow which most graphs would refuse to do.

Another problem with graphs is the precise visualization of data flow. Ironically, flow visualization is often touted as a main advantage of graph based systems. Notable example is Blender's geometry nodes. It's basically a geometry shader in graph form, but it struggles to discern between field and "normal" data representation (in glsl terminology; vertex attributes and uniforms/varyings). Two fundamentally distinct things are differentiated only by color coding of noodles. This does almost nothing to depict what's actually happening with the data. The nature of geometry shader data flow simply does not lend itself well to box+noodle representation. That's why geometry nodes tend to confuse people unfamiliar with the concept of vertex/geometry shader.

Megalomaniak

xyz Imho, adding some sort of higher level graph would be powerful if implemented well but could considerably complexify the architecture and consequentially bog down the performance.

I recon it might make most sense as a addon/plugin via GDExtension. As for the performance thing, I'm not sure it would necessarily be a huge overhead, though some for sure. Ultimately depends on the project and it's performance/minimum HW target if too much or not.

Tomcat

xyz Imho, adding some sort of higher level graph would be powerful if implemented well

Aha… So, there are situations where visual programming can be useful… thanks… that's what I wanted to hear… let's put it that way.

Megalomaniak I recon it might make most sense as a addon/plugin via GDExtension.

That's all true… but I highly doubt it will be implemented in the foreseeable future. Designers need it, but they don't have the necessary qualifications. Programmers are piously convinced that everyone must learn programming… there is some truth in this, of course, but the accompanying problems and overheads are too great. The only people who are interested in this and who may have the necessary skills — are experienced teachers, if Godot become a kind of standard for teaching. But this contingent usually has no free time at all, all taken up by the curriculum.

This is a highly non-trivial task — here I fully agree with @xyz . Perhaps the mutual misunderstanding is due to the fact that he approaches it from a programmer's point of view and considers the effort required to do so unwarranted. I am convinced that the benefits, including indirect and deferred, can pay for the costs. This question is highly debatable. In any case, Godot now has more pressing and urgent problems that need to be solved… unfortunately.

cybereality

If the visual scripting is higher level than the code, then it's useful. For example, Blueprints in Unreal is very well designed and powerful, you rarely need C++ unless you are doing something unique or need high performance. Even then, you can create Blueprint nodes with C++, for example a senior programmer can create the logic and expose a few input/outputs or variables, that a gameplay engineer or a level designer can tweak, without any understanding of the code. For small teams or one person projects, this distinction may not matter, but it does make a huge difference when you have non-coders or artists on the team that wish to make changes and would never be able to edit C++ code. Many artists are also familiar with node graphs from Maya/Blender/etc. so it's not a huge learning curve.

xyz

Tomcat Aha… So, there are situations where visual programming can be useful… thanks… that's what I wanted to hear… let's put it that way.

We were discussing graphs. Graphs are generalized mathematical structures that have broad range of applications. They are per se not even remotely synonymous with "visual programming". A graph based system needs to be Turing-complete before it can be considered "programming" in true sense. For example, streets in your town constitute a bidirectional lattice but there is no way to use them to implement bubble sort. Blender shader networks are not Turing complete either, so strictly speaking, building them is not programming. Same holds true for Godot's scene tree and Maya's DG networks. All triangular meshes in your favorite game are undirected graphs as well but they don't have any computation capabilities.

xyz

Tomcat @xyz . Perhaps the mutual misunderstanding is due to the fact that he approaches it from a programmer's point of view and considers the effort required to do so unwarranted

No, I perfectly understand your position. The problem is that I was speaking from the perspective of a team producing a title, while you were reading into it from the perspective of a casual coder.

"Viusal programming" is as useful as any other type of programming. It's also as hard. Therefore your argument that it's easier because programmers can make visual programs for non-programmers on a team to tweak is fallacious. It compares apples and oranges. They can as well make regular code or rigs for non-programmers to tweak. Same difference. Programming is the hard part here, and tweaking it is the easy part. It doesn't matter if the code is "visual" or not.

If you don't believe me, here's a test for you. Try to implement biarc interpolation first in GDScript and then in VisualScript. In both cases provide tweakable interpolation parameters for the rest of us on the team to play with. When you're done, compare how hard was each to implement and how hard is each to tweak.

So if you have programmers on a team, they should be responsible for keeping non-programmers as far as possible from tedium of programming. Good programmers naturally gravitate towards producing highly flexible systems. This is always beneficial to non-programmers on the team as they can simply use those systems instead of needing to do pretend-coding.

DaveTheCoder

This discussion makes me think of other discussions that probably occurred decades ago:

Before there were high level programming languages, programming had to be done in assembly language (or even machine code, or setting DIP switches).

Before there were WYSIWYG word processors, word processing was done using applications such as Runoff using text formatting tags.

Before there were WYSIWYG web design applications, web page design had to be done using HTML tags.

There are still situations where the low level coding has to be done, but for "the masses", the high level tools can be used.

Tomcat

xyz while you were reading into it from the perspective of a casual coder.

I appreciate the compliment, but you flatter me. 😊 I am NOT a programmer. I've been in design all my life. And I'm speaking from an artist's point of view. And I only recently started studying programming to try to make my own project. (I'll skip the episode of my life where I studied programming introductively decades ago.)

You make it so easy to say "find and team up with a programmer". And any programmer is not suitable, I was very clearly explained the difference between the casual and game programmer. Are you personally ready to join the project? Good programmer to find a very difficult. Perhaps even much harder than writing a program on the visual programming.

I chose Godot precisely because of the external ease of learning. Including learning how to program. The impression was correct.

xyz

Tomcat Are you personally ready to join the project?

Nope. I'm afraid my visual coding skills may be insufficient for "the project" 😉

Tomcat

xyz I'm afraid my visual coding skills may be insufficient for "the project"

You see how hard it is to find a programmer. But I thank you for your sincere and honest answer. Sometimes people take on things they can't do. Although, on the other hand, "trying to jump over the top" gives you the opportunity to develop your skills. You don't always have to be overly modest.

"Project" will be created in Godot 4.x. So we are not talking about any visual programming, of course. But you can try to put into practice your concept about artists' access to the fine-tuning of the program. I'm very curious about what that might look like. It would either result in extremely limited access to some variables or, when trying to provide advanced customization options… back to visual programming.

Meternik

If it is an animation it's possible with animation player, but you can't make a game without coding. Godot works without coding but not for making any game.

xyz

Tomcat You see how hard it is to find a programmer.

Sure. Complaining about it won't make it any easier though. Making games requires serious time and effort commitment. To attract competent people to your project you'll need to be able to readily display as many items as possible from the below list:

an elaborate design document, focused on game rules and mechanics, gameplay loops and world building
a working rough prototype and/or convincing animated mockups that demonstrate key gameplay concepts
visually interesting concept art sheets and mood boards
portfolio of your visual and/or design works
a viable business plan that includes prototyping, development, launch and marketing phases
a sound financial/funding strategy with focus on fees and royalties for partners and collaborators

The more of those you hold in your hands the more "luck" you'll have with finding partners.

There's also an alternative route; Befriend someone and participate as a team on a small, low-effort jam project over at itch.io. Successfully completing projects like this together goes a long way in forming partnerships.

In other words, you have to show your own powers and seriousness before expecting people to lend you theirs.

Tomcat

xyz Complaining about it won't make it any easier though.

Just like the Ukrainian march:

"For crying has not yet given anyone freedom"

That's pretty much it… or so it seems… the point is that the project is very much experimental. Therefore, the existing frameworks are very poorly suited to it. However, the fact that it's possible to create a strong game even without a design document at all is known.

But in general, I follow this plan and have all the points except the second

a working rough prototype and/or convincing animated mockups that demonstrate key gameplay concepts

and that point is a frontier in my concept. I'm working on it now.

There is a third way. You could say it's a compilation of the first two options.

In any case, progress on the project will be posted on this site.

In my opinion we've gone way off topic, but since the moderator is flooding along with us, we're good for now. 😹

cybereality This is why I do everything myself.

Single work, unfortunately, very much limits the scope of possible work.

cybereality

This is why I do everything myself.

« Previous Page Next Page »