![[de]](/mwf/flags/de.png "Germany")
This is quite late for an OCM write-up but before I was busy with my travel preparations, work and so on.First of all, to all who could join the meeting, thank you for coming! I enjoyed it very much. Too bad the weather was so bad the whole week, I would have liked to go kajaking with you. Well, there is always a next time.
Some interesting topics were discussed on the OCM. I did not follow all the discussions but here are those I remember.
Keyboard-layout independent controls
Ker's implementation of keyboard-layout independent controls (scancode branch) was not fully working on Windows.
On the OCM, it has been tested, fixed and merged into master. Hooray!
yay! if everyone is happy with the current state, my next target is to remove the dvorak stuff. babysteps towards a bigger goal :D
Debugrec commandline parameter
Debugging the eternal problem of network play between mac, windows and linux has been made quite a bit easier now. Mortimer changed debugrec to be a commandline parameter now and not a compiler option. So turning on debugrec is possible without recompiling the engine.
![[gb]](/mwf/flags/gb.png "United Kingdom")
Water
This is a topic Matthi brought up while we were playing the ruby cave scenario where all the rubies are in the middle of an underground lake. Currently, water is an obstacle similar to acid but less bad: One can dive a few seconds but after that it will drain your hp fast. Dealing with water is always the same. Build a reservoir and pump the water away, the same tactic like with other fluids. Water could be more than that if there were more ways to overcome or work in water.
Some suggestions:
• Make the clonk able to hold his breath much longer: Don't die by getting stuck on some edge, instead the breath is there to remind the player that he can not stay forever. This is something we already did on the OCM. We changed it from 7 to 20 seconds.
• Make the clonk able to stand on the ground in water with special equipment like for example the divers helmet (already modelled). This will enable him a whole new range of underwater operations as he will be able to use tools then
• Add tools, vehicles and/or buildings that open more possibilities to interact in water. Some ideas:
• Diving bell (a structure like the elevator)
• Make the pump pump air bubbles to the drain pipe if the source is free which will restore some of the the clonk's breath (perhaps enable him to stay underwater forever in combination with the divers helmet?)
![[nl]](/mwf/flags/nl.png "Netherlands")
> • Make the pump pump air bubbles to the drain pipe if the source is free which will restore some of the the clonk's breath (perhaps enable him to stay underwater forever in combination with the divers helmet?)
I like that, but the range of the pipe should not be endless.
And of course for melees, an enemy must have the opportunity to cut the pipe somehow, otherwise underwater camping will be possible.
> • Diving bell (a structure like the elevator)
Why not make a shell or a kind of wrapping, which could be attached to the elevator? Therefore not going for a new building.
> And of course for melees, an enemy must have the opportunity to cut the pipe somehow, otherwise underwater camping will be possible.
What about the obvious choices: destroying the pump and/or the power supply? Someone in deep sea is most likely unable to defend the base.
I don't even see the point in under water camping but whatever ;) say a direct explosion hit on the pipe end will destory it. Anything like a low level attack ("cut the pipe whereever you want using a sword") will make the whole thing useless (and of course it's virtually impossible to script right now since lines do not interact with any object).
>I don't even see the point in under water camping
Let's say someone builds something like the old "Kill the Captain" in a team match. And let's say the pump is very hard to reach, I can easily imagine a good game going bad.
(And apart from that, even if there is absolutely no point, there will be players doing it - for example in a league game, to try and get a "win by patience").
I actually had this once or twice in CR with aquaclonks.
>Anything like a low level attack ("cut the pipe wherever you want using a sword") will make the whole thing useless (and of course it's virtually impossible to script right now since lines do not interact with any object).
Hm, true. Keeping it useful seems more important.
Btw: Power for air is a very unreliable source of breath. If the wind stops, or someone is using the elevator you suddenly don't get air :)?
I implemented bubbles restoring Clonk's breath. Didn't implement pumping of air yet though.
>Bubbles can be breathed in by anything but their creator
So two clonks can exchange breath underwater?
Well, the bubble collection range is below the creation range. So you can collect bubbles, but only upwards. And you cannot collect your own bubbles.
That doesn't seem to work very well. In this position, I get infinite air. ;)
Weird. I thought I made a check that prevents you from collecting your own bubbles. Or did you do tandem breathing with two Clonks?
New old an new items
The jar of winds has a new graphic and is called wind bag (like bag pipe) now. Also, Clonkonaut and Matthias made a new weapon, the grenade launcher which shoots iron bombs. Unfortunately, I think it is not included in any (arena) scenario yet. Who can make some renders of those to show them off here? ;-)
Le big clean up
During the OCM, I converted most textures without transparent areas to high quality JPEGs and converted sound effects that come from a single point to mono along with some other adaptions that made the files smaller without loosing quality. Matthi exported the pump as a mesh model now (before it was a very large PNG with lots of animation phases). And Günther did, in the process of fixing how the background image in the main menu is cropped on different resolutions (it keeps it's aspect ratio now), delete some now unused menu background graphics.
Overall, this saved us more or less 15 MB (unpacked). For comparison, the current release installation file is 40MB.
Yet new controls
Yet another time, the controls are being redesigned. Based on the experiences from playtesting settlement rounds and feedback from the community, Zapper is reworking some aspects of the clonk controls. A few important changes being:
• The clonk can only use one item at the same time ("one hand"), the right mouse button is reserved for something else
• The clonk has now only 5 slots
• You can use the scrollwheel now to cycle through your inventory (Shift+Scrollwheel for zoom)
We playtested the new controls a lot on the OCM, there are still some bugs but overall, the redesign is quite far. But actually, Zapper has a better overview over what has been changed and what he is still about to change. So Zapper, could you elaborate?
>So Zapper, could you elaborate?
You already said the obvious:
- Item slots reduced to five, since we had the impression that the Clonk was able to carry too much and therefore never actually needed lorries etc. One idea was to reduce it even further (to three maybe?) so let's see how 5 works out first.
- Two-hand-control removed. We had the impression that, while adding a lot of interface clutter (who of you actually knew how to select an item into the second hand via keyboard?), it did not really have any benefits for gameplay with the only beneficial situation being shield+sword. You were more likely to just lose your items in your inventory ("on what slot did I put it again?") than use it efficiently. There is now a quick-switch-button ([Q]) as known from f.e. many shooters that switches back to your last-selected inventory slot. That still allows pretty fast shield+sword action while not being so very unintuitive like the two-hand-control in all other cases.
The right mouse button is currently what was [Shift]+[Click] before: throwing the item away as opposed to using it. Let's see how that plays out.
- Cycle through your inventory with the mouse-wheel. With only one hand, this well-known mechanism can be used without having to worry about which hand is cycled and why. Zoom is now on [Shift]+[Mouse-Wheel] since it usually plays a very small role compared to using your inventory - especially if more and more scenarios currently have a zoom-limit and you can't see the whole map anymore anyway.
Now the other points:
- "Lazy reactions". Clicking and holding the mouse-button now executes the action whenever possible. What does that mean?: Imagine you try to start aiming with your bow but are still in the kneel-down-action and therefore can not use any item right now. Currently, the action is lost. You never aim the bow and have to click the button again once standing. In the Controls-branch, the action is executed automatically when you are standing again, if you are still holding down the mouse-button. For scripters, this also reduces effort, since quite a few items had custom checks for re-aiming (shield/bow) if disturbed (by tumble/climbing). This is now handled by the Controls library.
- The action bar now only appears after holding down [Space] for about a second and is then displayed a lot more prominently on the screen. When only tapping [Space], the most fitting action (first on the action bar) is executed. In our test games this was what the player wanted 90% of the cases anyway (grabbing lorry/chest/building) and therefore there is no need with spamming the screen with an ever-changing bar at the bottom of the screen.
- The inventory bar is now displayed on the bottom of the screen, since the action-bar moved and made space ;)
This better reflects the layout analogies between the number keys and the item-slot that the key selects. Also, you don't have to look on the left side of the screen anymore (! which is probably a positive point, I suppose?) since the inventory-bar is now always centered.
- The inventory and object-interaction menus will be merged into one. This is work-in-progress. It should help both simplify the interaction for the user ("how did that work again??") and merge some of the dozens of different menus we have right now.
PS: And I also cleaned up the old Controls-library and split it into about three or four libraries just to be able to work with it.. :)
Are you aware of that inventory refresh bug? (Picture doesn't get removed after object is gone)
I have grabbed all the inventory bugs from the bugtracker and assigned them to me. So if the bug is among them, I am aware :)
Just some short feedback: When I first played controls branch, I thought you had to confirm your selection when scrolling through the inventory, because the slot looked like it was just highlighted and not selected.
Maybe the selected slot should be less brighter and highlighted looking and a bit smaller. (that also prevents blurry object graphics)
Maybe the selected slot should be less brighter and highlighted looking and a bit smaller. (that also prevents blurry object graphics)
I remember a few years ago being attacked on my argument that using 2 items at the same time with the two mouse buttons was not a good idea, and it would become much confusing. I think I suggested to use the right mouse button as a "item special function" button: you could use it for doing different type of attacks with a sword for example (like a much slower but more powerful attack), to switch ammunition type if you are using a gun, or anything that could be useful for the item. You could also use it to trigger the shield while holding the sword if you have a shield in your inventory (not sure about this one since is some kind of exception, but it could be useful).
However already using it for throwing stuff is a much better improvement.
Overall I am happy that you decided to make the switch, i do believe controls are going to be much more natural now!
Ps (nobody will remember me, Im just an old fan of the project still lurking and keeping under my radar from time to time... keep up the work guys, you are amazing!)
However already using it for throwing stuff is a much better improvement.
Overall I am happy that you decided to make the switch, i do believe controls are going to be much more natural now!
Ps (nobody will remember me, Im just an old fan of the project still lurking and keeping under my radar from time to time... keep up the work guys, you are amazing!)
Engine menus
This is definitely worth a blog topic: In his control branch, Zapper implemented engine-supported menus in a similar way than PeterW once suggested in the forum, using proplists to define their layout. This will replace the current HUD, the old tiny engine menus and the circle menus for contents. So what does this mean? This means that interaction in menus and possibly even the HUD will be unsynchronized over network and that scrolling will be possible properly in the menus and what else? Well, ask Zapper.
He already implemented a showcase menu that seemed quite powerful, so I am really looking forward to when it is finished. The contents management turned out to be one of the meaner problems that players have with our settlement implementation so his work there is actually quite important. If you are interested to help, ask him what you could do!
Anyway, Matthi and Zapper debated how the contents, buy and production menus could best be designed for several days and I think they came up with a quite solid concept. Would you tell us about it, Matthi, Zapper?
Does this make a proper game menu on ESC possible? Like in every other game? :)
btw, thank you for writing this up, Newton!
btw, thank you for writing this up, Newton!
>Does this make a proper game menu on ESC possible? Like in every other game? :)
The menus are more or less only a script-interface to layout rectangles (filled with stuff, graphics/text f.e.). If the ESC menu should be scripted, then it would be possible. I am not sure whether that would be a good idea, though :)
PS: And currently you can only have one font-size. Being able to load and scale arbitrary fonts would be extremely helpful for that (Guenther, didn't you say something about the scaling at the OCM?)
For the unsynchronized stuff:Does this mean fast 5 clicks on a production menue will equal 5 items to be produced? Because at the moment it's like you have to click 10 times into the ring menue to make a job for producing 5 items.
Well, yeah, one click should be one action :)If you currently need to click twice for every item, that sounds like a bug
> Guenther, didn't you say something about the scaling at the OCM?
I wanted to replace the various font textures with one huge, mipmapped one. And replace the coordinate system with a more traditional fixed height one instead of the monitor-resolution-dependent one we currently use.
>>If the ESC menu should be scripted, then it would be possible. I am not sure whether that would be a good idea, though :)
Why not?/What would be the other way to do it?
Engine-side (like the menu you get when you start OpenClonk.exe). For example, I am not sure if it would be a good idea to do the savegame-selection in script. *shrug*
This is engine-side, isn't it? In the post by Newton it says that there are new engine menus and that they are unsynchronized. Maybe you got me wrong, I meant: Could there be some sort of "game menu" on ESC using the new engine menus, instead of the current menu on "F"?
The menus are engine-side support for script-menus (similar to those described here). They should be used to help scripters create menus and offer some things that have not been possible before (adjusting to resolution/scrolling/free positioning/etc.) :)I don't think that would fit for the ESC menu since it's really rather for scripts. But a new ESC menu would still be possible with the old GUI system (the one you see when you click "Network Games" or even before that when you start the Game)
Scripted stuff is usually synchronized, meaning it has more delay, doesn't work in paused mode, hangs if network hangs, etc.There are ways to have stuff scripted and still non-sync functions (e.g. the script defines the menu in advance and leaves some callbacks as non-synced, etc.). That's relatively complicated to implement though.
>There are ways to have stuff scripted and still non-sync functions (e.g. the script defines the menu in advance and leaves some callbacks as non-synced, etc.). That's relatively complicated to implement though.
The hardest part would be to make sure that in those non-synced functions, nothing too demolishing is done (for example, using the Random generator or changing the game state)
Is it possible to create some sort of configuration dialogue with checkboxes, drop-down menus, text/number fields and sliders?
Dimensions: Carry heavy & inventory
Nearing the end of the meeting, we played a round of deadly grotto which took us almost 3 hours to complete. At the end, it was not so much fun anymore, it just stretched and stretched and stretched but the challenge was not changing: Pump this acid lake empty, pump that acid lake empty, pump this lava lake empty and build a bridge back.
Looking at what is played in Clonk Rage, the small and quick arena scenarios are the most popular. But settlement rounds don't need to be that long either - only because the map is small doesn't mean it must be easy. You just might not have to do that much of the repititive stuff then. So we resolved that it would be more fun if the "mission" settlement maps (free settlement is something else) were smaller.
Another thing we noticed were the sheer amounts of resources one had to toss around in the scenario(s): Mining away one vein of sulphur resulted in something like 100 sulphur items which all had to be thrown to the base. This is boring.
In the carry heavy branch, Clonkonaut once implemented that all resources were carry heavy, thus the resources were much bigger and one could only carry one at a time. The inventory slots would be for tools and weapons only.
Our additional idea at the OCM was to use this mechanic to justify that materials spawn much less but bigger chunks of resources when mining them. So if you mine coal, you are not spammed by coal chunks which keep falling on your head but you are pleased when you at last mined a single one. So one (carry heavy) chunk of e.g. sulphur would have to be as valuable as, say, 4 pieces now. How to do this is the question, what would be needed to produce dynamite then? 1/4 of a chunk of sulphur + 1/4 of a chunk of coal is not possible.
So what would be cool about carry heavy resources?:
• Less stuff lying around, single chunks are more valuable
• Your inventory slots are not spammed by resources, you can always carry 5 tools
• While carrying the resource, the clonk is hindered in his movement which can add a challenge
• Makes the lorry, elevators and other means of transporting resources more important again
• Clonks look funny when carrying large chunks of something
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
