Building Reusable Game Frameworks: How We Ship Games 50% Faster

Source: Dev.to

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 test‑bed 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 kick‑start client projects 30‑50 % faster (Rapid Prototyping Hyper‑Casual Framework) 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:

• Audio manager – handles music, SFX, and volume preferences
• Scene manager – handles transitions, loading screens, and deep links
• Save system – serialises player state to local storage
• Haptic‑feedback wrapper – unifies iOS Taptic Engine and Android vibration
• UI system – common patterns (modals, toasts, loading spinners)
• Analytics hook – 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’s 2–3 weeks spent on infrastructure before any gameplay code is written.

The hyper‑casual 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 (audio, UI, persistence, haptics, 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 → refactor to remove the coupling.
• If no → add it to 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

A framework’s worth is proven when it survives contact with a different game. We deployed it on three subsequent client projects and tracked required adjustments:

1. Audio manager – didn’t handle background/foreground transitions correctly on Android.
2. Save system – needed encryption support.

Each fix was fed 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.

• Cross‑fade 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. Our wrapper provides a unified API:

HapticFeedback.Light();   // iOS selection feedback, Android 10 ms vibration
HapticFeedback.Medium();  // iOS impact feedback, Android 25 ms vibration
HapticFeedback.Heavy();   // iOS notification feedback, Android 50 ms vibration

Tuned through extensive play‑testing so each tier feels perceptually equivalent across platforms.

Scene Manager

Handles scene transitions with configurable loading screens.

• Fade‑to‑black transitions with customizable curves
• Async scene loading with progress callbacks
• Scene pre‑loading 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, and that time went directly into gameplay.

Ready to accelerate your next Unity project?
Explore the full framework and case studies on our website: https://oceanviewgames.co.uk

Lay 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.

Related Reading

• What’s That Case Study – How we built the framework
• Game Development Services – Our full development offering
• What’s That Project Page – The game that started it all