Illiux

I don't think this approach is robust. It's possible that an entity has _both_ a `DynamicScene`-added `Parent` component and some other component that implements `MapEntities`. In that case, I believe,...

> So let's make a theoretical component `struct StepFather(Entity)` that implements MapEntities. If this component is added to a scene file, it will be affected by scene file changes. But...

Oh wait, nevermind I see. I was misreading the code and didn't properly notice that the entities list is per-component.

> Much better docs, and I really like the closure based API. Why not bake this in directly to `EntityMap`? It's unclear when you would be okay to forgo the...

> * When serializing, just create a brand new Entity->SceneId mapping and allocate new SceneIds as new entities are encountered. This is very difficult to do because we currently can't...

I went ahead and added a commit that goes back to serializing entity identifiers as u64s, but via changing the implementation of `Serialize` and `Deserialize` on `Entity` instead of the...

> Can't we bake that logic into the serialization implementation of Entity? Not without very significant complexity and tradeoffs, as far as I can tell. To map within serialization would...

> > which in turn means that we couldn't implement the serde traits. > > We already have the problem with deserialization though, where we need the type registry for...

I've spent a few hours reading code and contemplating things and have some further thoughts. > > > which in turn means that we couldn't implement the serde traits. >...

I think this PR _should_ now be ready for push, and I might try a further PR that rids us of `MapEntities`. The only other thing we may want to...