DEV Community: Ocean View Games

Game Development Budget Breakdown: Where Does the Money Go?

Ocean View Games — Sat, 26 Sep 2026 23:16:35 +0000

One of the most common questions we hear from clients is deceptively simple: "How much will my game cost?" The honest answer is always "it depends," but that does not mean we cannot give you a clear framework for understanding where the money goes and why.

Between David and Adam, our experience spans mobile, PC, educational games, legacy modernisation, and large live-game codebases. That gives us a useful planning framework for where budgets tend to go, even though the exact split changes substantially from project to project.

This post breaks down the major cost categories in a typical game development budget, explains what drives spending in each one, and offers guidance on where to prioritise when funds are limited.

The Five Core Budget Categories

For planning, we split game-development budgets into five core categories. The exact percentages shift with genre, scope, art requirements, platform targets, and team structure. The ranges below are heuristics based on the kinds of projects we scope, not universal industry benchmarks.

Category	Typical Share	What It Covers
Engineering	40-50%	Gameplay programming, systems architecture, networking, platform porting
Art & Audio	20-30%	2D/3D art, animation, UI design, VFX, music, sound effects
Design	10-15%	Game design, level design, economy balancing, UX research
QA & Testing	5-10%	Functional testing, device testing, performance profiling, regression
Project Management	5-10%	Production, scheduling, client communication, tooling

These numbers assume you are working with an external development partner or agency. If you are building in-house, the ratios still hold, but the absolute numbers will include salary overheads, equipment, and office costs that are baked into agency rates.

Engineering: 40-50% of the Budget

Engineering is usually the largest cost on the projects we scope, and for good reason. Your engineers are not just writing gameplay code - they are building the foundational systems that everything else sits on top of.

What Drives Engineering Costs

Core systems architecture - the skeleton of your game. This includes input handling, scene management, save systems, and the gameplay loop itself. A robust architecture pays dividends later; a fragile one creates exponential technical debt.
Networking and multiplayer - if your game has any online component, expect engineering costs to increase significantly. Server-authoritative backends, state synchronisation, lag compensation, and matchmaking systems are complex and require specialist expertise. When we built the networking layer for Domi Online, we used FishNet on a cost-optimised AWS infrastructure specifically to keep operational expenses sustainable without sacrificing security or performance.
Platform-specific work - shipping on iOS and Android is not simply "building once." Each platform has its own APIs, compliance requirements, input systems, and performance characteristics. Console porting adds another layer of complexity with certification requirements (TRC, XR, Lotcheck).
Performance optimisation - mobile devices have strict thermal, memory, and battery constraints. David's previous work on RuneScape Mobile at Jagex reinforced how much engineering can sit behind making a desktop-scale game behave well on mobile hardware. Even much smaller games need profiling and optimisation passes on real devices.
Third-party integrations - analytics, ad mediation, in-app purchases, authentication, cloud save, and push notifications. Each SDK integration carries its own implementation and maintenance cost.

Key Takeaway: Do not underestimate engineering costs for "simple" games. A 2D puzzle game still needs save systems, monetisation integration, device testing, and store compliance. The visible gameplay is often the smallest part of the engineering workload.

Where to Save

Use proven frameworks and libraries rather than building everything from scratch. Our internal development framework shortens setup by reusing standardised components for audio, haptics, UI, and scene management instead of rebuilding the same foundations on every project.
Prioritise your core loop. Get the one thing that makes your game fun working before investing in ancillary systems.
Choose your platforms carefully at launch. Shipping on one platform first and porting later is almost always cheaper than simultaneous multi-platform development.

Art and Audio: 20-30% of the Budget

Art is what players see first. It drives store page conversion, first impressions, and perceived quality. But it is also the category where scope creep is most dangerous.

What Drives Art Costs

