DEV Community: Ocean View Games

Working With a Game Dev Agency: What to Expect

Ocean View Games — Tue, 14 Apr 2026 22:21:51 +0000

If you are a founder, publisher, or product owner about to hire a game development agency for the first time, you probably have questions. How does the process actually work? What should you expect at each stage? How do you know whether an agency is the right fit?

These are fair questions. Most people commissioning game development have deep expertise in their own domain, whether that is education, entertainment, or publishing, but have never navigated an external game dev engagement before. The process can feel opaque if nobody walks you through it.

This guide covers what a typical engagement looks like from first contact through to launch and beyond. I have tried to be honest about what good looks like and where things commonly go wrong.

If you have not written your brief yet, start with our guide to writing a game development brief. And if you are still at the stage of figuring out whether outsourcing is right for you, our post on questions to ask before starting is a useful starting point.

Discovery and Scoping

The discovery phase is where a good agency earns its keep. Before anyone writes a line of code, both sides need a shared understanding of what is being built, who it is for, and what success looks like.

What a good discovery phase includes

A structured discovery phase typically covers:

Understanding your goals. Not just "build a game" but the commercial or educational objectives behind it. Are you targeting a specific audience? Is there a revenue model? Are there platform constraints?
Technical feasibility. Can the thing you want actually be built within your budget and timeline? A good agency will tell you early if something needs to be descoped or rethought.
Reference gathering. Looking at comparable products, identifying the features and mechanics that matter most, and establishing a shared visual and design language.
Risk identification. What are the unknowns? Where might scope creep happen? What third-party dependencies exist?

At Ocean View Games, we use this phase to produce a detailed brief that both sides sign off on. If you already have a brief, our game development brief builder can help you structure it in a way that makes scoping faster and more accurate.

Red flags at this stage

Be cautious if an agency skips discovery entirely and jumps straight to quoting. Without a proper scoping phase, estimates are guesswork. A quote without understanding is just a number.

Other warning signs include an agency that does not ask about your target audience, does not raise technical risks, or agrees to everything without pushback. A good partner challenges your assumptions constructively. That is what you are paying for.

Discovery typically takes one to three weeks depending on project complexity. It might feel like a slow start, but it consistently saves time and money further down the line. In our experience, a thorough discovery phase can prevent 20 to 30 percent of the budget overruns that plague projects where teams dive straight into production.

Proposal and Agreement

Once discovery is complete, the agency should present a formal proposal. This is the document you will refer back to throughout the project, so it needs to be clear and comprehensive.

What a proposal should include

At minimum, a good proposal covers:

Scope of work. A detailed breakdown of features, screens, and deliverables. Vague descriptions like "a mobile game" are not sufficient. You need specifics.
Milestone schedule. The project broken into phases with dates and deliverables for each. This gives both sides checkpoints to assess progress.
Budget and payment terms. Whether fixed price or time-and-materials, the commercial model should be transparent.
IP ownership. Who owns the code, art assets, and game design when the project is complete? This must be explicitly stated. In most client-agency arrangements, IP transfers to the client on payment, but never assume this.
Change request process. How will scope changes be handled? What is the approval process and how does it affect budget and timeline?

Fixed price vs time-and-materials

Fixed price works well when the scope is clearly defined and unlikely to change. You know what you are paying upfront, and the agency carries the risk of overruns. The trade-off is less flexibility. Changes mid-project require formal change requests that adjust the budget.

Time-and-materials suits projects where requirements are expected to evolve. You pay for actual hours worked, usually against a capped budget with regular reporting. This gives you more flexibility to iterate but requires trust and strong project management on both sides.

Many engagements use a hybrid approach: fixed price for well-defined phases and time-and-materials for exploratory work like prototyping or R&D.

Production

This is where the game gets built. Production is typically the longest phase and the one where communication matters most.

Sprint cadence and milestone structure

Most agencies, including Ocean View Games, work in sprints. These are typically one or two week cycles where the team commits to a set of tasks, builds them, and delivers a working increment.

Sprints sit within a broader milestone structure. A typical mobile game project might have milestones like:

Prototype. Core mechanic working in a rough state. Enough to validate the concept.
Vertical slice. One complete section of the game at near-final quality. This proves the art style, UI, and core loop work together.
Alpha. All features implemented, though not all polished. The game is playable from start to finish.
Beta. Feature complete with polish applied. Ready for focused testing.
Release candidate. Final version pending approval.

Each milestone should have clear acceptance criteria agreed in advance. There should be no ambiguity about what "done" means at each stage.

Communication rhythm

During production, you should expect regular, structured communication. At Ocean View Games, a typical rhythm looks like:

Weekly builds. A playable build delivered every week or every two weeks, depending on sprint length. You should be able to pick up the game and see tangible progress.
Sprint reviews. A short meeting at the end of each sprint to demonstrate what was built, discuss what is next, and flag any blockers.
Milestone reviews. Longer sessions at major milestones where we review the build against the agreed criteria, gather feedback, and plan the next phase.
Ad hoc communication. Slack, Teams, or email for day-to-day questions. A good agency is responsive without requiring you to chase them.

If your agency only shows you work at major milestone gates, problems can compound silently between reviews. Regular builds keep everyone aligned and give you the opportunity to course correct early.

Handling scope changes mid-project

Scope changes happen on virtually every project. A stakeholder has a new idea. User testing reveals an issue. A platform requirement changes. This is normal.

What matters is how changes are managed. A good agency will:

Assess the impact on timeline and budget before committing to any change.
Present options, such as adding the feature and extending the timeline, swapping it for something of equivalent size, or deferring it to a post-launch update.
Document every change formally so there is a clear record of what was agreed.

The worst outcome is informal scope creep where new requests are absorbed without adjusting expectations. This leads to missed deadlines, budget overruns, and frustration on both sides.

As someone who has worked on large productions at Rockstar and Sumo Digital, I can tell you that even AAA studios struggle with scope management. The difference is not whether changes happen but whether you have a process to handle them.

QA and Polish

Quality assurance is not something you bolt on at the end. It runs parallel to production from the very first playable build.

Why QA matters throughout production

Testing during development catches bugs when they are cheapest to fix. A bug found during a sprint takes minutes to address. The same bug found during final certification can take days, because it is buried under weeks of additional work.

Effective QA during production includes:

QA type	Purpose
Functional testing	After each sprint to verify new features work as intended.
Regression testing	To ensure new work has not broken existing features.
Device testing	Across target hardware, which is particularly important for mobile where the device landscape is enormous.
Performance profiling	To catch frame rate issues, memory leaks, and loading times before they become systemic.

At Ocean View Games, our QA testing services are integrated into every project from the start, not offered as an optional extra. We test on real devices across the range of hardware our clients' players actually use.

The polish phase

The final weeks before launch focus on polish: tightening animations, refining UI transitions, tuning difficulty curves, and fixing the long tail of minor bugs that individually seem trivial but collectively define the player's experience. This phase is often underestimated in project planning. Budget for it explicitly.

Launch and Beyond

Shipping the game is not the end of the engagement. The launch process itself requires careful planning, and post-launch support is where many products find their footing.

App Store submission and soft launch

If you are launching on mobile, App Store and Google Play submission involves review processes that can take days. A good agency handles:

Store listing preparation. Screenshots, descriptions, keywords, and metadata optimised for discoverability.
Compliance review. Ensuring the build meets platform guidelines around privacy, age ratings, and content policies.
Soft launch. Releasing in a limited market to gather real player data before a full global launch. This is standard practice for mobile games and catches issues that internal testing cannot.

Our app store launch services cover the full submission and optimisation process, so you are not navigating platform requirements alone.

Post-launch support

After launch, expect a period of active support. Players will find bugs your QA team did not. Analytics will reveal drop-off points in your onboarding flow. Store reviews will surface usability issues.

A good agency provides a defined post-launch support period, typically four to twelve weeks, with a clear process for triaging and fixing issues. Beyond that, many clients move to a retainer arrangement for ongoing updates, seasonal content, or feature additions.

Plan for post-launch work from the start. The first version of your game is rarely the final one.

How to Choose the Right Agency

Not every agency is the right fit for every project. Here is what to look for when evaluating potential partners.

Relevant experience

Ask to see work that is comparable to what you need. If you are building a mobile educational game, an agency whose portfolio is entirely PC shooters may not be the best match, regardless of their technical skill.

Look at their case studies in detail. Do they explain the technical challenges they solved, or just show pretty screenshots? The depth of their case studies tells you a lot about how they think about problems.

Technical alignment

If your project requires Unity expertise, work with a team that specialises in Unity. If you need multiplayer networking, check whether they have shipped multiplayer titles before. At Ocean View Games, our core team has deep Unity experience across mobile, educational, and live service projects. You can see the full range of our game development services to understand where our strengths sit.

Communication and culture

You will be working with this team for months. Pay attention to how they communicate during the sales process, because that is often the best communication you will ever get. If they are slow to respond, vague in their answers, or dismissive of your questions before the project starts, it will only get worse under production pressure.

References

Ask for references from previous clients, ideally ones with a similar project profile to yours. A good agency will be happy to connect you.

Conclusion

Working with a game development agency does not need to be a leap of faith. When the process is structured, with clear discovery, honest proposals, regular communication during production, and integrated QA, the engagement becomes predictable and productive.

The key is knowing what to expect at each stage and being willing to invest in the early phases that make everything downstream smoother. If you are considering a game development project and want to understand how we would approach it, get in touch. We are always happy to have an initial conversation with no obligation.

Adam Kaye is a senior developer at Ocean View Games, a London-based game development agency. Before joining OVG, Adam worked at Rockstar, Sumo Digital, Square Enix, BBC, and Nickelodeon.

Mobile Game Porting Guide: PC to Mobile in Unity

Ocean View Games — Mon, 06 Apr 2026 12:00:12 +0000

Porting a PC or console game to mobile is one of the most technically demanding challenges in game development. It is not a simple rebuild. Every assumption your game makes about input, screen size, processing power, memory, and player session length needs to be reconsidered. Teams that treat a mobile port as a "downscale and ship" exercise end up with a product that feels awkward, runs poorly, and haemorrhages players within the first week.

I led the mobile porting effort for RuneScape Mobile at Jagex between 2017 and 2019, adapting a 20-year-old Java-based MMO with a complex UI and deep systems to run on phones and tablets. Since founding Ocean View Games, our team has continued porting Unity titles across genres and complexity levels. The lessons from those projects inform everything in this guide.

Before starting a port, assess whether your game is ready. Our porting feasibility guide covers that assessment in detail. This post picks up where that guide leaves off, walking through the practical work of actually executing a mobile port in Unity.

Input Remapping and UI Adaptation

Input is where most ports succeed or fail. A PC game designed around mouse precision and keyboard shortcuts cannot simply have virtual buttons overlaid on the screen. The entire interaction model needs rethinking.

Touch Controls vs Traditional Input

A mouse cursor provides hover states, right-click context menus, and pixel-level precision. A finger on a touchscreen provides none of these. The gap between these input paradigms is larger than most teams expect, and closing it requires genuine design work rather than surface-level adaptation.

RuneScape Mobile is a good example of the scale of this challenge. The desktop game had evolved over 20 years with an interface built around right-click context menus, small inventory icons, a minimap, and dozens of on-screen buttons. None of that translated to touch. The mobile team had to rebuild the entire interaction model: replacing right-click menus with long-press radial menus, enlarging interactive elements, collapsing multiple toolbars into tabbed panels, and rethinking how players navigate a vast 3D world with two thumbs instead of a keyboard and mouse. It was not a reskin. It was a fundamental redesign of how players interact with the game.

XCOM 2 Collection on iPad faced a different but equally instructive challenge. The desktop game relies on precise cursor placement for unit selection, targeting, and camera control. The iPad port replaced mouse hover with tap-to-select, added a dedicated camera rotation gesture, and enlarged the targeting reticle so that finger-based aiming felt deliberate rather than clumsy. The result worked because the team treated touch as a first-class input method rather than a fallback.

Haptic feedback is an often overlooked tool for improving touch controls. Modern iOS devices support the Core Haptics API, and Android provides the VibrationEffect system for fine-grained vibration patterns. Short, crisp haptic pulses on button presses, successful attacks, or UI confirmations give players tactile feedback that compensates for the lack of physical buttons. Used well, haptics make touch controls feel more responsive and satisfying. Used poorly (constant vibration, heavy rumbles), they drain battery and annoy players.

