I just committed a redesign for the ingame HUD I've been working on.Here I want to give you all a quick overview over what has been changed and why. I also want to receive your feedback on this!
Inventory
I switched the position from bottom to top. It felt more visible like this. Before, I had to double check whether or not a certain inventory slot was selected. This leaves the bottom of the screen completely free. Also, on the top, inventory slots more often have a bright background (sky).
Action bar
As you can see on the screenshot, I added an icon next to the crew portraits showing the first available interaction (~what happens if I hit space). For testing purposes, I added the key name that was assigned to CON_Interact. We might want to add an option or similar that disables those helps for experienced players. I also thought about changing the inventory slot numbers to the key names associated. But that might look stupid if the key name was too long.
Please give me feedback about the position of this icon. I work with 1080p + 16pt font size and it looks good to me.
The icon will show a green plus symbol (as you can see on the screenshot) if there is more than one interaction availavle. To get to these, you have to hold down the interaction key like it was before.
Crew portraits
I limited these to 2 clonks. None of our current scenarios features more than 2 clonks and Zapper is even implementing relaunches into many scenarios, so that they might be played with just one clonk at a time. Back when we first thought about the HUD, we had CR in mind where it was an advantage to have several clonks. In OC, this isn't the case anymore.
The HUD shows the currently select clonk and the next one in line.
I added 'crew warnings' (as seen on the screenshot, the third clonks loses breath) to help you see what's going on. But I don't think we need to clutter the top of the screen with several portraits and so on. You can the click the green plus symbol next to your second clonk to get a small clonk selection menu:
This is inconsistent with the action icon, I know. I thought about making this a more prominent button. I also thought about showing the menu when the next clonk control ('R' by default) is held down.
Known bugs
- The (verbose) interaction bar does not react to hotkey presses. Right now, you have to select the specific interaction button via mouse click
- Clicking the crew plus sign also forwards a mouse clonk to the currently selected clonk
- I haven't checked all scenarios yet, in case any dialogues / new HUD elements look stupid now or whatever
- The health bar disappears on synchronisation. Haven't figured out why!
- The inventory bar is pretty much limited to 5 slots now. That is okay for us but maybe not for third party delevelopers. I thought about arranging the inventory in two rows if there are more than 5 slots. Haven't done it yet since the action icon's position isn't fixed. 10 inventory slots should be maximum nonetheless.
![[de]](/mwf/flags/de.png "Germany")
Some general comments:* Have you tried putting the crew warnings to the very left on the screen (below the main portrait)? I know that they are aligned with the second portrait now, but it feels like they are floating around somewhere without reference point.
* Now (and before?) we have white text against a potentially very bright background. Maybe it would make sense to darken the background of the portraits/interaction info and pull the text into the rectangle.
* That leads me to the next point: we have rectangles with a bright background and circles with a dark background. It looks like the UI was not designed as a whole but in parts. We should probably make at least the background icons (border-thickness, background color) of all the UI items the same.
* The HP bar could imo be brighter.
* I like showing the interaction key above the lorry.
>- The (verbose) interaction bar does not react to hotkey presses. Right now, you have to select the specific interaction button via mouse click
Did the bug also exist before? I thought I had fixed space+hotkey back then.
>- Clicking the crew plus sign also forwards a mouse clonk to the currently selected clonk
That might be require an engine change (currently (and before) the Clonk is just disabled when a large menu is shown). What would be the expected behavior? Catching all clicks or catching only clicks that lead to actions?
> Have you tried putting the crew warnings to the very left on the screen (below the main portrait)? I know that they are aligned with the second portrait now, but it feels like they are floating around somewhere without reference point.
That might fit, yeah. I haven't made a fully fledged interface but in theory you can put as many bars below the (main) portrait as you wish. But it's no problem to put the warnings below that.
> Now (and before?) we have white text against a potentially very bright background. Maybe it would make sense to darken the background of the portraits/interaction info and pull the text into the rectangle.
Could you elaborate? :o
> That leads me to the next point:
Yes, you are right!
> The HP bar could imo be brighter.
Okay. But it's the same colour than before!
> Did the bug also exist before? I thought I had fixed space+hotkey back then.
I haven't checked. Could very well be that I am responsible.
> What would be the expected behavior? Catching all clicks or catching only clicks that lead to actions?
For me the following would do: Checking the return value of the actions and if its true, catch all clicks.
>Could you elaborate? :o
The text "Grab Lorry" is in front of the sky. The text "Homunk" is in front of the portrait inside the rectangle (and thus has a darker background). I'd say the text should also be inside the rectangle (thus, have a background) but maybe not in front of the symbol(?). So then the symbol could be made smaller?
>Checking the return value of the actions and if its true, catch all clicks.
Then the player would trigger an ingame action by missing and clicking just next to the button. But catching all actions would mean that also the invisible container enclosing the buttons would catch stuff. Mhmhmh
> Then the player would trigger an ingame action by missing and clicking just next to the button.
True. The button should get a hover state.
I thought this overall behaviour was already in the game though! In the previous HUD, mouse left release events were caught by the HUD (you could hold a mouse button to e.g. draw a bow and if you released the button while hovering a crew portrait, the release event didn't fire).
> The text "Grab Lorry" is in front of the sky. The text "Homunk" is in front of the portrait inside the rectangle
Problem is that "Grab Lorry" can also be way more text. After grabbing the lorry it says "Let go of\nLorry". I can't be sure that the interaction help text always fits the rectangle.
![[us]](/mwf/flags/us.png "United States")
> * Now (and before?) we have white text against a potentially very bright background. Maybe it would make sense to darken the background of the portraits/interaction info and pull the text into the rectangle.
Our fonts have always been a big trouble. I think it's just not very well-design for display at small sizes. Maybe we can improve the situation by modifying shadow calculation to create a black border around fonts when displayed in a bright color. And also adjust player color modulations to never go below e.g. 50% brightness (players with black player color have unreadable text in many situations)
>The inventory bar is pretty much limited to 5 slots now. That is okay for us but maybe not for third party delevelopers. I thought about arranging the inventory in two rows if there are more than 5 slots. Haven't done it yet since the action icon's position isn't fixed. 10 inventory slots should be maximum nonetheless.
I certainly want to be able to have/define more inventory slots, but not more than 10. It would be cool if one could easily rearrange the position and graphics of the slots without having to script a whole new GUI.
Are these inventory slots positioned at the center or does it only look like it? I'd just wondered if there's finally a solution to position things at mid-screen.
Yes, centering UI elements is possible with the new menu system.
\o/
How is this achieved? Are there any flags to be set to render relatively to the center or are screen coords in-"script" avaiblable?
How is this achieved? Are there any flags to be set to render relatively to the center or are screen coords in-"script" avaiblable?
They aren't regular objects. The engine just got a way to define interface elements.
I think... maybe I were in favour of removing the feature of having multiple crew members in open clonk. Not because it is not a good an necessary feature in clonk rage, simply because I think it is not used in open clonk the way it is used in clonk rage and only complicates things. We already took many steps in this direction actually
1. we already removed the training of physicals (climbing, energy etc), removing the necessity to store much more information than the name of each clonk in the OCP
2. in every scenario where it matters, a relaunch logic replaces the game feature of havin a "stash of reserve clonks"
3. we do not have, as clonk rage did, a RTS-like mouse control where you could send your clonks off to do this and that simultaniously
4. likewise, we do not have these automations anymore that you can activate "collect wood" in the sawmill and the clonk would chop the nearby forest down and put it into the sawmill
5. we do not have "safe places" (=houses with doors) for the player to store his clonks anymore, which was a deliberate design decision
6. one can not control all his clonks at once (double-w, *ding*, remember?) anymore to do things like transport several things at once. Instead a single clonk can carry more.
7. we removed "long actions" that bind a clonk to one place like waiting for a castle to be built, waiting for stuff to be smelted, an airship to be constructed, a forest to be chopped down or a melee-fight to finish (well, if anyone ever used that)
8. clonks are more agile now and much less prone to get stuck somewhere, creating the necessity for another to free him. This already started with clonk rage(?) where all clonks gained the ability to climb and hangle from the beginning on and unstuck-checks were introduced
9. arena fights (e.g. cauldron) prevail much over classical melees (e.g. clepal) in open clonk. In the latter it can still make some sense to have a clonk at another location
If support for multiple clonks were to be dropped completely, I think it would simplify a lot of things. Or, as the lite version: Do not offer keys to change the crew member and do not show this in the HUD. So something like a "camera view" would still be possible (e.g. an item "telescope")
I do fully agree. The way OC developed we focused more on a 'single clonk' playing style. Especially the no safe house mechanic facilitated this. I do hate that first thing in the game is to find a relatively safe spot for your excess clonks.Not only would we free HUD space but controls (gamepad buttons!) and a lot of game menu stuff (the area where you can manage your crew). The one clonk could always be named after the player.
Internally, we might keep the support for projects like the Classic Clonk from Marky.
Concerning multiple clonks, you are right that it is currently rarely used. I already changed the beginner missions to single clonks and respawn at the nearest flagpole (Free+unlimited in the newbie missions; I believe Maikel has put a cost on it in the worlds).It is also true that the "safety clonk" mechanism is not that useful in OC.
However, this concerns newbie missions and newbie gameplay only. There are still a lot of more advanced strategies both for settlement and for melee:
* Disconnected settlement bases. E.g.: A home base with power production and a long elevator shaft down into the volcano. You keep one clonk in the home base and another goes down to mine. The clonk in the base repairs wind generator after lightning strikes, puts fresh coal into the power plant, feeds the wipfs to continue running the treadmills, etc. Without the extra clonk, when power collapses, the clonk down in the mine is just lost.
* Another example: Having one base for production and distant mining connected by e.g. trains or cable lorries. You want one clonk at the mining base, filling the lorries, then send them off to the home base where products are refined. But the products can travel while you continue mining and you don't want to twiddle thumbs sitting on that cable car all the time.
* Melees: Clonks for strategic protection. Classic example: A clonk with a bow stands on top of the castle and you switch to that clonk if an attacker comes.
* Melees: Clonks for attack and defend. If you play 1vs1 with bases, you attack and the enemy counterattacks, there is no way to defend your base (which effectively reduces most melees to 1on1 combat). Even if you play 2v2, you would strictly need one attacker and one defender. Otherwise, your base is defenseless once you start a joined attack. Allowing multiple clonks gives you more options.
* Melees: Building outposts. We do not have good buildings for this yet, but I'm sure they will come. Having an extra clonk at an outpost is a nice strategical move.
These are all "pro" features and some of them seem far off at the moment, but more complex and strategic scenarios are coming and having the option of multiple clonks adds to the depth of the game. Managing multiple clonks was a defining factor of good players in scenarios like CoFuT in Clonk Rage. We shouldn't remove it just because it's not a newbie feature.
I agree though that having multiple clonks doesn't need that much UI consideration and we don't need to waste too many hotkeys on clonk management. I also think we can change the worlds and give only one starting clonk plus enough gold for a respawn in the normal worlds. Maybe expert worlds such as Acid Gold Mine can have two from the start because you might die before having built a flagpole.
![[gb]](/mwf/flags/gb.png "United Kingdom")
Not news that I am in favour of removing multiple-Clonk scenarios, but just a few notes - wasn't it actually very memorable when your elevator case came down burning and you realised it might be a long climb before you even find out how much of your settlement is left standing? I always enjoyed that quite a bit.
Plus wouldn't a town portal scroll solve a lot of these too? That would especially make it a more meaningful strategic choice in my book. A Clonk left at home basically means an infinitly reusable teleport point.
Plus wouldn't a town portal scroll solve a lot of these too? That would especially make it a more meaningful strategic choice in my book. A Clonk left at home basically means an infinitly reusable teleport point.
I actually miss these 3 a lot:
In Clonk Rage I used around 4 active Clonks most of the time: One in the base, one at the tower opening the gates and defending, one attacker - and if there was time I had one more auto collecting gold from the mine and moving it up.
I don't like how in Openclonk I have to "watch" my clonk chopping wood, or transporting material along a smooth shaft. If I switch to another Clonk, he stops working.
It's true that the features of having several clonks are barely used right now, but that doesn't mean we have to abandon this completely. It would waste a lot of potential and creativity in my opinion. Also think of extensions created by players - they may want this feature to be kept.
>3. we do not have, as clonk rage did, a RTS-like mouse control where you could send your clonks off to do this and that simultaniously
>4. likewise, we do not have these automations anymore that you can activate "collect wood" in the sawmill and the clonk would chop the nearby forest down and put it into the sawmill
>5. we do not have "safe places" (=houses with doors) for the player to store his clonks anymore, which was a deliberate design decision
In Clonk Rage I used around 4 active Clonks most of the time: One in the base, one at the tower opening the gates and defending, one attacker - and if there was time I had one more auto collecting gold from the mine and moving it up.
I don't like how in Openclonk I have to "watch" my clonk chopping wood, or transporting material along a smooth shaft. If I switch to another Clonk, he stops working.
It's true that the features of having several clonks are barely used right now, but that doesn't mean we have to abandon this completely. It would waste a lot of potential and creativity in my opinion. Also think of extensions created by players - they may want this feature to be kept.
Speaking of wasting things, we'd need a lot of work to reimplement all those features again. Crafting such an AI in a game like Clonk isn't an easy task. Even in CR it didn't work very good. As a player, you had to learn the pitfalls of the AI. Literally pitfalls because your clonk could easily walk off a cliff and die.We already have invested a fair amount of work into making these mundane task less mundane. Chopping a tree really isn't that bothersome anymore and usually you don't need to chop a huge forest.
A very simple KI could do the following tasks:
-chop wood on a flat surface
-harvest on a flat surface
-Guard and defend with missile items: Musket / Bow / Spear.
-walk flat surfaces
-use an elevator
Transport objects along a flat surface/elevator, and storing objects in a container.
In CR the command you could do with the mouse frame and strg was the most useful: "Collect all these objects and store them in this lorry"
That's around all the CR KI could do reliably as well.
-chop wood on a flat surface
-harvest on a flat surface
-Guard and defend with missile items: Musket / Bow / Spear.
-walk flat surfaces
-use an elevator
Transport objects along a flat surface/elevator, and storing objects in a container.
In CR the command you could do with the mouse frame and strg was the most useful: "Collect all these objects and store them in this lorry"
That's around all the CR KI could do reliably as well.
It sounds easy, written down like this. But actually, you'd have to put a lot of (programming) effort into finding out what a "flat surface" is and if the area the clonk will work in (what is that?) is such an area.And what happens when the player does not select a flat surface? You get an error message "I can't work here" or similar?
>And what happens when the player does not select a flat surface? You get an error message "I can't work here" or similar?
In my mind the clonk just stops.
If we at some point decide to build this we can concept the details. For now we have enough work :). Well, but just copying the CR behavior would give back the possibilities I mentioned: Of course some Clonks would die or fall down cliffs if they are not watched from time to time, this would probably not be very newbie friendly. Still the commands made controlling multiple clonks possible. If there are no commands their use gets reduced to equipment and position (which is still enough to justify that we keep some support to my taste).
> If there are no commands their use gets reduced to equipment and position
A "Defend" command that is using equipped weapons to defend a position wouldn't be hard to do because we already have the EnemyAI scripting. It might even be automatic for all clonks (so you just buy and equip them and place them on your castle). And I think it would greatly improve strategy in base melee.
Yes, those were cool things, I like them in CR too. I did not mean to say that we ditched the RTS-like mouse because it was a bad feature. The mouse in Open Clonk is simply used in a different way than it was in CR, a way that is oriented more at FPS. The whole gameplay is (more) focused on one clonk. That enabled us to do a lot of cool and convenient things. Others, like the whole multi-clonk controls were not respected.
Yes, OC is different in this regard - and also the recent Clonk Rage years were mostly just one clonk and having relaunches. Still, since Clonk development has always been kept flexible I would grieve about support being completely abandoned. It was also pretty unique to Clonk, no other game I know of has a similar approach.
At least keep the possibility of having multiple crew members in the engine. For my "classics" project I actually need this. Doing it from the GUI would be annoying, but acceptable, as I have to overwrite most of the functions anyway.
In my scenario Inside the Glacier it is actually important to have a second clonk. A clonk can freeze to ice and can't move by itself anymore. With a secon clonk, you can start a rescue mission and carry it to a warm place where the clonk defrosts.
Also in a case, where your clonk is trapped somewhere, you could rescue him with a second clonk and a loam bridge for example.
I tried to take clonkonauts approach and condense the elements some more while keeping I mind to make the entire HUD more readable, less hectic and more distinguishable from the game world. Also I added in a way to show the inventory of another clonk because that is what makes individual clonks really special in OpenClonk.I avoided using heavy graphical elements like sprites or text shadows.
That looks surprisingly convincing. What about the portaits? I guess you removed the 3D preview for a reason?
No, not at all. This is just a photoshop mockup and I didnt want to start blender just to get a few 3D portraits of Clonks.But now that you got me started on this: I would probably just have the clonks "idle" animation and a closeup on the face instead of showing a whole clonk running and jumping around in the HUD. I can see it running around on the screen so no need to add distracting animations up there. The face (and thus, the skin) could help identify the clonk quickly though.
AFAIK this is not possible. You cannot render only parts of a model and crop the rest away.
It wouldn't be very hard to add an option where the engine renders only a certain submesh. But then the Clonk mesh would need to be split into two submeshes, one for the head and one for the rest. Alternatively, the head could be duplicated in a separate GraphicsHead.mesh and one could use SetGraphics to show that one.
That would be great. I also would prefer to have the rendered heads as portraits in dialogues. I ended up making 2D graphics as copies for these portraits because I couldn't find a way to render only the head.Alternatively, there could just be a second mesh that contains only the head?
The solution with the submesh would allow to actually animate the head in the HUD like currently the whole clonk is animated. But I guess we would not want that anyway for either the HUD or in dialogs.
Animated heads in dialogues would be very cool (even just moving a bit, blinking, etc.).
True. And if you don't need to synchronize those animations with an ingame NPC mesh it still wouldn't require engine changes.
In general, as I said yesterday: I'm in favour of clear borders, clear fontfaces (no shadows! Maybe no Endeavour?) and making it clear what is the "HUD".Where would you fit additional bars? (breath, magic, ammunition?)
For breath, I'd probably just split the health bar horitontally as long as the clonk is under water as the information is very short-lived.For other persistent bars, my real answer would be "I don't care" because we dont have magic or ammunition. But if it was me designing a new pack which needs some of those, I'd probably extend the clonk-hud-display downwards and put thinner bars unter the whole thing (Or I'd make a less neutral, more fantasy- /sci-fi-themed HUD altogether).
Yes, I definitely "took away" the graphical or art aspects of the HUD. It was my intention to make a clear cut between the game world and the HUD. There is a lot of stuff going on in the game world, so I think it's ok for the default HUD to step back a bit.
I just find it funny/interesting that this new boxy style now so in fashion in new OSs is so very similar to programmer art.And also very similar to the HUD and GUI style of OpenClonk 2-3 iirc. Before Ringwaul made those paper-y graphics, they also were black half transparent boxes.
I like the clarity (much of it being just due to better fonts), but miss the playful design of the old HUD :(How would that look on a night sky background? (where the background would have almost the same color as the HUD elements)
Good point. I'll test it later, probably. in the end, there will always be the possibility that some scenario has a background that works really bad with the gui color scheme, but I think it should look good on black because thats our shadow color when underground as well.
Quick mock to show it on black background. I think the flat shapes could be a little bit brighter so that there is a little bit more contrast.
Maybe you should place the numbers on the bottom border for better UI Alignement to the edge of the game.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
