Menace of Man
2 Weeks
Feature Owner / Gameplay Design / Sound Design
5
Unreal | Miro | Diversion
Trailer
Overview
With a small but highly collaborative team of designers, I set out to make a hectic bullet hell shooter focusing on quick reactions and positioning, where the player faces off against an evolving boss in an arena challenge.
This project became an exercise in restraint and focus while delivering a reactive combat experience within a compact scope.
In-game screenshots
Responsibilities
As Feature Owner, I was responsible for securing a tight but engaging game loop, an aligned scope between the level and system designers, and transparent communication throughout.
As Gameplay Designer, I owned the 3C experience, from movement logic and dash systems to gun aiming and camera behavior. I also handled QA and most bug testing, and implemented all sounds and music.
Feature Owner
With a short development cycle and need for a condensed scope, I took this opportunity to challenge myself to balance the Feature Owner responsibility with the 3C design role. It was indeed challenging, but clear responsibilities and scope made it possible to stay involved in key decisions without losing focus on my design responsibilities.
By thoroughly discussing ideas before prototyping, I ensured that the team was synced from start to finish and held scope creep down, making the close deadline less daunting. Once our direction was set, I kept meetings to a minimum, other than quick daily standups, and stuck with Miro and Discord to keep development effective.
I coordinated across the crafts to ensure responsiveness, clarity, and gamefeel stayed consistent.
3C/Gameplay Design
To support the boss-centered design, I replaced Unreal’s default click-to-move setup with responsive WASD controls and mouse aiming for more responsive player control. Balancing around the boss’s abilities meant constantly adjusting player-centric values and projectile lifetimes to achieve synergy.
With most boss attacks originating from the boss model, playtesting showed that it was always safest to stay close to the map edges. I reduced projectile lifetime to force players to close the distance, which steered the game from a ranged shooter into a dynamic mid-range brawl that rewarded risk-taking.
With so much happening on the screen at the same time, the player character easily got obscured by obstacles and projectiles. To avoid losing sight of the player, I implemented an obscured-player visibility system, which helped players and also the team to experiment freely in developing boss attacks.
Visibility system (1st iteration)
Midway through development, we shifted from an isometric to a true top-down perspective to improve readability. Apart from solving projectile readability and simplifying several systems, it allowed me to refine the player visibility feature, going from a location opacity material on objects to an overlay on the player (skeletal mesh with a translucent material).
Visibility system (final iteration)
Playtesters also voiced issues with the lack of situational awareness and player feedback, which led me to implement more distinct boss telegraphy animations, damage overlays, and more UX-focused SFX such as bullet hits/ricocheting based on hit object and player taking damage. This helped the player read the fight without cluttering the HUD.
In-depth: Dash mechanic
Dash development evolution
Blueprint
In-depth: SpringArm Target Offset
Aim offset showcase
Blueprint
This became my least favourite outcome. To solve the map feeling cramped and reduce confusion (“where’s the boss?”, “what’s his next move?”), I tried to implement an Enter the Gungeon-style dynamic aim offset for better spatial awareness. However, it quickly became my personal Everest.
The biggest issues were getting the offset to behave consistently from all angles (some caused the camera to “tip over”) and preventing it from focusing outside the playable area (camera confine logic either had no effect or affected other logic too much).
My best attempt divided the viewport into 12 zones to define camera behavior based on cursor position, but it became too complex for me to work properly in, clashed with other systems, and worked extra poorly outside the arena. Most playtesters reported issues with it as it either felt too restrictive or loose, depending on the tester.
In hindsight, I should’ve reverted to a simpler follow camera, potentially a separate camera actor instead of a player-childed one, and explored more basic target offset logic instead.
The system gets and sets the player’s position based on which square the cursor reaches, and tells the camera the destination and distance to go based on different max offset values while ensuring it always includes the player in its view.
What I learned
This project reinforced how important it is to set a clearly stated scope and team responsibilities, and core feature definition of done’s. Thanks to that, progress was very smooth although it required some longer meetings at the start of the project, which caused some stress in the team with such a tight deadline.
Although the result became one of the game’s key flaws, I’m happy I challenged myself with the SpringArm Target Offset. In the end, as it admittedly became more of a personal vanity feature than an addition to the user experience, it taught me valuable lessons in complexity management and that as a Feature Owner I need to be ready to cut losses early when their complexity starts threatening the schedule or simply isn’t good enough. In the future, I hope to be quicker to spot and accept these issues and not be afraid of scrapping solutions that don’t work properly, even if they’re impressive on paper.