Project Slasher
Tethered
Scrap Gunsmith
CBG Cricket Game
Contact
About Me
Home
CBG Cricket Game
To make modding feel immediate, I implemented a live weapon preview using a UI Render Target. Instead of previewing the gun in the active level, I render a dedicated preview room into the inventory/modding screen so swaps feel instant and reliable.
-
Built the preview with a SceneCapture → Render Target pipeline, rendering a small room placed underneath the level.
-
On Tab (game pauses), move the weapon from the player’s hand into the preview room.
-
Keep all attachment meshes pre-placed to avoid constant spawning/despawning during rapid swaps.
-
On open and on each swap, read equipped slots and toggle mesh visibility (new part on, old part off).
-
On close, move the updated weapon back to the player with the attachments still applied.
This approach kept the modding screen fast and stable, even when players repeatedly opened/closed it mid-run.
.png)
CV
Adnan Aqeel | Projects | Scrap Gunsmith
Thanks for Reading!
-
The naming, and the handling for the prefixes and modifiers was a complete mess. We struggled a lot towards the end of production to tweak numbers etc because it was such a hassle to do and was not intuitively set up. While I wasn't the one who set up the data tables etc, I did come up with the structure for it, and should have checked in on them earlier in production to avoid this issue.
-
A huge thing I learnt was to have clear and separated Collision Presets. Given that our game had a lot of things that had collision based interactions, the amount of time I had to spend bug fixing and trying to find what was causing the issue in terms of collisions was way more than I would've needed to had I made clear collision presets for various actors/collisions.
-
We didn't properly account for the time it would take for polishing, and didn't conduct enough playtests, which came back to bite us. Given a redo, I would've advocated for an earlier feature freeze, and spent more time on polishing and making the game feel as smooth as possible, even if it mean sacrificing on a few features to get there.
-
One of the most glaring issues in the game, is the fact that the player character sort of blends in with the rest of the surroundings. This is one of the many QoL and UX fixes that we didn't have time to prioritize since we went too heavy with the systems.
Learnings and Things I Would Do Differently
I learnt a lot about how to structure systems, and how to define clear architecture from the get go to make for easier prototyping, and scalability in terms of design and implementation. For this project, we had to define a tight scope and at the same time we wanted to create something that had it's own identity and a level of nuance. There was a lot of "kill your darlings" throughout the project. We had initially planned for a boss fight every couple levels, but that ended up being way too out of scope.
There are a number of things that I would change or do differently in this project in hindsight, but having said that, I am proud of what we managed to create at the end of the day.
Conclusion
For 3C, we kept things snappy and responsive (closer to Hades / Kill Knight) and scoped it realistically for a 4-week production. I started from Unreal’s Twin Stick template character and tuned movement & camera values to remove the “template feel” while keeping iteration fast. We also built a dash as the core mobility tool (covered in detail above), so the rest of the controller needed to stay clean and predictable around it.
-
Movement: tight, snappy acceleration/response; focused on player control over simulation.
-
Aim: mouse + keyboard, PC-only, isometric.
-
Camera: follow camera with a deadzone, plus mouse-driven edge panning (moving the cursor to screen extremes pans the camera) so players can scout ahead, a QoL change we added after playtesting.
We took the decision to not build a character controller from scratch because it would have been counterproductive given the short timeline, and chose to spend that time on the upgrade/modding systems that defined our game’s runs.
Movement, Aim, Camera
The shop acts as the run’s reset point every 2 levels a quick place to spend scrap, swap parts, and steer your build before the next difficulty jump.
-
Pedestal inventory: entering the shop spawns a set of items on pedestals using weighted spawn chances.
-
Pricing: each item’s cost is computed from its Attachment Slot, Rarity, and whether it rolled a Special Effect. All of these have either a value, or a multiplier associated with them.
-
Currency: players earn Scrap from killing enemies and spend it in the shop.
-
Reroll totem: rerolls replace the entire pedestal set with a new set of items.
-
Anti-spam scaling: reroll cost increases exponentially each use so players can’t brute-force perfect shops.
Shop System
Uncommon+ attachments can optionally roll a special effect:
-
Burning: damage over time
-
Slowing: move speed slow
I implemented effects as Blueprint Components so the logic stayed modular and reusable since these effects could be inflicted by elite enemies onto the player as well. On hit, we roll proc chance from the equipped item’s data (struct + data table values). If it succeeds, the weapon communicates with the enemy through an interface (no hard casts) to apply the effect.
Effects are driven by timer handles for duration/tick control, and if the same effect procs again while already active, we reset the timer instead of stacking. For Burning, I used event dispatchers to broadcast HP updates after every damage tick so UI/health state stayed in sync during the proc window.
Special Item Effects
All attachment tuning routes through the same shared pipeline:
-
Add (flat changes)
-
Multiply (scaling)
-
Set (hard overrides)
Keeping these rules consistent meant most iteration happened in struct/data table values instead of Blueprint rewrites.
Stat Application Rules
Barrel Archetypes
Archetypes are barrel-only, so the barrel is what sets the weapon’s identity:
-
Shotgun barrel: multi-shot behavior with a fixed angle spread for consistent patterns.
-
Sniper barrel: fewer shots, but higher damage/range with deliberate fire-rate tradeoffs.
-
Rifle barrel: baseline reference point so the other two feel meaningfully extreme.
Because magazines and triggers are generic, they act as tuning knobs (reload/mag size, cadence) without introducing competing weapon-family logic.
Levels are procedurally generated and end when all enemies are cleared. On enemy death, we run a per-enemy drop roll. If it succeeds, we build the drop through layered weighted selection:
-
Slot → Barrel / Mag / Trigger
-
Rarity → Common / Uncommon / Epic / Legendary
-
Barrel-only: if the slot is Barrel, roll a Barrel Archetype → Shotgun / Sniper / Rifle
-
Uncommon+ only: roll a Special Effect chance → if successful, roll Burning / Slowing
Once selected, we pull the matching row from our Data Tables, populate the attachment struct, and spawn the pickup into the inventory flow.
I personally worked on the logic flow for loot generation, but most of the functions for this were made by our programmer in C++, which I then integrated into our Blueprints.
Loot Generation (Drops, Barrel Archetypes, Rarity, Special Effects)
Live Modding Screen
Implementation-wise, the system is driven through enums + structs + data tables so we could iterate quickly without rewriting Blueprint logic.
At a high level, an attachment is defined by:
-
EAttachmentSlot (Barrel / Mag / Trigger)
-
ERarity (Common / Uncommon / Epic / Legendary)
-
Stat payload values (damage/range multipliers, shot count adds, reload/mag changes, etc.)
-
Optional ESpecialEffect (None / Burning / Slowing) (only rollable on Uncommon+ and chance-based)
For barrels, we also store:
-
EBarrelType (Shotgun / Sniper / Rifle)
The attachment struct was the single source of truth for gameplay and UI. When the player equips a part, we read the struct values, apply them through the shared stat pipeline, and update the weapon mesh to match the equipped configuration.
To keep scaling consistent and avoid item-specific exceptions, stat changes are applied through a simple shared rule set: Add / Multiply / Set. That kept balancing predictable and let us expand the system through authored data instead of new Blueprint branches.
System Architecture (Structs, Enums, Data Tables)
Design Intent
Weapon Modding, Stats, & Item Generation
Technical Solutions
-
A dash that phases through obstructions can place the player inside walls/enemies or other blocking collision.
-
Checking only the max dash endpoint is unreliable - dense combat spaces often make the “ideal” endpoint invalid.
-
Even if a position isn’t inside geometry, it can still be unusable if there’s no valid ground beneath it.
Design Problems
Because the dash lets the player phase through enemies and obstructions, we needed a system that guarantees the dash always ends in a safe, standable spot. I split the logic into two pieces: one function to search for the best endpoint within range, and another to validate whether that endpoint is actually usable.
Implementation & System Design
-
This is the only movement-based ability in the game and is intentionally limited by a cooldown.
-
Designed to give players a reliable escape option in tight situations that feels satisfying and snappy to use.
-
Cooldowns and limited availability prevent the dash from being abused, preserving difficulty and the importance of positioning.
-
Introduces a clear risk–reward decision, where poor timing can leave the player vulnerable.
-
Supports player skill expression through the ability to chain dashes, rewarding confident and precise usage.
-
Ties into the overall goal of creating a fast, arcade-style experience with expressive, momentum-driven movement.
Player Experience Goals
I designed the dash as a directional movement ability so players could dodge enemy attacks without having to pull their aim away from the fight. A key part of the design was allowing up to two chained dashes, which created satisfying movement moments and helped keep the gameplay aggressive - something I really enjoyed in Hades and Kill Knight, both of which were strong inspirations for this system.
The dash was mainly created to handle situations where enemies could swarm the player, letting them phase through enemies and obstructions to break out, reposition, and survive without disrupting the flow of combat.
Overview
Dash Ability: Design & Implementation
-
Create an arcade-style experience focused on immediate, straightforward fun rather than long-term commitment.
-
Keep a low barrier of entry, allowing players to jump in quickly without needing tutorials or heavy onboarding.
-
Design the game around short, repeatable play sessions, where players can complete a few runs and step away.
-
Focus on snappy, readable movement that feels satisfying and easy to control from the first run.
-
Design the camera to clearly communicate gameplay-critical information, while maintaining a balance between visibility, motion, and player comfort.
-
Ensure movement and camera work together to support fast decision-making and moment-to-moment gameplay flow.
Player Experience Goals & Design Intent
-
Took ownership of combat and core 3C (character, camera, and controls), handling both design and implementation.
-
Built and maintained the character stat system, including stat calculations, scaling, and runtime updates.
-
Designed and implemented the shop system, supporting player upgrades and progression.
-
Implemented in-run weapon modding, including a live weapon modding screen that allows players to modify weapons dynamically during gameplay.
-
Researched similar games in the genre (Kill Knight, Hades, Crab Champions) and drew inspiration from mechanics and systems that aligned with our project’s goals.
-
Developed a data-driven ability system (including dash, cooldowns, and conditions) that made it easy to add new abilities and passives without touching core gameplay code.
-
Set up runtime stat and modifier handling with stacking rules, caps, and tuning support, making balancing and iteration faster and more reliable across weapons and upgrades.
My Responsibilities
Scrap Gunsmith is built around fast clears: drop into a procedurally generated level, kill every enemy, grab drops, collect scrap, and take the portal that spawns at the last kill. Every 2 levels you hit a shop room to spend scrap and swap parts before pushing into harder waves. The run ends on death.
Tethered
Scrap Gunsmith
Project Slasher
Role: Gameplay, Systems, Combat, & 3C Design
Genre: Isometric Roguelike
Team Size: 9
Time Frame: 4 Weeks
Engine: Unreal
Scrap Gunsmith is an action packed twin-stick shooter set in the post apocalypse. Progress through procedurally generated levels, taking out nasty robots along the way! Don’t forget to spend your well earned scrap at the shop to upgrade your gun into the ultimate rust-bucket recycler!
The game features in run weapon customization and a simple shop system that enables replayability and unique player builds.
Core Loop
We built the upgrade loop around modular weapon attachments and a shared stat-application pipeline, so new content could be added through data (structs/data tables/enums) without rewriting combat logic. The goal was simple: builds should come from how parts combine, not from a fixed weapon path.
Attachments are designed to mix freely across the weapon system. Since only the barrel defines the archetype, players can pair something like a Sniper Barrel with any magazine and trigger, and the game still evaluates the full set of stat changes from every equipped part through the shared pipeline. The intent was to leave room for emergent gameplay and player expression: different combinations don’t just change numbers, they change how the weapon behaves, which naturally shifts decisions run to run.
-
Built GetFurthestValidLocation to find the furthest reachable dash endpoint within max distance that the player can actually stand on.
-
Uses the player’s capsule size (radius / half-height) so traces match real collision.
-
Calculates the dash direction from the player’s last input vector, keeping the dash fully directional.
-
Breaks the dash path into a set of candidate points and runs capsule traces to test occupancy (terrain / enemies / obstructions), rather than trusting a single end-point check.
-
If the furthest point is invalid, it steps back along the path and returns the closest valid fallback.
-
-
Built IsValidDashLocation as the “can I safely land here?” gate:
-
Runs a Multi Line Trace downward from the candidate point to confirm there’s supporting ground under the player.
-
If there are no hits, the location is rejected (prevents dashing to “air” / edges / weird support cases).
-
Iterates the hit results and filters out anything that would block the player by checking the hit component’s collision response (e.g., whether it blocks the pawn channel).
Here are the Blueprints for the functions:
GetFurtherValidLocation, IsValidDashLocation
-
The goal was readable and modular build-making. Each slot owns a clean slice of the build space:
-
Barrel controls Damage, Range, Shot Count, and applies Buffs/Debuffs to each slot based on the Archetype.
-
Magazine controls Mag Size and Reload Speed.
-
Trigger controls Fire Rate.
A key design decision was that only barrels carry an Archetype identity (Shotgun / Sniper / Rifle). That’s what sets the weapon’s “personality” (multi-shot vs high-damage & range vs baseline). Magazines and triggers stay generic, so they act as tuning knobs that help you stabilize or lean into whatever identity the barrel has established.
Click to Expand
Scrap Gunsmith
Thanks for Reading!
Learnings & Things I Would Do Differently
-
The naming, and the handling for the prefixes and modifiers was a complete mess. We struggled a lot towards the end of production to tweak numbers etc because it was such a hassle to do and was not intuitively set up. While I wasn't the one who set up the data tables etc, I did come up with the structure for it, and should have checked in on them earlier in production to avoid this issue.
-
A huge thing I learnt was to have clear and separated Collision Presets. Given that our game had a lot of things that had collision based interactions, the amount of time I had to spend bug fixing and trying to find what was causing the issue in terms of collisions was way more than I would've needed to had I made clear collision presets for various actors/collisions.
-
We didn't properly account for the time it would take for polishing, and didn't conduct enough playtests, which came back to bite us. Given a redo, I would've advocated for an earlier feature freeze, and spent more time on polishing and making the game feel as smooth as possible, even if it mean sacrificing on a few features to get there.
-
One of the most glaring issues in the game, is the fact that the player character sort of blends in with the rest of the surroundings. This is one of the many QoL and UX fixes that we didn't have time to prioritize since we went too heavy with the systems.
I learnt a lot about how to structure systems, and how to define clear architecture from the get go to make for easier prototyping, and scalability in terms of design and implementation. For this project, we had to define a tight scope and at the same time we wanted to create something that had it's own identity and a level of nuance. There was a lot of "kill your darlings" throughout the project. We had initially planned for a boss fight every couple levels, but that ended up being way too out of scope.
There are a number of things that I would change or do differently in this project in hindsight, but having said that, I am proud of what we managed to create at the end of the day.
Conclusion
For 3C, we kept things snappy and responsive (closer to Hades / Kill Knight) and scoped it realistically for a 4-week production. I started from Unreal’s Twin Stick template character and tuned movement & camera values to remove the “template feel” while keeping iteration fast. We also built a dash as the core mobility tool (covered in detail above), so the rest of the controller needed to stay clean and predictable around it.
-
Movement: tight, snappy acceleration/response; focused on player control over simulation.
-
Aim: mouse + keyboard, PC-only, isometric.
-
Camera: follow camera with a deadzone, plus mouse-driven edge panning (moving the cursor to screen extremes pans the camera) so players can scout ahead, a QoL change we added after playtesting.
We took the decision to not build a character controller from scratch because it would have been counterproductive given the short timeline, and chose to spend that time on the upgrade/modding systems that defined our game’s runs.
Movement, Aim, Camera
The shop acts as the run’s reset point every 2 levels a quick place to spend scrap, swap parts, and steer your build before the next difficulty jump.
-
Pedestal inventory: entering the shop spawns a set of items on pedestals using weighted spawn chances.
-
Pricing: each item’s cost is computed from its Attachment Slot, Rarity, and whether it rolled a Special Effect. All of these have either a value, or a multiplier associated with them.
-
Currency: players earn Scrap from killing enemies and spend it in the shop.
-
Reroll totem: rerolls replace the entire pedestal set with a new set of items.
-
Anti-spam scaling: reroll cost increases exponentially each use so players can’t brute-force perfect shops.
Shop System
Uncommon+ attachments can optionally roll a special effect:
-
Burning: damage over time
-
Slowing: move speed slow
I implemented effects as Blueprint Components so the logic stayed modular and reusable since these effects could be inflicted by elite enemies onto the player as well. On hit, we roll proc chance from the equipped item’s data (struct + data table values). If it succeeds, the weapon communicates with the enemy through an interface (no hard casts) to apply the effect.
Effects are driven by timer handles for duration/tick control, and if the same effect procs again while already active, we reset the timer instead of stacking. For Burning, I used event dispatchers to broadcast HP updates after every damage tick so UI/health state stayed in sync during the proc window.
Special Item Effects
All attachment tuning routes through the same shared pipeline:
-
Add (flat changes)
-
Multiply (scaling)
-
Set (hard overrides)
Keeping these rules consistent meant most iteration happened in struct/data table values instead of Blueprint rewrites.
Stat Application Rules
Archetypes are barrel-only, so the barrel is what sets the weapon’s identity:
Shotgun barrel: multi-shot behavior with a fixed angle spread for consistent patterns.
Sniper barrel: fewer shots, but higher damage/range with deliberate fire-rate tradeoffs.
Rifle barrel: baseline reference point so the other two feel meaningfully extreme.
Because magazines and triggers are generic, they act as tuning knobs (reload/mag size, cadence) without introducing competing weapon-family logic.
Barrel Archetypes
.png)
Levels are procedurally generated and end when all enemies are cleared. On enemy death, we run a per-enemy drop roll. If it succeeds, we build the drop through layered weighted selection:
-
Slot → Barrel / Mag / Trigger
-
Rarity → Common / Uncommon / Epic / Legendary
-
Barrel-only: if the slot is Barrel, roll a Barrel Archetype → Shotgun / Sniper / Rifle
-
Uncommon+ only: roll a Special Effect chance → if successful, roll Burning / Slowing
Once selected, we pull the matching row from our Data Tables, populate the attachment struct, and spawn the pickup into the inventory flow.
I personally worked on the logic flow for loot generation, but most of the functions for this were made by our programmer in C++, which I then integrated into our Blueprints.
Loot Generation (Drops, Barrel Archetypes, Rarity, Special Effects)
To make modding feel immediate, I implemented a live weapon preview using a UI Render Target. Instead of previewing the gun in the active level, I render a dedicated preview room into the inventory/modding screen so swaps feel instant and reliable.
-
Built the preview with a SceneCapture → Render Target pipeline, rendering a small room placed underneath the level.
-
On Tab (game pauses), move the weapon from the player’s hand into the preview room.
-
Keep all attachment meshes pre-placed to avoid constant spawning/despawning during rapid swaps.
-
On open and on each swap, read equipped slots and toggle mesh visibility (new part on, old part off).
-
On close, move the updated weapon back to the player with the attachments still applied.
This approach kept the modding screen fast and stable, even when players repeatedly opened/closed it mid-run.
Live Modding Screen
Implementation-wise, the system is driven through enums + structs + data tables so we could iterate quickly without rewriting Blueprint logic.
At a high level, an attachment is defined by:
-
EAttachmentSlot (Barrel / Mag / Trigger)
-
ERarity (Common / Uncommon / Epic / Legendary)
-
Stat payload values (damage/range multipliers, shot count adds, reload/mag changes, etc.)
-
Optional ESpecialEffect (None / Burning / Slowing) (only rollable on Uncommon+ and chance-based)
For barrels, we also store:
-
EBarrelType (Shotgun / Sniper / Rifle)
The attachment struct was the single source of truth for gameplay and UI. When the player equips a part, we read the struct values, apply them through the shared stat pipeline, and update the weapon mesh to match the equipped configuration.
To keep scaling consistent and avoid item-specific exceptions, stat changes are applied through a simple shared rule set: Add / Multiply / Set. That kept balancing predictable and let us expand the system through authored data instead of new Blueprint branches.
System Architecture (Structs, Enums, Data Tables)
The goal was readable and modular build-making. Each slot owns a clean slice of the build space:
Barrel controls Damage, Range, Shot Count, and applies Buffs/Debuffs to each slot based on the Archetype.
Magazine controls Mag Size and Reload Speed.
Trigger controls Fire Rate.
A key design decision was that only barrels carry an Archetype identity (Shotgun / Sniper / Rifle). That’s what sets the weapon’s “personality” (multi-shot vs high-damage & range vs baseline). Magazines and triggers stay generic, so they act as tuning knobs that help you stabilize or lean into whatever identity the barrel has established.
Design Intent
We built the upgrade loop around modular weapon attachments and a shared stat-application pipeline, so new content could be added through data (structs/data tables/enums) without rewriting combat logic. The goal was simple: builds should come from how parts combine, not from a fixed weapon path.
Attachments are designed to mix freely across the weapon system. Since only the barrel defines the archetype, players can pair something like a Sniper Barrel with any magazine and trigger, and the game still evaluates the full set of stat changes from every equipped part through the shared pipeline. The intent was to leave room for emergent gameplay and player expression: different combinations don’t just change numbers, they change how the weapon behaves, which naturally shifts decisions run to run.
Weapon Modding, Stats, & Item Generation
-
Built GetFurthestValidLocation to find the furthest reachable dash endpoint within max distance that the player can actually stand on.
-
Uses the player’s capsule size (radius / half-height) so traces match real collision.
-
Calculates the dash direction from the player’s last input vector, keeping the dash fully directional.
-
Breaks the dash path into a set of candidate points and runs capsule traces to test occupancy (terrain / enemies / obstructions), rather than trusting a single end-point check.
-
If the furthest point is invalid, it steps back along the path and returns the closest valid fallback.
-
-
Built IsValidDashLocation as the “can I safely land here?” gate:
-
Runs a Multi Line Trace downward from the candidate point to confirm there’s supporting ground under the player.
-
If there are no hits, the location is rejected (prevents dashing to “air” / edges / weird support cases).
-
Iterates the hit results and filters out anything that would block the player by checking the hit component’s collision response (e.g., whether it blocks the pawn channel).
Here are the Blueprints for the functions:
GetFurtherValidLocation, IsValidDashLocation
-
Technical Solutions
-
A dash that phases through obstructions can place the player inside walls/enemies or other blocking collision.
-
Checking only the max dash endpoint is unreliable - dense combat spaces often make the “ideal” endpoint invalid.
-
Even if a position isn’t inside geometry, it can still be unusable if there’s no valid ground beneath it.
Design Problems
Because the dash lets the player phase through enemies and obstructions, we needed a system that guarantees the dash always ends in a safe, standable spot. I split the logic into two pieces: one function to search for the best endpoint within range, and another to validate whether that endpoint is actually usable.
Implementation & System Design
-
This is the only movement-based ability in the game and is intentionally limited by a cooldown.
-
Designed to give players a reliable escape option in tight situations that feels satisfying and snappy to use.
-
Cooldowns and limited availability prevent the dash from being abused, preserving difficulty and the importance of positioning.
-
Introduces a clear risk–reward decision, where poor timing can leave the player vulnerable.
-
Supports player skill expression through the ability to chain dashes, rewarding confident and precise usage.
-
Ties into the overall goal of creating a fast, arcade-style experience with expressive, momentum-driven movement.
Player Experience Goals
I designed the dash as a directional movement ability so players could dodge enemy attacks without having to pull their aim away from the fight. A key part of the design was allowing up to two chained dashes, which created satisfying movement moments and helped keep the gameplay aggressive - something I really enjoyed in Hades and Kill Knight, both of which were strong inspirations for this system.
The dash was mainly created to handle situations where enemies could swarm the player, letting them phase through enemies and obstructions to break out, reposition, and survive without disrupting the flow of combat.
Overview
Dash Ability: Design & Implementation
-
Create an arcade-style experience focused on immediate, straightforward fun rather than long-term commitment.
-
Keep a low barrier of entry, allowing players to jump in quickly without needing tutorials or heavy onboarding.
-
Design the game around short, repeatable play sessions, where players can complete a few runs and step away.
-
Focus on snappy, readable movement that feels satisfying and easy to control from the first run.
-
Design the camera to clearly communicate gameplay-critical information, while maintaining a balance between visibility, motion, and player comfort.
-
Ensure movement and camera work together to support fast decision-making and moment-to-moment gameplay flow.
Player Experience Goals & Design Intent
Took ownership of combat and core 3C (character, camera, and controls), handling both design and implementation.
Built and maintained the character stat system, including stat calculations, scaling, and runtime updates.
Designed and implemented the shop system, supporting player upgrades and progression.
Implemented in-run weapon modding, including a live weapon modding screen that allows players to modify weapons dynamically during gameplay.
Researched similar games in the genre (Kill Knight, Hades, Crab Champions) and drew inspiration from mechanics and systems that aligned with our project’s goals.
Developed a data-driven ability system (including dash, cooldowns, and conditions) that made it easy to add new abilities and passives without touching core gameplay code.
Set up runtime stat and modifier handling with stacking rules, caps, and tuning support, making balancing and iteration faster and more reliable across weapons and upgrades.
My Responsibilities
Scrap Gunsmith is built around fast clears: drop into a procedurally generated level, kill every enemy, grab drops, collect scrap, and take the portal that spawns at the last kill. Every 2 levels you hit a shop room to spend scrap and swap parts before pushing into harder waves. The run ends on death.
Core Loop
Scrap Gunsmith is an action packed twin-stick shooter set in the post apocalypse. Progress through procedurally generated levels, taking out nasty robots along the way! Don’t forget to spend your well earned scrap at the shop to upgrade your gun into the ultimate rust-bucket recycler!
The game features in run weapon customization and a simple shop system that enables replayability and unique player builds.
Role: Gameplay, Systems, Combat, & 3C Design
Genre: Isometric Roguelike
Team Size: 9
Time Frame: 4 Weeks
Engine: Unreal
CV
Adnan Aqeel | Scrap Gunsmith
Contact
About Me
Home
Tethered
CBG Cricket Game
Scrap Gunsmith
