Technical & System designer

Oh, Bugger! is a first-person shooter where players are swarmed by groups of enemies and have to defeat them. The playstyle feels much like a classic boomer shooter (like DOOM) that meets a horde-based game (like Warhammer 40K: Darktide / Space Marine 2).

The game excels at making the player feel powerful by putting them into tight scenarios, where all resources are designed to maximize engagement and minimize downtime.

Push Forward
Within the game everything is designed to create a “pushing-gameplay-style”. In other words, all system reward and motivate the player to keep attacking and moving forward.

Order to Chaos
As you keep pushing, most of the encounters will be with groups in cramped spaces. Providing powerful abilities that can neutralize chaotic environments in seconds.

For Oh, Bugger! I worked as a technical & system designer, being responsible for documentation, prototyping, and optimizing. This included:

  • Writing detailed design documents to collaborate efficiently with other disciplines.

    • Containing sketches, flowcharts, and the design specifications.

    • Frequently updating this game design document.

  • Designing, implementing and balancing different AI systems.

    • Crowd management system, used to navigate enemies in smaller groups towards the player.

    • Attack management system, which directs the order and permission for enemies to attack.

    • General AI balancing - the act of prototyping, testing, and iterating rapidly on enemy types.

  • Designing, implementing and balancing player systems.

    • Player abilities, like the slam, dash, and more.

    • Player camera system, to create a heavy and powerful feeling while controlling the character.

    • Checkpoint system that respawns the player correctly based on where they died.

  • QA testing to ensure intuitive gameplay, iterating based on feedback.

  • Worked closely with other disciplines to optimize features and troubleshoot wherever was needed.

  • Interactive credits post-game (WIP), created to make people enjoy credits more.

Group management

University Project

Project info

16 weeks

Oh, Bugger! Demo Trailer

Design Pillars

personal contribution

Personal Showcase

overview

A group-management system for enemies that splits them into smaller squads, each with a leader. The leader navigates toward the player (with collisions disabled), while followers chase the leader.

Resolving two major issues;

  • Pathfinding bottlenecks: Enemies no longer getting stuck behind each other.

  • Performance drain: Reducing redundant NavMesh calls.

implementation

  • Group Creation:

    • The first spawned enemy becomes the leader (collision become disables via interface).

    • A “Group Actor” spawns afterward, storing the leader and following enemies until group is full (e.g. 10 enemies).

  • Dynamic Group Management:

    • On Enemy Death:

      • Followers notify group actor, decrementing groupCount integer.

      • If groupCount <= 1, destroy group actor.

    • On Leader Death:

      • Group actor promotes next valid entry in array to lead.

  • Pathfinding Logic:

    • Leaders: Reference the player as destination in behaviour tree.

    • Followers: Reference their leader as destination point.

    • Staggered Updates: Leaders recalculate paths at staggered intervals to avoid CPU spikes.

21 people

First Person Shooter

Quick navigation Menu

Proof-of-concept in engine; First prototype

  • Creating Smaller Attack Groups:

    • Pros:

      • Made coordination look better of enemies.

      • Enemies did not get stuck anymore.

    • Cons:

      • Enemies occasionally still get stuck.

      • Strays from our design goals (Order to Chaos).

Attack management

  • Changing Collision Settings:

    • Pros:

      • Easiest and quickest solution.

      • Pathing becomes cheaper.

      • Enemies reach player.

    • Cons:

      • Makes players lose overview of enemies.

      • Breaks immersion and feels unfair.

  • Emergency Reset: Giving players agency in overwhelming situations.

  • Was a loved ability since the first prototypes onwards.

  • Game Feeling:

    • Heaviness: Supported by all layers of polish and feedback.

    • Control: Provides a safe and controlled feeling.

    • Catharsis: Enemies ragdolling + chaos destruction.

  • Pacing: Supports the pushing playstyle.

Alternatives

  • Cooldown-Per-Enemy:

    • Did not scale well with amount of enemies we have.

  • i-frames Implementation:

    • Pros:

      • Creates the same functionality.

    • Cons:

      • Taxes another strike-team.

      • Still overwhelms the player.

Enemy meshes getting stuck

Design impact

  • Performance Gains:

    • 90% fewer NavTo pathing calls.

    • Profiled improvement: 2ms → 1,2ms per frame in Unreal Engine Editor.

  • Gameplay:

    • Enemies now move in cohesive packs. Making encounters feel more rewarding and creating more down-time between waves of combat.

    • Players experienced:

      • No more stuck enemies.

      • Constructed attack waves.

    • Easier to manage enemies and direct them.

  • Scalability:

    • Now supports 40 → 60 enemies for the same performance of 60fps.

Why this solution?

  • Implementation was easy, allowing quicker iterations and more polishing on the system.

  • Uses of the two best factors from alternatives and combines them to improve performance & gameplay.

  • Aligns well with the design goals.

  • Enemies do not need to know others’ exact locations.

  • Makes enemies more manageable.

  • Got implemented with only a bit of support from programmers, by increasing NavMeshAgent.Radius.

