DEV Community: Ocean View Games

Gamification in Corporate Training: Beyond Compliance Checkboxes

Ocean View Games — Tue, 13 Oct 2026 02:25:40 +0000

A common failure mode in corporate e-learning is optimising for completion rather than competence. Employees click through slides, pass a short quiz, and the LMS records that training happened. That proves attendance; it does not necessarily prove that somebody can make the right decision when the real situation appears.

The problem is often not the employee. Some courses have been designed primarily to demonstrate completion rather than assess how learning is applied. When the primary goal is "prove that employees saw this content," the result can be passive learning with little opportunity to practise.

Game-based learning can offer a different approach. Instead of asking employees to absorb information, it asks them to make decisions, face consequences, and adapt their behaviour - the same cognitive processes that drive real-world performance. This post focuses on game-based learning through interactive scenarios. Gamification can add elements such as points or rewards to existing training, while game-based learning uses the activity itself to practise decisions. Both can have a role, but they are not the same thing.

Where Traditional E-Learning Can Fall Short

Before examining the solution, it is worth understanding exactly why the current approach underperforms.

The Passive Consumption Problem

Traditional e-learning often follows a pattern: read content, watch a video, answer multiple-choice questions. That can be useful for checking recognition, but many workplace tasks require recall, judgement, and application under imperfect conditions. If the training never asks learners to practise those decisions, the assessment may be measuring the wrong thing.

The Compliance Trap

When training exists primarily to satisfy regulatory requirements, the incentive structure is backwards. The organisation wants proof of completion, not proof of competence. Employees learn that the fastest path through is to click "Next" repeatedly, skim the quiz questions, and move on. The LMS records a completion. Everybody is satisfied, and nobody has learned anything.

The Context Gap

Real workplace decisions happen under pressure, with incomplete information, and with consequences for getting it wrong. A multiple-choice question about data protection policy bears no resemblance to the actual moment when an employee must decide whether to share a file externally. Without contextual practice, knowledge remains abstract and inapplicable.

What Game-Based Corporate Training Actually Looks Like

Badges and leaderboards are examples of gamification, but they cannot replace useful practice on their own. For the situations discussed here, we mean designing game-based training around interactive decision-making.

Scenario-Based Simulations

The most effective corporate training games place employees inside realistic workplace scenarios and ask them to make decisions. Consider these examples:

Compliance training: Instead of reading about data handling policies, the employee manages a simulated inbox where they must identify phishing attempts, classify documents by sensitivity, and decide when to escalate a potential breach. Wrong decisions trigger realistic consequences - a simulated data leak, a regulatory inquiry, a news headline
Customer service training: The employee handles a series of increasingly difficult customer interactions, choosing from dialogue options and observing how the conversation unfolds based on their choices
Safety training: Workers navigate a virtual environment identifying hazards, choosing corrective actions, and managing time pressure - simulating the cognitive load of a real work environment
Onboarding: New hires explore a simulated version of company systems and processes, completing tasks that mirror their actual first-week responsibilities

In each case, the employee is actively engaging with the material rather than passively observing it. This is the critical distinction.

Branching Decision Trees

Linear training presents the same content to everyone in the same order. Game-based training adapts based on the learner's choices. A branching decision tree allows:

Employees who demonstrate competence to progress quickly through familiar material
Employees who struggle with specific topics to receive additional practice in those areas
Different learning paths based on role, department, or experience level
Multiple outcomes that show how different decisions lead to different results

This approach respects the employee's time while ensuring that everyone achieves the required level of competence.

Decision-Quality Scoring

Traditional training uses binary pass/fail assessment. You either answered the question correctly or you did not. Game-based training can be designed to record more aspects of decisions, where appropriate:

Speed: How quickly did the employee identify the correct course of action?
Accuracy: Did they make the right call?
Reasoning, if captured: Can learners explain their choice, or does the scenario record enough steps to analyse the route they took?
Consistency: Do they make the same types of errors repeatedly?
Improvement: How does performance change across repeated scenarios?

This may reveal patterns that one score misses, although collecting extra data is only worthwhile if someone can act on it.

Key Takeaway: Game-based training can give learners opportunities to practise decisions in realistic scenarios. The game mechanic is not the point - the decision-making practice is the point.

Measurable Outcomes: What L&D Teams Should Measure

