Skip to content

RevFramework – Pickups • FAQ

This FAQ answers decision questions about the Pickups system.

It is not a feature list or a repeat of the READMEs — it exists to help you decide:

  • Is this the right extension point?
  • Why does this behave the way it does?
  • Am I integrating this correctly?

If you’re looking for setup or API details, see the folder READMEs instead.

This page focuses on integration decisions and architectural intent, not basic usage.

❓ How do I integrate Pickups into my game?

World pickups (fastest path)

Use this when the pickup should trigger automatically on contact.

Do this:

  • Add TriggerPickup to a prefab
  • Add TriggerRelay2D or TriggerRelay3D
  • Assign a PickupEffect (usually built from a Definition)
  • Set layer/tag filters if needed

Avoid:

  • Writing custom trigger logic
  • Calling effects directly from OnTriggerEnter

Interactable pickups (player input)

Use this when the pickup requires player intent.

Do this:

  • Subclass InteractablePickupBase
  • Implement DoPickup(GameObject actor)
  • Trigger success/failure via return value

Avoid:

  • Putting effect logic directly in the interactable
  • Mixing input handling with effect execution

❓ Is Pickups tied to Inventory, Health, or Currency?

No.

Pickups is modular:

  • Inventory integration is optional (via custom effects)
  • Currency integration is optional (via custom effects)
  • Health integration is optional (via custom effects or bridges)

Pickups itself introduces no hard dependency on these systems.

If an integration is not present:

  • behaviour depends on your effect implementation
  • some effects may safely do nothing
  • others may require guards or null checks

Pickups does not enforce integration behaviour — your effects do.

❓ Why didn’t my pickup apply its effect?

Check these in order:

1. Authority

  • Is an IPickupAuthority present and returning false?
  • No authority = allowed by default

2. Null-damageable rules

  • Does the effect require IDamageable?
  • If yes and missing → effect will not run

3. Conditional decorators

  • Tag, RNG, or other conditions may block execution

4. Cooldowns

  • Effect may still be on cooldown for that owner

5. Layer / tag filters

  • TriggerPickup may be rejecting the actor

❓ Why did my pickup trigger twice?

Usually caused by multiple colliders on the same actor.

Examples:

  • capsule + feet collider
  • rigidbody + child colliders
  • composite 2D setups

Pickups prevents duplicate consumption within a single physics step using an internal latch.

If it still happens:

  • check for multiple pickup components
  • check overlapping interactables
  • check duplicate relay components

❓ Should I put gameplay logic in Effects or Interactables?

Effects. Always.

  • Effects = gameplay logic
  • Interactables = input + flow control

Interactables should:

  • decide when a pickup happens
  • not decide what the effect does

If logic lives in interactables, it becomes:

  • harder to reuse
  • harder to decorate
  • harder to test

❓ When should I use a Decorator vs a new Effect?

Use a Decorator when:

  • adding cross-cutting behaviour (VFX, SFX, logging, conditions)
  • behaviour should apply to multiple effects
  • core effect should remain unchanged

Use a new Effect when:

  • implementing new gameplay logic
  • behaviour is specific and not reusable

Rule of thumb:

Effects do gameplay. Decorators decorate.

❓ Why are Decorator priorities "backwards"?

They are explicit and deterministic:

  • Lower values = inner
  • Higher values = outer

At runtime:

  • outer decorators run first (BeforeApply)
  • inner decorators run closest to the core effect

❓ Does Pickups handle multiplayer replication?

No. By design.

Pickups only answers:

“Can this actor consume this pickup?”

Replication, prediction, rollback, and despawning belong to your networking layer.

Pickups provides:

  • authority hooks
  • clean execution seams

❓ Can I safely remove parts of Pickups?

Yes — if you respect boundaries.

Typically safe to remove if unused:

  • feedback components
  • specific decorators or effects

Do not remove:

  • Core/
  • Abstractions/
  • Definitions/

If other systems are removed:

  • Pickups still works
  • related effects must handle missing integrations safely

❓ Is Pickups meant for no-code designers?

No.

Pickups is designed for developers who:

  • are comfortable with C#
  • want explicit, inspectable behaviour
  • prefer modular systems over hidden logic

Designers can author Definitions, but system behaviour is developer-driven.

🧭 Final Guidance

If you’re unsure where something belongs:

Concern Correct Surface
Gameplay logic PickupEffect
Reusable behaviour PickupEffectDecorator
Authoring data PickupEffectDefinitionBase
Scene glue runtime components (TriggerPickup, InteractablePickupBase)
UX response IPickupFeedback
Policy / rules IPickupAuthority

If you follow that split, Pickups stays clean and scalable.