Suck it Up!

Overview:

Suck it Up! Is a strategic twin-stick shooter about using your enemies’ words against them. Players fight through rooms of enemies while manipulating insults as projectiles and environmental interactions. The game started as a Global Game Jam 2025 entry and later evolved into a polished Steam demo shown at multiple conventions across Georgia.

Team & Scope:

Engine: Unreal Engine

Team Size: 20 total team members (design, art, audio, production)

Timeline: 2 months to create a playable steam demo.

Project Type: Jam-origin game taken into post-jam development for competitions and conventions.

Role and Responsibilities:

As one of three programmers, I focused on creating modular, designer friendly gameplay systems and maintaining a stable, scalable codebase.

Designed and implemented modular projectile and interaction systems
Implemented behavior for all interactable objects (doors, pickups, etc.)
Developed saving and loading systems for player progress and settings
Refactored core gameplay to use Unreal Engine's Gameplay Ability System (GAS)
Built a designer-friendly random quest system on top of GAS

What I learned

Suck It Up! was my first large group project outside of classes. As a team, we self organized and met twice a week in 2.5 hour work session blocks. We called at 7:30 pm daily for standups. Since our competition, we have taken the Suck It Up! demo to conventions and gotten more hands-on feedback from players.

Systems built:

1. Modular Projectile & Interaction Systems

Created a data-driven projectile system enabling different projectile types without hardcoding
Exposed key parameters (speed, lifetime, damage) so designers could prototype quickly
Built a centralized interaction component that:
- Tracks nearby interactables
- Ensures only one object can be focused at a time
- Uses line traces to ignore objects hidden by walls

Takeaway: Reduced bugs and made late-stage feature additions much safer.

2. Quest System

Used C++ Extensions to create data assets so designers can configure quests per level without changing code
Created a base-class actor with common and decoupled quest behavior for rapid quest creation
Recorded video instructions for designers using this tool

Created a dialogue system using custom data assets for more flexible configuration than data tables would allow.
Implemented dynamic UI accounting for edge cases (2 notifies triggering at once, overlapping dialogue, etc).

Process & Playtesting

Hosting playtests and getting feedback:

Suck it Up! Originally had a straight-on camera. As our map got more complex, the camera angle and flat shading confused doorways. I wanted to make a change to a 45° angle, but we were nervous about making a big visual change so close to our competition deadline. Would it be worth it?

To find out, I co-hosted our first major A-B playtest. I prepared two builds of the game with the different camera settings. I prowled the halls of Monty with a bag of chocolates for potential play-testers. Our stretch goal for feedback forms was 15, but we got over 40.

We had to figure out the camera angle ASAP, but our build was otherwise not in a state intended for playtesters, so the whole day felt like 40 small ego deaths.

Takeaways:

I learned that day how to be enthusiastic about feedback at all stages of a project. We got all of the feedback we needed to make the change in time.

Conventions and External Playtesting

After the competition, we continued showing Suck it Up! at conventions around Georgia. I attended as a developer, getting to watch hundreds of people play our game and give instant and direct feedback has been invaluable and deeply fulfilling.

External playtesting exposed edge cases and usability issues we never saw in school and gave me practice in talking about the game under pressure.

Technical Challenges & Solutions

1. Probelm: Players getting stuck on doors

When players tried to blast through doors from awkward angles, they would often snag on the doorframe instead of flowing into the next room.

Solution:

Added a line trace test to detect when the door is obstructed by a wall
if the trace hits a wall, the system briefly snaps the player to a position directly in front of the door, then applies the knock-through door behavior so they enter the next room cleanly.

This fix:

Removed a major source of frustration
Preserved the fast, "blast-through" fantasy without messy collisions

2. Probelm: Prioritizing interactable Objects

With many interactables in range (doors, pickups, etc.), the player could get confused or accidentally interact with the wrong object.

Solution:

Built the interaction component to:
- Track all nearby interactables
- Use line traces to filter out objects that are behind walls
- Decide which interactable is "focusable" based on distance, angle, and obstruction

This fix:

Ensured there was always one clear interaction target.

Results & Recognition

Global Game Jam 2025: Origin of the project
SCAD: Won Best in Show at the Savannah College of Art and Design
Georgia Game Developers Association: Won “Best in Georgia” competition
Conventions: Won Best Indie at Momocon and Southern Fried Gaming, and placed second in the People’s Choice award at Dreamhack Atlanta
Platform: Released as a Steam demo