Now, all of this new gear and loadout stuff leads me to needing all-new UI. And this is a tough sell (read: feature creep). UI takes time, art takes time, it implies all sorts of input requirements and visual feedback and methods of data access. But hopefully I can do it for one panel and then use it for all the rest similarly (much easier said than done).

So I am making a new panel for loadouts — changing player’s equipped gear — and first I’m adding a quick debug button to open it:

I don’t actually have any location in-game where the player can access the loadout. I will cover this functionality later. For now I just want to get the panel working.

As the core logic, I am creating a display of all the player’s gear slots and items in those slots:

I have glanced over UI panels before, but there’s a lot of low-level stuff happening, so I’ll go over some of it. I rarely get to make lots of screenshots for relatively quick features (at least, since I’ve done UI so much). In the end, this looks something like this (horizontal lines being slots and boxes being items):

I knew how I wanted to do this before I did this, so I will work backwards (top-down) explaining what is happening.

The “Slots” creates all the slots I need at runtime — the ones I defined above, so we get 5 slots:

And each “Slot Display” creates all the items that the player has available in their gear system, so we get the same 3 hull and 2 weapon items:

This is done with some “lazy” pooling where I create the items I know I will need (slots) or create them when I need them (item).

One of the most important parts here is navigation — I need the player to select what they want. It’s quiet easy with a mouse, but it gets tricky with a keyboard and–oh boy–do we get into fun zone with the controllers.

Thankfully, as I mentioned before, I am using Rewired plugin and I can wire the joystick buttons and the keyboard keys to the UI actions of moving the selection around. And I can get these to register, get processed and show up, even though it’s all finicky being virtual axis and whatnot:

And I need to do my own processing of axis so I can check what has actually been “pressed”:

Anyway, long story short, I can now pass these to my panel manager, which then passes a formatted list of UI input actions to the panels that needs these:

It’s very important that no panel ever decides they are allowed to process input that can come from multiple sources and the player could have rebound. It’s got to come from a central system. Mouse control is … different — I am fine with detecting “clicks” because it’s the same as taps or virtual cursors and Unity events handle those okay.

Anyway, I can then pipe these UI input actions down the panel hierarchy to whatever elements I want to process this. Here’s my new hierarchy ready for navigation:

With some additional elements for highlighting the selected slot and the item that is selected and/or equipped, I get this (blue line – selected slot; green rectangle – equipped item, blue square – selected item):

Now, I don’t want to select items in rows/slots that the player isn’t on. So I only show the selected item for the selected slot:

    

In fact, my slots remember which items they have selected. I don’t want this — I want the player to navigate visually logically, so like so:

I am also wiring mouse/pointer clicks to act as instant select and equip.

These will of course look differently, but for testing they work out nicely. And the navigation lets me update the selected items on the fly and tell the loadout system to swap items around.

Now, I need for the player to know what bonuses their loadout and gear actually provide. First, I’ll add the overall bonuses for the equipped gear. This means I need a similar hierarchy for bonuses to display:

The default case is when there are none, so there’s a special label for that:

And if there are, a display for each gets created:

I will be adding proper UI later, but for now I have debug ones:

And very similarly I can have each slot have its own bonus display element that shows the bonuses from that particular gear item:

And this pretty much completes the loadout panel logic.

As I said, I will have to do all the proper UI later — positioning, sprites, labels, organization, feedback, etc. And not to mention actually being able to access this in-game. But all of that is for later (which seems to be my motto for every feature).

Related Posts

MicroRogue DevDiary #72 – Loadout UI
Tagged on:         

Leave a Reply

Your email address will not be published. Required fields are marked *