Rasmus you said that such in-room storages would make player to lose control over situation, but I don't know exactly how. What I missed there?

In an example of such in-room storage - just mined iron ores would go only to rooms which actually needs iron ores, player so knowing which rooms requires iron ores will search for them only in these rooms. He have full control over where his Iron Ores are being stored.

If there are more then one iron-ore-needing Rooms then there's made a "queue of these Rooms demands" - whenever a Room just finished crafting an item / was just build or number of fish in Bar Room is less then required to fulfill its clients needs for Fish - then Rooms is reserving the required Iron Ore(s) / Fish and there's made a queue - so other rooms would need to wait for the same resources being queued as second, then third, etc.

This disallow production chains to be interrupted and whenever some Rooms palyer would like to shut down - Rooms just wouldn't make a reservation for required to production / service resource item.

Moreover, having still one storage for everything doesn't solve the problem of having Storage Room possibly filled with an items that are so many you won't have place for other Items... Surprisingly Backpacks you made may resolved this issue as also helps in-room storage idea, because now an Imps could take for example 10 Iron Ores in one time and then walking thorough dungeon delivers 3 Iron Ores to this Rooms, then 3 to other room - in order of queue list.

What if player don't have required room to store certain kind of items - well then we have Dark Mother storages that can take any kind of Item, from which whenever there's need for certain resource from there an order is sended to assigned to needed-this-resource-room Imp to take resources from Dark Mother then when there's no resources in Dark Mother's storages then Imps who are digging Iron Ores have to deliver Iron Ores to that room.