Alternative solutions

  • Communicating Via BT:

    • Pros:

      • Awareness other enemy locations.

    • Cons:

      • Immitates flocking, but is way more expensive.

      • Drains performance, 40+ enemies scanning surroundings.

overview

A token-based attack permission system for enemies, inspired by elementary school hall passes. Enemies must request a token from the player to attack, preventing overwhelming swarms and creating a fair game flow.

Key-Features:

  • Limits simultaneous attackers via a shared pool.

  • Uses interfaces for decoupled communication between enemies and players.

  • Tokens automatically return on attack completion or death.

implementation

Design impact

  • Token Request Flow:

    • Enemy Requests Token:

      • Calls RequestAttackToken() interface method on player.

      • Player’s AttackTokenComponent checks TokenCount.

    • Permissions Granted:

      • If TokenCount > 0, decrement count and return true.

      • If TokenCount == 0, enemy waits.

  • Token Return Logic:

    • On Attack End:

      • After AttackAnimation (+ Cooldown variable), increment TokenCount.

    • On Enemy Death:

      • Token is returned through DeathEvent, to close out edge cases where enemy dies mid-attack.

  • Tweakable Variables:

    • MaxTokens: Controls how many tokens the player has.

    • AttackCost: Determines many tokens the attack will cost.

      • For different types of enemies.

    • AttackCooldown: Variable to potentially provide more breathing room to players..

  • Prevents Player Overwhelm:

    • Ensures only N enemies attack at the same time (3 for now).

  • No i-frames required:

    • Creates an organic feeling & reduces work for other departments.

  • Debug Friendly / Easily Scalable:

    • Tokens can be tweaked quickly and tested with. Allowing quick iterations and balancing.

Why this solution?

  • Easy to implement on and test with.

  • Scalable for bigger groups and more enemy types.

  • Limits the enemy in a way that feels more natural.

  • Clear to players what is going on, combined with SFX.

  • Designer-controllable allowing quick balancing.

  • Saved programmers time that could be used elsewhere.

Player ability: Stomp

Destructible objects

Credit Screen Game (wip)

A physics-driven credits screen that replaces passive scrolling with interactive name-plates, encouraging players to "play" with the team's names via physics-based interactions.

Currently still in prototyping state, but aims to create interaction with a completely new art-style.

overview

A high-impact stomp ability that lets the player obliterate hordes, creating breathing room in chaotic encounters. Combines physics-driven knockback, destructible environments, and visual feedback to deliver a "power fantasy" moment.

Key-Features:

  • Scalable AoE: Damage radius grows with fall distance.

  • Environmental Destruction: Chaos-enabled objects explode on impact.

  • Invulnerability: Brief safety window during execution.

implementation

  • Ability Flow:

    • Input Trigger:

      • Player presses button > check cooldown.

    • Ascend Phase:

      • Player becomes invulnerable.

      • Vector lerp smoothly lifts player.

    • Descend Phase:

      • Physics-driven slam (launch node).

  • Impact Detection:

    • Multi-Sphere Trace:

      • Radius scales with fall distance (clamped)

      • Checks for Chaos objects (destroyed via Field System)

    • Damage:

      • Communicates through an interface.

  • Feedback:

    • VFX: Shockwave showing weight.

    • SFX: Heavy “Boom” bass sound.

    • Screen shake: For extra juice.

Why the Stomp?

overview

A Chaos-driven blueprint that lets level designers easily create destructible props with customizable strain and explosion forces, enhancing player immersion and gameplay variety.

Key-Features:

  • Synergy: With all player interactions (e.g. Shooting).

  • Tweakable Magnitude: To scale impact easily.

  • Types: Different types of shattering can be selected.

implementation

  • Chaos Integration:

    • Geometry collections:

      • Created in editor.

    • Field System Trigger:

      • Spawned on:

        • Player collision.

        • Damage events.

  • Customizable Destruction:

    • Strain Control:

      • Internal- / ExternalStrain easily tweakable for different effects.

    • Explosion Power:

      • Apply linearVelocity with ForceMagnitude.

  • Designer-Friendly Workflow:

    • Create New Mesh:

      • Wrote a how-to document.

      • Selectable in details panel.

    • Exposed Variables:

      • Magnitude of explosion.

      • eNum for changing SFX.

      • StrainCurve to control break pattern.

Design impact

  • Level Design Flexibility: Providing easy implementation and iteration without coding.

  • Player Experience:

    • Juicy: Supported by the shatter type, VFX, and SFX.

    • Strong: Coming from the ease to destroy areas.

    • Dopamine-driven: Players can’t seem to stop destroying.

overview

why

  • Subversive Engagement: Players will interact instead of skip.

  • Passive Exposure: Playful ineractions increases name visibility.