Design pattern for level editor modes?

Question

In a level editor that supports multiple editing modes, written in an oop language, how would you go about switching from mode to mode, considering that data itself remains the same?

I am using a MVC pattern like so.

1. A data model for the level's structure.
2. One model for the editor's state depending on the current editing mode and it contains data about the user's editing activities that was not applied or does not affect the level model (i.e what entities or item are currently selected).
3. A view for each mode (they all render similarly but differently cause they put emphasis on different items in the level).
4. Controllers accepting input and manipulating the state. These also differ from one mode to another.

The Controller accepts input from the user. It calls the corresponding methods on the State model which in turn modifies the LevelData. The controller refreshes the View after changes are made to the LevelData and State so these changes are properly reflected to the user.

Currently, to switch, I have all controllers inherit from a base controller that contains the mode switching capability. I have a class called AppContainer (each mode is like an app) that is being informed that a switch needs to be made. This class deactivates the controller and activates a new controller instead. The new controller refreshes the view and clears the state upon reinitialization.

I am wondering if there is a simple way to accomplish the same thing that I haven't though of.

I basically need to switch the Controller, the State and the View. HaxeFlixel does this pretty elegantly. Does anyone know how that is accomplished in high level abstraction?

Answer 1

You can also use the MVVM (Model-View-ViewModel) pattern instead of MVC. You can read the article on wikipedia. I also like this article on codeproject.

Whereas it is mostly used together with WPF, Silverlight, etc. in the .NET world it is also used by AngularJS for example.

So MVVM could be an alternative for you. It is hard to exaplain software architecture patterns accurately with only few words so I leave it up to you to read the articles.

You can abstract your scenario by having different views with the same view-model behind. Or (the way I would do it) a model and then a view-model for every mode. Every view-model type gets coupled to a view and then we switch from one view-model to another with the same model behind to render different aspects of the level (called view-model-driven MVVM).