Post by caesuric in Multi-line auto-resize

Viewing post in Multi-line auto-resize

Sure thing. So it's for a digital card game where I want the text to scale down when there's a lot of it. My attempt to paste in a bunch of example images keep erroring out so here is a link to my itch.io page: https://caesuric.itch.io/vortex-siege

In TMP I set a bounding box like so:

I would like to know the best way to achieve a similar scaling effect in SuperTextMesh, as I have a highlighting feature that emphasizes parts of the card text when they have changed due to effects, and STM's various animation capabilities would make this system far more effective for grabbing the player's attention.

Thank you for your time!!

KaiClavier221 days ago

Ah, got it! I see in your examples that you're dynamically scaling text to fit in the card's text area with a maximum possible size... I'm going to make a suggestion here to settle on a comfortable reading size for the text for consistency, and then base the length of what can be written on a card around that... With real cards, you'd want to keep a consistent text size to improve readability.

So... two ideas I'd do:

1. Choose a size based on the longest string in your game.

Here, I've used the rect transform to position it within a given area box, and changed the line spacing value to move text in a bit closer. (another option here is setting the Vertical Limit Mode to Squish, but that code isn't done yet and gets the alignment wrong. Either way...) As long as you test this with the longest possible string that will be shown on a card in your game, this solution will work and keep the font size consistent.

That said, the card's text is really small on the left, where I have it set to actual screen size. An 8px rendering size is really small, but if you're okay with this, this is the easiest solution. If possible, the text can be re-written to fit in at a bigger size, but assuming that's impossible...

2. Keeping a readable size, but not showing all at once.

So, if It's absolutely impossible to keep the text at a readable size in a particular area, I'd try to use a scroll rect! Here, I've set up a scroll rect in the area on the card, and I've got a few unity UI components set up in a very specific way:

On the "content" object, I've put on a content size fitter and a vertical layout group, note the settings on these, this will resize the content's height to match the containing text.

And here, I've scrolled down to show that the scrollrect ends where it's supposed to, and I've selected the Super Text child object. What's important here is the content size fitter with "vertical fit" set to "preferred size"... it will give you a warning about being within a layout group, but ignore it.

All that's missing is... you can disable "interactable" on the scrollrect, and make a script that automatically scrolls the scrollrect after a few seconds, and returns to the top, when text is too large to show at once.

So... apart from the broken "Squish" vertical limit mode, this is how I would handle it. Focus on the text size you want on screen first, then go from there! (Additionally, for the names on cards, the "Squish Over Limit" best fit option will be good for those, since they are a single line of text.

caesuric220 days ago

Thanks, I really appreciate all the thought and detailed examples, but this is a UI feature I see in games like MTG: Arena, and it is supported by TextMeshPro. Unfortunately I will probably need to stick to TMP for this particular type of text, at least until I think of another solution or work out some manual math to figure this out (perhaps using the content size fitter approach and checking the bounding box size).

My game also has dynamic rule text that can be changed by player modifications. While I do have a character limit on how big a card can get, for readability reasons, it's not really practical to assess based on the longest "printed" preset card.

Additionally, I once used the method you suggested where I just sized the text to the biggest practical size. In working on Steam Deck compatibility, I found that on handhelds, this text size was too small and required the player to hit the "view enlarged" button on every card to understand what was happening, hence how I ended up with a larger font size for cards that can fit it. What's "readable" differs greatly from device to device, unfortunately.

Also, unfortunately, the cards are in 3D world space, so a scroll rect is probably not great for me unless I create the UX for it manually by binding to mouse scroll events. And the vertical "marquee" effect I've seen in other games, and it has some disadvantages imo in terms of readability (the player might not be ready for the text to scroll, etc.).

Regardless, thank you very much for the thoughtful responses!

KaiClavier220 days ago

Oh, I see! I suppose since an arbitrary amount of text *does* need to be added to this space to fit the game's design, that is a good reason for this feature to exist... I'll add fixing up the "multiline" best fit mode back to my to-do list! The current implementation *works* but I'm just not satisfied with it. But since text will still get too small for where it's needed, I'm not sure it's the complete solution for this...

Hmm, if you're having text that's too small on a lot of cards, maybe they could automatically zoom in on hover instead of when pressing "view enlarged"? Or display the effect text enlarged somewhere else on screen? That way, there's no automatic scrolling that might happen at a bad time... I do want to add this best fit option as a feature to be clear, but I'm always thinking of stuff from a UX perspective.

Finally, Super Text Mesh *should* be compatible with SpriteMasks, so that will work outside of Unity UI as a manual type of scroll rect. (And you can have a world space canvas as well!)

caesuric219 days ago

Thank you! I suppose "popping out" an enlarged version of the text that uses STM features to show what's changed would be a pretty decent solution for now! I will probably hold off on making that animation, but it could enhance the current functionality anyway, so it's a pretty good idea. Thank you again for all the help!