Not logged inOpenClonk Forum
Up Topic Development / Developer's Corner / Experiment: Interaction Menu
1 2 Previous Next
- - By Clonkonaut Date 2018-03-28 15:54 Edited 2018-03-28 15:57
After a release, it is time for experiments!

I collected some of the feedback we got for our newest release and am planning to do some testing around with various elements of the game.

This experiment is about the interaction menu. The feedback I collected revolves around how this menu is very distracting and very big. It essentially blocks out the main game and obscures anything going on behind it. People tend to strongly dislike it in Melee scenarios because you cannot spot enemies attacking you while going through an inventory. As described by B_E, it can also confuse you in a peaceful scenario because you don't see threats for your clonk.
I also realized that this menu uses the wooden decoration frame as opposed to all other GUI elements that are not dialogues. So I replaced the frame with something simple, golden. I am not fully happy with it yet, as there are problems (mainly the scripted GUI not respecting the space a frame takes up).

So, what did I do? Attached you find a scenario in which I drafted three styles of menus I came up with. You can open each one and compare.

Press E for the old style menu with a different frame. No major change here, except for the 'swap everything' icon which is also a suggestion:


Press R for a compact menu. With this one, I tried to shrink down various elements, to make it more compact and take up less size on the screen. Also, the background is mostly transparent, so you can still see what is going on.


Press T for a togglable/collapsable menu. The style is same as the compressed one but that is coincidental. This isn't something new per se as the old style menu also has a minimized version. The differences with this one are: the major structure of the menu doesn't change place, so you'll always know where it opens and when collapsed it only displays the contents and nothing else. Ideally, contents and other entries will be more visually separated. Maybe the 'Production' submenu will always be present when collapsed, as this and contents are the most frequently used ones. And of course, the collapse/uncollapse button should not move.
As to when it opens collapsed / not collapsed, there are several possibilities: Always collapsed when opened (as it is in the test scenario), double tap the button for uncollapsed opening, a per Scenario setting (distiction could be Mode Settlement/Melee), a per Player setting or a per Object setting.
Incidentally, this menu when uncollapsed also is an example of the compressed menu style but covering more display area.


Of course these styles are not yet fully fleshed out, so no need to nit-pick any small errors like overlapping elements. I wanted to get feedback before putting too much effort into this so it won't be wasted. I have also taken the time and separated the menu creation from the interaction menu's script to support different styles. We could therefore have several different styles and leave the decision to the players.

The scenario can be tested with 8.0/8.1 so no need to download a snapshot.
Attachment: Interaction_Menu_Test.ocs (142k)
Reply
Parent - - By Maikel Date 2018-03-28 16:33
Aleady discussed in IRC, but just my opinion for all here:
* New frame is great! No need to block stuff by a large frame.
* I would prefer to stick to "2em" size slots in the contents menu (for more speedy selection).
* I would prefer the R menu (but less compact in vertical direction) with opaque backgrounds and the side buttons with text below them (the side buttons can be transparent).
* Then add an option to turn the menu in transparent vs. opaque for each player(.ocp).
Parent - By Clonkonaut Date 2018-03-28 16:40

> * Then add an option to turn the menu in transparent vs. opaque for each player(.ocp).


That's a good idea!
Reply
Parent - - By Marky [de] Date 2018-03-28 19:02
I like the R one. Please try to design the menus so that the look can be overloaded easily :)
Parent - By Clonkonaut Date 2018-03-28 23:28
Yeah, I will keep the separation of menu code and menu style, for overloading purposes.
Reply
Parent - - By DaFatBrainbug Date 2018-03-28 19:46
I think the last one is the best of the 3, but there are some other things wrong with it besides occupied screen space.

Using it is hard:
way with mouse is soooo long.
Stuff I have to click is too small.

I don't need text:
"Bran - Inventory" - I know this is my inventory
Text on left and right should be left out too, instead make pictures speak.

Still a lot of dead space even in the last one.

With all this in mind, I made a quick mockup of what I think it could look like.
Reply
Parent - - By Clonkonaut Date 2018-03-28 23:44
The mockup certainly would be a bit nicer for just transfer of contents. However, the menu must be able to display more, i.e. all other important settings that buildings offer: production, repairing, information... (see attached screenshot).
Reply
Parent - - By DaFatBrainbug [de] Date 2018-03-29 08:53
Would you say that the main function of the menu is transfering items?
If so, then this function shoud be more prominent in the design.