The case for scenario-based training should rest on results that can be measured against an existing approach, not on an assumption that it will always be more engaging or effective.

Completion Rates

Completion rate is worth measuring, but it should be measured against your existing course rather than against a generic benchmark. If a scenario-based module improves completion, that is useful; if completion rises but decision quality does not, the redesign has not solved the real problem.

Knowledge Retention

Game-based training can be designed around learning techniques such as retrieval practice, spaced repetition, and repeated decision-making rather than relying only on passive presentation. Useful patterns include:

Retrieval practice: Forcing the learner to recall information rather than recognise it
Spaced repetition: Revisiting concepts at increasing intervals
Interleaving: Mixing different types of problems rather than grouping them by topic
Desirable difficulty: Making tasks challenging enough to require effort without being frustrating

Time-to-Competency

How long does it take a new hire to become productive? A well-designed simulation may help improve this metric by letting employees practise real workflows in a safe environment before they encounter them on the job. Mistakes in a well-contained simulation avoid many of the risks of learning on the job. Mistakes made with real customers or real data cost real money.

Behavioural Change

The ultimate measure of training effectiveness is not what employees know but what they do differently. Game-based training with scenario-based decision-making can provide practice closer to workplace tasks, but any improvement in real behaviour still needs to be tested.

Building the Business Case: ROI Metrics for Leadership

L&D teams often struggle to justify training investments because the benefits are intangible. Scenario-based training can capture more detailed learning data, but connecting that data to business outcomes requires evaluation.

Direct Cost Savings

Potentially fewer compliance incidents: Compare incident rates before and after training, while allowing for other changes that may affect the result
Potentially lower onboarding costs: Measure whether new starters reach agreed competency milestones sooner
Possible retention benefits: If employee retention is part of the business case, measure it rather than assuming training alone will reduce turnover
Potentially fewer training hours: Check whether adaptive routes save staff time without weakening learning outcomes

Measurable Learning Metrics

Depending on their design, interactive training systems may capture additional analytics, including:

Competency heat maps - which departments or roles struggle with which topics?
Decision-pattern analysis - are specific types of errors systemic across the organisation?
Time-to-mastery curves - how does learning speed vary across cohorts?
Retention decay rates - how quickly does performance degrade without refresher training?

If these measures are collected reliably and interpreted alongside other evidence, they can help L&D teams decide where training needs attention.

The ROI Formula

A practical framework for calculating game-based training ROI:

Cost of current training: Development time + delivery time + employee hours spent + LMS licensing
Cost of training failures: Compliance incidents, onboarding delays, performance errors attributable to training gaps
Cost of game-based solution: Development investment + platform costs + ongoing content updates
Projected improvements: Set conservative targets against your own baseline, then validate them with a pilot before extrapolating across the organisation

Whether the investment pays back depends on the cost of the problem you are solving. A pilot gives you the evidence to calculate payback using your own incident rates, onboarding time, learner hours, and support costs instead of relying on a generic ROI promise.

Key Takeaway: Frame the business case around cost avoidance and productivity gains, not engagement scores. Leadership cares about reduced incidents, faster onboarding, and measurable competency - not completion certificates.

Implementation Considerations

LMS Integration

An LMS connection may be essential for some training projects, but it is not automatic. Requirements depend on the platform, reporting needs and IT constraints. Before commissioning development, confirm whether SCORM, xAPI, an LMS-specific API or a simpler reporting approach is appropriate. Integration requirements should be confirmed during discovery; they need suitable implementation and testing before a delivery commitment.

Multi-Device Deployment

Corporate training reaches employees on desktops, tablets, and mobile phones. Field workers, remote employees, and office staff all need access. We build responsive, cross-platform experiences using Unity that adapt to the target device - touch-optimised interfaces for tablets and phones, keyboard/mouse support for desktops.

Content Update Pipelines

Regulations change. Products update. Processes evolve. A training game that requires a full redevelopment every time the content changes is not sustainable.

One useful design option is to separate editable learning content from the application logic so teams can update material without needing a full rebuild every time. Data-driven architectures separate content from logic, meaning your team can modify training scenarios through a spreadsheet or CMS rather than requesting a development sprint.

Enterprise Security

Corporate training handles employee data and potentially sensitive business processes. Security, hosting, personal data and authentication requirements must be scoped with the commissioning organisation. SSO, on-premise hosting and data-handling arrangements are not assumed capabilities or automatic features; they need technical and legal review before being promised.

