Hello GuildMestars,

Today I have a deep dive prepared for one of 0.1.3.0's primary features, Repairing! The repair system brought some much need functionality to an existing odd but necessary system. While the changes are quite a bit different from the old system they still provide the original intention at a much more interesting level.

Items play a key function in the game in that they allow a resourceful GuildMestar to shore up the weakness of a specific character or the party as a whole. As they provide such a powerful function it was necessary to limit players use while avoiding the common issues plaguing consumables in most games. At first this meant high accessibly with trading and dungeon loot but once the player had acquired several items how would they then be encouraged to continue the cycle and facilitating the economy loop?

The idea of durability came up early but simply adding another stat for the player to keep track of was uninteresting and once again created a fear of using an item at an un-optimal time. Having a look at the idea again the thought of repairing items was brought up but we didn't have a good way to implement it at that time. With the introduction of update 0.1.2.0 (Construction Part 1) the groundwork was laid for new NPCs and their functionality to be added. With this, repairing started to become a reality.

Drawing heavy inspiration from the Ceremonial Smithing minigame from the popular MMO Runescape a base was formed. We knew that while the minigame was enjoyable several things had to change as they simply didn't fit our game. While the original version contains several patterns they are presets and are only for shaping blades. As our game contains a wide variety of items, tags were set into place for the repair system to check when deciding what pattern to display and random values used for the target piece to provide more variety of gameplay when repairing over long periods.

At first these seemed like good changes as they did provide interesting values and... unique patterns, but a major issue was present. When drawing the values the system checks how the current refinement value compares to its neighbors, adjusting the curve and creating a look that reflects the amount its been worked. With entirely random values a target piece could generate with wild abandon creating something completely unfit for use and physically impossible. Two fixes were put into place to combat this, a mirroring system and neighbor range. In addition to their regular neighbors, action locations could now have mirrors creating a more symmetrical and thus realistic piece. To combat their wide generation ranges a limit was placed on how far a neighbor's refinement value could differ from each other. Ultimately this achieved random but tame outcomes, while still leaving in the possibility for more interesting targets to appear.

Additional major changes include action values displaying their next magnitude in order to give the player a more deterministic outcome as well as provides strategy in saving certain values for later. The strongest action "Wild" was also provided an area of effect action magnitude of 1 applying to its neighbors. This provides the player a much higher action value with the added caveat of future planning in order to fully take advantage of this power and not accidentally overwork your piece.

Lastly just for you super nerds I want to talk about how target and blank values are displayed. Without knowing how the original inspiration displayed their refinement value curves my initial thought were bezier curves. These curves are easy to calculate using a neighboring 3 point system and could be leveraged to mask the foreground vs background material. Unity does provide the native ability to mask line curves however this unfortunately only applies to sprites whereas we needed this to apply to UI Images. Rather than attempt to rewrite this code a simpler but much odder solution presented itself, sliders.

Sliders provide exactly what we need, foreground and background images as well as a sprite whose position can easily and reliably be altered. Using sliders each action location was assigned a slider whose value updates based on the refinement value of that position, then the sprite representing the slider's handle changes to reflect it's neighbor's values. Though a bit silly to explain it worked out rather well and removes much of the overhead that could come with rendering multiple masked curves.

Thank you for listening to my Guild Talk, I hope you enjoyed learning a bit more about what goes into adding some new features as well as the troubles we run into. Anyone who got this far and is looking for more information on the next update, I don't want to boast but I think everyone will have something to tryout sooner rather than later.

Signed,

StrangerTod - OffPath