#Best practices for complex UI?

5 messages · Page 1 of 1 (latest)

granite lion
#

Are there established best practices for designing and coding complex interactive UIs such as you might find on strategy games?

I'm particularly concerned with situations where:

  • There are many interactable elements (e.g., buttons) in different areas of the screen, which might pop up menus and sub-menus that should retain focus (or at least prevent interactions with underlying UI elements) until they're dismissed
  • You might be in different interaction modes (e.g., placing an improvement, viewing statistics, etc.) that might show or hide certain interactable elements

My primary concern is with maintainability. I don't want jumbles of conditional code for checking global UI state scattered around the codebase where I'm handling user input in different nodes. I'd also like to be able to extend/modify the UI as simply as possible.

spare parcel
#

Compartmentalize. Don't do everything in one menu object. Work out what types of buttons n stuff your going to be using, with an eye on potential uses of inheritance.

soft axle
#

+1 on what RadMcCool said. Create widgets for your UI elements and implement stuff using data.

#

and if you plan on doing localization, plan it from the beginning. Is gonna save you a lot of time.

granite lion
#

Thanks! I definitely am breaking the UI down into component objects. The problem I'm slamming up against, which I guess I didn't explain very well, is that using nodes as the basis for separation of concern breaks down when the propagation of input events is global by design, which creates lots of weird interdependencies between nodes. ("Why isn't this input working? Oh, it's being intercepted by one of the 35 other UI elements, which receives a different action bound to the same key, which theoretically should only be captured in input mode A, but that node isn't aware that we're currently in input mode B.")