11
\$\begingroup\$

How can I setup a Godot 4 project in the way of a "classical" software project? With a Main function. Openable in any IDE. Compiling to an executable file to which I may attach any debugger or profiler fitting my compiler. With visible, traceable data and control flows.

I have found documentation indicating that I should extend a MainLoop but that documentation seems to be... confused? I do not think it is talking about the same thing:

  • "Upon the application start, a MainLoop implementation must be provided to the OS; otherwise, the application will exit." - no. The OS calls Main. As long as Main does not return or throw, nothing will exit (well, the OS could of course kill the process, but will not do such a thing normally; but then, if the application previously forked additional processes, losing the first one will not necessarily shut down the whole application).
  • "godot -s my_loop.gd" - no. This is not how to start a C# application, nor a call to a C# compiler.
    (I guess it's fine for trying out an isolated part of the program, like e.g. a test runner for xUnit, but we are talking about the Main Loop here - not many "isolated parts" left when running the Main Loop!)

Alternatively, if this is not possible : How can I debug effects seen in the WYSIWYG editor (such as the sprite animation state machine) without lines of code for breakpoints and without fields for watch points? Using a normal debugger for the language chosen, e.g. the Visual Studio debugger or the Jetbrains Rider debugger or even lldb?

... I have been a programmer for decades now, including for games, but (or maybe thence?) I cannot seem to wrap my head around working with these "Game Engines" in particular. Previously I have given up on Unreal and Unity, now I am trying Godot, but the problem is always the same: They take away all my tools and give lots and lots of... inadequate, indirect, immature, inferior replacements. I just hope it is a matter of unmatching vocabulary (that is: I am using the wrong terms for this domain) or similar misunderstandings and easily resolved.

\$\endgroup\$
5
  • 4
    \$\begingroup\$ I haven't used Godot, but it seems clear from a cursory glance at the documentation that MainLoop is an engine-specific concept and is not the same as the main() function called by the OS when the application starts. \$\endgroup\$
    – Kevin
    Dec 20, 2023 at 23:14
  • 17
    \$\begingroup\$ With modern engines such as Unity and Unreal, the engine is far more than just a library of code that you build onto. It might help to think of it this way: you're not developing a full application, you're developing content that runs in the engine. Your content will almost certainly include custom code, but the content in and of itself isn't a full application. Depending on the engine and licensing terms, you may or may not have access to the source code for the engine and editing tools, but you're generally not expected to need to debug the tools... \$\endgroup\$
    – Kevin
    Dec 20, 2023 at 23:49
  • 10
    \$\begingroup\$ ...just like you wouldn't expect to need to run a debugger or step through the source code when authoring content with software such as Word, Photoshop, Final Cut Pro, or Pro Tools. \$\endgroup\$
    – Kevin
    Dec 20, 2023 at 23:53
  • 9
    \$\begingroup\$ You want a "code first" game engine. They are much more like normal applications. JmonkeyEngine is one such engine and a JME application can indeed be opened in any IDE and has a main method. \$\endgroup\$ Dec 21, 2023 at 13:24
  • 1
    \$\begingroup\$ Possibly related question from me about Unity years ago: gamedev.stackexchange.com/questions/81648/… \$\endgroup\$
    – Ray
    Dec 21, 2023 at 16:06

3 Answers 3

15
\$\begingroup\$

Finding the entry point in Godot

Godot has a different entry point and uses different binding for each platform it supports. Because of that, it does not offer access to any of the actual entry point functions. Thus, if you want to do this with Godot you would be working with the source code, i.e. clone the repository. See Building from source.

In fact, Godot supports two approaches to develop your games in C++ (Modules and GDExtension) beside modifying the source code.

Of course, you can modify the source. My answer to How is the Godot Engine itself structured? might help you get around.


Using Godot as a library

If your goal is just to retain control of the entry point, consider for example SwiftGodot which allows you to take control of Godot as if it were a library (something that has been proposed for the engine, but has no official support).


Debug your game on Visual Studio Code

I also want to highlight that even though the GDScript debugger is built-in inside Godot, you can connect to via socket since it launches a debug server over the loopback adapter. In fact Godot-Tools plugin for Visual Studio Code connects to it this way, allows you to debug GDScript from Visual Studio Code. Similar plugins for other IDEs should be possible (although I'm not aware of any). If you also want to debug C# from Godot inside of Visual Studio Code you can use C# Tools for Godot.


Godot development (as in developing the engine, not a game on the engine)

Let us say found a bug in Godot and want to fix it yourself. Even in this scenario it remains a good idea to report it, as the developers expect either an issue or a proposal to justify any pull request. See the Pull request workflow.

Of course the contributors need to debug the engine, which is different from debugging the games. In Building from source you also find how to make debug builds. And, of course, Godot is a C++ application, which you would debug with a suitable C++ debugger.

There is also a contributors chat where you can find help when working on improving the engine.


On other engines

And yes, it is the similar situation with any Game Engine in that they hide the entry point (and arguably worse if you don't have access to the source code). Which makes me think you want a game development framework that is not a Game Engine.

So, I would like to submit these to your consideration: The Best Game Development Frameworks. Of course this is not an exhaustive list, and it is bound to be outdated, but I hope it help you find a better fit tool.


To be fair, if debugging the games is enough, if I recall correctly the integration of C# in both Unity and Godot allows debugging with an external .NET debugger.

\$\endgroup\$
3
  • 1
    \$\begingroup\$ +1. I had quite some difficulty formulating this question, and from previous tries with Unreal and Unity I am already quite aware that this is a "different worlds" problem. No surprise then, that the vocabulary and implicit expectations will differ a lot (as seen in the various other comments) between the "natives" and myself. The last link in particular looks pretty nice - I have already done (little, but good-feeling) work with the first two entries in the list: SDL(2) and SFML. \$\endgroup\$
    – Zsar
    Dec 21, 2023 at 12:47
  • \$\begingroup\$ ´That said, I'll wait a while before accepting, in the hope that some latecomer answer maybe does provide a way to bridge the gap, as e.g. Spring Boot allows for the Spring Framework, which I feel comes with similar expectations as Game Engines do (user code as embedded fragments, lots of runtime binding, large/powerful non-code parts, etc.). \$\endgroup\$
    – Zsar
    Dec 21, 2023 at 12:47
  • \$\begingroup\$ @Zsar I'm not familiar with Spring Boot. However, I have expanded the answer based on your comments here and on the other answer. \$\endgroup\$
    – Theraot
    Dec 21, 2023 at 20:03
10
\$\begingroup\$

With modern engines such as Unity and Unreal, the engine is far more than just a library of code that you build onto. It might help to think of it this way: you're not developing a full application, you're developing content that runs in the engine. Your content will almost certainly include custom code, but the content in and of itself isn't a full application. Depending on the engine and licensing terms, you may or may not have access to the source code for the engine and editing tools, but you're generally not expected to need to debug the tools, just like you wouldn't expect to need to run a debugger or step through the source code when authoring content with software such as Word, Photoshop, Final Cut Pro, or Pro Tools.

On that note, video editing software is a good analogy for how to think about these engines:

  • With video editing software, you'll create a project into which you import assets (video clips, audio clips, and images). You create content from these assets (by arranging them on a timeline). You can export your content (as a video file) and run it in compatible software (a media player).
  • With a game engine that comes with development tools/software, you'll create a project into which you import assets (code, models, textures, audio, etc). You create content from these assets (by building scenes/levels/etc). You can export your content (as some combination of binary and text data) and it runs in compatible software (the engine executable).

For the purposes of the analogy, the biggest difference here is that a video file is standalone content that can be viewed in different media playing software, whereas a game typically ships with an engine executable and only runs in that specific executable.

With video editing software, you wouldn't expect to need to run the video editor in a debugger or step through its source code. You don't need to worry about the specifics of how the video is played, or what platform it's viewed on*. You just focus on authoring your content.

If you look at developing in a typical modern engine with the same perspective, it starts to make more sense. The engine is designed to handle low-level things (like interfacing with the operating system, and initializing core modules) so you can focus on creating unique content for your game. The GUI-driven editing tools/software are designed to be usable by people who aren't programmers and without the need for debugging. Yes, the tools can have bugs, but so can any other software you don't have access to the source for.

*In reality, you do sometimes need to worry about things like what codecs and bitrates are supported on a particular target device, but that's too much of a tangent.


Let's look at part of what you wrote:

"Upon the application start, a MainLoop implementation must be provided to the OS; otherwise, the application will exit." - no. The OS calls Main. As long as Main does not return or throw, nothing will exit

The wording here is definitely confusing, but MainLoop is not the main() function called by the operating system. Your implementation of MainLoop is part of your content that runs within the engine.

If you want to see the built-in engine code that runs when Godot starts, try here: https://github.com/godotengine/godot/blob/master/main/main.cpp. If you search that code, you can see how the MainLoop gets initialized

\$\endgroup\$
7
  • 1
    \$\begingroup\$ Once (not if) one of the tools, say the sprite animation state machine, behaves in an unexpected way, how am I supposed to proceed, if I cannot debug it? Cry? Start over? Switch engines immediately? How is this use case modelled, considering it is guaranteed to occur sooner or later? The error is almost guaranteed to be miniscule and trivial to fix (as most errors are), but how to spot it, if the means to spot it are taken away? Finding the source of an error is almost always the - much, much - harder part. \$\endgroup\$
    – Zsar
    Dec 21, 2023 at 10:50
  • 1
    \$\begingroup\$ (FWIW: This is not meant to critique of your answer - it certainly sounds plausible to me: Such hubris is not unheard of in middleware design and I have encountered it often enough in e.g. the form of libraries with zero documentation: "You do not need to understand what happens, just use the public functions, those are self-explaining!" - I do and they are not, but every now and then a developer thinks so. And to be fair, it probably all is indeed self-explaining to its creator .) \$\endgroup\$
    – Zsar
    Dec 21, 2023 at 10:53
  • 1
    \$\begingroup\$ @Zsar usually after checking that you've done everything correctly on your part, the next step in such cases would be to file a bug report to the game engine, describing the repro steps. \$\endgroup\$
    – justhalf
    Dec 21, 2023 at 11:56
  • 1
    \$\begingroup\$ @Zsar - Yes, this is unfortunately a bit of the situation here. Although a bit better in the case of Godot, because it's open source, so you can actually compile it yourself and try stepping through it, but it's not really the intended way to go. Bugs in the engine will be relatively rare. By default assume it's working correctly and it's you who's done something wrong. The lack of good documentation however is a real problem, that I agree with. Although Godot does have something useable there, even if it is far from perfect. \$\endgroup\$
    – Vilx-
    Dec 21, 2023 at 21:28
  • 4
    \$\begingroup\$ @Zsar My suggestion is, rather than giving up now because of a hypothetical issue in the future, pick an engine, plow on ahead, and start learning. Once you acclimate to the development paradigm, you'll probably find that it's easier than you expected. However, take note that while Unity and Unreal let you debug your own code in Visual Studio, it sounds like Godot only lets you debug your own code in their proprietary debugger. But since it's open source, you could theoretically modify the debugger or write your own. \$\endgroup\$
    – Kevin
    Dec 22, 2023 at 1:32
2
\$\begingroup\$

Good, general answers already here. I'll just add a little Godot-specific information. One of the reasons why there isn't an alternative IDE for Godot (nor indeed is it likely for there to ever be one) is that a LOT (sometimes even most) of the development actually happens inside the custom "TSCN" (Scene) files. These files are not code but more like configuration. It's what ties all the separate pieces of content together into a coherent game. Their editor is the visual editor you have on the screen. Replicating that in another IDE would mean recreating most of Godot itself. There's just no point.

You can however use an external IDE for the code parts that you write for the game, if you choose to use C#. But, just to reiterate - that code will be just a part of your game, and might not even be the biggest part. It will just cover the hyper-specific parts of the game that are not already part of the engine. Most of the generic stuff (graphics, physics, collisions, etc) will be handled by the Godot engine itself, and set up via the TSCN files.

Remember - the point of Godot and other engines is to REDUCE the amount of code you need to write (up to eliminating it entirely in some cases), so they provide a vast set of tools and libraries to take as much work away from you as possible.

And don't forget that they are "frameworks" rather than "libraries". By that I mean:

  • A "library" provides a set of useful functions that you may or may not use in your program as you see fit. But you're in control of your own program and its structure.
  • A "framework" provides a program structure which you extend at predefined points.
\$\endgroup\$
1
  • 2
    \$\begingroup\$ Good answer! I'd add that tscn files are especially nice for version control since it's text based. I've had to occasionally merge scenes by hand and, while it's not fun, at least it's possible if you really have to. And you can use an external editor with GDScript! \$\endgroup\$
    – GammaGames
    Dec 21, 2023 at 23:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .