1
\$\begingroup\$

I was wondering how I should approach the runtime changes on the game UI when selecting different types of units in a RTS.

For example, in Starcraft, each unit type has its own portrait, attributes, buffs and command cards displayed in the UI. Selecting another unit will update all of these.

I can see two possible solutions:

  1. Each unit type has its own UI panel created (in memory), and selecting another unit disables the current UI panel and enables the new one.
  2. There is only one UI panel, and selecting a unit fills the portrait, attributes, command cards, etc. dynamically.

Both solutions seem inefficient. The first may consume too much memory, and the second makes no caching at all. Maybe the way to go would be something in-between, or completely different.

I'm working with Unity, but I think the discussion should stay pretty high level.

\$\endgroup\$
2
  • 1
    \$\begingroup\$ Since this is something that happens once, when the player takes an action, rather than continuously every frame, it's unlikely to be a performance bottleneck. You should prioritize whatever will help you implement and iterate on design changes nimbly. For example, building the UI panel at selection time keeps open the possibility of showing a combined/filtered list of commands if you select units of multiple distinct types, or in multiple states with different commands available. \$\endgroup\$
    – DMGregory ♦
    Apr 2, 2015 at 20:13
  • \$\begingroup\$ On what basis do you say that option 1 might use "too much" memory? How much memory would it use, and how much is "too much"? On what basis do you say that the second uses "no caching at all"; what would it not be caching, and why would it not be caching it, and why would not caching whatever it is that you're not caching be a problem? \$\endgroup\$
    – Trevor Powell
    Apr 3, 2015 at 5:10

2 Answers 2

Reset to default
2
\$\begingroup\$

Do not prematurely optimize: it will introduce bugs for sure or make code hard to maintain which will result in more bugs anyway.

And because you are working in Unity all graphics caching is efficiently handled by the engine(yes, you can hint the engine by referencing required data in scripts)

The whole problem should be taken in the most logical approach which you see as the most flexible one. Personally, I would select option 2 as it keeps state clean on every reselection event and is more data driven. While option 1 will introduce clutter in hierarchy and possible problems like in case two or more will stay(due to exception preventing the proper flow of switching). Actually everything which doesn't clean its state asks for trouble.

\$\endgroup\$
1
\$\begingroup\$

Option 2 is most common method. If you concern about the update efficiency, you could do more property compare in the ui update function, and only update properties really changes.

// a single state cache for current ui sheet
preState = stateCache[stateKey];
// or you can retrieve from ui element to save memory and keep it simple
// preState = uiElement.getValue();
if (preState != unit.state) {
   uiElement.apply(unit.state);
}

In most case, most part of ui stay unchanged, as selecting between similar units. Finally, the selecting is not a frequent action as per-frame action, it will not be the bottleneck usually.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .