+1 vote

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.

Godot version 3.x
in Engine by (13 points)

2 Answers

0 votes

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.

by (1,314 points)


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:


0 votes

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.


by (37 points)
Welcome to Godot Engine Q&A, where you can ask questions and receive answers from other members of the community.

Please make sure to read How to use this Q&A? before posting your first questions.
Social login is currently unavailable. If you've previously logged in with a Facebook or GitHub account, use the I forgot my password link in the login box to set a password for your account. If you still can't access your account, send an email to webmaster@godotengine.org with your username.