Timber is an Isometric 3D survival game where you play as a lumberjack in a magical forest tasked with collecting wood for the village whilst also befriending the mysterious creatures that exist within the forest. It was made by a team of 6 which consisted of 3 programmers, 2 artists and 1 designer. I was the head programmer for the team and was responsible for building most of the game systems and implementing them into the final product. The game was made using Unity which would be my first time using it and the C* scripting process.

The GitHub (https://github.com/KingSaturn/TDemo-5-Timber) shows all of the developments I made across this project but to summarise, the code I contributed was as follows:

• A stats system to calculate health, damage, speed and other values

• The movement of the camera attached to the player

• Implementing and modifying the rendering pipeline (Universal Rendering Pipeline) and other volumes

• Loading between scenes

• Saving between scenes

• Implementing the attack functionality in the player and mushroom

• Implemented the title screen with buttons

• Added pickup-able items that worked alongside the inventory system created by Tom

• Implemented a pause screen

• Implemented talking NPCs

• Added interactable trees that drop items when destroyed

• Added health bar functionality

• Combining systems others had made such as stats for inventory or damage for the axe

• Fixing / improving parts of systems made by others

I created a saving function that saves every time a load zone is entered. This saves all relevant data into a .txt file in a JSON format. Whenever this file is present, upon loading, the game will load all relevant data into whatever script requires it such as the inventory, character or NPC's. Doing it this way allows quick and easy saving to happen whilst also allowing new attributes to be added in the future (Sharma, 2014). The downside to this is that states of dynamic objects cannot be stored in its entirety as JSON only allows serializable variables to be stored such as integers, floats, strings or bools (Spector, 2018).

For movement of items and the spirits, I incorporated a sin function combined with time. This allowed me to create a smooth wave whilst also multiplying certain elements to change the speed and shape of the wave, the first multiplication controls the speed of the wave whilst the second controls the height. Doing this creates a smooth hover that is found in many different games by using a simple mathematical function (Sine Cosine / Examples, n.d.). 

For class info such as health, attack and speed, I used inheritance on a base class that provides basic health and damage to allow modifications for other classes to account for elements such as UI for health bars and different death or damage methods. This is very flexible and is used commonly in Object Oriented Programming which is the framework Unity C* provides. (Yeager, 2014) 

Alongside this, I had to deal with many bugs and errors formed by combining both my systems and the systems from the other 2 programmers.

One fix was the broken axe throw that didn't allow the axe to be thrown a variable distance. I fixed this by properly implementing the timer and using it to calculate the throwing power.

Many glitches happened due to setup in the Unity Engine rather than scripting errors. For example, the mushroom randomly did inexplicable movements as a result of its hitbox being slightly clipped through the floor or trees had no collision due to colliders or rigid bodies not being applied properly. There were also many import errors brought about due to improper use of the Git repository, forcing me to manually import work made by others.

In my opinion, I believe the development of this project was mostly flawed and the game we created was subpar to what we could have achieved.

Our teamwork for this project very poor when compared with what is normal in the industry. We had a timetable that was used to mark our hours however this was mostly unused. Not only this, but there was no agile workflow implemented such as Scrum or Kanban (How to Make an Agile Workflow for Your Team, 2022). This meant work was spontaneous and no plan was followed outside of the design brief we created which, as said before, was too ambitious to ever see completion. I personally would've preferred to use a scrum workflow, which would allow us to choose a topic to work upon and give updates after a set amount of time. This could've fit into the weekly meetings that were planned and allowed everyone to track each other's progress and work more as a team.

The games concept originally included more than 5 areas with a main questline alongside multiple side quests, roughly 10 enemies that each had different animations and attacks, boss battles with the large ents that govern the forest and an ethical system that rivalled the quality and expanse of the system from Undertale. As a rough estimate, the designs we made would've created a game that is similar to Stardew Valley in content. To create this scale of a game within 4 months with the little game development and teamwork experience we have is completely unreasonable and is part of the reason why I believe this game is largely a failure.

The final game we created has a few interesting graphical and technical features but doesn't achieve much as a complete package. The art of the game looks passable other than the grey default boxes used for some assets that didn't get fully textured. However, there is a lack of an overall style with models such as trees and bushes having minimalistic textures, the humans and buildings having cartoonish textures, and the ground having semi-realistic pixelated textures. This combined with a mixture of default and designed UI leads to the game's art looking very unfinished and poor compared to a complete package.

Some impressive technical elements were created such as the working inventory with rearrangeable slots, spawned items that spin and contribute to the inventory system and a functioning projectile weapon that can do heavy damage to enemies. The saving feature also helps to make the game feel more complete as it allows the player to continue at a later date rather than losing all progress. Yet there were many technical improvements that could be made. Firstly, we should have implemented a bug tracking sheet that allows anyone to playtest and submit bugs. This would help us identify issues that some would probably miss whilst playing and allow us to more easily identify the problem rather than searching for it. Another issue with the technical side was the Git repository we made was largely unused for any source control elements (What Is Source Control and Why Is It Important?, n.d.), instead it was mainly used to upload scripts similar to the google drive we created. With better use of branches, merging and locking, our team could have all worked in the same project at the same time, increasing productivity and efficiency. We could have then used our time more effectively to add more content such as new areas, new enemies, new items, potential quests and more interactivity to create a realistic gameplay loop rather than cut down trees to give to the ent.

Though I am not proud of this project, I will concede that we did manage to put out a product that roughly aligns with what our brief stated and with more time and better planning, we could meet the full expectations of this project. I am also personally proud with how fast I was able to learn how to use the Unity engine especially as a beginner and have learnt it's strengths and weaknesses when compared to Unreal Engine 4. The TDEMO module as a whole has taught me many different improvements and drawbacks that occur when working as a team on a game and will prove useful in future years and jobs when I have to work in a group environment.

How to Make an Agile Workflow for Your Team. (2022, March 3). ProjectManager. https://www.projectmanager.com/blog/how-to-make-an-agile-workflow

Sharma, R. (2014, November 21). JSON - its advantages and disadvantages. Ezeelive.Com. https://ezeelive.com/json-advantages-disadvantages/

Sine Cosine / Examples. (n.d.). Processing. Retrieved 21 May 2022, from https://processing.org//examples/sinecosine.html

Spector, D. (2018, April 30). JSON Data Types. REST API Tutorial. https://restfulapi.net/json-data-types/

What Is Source Control and Why Is It Important? | Perforce. (n.d.). Perforce Software. Retrieved 21 May 2022, from https://www.perforce.com/blog/vcs/what-source-control

Yeager, D. P. (2014). Object-Oriented Programming Languages and Event-Driven Programming. Mercury Learning & Information. http://ebookcentral.proquest.com/lib/portsmouth-ebooks/detail.action?docID=4895089