|
Maddening Mercy is a bullet-hell visual novel. However, the vast majority of my work pertains to the bullet-hell section of the game. I was responsible for implementing that entire section, so I prototyped most of it before handing off parts of it to other programmers so I could focus on the enemy behavior.
Some minor contributions I did outside of the combat were the framework for the dialogue system and the action list. The action list I used was an older version of the one available in my Code Samples. The dialogue system was also made for an older game jam that never got finished, so I handed it over to the team to use as a prototype. It was a simple script that handled Unity Scriptable Objects and displayed them in a text box on the bottom of the screen alongside character portraits and name for whoever was talking. It integrated with the action list to provide a fair bit of early polish to the game's dialogue, and was designed to be expanded on later by programmers/designers responsible for the visual novel part of the game.
|
A development preview of the bullet-hell combat.
|
For the bullet-hell section, I prototyped the player movement script and player health in order to get a working player controller so I could properly test the enemy. The player scripts were fairly simple, so there's not much to note here outside adding dedicated damage collider components so that any collider could be easily converted into a damage collider instead of hard-coding that logic into the bullet script.
The enemy was broken up into three separate sub-systems. Looking back, I wish I had made this more scalable to allow for additional systems to be added without needing heavy modifications to the enemy controller. The three systems were Basic Attacks, Themed Attacks, and Movement. Movement was the easiest, it simply utilized my action list with an interrupt for if the fight ended while the enemy was still moving. There was also a way to override movement if Themed Attacks or Basic Attacks needed to control where the enemy moved.
Basic attacks were by far the most complicated while still maintaining a rigid structure. Each basic attack was made up of a series of 'blasts' each blast was a collection of bullets to be fired simultaneously. Defining it this way made it easier to implement data-driven combat, it also divided the responsibilities of different parts of enemy shooting into smaller sections that made far more sense. One issue with data-driven combat was that occasionally we would want an attack that required some runtime calculation. For instance, there is a charge attack that needs to spawn the bullets perpendicular to the line between the player and the enemy throughout the duration of the attack. This required setting a custom fixed bullet orientation when the attack starts which was a bit hacky and required rewriting a bit of the logic.
The last system for the enemy was it's various Themed Attacks, these were individually complicated, but the core system they used was not. The idea behind themed attack was to make them customizable and to avoid restricting them. What this ended up leading to was a simple state machine with three states. Attack signifiers, the attack itself, and the attack cooldown. Each state could be implemented differently for different themed attacks. While not a perfect solution, it provided enough versatility to implement the themed attacks without issue.