Develop some workflow for "low level" Godot development for advanced users

[ca3games]

Describe the project you are working on: A custom 2D engine on top of Godot.

Describe the problem or limitation you are having in your project: I want to really use Godot in a closer way to how you would develop a game in a game framework like monogame.

Describe the feature / enhancement and how it helps to overcome the problem or limitation: I need to have my own custom gameloop, which some godot users told me It was possible extending the game loop and customizing it using Servers. Still my issue is that is an area of not much documentation or interest in the comunity, but is vital for serious developers (specially for professional programmers from a serious studio).

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams: Develop a better workflow to completelly work with godot in a "low level" that is closer to a game framework, without having to create C++ modules.

If this enhancement will not be used often, can it be worked around with a few lines of script?: No, because this is too low level to be simple lines of script.

Is there a reason why this should be core and not an add-on in the asset library?: It affects the core of the engine.

[ghost]

i don't have much else to say beyond, "yes, i want this too", but my post will be marked as off topic anyway for some reason

i'm not even sure where the main function is supposed to be, or where the first line is actually read by the compiler, or how anything is organized and what the general flow of the program is, i pretty much need to go in with the debugger and i need to waste my time to figure out literally everything since there's no documentation on any of this, and the source code itself is badly documented, as in, there's barely anything in it

i know that i'll just be told by everybody else that i'm dumb or that i need to just, learn it, or that "it's all obvious, just read the source, you don't need comments" (or any kind of documentation for that matter...) and crap such as "if you know what you are doing you will understand" and to me it sorta makes everything feel very elitist and it kinda makes me feel like there's a whole lot of gate keeping going on around here when that's the general attitude towards new users

a lot of users seems very hostile towards helping people figure out the more advanced parts of the engine either way, since they are just told to figure it all out by themselves, even when, it's not reasonable to have NO documentation at all

i don't consider the few, vague comments in the source code to count as "documentation", they don't help me in any way most of the time, since i don't even understand what the person who wrote the comments is talking about in the first place, so i need to figure it all out by myself anyway

if the people who work on godot honestly expect only industry veterans to work with the engine, or people who went to college or something, then i have bad news for them

[KoBeWi]

Why do you want to use game engine like game framework though? It kills the purpose of the engine 🤔

[Xrayez]

I want to really use Godot in a closer way to how you would develop a game in a game framework like monogame.

I think Godot is a wrong choice for that to be honest. I already considered trying out other low-level frameworks which you can assemble and configure to better meet project's requirements for that reason.

Godot's development philosophy is to provide tools which are easier to use to achieve the same effect as in commercial engines out of the box, but if you need more than the regular expectation, I think the best way you can do currently is to maintain your own fork (or a set of patches), which would work best in the long run, especially if you plan on making any kind of long-term project. Gladly, the available low-level C++ modules/GDNative tools allow you to solve a lot of limitations already.

I do believe that the engine could benefit from having more hooks/callbacks without sacrificing its intended design too much...

That said, it's quite possible to work with Godot Engine on the "professional level", but requires a lot of tinkering anyways. I don't have enough experience to assert that with confidence though.

I need to have my own custom gameloop, which some godot users told me It was possible extending the game loop and customizing it using Servers.

Here you go: godotengine/godot#41190! 🙂

[ca3games]

@KoBeWi @Xrayez I agree, maybe godot is not the best tool for engine developers, even then, is very common in the world of AAA game developers to have low level access for the professional programmers in the team. You could argue that godot is not meant for that, and I kind of agree. But I'm at the point where I need to start working on a project using monogame, for the same reason that godot is too high level. Even then, trying to remake all the goodies godot already has, is a hard blow proposal. It may seen I'm kind of being ilogical, but this is not meant for begginers, but for more advanced users, and could be nice if you were allowed to customized a godot game while working in some low level, closer to working with a game framework, would be really nice for some crazy guys, who may still want all the Godot goodies the team has made, but still work in an enviroment closer to something like monogame, without having to fork the engine and work in C++

[Xrayez]

Even then, trying to remake all the goodies godot already has, is a hard blow proposal.

Yes, I think that's one of the reasons why even seasoned developers find Godot compelling, ideologically it's a really nice engine. I'm not sure if I'd be able to switch to something else without having to reinvent similar architecture Godot currently has. I think that may be one of the reasons and motivation behind proposals like #1330.

[ca3games]

