In this project I coded the shopfront. This had 5 features: a random customer sprite, randomised request texts, a to do board that appears and disappears with a button press that has 6 random order slots and a simple temporary drag potion code that was used while I didn't have access to the other coders inventory system.

This is the drag potion code. I also used it to store all the randomisers in the same place. I stored all my randomisers in the same place because all of the randomisers are triggered by the correct potion being given to the customer and so by doing this here I can link all the other scripts to this one which is a lot neater and creates a lot less redundancies than if it is done in their respective codes. I struggled with coding this due to the complexity of so many different files needing different variables and so this is where visualising my data was very beneficial. Doing it this way is also supported by the concept of "separation of concerns" which is a design principle that describes how software is divided into modules based off the functionality they perform. (Halpern, 2019)

I had an issue with the code randomising to the same sprite twice in a row. To fix it I added a while loop that checked to see if the new random number and current random number are the same and if they are, to get a new random number, until the two numbers are different.

I used a for loop to randomise the potion asked for on the order board. This made it more efficient than having to make a different switch case for each of the orders.

I used a for loop to randomise the potion asked for on the order board. This made it more efficient than having to make a different switch case for each of the orders.

To draft my code during this project I used flowcharts a lot. This helped to give me a better insight into what I was coding and helped me to visualise it better, resulting in much more efficient code and less debugging due to code logic not working as expected (Hunt & Thomas, 1999), than if I went into coding it without any sort of plan.

Most of the things I would do to improve this code would be to do with making the code more efficient. For example, for the code that helps you enter and leave the to do board, instead of setting each object to true or false in the procedures it could instead do something like this, which would have dramatically reduced the amount of code needed for the class, increasing both efficiency and readability:

bool orderTF = false;

      void Start()
      {
        orderTF = false;
      }
      
      public void launch_orderboard()
      {
        if (orderboard.active == true)
        {
          orderTF = false;
        }
        else
        {
          orderTF = true;
        }
      }
      
      void Update()
      {
        orderboard.SetActive(orderTF);
        order1.SetActive(orderTF);
        ...
      }

With this project, I was happy with how I fixed the randomiser to not be completely random, so that players couldn't get back to back repeats. However, in future I would like to spend more time thinking more about better ways to execute things in a more efficient fashion, which can be figured out a lot easier with things like the flowcharts that I used in this project. Therefore, I will continue to utilise these in planning my code in future. Another thing I think I could have improved on is my use of comments and try to use them more often in future.

Bibliography

Hunt, A., & Thomas, D. (1999). The Pragmatic Programmer From Journeyman to Master. Addison-Wesley.

Halpern, J. (2019). Developing 2D games with Unity: Independent Game Programming with C#. Apress Media. http://ebookcentral.proquest.com/lib/portsmouth-ebooks/detail.action?docID=5606699.