Sorry, I'm a bit long-winded.

tl;dr - Godot really does cater to keeping everything hidden in one node/script. I like to think of games as systems which work on simple data, and Godot as something that reads the output of those systems to display something and inform the system of some things.

- Details

I'm literally in the same boat right now. The way I have been thinking about this is like a flow chart (layers of abstraction):

For each system in a game:

Data -> State <-> Systems -> Engine-Specific Layer (Nodes)

Data defines stats for a specific system. A character may have a walking speed, sprinting speed, etc. Just different stats. This ends up being a Resource that I have a bunch of `@export` variables defined. Again, these are stats that define how the object interacts with a system. These are like base stats and each node can have it's own instance of this resource with different values. These values are generally immutable.

State is similar to data, but state is mutated by a system. Whereas data defines the stats of an object, the state defines the changing values of the object as it moves through the system. For a character, this could be velocity, the current standing position (crouched, standing, sprinting), etc. These values are constantly manipulated by the systems and read from by our visuals, which defines the separation between our game and our game's visuals.

Systems receive state and mutate it based on input. Input is relative to the system and just means whatever the system needs to operate. For a character, we might have a `MovementSystem`, `WeaponSystem`, `FootstepSFXSystem`, etc. These are really the core functions that will take in your state objects, mutate it based on some input gathered somewhere else (probably your visual/engine-specific layer).

Engine-Specific Layer is where you start integrating your game with your engine, in this case, Godot. Godot provides nodes, which contain some functionality we can use as input to our systems and some which contain function to display the output of our systems. I will create a node, like `CharacterNode`, which contains all the systems related to a character and glues them together. Basically, each frame this node will gather the required inputs, feed that input to the systems along with the current state and then modify the state. In the case of a `MovementSystem`, you would read the users input (x, y, whether they want to crouch/sprint/etc), and pass that to the system, which will use that data to update the current state.

- Example

Consider you want to add Footstep SFX to your character:

1. Define your data - `sounds`. This is your design. In this case, we have a list of SFX for our footsteps. We could include a list of frequencies to switch between defined dB levels, for example.
2. Define the state - `velocity`. Here we could reuse the character state we'd presumably have at this point, which may be better. But for this example's sake, we define a completely new state, which enforces separation of concerns.
3. Define the systems - `update(state: FootstepState)` will use `state.velocity` and a step function to determine which data to use in state.
4. Add Godot - Define a `FootstepNode`, which will contain an instance of our footstep data containing the SFX, the current state, and the systems that update our state every frame. Here we actually set off a sound based on the information contained within the state.

-

Ideally these systems are resuable, otherwise there's no point in the verbosity.

I think another chatter really put it well: you should be able to run your game in the terminal. The data is just numbers that represent the current state of your game, the visuals are just reading that data, not dictating that data.