Every new game project starts with the same boilerplate; audio managers, scene transitions, save systems, haptic feedback wrappers, analytics hooks, UI scaffolding. None of it is unique to the game, yet every team rebuilds it from scratch.
At Ocean View Games, we decided to stop paying that tax. When we developed What's That (a mobile quiz game) we treated it as a live testbed for a reusable framework. The game shipped successfully, but the real deliverable was the modular component library we extracted from it.
That library now lets us kickstart client projects 30-50% faster than starting from an empty Unity project.
The Problem: Rewriting the Same Code, Every Project
In our first year of client work, we noticed a pattern. Every mobile game needs:
- An audio manager that handles music, SFX, and volume preferences
- A scene manager that handles transitions, loading screens, and deep links
- A save system that serialises player state to local storage
- A haptic feedback wrapper that unifies iOS Taptic Engine and Android vibration
- A UI system with common patterns (modals, toasts, loading spinners)
- An analytics hook that fires events without coupling to a specific provider
Each of these takes 2-5 days to build properly. Across a 6-8 week project, that is 2-3 weeks spent on infrastructure before any gameplay code is written.
The hypercasual market amplified this. Clients need MVPs fast, sometimes in 4-6 weeks. Spending half that time on boilerplate is not competitive.
Key Takeaway: If you are building the same systems for every project, you are either billing clients for redundant work or absorbing the cost yourself. Neither is sustainable.
Our Approach: Extract, Standardise, Test
We did not design the framework top-down. We built it bottom-up by extracting battle-tested code from a shipping game.
Step 1: Build It in a Real Product
What's That was deliberately scoped to exercise a wide range of common systems, including audio, UI, persistence, haptics, and scene management. We built each system with slightly more abstraction than the game needed, knowing we would extract it later.
Step 2: Decouple and Package
After the game shipped, we reviewed each system and asked: "Does this depend on anything specific to What's That?" If yes, we refactored to remove the coupling. If no, it went into the framework as-is.
The result is a set of independent modules, each with:
- A clear public API
- No dependencies on other framework modules (unless explicitly declared)
- A prefab or ScriptableObject for configuration
- Basic unit tests
Step 3: Validate on Client Projects
The real test of a framework is whether it survives contact with a different game. We deployed it on three subsequent client projects and tracked where it needed adjustment. The first project revealed that our audio manager did not handle background/foreground transitions correctly on Android. The second revealed that the save system needed encryption support. Each fix went back into the framework.
What Is in the Framework
Audio Manager
A singleton that manages three audio layers (music, SFX, ambient) with independent volume controls. Key features:
- Crossfade transitions between music tracks
- Automatic ducking (SFX lowers music volume momentarily)
- Handles app minimisation - music pauses when the app loses focus and resumes correctly
- Volume preferences persist via the save system
Haptic Feedback Wrapper
iOS and Android handle haptics completely differently. iOS has the Taptic Engine with structured feedback types (light, medium, heavy, selection). Android has raw vibration with duration and amplitude.
Our wrapper provides a unified API:
HapticFeedback.Light()- maps to iOS selection feedback, Android 10ms vibrationHapticFeedback.Medium()- maps to iOS impact feedback, Android 25ms vibrationHapticFeedback.Heavy()- maps to iOS notification feedback, Android 50ms vibration
Tuned through extensive playtesting so each tier feels perceptually equivalent across platforms.
Scene Manager
Handles scene transitions with configurable loading screens. Supports:
- Fade-to-black transitions with customisable curves
- Async scene loading with progress callbacks
- Scene preloading for seamless transitions
- Deep link handling (opening the app to a specific scene)
Save System
A lightweight serialisation layer built on top of Unity's PlayerPrefs with added structure:
- Type-safe accessors (no raw string keys scattered through the codebase)
- Optional AES encryption for sensitive data
- Versioned save format with migration support
- Automatic backup before writes
UI Component Library
Pre-built, themeable components following a consistent interaction pattern:
- Modal dialogs with backdrop tap-to-dismiss
- Toast notifications with auto-dismiss timers
- Loading overlays with progress indicators
- Button components with squash-and-stretch press animations and sound
The Impact on Client Projects
The framework does not eliminate custom work. Every game still needs unique gameplay code, art integration, and design iteration. What it eliminates is the first two weeks of setup.
On a recent project for Mojo Games (Pocket Factory), the framework saved an estimated 10 days of development time. Audio, haptics, and scene management were configured in hours rather than days. That time went directly into gameplay polish; the part of development that actually differentiates the product.
Key Takeaway: A framework's value is not just speed but also consistency. When audio, saves, and UI follow proven patterns, the defect rate drops because you are not debugging new code for solved problems.
When to Build Your Own Framework
Not every studio should build a framework. It makes sense when:
- You ship multiple projects per year - the investment amortises across releases
- Your projects share a platform - a mobile Unity framework does not help with a desktop Unreal project
- You have battle-tested code to extract - do not design a framework speculatively; extract it from a shipping product
- Your team is disciplined about updates - a framework that is not maintained becomes a liability
If you ship one game every two years, the overhead of maintaining a framework probably exceeds the time it saves. Focus on clean, well-documented code instead.
