So I made a thing:
This is intended to be the prefab format that users will be able to create and modify through the editor. The existing prefab implementation isn’t ideal for using in the editor for various reasons, so this implementation was designed to unblock some of the work needed to have a prefab editor. On the other hand, this prefab format is pretty impractical to write by hand, so it won’t be ready for wider adoption until we have the prefab editor built.
I initially posted this in Discord and got some replies which I will respond to here:
YAY! That pleases me greatly, that was the entire reason I made
serde_dyn, so we could do this at some point. Though I’m curious why you feel type-uuid should be a separate crate
I did a couple of things differently than your initial implementation:
- I had the
TypeUuid::UUIDconstant be a
uuid::Bytesrather than a
u128, because I immediately ran into endianness issues when trying to compare the string version of the UUID to the
- Rather than deserializing the data into a
Box<Any>, I wanted to deserialize it into a trait object that directly implements the methods I need. I don’t know that this approach is actually better than what serde_dyn provides, it just made more sense to me at the time and I was in a rapid-prototyping phase
It also occurs to me that type-uuid could have use independent of serde_dyn, so it could be practical to publish it as a separate crate in order to make it the Rust standard for creating stable type IDs.
The only remaining feature to support my vision of asset pipeline for prefabs will be support for deserialisation of Handle<T>, where the handle is represented using an AssetUUID in serialised form.
This should be pretty doable. I’m still using
PrefabData under the hood, which includes a notion of loading sub-assets. So you could create an
AssetHandle type and implement
PrefabData for it, and it would automatically load the dependent asset.
Oh, and instantiation of Prefabs too.
I think you’re referring to sub-assets here? Nested prefabs? Should already work (or require little extra work to implement) since the existing prefab system supports sub-assets
Did you add prefab editing to the editor too?
Nope! There’s still a couple of major blockers in the way (type schemas and the editor core), but this is the first step toward the prefab editor.
We should consider serializing as RON rather than JSON too imo
One argument I can see in favor of JSON is it has bindings for other languages already built
I used JSON here simply because the implementation was more mature. I ran into some issues using
ron::Value, and noted that support for untyped desererialization wasn’t fully supported. serde_json is much more mature at this point, so it was more expedient to use it.
Also we should restructure the
amethystdependency to not depend on Amethyst directly. That way we can integrate it into the
I don’t think this needs to be directly in amethyst. amethyst only needs to depend directly on type-uuid such that all component/prefab data types have a UUID. Otherwise this can exist as one of the child crates like amethyst-assets.