From Our Experience: Lessons in Educational Game Design

Our work in educational game development has taught us principles that apply directly to corporate training:

When we partnered with The Language Conservancy to build Vocab Builder - a suite of 9 mini-games for language preservation - we learned that every game mechanic must serve a specific learning objective. The same principle applies to corporate training: the game mechanic is the vehicle, not the destination
Our data-driven asset pipeline approach (originally designed so linguistic experts could add new languages without developer involvement) translates directly to corporate content management, where L&D teams need to update training material independently
Focus testing with real learners - a core part of our game design process - is equally critical for corporate training. Employees will tell you what feels patronising, what feels confusing, and what actually teaches them something

These principles, combined with our experience designing games that balance engagement with measurable outcomes, form a useful principle when planning an interactive training project.

Getting Started

If your organisation is considering game-based training, here are the first steps:

Identify one high-impact training programme that currently underperforms. Compliance training is often the best starting point because the costs of failure are quantifiable
Define success metrics before development begins. What does "better" look like - higher completion rates, fewer incidents, faster onboarding, or all three?
Start with a pilot. Build a single training module as a proof of concept, measure the results against your existing approach, and use the data to build the business case for broader adoption
Choose a development partner with educational game expertise. Generic app developers build games. Specialist studios build learning experiences that happen to be games. The distinction matters

5 Signs You Need a Co-Development Partner

Ocean View Games — Mon, 05 Oct 2026 20:23:39 +0000

Nobody starts a game studio planning to ask for help. You build your team, define your vision, and set out to deliver something great. But game development is unpredictable. Scope creeps. Key people leave. Publisher milestones arrive faster than anticipated. Technical challenges turn out to be harder than the prototype suggested.

At some point, many studios face a critical decision: do we push our existing team harder, or do we bring in external support?

The answer is not always obvious. Asking for help too early wastes money. Asking too late puts the project at risk. At Ocean View Games, we operate as a co-development partner for studios ranging from funded startups to established mid-size teams. We have seen the patterns that indicate when a studio genuinely needs external support - and we have also seen studios bring in help they did not need.

This post covers the five clearest signals that it is time to bring in a co-development partner, explains what co-development actually means (it is not outsourcing), and offers guidance on how to make the partnership work.

First: Co-Development Is Not Outsourcing

These terms are used loosely in the industry, but they describe fundamentally different relationships. Understanding the distinction matters because it affects how you scope the engagement, how you manage communication, and what results you can expect.

Outsourcing

Outsourcing means handing off a defined piece of work - a set of 3D character models, a batch of level designs, a completed feature - to an external team that works independently and delivers the finished product. Communication is typically at the handoff points: briefing, review, revision, delivery.

Outsourcing works well for well-defined, self-contained deliverables where the external team does not need deep context about the rest of your project.

Co-Development

Co-development means embedding external developers directly into your team. They attend your stand-ups, work in your Jira, push to your repo, and follow your coding standards. From a day-to-day workflow perspective, they are indistinguishable from your internal developers.

Co-development works well for complex, interdependent work where the external team needs to understand your architecture, collaborate with your engineers in real time, and make decisions that affect other systems.

For embedded engineering engagements, we use a co-development model. When we partnered with Domi Online to build their MMORPG infrastructure, we did not deliver a "networking module" in isolation. We acted as the core engineering team - building combat systems, skill progression, multiplayer networking, and environment rendering as an integrated whole. As Domi Online's CEO put it: "There would be no Domi Online without their expertise."

Key Takeaway: Use outsourcing for well-defined, self-contained deliverables. Use co-development when the external team needs to work inside your architecture and make decisions alongside your developers.

Sign 1: You Are Missing Milestones

This is the most visible and most urgent signal. If your team is consistently missing sprint commitments, your vertical slice date keeps slipping, or your publisher is sending increasingly concerned emails about the Alpha delivery, something has to change.

Why Milestones Slip

In our experience, milestone slippage in game development usually comes from one of three root causes:

Underestimated scope. The feature list was defined before technical unknowns were fully understood. Networking code took three times longer than estimated. The AI system required a complete rewrite.
Technical debt compounding. Early prototyping decisions ("we'll clean this up later") are now slowing every subsequent feature. Adding new content takes twice as long because it keeps breaking existing systems.
Team capacity mismatch. The project plan was written for a team of eight, but attrition or hiring delays mean you are running with five.

