Managing Complex UI with Multiple Panels/Screens

0 favourites
  • 6 posts
From the Asset Store
Casual UI Button is a customizable, ready to use desktop and mobile-friendly game UI Asset.
  • Hi everyone,

    I'm developing a football management/RPG game in Construct 3, and I'm facing a challenge with managing a complex UI. The main hub of the game has a persistent bottom dock, but the central area is divided into three main sections:

    * A slide-out player info panel (left side).

    * A central area displaying various screens (news, team info, player detailed view, etc.).

    * A right-side area for displaying other game entities (other players, agents, etc.).

    I'm trying to figure out the best way to structure my layouts for organization. My initial thought was to use a single layout with many layers, but I'm concerned about the complexity of managing the visibility of so many layers. Keeping track of which layers should be visible at which time seems like it could quickly become a nightmare, especially as the project grows.

    My main concern is reducing the complexity of managing the UI state rather than purely focusing on draw calls and memory usage, although performance is still a consideration. Any advice or best practices regarding UI organization in Construct 3 would be greatly appreciated.

    Thanks in advance!

  • You use as many layouts as you need that makes sense, and you put your ui on global layer(s).

  • Thanks for the suggestion! However, I think I might not have explained my setup clearly enough. The three sections of the layout (left panel, central area, and right panel) need to display different screens independently of one another. For example, the central area might show the news feed, the left panel could display player stats, and the right panel might show agents—all at the same time.

    To give a better idea, the setup is somewhat similar to how the UI works in Crusader Kings 3, where different parts of the screen can show completely separate interfaces depending on what the player is doing.

    Because of this, using global layers or switching layouts doesn’t fully address my needs, as it seems more suited for situations where the entire interface changes together. Do you have any advice for managing independent sections within a single layout while keeping the UI state manageable? Or maybe there's something about global layers and layouts that I'm totally missing?

  • That's what layers are for. There are system conditions to help you handle and manage layers.

    You can even use a dedicated event sheet for ui that is included on other event sheets for other layouts.

    Global layers can be used so that you don't have to recreate them in multiple layouts, and only need to edit the base one once to make changes.

    Otherwise I'm still not quite sure what the problem you're trying to address here is.

  • In your case, the best option is to use layers, but be aware of possible issues with objects overlapping or being hidden behind objects in adjacent layers.

    The advantage of layers is that you can perform certain actions (e.g., toggle visibility) on all objects in a layer without having to think about the object type of the instances you're dealing with. Layer interactivity is also a key feature.

    One thing I would suggest is using Construct 3's hierarchy system. A while ago, I made a fairly large building game with a complex UI. I assembled each panel (like the ones at the center of the window in your image) in a dedicated layout, using templates to make my life easier. Then, when needed, I would create the panels with the "Create hierarchy" option enabled, so that with just one action, the entire panel content was created.

    By setting the base of the panel as the parent and its content as its children, I was able to make the process of building the UI much less tedious.

    Looking back, though, I would rework this system by having a "container" as the parent. For example, I would create the panel with the player stats like this:

    - An invisible container named PlayerStatsPanel, which acts as the parent, with instance variables related to the panel itself.

    - The base panel (the rectangle that acts as the background), which is a child of the container.

    - The other objects, which are children of the base panel.

    You could also use sub-containers to make your life easier. For example, the objects that make up the stats pentagon could be children of a sub-container (which is a child of the base panel). The idea is to break down the UI into smaller parts, and then break these smaller parts into simple components.

    Here’s a trick that may help you. Let’s say you want to perform an action on a lot of objects: for example, you want to make each object of the player stats pentagon gray. You can’t do that just using the basic properties of the hierarchy, but a little script can help. We have our sub-container, and each object of the stats pentagon is a child of that sub-container. Then, we can do this:

    /*place inside a function with 3 parameters:
    number containerUID - the uid of your container
    string property - the property on the container children you want to change
    string newValue - the new value for the property
    */
    function isJson(str) {
     try {
     JSON.parse(str);
     } catch (e) {
     return false;
     }
     return true;
    }
    
    let newValue = localVars.newValue;
    if(isJson(newValue)) newValue = JSON.parse(newValue);
    
    if(newValue) {
    	const container = runtime.getInstanceByUid(localVars.containerUID);
    		for(let child of container.allChildren()) {
    		if(child[localVars.property] == undefined) continue;
    		child[localVars.property] = newValue;
    	}
    }
    

    This script changes any non nested property on every child of the container (also works for children of children). Place it in a function (let's call it ChangeProperty(...))

    Then you can use it in Construct events like this:

    ChangeProperty(Container.UID , "colorRgb" , "[0.5 , 0.5 , 0.5]")

    Also, make use of families and tags, they're very useful when dealing with UI :)

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Yes, in the end, I’m organizing myself with layers, and although I can grasp the main aspects of your explanation, I don’t know how to write code for Construct 3. So, I’ll have to find a solution through events/sub-events, while still making use of containers/hierarchy. Right now, I’m working on creating context menus using arrays, and making them clear and somewhat visually appealing is definitely a challenge... Anyway, thank you for your time!

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)