Cheffin' it Up

Introduction

The goal of this project was to create a 2D Top-Down game with multipictive mechanics, providing a full gameplay experience. I really wanted to focus on the mechanics of this project, and ensure they are not only robust but fun to play around. This want lead to me coming to idea of taking inspiration from vampire survivors, as the horde survivor genre of games creates opporunity for a playground in where the players can freely interact with the mechanics.

The focus of the games development went into the crafting system, shooting and high score save system. Each of these forced me to tackle problem solving outside of what I already knew, to not only complete the project but also too create a product I was happy with. This was a solo project, I had the responsbility for all the games coding and design, art and assets belong to their respective creators.

Crafting, Items and Inventory

All three of these systems are built around Unity’s Scriptable Objects system. Scriptable objects are useful in reducing a projects memory usage by avoiding the need to create many copies of the same values as it allows for singular copy in memory that is used as a reference for the stored values.

Due to the nature of creating a ‘horde-style’ game with constant item instantiations, performance was a key factor to consider and wanting to use my project development as a means to better understand the unity engine all roads pointed to the use of Scriptable Objects.

The crafting system itself uses the objects ‘name’ variable to run a string search against an established cooking recipe list. These recipes are written as such, “WheatMeatCheese” with each being changed to match the given recipe. This system could be improved by allowing flexibility in the crafting process, rather than having to place items into specific slots, this is something I hope to rectify in the future, the method used was picked as it matched with the already established systems along side the use of scriptable objects.

The inventory system allowed me to interact with Unity’s interface systems. Namely the IDragHandler & IBegin(/End)DragHandler interfaces. Interfaces define functionality within a Unity Project, the three I mentioned are pre-built interfaces that define drag & drop functionality, this isn't a simple copy and paste job however, these interfaces simple provide tools to simplfy the creation of systems and using these tools I created a dynamic inventory to crafting item swap.

Code - Inventory

Shooting

Early into development, the arrow keys were used to fire the player’s weapon. This meant that the player could only fire in up to 8 directions, this wasn’t ideal for a game where threats can approach you from any given direction. I had to make the decision to implement mouse shooting, to better suit the overall design and game feel.

From talking to peers and lecturers, I came to the hard conclusion that it wasn’t a simple transition from one to the other. I needed to understand a certain level of vector maths. After a lot of research and a lot of trial and error, I came to understand that I had taken a wrong approach to applying what I learnt. I couldn’t simply add it onto what I had already created, I needed to create something new.

This led to a much smoother development, the system came out with very few hiccups that I cleaned up throughout the project. I had been treating the player as the firing point, however what was needed instead was a disembodied component that rotates around the player, almost acting as a invisible gun for the projectiles to be fired from.

Code - Shooting

High Score

To provide a true gameplay loop, I wanted to add more player incentive outside of just playing the game. This started as a simple scoring system, the player gains scores for certain actions. Including; crafting, survival time, and monsters killed, which would then be totalled throughout the playtime before being displayed on the final screen. This was an incredibly simple addition that I added early on, but as the games development was coming to an end, I came to realise I should try to do more with this system.

After talking to lecturers about how I could add to this system, I was given multiple options of how to approach a system such as score keeping. The use of a database was too complex within the time frame I had left on the project, however the use of writing to file was exactly what I was looking for. This is a common approach to game state saving afterall. The Unity Engine has an implementation of JSON (JavaScript Object Notation), making it easy to seralize/deseralize data to store game states locally on a players PC.

What this really means is a convertation between C# objects/structures into JSON format, and vice versa. Having such a short time frame to research and implement JsonUtility into the game, I was lucky to find that JSON is built to be easy for humans to read/write, and simple for computers to parse the data. Using JSON I created a High Scores system, where a players 10 highest scores is saved, this is then wrote to a .txt file locally on the computer to be displayed on the main menu.

Code - Score Management

What was Learnt

This was the first game I had developed start to finish within a game’s engine, and as such it was a major learning experience. Despite having coded for years this was the most freedom I had felt to create within education, for better and for worse, and due to the solo nature of the project I found myself under/overestimating the scope of the project constantly. On that front the greatest lesson I learnt throughout the project was planning, while I had plans for the project, I had underestimated how every component I wanted to develop was so much easier to work with once I broke it down into digestible segments. Decomposition has been a principle I have learnt about for years, it was here where its usage finally clicked, and I found the project to feel more like a puzzle to be solved rather than a labyrinth that I could run headfirst into.

This was massively assisted with communications amongst peers and mentors, despite the solo nature of the project, I would often find that having someone to bounce off ideas with or lend an ear to, gave me a deeper understanding of what I was working with before I tackled issues, helping me improve on new and old techniques and skills. Being able to work in a space where open communication was incentivised felt rewarding when I could make the results with the feeing.

On the technical front the Unity Engine was great to work. My aim with this project was to utilise the engine to the best capability I could to reach a better understanding of its implementation. The use of tools such as prefabs, scriptable objects and unity events helped me better come to terms with the engine. Alongside JSONUtlity, I found that the engine directly assisted the development throughout and I hope to better understand other features within the engine in the future.

Project Repository