TaleSpire DevLog 424

Hey, it's me again!

Before we go into the usual devlog content, I want to say that Bouncyrock is officially on holiday from the 19th of December until the 2nd of January - as usual, we will stick around to ensure everything continues to run smoothly. Still, we'll spend most of that time refreshing and relaxing to recover our energy and kick off the new year with even more progress than we're ending this one with!

But now, back to the scheduled program: Next to the usual handling of tickets and a handful of bug fixes, what kept me busy recently was tags. So many tags. ALL OF THE TAGS.

My last update on them was a while ago, and there definitely was movement on that front! Last time, I talked about the overarching goals the new tagging system had to achieve, so let's get into those in a bit more detail:

• Discoverability: To find assets (new or "forgotten" old ones), we need more consistency and predictability in our tagging. We plan to tackle this by making the asset authoring tools more straightforward to use (more on that later) and having a more thought-through and "planned" list of tags instead of the over-time-organically-grown list we have now.
• Ease of authoring: Making tagging simpler aids in letting artists do what they are best at - create art - and frees up more mental capacities to let them do a better job with tags. To facilitate this, we plan on doing a few things:
  - Tags imply other tags: This allows artists to "describe" the asset without needing to specify "obvious categories" manually - e.g., adding the "chair" tag automatically adds "furniture" as well^[0] or tagging "dragonfolk" also adding "humanoid". This ensures that unless explicitly overridden by the artist, users can depend on these "category" tags to be consistently on all relevant assets without any extra work from the artists.
  - Questionnaire: An interactive questionnaire should help fill in the most common things without having to "think" about it or risk forgetting parts. An example of this would be "Is your creature alive or not?" with options like "Alive", and "(Un)dead", where selecting "Dead" would show a list of relevant tags like "zombie", "ghost", or similar. Completing the questionnaire should be quick and leave you with an asset that has most basic tags added, and all you need to do is fill in the things that make this asset unique. This structure also makes it easier for modders to follow the same tagging "style" we do.
  - Automatic tagging: We can automatically detect and tag certain properties from the 3D model itself: Whether it "emits light", its size, interactivity, and maybe even auto-detect colors. Again, artists will be able to override these automated tags.
• Translations: We've had some discussions here and decided that there aren't many "smart" things we can be doing here, so we "just" need to make sure that we don't stand in our way in the future when we tackle this.
• Scalability: Since the tag system is now a lot less strict with categories than my initial plans, we get this for "free" - whatever else we want to tag in the future, we can simply use a similar approach, just with a different list of tags (music tracks have little use for a "dragonfolk" tag after all)

Let's get more into the weeds: I pivoted from investigating tiles and props tags to creature tags a few weeks ago.
The first step was sifting through the current list of all our tags. Just for creatures, that is 633 currently in use, which is... a lot. A big task was thinning this list down to tags that make sense - we don't want to get too specific because then a tag might only have one or two creatures associated with it, but staying too generic provides insufficient tools to narrow down the library. Additionally, we don't want synonyms of the same thing as individual tags; our search engine implementation should handle this^[1]. Applying these two principles, we've gotten the list of unique creature tags down to just 200 - even though we also added many generic tags for future use! This list of tags is intended to be "as minimal as possible", which we'll likely expand on once implemented and tested.
The next step was to add as many meaningful relations between tags as possible (the aforementioned "chair" -> "furniture" kind of relation). At this point, I want to shout out graph databases for being a really cool thing for organizing this kind of mess!

Hopefully, we'll have a first implementation of the new tags in your hands reasonably soon - there's some remaining cleanup to do, but the actual list of tags is nearing completion, then we'll have to integrate it into TaleWeaver in a way that makes sense.

Disclaimer: This DevLog is from the perspective of one developer. It doesn't reflect everything going on with the team

[0]: This "tag implies tag" can, of course, be overridden - we want to allow entering sane defaults as quickly as possible, not remove control from the artists.

[1]: As an example, we don't need to have "hunter", "ranger", and "archer" - as long as our search implementation suggests "archer" when a user enters "hunter" or "ranger", we only need the archer tag - that way there's no chance for one "person with a bow" to be tagged hunter, while another is tagged ranger and a third with archer when they all look the "same" and can fill the same use case ("I need some people to be on my city wall to shoot down on the zombie hordes"). In a similar vein, we've removed a lot of tags that aren't visually distinct - a PR manager and an accountant don't "inherently have a different look"; they're just different kinds of office workers. If we had an "accountant" tag, we'd also have to have one for every possible office job under the sun, which is not very useful. Of course, this can be a grey area with plenty of trade-offs between specificity and generalization.