Explore the city of Wrath and meet friends and foes alike! Play as Ven and utilize his neurotoxic magic in combat.
Engine: Unity
Team Size: Solo
Project Length: Background Development, began December 2024
Role: Programmer, Designer
Focus: System design, Input
The player's actions are handled by multiple scripts specific to the needed action. The current list of scripts is PlayerInput, which handles everything related to input and their event calls, PlayerAttack, which handles normal attacks, Healing, which handles healing magic, and Neurotoxin, which handles the specialized poison spell. Each specialized script listens to the events in PlayerInput and fires its respective methods depending on the player's action.Â
Originally, PlayerInput was separated into two different scripts, with one handling solely movement and the other handling actions like dashing and magic calls. It got hard to remember which script to reference back to during programming, so before the amount of scripts grew too out of hand, they were combined into one.
Enemies are set up using the base Enemy class shown first (left). The primary function of the base class is to handle receiving damage from the player. Specific types of enemies use their own class inheriting from Enemy. The specific class handles giving damage to the player along with how they react to them. For example, the testing enemy shown second (right) slowly but constantly moves towards the player's position, and when they are inside its hitbox, it deals 1 point of damage every 10th of a second.
The Dialogue base script shown was made with the idea that different types of dialogue will have easily editable child classes and a designer friendly setup in the inspector. Its key highlight is its data array of a serialized class. Each array component lets a designer write what they want the character to say, set the character's talking sprite, and tell the script whether or not the player character is speaking. Once all of the data is set in the array, the script takes care of the rest. Any child classes use the base array as the initial data, then they have their own for their personalized data. For the base class, it only plays one set of dialogue. Nothing changes it when the player interacts with it again.
The first child class creates dialogue that changes into a second group after the player interacts with it once. The initial base class's dialogue plays first, then when the player interacts again, it is swapped for the class's specific data set. The first set of data is not played again after it is swapped out.
The second child class creates dialogue that swaps between the two sets of data each time the player interacts with it. It is controlled by a boolean that gets set to the inverse each time an interaction is triggered. Unlike the first class, both sets of dialogue are accessible after the player reads them.
The third child class creates dialogue with a prompt allowing the user to select between two options. It is initially set up and designed around a Yes or No prompt, but the script can work with any two given options. The code first plays out an introductory set of dialogue from the base, then if no options have been selected yet, it displays the choices the user can pick from. When a selection is made, the specific dialogue runs until completion, which it then triggers its own reset to return back to the introductory dialogue.