Would making game using Godot engine source code and removing editor and using C++ coding to make not GDExtension but entire logic for gameplay instead of using editor make any sense whatsoever?
Obviously the Godot use scons for compile, so the itterations be to test gameplay be via terminal, but be interesting to know if anyone attempted it.
Did I tried it ?
No, I’m still discovering Godot source code.
Would this approach help make anyone better performance?
Well this will be a bit of theoretical as it seem to be irrational not use editor for scene hierarchy but instead binding classes in new cpp /.hpp files .
That would be great if you do that! (At least for who doesn’t want the editor) But I think I could be a lil hard. What you could possibly do is duplicating the engine for creating a “new one” ( I never done that and I never found a tutorial but it’s the easier way since you could get errors.)
It’d be a strange setup, you can’t really use resources or scenes effectively without editor integration or handle importing assets, and not using resources or scenes is not a very efficient way to handle game data
What would be the goal of this or is it just an experiment to see if it’s possible? I doubt it’d give better performance to manually create (and manage, a spaghetti code nightmare if you ask me) scenes and resources and configure them instead of using resource and scene files etc.
You could use the editor in a minimal way by having some form of export plugin or similar, or run a completely custom scene tree to get around the main scene, or create a dummy main scene, but I’m not sure Godot is the best option if you are largely going to not utilize the scene system and files etc., especially if you intend to be minimal in using the editor (you can’t really not use it at all I’d say unless you create some very custom setup to just run the export template directly, you probably need to at least use it for export)
This, or some variant of the question is asked pretty often. I guess Godot gives a pretty good experience for users to want to push it’s options back to the metal.
Ultimately if you are choosing a game engine you should be doing so for it’s editor, rendering, physics, and optionally networking. If a game engine doesn’t handle those implementations, or doesn’t handle them well, then it’s probably not a good game engine.
If you don’t want to use a game engine’s editor, rendering, or physics, then you should be looking at frameworks/libraries instead, like SDL2 (now SDL3!), SFML, Raylib, and Bevy. With these you will be in charge of making your own editor (if needed, many leverage importing from tiled or blender), rendering, and physics.
And if you don’t want to use a framework then diving into Windows API is probably what you’ll be doing. The frameworks usually provide cross-platform window creation, inputs (though not through action-mapping), and a rendering context.
No. Even if you don’t need/want to use the scene tree. There’s plenty of stuff in the editor that’d you’d need to reimplement anyway, especially in the later stages of development when “boring” managerial things take precedence over “exciting” core technical problems, so called high-level stuff that makes the crucial difference between a game and a tech demo. That stuff is also tedious to implement so why waste time on that when there’s an excellent ready made solution. It’s much easier to write a gui-based tool in the context of the editor. And you’ll need dozens of such custom tools for a typical game.
You also wouldn’t want to get rid of a scripting language in favor of C++, for similar reasons. Do as little as possible in C++.
As an example the editor handles a lot of data automatically like UIDs and other resource management, which improves a lot of structure and performance down the line, the editor also handles exporting resources including compression and customization. The engine isn’t really designed to use a lot of raw data formats directly for the graphics and audio and a lot of more performant features and some specific features are not available by just loading an image, it has to be imported through the asset pipeline and then exported properly
No. This is as practical as code golf. If you find that fun, then have fun. But this is a dumb idea if you are trying to do this for any other reason than “just to see if you can”.
It is a bad idea with many downsides and no upsides.
No. Because you would end up bypassing a bunch of built-in code that makes things faster - and you wouldn’t know how you optimize it.
Thanks for view, i quite noticed amount of modules and 3rd party components in engine itself.
Raylib seem to be cleaner framework, but doesn’t include Metal, Vulkan or DX support.
What would be minimum of Godot to compile to be able to make Window with text, and allow for text based game ?
Maybe C? it has cross platform printing to stdout with printf and reading from stdin with scanf, Python is also cross platform and just as old. Just about any language will do as i/o is usually one of the first things implemented in one way or another.
A text game on itch could be done with javascript, you can upload html/js to itch so make a text box and a submit button in HTML and process the written input with javascript. You don’t need OpenGL to write <p>Adventure begins</p>
If anything a web browser is just a larger coding foundation than most frameworks, so if you are trying to rely less on and less on libraries that’s the wrong direction.
While C (or C++ for that matter) provide standard functions for printing text, if you want this text to be formatted (foreground/background colors, bold, etc), or if you want to build a TUI (capturing input, “drawing” at arbitrary coordinates, responding to window size changes), these are platform dependent. On the unicies it depends on which features are supported by the terminal emulator, and Windows is doing its own thing. You will want to build something like this on top of ncurses, if not creating your own abstraction layer with ncurses as one back-end.
