Help with Model View Presenter pattern

[broken elm]

I’m having trouble with my MVP setup and could use some help

UnitModel (data)
UnitView : IUnit (iMonoBehaviour).
UnitPresenter – connects the model and view.

I have some code that uses a raycast to find a Unit through IUnit. My goal is to keep a clean separation between the game’s logic and the visuals, so that the game state can exist independently of scene objects and be rebuilt from models/
The issue is that IUnit doesn’t know anything about the model. This makes it hard to decide how to authorize or apply changes to the model when interacting with the view.
I want to stick to MVP, unless told otherwise. One idea I had was:

During initialization, bind an ID to the model and view through the presenter.
Store that ID in IUnit.
When interacting with the view, look up the corresponding model in a dictionary.

Does that make sense, or is there a better way to keep the model-view separation without breaking MVP?

[sour elbow]

MVP (or MVVM since you're mentioning databinding) doesn't lend itself naturally to most parts of gamedev. its assumptions revolve around passive views, presenting only model state, event isolation, low event rate, single ownership of state, immediate updates, cheap indirection. none of these are reliably available in games.

your best bet (initially, until boundaries are well understood) is to focus on the 'presenter' as an observer of a system that pushes input to it and displays state in useful ways to a player. don't get overly specific how that happens, each system has different needs. you will have to deal with a lot of state that is not in the model (if model = persistent state) and often you will have to deal with partial updates of views and managing that, just binding a view to a variable often can't do that and you binding mechanism grows quickly into a mini-presenter. you easily start to build systems within systems just to maintain the pattern.

when you only consider UI, MVP applies relatively cleanly, but views in games can take all sorts of weird shapes that don't come up in 'static 2D UI' focused situations.

that said, having trouble with setting up MVP/MVVM is the nature of the game.

a pattern that generally works is to have all your gameplay logic implemented in systems that expose request and notification APIs but decide model update internally based on declarative configuration and plug-in handlers. A presenter observers and forwards user input to these requests but doesn't decide which are possible or valid, it asks the system. A view is controlled directly by the presenter via procedural code for anything that needs to be performant. Assume all events need to be rate limited eventually. You can keep model state internal to systems and only expose it to a pull-based persistence layer on demand and anonymously (without exposing the internal schema), you don't need a relational datastructure for the model that lives outside the systems if your systems provide the required query APIs. If you have public, free-for-all access to the model, it becomes difficult to reason about what systems owns a particular state and what transitions are allowed and when. Your model then turns into a messaging system that will be very difficult to keep under control once the project grows beyond what you can keep in your head.

[broken elm]

Thank you! I will try to digest what you told me