DEV Community: Ocean View Games

SCORM vs Custom API: Integrating Games with Learning Management Systems

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

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

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

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

What Problem Are We Solving?

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

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

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

SCORM: The Established Standard

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

SCORM 1.2

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

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

Key data model elements in SCORM 1.2:

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

Strengths of SCORM 1.2:

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

Limitations of SCORM 1.2:

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

SCORM 2004 (Editions 1-4)

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

Key improvements over 1.2:

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

Limitations of SCORM 2004:

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

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

xAPI (Tin Can API): The Modern Alternative

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

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

Strengths:

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

Limitations:

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

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

Custom API: The Flexible Alternative

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

Architecture Overview

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

What Your Backend Handles

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

Strengths of a Custom API

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

Limitations of a Custom API

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

Decision Framework: Which Approach Should You Use?

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

1. What platforms will the game run on?

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

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

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

3. How many LMS platforms must you support?

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

4. What is your maintenance budget?

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

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

Integration Approach Comparison

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

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

The Hybrid Approach

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

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

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

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

Implementation Tips for Unity Developers

SCORM from a Unity WebGL Build

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

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

Key gotchas:

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

Custom API from a Unity Native Build

For iOS and Android deployments:

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

Compliance and Privacy

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

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

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

Choosing the Right Path

To summarise, here is our recommended decision path:

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

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

How Long Does Game Development Take? A Realistic Timeline

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

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

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

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

Timelines by Game Type

Hyper-Casual Games: 1-3 Months

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

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

Typical breakdown:

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

Casual and Educational Games: 3-6 Months

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

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

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

Typical breakdown:

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

Mid-Core Games: 6-12 Months

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

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

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

Typical breakdown:

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

Multiplayer and MMO Games: 12-36+ Months

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

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

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

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

Typical breakdown:

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

The Four Phases of Game Development

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The 6 Most Common Causes of Delays

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

1. Undefined or Changing Scope

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

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

2. Art and Asset Dependencies

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

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

3. Multiplayer and Networking Complexity

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

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

4. Platform-Specific Issues

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

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

5. Store Submission Rejections

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

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

6. Stakeholder Feedback Cycles

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

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

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

How to Plan a Realistic Timeline

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

Step 1: Classify Your Project

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

Step 2: Add Contingency

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

Step 3: Work Backwards from Your Launch Date

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

Reduce scope
Increase team size
Move the launch date

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

Step 4: Use a Timeline Estimator

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

Step 5: Milestone, Do Not Waterfall

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

A Note on Team Size and Timeline

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

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

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

The Bottom Line

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

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

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

GPU Instancing for Dense Game Worlds in Unity

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

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

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

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

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

Understanding the Draw Call Problem

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

What Happens During a Draw Call

Each draw call involves the CPU performing several operations:

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

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

The Naive Approach Fails Fast

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

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

Solution 1: The SRP Batcher

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

How It Works

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

This means:

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

When to Use It

The SRP Batcher works best when:

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

Limitations

The SRP Batcher is not a silver bullet:

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

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

Solution 2: GPU Instancing

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

How GPU Instancing Works in Unity

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

The key requirements:

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

Per-Instance Properties

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

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

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

Performance Gains

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

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

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

Solution 3: The Interactive Object Swap Pattern

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

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

The Swap Pattern

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

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

Why This Works

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

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

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

Solution 4: LOD Strategies for Mobile

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

Distance-Based LOD Groups

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

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

LOD and Instancing Together

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

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

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

Mobile-Specific LOD Considerations

On mobile, we apply additional LOD strategies:

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

Putting It All Together: The Full Pipeline

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

Rendering Pipeline (Per Frame)

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

Results

On Domi Online, this pipeline achieves:

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

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

Common Pitfalls

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

1. Forgetting MaterialPropertyBlock Limits

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

2. Shadow Casting with Instanced Objects

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

3. Physics Colliders on Instanced Objects

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

4. Dynamic Batching Conflicts

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

When GPU Instancing Is Not the Right Solution

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

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

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

Applying This to Your Project

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

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

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

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

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

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

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

The headline: no rebuilding required

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

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

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

Faster iteration, which means faster builds and cheaper changes

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

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

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

Better lighting that scales down to mobile

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

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

Monetisation built into the engine

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

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

AI agents get a front door

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

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

What we recommend

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

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

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

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

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

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

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

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

What CoreCLR Is, and Why Unity Is Doing It

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

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

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

The Timeline That Actually Matters

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

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

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

What Changes Under the Hood

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

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

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

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

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

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

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

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

What Will Break, and What to Check Now

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

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

Concretely, before the 6.8 cutover reaches you:

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

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

How We Can Help

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

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

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

Unity 6.5 Is Here: Should Your Studio Upgrade?

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

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

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

First, What Kind of Release This Is

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

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

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

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

The Real Story: What Is Being Deprecated

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

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

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

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

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

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

The Changes That Matter for Mobile and Web

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

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

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

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

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

For Artists and 2D Teams

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

The Runtime Is Shifting Underneath All of This

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

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

So, Should You Upgrade to Unity 6.5?

It depends entirely on where you are:

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

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

How We Can Help

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

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

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

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

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

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

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

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

Option 1: Full-Time Hires

How It Works

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

Pros

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

Cons

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

When It Works Best

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

Option 2: Freelancers

How It Works

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

Pros

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

Cons

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

When It Works Best

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

Option 3: Co-Development Partners

How It Works

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

Pros

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

Cons

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

When It Works Best

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

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

The Real Comparison

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

Comparison at a Glance

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

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

A Hybrid Approach

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

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

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

How We Work as a Co-Dev Partner

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

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

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

Unity vs Godot vs Unreal for Indie Developers (2026): Which Engine Wins?

Ocean View Games — Sun, 05 Jul 2026 04:16:43 +0000

The 2023 Unity Runtime Fee episode pushed thousands of indie developers to reconsider their engine choice. Three years later, the question is more nuanced than the headlines suggested. Unity walked back the changes, Godot took advantage of the moment to grow significantly, and Unreal continued to dominate high-fidelity work. Indie studios in 2026 have a real choice for the first time in a decade.

I have spent 12 years in game development, including a tenure as Mobile Team on RuneScape Mobile at Jagex. We are a Unity-specialist studio that works with indie clients on contracts from £20k upwards: solo developers building first commercial titles, two- and three-person teams shipping their second or third game, and small teams with seed funding building toward a Steam launch. We picked Unity deliberately and we will say upfront where that lens does and does not serve you. The advice below is what I tell indie clients during scoping calls when they ask whether they have made the right engine choice.

This is not a feature checklist. It is the engine question viewed through the constraints that actually matter for indies: cost, scope risk, hiring at small scale, asset ecosystems, and the licence terms that survive the next downturn.

The 30-Second Answer

If you skim nothing else, take this:

Pick Unity if you are a one- to five-person team building a commercial 2D or mobile game on a budget. Largest contractor pool at indie-friendly rates, deepest asset ecosystem, mature monetisation tooling. The pragmatic indie default.
Pick Godot if licence freedom is non-negotiable, your project is 2D-first, your team already knows Godot, or you are building toward an open-source distribution model. The cleanest licensing position of any major engine.
Pick Unreal if your indie team has C++ depth and visual fidelity is your core marketing hook. The right call for small teams chasing AAA visuals on a tight budget, the wrong call for almost everyone else.

The rest of this article explains why each is true, which scenarios reverse the recommendation, and the cost realities of running an indie team on each engine.

What Indies Actually Need from a Game Engine

Indie constraints differ from studio constraints. A 200-person studio cares about pipeline scaling, custom tool integration, and engine source access. A solo or three-person team cares about something narrower:

Low or zero engine cost. Indie margins are thin. An extra £2,000 per year on tooling subscriptions matters when your runway is six months.

Fast iteration. When you are wearing multiple hats, the time between "have an idea" and "see it on screen" is the most expensive variable in your day.