When I first opened the (old) menu I didn't get it. Too much going on, and the important stuff is somewhere in between the rest.
So I avoided using it at all.
This shouldn't be the impression first users get.

I'm used to complex menus, I play Paradox games (Stellaris), but I think is one is unnecessary complex.
Do you need healthbars in a menu? The production could be a different looking column to the right (in my example).

Don't get me wrong, I think your'e doing a very nice job here. I am trying to help :)
Reply
Parent - By Clonkonaut Date 2018-03-29 10:38
Have to think about it, but redesigning this is something that would involve all the devs.
Reply
Parent - - By Zapper [de] Date 2018-03-29 11:30
IMO, the inventory transfer is the most frequent function of the menu. But I doubt that it's the most important.
Being super clear with difficult states (e.g. the pump state) and showing additional information about how things work (sawmill/windmill/damage) is, IMO, very important to actually reduce the perceived complexity of the game and to make players pick up the game more easily.

>Do you need healthbars in a menu? The production could be a different looking column to the right (in my example).


There is a drawback with more columns: Vertical scaling is easy due to scrolling. Horizontal not so much. You have to ensure that a player has a specific width of screen space available.
And in case we get back to splitscreen gameplay, the available space might be too low for multiple columns.
Parent - - By DaFatBrainbug [de] Date 2018-03-29 12:30
I agree that you have to reduce perceived complexity. But I think the presentation of this information in a big menu actually does the opposite.
Having the health bar float over the building and having an easy-to-read icon (maybe with a little text) floating beside it would be much faster to grasp.
Think about Anno for example. If there is a problem with a building, there will be a floating icon over it, stating the problem even without text. No need to go there or click it. Just at a glance while doing other things.

And if you can't state the problem in an icon, i feel like the mechanic itself might be too complex.

It feels like the big menu 'cuts' into the game-flow/atmosphere.
Reply
Parent - By Zapper [de] Date 2018-03-29 12:44

>Having the health bar float over the building and having an easy-to-read icon (maybe with a little text) floating beside it would be much faster to grasp.
>Think about Anno for example. If there is a problem with a building, there will be a floating icon over it, stating the problem even without text. No need to go there or click it. Just at a glance while doing other things.


I actually worked on such a "status display" before based on showing messages around the building when a certain key is held (back in 2013, wow).
But that felt a bit clumsy. And even the feedback for the power light-bulbs was along the lines of "That cuts a lot into the atmosphere and immersion of the game" when icons float around.

In Clonk it's not necessarily about a "problem" with the building, but also about managing state (pump, scaffolds, probably more..). For that, you have to open a menu in Anno as well.
Parent - By Clonkonaut Date 2018-03-29 12:53
I'd like to have the menu structured in a sensible way (so more important items are easier to see) but agree that having all that information in a menu is easier to grasp (so agreeing with Zapper here).
The menu is a place where you get all information about any given object and all options available. No need to have multiple sources of information. Redundant information would be okay though.

The problem with floating icons are, unfortunately, numerous. First of all, when does a specific icon show up? All the time (so damaged buildings would always show health bars)? Or at what specific action during the game? With Anno (and all other top down, isometric view style games), this is much easier, as health bars or icons seldom overlap with other game content or can show up when you select a specific building/unit. In OC, we'd have to define that specific moment of 'now show information' (which right now is the voluntary press of E in front of an object).
The next problem is how many of these icons show up? A complex structure like a pump might show you so many things at once, it gets confusing and annoying just looking at it (I actually dislike the floating light bulbs for electricity buildings, these are often distracting and seldom useful).
The biggest problem is always iconography / semiotics. Pictures alone will often not be unambiguous. Something that you think speaks clearly might confuse other people. Coming up with a fitting icon for a certain information is a hard task. Even for 'simple' things (think of the common 'Save' icon for example, depicting a floppy disc; for the current young generation, this picture carries no meaning whatsoever and they have to actually learn that this will save your work).
Reply
Parent - - By Zapper [de] Date 2018-03-29 16:19
Okay, but whaaat about adding a super-hotkey version of the inventory:

