Separate view from model (game (world) state from UI)

[evktalo]

Separate current game state from UI state.

Model game state without references to its UI representation.

We need game definition for it's model and then the view implementation of the model. View definition refers to model and describes e.g. images, resolution, coordinates, ...

Game model definition has the initial state of the game and may be actually the same ...

Perhaps about as simple as:

erDiagram
  CHARACTER ||--|| ROOM : resides
  ROOM ||--o{ OBJECT : contains
  CHARACTER ||--o{ ITEM : holds

Loading

View refers to modal and may have data such as:

erDiagram
  ROOM ||--|{ IMAGE : has
  OBJECT {
    int x
    int y
  }
  OBJECT ||--|{ IMAGE : has
  ITEM ||--|{ IMAGE : has
  CHARACTER ||--|{ ANIMATION : has
  ANIMATION }|--|{ ANIMATION_FRAME : consists
  ANIMATION_FRAME ||--|{ IMAGE : has
  IMAGE {
    string filename
  }
  ANIMATION_FRAME {
    int duration
  }

Loading

Some thoughts:

• ANIMATION sounds like it could be part of the model (EMOTION or something)
  • Interactions should probably be view-agnostic (maybe?) and thus every command in an interaction should only alter model state, not view directly
  • The interaction handling could trigger an event for the UI, and how UI wants to handle that event is left up to it (see Consider interaction commands for "locking" and "opening" interface #98 for a consideration about a UI-centric interaction command)
• Everything that has an IMAGE could of course be an animation
• Should TEXT or SPEECH or also be part of this model? Added to message log and view decides how to render it, e.g. temporarily shown in a speech bubble but also added to a separately viewable "static" message log?

Indeed perhaps the game definition describes the initial game state, and the interactions then add/remove objects from rooms and items from inventory. Does this create a challenge for building the view, if e.g. the view wants to treat addition / removal of objects from UI by hiding / displaying them (but having all the items initially present in e.g. Konva stage / memory?)

More to consider:

• Interactions are part of the game data (but not the world state?)
• Interactions could be immutable, or we could have a command to remove / add interactions as well!
• Interaction log
• Message log

Game definition could use "higher level" definitions (such as doors, containers, menus, ...) and be "compiled" to initial game world data and interactions. Compiling the view probably needs some thinking.

There could be multiple different game definition schemas, as long as they compile eventually to the 'game world state schema' and interaction schema. There could be multiple layers, and there could be multiple different game engines that can interpret different layers of sophistication / complexity.

View considerations: change in the game world state should of course be reflected in view and be rendered, but might there be performance considerations if naively rendering the full state on every change? Maybe diff between states and render only what changed? (That's up to the view of course)