Further development on the Order System

This week our team further developed the order system, both practically and visually. Through our own experiences testing Sword Smithy we found it necessary to add a decline order button but also an order request button.

Decline Order button

the decline order button works like it sounds, it declines orders that until recently clogged screen-space until they were accepted.

Order Request Button

Instead of  having the customer chat box randomly popping up and getting in the way, which we found annoying during testing, a less intrusive order request button is activated which triggers the customer dialogue on click. 

Super Fun Data Structures Segment

A big task for this week was planning and implementing the data structures for storing order data. This involved the classic strategy of writing on a whiteboard:

The list data structure was chosen for storing the order data, as items can be easily added and removed from it. There are 3 separate lists for the active order data: the order object itself (orders), the contents within the order (swords), and the customer who made the order (customers). Each index corresponds to a specific order, meaning that orders[i], swords[i], and customers[i] all refer to the same order. Every time an order is added, its data is added to each active order list and when an order 'i' is complete, the item at index i in each list is removed. This system is effective because it allows us to store all the data we need on each individual order, making the project more scalable. For example can use it to create unique order tags and trigger customer specific dialogue when an order is fulfilled or failed. 

When the player finishes their sword and chucks it in the 'done' chest, the list of active orders' content (swords) is traversed. The orders' content list stores a list of swords at each index (yes it is confusing), as each order boils down to being a list of swords. The list of swords at each index is traversed (from oldest to newest), and if a sword in that list matches the player's crafted sword it is removed. If the sword list at that index 'i' is empty after removing the matched sword, that means the order is complete and the order at index 'i' is removed on all order lists. This checking system has a time complexity of O( N x M ), where N is the number of orders and M is the average number of swords in an order. Hopefully the following diagrams explain this better than words can!

Diagram of the active order contents list (the dreaded list of lists!):

Diagram showing the list traversal when the player submits an iron axe:

The below gif shows this system in action. The orders list and customers list are shown in the inspector (unity doesn't show the active order content list as it is a list of lists). When the order for the customer Asakura at index 1 is fulfilled, the list items at index 1 are removed:

The result of this is a reactive UI that shows the player all of the current active orders and their details:

Fleshing out orders

During previous weeks, each customer would share the exact same order; a basic sword or two. Whilst this is a good system to have for debugging, it has two primary issues - firstly, and the most obvious issue, is that this will lead to the game becoming ultra-repetitive due to a lack of variety, but it also means that a character's personality won't be as fleshed out. Different weapons have different properties, and people who order certain weapons will likely have their personalities reflected in their choices. Take for example Darlington - a man who believes he is incredibly strong and has a "secret power." As of such, he will tend to go for the more typical item of a common sword. However, due to his recklessness, he often breaks them, leading to him requesting more and more weaponry. Asakura on the other hand is the leader of her shogunate, and as of such will only request items of high value. 
As more and more weapon types will be added throughout the development of the game, this will lead to more opportunities for different weapon types and combinations to be programmed in, making customers more and more unique as a result.

An example of a customer order, in this case, Darlington's. Each order is numbered to help with organisation.

Art Progress

Ingot quality is now indicated by the shader applied to the ingot material, the more shiny an ingot is the better quality it is, therefore rewarding the player more for smithing a sword with better ingots.

Here is an example from left to right of a poor quality to excellent quality ingot.

Since the table model was very much a placeholder, a new model has been made for this asset which fits the game world much more nicely.

The three additional weapons have seen a visual improvement to make sure that they fit the game world more.

Each ingot type has been added to the game with each ingot material associated with it, the player can now hover their mouse to see the ingot type, as well as an indication of the quality of that ingot.

Sharpening stone animation has been added which really adds a sense of immersion into the world.