Personal citizen Crafting - Integration into the Requesting System

A quick Intro:

For what project is this:

This a Post which talks about the integration of the Crafting System that has been introduced into Minecolonies and its RequestSystem counterpart that controls intercolony communication.

What is the RS?

The RS stands for RequestSystem and is a mostly Tickless Statedriven BlackBoard system that I have developed for over a year now, with as primary goal, to enable communication between a citizen in need and the rest of the colony. It's primary feature is that it decouples the actual requester from the, what is called, the resolver (the citizen or building that fullfills the request).

How does it work:

The RS takes incoming requests in the form of the IRequestables (a marker interface to detect and handle type searching) and analyses them, by passing them allong to resolvers that are known to it in multiple stages.

Personal Citizen Crafting:

As @raycoms described in hist Post we recently added a new capability to citizens: They are capable of crafting small things themselfs, how this actual crafting works is described in his Post. My Post will be about the connection to the RS and how it determines if Citizens need to craft something, or if the Warehouse should resolve it.

A comparison of the functionality with real life:

During this post I will compare several of the functionalities of the RS with a buy on a site like Amazon. You order something online and it will come to you by post.

The players:

A quick introduction into the required classes ahead of time:

The heavy lifter:

This class is the resolver that works with the request system to determine if the citizen can fullfill a request by crafting and if so, what is required. In our analogy you could compare this to a factory or producer of goods that are offered on amazon.

The shadow player:

Since we want to use most of these mechanics in the future for our dedicated crafting worker. Most of its logic is however abstracted away into the following class: AbstractCraftingRequestResolver
This class is responsible for most of the logic you would expect from something that handles crafting in Minecraft. It determines how often a craft needs to occur, and it will ask the request system for the requirements to perform the craft itself. Comparing this to our buy at Amazon, you could say that all producers have certain things in common: They need other stuff to produce your order (nothing can be made out of thin air, neither can here). Which is exactly what this class does, determining for Amazon what the producer might need.

The Controller:

This is the central endpoint for the RequestSystem API.
This class functions as the IO-Point for the RequestSystem. It controls how and when data is changed. Also it is responsible for managing the DataStores. But more of that in a second Post.
Compared to our amazon this is the website and your postbox in one. Simple and light.

The Puppetmaster:

This is the class that actually performs the logic that controls the RS and its functionality. (Our amazon and post office in one, with a bit of you mixed in for good measure.)

So how does it exactly work:

Well lets keep our analogy going shall we. We order something. Say a game of some sorts. You will ask amazon who can give you the game. And amazon will tell you R1, R2 and R3 might have it, it will even sort them for you on several priorities. This logic is also applied by our RS: It will search for resolvers that can fullfill the order and sort them. While you are browsing through the site you go from top to bottom and see that the first two (R1 and R2) do no have it in stock. Comparing it to Minecolonies this means that both the citizens building and the Warehouse do not have the stack. Ending finally up at R3 you see that he can send you the game in 1 Week since he has to make it. So you order it since you really need this game.

Now R3 tells amazon well i need some stuff to make this game: Namely a DVD, a Hull, and some paper. And R3 does exactly the same as you do: He opens up amazon searches for the requirements and orders them. The RequestHandler (our puppetmaster) does this too: Once it finds a resolver (R3) that can resolver the request (our Order) it will ask him what he needs. And it will then recursively also try to fullfill those requests, by starting all over again.

So we still need to store some data somewhere so that we know who wanted that game. You could compare with it with your address on the label of the postoffice box in which the game is send to you. You may also want to see howfar your order is coming along online. The RS does the same: It puts a citizens IRequestable into an IRequest and uses that to track address, progress, and even requirements to display in the UI and in chat.

Why was this integration made:

We did not want the citizens to craft all the time. On the other hand we did not want to code all the logic for the entire colony structure (aka what buildings are in the colony and what can they make) directly into each citizen, that would be hard to maintain. So the RS was born and this connection was made to first check the buildings inventory, then the warehouse and then start crafting.

A foot note before I leave

The RS seems to be insanely overkill to make a simple crafting system. However the RS is designed to be a general Purpose solution (as stated it is a BlackBoard) for inter- and intra- colony communication. As such this solution is capable of so much more then just crafting and we will see in the future were its limits will be.

Greets,

Orion.

---

Posted on Utopian.io - Rewarding Open Source Contributors

---