How Co-Development Helps

A co-development partner provides experienced capacity much faster than the 2-3 month lead time of traditional hiring, once codebase access and onboarding are confirmed. We bring senior engineers who can navigate complex codebases and start contributing production-ready code within the first sprint.

When we work as an embedded team, we adopt your sprint cadence and take ownership of specific features or backlog items. This directly reduces the load on your internal team and helps you recover missed milestones without burning out the people you already have.

Sign 2: You Have a Critical Skill Gap

Game development requires a breadth of technical skills that few small or mid-sized studios have fully in-house. You might have strong gameplay programmers but nobody who owns performance, mobile platform work, legacy modernisation, build pipelines, or a difficult architectural problem that cuts across the whole project.

Common Skill Gaps We Fill

Mobile performance - Desktop developers moving to mobile can underestimate thermal limits, memory pressure, battery use, touch input, and device variation. These problems benefit from mobile-specific expertise.
Legacy code and architecture - An older Unity project can be commercially valuable while still being difficult to change safely. A fresh pair of senior eyes can identify where to stabilise, refactor, or isolate risk before feature work continues.
Platform integration and porting - Store SDKs, save systems, input, achievements, content delivery, and platform requirements all introduce work outside the core game loop.
Live operations and tooling - Telemetry, remote configuration, content pipelines, and operational tooling require a different mindset from simply getting a build to launch.

The Alternative Is Expensive

Hiring for a specialist role can take months once sourcing, interviews, notice periods, and onboarding are included. If the gap is project-specific, a permanent hire may not be the right investment anyway. Co-development lets you add the capability for the period where it is actually needed.

A co-development partner gives you access to senior specialists for the period you need them without committing to a permanent hire. There is still onboarding, but relevant experience can keep that ramp-up focused.

Sign 3: A Publisher Deadline Is Approaching

Publisher relationships are built on trust, and trust is built on delivery. When you have committed to a milestone date - a vertical slice for a greenlight review, an Alpha build for a trade show, a content update for a seasonal event - missing that date has consequences beyond the immediate project.

The Pressure Compounds

Late deliveries do not just delay revenue. They erode publisher confidence, which can affect:

Approval for additional funding tranches
Marketing support and featuring commitments
Future project greenlight decisions
The overall perception of your studio as a reliable partner

How to Scope a Rescue Engagement

When studios approach us with an imminent deadline, we follow a rapid triage process:

Assess the gap. What specifically is not done? What is the minimum viable delivery that satisfies the milestone requirements?
Identify parallelisable work. Which outstanding tasks can an external team take on without blocking your internal team?
Define integration points. How will our code merge into your project? What are the coding standards, branching strategy, and review process?
Execute. Once access and onboarding are sorted, we aim to be set up in your environment and pulling tickets within days rather than weeks. The exact timeline depends on how quickly access can be granted and how complex the codebase is.

The key is acting early. If you can see a deadline becoming unrealistic two months out, that is the time to engage a co-development partner - not two weeks before the due date.

Key Takeaway: A co-development partner is most effective when engaged early enough to make a meaningful impact. The worst time to ask for help is when it is already too late.

Sign 4: Your Team Is Burning Out

Crunch is the industry's worst-kept secret. Extended periods of overtime, weekend work, and sustained high pressure lead to reduced code quality, increased bugs, declining morale, and - ultimately - people leaving.

The Hidden Cost of Burnout

The financial impact of developer burnout is severe and often underestimated:

Attrition. Replacing a senior developer carries recruitment cost, onboarding time, and a productivity gap while the replacement learns the project.
Bug rates increase. Tired developers write buggier code. The resulting QA burden and rework cycle further extends timelines.
Decision quality degrades. Architectural decisions made under sustained pressure tend to prioritise short-term expedience over long-term stability. This creates technical debt that compounds over the life of the project.
Creativity suffers. Game development is a creative discipline. Exhausted teams produce safe, uninspired work. The spark that makes a game special gets ground down by sustained overwork.

How Co-Development Relieves Pressure

Bringing in an embedded co-development team does not add management overhead for your leads - not if the partner is experienced. Senior co-development engineers should be self-directed within your sprint framework. They take tickets, submit pull requests, and participate in reviews like any other team member.