The ability to hire help if the project takes off. Most indie projects either fail or grow beyond what one or two people can finish. Engine choice determines how easy it is to bring in a contractor for a sprint.

A pre-built asset and plugin ecosystem. A solo dev cannot build a save system, an inventory UI, a dialogue system, a settings menu, an analytics SDK, an IAP integration, and a localisation pipeline from scratch. Buying or downloading these is the difference between shipping and quietly abandoning the project.

Licence terms that will not change. The 2023 Unity Runtime Fee episode showed that engine licensing can change without warning. For indies, that risk is concrete: a fee structure shift can wipe out projected margins on a game that has already been written.

Marketability. Engine choice has a small but real effect on Steam reviews, press coverage, and player perception. Mostly minor, occasionally relevant.

We will look at each engine through these constraints.

Unity for Indies

Unity remains the pragmatic indie choice for most commercial projects. Here is why.

Cost reality. Unity Personal is free for studios earning under $200,000 per year. Most indie projects, including most that ship to Steam or mobile stores, never cross that threshold. For studios that do, Unity Pro is roughly £1,800 per seat per year. There is no per-install fee. Predictable, and almost always free for indie scale.

The Asset Store advantage. This is genuinely Unity's largest indie-specific strength. A solo dev buying a £40 character controller, a £30 dialogue system, and a £25 save manager has saved themselves four to six weeks of development time. The asset store has hundreds of options at every price point including free. For indie teams without dedicated tooling engineers, this is huge.

Contractor pool. Unity contractors are everywhere. Indie-friendly day rates exist (we see £300 to £700 typical for Unity mobile contractors, with the lower end aimed at indie projects). When you need a sprint of additional help to ship a feature or fix a stubborn bug, Unity has the deepest pool.

Mature monetisation tooling. Unity LevelPlay, AdMob, IronSource, Unity IAP, GameAnalytics. All have first-party or vendor-maintained Unity packages. For free-to-play indie mobile, this is a months-of-work saving over assembling the same stack in another engine.

Console export. Unity has direct first-party support for PlayStation, Xbox, and Nintendo Switch. Indies still need a publisher relationship to actually ship to consoles, but the engine side is straightforward.

The 2023 Runtime Fee aftermath. Unity walked back the worst of the changes, but trust took a hit. Three years on, the per-seat subscription is back to being predictable. Some indies still moved to Godot during the episode and have not come back, but for new projects, Unity's licensing is again rational.

Limitations to know about. "Another Unity game" reviewer fatigue is real but minor. Some Steam reviewers flag Unity-built games as low-effort, but this is rarely the dealbreaker some claim and it can be neutralised with strong art direction and polish. Unity Pro per-seat costs add up if your team grows past the revenue threshold. The engine has a history of "multiple ways to do the same thing" (Built-in vs URP vs HDRP, old Input vs new Input System), which can frustrate indie teams using older tutorials.

Godot for Indies

Godot is the right call for a specific subset of indie scenarios. Here is when.

The cleanest licensing position of any engine. Godot is MIT-licensed: no fees, no royalties, no usage tracking, no terms that can change later. You can fork the engine source, ship commercial games, and owe nothing. For indies who got burned by the 2023 Unity episode (and for indies generally allergic to platform risk), this matters.

2D pipeline strength. Godot's 2D engine is purpose-built rather than retrofitted on a 3D renderer. For 2D indie games, the workflow feels native: dedicated 2D physics, 2D lighting, sprite tools, tilemaps. If your project is 2D-first, Godot is often more efficient to work in than Unity.

Small editor footprint and fast iteration. Godot is around 120 MB. The editor opens in seconds. GDScript has no compile step. For indie teams iterating rapidly during pre-production, this matters more than feature parity with larger engines.

Growing community and ecosystem. Since 2023, Godot's contributor base, plugin ecosystem (AssetLib), and tutorial volume have grown significantly. It is no longer a hobbyist-only tool, though it has not yet caught Unity in commercial mobile.

Limitations to know about. Contractor pool is small (we estimate roughly 1/5 the Unity contractor pool, though it varies by region). The AssetLib equivalent of the Unity Asset Store is smaller and less actively curated. Console support requires a third-party publisher (W4 Games and Lone Wolf Technology are the names indies typically work with), which adds cost and complexity. Monetisation SDK gaps for mobile (AdMob, IronSource, AppLovin) require either a community plugin or manual native integration. For free-to-play mobile, this is real friction.

When Godot is the right indie call. A solo developer or two-person team shipping a paid 2D game to Steam or a premium mobile audience. A team that already knows Godot and would lose time switching. A team with strong licence-freedom convictions. A project where the engine will need to be modified or extended at the source level.

Unreal for Indies

Unreal is rarely the right indie call. Here is when it is.

5% royalty above $1M is rarely an indie concern. Most indie projects do not hit $1M in lifetime gross revenue. For those that do, the royalty is a tax on success, which is a problem to be glad you have. Effectively free for indie scale.

MetaHuman, Megascans, and Quixel Bridge are included free. Epic bundles assets that would individually cost thousands of pounds elsewhere. For an indie chasing AAA-looking visuals, this is a meaningful subsidy.

AAA visual fidelity is genuinely Unreal's strength. If your indie game's marketing hook is "this looks AAA on a small budget", Unreal gives you more visual quality per artist-hour than Unity or Godot.

Limitations to know about. Editor weight is the biggest issue. Unreal assumes a powerful PC. Indie teams on older laptops will struggle. C++ compile times are long, often 15 to 60 seconds for incremental changes. Blueprints get unwieldy at scale, and serious indie work eventually requires C++. Contractor day rates are roughly 30 to 50% higher than Unity equivalents (£500 to £900 typical), which matters for indie budgets. Build sizes are large (150 to 300 MB minimum for mobile), which hurts mobile install rates. The 5% royalty, while rarely triggered, is administratively annoying when it does kick in.

When Unreal is the right indie call. A small team with existing C++ depth and a project specifically focused on photorealistic 3D PC or console release. A team migrating from a previous Unreal project where the engine knowledge is sunk cost. A solo or two-person team where the lead has shipped Unreal commercially before.

For everyone else, Unreal is overkill.

Cost Reality Comparison

Indie cost realities, side by side. All figures in GBP for typical UK and EU contractor rates, USD for Unity revenue threshold and Unreal royalty (set in those currencies):