Then such in-room storages could be unlimited or (and it's better idea IMHO) storage capacity size is determined of number of storages or Room size.

You said in 1st post you would like to have certain storage for certain items - so you've got that here.

Alternative idea:
If such in-room storages wouldn't replace Storage Rooms then maybe they could just serve as an object to store items in them by Imps that will replace blue flags mechanism? I mean Imps are placing everything on tiles with blue flags standing on them, what if in-room storages could replace them, so you wouldn't need to use blue flags anymore because Imps would automatically store resources in in-room storage units like shelves or barrels, etc?

I envisioned the system pretty much like what Sebt described. I would still make the storage finite, so you'd have to expand the rooms to fit more storing tiles to keep up with the production/consumption balance.

Another fundamental change that I would love to try would be reversing the storing dynamic. Right now, you start with huge storing space (Dark Mother) and, as you expand, you fill it and need to build storing rooms. That marks the spot where it gets complicated and clunky, and not in a fun way. It feels almost bureaucratic. You need to build a table? Oh well, you need 2 logs. What? Those two, right over there, on the floor besides the table plan? No no no, those haven't gone all the way to the storage room yet, let me add your request to the imp queue. As soon as an imp finishes his current task, he'll come pick them up, take them to the storage room, fill in the income forms and papers, have them stamped by the Dark Mother (obviously) and go fish while he's at it, because why the hell not. Then, another imp will go pick them up, fill in the outcome forms and papers, pick up the logs, check that the description matches the product, realize he picked up antroots instead, pick up the correct logs this time, go all the way to the table plan right after he finishes drinking a pint from the nearby tavern, and THEN build the table, which, by the way, was inside that very same tavern.

(this makes me want to build a bureaucracy simulator where everything gets exponentially more complicated and slow to do, until the whole system collapses, kinda like Papers, Please, only you'd see the little workers coming and going, gathering stamps and signatures, and queues growing. A game where your goal would be to grow the longest queue before a citizen breaks down and starts throwing chairs through windows)

What would happen if you start with no storage at all? Resources would be left on the floor until they are needed, or a room builds an appropriate storing item. It would be slow and disorganized at first, but as you grow you'll start seeing that everything starts getting organized, that the imps are faster when building/making things because the needed items are right there, where they need them?

(29-06-2015, 05:06 PM)Sebt Wrote: If there are more then one iron-ore-needing Rooms then there's made a "queue of these Rooms demands" - whenever a Room just finished crafting an item / was just build or number of fish in Bar Room is less then required to fulfill its clients needs for Fish - then Rooms is reserving the required Iron Ore(s) / Fish and there's made a queue - so other rooms would need to wait for the same resources being queued as second, then third, etc.

This disallow production chains to be interrupted and whenever some Rooms palyer would like to shut down - Rooms just wouldn't make a reservation for required to production / service resource item.

I am not sure I understand what you mean here, but as I understand it the "queue of these Rooms demands" is something where each room calculate the demand of a certain items etc. and the highest needs gets the item. The problem here is that the "queue of these Rooms demands" are hard enough to calculate for the storage rooms, and it will be way harder to calculate for individual rooms as there are so much more of them.

Actually, right now the game don't care about any room demands at all, when the storage rooms were first introduced I tried to calculate the demand of each room and that got complicated way to fast and the balance were lost, usually it ended up with one room getting all the items and the rest got nothing.

The only thing the game does right now is to give the storage rooms the information about what rooms are connected to them and what items they should stock up on. Then when a new item gets produced it get sent to a random storage room that might need this item, and this works very well. The only thing that don't work so good is where to store all the items, we could use the standard rooms as storage, but this would make it more complicated for the player to keep the production chain going, and it would be a lot harder for the game to calculate which items should go where because then we would have all the rooms that has a storage involved in the calculation instead of just having one storage room per room.

(29-06-2015, 05:06 PM)Sebt Wrote: Moreover, having still one storage for everything doesn't solve the problem of having Storage Room possibly filled with an items that are so many you won't have place for other Items...

The game should move items between storage rooms as new storage rooms pops up and they demand items that aren't in their storage room. The only problem I see here is that the storage rooms has limited storage and at some point they can't be expanded anymore. So either we find a way to upgrade the storage rooms, make specific storages per item that holds an infinitive amount of items of that type, or just give all the storage rooms infinite storage and focus on the logistic to make storage rooms close to other rooms.

(29-06-2015, 05:06 PM)Sebt Wrote: Surprisingly Backpacks you made may resolved this issue as also helps in-room storage idea, because now an Imps could take for example 10 Iron Ores in one time and then walking thorough dungeon delivers 3 Iron Ores to this Rooms, then 3 to other room - in order of queue list.

I can't make it so that an imp fill his backpack with items that has different target locations. It gets way to complicated, the only time he fills his backpack is if all the items are going to the same location.

(29-06-2015, 05:06 PM)Sebt Wrote: Alternative idea:
If such in-room storages wouldn't replace Storage Rooms then maybe they could just serve as an object to store items in them by Imps that will replace blue flags mechanism? I mean Imps are placing everything on tiles with blue flags standing on them, what if in-room storages could replace them, so you wouldn't need to use blue flags anymore because Imps would automatically store resources in in-room storage units like shelves or barrels, etc?

The blue flag is working as a way point where the rooms are linked together, not as a storage location, it is more like a drop point. If we would have in room storage we would still need the blue flag as a dropping point.

(01-07-2015, 03:51 AM)Excess Wrote: I envisioned the system pretty much like what Sebt described. I would still make the storage finite, so you'd have to expand the rooms to fit more storing tiles to keep up with the production/consumption balance.

Another fundamental change that I would love to try would be reversing the storing dynamic. Right now, you start with huge storing space (Dark Mother) and, as you expand, you fill it and need to build storing rooms. That marks the spot where it gets complicated and clunky, and not in a fun way. It feels almost bureaucratic. You need to build a table? Oh well, you need 2 logs. What? Those two, right over there, on the floor besides the table plan? No no no, those haven't gone all the way to the storage room yet, let me add your request to the imp queue. As soon as an imp finishes his current task, he'll come pick them up, take them to the storage room, fill in the income forms and papers, have them stamped by the Dark Mother (obviously) and go fish while he's at it, because why the hell not. Then, another imp will go pick them up, fill in the outcome forms and papers, pick up the logs, check that the description matches the product, realize he picked up antroots instead, pick up the correct logs this time, go all the way to the table plan right after he finishes drinking a pint from the nearby tavern, and THEN build the table, which, by the way, was inside that very same tavern.

(this makes me want to build a bureaucracy simulator where everything gets exponentially more complicated and slow to do, until the whole system collapses, kinda like Papers, Please, only you'd see the little workers coming and going, gathering stamps and signatures, and queues growing. A game where your goal would be to grow the longest queue before a citizen breaks down and starts throwing chairs through windows)

What would happen if you start with no storage at all? Resources would be left on the floor until they are needed, or a room builds an appropriate storing item. It would be slow and disorganized at first, but as you grow you'll start seeing that everything starts getting organized, that the imps are faster when building/making things because the needed items are right there, where they need them?

Would that be more fun or more boring?

I can say with confidence that some people would get very angry with me if I allowed the dungeon to be filled with items just laying around on the floor. Personally I like a clean dungeon Besides from that, if we had no storage then the whole game mechanic to explore and collect treasures from the far corners of the dungeon would be in vein.

(03-07-2015, 01:50 PM)Rasmus Wrote: I am not sure I understand what you mean here, but as I understand it the "queue of these Rooms demands" is something where each room calculate the demand of a certain items etc. and the highest needs gets the item. The problem here is that the "queue of these Rooms demands" are hard enough to calculate for the storage rooms, and it will be way harder to calculate for individual rooms as there are so much more of them.

Actually, right now the game don't care about any room demands at all, when the storage rooms were first introduced I tried to calculate the demand of each room and that got complicated way to fast and the balance were lost, usually it ended up with one room getting all the items and the rest got nothing.

Sorry, I should have been more specific when describing the whole idea.
Now I managed to think about this idea for longer so let me explain it then in details and put some example:

I. Basics
First the idea of in-room storages says that: There's no such thing like Storage Rooms as building to build, they're gone forever in this form, but instead, each Room has it's own storage unit as in-room construction that can be placed in Room by the Room itself or a player l like now it's bed in Bedroom or table and chairs in Bar Room. So all storages are specialized in certain items of the Room they're placed in - so finally you can make for each Room special graphic, so weapons won't be stocked in small squared shelves, but on special racks, gold items in vaults, fish in crates filled with ice, etc. - these are this in-room storage I'm trying to describe and several posts before some of us even put some images for them.

Then it's your decision whether player has to build these or Rooms decides depending on their size or quantity of in-room constructions how much in-room storages will be automatically placed there - (like in DK) - so I see only this solution for what problem you mentioned saying "The only problem I see here is that the storage rooms has limited storage and at some point they can't be expanded anymore".

II. Allocation
In Dwelvers Rooms are not deciding of how much of what has to be delivered, but their in-room constructions (like they're Tables in Bar Room or Brewing Vat in Brewery) decides, because it is in-room constructions that are producers - not same Rooms, so...

Let's say we have 3 different in-room constructions that are placed in different Rooms in different distance between each other - they produces different goods, but each of them requires the same item to produce, let's say Iron Ores - so how the game will know to which of these in-room constructions and in what number has to go those Iron Ores first? Game then makes a QUEUE - each TYPE of Item in the game has it's own queue of in-room constructions.

III. The (holy) Item related Queues
How the QUEUE works? Hmm, different in-room constructions that needs the same resource type probably needs those Iron Ores in different quantity and produce goods from those Iron Ores in different time, right? Let's take a look of these 3 different in-room constructions closely and put numbers for them: 1, 2 and 3:

- number 1 requires 2 Iron Ores and needs 20 seconds to make a good from them,
- number 2 requires 3 Iron Ores and needs 15 seconds to make a good from them,
- number 3 requires 5 Iron Ores and needs 47 seconds to make a good from them.

So queue is being made in TIME and it predicts which in-room construction will get and how many of Iron Ores first, so it makes a super fast calculations and the results are in order (assuming that all started their production at the same time and got all required resources):

1. number 2 and 3 Iron Ores,
2. number 1 and 2 Iron Ores,
3. number 2 and 3 Iron Ores, (it's 30th second of the player's Dungeon production from Iron Ores now here, number 1 is still producing so it doesn't need Iron Ores yet and number 3 hasn't finished his task, so it doesn't need them either)
4. number 1 and 2 Iron Ores,
5. number 3 and 5 Iron Ores,
6. number 2 and 3 Iron Ores,
etc...

First room in queue will be number 2 in fifteen second and then number 1 gets Iron Ores - but it won't get anything until you'll deliver the exact number of Iron ores to number 2, numbers won't change their places in queue even if there's 1 hour brake of empty storages with Iron Ores!
Then when number 2 got those 3 Iron Ores and then number 1 it's 2 Iron Ores, then after them next Iron Ores have to go to the number 2, then again number 1 and so on...

IV. Delivery and Imps

(03-07-2015, 01:50 PM)Rasmus Wrote: I can't make it so that an imp fill his backpack with items that has different target locations. It gets way to complicated, the only time he fills his backpack is if all the items are going to the same location".

Let's change this so. Now until Imp won't fill his backpack up completely or there's no other task about digging resources and so his backpack is not filled up completely I see this algorithm:

1. Going to dig resource block (in our case it can be the Iron Ore block).
2. Obtained 1 Item after digging.
3. Check if there's next resource digging task to do.
- if yes: go to the (next) digging point and start from point 1 above,
- if no: go to the point 4,
4. Search in obtained Item's QUEUE for first in queue in-room construction that requires now that obtained Item.
- if yes: deliver obtained Item to the free space of in-room storage placed in the Room in which is placed demanding in-room construction. After delivering it to there search for any new task,
- if no: search for any new task, but after doing it start from point 3.

What if this Imp has already or almost filled backpack up with different resources?
Let's say that each Backpack can be filled up with 10 items and Imp just got it full. It gathered 6 Iron Ores, 1 piece of Wood and 3 Fish. Imp after getting his backpack full is searching in all queues - Iron Ore queue, Wood queue and Fish queue at the same time and makes his own queue of which of these Items in what number it has to deliver where which queue works of the same rule like queue for Items - but there Imp also reserves slots equal to number if items. So for example in Iron Ore queue the first in queue is - let's take it from the earlier example - number 2 and 3 Iron Ores - that means there are 3 slots that can be reserved. If there was no other Imp who took all the slots our Imp friend can reserve all the slots and the next Imp that will search for free slots in Iron Ore queue will have to occupy free slots from the second on the list of Iron Ore queue.

Of course to not drive Imp crazy like going to the same Room twice Imp's queue is corrected of calculated distance between him and Rooms he has to go, so even if the first in queue in-room construction that needs i.e. 3 Iron Ore - Imp could deliver to there up to 5 or 6 Iron Ores instead of 3 there's demand for - because there can be another in-room construction that will require Iron Ores in the time this Imp reach the Room in which are placed both of demanding in-room constructions. If any in-room construction won't demand more then 3 Iron Ores in the same Room if Imp will be fast enough...well, the Imp still is carrying other resources so if he won't manage to deliver Wood and Fish to their respective storages before demand for 5 or 6 Iron Ores will happen then he will deliver required 3 Iron Ores not 5 or 6 at once.

V. Blue flags are not needed anymore

(03-07-2015, 01:50 PM)Rasmus Wrote: The blue flag is working as a way point where the rooms are linked together, not as a storage location, it is more like a drop point. If we would have in room storage we would still need the blue flag as a dropping point.

Well, now Imps will deliver required item to the closest free slot of any in-room storage in the Room in which lays in-room construction that demands an item from an Imp - if Imp is carrying required Item. Blue flags are not needed anymore because now in-room storages serves for such dropping points, but in more esthetic way.

II. Allocation
------------
The queue is similar as it is now, except that it is randomly distributed instead to all the rooms that may need certain items. So if room A, B and C needs iron ore and a new iron is produced, then it will be randomly transported to either room A, B or C. Personally I like the random part more than the queue part because trying to control it to much can have undesired consequences. Keep it simple is my motto.

Either way, your system can work exactly the same with random distribution as I see it.

III. The (holy) Item related Queues
----------------------------------
This is getting way to controlled in my opinion, I would like to see it simpler. Using random distribution of items will give the player more things to control and experiment with. With the simple understanding that "each newly produced item will get transported to a random storage room that have rooms connected to them that needs that item type" gives the player room to build his dungeon as efficient as possible without any surprises.

IV. Delivery and Imps
--------------------
This is an extremely complex subject. Now lets say that we have the queue's, and an item a imp hold is being queued to a room. Now lets say that this room is on the other side of the dungeon, or other items being held in the backpack is closer, how do you prioritize between queue order and distance? And maybe we should ignore the delivery all together because in 2 seconds another imp will be able to deliver that item type to that room a lot faster. This is something that gets extremely complicated way to fast.

Conclusion
----------
Right now we may not have the most efficient system, but it is very functional and don't surprise the player in any way that makes the game seems broken. So I wouldn't dare to make such a big change in this state unfortunately. I can make small changes that makes it more efficient, but not reconstructing it all, because we will find issues down the road that are bigger than the ones we have now, that I am sure of.

(07-07-2015, 03:57 PM)Rasmus Wrote: II. Allocation
------------
The queue is similar as it is now, except that it is randomly distributed instead to all the rooms that may need certain items. So if room A, B and C needs iron ore and a new iron is produced, then it will be randomly transported to either room A, B or C. Personally I like the random part more than the queue part because trying to control it to much can have undesired consequences. Keep it simple is my motto.

Either way, your system can work exactly the same with random distribution as I see it.

It could, but If this would work random you'll lost the production fluency - by this I mean that if (in-)Room Construction A would need Iron Ore faster then Room Construction B and game choose to send newly gathered by Imp Iron Ore to Room Construction B which will produce item later then A, then production in Room Construction A will be halted and very possibly you'll get a situation - like you wrote before - that it may end up with one Room Construction getting all the items and the rest got nothing - randomness can choose a Room Construction C even 3 times in a row, how could that be efficient way to produce what you want in time in other Room Constructions especially like A that will be the fastest one?

About what we speak it has to be fully automated mechanism of allocating newly manufactured / gathered items that prioritise to where should this item go first to keep your production working the best as it can in actual condition, so optimal.

That's why I suggested queue system in which when room construction needs specific item to be the first who will produce an item from Iron Ore first it will get the first gathered / produced items as first, it's on the top of the queue.

(07-07-2015, 03:57 PM)Rasmus Wrote: III. The (holy) Item related Queues
----------------------------------
This is getting way to controlled in my opinion, I would like to see it simpler. Using random distribution of items will give the player more things to control and experiment with. With the simple understanding that "each newly produced item will get transported to a random storage room that have rooms connected to them that needs that item type" gives the player room to build his dungeon as efficient as possible without any surprises.

Still there you're engaging more Imps to manage storage and the distribution system is indirect - works like it is a warehouse/wholesaler. Direct distribution like I presented shortens much more time of getting ingredients for production from storage. Now it's like:

Storage Room system with randomness:
resource tile --(a long way to Storage Room)--> random Storage Room blue flag place and then item is taken by SR worker on the i.e. Shelves --(long distance between rooms)--> Room Construction that produces something.

In-room storage system with queues:
resource tile --(a little bit longer way then above, but don't need an additional Imp in storage and blue flags)--> in-room storage of the Room Construction that produces something (here worker that produces with the machine just take items needed from i.e. shelve that's right behind it instead of getting needed item from Storage Room which can be close to the worker, but still distance is bigger).

Also imagine that one production chain consists of 3 manufactures, one needs previous one and previous one needs another previous one i.e. Wheat Plant --> Mill --> Bakery - should all of them go to Storage Room making additional distance or they could just go to the next door room or even all of them are in the same room and use the same in-room storage?

(07-07-2015, 03:57 PM)Rasmus Wrote: IV. Delivery and Imps
--------------------
This is an extremely complex subject. Now lets say that we have the queue's, and an item a imp hold is being queued to a room. Now lets say that this room is on the other side of the dungeon, or other items being held in the backpack is closer, how do you prioritize between queue order and distance? And maybe we should ignore the delivery all together because in 2 seconds another imp will be able to deliver that item type to that room a lot faster. This is something that gets extremely complicated way to fast.

Here game like I said makes predictions of which Imp that was ordered to gather Iron Ore will came first to 'the most needing Iron Ore Room Construction' - item queue calculates every Imps movement speed, actual distance between Iron Ore tile that it is going to dig out, time of digging and then distance between the Room Construction and Imp position - in results item queue choose the fastest one who will be in 1st needing Room Construction - but what if player suddenly mark another tile with Iron Ore that's much closer to that Room Construction? What also about the Imp that had been chosen by game as the one who will be the fastest, but now other Imp will be faster?

The one who was the first, but ATM it doesn't because of sudden mark will jump into the next Room Construction in that item type (which Imp is carrying now) queue and so every other Imps that are being right behind the former the fastest Imp will jump down by one - it's like inserting a new empty column in Excel in the full table. Game so has to make calculation, make a refresh of itself in every i.e. 1 second so it can add sudden events - like death of the Imp or obstacle or whatever suddenly created that slowed down the Imp.

What if that was the only task where was Iron Ore needed and now Imp is not needed with that item? Well then Imp just go to a nearest in-room storage that would need held Item of Imp in the future.

(07-07-2015, 03:57 PM)Rasmus Wrote: Conclusion
----------
Right now we may not have the most efficient system, but it is very functional and don't surprise the player in any way that makes the game seems broken. So I wouldn't dare to make such a big change in this state unfortunately. I can make small changes that makes it more efficient, but not reconstructing it all, because we will find issues down the road that are bigger than the ones we have now, that I am sure of.

Like I said actual system requires more workforce, make a mess on the Storage Room floor, adds additional micromanagement with blue flags and makes production chain working slower because the distance between needed to production item and manufacturer is longer - in real life entrepreneurs do whatever they could to make distribution of their goods direct because it saves time and resources.

The system with Storage Rooms reminds me distribution system in ANNO games, where manufacturers goes to marketplace and takes newly manufactured good (if won't take it directly from the source), but there resources are not allocated in each marketplace separately, but every item is summed into the one sum of that item type and it doesn't matter where each of them were placed - in Dwelvers it very does matter.

In multiplayer mode everything is being played much faster then in single player gameplay, time is the key to victory and shortening time of production can be vital and player will need to have everything under control not random.

i skimmed thru most of the posts, but didn't laboriously read them all, but thought i'd add my 2cents into the puddle.

when playing 9d, i found that with additional storage rooms i had to link the new room storage room to the metalworks room in order for the metalworks room to produce crafted goods, and hence have those materials stored in the new storage room. This however caused my food production to stop as there was no wood to fire the ovens coz said wood was now stored in the new storage room to fire the kilns.

Rasmus mentioned that he'd like players to be able to set options via mouse clicks in the menu's, and so i thought about this a little bit. In the storage room info menu, you can choose which items get exported from the storage room. This seemed counter intuitive as generally you want to click the items you want to store rather than the items you want removed from storage. And so i had to think backwards. Build the new storage, goto the mother storage and select the items i want removed and ferried to the new storage room. what if the mother didn't have this option.. isntead all items are automatically stored at her, and only upon building a storage room, you could set which items you want stored in that room (ie arrows point inwards instead of outwards).

Rasmus mentions in his posts that he's keen on the randomisation of storage. Thats fine.. i don't mind that, but would like to see the mother have a cap on storing one particular item. If the mother can accept any and all items, then assuming new storage rooms have an item set for storage, then the overflow could be directed to the new storage room. In this way the mother is still providing raw materials to the main productions close to her, with any overflow of goods being sent to the new storage room.

* Imp finds bunch of loot on the ground of various types...loads up his backpack and ferries it to the mother, and dumps it at mother. Imp can carry multiple items of different types coz imp is only carrying it to mother.
* Imp finds a bunch of loot on the ground of one type. Imp checks mothers item cap for said item. Imp looks for alternative location, imp finds alternative and ferries to alternate storage location. If more than one, then imp randomly determines which is sent based on storage room cap availability.
* In either case, imp arrives at storage location to find storage cap full. imp dumps items on ground at blue flag. Blue flag may get an assortment of items piling up, but not overly so as each imp will have checked cap upon finding item before transporting it.
* Imp finds a bunch of loot on the ground.. checks storage locations for space.. finds none.. moves on.. leavving it on the ground. This will alert player to the fact that more storage is required.