“Gnomer Shooter” Combat Prototype
Designing dynamic combat interactions is more about game feel than realism. How do you know where to start when you know reality isn't as fun?
One of the first things we did as a team after setting up our project and controller was to figure out the behavior of our first rune and it's detonation. As the only person with significant coding experience in my team, I was responsible for setting up our runes behavior, testing, and iterating on it.
We settled on a “Launch Rune”, which fires the player and enemies up into the air when detonated. As we realized that the just applying a radial force to everything in the blast radius wouldn't feel good (despite being physically accurate), I put a good deal of effort into creating a conditional algorithm which would launch players and enemies in a more satisfying way, with a focus on upward movement.
This exercise was a good reminder that when you know reality isn’t going to be a good starting point, it’s good to start with your goal for the player experience and work backwards. Instead of starting with the base physics impulse and adding onto it, I broke the behavior down into its necessary parts and worked from there.
In order to improve my skills in combat design and general development, I worked with a team of 5 over a handful of weeks to prototype a unique FPS combat system
The “Gnoomer Shooter” prototype was built based on a design principle of managing two different shooting configurations at the same time—hitscan and projectile. I wanted to build a system that merged the benefits of both systems and allowed players to use either interchangeably.
Once we had come to a conclusion on this, the first person perspective, and a tight, “boomer shooter” style character controller, we added an additional gameplay goal: We want players to combine both weapon types to pull off actions that were greater than the sum of their parts. We ended up settling on the “Rune” system after some ideation. Players can place runes with the projectile weapon (we ended up allowing 3 different rune types), then fire at them with the hitscan weapon to “detonate” some effect.
With this initial mechanic decided we began developing a basic prototype in Unreal Engine 5.
A key part of creating engaging enemy hordes is creating tools and behaviors that lessen horde pressure on the player as needed .
As we kept developing, we knew we wanted the player to be using their AOE attacks and precise revolver shots to take on hordes of enemies. In this case, many rabid, zombified gnomes (At least, that’s how we imagine them—in this prototype they are rendered as little blue men with tall white hats). As we thought about horde enemies and what makes them tick, we realized a key part of that is maintaining a fun amount of pressure.
As is common design knowledge, a good stairstep pattern of pressure and player skill as a game progresses is key to an enjoyable game experience, and in a game with hordes of enemies, a large part of putting on and relieving that pressure is controlling horde patterns. As we designed our enemy AI, we looked at how this is done in other games (Left4Dead, Warhammer: Vermintide), and noticed some key things: players are given abilities and movement to kite, stall, and seperate enemies; and enemies are given behaviors which stall them occasionally or reorganize themselves. While we ended up opting for relatively simple enemy AI for the initial prototype, we did design out more complex AI behavior which met the latter requirements, and for the former, we designed two additional rune types which lead into these requirements while maintaining player agency for how to deal with hordes of enemies. In this case, the Ice Rune stalls and stops enemies in a specific area, while the Gravity rune gave players the ability to control horde grouping.
As time goes on, I am very interested in continuing to refine this prototype—it has taught me a great deal about how single player FPS games tick in the technical aspect.
Demo Video
From August 2023 til early December 2023, I designed and produced four different prototypes during short, 2-3 week development cycles.
This was done as part of my first semester of Graduate School with the University of Utah’s Division of Games, and was hugely educational for me.
The first prototype, Asteroid Panic, took only two weeks, and had the constraint of modifying an existing 70s era arcade game with a new aesthetic and one additional mechanical complexity.
For this project I served as the designer and producer alongside two engineers and an artist.
We settled on Activision’s Avalanche (1978), a game where you catch falling rocks with a paddle (think opposite-day Breakout). In order to modify the game, I suggested simply adding an additional heuristic and response to the game: some rocks you catch, some rocks you bounce away. The player has to recognize which objects require which response, and then press the appropriate button to swap the paddle “mode” to respond accordingly.
This game taught me the power of simplicity, as well as how to scale quickly and work within a tight time frame.
The approach during these projects was to develop a prototype, and a prototype only, albeit with an increased amount of art assets and visual development compared to the industry standard for a prototype. They all have playtimes under 5 minutes, and serve as testaments to my education and continued improvement as a developer.
The second prototype served more as a technical exercise. We were tasked with taking a verb, and creating a number of single mechanics or interactions within a shared gymnasium. This project took about 3 weeks.
For this project, all members of the team had to implement their own mechanic.
We were given the verb “Lure”, and I chose to learn Unreal’s Blackboard and Behavior Tree system to create a monster AI that the player must “Lure” around while voiding getting caught.
This game gave me a number of new skills within Unreal Engine and introduced me to AI behavior.
Rescue Rush
Project Lure
Though I had 5 published projects by this point (2 on Steam, and 3 on itch.io), the opportunity to work in a simulated studio environment among passionate peers in the program was enlightening, educational, and effective. I can proudly say I am a more effective game developer after these projects.
The final prototype was the longest, at 5 weeks, and was focused on creating twitch integration for a 3D version of a previous 2D prototype. Our team ended up recreating another team’s arcade prototype, and using twitch integration to allow for viewer representation and interaction in the game
For this project, I designed our twitch integration and helped produce the API and integration development
The twitch integration for the game went through about a week of ideation, before we settled on a system wherein twitch viewers’ names are assigned to the player’s objectives (crying babies that they must kick out of a building in order to rescue them from an impending fire). Viewers could also input commands to make their babies cry, scream, laugh, etc., giving them a way to annoy and interact with the streaming player. Unfortunately, due to a server issue, I no longer have an available build of the game.
This game gave me a unique opportunity to learn about design practices for viewer-integration and API usage, a unique skill that I hope to find new uses for as I continue developing.
