I’m trying to organize my project tree better, including various GDScripts.
Up until now I was saving GDScript files either in the same directory as the scene they work on, or in a dedicated folder, or in thematic folders (Enemy, Collisions…) or in some other way, but no matter what, there are always so many of them that it ends up messy or is hard to maintain etc.
It’s also easy to end up with orphaned scripts that no one really knows where did they come from or what is their purpose. For example, when making quick tests (something I do all the time), if I forget to delete the accompanying GD script file, It’s easy to forget what did it belong to and it takes effort to decide whether I should remove it.
Also, in my case a script is very rarely directly used by multiple scenes so I might as well “tie them” to a particular scene.
Reading about GDScripts makes me think they’re much more practical in vast majority of cases than the detached scripts.
But for some reason I never see them mentioned, at least where I’m looking, for example I can’t remember ever seeing them mentioned in a tutorial (and I watched tons of them). I found some basic info about them online but it’s pretty old. I assume they have some downsides (in 2019 it was not possible to register a class within a built-in script according to a forum post here but ok, not a big problem link and there are some downsides mentioned elsewhere on Reddit) but so far I haven’t really seen any arguments against using them as the default for scripting in my case.
So, is there a reason no one is ever talking about built-in scripts?
And if there are people here that do use them: any gotchas I should be aware of in 2024 when using built-in scripts?
I’m not sure if built-in scripts are still a thing in Godot 4.x, but if they are they’re very well hidden.
That said, I imagine one advantage they’d offer is encapsulating everything in a single file, which would make the file-system a little tidier.
For all my scenes with scripts, the script files sit next to the scene file (e.g. ghost.gd below). If a script is shared by more than one scene I put them in a parent folder (e.g. enemy.gd and moving_actor.gd). And if a script is shared in lots of places, I put it in my /scripts folder. Seems to keep things tidy enough for me, so I don’t really miss built-in scripts.
Yes, built in scripts are still here as always. I wouldn’t call them hidden, it’s right there every time a new script is made:
That’s what attracted me to built in scripts, I don’t understand why isn’t this the default anyway since FWIK the majority of Godot users don’t use external editors anyway and the scripts do not get reused that often (which are two main advantages of detached scripts over built in scripts).
For all my scenes with scripts, the script files sit next to the scene file (e.g. ghost.gd below). If a script is shared by more than one scene I put them in a parent folder (e.g. enemy.gd and moving_actor.gd). And if a script is shared in lots of places, I put it in my /scripts folder. Seems to keep things tidy enough for me, so I don’t really miss built-in scripts.
That’s what I was doing too, but with time it all gets hard to find and maintain.
I don’t believe I have that option because I use C# (although I’m going to have to go check now ) so I’d say that alone makes seperate files more standard.
But some other reasons I’d point out that make it a preferance are:
Seperation of concerns
Better for source control
Easily switchable (as in i want to totally change the script, but don’t want to delete the old one)
More reusable like you say. Remember, that’s not just within a project.
@tpmassey fair enough, yes if you prefer to use an external editor then I am not sure whether built in scripts are supported at all.
I’m not sure what makes standalone scripts more practical for source control, unless you’re working in a big team. Anyway I’ll take your word for it.
In theory, yes it’s practical to have an option of switching scripts without deleting the old one, but in my last few projects I just started attaching scripts to nodes which are then plugged in and out anyway. So I never have to switch the actual scripts anymore.
In my experience:
After using them for some time, I came to the conclusion that in 95% of cases built in scripts are more practical than separate scripts for small everyday kind of tasks a game consists of… or at least they would be if they weren’t so quirky.
Annoyances:
built in scripts don’t reopen when a project is launched!
when searching for a string, built in scripts are not checked at all (because they are resources)…
adding a new built in script to a Scene actually adds it to the parent scene! This one is sooo annoying part 1. If there’s an error in a built in script, Godot might report it as " res://bases/stage level.tscn::GDScript_rmkfy:10 - Invalid access to property or key ‘Pippy’ on a base object of type ‘Node (a_signal_trigger.gd)’." So if you have a few built in scripts in the same scene, you can’t know which “_rmkfy:10” script is the error in (I think it works like that even if you explicitly name the built in script, will check later).
adding a new built in script to a Scene actually adds it to the parent scene! This one is sooo annoying part 2. Try this: open a scene with parent NodeP1 and two children NodeC1 and NodeC2. Attach a built in script to NodeC1 and name it something generic like “manager” (let’s say you just want to test something out real quick). Now add a built in script to Node C2 and name it “manager” too. You will get an easy to miss warning about cyclic referencing and the second script will be generated as “unnamed”!
Deleting part 1: add a subscene “S” to a scene “P”. Add an inbuilt script to “S” and name it “my_script”. Type something in it. Delete “S”. Add a new script to “P” named “my_script”. In the code editor, you will end up with two scripts named “my_script”, out of which one kind of doesn’t exist so you might end up typing in an “orphan” script not attached to anything.
Deleting part 2: add a built in script to a scene and open the script in the code editor. Now delete the scene that is meant to be the owner of the script. The scene will be deleted, and the orphaned script will remain in the code editor. Again, you might end up typing into a script not connected to anything.
Some of these are probably unavoidable (and “logical” technically… or maybe I’m doing something wrong) but can be very annoying to deal with.
There is a related thread about built in scripts on Github by @kobewi :
Well it’s not that it’s an external editor, C# needs to be compiled outside of godot. But that is another reason, i’d imagine a lot of people use another ide even for gdscript.
It’s better for source control because your only dealing with code changes in your code file. So if you want to roll back a change your not forced to roll back both.
You can also look at the history of the code file and see just the code changes you’ve made. If you use built in you’d have all the scene changes mixed in too. So if you’re trying to find where an issue was introduced say, comparing changes with built in would be harder.
Then there’s conflict resolution. Which isn’t as much of an issue for a single dev for sure, but can still happen. If your code and scene are separate, conflicts shouldn’t happen as often and should be easier to deal with.
I’d say that using a separate code file is the preferred, correct, and standard way to do it. But if it suits the way you work and your not having any problems with it, keep going and don’t worry about it too much.
Well, I’m using built-in scripts almost exclusively and I don’t find them problematic for source control, even in a team. Since a script belongs exclusively to one scene, if a problem is introduced it will be related to the scene anyway. Built-in scripts are pretty readable inside tscn, the only issue is that quotes are escaped, so highlighting can get borked.
My biggest issue with built-in scripts was when I had a big scene and it had multiple scripts hidden inside nodes. Navigating it was hell, but Godot 4 has a built-in resource list (you can find it inside ⫶ menu of scene tree), so that problem is gone.
Blockquote
built in scripts don’t reopen when a project is launched!
) so I’d say that alone makes seperate files more standard.