Spell Slingers
~Programmer~
Spring 2025
Unity 3D
Architecture
System
Spell Slingers is a prototype made by a team of 10 over the course of 5 weeks. We decided to prototype the mechanic of combos in a tile and turn based rpg setting. The player controls 3 different characters: Fire, Earth, and Water. Each character has an attack ability to use on enemies and a trap ability to use on tiles. When these abilities combine, they create a variety of large effects. To keep scope in mind, the enemies were simple dummies for the player to move around to perform combos on.
One strategy the programmers used on this prototype was to make flowcharts of the different systems we needed to build. From the flowcharts we were able to foresee and counter a few different issues while planning the systems. I took the lead on flowcharting the tiles and the ability system.
I started by creating the tile and grid system, and planning the needed character movement functionality. The map builder and some of the tile functionality came from the editor tool I built for ORBIT. One major change I made was spawning instances of the tile prefab, rather than just game objects, so they retained the benefits of being prefabs. I extended the functionality of the tiles to account for the character’s movement and ability effects, and then collaborated with one of my teammates to get the character movement script working.
Above and to the left you can see the flow charts made during this prototype. These charts were made using miro and use C# psuedo code to plan out the architecture of these systems.
We went through many drafts of the ability and combo flowchart, but settled on a hierarchy of scriptable objects for the abilities, a hierarchy of monobehavior classes for the combos, and then a Combo Codex singleton manager. The abilities needed to be comparable to each other and have the one function called when the ability is cast. Characters and tiles needed to have a variable number of combos affecting it at any given time, with a variety of functionality depending on the effects. The Combo Codex was then made to evaluate which abilities combine to which combos.
After the base systems were made we did some playtesting, and realized we were missing the most important element of this type of a game: Player communication.
The team split off into adding different elements to communicate the mechanics. My task was to implement VFX and icons for every combo. Using some free VFX assets from the assets store, I modified and combined them to create a unique prefab for each combo. I made a combo class to hold references to the combo’s icon and VFX asset, and compiled them into a list on the Combo Codex.
Of course, at this point I would have re-structured the ability/combo system to be more flexible with the needed player communication in mind. I would have made the combos scriptable objects to hold all of the information pertaining to the combos instead of them being split in a couple different places. These objects could have included the combo’s descriptions and been used by the UI to fill in the combo information screen instead of manually pasting all of the text. Due to scope, this was unfortunately not going to happen, but it was a good experience to learn from.
More Projects!
