Hey everyone, we had some reports incoming about unsatisfied users with our cook and smelter, and while I was looking at their code I noticed that on an abstract level 90% of their code is supposed to do the same thing.
Basically, both have to request a fuel, both have to request something to put in the furnace (food or ore) and both actually have to put and retrieve it.
First of all, this change was extremely successful in two ways:
- Way less code than before:
- Workers seem to work way smoother than before
To achieve this I did it in two steps:
- Abstract the Building
- Abstract the AI
The Building
Let's start with the easier one.
Previously we had in both buildings the list of furnaces.
I, therefore, extracted the code from the Cook and Smelter into an abstract class, including the code to manage it (Getter, Setter, and Persistence).
And then I had the Cook and Smelter extend it.
Now both buildings are able to retrieve it without needing any specialized code.
And, when I create another furnace user I only have to extend this to get the functionality.
The AI
The Ai was a bit more complex.
First of all, I moved a generic predicate of what they need and a generic position over (The smelter already has something similar).
Then when an Item is needed
It will get the smeltable of each worker
Since they have to override this functionality in order to implement the abstract class.
This way we get generically what exactly they need.
And then on request it will go through a generic method which will try to obtain the generic item from the building, whichever it might be.
Besides that I also generalized the way we check if we can start smelting:
In short words, we check if we have fuel and smeltable in the furnace,
or we have smeltable and fuel in the furnace, or both in the inventory.
If any of the three are correct for any of the furnaces he will start using the furnace. He will remember which one to use using the position.
And since, how I explained in the previous part the building has the furnaces in the Abstract class we can get it without having to worry about the exact type of the building (Cook or Smelter, or any other in the future) since they'll have to extend from the abstract class.
Additionally, we had to make sure that the workers are able to execute any tasks before or after the default smelting task. For that I added:
Those are called before the actual action is taken and after the default action has been checked.
Each worker which requires any additional action can then override this, like the smelter:
Which checks if he can deconstruct tools if he doesn't have to put anything in the oven.
I hope you liked today's rework.
See you another time, =D
Posted on Utopian.io - Rewarding Open Source Contributors
Thank you for the good information.
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
Thank you for the contribution. It has been approved.
You can contact us on Discord.
[utopian-moderator]
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
Inspired report in a method ...
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
good shering @raycoms
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
Hey @raycoms I am @utopian-io. I have just upvoted you!
Achievements
Community-Driven Witness!
I am the first and only Steem Community-Driven Witness. Participate on Discord. Lets GROW TOGETHER!
Up-vote this comment to grow my power and help Open Source contributions like this one. Want to chat? Join me on Discord https://discord.gg/Pc8HG9x
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
which programming language used here??
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
It's java
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit