Not logged inOpenClonk Forum
Up Topic Development / Developer's Corner / Experiment: Interaction Menu
1 2 Previous Next
Parent - By Marky [de] Date 2018-04-08 19:18
Looks good. Also, it would be really cool if the tabbed menu could be implemented as a customizable menu style simply.
Parent - - By Flinti Date 2018-07-12 03:12
I think that this iteration definitely improves the interaction menu. Some suggestions:

- I do not like the position of the container names, I just get confused whether they are below or above the corresponding icon. Imho the names should be contained inside the borders, to the left or right of the icon
- The headings ("Inventory", "Production", ...) should be more obvious (There is no way of changing font weight, is there?). Maybe one could use borders for structuring this (see the bad mockup just below)



Another thing I'd like to mention is the way it is (and used to be like that in the past) shown that a particular item in the inventory has an inventory itself. I think just showing a chest without any visual indication that the chest is not an actual item is quite a bad solution, it even looks exactly like a chest, not even grayed out or something like that. A player not used to that just assumes the chest to be an actual item. I suggest indicating that by using borders to visually seperate the items. One could even use a grayed out version of the icon of a chest as a background for the item's inventory slot (even better, one could design borders that make the item inside them look like it were put into an actual frame).

Parent - By Clonkonaut Date 2018-07-12 12:37
Good suggestions. I'll see what I can do.
I am somewhat limited by what the GUIs can do, the fancy border stuff is hard to achieve.
Reply
Parent - By Clonkonaut Date 2018-10-11 15:02
Just a heads-up:
I am working again on this!
Reply
- - By Maikel Date 2018-03-31 07:49
Maybe we can also come up with some logical ordering for the side tabs. At the moment things do not make much sense at all, i.e. basements being not completely at the bottom. I think this also an important part of the menu. Suggestions we can test:

* If the clonk holds a vehicle. not the clonk is the first tab on the left but that vehicle, the selected tab on the right is a structure (to unload into) the clonk itself or surroundings. (This also needs that if the clonk holds a vehicle it can always interact with it, c.f. bounding box overlap issues).

* Basements and other stuff which can only be repaired are always last in the list.

* Buildings are always before vehicles, because you typically can only stand in front of one and when you do you typically want to interact with them.
Parent - - By Clonkonaut Date 2018-03-31 09:54
The current order is by reverse Plane and cursor always on top. Just a side note.
Reply
Parent - By Zapper [de] Date 2018-03-31 11:06
Yeah, that's pretty basic. Even the interaction selection (space) has a more sophisticated behavior. So I guess it's very sensible to make that ordering better. Theoretically, even the interaction-selection-order might be better than what we have now
- - By Clonkonaut Date 2018-10-12 15:19
More changes, some more settings and things.

Different settings can be seen here: https://imgur.com/a/Ws8yIOS

There are some quirks, mainly because it's not really implemented in Objects but through appendto etc.

I also did some alterations to the contents, production and hammer menu.

Should I transfer it to Objects?
Attachment: Interaction_Menu_Test.ocs (472k)
Reply
Parent - - By Zapper [de] Date 2018-10-12 15:45
From the images, I would like the transparency of the background from "Transparent" in combination with the opacity of the sub menus of the "Standard style". AKA the transparent part in "Half transparent" could get a little more transparent.
What do the buttons on the right side do? Especially the mercedes star?
Parent - - By Clonkonaut Date 2018-10-12 15:58 Edited 2018-10-12 16:00
Those are the settings buttons, to change the different styles. So we don't actually have to decide on one style ;)
(settings are in player extra data)
Reply
Parent - - By Newton [de] Date 2018-10-14 23:15
How the menu looks shouldn't be up to each individual player, and if at all, it shouldn't be customizable ingame but in the game options
Parent - - By Clonkonaut Date 2018-10-15 07:14

> How the menu looks shouldn't be up to each individual player


Customisable UI is a highly debated topic amongst gamers and game designers; so why shouldn't it be up to the player? It comes down to personal preference and what individual people can perceive with a glance (which is different from person to person).
This is most definitely not a fully moddable UI that MMORPGs tend to use. I kept the options to a small number of easily distinguishable styles. Especially something like 'Menu Transparency' is a common option (citation possible if needed).
Why would say that e.g. Font Size is a valid customisation (or maybe no customisation at all?) as opposed to this? It also affects the visuals of the menu (quite substantially in OC because the menus scale with the size).

> it shouldn't be customizable ingame but in the game options


