Unity
RevFramework Complete — Modular Gameplay Systems for Unity
By RevByDesign
$299
Rated 0.0/5 from 1 ratings on Unity.
Price history
Recorded standalone sale prices and the latest available store price, in USD. Historical dots use the sale start date and its recorded offer price. Prices can change during a sale; this is not a daily price log. Bundle prices and upcoming offers are excluded. History covers up to the 100 most recent recorded offers.
Lowest recorded standalone price in this history: $149.50. The latest store price is $299.
View 5 recorded prices
| Sale start / price check | Price | Observation |
|---|---|---|
| $299 | Latest store price | |
| $149.50 | Autumn Sale | |
| $299 | Unity First Price 2026-06-19 2026-06-26 | |
| $149.50 | Unity New Release Discount 2026-06-17 2026-07-01 | |
| $149.50 | Unity New Release Discount 2026-06-17 2026-07-01 |
Sale and bundle history
The 4 most recent recorded offers including this asset. Past offers may no longer be available. Bundle prices cover a package, not this asset alone.
About RevFramework Complete — Modular Gameplay Systems for Unity
- Tools, Systems & Learning > Game Templates & Systems
- Tools, Systems & Learning > Development Tools & Automation
- Tools, Systems & Learning > Learning & Tutorials
Eight gameplay systems, each usable on its own:
Inventory -- slot-based containers, hotbars, equipment slots and filters, stack split/merge/swap/move, replaceable sort and search strategies, JSON snapshot save and restore
Pickups -- 2D and 3D pipelines, multiple interaction modes, effect-driven architecture so you define what pickup means, decorators, cooldowns
Crafting -- job-based with preflight validation and progress tracking, batch crafting, validators, modifiers, output routing, workbenches, deterministic RNG, optional offline progress
Loot -- drop tables, weighted and independent-chance rolls, nested tables with cycle detection, and delivery that accounts for every award: given to the owner, dropped into the world, or named in an Undelivered event. Never silently discarded, which is the failure a loot system is likeliest to hide
Health -- damage and heal pipelines returning structured results, non-mutating previews safe to call from UI, shields (rechargeable, damage reduction, temporary HP, overheal, chains), regeneration, i-frames, death and revive lifecycle with before-death handlers
Status Effects -- buffs and debuffs with stack and refresh policies, DOT and HOT, dispel and cleanse, potency and duration scaling, immunity and resistance seams, auras and zones, multiple time sources
Currency -- ledger-based credit, debit and transfer, overflow-safe execution, escrow and holds with commit/release/TTL expiry, rollback-safe transaction staging, request-ID replay protection, exchange with rates, fees, limits and deterministic rounding, batched blocks with audit logs
Economy -- shop services with all-or-nothing delivery and charge refund on failure, crafting cost integration with refund and restore, reward flows
Plus a save layer: a coordinator, a file store, participant ordering, and carry-over -- so loading a save written by a build that had a system you have since removed does not discard that data permanently.
You are not buying a prefab kit. You are buying gameplay architecture.
Why It Is Different
Most Unity assets give you templates and hope the pieces fit together. RevFramework gives you systems and explanations.
Every Currency, Economy and Inventory operation returns a result object: a success flag, a machine-readable reason code, and an optional message. When a transaction does not go through, the system tells you exactly what happened.
If something fails, you know why. If a rollback occurs, you can trace it. If authority validation rejects a mutation, it is explicit. By design, not by luck.
It Teaches Itself Inside the Editor
This is where RevFramework is genuinely different, and it is the hardest part to show in a screenshot.
Teachable Panels
Interactive panels built into the framework, already placed in the sample scenes. Press Play, read what the panel is teaching, toggle the edge cases, press the buttons, and watch live results -- balances, stacks, failure reasons, state changes. When it makes sense, copy the service calls into your own UI and delete the panel.
Most are written as hostile consumers: restricted to the public API and nothing else. No internal namespaces, no reflection, no undocumented helpers, no sample-only utilities. That constraint is the point. If they compile and run, the public API is genuinely sufficient to build on.
They teach the framework and verify its API surface at the same time.
Documentation
Every system has an Overview, Mental Model, Integration Surfaces, Public API, System Guarantees Matrix, Testing Philosophy, System Boundaries and FAQ. 400+ folder-level READMEs beside the source, explaining intent and reasoning rather than restating what the code says. A guarantees matrix per system that lists what it does NOT promise as plainly as what it does. Where a page has been wrong, the correction says so instead of quietly replacing the text. Where a design costs you something, the documentation lists the cost. There is an In Development page that marks itself as intent rather than promise and names what does not exist yet.
Video
65 tutorials covering the teachable panels. 4 core onboarding videos: scope, teachables, documentation, and a live demonstration of removing and restoring systems in a real project. Every video shows real behaviour in a real scene.
Testing and Reliability
EditMode 2519 tests 36 assemblies
PlayMode 402 tests 19 assemblies
Both green, run on every push against a clean Unity project in CI. The counts are stated rather than summarised because a number you can check is worth more than an adjective.
The goal was never a coverage percentage. It was predictable architectural behaviour.
Hostile Consumer tests -- exercise the public API the way a real project would, through supported surfaces only, with no access to internals. If these pass, the contract holds.
Internal Truth tests -- pin framework assumptions so a future refactor cannot silently change behaviour: event ordering, rollback paths, authority rejection, restore semantics.
PlayMode tests -- Unity lifecycle failures that EditMode cannot reach.
Convention tests -- structural guards that stop a fixed bug class from quietly returning.
Test assemblies are not shipped -- you get clean runtime, editor, sample and teaching assemblies with no NUnit dependency and no compile overhead. The suite is a free download for owners instead.
Modularity
Modularity is enforced at the assembly level, not just by folders. Each system compiles independently -- delete Inventory and Crafting still builds. Integration lives in optional, define-gated layers rather than hard references, and scripting symbols update automatically as systems are added or removed.
One deliberate exception: Economy is the integration layer over Currency and Inventory, so it builds on both by design.
No prefabs. No required singletons -- every service is an instance you create, own and can substitute. No MonoBehaviour soup.
Multiplayer and Networking
Stated plainly because it is the likeliest mistaken assumption. RevFramework is netcode-agnostic: it does not implement networking, replication, prediction or rollback.
Authority binders let you gate mutations through your own ownership and permission rules across every system -- NGO, Mirror, Photon, Fusion, or something you wrote. We give you the rules; your netcode drives the simulation.
UI
Reference UI is included across all systems. It shows you how to talk to the systems correctly -- it is not your game UI. Build your own with Canvas, UI Toolkit, or whatever fits.
RevFramework gives you the foundations. You build the game.
Every system. Every failure. If something fails, it tells you why.
That is not a feature. It is the foundation everything else is built on.
Inventory -- slot-based containers, hotbars, equipment slots and filters, stack split/merge/swap/move, replaceable sort and search strategies, JSON snapshot save and restore
Pickups -- 2D and 3D pipelines, multiple interaction modes, effect-driven architecture so you define what pickup means, decorators, cooldowns
Crafting -- job-based with preflight validation and progress tracking, batch crafting, validators, modifiers, output routing, workbenches, deterministic RNG, optional offline progress
Loot -- drop tables, weighted and independent-chance rolls, nested tables with cycle detection, and delivery that accounts for every award: given to the owner, dropped into the world, or named in an Undelivered event. Never silently discarded, which is the failure a loot system is likeliest to hide
Health -- damage and heal pipelines returning structured results, non-mutating previews safe to call from UI, shields (rechargeable, damage reduction, temporary HP, overheal, chains), regeneration, i-frames, death and revive lifecycle with before-death handlers
Status Effects -- buffs and debuffs with stack and refresh policies, DOT and HOT, dispel and cleanse, potency and duration scaling, immunity and resistance seams, auras and zones, multiple time sources
Currency -- ledger-based credit, debit and transfer, overflow-safe execution, escrow and holds with commit/release/TTL expiry, rollback-safe transaction staging, request-ID replay protection, exchange with rates, fees, limits and deterministic rounding, batched blocks with audit logs
Economy -- shop services with all-or-nothing delivery and charge refund on failure, crafting cost integration with refund and restore, reward flows
Plus a save layer: a coordinator, a file store, participant ordering, and carry-over -- so loading a save written by a build that had a system you have since removed does not discard that data permanently.
You are not buying a prefab kit. You are buying gameplay architecture.
Why It Is Different
Most Unity assets give you templates and hope the pieces fit together. RevFramework gives you systems and explanations.
Every Currency, Economy and Inventory operation returns a result object: a success flag, a machine-readable reason code, and an optional message. When a transaction does not go through, the system tells you exactly what happened.
If something fails, you know why. If a rollback occurs, you can trace it. If authority validation rejects a mutation, it is explicit. By design, not by luck.
It Teaches Itself Inside the Editor
This is where RevFramework is genuinely different, and it is the hardest part to show in a screenshot.
Teachable Panels
Interactive panels built into the framework, already placed in the sample scenes. Press Play, read what the panel is teaching, toggle the edge cases, press the buttons, and watch live results -- balances, stacks, failure reasons, state changes. When it makes sense, copy the service calls into your own UI and delete the panel.
Most are written as hostile consumers: restricted to the public API and nothing else. No internal namespaces, no reflection, no undocumented helpers, no sample-only utilities. That constraint is the point. If they compile and run, the public API is genuinely sufficient to build on.
They teach the framework and verify its API surface at the same time.
Documentation
Every system has an Overview, Mental Model, Integration Surfaces, Public API, System Guarantees Matrix, Testing Philosophy, System Boundaries and FAQ. 400+ folder-level READMEs beside the source, explaining intent and reasoning rather than restating what the code says. A guarantees matrix per system that lists what it does NOT promise as plainly as what it does. Where a page has been wrong, the correction says so instead of quietly replacing the text. Where a design costs you something, the documentation lists the cost. There is an In Development page that marks itself as intent rather than promise and names what does not exist yet.
Video
65 tutorials covering the teachable panels. 4 core onboarding videos: scope, teachables, documentation, and a live demonstration of removing and restoring systems in a real project. Every video shows real behaviour in a real scene.
Testing and Reliability
EditMode 2519 tests 36 assemblies
PlayMode 402 tests 19 assemblies
Both green, run on every push against a clean Unity project in CI. The counts are stated rather than summarised because a number you can check is worth more than an adjective.
The goal was never a coverage percentage. It was predictable architectural behaviour.
Hostile Consumer tests -- exercise the public API the way a real project would, through supported surfaces only, with no access to internals. If these pass, the contract holds.
Internal Truth tests -- pin framework assumptions so a future refactor cannot silently change behaviour: event ordering, rollback paths, authority rejection, restore semantics.
PlayMode tests -- Unity lifecycle failures that EditMode cannot reach.
Convention tests -- structural guards that stop a fixed bug class from quietly returning.
Test assemblies are not shipped -- you get clean runtime, editor, sample and teaching assemblies with no NUnit dependency and no compile overhead. The suite is a free download for owners instead.
Modularity
Modularity is enforced at the assembly level, not just by folders. Each system compiles independently -- delete Inventory and Crafting still builds. Integration lives in optional, define-gated layers rather than hard references, and scripting symbols update automatically as systems are added or removed.
One deliberate exception: Economy is the integration layer over Currency and Inventory, so it builds on both by design.
No prefabs. No required singletons -- every service is an instance you create, own and can substitute. No MonoBehaviour soup.
Multiplayer and Networking
Stated plainly because it is the likeliest mistaken assumption. RevFramework is netcode-agnostic: it does not implement networking, replication, prediction or rollback.
Authority binders let you gate mutations through your own ownership and permission rules across every system -- NGO, Mirror, Photon, Fusion, or something you wrote. We give you the rules; your netcode drives the simulation.
UI
Reference UI is included across all systems. It shows you how to talk to the systems correctly -- it is not your game UI. Build your own with Canvas, UI Toolkit, or whatever fits.
RevFramework gives you the foundations. You build the game.
Every system. Every failure. If something fails, it tells you why.
That is not a feature. It is the foundation everything else is built on.