The immediate effect is that your internal team's workload drops to sustainable levels. Features that were being deferred because nobody had capacity start moving again. People get to work regular hours. Code quality improves. Morale recovers.

This is not a luxury. It is a strategic investment in the sustainability of your team and your project.

Sign 5: You Need to Scale for Live Operations

Shipping the game is a milestone, not the finish line. For live-service games, the real work begins at launch: daily content operations, seasonal events, server monitoring, bug fixes, platform updates, community management, and ongoing optimisation.

The Live-Ops Capacity Problem

During development, your entire team is focused on building the game. At launch, that same team needs to simultaneously:

Fix critical bugs reported by players
Deploy hotfixes without introducing regressions
Develop and ship the first post-launch content update
Monitor server performance and scale infrastructure
Respond to platform-specific issues (iOS update breaks something, Google Play policy change requires compliance updates)
Begin pre-production on the next major update

This often creates a step-change in workload just as the team is trying to stabilise the launch.

The Co-Development Solution

A common and effective pattern is to engage a co-development partner specifically for live operations support. Your internal team focuses on the next major content milestone while the co-development team handles:

Bug triage and fixing - Addressing player-reported issues and crash reports
SDK and platform updates - Keeping third-party SDKs current and maintaining store compliance
Technical debt reduction - Refactoring systems that were rushed to ship, improving stability for the long term
Seasonal content implementation - Building and deploying time-limited events based on your design team's specifications

This split allows your internal team to remain focused and creative while the live game receives the attention and stability it needs to retain players.

Making Co-Development Work

Bringing in an external team is only effective if the integration is handled well. Here is what we have learned from our engagements:

1. Treat Them Like Internal Team Members

The biggest mistake studios make is treating co-development partners as vendors. If your external developers are excluded from architecture discussions, design reviews, and retrospectives, they cannot make informed decisions. They end up producing code that technically meets the ticket requirements but does not align with the broader vision.

Give them the same access to information, the same voice in meetings, and the same accountability as your internal developers.

2. Invest in Onboarding

Even senior developers need context. Spend time walking through your architecture, explaining design intent, and sharing the unwritten conventions that every codebase accumulates. A day or two of thorough onboarding saves weeks of misalignment.

3. Establish Clear Code Standards

Provide your style guide, naming conventions, branching strategy, and PR review process upfront. At Ocean View Games, the first thing we do on any co-development engagement is review the client's coding standards and ensure every line we write matches their project's conventions. When we leave, there should be no way to tell which code we wrote.

4. Define Ownership Boundaries

Be explicit about which systems or features the co-development team owns. Ambiguous ownership leads to duplicated effort and merge conflicts. Clear boundaries allow both teams to work in parallel with confidence.

5. Plan the Handover

Every co-development engagement should have a defined exit plan. We document every system we build, comment our code thoroughly, and provide technical handover sessions to ensure your internal team can maintain and extend our work without confusion. Zero lock-in is a core principle - if our engagement ends, your team picks up exactly where we left off.

Is It Time?

If you recognise one or more of these signs in your studio, it is worth having the conversation. Not every situation requires a co-development partner - sometimes the answer is a scope reduction, a timeline extension, or a targeted hire. But when capacity, expertise, or timeline pressures exceed what your internal team can sustainably handle, a co-development partnership is the most effective way to bridge the gap.

At Ocean View Games, we work with game studios and funded startups as embedded Unity engineering teams. We join your workflow, adopt your standards, and deliver production-ready code from the first sprint. Our team brings senior-level experience from projects including Domi Online and RuneScape Mobile - complex, high-stakes codebases where quality and reliability are non-negotiable.

If you want to explore whether co-development is the right model for your current project, reach out to our team. We are happy to discuss your situation, even if the conclusion is that you do not need us yet.

Building Accessible Games: WCAG for Interactive Content

Ocean View Games — Mon, 28 Sep 2026 21:21:23 +0000

Accessibility in games is not charity work. It is sound engineering, responsible design, and increasingly, a contractual requirement. When public institutions, government bodies, and educational publishers commission interactive content, they expect compliance with established accessibility standards. And even for commercial titles targeting the widest possible audience, accessible design consistently improves the experience for everyone who plays.

Our team's prior institutional work included educational projects for Cambridge University Press, the Museum of London, and European research consortia funded by EU Horizon 2020. In every one of those projects, accessibility was not a nice-to-have feature bolted on at the end. It was a design constraint from Day 1, and it made the games better.

