Reusable Weapon System — Ebben’s Portfolio

Built as a product, not a one-off feature

I created the system to support both manual and automatic weapons without locking a developer into a specific input, targeting, inventory, or character setup. The challenge was not simply making a weapon fire; it was defining clean boundaries so the same foundation could be reused across different games.

Configurable

Weapon behavior and balance data can be authored without rewriting the core system.

Extensible

Projects can provide their own attack behavior, presentation, and surrounding systems.

Verified

Automated Edit Mode and Play Mode tests protect the most important runtime behavior.

How I approached the development

1. Defined responsibilities

I separated configuration, runtime state, attack execution, and presentation. This keeps changes in one area from creating unnecessary dependencies elsewhere.

2. Designed for different projects

The weapon layer receives the information it needs but does not own unrelated game systems. That makes integration possible without forcing a full architecture.

3. Made authoring practical

ScriptableObject-based data gives developers a readable place to tune identity, damage, timing, range, critical hits, and automatic attack cycles.

4. Treated usability as part of the code

Sample content, documentation, inspector-friendly configuration, and predictable defaults were developed alongside the runtime system rather than added afterward.

System in action

Two deliberately simple examples demonstrate that different attack styles can share the same weapon foundation without exposing its source code.

A ranged weapon repeatedly attacking practice targets — A ranged example demonstrating repeatable attacks and target damage.

A rotating area weapon attacking nearby practice targets — An area-based example using the same reusable weapon foundation.

Automated testing

Because this was intended for reuse, I tested behavior that could quietly break as the product evolved. Edit Mode tests cover stat calculations, upgrades, cooldown rules, and damage outcomes. Play Mode tests exercise time-dependent automatic weapon cycles in a running Unity environment.

This lets me demonstrate engineering discipline and product reliability without exposing proprietary implementation. A Unity Test Runner result screenshot can be added here later.

Developer-facing workflow

These editor views show how a developer connects a weapon and configures its data. They communicate the system’s usability while keeping the underlying source private.

Unity inspector showing configurable weapon data — Data-driven setup for weapon identity, core stats, attack type, and optional assets.

Unity inspector showing the weapon component setup — A small component surface connects data, attack point, and optional presentation.

Unity inspector showing a different weapon using the same system — The same foundation supports a different weapon and visual behavior.

What this project demonstrates

Reusable architecture, data-driven Unity tooling, API boundary design, automated testing, documentation, and the judgment required to turn a working gameplay feature into something another developer can confidently adopt.

The source code and lower-level implementation details are intentionally not published because Reusable Weapon System was developed as a commercial product.