That is a problem indeed but a problem of how Clonk always managed options. The menus should most definitely not be customisable from a place where you can't immediately test the looks. Having an options page with UI options and only be able to see the difference after you've started a scenario would be horrible. And ingame, you can't access the options again and have to stop playing. This is a problem with many more options (like volume controls). To change this, a revision of the options in the engine is necessary in general. Also additional script interfaces, since the ingame menus are all done via script.
Reply
Parent - By Newton [de] Date 2018-10-15 07:49
Well of course it is just my opinion. It appears menu transparency (only) came up because the menu blocks screen "real estate" ;-) - my statement came from the notion that effort should rather be invested how to better use the space so that menu opacity is perhaps not even necessary beyond cosmetics - rather than adjusting how much opacity is still okay for the user.

Font size customization is necessary when the text doesn't automatically scale with the display size (but with the resolution, which may be unwanted.
Parent - By Luchs Date 2018-10-12 18:10

>Should I transfer it to Objects?


Yes! I think there was already consensus that this is going in the right direction, and having it in the snapshots is good for proper testing.
Parent - - By Newton [de] Date 2018-10-14 23:47 Edited 2018-10-15 00:03
Hmm, the menu looks still really cluttered in my opinion.

- There is so much blank space that overlays the possibly very important information of what's going on in the game right now. Idea: the menu could grow in size by the content that needs to be displayed. If there really is so much that it would/should cover the whole screen, it could still start small and optionally expand. (Like a "bottom sheet" in Android) But all in all, I in my opinion the menu should never obscure more than half of the screen (and the clonk is centered in the free half)

- having the name plus icon of the container on the tab but the name of the container on the first line of the menu as well seems duplicate. Couldn't the tabs be moved to the top (also this is a more standard location for tabs) and maybe made more prominent? Then that title could be removed

- Imo there is to much usage of shadows, different colours per row and borders at the same time. I'd reduce that to just colours and maybe spacing between the rows (instead of borders).

- Also, I wonder if the titles for the rows are really necessary. "Damage: not damaged" certainly also reads quite verbose. That the above is an inventory seems also self evident. Same with these progress bars. I understand this with the damaged, but why not just show the text "not damaged" on the progress bar?
Also, i have never seen a progress bar for how full an inventory is, the 3/5 text is much more helpful there. Or, why not do it like many other games do and show the slots? Then it is absolutely evident that it is an inventory and also how much more space is left.

Edit
Regarding the box at the bottom, isn't this something that could best be displayed (and often is in other games) as some kind of tooltip?
Parent - By Clonkonaut Date 2018-10-15 08:05 Edited 2018-10-15 08:21
Disclaimer at the beginning: Many of my answers will include the reason: 'because scripted GUI cannot really do that'. I am currently limited by what is possible with these and what not. Every other feature would need more changes in the engine which I am not capable of doing.

> There is so much blank space that overlays the possibly very important information of what's going on in the game right now. Idea: the menu could grow in size by the content that needs to be displayed.


