Sam-Gideone
commented
10 months ago I second this proposal. Data that can be stored at the asset-level is extremely beneficial for a myriad of cases.
That being said — part of me wonders about the effectiveness of using Prefabs as data containers instead. Yes, there is no type-safety (and with the lack of ability to write custom attribute/property drawers this is very notable issue (Just scrounged enough to learn that editor extensibility is possible — just undocumented. Is it as flexible as Unity?)) but the Entity-Component nature of a Prefab gives greater flexibility than the inheritance-architecture that Unity's ScriptableObject class provided.
If ways to remedy the authoring pitfalls of using Prefabs as Custom Asset Types were implemented, a side of me feels that using Prefabs may result in a more flexible and unified approach to Evergine's current philosophy and tech stack. Custom property drawers, inspectors, and editors would all be necessary to make the experience first-class, however. And that's the gotcha — the development work necessary to make this approach truly viable may be too great to have this be a consideration.
All of this being said — I think there is a place for both Custom Asset Types and Prefab-Data-Container adhoc usage. If it were possible, I would prefer for both cases to be streamlined as each are valuable in their own ways.
When building Games, one of the challenges that usually need to be addressed early in development is "how will we keep our data?". As an example of a card game, you will need to keep data of all the cards that are available in your game and additional information of the card, such as: Texture, Name, Description, Effects List... In cases where we are dealing with an Online Card Game, such data will probably be stored somewhere in a server ready to be retrieved, if necessary. However, when building on Single-player experiences you will want this data to be shipped with your game.
Right now we can expand Evergine to read raw data using the .NET API easily to bring this data during runtime using the format of choice. The are endless ways to keep this data and read it later during runtime. However, external assets created this way will have to be manually included into the build pipeline of C# so they can later be copied over and they will not be referenced through Evergine's Asset Manager.
To keep data more integrated with their Engine, Unity created the ScriptableObjects, which are usually used to keep a large amount of data which can be assigned directly through the inspector and referenced later when needed. I believe Evergine would benefit greatly from the ability to create custom asset types that could be viewed and edited directly through the Editor as well as referenced in Components, Services or Managers. This would also allow whole teams to keep to the Editor itself when building these experiences and eliminate the need of using external tools to populate such data and later custom code to read it during runtime.
Custom Property and Panel Editors could also be used to customize the editing experience of such custom Asset Types, allowing for better editor tools and better engine workflow.
Potentially, this could be used further to extend the Editor by the implementation of Custom Importers, such as Unity's ScriptedImporters approach. This would allow custom file types to be easily integrated into Evergine if they use external editors or if they have a need for additional data processing during import.