Decouple game state from game UI (call it MVC or not)

Question

For people coming from SW engineering background thinking in terms of MVC is natural.

For many types of games there are clear benefits to separating [logical] game state from what is displayed on-screen (e.g. board games, various strategy games etc.)

I want to decouple state of my game from displayed objects/nodes. In fact, structure of my game state does not have to mirror the structure of what is on-screen. I don't want to distribute my game state among various (displayable) nodes. It should sit in one place where it can be easily manipulated and tweaked. What remains then is to communicate between the on-screen UI and core game logic that manipulates the state. This way I can evolve UI separately from game logic. Call it MVC or not, for SOME games it's just better.

Godot documentation largely ignores this problem and I did not find any good tutorials on how to do this.

Has anyone done this in practice and can share insights or found any good resources?

BONUS question is - given that, how to elegantly implement a save/restore functionality. Looks like the currently supported "Persist objects" scheme is rather simple and node-oriented - saving/loading complex nested/linked data structures might have to be built from scratch.

Answer 1

You are probably looking for signal (Godot's implementation of observer pattern). This way game object can emit signals that can be listened by UI and they will not be coupled (if UI is removed, game still be working without any errors and if game is removed UI will work too).
And there is no answer for bonus question, because it heavily depend on type of the game you making and your coding preferences.

Comments

@AlexTheRegent

Signals are a low level decoupling mechanism so they would be likely a small part of the solution. I am looking for more architectural/high level insights. For example this is an article describing MVC implementation in Unity. Most of this particular solution is straightforward to apply in Godot:

https://www.toptal.com/unity-unity3d/unity-with-mvc-how-to-level-up-your-game-development

Answer 2

for one of my games, I'm using C# models that have some of the game logic implemented outside the godot realm. This has the additional benefit that I can write standalone unit tests.

the connection to godot is a bit tricky at times, i.e. the more and more it needs interaction with the UI, the softer the distinction gets.

But when you only want to use godot (GDScript): one way could be to manage the objects and their states outside the node tree, e.g. in own arrays and dicts.

Regarding the BONUS question: I found it helpful to start very early to separate runtime / computed properties from saveable state properties. ideally keep them in an own class or dict.

HTH

Answer 3

I'm working on something like this for godot. It allows you to add an extra Binds node inside each control, which has bindings to a 'model' which lives at the scene root.

It auto-connects signals when possible to provide two-way-binding between the data model and the controls in your scene, decoupling the layout structure from the workflow/data.

https://github.com/jamie-pate/godot-control-data-binds#readme