This article is a practical guide to applying WCAG 2.2 AA standards to interactive game content. We will cover what the guidelines actually mean for games, where they apply, and how to implement them without compromising the player experience.

Why Accessibility Matters for Games

The Numbers Are Significant

Disability and temporary or situational access needs affect a substantial part of any broad audience. Designing an experience that depends on one input method, one colour distinction, or perfect hearing needlessly narrows who can use it.

Institutional Clients Require It

If you are building interactive content for government bodies, museums, or educational publishers, accessibility requirements are often part of procurement. The exact legal and contractual standard depends on the client, jurisdiction, platform, and nature of the service, so confirm the required conformance target during discovery rather than assuming one rule applies to every game.

During our team's work on the Great Fire of London interactive game for the Museum of London, accessibility was a core deliverable. The game needed to be playable in classrooms across the UK on a range of devices, by children of varying abilities. This meant responsive layouts, readable text, keyboard-navigable menus, and colour-blind-friendly visual design were non-negotiable.

It Improves UX for Everyone

This is not just a feel-good talking point. Accessible design patterns consistently produce better user experiences across the board:

Larger tap targets designed for motor-impaired players also reduce misclicks on mobile for all players
High-contrast UI designed for low-vision players also improves readability in bright sunlight or on cheap screens
Remappable controls designed for players with limited dexterity also satisfy power users who prefer custom bindings
Subtitles and visual cues designed for deaf players also help anyone playing on a commuter train with the volume off

Key Takeaway: Accessible design is not a constraint on creativity. Many accessibility decisions - clearer hierarchy, flexible input, readable UI, captions - also improve usability in everyday situations for a wider audience.

Understanding WCAG 2.2 in a Game Context

The Web Content Accessibility Guidelines (WCAG) were written for web content, not games specifically. Applying them to interactive experiences requires interpretation. Here is how the four core principles, known by the acronym POUR, translate to game development.

1. Perceivable

Players must be able to perceive the information presented. In a game, this means:

Text alternatives for non-text content. If a quest objective is communicated through an icon alone, provide a text label or tooltip alongside it.
Captions and subtitles for audio content. Any dialogue, narration, or critical sound effect should have a visual equivalent.
Sufficient colour contrast. The minimum contrast ratio for normal text is 4.5:1 against its background. For large text (18pt or 14pt bold), the ratio is 3:1. HUD elements, menu text, and in-game dialogue must meet these thresholds.
No information conveyed by colour alone. If a health bar goes from green to red, it must also change shape, label, or pattern so colour-blind players can interpret it.

2. Operable

Players must be able to operate the interface. For games, this is where things get interesting:

Keyboard/controller accessibility. Every menu, dialogue, and critical gameplay interaction should be operable without a mouse. For educational web games deployed to classrooms (where students may use Chromebooks with trackpads or keyboard-only setups), this is essential.
No time-dependent inputs unless adjustable. If a game mechanic requires a player to press a button within a strict time window, provide an option to extend or disable that timer. This is particularly relevant for quick-time events (QTEs).
Seizure safety. Avoid flashing content that exceeds three flashes per second. This is not just a guideline; it is a serious health concern.
Navigable structure. Players should always know where they are in the game's menu hierarchy and how to return to the main menu or pause screen.

3. Understandable

The game's interface and content must be understandable:

Readable text. Use clear fonts and test them at the actual physical sizes, viewing distances, resolutions, and scaling settings your players will use. A single point-size rule does not translate reliably across phones, tablets, browsers, and televisions.
Predictable behaviour. Menus should behave consistently. A "back" button should always go back. Settings should persist across sessions.
Error prevention and recovery. If a player makes a purchase, confirm it. If a player accidentally deletes a save file, ask for confirmation. This aligns with both accessibility best practice and good UX.

4. Robust

The content must be robust enough to be interpreted by a wide range of user agents, including assistive technologies:

Semantic markup. For HTML5/WebGL games, use proper ARIA roles and labels so screen readers can interpret menu elements.
Assistive technology compatibility. Test with screen readers (NVDA, VoiceOver) to ensure critical UI elements are announced correctly.

Practical Implementation Guide

Colour Blindness Modes

Colour vision deficiency is common enough that colour-only communication is a poor default. The most common categories you will encounter in testing are:

