Karta Subcrates

[teodosin]

No description provided.

[teodosin]

Initial thoughts:
Given the generalisability of the individual problems Karta tries to solve. it would make sense to modularise the code into crates that could be individually useful. This will help guide the plugin structure of the project, which so far has been unoptimal. Also might help attract contributors who may not be interested in Karta as a whole.

So here's an off-the-cuff initial suggestion for what the crate structure could be:

Graph Storage

This plugin would allow an ECS World to be saved and loaded into a database or folder of files. See #46

ECS Graph Editor

A plugin that displays the ECS World as a graph (or table). #47 Is drawn in front of the Scene.

ECS Scene Editor

#48 For creative coding and presentation purposes. A graph could be evaluated into an output, which would be displayed as a 2D or 3D Scene. Should be generalizable enough to eventually act as a scene editor for Bevy.

[teodosin]

There has to be an easy way to toggle between controlling the scene and controlling the graph.

In general the decision must be made of where the inputs are processed and what the division of labour between these two plugins is. Right now I am uncertain. The graph has to be able to affect the scene in a very quick and high-fidelity way, and it also has to be able to react to what happens in the scene. Can the division then be maintained so that the scene doesn't have to know about the graph? Would the scene editor still be useful, then, as a crate on its own?

What if both managed their own inputs but then had events that they broadcast so that when one is edited the other can be synchronised? I feel that might be the best approach to allow these to be used both separately and together.

In that case, the thing that would be out of scope for the scene editor would be managing what gets spawned and despawned. That's in the realm of the graph editor, which manages contexts and evaluates the data.

[teodosin]

The seemingly obvious starting point for this is to distribute the Events module into the parts that actually use it. Currently the Events module does nothing on its own (obviously) and the plugins that use it can't live without it.

One detail that could potentially affect this is the communication between the Graph Editor and the Scene Editor. They are meant to affect one another but also work on their own. They might need common events in order to communicate. Either that or they both should edit the ecs World directly and just react to changes in the World. Maybe the latter is simpler.

[teodosin]

Closed in favor of #86.