Arcana
Arcade Shooter Made from Scratch
Game Designer/Scripter
ENGINE: Unity 5
LANGUAGE: C#
DEV TIME: 8 Weeks
GAME MODE: Single Player
Download
Arcana
Download
Design Doc
Scripting Highlights
Card System
I knew when I started to design the card system that it would be important to make the card system flexible and centralized in case I needed to make changes in the future. I did this by centralizing all critical card code in a single manager component class attached to the player. This class managed card effects, instances, and tooltips so that changes to the functionality of a card wouldn't have to be spread across multiple disparate components. I used the Singleton pattern to ensure that I could easily access the information in this class without having to make expensive GetComponent calls throughout my code.
Card enumerator and card instance structure
Tooltip Dictionary
Two basic card implementations
Juice Components
During the juice and polish phase of the project, I found myself repeatedly implementing that same functions, such as screenshake or voobing (when a game object scales up and down rapidly). To increase code reuse, I created simple, generic components for these effects which I could attach to various game objects. Since both screenshake and voobing occur over time, but the Update function is brittle and expensive to use, I implemented both using Coroutines, which are cheaper and can be stopped and started quickly.
These two components differ in other aspects of their execution, however. Since Arcana is a 2D, single-screen game, screenshake is implemented using a single component manager which handles all screenshake for the entire game. Voobing, on the other hand, is only applied to specific Game Objects, and so is a component that can be passed to other functions to trigger the effect.
Screenshake Coroutine implementation and public values
Screenshake public functions
Voobing component variables
Voobing Coroutine implementation, featuring a lock/unlock feature
Death Function
Throughout Arcana, I used a single Health component for both the player and enemies in order to reuse code. While this approach had its challenges, it served me well throughout the early part of the project. Unfortunately, when it came time to add juice and conveyance to player enemy death, this implementation became a hindrance. While I initially planned to make two separate functions for player and enemy death, I eventually settled on a single, flexible death function. The advantage of this system was that it allowed me to easily modify the juice on death for each element of the game without worrying about breaking the same function in another part of the code.
First half of the death function. Score pop-ups, debris, and particles only spawn if an object prototype is specified.
Second half of the death function. Differing effects depending on whether this is the player's health.