FORGE OF SPIRITS

Download Link (Windows): https://miffins.itch.io/forge-of-spirits-prototype?password=ForgeSpirits

GitHub Repository: https://github.com/BaffleBird/ForgePrototype

Overview

Forge of Spirits is a Prototype Unity Project for an experimental 2D Top-down Action Combat system involving lots of cool sword things. The player picks up and discards various weapons on the fly, with each type of weapon having its own move set. Loaded with weapons and skills, the player dodges, slashes, and rushes through ruins and monsters.

Design

This project is still in the works and needs a lot of tweaking, but I can give a rough outline of where things are headed. Starting with a general overview:

False 2D Rendering:
- 2D graphics in a 3D space. This is to help cut corners with depth-sorting sprites and to open up some neat graphical possibilities that would otherwise be very tricky in a typical 2D game.
Action States For Movement and Combat:
- The core combat system is centered around a set of actions such as Moving, Dodging, Light Attack Combo, Strong Attack, Parrying/Counters, Guarding, etc.
Weapon Types:
- Player will be able pick up, switch, and discard weapons. Different weapon types will have different moves set up for each of the basic combat states. This means making unique animations and sorta unique action states for every weapon I design.
Skills:
- As an extra avenue for combat depth, I plan on having Skill-Loadout system to allow the player a few special moves and abilities for different situations.

It's 2D, But Not Really

I set up the graphics based after some posts made by Dodgeroll, the makers of Enter the Gungeon which was made the same way. According to them, to create the illusion of a 2D game in Unity, you have to do the following:

Set the Camera to Orthographic and zero out its rotations (which aligns it to the z-axis).
Tilt all horizontal/floor sprites back 45 degrees.
Tilt all vertical/wall sprites forward 45 degrees.
Stretch all sprites along the y-scale by a factor of the square root of 2 (approximately 1.414)

As mentioned, this makes lighting depth easier to manage and opens up a few options for graphical exploration. For example, you could make a water-shader plane and physically pull it up the Y-axis to the height of a character sprite's ankles. If you use 3D collision, you wouldn't have to work with the slant and would just angle the Camera instead (Unity 2D collision is restricted to the XY Plane).

A Finite State Machine

Character Actions are probably most easily represented as States. A typical character would start in a Standing state and would be able to transition states for Running, Jumping, Ducking, etc.

Most of my previous works only had a few actions and could be managed with If-Statements and Switch Cases. But Forge of Spirits has significantly more actions and required a more manageable, object-oriented approach.

I went with a commonly suggested solution, which was to make a State class which would contain all the scripting for a state and a StateMachine Class to run the states for a class. Both classes would include other references and functions based on what your game needs, but the basics of it is as follows

The every child of the State class (that is to say, every state) inherits 3 main functions:

- StartState(); What happens when a state starts (usually playing an animation)

- UpdateState(); Everything that happens in a state and how it transitions to other available states

- EndState(); What happens when on the way out to another state (usually resetting variables).

The StateMachine class has a variable for containing the Current State and runs its respective update functions, and running the StateState() and EndState() functions when switching States.

Using the Animator

On a related note, it's been a little awkward work around Unity's Animator. One approach is to use an enum type to identify different states and pass the integer value to the Animator to use as a parameter for transitions. That way, you would just make a 1 to 1 copy of your state machine. For every transition in script, you'd make a state transition in the Animator. But this can get real messy.

However, since I was only doing spritesheet animations, I had no need to rely on transitions which are typically used for 3D and/or bone animation transitions. Instead, I simply used the Animator.Play() function which allows you jump to any Animator State by name regardless of whether or not it is in a Sub-State Machine. You just need to keep the name of each Animator State unique. (You can still use transitions for other tricky business like branching into different animations based on weapon.)

Sprite Swapping

A side issue was figuring out how to load a different sprite for each weapon. For example, what if I wanted to use the same animation for a red sword instead of a blue one? My solution was just use the same Animator as the character, but use a script on the weapon's renderer to load a spritesheet of the same name and size but from a different file location specific to the weapon. Now I don't have to make Animation Clips for every weapon.