I’m very interested in how this works in Unity. Looking forward to code samples.
This is a good approach for UI and some certain types of game logic. In particular, the types of game logic that is easily and painlessly separable from visual Unity components: request-response multiplayer games, turn-based games, and other stuff like this.
For games that have game logic that is tightly linked to visual stuff, though, such attempts at decoupling end up in disaster. Simplest example is: if you have hitboxes that move every visual frame together with animations created by your artists, this will only bring pain. And most importantly, it will bring pain not only to developers, but to game designers, level designers and artists, the very people who you want to make most productive with your game code.
Separation of different layers in software is a great tool when these layers really have different meanings that are not connected to one another. When you’re writing a UI to display a counter, number in the counter doesn’t have anything in common with the rendered shapes. But when you’re writing an action game, the logic of shooting at an animated model has everything in common with the animation you use to update the rendered mesh. Don’t try to separate the two.
We recently had someone give a talk about Unity and NATS.io which may be interesting.