Let's get real for a sec.
UI is hard.
UX is hard.
Like QA, it's an area that many devs seem to ignore and not consider in the core loop.
It may be due to many AAA games go for more spatial (in the location) or diegetic systems (part of the world and story) so people may miss it, or just the fact that good HUD- like, really good HUD- won't be seen simply because it's integrated so neatly into the experience.
There's a seriously deep level of consideration that goes into it.
To elaborate, there are different types of UI designs that can push clear information to the user.
Non-Diegetic - Simply 2D overlays of information, such as a Health Bar.
Spatial - In world representation of something that is not in-character such as a character having an outline colour for their health (non-aware in narrative).
Meta - A representation of something in-character (narrative) on the screen to relay the character state to the Player directly, such as blood effects in a FPS.
Diegetic - A blend where in-character information is also part of the physical world, such as an object in the world acting as a health-bar object that characters are aware of.
User interface design in video games (Stonehouse, A. 2014)
As the Travellers title is using a retro shared screen system with hard combat values, many UI tricks become limited meaning I have to rethink my approach to how to share this data without displaying too much information at once. A list of considerations for the UX and UI comes into play for this.
What genre is it (expectancy)?
What camera angle is it?
How many players is there information to show for and is it on a single viewport or split screen?
How many values are there to show and when are they needed?
Which information is most important to relay, and which is the least?
How can it compliment the artstyle and tone? (e.g. working with an artist team or set asset pack)
Asset scaling for correct resolution
Etc, etc. And this is just the in-game interface!
As UI isn't my primary submission focus, it's not something that I need to focus on immensely. But as I wish to keep a cohesion in the experience, I took out some time to apply some UE4 techniques picked up from the previous UI Module and work from the Travellers Kingdoms asset set.
Design and Creation
First off, I looked back at similar titles that matched a few of the answers to work of as a baseline; multiple-players in real-time gameplay, top-down camera, lighter-tone 2D assets, etc. Many of these worked simply with 2D non-diegetic UI for simple information, complimented by spatial UI elements such as Damage Rings when things would get busy.
Where Hades, Rogue Legacy and other single-player rouge-likes/lites help show how clearly set in stone is the Interface styles of the genre is, finding multiplayer takes on it deemed a tad more challenging.
To help this starting point, I looked at something outside of the genre that hit these points.
I rediscovered Final Fantasy: Crystal Chronicles which took a classic style of having Player UI taking each corner of the screen (akin to a splitscreen title). The more saturated UI to the game textures helped them pop-out, and simply displayed their health, name and skill; accompanied with a strip colour for their Player Number and Ring Colour.
Also, this was a GameCube title that used Game Boy Advance connections to act as multiplayer controllers! Surprising, and super motivating to see a player-base for this type of game!
Next up, Crypt of the NecroDancer was a helpful look at dungeon-crawling with it's Zelda-like visuals but shared for 2 Players. Their take simply shrunk down the UI for 2-Player (leaving shared inventory 1:1) to free up screen space. It wasn't the most neat way to present this, but due to the nature of the game being character sprite and tilset focused, it didn't ultimately detract from the game's flow. I went back over popular resolution specs to start working on a strong canvas size and plan out the new HUD.
The Individual Player's slate was drafted to mimic a blend of the aforementioned titles for the key elements: space for the Player's colour (Player Number), Health, clear input actions as Icons, and any perks/buffs.
A second iterative with feedback and more research had Player's important information stacked as a upper header for quick readability, and lesser info (such as buffs, and money) moved to the lower side of the screen.
This new setup also was a good time to make a stress test and consider the effects of exceeding the planned amount of users in the session (testing how UI would look if things shrunk with user participation).
With things spaced out more fairly, I readjusted needed components, such as the dungeon crawl map to give Player clarity in progression, and worked on more icons for easy readability and colour associations, e.g. Attack Skills being on the [B] button position given red icons.
As the plan is to continue to develop further content for this project, I've set icons up to be easily replaceable as construction parts created dynamically in the editor based on VARs, e.g. the map tile pieces referencing available exits and room items.
Deconstruction and Implementation
With the UI mockup deconstructed into parts, they were reconstructed into Widget Children for dynamic building to act independently (e.g. bound Skill Cooldown timers per Skill Slot), and collected into a Widget Parent as if it's a folder system.
I also used this chance to try dynamically building stats on the fly.
Empty widget Panels were used to set a canvas space of where I'd like elements to appear, and upon the construction event or a stat-changing events (e.g. Player took damage), update how many items exists in this panel stack.
Do they need removing? Do they need a new image?
It allowed UI to build itself neatly for each Player with only a location point and light icon reference without needing to hand-place each individual Health Heart or Skill, and leave only the subtle offset positions for final manual tuning.
The Map system was creating using a similar method to tile each room spot, but is slightly more complex in arrangement.
The Map widget folder is the core reference that builds the entire dungeon stream based on icons used, so it needs to be more specific.
The VARs used for each Tile widget child included the contents of the room, all generated as an array element series of Structures to understand what each icon means and to stream it into the game via sublevels when needed; Room Size, Treasures, Exit Directions, Enemy Composition, etc.
It can get more complicated in areas so if this is something that interests you, throw me a message and we can discuss how it's composed! It's some tedious fine-tuning, but it helps add to the feel of progress in a Dungeon when you see the your movement in the environment, even if the battle stage is on the small side.
Final Notes
UI is hard.
UX is hard.
But with practice, I'm slowly getting better at designing interfaces around an experience, and finding more ways to streamline the iteration process and development side of UE4's UMG setup. And I can't complain. It's really fun.
Comments