This was a student project where I worked alongside Level Designer Evan Johnson, and Producer Jayden Rieck. I scripted and designed the systems for the game, including menus, player controllers, and enemy AI. The goal of the project was to practice developing a game in an Agile/Scrum structure, developing the game to a minimum vertical slice state.
Initial Concept
The idea of Rapid Fire came from the friction that I often felt with beat'em-up, and more strongly with their cousins, fighting games, that they required a lot of pattern memorization in order to fully enjoy. This hurdle often leads to more casual players in the genres to simply button mash, which is the equivalent to flailing your arms wildly in the hopes that you won't drown, it can be mildly effective, but not very enjoyable. The idea was instead of having the remember a combo, the player could simply read it off of an enemy instead. This would turn a memory required skill to a more reactionary, not necessarily decreasing skill, but require less specific game knowledge in order to pick up and play, thusly making it more approachable.
Enemy and Combat Design
The enemies for Rapid Fire, due to the combat system, had to be considered a bit more carefully than your average beat'em up. We needed a way to show the combos that the player needed to do in order to kill them. Using colors was an almost instant decision as they could be not only understood faster than symbols, but not limit the games structure to a certain control method if we ever wanted to add controller support. I thought of using clothes to possibly show the colors, but it was quickly passed in favor of using colored lights on robots. This gave us more flexibility with the character design of the enemies as well as allowing us to turn off the lights at successful hits.
We planned out four robots ranging with numbers of lights ranging from 1 to 4, so that the strongest robot could possibly require all four colors in order to kill. Larger robots were also more complex both in form and function, gaining larger modes of movement and more complex attacks as they got larger. We also considered what they're purposes were story-wise. Lights on the robots were carefully arranged so that their combo could be read from top to bottom, providing a quick and consistent way to decipher them.
When it came to the flow of combat, we needed a way to prevent the sometimes, quite large amount of enemies from crowding the player. So only one robot can be "engaged" with the player, going for close ranged attacks. This doesn't mean that "unengaged" enemies are harmless, they instead circle the player and fire ranged attacks that the player must dodge. Unengaged enemies can also still be hit, so the player can choose to try and focus some of them if they so wish. The robots and their functions goes as follows:
The Orbs (one light) have no ranged options and use a lighting bolt for their close-range attack. They're mostly a fodder enemy, considering they're one-hits. They work as delivery drones when they're not trying to kill you.
Wheelies (two lights) have a grenade they toss which will explode after a few seconds for their ranged attack, and use the same lighting attack for their close range. They're a larger delivery drone that now deliveries explosives instead of packages.
Flamens, which "werf flamen" and toss molotovs. They act as an AoE enemy, forcing the player to think more about positioning. They were originally sentient barbeques/coolers.
And finally, there are the Sluggers, humanoid pitching and batting machines, using their bats and baseballs now as weapons. They act as the most difficult enemy to defeat and can easily deal the most damage with their bat, making them high priority targets.
Level Design
While I didn't do the level design for this project, I also needed to consider it when creating systems. Mechanics need to be easily adjusted and placed by level designers, so in a way, in this project I learned to design for designers.
How I did this was mainly carried out via "Dev cubes". Each dev cube would hold a script that would run a specific mechanic, only triggering once the player passed them on the linear stage. I textured them with these beautifully ugly images you see to your right to make them distinct and clearly not meant to be seen by the player (they were all hidden under the level).
Their functions were: screen lock, which prevents the camera from scrolling until certain enemies were killed, check point, which saves the player's progress for if they die, spawn point, which spawns enemies, and color cap, which edits the color cap, preventing or allowing enemies from using a range of colors.
