The data is stored in the Colony and all relevant classes will implement INBTSerializable and their data will be stored in the colonies NBTTag.
All non fullfillable request end up at the player.
Most data can be cached when the overall state of the Colony changes (request completed, building added, building upgraded, worker added etc)
Due to the fact that the new system supports multiple Warehouses I would propose adding a small Warehouse to te Townhall to get the Colony started. This would give the Townspeople a place to store stuff.
Appending to the proposal under the first section I would suggest adding the capability to store and retrieve stuff from warehouses to all workers as long as no Deliveryman has been hired to do this job. Adding this feature would in my eyes still be balanced, workers that are bringing and collecting goods form warehouses, are not doing their jobs.
A request for Items is being made to the active Players. To do this i would suggest a multi tier system. First tier Worker calls his requests out to players in the Area. Second tier a billboard style building. Third tier a Newspaper like system that keeps the user dynamically up to date.
Warehouses will become filterable, if the request can be fullfilled by a filtered warehouse that takes priority, else the warehouses closest to the requesting building will fullfill the request as much as it can, then the second closest, etc.
When a request is made, it can be chained, fullfilled or put on hold. Full filling a request means that the requested object is available and will be delivered to the requester. Chaining meaning that a request is being forwarded to an other worker, except for a Deliveryman who gets requests that can be fullfilled directly, who can fullfill the request by what ever means necesarry, aka crafting, mining, etc.
The worker closest to the requester will fullfill the request, even if it is not the cheapest. (A way to simulate the economy of a Colony having more then one aspect)
One thing: First comes first serve!
The delivery is marked as non complete, and defunct. It will be rescheduled to a other delivery man, if he exists, if not the worker requesting the delivery will have to complete it himself.
----- NOTE: It is possible for Entities to vanish in thin air (External Manipulation), we should track if the Entity still exists regularly. A good way would be to implement a progress report on the delivery every so often and Track the Entity that way. WARNING Weak coupling of the Entity required MEMORY LEAK!! -----
The delivery will be trashed if it is not part of a request chain, but made for stock. If the Warehouse gets close to full a report will be made to the user to either build something like a trashjard where items slowly degrade over a periode of time, or build a new warehouse.
Updated the use case study with new information.