Screen real estate is the biggest constraint. A 6-inch phone display has roughly 15% of the usable area of a 24-inch monitor. UI elements that worked at desktop scale become illegible or untappable at mobile scale. The general rule is that any interactive element needs a minimum touch target of 44x44 points (Apple's Human Interface Guidelines) or 48x48 dp (Material Design). That eliminates most desktop-style toolbars and nested menus.

Practical Approaches

Contextual controls work best for complex games. Rather than showing every action at once, surface controls based on what the player is doing. RuneScape Mobile used this approach extensively, showing combat abilities only during combat and skilling interfaces only when interacting with relevant objects.

Virtual joysticks are appropriate for action games with direct character movement. They work poorly for strategy, simulation, or menu-heavy games. Gesture recognition (pinch-to-zoom, swipe-to-rotate) supplements touch controls well but should never be the only input method for critical actions. Players need visual affordances showing them what gestures are available.

Sometimes the right answer is to simplify mechanics. Albion Online removed some mouse-driven inventory management when porting to mobile, replacing drag-and-drop with tap-based interactions. Dead Cells adapted its fast-paced combat with customisable virtual button layouts, giving players control over where buttons sit on screen. These are design decisions, not just technical ones, and they need to happen early in the porting process.

Performance and Thermal Management

Mobile hardware is powerful but thermally constrained. A modern flagship phone has a GPU comparable to a mid-range laptop, but it sits inside a thin metal or glass shell with no active cooling. After 10 to 15 minutes of sustained load, the device's thermal management system kicks in and throttles the CPU and GPU, sometimes by 40% to 60%. A game that runs at 60fps in the first five minutes and drops to 25fps after fifteen minutes has a thermal problem, not a performance problem.

Profiling Workflow

Effective profiling requires testing on real devices in realistic conditions. The Unity Profiler provides frame timing, memory allocation, and rendering statistics. For iOS, Xcode Instruments offers Metal System Trace for GPU profiling and the Allocations instrument for memory tracking. On Android, the Android GPU Inspector gives detailed render stage breakdowns and counter data.

Profile on mid-range devices, not flagships. A Samsung Galaxy A54 or Pixel 7a represents what most of your players will actually use. Profile in a warm environment. A device sitting on a desk in an air-conditioned office will throttle later than one in a player's hands on a summer commute. Run profiling sessions for at least 20 minutes to capture thermal throttle behaviour.

Common Optimisations

Draw call batching is often the single biggest performance win. Mobile GPUs handle fewer draw calls efficiently than desktop GPUs. Use Unity's SRP Batcher with URP, enable GPU instancing for repeated objects, and merge static geometry where possible. Aim for under 200 draw calls on low-tier devices.

Texture compression with ASTC (Adaptive Scalable Texture Compression) gives the best quality-to-size ratio on modern mobile hardware. ASTC is supported on all iOS devices from the A8 chip onward and on most Android devices shipping since 2015. The block size you choose determines the trade-off between visual quality and memory usage. ASTC 4x4 delivers the highest quality at roughly 8 bits per pixel, making it the right choice for UI elements, normal maps, and any texture where compression artefacts would be noticeable. ASTC 6x6 at approximately 3.6 bits per pixel is the sensible default for most game textures, offering a good balance of quality and size. ASTC 8x8 at around 2 bits per pixel is aggressive compression best suited to large background textures, skyboxes, and terrain where fine detail is less critical. Getting the block size right across your asset library can reduce total texture memory by 40% to 60% compared to uncompressed or poorly configured formats.

LOD management (Level of Detail) is essential. Desktop games often render high-poly models at distances where mobile screens cannot display the detail anyway. Aggressive LOD switching, dropping to 25% triangle count at medium distance, saves substantial GPU time without visible quality loss on a small screen.

Shader simplification often means replacing desktop shaders with mobile-specific variants. Standard PBR with multiple texture maps can be replaced with simplified lit shaders using fewer samplers. Baked lighting reduces runtime cost significantly for static environments. Shader variant stripping is another important step that teams frequently overlook. Unity compiles shader variants for every possible keyword combination, and a complex shader can generate thousands of variants, most of which your project will never use. Use Unity's shader variant stripping callbacks or the Shader Variant Collection tool to identify and exclude unused variants. This reduces build size, speeds up load times, and lowers runtime memory consumption.

Memory Budgets by Device Tier

Realistic memory budgets vary significantly across the device spectrum, and the numbers are tighter than many PC developers expect. The operating system, background services, and system processes all consume RAM before your game gets any of it.

Device tier	Memory budget
Low tier Android (2GB RAM total)	The OS and background services consume roughly 1.2GB, leaving approximately 800MB for your application. In practice, staying under 600MB to 700MB is safer to avoid low-memory kills. This tier requires aggressive asset streaming, lower-resolution textures, and careful management of loaded scenes.
Mid tier Android (4GB RAM total)	With the OS overhead, roughly 1.5GB is available for your application. Budget around 900MB to 1.2GB to leave headroom. This is where most of your Android players sit, and it should be your primary optimisation target.
High tier Android (8GB+ RAM)	2GB or more is available, but do not design for this as your baseline. Use the extra headroom for higher-quality assets on capable devices rather than treating it as your minimum requirement.
iOS (3GB iPhone, typical of iPhone 13 and similar)	iOS manages background apps aggressively, freeing up more memory for the foreground application. Around 1.8GB is a safe working budget on a 3GB device. However, exceeding the Jetsam memory limit triggers an immediate, silent crash with no warning dialog and no chance to save state. Monitor memory pressure using `os_proc_available_memory()` and implement fallback asset loading before you approach the limit.

For a deeper dive into sustained performance, read our post on managing thermal throttling in Unity mobile. If you need hands-on help, our performance optimisation services cover profiling, optimisation, and thermal management for mobile Unity projects.

Platform-Specific Considerations

iOS and Android have different rendering APIs, submission processes, and fragmentation profiles. A successful port accounts for both from the start.

iOS

Apple's Metal API is the only supported graphics API on iOS. Unity handles Metal rendering through URP or the built-in render pipeline, but certain shader features and compute operations behave differently under Metal than under DirectX or Vulkan. Test shader behaviour on actual iOS hardware early.

App Store review adds time and unpredictability to your release schedule. Apple's reviewers will reject builds for performance issues, crashes, and UI that does not conform to Human Interface Guidelines. Budget one to two weeks for the review cycle, and expect at least one rejection on your first submission. TestFlight is essential for beta distribution and supports up to 10,000 external testers, making it a powerful tool for gathering performance data across device models before launch.

Minimum OS targeting requires a careful balance. Supporting iOS 15 and above covers roughly 95% of active devices. Dropping to iOS 14 picks up a few percent more but introduces compatibility constraints with newer Metal features and Swift runtime requirements. Check Apple's published adoption statistics for current figures.

Android

Device fragmentation is the defining challenge of Android development. Over 4,000 active device models span a vast range of chipsets, screen sizes, and OS versions. Your game will encounter Qualcomm Adreno, ARM Mali, and Imagination PowerVR GPUs, each with different performance characteristics and driver quirks.

Vulkan is the preferred graphics API for modern Android devices, offering better CPU overhead characteristics than OpenGL ES 3.x. However, Vulkan driver quality varies significantly by manufacturer. Samsung and Google Pixel devices generally have solid Vulkan support. Some budget MediaTek and older Qualcomm chipsets have Vulkan implementations that are technically present but practically unreliable. A common strategy is to default to Vulkan on known-good devices and fall back to OpenGL ES 3.2 on others, using a device capability list.

Android App Bundles (AAB) are now required for Google Play submissions. AABs enable dynamic delivery, letting you ship device-appropriate assets (resolution, texture compression format) without bloating the initial download. The initial install limit is 200MB for the base APK, with additional content delivered via Play Asset Delivery.

Google Play policies around permissions, data safety declarations, and target API level requirements change frequently. As of 2026, new apps must target at least API level 35 (Android 15). Budget time for policy compliance alongside technical development.

Cross-Platform Considerations

For both platforms, link to our platform readiness guide for the full pre-submission checklist covering store metadata, rating questionnaires, privacy declarations, and compliance requirements.

Testing and Device Coverage

You cannot test on every device. The goal is to build a device matrix that covers the range of hardware your players will use, then supplement physical testing with cloud-based device farms.

Building a Device Matrix

Start with analytics data if your game has a PC or web presence. Your existing audience's mobile device distribution tells you what to prioritise. Without existing data, a reasonable matrix for a global audience includes 8 to 12 physical devices:

Platform	Recommended devices
iOS (3 to 4 devices)	iPhone SE 3rd gen (baseline, smallest screen, A15 chip), iPhone 13 (mid tier, representative of the largest active iOS segment), iPhone 15 Pro (high tier, A17 Pro, ProMotion 120Hz), and an iPad Air for tablet layout testing
Android (5 to 8 devices)	Samsung Galaxy A14 (low tier, MediaTek Helio, Mali GPU, 2 to 4GB RAM), Pixel 7a (mid tier, Tensor G2, Adreno GPU), Samsung Galaxy S23 (high tier flagship), Xiaomi Redmi Note 13 (high volume emerging market device), and ideally an older flagship like the Samsung Galaxy S20 or Pixel 5 to test aging high-end hardware with degraded battery and thermal performance

The most important principle in device matrix construction is to test on the worst device you intend to support, not the best. If your minimum spec is a Samsung Galaxy A14, that device should be the one sitting on your desk every day during development. It is tempting to develop on a flagship and optimise for lower devices later, but that approach leads to architectural decisions that are expensive to reverse. Performance problems discovered late on low-end hardware often require fundamental changes to rendering, asset loading, or scene complexity rather than simple parameter tweaks.

Prioritise variety across four dimensions: chipset manufacturer (Qualcomm, MediaTek, Samsung Exynos, Apple), GPU family (Adreno, Mali, PowerVR), RAM tier (2GB, 4GB, 6GB, 8GB+), and screen size (compact phones, standard phones, large phones, tablets). Each combination can reveal unique issues that other configurations would miss.

Automated and Cloud Testing

Firebase Test Lab and AWS Device Farm provide access to hundreds of device models for automated test runs. These are excellent for catching device-specific crashes, layout issues, and compatibility failures. They are less useful for performance profiling, as virtualised or remote device environments do not replicate real thermal behaviour.

Automated UI testing with Unity Test Framework or Appium catches regression issues across builds. Smoke test suites that launch the game, navigate menus, and play through a short session on a matrix of devices save significant manual QA time.

For teams without an in-house QA function, our QA testing services provide device coverage testing, performance profiling, and compatibility validation across iOS and Android.

Timeline and Cost Expectations

Porting timelines depend on the complexity of the source game, the state of its codebase, and the depth of adaptation required. Here are realistic ranges based on our experience.

By Project Complexity

Simple ports (2D games, minimal UI, straightforward controls): 2 to 4 months with a small team (2 to 3 developers). Examples include puzzle games, card games, and simple action titles with existing touch-friendly mechanics.

Medium complexity (3D games, moderate UI, some systems redesign): 4 to 8 months with 3 to 5 developers. This covers most indie and mid-tier titles that need input reworking, performance optimisation, and UI adaptation.

Complex ports (MMOs, deep strategy, extensive systems, large asset libraries): 8 to 18 months with a dedicated team of 5 or more. RuneScape Mobile took approximately two years with a large team. Games with complex networking, large persistent worlds, or heavy content pipelines sit at this end. Multiplayer and online games face additional complexity from network stack adaptation, server infrastructure for mobile session patterns, and reconnection handling for unstable mobile connections, which is why MMO or multiplayer ports typically fall in the 6 to 12 month range even when the core gameplay is relatively straightforward.

These timelines assume the source codebase is in reasonable condition. Legacy codebases with heavy technical debt, hardcoded resolution assumptions, or tightly coupled platform-specific code add 30% to 50% to these estimates. Factor in additional time for platform submission and review cycles, particularly if your team has not shipped on iOS or Android before.

Use our game development cost estimator to build a rough budget based on your project's scope, and our game development timeline estimator to model realistic schedules for different project sizes. For a conversation about your specific project, explore our mobile development services or get in touch directly.

Conclusion

A successful mobile port requires deliberate decisions about input, performance, platform compliance, and testing. None of these areas can be treated as an afterthought. The games that port well to mobile are the ones where the team committed to rethinking the experience for the platform rather than simply shrinking the desktop version.

Start with a feasibility assessment, invest in proper thermal profiling on real devices, build your device matrix early, and budget realistically for the timeline. If your team needs specialist support, whether for the full port or for specific challenges like performance optimisation or platform submission, Ocean View Games has the experience to help. We have been through this process on projects ranging from MMOs to educational titles, and we know where the pitfalls are.

David Edgecombe is the founder and technical lead at Ocean View Games, a London-based game development consultancy. A Unity Certified Expert with over 10 years of Unity experience, David previously served as Mobile Team Lead at Jagex, where he led the porting effort for RuneScape Mobile from 2017 to 2019.

Platform Readiness: What Every Developer Needs Before Hitting Submit

Ocean View Games — Sat, 04 Apr 2026 12:45:16 +0000

You have built your game. It runs well, the QA pass is clean, and you are ready to ship. Then you submit to the App Store and get rejected for a missing privacy manifest. Or your PlayStation build fails certification because the game does not handle controller disconnection correctly. Or your Google Play listing gets flagged because your data safety declaration does not match your actual data collection.

These are not edge cases. They are the most common reasons game launches get delayed, and they are almost always avoidable with proper preparation.

At Ocean View Games, we have submitted games to the Apple App Store, Google Play Store, and assisted with console certification submissions across PlayStation, Xbox, and Nintendo Switch. We have also been rejected, and learned from every rejection. This post is the consolidated knowledge from those experiences: the requirements that catch developers off guard, the integrations you cannot skip, and the pre-submission checklist we use before every launch.

Why Readiness Matters More Than You Think

A failed submission is not just a delay. It has cascading effects:

Marketing timing breaks down. If you have press coverage, influencer partnerships, or a launch event timed to your release date, a week-long delay while you fix a compliance issue and resubmit can waste months of marketing preparation.

Resubmission queues are not instant. Apple's review typically takes 24 to 48 hours, but can stretch longer during busy periods. Console resubmission queues can take one to two weeks. A single failed certification attempt can push your launch by a month.

Team morale suffers. Nothing deflates a team faster than being told the game they thought was finished needs another round of fixes for requirements they did not know existed.

The solution is straightforward: treat platform readiness as a distinct phase of development, not an afterthought bolted onto the end of QA.

Mobile: iOS and Android Requirements

Apple App Store

Apple's requirements have become significantly more complex in recent years, particularly around privacy. Here are the areas where we see the most rejections:

Privacy manifests are now mandatory for any app that uses specific APIs (UserDefaults, file timestamp APIs, system boot time, and others). If your Unity project accesses these APIs, either directly or through third-party SDKs, you need a PrivacyInfo.xcprivacy file declaring the reasons. This catches many Unity developers because Unity's own runtime touches some of these APIs, meaning almost every Unity game needs a privacy manifest.

App Tracking Transparency (ATT) is required if your game uses any form of device tracking for advertising purposes. If you use ad SDKs (AdMob, IronSource, Unity Ads), you almost certainly need an ATT prompt. The prompt must appear before any tracking occurs, and you must respect the user's choice. Apple rejects apps that track without permission or that gate content behind the ATT prompt.

In-app purchase configuration must be submitted alongside the binary. Every IAP product needs a description, pricing tier, and screenshot for review. Apple rejects apps where the IAP flow is confusing, where prices are not clearly displayed before purchase, or where the restore purchases button is missing or non-functional.

Content ratings must be declared accurately. If your game allows user-generated content, user communication, or has unrestricted web access, the content rating must reflect the worst-case content exposure.

App Store screenshot and metadata requirements specify exact dimensions for each device class (iPhone 6.7", iPhone 6.5", iPad Pro 12.9"). Missing even one required screenshot size will block submission.

Google Play Store

Google's requirements overlap with Apple's in many areas but differ in specifics:

Data safety declarations are Google's equivalent of Apple's privacy labels. You must declare what data your app collects, whether it is shared with third parties, and whether users can request deletion. Critically, this declaration must account for all SDKs in your app, not just your own code. We have seen rejections where the developer accurately described their own data collection but forgot that their analytics SDK was collecting device identifiers.

Target API level requirements increase annually. As of 2026, new apps must target a recent Android API level, and updates to existing apps must also meet this requirement. If your Unity version cannot target the required API level, you need to upgrade Unity before you can submit.

Large app bundles (over 150 MB) require Android App Bundles (AAB) rather than monolithic APKs. Unity handles this through the "Split Application Binary" build option, but the asset packs need testing to ensure all content downloads correctly on first launch.

Families Policy compliance applies if your game's target audience includes children. This restricts ad formats, data collection, and requires compliance with local child protection regulations (COPPA in the US, GDPR-K in Europe, AADC in the UK).

Console: Certification Requirements

Console certification is an order of magnitude more prescriptive than mobile store review. The full certification documents run to hundreds of pages, but here are the categories where we see the most failures.

Universal Requirements (All Platforms)

Save data handling must be bulletproof. The game must save automatically at reasonable intervals, must not corrupt save data if power is lost mid-save, and must handle the case where save data is corrupted or missing gracefully (offer to create new data, do not crash). On consoles with cloud save support, the game must handle sync conflicts without data loss.

System events must be handled correctly. The game must respond properly to controller disconnection (pause the game, show a reconnection prompt), headset connection/disconnection, system overlay activation (PS button, Xbox guide button), low battery warnings, and console suspend/resume. Every one of these scenarios is tested during certification, and failure is an automatic rejection.

Accessibility requirements are expanding across all platforms. At minimum, subtitle options, control remapping, and colour-blind modes are expected. Sony, Microsoft, and Nintendo each have specific accessibility guidelines that are increasingly enforced during certification.

Performance must meet platform-specific standards. Frame rate drops, excessive loading times, and memory leaks that cause crashes are certification failures. Console certification testers will stress-test your game for hours, looking for memory growth, frame rate degradation, and instability.

PlayStation-Specific (TRC)

Sony's Technical Requirements Checklist includes specific requirements around DualSense features (adaptive triggers, haptic feedback), PS VR2 compatibility declarations, PlayStation Network integration (trophies, friends, activities), and Share functionality. Trophy implementation is particularly strict: trophy descriptions, icons, and unlock conditions must all meet specific formatting and content guidelines.

Xbox-Specific (XR)

Microsoft's Xbox Requirements focus on Xbox Live integration, Smart Delivery (ensuring the correct version loads on Xbox Series X|S vs Xbox One), Quick Resume support, and accessibility features through the Xbox Accessibility Guidelines (XAG). The XAG is not strictly mandatory for all titles, but compliance is increasingly expected and affects featuring decisions.

Nintendo Switch-Specific (Lotcheck)

Nintendo's Lotcheck process has unique requirements around handheld/docked mode transitions, Joy-Con detachment handling, touch screen support in handheld mode, and Nintendo Account integration. The Switch's lower hardware specifications compared to PlayStation and Xbox also mean performance requirements are tighter. Nintendo is particularly strict about loading times and frame rate stability.

The Integrations You Cannot Skip

Regardless of platform, certain integrations need to be verified before submission:

Analytics and crash reporting should be integrated and confirmed working in the release build, not just debug builds. Verify that events fire correctly, that crash reports include useful stack traces, and that the analytics dashboard shows real data from a test device running the release binary. We use Firebase Crashlytics and GameAnalytics on most projects, but whatever you choose, confirm it works in the actual shipping build.

Deep links and universal links (if applicable) must resolve correctly. If your game supports links from email campaigns, social media, or web-to-app flows, test every link type on every target platform.

Push notifications (if applicable) require proper permission handling, must not send notifications before the user grants permission, and must provide a clear way to manage notification preferences in-game.

Cloud save integration needs testing across the full lifecycle: fresh install, device migration, offline play followed by sync, and conflicting saves from multiple devices. Each platform's cloud save API (iCloud, Google Play Games Services, Steam Cloud, PlayStation Plus cloud storage) has its own quirks.

Our Pre-Submission Checklist

We built a free Platform Readiness Checklist that walks you through every requirement for your specific target platforms. It covers iOS, Android, PlayStation, Xbox, Switch, and Steam, and generates a personalised checklist based on which platforms you are targeting and what features your game includes.

For teams that want a more hands-on approach, our App Store Launch service handles the entire submission process: store listing optimisation, screenshot preparation, metadata configuration, privacy compliance, and submission management. We have submitted dozens of titles across iOS and Android and know the common rejection triggers intimately.

The 48-Hour Pre-Submit Review

In the 48 hours before any submission, we run this rapid verification:

Build verification. Install the exact binary you are submitting on a real device. Play through the first 15 minutes of the game. Navigate every menu. Trigger every IAP flow (including restore purchases). Verify analytics events are appearing in your dashboard.

Metadata review. Read every word of your store listing. Check that screenshots match the current build. Verify that your privacy declarations accurately reflect the current state of the app (SDKs change between versions, and your privacy declaration needs to change with them).

Compliance scan. Run through the platform-specific requirements one final time. This is tedious but it is far less tedious than a rejection and resubmission cycle.

Rollback plan. If the submission fails or a critical bug is discovered post-launch, do you have a plan? Know how to trigger an expedited review (Apple), how to halt a staged rollout (Google Play), or how to submit a day-one patch (console platforms).

When to Bring In Help

If platform readiness feels overwhelming, that is normal. The requirements are extensive, they change frequently, and each platform has idiosyncrasies that are difficult to anticipate without experience.

Our App Store Launch service exists specifically for studios that want expert guidance through the submission process. For console submissions, our console porting team handles certification compliance as part of the porting engagement.

Start with the free Platform Readiness Checklist to see where your project stands, and get in touch if you want a hands-on review.

Is Your Game Ready to Port? A Technical Feasibility Guide

Ocean View Games — Thu, 26 Mar 2026 03:57:50 +0000

Porting a game to a new platform sounds straightforward in a pitch meeting. "We built it in Unity, Unity supports everything, so we just need to hit the build button for PlayStation." Anyone who has actually shipped a port knows this is fantasy. The gap between "Unity can target this platform" and "our specific game runs well on this platform" is where the real engineering lives.

During our founder's tenure at Jagex, our team worked on one of the most complex mobile ports in gaming history: bringing RuneScape, a 20-year-old MMORPG, to mobile devices. That experience taught us that porting feasibility is not a binary question. It is a spectrum, and knowing where your project sits on that spectrum before you commit budget is the difference between a smooth port and a costly surprise.

This guide covers the technical factors you need to assess before greenlighting a port, and gives you a practical framework for estimating what it will actually take.

The Five Feasibility Factors

Every porting assessment we conduct evaluates five areas. Each one can independently turn a "simple port" into a significant engineering project.

1. Middleware and Plugin Compatibility

This is the most common blocker, and it is the first thing we check.

Your game almost certainly uses third-party middleware: networking libraries, analytics SDKs, ad mediation platforms, audio engines, input systems, or platform-specific integrations. Each one of these needs a verified build for your target platform.

Common blockers we encounter:

Networking libraries are the highest-risk category. If your game uses FishNet, Mirror, Photon, or a custom networking stack, verify that the library has been tested and certified for your target platform. Console platforms in particular have strict requirements around network traffic, NAT traversal, and platform-specific multiplayer APIs (PlayStation Network, Xbox Live, Nintendo Switch Online) that may require additional integration work.

Native plugins compiled for one architecture (x86/x64 for PC) will not run on another (ARM for mobile, or console-specific architectures). Any plugin with native code needs a platform-specific build, and not every plugin vendor provides one.

Analytics and monetisation SDKs are often platform-specific. Google AdMob does not exist on PlayStation. Steam Workshop integration does not exist on mobile. These integrations need platform-native replacements, not just recompilation.

How to assess this: List every third-party dependency in your project. For each one, check whether the vendor provides a build for your target platform. If even one critical dependency has no port, you need a replacement or a workaround, and that changes your scope estimate significantly.

2. Performance Gap

The performance characteristics of your source platform and target platform determine how much optimisation work the port requires.

Porting down (PC to mobile, or console to Switch) almost always requires significant optimisation. A game running at 60fps on a desktop GPU with 8GB of VRAM will not automatically run at 30fps on a mobile GPU with 1GB of shared memory. You need to reduce draw calls, compress textures, simplify shaders, implement LOD systems, and potentially rework memory management.

For our Empires Rise strategy game, the procedural map generation system that worked comfortably on desktop needed chunk-based loading and aggressive memory management to run on mid-range mobile devices. The optimisation phase reduced peak memory usage from 45MB to 18MB for that single system.

Porting up (mobile to PC/console) is less technically demanding but introduces different challenges: players expect higher visual fidelity, ultrawide monitor support, uncapped frame rates, and graphics options menus. A mobile game running unmodified on a 4K monitor looks sparse and underwhelming.

Porting across (PC to console, or between console generations) is usually the most contained scope, but certification requirements add significant testing overhead.

How to assess this: Profile your game on your source platform. Note the frame time budget, peak memory usage, draw call count, texture memory, and asset loading times. Then research the specifications of your target platform's minimum hardware tier. The gap between those two profiles is your optimisation workload.

3. Input Abstraction

How well your game separates input handling from game logic determines how much UI and control work a port requires.

Well-abstracted input means your game uses an input abstraction layer (Unity's new Input System, or a custom input manager) that maps abstract actions ("jump", "attack", "navigate menu") to platform-specific inputs. Porting to a new input method means adding new bindings, not rewriting gameplay code.

Tightly coupled input means your code directly references specific input methods: Input.GetMouseButtonDown(0) scattered throughout gameplay scripts, touch-specific gestures hardcoded into UI, or keyboard shortcuts assumed in menu navigation. This is common in games that were built for a single platform, and it means every interaction point in the game needs individual attention.

The RuneScape mobile port was an extreme example of this challenge. The original game was designed around a mouse-and-keyboard interface with right-click context menus, hover tooltips, and keyboard shortcuts for 29 distinct skills. Translating that to touch required a complete UI rearchitecture, not just a control remap. The mobile UI work was one of the largest workstreams in the entire port.

How to assess this: Search your codebase for direct input references. If input handling is centralised in a small number of manager classes, the port is contained. If input code is scattered across hundreds of scripts, budget significant time for input refactoring.

4. Platform-Specific Requirements

Each platform has mandatory requirements that your game must meet before it can ship. These are not optional features; they are certification gates that will reject your submission if they are missing.

Console certification is the most rigorous. Sony's Technical Requirements Checklist (TRC), Microsoft's Xbox Requirements (XR), and Nintendo's Lotcheck each specify hundreds of mandatory behaviours: how the game handles controller disconnection, how it responds to system suspend/resume, achievement integration, save data management, accessibility features, and much more. Our console porting checklist covers the most common failure points.

Mobile store requirements are less prescriptive but still significant. Apple requires support for specific iOS features (Dynamic Island, multitasking, privacy labels), and both Apple and Google have minimum SDK version requirements that change annually. A game built on an older Unity version may not be able to target the required SDK.

PC storefronts have the lightest requirements, but Steam, Epic, and GOG each have their own integration requirements for achievements, cloud saves, overlay support, and DRM.

How to assess this: Download the certification requirements document for your target platform (these are available through developer programmes) and audit your game against the mandatory items. Count the gaps. Each gap is a distinct work item in your porting scope.

5. Content and Asset Pipeline

Your existing assets may not be suitable for the target platform without modification.

Texture formats differ across platforms. ASTC is standard on mobile, BC formats on PC and console. If your textures are authored in a format that requires transcoding, you need to verify that quality is maintained and that the transcoded textures do not cause visual artefacts.

Audio formats and compression vary. Mobile platforms are more sensitive to audio memory, so uncompressed audio tracks that work fine on PC may need recompression or streaming on mobile.

Asset loading strategies may need reworking. A PC game that loads an entire level into memory at startup may need streaming or chunked loading on memory-constrained platforms. If you are using Unity's Addressables system, this is more manageable. If you are using Resources.Load or direct asset references, the refactoring work is larger.

Localisation and platform-specific content adds scope. Console certification may require specific localised strings for system-level features (save data descriptions, trophy descriptions), and platform holders may require content modifications for regional ratings compliance.

The Feasibility Matrix

We score each of the five factors on a 1 to 3 scale:

Score	Meaning
1	Low risk. Minimal work expected.
2	Moderate risk. Known work required, scope is estimable.
3	High risk. Significant unknowns or confirmed blockers.

A total score of 5 to 8 suggests a contained porting project (4 to 8 weeks for a small to mid-size game). 9 to 12 suggests a substantial porting effort (2 to 4 months). 13 to 15 suggests a major engineering project that should be planned and budgeted as carefully as the original development.

We built a free Porting Feasibility Checker that walks you through this assessment interactively. It asks specific questions about your project and produces a personalised feasibility report with estimated effort ranges.

Common Porting Paths and What to Expect

PC to Mobile

This is the most common "porting down" scenario, and it typically requires the most work. Expect to address performance optimisation (the largest workstream), input redesign from mouse/keyboard to touch, UI scaling for smaller screens, battery and thermal management, and mobile-specific monetisation integration (if applicable). Timeline: 3 to 6 months for a mid-core game.

Mobile to PC

Visually underwhelming if done without enhancement. The game runs quickly, but players expect higher fidelity, keyboard/mouse controls, resizable windows, and graphics options. The technical work is moderate but the "polish to meet platform expectations" work is often underestimated. Timeline: 2 to 4 months.

PC to Console

Technically contained if you are already using Unity or Unreal, but certification requirements add significant QA and compliance work. Controller support, achievement integration, and platform-specific features (PS5 DualSense haptics, Xbox Quick Resume) are the main workstreams. Timeline: 2 to 4 months per console platform.

Console to Console

Usually the lightest port scope within the console family. Cross-generation (PS4 to PS5) ports benefit from backward compatibility. Cross-platform (PlayStation to Xbox) ports require integration swaps (PSN to Xbox Live) but the core game typically runs without major changes. Timeline: 1 to 3 months.

Before You Commit: The Pre-Port Audit

Before committing budget to a port, we strongly recommend a focused technical audit. This is a short engagement (typically one to two weeks) where we:

Inventory your dependencies and verify platform compatibility for each one
Profile performance on your source platform and estimate the optimisation gap
Audit input architecture for abstraction quality
Map certification requirements against your current implementation
Produce a detailed scope estimate with timeline ranges and identified risks

This audit typically costs a fraction of the port itself and prevents the most common porting failure: discovering a blocker three months into a six-month project.

Our porting and mobile development teams have shipped ports across every major platform. If you want a realistic assessment of what your specific port will involve, get in touch for an initial conversation.

When to Migrate Your Unity Project (And When to Stay Put)

Ocean View Games — Sat, 21 Mar 2026 12:11:43 +0000

"Should we upgrade to Unity 6?" is one of the most common technical questions we hear from studios and clients. The answer is almost never a simple yes or no, because a Unity version migration is not a free upgrade. It is a project in its own right, with real costs, real risks, and a timeline that depends entirely on the state of your codebase.

At Ocean View Games, we have migrated projects across multiple Unity versions over the past decade. We have seen migrations that took a single afternoon and migrations that consumed weeks of engineering time. The difference almost always comes down to preparation and honest assessment of what the migration actually involves.

This post is the framework we use internally when advising clients on whether to migrate, when to migrate, and how to do it without derailing their production schedule.

Why Unity Migrations Are Not Free

Every major Unity version introduces changes to the rendering pipeline, scripting API, package manager dependencies, and platform toolchains. Some of these changes are additive (new features you can adopt gradually). Others are breaking (APIs removed, behaviours changed, deprecated systems finally deleted).

The cost of a migration is determined by how many breaking changes affect your specific project. A project using Unity's built-in render pipeline, standard physics, and no third-party plugins might migrate in hours. A project using custom render passes, native plugins, platform-specific code paths, and a dozen Asset Store dependencies could face weeks of compatibility work.

The Hidden Costs

The obvious cost is fixing compilation errors. The hidden costs are what catch teams off guard:

Behaviour changes are the most dangerous category. Your project compiles and runs, but something behaves differently. Physics interactions feel slightly off. Particle effects render at the wrong scale. UI layout shifts on certain aspect ratios. These issues do not throw errors; they slip through unless you have thorough test coverage or meticulous QA.

Plugin compatibility is the most common blocker. If any of your third-party plugins or Asset Store packages have not been updated for the target Unity version, you are stuck waiting for the maintainer or finding an alternative. For projects using networking libraries like FishNet or Mirror, this is especially critical as networking code is deeply integrated and version-sensitive.

Build pipeline changes affect your CI/CD workflow. Unity has shifted build systems, changed Gradle integration for Android, and updated Xcode project generation for iOS across recent versions. Your automated build pipeline may need reconfiguration.

Team disruption is the cost nobody budgets for. While migration work is in progress, the main development branch is in flux. Feature work either pauses or runs on a parallel branch that will need merging later. For a small team, this disruption is proportionally larger.

When Migration Makes Sense

Despite the costs, there are clear situations where migrating is the right call.

You Need a Feature That Only Exists in the New Version

Unity 6 introduced significant improvements to the rendering pipeline, GPU Resident Drawer for reduced draw call overhead, and enhanced multiplayer tooling. If your project specifically needs one of these features and there is no reasonable workaround on your current version, migration is justified.

For our work on Domi Online, the GPU instancing improvements in newer Unity versions directly impacted our ability to render 10,000+ trees with minimal draw calls. The performance gain was worth the migration effort because it solved a concrete, measured problem.

Your Current Version Is Approaching End of Life

Unity provides Long Term Support (LTS) for each major release, but that support window is finite. Once your version leaves LTS, you stop receiving security patches, platform SDK updates, and bug fixes. More critically, Apple and Google regularly update their SDK requirements for app store submissions. If your Unity version cannot target the latest required iOS or Android SDK, you will eventually be unable to submit updates to the stores.

This is not a hypothetical risk. We have seen studios unable to push critical bug fixes because their Unity version could not produce a build that met updated store requirements.

Your Plugin Ecosystem Has Moved On

If the plugins and packages your project depends on have dropped support for your Unity version, you are accumulating risk with every update you skip. Eventually, a critical plugin update (a security patch, a platform compatibility fix) will only be available for newer Unity versions, forcing an unplanned migration under time pressure.

You Are Starting a New Phase of Development

If your project is between major development phases, such as finishing a vertical slice and moving into full production, or completing initial release and planning a major content update, the natural gap in feature development is the best time to absorb migration costs. The team is not mid-sprint on critical features, and there is time to test thoroughly before resuming production velocity.

When to Stay Put

Migration is not always the right call, and premature migration is surprisingly common.

You Are Mid-Production With a Hard Deadline

If you are six weeks from a milestone delivery or store submission, do not migrate. The risk of introducing subtle bugs or incompatibilities outweighs any benefit from new features. Finish the milestone on your current version, then evaluate migration during the next planning phase.

The New Version Does Not Solve a Real Problem

"Unity 6 is out, we should probably upgrade" is not a sufficient reason to migrate. If your current version is stable, your plugins are compatible, your build pipeline works, and you are not hitting performance limitations that the new version specifically addresses, the migration cost buys you nothing tangible.

Your Test Coverage Is Thin

If you do not have automated tests covering core systems (progression, economy, save/load, networking) and you do not have a structured QA process, a migration will introduce behaviour changes you cannot detect reliably. Invest in test coverage first, then migrate.

You Have Heavily Customised Engine Internals

Projects that have forked Unity packages, written custom render passes against internal APIs, or patched engine source code face disproportionate migration costs. Each customisation is a potential point of failure that must be individually verified and potentially rewritten.

The Migration Decision Framework

We use a simple scoring approach when advising clients. For each of these five factors, score your project 0 (no risk), 1 (moderate), or 2 (significant):

1. Third-party dependencies. How many Asset Store packages and native plugins does your project use? More dependencies means more compatibility risk.

2. Custom rendering. Have you written custom shaders, render passes, or post-processing effects? These are the most likely to break across Unity versions.

3. Platform targets. How many platforms do you ship to? Each platform adds a testing and verification pass to the migration. A project shipping to iOS, Android, WebGL, and Steam has four times the platform verification work of an iOS-only project.

4. Codebase size and age. Larger, older codebases accumulate more deprecated API usage. A project that has been in development for three years across two Unity versions will have more migration surface area than a six-month project.

5. Test coverage. Do you have automated tests for core systems? A project with solid test coverage can migrate with much higher confidence than one relying entirely on manual QA.

A total score of 0 to 3 suggests a straightforward migration (days). 4 to 6 suggests moderate effort (one to two weeks). 7 to 10 suggests a significant migration project that should be planned and budgeted as a distinct workstream.

We built a free Unity Migration Checker that walks you through this assessment interactively and gives you a personalised recommendation based on your specific project parameters.

How to Execute a Migration Safely

If you have decided to migrate, here is the process we follow:

1. Branch and Baseline

Create a dedicated migration branch. Before changing anything, run your full test suite and record the results. Take screenshots or video of key gameplay sequences. This baseline is your reference for verifying that the migration has not introduced regressions.

2. Upgrade in Steps

If you are jumping multiple Unity versions (e.g. 2021 LTS to Unity 6), do not leap directly. Upgrade one LTS version at a time, fixing issues at each step. This makes it far easier to identify which version introduced a specific problem.

3. Fix Compilation First, Behaviour Second

Get the project compiling before you start testing behaviour. The Unity upgrade wizard will flag most API changes. Fix those systematically, using Unity's migration documentation for each version step.

4. Test on Real Devices

Editor testing is not sufficient. Build to your target platforms and test on actual hardware, especially minimum-spec devices. Rendering differences, input handling changes, and performance characteristics all vary between Editor and device.

5. Verify Third-Party Plugins Independently

Before attributing a bug to the Unity upgrade, verify that each third-party plugin has been updated for the target version. Plugin-related issues are the most common source of post-migration bugs.

When We Can Help

If you are evaluating a Unity migration and want an expert assessment of the effort involved, our legacy modernisation service includes codebase audits specifically designed to surface migration risks before you commit. We have migrated projects ranging from small educational games to a large-scale MMORPG, and we can give you an honest estimate of what your specific migration will cost.

Start with our free Unity Migration Checker for an initial assessment, or get in touch for a detailed review.

Which Game Engine Should You Use? Unity vs Unreal vs Godot (2026)

Ocean View Games — Tue, 10 Mar 2026 19:56:01 +0000

Choosing a game engine is one of the earliest and most consequential decisions in any game project. It determines your programming language, your available talent pool, your deployment pipeline, your licensing costs, and in many cases, the upper bound of what your game can achieve visually and technically.

The problem with most engine comparison articles is that they list features in isolation. Feature lists do not help you decide. What helps is understanding how each engine performs in the context of a real project, with real constraints around budget, timeline, team size, and target platform.

This guide compares the four engines we see most often in client work and industry discussions: Unity, Unreal Engine, Godot, and GameMaker. For each, we cover what it does well, where it struggles, what it costs, and who it is best suited for.

If you want a personalised recommendation based on your specific project, try our Game Engine Comparison Tool. It takes about two minutes and weighs your answers against the same criteria we use when advising clients.

Unity

Language: C#
Current version: Unity 6 (2024 LTS)
Licence: Free up to $200K revenue; Plus at $399/year up to $200K; Pro at $2,040/year above $200K
Platforms: iOS, Android, Windows, macOS, Linux, WebGL, PS4/PS5, Xbox, Switch, VR/AR

What Unity does well

Unity's core strength is breadth. It deploys to more platforms than any other engine, and it does so from a single codebase. If your game needs to ship on mobile, PC, console, and web, Unity is the path of least resistance.

For 2D games, Unity is arguably the strongest option. Its Tilemap system, 2D physics, sprite animation tools, and 2D lighting (introduced in URP) are mature and well-documented. Most successful 2D indie games of the past decade were built in Unity: Hollow Knight, Cuphead, Celeste, and Ori and the Blind Forest.

The Asset Store is a genuine accelerator for small teams. Pre-built networking solutions (FishNet, Mirror, Photon), UI frameworks, shader packs, and complete game templates can save weeks of development time. The ecosystem is larger than any competitor's.

C# is a practical choice for game development. It is strongly typed, has excellent tooling, and is easier to hire for than C++. Most game programmers can be productive in C# within days, which matters when you are building a team or onboarding contractors.

Unity 6 brought meaningful improvements to rendering (adaptive probe volumes, GPU Resident Drawer), the new multiplayer framework (Netcode for GameObjects and Entities), and stability of the Entity Component System for data-oriented design. If you tried Unity's DOTS stack in 2022 and found it immature, it is worth revisiting.

Where Unity struggles

Unity's 3D rendering, while competent, does not match Unreal's out-of-the-box visual fidelity. Achieving photorealistic results in Unity requires significant shader work and artist expertise. For AAA-quality visuals, Unreal has a clear lead.

The engine's history of frequent API changes has frustrated developers. Features like the old Input Manager vs the new Input System, the legacy rendering pipeline vs URP vs HDRP, and the ongoing transition to DOTS mean there are often two or three ways to do the same thing, not all of which are fully supported. Unity 6 has improved this, but the legacy of fragmentation persists in tutorials and community answers.

Unity's pricing model became a source of controversy in 2023 with the Runtime Fee announcement, which was subsequently revised. The current per-seat subscription model is straightforward, but the episode damaged trust with some developers. Worth noting for teams making long-term engine commitments.

Best for

Mobile games (2D and 3D), cross-platform deployment, 2D games of any complexity, indie and mid-tier 3D games, educational and serious games, AR/VR applications, live-service games with multiplayer requirements.

Unreal Engine

Language: C++, Blueprints (visual scripting)
Current version: Unreal Engine 5.5
Licence: Free until $1M revenue; 5% royalty above $1M
Platforms: Windows, macOS, Linux, iOS, Android, PS4/PS5, Xbox, Switch

What Unreal does well

Unreal Engine's rendering pipeline is the industry benchmark for real-time visual quality. Nanite (virtualised geometry), Lumen (global illumination), and MetaHuman (digital humans) produce results that no other engine matches without extensive custom work. If your game's selling point is visual fidelity, Unreal is the default choice.

Blueprints is genuinely useful. It is not a toy scripting system; entire commercial games have shipped using only Blueprints. For teams with strong artists and designers but limited programming resource, Blueprints allows non-programmers to build and iterate on gameplay logic. The combination of Blueprints for rapid prototyping and C++ for performance-critical systems is a proven workflow.

Unreal's tooling for large-scale projects is mature. World Partition (for open worlds), level streaming, the Sequencer (for cinematics), and the animation system (Control Rig, IK Retargeter) are production-grade tools that AAA studios rely on. If your project has hundreds of hours of content and dozens of team members, Unreal's project management tooling scales to meet that.

The royalty model is attractive for smaller studios. You pay nothing until your game earns $1 million in revenue. For most indie projects, Unreal is effectively free.

Where Unreal struggles

Mobile development in Unreal is possible but not its strength. The engine's rendering pipeline is designed for high-end hardware. Getting an Unreal game to run well on a mid-range Android phone requires significant optimisation work that you would not need in Unity or Godot. Draw call overhead, shader compilation times, and package sizes are all larger by default.

The learning curve is steep. C++ is a powerful but demanding language. Compile times are long. Debugging is harder than in C#. For small teams or solo developers, the overhead of Unreal's complexity can eat into productivity.

Iteration speed is slower than Unity for certain workflows. Hot reload in C++ is unreliable. Blueprint compilation can stall with large graphs. For rapid prototyping of gameplay mechanics, Unity's C# workflow typically allows faster iteration.

Unreal's 2D capabilities are limited. While it technically supports 2D through Paper2D, the plugin is no longer actively developed. If you are making a 2D game, Unreal is the wrong choice.

Best for

Visually ambitious 3D games, AAA and AA productions, open-world games, narrative-driven games with cinematic sequences, competitive shooters, games targeting PC and current-gen consoles, architectural visualisation and virtual production.

Godot

Language: GDScript, C#, C++, GDExtension
Current version: Godot 4.4
Licence: Completely free, MIT licence, no royalties, no fees, no restrictions
Platforms: Windows, macOS, Linux, iOS, Android, WebGL (console support via third-party solutions)

What Godot does well

Godot is free in the truest sense. MIT licence means no fees, no royalties, no usage tracking, no terms that can change. For developers who were burned by Unity's pricing controversy, this is a significant draw. You can modify the engine source code, ship commercial games, and owe nothing to anyone.

For 2D games, Godot is excellent. Its 2D engine is not a retrofit on top of a 3D renderer (as it effectively is in Unity and Unreal). Godot has a dedicated 2D rendering pipeline with its own physics, lighting, and coordinate system. This makes 2D development feel native rather than constrained.

GDScript is intentionally simple. It resembles Python in syntax and is designed specifically for game development. For solo developers, hobbyists, and small teams that want to prototype quickly without the overhead of C# or C++, GDScript removes friction. Godot 4 also supports C# through Mono, so teams with existing C# experience can use their preferred language.

The scene system is elegant. Everything in Godot is a scene, and scenes can be nested and instanced. This compositional approach is intuitive once learned and encourages modular design from the start.

The engine is lightweight. The editor is approximately 40MB. Projects compile quickly. Export templates are small. For web games and lightweight mobile games, Godot's footprint is an advantage.

Where Godot struggles

Console deployment is Godot's most significant gap. There is no official support for PlayStation, Xbox, or Nintendo Switch. Third-party solutions exist (such as W4 Games' console ports), but they add cost and complexity. If console is in your roadmap, this is a hard constraint.

Godot's 3D capabilities have improved dramatically in version 4, but they are still behind Unity and substantially behind Unreal. Complex 3D projects (open worlds, large-scale multiplayer, photorealistic rendering) will push against Godot's current limits.

The ecosystem is smaller. The asset library has fewer plugins, fewer tutorials, and fewer community-maintained tools than Unity's. Hiring Godot developers is harder because the talent pool is smaller. For commercial projects where you need to staff up quickly, this matters.

Documentation has improved but remains uneven. Core features are well-documented. Newer features and advanced use cases often rely on community tutorials or reading the source code.

Best for

2D games of any scope, lightweight 3D games, web games, jam games and prototypes, educational projects, developers who value open source and licensing freedom, solo developers and very small teams, projects with no console requirements.

GameMaker

Language: GML (GameMaker Language)
Current version: GameMaker 2024.11
Licence: Free tier available; Creator at $4.99/month; Indie at $9.99/month; Enterprise pricing on request
Platforms: Windows, macOS, Linux, iOS, Android, HTML5, PS4/PS5, Xbox, Switch

What GameMaker does well

GameMaker is the most accessible engine for 2D game development. Its room editor, sprite editor, and visual workflow are designed specifically for 2D and feel more intuitive than Unity's or Godot's general-purpose editors when working in two dimensions.

GML is simple enough for beginners but powerful enough for commercial games. Undertale, Hotline Miami, Hyper Light Drifter, and Katana Zero were all built in GameMaker. These are not trivial games; they have complex state machines, custom shaders, and polished gameplay feel.

GameMaker has legitimate console export support, unlike Godot. If you are making a 2D game that needs to ship on Switch, PlayStation, or Xbox, GameMaker handles the export pipeline.

The subscription pricing is low. For an indie developer, $9.99 per month for full platform export is significantly cheaper than Unity Pro.

Where GameMaker struggles

GameMaker is a 2D engine. It has some 3D capabilities, but they are rudimentary and not recommended for anything beyond simple experiments. If there is any chance your project needs 3D, choose a different engine.

GML is a proprietary language with no use outside GameMaker. Skills learned in GML do not transfer to other engines or general software development. For career development, C# (Unity/Godot) or C++ (Unreal) are more valuable.

Performance ceiling is lower than Unity, Unreal, or Godot for compute-heavy games. Particle-heavy shmups, physics simulations, or games with thousands of active entities will hit GameMaker's limits before they hit other engines'.

The community is smaller and skews hobbyist. Finding experienced GameMaker developers for a commercial project is harder than finding Unity or Unreal developers.

Best for

2D indie games, pixel art games, game jam entries, solo developers making their first commercial game, 2D games targeting console, developers who prioritise simplicity and fast iteration over engine flexibility.

How to Choose

The engine decision is not about which engine is "best." It is about which engine best fits your constraints. Here is how we think about it when advising clients:

Start with your platform. If you need console support, Unreal, Unity, or GameMaker. If you need web, Unity or Godot. If you need mobile as a primary platform, Unity is the strongest choice. If you only need PC, all four work.

Then consider your visual requirements. If the game's value proposition depends on visual fidelity (photorealistic environments, cinematic cutscenes, high-poly character models), Unreal is the right answer. For stylised 3D, Unity is more than capable. For 2D, Godot or GameMaker.

Then consider your team. What languages does your team know? What engines have they shipped on? A team of C++ veterans will be more productive in Unreal than in Unity, regardless of what a comparison chart says. A solo developer with Python experience will ramp up faster in Godot than in any other engine.

Then consider your budget. Unreal's royalty model means you pay nothing until success. Unity's subscription means you pay from day one but owe nothing on revenue. Godot and GameMaker (at the indie tier) have the lowest ongoing costs.

Then consider your timeline. Unity and GameMaker have the fastest prototyping workflows for their respective strengths (general-purpose and 2D). Unreal's iteration speed is slower but its built-in systems (animation, cinematics, world building) save time on large productions. Godot is fast for small projects but may require building tools that other engines provide out of the box.

Our Engine Comparison Tool walks you through these factors in a structured way and gives you a weighted recommendation. If you want to discuss your specific project, get in touch and we are happy to advise.

A Note on Custom Engines

Some teams consider building a custom engine, particularly for highly specialised games or when licensing terms are a concern. This is rarely the right choice unless you have a team of experienced engine programmers and a very specific technical requirement that no commercial engine meets.

The development cost of a custom engine, measured in years of engineering time, almost always exceeds the licensing cost of a commercial engine, even at scale. The exception is studios with an existing proprietary engine and the institutional knowledge to maintain it.

Our Experience

At Ocean View Games, we specialise in Unity development. We chose Unity because our work focuses on mobile games, cross-platform deployment, and live-service multiplayer, all areas where Unity's strengths align with client needs. Our team has shipped projects ranging from MMORPGs with FishNet networking to educational games for language preservation to procedurally generated strategy games on mobile.

That said, we are honest when Unity is not the right fit. If a client comes to us with a photorealistic first-person shooter targeting PC and console only, we will tell them to consider Unreal. If they are a solo developer making a 2D pixel art game with no multiplayer, Godot might be the better choice. The right engine is the one that serves the project, not the one the studio happens to prefer.

Need help choosing an engine or starting development? Get in touch to discuss your project, or try our Engine Comparison Tool for a quick recommendation.

Related Resources

Game Engine Comparison Tool — Free interactive tool to find the best engine for your project.
Unity 6 Technology Page — What's new in Unity 6 and how we use it.
C# for Game Development — Why C# is our language of choice.
Game Development Cost Estimator — See how engine choice affects project cost.
Questions to Ask Before Starting a Game Project — Engine is just one of the decisions you need to make early.
Building Reusable Game Frameworks in Unity — How we accelerate Unity development with modular frameworks.

Gamifying Language Learning: Design Principles for EdTech

Ocean View Games — Tue, 10 Mar 2026 19:55:31 +0000

"Gamification" has become a buzzword that often means little more than slapping points and badges on top of existing content. Real gamification measurably improves learning outcomes and requires a deeper understanding of both game design and pedagogy.

When we partnered with The Language Conservancy (TLC) to build Vocab Builder, a suite of 9 mini-games designed to preserve endangered indigenous languages, we learned firsthand what it takes to turn curriculum into genuine engagement.

This post shares the design principles that guided the project and that we now apply to every educational game development engagement.

Principle 1: Start with the Learning Objective, Not the Mechanic

The most common mistake in educational game design is starting with a game mechanic and retrofitting the curriculum. "Let's make a matching game" sounds reasonable, but it skips a critical question: what cognitive skill does matching actually reinforce?

For Vocab Builder, TLC provided us with specific learning objectives for each vocabulary set:

Recognition - can the learner identify the correct word when they hear it?
Recall - can the learner produce the word from memory?
Orthography - can the learner spell the word correctly?
Listening comprehension - can the learner distinguish between similar-sounding words?

Each of the 9 mini-games was designed to target one or two of these skills. An audio-matching game reinforces listening comprehension. A drag-and-drop spelling game reinforces orthography. A timed flashcard game reinforces recall under pressure.

Key Takeaway: Define the cognitive skills you want to develop before choosing game mechanics. The mechanic should serve the learning objective, never the reverse.

Principle 2: Data-Driven Content, Not Hardcoded Assets

Educational games need to scale across content sets without code changes. A language learning app that requires a developer to add each new vocabulary list is not scalable.

We engineered a data-driven asset pipeline for Vocab Builder:

Linguists populate a Google Sheets template with vocabulary entries, including word, translation, pronunciation guide, and category
Audio recordings are uploaded to a shared folder, named to match the spreadsheet entries
Our build pipeline parses the spreadsheet and audio files, validates them for completeness, and packages them into Unity-readable ScriptableObjects
The game loads vocabulary sets dynamically at runtime

This pipeline means TLC can add a new language to the app without any developer involvement. They fill in the spreadsheet, record the audio, and the game picks it up automatically.

Why This Matters

Language preservation projects operate on limited budgets. Every hour of developer time spent manually integrating content is an hour not spent on new languages. The pipeline we built for Vocab Builder has since been used to add multiple languages with zero code changes.

Principle 3: Culturally Sensitive Design

This is where educational game development diverges most sharply from commercial game development. When your users are members of indigenous communities, the visual identity of the app carries weight beyond aesthetics.

For Vocab Builder, we worked closely with TLC to ensure:

Colour palettes reflected natural tones rather than the garish primaries common in consumer language apps
Iconography avoided culturally loaded symbols. A simple example: we replaced a generic "trophy" reward icon with something community-specific after feedback that the trophy felt disconnected from the cultural context
Typography accommodated special characters and diacritical marks essential to accurate orthography
Feedback sounds used tones rather than voice clips, avoiding any default language bias

None of this required exotic technology. It required listening and building rapid feedback loops into the design process. We shared mockups early and often, treating TLC's linguistic team as co-designers rather than passive clients.

Principle 4: Spaced Repetition Without the Boredom

The science of memory is clear, and spaced repetition reviewing material at increasing intervals is the most effective technique for long-term retention. But pure spaced repetition (like Anki flashcards) is boring, especially for younger learners.

We embedded spaced repetition into the game progression system:

Words the player gets wrong appear more frequently in subsequent rounds
Words the player consistently gets right appear less frequently but never disappear entirely
Difficulty scales with mastery: early rounds show 4 options for multiple-choice; advanced rounds show 6-8
The game tracks per-word accuracy and adjusts weighting accordingly

From the player's perspective, this feels like a game that gets progressively harder. From a learning perspective, it is a spaced repetition engine disguised as difficulty scaling.

Key Takeaway: Spaced repetition and game difficulty curves are structurally identical as both increase challenge over time. Use this alignment to embed effective learning science into natural game progression.

Principle 5: Measure What Matters

Educational games need analytics that go beyond "daily active users" and "session length." We instrumented Vocab Builder to track:

Per-word accuracy rates - which words are learners struggling with?
Retention curves - how does accuracy change over time for previously learned words?
Mini-game effectiveness - which of the 9 games produces the best retention for each skill type?
Session completion rates - are learners finishing sessions or dropping off mid-game?

This data feeds back to TLC's linguistic team, helping them refine vocabulary sets and teaching strategies. The game is not just a delivery mechanism, but rather a measurement tool for the language preservation programme.

Lessons for Other EdTech Projects

Whether you are building a language app, a maths tutor, or a corporate training game, these principles apply:

Start with learning objectives - mechanics follow objectives, not the reverse
Build data-driven pipelines - content creators should not need developers for every update
Respect your audience's context - cultural sensitivity is not optional in educational settings
Embed learning science - spaced repetition, retrieval practice, and interleaving are proven techniques that map naturally onto game mechanics
Measure learning outcomes - engagement metrics are necessary but not sufficient. Track whether players are actually learning.

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

Ocean View Games — Tue, 24 Feb 2026 12:05:54 +0000

Every new game project starts with the same boilerplate; audio managers, scene transitions, save systems, haptic feedback wrappers, analytics hooks, UI scaffolding. None of it is unique to the game, yet every team rebuilds it from scratch.

At Ocean View Games, we decided to stop paying that tax. When we developed What's That (a mobile quiz game) we treated it as a live testbed for a reusable framework. The game shipped successfully, but the real deliverable was the modular component library we extracted from it.

That library now lets us kickstart client projects 30-50% faster than starting from an empty Unity project.

The Problem: Rewriting the Same Code, Every Project

In our first year of client work, we noticed a pattern. Every mobile game needs:

An audio manager that handles music, SFX, and volume preferences
A scene manager that handles transitions, loading screens, and deep links
A save system that serialises player state to local storage
A haptic feedback wrapper that unifies iOS Taptic Engine and Android vibration
A UI system with common patterns (modals, toasts, loading spinners)
An analytics hook that fires events without coupling to a specific provider

Each of these takes 2-5 days to build properly. Across a 6-8 week project, that is 2-3 weeks spent on infrastructure before any gameplay code is written.

The hypercasual market amplified this. Clients need MVPs fast, sometimes in 4-6 weeks. Spending half that time on boilerplate is not competitive.

Key Takeaway: If you are building the same systems for every project, you are either billing clients for redundant work or absorbing the cost yourself. Neither is sustainable.

Our Approach: Extract, Standardise, Test

We did not design the framework top-down. We built it bottom-up by extracting battle-tested code from a shipping game.

Step 1: Build It in a Real Product

What's That was deliberately scoped to exercise a wide range of common systems, including audio, UI, persistence, haptics, and scene management. We built each system with slightly more abstraction than the game needed, knowing we would extract it later.

Step 2: Decouple and Package

After the game shipped, we reviewed each system and asked: "Does this depend on anything specific to What's That?" If yes, we refactored to remove the coupling. If no, it went into the framework as-is.

The result is a set of independent modules, each with:

A clear public API
No dependencies on other framework modules (unless explicitly declared)
A prefab or ScriptableObject for configuration
Basic unit tests

Step 3: Validate on Client Projects

The real test of a framework is whether it survives contact with a different game. We deployed it on three subsequent client projects and tracked where it needed adjustment. The first project revealed that our audio manager did not handle background/foreground transitions correctly on Android. The second revealed that the save system needed encryption support. Each fix went back into the framework.

What Is in the Framework

Audio Manager

A singleton that manages three audio layers (music, SFX, ambient) with independent volume controls. Key features:

Crossfade transitions between music tracks
Automatic ducking (SFX lowers music volume momentarily)
Handles app minimisation - music pauses when the app loses focus and resumes correctly
Volume preferences persist via the save system

Haptic Feedback Wrapper

iOS and Android handle haptics completely differently. iOS has the Taptic Engine with structured feedback types (light, medium, heavy, selection). Android has raw vibration with duration and amplitude.

Our wrapper provides a unified API:

HapticFeedback.Light() - maps to iOS selection feedback, Android 10ms vibration
HapticFeedback.Medium() - maps to iOS impact feedback, Android 25ms vibration
HapticFeedback.Heavy() - maps to iOS notification feedback, Android 50ms vibration

Tuned through extensive playtesting so each tier feels perceptually equivalent across platforms.

Scene Manager

Handles scene transitions with configurable loading screens. Supports:

Fade-to-black transitions with customisable curves
Async scene loading with progress callbacks
Scene preloading for seamless transitions
Deep link handling (opening the app to a specific scene)

Save System

A lightweight serialisation layer built on top of Unity's PlayerPrefs with added structure:

Type-safe accessors (no raw string keys scattered through the codebase)
Optional AES encryption for sensitive data
Versioned save format with migration support
Automatic backup before writes

UI Component Library

Pre-built, themeable components following a consistent interaction pattern:

Modal dialogs with backdrop tap-to-dismiss
Toast notifications with auto-dismiss timers
Loading overlays with progress indicators
Button components with squash-and-stretch press animations and sound

The Impact on Client Projects

The framework does not eliminate custom work. Every game still needs unique gameplay code, art integration, and design iteration. What it eliminates is the first two weeks of setup.

On a recent project for Mojo Games (Pocket Factory), the framework saved an estimated 10 days of development time. Audio, haptics, and scene management were configured in hours rather than days. That time went directly into gameplay polish; the part of development that actually differentiates the product.

Key Takeaway: A framework's value is not just speed but also consistency. When audio, saves, and UI follow proven patterns, the defect rate drops because you are not debugging new code for solved problems.

When to Build Your Own Framework

Not every studio should build a framework. It makes sense when:

You ship multiple projects per year - the investment amortises across releases
Your projects share a platform - a mobile Unity framework does not help with a desktop Unreal project
You have battle-tested code to extract - do not design a framework speculatively; extract it from a shipping product
Your team is disciplined about updates - a framework that is not maintained becomes a liability

If you ship one game every two years, the overhead of maintaining a framework probably exceeds the time it saves. Focus on clean, well-documented code instead.

Procedural Generation on Mobile: Balancing Complexity and Performance

Ocean View Games — Tue, 24 Feb 2026 12:05:47 +0000

Procedural generation is one of the most powerful tools in a game developer's toolkit. It creates near-infinite replayability from finite assets. But on mobile, where RAM is measured in gigabytes rather than tens of gigabytes and thermal throttling is a constant threat, procedural generation demands careful engineering.

When we built Empires Rise (a 4X turn-based strategy game targeting iOS and Android) we needed maps that felt hand-crafted but were generated fresh every session. This post covers the techniques we used and the tradeoffs we navigated.

Why Procedural Generation for a Strategy Game?

Turn-based strategy games live or die by map variety. If every playthrough feels the same, players churn. Pre-built maps are finite. Procedural generation offers:

Infinite replayability - no two sessions are identical
Reduced asset storage - algorithms replace dozens of hand-built map files
Dynamic difficulty - seed parameters can adjust map complexity to match player skill

But mobile imposes hard constraints. We could not run generation on a background thread for seconds at a time. Players expect near-instant loading. Our target was under 2 seconds from tap to playable map on a mid-range device.

The Generation Pipeline

Our pipeline has three stages, each building on the previous:

Stage 1: Terrain Layer (Modified Perlin Noise)

Standard Perlin Noise produces organic-looking height maps, but raw noise tends to generate repetitive, blobby terrain. We applied several modifications:

Octave layering - combining multiple noise frequencies to add both large-scale continents and small-scale terrain detail
Falloff masking - applying a radial gradient to guarantee water at map edges, creating natural island formations
Biome thresholds - mapping noise values to discrete terrain types (ocean, coast, plains, forest, mountain) rather than continuous gradients

The result is a terrain grid that looks natural but is structurally viable for gameplay. Every map has coastline, inland territory, and mountain chokepoints.

Stage 2: Feature Placement (Cellular Automata)

Raw terrain is a canvas. Features make it a map. We used cellular automata to distribute forests, rivers, and resource deposits:

Scatter seed cells randomly across the terrain grid
Run 3-4 iterations of growth rules (a forest cell expands if 3+ neighbours are also forest)
Prune isolated cells that failed to cluster

This produces natural-looking clusters rather than the uniform scatter you get from pure random placement. Rivers use a different approach as we trace downhill paths from mountain cells to coast cells using gradient descent on the height map.

Stage 3: Gameplay Validation

Not every generated map is playable. We run a validation pass that checks:

Every player spawn point can reach every other spawn point (flood fill connectivity check)
Resource distribution is balanced within a tolerance band
No player starts with a significant geographic advantage

Maps that fail validation are silently re-rolled with a new seed. In practice, our generation parameters are tuned well enough that fewer than 5% of maps are rejected.

Key Takeaway: Procedural generation is not "generate and ship." Always validate that the output meets gameplay requirements before presenting it to the player.

The Mobile Optimisation Challenge

The generation pipeline above works well on desktop. On a phone with 3GB of RAM and a thermally constrained SoC, three problems emerge:

Problem 1: Memory Spikes During Generation

Generating the full map in memory means allocating large 2D arrays for terrain, features, and validation data simultaneously. On a 256x256 tile map, that is 65,000+ cells across multiple layers.

Solution: Chunk-based generation. We divided the map into 16x16 tile chunks and generated them sequentially. Only the current chunk's data lives in memory at once. Once a chunk is generated, its tile data is serialized to a lightweight format and the working arrays are released.

Problem 2: Main Thread Stalls

Cellular automata iterations and flood-fill validation are CPU-intensive. Running them synchronously freezes the UI.

Solution: Coroutine time-slicing. We wrapped the generation loop in a Unity Coroutine that yields every N iterations, returning control to the main thread to render a loading animation. The player sees a smooth progress bar rather than a frozen screen.

// Simplified time-slicing pattern
for (int i = 0; i < totalCells; i++) {
    ProcessCell(i);
    if (i % CELLS_PER_FRAME == 0) yield return null;
}

Problem 3: Tilemap Rendering Performance

Unity's Tilemap system is convenient but can choke on large maps. Setting 65,000 tiles in a single frame causes a visible stall.

Solution: Progressive chunk loading. We only instantiate tilemap chunks within the camera viewport plus a one-chunk buffer. As the player pans the camera, new chunks load and distant chunks unload. This keeps the active tile count under 4,000 at any time, regardless of total map size.

Key Takeaway: On mobile, the generation algorithm is only half the battle. How you load and render the result is equally important for perceived performance.

Tuning for Feel

The technical implementation is necessary but not sufficient. Procedural maps need to feel good to play on, not just look correct. We spent considerable time tuning:

Island size distribution - too many small islands makes naval traversal tedious; too few large landmasses reduces strategic variety
Resource density - too sparse and early game is frustrating; too dense and there is no incentive to expand
Chokepoint frequency - mountain passes and river crossings create natural defensive positions. Too few and combat becomes a formless blob; too many and expansion feels blocked

Each of these parameters is exposed in a configuration file, not hardcoded. This allowed our designers to iterate on feel without touching C# code.

Results

The final implementation generates a playable 256x256 map in under 1.5 seconds on a mid-range Android device (Snapdragon 665), well within our 2-second target. Memory usage during generation peaks at 18MB, compared to 45MB+ for the naive approach.

The chunk-based rendering keeps frame times under 16ms (60fps) during camera panning, with no hitches when crossing chunk boundaries.

Applying This to Your Project

If you are considering procedural generation for a mobile title, here are the key takeaways:

Generate in chunks - never allocate the full map in memory at once
Time-slice CPU work - yield to the main thread frequently to keep the UI responsive
Load progressively - only render what the camera can see
Validate gameplay viability - automated checks catch unplayable maps before the player does
Expose tuning parameters - let designers iterate without code changes

These techniques are not limited to strategy games. They apply to any genre that uses procedural content, including roguelikes, survival games, or even procedurally generated educational levels.

Mobile UI Design for Complex Games: Lessons from RuneScape Mobile

Ocean View Games — Fri, 13 Feb 2026 21:00:46 +0000

Porting a game to mobile is never just a resolution swap. When the source material is a 20-year-old MMORPG with dozens of overlapping menus, right-click context actions, and a keyboard-heavy control scheme, the challenge becomes an entirely different beast.

During our founder's tenure at Jagex, we were part of the team that brought RuneScape to iOS and Android, a project that touched over 10 million players. That experience now underpins every mobile development project we take on at Ocean View Games.

This post distils the hard-won lessons from that process into practical principles any studio can apply when adapting complex desktop interfaces for touchscreens.

The Core Problem: Information Density vs. Screen Real Estate

Desktop MMORPGs are information-rich by design. A typical RuneScape session might have the game world, an inventory panel, a chat window, a minimap, action bars, and skill trackers all visible simultaneously. On a 24-inch monitor, that works. On a 6-inch phone, it is unplayable.

The instinct is to shrink everything. That instinct is wrong. Tiny buttons lead to mis-taps, frustration, and uninstalls. The real solution is not miniaturisation but prioritisation.

Key Takeaway: The goal of mobile UI adaptation is not to fit everything on screen at once. It is to show exactly what the player needs, exactly when they need it.

Principle 1: Context-Sensitive Interfaces

The single biggest architectural shift we made was moving from a static panel layout to a context-sensitive interface that dynamically adapts to what the player is doing.

When a player is mining, they need to see:

The rock they are interacting with
Their inventory (to track ore)
A progress indicator

They do not need to see their friends list, their quest log, or a chat window full of trade spam.

How It Works in Practice

We built a state machine that tracks the player's current activity and adjusts visible UI panels accordingly:

Combat mode - health bars, prayer points, and action bar take priority. Inventory minimises to a quick-access strip.
Skilling mode - the relevant skill interface expands. Non-essential panels collapse.
Social mode - chat and friends list expand. Game HUD elements shrink to the periphery.

The transitions between modes needed to feel instant and invisible. Any animation longer than 150ms felt sluggish during combat. We settled on 100ms slide transitions with a subtle fade, fast enough to feel responsive but smooth enough to avoid visual jarring.

Principle 2: Tap Targets Are Sacred

Apple's Human Interface Guidelines recommend a minimum tap target of 44x44 points. Google's Material Design suggests 48x48dp. In a complex game with dozens of interactive elements, meeting these minimums is a constant battle.

We established a strict rule: no interactive element smaller than 44x44 points, regardless of how it looks visually. The visual footprint of a button can be smaller than its hit area. We used invisible padding to extend tap zones beyond their visual boundaries.

The Right-Click Problem

RuneScape's desktop interface relies heavily on right-click context menus; a mechanic with no direct mobile equivalent. We evaluated three approaches:

Long-press - Mimics right-click but adds latency to every interaction
Dedicated context button - Adds UI clutter
Swipe gestures - Discoverable but conflict with scrolling

We ultimately used a hybrid: long-press for context actions, with a visual "hold" indicator that fills radially around the finger position. This gave players clear feedback that a long-press was registering, reducing accidental cancellations.

Principle 3: Decouple UI from Game Logic

One of the most valuable architectural decisions was fully decoupling the UI layer from the underlying game systems. The game logic did not care whether the player pressed a keyboard shortcut or tapped a button. It
received the same event.

This separation had two critical benefits:

Cross-platform parity - Mobile and desktop players could exist in the same world without either platform receiving an advantage. Network packets and client-side prediction remained identical.
Iterative design - We could redesign the mobile UI without touching game logic. When early playtests revealed that the combat interface needed restructuring, the change was confined to the UI layer.

Key Takeaway: If your UI code is entangled with game logic, you will pay for it during every porting project. Invest in clean separation early.

Principle 4: Design for Fat Fingers, Not Pixel Perfection

Desktop interfaces can rely on pixel-perfect cursor positioning. Mobile cannot. We adopted several techniques to accommodate imprecise touch input:

Generous hit zones - As mentioned, always larger than the visual element
Snap-to targets - When dragging items in the inventory, the item snaps to the nearest valid slot within a tolerance radius
Forgiveness windows - Tapping slightly outside an interactive element still registers if no other element is within range
Confirmation for destructive actions - Dropping valuable items requires a deliberate double-tap, preventing accidental loss

These techniques sound minor individually but collectively they transform the experience from "playable but annoying" to "feels native."

Principle 5: Respect the Viewport

Mobile players are often in portrait orientation on a phone, but in landscape on a tablet. A fixed layout breaks one or the other.

We built the UI on a responsive anchor system. Critical HUD elements anchor to screen edges and corners rather than absolute positions. The minimap anchors to the top-right. The action bar anchors to the bottom-centre. As the viewport changes, elements reflow without overlapping.

For panels that needed scrolling (inventory, skill lists, quest logs), we used native scroll physics with momentum and rubber-banding. Custom scroll implementations that ignore platform conventions feel immediately wrong to players, even if they cannot articulate why.

Applying These Lessons to Your Project

You do not need to be porting an MMORPG for these principles to apply. Any game with moderate UI complexity (such as strategy games, RPGs, management sims, or educational apps) benefits from:

Designing for context, not static layouts
Respecting minimum tap target sizes
Separating UI from game logic
Building for imprecise input
Using responsive anchoring instead of fixed positions

At Ocean View Games, we apply these principles across every mobile project and porting engagement we take on. Whether we are optimising performance for mid-range devices or adapting desktop controls for touch, the foundation is always the same: put the player's needs first.

What Makes a Great Game Development Consultancy in the UK?

Ocean View Games — Thu, 12 Feb 2026 12:15:30 +0000

The UK games industry generated over £7 billion in revenue last year, making it one of the largest creative sectors in the country. With that scale comes a crowded market of studios, freelancers, and consultancies, all claiming expertise. So when publications like Digital Reference compile lists of the best game design consulting services in the UK, what criteria actually matter?

As a studio that was recently named in that list, we thought it would be useful to break down what we believe separates a genuinely capable consultancy from one that simply has a good website.

Technical Depth Over Breadth of Services

The biggest red flag when evaluating a game development consultancy is a services page that claims to do everything. Web apps, blockchain, AI, mobile, VR, AR, "metaverse". If a studio lists every buzzword, they're likely a generalist agency that treats games as just another software vertical.

A great game dev consultancy has deep, demonstrable expertise in specific technical domains. That might be:

Engine-level optimization - not just "we use Unity" but "we've optimized draw calls for mobile GPUs rendering 10,000+ entities"
Networking architecture - understanding server-authoritative design, tick rates, interpolation, and lag compensation for multiplayer games
Platform-specific porting - knowing the actual constraints of iOS Metal, Android Vulkan, and the compromises required to hit 60fps on a mid-range phone

At Ocean View Games, we deliberately specialize. Our core competencies are Unity development, mobile porting and optimization, and multiplayer networking. We don't claim to build VR experiences or design board games, because doing fewer things well is how you build genuine authority.

A Provable Track Record

Case studies matter more than client logos. Any studio can list impressive names, but the question is: what did they actually build, and what were the results?

Look for consultancies that publish detailed technical case studies. Not marketing fluff, but honest accounts of the problems they solved. Did they describe the architecture? Did they explain trade-offs? Can you see the shipped product?

Our case study on porting RuneScape to mobile walks through specific UI/UX challenges we solved for a 20-year-old MMORPG with millions of active players. Our Domi Online case study details the server-authoritative networking decisions we made for a blockchain MMORPG built from scratch. These aren't vague "we helped a client" stories, they're technical narratives that demonstrate actual engineering capability.

Third-party coverage helps too. When Beam interviewed our lead developer about the architecture behind Domi Online, it wasn't a paid placement. It was a platform reaching out because the work was technically interesting enough to warrant coverage.

Industry-Specific Experience

Game development isn't one discipline, it's dozens. A studio that excels at casual mobile puzzle games may be completely wrong for your multiplayer RPG. A consultancy that builds educational games may not understand live-service monetization.

The best consultancies have depth in specific verticals:

MMORPG and multiplayer - requires networking, database architecture, anti-cheat, and scalability expertise
Educational and serious games - requires understanding pedagogy, accessibility standards, and institutional procurement processes
Mobile porting - requires deep platform knowledge, performance profiling, and UI adaptation for touch interfaces

We've worked across game studios and education institutions specifically because these two verticals demand the kind of rigorous engineering we specialize in. A vocabulary app for Cambridge University Press has more in common with an MMORPG than you might think; both require offline-first architecture, progressive content loading, and obsessive performance optimization.

Communication and Process Maturity

Technical skill means nothing if the consultancy can't communicate clearly, hit deadlines, or integrate with your existing team.

The hallmarks of a mature consultancy:

Clear scoping and estimation - they tell you what's hard and what's risky before starting
Transparent weekly reporting - you see progress, blockers, and burn rate regularly
Co-development capability - they can embed into your Jira/Slack/Git workflow rather than operating as a black box
Post-launch support - they don't disappear after shipping; they offer maintenance and live-ops retainers

This is particularly important for studios that need staff augmentation or a specialized team to hit a milestone. The consultancy needs to function as an extension of your team, not a separate entity that delivers a ZIP file at the end.

Long-Term Thinking

The best consultancies think beyond the current invoice. They make architectural decisions that serve the project's 5-year roadmap, not just the next sprint.

When we built the 64-bit progression system for Domi Online, we could have used standard 32-bit integers and moved on. But we knew the game was designed for decades of player progression, so we engineered a system that mathematically cannot overflow. That's the kind of decision that separates a consultancy from a contractor.

Similarly, when we modernized Flash games for the Museum of London, we didn't just convert ActionScript to JavaScript, we rebuilt the architecture in TypeScript with Phaser so the institution could maintain and extend the game for years to come.

The UK Advantage

The UK has genuine structural advantages for game development consultancy:

Talent pipeline - universities like Abertay, BAFTA-affiliated programs, and proximity to major studios (Rockstar North, Rare, Jagex) create a deep talent pool
Time zone positioning - GMT/BST overlaps with both US East Coast and European working hours, making co-development practical across regions
Tax incentives - Video Games Tax Relief (VGTR) and the UK Games Fund actively support the industry
Cultural proximity to major markets - British studios work natively in English and understand both Western and Asian gaming markets

These aren't just marketing points, they're practical advantages that affect project delivery. When you hire a UK consultancy, you're tapping into an ecosystem that has produced some of the most successful games in history.

What to Ask Before Hiring

If you're evaluating game development consultancies, here are five questions that quickly separate the serious from the superficial:

"Show me a technical case study for a shipped product" - if they can't, they're hiding something
"What's your team's background?" - look for people who've worked at actual game studios, not just "full-stack developers"
"How do you handle scope changes mid-project?" - the answer reveals process maturity
"What would you recommend against for our project?" - a good consultancy says no to bad ideas
"Can we talk to a previous client?" - confidence in referrals signals quality

Final Thought

Being named among the best game design consulting services in the UK is a milestone we're proud of. But recognition follows results - not the other way around. We'd rather be known for the work than the awards.

If you're looking for a game development consultancy that brings deep technical expertise, honest communication, and a track record of shipped products, get in touch. We're happy to discuss your project even if you end up choosing someone else.

Interview with Merit Circle

Ocean View Games — Mon, 09 Feb 2026 19:54:46 +0000

We sat down with David Edgecombe, lead developer at DomiOnline - an MMORPG that's building on Beam. We talk about the evolution of the gaming industry, the development of DomiOnline, the current challenges and trends in the gaming industry, and how blockchain plays into all of that.

Before working on DomiOnline David wasn’t into web3 at all. But when he started learning about blockchain in gaming, he saw the potential straight away. “Playing around with it is nothing but fun. What we’re trying to do is to make it simpler. The goal is to make it more user-friendly, so that it can go mainstream. “

David got his computer science degree in University, which landed him his first job in the gaming industry; he started at an agency that worked on client projects. After years of gaining experience, he made the move to Jagex, the company behind the popular MMO RuneScape, a game he had played since he was young.

"I loved that game and had been playing it since 2006. They asked me to work on the RuneScape mobile project, which was amazing. How do you port a 20-year-old MMO onto mobile phones? It was a huge undertaking."

After he completed that project, he moved on from the company and started his own - Ocean View Games, a video game development agency. Not too long after he started, he received a message from Pellek, co-founder and CEO of DomiOnline. Pellek asked David if he wanted to work together. “And the rest is history.”

The development of DomiOnline

DomiOnline is an MMORPG set in a medieval fantasy world where there is no level cap or skill cap, and where death has severe consequences. Players explore dark forests and mountains, facing mythical creatures. They engage in quests, battles, skill mastery, and form alliances.

David has been working on it since 2021. “It’s been a really fun project to work on,” he said. “It’s cool to actually build the whole game from scratch. Normally you don’t get that level of creative freedom.” The project takes inspiration from some of the builders' favorite games - World of Warcraft and RuneScape. “And we kind of incorporate the best of both.”

When asked if the goal is to be like legendary games like those two, or to be in their own lane. David doesn’t shy away from his dreams. “It would be nice to even surpass them. It’s a dream. You want the product to be successful. I think we’ll be successful. But we shall see.”

The upcoming release

The first release of the game is coming close. What can we expect? “We’ve been closed Alpha for ages, which means we’ve let a select group of people in. We want to make sure we have a quality game.” They’re always developing and expanding the game. “Before, we had day and night. Now, we have rain, thunder, snow, you name it.”

"When you first join the game, you get put on this small island with an NPC that holds your hand as you emerge into this MMO. After there are no hard rules - you make your own journey. If you want to cook something? Go for it. If you want to go and kill monsters? Go ahead."

But it doesn’t end there. The team is clear about where it’s heading. “In the future, there will be game events. A Christmas event or an Halloween event, for instance.”

David gets visibly excited just talking about what the game will be. But he’s most excited to just boot up his PC and play it himself. “To login and see people playing the game and having fun. We’ve been closed for so long, so there’s not many people yet. I’m excited to have the flood gates open and just watch people play and see what they do.”

He says this will also help the game get even better. “We might find that people like combat the most. Or maybe just skilling.” They plan to use this feedback to steer the game in the direction the users want. “It would be nice to see what players do, where they get stuck and what they love, and build the game accordingly.”

The evolution of the gaming industry

David is not just excited about the future of DomiOnline itself, but about where the gaming industry is headed over the next decade as a whole.

He thinks there will be more live services in gaming. “That’s the buzzword that’s been mentioned a lot.” He mentions Fortnite as a pioneer, with its ever-changing seasons and live events, such as the Travis Scott concert. “More streaming,” is another prediction he makes. “You don’t need a PlayStation.”

"You just stream it from the internet. Like Netflix, but for gaming. And that opens up a lot of possibilities, because now you can have a massive data center rendering your game."

The intersection between blockchain and gaming

Before working on DomiOnline David wasn’t into web3. But when he started learning about blockchain in gaming, he saw the potential straight away. “Playing around with it is nothing but fun.”

“I think the possibilities for NFTs and play-to-earn and things like that are extremely exciting. And I do feel like even traditional studios such as Ubisoft, Activision, and EA Sports will start to look at that.” Hinting at a future where we might see big games like GTA on blockchain.

But we’re not there yet. “What we’re trying to do is to make it simpler. We’re not forcing it on you. The goal is to make it more user-friendly, so that it can go mainstream. At the moment it’s a bit of a learning curve getting used to it,” implying that over the next few years this curve will be flattened.

David says that this is what Merit Circle is doing so well with Beam. “Making sure that it is as easy for gamers to just play around with a game that is using Web3 elements, without even realizing it.”

There are no limits to the potential of blockchain gaming, and DomiOnline is approaching it in a unique way. While the game is still in Alpha, development is going extraordinary and we can expect a public launch soon. With the builders having decades of experience in the industry and a true love and passion for MMORPGs, DomiOnline is one to watch.

Originally published on Beam Medium

DEV Community: Ocean View Games

Working With a Game Dev Agency: What to Expect

Discovery and Scoping

What a good discovery phase includes

Red flags at this stage

Proposal and Agreement

What a proposal should include

Fixed price vs time-and-materials

Production

Sprint cadence and milestone structure

Communication rhythm

Handling scope changes mid-project

QA and Polish

Why QA matters throughout production

The polish phase

Launch and Beyond

App Store submission and soft launch

Post-launch support

How to Choose the Right Agency

Relevant experience

Technical alignment

Communication and culture

References

Conclusion

Mobile Game Porting Guide: PC to Mobile in Unity

Input Remapping and UI Adaptation

Touch Controls vs Traditional Input

Practical Approaches

Performance and Thermal Management

Profiling Workflow

Common Optimisations

Memory Budgets by Device Tier

Platform-Specific Considerations

iOS

Android

Cross-Platform Considerations

Testing and Device Coverage

Building a Device Matrix

Automated and Cloud Testing

Timeline and Cost Expectations

By Project Complexity

Conclusion

Platform Readiness: What Every Developer Needs Before Hitting Submit

Why Readiness Matters More Than You Think

Mobile: iOS and Android Requirements

Apple App Store

Google Play Store

Console: Certification Requirements

Universal Requirements (All Platforms)

PlayStation-Specific (TRC)

Xbox-Specific (XR)

Nintendo Switch-Specific (Lotcheck)

The Integrations You Cannot Skip

Our Pre-Submission Checklist

The 48-Hour Pre-Submit Review

When to Bring In Help

Related Reading

Is Your Game Ready to Port? A Technical Feasibility Guide

The Five Feasibility Factors

1. Middleware and Plugin Compatibility

2. Performance Gap

3. Input Abstraction

4. Platform-Specific Requirements

5. Content and Asset Pipeline

The Feasibility Matrix

Common Porting Paths and What to Expect

PC to Mobile

Mobile to PC

PC to Console

Console to Console

Before You Commit: The Pre-Port Audit

Related Reading

When to Migrate Your Unity Project (And When to Stay Put)

Why Unity Migrations Are Not Free

The Hidden Costs

When Migration Makes Sense

You Need a Feature That Only Exists in the New Version

Your Current Version Is Approaching End of Life

Your Plugin Ecosystem Has Moved On

You Are Starting a New Phase of Development