top of page
Gameplay Trailer and Development Information
-
Team Size: 5
-
Roles:
-
Lead Systems Designer
-
Technical Designer
-
-
Tools: Unity 3D, C#, Adobe Suite, Google Suite
-
Development Time: ~3 Months (Early September - Late November 2019)
-
Logged Hours:
-
Individual: 181.5 hours
-
Total: 807.69 hours
-
-
Platform: PC
Note: Music in the trailer is Kevin MacLeod's "Crossing the Chasm"; Trailer created by Brian Harney and edited by Zachary Fugere
Intent Statement:
Bring Your Spells is a first-person action-adventure game in which the player controls a mage who must wield a variety of spells to defeat enemies and progress through a series of levels to take down a powerful boss enemy. This game is designed to provide fast-paced, close-quarters gameplay and break the long-lasting stereotype of mages as being slow, frail, and long-range-only. Each spell in the game is unique; each one has its own element, effect, and charge rate. Defeating an enemy with a spell from one element (such as [Energy]) will cause it to drop pick-ups that reduce the cooldown of spells featuring a different element (such as [Void] or [Nature]). In doing so, we hope to encourage players to choose their spell loadouts strategically before starting each level, to experiment with different types of spells, and to play quickly and aggressively.
Feature List:
-
First-person adventure game with non-linear levels
-
Player ability to bring five spells (three combat spells, one vertical movement spell, and one horizontal movement spell) into each level
-
Spell recharge system where players are rewarded for rotating and casting their spells quickly
-
Shop system where players can use gold won throughout Level 1 to purchase a new spell
-
Combat system featuring both normal enemies and a powerful boss
Design Reel:
Design Work:
Spell Design:
Role and Design Process
Ever since Bring Your Spells' inception, our primary goal has been to make fun, interesting, and unique spells that stand out from the standard fantasy fare. We also did not want to give our players long-range spells that they could use to decimate enemies from across a room; we wanted to force them to move and directly interact with enemies. This is why we separated spells into two categories: movement spells (which give players either a horizontal or vertical boost) and damage spells.
Partway through the initial design process, we began fleshing out the broader system of how we wanted spells to function. Rather than relying on MP or some other resource, spells would rely on a simple charge-and-cooldown system. This led to the development of the element and spell rotation systems. These state that all damaging spells fall into one of four basic elements: [Nature], [Force], [Energy], and [Void]. Enemies drop orbs representing these elements upon death, and if the player picks one up, it recharges every spell in their inventory with a corresponding element. However, spells cannot make enemies drop orbs of their own element; a [Void] spell will never drop [Void] orbs, for example. Instead, the player must use magic from various different elements. Because players can only take three damaging spells into each level, they would thus have to carefully select their magic in advance in order to bring a load-out that lets them efficiently chain spells together.
At first, we considered locking orb drops to each element, such as having all [Nature] spells drop [Force] orbs. We ultimately decided against this, though, since it could potentially limit design space. Additionally, we realized that having orb drops be based on elements rather than spells would likely result in players completing ignoring certain spells in favor of others, which we wanted to avoid. As a result, we decided to tie orb drops directly to spells, instead. This system ultimately proved successful, and it allowed for the creation of a variety of different spells throughout the course of the project.
Spells
(Click on a spell to read its information!)
Bees
Magic Laser
Ice Shard
Dash
Vortex
Jump
UI Design & Implementation:
Role and Overview
I took charge of implementing and iterating upon many of Bring Your Spells' UI elements over the course of the project. These included the visuals for rotating between spells, taking damage, and obtaining gold. The implementation process included programming the UI elements in a way that was fairly flexible. For example, at the beginning of each level, the game automatically fills a charge meter with many pieces of information based on the player's equipped spells, including its icon and the color of and number of divisions in the charge meter. This allowed us to quickly develop spells without having to worry about creating unique assets for each of their charge meters, and as a result, development became quicker and more efficient.
Design and Iteration Process
From the beginning of the project, our team focused on designing the spell rotation system in a way that would let players easily understand which spell they were currently selecting. I first decided that the best way to get this information across was to use simple icons in the bottom-left corner of the screen, where players could easily locate them. In the first iteration, I made these icons square-shaped. Each spell featured a meter showing players how many charges they had remaining, which refilled from left to right for easy readability. The player could switch between spells using the 1, 2, and 3 keys on their keyboard.
Initial spell UI design (bottom-left corner). Note the white outline on the currently selected spell.
Testing revealed that this design came with a number of issues. First, several players complained about having to crane their fingers to hit the 1, 2, and 3 keys. Second, the refilling bars made it difficult to see the images representing each spell. Even if they were just placeholder images at the time, we knew this would probably become an issue further into development. Third, even when a spell's charge meter refilled, players found it difficult to understand when they could and could not cast it.
I spoke with two teammates to resolve these problems: fellow designer Zachary Fugere and artist JJ Robertson. Our intent was to create a more visually appealing and readable method of displaying spell charges and cooldowns. After some discussion, JJ created new, circular icons for each spell. We also decided to swap the current visual method of spell-recharging for rounded charge meters. These would be separate from the icons, which made the meters far easier to read. Upon implementing the meters into the game, I then added a "pulsing" effect over any fully charged segments to make them clearer and easier to read. I also changed the display to better emphasize the currently selected spell.
Finally, I updated the input system to let players move back-and-forth between the three combat spells with the Q and E keys, rather than having them select one via the number bar. This is because players could only bring three damage spells into a level at a time, so letting them swap "left" or "right" would instantly give them access to their desired spell. I then programmed an animation that "rotates" spells around the UI to make it more obvious that players were shifting between spells.
First update of the spell UI. Note the selected spell in the bottom-left, which is larger and more centralized. I also added icons and charges for the horizontal and vertical movement spells, which they were previously missing.
Testers enjoyed the updated spell rotation system, especially since they could understand which spell they were currently selecting, could more easily see how many charges they had remaining, and could more easily swap between spells. However, I was unsatisfied with the current design's visuals; the charge meters had a non-negligible amount of artifacting (since I quickly threw them together to match JJ's icons). I also found the jump and dash spell UI clunky and awkward, since the charge meters laid over the icons.
Over the course of a few weeks, I made several tweaks to the UI to address the above issues. I moved the combat spells to the middle of the screen and readjusted the size disparity between the selected and non-selected spells. This ensured that players can more easily access this important information at a glance. Additionally, I moved the jump and dash spells and changed their charge meters to not obscure the images. During this time, I also added a health meter and a red flash whenever the player takes damage.
Final update of the spell UI, which also includes general UI changes. Note that the combat spells are now centralized, there is now a health bar in the upper-left, and that I made changes to the non-combat spell UI.
Boss Design & Implementation:
Role and Overview
Late into the development of Bring Your Spells, we decided to create a simple boss enemy to cap off the prototype. We designed the boss with two basic goals in mind: first, to avoid overworking ourselves, it would have fairly basic functionality and would stand still throughout the fight; and second, to fit with Bring Your Spells' gameplay, the boss would periodically summon enemies so players could easily earn orbs and continue casting their spells. Several elements of the boss' behavior, such as it turning temporarily invincible after summoning enemies, were inspired by Destiny's raid bosses. I was assigned the role of fully designing, programming, and testing the boss, which I accomplished in a total of roughly 11 hours.
Boss Mechanics and Design Process
Upon entering the boss' chamber at the end of Level 2, the boss spawns and its health bar appears at the top of the screen. As the fight progresses, the boss gains more powerful attacks and summons more powerful enemies during its health thresholds.
The boss has three attacks: one blue laser, which it fires from the beginning of the battle until its health drops below 50%; a succession of five green lasers, which it begins firing once its health reaches 75%; and a series of 30 orange lasers, which it begins firing rarely once its health reaches 50%. Each of these lasers is telegraphed by a particle effect of the same color appearing on the boss' eye, as seen below:
After a flat number of seconds pass, the boss will fire its attack at the player, dealing damage if it hits them. Certain attacks - especially the 30-hit orange laser - last longer and deal more damage than others. This, along with the boss arena being a large, open room, is meant to force the player to move more often during the later parts of the fight. It should also push them to use their movement spells to dodge the attacks more easily.
Each time the boss loses 25% of its maximum health, it summons allies and becomes invincible until the player defeats them. While invincible, the boss' health bar turns blue; it gains a large, swirling barrier; and it no longer performs a "damaged" animation when hit by the player's attacks. During this time, the boss will continue to attack the player, forcing them to keep watching it while they fight the enemies.
I implemented these tells in response to some feedback while testing the boss fight's first iteration. At the time, several testers expressed confusion that the boss was no longer taking damage, as the only indicator was a semitransparent blue sphere over the boss that acted as a placeholder barrier. Implementing these three "tells" above made it much easier for testers to understand that the boss was invulnerable during this period, and they immediately started killing its allies to remove the barrier.
Upon defeating the boss, the screen flashes white, time slows to a crawl for several seconds, and a massive number of gold coins and elemental orbs explode from the boss' body. This process takes cues from other action-heavy games, such as Kingdom Hearts, with the intention of making the last strike on the boss feel dramatic and (if the boss proved particularly difficult) cathartic.
When testing some early iterations of the boss fight, some players thought the slowdown effect was a result of the game dropping frames due to the large number of spawned rewards. This is because, while I slowed down the game's internal clock, I did not adjust the physics to compensate. As a result, the coins and orbs looked choppy and awkward as they flew away from the boss. In response to this, I went back and altered the physics' timer to make the slowdown look more natural. From that point on, the number of players who believed the slowdown effect was a result of frame-drops decreased dramatically, with the vast majority now enjoying the effect.
Notably, players also showed an interest in running around the room after the boss died to pick up all the coins and orbs before they vanished. This was in spite of them no longer having any in-game purpose thanks to the boss being the last available challenge. After this, testers would them walk through the door at the end of the hallway, ending the game.
Intent Statemet
Feature List
Gameplay Trailer
Design Work
Spell Design
UI Design and Implementaton
Boss Design and Implementation
Meet the Team
bottom of page