Drain Runner

Unreal Engine 4 | 19 Person Team | Design Lead/Technical Designer

Dubbed “The Most Technically Challenging Game to Make in FIEA History” by FIEA Professor Ron Weaver!

An underground haven for trash, scrap, and the unwanted. Failed experiments and metallic monsters make their home in the grime of the sewers. Entire quadrants of sewage, towns, and buildings floating on trash barges, flooding underneath the sewage waters at a moment’s notice. There’s only one thing you can try to do if you’re stuck here: survive.

Drain Runner is a third-person action roguelike in which the player is placed into an ever-changing sewer system, equipped with a magnetic arm and scrap gun. Using these tools, the player must survive as long as they can. During each “run” of the game, entire sections of the map will periodically be removed and replaced with new sections, presenting the player with new challenges, loot, and gameplay possibilities. Using their magnet arm and side weapon, the player must traverse and fight their way around the sewer system, fighting to stay alive and avoid drowning beneath the waves of sludge.

The game takes inspiration from arcade roguelikes like Risk of Rain 2, and the movement mechanics of Sunset Overdrive.

Read the Full Retrospective Below!

Role Overview: Design Lead & Technical Designer

  • Concept initial game design and hosted roundtable sessions with team members for iteration and ideation

  • Construct and enacted design and developmental plans for addressing critical focus areas and feedback from team advisors and player testing

  • Coordinate gameplay and level creation pipelines between 20 individuals across multiple disciplines

  • Identify slowdowns in key pipeline processes in response to developer feedback and time-tracking data and execute changes in development strategy, reducing task time estimates by 50%

  • Design and Implement game systems and mechanics related to magnetism such as a spline-based rail-grinding system and magnetizable enemies, objects, and walls

  • Assist all members of the team in the debugging and implementation processes

Key Lessons Learned:

  • Best practices for keeping blueprints clean and commented

    • Do NOT let the player class get bloated :(

  • Clear, smooth pipelines are incredibly important. Giving developers the tools to keep moving and keep them from doing monotonous work is incredibly valuable

  • “Good Communication” simply depends on who you’re communicating with. Some people need more hands-on communication, others less so. Knowing the best way to communicate with each member of the team is one of the most important things to do correctly

  • Ability to read Unreal C++. Can I write it? Not well. But I know enough after this project to be able to read it!

  • Know your scope and your timeframe. Keep it in check at all costs.

What Would I Do Differently?

  • Scope down from the start.

    • We started with an incredibly high scope given the team’s experience and our timeframe, and that hurt us in the long run.

  • Don’t Make Cuts without having suitable replacements in check

    • Given our large scope, we naturally had to make cuts. We did this without having replacements though, and the things we cut ended up leaving holes in our overall game flow and sandbox that made things feel disjointed in the end.

  • Be more hands-on when leading others

    • I had 6 individuals directly under me on the design team, and I know I could’ve done a better job getting some of them more involved

  • Give the player more guidance

    • We were aiming for a sandbox-y feel, and underestimated how hard that is to get correct. Some games like Destiny and Halo spend years and multiple titles creating their sandbox. Trying to do that in this small time frame with limited resources was a tall task, when instead we should’ve focused on guiding the player through the experience more rather than letting them loose.

  • Scrap the Arena Mode

    • The end of the game - the “arena” - ended up taking way too much of our resource pool, and the final state it ended in in the game’s final release is pretty half-baked because of it. It’s not entirely clear to the player what it is or when it happens.

Early Mechanic Prototyping

Early prototype of magnetizable objects and walls

Early prototyping of rail-grinding using a spline-based system

Adding some emphasis on player movement with screen shakes and camera lag

The behind-the-scenes functionality of these mechanics changed a bit from the prototyping stage to the final game, but the end result uses an interface IMagnetizable, and checks to see if the object the player attempts to magnetize implements it. From there, the object itself tells the player what it’s going to do, clearing the Player class of some unnecessary bloat. This same logic applies to the magnetizable enemies within the game as well.

UI - Menu Screens and HUD Elements

Menu Screen

Credits Screen

Moving Material instances on health and magnet charge UI elements within the player HUD

Reactive on-screen controls UI, changing during gameplay to accurately reflect player options