Refactor recipes

[Samasaur1]

The way that construction recipes are currently handled is as follows: https://github.com/Samasaur1/CityManagement/blob/7a0404a9fb8dd511df91b7d2e4af0244278fdb4f/src/main/java/com/samgauck/CityManagement/Economy.java#L15 https://github.com/Samasaur1/CityManagement/blob/7a0404a9fb8dd511df91b7d2e4af0244278fdb4f/src/main/java/com/samgauck/CityManagement/Economy.java#L57-L68 https://github.com/Samasaur1/CityManagement/blob/7a0404a9fb8dd511df91b7d2e4af0244278fdb4f/src/main/java/com/samgauck/CityManagement/Economy.java#L93-L95

This is kind of horrific.

Also, it doesn't work well. Consider #35. To be a 19:1 ratio, you need to either use fractional pieces (no) or produce 20 at a time (yes). In order for the game to determine that it needs to give out 20 at a time, it needs to add the ratio together. This doesn't seem so hard, and it's not, but what if constructing some material doesn't give out the sum of its parts. For example, suppose it takes one X and one Y to create 1 Z. The system wouldn't work.

What I'm proposing is an inner class to Economy called Recipe. This class has a requirements Resources property, and a results Resources property. While the implementation may change, this idea should stay constant.

Note that this structure allows us to add more information to construction, such as the amount of time it takes to construct something. (subclass Recipe to make SteelRecipe, which has a static number of days to make and an instance property of when it will finish)

[eknuth1002]

Is the idea that 19 iron to 1 coal produce 20 steel? Shouldn't that produce 19 steel?

[eknuth1002]

I have a possible refactor in mind that could work the way you describe, but I won't be able to work on it until this weekend. I will create a pull when I get it.

[Samasaur1]

Yes, it should be. But that's still not possible until the recipes are refactored