Doloro GDK 22 .1.0 Beta
by Tauri Interactive
|
TagsDatabase
as you may expect holds Tag
instances and provides API to handle the content.
.asset
object within the Assets directories.The project may contain several databases. This lefts you with an option to use personal database related to some module instead of using a common database.
package
or AssetBundle
.Even if you are using several databases the backstage does not require you any addressable access toward them.
Tags tools merge databases into a single one on runtime for common purposes, but also leave access to separated instances in case you need.
More about: API
TagsDatabase
instance must be located within Resources
folder to be accessible after build.Is an atomic entity of the Tags Tool that could be applied on over compatible objects.
By itself Tag
not provides any features and using only as a flag applied to an object.
The tags exist for several purposes:
The Tag
has simple descriptive members that allows you to adjust tag using within other systems.
Member | Type | Meaning |
---|---|---|
Key | string | Key of the tag using as flag. Case insensitive for backstage systems. |
Visibility | TagVisibility | Declaration of tag using policy. Not uses by core logic itself but can be useful for higher level systems. |
IsCached | bool | Editor only flag that allows to move tag related resources to cached collections for instance access in future. More about: Cache |
Tint | Color | Color of tag backplate that should be used at UI elements. |
Tag
related resources as cacheable only via editor. This limitation planned to be erased in future.You may mark a tag as IsCached to make the DynamicResource
instances with defined tag available instantly as collection.
This allows you to optimize operations during runtime and pre-compute part of catalogs during the game loading without ruining game experience of players with loading screens of micro-freezes during gameplay.
One of the possible exceptions Item
tag that allows to filter dynamic resources to inventory related system.
Such a tag should has the To Cache
flag defined as true
.
That will allow to get entire items in any frequently using systems like a:
Rewards, Shops, Inventories, Spawners.
At the same time the Item
market resource also may have some details tags like one of offered:
Tag | Sample in-game feature over the objects with the tag |
---|---|
Weapon | Item is a weapon. Should be displayed at weapon UI group. Can be applied to a weapon slot. |
Consumable | Item can be consumed. |
Food | Item is a food. Should located at the following section. Has affect over spoiling system. |
Cloth | Item could be spawned in tailor shops. Item can be fixed with sewing kit . |
Quest | Item can be dropped, consumed, traded via UI. |
Such a tags no need to be cached. It's enough to check is the item has a tag on-fly. But such tags allow to filter items by its property in UI groups, spawn logic or compatible features permitted toward the item.
As soon as the project may has several databases its a common sense that you may face a situation where you face a databases conflict when they have the same name and the same tags.
For a such case the backstage services do not use the databases directly but accessing them using API that provides merged database got via Merge Tool from entire detected TagsDatabase
instances into the project and asset bundles.
Databases merged to each other by following rules:
In case if the Tag
instance collides by the key to a tag in merge target collection then collided tag will be updated with the source one via the Tag.MergeTo(Tag)
handler.