Game Concept and Prototyping
Absolution's initial concept was born from a question;"What if your gun didn't just do damage?" We began by investigating two possible gameplay styles.
The first one involved weapons that didn't do damage, but instead threw enemies around the screen, colliding with obstacles and each other to deal damage. I quickly designed a whitebox prototype to test the mechanic. Unfortunately, though it was engaging, several bugs arose simply from the prototype, and we determined that designing a game around the system would be out of scope for the development period we had.
​
The second concept revolved around using the player's gun as their primary form of movement. Rather than moving the enemies, it moves the player. With this method being the simpler base, we believed we could better build gameplay systems around it, which led us to choose this option as the framework for Absolution.​
Brainstorming and Systems Design
With the core mechanic established, we moved into designing secondary mechanics. Our team had a disproportionate number of designers, so the work was divided between them. My primary responsibility was to create a number of concepts for loadouts: different character selection options that change how the game is played. While only a few of my concepts were ultimately implemented, you can view my brainstorming process and first-draft options in this document.
​
​
Once the concepts from all designers had been compiled, the options that best aligned with each other were compiled, creating diagrams and descriptions to aid guide programmers in the process of implementation. The same was done for all items and enemies.
Technical Design and Implementation
In the production phase, I was primarily responsible for the implementation of the enemies, as well as the player's abilities. In addition to programming, I also served as a technical designer as I converted the more abstract diagrams and concept descriptions into balanced and refined technical systems.
​
My first challenge was interpreting the more artistic and creative design documentation through a technical programming lens. The initial conceptualization was focused on the player experience, using abstract phrasing like "light damage" or "low health." Translating these values into actual gameplay experience required rapidly and frequently testing various abilities and stat values to determine a satisfying balance for the player that felt both challenging and fair.
​
I used the A* Pathfinding Project Module by Aron Granberg for enemy movement, and used a system of states (between 0 and 2 for most enemies) to determine the enemy's behaviour based on a number of factors.
​
My largest piece of technical design was demonstrated in the Ability system. An enemy's behaviour (as well as the player's) was divided up into modular Ability classes. A specific enemy's class references ​a number of attached Ability classes. When an enemy needed to use one of those abilities, it would simply call the public function of its assigned Primary Ability, and the effect would depend on which ability is assigned to that slot. This sort of modular design allowed me to rapidly prototype and iterate on enemies with minimal changes to the actual scripts involved, and improved the playtesting process, as large-scale changes could be applied to all enemies at once.