@Xrayez I think godot already has support for what I am asking, you can customize your own gameloop and you already have the servers, but is a really obscure part of the engine, and there's nothing on the internet beyond the basic documentation. So is kind of hard to figure out how to work in a "low level" using the Engine. Maybe this could be a chance for the documentation team to make a section on "low level" use of Godot. Would be nice.

[KoBeWi]

But I'm at the point where I need to start working on a project using monogame, for the same reason that godot is too high level. Even then, trying to remake all the goodies godot already has, is a hard blow proposal.

Well, Godot is open-source, so all its goodies are already available for you. You are free to take the code and use it in whatever way you like, framework-like included. If you want to use the engine this way, you should be prepared that it's more difficult.

[ca3games]

@KoBeWi I agree, but still there's not a lot of information on this issue, so is much harder, not because is technically harder but because of lack of documentation on this.

[TheDuriel]

The basics of how to replace the SceneTree, and thus use Godot without Scene should be documented. It's the only thing you need to do to use Godot as a framework, and its not actually all that hard.

There even is a useless setting in ProjectSettings which is meant to let you set a custom MainLoop instance instead of SceneTree.

[ca3games]

@TheDuriel yeah, I agree is not so much an issue of lacking some feature, but more on having better documentation on this area, maybe the comunity could make some "demos" showcasing how to use godot more like a framework.

[Calinou]

@ca3games Documentation issues should be opened on the godot-docs repository. That said, please open one issue per item that should be documented. Therefore, it wouldn't really make sense to create a generic issue about documenting low-level Godot development.

[Xrayez]

Therefore, it wouldn't really make sense to create a generic issue about documenting low-level Godot development.

I think the proposal is more like "call to action". It's difficult to know what you don't know in order to be able to request specific documentation on this topic.

The problem is that when you know something, you're reluctant to document it (unless the information is quite heavy on numbers, constants, algorithms etc). So we're left in a difficult situation of "teacher vs student".

But yeah I agree that if certain low-level stuff could've been documented earlier, I wouldn't have to spend my time figuring this all out by myself back in the days of Godot 2.1. Writing documentation is also a difficult and time consuming task in and of itself because you have to be really good at matching your understanding to the mental map of other people, only complicated further by existence of the many natural languages such as English, apart from C++. 😛

Unfortunately, we live in a world of quick-fix mentality and everybody just want to "make it work now". On the contrary, some developers that use Godot for their (on Steam) games said that they really wished for the engine to be more stable (but I think a lot of people simply misinterpret the word "stable" in the context of versions managing, because stability is within the API, but doesn't mean bug-free). What I imply by this statement is that focusing on stability can certainly make the documentation part more stable as well, oftentimes what was written months ago gets removed.

And of course another problem is that most contributors are not even paid to do that, so they go and say: "Why bother"? That's on the contrary with commercial engines, where developers are highly interested in making their product bug-free and fairly documented. Else you're on your own mostly, unless another person sharing the same interests helps you to achieve the same thing, I think that's the only force for open-source software development currently (excluding donations of course).

I mean, some people just write books instead of documentation, likely due to the same reasons outlined above.

[Xrayez]

Protip: look at various tests implemented (not exclusive to Godot), for instance 2D physics. Those kind of "tests" inherit from the MainLoop, the scene system is not used there at all. Tests are a form of documentation.

[m6502]

This would be of interest and use for me too :-)

[Calinou]

@m6502 Please don't bump issues without contributing significant new information. Use the :+1: reaction button on the first post instead.

[willnationsdev]

@ca3games

Similar to Calinou's assessment, I would submit that 1) documentation requests should be in godot-docs and 2) requesting that "low-level" stuff be documented is a bit too generic. It would be more useful if you specifically outlined what kind of use of Godot you would like / expect in terms of "using Godot as a framework", and then request that, if it is possible to do such a thing in Godot, that the process be documented. That presents an explicit use case of what needs to be better documented to show people how to do such a thing. And if, in the process of creating those use cases / documentation, we find that Godot has some sort of restriction that prevents it from being used as a lightweight framework, then you could submit a Proposal for how to remove those obstacles, citing your unsupported use case.

[Calinou]

Closing per the above omment. The ability to use Godot in a low-level manner is already there, but documentation is a little sparse. Since the community interest in low-level Godot development is fairly limited, it will likely take a while for the documentation in this aspect to improve. Still, if you're interested in helping improve the documentation, open issues on godotengine/godot-docs and join the Godot Contributors Chat :slightly_smiling_face: