Is it possible to ONLY use GDscript, and completely avoid the GUI?

:information_source: Attention Topic was automatically imported from the old Question2Answer platform.
:bust_in_silhouette: Asked By toblin

Hi forum!

I’m a person who prefers to do everything through programming. The reason I got interested in Godot is that it seemed like it provided a lot of behind the scenes stuff (physics etc, like any game engine) but additionally allows one to do everything through programming (whilst providing a GUI for non-programmer users).

As I’m going through the Learning material however, I’m beginning to doubt whether or not it is possible to indeed “do everything” only through programming through e.g. GDscript (and then see the results through the GUI). Hence, I would like to ask the question to be sure:

Is it possible to design everything ONLY through programming in Godot, and then simply evaluate the results through the GUI? I’m fine with using the GUI software as a text editor, and a way to visualize and run the results (as an Interactive Development Environment (IDE)), but that’s about it.

If one needs to use the GUI for something else, such as inheritance, or whatever it may be, then it would be great if that something could be specified as well (if it can shortly be summarized). I’m for example finding it strange that one has to specify inheritance of the programming files themselves through the GUI, and that makes me suspicious of being able to create proper modules and packages through GDscript.

Any response will be appreciated. Thanks =)

Hi Tobias! Have you tried it? Does it work?

Marcus Dobler | 2020-10-10 19:22

:bust_in_silhouette: Reply From: wombatstampede

First of all, Godot is a game engine. You can also use Godot for developing (multi-platform) apps. Naturally, you’re also free to use and/or adapt to any other purpose you have in mind but that might not be what the developer community is focusing on.

Godot can generate apps that require no GUI.
Currently there’s a “Server” template available for linux only for that purpose.

Why Server? Because this module is mostly used for multi-player gameservers running on headless webservers. This way, you can use the multi-player classes in godot as well as common code/resources with the game-client projects.

:bust_in_silhouette: Reply From: chikamichi

First, for newcomers and seasoned Godot users as well: I feel like wombatstampede’s answer is not related to the OP’s question, who was not asking about creating headless games/apps (no GUI in the final build, ie. background scripts), but rather about being able to code games/apps using GDScript without resorting to using Godot’s editor for anything but rendering (and possibly coding inside the built-in code editor for ease of life).

Yes, it is possible to create a game/app using GDScript, without the editor needing to tie things up . Basically, one may attach a single “entrypoint” .gd script to the root scene’s root node, and preload/import, instantiate and put to use everything programmatically from there:

extends Node # hi, I'm the root scene's root node

# I'm responsible for loading & using systems, entities, etc.
# Let's assume my beloved developer coded using OOP:
var main_state = preload("res://lib/systems/").new()
var player = preload("res://lib/actors/").new()
# ...

# Let's use all of these and create a decent game/app!

One may still use the editor to edit the .gd files, which comes in handy because it has good syntax highlighting, type checking, etc. But VSCode and its official extension is pretty good as well.

Now, is that a “good” practice? Your mileage may vary. I feel like using GDScript that way kind of goes against the flow. GDScript has been specifically designed for integrating with the editor, and somehow many features/syntax provided by & “exclusive” to GDScript benefit from tight coupling with the editor’s UI (for instance, exported variables showing up in the inspector; tool scripts; etc.) One might be better off attaching not one but several/many .gd scripts to multiple, “key” nodes and keep the SOC to its usable minimum.

Please also remain aware that a somewhat “extreme” stance SRP-wise IMO would be to programmatically create most of your nodes (eg var player = etc. for most of the game entities/concepts), instead of creating an explicit node tree upfront using the editor. I feel like this is not the way Godot is meant to operate. Godot feels very strong when you create atomic, reusable scenes by aggregating child nodes/node types directly within the editor, so that anyone involved with project may then test and tweak things up (including non-programmers). The “glue (code)” might be programmatically handled for sure.

