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!
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.
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.
• 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?)
> • 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 :)?
>Bubbles can be breathed in by anything but their creator
So two clonks can exchange breath underwater?
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.. :)
Maybe the selected slot should be less brighter and highlighted looking and a bit smaller. (that also prevents blurry object graphics)
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!)
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?
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?)
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.
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?
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)
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)
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