Official UI wireframing

yeah, @cirocontinisio, that seems like a very reasonable first step. One which does not depend on the specific implementation of the design. I'd be happy to start working on that after work tomorrow.

Just gonna repeat back the requirements to make sure I am understanding correctly:

what i'm hearing for requirements is destiny 2 style menu controls

e.g. once a menu pops up:
- both the mouse/keyboard and gamepad control schemes manipulate a "pointer"
- pointer position defines which UI element is 'selected'
- each control scheme has an "interact" mapping which activates whatever UI element is 'selected' (the pointer is hovering over)
- if the pointer is not hovering over a 'selectable' ui element, nothing is selected (e.g. pressing the 'interact' key does nothing)

 

My latest Miro-Mockups didn't include free movement with controller. Would be nice to have some feedback about it.

 

Those mockups are starting to get as complex as my original BotW-inspired wireframe, with the differences being additional popups instead of finding space on the main screen for cooking and using PS button controls instead of gamepad controls, which arguably are mostly interchangeable as far as position on the controller goes (i.e. both have 4 arrows on left, 4 buttons on right, and triggers up top).

I like how they flow, though, and think incorporating free movement with mouse or controller would simply mean adding an extra step to figure out where the "pointer" is before the LMB or action button could actually do anything.

One thing I'm not sure about is the quantity of recipe/dish to cook, do we need more than 1 at any given time?

 

Hmm, no, this UI from Destiny 2 is basically a mouse-first UI, where the controller just handles the pointer when the mouse is not present (= on console).

This is a pretty strange choice if you ask me. Looks like they wanted to deal with the big amount of buttons, grids, panels, options on screen (Destiny is an MMO after all); something which we won't have. So they went with a pointer, to allow the player to quickly traverse the screen and reach the desired option. Also it feels like they were getting ready for the PC version. Destiny being a shooter, it's understandable that they thought a big chunk of players would play it on PC.

What I'm thinking about for our game is a UI that's joypad/keyboard first, where the mouse can "intervene". At that point it'd work like just a normal pointer-based UI.

 

I see, yeah I misunderstood! So the business requirements are something like the following...

the keyboard + mouse schema acts just like the gamepad:
- some keys move the 'selection' from one ui element to another
- there is some 'confirm' or 'interact' button, which activates the currently selected UI element

However, the keyboard + mouse schema has the added caveat:
- if the mouse is moved it "overrides" the basic behaviour and a cursor appears
- mouse movements will update the cursor position
- whatever ui element the cursor is over is considered 'selected'
- left click will now act as an additional 'confirm' or 'interact' button

Finally:
- if the cursor is active, and the player uses the keyboard or gamepad, the cursor will dissapear
- - the 'cursor mode' interrupting keyboard / gamepad input will be applied, if possible, to the currently highlighted selection, otherwise to the previously selected ui element(?)

is this closer to what you had in mind?

And re destiny: i think you hit the nail on the head. I saw some talk on the UI of that system and they mentioned one of the main drivers behind their control schema was that standardized cross-platform / cross-control scheme interface. just like you were saying, they were launching both on PC & console, and had a pretty complex UI. so that solution worked very well for them.

 

Following last @piraente 's wireframes, I would just break down the types of Cooking items into tabs (or filters) instead of separating them by headers.

 

Yes, 100%.

The only thing I didn't get is this:

Do you mean that the currently highlighted selection is where the cursor appears, or what?

 

So the scenario is:

1. user is in 'cursor mode', user is highlighting the 'craft button'
2. user moves the cursor to some screen space with no ui elements, previously selected UI element ('craft button') is no long selected
3. user inputs right arrow key on keyboard or left stick to the right on gamepad

What happens?

I am assuming the desired behaviour is:

• store the last UI selection (in this case 'craft button')
• apply the command from that stored position- e.g. move to the UI element to the right of the 'craft button'

Is that correct? Alternatively we could do something like:

1. same steps 1-3 as above....
2. highlight the last UI element selection but eat the input... eg - user hits right arrow key, we just re-select the 'craft button' instead of moving to the next element.

Does that make sense?

 

If it’s possible, would be neat to have the cooking animation start by dragging each ingredient one at a time to the middle into a pot, have some steam coming out, then once all the ingredients have been dragged in, shake/stir the pot and have a sizzle/pop/ding sound when it’s done, with the image then changing to the finished dish with 2-3 action buttons below (eat), (save/store), and maybe (give) if the dish is for an NPC. Too much?

 

Ah, yes, so you're saying: what happens if the player starts using the keyboard again after using the mouse. Yes, makes sense that the selection is the last UI element that was touched when the keyboard was used.

I think for now we'll make it simpler, also never forget that we don't have "dragging" in the menus, since we want to support both gamepad and mouse, as discussed above and in the Controls thread.

 

I just meant the animation does it after the player clicks the action button to cook, kind of like the center of the circle sucks it in, not that the player is doing the dragging.

 

sounds fun =)

 

@ChemaDmk Can't find the current version of UI wireframing in Miro, which was shown on last stream

 

Is this what you’re looking for?

EDIT: Never mind, that’s not the UI wire framing. @cirocontinisio promised a cleanup and post of the private diagram to someone in chat on the last livestream, so hopefully he’ll have some time to do that before Tuesday. If not, we can just ask again then.

 

No, version of UI wireframing in Miro was shown on stream 2 by @ChemaDmk (partial here)

 

Hello, @ChemaDmk you did a lot of work to design the wireframes at miro. But there's a spelling error I have spotted.

 

These are really interesting observations, especially since they used this UI schema for Destiny 1 which was console only. Now that I think on that.. it makes sense that they went with a pointer for a controller only game solely because there were so many buttons, options, and panels. Very interesting. I can imagine getting annoyed if I had to move my selection across a lot of options.

Additionally, this circular cooking wireframe reminds me of a quick-access wheel. Has there been any discussion on HUD UI? Everything here looks so polished.