Without any menu open, when you press Shift+E (because Shift is the pickup modifier), you get a small number above each nearby container. When you press that number, that container shows the first 9 items of its inventory above its ingame graphics. When you press a number, you get that item from the container. When you press Shift+Number, you put your own inventory item inside the container. When you press [left], you take all items from the container. When you press [right], you put all items into the container. When you press [down], you abort. When you press [up], you open the interaction menu for that object.

That would still allow the easy to understand and detailed interaction menu to exist in its current form. But for better players, who would play with hotkeys, it would over a maximum-fast alternative to the mouse-based menu.

Mhhh?
Parent - By Clonkonaut Date 2018-03-29 16:28
That does sound cool. :o
Reply
Parent - - By Randrian [de] Date 2018-03-29 16:41
Hmm, I am not convinced with the number keys, when you have your hand resting on wasd, you can only reach a very limited number of number keys. Why not have then open a small menu which shows a row of your own 5 item slots and then the items from the container and you can navigate with wasd in the menu. Hitting the confim button (e.g. space) you transfer the item you have selected in the menu to the "other" container (e.g Clonk->Container or Container->Clonk).
Reply
Parent - - By Zapper [de] Date 2018-03-29 16:58
How would the first selection work? Still with a number and assume that you usually just stand in front of one or two object?
Parent - By Luchs Date 2018-03-29 19:00
I like your (parent) suggestion, but I'm with Randrian here: the number keys should at least be optional. Apart from some hard-to-reach numbers, I'm also thinking about our gamepad controls which do not have any number keys.

You could avoid the first number selection by cycling through containers with repeated Shift+E presses (but number keys would still work for those who prefer them).
Parent - - By Marky [de] Date 2018-03-29 16:45
Sounds very "Clonk has strange controls"-like?
Parent - - By Zapper [de] Date 2018-03-29 17:00
Yeah, but that would be the controls for people who want to optimize.
New players would still be able to use the interaction menu.

Along the lines of: Easy to learn, hard to master.
Parent - By Fulgen [at] Date 2018-03-29 17:42
Floor Menu Fight!
Parent - By Fulgen [at] Date 2018-03-29 17:42
Nice idea! I like it.
Parent - By Mupf Date 2018-03-31 09:52
As long as this limited menu is also usable with mouse and/or gamepad, I'm all for it!
Parent - By Zapper [de] Date 2018-03-29 06:42
Pictures speak more than 100 words.
Second picture is a new suggestion.
Parent - - By Newton [de] Date 2018-03-29 21:15
As someone who hasn't been playing OC for quite a while, you can call me a n00b:
- I think it is important to somehow make it clear in the UI that the icons on the left and on the right are actually tabs. They are tabs, right?
- The free-floating X is weird. Couldn't the menu be closed by clicking anywhere outside the menu area?
- I don't understand what the big empty box on the lower center is for.
- I find it weird that the production and damage? menu is shown as if it was an inventory. The old-style menu seemed to make it a bit clearer. Idea: Use different background colors for the different types of menus?
- I yearn for the old circular menu :-P - I know, the settlement-game is too complex for this, but still...
- I like DaFatBrainbug's idea. Perhaps, a related idea is to show the menu at the bottom, sliding up when opening and sliding down when closing, not covering the whole screen but what it covers is solid (Clonk 4 style, but not limited to one line ;-))
Parent - - By Clonkonaut Date 2018-03-29 22:37

> They are tabs, right?


Yes, they are!

> Couldn't the menu be closed by clicking anywhere outside the menu area?


I does! I guess the X is just redundancy for people who are confused on how to close this menu. Is good though because 'just click anywhere' isn't something you can communicate that well. But people can stumble upon it. Of course, the menu also closes when pressing E again (the button you opened it with).

> I don't understand what the big empty box on the lower center is for.


It shows decriptions and hints for items you are hovering over in the menu. The screenshots are not descriptive in that manner because I don't hover over anything. See attached a screenshot where I hover something!
But yeah, we can hide it as long as it doesn't show anything.

> Idea: Use different background colors for the different types of menus?


Yeah, Zapper's iteration has that and my next one will as well!
Reply
Parent - - By Marky Date 2018-03-30 07:30
I'd prefer it to be more transparent and if the production / damage fields were aligned to the bottom of the window. At the moment (in the old menu it was not as apparent) there is a lot of empty space below the damage bar, that looks weird.
Parent - - By Maikel Date 2018-03-30 08:45
How would you align to the bottom? I think it is not possible to make the menu size depend on the amount of entries an object has.
Parent - By Marky Date 2018-03-30 09:15
Ah, I think I get your point. How about making the non-inventory items a separate group/box then?
Parent - - By Clonkonaut Date 2018-03-30 10:38

> in the old menu it was not as apparent


Huh. If you look at the first screenshot in my starting post, I find the empty space very apparent.
Reply
Parent - By Marky Date 2018-03-30 11:32
In the old implementation everything is dark anyway, so I focus only on the GUI elements that stick out and the empty space does bother me less.
Parent - By Maikel Date 2018-03-30 08:52
This image looks already much more promising! Can we put the tab selection images in the same type of frame individually? Maybe that makes it more obvious that these are part of the menu.
Parent - - By Zapper [de] Date 2018-03-30 11:15
code plz
Parent - By Clonkonaut Date 2018-03-30 11:38
Yeah, yeah. Probably today. I'm not finished yet!
Reply
- - By Clonkonaut Date 2018-03-30 21:07
New iteration after I picked up the feedback in this thread:



I used the draft that Zapper posted above. There is now a bigger gap in the middle to see your clonk. The sidebars look more like tabs now. Most importantly, to end the debates about the best transparency I made a settings button (below the close button). Click it and you get two additional options button: background transparency and captions on/off.

Transparency has three modes: whole menu opaque, whole menu transparent and menu transparent but entries (Inventory, Production, Damage, ...) opaque (the latter being the default).
Captions on/off will remove some text that mainly DaFatBrainbug complained about - but I get it that more experienced users want to ditch helpful texts (because they know all the stuff) and have instead more compact information.

The options will be saved in the player file and are therefore kept throughout other scenarios.

Scenario attached. Again, there are a few quirks to yet work out (like some hovers or tooltips not working or something) but, again, I'd like feedback before getting into the detail work.

Answers to some other suggestions:

Have the menu be sized accordingly to the contents, making it smaller for most objects
This is, unfortunately, not possible at the moment, as there is no way to get feedback about the height of the entries (some of them scale freely, like contents with multiple rows). Maybe we could have a GUI style option GUI_FitChildrenLimited which would extend but only until Bottom = "..." is reached in length and then have a scrollbar.

What is that big box at the bottom
Again, my stupid screenshot doesn't contain helpful text. But, I realised that when using the menu, the description box is filled with text right away and then doesn't need to be hidden. I'd rather have a little tutorial text in it when opening which will quickly be replaced by whatever information is needed.

Restructure everything around contents
Zapper made a compelling argument that more columns / dynamic columns are bad. I'd rather have his 'Quick Pick Mini Menu'.

P.S.: Use E now. R and T are broken, I know that! It's because I refactored the code and made parameter order better.
Attachment: Interaction_Menu_Test.ocs (302k)
Reply
Parent - - By Maikel Date 2018-03-31 07:44 Edited 2018-03-31 07:49
I am very happy with this iteration. Did not like two things yet:

1) The side tabs really need to be bigger for my taste and to be able to click them fast. Maybe if you choose the option with more texts/headers the headers can be inside the side tab frame and the frame can be twice as big. Then you can choose between bigger and more information and minimal and more visibility.

2) The side tabs need a hovering highlight color change so that you can be sure that you clicked them.

3) This bug still exists.
Parent - - By Clonkonaut Date 2018-03-31 09:49
The tabs with captions are quite spacious in fact. They are 4em x 3em (in the old menu it's 4x4). I think you just think they're smaller because the hover highlight is missing (a known bug and one I said not to nit-pick :( ). You can click the text / caption.
Reply
Parent - - By Maikel Date 2018-03-31 10:12
I felt we are getting near the nit-picking phase already! And it is not so much nit-picking because it affects the feel of the menu a lot for me. Also I don't see a clean way to implement hovering feedback if the text is not inside the tab structure.
Parent - By Clonkonaut Date 2018-03-31 10:16
I'll see to fixing that highlight and then we can discuss how it should be done!
Reply
Parent - - By Clonkonaut Date 2018-04-07 16:53
Feedback came to a relative stop here. Do people like this then? Shall I commence and implement it?
Reply
Parent - - By ala [de] Date 2018-04-07 18:46
It is an improvement to the current screen-blocking menu for sure, since you can see your Clonk. But the issue of being restricted by the menu in a fast paced situation, like a battle will remain for sure.

For a permanent suggestion:
How about using a slim version of the menu, that would not give you any of the additional information, but just the content of the container (so also not your own content, you can see this in your inventory). There than could be a '+ button', which would enlarge the menu and display the full information, and would create your current menu with multiple containers, descriptions, pipes and such.
Parent - - By Sven2 [us] Date 2018-04-07 19:10
I think a huge improvement would be keyboard controls. Things like quickly taking stuff out of a container should work from muscle memory just like in CR.

Then you can use the collapsed view of the menu and should be fine.
Parent - - By Clonkonaut Date 2018-04-07 19:20
Lack of GUI keyboard controls is, imho, the biggest issue with gameplay we currently have. I would love any person who took up this task.
I tried once but working with the engine and C++ is, for me, excruciatingly slow and frustrating as I am a beginner in C++, the engine's code is very confusing and mostly not well documented and I don't know how to properly utilise debug operations.
Reply
Parent - - By Caesar [jp] Date 2018-04-08 03:20
Hm, what do you need to do in the engine for that, what is missing? You should be able to define new key combinations just fine from the PlayerControls.txt.
Parent - - By Clonkonaut Date 2018-04-08 10:15 Edited 2018-04-08 10:19
Yes, but no defined controls will cause selection in a menu. There are of course already menu controls defined (e.g. you can control dialogues, i.e. CustomMessage, just fine with keyboard or the old CR menus, created with CreateMenu).

So either the scripted GUIs internally would process these controls (MenuLeft/Right/Up/Down/OK/Cancel, maybe new ones) or expose more information to scripts to emulate controls. Right now, what one could do, is to script Left and Right controls (using GuiAction_SetTag to show a fake selection cursor but it would battle with the moving mouse cursor). In a list, like the Inventory list, I can remember in my script how many entries there are and select the next ID. I would then have to remember the GuiAction_Call parameters and call those via script. But that is about as far as the script can do.

First of all, I would have to save a good chunk of information of the created menu in script (which is against the idea that scripted GUIs are not synced via network - if I save all the information in a variable anyway, nothing is gained).

Then, I cannot get needed information about the menu. For Up and Down controls, I'd have to know what elements are in a row above or below (see attached screenshot for an example; the inventory uses GUI_TightGridLayout and automatically arranges the menu entries in two rows). I cannot redo the math behind this in script as I can neither convert the percentage nor 'em' values the GUI is constructed from in pixels. And again, I would need to save all the information in a network-syncing way.

So, in conclusion, it is neither viable nor a good idea to script menu controls right now. ;)
Reply
Parent - By Caesar [jp] Date 2018-04-08 15:36
Meh, I should have thought of that without making you type so much, sorry. Since I already messed with keyboard input (*sigh*) a bit in the recent past, I'll have a look how difficult this might be.
Parent - By Clonkonaut [de] Date 2018-04-08 10:39
Maybe to make myself clear: when I say 'lack of keyboard controls' in here, I refer to menus opened with GuiOpen(). Like the interaction menu.
Reply
Parent - - By Clonkonaut Date 2018-04-07 19:16
Even with the transparent menu settings? Keep in mind that my screenshot only shows the obaque version of the menu. Did you test it? ;)

As to your suggestion: even the old menu came with a minimize button that did exactly what you suggest here (see screenshots). But since this suggestion came up time and time again, I presume no one ever used / found it?
Reply
Parent - By ala [de] Date 2018-04-07 20:24
Wow, really we already have that :D? .. And I keep dying the whole time while browsing chests..

>Even with the transparent menu settings? Keep in mind that my screenshot only shows the obaque version of the menu. Did you test it? ;)


No sorry, no testing so far, didn't play much recently :|
Still, even with some transparent elements, it probably still distracts to some degree from approaching enemies.
Parent - By Maikel Date 2018-04-08 08:12
Yes, I don't know what this exactly means, but the last iteration was the best so far.
Up Topic Development / Developer's Corner / Experiment: Interaction Menu
1 2 Previous Next

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill