Pixel Crushers Forum

Hello, we are working on a mobile game and I'm curious on how dialogue system stores the information such as conversations, actors, portraits, and quest. Specifically wondering when you are using Actor portraits, are all of the images being cache once a Dialogue Manager is loaded.

They have to be in memory because any portrait could be used at any time, but each portrait image is prepped the first time it's used. If you're seeing hiccups, which can happen when prepping large images on slower devices, add a Preload Actor Portraits component to your Dialogue Manager. This should resolve the hiccups. The best setting is to tick Collapse Legacy Textures, and then inspect the Dialogue Manager and tick Instantiate Database.

Mostly I don't want them to take any ram space until I use them.

What's your RAM budget?
How big are your images?
How many portraits do you have?

If it turns out to be a concern, you can manage the UI yourself instead of using the built-in UI options. The Dialogue System will work happily with any script that implements the C# interface IDialogueUI.

If you know that certain characters won't be in certain scenes, you can split your content into multiple databases and only load the databases that you need for each scene. I recommend only doing this if you absolutely need to. Managing multiple databases adds a lot more complexity.

Another option is to load portraits dynamically using assetbundles and the SetPortrait() sequencer command. But you need to manage assetbundles in this case.

If you can provide answers to the questions above, I may be able to offer some advice.

My ram budget is 220mb,

Currently portraits are this nasty size 446x500 each sporting 0.9mb. And 20 portraits are set for the actors.

-Currently Fixing portraits to 512x512

*edit fixed all portraits to 512x512 with compression now sporting 256kb for each

That means your portraits will take 2% of your RAM budget. If that's acceptable, I recommend going with it as-is. It's by far the simplest approach, since you don't have to do anything extra.

If that's not acceptable, please let me know if you're comfortable scripting. I'll describe solutions based on scripting or not. Scripting is more succinct, but it's possible to handle this without scripting, too.