Yes, that would be nice. I tested around with something like it but gave it up. The reason is: The GUI cannot really do that.
I can have a a variable height but cannot really include a maximum height and have elements below that variable element. I can have one element with a variable height but cannot define a maximum height in addition. So I need to nest it into another (invisible) element with a fixed height. This means that the invisible element will still occupy the screen area and other elements (the description box) cannot dynamically occupy that area.
The next problem is:
The big elements are measured in relative units (screen area percentage), the small elements (Inventory, Production, Damage) in a fixed unit (em). I cannot convert one into the other, so I don't how much space a '2em element' will occupy on the screen. So I cannot calculate the menu height and position other element accordingly. And because pixel-perfect positioning is impossible (px is not a unit the GUI knows), I couldn't include spacers for frames, I would have to give it a safety measure in em (I currently do that, there is a right margin in the two big menus of 0.25em, otherwise they'll partially overlap the frame).

> But all in all, I in my opinion the menu should never obscure more than half of the screen (and the clonk is centered in the free half)


I can't control the camera in any way but yes, that would be nice. Since it's impossible, it can only work with what I have - I can't tell where the clonk is on the screen and can't position the camera. Regarding the height of the menu: Also possible but I would include a lot more scrolling because even the most simple information of most buildings (Inventory, Production, Damage - even worse with buildings the Foundry which has all the pipe control elements) exceed half the screen with 1080p and standard font size.

> having the name plus icon of the container on the tab but the name of the container on the first line of the menu as well seems duplicate.


It's possible to filter that tab but it's only just one tab.

> Couldn't the tabs be moved to the top


Yes and no. First of all, the height of the menu is the most critical problem about it and moving tabs to the top means a higher menu. Then there is the problem of having too many tabs. Vertical scrolling is very inconvenient with the GUI (a 'cannot really do that' argument here). There are problems with scrollbars not being displayed properly (clipping would occur), so many times you probably wouldn't be aware that you can scroll vertically). Mouse wheel scrolling does not work vertically (I think), so you'd have to drag the scrollbar. And there is more tab space in height than in width, so less tabs visible.

> and maybe made more prominent?


Bigger? Opaque? The icons of everything would have to be more self-explanatory (like Surrounding). But yes, the names can be left out (like it is when you disable Headings using the settings button - can be seen in the example screenshots I did).

> Imo there is to much usage of shadows


Can you be more specific? The GUI can't do shadows or fancy effects, so I don't really know what you mean.

> different colours per row


Yeah, I agree. But since these elements were made by other people (Zapper and Maikel, I think?) I didn't really modify these. The menu elements are generated by any individual object and are customisable via script. My compromise was the 'Grey' settings buttons to filter out the colours. Spacing is a problem because it adds more height.

> Also, I wonder if the titles for the rows are really necessary.


Because the entries are customisable, there are more than just the standardised entries of Inventory, Production and Damage and the meaning of a sub-element isn't necessarily obvious at first glance. But I included the settings button for that reason because experienced users do not need the explanation.

> Also, i have never seen a progress bar for how full an inventory is


Yeah. I kept it from the previous version that someone else (Zapper?) did but made it less big. You can always compare everything to the top screenshot in this thread to see the version before I ever began working. And yes, a progress bar is uncommon here.

> Or, why not do it like many other games do and show the slots?


Because that's a real problem. With the clonk, it's fine (5 slots). But even then, the inventory space of a clonk is fully customisable and having to show many slots would look weird. Then take the chest in my examples. It has 50 slots! Always displaying 50 slots would look extremely bad. Many containers are also limitless (most of the buildings), so 'slots' don't fit there.
Slots also give the illusion of having drag&drop support. I don't want to give that illusion because the script GUI can't do dnd. I would love to have drag&drop support though!

> Regarding the box at the bottom, isn't this something that could best be displayed (and often is in other games) as some kind of tooltip?


Well, yes! But, script GUI can't really do that. I can not show the box as long as it's empty. I tested that. But it's a useless effort because the box shows something in 80/90% of all time using the menu. Most elements have a hover tooltip (Inventory shows a description, Production shows that + building material, Damage is a tooltip etc.). The tooltips of the script GUI are unreliable and not very organised (can't be customised, so it's just a text). Very bad for something like production material dynamically showing what is missing or similar. I can't display a windows where the cursor is at (a typical tooltip position) because I can't get the screen coordinates of the cursor (first problem) and I can't use pixels as a unit of positioning (or sizing) for the GUI anyway (second problem). So the 'tooltip' needs a fixed position (like it is now) and would be displayed at almost all time (like it is now).

Edit: In summary: you do have valid points but I am working under very harsh constraints.
Reply
Parent - By Zapper [de] Date 2018-10-15 08:28
Random order:

>Idea: the menu could grow in size by the content that needs to be displayed.


The left and right part could shrink down dynamically (that would show you the same stuff as the transparent versions), but I don't think it would be helpful if the description box (or generally, large parts of the menu) jumped around randomly. In Clonk your environment is not static

>(and the clonk is centered in the free half)


That would probably at least break when we have splitscreen back - and I also think it's not a wise choice in general (because it makes the menu interactions slower (more scrolling))

>Couldn't the tabs be moved to the top (also this is a more standard location for tabs)


That doesn't work as well with the mouse wheel and there is a lot less space for horizontal text

>- Imo there is to much usage of shadows, different colours per row and borders at the same time. I'd reduce that to just colours and maybe spacing between the rows (instead of borders).


Yeah, true. I think I made the background of the title a darker tone to make the text have higher contrast

>"Damage: not damaged" certainly also reads quite verbose.


I think I had the text overlay the progress bar in the first iteration - but the row will be 2em height anyway (because of the button/icon on the left), so it wouldn't save space and I decided against it

>Or, why not do it like many other games do and show the slots?


That wouldn't work with a lorry (or generally, any other container than a Clonk). And most of the time it's not 100% clear whether 40xArrow occupies one slot or two.

>Regarding the box at the bottom, isn't this something that could best be displayed (and often is in other games) as some kind of tooltip?


Yeah, that would be a rather huge tooltip though.
I am kind of a fan of how additional info is always available (even forcefully) for new players in Clonk, because the game is just so confusing. But it might be wort a try optionally being able to hide the box by default and enable it e.g. by Alt+Clicking on an item or pressing a key or something..
- By Clonkonaut Date 2018-10-16 10:12
Btw, I transferred this to the repository.
Reply
Up Topic Development / Developer's Corner / Experiment: Interaction Menu
1 2 Previous Next

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill