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.
* 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).
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.
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 :)
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.
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.
>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.
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).
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.
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).
New players would still be able to use the interaction menu.
Along the lines of: Easy to learn, hard to master.
Second picture is a new suggestion.
- 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 ;-))
> 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!
> 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.
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.
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.
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.
Then you can use the collapsed view of the menu and should be fine.
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.
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. ;)
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?
>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.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill