9 Dayz started as a Jam game. I coded the first version of that game in only 1 month - rushing everything to a state where the game was playable. The inevitable result of such a rapid development was a code that can at best be called "pragmatic".

With the following example at hand, I want to demonstrate, why refactoring and restructuring your souce codes after such periods of rush and hectic  makes sense.

Crafting

In 9 Dayz you have several crafting options. All these options have certain requirements represented  by crafting recipes. Basically a combination of simple items is needed  to craft more complex items - nothing new here.

The following lines are showing one part of the old implementation, controlling the availability of certain crafting options (activating the buttons in the UI above). The mentioned requirements I hardwired directly in that piece of code - a fast and pragmatic approach.

The problem

These lines above can be read easily and straight forward, are quickly written down and do their job pretty well.

But they represent only one part of the crafting logic. In another place, there are codes for actually crafting the item. And there, I have hardwired the same requirements again, just in another context (what new item needs to be added after crafting, how is it added, which items need to be removed from inventory after crafting).

Next I want to implement an in-game help, containing a chapter for presenting all crafting options (what items can be crafted, what items are needed, what is the result).

So this would be the third place where I would have to hardwire my crafting requirements again. And the story would just continue like this.

Following such a code strategy for adding new crafting options, or even worse, changing and introducing new logic, is error-prone and tedious.

The solution

With my refactoring I extracted the multiple hardwired requirements into this single craftingRecipes configuration object.

Next I was rewriting all the codes involving crafting requirements and crafting results.

The example code from the beginning in its new form processes the  craftingRecipes configuration object, instead of hardwiring all the crafting requirements. I did similar refactorings also for all the other crafting codes involved. And not only here - I am following this strategy in a broad sense, for many aspects of my game.

The code is not that easy to grasp any more   (also because some tricky OR requirement logic is involved in the 9 Dayz crafting system) - general, adaptable solutions often come with such an inherit code complexity.

But the benefit and improvement is a big one: from now on I can add new crafting recipes to the configuration, they get instantly processed and deliver the expected results. Not only in the code section above, but in all places where crafting aspects are already implemented or will be implemented in the future.