Godot

It's not something that's immediately obvious, but Godot's scene system is pretty much entirely optional. You can bypass it and interact with the various servers that handle rendering, navigation, physics, and other core functionality directly. They actually recommend it for performance optimisation. You could also implement your simulation using that same server architecture if you wanted to: https://docs.godotengine.org/en/stable/contributing/development/core_and_modules/custom_godot_servers.html

I think it is entirely possible in Godot. You don't have to extend any Godot specific class when you create new objects and scripts, just define a new class, and put your game logic there. Then, you can use an instance of that class in your rendering specific logic.

If you want, you can take a look at my pet project, a match three "game", I made it to learn Godot. I had the same concerns as you, so I tried to separate game logic and animation. What I did was to create separate queue for the animations based on game logic steps.

https://github.com/zsoki/godot-4-match-three/blob/master/Events/Game/game_event.gd

The code is not terribly optimized or readable, so sorry. But might give you some ideas.

Pretty much every engine out there is built on strong opinions about “how game code should be structured” so while you almost always can bring your own opinions like this, you are likely to make life difficult for yourself…

It very much depends on what kind of game you’re making but I actually don’t think Godot is actually all that unsuitable for the sort of separation of concerns you’re going for, though you’re unlikely to find many tutorials geared towards that style of coding.

I say this as someone with similar instincts about how to structure my code, who spend 2-3 years working against the grain in UE4 to maintain a clear model/view separation in a 2D simultaneous-turn-based strategy game & am currently going down a similar route with Godot.

You can use plain Node & Resource derived classes for a lot of your model-side stuff & only use “things that automatically draw themselves” nodes as a layer on top of that if needs be… but yeah, it very much depends on what kind of game you’re making. For most traditional real-time games (as opposed to turn-based ones etc), especially anything 3D or where you want to use in-built physics stuff, I’d lean towards trying to work with the engine as much as possible, rather than being too fanatical about following a particular design pattern that isn’t fully encouraged by the engine… at least for your first game or two!

One thing you could do is to use resources and one or two global scripts to run simulations like I do in my game project (Very heavy calculus and material simulations). There is going to be some interconnectedness with nodes, but that is a strength, not a weakness in my opinion!

It seems you want something that can have a good separation of concerns. Maybe something like Bevy? Its using ECS, so you can customize your logic and separation between it however you want.

Since replying to my comment from kbin doesn't seem to work, I've signed up here to post a little update.

If your project has Use Physical Light Units enabled, lighting through GDScript and the RenderingServer isn't possible to do cleanly on stable builds. The enum used to set light intensity isn't bound, so you have use its integer value.

RenderingServer.light_set_param(light_RID, RenderingServer.LIGHT_PARAM_INTENSITY, 1500)

Becomes

RenderingServer.light_set_param(light_RID, 20, 1500)

It sounds like the thing you want is Functional Reactive Programming (FRP), where you have a state value that represents the current state, an update function which integrates an input and the current state, and a display function which just presents the state for the user. This is not Godot, but you may be able to search for an FRP game engine and find something more than a half-built weekend project from 8 years ago 😅

Godot is not a function-oriented environment at all, though the version of gdscript in Godot 4 does have first-class functions finally. Their entire model is very object-oriented, though. So your player will 100% be a subclass of a Godot class.

That having been said, more than many OOP projects Godot encourages object composition over multiclassing and mega objects. The "right" way to build a character in Godot is to have a health component that just holds health, takes damage, and heals. Then another which does damage to thing, etc. Then the player is a subclass of the physics body, and does have some glue code, but all of the concerns just get added to it and it becomes the sum of its parts. That allows the health component to be added to enemies and trees as well without rewriting it, etc.

This solution is "ugly" from a programming theory perspective, but it works, especially for a single-player game. You have a global Singleton class that has all the game state information. In the GUI part, you have it check the global Singleton when deciding that to draw.

If you do it this way, you can put the game logic in another thread, or even use a C/C++ GDExtension if you want really high performance.

For example, you keep the player's HP in a global singleton. Then in the GUI where you show the player's HP, you have it check the value in the global singleton.