Cost factor	Unity	Godot	Unreal
Engine licence (small team)	Free under $200k revenue; per-seat Pro after	Free, no royalties, no thresholds	Free; 5% royalty above $1M lifetime
Editor + dev environment cost	Negligible (any modern laptop)	Negligible (very lightweight)	Significant (powerful PC/RTX recommended)
Typical contractor day rate	£300-£700	£350-£600 (smaller pool)	£500-£900
Asset Store / pre-built systems	Largest, mature	Smaller (AssetLib)	Marketplace good, less indie-priced
Console export (indie-friendly)	Direct via Unity	Third-party publisher needed	Direct via Unreal
Mobile build size (minimum)	30-50 MB	30-60 MB	150-300 MB
Iteration speed (compile)	3-10s (C#)	Instant (GDScript)	15-60s (C++)

Scope Risk: Which Engine Forgives a Small Team's Mistakes?

Indie projects rarely fail because the engine was wrong. They fail because scope grew past what a small team could finish. Engine choice still affects how badly scope errors hurt.

Unity has the deepest community for unblocking. When an indie team hits a problem they cannot solve, Unity has the largest pool of StackOverflow answers, YouTube tutorials, and Discord communities. The probability that someone has hit your exact bug and solved it is highest in Unity. For indies without senior engineering depth, this matters enormously.

Godot has the cleanest scaling story. No fee triggers, no licence renegotiation, no per-install costs. If your indie game becomes a hit, Godot's licensing does not change shape under you. The trade-off is that you are responsible for more of the infrastructure (especially monetisation and analytics) yourself.

Unreal punishes scope errors hardest. Long compile times, heavy editor, and the C++ overhead mean that "I will refactor this later" costs more in Unreal than in the others. For indie teams who change direction mid-project (most indie teams), this is a real cost.

For most indies, the right answer is to keep scope small enough that the engine's forgiveness does not matter. But when scope inevitably grows, Unity's community depth saves the most projects.

The Marketability Question

Players largely do not check what engine you used. Reviewers and journalists occasionally do. Here is the actual impact.

Steam review fatigue around Unity is real but minor. Some Steam reviewers flag Unity-built games as "another Unity game" or assume low effort. This effect is small and can be neutralised with strong art direction, polished UX, and a distinctive visual style. We have not seen evidence that engine choice meaningfully affects Steam review scores or revenue.

The "hand-crafted in Godot" indie marketing angle exists. A small but visible subset of indie marketing leans into "we built this in Godot because we believe in open source". This works for specific audiences (FOSS-aligned communities, certain Twitch and YouTube circles) but is irrelevant to most commercial markets.

Unreal's visual selling power. "Built in Unreal Engine 5" is a marketing signal that can move pre-orders if your trailer looks AAA. For indies whose pitch is visual fidelity, this is genuinely valuable. For indies whose pitch is gameplay or story, it is invisible.

For most indie projects, engine choice should not be driven by marketing. Pick the engine that lets you ship; the marketing follows from the game itself.

Three Indie Scenarios with Specific Recommendations

Generalisations only get you so far. Here are three specific indie scenarios with the recommendation.

Scenario 1: Solo dev shipping a 2D game in 12 months

You are one person. You have a 2D game in mind. You want to ship to Steam or itch.io within a year. You may release a mobile companion build later.

Recommendation: Godot is often the better call. Faster iteration, cleaner licensing, purpose-built 2D pipeline, smaller editor footprint. The contractor pool size matters less because you are not planning to hire. The asset ecosystem gap matters less because solo devs typically build their own systems anyway. If you already know Unity well, stick with Unity. Otherwise, Godot.

Scenario 2: Two- to five-person team shipping a commercial mobile or hybrid title

You are a small team with seed funding or self-funded runway. You are building a free-to-play or hybrid mobile title with ad mediation, IAP, and analytics. You may need a contractor for a few sprints to hit your launch window.

Recommendation: Unity is almost always the right call. Mature monetisation tooling, large contractor pool, deep asset ecosystem, and the highest probability of finding affordable specialised help when you need it. The licensing predictability is now back to where it was pre-2023. For commercial mobile work specifically, Unity is the pragmatic indie default.

Scenario 3: Indie team chasing AAA visuals on a small budget

You are a small team with at least one engineer comfortable in C++. Your pitch is visual fidelity: a 3D PC or console game that looks like a much bigger studio made it. Your marketing hook is the trailer.

Recommendation: Unreal, but only if visual fidelity is your top marketing hook. The free MetaHumans, Megascans, and Lumen rendering are real subsidies for the look you are chasing. Be honest with yourself about whether the team has the C++ depth to ship in Unreal without burning the timeline. If the answer is no, build in Unity with strong art direction instead. For a single project, Unreal can deliver visuals that punch above your weight. For a sustained indie career, Unity has lower per-project overhead.

Frequently Asked Questions

Which engine is best for indie game development in 2026?

Unity for most commercial indie projects, especially mobile. Godot for licence-sensitive teams, 2D-first projects, and developers who already know it. Unreal only when visual fidelity is the core marketing hook and the team has C++ depth.

Is Godot good enough for commercial indie games?

Yes for 2D and mid-tier 3D, particularly for paid releases on Steam and itch.io. Several commercial indie titles have shipped on Godot. The main commercial gaps are console support (third-party publisher required) and mobile monetisation tooling (community plugins rather than first-party SDKs).

Is Unreal too expensive for indie developers?

Engine licence cost is not the issue. Unreal is free until $1M lifetime gross revenue, then 5% royalty above that. For most indies, this is effectively free. The real costs are hardware (Unreal needs a powerful PC), iteration time (long compile cycles), and contractor rates (30 to 50% higher than Unity equivalents).

What is Unity's Runtime Fee and is it still a concern?

The 2023 Runtime Fee proposed a per-install charge above certain revenue thresholds. Unity walked back the changes after significant industry backlash. As of 2026, Unity's pricing is per-seat subscription only, with no per-install fee. The episode damaged trust but the current pricing is predictable and back to its pre-2023 model.

How much does it cost to make an indie game in Unity?

It depends on scope. A focused 2D indie title built by one or two developers might cost £20,000 to £80,000 in actual cash spending (including contracted art, audio, and engineering help). A more ambitious 3D indie title with a small team might cost £80,000 to £300,000. Unity engine cost is rarely the dominant factor; team time is.

Can I publish a Godot game on consoles?

Yes, but you need a third-party publisher. Godot itself does not have first-party PlayStation, Xbox, or Nintendo Switch support. Companies like W4 Games and Lone Wolf Technology offer console porting services for Godot games. This adds cost and a relationship to manage that Unity and Unreal do not require.

Should I switch from Unity to Godot for my next indie project?

Probably not, unless your next project is specifically 2D-first or licence freedom is genuinely critical to you. Engine switching costs three to six months of learning curve plus the loss of your accumulated Unity workflow knowledge. For a new indie project where you have no engine bias, Godot for 2D and Unity for everything else is a reasonable starting point.

Closing CTA

If you are still weighing the choice, our 3-engine comparison hub covers the full picture across all use cases, not just indie scenarios. If you specifically want the mobile-focused breakdown, our Unity vs Godot vs Unreal for mobile post covers that in depth. For beginners just starting out, our beginner-focused engine comparison is the right place to begin.

If you have decided on Unity and want a senior team to embed alongside your indie squad for a sprint, our co-development service is designed for exactly that. We work with indie studios on contracts from £20k upwards.

The engine matters less than shipping. Whichever you pick, the discipline is the same: keep scope small, iterate fast, and ship the smallest viable version of your idea.

Cross-Platform Multiplayer Networking in Unity: FishNet, Mirror, and Photon Compared

Ocean View Games — Sun, 05 Jul 2026 04:16:23 +0000

Choosing a networking framework for a Unity multiplayer game is one of the most consequential technical decisions you will make. It affects architecture, server costs, latency, cheat prevention, and (critically) how painful the next 12 months of development will be.

At Ocean View Games, we have shipped multiplayer projects using FishNet and have evaluated Mirror and Photon in depth. Our network engineering work on Domi Online (a server-authoritative MMORPG serving a global player base) gave us extensive hands-on experience with the real-world tradeoffs.

This post is the comparison we wished existed when we started.

The Three Contenders

FishNet

An open-source networking framework built specifically for Unity. Created by FirstGearGames, it positions itself as a modern, performance-focused alternative to Mirror.

Mirror

An open-source successor to Unity's deprecated UNET. The most widely adopted Unity networking solution, with a large community and extensive documentation.

Photon (PUN / Fusion)

A commercial networking platform with both client-hosted (PUN) and server-authoritative (Fusion) options. Provides managed infrastructure so you do not run your own servers.

Architecture: Server-Authoritative vs Peer-to-Peer

This is the most fundamental decision, and it constrains your framework choice.

Server-Authoritative

The server is the single source of truth. Clients send inputs; the server validates them and broadcasts the result. Cheating is significantly harder because the client cannot unilaterally modify game state.

When you need it: Any game with competitive mechanics, real-money economies, leaderboards, or persistent worlds. For Domi Online, server authority was non-negotiable as the game has a player-driven economy where item duplication or stat manipulation would destroy the game.

Frameworks: FishNet (excellent), Mirror (good), Photon Fusion (good, managed)

Peer-to-Peer / Client-Hosted

One player acts as the host. Other players connect to them. Simpler to set up, but the host has an inherent latency advantage and can potentially cheat.

When it works: Co-op games, casual multiplayer, games where cheating has low impact.

Frameworks: Mirror (common use case), Photon PUN (designed for this), FishNet (supports it but overkill)

Key Takeaway: Choose your architecture first, then pick the framework that best supports it. Do not let framework familiarity drive an architectural decision.

FishNet: Our Framework of Choice for Domi Online

Why We Chose It

When we evaluated networking options for Domi Online, we needed:

Server-authoritative architecture with full state control
Efficient bandwidth usage (MMORPG with hundreds of concurrent players)
Extensibility for custom serialisation of our 64-bit progression system
Active development and responsive maintainer

FishNet met all four criteria.

Strengths

Prediction and reconciliation - FishNet's client-side prediction is mature and well-documented. Players see immediate feedback on their actions while the server validates asynchronously.
Object spawning - network object lifecycle management is clean. Spawning, despawning, and ownership transfer are straightforward.
Custom serialisers - we wrote custom serialisation for our 64-bit stat system. FishNet's serialiser API made this painless.
Performance - benchmarks consistently show lower bandwidth overhead than Mirror for equivalent workloads.
Active development - the maintainer ships regular updates and is responsive to issues.

Weaknesses

Smaller community - fewer tutorials, Stack Overflow answers, and third-party integrations compared to Mirror
Documentation gaps - improving rapidly, but some advanced features require reading source code
Learning curve - developers coming from PUN or Mirror will need adjustment time

Mirror: The Community Standard

Strengths

Massive community - the most widely used Unity networking solution. Finding answers to common problems is easy.
Extensive transports - supports WebSocket, KCP, Steam, and more out of the box
Battle-tested - used in hundreds of shipped games across diverse genres
Low barrier to entry - getting a basic multiplayer prototype running is fast
Well-documented - comprehensive documentation and numerous tutorials

Weaknesses

Bandwidth efficiency - Mirror's default serialisation is less efficient than FishNet's. For small-scale multiplayer (4-16 players) this is irrelevant. For MMO-scale, it adds up.
Prediction - client-side prediction exists but is less mature than FishNet's implementation. Requires more manual work for smooth results.
Host migration - limited support. If the host disconnects in a client-hosted game, recovery is complex.

When to Choose Mirror

Mirror is the right choice when:

Your game has 2-16 players (co-op, competitive matches)
Development speed matters more than bandwidth optimisation
Your team has existing Mirror experience
You need maximum community support and third-party asset compatibility

Photon: Managed Infrastructure

Strengths

No server management - Photon handles matchmaking, relay servers, and infrastructure scaling. You do not run your own servers.
Global infrastructure - data centres worldwide with automatic region selection
Quick prototyping - PUN (Photon Unity Networking) gets a multiplayer prototype running in hours
Photon Fusion - their newer framework supports server-authoritative architecture with tick-based simulation, comparable to FishNet in capability

Weaknesses

Cost at scale - Photon charges per CCU (concurrent user). For an MMORPG with thousands of concurrent players, costs escalate quickly. This was a decisive factor in our decision not to use Photon for Domi Online.
Vendor lock-in - your networking code is tied to Photon's API. Migrating away is a significant rewrite.
Less control - you cannot inspect or modify the server infrastructure. Debugging latency issues requires Photon's support team.
PUN limitations - PUN is client-hosted only. For server-authoritative, you need Fusion, which has a steeper learning curve.

When to Choose Photon

Photon is the right choice when:

You do not want to manage servers
Your CCU will stay under a few hundred (where the free/affordable tiers apply)
You need rapid prototyping with minimal backend work
Global matchmaking is a requirement and you want it out of the box

Head-to-Head Comparison

Factor	FishNet	Mirror	Photon PUN	Photon Fusion
Architecture	Server-auth or P2P	Server-auth or P2P	Client-hosted only	Server-auth
Cost	Free (open-source)	Free (open-source)	Per-CCU pricing	Per-CCU pricing
Server management	Self-hosted	Self-hosted	Managed	Managed
Bandwidth efficiency	Excellent	Good	Good	Excellent
Client prediction	Mature	Basic	N/A	Mature
Community size	Growing	Large	Large	Growing
MMO suitability	Excellent	Possible	Poor	Good (but costly)
Prototyping speed	Moderate	Fast	Very fast	Moderate

Framework Comparison at a Glance

Here is how FishNet, Mirror, and Photon compare across the factors that matter most when choosing a multiplayer framework:

Feature	FishNet	Mirror	Photon
Server authoritative	✅ Excellent	✅ Supported	⚠️ Fusion only (PUN is client-hosted)
Free/open source	✅ MIT licence	✅ MIT licence	❌ Per-CCU pricing
Cloud hosting	❌ Self-hosted	❌ Self-hosted	✅ Managed infrastructure
MMO scale	✅ Built for large scale	⚠️ Possible with effort	⚠️ Costly at high CCU
Learning curve	⚠️ Moderate	✅ Low barrier to entry	✅ PUN is very fast to learn
Active development	✅ Regular updates	✅ Mature, stable	✅ Actively maintained
Unity integration	✅ Purpose-built for Unity	✅ Purpose-built for Unity	✅ Official Unity SDK

Our Recommendation

There is no universal "best" framework. The right choice depends on your game:

Building an MMO or competitive game with a persistent world? FishNet. The bandwidth efficiency and prediction systems justify the smaller community. This is what we chose for Domi Online.
Building a co-op or small-scale multiplayer game? Mirror. The community support and rapid development speed outweigh its efficiency gap at small player counts.
Building a prototype or MVP with no backend team? Photon PUN. Get something playable fast and evaluate whether the pricing model works at your projected scale.
Need server-authoritative without managing infrastructure? Photon Fusion. But model your CCU costs carefully before committing.

Key Takeaway: The framework you prototype with is not necessarily the framework you ship with. Evaluate based on your production requirements, not your prototyping requirements.

Serious Games vs Gamification: What''s the Difference?

Ocean View Games — Sun, 05 Jul 2026 04:16:09 +0000

These two terms get used interchangeably in boardrooms and pitch decks across the education and corporate sectors. We hear it regularly: "We want to gamify our training programme" when what the client actually needs is a serious game, or "We need a serious game" when a lighter gamification layer would achieve their goals at a fraction of the cost.

The distinction matters. Choosing the wrong approach wastes budget, delays delivery, and - most critically - fails to produce the learning outcomes the project was supposed to achieve.

At Ocean View Games, we have built both. We have developed serious games for language preservation, contributed to award-winning educational titles during our team's previous tenure, and designed gamified systems within non-game applications. This post clarifies the difference, explains when each approach is appropriate, and helps you make the right decision for your project.

Definitions: Getting the Language Right

What Is a Serious Game?

A serious game is a complete, standalone game experience where the primary purpose is something other than pure entertainment. It has game mechanics, a game loop, visual design, audio, progression systems, and player agency - all the elements you would expect from a commercial game. But its core objective is to teach, train, simulate, or change behaviour.

The key word is "game." It is a self-contained product that a user launches, plays, and engages with as a game. The learning happens through the gameplay itself, not alongside it.

Examples include:

Flight simulators used to train pilots before they fly real aircraft
Medical training games where surgeons practise procedures in a risk-free virtual environment
Language learning games where vocabulary and grammar are embedded into gameplay loops rather than presented as flash cards
Historical simulations that teach events through interactive narrative and decision-making

What Is Gamification?

Gamification is the application of game mechanics and design principles to non-game contexts. It does not create a new game. Instead, it layers game-like elements - points, badges, leaderboards, streaks, progress bars, challenges - onto an existing process or platform.

The underlying activity (taking a course, completing compliance training, hitting sales targets) remains the same. Gamification adds motivational scaffolding around it.

Examples include:

A corporate LMS that awards badges for completing training modules
A fitness app that tracks streaks and provides achievement unlocks
A sales dashboard with team leaderboards and weekly challenges
An onboarding process that uses a progress bar and milestone rewards

Key Takeaway: A serious game IS a game with a non-entertainment purpose. Gamification ADDS game elements to something that is not a game. The distinction is not cosmetic - it fundamentally changes scope, budget, timeline, and expected outcomes.

When to Choose a Serious Game

Serious games are the right choice when the subject matter is complex enough that learning through doing is significantly more effective than learning through reading or watching. They excel in specific circumstances:

1. The Learning Requires Practice and Repetition

Some skills cannot be acquired through passive consumption. Language acquisition, for example, requires active recall, listening comprehension, and pattern recognition - all of which map naturally to game mechanics.

When we partnered with The Language Conservancy to build Vocab Builder, we designed 9 distinct mini-games, each targeting specific cognitive retention skills. Audio-matching games built listening comprehension. Drag-and-drop games reinforced orthography. Timed recall games strengthened active vocabulary. The learning was inseparable from the gameplay - you could not play the game without learning, and you could not learn without playing.

2. The Environment Is Too Dangerous or Expensive to Practise In

Flight simulators exist because crashing a real plane during training is not acceptable. Medical simulations exist because practising surgery on real patients carries real risk. Serious games create safe failure environments where learners can make mistakes, learn from them, and try again without real-world consequences.

3. The Audience Has Low Intrinsic Motivation

Children learning an endangered language may not inherently find vocabulary drills engaging. Corporate employees may not willingly complete compliance training. A serious game wraps the required content in an experience that generates its own motivation through challenge, curiosity, and progression.

During our team's previous tenure at fish in a bottle, we contributed to the development of Navigo - a tablet-based learning game for the EU Horizon 2020 iRead Project. The game supported children learning English, German, Spanish, or Greek as a first language. Building 15 unique mini-games within an explorable world with NPC interactions and character customisation transformed what could have been dry literacy exercises into an experience that children chose to return to. The project went on to receive an award from the Serious Games Society.

4. You Need Deep Engagement Over Extended Periods

If your training programme requires learners to engage repeatedly over weeks or months, a serious game's progression system, unlockable content, and increasing challenge can sustain engagement far longer than a points-and-badges layer on existing content.

When to Choose Gamification

Gamification is the right choice when the core activity is already defined and functional, and the goal is to increase engagement, completion rates, or behavioural frequency without rebuilding the underlying experience.

1. The Content Already Exists

If you have a library of training videos, a course curriculum, or an established onboarding workflow, gamification adds a motivational layer without requiring you to redesign the content. You are enhancing what is already there, not replacing it.

2. The Budget or Timeline Is Constrained

A serious game is a full software development project. It requires game design, art, audio, engineering, QA, and deployment - the same pipeline as a commercial game. Gamification can often be implemented as a feature set within an existing platform, at a fraction of the cost and timeline.

3. The Goal Is Behavioural, Not Skill-Based

Gamification is highly effective for encouraging specific behaviours: completing modules, logging in daily, hitting performance targets, or participating in team activities. These are motivational challenges, not skill acquisition challenges. Points, streaks, and leaderboards are well-suited to driving these behaviours.

4. You Need to Scale Across a Large Organisation

Rolling out a serious game to 50,000 employees across multiple departments requires significant infrastructure and support. Adding gamification elements (progress tracking, team challenges, achievement badges) to your existing LMS scales much more easily.

Key Takeaway: Choose a serious game when the learning requires active practice, safe failure, or deep engagement over time. Choose gamification when you need to boost participation and completion rates for content that already works.

The Hybrid Approach

In practice, the most effective educational and training solutions often combine both approaches. A serious game might use gamification elements (leaderboards, daily challenges, achievement systems) to drive retention. A gamified LMS might include mini-game modules for specific skill-based topics.

When we built the Vocab Builder suite for The Language Conservancy, the core experience was undeniably a serious game - 9 distinct mini-games, each with unique mechanics designed around specific learning objectives. But we also incorporated gamification elements: progress tracking across languages, score systems, and completion indicators that motivated learners to return and improve.

The distinction is not about choosing one or the other permanently. It is about understanding which approach serves each specific learning objective and allocating your budget accordingly.

Common Mistakes We See

Calling Gamification a "Game"

Adding a points system and leaderboard to your compliance training does not make it a game. If you market it as a game and the experience feels like a spreadsheet with a progress bar, learners will disengage faster than if you had presented the training honestly. Set expectations correctly.

Building a Serious Game When Gamification Would Suffice

Not every learning objective requires a full game. If your employees need to read and acknowledge a policy update, a gamified completion tracker with a team challenge is appropriate. Commissioning a 3D simulation for this use case is over-engineering the solution.

Underestimating Serious Game Scope

We regularly speak with organisations that want a "simple educational game" and expect it to take a few weeks. A well-designed serious game is a software product. It requires game design documentation, iterative prototyping, focus testing with the target audience, QA across devices, and ongoing maintenance. Budget and plan accordingly.

Ignoring the Subject Matter Experts

Both approaches require close collaboration with the people who understand the content. When we built Vocab Builder, we worked with The Language Conservancy's linguistic experts throughout the entire design process. They provided vocabulary databases, audio recordings, and cultural guidance. Our job was to translate their expertise into effective game mechanics - not to guess at the pedagogical requirements.

This is true for corporate training as well. Your compliance team, HR department, or training managers are the subject matter experts. The game development studio brings the technical and design expertise. Neither can produce an effective result alone.

The Decision Framework

When evaluating which approach to take, we walk clients through these questions:

Does the learning require active practice? If yes, lean toward a serious game. If it requires information consumption and acknowledgement, lean toward gamification.
What is the engagement duration? A one-time onboarding process may benefit from gamification. A multi-month skill development programme may require a serious game.
What is the budget? Serious games are full development projects. If the budget does not support game design, art, development, and QA, gamification within an existing platform may be the pragmatic choice.
Who is the audience? Young children and reluctant learners often need the immersive pull of a real game. Motivated professionals may respond well to lighter gamification.
Does the content already exist? If you have established training materials, gamification enhances them. If you are building a learning experience from scratch, a serious game gives you full control over how content is delivered.

How We Can Help

At Ocean View Games, we specialise in educational game development across the full spectrum - from lightweight gamification consulting to full serious game production. We work with educational institutions and corporate training departments to identify the right approach for each project, ensuring budget is spent where it will have the most impact on learning outcomes.

Whether you need a suite of mini-games to bring a language curriculum to life, a simulation to train employees in high-stakes decision making, or a gamification strategy for your existing LMS, we bring the same rigorous, pedagogy-led design process to every engagement.

The most important step is the first conversation. Get in touch and let us help you figure out what your learners actually need.

How Much Does Mobile Game Development Cost in 2026?

Ocean View Games — Sat, 13 Jun 2026 17:20:19 +0000

"How much will my game cost?" is the first question nearly every client asks us. And the honest answer is always the same: it depends. But that does not mean we cannot give you a clear framework for estimating costs before you commit a single pound of budget.

After shipping mobile games for over a decade - from hyper-casual titles that took weeks to build, to a full-scale MMORPG that has been in development for years - we have seen the full spectrum of mobile game budgets. This guide distils that experience into actionable cost ranges, explains the factors that push budgets up or down, and gives you a practical method for getting an accurate estimate for your specific project.

Cost Ranges by Game Type

The single biggest determinant of cost is the type of game you are building. Here is a realistic breakdown of what different categories of mobile games cost to develop in 2026, based on our direct experience and current UK market rates.

1. Hyper-Casual Games: GBP 10,000 - 50,000

Hyper-casual games are the simplest category: one core mechanic, minimal UI, short play sessions. Think tap-to-play puzzles, endless runners, and reaction games.

When we built What's That, our own hyper-casual title, the entire development cycle took roughly two months with a team of two. The game served as both a commercial release and a proving ground for our reusable game framework, which now allows us to kickstart new projects 30-50% faster.

At this price range, you are paying for:

A single, polished core mechanic
Basic UI (menus, settings, leaderboards)
Ad monetisation integration
App store submission for iOS and Android

2. Casual / Puzzle Games: GBP 50,000 - 150,000

Casual games add complexity: multiple levels, progression systems, polished art, and more sophisticated monetisation. Educational games also tend to fall into this bracket.

Our work for The Language Conservancy on Vocab Builder is a good example. We partnered with TLC to design and develop nine distinct mini-games, each targeting specific cognitive retention skills, with a scalable data pipeline that lets linguistic experts add new languages without code changes. The project required approximately six months with a team of three.

Budget drivers at this tier include:

Number of unique game modes or mini-games
Custom art and animation
Audio (music, sound effects, voiceover)
Backend integration for analytics or user progress tracking
Multi-language localisation

3. Mid-Core Games: GBP 150,000 - 500,000

Mid-core games are where complexity ramps up significantly. Strategy games, RPGs, and competitive multiplayer titles fall here. These projects typically require larger teams, longer timelines, and more sophisticated backend infrastructure.

Our internal title Empires Rise - a 4X turn-based strategy game for mobile - sits in this category. It involved procedural map generation using modified Perlin Noise, a utility-based AI system with coroutine time-slicing for mobile performance, and a modular architecture designed for cross-platform deployment. Development took roughly six months with a focused team, though a comparable client project with full art production and QA would sit at the higher end of this range.

4. MMOs and Large-Scale Multiplayer: GBP 500,000 - 3,000,000+

Massively multiplayer games are the most expensive category by a wide margin. The costs come not just from the game itself, but from the server infrastructure, networking architecture, and ongoing live operations required to keep the game running.

Our partnership with Domi Online is a clear illustration. We engineered the entire technical foundation for a "cap-less" MMORPG - including a custom 64-bit progression system, cost-optimised AWS infrastructure using FishNet networking, and GPU-instanced environments rendering 10,000+ trees with minimal draw calls. The vertical slice we built helped secure significant seed funding, and the project has been in active development since 2021 with a lean team of three full-stack developers.

Key Takeaway: The type of game you are building is the single biggest cost determinant. A hyper-casual game and an MMO are fundamentally different products - do not let anyone give you a single number without understanding which category your project falls into.

The 7 Factors That Drive Costs Up or Down

Within each game category, the actual cost varies enormously based on specific project requirements. Here are the seven factors we see most frequently influencing budgets.

1. Art Complexity and Volume

Art is often the single largest line item after programming. A 2D game with flat vector graphics costs a fraction of what a fully 3D game with custom character models, animations, and particle effects requires. If you need original art rather than Asset Store purchases, budget accordingly.

2. Multiplayer and Networking

Adding multiplayer to a game does not double the cost - it often triples it. Server-authoritative architecture, netcode, matchmaking systems, anti-cheat measures, and ongoing server costs all compound. During our founder's tenure at Jagex working on RuneScape Mobile, the networking and cross-platform parity challenges were among the most resource-intensive aspects of the entire project.

3. Platform Targets

Building for iOS and Android simultaneously using Unity is relatively straightforward - that is one of Unity's core strengths. But adding console targets (PlayStation, Xbox, Nintendo Switch) introduces certification requirements, controller remapping, and platform-specific optimisation passes that can add 20-40% to total costs. See our console porting services for details on what that involves.

4. Monetisation Complexity

A simple banner ad integration costs very little. But a full free-to-play economy with in-app purchases, virtual currencies, server-side receipt validation, A/B-tested pricing, and subscription models requires significant backend engineering. We built and integrated monetisation systems for Pocket Factory alongside core gameplay, and the revenue engineering was a substantial part of the overall scope.

5. Backend and Live Services

Any game that requires user accounts, cloud saves, leaderboards, or analytics needs a backend. Firebase, PlayFab, or a custom server solution each have different cost profiles. Games that need ongoing live operations - seasonal events, content updates, server maintenance - should budget for post-launch costs from the start.

6. Team Location and Structure

UK-based studios (like us) typically charge GBP 400-800 per developer per day, depending on seniority. Eastern European studios may charge 40-60% less, while US studios often charge more. The cheapest option is not always the best value - we have been hired multiple times to rescue projects that went wrong with an underqualified offshore team.

7. Scope Creep

The silent budget killer. Every "quick addition" and "small tweak" during development costs money. A clear, detailed Game Design Document (GDD) agreed before production begins is the best insurance against scope creep. Our game design services exist specifically to help clients define scope before committing to full development budgets.

Key Takeaway: Multiplayer, custom art, and scope creep are the three factors that most commonly cause budgets to exceed initial estimates. Be honest about your requirements upfront, and you will get a far more accurate quote.

How to Get an Accurate Estimate

Generic cost articles can only take you so far. Here is how to get a number that actually applies to your specific project.

Step 1: Define Your Scope

Before approaching any studio, document:

Your core gameplay mechanic
Target platforms (iOS, Android, both, console)
Art style and complexity
Multiplayer requirements (if any)
Monetisation model
Must-have features vs. nice-to-haves

Even a rough Game Design Document significantly improves the accuracy of any estimate you receive.

Step 2: Use a Cost Estimator

We built a free Game Development Cost Estimator that lets you input your project parameters and receive an indicative cost range. It is based on our real-world project data and current market rates. While no automated tool replaces a proper scoping conversation, it gives you a solid starting point.

You can also explore our detailed Game Development Cost Guide for a deeper breakdown of cost factors.

Step 3: Get Multiple Quotes

Always speak to at least two or three studios. Compare not just price, but:

Relevant portfolio work (have they built something similar?)
Communication quality during the quoting process
Whether they ask detailed technical questions or just give a flat rate
Post-launch support and maintenance terms

Step 4: Budget for the Unexpected

Add a contingency of 15-20% to whatever estimate you receive. This is not pessimism - it is standard project management practice. Platform requirement changes, device fragmentation issues, and store policy updates all introduce costs that are difficult to predict.

What You Are Actually Paying For

One important perspective shift: the cost of game development is not just "programming hours." A well-structured project includes:

Pre-Production (10-15% of budget): Game design documentation, market research, prototyping, technical architecture planning
Production (50-60% of budget): Programming, art creation, audio design, level design, integration
QA and Polish (15-20% of budget): Testing across devices, bug fixing, performance optimisation, accessibility improvements
Launch and Post-Launch (10-15% of budget): Store submission, ASO, initial marketing, post-launch patches, analytics integration

Studios that skip pre-production or QA may offer lower quotes, but those savings are typically eaten by rework costs and delayed launches.

The Bottom Line

Mobile game development in 2026 ranges from GBP 10,000 for the simplest hyper-casual titles to GBP 3,000,000+ for ambitious multiplayer experiences. The exact cost depends on your game type, art requirements, technical complexity, and team structure.

The best thing you can do before committing budget is to define your scope clearly and talk to studios that have built something similar. We have worked across the full spectrum - from two-month hyper-casual builds to multi-year MMORPG partnerships - and we are always happy to discuss where your project fits.

Unity vs Godot vs Unreal for Beginners (2026): Which Engine Should You Start With?

Ocean View Games — Thu, 04 Jun 2026 21:55:27 +0000

If you have never written a line of game code and you are trying to choose between Unity, Godot, and Unreal, the internet will give you fifty contradictory answers in your first hour of searching. This article is the answer we give to people who ask us in person.

We are a Unity-specialist studio. I have spent 12 years building games, including a tenure as Mobile Team on RuneScape Mobile at Jagex. Over that time I have mentored a steady stream of new developers entering the industry. We picked Unity for our commercial work, deliberately, and we will say upfront where that lens does and does not serve you. The advice below is what I would tell a friend's teenager who asked which engine to learn first, not the version where I am trying to win you as a client.

Three things drive whether a beginner finishes their first game or quietly abandons it: the engine's first-week friction, the quality of the free learning material, and whether the language and tools punish you or reward you when you make a mistake. Comparison articles obsess over feature lists. Beginners obsess over whether they can get something on screen by Saturday. We are going to talk about Saturday.

The 30-Second Answer

If you skim nothing else, take this:

Pick Godot if you want the gentlest first week. The editor is small, the language reads like Python, and you can ship a 2D game to the web in a single afternoon. Best chance of you actually finishing a project.
Pick Unity if you want a future career in the games industry. Largest tutorial library, biggest job market, most transferable skills. C# is harder than GDScript but every hour you spend on it pays back in the long run.
Pick Unreal if you have always wanted to make games specifically because of the visuals. Blueprints let you avoid C++ at the start, the rendering looks beautiful from day one, and the long learning curve has the highest payoff if you commit.

For the rest of the article, we will explain why each of those is true, where the engines genuinely differ for new developers, and how to choose between them based on what you actually want to build.

What "Easy to Learn" Actually Means

Most beginner articles claim their preferred engine is "easy to learn" and move on. That phrase hides four very different things, and only one of them is the engine itself.

Editor weight. How long does the editor take to open? How much disk space does it use? Does it run on a five-year-old laptop? Godot opens in two or three seconds and weighs around 120 MB. Unity is closer to 30 to 60 seconds depending on your project, and the install with one platform module is several gigabytes. Unreal is the heaviest of the three: long startup, large disk footprint, and it assumes a powerful PC.

Language difficulty. GDScript is the easiest of the three. It looks like Python, it is dynamically typed by default, and the error messages are usually understandable. C# (Unity) is harder but extremely well-supported by tooling: IDE autocomplete, type checking, and a vast amount of professional documentation. C++ (Unreal) is the hardest, with compile times that punish small mistakes.

Free tutorial availability. Unity has more tutorials than the other two combined. Brackeys remains the de facto starting point for thousands of beginners. Godot has a strong and growing tutorial ecosystem and very high-quality official documentation. Unreal has Epic's official tutorials and a sizable community, but the "your first game" path is longer.

Time to your first runnable thing on screen. This is the variable that actually predicts whether someone sticks with the engine. In Godot, you can have a moving sprite in 15 minutes. In Unity, 30 to 60 minutes. In Unreal, 60 to 120 minutes for a comparable result. Those minutes matter when motivation is the scarcest resource.

The engine that gives you the best chance of finishing your first project is the one whose first 10 hours feel rewarding rather than frustrating. We will look at each engine through that lens.

Godot for Beginners

Godot is the engine I would recommend to a friend who has never coded before and just wants to make a game. Here is why.

The editor opens in seconds. Godot's full editor download is around 120 MB. There is no install wizard, no version manager, no licence agreement to scroll through. You unzip the executable, double-click it, and you are in. For someone who has not committed to game development as a serious pursuit, this lower friction matters enormously.

GDScript reads like Python. Variables, functions, indentation-based scope. If you have ever touched Python or had a friend explain Python to you, GDScript will feel familiar. Godot 4.x also supports C# through .NET, so if you know C# already, you are not locked into GDScript.

The scene and node system is intuitive. Godot's core concept is simple: everything in your game is a "scene", and scenes contain "nodes". A character is a scene with a sprite node, a collision node, and a script node. A level is a scene that includes the character scene. This compositional approach clicks for most beginners faster than Unity's GameObject and Component model.

Free MIT licence with no scary thresholds. Godot is MIT-licensed: no fees, no royalties, no usage tracking, no terms that can change later. For a beginner, the absence of "what happens when I earn money?" anxiety is a real benefit.

Excellent web exports. A 2D Godot game can ship to a web browser in three clicks. You can share a link to your first game with friends within a week of starting.

Limitations to know about. The tutorial library is smaller than Unity's, though it is growing fast. The asset ecosystem (the Godot AssetLib) is smaller than the Unity Asset Store, so pre-made systems and templates are scarcer. The job market signal of "I can use Godot" is weaker than "I can use Unity" if your goal is a games-industry career. Console deployment requires third-party publishers (no first-party PlayStation, Xbox, or Switch support).

For a hobbyist building 2D mobile or web games, none of those limitations matter much. For a career-builder, they start to add up.

Unity for Beginners

If your endgame is "I want a job in the games industry", Unity is the right place to start. Here is why.

The largest tutorial library on the internet. YouTube is full of free Unity tutorials, ranging from 30-second tip videos to full multi-hour courses. Brackeys is the canonical starting point. Code Monkey, Sebastian Lague, and many others publish high-quality Unity content. If you get stuck, someone has almost certainly hit the same problem and posted a solution.

C# is the right language to learn for a games career. Unity uses C# for all gameplay scripting. C# is a strongly-typed, modern language that maps directly to professional software engineering practice. Concepts you learn in C# (object-oriented design, interfaces, generics, async programming) transfer directly to Unreal C++, web development, and enterprise software. GDScript skills do not transfer the same way.

The Asset Store accelerates your first projects. Need an inventory system? A character controller? A dialogue system? The Unity Asset Store has hundreds of options at every price point including free. As a beginner, this means you can buy or download a £20 pre-built system and skip three weeks of pain on a problem that is not what you actually want to be working on.

Free up to a revenue threshold. Unity Personal is free for studios earning under $200,000 per year. For any beginner, this is effectively free forever. Unity Pro is a per-seat subscription only relevant once your project earns real money.

The biggest mobile market share. Most of the top mobile games are built in Unity. If your goal is to ship a mobile game, Unity is where the road has been paved.

Limitations to know about. The editor is heavier than Godot's. The first-week friction is higher: Unity Hub, version selection, project templates, render pipeline choice, all decisions before you have written any code. Unity has a history of multiple "ways to do the same thing" (Input Manager vs the new Input System, Built-in Render Pipeline vs URP vs HDRP), which can confuse beginners following older tutorials. The 2023 Runtime Fee episode also damaged trust with parts of the indie community, though Unity walked back the changes.

For a beginner who can push through the higher first-week friction, Unity rewards the investment with the largest learning ecosystem and the best long-term career outcome.

Unreal for Beginners

Unreal is the engine I would recommend to a beginner who has been dreaming about making a 3D game with cinematic visuals since they were a teenager. Less so for someone who wants to ship something this month.

Blueprints let beginners avoid C++ initially. Unreal's Blueprint visual scripting system is genuinely powerful. Entire commercial games have shipped using only Blueprints. For a beginner who is intimidated by code, Blueprints provide a way in. You can build playable prototypes by connecting nodes on a graph, and the visual feedback when a connection is wrong is often clearer than a compile error.

The visual results are rewarding from day one. Unreal's default lighting, materials, and post-processing produce visuals that look impressive almost immediately. For a beginner whose motivation comes from seeing pretty things on screen, this is a powerful loop. Lumen and Nanite (the headline rendering features) work out of the box on a powerful PC.

Free with a 5% royalty above $1M revenue. For any beginner, this is effectively free. The royalty only kicks in if your game earns over $1 million, which is a problem to be glad you have.

Limitations to know about. The editor is heavy. Unreal assumes you have a powerful PC with a recent GPU. Compile times for C++ are long, often 15 to 60 seconds for incremental changes, sometimes much longer. Blueprint graphs become unwieldy as projects grow, and you will eventually need C++ for serious work. The learning curve is the steepest of the three engines: there is more terminology, more boilerplate, and more "you just have to know" tribal knowledge before you can do something simple.

For a beginner who is patient, has a powerful PC, and is specifically motivated by visual fidelity, Unreal is rewarding. For everyone else, it is overkill.

Side-by-Side Comparison for Beginners

Where the three engines actually differ for new developers, in one place:

Factor	Unity	Godot	Unreal
Editor download size	Several GB (with one platform module)	~120 MB	~30 GB+ (Engine + symbols)
Time to first runnable scene	30-60 minutes	10-20 minutes	60-120 minutes
Primary scripting language	C# (strongly typed)	GDScript (Python-like)	C++ (steep) + Blueprints (visual)
Free tutorial volume	Largest	Strong, growing	Good
Job market relevance	Highest	Growing, currently lower	Strong (AAA studios)
Editor hardware requirements	Mid-range laptop OK	Any modern laptop	Powerful PC recommended
Mobile support	Best in class	Good (2D especially)	Possible, not a strength
2D support	Strong (Tilemap, URP 2D)	Best in class	Effectively non-existent
3D support	Strong (URP, HDRP)	Improving, behind Unity	Industry-leading
Best first project type	Mobile hyper-casual, 2D puzzle, simple 3D	2D platformer, top-down RPG, visual novel	3D walking simulator, simple stealth game

Realistic First-Project Recommendations

The biggest mistake a beginner makes is choosing too ambitious a first project. Match the project to the engine.

Godot first projects that work. A 2D platformer with three or four levels. A top-down 2D RPG with simple combat. A visual novel with branching dialogue. A simple endless runner. All of these can be completed in 20 to 40 hours of work, ship to the web, and give you a finished game to point at.

Unity first projects that work. A mobile hyper-casual game (tap to jump, swipe to dodge). A 2D puzzle game with 20 to 50 levels. A simple third-person 3D collectathon (move around, pick things up, win). A small endless runner. The Asset Store can supply a character controller and basic enemies, so you can focus on the part you actually want to learn.

Unreal first projects that work. A 3D first-person walking simulator. A simple stealth game where you sneak past two enemies. A short narrative experience with two scenes. Avoid anything mechanically ambitious for a first Unreal project; you will spend more time fighting the engine than building gameplay.

What does not work as a first project in any engine: an MMORPG, an RTS, anything with multiplayer, anything with procedural generation, anything that requires more than two people. Start small. Finish something. Then decide what to build next.

The Honest Answer for Two Beginner Archetypes

Most beginners I have mentored fall into one of two camps. Here is the recommendation for each.

Archetype 1: "I just want to make a game and ship it."

You are the hobbyist. You have a small idea. You want to feel the satisfaction of finishing something and putting it in front of friends. You may or may not turn this into a career.

Choose Godot. Lower friction means a higher chance of finishing. The editor opens in seconds, GDScript is forgiving, and you can ship to the web in an afternoon. The job-market downside does not matter for you because you are not job-hunting. The smaller asset ecosystem does not matter because your first game is not buying assets. Pick Godot, finish a small 2D game, and decide what you want to do next based on whether you enjoyed the experience.

Archetype 2: "I want a career in games."

You are the career-builder. You see a future where you work at a game studio, or run your own. The first engine you learn is the one you will use to apply for jobs and build a portfolio.

Choose Unity. Largest job market, most transferable concepts, best long-term ROI on every hour you put in. The Asset Store accelerates your portfolio projects. C# is what professional studios actually use. The first week is harder than Godot, but the next ten years are easier. If you decide later you want to specialise in AAA, you can pick up Unreal in 6 to 12 months because the underlying concepts (game loops, components, materials, animation) transfer. Starting in Godot and trying to switch to Unity later means rewriting your habits in the harder language anyway.

If you are torn between the two camps, default to Unity. The cost of starting with Unity and discovering you are a hobbyist is low. The cost of starting with Godot and discovering you wanted a career is twelve more months of learning the engine the industry actually uses.

Frequently Asked Questions

Is Godot easier than Unity?

For the first week, yes. The editor is lighter, GDScript is more forgiving, and there is less ceremony before you can write code. For long-term skill development and career outcomes, Unity has more depth and more transferable skills.

What is the easiest game engine to learn in 2026?

Godot, for most beginners. The combination of a small editor, a Python-like scripting language, and an intuitive scene system gives the gentlest first-week experience.

Should beginners learn C# or GDScript?

If you want a career in games or in software engineering generally, learn C#. It transfers everywhere. If you want to ship a hobby game and have fun, GDScript is fine and can be learned in days rather than weeks.

Is Unreal too hard for beginners?

It is the hardest of the three to start with, but not impossible. Blueprints make a lot of game development accessible to non-coders. The bigger issue is editor weight: Unreal assumes a powerful PC. If your laptop is five years old, Unreal will feel sluggish in a way Unity and Godot will not.

Can I make money with Godot?

Yes. Godot is MIT-licensed: no fees, no royalties, no revenue caps. Several commercial games have shipped on Godot. Console support requires a third-party publisher, which is the main commercial limitation.

How long does it take to learn Unity?

To build a finished simple game, 50 to 100 hours of focused practice. To be employable as a junior Unity developer, 500 to 1,000 hours of building real projects. To be senior, several years of professional work. Numbers vary widely by individual and prior coding experience.

Should I learn an engine or pick one project and start?

Pick a project and start. Beginners who try to "learn the engine first" and watch tutorials without building anything almost always quit. The right approach is: pick a small first project, watch the tutorials you need to make that specific project, ship it, then pick the next project.

Closing CTA

If you are still weighing the choice and want a wider view, our 3-engine comparison hub covers the full picture across all use cases, not just beginners. If you have decided on Unity and want to understand why we use it for everything from indie mobile to MMO scale, read why we picked Unity. And if you want a ballpark on what your first commercial project might cost, our game development cost estimator gives you a starting figure in two minutes.

The most important thing, more than which engine you choose, is that you pick one and ship something. Three months of building anything in any engine teaches you more than three years of comparing engines.

DEV Community: Ocean View Games

SCORM vs Custom API: Integrating Games with Learning Management Systems

What Problem Are We Solving?

SCORM: The Established Standard

SCORM 1.2

SCORM 2004 (Editions 1-4)

xAPI (Tin Can API): The Modern Alternative

Custom API: The Flexible Alternative

Architecture Overview

What Your Backend Handles

Strengths of a Custom API

Limitations of a Custom API

Decision Framework: Which Approach Should You Use?

1. What platforms will the game run on?

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

3. How many LMS platforms must you support?

4. What is your maintenance budget?

Integration Approach Comparison

The Hybrid Approach

Implementation Tips for Unity Developers

SCORM from a Unity WebGL Build

Custom API from a Unity Native Build

Compliance and Privacy

Choosing the Right Path

Related Reading

How Long Does Game Development Take? A Realistic Timeline

Timelines by Game Type

Hyper-Casual Games: 1-3 Months

Casual and Educational Games: 3-6 Months

Mid-Core Games: 6-12 Months

Multiplayer and MMO Games: 12-36+ Months

The Four Phases of Game Development

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

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

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

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

The 6 Most Common Causes of Delays

1. Undefined or Changing Scope

2. Art and Asset Dependencies

3. Multiplayer and Networking Complexity

4. Platform-Specific Issues

5. Store Submission Rejections

6. Stakeholder Feedback Cycles

How to Plan a Realistic Timeline

Step 1: Classify Your Project

Step 2: Add Contingency

Step 3: Work Backwards from Your Launch Date

Step 4: Use a Timeline Estimator

Step 5: Milestone, Do Not Waterfall

A Note on Team Size and Timeline

The Bottom Line

Related Reading

GPU Instancing for Dense Game Worlds in Unity

Understanding the Draw Call Problem

What Happens During a Draw Call

The Naive Approach Fails Fast

Solution 1: The SRP Batcher

How It Works

When to Use It

Limitations

Solution 2: GPU Instancing

How GPU Instancing Works in Unity

Per-Instance Properties

Performance Gains

Solution 3: The Interactive Object Swap Pattern

The Swap Pattern

Why This Works

Solution 4: LOD Strategies for Mobile

Distance-Based LOD Groups

LOD and Instancing Together

Mobile-Specific LOD Considerations

Putting It All Together: The Full Pipeline

Rendering Pipeline (Per Frame)

Results

Common Pitfalls

1. Forgetting MaterialPropertyBlock Limits

2. Shadow Casting with Instanced Objects

3. Physics Colliders on Instanced Objects

4. Dynamic Batching Conflicts

When GPU Instancing Is Not the Right Solution