Visual fidelity - a hyper-casual game with flat 2D art costs a fraction of a game with hand-painted environments and 3D character animations. The gap is enormous.
Asset volume - an open-world game needs hundreds or thousands of unique assets. A puzzle game might need dozens. When we developed Empires Rise, our internal 4X strategy game, sourcing and integrating art assets across multiple civilisations and biomes was a significant production effort.
Animation - character animation, UI animation, and VFX all require specialised skills. Skeletal animation systems (Spine, Unity's Animation Rigging) reduce costs compared to frame-by-frame approaches, but still require skilled artists.
Audio - music, sound effects, and voice acting. Often underbudgeted, audio is critical to game feel. A good sound designer can make a £10,000 game feel like a £100,000 game.
UI/UX design - interface design for games is a specialised discipline, particularly for mobile. Touch targets, safe areas, adaptive layouts, and platform-specific conventions all matter.

Where to Save

Define your art style early and stick to it. Style changes mid-production are the single most expensive art decision.
Use asset stores strategically for non-hero content (background foliage, generic sound effects), but invest in custom work for anything the player interacts with directly.
Modular art pipelines reduce cost at scale. Design characters, environments, and UI elements as composable pieces rather than bespoke one-offs.

Design: 10-15% of the Budget

Game design is often the most undervalued line item, yet it has the highest leverage on your game's commercial success. A well-designed game with modest art will outperform a beautiful game with poor mechanics.

What Drives Design Costs

Game Design Documentation (GDD) - the blueprint for your entire project. A thorough GDD covers mechanics, progression, economy, UI flows, and technical specifications. This document prevents expensive mid-production pivots.
Economy and balancing - free-to-play games live or die by their economy design. Modelling currency flows, progression curves, and pricing requires data-driven iteration that continues well past launch.
Level design - creating engaging content that uses your mechanics effectively. For Navigo, the educational game our team built during a previous agency tenure for the EU Horizon 2020 programme, designing 15 unique mini-games across four languages required extensive collaboration with educational specialists.
User research and playtesting - testing with real players reveals problems that no amount of internal review will catch. Budget for at least two rounds of structured playtesting.

Where to Save

Invest heavily in pre-production design. Every pound spent on design validation before production begins saves five to ten pounds in engineering rework.
Use greybox prototyping to validate mechanics before committing to art production. We build playable Unity prototypes in our game design process specifically to find the fun before spending on final assets.

Key Takeaway: Design and prototyping are high-leverage spend. A clear GDD and an early playable prototype can expose expensive assumptions before they turn into production rework.

QA and Testing: 5-10% of the Budget

QA is the category that gets cut first when budgets tighten, and it is the category that causes the most damage when underfunded. A crash-heavy launch or a broken tutorial will tank your store rating and retention metrics.

What Drives QA Costs

Device fragmentation - Android alone has thousands of device configurations. Testing across a representative set of screen sizes, chipsets, and OS versions is essential for mobile games.
Regression testing - every new feature risks breaking existing ones. Systematic regression sweeps before each build delivery catch issues before players do.
Performance profiling - ensuring stable frame rates, acceptable memory usage, and manageable thermal output across your target devices. This is particularly critical for mobile, where a game that overheats the phone will be uninstalled immediately.
Platform certification - console submissions (TRC, XR, Lotcheck) require extensive pre-validation. A failed certification costs weeks of delay.
Live service testing - if your game receives updates, every patch needs testing. Seasonal events, balance changes, and new content all carry regression risk.

Where to Save

Automate where possible. Unit tests for core systems and automated build verification catch regressions cheaply.
Prioritise the critical path. Test the first-time user experience and core gameplay loop exhaustively. Edge cases in rarely-used menus can wait.
Integrate QA into your development pipeline from day one, not as an afterthought at the end of production.

Project Management: 5-10% of the Budget

Project management is the glue that holds everything together. It includes production scheduling, client communication, risk management, and the tools that enable the team to collaborate effectively.

What Drives PM Costs

Team coordination - the larger the team and the more external dependencies (freelancers, external art studios, platform holders), the more management overhead is required.
Client communication - regular sprint reviews, playable demos, and status reports take time to prepare but are essential for maintaining alignment.
Tooling and infrastructure - Jira, Notion, version control (Git, Perforce, Plastic SCM), CI/CD pipelines, and cloud services all carry licence and maintenance costs.
Risk management - identifying and mitigating technical and schedule risks before they become crises. A good producer pays for themselves many times over.

Where to Save

Use agile methodologies with two-week sprints. Short cycles surface problems early when they are cheap to fix.
Invest in good tooling. The cost of a Jira licence is trivial compared to the cost of miscommunication.
Define scope clearly at project start. The single biggest driver of PM overhead is scope creep.

Budget Allocation by Game Type

The ranges below are illustrative planning examples, not fixed market prices. Existing code, supplied art, content volume, platform requirements, and technical risk can move a real quote substantially.

The percentages above are averages. Here is how they shift for common game types:

Mobile Casual / Hyper-Casual

Engineering: 35-40%
Art: 25-30%
Design: 10-15%
QA: 5-10%
PM: 5-10%
Total range: £30,000-150,000

Mobile Mid-Core (Strategy, RPG)

Engineering: 40-50%
Art: 20-30%
Design: 10-15%
QA: 5-10%
PM: 5-10%
Total range: £100,000-500,000

Multiplayer / Online Games

Engineering: 45-55% (networking costs increase significantly)
Art: 15-25%
Design: 10-15%
QA: 10-15% (multiplayer testing is more complex)
PM: 5-10%
Total range: £200,000-2,000,000+

Educational / Serious Games

Engineering: 35-45%
Art: 20-25%
Design: 15-20% (curriculum alignment increases design work)
QA: 5-10%
PM: 5-10%
Total range: £50,000-300,000

Planning Your Budget: Practical Steps

Start with scope, not budget - define what your game needs to do before setting a number. Our game development cost estimator can help you build a baseline estimate.
Build a contingency - leave meaningful budget and schedule margin for unknowns. The right percentage depends on how much of the design, technology, and content is already proven.
Phase your investment - do not commit the entire budget before the riskiest assumptions have been tested. Use discovery and prototyping to decide whether the full production investment still makes sense.
Understand the cost of delay - a three-month delay does not just cost three months of developer time. It costs three months of missed revenue, three months of market timing risk, and the opportunity cost of what your team could have built instead.
Get an external estimate - even if you are building in-house, an external perspective on scope and cost can reveal blind spots. Our game development cost breakdown provides additional context on what drives pricing.

Why Your Legacy Educational Game Needs an Update

Ocean View Games — Sat, 26 Sep 2026 23:16:28 +0000

Somewhere in your organisation, there is an educational game that was built five, ten, or even fifteen years ago. It might have been a Flash-based interactive for a museum. It might be a Unity 4 app that no longer compiles. It might be a Java applet that last ran reliably in Internet Explorer 8. Whatever it is, it was effective when it launched - teachers loved it, learners engaged with it, and the investment paid for itself many times over.

But now it is dying. Not because the content is wrong or the pedagogy is outdated, but because the technology underneath it has become obsolete.

This post makes the case for modernising your legacy educational game - and explains what that process actually involves.

The Four Forces Killing Your Legacy Game

1. Flash Is Dead (and It Is Not Coming Back)

Adobe Flash was officially discontinued in December 2020. Every major browser has removed Flash Player support. Chromebooks - the dominant device in schools - never supported it. If your educational game was built in Flash, it is effectively inaccessible to the audience it was designed for.

This is not a theoretical risk. Thousands of educational interactives built between 2000 and 2015 were Flash-based. Many of these were excellent learning tools that represented significant investment. Without modernisation, that investment is lost entirely.

Flash end-of-life is the most urgent trigger, but it is not the only one. Legacy Unity projects (pre-Unity 2018), Java applets, Silverlight applications, and even early HTML games with jQuery dependencies face similar obsolescence timelines as browsers and operating systems drop support for older runtimes.

2. Learners Are Mobile-First

When your educational game was built, the target device was a desktop computer or perhaps a laptop. Today, learners reach for tablets and phones first. In many schools, the primary computing device is a Chromebook or iPad.

A game designed for a 4:3 desktop monitor with mouse-and-keyboard input does not work on a 6-inch touchscreen. The interface elements are too small to tap accurately. The layout wastes screen real estate or, worse, overflows the viewport. Hover states do not exist on touch devices. The entire interaction model needs rethinking.

This is not just a convenience issue - it is an access issue. If your educational game cannot run on the devices learners actually use, it reaches nobody.

3. Accessibility Requirements Have Evolved

WCAG 2.2 was published in 2023 and is rapidly becoming the baseline expectation for publicly funded educational content. Many legacy games were built before WCAG 2.0 was widely adopted, let alone 2.2.

Common accessibility gaps in legacy educational games include:

No keyboard navigation: Games built for mouse-only interaction are unusable for learners with motor disabilities
Poor colour contrast: Aesthetic choices from a decade ago often fail modern contrast ratio requirements (4.5:1 for normal text)
No text alternatives: Images, animations, and audio without alt text or transcripts exclude learners using screen readers
Fixed text sizes: Content that cannot be scaled excludes learners with visual impairments
No captions or subtitles: Audio-dependent content excludes deaf and hard-of-hearing learners

For publicly funded educational content, accessibility is not optional. Institutions face legal obligations under the Equality Act 2010 (UK), ADA (US), and equivalent legislation worldwide. A game that does not meet current standards is a compliance liability.

4. LMS Integration Expectations

Modern educational institutions expect training content to integrate with their Learning Management System. Teachers want to track which students completed which modules, how they scored, and where they struggled.

Legacy games typically have no LMS integration whatsoever. They are standalone experiences that produce no data. In an era when xAPI, SCORM, and Learning Tools Interoperability (LTI) are standard expectations, a game that cannot report learner progress back to the institution's systems is increasingly difficult to justify deploying.

Key Takeaway: Legacy educational games face four simultaneous pressures: runtime obsolescence (Flash/Java/Silverlight), device incompatibility (mobile-first learners), accessibility non-compliance (WCAG 2.2), and integration gaps (no LMS reporting). Any one of these is sufficient reason to modernise. Most legacy games face all four.

The Modernisation Spectrum

Not every legacy game needs the same level of intervention. The scope depends on the game's current state and your institution's requirements.

Level 1: Runtime Migration

The lightest touch. The game logic and design remain largely unchanged, but the underlying technology is replaced. Flash to HTML5/WebGL is the most common migration of this type.

This is appropriate when:

The game design and content are still sound
The target devices and screen sizes have not changed dramatically
Accessibility requirements are minimal or already met
No LMS integration is needed

Level 2: Platform Modernisation

The game logic is preserved, but the interface is redesigned for modern devices and accessibility standards. This typically involves:

Responsive layouts that work on mobile, tablet, and desktop
Touch-friendly interaction redesign
WCAG 2.2 compliance (keyboard navigation, contrast, text scaling, screen reader support)
Modern aspect ratio support (16:9, 19.5:9 instead of legacy 4:3)

Level 3: Full Reconstruction

The game is rebuilt from the ground up on a modern engine (typically Unity or HTML5), preserving the pedagogical design but modernising everything else. This is necessary when:

The original source code is lost
The game design needs significant updates to reflect current curriculum
LMS integration is required
The game needs to support multiple new platforms (iOS, Android, Chromebook, WebGL)

A Real-World Example: The Great Fire of London

To illustrate what modernisation looks like in practice, consider the Great Fire of London interactive game. Originally built in Flash, this educational game was a staple in UK classrooms, teaching children about the historic events of 1666 through interactive scenarios and mini-games.

When browsers dropped Flash support, the game faced extinction. During David's previous agency tenure, the team he worked with was commissioned by the Museum of London to rescue the experience.

The Challenge

The original source code had been lost. This meant a simple recompile or automated conversion was impossible. The team had to treat the original Flash game as a "black box" and reverse-engineer every interaction.

The Approach

The team catalogued every interaction, animation timing, and win-state condition from the original Flash version by playing through it systematically. Using this as a blueprint, they:

Reverse-engineered the game logic frame by frame, documenting every mechanic and state transition
Extracted and optimised original assets - converting Flash vector art into optimised sprite sheets that load quickly on school Wi-Fi networks
Rebuilt the UI for modern screens - the original 4:3 CRT layout was re-engineered for responsive 16:9, with UI elements decoupled from the game world so menus anchor to screen edges on any device
Targeted school hardware - the rebuilt version runs on Chromebooks, iPads, and modern web browsers, covering the vast majority of school computing environments

The Result

The Great Fire of London game continues to be used in classrooms today, running natively in modern browsers without plugins. The pedagogical design that made it effective remains intact. The technology underneath is modern, maintainable, and accessible.

This project demonstrates a critical principle of legacy modernisation: the goal is to preserve what works (the learning design) while replacing what does not (the technology).

Key Takeaway: Even when original source code is lost, legacy educational games can be fully reconstructed through reverse engineering. The Great Fire of London rescue proves that no game is truly "dead" if the content and pedagogy are worth saving.

The Cost of Doing Nothing

Some organisations delay modernisation because it requires budget. But the cost of inaction is not zero - it is hidden.

Lost Educational Value

If your game was effective when it launched, every day it remains inaccessible is a day learners miss out on that educational value. The original development investment generates zero return once the game stops working.

Accumulated Technical Debt

The longer you wait, the harder (and more expensive) modernisation becomes. Flash decompilers become less reliable. Original team members leave. Documentation gets lost. The gap between the original technology and current standards widens.

Compliance Risk

Accessibility non-compliance can create contractual, reputational, and in some contexts legal risk. The applicable requirement depends on the institution, jurisdiction, platform, and how the content is provided, so it should be part of the modernisation audit rather than treated as a cosmetic upgrade.

Institutional Reputation

An educational institution that deploys broken, outdated, or inaccessible digital content sends the wrong message about its commitment to quality and inclusion.

What to Look For in a Modernisation Partner

Not every game development studio is equipped for legacy modernisation. This is specialist work that requires a specific skill set.

Reverse Engineering Capability

If your original source code is lost (and it very often is), the modernisation partner needs experience in decompilation and reconstruction. This is not standard game development work - it requires forensic analysis of compiled binaries, asset extraction from legacy formats, and the ability to recreate game logic from observed behaviour.

Educational Game Experience

A studio that builds commercial games is not necessarily equipped to build educational ones. The modernisation partner should understand:

Curriculum alignment and pedagogical design
Age-appropriate UX for your target demographic
Accessibility standards (WCAG 2.2) and how to implement them in games
LMS integration protocols (xAPI, SCORM, LTI)
Data protection requirements for educational contexts (GDPR-K, COPPA)

Cross-Platform Deployment

Your modernised game needs to reach the devices your learners actually use. The partner should have experience deploying to:

Modern web browsers (HTML5/WebGL)
Chromebooks (the dominant classroom device in many regions)
iPads and Android tablets
Interactive whiteboards and kiosk installations (for museum contexts)

Preservation Mindset

The right partner understands that the goal is not to build a new game - it is to preserve an existing educational asset. The pedagogy, content accuracy, and learning design should be treated as sacred. The technology is what gets replaced.

Planning Your Modernisation Project

If you are considering updating a legacy educational game, here is a practical starting point:

Step 1: Audit the Current State

What technology was the original game built in?
Do you have the original source code and assets?
What devices do your learners currently use?
What accessibility standards do you need to meet?
Does the game need LMS integration?

Step 2: Define the Target State

Which platforms must the modernised game support?
What accessibility standard or conformance target is required by the client or procurement framework?
Do you need analytics or LMS integration?
Does the game content (curriculum, facts, scenarios) need updating alongside the technology?

Step 3: Assess Scope and Budget

The scope varies enormously depending on whether source code is available, how many platforms need supporting, and whether the content itself needs updating. A runtime migration (Flash to HTML5 with minimal changes) is a fraction of the cost of a full reconstruction.

Step 4: Engage a Specialist

Legacy modernisation is not a good fit for general-purpose web agencies. Look for a studio with specific experience in:

Flash-to-HTML5 or Flash-to-Unity conversion
Educational game development
Cross-platform deployment to school hardware
Accessibility compliance

Our Approach

At Ocean View Games, legacy game modernisation is one of our core services. We bring direct experience in Flash-to-HTML5 conversion, cross-platform educational game deployment, and building accessible, LMS-integrated learning experiences.

Our team's experience working on the Great Fire of London modernisation project - reverse-engineering a lost-source Flash game into a fully functional modern HTML5 experience - demonstrated exactly the kind of forensic, preservation-focused approach that legacy educational games require.

Whether your game needs a runtime migration, a full platform modernisation, or a ground-up reconstruction, we start with a feasibility audit that tells you exactly what is possible, what it costs, and how long it takes - before you commit to anything.

Cross-Platform Save Systems: Cloud Sync Done Right

Ocean View Games — Sat, 26 Sep 2026 23:16:19 +0000

Few systems in game development are as universally needed - and as consistently underestimated - as save data management. When your game lives on a single platform and a single device, saving is straightforward. The moment you add a second platform or a second device, you inherit an entirely new class of engineering problems: conflict resolution, offline play, schema evolution, and platform-specific API compliance.

We have built save systems for games across the complexity spectrum. Our work on Domi Online, a persistent MMORPG with a server-authoritative backend, demanded a fundamentally different architecture than a mobile puzzle game. David's time working on RuneScape Mobile at Jagex also reinforced the wider lesson behind this article: long-lived games make persistence and backwards compatibility architectural concerns, not implementation details.

This post is a technical guide for Unity developers building cross-platform cloud save systems. We will cover architecture decisions, platform-specific APIs, conflict resolution strategies, offline-first design, and schema migration for live games.

Why Cloud Save Is Harder Than It Looks

At first glance, cloud save seems simple: serialise the game state, upload it to a server, download it on another device. In practice, every step introduces complexity:

What happens when the player is offline? Mobile players lose connectivity constantly. Your game must remain fully playable.
What happens when two devices have divergent saves? The player progresses on their phone, then opens the game on their tablet before the phone syncs. Which save wins?
What happens when you update the game? The save schema changes, but the player's cloud data is still in the old format.
What happens when the platform API fails? Google Play Games Services, Game Center, and Steam Cloud each have their own failure modes, rate limits, and quirks.

A robust cloud save system must handle all of these cases gracefully, without data loss and without confusing the player.

Architecture: The Three Layers

We recommend structuring your cloud save system as three distinct layers. This separation makes each layer independently testable and replaceable.

Layer 1: The Save Data Model

Your save data should be a plain C# class (or set of classes) with no dependencies on Unity types, MonoBehaviour, or any platform SDK. This makes it serialisable, testable, and portable.

[System.Serializable]
public class PlayerSaveData
{
    public int schemaVersion;
    public long lastModifiedUtc;
    public string deviceId;
    public PlayerProgress progress;
    public InventoryData inventory;
    public SettingsData settings;
}

Key principles:

Include a schema version - you will need this for migration (covered below).
Include a timestamp - lastModifiedUtc is essential for conflict resolution. Use UTC epoch milliseconds to avoid timezone issues.
Include a device identifier - useful for debugging and for conflict resolution UI.
Separate volatile and stable data - settings change rarely; progress changes constantly. Splitting them reduces sync frequency and payload size.

Layer 2: The Local Persistence Layer

This layer handles reading from and writing to the device's local storage. It operates independently of any cloud service and is the foundation of your offline-first design.

Responsibilities:

Serialisation - convert the save model to bytes. We recommend JSON for debug-friendliness during development and binary (MessagePack or a custom binary format) for production. JSON is human-readable but larger; binary is compact but opaque.
Encryption - if your save data contains anything the player could benefit from tampering with (currency, progression, unlocks), encrypt it locally. AES-256 with a device-derived key is a reasonable baseline. For competitive games, this is non-negotiable.
Atomic writes - never write directly to the save file. Write to a temporary file, then rename it. This prevents corruption if the app is killed mid-write. On mobile, this is more common than you might expect.
Backup copies - maintain the previous save as a rollback option. If the current save is corrupted, the player loses one session instead of everything.

Layer 3: The Cloud Sync Layer

This layer manages communication with the cloud backend. It should be completely decoupled from the local persistence layer via an interface, allowing you to swap cloud providers without touching your save logic.

public interface ICloudSaveProvider
{
    Task<CloudSaveResult> UploadAsync(byte[] data, SaveMetadata metadata);
    Task<CloudSaveDownload> DownloadAsync();
    Task<bool> DeleteAsync();
    bool IsAuthenticated { get; }
}

This interface can then have concrete implementations for each platform: GameCenterSaveProvider, GooglePlaySaveProvider, SteamCloudSaveProvider, and a PlayFabSaveProvider or custom backend provider for your own infrastructure.

Platform-Specific APIs

Each platform provides its own cloud save API with distinct characteristics. Here is what you need to know about each.

Platform Comparison

Platform APIs, quotas, and behaviours change over time. Treat this as an architectural comparison and verify the current platform documentation before implementation.

	Apple Game Center	Google Play Games	Steam Cloud
API	`GKSavedGame` (GameKit)	Saved Games API (Play Games SDK v2)	`ISteamRemoteStorage` (Steamworks)
Storage limit	No hard limit, Apple recommends under a few MB	3 MB per save slot (multiple slots)	Configurable per app (typically 100 MB-1 GB)
Conflict handling	Detects conflicts, provides array of conflicting saves. You must resolve explicitly	Conflict callback with local and server versions. You implement resolution	Last-write-wins by default. Use `RemoteStorageFileConflict_t` for custom handling
Quirks	Tied to Apple ID. No Game Center sign-in means no cloud save	Requires Google Play Games sign-in, which some players decline. Need a fallback	File-based, not structured data. Syncs based on configured file paths in Steamworks
Offline	Local saves work independently, sync on reconnect	Caches locally, syncs when connectivity restores	Steam Deck and offline mode use local cache, sync on reconnection

Custom Backend (PlayFab, Firebase, or Self-Hosted)

For cross-platform games that need a single source of truth regardless of storefront, a custom backend is often the right choice:

Backend	Description	Best for
PlayFab	Microsoft's BaaS with Player Data APIs and automatic timestamp-based conflict resolution	Games already using PlayFab for multiplayer or analytics
Firebase / Firestore	Google's offering with strong offline support and automatic sync	Mobile games needing reliable cross-device sync
Self-hosted	Maximum control but maximum maintenance burden	Games with server-authoritative state (like Domi Online, where the server is the canonical source of truth)

Key Takeaway: For single-platform games, use the native platform API. For cross-platform games, use a backend service (PlayFab, Firebase, or custom) as the canonical source and treat platform APIs as optional sync accelerators.

Conflict Resolution Strategies

Save conflicts are inevitable in any cloud sync system. The question is not whether they will happen, but how you handle them when they do.

Strategy 1: Last Write Wins (LWW)

The simplest approach: compare timestamps and keep the newest save.

Pros: Easy to implement, easy to reason about.

Cons: The "newest" save is not always the "best" save. A player who progresses significantly on Device A, then opens Device B briefly (which uploads an older save with a newer timestamp), will lose their progress.

When to use: Casual games where save data is small and progress loss is minor.

Strategy 2: Merge by Field

Compare individual fields and take the "best" value from each version. For example:

highScore: take the maximum
totalCoinsEarned: take the maximum
levelsCompleted: take the union of completed levels
settings: take the most recently modified

Pros: Preserves the most progress. Players rarely notice conflicts.

Cons: More complex to implement. Requires defining merge rules for every field. Some fields cannot be merged meaningfully.

When to use: Mobile games with incremental progress (puzzle games, idle games, educational titles).

Strategy 3: Player Choice

Present the conflict to the player with clear information: "Device A: Level 47, 3 hours ago. Device B: Level 42, 1 hour ago. Which save would you like to keep?"

Pros: The player always gets what they expect. No silent data loss.

Cons: Interrupts the play experience. Confusing for non-technical players. Requires UI work.

When to use: Games where progress is significant and reversible loss would be frustrating (RPGs, strategy games, lengthy campaigns).

Strategy 4: Server-Authoritative (No Conflicts)

The server is the canonical source of truth. The client sends actions (not state), and the server applies them. There is no concept of "conflicting saves" because the server's state is always correct.

Pros: Eliminates conflicts entirely. Prevents cheating.

Cons: Requires a persistent server connection (or an action queue for offline play). Significantly more complex and expensive to build.

When to use: Competitive multiplayer games, games with real-money economies, MMOs. This is the architecture we use for Domi Online, where the server-authoritative backend built with FishNet on AWS is the single source of truth for all player state.

Offline-First Architecture

Mobile players will lose connectivity. Your game must continue to work. This is not an edge case - it is the normal operating condition for mobile games.

An offline-first save system follows these principles:

The local save is always the primary data source at runtime. The game reads from and writes to local storage. Cloud sync happens asynchronously in the background.
Never block gameplay on a network call. If the cloud upload fails, queue it for retry. If the cloud download fails, use the local save. The player should never see a loading spinner waiting for a cloud operation.
Sync on key events, not on a timer. Good sync triggers include:
- App launch (download latest cloud save)
- App backgrounding / suspension (upload current save)
- After significant progress milestones (level completion, boss defeat)
- When network connectivity is restored after a loss
Handle the "cold start" case. When a player installs the game on a new device, the local save does not exist. The game must attempt a cloud download before showing the main menu. This is the one case where a brief loading state is acceptable.
Implement retry with exponential backoff. Cloud APIs fail. Rate limits kick in. Network conditions fluctuate. A retry strategy with exponential backoff (1s, 2s, 4s, 8s, capped at 60s) prevents hammering the server while ensuring eventual consistency.

Schema Migration for Live Games

Your save data format will change. You will add new features, remove deprecated fields, restructure data for performance, or fix bugs in how data was stored. When this happens, players will have cloud saves in the old format that your new code must be able to read.

The Version Field Approach

This is why the schemaVersion field in your save data model is critical. Every time you change the save structure, increment the version and write a migration function.

public static PlayerSaveData Migrate(PlayerSaveData data)
{
    if (data.schemaVersion < 2)
    {
        // v1 -> v2: Added inventory system
        data.inventory ??= new InventoryData();
    }
    if (data.schemaVersion < 3)
    {
        // v2 -> v3: Renamed 'coins' to 'softCurrency'
        data.progress.softCurrency = data.progress.coins;
    }
    data.schemaVersion = CURRENT_VERSION;
    return data;
}

Migration Rules

Migrations must be forward-only. Never delete a migration function. A player who has not opened your game since version 1 must be able to migrate through v1 -> v2 -> v3 -> ... -> current in a single chain.
Migrations must be idempotent. Running the same migration twice on the same data must produce the same result.
Test migrations with real data. Capture save files from each version and include them in your test suite. Automated migration tests catch regressions that manual testing will miss.
Handle missing fields with defaults. When deserialising an old save, new fields will be null or zero. Your migration code must provide sensible defaults.
Consider backward compatibility. If your game allows older clients to connect (common in soft-launch), the server must handle both old and new save formats simultaneously.

Key Takeaway: Ship a schema version field from day one, even if you do not plan to change the format. Adding it retroactively to saves that do not have it is the single most painful migration you will ever write.

Security Considerations

Save data security depends on your game's context:

Single-player casual games - basic encryption prevents casual tampering but is not worth significant investment. Players who hack their own save data in a non-competitive game are not causing harm.
Competitive games with leaderboards - encrypt local saves, validate on upload, and consider server-side verification of key metrics (scores, completion times).
Games with real-money economies - server-authoritative state is mandatory. Local save data should be treated as a cache, not a source of truth. This is the approach we took with Domi Online, where the high-stakes economy demanded that all player state be validated server-side.

Common Attack Vectors

Local save file editing - players modify JSON or binary saves on rooted/jailbroken devices. Encryption and checksum validation mitigate this.
Time manipulation - players change their device clock to exploit timestamp-based logic (cooldowns, daily rewards). Use server time for anything with economic impact.
Replay attacks - players restore a backup save after spending premium currency to "refund" the purchase. Server-side receipt validation and sequential save versioning prevent this.

Implementation Checklist

Before shipping your cloud save system, verify that it handles these scenarios:

[ ] Player has no internet connection at launch
[ ] Cloud download fails mid-transfer
[ ] Cloud upload fails mid-transfer
[ ] Player opens game on two devices simultaneously
[ ] Player's device clock is set incorrectly
[ ] Player updates the app and the save schema has changed
[ ] Player uninstalls and reinstalls the app
[ ] Player declines platform sign-in (Game Center, Google Play Games)
[ ] Cloud storage quota is exceeded
[ ] Player's cloud save is corrupted or empty
[ ] Player switches platform accounts

Each of these is a real scenario we have encountered in production games. Testing them before launch is significantly cheaper than debugging them after.

Choosing the Right Approach for Your Game

The architecture you need depends on your game's characteristics:

Game Type	Recommended Approach
Single-player mobile (casual)	Local save + platform API (Game Center / Google Play) with LWW
Single-player mobile (mid-core)	Local save + platform API with merge-by-field
Cross-platform single-player	Local save + backend service (PlayFab/Firebase) with player choice on conflict
Cooperative multiplayer	Backend service with server-authoritative state for shared data, local for settings
Competitive multiplayer / MMO	Fully server-authoritative, local cache for offline resilience

Start with the simplest approach that meets your requirements. You can always upgrade from LWW to merge-by-field, or from platform APIs to a custom backend, if your game's needs evolve.

The True Cost of Game Development Outsourcing

Ocean View Games — Fri, 04 Sep 2026 12:03:32 +0000

When studios compare outsourcing options, the conversation almost always starts - and too often ends - with hourly or daily rates. A provider quoting half the rate looks half the price. In practice, rate is only one variable in the cost of getting reliable, production-ready work into your game.

Except the maths is wrong. Or rather, it is incomplete.

The hourly rate is the sticker price, not the total cost of ownership. The real cost of outsourcing includes communication overhead, ramp-up time, quality variance, IP risk, timezone friction, management burden, and the cost of getting it wrong. These hidden costs can erase much of the apparent saving from a lower rate - or make a more expensive partner cheaper once delivery risk and internal time are included.

We write this from a particular vantage point. Ocean View Games is a UK-based co-development partner. We have sat on both sides of the outsourcing relationship - as the team being outsourced to, and as developers who have worked alongside outsourced teams on large studio projects. We have seen what works, what does not, and what the actual cost drivers are.

The Visible Costs

Let us start with the costs that do appear on invoices. These are the numbers procurement teams compare.

Hourly or Daily Rates

The direct cost of developer time is the easiest number to compare, but quoted rates are shaped by more than geography. Seniority, specialism, contract length, whether project management is included, and how much responsibility the partner is taking all affect the number.

When comparing providers, normalise the quote before drawing conclusions:

Question	Why It Matters
Who will actually work on the project?	A senior-led team and a junior-heavy team are not equivalent purchases
What is included in the rate?	Production, QA, technical leadership, meetings, and support may be inside or outside the quote
How much working-day overlap is there?	Real-time collaboration changes iteration speed
Is the scope deliverable-based or time-based?	A fixed deliverable transfers different risk than staff augmentation
What happens after delivery?	Documentation, handover, warranty fixes, and ongoing support affect total cost

The useful comparison is not "who has the lowest hourly rate?" It is "what will it cost us to get this scope integrated, accepted, and maintainable?"

Project Management and Coordination

Most outsourcing providers include a project manager in their rates, but this person manages the outsourced team's internal workflow - not the integration with your team. You will still need someone on your side to manage the relationship, review deliverables, and translate requirements. Budget explicit internal time for coordination rather than assuming the provider's project manager removes the need for client-side ownership.

Tooling and Infrastructure

If the outsourced team needs access to your version control, project management tools, CI/CD pipeline, and communication platforms, there may be additional licence costs. Some providers use their own tools, which creates a handover problem later.

The Hidden Costs

This is where the real total cost emerges. These costs do not appear on any invoice, but they are real and measurable.

1. Communication Overhead

Communication is the single largest hidden cost in outsourcing, and it scales non-linearly with team size and cultural distance.

Shared language and context - even when everybody communicates well, phrases like "the inventory should feel snappy" are ambiguous. External teams usually need more explicit acceptance criteria because they have less product context. Writing and maintaining that context takes time.

Communication norms - teams differ in how quickly they challenge requirements, surface uncertainty, and escalate blockers. The important factor is not nationality; it is whether the working relationship makes uncertainty visible early.

Asynchronous communication cycles - large timezone gaps can turn a quick clarification into a next-day response. That is manageable for self-contained work, but expensive when a feature needs rapid iteration with designers and engineers.

Practical impact: Track coordination time during the first few weeks. If senior people on your side are spending several hours a week rewriting briefs, chasing clarifications, or reviewing avoidable rework, include that time in the effective cost of the engagement.

2. Ramp-Up Time

Every new developer, whether in-house or outsourced, needs time to understand your codebase, tools, conventions, and domain. The question is how long this ramp-up takes and who pays for it.

Ramp-up is driven much more by relevance than postcode. A team that already knows your engine version, platform constraints, backend pattern, and type of codebase can start making useful changes sooner. A team learning all of those things at once will need more review and context before it can work independently.

That difference is worth modelling explicitly. Ask every provider what the first two weeks look like, which people will be onboarding, what they need from your team, and when you should expect the first production contribution.

When we join a project as a co-development partner, we aim to make the first useful contribution quickly. Relevant experience on large Unity codebases, including David's previous work on RuneScape Mobile at Jagex and our work on Domi Online, reduces the amount of domain learning required before we can help.

3. Quality Variance and Rework

The most expensive code is code that has to be written twice.

Quality variance is the gap between what you expected and what you received. It manifests in several ways:

Code that works but is not production-ready - no comments, no tests, no adherence to your coding standards. It functions but creates technical debt that your in-house team must clean up.
Code that does not integrate - the outsourced team built a module in isolation that does not mesh with your architecture. Integration work falls on you.
Misunderstood requirements - the feature was built to specification, but the specification was interpreted differently. Rework ensues.
Missing edge cases - the happy path works; error handling, null checks, and boundary conditions do not. These bugs surface in QA or, worse, in production.

Practical impact: Measure rework as part of the engagement. Track how often delivered work is rejected, substantially rewritten, or needs unexpected integration work. A low rate is not valuable if the same feature is effectively paid for twice.

Key Takeaway: A lower rate is not automatically a lower cost. Calculate the effective cost of usable, production-ready output, including the time your own team spends getting it there.

4. Timezone Friction

Timezone differences affect more than communication speed. They affect your ability to:

Iterate quickly - game development is iterative. "Try this, see how it feels, adjust" is the core workflow. When each iteration cycle takes 24 hours instead of 30 minutes, the feedback loop breaks.
Respond to emergencies - your live game is down, and the team that wrote the server code is asleep. How long can you wait?
Participate in standups and reviews - if overlap is minimal, either your team or theirs is attending meetings outside working hours. This is unsustainable.
Maintain team cohesion - when people never interact in real-time, they do not form working relationships. The outsourced team becomes "them," not "us."

The overlap question: There is no magic number of shared hours. The right amount depends on the work. A self-contained asset task may need very little overlap; embedded engineering, debugging, and design iteration benefit from a reliable daily window where the relevant people can talk in real time. Define that window before the engagement starts.

5. Intellectual Property Risk

When you outsource game development, you are sharing your source code, design documents, art assets, and business strategy with an external party. This creates IP risk that must be managed through legal, technical, and procedural controls.

Legal protections:

Non-Disclosure Agreements (NDAs) - essential, but enforceability varies by jurisdiction. An NDA governed by UK law is straightforward to enforce in the UK. Enforcing it in a jurisdiction with different IP protections is more complex and expensive.
Work-for-hire agreements - ensure that all code, assets, and documentation produced are owned by you, not the outsourcing provider. This is standard but must be explicit.
IP assignment clauses - separate from work-for-hire, these ensure any background IP contributed by the provider is licensed to you appropriately.

Technical protections:

Compartmentalised access - the outsourced team should only access the repositories and systems they need. Not your entire codebase.
Code review gates - all contributions must pass review by your in-house team before merging.
Secure development environments - VPN access, no local code storage, audit logging.

Practical risk assessment: For most professional outsourcing relationships, IP theft is rare. The greater risk is IP leakage through poor security practices (unencrypted laptops, shared credentials) rather than malicious intent. Proper onboarding and security protocols mitigate this effectively.

6. Management Burden

Managing an outsourced team takes more of your time than managing an equivalent in-house team. This is your time - the most expensive time in the project.

Responsibilities that fall on you:

Writing more detailed specifications (because you cannot explain context verbally)
Reviewing code and deliverables more carefully (because the team is less familiar with your standards)
Mediating between in-house and outsourced teams (integration points, merge conflicts, architectural decisions)
Handling administrative overhead (invoicing, contracts, access management)

Practical impact: Put a value on the client-side management burden. If your technical lead spends a day each week coordinating external work, that day belongs in the cost model just as surely as an invoice does.

Comparing the Models: Offshore vs Nearshore vs UK-Based

Offshore (Large Timezone Gap)

Often a good fit for: Well-defined, self-contained work with clear acceptance criteria and a workflow designed for asynchronous delivery.

Watch for: Slow feedback loops on work that depends on frequent design or engineering decisions.

Nearshore (Meaningful Working-Day Overlap)

Often a good fit for: Ongoing support where real-time collaboration matters but the client is comfortable working across jurisdictions and organisations.

Watch for: Assuming proximity guarantees process fit. Team seniority, communication, and ownership still matter more than the label.

Local / Same-Timezone Partner

Often a good fit for: Embedded engineering, architectural decisions, workshops, rapid iteration, and work where the external team must behave like part of the internal team.

Watch for: Paying a premium for proximity when the work is actually self-contained and does not benefit from it.

Key Takeaway: Geography is a constraint, not a quality score. Compare the collaboration model to the work you need done, then compare total cost rather than assuming one region is inherently better than another.

What to Look for in an Outsourcing Partner

Regardless of geography, the factors that predict outsourcing success are:

1. Relevant Portfolio

Have they built games like yours? Not just "Unity games" - your platform, type of codebase, and technical constraints. When we partnered with Domi Online, experience with large live-game systems and David's previous work on RuneScape Mobile at Jagex meant we were familiar with many of the architectural problems from the start.

2. Communication Quality

Test this before signing. How quickly do they respond to your initial enquiry? How clearly do they explain their process? Do they ask good questions about your project, or do they just quote a rate? The pre-sales interaction is a reliable predictor of the working relationship.

3. Process Maturity

Do they use version control? Do they have a code review process? Do they write tests? Do they use project management tools? These are not "nice to haves" - they are the minimum requirements for professional software development. Be wary of any provider that cannot clearly articulate their development process.

4. References from Similar Projects

Ask for references and actually call them. Ask specifically about:

Ramp-up time
Communication quality
Code quality on delivery
How they handled disagreements or scope changes
Whether the reference would hire them again

5. Team Stability

Will the same developers work on your project throughout, or will they be rotated to other clients? Developer rotation resets the ramp-up clock every time. Contractually binding named developers to your project is worth negotiating.

6. Clear IP Agreements

The contract should explicitly state:

You own all code, assets, and documentation produced
The provider will not reuse your code on other projects
Background IP (frameworks, tools) is licensed to you
Source code is delivered incrementally, not only at project end

Making the Decision

Here is a practical framework for choosing your outsourcing model:

If your priority is...	Consider...
Lowest possible cost for well-defined tasks	Offshore with detailed specifications
Balance of cost and collaboration	Nearshore with daily overlap
Maximum integration and minimum friction	UK-based co-development partner
Surge capacity for a specific phase	Short-term co-development engagement
Long-term ongoing support	Retained co-development relationship

The worst outcome is not choosing the "wrong" label - it is choosing a model without accounting for the hidden costs. A higher-priced engagement can be cheaper overall if it reduces internal rework and protects the delivery schedule.

How We Approach Co-Development

At Ocean View Games, our co-development model is designed to minimise the hidden costs described above:

Embedded integration - we join your Slack, attend your standups, commit to your repo. We operate as an extension of your team, not a separate entity.
UK-based, UK timezone - we have a full working-day overlap with UK clients, which makes real-time pairing, debugging, and iteration straightforward.
Senior developers only - our experience spans David's previous RuneScape Mobile work at Jagex and our Domi Online work, alongside mobile, educational, and legacy projects.
Clean handoff - all code is documented, commented, and follows your style guide. When the engagement ends, your team picks up without confusion. No lock-in.
UK legal jurisdiction - our contracts use English law, which can simplify procurement for UK clients.

We are not the cheapest option on a rate card. We are, for many studios, the most cost-effective option when total cost of ownership is considered.

Calculating Your True Cost

Before engaging any outsourcing partner, build a total cost model:

Direct cost - hourly rate x estimated hours
Ramp-up cost - weeks to productivity x weekly rate (producing minimal output)
Communication overhead - your team's time spent on specifications, reviews, meetings, and coordination
Rework budget - the cost of rejected work, integration fixes, and substantial rewrites; estimate this from the provider's references or a paid trial rather than a generic percentage
Management burden - your lead's time redirected to coordination (value this at their effective rate)
Risk premium - the cost of delay if things go wrong (missed market window, delayed revenue)

Add these together. Compare the totals, not the hourly rates. The answer may surprise you.

Use our game development cost estimator to build a baseline budget, then layer these outsourcing-specific costs on top.

Porting a 20-Year-Old Game to Mobile: Lessons from RuneScape

Ocean View Games — Mon, 24 Aug 2026 11:16:46 +0000

RuneScape is one of the longest-running MMORPGs in history. First released in 2001, it had already accumulated more than 15 years of content, systems, interfaces, and player expectations when I joined the mobile effort. Bringing a game with that history to iOS and Android is a very different problem from porting a title designed with mobile in mind.

I worked at Jagex from 2017 to 2019 as a Technical Developer on the RuneScape Mobile team. That put me inside the practical work of adapting a long-lived desktop game for touch devices and much more constrained hardware.

This article shares the technical lessons I took from that experience and how they now inform the mobile development and porting work we do.

Important note on attribution: The RuneScape work discussed here was performed during my previous employment at Jagex Games Studio. RuneScape is a trademark of Jagex Ltd. Ocean View Games was not a contractor or agency partner on the project. I reference the experience because the lessons directly inform how we approach mobile and legacy codebases today.

The Scale of the Challenge

To understand why porting RuneScape to mobile was so technically demanding, you need to appreciate what the game actually contains:

Over 20 years of accumulated content built by hundreds of developers across multiple generations of the codebase
A large set of skills and activities, many with their own interfaces and interaction patterns
Years of quests and bespoke content built across multiple generations of the game
A live, persistent world shared between mobile and desktop players
A player-driven economy that had to behave consistently across platforms
An established community with strong expectations about how the game should look and feel

This was not a case of building a simplified "mobile version" of the game. The mandate was full cross-platform parity: a mobile player needed to be able to do everything a desktop player could, in the same world, at the same time.

Key Takeaway: When porting a legacy title to mobile, the first and most important question is scope. "Full parity" and "mobile companion app" are fundamentally different projects with different technical requirements, timelines, and budgets. Define this boundary clearly before writing a single line of code.

Lesson 1: Legacy Code Is the Real Boss Fight

Understanding the Codebase

RuneScape's codebase had been evolving for over 15 years by the time the mobile port began. It contained code written by developers who had long since left the company, using patterns and conventions that predated modern best practices. The game's scripting language, RuneScript, was a proprietary system unique to Jagex.

The practical challenge was not just "make this run on mobile." It was "make this run on mobile without destabilising the desktop experience for an established live-game community."

The Lesson: Audit Before You Architect

Before our team wrote any mobile-specific code, we conducted a thorough audit of the systems we would need to touch. This revealed:

Hard-coded screen dimensions embedded deep in UI rendering logic
Mouse-specific input assumptions baked into core gameplay mechanics (right-click context menus were fundamental to the game's interaction model)
Desktop-specific rendering paths that assumed minimum hardware specifications far above any mobile device
Memory usage patterns that were acceptable on desktop (2GB+ RAM available) but catastrophic on mobile (often limited to 1-2GB total, shared with the OS)

The audit took weeks, but it saved months. Every assumption we identified and documented upfront was a crisis we avoided during production.

Applying This at Ocean View Games

This experience directly informed how we approach every porting project today. When we partnered with Inferna Games to remake Nub (originally a Java app for the Ouya console) in Unity for iOS, Android, and Steam, we started with the same audit-first methodology. Even with a much smaller codebase, the discipline of cataloguing every platform assumption before writing new code prevented the kind of cascading bugs that derail porting timelines.

Lesson 2: Touch UI Is Not "Smaller Desktop UI"

The Fundamental Problem

RuneScape's desktop interface was designed for a mouse and keyboard. The game relied heavily on:

Right-click context menus for virtually every interaction (talk to NPC, pick up item, examine, attack)
Hover states to preview information before clicking
Small, dense UI panels that displayed enormous amounts of information simultaneously (inventory, equipment, prayer, magic, combat stats - all visible at once)
Keyboard shortcuts for quick switching between interface panels

None of these patterns translate directly to touchscreens. A finger is far less precise than a mouse cursor, touch has no hover state, right-click needs an alternative, and a phone cannot comfortably display the same information density as a desktop monitor.

The Solution: Context-Sensitive Adaptive UI

The important design direction was to avoid simply scaling down the desktop interface. A mobile UI needs to adapt the information and interactions to the player's current context. The core principles are:

Show only what matters now. When a player is in combat, surface combat-relevant panels (health, prayer, special attack) and collapse non-essential ones (skills, quest log). When the player is skilling, swap the priority.
Give desktop-only interactions a touch-native equivalent. Right-click and hover behaviours need deliberate replacements such as long-press, tap-and-hold, contextual actions, or dedicated controls.
Expand tap targets aggressively. Visual elements that are easy to click with a cursor often need larger or more forgiving hit areas on touch devices.
Redesign, do not just resize. Any interaction built around precision mouse input should be reviewed as a mobile design problem. Preserve the intent of the mechanic, but be willing to change how the player expresses it.

The Lesson: Invest in a Dedicated Mobile UI Pass

A common mistake in porting projects is treating mobile UI as a configuration change - swap out some assets, scale some panels, ship it. This produces games that technically run on mobile but feel terrible to play.

My recommendation, based on that RuneScape experience: budget for a full UI redesign as a first-class work item. This does not mean changing the visual style. It means rethinking how every interaction maps to touch input and how information is prioritised for a smaller viewport.

Key Takeaway: The gap between "works on mobile" and "feels native on mobile" is almost entirely a UI/UX problem. Invest in dedicated mobile interaction design. Your players will notice the difference immediately.

Lesson 3: Cross-Platform Parity Requires Server-Side Discipline

The Synchronisation Problem

RuneScape Mobile was not a separate game. Mobile and desktop players existed in the same world on the same servers. This meant:

A mobile player and a desktop player could trade items face-to-face
A mobile player could participate in the same boss fight as desktop players
The game's economy, driven by the Grand Exchange marketplace, operated identically regardless of platform
Any content update had to work on both platforms simultaneously

Network Packet Optimisation

Desktop RuneScape could assume a stable broadband connection. Mobile could not. The mobile effort had to account for cellular connections as well as desktop broadband. That reinforced an important porting lesson: bandwidth, latency, reconnect behaviour, and failure recovery all need to be treated as mobile design constraints rather than tested at the end.

For a mobile port, that means reviewing the network path with mobile conditions in mind: payload size, reconnect behaviour, timeout assumptions, latency tolerance, and which state is truly critical. The exact implementation depends on the game's architecture, but those questions should be answered deliberately rather than inherited from the desktop client.

The Lesson: Define "Parity" Precisely

"Cross-platform parity" can mean different things:

Data parity: The same account, progression, and items across platforms (essential)
Feature parity: The same gameplay features available on all platforms (desirable but expensive)
Experience parity: The game feels equally good to play on all platforms (the highest bar, and the most important for player retention)

We now apply this three-tier framework to every porting project we scope. For our ongoing work on Domi Online, we designed the network architecture with cross-platform play in mind from the start, using FishNet to build lightweight server-authoritative backends that optimise bandwidth for mobile clients without compromising the desktop experience.

Lesson 4: Optimise for the Worst Device, Not the Best

The Android Fragmentation Reality

When targeting Android, you are not targeting one device. You are targeting thousands. During the RuneScape Mobile development, we had to ensure the game ran acceptably on:

Flagship devices (Samsung Galaxy S series, Google Pixel) with powerful GPUs and 6-8GB of RAM
Mid-range devices that represented the bulk of the player base
Budget devices with as little as 2GB of RAM and GPUs that struggled with basic shader operations

Tiered Quality Settings

A practical response is a tiered quality strategy so that the game can trade visual cost for stability on weaker devices. Typical controls include:

Draw distance and object density
Texture resolution and compression format
Shadow quality (or complete shadow disabling on the lowest tier)
Particle effect density
Frame-rate targets or caps appropriate to the device and thermal budget

Whatever the detection strategy, the default should be conservative enough that supported devices start in a playable state rather than making the player diagnose performance themselves.

Battery and Thermal Management

Mobile games face constraints that desktop games never consider:

Thermal throttling: When a phone overheats, the OS forcibly reduces CPU/GPU clock speeds, causing frame rate drops and stuttering
Battery drain: Heavy CPU/GPU use can make a technically smooth game unpleasant to play for long sessions
Background interruptions: Phone calls, notifications, and OS memory pressure can suspend or kill the game process at any time

The practical lesson is to test sustained sessions, not just a five-minute benchmark. A build that starts at 60fps can perform very differently after the device heats up. Profile frame time, loading spikes, memory pressure, and thermal behaviour on real hardware.

Lesson 5: Your Existing Players Are Your Toughest Critics

Managing Community Expectations

RuneScape's player community had been playing the game for years, sometimes decades. They had strong opinions about every UI element, every interaction pattern, and every visual detail. Any change made for mobile that visibly affected the desktop experience generated immediate and vocal feedback.

The Lesson: Isolate Mobile Changes

Wherever possible, mobile-specific behaviour should sit behind platform abstraction layers rather than leaking platform checks throughout shared gameplay code. For example:

Input handling was routed through an abstraction that returned platform-appropriate interactions
UI layouts used a responsive system that adapted to screen size without changing the underlying data model
Performance optimisations that benefited both platforms (reduced draw calls, better batching) were implemented in shared code; mobile-only compromises (reduced texture quality) were isolated behind platform checks

That extra structure costs some time up front, but it reduces the risk that a mobile-specific compromise accidentally degrades the desktop experience.

How These Lessons Inform Our Work Today

Every project we take on at Ocean View Games is shaped by this experience. Whether we are building a new title from scratch or porting an existing game to mobile, we apply the same principles:

Audit first. Catalogue every platform assumption in the existing codebase before writing new code.
Design for touch natively. Never treat mobile UI as a scaled-down version of the desktop interface.
Define parity levels explicitly. Agree with the client on exactly what "cross-platform" means before scoping the work.
Optimise for the floor, not the ceiling. Target the weakest supported device first. If it runs well there, it will run well everywhere.
Isolate platform-specific code. Use abstraction layers to prevent mobile changes from breaking the existing experience.

If you are considering a mobile port of an existing title, our mobile game porting case study provides a detailed technical breakdown of this approach. For new projects where you want to target mobile from Day 1, our mobile game development services page outlines how we architect for cross-platform from the start.

SCORM vs Custom API: Integrating Games with Learning Management Systems

Ocean View Games — Mon, 17 Aug 2026 13:43:48 +0000

When an educational institution commissions a game, one of the first questions on the requirements document is: "Will it integrate with our LMS?" The answer is almost always "yes." The follow-up question - how - is where the real engineering decisions begin.

Our educational work ranges from The Language Conservancy (Vocab Builder) to projects delivered during previous agency tenures for institutions including Cambridge University Press, the BBC, and European university consortia through the EU Horizon 2020 programme (Navigo). Institutional projects repeatedly raise the same integration questions: where the game runs, how identity is passed in, what progress must be reported, and which system owns the learning record.

This post compares the two primary approaches to LMS integration - SCORM (the established standard) and custom APIs (the flexible alternative) - and provides practical guidance on when each approach makes sense.

What Problem Are We Solving?

Before comparing solutions, it is worth being precise about what LMS integration actually needs to accomplish:

Launch - the LMS needs to open the game in the right context (correct student, correct assignment, correct lesson).
Track progress - the LMS needs to know how far the student has progressed through the content.
Report scores - test results, quiz scores, and performance metrics need to flow from the game back to the LMS gradebook.
Record completion - the LMS needs to know when the student has finished the activity so it can unlock the next one or mark the assignment as done.
Resume - if the student stops mid-session, the game should pick up where they left off when they return.

These five requirements are common to virtually every educational game integration. The question is which technology best delivers them for your specific context.

SCORM: The Established Standard

SCORM (Sharable Content Object Reference Model) is the most widely adopted e-learning standard. Maintained by ADL (Advanced Distributed Learning), it defines how learning content communicates with an LMS.

SCORM 1.2

Released in 2001, SCORM 1.2 is still widely encountered in established e-learning environments. Major LMS products commonly support it, although the exact launch, reporting, and packaging behaviour varies by platform and configuration.

How it works: The LMS launches your game in an iframe. Your game communicates with the LMS via a JavaScript API (API object on the window). You set and get data model elements using standardised keys.

Key data model elements in SCORM 1.2:

Element	Purpose	Example Value
`cmi.core.lesson_status`	Completion state	`completed`, `incomplete`, `passed`, `failed`
`cmi.core.score.raw`	Numeric score	`85`
`cmi.core.score.min`	Minimum possible score	`0`
`cmi.core.score.max`	Maximum possible score	`100`
`cmi.core.lesson_location`	Bookmark / resume point	`level-3-question-7`
`cmi.suspend_data`	Free-form string for game state	JSON string (4096 char limit)
`cmi.core.session_time`	Time spent in session	`00:15:32`

Strengths of SCORM 1.2:

Broad LMS support - SCORM 1.2 remains a common compatibility target across established LMS products
Simple to implement - the API surface is small. A basic integration can be built in a few days.
Proven and stable - the standard has not changed in over two decades. It will not break.
No backend required - communication happens entirely client-side between the game and the LMS

Limitations of SCORM 1.2:

4096-character limit on suspend_data - this is the biggest practical constraint for games. A complex game with significant state (inventory, progress across multiple mini-games, per-question analytics) will quickly exceed this limit.
Single score model - SCORM 1.2 supports one score per content object. If your game has multiple assessments, you must either aggregate them or package each assessment as a separate SCO (Sharable Content Object).
No detailed interaction tracking - there is no standard way to report individual question responses, time per question, or attempt history.
iframe dependency - the game must run inside the LMS iframe. This introduces CSP (Content Security Policy) constraints, cross-origin issues, and limits your ability to use fullscreen or certain browser APIs.

SCORM 2004 (Editions 1-4)

SCORM 2004 addresses many of SCORM 1.2's limitations with a richer data model and a sequencing engine.

Key improvements over 1.2:

cmi.interactions - a structured array for recording individual question-level data: question type, correct response, learner response, latency, and result. This is invaluable for educational games with assessment components.
Larger suspend_data - the 4096-character limit is increased to 64,000 characters in most SCORM 2004 implementations.
Multiple objectives - track progress against multiple learning objectives within a single content object, each with its own score and completion status.
Sequencing and navigation - define prerequisite relationships between content objects. The LMS can enforce that Level 1 must be completed before Level 2 unlocks.

Limitations of SCORM 2004:

Less universal LMS support - while major platforms support it, some older or specialised LMS installations only support SCORM 1.2.
More complex to implement - the sequencing engine is powerful but adds implementation complexity.
Still iframe-dependent - the same hosting constraints apply.
Overkill for simple games - if you only need a completion flag and a score, SCORM 2004's additional capabilities add complexity without proportional value.

Key Takeaway: If the target LMS is already known, test against that platform first rather than choosing a standard in the abstract. SCORM 1.2 is a strong compatibility option for simple completion/score reporting; richer tracking may justify SCORM 2004, xAPI, or a custom integration.

xAPI (Tin Can API): The Modern Alternative

Before discussing custom APIs, it is worth mentioning xAPI (also known as Tin Can API), which sits between SCORM and a fully custom approach.

xAPI uses a "statement" model: Actor + Verb + Object. For example: "Student 42 completed Level 3 with score 92%." These statements are sent to a Learning Record Store (LRS) via HTTP.

Strengths:

Rich, flexible statement model without SCORM's small suspend-data constraint
Works outside the browser (mobile apps, VR, offline with deferred sync)
Excellent for analytics and learning data research

Limitations:

Requires an LRS (not all LMS platforms include one natively; Moodle requires a plugin)
More complex client-side implementation than SCORM
Less institutional familiarity - IT teams at schools and universities are often less comfortable with xAPI than SCORM

xAPI is a strong choice when you need detailed learning analytics and your client's infrastructure supports it. In our experience, many institutional briefs still ask for SCORM because it is familiar to procurement and L&D teams, even when a richer integration would be technically possible.

Custom API: The Flexible Alternative

A custom API approach means building your own backend service that sits between the game and the LMS. The game communicates with your API via standard HTTP REST calls, and your API translates the data into whatever format the LMS expects.

Architecture Overview

[Game Client] <--REST/WebSocket--> [Your Backend API]
                                          |
                                   [Your Database]
                                          |
                              [LMS Integration Layer]
                                    /     |     \
                              [Moodle] [Canvas] [Blackboard]

What Your Backend Handles

Authentication - the LMS passes a token or session identifier when launching the game. Your backend validates it and associates the session with the correct student and assignment.
Data storage - all game telemetry (progress, scores, interaction logs, time-on-task, attempts) is stored in your database. No character limits. No schema constraints.
Score and completion reporting - your backend pushes aggregated results back to the LMS gradebook via the LMS's API (Moodle Web Services API, Canvas REST API, Blackboard REST API).
Analytics dashboard - because you own the data, you can build teacher-facing dashboards that provide richer insights than the LMS's built-in reporting. When we worked on educational projects, the ability to show educators which specific concepts students were struggling with - not just a percentage score - was consistently cited as the most valuable feature.
Resume and state management - game state is stored server-side with no size constraints. The game can resume exactly where the student left off, regardless of device or browser.

Strengths of a Custom API

No data limits - store as much telemetry as you need. Per-question timing, hint usage, retry counts, learning path analytics.
Platform independence - the game communicates with your API, not the LMS directly. Adding support for a new LMS means adding a new integration adapter, not rewriting the game.
Native mobile support - Unity games deployed as native iOS/Android apps cannot use SCORM (which requires a browser runtime). A custom API works identically for web, mobile, and desktop builds.
Richer analytics - build teacher dashboards, export data for research, generate per-student reports that go far beyond a single score.
Real-time data - WebSocket connections allow the teacher to see student progress in real-time during a classroom session.

Limitations of a Custom API

You build and maintain the backend - this is additional engineering cost, infrastructure cost, and ongoing maintenance. SCORM is essentially "free" at the integration layer because the LMS provides the backend.
Per-LMS integration work - every LMS has a different API. Moodle's Web Services API is different from Canvas's REST API. Each integration must be built and maintained separately.
Procurement friction - educational institutions have established procurement processes for SCORM content. A custom integration requires IT involvement, security reviews, and potentially custom hosting arrangements.
Data privacy compliance - you are now a data processor handling student data. GDPR (and GDPR-K for children), COPPA (US), and FERPA (US education) all apply. Your backend must be compliant.

Decision Framework: Which Approach Should You Use?

The choice between SCORM and a custom API depends on answering four questions:

1. What platforms will the game run on?

If the game runs only in a web browser and is launched from the LMS, SCORM is the path of least resistance. If the game runs as a native mobile app (iOS/Android) or a desktop application, you need a custom API because SCORM's JavaScript API is browser-only.

2. How complex is the data you need to track?

Data Complexity	Recommended Approach
Completion flag + single score	SCORM 1.2
Completion + score + 5-10 interaction records	SCORM 2004
Detailed per-question analytics, time-on-task, learning paths	Custom API or xAPI
Real-time teacher dashboard, adaptive difficulty	Custom API

3. How many LMS platforms must you support?

If your client uses a single, known LMS, a custom integration is manageable. If your product must work with any LMS the customer happens to use, SCORM's universality is a significant advantage.

4. What is your maintenance budget?

SCORM is a fire-and-forget standard. Once your SCORM wrapper works, it works everywhere, indefinitely. A custom API requires hosting, monitoring, security updates, and per-LMS compatibility maintenance. This is an ongoing cost.

Key Takeaway: Use SCORM when universality and low maintenance are priorities. Use a custom API when data richness, mobile deployment, or real-time analytics are requirements. In many projects, the best answer is both - SCORM for basic LMS compliance, plus a custom backend for analytics.

Integration Approach Comparison

Here is how the three main LMS integration approaches compare across the factors that matter most:

Factor	SCORM	xAPI	Custom API
LMS compatibility	✅ Universal (1.2 supported everywhere)	⚠️ Requires LRS (not always native)	❌ Per-LMS integration required
Granular tracking	❌ Limited (single score, 4K suspend_data)	✅ Rich statement model, no limits	✅ Unlimited, schema-free
Offline support	❌ Browser-only, no offline	✅ Deferred sync supported	✅ Local queuing with batch upload
Implementation effort	🟢 Low (days for basic integration)	⚠️ Medium (LRS setup + statements)	🔴 High (backend + per-LMS adapters)
Standards compliance	✅ Widely recognised for procurement	✅ IEEE standard (9274.1.1)	❌ No standard, custom documentation
Real-time data	❌ No live data flow	⚠️ Near-real-time via LRS	✅ WebSocket for live dashboards

The Hybrid Approach

In practice, we often recommend a hybrid architecture that provides the best of both worlds:

Package the game as a SCORM object for LMS compatibility (completion, basic score, resume via suspend_data).
Simultaneously send detailed telemetry to your own backend for analytics, teacher dashboards, and research data.

The SCORM layer ensures the game "just works" in any LMS. The custom backend provides the rich data that SCORM cannot capture. The game client simply fires data to both endpoints.

This hybrid pattern is often worth considering in educational game development: use the LMS-facing standard for launch, completion, and core reporting, while a separate backend captures the richer telemetry needed for dashboards or research. Whether that is appropriate depends on the client's data-governance and procurement requirements.

Implementation Tips for Unity Developers

SCORM from a Unity WebGL Build

Unity WebGL builds run inside a canvas element, which the LMS wraps in an iframe. To communicate with the SCORM API:

Create a JavaScript plugin (.jslib file) that accesses the SCORM API on the parent window.
Call the JavaScript functions from C# using Unity's [DllImport("__Internal")] interop.
Wrap the SCORM calls in a C# class that implements a common interface (so you can swap to a custom API for non-SCORM deployments).

Key gotchas:

Cross-origin issues - ensure the Unity build is served from the same origin as the LMS, or configure CORS headers appropriately.
WebGL memory - educational institutions often use low-spec devices (Chromebooks). Keep your WebGL build's memory allocation conservative.
Fullscreen - SCORM iframes may prevent fullscreen API access. Design your game's UI to work within a constrained viewport.

Custom API from a Unity Native Build

For iOS and Android deployments:

Use UnityWebRequest for HTTP communication with your backend.
Implement local queuing for offline resilience - educational environments often have unreliable Wi-Fi.
Authenticate via OAuth 2.0 or a signed JWT token passed from the LMS at launch.
Batch telemetry events and send them periodically (every 30-60 seconds) rather than on every interaction, to reduce network overhead.

Compliance and Privacy

Educational game developers handling student data must navigate several regulatory frameworks:

GDPR (EU/UK) - requires a lawful basis for processing, data minimisation, right to erasure, and a Data Processing Agreement between you and the institution.
GDPR-K / Age-Appropriate Design Code (UK) - additional protections for children's data, including restrictions on profiling and data sharing.
COPPA (US) - requires verifiable parental consent for children under 13. Applies to any game used in US schools.
FERPA (US) - protects student education records. Your backend becomes a "school official" if it accesses student data on behalf of the institution.

Privacy compliance is not optional and should be designed into the architecture from day one, not bolted on before launch. We factor compliance requirements into the initial architecture design for every educational project.

Choosing the Right Path

To summarise, here is our recommended decision path:

Browser-only, single LMS, simple tracking --> SCORM 1.2
Browser-only, multiple objectives, detailed interactions --> SCORM 2004
Native mobile app, any platform --> Custom API (SCORM is not available)
Complex analytics, teacher dashboards, research --> Custom API or xAPI
Universal LMS compatibility + rich analytics --> Hybrid (SCORM + Custom API)
Future-proofing for modern infrastructure --> xAPI with LRS

The worst outcome is choosing an approach that does not meet your requirements and having to re-engineer mid-project. Invest the time upfront to understand your client's LMS landscape, data needs, and deployment platforms.

How Long Does Game Development Take? A Realistic Timeline

Ocean View Games — Wed, 12 Aug 2026 15:21:11 +0000

Every prospective client asks us two questions: "How much will it cost?" and "How long will it take?" We covered costs in our mobile game development cost guide. Now let us tackle timelines with the same honesty.

The short answer: a simple hyper-casual game takes 1-3 months. A complex multiplayer game takes 12-24+ months. But those numbers mean very little without understanding what happens during each phase and what causes projects to take longer than planned.

This guide breaks down realistic timelines by game type, explains the four development phases, identifies the most common causes of delays, and gives you practical strategies for keeping your project on track. Every timeline cited here comes from our direct experience shipping games across the full complexity spectrum.

Timelines by Game Type

Hyper-Casual Games: 1-3 Months

Hyper-casual games are the fastest to develop because they are intentionally simple: one core mechanic, minimal art, short play sessions.

When we developed What's That, the total development timeline was approximately two months with a team of two. This included game design, development, basic art, monetisation integration, and store submission. The project also served as a testbed for our reusable game framework, which now lets us kickstart similar projects 30-50% faster.

Typical breakdown:

Pre-production: 1-2 weeks
Core development: 3-6 weeks
Polish and QA: 1-2 weeks
Store submission: 1-2 weeks

Casual and Educational Games: 3-6 Months

Casual games, puzzle games, and educational titles require more content, more polished art, and usually some form of progression system or backend integration.

Our partnership with The Language Conservancy on Vocab Builder took approximately six months. We designed and developed nine individual mini-games, built a scalable data pipeline for adding new languages, and handled full store deployment. The timeline was driven primarily by the volume of distinct game modes and the collaborative design process with the client's linguistic experts.

Our founder's team delivered Word Fun World for Cambridge University Press in roughly four months - a mobile game with multiple mini-games designed for early-years language learning. The relatively brisk timeline was possible because Unity's rapid prototyping capabilities allowed the team to realise the client's vision quickly.

Typical breakdown:

Pre-production: 2-4 weeks
Core development: 8-16 weeks
Content creation: 4-8 weeks (often parallel with development)
QA and polish: 2-4 weeks
Store submission and launch: 1-2 weeks

Mid-Core Games: 6-12 Months

Strategy games, RPGs, and games with complex systems (AI, procedural generation, economies) fall into this bracket. These projects require deeper technical architecture and significantly more content.

Empires Rise, our internal 4X turn-based strategy game, was developed over approximately six months with a lean team. But this was an internal project where we controlled every decision without client review cycles. A comparable client project - with stakeholder approvals, art revisions, and more extensive QA - would realistically take 8-12 months.

The technical challenges at this tier are substantial. Empires Rise required procedural map generation using modified Perlin Noise with cellular automata, a utility-based AI system with coroutine time-slicing to keep the UI responsive on mobile, and a modular architecture designed for future cross-platform deployment. Each of these systems required prototyping, iteration, and optimisation cycles that add weeks to the timeline.

Typical breakdown:

Pre-production: 4-8 weeks
Core systems development: 12-24 weeks
Content and level design: 8-16 weeks (parallel)
AI and backend systems: 4-12 weeks (parallel)
QA, optimisation, and polish: 4-8 weeks
Store submission and launch: 2-4 weeks

Multiplayer and MMO Games: 12-36+ Months

Multiplayer games are in a category of their own when it comes to timeline. The networking layer alone can take as long as a complete single-player game to develop, and the testing and infrastructure requirements are far more demanding.

Our work on Domi Online - a full-scale MMORPG - has been in active development since 2021 and remains ongoing. The initial vertical slice took approximately 18 months of focused development with a core team of three full-stack developers. That vertical slice included a custom 64-bit progression system, server-authoritative networking with FishNet, cost-optimised AWS infrastructure, and GPU-instanced environments.

During our founder's tenure at Jagex, the RuneScape Mobile port involved a team of 50+ people working for approximately two years. The complexity of bringing a 20-year-old MMORPG with thousands of quests, items, and systems to mobile required rewrites of core gameplay loops, adaptive UI architecture, and extensive cross-platform testing.

Key Takeaway: Multiplayer adds 50-100% to the development timeline compared to a similar single-player game. The networking layer, server infrastructure, security, and testing requirements are substantial. Plan accordingly and do not let anyone tell you multiplayer "only adds a few weeks."

Typical breakdown:

Pre-production and architecture: 8-16 weeks
Core systems and networking: 16-40 weeks
Content and world building: 16-40+ weeks (parallel)
Server infrastructure and DevOps: 8-16 weeks (parallel)
Alpha testing and iteration: 8-16 weeks
Beta testing and optimisation: 8-16 weeks
Launch preparation: 4-8 weeks

The Four Phases of Game Development

Every game project, regardless of scale, moves through four distinct phases. Understanding these phases helps you set realistic expectations and identify where your project currently sits.

Phase 1: Pre-Production (10-15% of total timeline)

Pre-production is the most important phase and the one most commonly rushed or skipped. This is where you:

Define the core gameplay loop and mechanics
Create or refine the Game Design Document (GDD)
Conduct market research and audience analysis
Build "greybox" prototypes to test whether the core mechanic is fun
Define the technical architecture and choose tools/frameworks
Establish art style guides and asset pipelines

We cannot overstate how much time a thorough pre-production phase saves downstream. Projects that skip this phase invariably spend more time in production because fundamental design questions surface after systems have already been built. Our game design services exist specifically to help clients get this phase right.

Phase 2: Production (50-60% of total timeline)

Production is the longest phase. This is where the game is actually built:

Programming core systems and gameplay
Creating art assets, animations, and visual effects
Composing music and designing sound effects
Building levels and content
Integrating backend services (analytics, monetisation, cloud saves)
Regular milestone reviews and playtest sessions

We work in two-week sprint cycles during production, delivering playable builds at each milestone so clients can see tangible progress and provide feedback before too much work is invested in any single direction.

Phase 3: QA and Polish (15-20% of total timeline)

Quality assurance is not something that happens at the end - it should be integrated throughout production. But the final QA phase focuses on:

Comprehensive functional testing across all supported devices
Performance profiling and optimisation on target hardware
Bug fixing and regression testing
Accessibility improvements
Final art and animation polish
Platform compliance verification

This phase is frequently underestimated. We routinely see projects that allocate just one week for QA on a six-month game, which is a recipe for a buggy launch and negative reviews.

Phase 4: Launch and Post-Launch (10-15% of total timeline)

The work does not stop when the game is "done":

App Store and Google Play submission (which can involve multiple review rounds)
App Store Optimisation (ASO) for discoverability
Launch monitoring (crash rates, performance metrics, user feedback)
Day-one patches for issues discovered by the broader player base
Analytics review and initial live operations

The 6 Most Common Causes of Delays

Over more than a decade of game development, we have seen the same delay patterns repeat across projects of all sizes. Here are the six most common causes and how to mitigate them.

1. Undefined or Changing Scope

The single biggest cause of delays. When the scope is not locked down before production begins, new features and changes get added continuously. Each "small addition" extends the timeline by days or weeks, and the cumulative effect can double a project's duration.

Mitigation: Invest in pre-production. Create a detailed GDD with a prioritised feature list. Agree on a clear "MVP" (Minimum Viable Product) scope and treat everything else as post-launch content.

2. Art and Asset Dependencies

Programming often moves faster than art production, creating bottlenecks where engineers are waiting for assets. Conversely, art changes requested late in production can force engineering rework.

Mitigation: Establish the art pipeline early. Use placeholder ("greybox") assets during development so engineering work is never blocked. Lock down the art style before production begins.

3. Multiplayer and Networking Complexity

Networking bugs are among the hardest to reproduce and fix. Race conditions, desynchronisation, and latency-related issues often only surface under specific conditions that are difficult to simulate in a development environment.

Mitigation: Budget extra time for multiplayer testing. Build automated stress-testing tools early. Accept that networking will take longer than you think, even if your team is experienced.

4. Platform-Specific Issues

A game that works perfectly on one device may crash on another due to GPU driver differences, OS version incompatibilities, or screen aspect ratio variations. Mobile fragmentation - particularly on Android - creates a long tail of device-specific bugs.

Mitigation: Begin device testing early and on real hardware, not just emulators. Define a target device matrix at the start of the project and test against it regularly.

5. Store Submission Rejections

Both Apple and Google reject apps for policy violations, and the review process can take days to weeks per submission. Common rejection reasons include privacy policy issues, monetisation guideline violations, and performance problems on low-end devices.

Mitigation: Review platform guidelines before development begins. Build compliance checks into your QA process. Budget 2-4 weeks for the submission cycle, not just a few days.

6. Stakeholder Feedback Cycles

Client review and approval cycles can introduce significant delays if not managed proactively. A two-week delay in feedback on a milestone can push the entire project back by a month once downstream dependencies are accounted for.

Mitigation: Establish clear review windows in the project schedule. Agree on maximum feedback turnaround times (we recommend 3-5 business days per milestone). Use regular sprint reviews to keep stakeholders engaged throughout development.

Key Takeaway: Most delays are caused by process problems, not technical problems. Clear scope definition, established art pipelines, and structured feedback cycles prevent the majority of schedule overruns. Invest time in these processes upfront and you will save far more time downstream.

How to Plan a Realistic Timeline

Based on our experience, here is a practical framework for planning your game development timeline.

Step 1: Classify Your Project

Use the game type categories above to establish a baseline timeline range. Be honest about where your project falls - ambition is good, but underestimating complexity leads to missed deadlines.

Step 2: Add Contingency

Apply a contingency buffer of 20-30% to your baseline timeline. This is not pessimism; it is standard practice in professional game development. Platform changes, unexpected bugs, and scope refinements will consume this buffer.

Step 3: Work Backwards from Your Launch Date

If you have a fixed launch date (a conference, a seasonal window, a contractual obligation), work backwards to determine when development must start. If the math does not work, you have three options:

Reduce scope
Increase team size
Move the launch date

We have found that option 1 (reducing scope) produces the best outcomes. Smaller, polished games outperform ambitious, unfinished ones every time.

Step 4: Use a Timeline Estimator

We have built a free Game Development Timeline Estimator that lets you input your project parameters and receive an indicative timeline range. It accounts for game type, team size, platform targets, and multiplayer requirements.

Step 5: Milestone, Do Not Waterfall

Break your project into milestones of 2-4 weeks each, with a playable deliverable at each milestone. This gives you regular checkpoints to assess progress, catch scope creep early, and adjust the plan if something takes longer than expected.

A Note on Team Size and Timeline

There is a common misconception that doubling your team halves your timeline. In practice, the relationship between team size and development speed follows a curve of diminishing returns.

1-2 developers: Ideal for hyper-casual and simple casual games. Low communication overhead, fast decision-making.
3-5 developers: The sweet spot for most mid-core projects. Enough specialisation to cover programming, art, and design without excessive coordination costs.
6-10 developers: Necessary for larger projects, but each additional person adds communication overhead. This is where project management becomes critical.
10+ developers: Required for AAA-scale projects. The overhead of coordination, code integration, and pipeline management becomes a significant percentage of total effort.

We delivered the Domi Online vertical slice with a core team of just three full-stack developers, proving that efficient architecture beats brute-force headcount. A larger team would have been faster in some areas but would have introduced coordination overhead that could have offset the gains.

The Bottom Line

Game development timelines range from 1 month for the simplest titles to 3+ years for ambitious multiplayer experiences. The biggest determinant is game type, but scope clarity, team size, and process discipline have an equally significant impact on whether your project finishes on time.

The single best thing you can do to protect your timeline is to invest properly in pre-production. Define your scope. Build prototypes. Lock down your art pipeline. Then execute with structured milestones and regular stakeholder reviews.

We have shipped games across every timeline bracket discussed in this article, and we are always happy to review your project plan and give you an honest assessment of whether your timeline is realistic.

GPU Instancing for Dense Game Worlds in Unity

Ocean View Games — Wed, 12 Aug 2026 15:20:58 +0000

When you are building a game world that needs to feel alive - dense forests, sprawling cities, battlefields with hundreds of units - you hit a fundamental rendering bottleneck long before your polygon count becomes the problem. The bottleneck is draw calls.

Every time Unity tells the GPU to render an object, it issues a draw call. Each draw call has CPU overhead: setting up the material, binding textures, configuring the render state. On desktop hardware, you can get away with a few thousand draw calls per frame. On mobile, you often need to stay under 200 to maintain a stable 60 FPS.

This is the challenge we faced when engineering the environment systems for Domi Online - an MMORPG with dense, interactive forests where every single tree can be chopped down. We needed to render 10,000+ trees across the visible world with minimal draw calls on mid-range hardware, while still allowing players to interact with individual objects.

In this article, we will walk through the GPU instancing techniques we use to solve this problem, covering the SRP Batcher, manual GPU instancing, LOD strategies, and the interactive-object swap pattern that makes dense worlds both beautiful and functional.

Understanding the Draw Call Problem

Before diving into solutions, it is worth understanding why draw calls are so expensive, particularly on mobile.

What Happens During a Draw Call

Each draw call involves the CPU performing several operations:

State changes: Setting the shader, material properties, and textures for the object
Buffer binding: Pointing the GPU to the correct vertex and index buffers
Uniform uploads: Sending per-object data (transform matrices, colour tints) to the GPU
The actual draw command: Telling the GPU to process the vertices

On desktop GPUs, steps 1-3 are fast because the driver is highly optimised and the CPU-GPU bus has high bandwidth. On mobile GPUs (Adreno, Mali, Apple GPU), these operations are comparatively expensive. The GPU itself can handle millions of triangles, but the CPU overhead of setting up each draw call becomes the limiting factor.

The Naive Approach Fails Fast

Consider a forest scene with 5,000 trees. If each tree is a separate GameObject with its own MeshRenderer and material, Unity issues 5,000 draw calls per frame just for the trees. Add ground, rocks, grass, buildings, and NPCs, and you are looking at 10,000+ draw calls. On a mid-range mobile device, that is a slideshow.

Key Takeaway: On mobile hardware, the number of draw calls - not polygon count - is typically the primary rendering bottleneck. Reducing draw calls from thousands to dozens is the single most impactful optimisation you can make for dense game worlds.

Solution 1: The SRP Batcher

Unity's Scriptable Render Pipeline (SRP) Batcher is the first line of defence against excessive draw calls when using URP (Universal Render Pipeline) or HDRP.

How It Works

The SRP Batcher does not reduce draw calls in the traditional sense. Instead, it reduces the cost per draw call by keeping material data persistent on the GPU. Instead of re-uploading material properties every frame, the SRP Batcher caches them in a dedicated GPU buffer (Constant Buffer). Only per-object data (the transform matrix) needs to be updated each frame.

This means:

Objects using the same shader (even with different material properties) can be batched efficiently
The CPU overhead per draw call drops dramatically
You no longer need to force all objects onto a single material atlas to get batching benefits

When to Use It

The SRP Batcher works best when:

You are using URP or HDRP (it does not work with the Built-In Render Pipeline)
Your objects share the same shader but may have different material instances
You have many unique objects that cannot be statically batched (moving objects, procedurally placed objects)

Limitations

The SRP Batcher is not a silver bullet:

It still issues individual draw calls - it just makes them cheaper
It does not help with objects using fundamentally different shaders
On very low-end mobile hardware, the per-draw-call cost can still add up even with SRP Batcher enabled

For Domi Online, the SRP Batcher gave us a solid baseline, but we needed to go further for the truly dense forest areas.

Solution 2: GPU Instancing

GPU Instancing is the heavy hitter for rendering thousands of identical (or near-identical) objects. Instead of issuing one draw call per object, you issue a single draw call that tells the GPU: "render this mesh 5,000 times, here are the 5,000 transform matrices."

How GPU Instancing Works in Unity

Unity's GPU Instancing works at the material level. When you enable "GPU Instancing" on a material, Unity groups all renderers using that material and mesh combination into instanced batches. Each batch is a single draw call that renders up to several thousand instances.

The key requirements:

Same mesh: All instances must use the same Mesh asset
Same material: All instances must share the same Material with GPU Instancing enabled
Instancing-compatible shader: The shader must include instancing variants (most URP shaders support this)

Per-Instance Properties

One common misconception is that all instanced objects must look identical. In practice, you can vary per-instance properties:

Transform (position, rotation, scale) - handled automatically
Colour tints - using MaterialPropertyBlock
Custom float or vector values - for wind sway amounts, health-based colour changes, growth stages

This allowed us to create forests in Domi Online where trees appeared varied despite sharing the same mesh and material.

Performance Gains

In our testing on mid-range Android devices (Snapdragon 7-series), GPU instancing produced dramatic results:

5,000 individual trees: ~5,000 draw calls, 12 FPS
5,000 instanced trees: ~3 draw calls, 58 FPS

That is a reduction from thousands of draw calls to single digits. The GPU handles the per-instance transforms internally using hardware-accelerated instancing, which is orders of magnitude faster than the CPU issuing individual draw calls.

Solution 3: The Interactive Object Swap Pattern

Here is where the engineering gets interesting. GPU instancing works brilliantly for static scenery, but Domi Online's trees are not static scenery. They are interactive objects that players can chop down.

An instanced tree is not a GameObject - it is just a transform in a buffer. You cannot attach scripts, colliders, or animation controllers to it. So how do you make instanced objects interactive?

The Swap Pattern

We developed what we call the "swap pattern," and it works like this:

Default state: All trees are rendered via GPU instancing. They are cheap, static, and beautiful. No GameObjects exist for them.
Player approaches: When a player moves within interaction range of a tree, the system identifies the nearest instanced tree using spatial hashing.
Swap in: The instanced tree is removed from the instance buffer and replaced with a full GameObject "Interactive Tree" prefab at the same position. This prefab has a collider, interaction script, and chopping animation.
Interaction complete: After the player chops the tree, the Interactive Tree plays a falling animation and transitions to a "Stump" prefab.
Swap out: Once the player moves away, the stump can optionally be converted back to an instanced mesh (a stump mesh) for efficient rendering.

Why This Works

At any given moment, the vast majority of trees in the world are static and non-interactive. Only the 2-3 trees nearest to the player need full GameObject functionality. By maintaining thousands of trees as instanced meshes and only "activating" the ones the player can actually interact with, we keep the draw call count low while preserving full interactivity.

The swap is imperceptible to the player - it happens before they are close enough to notice any visual difference.

Key Takeaway: GPU instancing and interactivity are not mutually exclusive. The swap pattern lets you render thousands of objects efficiently while maintaining full interaction capability for the ones players can actually reach. Only promote objects to full GameObjects when the player needs them.

Solution 4: LOD Strategies for Mobile

Level of Detail (LOD) is a well-established technique, but applying it effectively on mobile requires specific considerations.

Distance-Based LOD Groups

Unity's built-in LOD Group component lets you define multiple mesh representations at different detail levels:

LOD 0: Full-detail mesh (1,000+ triangles) for objects near the camera
LOD 1: Medium-detail mesh (200-500 triangles) for mid-range objects
LOD 2: Low-detail mesh (50-100 triangles) or billboard for distant objects
Culled: Objects beyond a certain distance are not rendered at all

LOD and Instancing Together

A critical optimisation: each LOD level can be independently instanced. This means:

All LOD 0 trees (near the camera) are instanced together in one batch
All LOD 1 trees (mid-range) are instanced in a separate batch
All LOD 2 trees (distant) are instanced in a third batch

You end up with 3 draw calls for an entire forest, regardless of whether it contains 1,000 or 10,000 trees.

Mobile-Specific LOD Considerations

On mobile, we apply additional LOD strategies:

Aggressive culling distances: Mobile screens are smaller, so distant objects contribute less visual value. We cull objects at shorter distances than we would on PC.
Billboard LODs: The furthest LOD level uses a camera-facing quad with a baked texture rather than a 3D mesh. This is extremely cheap to render and works well for trees and foliage.
Dynamic LOD bias: On lower-end devices (detected at startup), we shift all LOD transitions closer to the camera, reducing the number of high-detail meshes rendered at any time.
LOD cross-fading: Rather than hard-popping between LOD levels (which is visually jarring), we use a brief dithering transition. The GPU cost of dithering is negligible compared to the visual improvement.

Putting It All Together: The Full Pipeline

Here is how all these techniques combine in practice for a scene like Domi Online's open-world forests:

Rendering Pipeline (Per Frame)

Frustum culling eliminates all objects outside the camera's view
Occlusion culling eliminates objects hidden behind terrain or large structures
LOD evaluation assigns each remaining object to the appropriate detail level
GPU instancing batches all objects at each LOD level into minimal draw calls
Interactive swap promotes nearby objects to full GameObjects when players approach
SRP Batcher handles any remaining non-instanced objects (UI, unique props, NPCs) efficiently

Results

On Domi Online, this pipeline achieves:

10,000+ trees rendered in the visible world
Under 100 total draw calls for the entire environment
Stable 30+ FPS on mid-range mobile hardware
Full interactivity preserved for every tree in the world

The performance gain is not incremental - it is the difference between "unplayable" and "smooth" on mobile hardware.

Common Pitfalls

Over the course of developing these systems, we encountered several pitfalls worth highlighting:

1. Forgetting MaterialPropertyBlock Limits

While MaterialPropertyBlock lets you vary per-instance properties, overusing it can break instancing. If you set unique properties on too many objects, Unity may fail to batch them, negating the performance benefit. Keep per-instance data minimal: transform, colour tint, and one or two custom floats at most.

2. Shadow Casting with Instanced Objects

Instanced objects can cast shadows, but shadow map rendering effectively doubles your draw calls (once for the camera, once for each shadow cascade). On mobile, consider disabling shadow casting for instanced foliage and using baked shadow textures or ambient occlusion instead.

3. Physics Colliders on Instanced Objects

Instanced meshes do not have colliders. If you need collision detection (for example, preventing players from walking through trees), you can use a separate, invisible collision layer with simple box or capsule colliders placed at tree positions. These are far cheaper than full mesh colliders and do not require GameObjects with renderers.

4. Dynamic Batching Conflicts

Unity's dynamic batching and GPU instancing can conflict. If both are enabled, Unity may choose dynamic batching for small meshes, which is often less efficient than instancing. Disable dynamic batching when using GPU instancing to ensure the instancing path is always used.

When GPU Instancing Is Not the Right Solution

GPU instancing is powerful, but it is not always the best approach:

Unique objects (a single boss character, a unique building) do not benefit from instancing since there is nothing to batch
Skinned meshes (animated characters with bone rigs) cannot be GPU instanced in Unity - use other optimisation strategies for NPCs
Objects with many material variants (different textures, different shaders) break instancing batches. If your forest has 50 tree species each with unique bark textures, consider texture atlasing to consolidate materials

For these cases, the SRP Batcher, static batching (for immovable objects), and manual mesh combining are better alternatives.

Applying This to Your Project

If you are building a game with dense environments - whether that is a city builder, a farming sim, an RTS with hundreds of units, or an open-world RPG - the same principles apply:

Profile first. Use Unity's Frame Debugger to see exactly how many draw calls your scene generates and why.
Enable GPU instancing on materials for any object that appears multiple times.
Implement LOD groups with at least 3 levels, including a billboard LOD for the furthest distance.
Use the swap pattern for objects that need to be both numerous and interactive.
Test on target hardware. Editor performance is not indicative of mobile performance. Profile on the lowest-spec device you plan to support.

These are not theoretical techniques - they are the exact systems we built for a live MMORPG that runs on mid-range mobile hardware. They work.

Unity 7 Is Coming: What It Actually Means for Your Game

Ocean View Games — Mon, 27 Jul 2026 13:10:08 +0000

Unity announced Unity 7 at Unite Seoul this month, with an early beta arriving in December 2026 and a full release targeted for Q1 2027. Big engine version announcements usually come with a familiar sinking feeling: broken projects, deprecated APIs, and weeks of migration work nobody budgeted for. This one looks different, and that is genuinely worth talking about.

Here is our take on what was announced, what matters, and what we would recommend if you are running a live Unity project or planning a new one.

The headline: no rebuilding required

The single most important thing Unity said in Seoul is that Unity 7 is a direct continuation of the Unity 6 architecture. No project rebuilds, no new programming language, no breaking changes at the version boundary. Your Unity 6 project should open in Unity 7 and carry on working.

If you have been through the Unity 4 to 5 transition, or watched Unreal move towards Verse with UE6, you will know how unusual this is. Unity is deliberately positioning itself as the low-friction option: the foundational pieces of Unity 7 are being shipped and battle-tested inside Unity 6.x releases first, so by the time Unity 7 lands, most of it will already be proven in production.

For our clients, the practical upshot is simple. Projects we build on Unity 6 today are not going to be stranded on a legacy version in 2027. That is a real risk with any long-lived mobile title, and it is one Unity has just taken off the table.

Faster iteration, which means faster builds and cheaper changes

Unity 7 standardises on CoreCLR, the modern .NET runtime, as its scripting backbone. The promised results:

Near-instant Play Mode entry
Domain reloads that only touch the code that actually changed
Shader compilation up to 90% faster

Take the 90% figure with the usual grain of salt until independent benchmarks appear, but the direction is right. Iteration speed is the hidden cost centre of game development. Every minute a developer spends waiting for Play Mode or shader compiles is a minute you are paying for. If Unity delivers even half of what it is claiming here, that translates directly into more features shipped per sprint.

Better lighting that scales down to mobile

The flagship visual feature is Surface Cache GI, a real-time global illumination system where indirect lighting responds dynamically as lights change. Crucially for us, Unity says it is designed to run from a single renderer and scale from high-end PC down to mobile, with AI-assisted optimisation and neural upscaling doing the heavy lifting on lower-end devices.

Mobile has historically been where fancy lighting goes to die. Baked lightmaps, blob shadows and careful fakery have been the standard toolkit for years. If Surface Cache GI genuinely scales to mid-range Android hardware, that changes what is achievable in a mobile art budget. We will be testing this the moment it appears in a Unity 6.x preview.

Monetisation built into the engine

Unity 7 folds monetisation deeper into the platform: native direct-to-consumer in-app purchases, no-code webshops, and unified catalogues that feed purchase data into Vector, the AI system behind Unity Ads.

Direct-to-consumer IAP is the one to watch. With app store rules loosening around external purchases, a first-party path to selling outside the Apple and Google storefronts, without bolting on a third-party service, could meaningfully improve margins on live titles. If you are running a game with in-app purchases today, this belongs on your 2027 roadmap conversation.

AI agents get a front door

Unity 7 ships with a free MCP (Model Context Protocol) integration, letting AI coding agents connect directly to the engine, plus a new CLI and public API so builds and asset validation can happen outside the Editor. Unity has been clear that the AI tooling is optional rather than mandatory, which matters for studios and clients with policies around AI-generated content.

We already use AI-assisted workflows where they make sense, and a first-party, supported integration beats the current landscape of community plugins. The CLI and public API are quietly significant too: producers and artists being able to push builds and validate assets from their own tools is a genuine pipeline improvement, not a gimmick.

What we recommend

If you have a live Unity project: get onto the latest Unity 6 release if you are not already there. Unity has said the foundational Unity 7 features are arriving through Unity 6.x first, so staying current is the entire migration strategy. There is no cliff edge to prepare for.

If you are planning a new project for 2026: build it on Unity 6 with confidence. It will move to Unity 7 cleanly, and you will pick up the performance and lighting improvements along the way.

If you are still on Unity 2021 or 2022 LTS: this is the moment to plan the jump to Unity 6. The longer you wait, the further you fall behind a version line that is now clearly the foundation for the next several years.

The beta opens in December 2026 and we will be in it from day one. If you want to talk through what Unity 7 means for your project specifically, get in touch.

Unity's Path to CoreCLR: What the Mono Cutover Means for Your Studio

Ocean View Games — Wed, 22 Jul 2026 21:36:15 +0000

Unity is replacing its scripting runtime. Not tweaking it, replacing it. The Mono runtime that has sat under every line of C# you have written in Unity for years is being retired in favour of Microsoft's CoreCLR. It is the most significant change to Unity's foundation in over a decade, and it is no longer a distant roadmap item: the Unity 6.7 public alpha is out now, with CoreCLR arriving as an experimental option.

Most of the coverage treats this as good news wrapped in a version number. It is good news. But if you run a real project, the interesting questions are the practical ones: when does this actually reach me, what changes underneath my game, and what is going to break. Here is that read, from the perspective of a studio that plans and runs Unity upgrades for a living.

What CoreCLR Is, and Why Unity Is Doing It

Unity has been running a heavily customised fork of Mono for years. That custom fork is the reason Unity has always trailed the wider .NET ecosystem: while the rest of the C# world moved to modern runtimes, garbage collectors, and language features, Unity developers looked on from behind a runtime that could not easily keep pace.

CoreCLR is Microsoft's modern, open-source .NET runtime, the same one that powers current .NET. Moving to it does three things at once: it gives Unity a far more capable runtime and garbage collector, it unlocks modern C# and the current .NET library ecosystem, and it dramatically improves iteration time, the write-save-wait-for-domain-reload loop that quietly eats hours of every Unity developer's week. Unity 6.8 is expected to target .NET 10 and C# 14.

To make room for it, Unity has done something telling: it paused new work on animation and world-building workflows specifically to concentrate engineering on this migration and on architectural stability. That is a company choosing foundations over features, which is the right call, and a sign of how big this change is.

The Timeline That Actually Matters

The migration lands across two releases, and the distinction between them decides what you should do.

Release	What happens	Your posture
6.7 (alpha now, LTS targeted late 2026)	CoreCLR arrives as an experimental, opt-in scripting backend, desktop first, sitting alongside Mono and IL2CPP	Test in a branch. Do not ship on it.
6.8 (targeted late 2026)	Mono is removed entirely. CoreCLR becomes the foundation of the C# layer. No Mono option remains.	This is the real cutover. Plan for it now.

Two things worth internalising. First, Unity has been explicit that 6.8 aims for holistic performance parity first, not a blanket speed-up. Some things will be faster, some slower, and the larger gains come over time as the runtime settles. Treat promises of instant performance with appropriate scepticism. Second, because 6.7 is where you can first put hands on CoreCLR, it is the release to experiment with, even though 6.8 is where the decision becomes unavoidable.

What Changes Under the Hood

The garbage collector is the headline. Mono uses the Boehm GC, which is conservative and non-moving: it cannot always tell precisely what is a live object, and it never relocates memory. CoreCLR brings a precise, moving, generational GC. It knows exactly which objects are live, and it can compact memory. In practice that means less collection overhead and fewer of the stalls that show up as frame hitches. For anyone who has spent time chasing GC spikes in a Unity profiler, this is the change that matters most.

The memory allocator changes too. Unity is integrating MiMalloc, Microsoft's high-performance allocator, which handles the locking problems that hurt multithreaded allocation. If your project makes serious use of the C# Job System, that code gets more stable and more predictable under load essentially for free, just from the engine update.

The C# and serialisation story improves. Beyond the language and library modernisation, Unity 6.7 adds native serialisation for Dictionary<TKey, TValue>, something the community has wanted for years and worked around with ISerializationCallbackReceiver gymnastics. Unity is also removing the old and insecure BinaryFormatter, which is a security improvement but a real migration item if your project or a dependency still uses it.

Iteration gets faster. This is the day-to-day win that every developer on the team feels: compile and domain-reload times come down. On a large project, that is hours back per developer per week.

The Nuance for Mobile and Console: IL2CPP Is Not Going Away

This is the part a lot of the excitement skips, and it is the part that matters most if you ship where we ship.

CoreCLR is a JIT runtime. It is aimed first at platforms that permit JIT compilation: desktop and the editor. But iOS, the consoles, and other restricted platforms require ahead-of-time compilation, and that is exactly what IL2CPP does. Unity has been clear that it has no plans to retire IL2CPP. So the real change is not "Mono to CoreCLR" across the board. It is that the old choice of Mono versus IL2CPP becomes a new choice of CoreCLR versus IL2CPP, with CoreCLR replacing Mono as the JIT option and IL2CPP continuing as the AOT option.

The honest implication for a mobile team: your production iOS and console builds will very likely still go out through IL2CPP for the foreseeable future. That means the immediate, guaranteed win from this migration for a mobile studio is faster iteration and a modern .NET foundation across the team, rather than an automatic reduction in on-device GC stalls on your shipped AOT build. The deeper runtime and GC gains land where CoreCLR actually runs. Knowing which improvements apply to which of your targets is the difference between planning this well and being surprised by it.

What Will Break, and What to Check Now

The migration risk does not sit in your gameplay code. It sits at the boundary between managed C# and native code.

Unity's own engine code, and a great deal of third-party plugin code, was written around the behaviour of the Boehm GC: what it does and does not move, how it handles references crossing into native code. A precise, moving GC changes those assumptions. Unity has had to rework its own internal marshaling tooling to make the transition; native plugins that make similar assumptions will need the same scrutiny.

Concretely, before the 6.8 cutover reaches you:

Audit your native plugins and native interop. Anything using p/invoke, custom marshaling, or pinned pointers is where problems will surface. This is the single highest-value thing to inventory early.
Find anything that relies on Mono-specific behaviour or on BinaryFormatter. Both are on borrowed time.
Check your critical packages and SDKs for CoreCLR readiness, particularly older or unmaintained ones. A dependency that assumes Mono can hold up your whole upgrade.
Test on the 6.7 alpha in an isolated branch, never in production. The point of alpha access is to find your project's specific issues before they are urgent.
Follow Unity's quarterly CoreCLR updates. This is moving fast, and the details shift release to release.

Key takeaway: CoreCLR is genuinely good news, a modern runtime, a much better garbage collector, faster iteration, current C#. But it is a foundational change, and foundational changes reward the studios that prepare and punish the ones that assume an engine upgrade will just work. The work is in the native interop, and the time to look is before 6.8, not during it.

How We Can Help

Ocean View Games plans and runs exactly this kind of migration. Runtime and version upgrades, native plugin audits, and the modernisation of older Unity projects are core to what we do, alongside mobile performance optimisation and mobile builds.

The CoreCLR transition is squarely in our territory, because it is fundamentally about the runtime, the garbage collector, and the managed-to-native boundary, which is where mobile performance work lives. And when you work with us, you talk to the engineer doing the work, not a producer relaying it. If you have a project you know will need to make this jump, we can audit it, tell you honestly what the migration involves, and embed to do it as a co-development partner.

Get in touch and we will give you a straight assessment of what CoreCLR means for your specific project.

Unity 6.5 Is Here: Should Your Studio Upgrade?

Ocean View Games — Wed, 22 Jul 2026 21:36:04 +0000

Unity 6.5 arrived in mid-June 2026, and if you skimmed the announcement you would be forgiven for filing it under "minor update." There is no single headline feature to point at. But 6.5 is more consequential than it looks, because the important changes are subtractions. Several systems that a lot of production projects still lean on have been marked for removal, and the countdown has started.

This post is the read we would give a client: what actually changed, which parts matter depending on where you are in your development cycle, and a straight answer on whether to upgrade.

First, What Kind of Release This Is

Under the Unity 6 model there are two kinds of release, and the difference decides most of the upgrade question on its own.

Update releases (6.4, 6.5, 6.6) carry the newest features, platform support, and performance work. Unity describes 6.5 as a Supported release with the same stability and critical-fix quality as an LTS, right up until the next release lands. They are aimed at projects in active or mid-cycle development.

LTS releases (6.3 LTS, and 6.7 LTS later this year) are the ones to lock production on. 6.3 LTS is supported with fixes and platform updates through December 2027. They are the safe harbour for a title that is shipping or about to.

One date to note if you have not moved recently: Unity 6.0 LTS support ends in October 2026. If you are still on it, that is the real deadline on your calendar, not 6.5.

The Real Story: What Is Being Deprecated

This is the part worth your attention. None of these break your project today, but each one is a planning item.

The Built-In Render Pipeline is deprecated. BIRP still works, and Unity has committed to supporting it through the full 6.7 LTS lifecycle, but it will become obsolete in a future release. If your project is still on BIRP, this is your signal to scope a migration to URP while it is a controlled piece of work rather than something forced on you by an engine upgrade you cannot avoid. Unity has added command-line and Render Pipeline Converter tooling to help move BIRP assets across, which makes now a sensible time to start.

Dynamic batching is deprecated and will be removed in a future release. If you rely on it for draw-call reduction, you will want to move to GPU instancing, the SRP Batcher, or static batching depending on your content.

HDRP is in maintenance. It remains available and is still being brought to new platforms (the Nintendo Switch 2 among them), but it is no longer receiving new features. Unity is consolidating around URP as the primary pipeline for all targets. If you are choosing a pipeline for a new project today, that consolidation should inform the decision.

Smaller items: the HDRP OptiX denoiser is deprecated in favour of Intel's hardware-agnostic OIDN (a compatibility-breaking change if you use OptiX temporal coherence in path tracing), the ReplayKit API has been removed after being obsolete since 6.0, and Entities Journaling is deprecated.

Key takeaway: The headline of Unity 6.5 is not a feature, it is a set of end-of-life notices. The studios that handle these calmly are the ones that read the deprecation list on every release and schedule the work early. The ones that get hurt are the ones that discover BIRP is gone during a rushed engine upgrade two years from now.

The Changes That Matter for Mobile and Web

If you ship to mobile or the browser, this is where 6.5 earns the upgrade.

Web builds got materially better. WebAssembly 2023 is now the default target, Unity bundles the Emscripten compiler with the web platform package so you no longer manage it yourself, and IL2CPP metadata has been optimised to cut web build sizes and shorten load times. There is also a runtime specifically optimised for mobile browsers. For anyone shipping WebGL, this is a real improvement to the two things that hurt most: download size and time-to-first-frame.

Android startup is faster, with build-level optimisations reducing launch time. On mobile, startup time is a retention lever, not a nicety, so this is worth having.

iOS and tvOS get an experimental Swift Xcode project type. Unity is rearchitecting the layer that connects the engine to Apple platforms, and there is now a dedicated public API for native plug-ins that supports lifecycle events, overlay content, and messaging back to C#. If your game depends on native iOS integrations, this is a direction worth tracking, though "experimental" means you test it, you do not ship on it yet.

One gotcha to check before your next iOS submission: UnityWebRequest has switched its underlying networking library from NSURLSession to Mbed TLS. As a result it is no longer automatically exempt from App Store encryption export regulations. If you use UnityWebRequest, review whether your export-compliance declarations need updating. It is a five-minute check that prevents a submission rejection.

For Artists and 2D Teams

Briefly, because it is real value even if it is not our core focus: Unity 6.5 adds APIs for custom 2D lighting and shadow systems, a BlendShape API that brings free-form, cage-based deformation to sprites, and continued work on the 2D physics core. Shader Graph gains a shader-function reflection API that lets you author HLSL nodes directly and have them appear automatically in the graph, plus new Expression and Switch nodes that cut down graph clutter. The AI tooling built into the Editor (Assistant for contextual help, Generators for assets, Sentis for runtime inference) continues to expand.

The Runtime Is Shifting Underneath All of This

Worth flagging, because it is the bigger story on the horizon: Unity 6.5 quietly continues the transition from the Mono scripting runtime to Microsoft's CoreCLR. That migration is the most significant change to Unity's C# layer in over a decade, and it lands properly in the next two releases: an experimental CoreCLR player in 6.7, and the full removal of Mono in 6.8.

It deserves its own treatment rather than a paragraph here, so we have covered what CoreCLR actually means for your project, especially for mobile frame times and garbage collection, in a dedicated companion post.

So, Should You Upgrade to Unity 6.5?

It depends entirely on where you are:

Your situation	Recommendation
Shipping in the next few months	No. Stay on 6.3 LTS. Do not chase an Update release into a launch.
Mid-development, no imminent launch	Worth it. You get the latest platform and performance work, and it smooths your eventual jump to 6.7 LTS.
Still on Unity 6.0 LTS	Plan a move regardless. Support ends October 2026. 6.5 or 6.3 LTS are both reasonable targets.
Still on the Built-In Render Pipeline	The 6.5 upgrade is secondary. The priority is scoping your URP migration before BIRP is removed.
On an older Unity version entirely (2021, 2022, or a legacy build)	This is a modernisation project, not a routine upgrade. Budget it as one.

The honest summary: 6.5 is a good, sensible Update release with genuine mobile and web wins. It is not urgent for a stable project. But its deprecation list is a prompt every studio should act on, whether or not you take this specific version.

How We Can Help

Ocean View Games is a senior Unity studio. We plan and run exactly this kind of work: Unity version upgrades, BIRP-to-URP migrations, and full modernisation of older or legacy Unity projects, alongside mobile performance optimisation and mobile and web builds.

The difference in working with us is direct senior access. You talk to the engineer doing the work, not a producer relaying messages. If you have a project on an ageing Unity version, or a BIRP codebase you know needs to move, we can scope the upgrade honestly, tell you what it will actually take, and embed to do it as a co-development partner.

Get in touch and we will give you a straight assessment before any commitment.

Co-Development vs Freelancers vs Full-Time Hires: Which Is Right for Your Studio?

Ocean View Games — Sat, 11 Jul 2026 17:32:06 +0000

At some point, every game studio faces the same question: we need more capacity, but how do we get it?

The answer is not always obvious. Hiring full-time is the default assumption, but it is not always the right one. Freelancers are fast but introduce coordination overhead. Co-development partners sit somewhere in between.

Having worked across all three models (as full-time employees at Jagex, as freelance contractors, and now as a co-development partner) we have seen the tradeoffs up close. This post breaks them down honestly.

Option 1: Full-Time Hires

How It Works

You recruit developers onto your payroll. They work exclusively for your studio, embedded in your team.

Pros

Maximum alignment - full-time employees are invested in your project's long-term success
Institutional knowledge - they accumulate deep understanding of your codebase, tools, and culture
Always available - no competing clients or project conflicts
Easier IP protection - employment contracts typically include comprehensive IP assignment

Cons

Slow to ramp - recruitment takes 2-4 months. A senior Unity developer in the UK market is in high demand.
Expensive fixed cost - salary, benefits, equipment, office space. In London, a senior Unity developer costs £60,000-90,000 per year before overheads. That cost persists whether the project needs them or not.
Hard to scale down - when the project ships, you are still paying the team. Redundancies are expensive, slow, and damaging to morale.
Skills gaps - your hire might be strong in gameplay but weak in networking. Covering all specialisms requires multiple hires.

When It Works Best

Long-running projects (2+ years) with consistent headcount needs
Core team roles where institutional knowledge is critical (lead engineer, technical director)
Studios with a pipeline of sequential projects that keep the team fully utilised

Option 2: Freelancers

How It Works

You engage individual contractors for specific tasks or time periods. They work remotely, often juggling multiple clients.

Pros

Fast to engage - a good freelancer can start within days
Flexible cost - you pay only for the hours or deliverables you need
Specialist skills - need a shader programmer for 3 weeks? A freelancer is the right tool
No long-term commitment - when the work is done, the engagement ends

Cons

Coordination overhead - every freelancer needs onboarding, context, and management. Multiple freelancers multiply this cost.
Variable quality - the freelance market ranges from exceptional to unreliable. Vetting takes time.
No team dynamics - freelancers optimise for their deliverable, not the project as a whole. Integration issues are common.
Availability risk - your preferred freelancer may be unavailable when you need them
Knowledge loss - when the contract ends, their understanding of your codebase leaves with them

When It Works Best

Short, well-defined tasks (shader work, audio integration, specific tool development)
Surge capacity for crunch periods
Highly specialised skills you need temporarily
Early prototyping where the team structure is not yet defined

Option 3: Co-Development Partners

How It Works

You engage an external studio that embeds a team into your project. They operate as an extension of your in-house team, using your tools, attending your standups, and contributing to your codebase.

Pros

Team, not individuals - you get a coordinated unit with complementary skills. At Ocean View Games, our co-development engagements typically include engineering, QA, and technical art capabilities.
Fast ramp-up - an established team has worked together before. No forming/storming/norming period.
Scalable - scale the team up for production sprints, down for content phases. The co-dev partner absorbs the bench cost, not you.
Battle-tested processes - a co-dev partner brings their own methodology and quality standards, not just warm bodies
Risk sharing - the partner has a reputation stake in the project's success. Poor work loses them future business.

Cons

Higher day rate than freelancers - you are paying for coordination, process, and reliability, not just keystrokes
Less control than full-time hires - the team has their own working patterns and tools preferences
IP considerations - requires clear contractual agreements about code ownership and confidentiality
Cultural fit - the partner's working style needs to mesh with yours. A mismatch creates friction.

When It Works Best

Projects with defined scope and timeline (6-18 months)
Studios that need to scale rapidly without permanent headcount increase
Overflow capacity when your in-house team is at full stretch
Specialised domains (mobile porting, multiplayer networking, educational games) where the partner has deep expertise your team lacks

Key Takeaway: Co-development is not "outsourcing." Outsourcing implies throwing work over a wall. Co-development means embedding a team that operates as part of yours.

The Real Comparison

Factor	Full-Time Hire	Freelancer	Co-Dev Partner
Ramp-up time	2-4 months	Days	1-2 weeks
Monthly cost	£5,000-8,000+	Variable	Scoped per project
Commitment	Permanent	Per-task	Per-project
Scale flexibility	Low	High	High
Knowledge retention	High	Low	Medium
Quality consistency	Depends on hire	Variable	High (team reputation)
Management overhead	Low (once onboarded)	High (per freelancer)	Low (self-managing team)

Comparison at a Glance

Here is how the three team scaling options compare across the factors that influence your decision:

Factor	Freelancer	Co-Dev Studio	Full-Time Hire
Cost (short-term)	✅ Pay per task	⚠️ Scoped per project	❌ Salary + overheads from day one
Cost (long-term)	⚠️ Adds up over time	✅ Scales with project phases	✅ Predictable fixed cost
Accountability	⚠️ Individual, variable	✅ Team reputation at stake	✅ Embedded in your culture
Scalability	✅ Engage and release quickly	✅ Scale up or down per sprint	❌ Redundancies are slow and costly
Domain expertise	⚠️ Depends on individual	✅ Specialist teams available	⚠️ Limited to your hire's skills
IP control	⚠️ Requires careful contracts	⚠️ Requires clear agreements	✅ Employment contracts cover IP
Onboarding time	✅ Days	✅ 1-2 weeks	❌ 2-4 months (recruitment + ramp)

A Hybrid Approach

In practice, the best studios use a combination. A common pattern we see among our clients:

Core team (full-time) - technical director, lead designer, producer. These roles require deep institutional knowledge and long-term investment.
Production capacity (co-dev partner) - the bulk of engineering and QA work during production sprints. Scales up and down with project phases.
Specialists (freelancers) - short-term engagements for highly specific skills (localisation, soundtrack, trailer editing).

This hybrid model gives you the alignment of full-time staff, the flexibility of freelancers, and the coordinated capacity of a co-dev partner.

How We Work as a Co-Dev Partner

At Ocean View Games, our co-development model typically involves:

Embedded integration - we join your Slack, attend your standups, commit to your repo
Complementary skills - we bring Unity engineering, mobile optimisation, and QA capabilities
Transparent communication - bi-weekly sprint reviews with playable demos
Clean handoff - when the engagement ends, you receive clean, documented code with no lock-in

Our work with Domi Online is a prime example. We joined as technical partners, grew with the project, and now operate as the core development team; a relationship that started with a code review and expanded based on trust and demonstrated capability.

DEV Community: Ocean View Games

Game Development Budget Breakdown: Where Does the Money Go?

The Five Core Budget Categories

Engineering: 40-50% of the Budget

What Drives Engineering Costs

Where to Save

Art and Audio: 20-30% of the Budget

What Drives Art Costs

Where to Save

Design: 10-15% of the Budget

What Drives Design Costs

Where to Save

QA and Testing: 5-10% of the Budget

What Drives QA Costs

Where to Save

Project Management: 5-10% of the Budget

What Drives PM Costs

Where to Save

Budget Allocation by Game Type

Mobile Casual / Hyper-Casual

Mobile Mid-Core (Strategy, RPG)

Multiplayer / Online Games

Educational / Serious Games

Planning Your Budget: Practical Steps

Related Reading

Why Your Legacy Educational Game Needs an Update

The Four Forces Killing Your Legacy Game

1. Flash Is Dead (and It Is Not Coming Back)

2. Learners Are Mobile-First

3. Accessibility Requirements Have Evolved

4. LMS Integration Expectations

The Modernisation Spectrum

Level 1: Runtime Migration

Level 2: Platform Modernisation

Level 3: Full Reconstruction

A Real-World Example: The Great Fire of London

The Challenge

The Approach

The Result

The Cost of Doing Nothing

Lost Educational Value

Accumulated Technical Debt

Compliance Risk

Institutional Reputation

What to Look For in a Modernisation Partner

Reverse Engineering Capability

Educational Game Experience

Cross-Platform Deployment

Preservation Mindset

Planning Your Modernisation Project

Step 1: Audit the Current State

Step 2: Define the Target State

Step 3: Assess Scope and Budget

Step 4: Engage a Specialist

Our Approach

Related Reading

Cross-Platform Save Systems: Cloud Sync Done Right

Why Cloud Save Is Harder Than It Looks

Architecture: The Three Layers

Layer 1: The Save Data Model

Layer 2: The Local Persistence Layer

Layer 3: The Cloud Sync Layer

Platform-Specific APIs

Platform Comparison

Custom Backend (PlayFab, Firebase, or Self-Hosted)

Conflict Resolution Strategies

Strategy 1: Last Write Wins (LWW)

Strategy 2: Merge by Field

Strategy 3: Player Choice

Strategy 4: Server-Authoritative (No Conflicts)

Offline-First Architecture

Schema Migration for Live Games

The Version Field Approach

Migration Rules

Security Considerations

Common Attack Vectors

Implementation Checklist

Choosing the Right Approach for Your Game

Related Reading

The True Cost of Game Development Outsourcing