# How can I manage complicated visual state over a simple model in puzzle games?

I've been encountering this design challenge making a few toys with Javascript (CreateJS, EaselJS)

The scenario is that you've got some sort of puzzle game with a simple game model. For a simple case, imagine a visual graph builder, where the model is a simple vanilla CS graph structure, maybe stored as nodes and edges.

However, you want to build a fancy interface for editing this graph structure, which introduces a lot more information. Colors, sizes, bezier curve control points for the edges, having a node "blink" during forming a connection, having the edited edge follow the mouse, etc.

How can I decouple the visual information from the raw model information? There's also a lot of state concerns. Some strategies I've employed:

Have an overall application state: ex. {NO_ACTION, CONNECTING}, where CONNECTING could store information about the selected node. Upon changing into the CONNECTING state after an event, I tell the node on which the connection was initiated to change into INITIATE_CONNECTION mode which, upon other things, causes the port to blink. Most of the ways I come up with to manage this feel hackish, dirty, and not abstracted.

I'm interested in resources or opinions about this type of scenario, and how I can better architect the application.

How can I decouple the visual information from the raw model information?

More easily than you are probably thinking:

class ModelObject {
...
}

class VisualObject {
ModelObject ModelReference;

...
}


As you note, the visual representation almost always only introduces new information, so it can be defined in terms of a reference to an existing model object (for any type of model object, be it a graph node, edge, puzzle piece, et cetera), plus it's extra properties. You then build your UI and interaction code around the visual API, which allows you to expose or derive all the interesting blink, color, node connection position, et cetera properties you want.

You will also need to keep a simple state machine in play in most cases, since in most cases the way you'd visually construct a new model instance requires more information than an UI can accept from the player all at once. For example, to return to your graph example, the player will probably first click somewhere to create a new node, and then click around to set some node properties and connect it to the rest of the graph. The model API, on the other hand, may not allow for that kind of multi-phase construction (for example, you may not be able to directly construct graph nodes, but rather need to ask the graph itself for a new node and supply all the relevant information, which you may not have from the user yet).

In that scenario, a simple state machine like you described works fine, and you may also need to have some idea of a "proxy" object that is under construction but not yet backed by an actual final model object.

In addition to the MVC pattern noted in the comments, there's also the MVVM pattern which you may want to look into. Both are useful, although with all patterns I recommend you avoid an overly dogmatic approach, because that's overkill (especially for games). By this I mean, don't decide to adopt MVC and then go around refactoring everything so you now have a "Sprite" and a "SpriteView" and a "SpriteController" and so on. The important parts of these patterns are the conceptual ways in which they are factoring responsibility and facilitating communication between the parties responsible for things.

I think you should check on Entity Framework. Particularly Ash framework and its Javascript port. Having a lot of information is ideal candicate to split these into components/entities. Then you can have systems that work over these entities. It's hard to give exact example when you haven't given any by yourself.

And for state management, you can combine this with FSM like MachinaJS.