How does a scene do things without a script?

Question

I was looking through some of the best practices on the documentation, specifically about when to use scenes vs when to use scripts. I'm pretty confused here, especially when it says to use scenes specifically for implementing systems specific to a game. Scenes are just node trees, right? And nodes can only implement custom behavior through scripting, correct? It seems like you'd be using roughly the same scripts either way, just with a different level of abstraction.

Beyond that, there's writing in the docs about how scenes are declarative and scripts are imperative, but I can't seem to find anywhere I'd code in either style beyond inside of a script. That's the only place you can add your own code, is it not?

If anybody has an example of doing the same thing with and without the usage of scripts, I'd appreciate it.

Haletky

Answer 1

scripts essentially modify your classes (nodes) to do what you want. So yes, scripts are how you do what you want to do. Your objects/resources can be edited in the Inspector visually without scripts, but not much else.

Scenes are less memory intensive because they are built inside of the engine. However, scripts are more flexible as they extend what your nodes can do.

Now, this is a VERY simple example, but take....
For instance, let's say you want to make a graphic spin. You could use an AnimationPlayer node to run an animation, then use a simple script to play it at ready(). However, you could also use code and do this every frame.

func _process(delta):
        $MyGraphic.rotate(0.001)

This would have the same effect. Now if you have a very LARGE scene though, the more code you execute, the slower the performance. It's a balancing act. The best practice is to save large collections of nodes that depend on each other as scenes and then use code for everything the editor can't already do. Make sense?

Shawntashawwal

Answer 2

That makes sense, but that still leaves me wondering why the documentation mentions scenes as the preferred way to implement systems that are specific to individual games. It seems like that's the opposite of what you'd do, since the stuff that's in the editor, as far as I can tell, is mostly static stuff. The example you give is playing an animation, but that seems like a pretty general system that would be reused across games. A hunger system, for example, is more specific per-game and would have no obvious nodes for implementing it that I know of.

Haletky

Answer 3

yeah it's a small example but the point I am making is the more lifting your code does, the more it hits your performance. You use scenes and scripts together.

A "hunger" system would likely involve a bool that you track. Something like this:

var _hunger = 0 ## track in real time
const _maxHunger = 100 ## limit to avoid overload/errors

Then you would use a node like ProgressBar to track that variable and display that info in real time in a way the player understands. You COULD build your own progress bar using graphics but this would be a bit more labor on the system. Small things like this add up over time. Performance/lag is largely death by a thousand cuts. Too much script can also cause software bloat or be just plain pain-in-the-arse to work on.

The important thing: graphics don't always have to reflect what is in code. A "game" is essentially a lot of code with visuals displaying and relaying information to you. How you put that together - in Godot especially - is up to your creativity, critical thinking and choices as a game dev. The nodes - and the Godot IDE in general - are meant to save you time from building so much small stuff and use scripts to control the bigger elements.

Think of scenes like a "container" for objects. It allows you to call them back (think a level with a tilemap, GUI, player and enemies) rather than have to rebuild it in code, which can be performance-hogging. Scripts are where the magic happens.

Shawntashawwal

Answer 4

Not sure why they presented scenes vs scripts as some sort of dichotomy. There's no real "versus" there.
In general you should use scenes (with scripts inside them) as much as possible. No need to overthink this. Scenes can take care for most of the building blocks in a typical game.

As for declarativity of scenes, a tscn file that contains a scene definition can be considered declarative code. You can type a tscn file into a text editor and let the engine open/run it.

Defection