This is the final PR for redesigning the asset types. The main improvements of this redesign are that the type provides better APIs for accessing raw or loaded level data, and internal/external levels are modeled more correctly.
The LdtkProject type is still the asset type and stores most metadata applicable to either level locale, along with LdtkProjectData.
LdtkProjectData is a enum whose variants store the actual ldtk json data, with a variant for each level locality. The internal types of the variants are LdtkJsonWithMetadata<L: LevelLocale>, with either InternalLevels or ExternalLevels as L.
LdtkJsonWithMetadata<L> is a generic type storing the actual ldtk json data + level metadata, with either InternalLevels or ExternalLevels as L.
Splitting these up like this allows us to define some methods that are exclusive to each level locality. This is important because accessing loaded level data is a very different operation memory-wise for each case (indexing the LdtkJson for internal-levels, or accessing the Assets<LdtkLevel> asset store for external levels). But other methods can be provided for either case, either with a generic implementation at the lowest level, or exposing transparent implementations in the higher-level types.
An important point about this new design is that LdtkLevel assets are no longer used in the internal-levels case. Level entities will only ever have a LevelIid component, no longer a Handle<LdtkLevel>. The handle for the asset in the external-levels case is only stored inside the LdtkProject. To help make this change clear, LdtkLevel has been renamed LdtkExternalLevel. Doing things this way actually fixes an egregious clone of all level data that is in all previous versions of this plugin.
See the documentation of LdtkProject to learn about the best ways to access loaded level data now.
feat!: LdtkLevel renamed to LdtkExternalLevel and is no longer used as a component (#244)
FYI @Hellzbellz123 this may affect you. Reflect is still only implemented for the level asset type, but now those assets are only created if the project uses external levels
Closes #205
This is the final PR for redesigning the asset types. The main improvements of this redesign are that the type provides better APIs for accessing raw or loaded level data, and internal/external levels are modeled more correctly.
The
LdtkProject
type is still the asset type and stores most metadata applicable to either level locale, along withLdtkProjectData
.LdtkProjectData
is a enum whose variants store the actual ldtk json data, with a variant for each level locality. The internal types of the variants areLdtkJsonWithMetadata<L: LevelLocale>
, with eitherInternalLevels
orExternalLevels
asL
.LdtkJsonWithMetadata<L>
is a generic type storing the actual ldtk json data + level metadata, with eitherInternalLevels
orExternalLevels
asL
.Splitting these up like this allows us to define some methods that are exclusive to each level locality. This is important because accessing loaded level data is a very different operation memory-wise for each case (indexing the
LdtkJson
for internal-levels, or accessing theAssets<LdtkLevel>
asset store for external levels). But other methods can be provided for either case, either with a generic implementation at the lowest level, or exposing transparent implementations in the higher-level types.An important point about this new design is that
LdtkLevel
assets are no longer used in the internal-levels case. Level entities will only ever have aLevelIid
component, no longer aHandle<LdtkLevel>
. The handle for the asset in the external-levels case is only stored inside theLdtkProject
. To help make this change clear,LdtkLevel
has been renamedLdtkExternalLevel
. Doing things this way actually fixes an egregious clone of all level data that is in all previous versions of this plugin.See the documentation of
LdtkProject
to learn about the best ways to access loaded level data now.feat!: LdtkLevel renamed to LdtkExternalLevel and is no longer used as a component (#244)