Skip to main content

Best Practices

Cube Weapon has been designed to be highly modular and scalable.

While the framework is flexible enough to support many different workflows, following a few recommended practices will help keep your project organized, maintainable and easy to extend.

This chapter collects the recommendations used throughout the previous chapters.

Treat Weapon Masters as Platforms​

A Weapon Master should describe a weapon platform—not a specific weapon configuration.

For example:

✔ Good

Weapon Master

M4 Platform

Weapon Builds

CQB Rifle

Marksman Rifle

Support Rifle

Training Rifle

✘ Avoid

Weapon Master

M4 CQB

M4 Marksman

M4 Desert

M4 Urban

Different configurations should almost always be represented by different Weapon Builds.

Reuse Weapon Parts​

Weapon Parts are designed to be shared.

If multiple weapons use the same attachment, create the part once and reuse it.

For example:

Red Dot Sight

        │

        ├── M4

        ├── SCAR

        ├── MP5

        └── G36

Reusing assets keeps balancing consistent and significantly reduces duplicated content.

Keep Assets Organized​

As your project grows, maintaining a consistent folder structure becomes increasingly important.

A recommended layout is:

Weapons
│
├── Assault Rifle
│   ├── Weapon Master
│   ├── Weapon Builds
│   ├── Parts
│   ├── Meshes
│   ├── Materials
│   ├── Icons
│   └── Animations
│
├── Shotgun
│
└── Sniper Rifle

Keeping every weapon platform self-contained makes navigation much easier.

Separate Gameplay from Weapon Data​

Cube Weapon already separates runtime behaviour from weapon configuration.

Try to follow the same principle in your own project.

Avoid placing gameplay logic inside Data Assets.

Instead:

  • Use Data Assets to describe content.
  • Use Blueprints to implement gameplay.
  • Let Cube Weapon manage weapon creation and lifecycle.

Let Cube Weapon Manage Runtime Objects​

Weapon Actors should always be considered temporary.

Keep internal actor creation and character attachment on their supported operation paths. External allocation, pool return and actor release are project responsibilities.

Instead, use the Blueprint nodes provided by Cube Weapon.

Use internal Acquire for built-in actors. For external allocation and cleanup, implement the controller callbacks. Unequip does not destroy or detach an actor automatically.

Store Weapon Builds​

Inventories and save systems should always store Weapon Builds.

Never store Weapon Actors.

Weapon actors may remain allocated until your cleanup or pooling implementation releases them.

Weapon Builds represent the actual weapon configuration and can be recreated at any time.

Build Small Blueprints​

Cube Weapon is designed to reduce Blueprint complexity.

Instead of creating large Blueprint graphs, divide gameplay into smaller reusable systems.

For example:

  • Inventory
  • Interaction
  • Character
  • User Interface
  • Equipment

Each system should communicate with Cube Weapon rather than directly manipulating weapon actors.

Use Meaningful Names​

As your weapon library grows, clear naming becomes essential.

Recommended examples:

Weapon Masters

DA_WM_M4

DA_WM_MP5

DA_WM_AK74

Weapon Builds

WB_CQB

WB_Marksman

WB_Suppressed

Weapon Parts

DA_Barrel_Long

DA_Barrel_Short

DA_Scope_RedDot

DA_Magazine_30Rnd

Consistent naming makes large projects much easier to maintain.

Avoid Duplicating Data​

Whenever possible:

  • Reuse Weapon Parts.
  • Reuse Weapon Masters.
  • Create new Weapon Builds instead of new weapon assets.

Duplicated assets increase maintenance and make balancing more difficult.

Design for Expansion​

When creating your own content, assume that additional weapons and parts will be added later.

A scalable asset structure today will save a considerable amount of work as your project grows.

Cube Weapon was designed with scalability in mind—your content should follow the same philosophy.

Summary​

Following these recommendations will help you:

  • Keep projects organized
  • Reduce duplicated assets
  • Simplify balancing
  • Improve maintainability
  • Make future plugin updates easier
  • Scale your weapon library without restructuring your project

Cube Weapon is designed to manage the technical complexity of modular weapons, allowing you to focus on creating gameplay and content.

Validate and Register Explicitly​

Register all master/part IDs in configured databases. After importing or modifying a working build, queue validation and wait for OnBuildValidatedCallback. Do not use stale validation flags or submit Equip with an unregistered build GUID.

Coordinate Asynchronous Stages​

Bind completion delegates before submitting operations. Serialize dependent working-build edits. Handle authority creation, client replication and actor acquisition separately rather than assuming one event fires in every network mode.

Keep Configuration and Gameplay State Separate​

Store FWeaponBuildData in your inventory/save workflow and keep current ammo, durability and other state in separate project records. Reuse asset definitions, but give independently editable weapon configurations independent GUIDs.