## 2018-06-14 Entity Component System #ECS #Insight 

Entity Component System (ECS) is a pattern / solution for modeling systems where the (meta-)behavior can change more often than object identity. Object in OOP have behavior either through classes, or object specific behavior. But changing how the object fundamentally behaves would require changing its class or rearranging super class structures, which are operation that happen while developing a lot but not so often in their actual object lifetime. Since the entity represents just "identity" and does not keep state or behavior. The components associated with that entity can change the behavior and state so dynamically that (game) objects in ECS can get flying, driving, walking, burning, speaking (components) effortlessly at run-time without having to recompile classes or methods. This is especially useful in statically compiled C++ environments, where such dynamic object adaptations are not possible. The reason why in games the behavior is more volatile than identity is that changing game rules (depending on context etc) for a single entity are an integral part of games themselves. In object oriented programming (OOP), separation of identity from state and behavior can be achieved using the #StrategyPattern (or entity component pattern), but ECS further pulls the behavior out of the strategies into systems to solve dependency problems between strategies. 


## ShearingLayers: Separate things that change at different rates

This separation of identity from state and behavior follow the #ShearingLayers (of #BigBallOfMud) pattern. Where things are separated in layers that change with the same velocity. Since identity does not change as often as state and behavior, it is separated. 

The #ShearingLayers pattern seems to be similarly responsibly for pulling apart state (and identity) from behavior in classic relational database-based systems, where the application behavior changes more often than the state. 

### Layers:

- Game / Simulation Engine (in C++), changes slowly
- Game / Simulation rules defined in system (possibly in a dynamic language), changes more often
- Entities (identities live longer than their components)
- Connection between entities and components
- State in components (super frequent changes)

## Performance: Keep things together that are needed at the same time

Even though it is an implementation detail, or practical observation: ECS can have certain performance advantages when systems (running code) needs to look and modify state. In OOP systems the state is scattered in memory in a heap of objects. In ECS the components are separated from entities and can be layouted in memory so that the data that has to be touched is co-located (resulting in better performance through better usage of hardware cache architectures). 

This seems to be a similar trade-off that columnar databases make when organize data not in rows, which is similar to the object layout in OOP, but in columns, which separates identity from multiple slices of state. This alternative organization of data results in better performance when touching only one slice of state in a multitude of identities (entities). The performance of columnar data is worse than row based approaches when all state of few entities is touched. This happens in #CRUD, when objects are modified, created or deleted. The character of analytical algorithms in that work on columns in databases are similar to systems that work on state in components in games. Both work a multitude of entities but only touch few slices of their state.  


On an lower level, this data organization can be found in Single Input Multiple Data (#SIMD) (like #Kedama), NumPy et al., and GPU stuff. These technologies are usually catered towards performance, but are typically not easy to use. In contrast, the data organization can be useful  on an End-user development (EUD) level:  game designers modify components (in a running system / #LiveProgramming) to adapt and introduce new games rules, while the entities are staying the same in the running system. 

## LiveProgramming

ECS makes devloping at runtime possible in statically compiled environments such as C++. The underlying fast game engine, changes in a different rate than the the rules of the game, ... #Continue


## References

- see [@Stein2017ECS]

<lively-bibtex-entry>
@misc{Stein2017ECS,
    title = {The Entity-Component-System - An awesome game-design pattern in C++ (Part 1)},
    author = {Tobias Stein},
    year = {2017},
    notes = {11/22/17},
    url = {https://www.gamasutra.com/blogs/TobiasStein/20171122/310172/The_EntityComponentSystem__An_awesome_gamedesign_pattern_in_C_Part_1.php}
}
</lively-bibtex-entry>

----


# # Meta: Scripts, scripts, scripts


```javascript {id="Foo"}
var hello="world"
```


```javascript {id="Bar" data-dependencies="Foo"}
world + "!"
```

- make all scripts optionally executable (add ui to code elements)
- resolve and execute dependencies before
- related: JavaScript modules... but we are finer grained and need side-effects for interactivity
- replace code elements with editors (code mirror) so source code can be changed in demo
- the changes should be preservable (e.g. when pressing save back to markdown)
  - this should should not happen by accident 
  - implementation idea: put the code mirror in the shadow root, so it is not seen by persistence code, this could become a general approach to enhance UI while keeping a persistable document

<script>
//... do the work1

</script>