ECS Pattern

[pcarvsilva]

Scenic elements should follow the ECS Pattern.

Entity-Component–System (ECS) is an architectural pattern. This pattern is widely used in game application development. ECS follows the composition over the inheritance principle, which offers better flexibility and helps you to identify entities where all objects in a scene are considered an entity.

An entity is a distinct object representing an actor in a simulated space. It has not actual data or behavior. A Component gives an entity its data. In Elixir modelling Entities as Supervisors and Components as Agents sounds a like a profitable idea. A System (the one that makes the processing) would receive from the component and entity updated message, insert it into a data struct and then do the system's purpose. If one element crashes under the system's queue, only the specific behavior for that specific component fails, so it really diminishes the blast radius of a bug.

Examples :

• Button would be just and entity with a Clickable Component, a Image component and a Text component, ordered by rendering priority. Click System would find if the clickable component was clicked or not and Rendering System would render Text, Image and other components on screen.

Another thing is that it just becomes really easy to build QtCreator/Unity like interfaces since you just should render the components and entities differently on different views. So Hierarchy, Scene, Inspector, could just take all fields of an ecto-like schema (scenic component schema) and render they by there given fields, creating new components also becomes really easy just use the scenic component schema

Persistence and prototypes are also a big advantage of that approach, since a scene is just a tree of data, saving in a json file would be a simple implementation, but it even better, you can save a json file for each common entity on your project(aka Prototype), and just persist on the scene the diff between the prototype's map and the instance o the entity's map on the scene, and there's a bonus here, if you change the color of a prototype everyone but the ones with this specific overridden field would change it's color, making it really easy to change elements that exists in multiple scenes

There's a lot to be explored in terms of designing with a QTCreator-like with this architecture, it would make coding a really rare when designing a scene. Animating, sound mixing, it all comes down to different systems for different components on the same scene entities.

I really hope to see this architecture in action with scenic and I'm willing to contribute if that's the case.

[quantumpotato]

+1 for this. ECS is standard for solid game engines. Having this in the UX would be great

ECS ingame dev:

https://www.youtube.com/watch?v=JxI3Eu5DPwE

https://www.youtube.com/watch?v=fGLJC5UY2o4

[crertel]

Thank you for your enthusiastic suggestion!

I'd suggest than an ECS is somewhat outside of the mandate of Scenic--this is a 2D rendering library, without a lot of frills. Any utility it has for something like games is nearly coincidental.

What might make more sense, as is the case for other games and engines, is to have a Renderable component in the engine/game ECS that itself calls out to Scenic.

An example of this is in @doawoo 's elixir_rpg project. Look at how they use:

• DrawingSystem
• SpecialSpriteSystem
• Sprite

(I think the rendering code/liveview stuff has been left out, but the bones of the ECS and how it works you can gleam from there.)

[pcarvsilva]

I'd suggest than an ECS is somewhat outside of the mandate of Scenic--this is a 2D rendering library, without a lot of frills. Any utility it has for something like games is nearly coincidental.

ECS is a pattern used in games it does not mean It's not supposed to be used outside this scope. QTCreator is not a game dev solution, but It cleary could benefit from a thing or two of this design

[crertel]

Closing out issue for now; let's resurrect it if Scenic 1.0 doesn't scratch the correct itches.