Relying on the exact same principle (entrypoint attached to root node), instead of .gd scripts, one may consider using other languages. Either through native support (C#) or through GDNative bindings. Compiled languages such as C++, Rust, D, Kotlin, Nim, Haskell, etc. are good candidates, for they are very easily attached to the runtime (see this example for godot-rust, works the same for any binding really), and these languages are arguably (way) more efficient, both performance-wise and management-wise for large, decoupled codebases. JIT languages are an option as well (for instance: Python, JavaScript/TypeScript, GameLisp…) And you may even mix multiple languages (just bind scripts/binaries to nodes in the tree).

Related question/answers: here on game.stackexchange.

:bust_in_silhouette: Reply From: MikeSundaysGameDev

For late-comers you can do that by editing the .tscn files yourself since the editor is only an interface for editing those via a GUI! Note that while there is not much documentation on this topic, you can do experiments to discover yourself! For example by creating a kinematic body on the GUI and then seeing what changes it does to the .tscn file
To edit these .tscn files the best way I see is vscode with the Godot-tools since it provides linting for that kind of file.

:bust_in_silhouette: Reply From: yrtv

You can also write project.godot and .import files for resources


 Engine configuration file.
; It's best edited using the editor UI and not directly,
; since the parameters that go here are not all obvious.
; Format:
;   [section] ; section goes between []
;   param=value ; assign values to parameters


_global_script_classes=[  ]








"vram_texture": false


dest_files=[ "res://.import/icon.png-487276ed1e3a0c39cad0279d744ee560.stex" ]



And editor is CLI tool.

~/Godot_v3.2.3-stable_x11.64 -h
Godot Engine v3.2.3.stable.official -
Free and open source software under the terms of the MIT license.
(c) 2007-2020 Juan Linietsky, Ariel Manzur.
(c) 2014-2020 Godot Engine contributors.

Usage: /home/yurii/Godot_v3.2.3-stable_x11.64 [options] [path to scene or 'project.godot' file]

General options:
  -h, --help                       Display this help message.
  --version                        Display the version string.
  -v, --verbose                    Use verbose stdout mode.
  --quiet                          Quiet mode, silences stdout messages. Errors are still displayed.

Run options:
  -e, --editor                     Start the editor instead of running the scene.
  -p, --project-manager            Start the project manager, even if a project is auto-detected.
  -q, --quit                       Quit after the first iteration.
  -l, --language <locale>          Use a specific locale (<locale> being a two-letter code).
  --path <directory>               Path to a project (<directory> must contain a 'project.godot' file).
  -u, --upwards                    Scan folders upwards for project.godot file.
  --main-pack <file>               Path to a pack (.pck) file to load.
  --render-thread <mode>           Render thread mode ('unsafe', 'safe', 'separate').
  --remote-fs <address>            Remote filesystem (<host/IP>[:<port>] address).
  --remote-fs-password <password>  Password for remote filesystem.
  --audio-driver <driver>          Audio driver ('PulseAudio', 'ALSA', 'Dummy').
  --video-driver <driver>          Video driver ('GLES3', 'GLES2').

Display options:
  -f, --fullscreen                 Request fullscreen mode.
  -m, --maximized                  Request a maximized window.
  -w, --windowed                   Request windowed mode.
  -t, --always-on-top              Request an always-on-top window.
  --resolution <W>x<H>             Request window resolution.
  --position <X>,<Y>               Request window position.
  --low-dpi                        Force low-DPI mode (macOS and Windows only).
  --no-window                      Disable window creation (Windows only). Useful together with --script.
  --enable-vsync-via-compositor    When vsync is enabled, vsync via the OS' window compositor (Windows only).
  --disable-vsync-via-compositor   Disable vsync via the OS' window compositor (Windows only).
  --tablet-driver                  Tablet input driver () (Windows only).

Debug options:
  -d, --debug                      Debug (local stdout debugger).
  -b, --breakpoints                Breakpoint list as source::line comma-separated pairs, no spaces (use %20 instead).
  --profiling                      Enable profiling in the script debugger.
  --remote-debug <address>         Remote debug (<host/IP>:<port> address).
  --debug-collisions               Show collision shapes when running the scene.
  --debug-navigation               Show navigation polygons when running the scene.
  --frame-delay <ms>               Simulate high CPU load (delay each frame by <ms> milliseconds).
  --time-scale <scale>             Force time scale (higher values are faster, 1.0 is normal speed).
  --disable-render-loop            Disable render loop so rendering only occurs when called explicitly from script.
  --disable-crash-handler          Disable crash handler when supported by the platform code.
  --fixed-fps <fps>                Force a fixed number of frames per second. This setting disables real-time synchronization.
  --print-fps                      Print the frames per second to the stdout.

Standalone tools:
  -s, --script <script>            Run a script.
  --check-only                     Only parse for errors and quit (use with --script).
  --export <preset> <path>         Export the project using the given preset and matching release template. The preset name should match one defined in export_presets.cfg.
                                   <path> should be absolute or relative to the project directory, and include the filename for the binary (e.g. 'builds/game.exe'). The target directory should exist.
  --export-debug <preset> <path>   Same as --export, but using the debug template.
  --export-pack <preset> <path>    Same as --export, but only export the game pack for the given preset. The <path> extension determines whether it will be in PCK or ZIP format.
  --doctool <path>                 Dump the engine API reference to the given <path> in XML format, merging if existing files are found.
  --no-docbase                     Disallow dumping the base types (used with --doctool).
  --build-solutions                Build the scripting solutions (e.g. for C# projects). Implies --editor and requires a valid project to edit.
  --gdnative-generate-json-api     Generate JSON dump of the Godot API for GDNative bindings.
  --test <test>                    Run a unit test ('string', 'math', 'basis', 'physics', 'physics_2d', 'render', 'oa_hash_map', 'gui', 'shaderlang', 'gd_tokenizer', 'gd_parser', 'gd_compiler', 'gd_bytecode', 'ordered_hash_map', 'astar').

Is this count as everything ONLY through programming?

1 Like

You can go through command line tutorial in Documentation of Godot
Section: Command line tutorial
Here: Command line tutorial — Godot Engine (stable) documentation in English