Deuteranopia (red-green, most common)
Protanopia (red-green)
Tritanopia (blue-yellow, rare)

Implementation approach:

Never use colour as the sole indicator of state. Pair every colour change with a shape, icon, or text change.
Provide a colour-blind mode in the settings menu that swaps problematic colour pairs. At minimum, target deuteranopia.
Use a colour-blind simulation tool during development. We recommend the Coblis simulator or Unity's built-in colour blindness simulation in the Scene View.
Test your UI with the Ishihara plate methodology: if two UI elements are distinguishable only by hue (not by brightness, shape, or label), they will fail for some players.

In our work on educational games, we adopted a "shape-first" design language. Every interactive element has a distinct silhouette, and colour is layered on top as a secondary cue. This approach survived colour-blind testing without requiring a separate "mode" at all.

Screen Reader Support for Menu Systems

For HTML5 and WebGL games, screen reader support is achievable and increasingly expected:

Use semantic HTML elements (<button>, <nav>, <dialog>) rather than generic <div> elements for all menu UI
Apply aria-label attributes to any interactive element where the visible text is insufficient (such as icon-only buttons)
Manage focus programmatically. When a menu opens, move focus to the first interactive element. When it closes, return focus to the element that opened it.
Announce dynamic changes with aria-live regions. If a player's score changes, a screen reader user should be able to access that information.

For Unity-based games deployed to native platforms, screen reader integration is more limited but improving. Unity's UI Toolkit supports some accessibility features natively, and third-party packages like UAP (Unity Accessibility Plugin) can bridge the gap for mobile deployments.

Motor Accessibility

Motor impairments range from tremors that make precision inputs difficult to conditions that limit a player to a single switch input. Here is what we recommend:

Remappable controls. Allow every control to be rebound. This is already standard practice on PC and console, but mobile games often neglect it.
Adjustable input sensitivity. Provide sliders for camera speed, dead zones, and aim assist.
Hold vs. toggle options. Any action that requires holding a button (sprinting, aiming) should have an alternative toggle mode.
Auto-play and assist modes. For educational games, consider whether a teacher or carer needs a way to advance, repeat, or operate content on behalf of the learner. The right option depends on the learning objective and target users.

Key Takeaway: Motor accessibility features are not "easy mode." They are input flexibility. Many non-disabled players prefer toggle-to-sprint, adjustable sensitivity, and remapped controls. Building these options benefits your entire player base.

Subtitle and Caption Best Practices

Subtitles in games have historically been an afterthought: tiny white text with no background, rendering them useless in bright scenes. Modern standards demand better:

Background contrast. Place subtitles on a semi-transparent dark background. Never render white text directly over gameplay footage.
Speaker identification. Use colour coding or labels to indicate who is speaking. Remember to pair colour with a name label for colour-blind players.
Size options. Provide at least three subtitle size options (small, medium, large).
Sound effect captions. Critical gameplay sounds (an approaching enemy, an alarm) should have optional visual indicators or descriptive captions like "[footsteps approaching from behind]".
Positioning. Allow players to adjust subtitle position to avoid covering important gameplay elements.

Accessibility in Educational and Government Games

When we build games for government institutions and museums, the accessibility requirements are typically more formal and more stringent than for commercial titles.

Compliance Documentation

Institutional clients may require an accessibility conformance report documenting which criteria the experience meets, partially meets, or does not meet. Some procurements use a VPAT/ACR format; others specify their own evidence. We recommend maintaining this document throughout development rather than producing it as a last-minute exercise before delivery.

Testing with Real Users

Automated accessibility checkers (Axe, Lighthouse) can catch low-hanging fruit like missing alt text and poor contrast ratios. But they cannot tell you whether a game is genuinely playable by someone using a switch device or screen reader. We strongly recommend:

Inclusive user testing with disabled participants during the prototype phase
Expert accessibility audits from a specialist consultancy during beta
Ongoing regression testing to ensure new features do not break existing accessibility features

Classroom Deployment Considerations

During our team's experience building educational games for projects funded by EU Horizon 2020, we learned that classroom environments introduce unique accessibility challenges:

Students may be using shared Chromebooks with no personalised accessibility settings
Teachers may need to operate the game on behalf of a student using a projector
Internet connectivity may be unreliable, so the game needs to function offline
Multiple students with different accessibility needs may be playing simultaneously on different devices in the same classroom

