![[de]](/mwf/flags/de.png "Germany")
On saturday we had a meeting at the OCM and amongst other things talked about how the inventory system could look like. This is not such an urgent matter since for the first release, we won't have any structures, bases, workshops and so on.Inventory-button
There will be an inventory button, lets call it (I) for now (probably it shouldn't be on i but on a closer button). When pressed, the contents of all objects that are in reach of the clonk (e.g. a storehouse and a lorry) and the clonk's inventory are shown in several menus next to each other in the center of the screen. The order on the screen should be predictable: From left to right - Clonk, vehicle(s), building, trade, ...extra. If the button is pressed again, the menu is closed again.
Non-modal menus
These menus are non-modal, meaning, that several menus can be open at the same time and drag and drop is possible between them. For gamepad users, there will be a second button to cycle through the menus. They are useable with the mouse but also navigatable with the direction keys. Each item can be clicked either with the right or with the left mouse button. Unlike the current menus, it must be possible to distinguish each menu from each other at first glance - for example through different colored/designed frames, a big icon on the top or a huge watermark-like icon that is shown in the entire background of the menu.
Trade and production
Apart from the contents menus, there are at least two more types of menus shown on (I): Trade menus (base) and perhaps the production menus (workshop). The production menu should be shown a little bit apart since it is not possible to drag and drop anything there plus it doesn't have anything to do with contents. It could be shown there just for convenience to not have to open the menu somehow else. Otherwise it could be shown on SPACE ("interact with building"). The trade menu is pretty much the same as the contents menu also in functionality but must look different (e.g. yellow frame) than other contents menus so that it is clear that the items shown there are not contents but can be bought / items are sold when dropped there. In any other aspect, the work the same as the contents menus.
Menu control
The contents in the shown menus can then be freely interchanged via drag and drop. (A drop outside any of the menus means: dropping it in the landscape.) Since drag and drop is too slow for hectic situations, the items can be exchanged via click (like before).
Clicking on an object in a menu should have a predictable effect. Right-click on any item in a menu except the trade menu causes the item to be sold into the trade menu. Right click in the trade menu transfers the bought object directly into the clonk. Left click on items in the clonk or vehicles on the one side and the building on the other side transfers the item each to the other side (from building into clonk if not full yet, otherwise in vehicle). Left click on the trade menu places the bought object into the building (if possible).
Modifiers like Shift, Alt or Control etc. could be used to transfer/sell/buy ALL of one type / get a input window of how many items should be transferred.
Put
Put is an issue which cannot be ignored either. There are situations in the game where one wants to stuff one object into a weapon fast (in order to shoot it). In CR, that was really straightforward and fast - use the first inventory object, done. We don't want to open the inventory menus only to just stuff one item into the catapult, this'd get very tedious if done with a few objects and is too slow anyway. So especially for put-into-weapons, there need to be a extra possibility (doesn't mean that (I) should'nt be possible anymore).
Specificly for the catapult, this solution was discussed:
On click down, a ringmenu with all contents of the clonk (including backpack) would pop up. During the selection, the catapult already starts to wind up. On release, the selected item is shot (with the strength = time that it took to select). However, this can't be used for the general case, e.g. with cannons. The general solution could look like this:
On click down, a ringmenu with all contents of the clonk (including backpack) would pop up. One item is selected (or the menu is cancelled) which is then transferred into the catapult and shown in it's extra slot (lower border of the screen). On the second click, the catapult can shoot it's contents. This is (almost) the same mechanism as with the bow. If there is only one choice (the clonk has only one item OR the vehicle does accept only one item in the clonks inventory), no ringmenu will pop up and the item is loaded automatically. The same method could be used for the bow if there are several arrow types available (not implemented yet).
Related discussions
Doors
We talked about if with this concept, we still need doors at all. PeterW earlier made the suggestion to remove the possibility to enter a building completely earlier. Since the contents of the objects in the landscape at the clonk's position are shown in any case, the clonk doesn't need to enter the building anymore for anything except to protect himself from dangers outside. However that feature could still be used for animation reasons - e.g. hide the clonk inside a workshop while you hear noises, smoke and rummaging coming from inside it.
As there are no urgent reasons to disable doors completely and still they might come in handy, we didn't agree on removing that possibility. Only we will keep in mind when we come to building design that doors are not really necessary. However we agreed that it makes sense to disable PushEnter - that it is not possible anymore to e.g. push airships etc into a building (or 100 lorries into a wagon).
Inventory not for all objects
Also we talked about that certain/many buildings do not really need an inventory. Not even bases do. The pro about limiting the number of objects which can have an inventory would be that there is less search for certain objects that were forgotten in one of the built buildings. Workshops could get their materials from a lorry that is in front of it or the clonk's inventory. However this can't really apply for all buildings because at least for auto production, there should exist a supply before the production starts. It was also suggested that chests could be buildable to supply a non-moveable inventory storage in front of buildings that have no inventory and otherwise only allow inventory in "storehouses".
Backpack
Already partly implemented is the backpack as a solution for a bigger clonk's inventory that is accessible fast and without confusion. The selection on both hands is not changeable anymore and those two items are actually the only inventory slots shown (in full size). On [Q], the backpack is opened as a ringmenu and accessible via mouse (virtual cursor with gamepad) and hotkeys. Left click on one item switches the first inventory slot with the selected item, right click switches the right inventory slot with the selected item.
It is planned to always show the contents of the backpack on the lower left corner as overlays of a big backpack-icon so that the position of certain objects in the backpack are already known before the backpack is opened.
Items are only automatically collected into the two first inventory slots, not the backpack.
By overloading MaxContentsCount() in the clonk, the size of the backpack can be adjusted.
Collect into backpack
It was suggested that there is a button with which one can collect items directly into the clonk's backpack. This button could also be a button which is already used, like double-[Q] or [down]. Automatic collection could also be turned off completely and one can collect stuff via left- and right-click.
Dig earth chunks-problem
Currently it is not possible to dig out earth chunks from the earth, even though it might be highly desireable. The following was suggested:
- Press down a modifier while digging / using something like [Shift] issues extra callbacks in the used object on press down and release
- Right-click while the left mouse button is hold down and the other way round issues extra callbacks or even starts a secondary use in the used object
![[ca]](/mwf/flags/ca.png "Canada")
>It was also suggested that chests could be buildable to supply a non-moveable inventory storage in front of buildings that have no inventory and otherwise only allow inventory in "storehouses".
This may cause players to build one central chest (because they want to save resources) which they store all of their goods in, causing more clutter. It was logical in CR that you made and stored explosives in the explosives workshop.
>Press down a modifier while digging / using something like [Shift] issues extra callbacks in the used object on press down and release
I had also thought of how a 'secondary use' would be useful for the shovel in this respect. :D
>This may cause players to build one central chest (because they want to save resources) which they store all of their goods in, causing more clutter. It was logical in CR that you made and stored explosives in the explosives workshop.
Actually you stored everything in your home base, didn't you? Since other players could easily steal stuff from your workshops :o
Additionally: If the players do that is has to have a reason. For example it could be easier for the player (otherwise he would not do that, would he?). I would not deny such player choices
![[ua]](/mwf/flags/ua.png "Ukraine")
> ...inventory are shown in several menus...
Looks a lot like the concept Ceasar suggested some time ago. I like it. I really do.
Can't say anything else until some prototype is implemented
> ...hide the clonk inside a workshop...
It would be merely impossible since our workshop does not even have a door. Maybe we should really agree on a list of buildings which are "enterable" (as was suggested somewhere here) - so the others will be not.
> ...strength = time that it took to select...
I do not like this idea. Shooting a catapult is highly different from shooting a bow. I always thought that it is weird to target clonks with a catapult - only buildings and machinery. In that case good aiming is highly needed. Since you shoot not cheap arrows but heavy explosives, clonks and chests full of gold the cost of mistake is sincerely higher. So you need to know where exactly you will hit before you shoot.
> Backpack
Can not say anything at the moment but I like the idea of disabling automatic pick-up.
> Dig earth chunks-problem
Like the idea of pressing SHIFT during dig to produce earth chunks
>Inventory-button
I am all for simple, consistent interfaces. I would try to avoid as much as possible things like:
-special behaviours/button combinations to use in one menu, and not in another one,
-Showing different menus, with different purposes, at the same moment/with the same command.
I like the general approach of multiple menus, very distinguable one to each other. However I would
-not include the production menu together with the Inventory menus. I would keep them divided, as you suggest using the "space" button. I cannot think of a situaiton where having both the inventory and the production menus opened it's really necessary. It could be useful, but not necessary, and it just adds complexity to the interface
-keep the trading menu simple, not bound to other menus. I would like the trading menu to handle all the buying/selling, by showing the objects buyable/sellable in the menu.
The inventory menus should be normally divided from the trade menus: if you press I you should only be able to move objects from one place to another, or put in your quickslots... buying and selling should be activated only when the user needs to buy/sell things (that is not as common as open the inventory). However when opening the trade menus, you could also open the inventory menu in order to select what to sell if you prefer this way. But that should be a specific case (opening the trade menu). The trade menu should not interfere in normal inventory use cases.
>For the PUT
I don't like this system... it seems to me more an hack for certain kind of objects that a default interface behaviour.
And I don't think it's a nice thing to design a hack even before implementing the system: an hack should be used only when it's the only way to quickly fix a problem on a working implementation; it surely should not be used in the design phase.
This is how I would do it:
right click on the catapult/cannon/weapon/anything: opens the ring menu, showing all and only the objects that can be used with the catapult/cannon/weapon/etc and that the user possess in that moment.
The user selects something from the menu (left click selects, right click undo the action)
At this point the catapult/cannon/weapon is loaded with the specific object.
The user left clicks on the catapult/cannon/weapon, holding down the left click. The longer the hold down, the stronger the shot
The user releases the left click. Kaboom
I would like to keep a kind of standard in navigating user interface menus and buttons:
left click select action/do something
right click undo/close the menu. (if done on a menu) or open a menu/ringmenu/multiplechoice buttons if done on a object
It is a standard used in many many many programs/games, and it helps the user to familiarize with the system in a easier way
>Related discussions
>Doors
Agreed that doors are not necessary, but I think it adds realism to the game if the clonk to create stuff needs to enter the workshop like in CR, instead of staying outside, and so on for all the buildings where there are actions "inside". However I guess there are a lot of buildings where it is useless to enter, and so it could be disabled (power generators and so on)
>Inventory not for all objects
Agreed
>Backpack
Auto-pick should be turnable off. I find it really annoying. Probably it is subjective, so maybe the user should choose if he wants to auto-pickup or not.
And anyway I would put auto-picked objects in the backpack, since they are not likely to be useful IMMEDIATLY most of the time. If a user wants to really pick up an object and use it in his slots, he could just pick them up with right or left click as you suggested
> secondary functions
I want to add another thing to the inventory system,but it is more general to all the controls.
Many objects might require a second function (a stronger attack for the sword, an activation for the dynamite, etc). This could be easily implemented by using a modifier, like shift,ctrl or alt, together with the mouse button associated with the object quick slot.
This could be used also by objects that needs multiple choices: for example if you have a bow on the left slot, you could press shift + left click, opening a ringmenu where you can choose the type of ammunitation wanted (normal arrows, fire arrows, etc), and then shoot with the normal left click.
Another example could be a magic wand: shift + left click opens a spell selection menu, and after with left click you shoot the spell.
Another example again the dynamite itself: shift + left click turns it on, shift + left click turns it off again, etc, and then left click throws
Another example: an airplane: with left click you shoot, with shift + left click you choose between bombs, missiles or wipfs
And so on, so on, so on
This system is very general, and can be used both for implementing a simple secondary function or a multiple-options function, for any object.
If you need to implement an object with only one function just use the normal mouse click
If you need to implement an object with two functions, use the normal mouse click, and the mouse click with the modifier
If you need to implment an object with more than two functions, use the normal mouse click for the defaul action, and the mouse click with the modifier to popup a multiple-choice menu (or the ringmenu )
This post made me think of an interesting idea...The problem is obvious when you play with different items a bit.
Imagine a situation. Clonk carries a bow in his A-slot (the one that is operated by LMB) and bow model is drawn along with the clonk model. Ok. What about if he carries it in B-slot? ... Well, this example is not very good. Let me suggest another one:
We already have a simple shield animation which looks fine when shield is placed in the B-slot. But if it is used when placed in A-slot, there happens a weird animation bug (The shield is still hanging on clonks back while he tries to defend himself from all dangers of the world with... his bare hand).
Another example: You have boompack/musket/other in your A-slot which is drawn ingame. And you have a D-box in your B-slot which is NOT drawn ingame. When you place all sticks with RMB you know (hypothetically) have a detonator in your hands which is also not drawn (because you have boompack/musket/other from your A-slot drawn instead). But you still have igniting animation. Weird.
Idea
All this stuff made me think of limiting the number of inventory slots to... yep, you are right... to 1 (one).
BUT
You still have the secondary slot which is used by pressing RMB. The only difference is that NOT EVERY object can be put into this slot - only tools. By "tools" I mean:
- Shovel (drawn as it is now - carried on the back);
- Axe (the same);
- Hammer (hanging on the waist/belt);
- Shield (drawn as it is);
- Magic book
and so on.
The only drawback is that tools should not be used from primary slot anymore. (or maybe not). And another important thing: tools must have a different background (red?) when drawn in inventory to make sure player does not blow up his brains trying to realize which item should be put into which slot.
This starts to remind me countless or RPGs where different items/clothes could be put into corresponding slot only.
And this is not the end of it
I think of implementing the third slot which can be used for storing different so-called "wearable" objects. By "wearable objects" I mean:
- Body armor
- Diver's helmet
- Backpack
and others
Since these objects are not usable you do not need additional mouse button to use them. Instead they are used constantly from the moment you put them on up to the moment you
This is not the most brilliant idea and I know that a lot of people will disagree with my point of view. But I think everyone will understand the importance of unifying the inventory and solving the "cross-animation" problem in some way. Or maybe there is no problem at all?
I already proposed the one slot solution in the past: having left and right click for using the object with normal use and secondary use, and switching objects with mousewheel (since I don't like so much the idea of spending a lot of time assigning items to hand slots.. in my opinion it is unnatural and over mechanical, not smooth, but I can live with it)
In my opinion, or we should go all for the 1 slot solution, or for the 2 slot solution. Solutions in between like your proposal (with only some items that can be used in the right slot) have many more cons than pros:
-less intuitive system for assigning objects to the slots..., not only you have to assign them to the slots, but now you have to keep attention of what you assign to what
-useless right mouse button if you don't need a tool (if you are in a combat, and you have to react fast, you WANT to exploit both mouse buttons to react fast.. with your system you could only use it for certain objects, that's limiting user's possibilities)
But i like the wearable idea... in my opinion in the inventory menu, or in a separated menu, we could have an equip GUI that shows what the clonk wears, like in many many many rpgs. However I would keep it in a menu, not in a quick slot... it's more clear, and more intuitive to use it (drag a hat over your character's head in the guy and it wears it)
In my opinion, or we should go all for the 1 slot solution, or for the 2 slot solution. Solutions in between like your proposal (with only some items that can be used in the right slot) have many more cons than pros:
-less intuitive system for assigning objects to the slots..., not only you have to assign them to the slots, but now you have to keep attention of what you assign to what
-useless right mouse button if you don't need a tool (if you are in a combat, and you have to react fast, you WANT to exploit both mouse buttons to react fast.. with your system you could only use it for certain objects, that's limiting user's possibilities)
But i like the wearable idea... in my opinion in the inventory menu, or in a separated menu, we could have an equip GUI that shows what the clonk wears, like in many many many rpgs. However I would keep it in a menu, not in a quick slot... it's more clear, and more intuitive to use it (drag a hat over your character's head in the guy and it wears it)
Then I vote for 1-item inventory (like the one used in CR base pack). In this case you are able to use LMB for primary use and RMB for secondary use. But yes, this makes us have a separate inventory which is not that fast to operate.... Stop. Why is that?
We can have as many inventory slots as we like (2,3,5, whatever) but only one of them will be selected at the moment. LMB and RMB will be used for using selected slot, keys 1,2,3... (or mouse wheel) to alter selection. This approach will solve ALL problems:
1) You can carry as many different items as you like (well, as your inventory allows) - not only one;
2) You can have 2 different uses (along with throw-away action) for every item;
3) The most important: now clonk (visually) carries only one item so different models do not mess one with each other.
And the last idea. Considering shield usage:
Shield can still be usable when selected in the inventory, but...
We can make sword (and javelin, perhaps) have an "extended" slot (the same slot that bow and musket have for their ammo). If you put something in this slot then from now on your sword will have only one, primary attack. The secondary attack is substituted with the usage of the item which is placed in this slot. This can be:
1) A shield (cover with RMB);
2) Stone (throw with RMB);
3) Additional sword (primary use (swing) with RMB)
and so on...
Hm... I start to think thgis is the one and only way I would like to see OC inventory system implemented (I mean, primary and secondary use and only one item selected at a time). At least can not think of anything better at the moment.
this is exactly my old idea, since a few months ago :)
and I already had a proposal for solving the shield problems: by having an equip menu where to insert the wearable objects
you can insert hats, shields, pants, whatever to wear in this guy, like in any RPG.
then:
if you have a shield equipped, all the weapons will only allow the normal (leftclick) usage. right click will use the shield,
if you don't have a shield equipped, you will have the secondary use for all the weapons (for example a more powerful,but slow, attack with the sword).
This would create different playstyles: who prefer to use a shield and cover himself, or who can use more type of attacks
it is essentially the system you describe, but putting the shield and stuff not in a "extended slot", that would cause confusion, but in a standard "equip menu", usable by all the wearable object
HOWEVER
there were a lot of people that didn't like the system (saying that to use the shovel and other objects would be less confortable to use the mousewheel to select them, instead of having them on the second slot and having always them available).
I still think that managing the two slots, putting objects there, etc it is much less comfortable.... but it is a subjective thing I guess
PS: we are going a bit OT here
and I already had a proposal for solving the shield problems: by having an equip menu where to insert the wearable objects
you can insert hats, shields, pants, whatever to wear in this guy, like in any RPG.
then:
if you have a shield equipped, all the weapons will only allow the normal (leftclick) usage. right click will use the shield,
if you don't have a shield equipped, you will have the secondary use for all the weapons (for example a more powerful,but slow, attack with the sword).
This would create different playstyles: who prefer to use a shield and cover himself, or who can use more type of attacks
it is essentially the system you describe, but putting the shield and stuff not in a "extended slot", that would cause confusion, but in a standard "equip menu", usable by all the wearable object
HOWEVER
there were a lot of people that didn't like the system (saying that to use the shovel and other objects would be less confortable to use the mousewheel to select them, instead of having them on the second slot and having always them available).
I still think that managing the two slots, putting objects there, etc it is much less comfortable.... but it is a subjective thing I guess
PS: we are going a bit OT here
>-keep the trading menu simple, not bound to other menus. I would like the trading menu to handle all the buying/selling, by showing the objects buyable/sellable in the menu.
The inventory menus should be normally divided from the trade menus:
Why? The inventory menu IS the menu of stuff you can sell. A leftclick in the inventory menu would always shift the object between your hut and your clonk (f.e.) - a right click on the other hand would always sell the item (if you can sell stuff there).
Why should there be two menus with exactly the same items (the ones that you can sell)?
then how do you assign an item in your inventary to a quick slot for using it?
there are two use cases here:
-user wants to see what there is inside is inventory to use it/manage the inventory
-user wants to sell stuff
in my opinion they should not be mixed. So you need some specific funcitons to handle the first one. For handling the second one you could reuse the same menu's and GUI, but it should not be triggered everytime you open the inventory, but only when the users really want to sell/buy stuff
AS far as I see it:
inventory menu: if you click on a object with the left click you assign it to the left slot, if you click on a object with the right click you assign it to the right slot, if you drag and drop/use a modifier you can switch the item between different context (clonk/vehicle/building's menus)
Trade menu: when the users opens it (by pressing another button, entering it's base, selecting an option from a menu, or whatever) it shows a menu with what it can buy from that store, and next to it it can open the inventory menu for selling stuff.
If you like the idea to keep only one menu for the inventory do it, I don't have problems with that. I am against allowing the buy/sell by simply opening the inventory. In my opinion the buying/selling function should be activated in a different way from the way you normally open the inventory
there are two use cases here:
-user wants to see what there is inside is inventory to use it/manage the inventory
-user wants to sell stuff
in my opinion they should not be mixed. So you need some specific funcitons to handle the first one. For handling the second one you could reuse the same menu's and GUI, but it should not be triggered everytime you open the inventory, but only when the users really want to sell/buy stuff
AS far as I see it:
inventory menu: if you click on a object with the left click you assign it to the left slot, if you click on a object with the right click you assign it to the right slot, if you drag and drop/use a modifier you can switch the item between different context (clonk/vehicle/building's menus)
Trade menu: when the users opens it (by pressing another button, entering it's base, selecting an option from a menu, or whatever) it shows a menu with what it can buy from that store, and next to it it can open the inventory menu for selling stuff.
If you like the idea to keep only one menu for the inventory do it, I don't have problems with that. I am against allowing the buy/sell by simply opening the inventory. In my opinion the buying/selling function should be activated in a different way from the way you normally open the inventory
> There will be an inventory button, lets call it (I) for now (probably it shouldn't be on i but on a closer button).
What about having it open automatically when grabbing? I don't see what the upside of having yet another key should be.
> huge watermark-like icon that is shown in the entire background of the menu.
Bad idea. It will be impossible to recognize it quickly.
> The production menu should be shown a little bit apart since it is not possible to drag and drop anything there plus it doesn't have anything to do with contents.
I don't understand that part. Dropping materials there should add them to the stack of materials used for stuff that is to be built.
The really interesting part is how accumulation of materials for buildings works in the first place. I would try to have no "normal" contents menu there. Instead, we could limit it to base materials specific to that particular buildings (say, wood and metal for the workshop). Then we have a special raw material list below the construction list, initially showing "0x [[wood]], 0x [[metal]]". The idea behind that is that it allows us to visualize material need elegantly: If a construction plan gets selected, this list would become "0x [[wood]], 0x [[metal]] (-2)" with (-2) red to signify unmatched raw material need.
Stealing a bit more from CX, we could think about making the buildings auto-buy from a nearby base if, say, an icon in the construction menu is double-clicked or drag/dropped. I would prefer this a lot to having vehicles or chemical products buyable in the base.
> A drop outside any of the menus means: dropping it in the landscape.
Where exactly? I'd make it a simple "exit in front of building/vehicle", simply because it's easy to mis-drag/drop.
> the items can be exchanged via click
"exchanged"? You mean the Clonk takes it in his hand?
> Clicking on an object in a menu should have a predictable effect. Right-click on any item in a menu except the trade menu causes the item to be sold into the trade menu. Right click in the trade menu transfers the bought object directly into the clonk. Left click on items in the clonk or vehicles on the one side and the building on the other side transfers the item each to the other side (from building into clonk if not full yet, otherwise in vehicle). Left click on the trade menu places the bought object into the building (if possible).
Uhm, that is really confusing me. Why those strange rules with right-clicking? If I buy something, I want to take it away, so the sensible choice is always having it transfer it into the Clonk's hand or something similar. My idea would be as follows:
* Drag/Drop: Transfer to other vehicle/building if there's a drop target, exit otherwise. Buy/produce item if necessary.
* (Left-)Click: Same, but auto-pick target - first Clonk, then backpack, then grabbed vehicle container, then other containers, then just exit in front.
Note that production might take a bit, so we need to think about what the most sensible behavior would be in that case. I'd like it if I could push the lorry in front of the chemical plant, alt-click flints, and then leave the plant chewing on my sulphur and placing the results into the lorry I left (second priority or third periority). Maybe we'd want to stop production, on the other hand, if the target is lost.
> Put
I don't see what the big issue with the catapult is. We already have means to select the currently "active" object. Having a ring menu to just duplicate what's already available at the bottom of the screen doesn't seem very elegant to me. Imo, transfering any objects into the catapult should be avoided as far as possible, because catapults should not be containers (in constrast to crossbows, which should be able to hold arrow packs).
A far more interesting problem is how putting an object into a building should work. One solution could be to have a special "drop" icon showing the currently selected object. But I'd actually prefer if we could resolve most of these situations by having the storage building have a collection zone like the lorry or the chemical plant. Throwing objects around is fun and Clonk-y.
> As there are no urgent reasons to disable doors completely and still they might come in handy, we didn't agree on removing that possibility.
As we're starting fresh, I'd put it the other way round: There's no reason to implement doors right now. And we should keep it that way until we really have a good concept of why they should be needed.
> Backpack
I'm not particulary interested in that topic (mainly because there already seem to be enough people with opinions), but we should keep it both visually and functionally compatible to building menus. Generally, I'm also a big fan of round menus, but they stack very badly.
>What about having it open automatically when grabbing? I don't see what the upside of having yet another key should be.
You could not see anything if you would always have screen filling menus open.
>Bad idea. It will be impossible to recognize it quickly.
A different color scheme for each of the menus was the other idea. Additionally the menus will always be on (nearly) the same position
>I don't see what the big issue with the catapult is. We already have means to select the currently "active" object. Having a ring menu to just duplicate what's already available at the bottom of the screen doesn't seem very elegant to me. Imo, transfering any objects into the catapult should be avoided as far as possible, because catapults should not be containers (in constrast to crossbows, which should be able to hold arrow packs).
The ringmenu is basically the backpack - so it would not be a special case for the player there. And the object should not enter the catapult but be instantly launched after selecting
>A far more interesting problem is how putting an object into a building should work.
I think we should avoid stuff in buildings (other than the homebase) wherever possible. The buildings should fetch stuff from nearby lorries/chests. That would make the buildings a lot more consistent (because you know that you don't have stuff in there) and if you really need some space for storing stuff, you could always build a chest in front of the building (which could be opened and have an Collection-area!)
Additionally that would be parallel to your "we-dont-need-no-doors"-attitude, so you just have to like it!
-- I think we need at least a homebase that you can enter, though
After reading the last two posts, I think before dealing with how to design the inventory menu, we should discuss about what do you intend for inventory, what it should be its goal and if an inventory is needed at all, since it seems to me that everybody here as a very different idea of what the purpose of the inventory should be and how it should work.
First we should all agree on :
-The features we would like to have related to inventory systems and handling of multiple objects in general
After we all agree on the features we would like to have, we could go on discussing on the best system to implement it.
But for me, right now we have all a different set of features and DESIGN in mind, so discussing about the IMPLEMENTATION is useless
First we should all agree on :
-The features we would like to have related to inventory systems and handling of multiple objects in general
After we all agree on the features we would like to have, we could go on discussing on the best system to implement it.
But for me, right now we have all a different set of features and DESIGN in mind, so discussing about the IMPLEMENTATION is useless
Agreed. We should definitely start with something like:Things for which the inventory is needed:
1. Item usage
a) Pick up item
b) Carry item from point A to point B
c) Use item
d) Throw item
e) Drop item
2. Item storing
a) Store item
b) Withdraw item
3. Item exchange
a) Buy item
b) Sell item
4. Manage several items
...
n. Some weapons can have diffrent ammunition types
and so on...
Possible solutions
1. Implement an inventory slot.
a) Autopick item if this slot is empty
b) ---
c) Use LMB to operate item
d) Use SHIFT+LMB to throw item
e) Use S+LMB to drop item
2. Have a storage menu opened over the hut when cpressing SPACE near it
a) Drag&drop item from inventory slot to blank storage position to store it
b) Drag&drop item from storage menu to inventory slot to withdraw it
3. Have a buy/sell menu opened after some manipulations with the hut
a) Drag&drop...
4. Implement additional slots
...
n. Implement extra ammunition slot for some items
and so on...
What about this kind of consideration.
P.S. Well, it may be TOO MUCH to make everything detailed so much but I think the main point of my suggestion is understandable.
I made a topic on this thing in the "general discussion" forum
it is a much more wider and general topic than the inventory system...
it is all about managing the project with a more "managed" approach than we have now..
and however to do something similar to what we describe only seems "TOO MUCH"...
there are many tools and standards (UML anybody? ) to do exactly this kind of things and basically 95% of professional and complex software projects do it
it is a much more wider and general topic than the inventory system...
it is all about managing the project with a more "managed" approach than we have now..
and however to do something similar to what we describe only seems "TOO MUCH"...
there are many tools and standards (UML anybody? ) to do exactly this kind of things and basically 95% of professional and complex software projects do it
> You could not see anything if you would always have screen filling menus open.
I'm not talking about "always" - just when you are pushing something. And the menus should be as small as possible anyway.
> The ringmenu is basically the backpack - so it would not be a special case for the player there.
That's my point. If possible, the interface to the backback should be consistent to the interface of buildings.
> Additionally that would be parallel to your "we-dont-need-no-doors"-attitude, so you just have to like it!
I see the spirit. But let's look at the other side for a moment: Won't this mean that I will end up building a chest or leaving a lorry for each and every building that does serious production? Won't this be the old universal containers - just at a higher cost? Plus I'm getting a bit sceptic when we are starting to use words like "nearby" - where exactly does "nearby" end? Will this be transparent to the player? Does he really expect items to get "beamed" from a chest to a production building?
>I'm not talking about "always" - just when you are pushing something.
"Always when you are pushing something", then
>And the menus should be as small as possible anyway.
Why? That would mean that you would have to scroll a lot through tiny, f.e. 2x2, menus just to find the item you need. I don't see how the gameplay would benefit from that. (You would have menus when you don't need them and you have only tiny menus when you need them)
>That's my point. If possible, the interface to the backback should be consistent to the interface of buildings.
The backpack needs to be accessible in fast fights (with maybe one or two clicks). The buildings on the other hand, do not - they can be a bit slower but, because they are no ringmenus, they can stay stackable
>Won't this mean that I will end up building a chest or leaving a lorry for each and every building that does serious production? Won't this be the old universal containers - just at a higher cost?
Well, yes. If that proves to be a problem (a chest would probably just cost one wood - and we don't have conkits anymore) production buildings could automatically spawn chest.
I would find it very inconsistent that you could put stuff in buildings but not enter them yourself
>Does he really expect items to get "beamed" from a chest to a production building?
The idea was that the clonk (when producing) leaves the building (only automatically if it has a door), grabs the chest and then beams the items from the chest directly into the building (so that he does not need free inventory slots for producing)
Nearby chests and lorries could be highlited when the player opens the production menu to make that a bit more transparent
> "Always when you are pushing something", then
Well, I'd say that it's actually pretty uncommon to be pushing something. Especially in regions where there are a lot of buildings. I mean, we are talking about the lorry menu and one or two building menus, right?
> That would mean that you would have to scroll a lot through tiny, f.e. 2x2, menus just to find the item you need.
My ideal menu size would be something like 6x1 or 6x2. See my concept sketch - I'd go maybe 50% larger than that, tops. And I absolutely think we should have no scrolling to the point of not offering an implementation.
> a chest would probably just cost one wood
That actually makes it worse - having it at low costs makes it less of a strategic decision to have one. The cheaper it is, the more you need one anyway and the wasted clicks and keystrokes become a simple annoyance.
> and we don't have conkits anymore
Uhm, did I miss the discussion about that? I would have proposed to merge the hammer with the conkit (= have it permament, like a shovel) and give it some additional functions like repairing buildings (we really need building damage feedback this time, btw). Removing the concept in its entirety doesn't seem like a good idea to me.
> production buildings could automatically spawn chest.
Which is equivalent to my proposal - only that you're not grouping the two menus together properly and have the problem again that you might leave irrelevant stuff in that chest.
> I would find it very inconsistent that you could put stuff in buildings but not enter them yourself
That's a bizarre point. Do you find it inconsistent, too, that you can't enter lorries? I'm actually talking about something like (maybe even visible?) wood and metal stacks in front of the workshop. Like that one wood stack building from the Knights package - which was stylish but unusable. Maybe I need to start making concept images again...
> The idea was that the clonk (when producing)
Oh, I guess I forgot to mention that: I imagined most buildings working without a Clonk operating it. Just deactivating a Clonk for some time is not fun - we should avoid it as far as possible. Maybe we could even go as far as having buildings and vehicles auto-construct.
> leaves the building (only automatically if it has a door)
Leaving a building? Doors? What is this nonsense? ;-)
>My ideal menu size would be something like 6x1 or 6x2. See my concept sketch - I'd go maybe 50% larger than that, tops. And I absolutely think we should have no scrolling to the point of not offering an implementation.
That would start being a problem when the lorry contains more than 6 (or twelve) objects. And even three 6x2-menus would obstruct a lot of the screen already
>I would have proposed to merge the hammer with the conkit (= have it permament, like a shovel)
That's the way it is (iirc). So you do not waste one conkit (worth 15 gold) for every building you build
>I'm actually talking about something like (maybe even visible?) wood and metal stacks in front of the workshop.
I don't see how that is different from a chest (-like) thing then
>Oh, I guess I forgot to mention that: I imagined most buildings working without a Clonk operating it.
I agree with that
> That would start being a problem when the lorry contains more than 6 (or twelve) objects
What about grouping objects of the same type?
> That would start being a problem when the lorry contains more than 6 (or twelve) objects.
How likely is that? And the main issue is: If someone insists on filling a lorry that much - is it better to have a menu that is a bit larger, or have the player operate a scroll bar to find the item he's searching for? I'm strongly leaning to the former.
> I don't see how that is different from a chest (-like) thing then
Like I said:
* No danger to lose objects. If we show the stacks, it's even possible to tell from the outside what kind of stocks are available.
* Grouping menus together - lower interface complexity and you can visualize material need in a clear way.
>How likely is that? And the main issue is: If someone insists on filling a lorry that much - is it better to have a menu that is a bit larger, or have the player operate a scroll bar to find the item he's searching for? I'm strongly leaning to the former.
I totally agree with that. And that is why we should not always display those "bit larger" menus but have the player press a button to open them
>Like I said:
>* No danger to lose objects. If we show the stacks, it's even possible to tell from the outside what kind of stocks are available.
>* Grouping menus together - lower interface complexity and you can visualize material need in a clear way.
So each workshop could only contain the materials used for producing stuff? I think I could live with that while not being totally happy, though. (what happens if we need something like an alchemists' workshop that can use ten different ingredients?)
You fail to account for the "How likely is that?" :)
Plus the menus are above the buildings for a reason - that space is in most cases unoccupied, so it's doubly unlikely we're blocking anything important. I mean, what is our worst case situation here, exactly? I'm pushing a lorry with 50 objects, which I can't let go for some reason, and have to look straight up? Maybe I'm grabbing a catapult, trying to defend, and a tightly packed chest is blocking my view?
I can't really see it right now - and having to define a special key is a huge price to pay, imo.
Yeah, that's the obvious downside. I would try to call that bad game design and look whether I'd get away with it.
Plus the menus are above the buildings for a reason - that space is in most cases unoccupied, so it's doubly unlikely we're blocking anything important. I mean, what is our worst case situation here, exactly? I'm pushing a lorry with 50 objects, which I can't let go for some reason, and have to look straight up? Maybe I'm grabbing a catapult, trying to defend, and a tightly packed chest is blocking my view?
I can't really see it right now - and having to define a special key is a huge price to pay, imo.
> what happens if we need something like an alchemists' workshop that can use ten different ingredients?
Yeah, that's the obvious downside. I would try to call that bad game design and look whether I'd get away with it.
>Plus the menus are above the buildings for a reason - that space is in most cases unoccupied, so it's doubly unlikely we're blocking anything important. I mean, what is our worst case situation here, exactly? I'm pushing a lorry with 50 objects, which I can't let go for some reason, and have to look straight up? Maybe I'm grabbing a catapult, trying to defend, and a tightly packed chest is blocking my view?
For me as a melee player (*cough*) it really is something like the catapult situation (or crossbow and you want to defend your base from a blimp). For settling everything does not have to be super-fast and stuff. Melees are something completely different!
Well, fair enough, but how often will you stand in front of a full lorry when doing that? We could even think about deactivating the behavior for items that don't have a building/vehicle menu themselves, like the mentioned crossbow and catapult.
In case you want to have fast reload from a nearby lorry and not a menu open all the time - well, I fear that's impossible, we can't have everything at the same time.
In case you want to have fast reload from a nearby lorry and not a menu open all the time - well, I fear that's impossible, we can't have everything at the same time.
Just a meta side note here:It is very hard up to impossible to follow those citation orgies. In my opinion, any realizable concept is lost in those citation-orgies because it is not clear anymore what was actually the point and only single points of one big concept are discussed/revised without respect to the dependencies with other stuff in there. It's picking it to pieces without putting the pieces together again (without explaining of how different it would look then as a whole).
Well, what would you propose? Should I include more context? That would make those posts even longer. Maybe we need a possibility to comment on paragraphs or something to that effect...
Initial post on the wiki.
Discussion on irc/forum, with slightly changes to the initial page when there is an agreement.
In this way everybody can always have the things clear and in a structured way
Discussion on irc/forum, with slightly changes to the initial page when there is an agreement.
In this way everybody can always have the things clear and in a structured way
>In this way everybody can always have the things clear and in a structured way
So if Peter and me have different opinions - the one who is faster at writing some wiki page wins?
no. if you have two different opinions you can discuss on the forum and on irc. But at least you have a place, on the wiki, where the proposal of one of the two can be always be checked and controlled. And in case it's easy to modify after an agreement and let everybody read it.
You can just have a section in the wiki called proposals, where only the actual developers can edit. It should be a write resticted area, because it should not be a place to simply propose ideas (for that there is the forum or irc), but a precise design to accomplish one requirement/feature. And when the proposal is accepted, you just need to move it to the doc section, out of the proposal one.
So you have already something written about a OC feature, it's already in the wiki and it's visible to everybody..
And this is just a way to do that.. come on guys, try to be a bit creative and make some proposal in order to improve the situation, instead of just arguing and arguing..
You can just have a section in the wiki called proposals, where only the actual developers can edit. It should be a write resticted area, because it should not be a place to simply propose ideas (for that there is the forum or irc), but a precise design to accomplish one requirement/feature. And when the proposal is accepted, you just need to move it to the doc section, out of the proposal one.
So you have already something written about a OC feature, it's already in the wiki and it's visible to everybody..
And this is just a way to do that.. come on guys, try to be a bit creative and make some proposal in order to improve the situation, instead of just arguing and arguing..
>Maybe we need a possibility to comment on paragraphs or something to that effect...
Thats possible, see? :P
Well firstly I don't see much sense to argue about small stuff that was mentioned in the margin and was obviously not well thought through in the first place (In context: Chests). With this stuff (inventory for workshops), we need someone to post a comprehensive tought-through concept. You mentioned something about allow only few materials inside workshops but which are shown outside(?). But how would that look like, how would you control it and how does it fit into the rest of the concept? I think to sketch this (and other ideas that were mentioned as an aside) would really help.I mean in general, generally when the discussion is threatened to drift into a slugfest.
>The really interesting part is how accumulation of materials for buildings works in the first place. I would try to have no "normal" contents menu there. Instead, we could limit it to base materials specific to that particular buildings (say, wood and metal for the workshop). Then we have a special raw material list below the construction list, initially showing "0x [[wood]], 0x [[metal]]". The idea behind that is that it allows us to visualize material need elegantly: If a construction plan gets selected, this list would become "0x [[wood]], 0x [[metal]] (-2)" with (-2) red to signify unmatched raw material need.
Interesting idea. But I can't really imagine how a production menu would look then. How would it look different from a normal menu?
>Where exactly? I'd make it a simple "exit in front of building/vehicle", simply because it's easy to mis-drag/drop.
Yes.
>"exchanged"? You mean the Clonk takes it in his hand?
Exchanged between the objects whose menus are shown.
WARNING: This is probably the most "heavy-loaded" forum topic (I mean the size of all posts). Probably we need to move further discussion about the inventory controls to IRC channel of create different topics for different aspects.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
