Cheffin' it Up

Introduction

The goal of this project was to create a 2D Top-Down game with multiplicative 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. This want led to me taking inspiration from vampire survivors, as the horde survivor genre of games creates opportunity for a playground where 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 problem solve outside of what I already knew, and to not only complete the project but also to create a product I was happy with. As 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, it allows for a singular copy in the 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 I wanted to use my project development as a means to better understand the unity engine with all roads pointing 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, which 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; IDragHandler & IBegin(/End)DragHandler. These interfaces define functionality within a Unity Project, with the three I mentioned being pre-built interfaces that define drag & drop functionality. This isn't a simple copy and paste job however, these interfaces just provide tools to simplfy the creation of systems, and in using these tools I included features such as a dynamic inventory in which players can swap items.

Code - Inventory

Shooting

Early in development, players used arrow keys to fire weapons meaning that players could only fire in up to 8 directions which wasn’t ideal for a game where threats can approach you from any given direction. I instead made the decision to implement mouse shooting, as it better suited the overall design and game feel.

When talking to peers and lecturers, I concluded that it wasn’t a simple transition to change to mouse shooting. I needed to understand a certain level of vector maths and after a lot of research and a lot of trial and error, I realised that I had taken the wrong approach when applying what I learnt as I couldn’t simply add it onto what I had already created but I needed to create something new.

This led to a much smoother development with the end result having a few hiccups that I cleaned up throughout the project. I had been treating the player as the firing point, however what was needed was a disembodied component that rotated around the player, almost acting as an 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, with the player achieving points 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 conversion of 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 written on a .txt file stored 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 using a games engine, and because of this it was a major learning experience. Despite having coded for years this was the most creative freedom I've had in 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. The greatest lesson I learnt throughout the project was structuring my time. While I had plans for the project, I had to learn that each component I wanted to develop would be much easier to work with once broken down into smaller segments. The principle of splitting work up has been one that I have learnt about for years, but it was here where its practicality finally clicked, and I found the project become more like a puzzle to be solved rather than a labyrinth that I had to run headfirst into.

This was massively aided in communications with peers and mentors because despite the solo nature of the project, I would often find that having someone to talk it through with, gave me a deeper understanding of what I was working with before I tackled issues, helping me improve on my techniques and skills. Being able to work in a space where open communication was encouraged felt rewarding when those conversations led to a successful change.

In a technical context, Unity Engine was great to work with. My aim with this project was to utilise the engine its full capacity so I could better understand the possibilities. The use of tools such as prefabs, scriptable objects and unity events helped me come to terms with the engine. Alongside JSONUtlity, I found that the engine directly assisted the development throughout and I hope to understand other features within the engine more in depth as I work on future projects.

Project Repository