These constraints forced us to build accessibility settings that are easy to change per-session rather than per-installation, stored in-game rather than relying on OS-level accessibility features.

Testing Your Game's Accessibility

Here is a practical testing checklist we use at Ocean View Games:

Visual Accessibility

Run every screen through a colour contrast checker (minimum 4.5:1 for body text)
Enable a colour-blind simulation and verify all critical information is still distinguishable
Scale text to 200% and verify no content is lost or overlapping
Verify all images and icons have text alternatives

Motor Accessibility

Play through the entire game using only a keyboard (no mouse)
Play through using only a controller
Verify all hold-to-activate actions have a toggle alternative
Test with reduced input speed (simulate motor impairment by limiting inputs per second)

Auditory Accessibility

Play through the entire game with volume at zero
Verify all critical audio information has a visual equivalent
Check that subtitles are readable, properly timed, and correctly attributed

Cognitive Accessibility

Verify all instructions are clear and use plain language
Check that the game can be paused at any point
Verify that tutorials can be replayed
Test that difficulty options are accessible and clearly explained

Building Accessibility Into Your Development Process

One of the most expensive mistakes is treating accessibility as a post-production polish pass. Retrofitting it late can force changes across input, UI architecture, content, audio, and QA at the point where those systems are hardest to change.

Here is how we integrate it into our process:

Discovery phase: Define accessibility targets (WCAG AA, platform-specific guidelines) as formal requirements in the GDD
Prototyping phase: Test core mechanics with keyboard-only and controller-only input before committing to a control scheme
Production sprints: Include accessibility acceptance criteria in every user story. "As a colour-blind player, I can distinguish between friendly and enemy units without relying on colour alone."
QA phase: Run the accessibility checklist above as part of every test pass
Delivery: Produce an accessibility conformance report alongside the final build

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.

DEV Community: Ocean View Games

Gamification in Corporate Training: Beyond Compliance Checkboxes

Where Traditional E-Learning Can Fall Short

The Passive Consumption Problem

The Compliance Trap

The Context Gap

What Game-Based Corporate Training Actually Looks Like

Scenario-Based Simulations

Branching Decision Trees

Decision-Quality Scoring

Measurable Outcomes: What L&D Teams Should Measure

Completion Rates

Knowledge Retention

Time-to-Competency

Behavioural Change

Building the Business Case: ROI Metrics for Leadership

Direct Cost Savings

Measurable Learning Metrics

The ROI Formula

Implementation Considerations

LMS Integration

Multi-Device Deployment

Content Update Pipelines

Enterprise Security

From Our Experience: Lessons in Educational Game Design

Getting Started

Related Reading

5 Signs You Need a Co-Development Partner

First: Co-Development Is Not Outsourcing

Outsourcing

Co-Development

Sign 1: You Are Missing Milestones

Why Milestones Slip

How Co-Development Helps

Sign 2: You Have a Critical Skill Gap

Common Skill Gaps We Fill

The Alternative Is Expensive

Sign 3: A Publisher Deadline Is Approaching

The Pressure Compounds

How to Scope a Rescue Engagement

Sign 4: Your Team Is Burning Out

The Hidden Cost of Burnout

How Co-Development Relieves Pressure

Sign 5: You Need to Scale for Live Operations

The Live-Ops Capacity Problem

The Co-Development Solution

Making Co-Development Work

1. Treat Them Like Internal Team Members

2. Invest in Onboarding

3. Establish Clear Code Standards

4. Define Ownership Boundaries

5. Plan the Handover

Is It Time?

Related Reading

Building Accessible Games: WCAG for Interactive Content

Why Accessibility Matters for Games

The Numbers Are Significant

Institutional Clients Require It

It Improves UX for Everyone

Understanding WCAG 2.2 in a Game Context

1. Perceivable

2. Operable

3. Understandable

4. Robust

Practical Implementation Guide

Colour Blindness Modes

Screen Reader Support for Menu Systems

Motor Accessibility

Subtitle and Caption Best Practices

Accessibility in Educational and Government Games

Compliance Documentation

Testing with Real Users

Classroom Deployment Considerations

Testing Your Game's Accessibility

Visual Accessibility

Motor Accessibility

Auditory Accessibility

Cognitive Accessibility

Building Accessibility Into Your Development Process

Related Reading