Skip to main contentSkip to contact
Ocean View Games
Frequently Asked Questions

Frequently Asked Questions

119 questions answered across our services and industries

Showing 119 of 119 questions

Unity Game Development

View Service Page →

We primarily build games and interactive products using Unity. Our work spans commercial games, educational projects, mobile and PC development, browser-based experiences and technically demanding interactive applications.

If you’re unsure whether your project fits, send us a brief and we’ll tell you directly.

No. We work with game companies, publishers, educational organisations and other teams building interactive products.

The important question is whether the project benefits from the kind of Unity engineering and technical ownership we provide.

Yes, within the right scope.

We have a small senior core team and can expand delivery through trusted contractors and specialists we’ve already worked with on real projects. We’re transparent about capacity and will tell you if a project’s team requirements would be better suited to a substantially larger studio.

Yes. Some engagements involve us owning most of the Unity development, while others involve working alongside an existing engineering, design or creative team.

For dedicated team reinforcement, see our Co-Development service.

Yes. We regularly work with existing codebases.

If the project’s condition or scope is unclear, we may recommend starting with a Technical Audit or Project Rescue engagement before committing to a larger body of work.

It depends on scope, platforms, content requirements and how much of the wider production we need to provide.

Once we understand the project, we can provide a structured estimate or proposal. For an early indication, use our Game Development Cost Estimator.

Unity is a mature cross-platform engine with a strong ecosystem and is particularly well suited to the kinds of mobile, PC, educational and interactive projects we work on.

Deep specialisation means we can spend less time learning the engine and more time solving the project’s actual engineering problems. Our engine comparison tool covers how Unity stacks up against the alternatives.

David Edgecombe holds Unity Certified Expert Programmer credentials. Certification is one piece of evidence alongside the team’s shipped projects and professional experience.

Mobile Game Development

View Service Page →
Both. We build new Unity projects for iOS and Android and also work with existing games that need to be ported, modernised or improved for mobile.
Yes, where the source project and target experience make sense for mobile. We normally start by assessing the existing codebase, input, UI, plugins, performance and platform dependencies so we can identify what can stay and what needs to change. Our Game Porting service covers that work in detail.
Yes. We work on existing Unity projects with issues such as frame-rate instability, memory usage, long loading times, thermal problems and device-specific performance. We start by profiling the real build so the work is based on evidence rather than guesswork. See our Performance Optimisation service.
Yes. We develop Unity projects targeting iOS and Android and can work on projects shipping to one or both platforms.
Yes. Older projects often need package, SDK, plugin or Unity-version work before they can meet current mobile requirements. Depending on the condition of the codebase, we may recommend a Technical Audit or Unity modernisation phase first.
No. We work with game companies, publishers, educational organisations and other teams building interactive products. Pedagogy-led work is covered by our Educational Games service.
Yes, within the right scope. We have a small senior core team and can expand delivery through trusted contractors and specialists we've already worked with. We'll also be direct if a project's staffing requirements are better suited to a substantially larger studio.

Game Design Services

View Service Page →
We agree the decisions and documents your team needs: core mechanics, player flows, progression, economy design or a playable prototype. The number of systems and the depth of testing shape the estimate. We set out deliverables and assumptions before work begins.
Once payment is complete, you own the bespoke documentation and deliverables created for your project under our agreement. Pre-existing tools and frameworks remain ours and are licensed for use within the delivered project.
Yes. Bring the audience, platforms and experience you have in mind, along with any references or constraints. We can help define the core loop, which is the set of actions players repeat, and turn it into a design your team can build.
We use playable Unity prototypes, structured feedback and systems models to test specific assumptions. For example, a prototype can reveal whether controls are understandable or a gameplay loop holds interest. The findings guide revisions before full production.
Yes. We agree a handover that can include the game design document, wireframes, systems diagrams, economy spreadsheets and prototype builds. We can also walk the receiving team through the decisions and unresolved questions.
Yes. We work with your subject experts to connect gameplay with learning objectives. See our educational game development service for examples and our approach to content review.

Game Monetisation Services

View Service Page →
Yes. We review the current build, audience, purchase flows and any available analytics before proposing changes. The work may involve in-app purchases, advertising, subscriptions or updating an existing SDK integration.
It can. Placement, frequency, rewards and audience expectations all matter. We agree a starting approach and use available player data to review it. Rewarded ads give players a choice, but still need testing within the game.
We charge for development or ongoing support rather than taking a revenue share. Store commissions, advertising network terms and third-party service charges are separate from our fees.
We look at the genre, audience, platforms, content plans and business goals. Premium purchases, in-app purchases, ads and subscriptions each have different design and implementation needs. Our monetisation strategy tool can help you explore the options before we talk.
We scope checks for successful and failed purchases, interrupted transactions, restoring purchases, entitlement changes and receipt validation. Subscription testing can also cover renewals and expired access where the project requires it.
We first agree the audience, data requirements and permitted monetisation approach with your team. We implement and test the technical measures specified for the project, working with your legal or safeguarding advisers where needed.

Educational Game Development

View Service Page →

Tell us who the game is for, what you want people to learn, and what content or research you already have. It also helps to know the target platforms, your available budget and any deadline, such as a funding milestone or planned launch.

An incomplete brief is fine. You do not need a finished game design or every technical decision made. We can help identify the missing information and decide whether the project can be estimated directly or would benefit from a short discovery phase.

You bring the subject expertise and any existing educational material, and we handle the game design and engineering around it. We agree who will create and review the content before production begins.

We can bring in artists and audio specialists through our freelance network, or work with your existing creative team. We scope these contributions as part of the project so responsibilities and costs are clear.

Sometimes. We first assess what is available, such as a playable build, published files, artwork, audio or documentation. Without source code, the work may require recreating the game rather than updating its existing code, so feasibility and cost depend on what can be recovered and what needs rebuilding.

In a previous role, David rebuilt London Museum’s Great Fire of London game in HTML5, using the original Flash game as the reference for every interaction. Share what you have and we can assess the options for your product.

Small, tightly scoped projects can be a couple of months. Most educational builds we see run somewhere between three and nine months, and larger multi-language or multi-platform programmes run longer.

Content volume and the number of stakeholders who need to review it tend to affect the timeline more than the engineering does. Our timeline estimator gives a rough indication before we speak.

Yes, and this is common. Clients regularly come to us with a curriculum, a research database, stories, artwork or subject expertise held by their own team, and need the game designed and built around it.

We are comfortable working alongside your educators, researchers, curriculum designers, illustrators or internal digital team rather than replacing them. Our team has done this with academic and institutional partners including Cambridge University Press, London Museum and the EU Horizon 2020 iRead consortium during previous employment, and with The Language Conservancy on Vocab Builder.

Where LMS integration is required, we first confirm the target platform, deployment environment and reporting needs. Depending on those requirements, the appropriate route may be SCORM, xAPI or a custom interface with single sign-on. Any standards-based integration is scoped and tested against the actual LMS rather than assumed to work universally.

Our SCORM vs Custom API post compares the approaches. Not every educational game needs LMS integration, so it is worth deciding early whether yours does.

Yes. Adam’s team at Fish in a Bottle delivered Navigo for the EU Horizon 2020 iRead consortium, working across more than a dozen European research and education partners. That work won a Serious Games Society award in the Digital Game Competition.

We are used to projects with formal reporting requirements, multiple stakeholders and fixed funding windows. Where you are still preparing an application, a paid discovery phase can produce the scope, technical plan and costed budget the bid needs.

Co-Development & Staff Augmentation

View Service Page →
We confirm availability and an onboarding plan after discussing your scope, codebase and production schedule. Access, build setup and understanding your conventions are part of the start of the engagement.
A day-rate or retainer arrangement can support changing priorities within the agreed capacity. A defined workstream can instead be scoped around milestones and deliverables. We agree the approach and how changes are handled before work begins.
The agreement assigns bespoke work to your studio under the agreed payment terms. Our pre-existing tools and frameworks remain ours and are licensed for use within the delivered project. Third-party components retain their own licences.
Yes. We can work in your repositories, task tracker, review process and sprint cycle. We agree coding conventions, access and communication with your team so responsibilities are clear.
We are based in London and work in GMT or BST. We agree meeting times and handover expectations with international teams. The amount of live overlap depends on your location and working hours.
We plan a handover of the agreed code, documentation, build steps and outstanding issues. Any further support period, maintenance or future capacity is agreed separately.

Performance Optimisation Services

View Service Page →
Yes. We reproduce the issue on an agreed device range and inspect memory use, logs and profiling data. Out-of-memory errors, resource leaks and other faults need different fixes, so we establish the cause before changing the build.
We start with the symptoms, affected devices and a representative build. A profiling pass can identify the main bottlenecks and produce a prioritised plan. Implementation is then estimated from the findings; see our Unity technical audit for an independent review.
We agree a target and measure performance on specified hardware and gameplay scenarios. The achievable result depends on the game and device limits. We discuss any changes to visual quality or gameplay before implementing them.
Yes, subject to availability and scope. We prioritise the issues with the greatest effect on release readiness, then compare builds and run regression checks. A late optimisation pass still needs time for testing.
We can investigate sustained CPU and GPU load, rendering, physics and other expensive work on real devices. Changes may include reducing repeated work or adjusting frame-rate and quality settings, with longer sessions used to assess the effect.
You receive the agreed code and asset changes, before-and-after measurements for the tested scenarios and notes on remaining risks. We can also help establish benchmarks for future releases so new regressions are easier to spot.

Legacy Game Modernisation

View Service Page →
We assess the available source, playable builds, assets, dependencies and target platforms. The estimate separates investigation, rebuilding or upgrading, content recovery and testing. A scoped audit can establish the migration plan before you commit to implementation.
Sometimes. We first assess the published files, playable build and recoverable assets. In a previous role, David rebuilt the Great Fire of London game in HTML5, using the original Flash game as the reference. The appropriate technology and feasibility depend on your project.
Yes. We rebuilt Nub from native Java in Unity. We use the original game as a behavioural reference and adapt controls and systems for the target platforms.
An upgrade retains the Unity project and adapts its code, assets and dependencies to a newer version. A rebuild recreates the experience on new foundations. We compare what can be retained, the risks and the maintenance needs before recommending either approach.
The version gap is only part of the work. Custom rendering, abandoned plugins, networking, save data and platform testing can all extend the timeline. We review those dependencies and provide a project-specific migration sequence and estimate.
We assess those decisions separately. Intermediate upgrades can help isolate breaking changes across a large version gap. A render pipeline change adds its own material, shader and lighting work, so we only include it when the project requirements justify it.
We check the versions and compatibility of your actual dependencies against the target Unity release. Where a plugin is unsupported, we identify whether it can be updated, replaced or removed and include that work in the plan.
Yes. We agree gameplay and save-data checks, release monitoring and rollback procedures around the live service. A staged release may be appropriate where the platform and infrastructure support it.

Game Porting Services

View Service Page →
A non-Unity game may need rebuilding rather than a direct port. We assess the source, assets and original behaviour before recommending an approach. See our legacy game modernisation service for engine migrations.
The timeline depends on the source project, touch controls, interface changes, dependencies and device performance. A feasibility review establishes what can be retained and gives you a range specific to the game, including testing and release preparation.
We can include build preparation, technical submission support and review feedback in the porting scope. We agree who owns the accounts, listing assets, policy declarations and final release decision.
We have not shipped a console title, so we assess console requests individually. Platform access, development hardware and certification expertise need to be established before we commit. We will be direct if a specialist console porting studio is a better fit.
You receive the reasoning in writing, including the technical constraints and any alternative scope worth considering. The report is yours to keep and use when deciding whether to proceed, defer the work or brief another team.
Potentially. Account systems, matchmaking, game versions, platform rules and the networking architecture all affect feasibility. We review those dependencies and scope cross-platform play explicitly.

App Store Launch Support

View Service Page →
Yes. Share the rejection notice, build version and review correspondence. We assess the stated issue, explain the changes required and scope the fixes and resubmission work. Approval and review timing remain with Apple or Google.
The estimate depends on the stores, build condition, purchase systems, listing assets and any unresolved review issues. We agree who supplies the copy, artwork and declarations, and which submission and post-launch tasks are included.
Yes. We can help with relevant keywords, store descriptions, screenshots and previews, using available listing data to identify changes worth testing. ASO can improve how clearly a listing presents the game; it cannot guarantee a ranking or number of downloads.
Your organisation should own the developer accounts and store listings. You grant the access needed for the agreed work, retain control of the release and provide the business and policy information required for submission.
Yes. We can configure test tracks, distribute builds and help collect and prioritise feedback before submission. We agree the testers, devices and acceptance criteria with your team.
We start with the build or source project, target stores, account access and release plan. We also review the available icons, screenshots, descriptions, privacy policy, audience information and purchase details, then identify anything missing.
We can scope Steam build preparation and store setup separately from mobile submission. Tell us what is already configured and whether you need technical release support, listing assets or both.

Multiplayer & Network Engineering

View Service Page →
Potentially, but it can require changes to gameplay state, saving, input and scene architecture. We review the codebase and intended online experience before estimating the conversion.
We assess the authority model and hosting approach against the genre, player count, latency, security needs and running costs. Dedicated servers, relay services and peer-hosted approaches have different trade-offs.
We review the game requirements, existing code and team needs. Our work includes FishNet architecture on Domi Online, and we can assess other Unity networking options where appropriate. See our FishNet work.
We agree expected sessions and player behaviour, then use repeatable load scenarios to measure server, network and persistence bottlenecks. Test results apply to the measured configuration; a player count from another game is not a capacity guarantee.
Yes. We can scope monitoring, updates and incident investigation through our LiveOps service. Coverage hours, response targets and any on-call support are agreed separately.

Unity Game QA and Testing

View Service Page →
We agree the build, features, target devices, testing depth and release window. You receive a test plan with the expected coverage and reporting. A focused release check and ongoing testing through production have different requirements.
We agree specific iOS, Android, Windows or browser coverage during scoping. The list should represent your target audience and minimum requirements. Any specialist hardware or devices you need to supply are identified before work begins.
Some functional and compatibility checks can run against a build. Source access allows deeper Unity profiling, component-level investigation and automated tests. We agree access according to the testing work required.
It depends on the feature set, device matrix, number of builds and time needed to verify fixes. We estimate the pass from a test plan and allow for retesting, rather than assuming every mobile game needs the same number of days.
We can check relevant mobile and PC release requirements and help with submission preparation. We have not shipped a console title; console certification requests need a separate assessment and may require a specialist partner.
Yes. We can add Unity tests and build checks for repeatable risks such as saving, loading and core systems. Automation complements manual gameplay and real-device testing, with scope based on the project.
Reproduction steps, the build and device tested, expected and actual behaviour, severity and supporting evidence where available. We also summarise coverage, unresolved issues and the risks relevant to your release decision.

Educational Institutions

View Industry Page →
We work directly with your subject matter experts from day one. Every gameplay mechanic, challenge, and reward loop is mapped to specific learning objectives in your curriculum framework. We produce a detailed Game Design Document (GDD) that links each feature to measurable learning outcomes before development begins.
We design around the audience, data collected and requirements confirmed by the institution. For children's titles, that can include data minimisation, age-appropriate consent flows, high-privacy defaults and careful review of third-party SDKs. Legal and compliance requirements are agreed with the client rather than assumed to apply identically to every project.
Share the devices, operating systems and browsers your institution uses. We assess their suitability and agree a supported hardware list before development, then test against that list. If a device cannot support the planned experience, we discuss changes to the scope or hardware before you commit.
Teachers see real-time dashboards showing each learner’s progress, quiz scores, and time-on-task. Administrators can export aggregated data for reporting. We connect to your existing LMS so there’s no separate login or manual data entry required.
We understand institutional procurement. We can work with purchase orders, provide W-8BEN/W-9 forms for international clients, accommodate multi-stage approval processes, and deliver against milestone-based contracts. We have experience working with university procurement departments and public sector frameworks.
Yes, this is one of our specialities. Our team has converted Flash-based educational games to HTML5 and Unity, preserving gameplay fidelity while adding modern features like mobile support, accessibility, and LMS integration. See our Fire of London case study, David’s rebuild for London Museum in a previous role. For a full overview of our approach, see our legacy modernisation service.
Typically within 3-5 business days. Our developers are experienced at reading existing Unity codebases, adopting house coding standards, and integrating into Jira and Slack workflows. We request a brief technical onboarding document and repository access, then we're productive from the first sprint.
You do. The bespoke code we write for your project is assigned to you upon payment, while our pre-existing tools and frameworks remain ours and are licensed for use within the delivered project. We sign NDAs before accessing your codebase and do not retain copies of your proprietary code after the engagement ends.
Yes, on every engagement without exception. We sign NDAs before accessing any code, documentation, or project details. We also carry professional indemnity insurance and are ICO registered for data protection compliance. If you're working on an unannounced title, your project details stay confidential.
We're based in London (GMT/BST) but regularly overlap with US East Coast and European studios. For US West Coast clients, we can adjust schedules to ensure 4+ hours of overlap for standups and code reviews.
For ongoing co-development we work on weekly or monthly rates with transparent sprint reporting, so you only pay for capacity you use. For well-scoped features (a porting layer, a UI system, a multiplayer integration), we can also provide fixed-price quotes with milestone-based payments.
Three things. Pedigree: our lead developer worked on RuneScape Mobile at Jagex. Integration: we join your tools and processes, not the other way around. Accountability: you get a consistent team with a UK-registered company behind them, not a solo contractor who might disappear mid-sprint. Our named client projects and case studies show that model in practice.
We're honest about this one: we have not shipped a console title, and certification experience does not carry over from mobile the way the Unity engineering does. We scope console requests case-by-case and tell you upfront whether we're the right team; if we're not, we'll point you to a specialist porting house. See our game porting service for the full picture.
While we specialise in Unity, our engineering fundamentals allow us to adapt to custom C# frameworks and proprietary editor tools. However, our peak efficiency is within the Unity ecosystem, so we're upfront about that during the discovery call.

Startups & Indie Studios

View Industry Page →
Typically within 1-2 weeks. Once we have agreed scope and signed contracts, we request repository access and a brief technical onboarding document. Our developers are experienced at reading existing Unity codebases and are productive from the first sprint.
We work on paid engagements, weekly rates, milestone-based, or fixed-price per feature. We do not take equity or revenue share. This keeps the relationship clean and ensures our incentives are aligned with shipping your game on time.
We work in short sprints with clear deliverables, so you always have a shippable build at the end of each cycle. If funding changes, we can pause cleanly. You own all the code, documentation, and assets produced up to that point.
We can help you build a polished vertical slice or demo that makes a strong impression on publishers and investors. We have experience building pitch-ready prototypes that demonstrate core gameplay loops, visual quality, and technical feasibility.
You do. The bespoke project deliverables are assigned to you upon payment, while our pre-existing tools and frameworks remain ours and are licensed for use within the delivered project. We sign NDAs before accessing your codebase and do not retain copies of your proprietary code after the engagement ends.
We work across Unity 2021 LTS through the latest 6000.x releases, with experience in both URP and HDRP. For mobile-focused titles we typically recommend URP for its performance characteristics. We also have production experience with FishNet for multiplayer.
It depends on scope, platform, and complexity, so we quote after a technical assessment rather than off a price list. As a floor, prototype engagements start from £10,000 and full development projects from £15,000, both billed on a milestone basis so you are never paying for work that has not been delivered. For general benchmarks, see our cost guide and interactive estimator.
Yes. We have built rapid prototypes and MVPs in as little as 2–4 weeks. For very early-stage projects, we can work on a fixed-price basis for a defined scope, keeping the engagement focused and the budget predictable.
Our game studios page is designed for established studios that already have a development team and need to augment capacity or bring in specialist skills for a specific phase. This page is for startups and indie teams that may not have an engineering team yet and need a partner to take them from concept to launch. The service is the same senior developers and the same engineering quality; the engagement model is shaped around the stage of your company.

Corporate Training

View Industry Page →
We would scope one audience, one learning objective and a playable scenario with choices and feedback. The proposal would set out content responsibilities, supported devices, accessibility requirements, evaluation methods and review points. Additional scenarios, production artwork, integrations and support depend on the agreed scope.
Our published track record is in educational games, including an OVG project for The Language Conservancy and work for Cambridge University Press and the EU Horizon 2020 research programme during previous employment. We do not currently present a completed corporate training case study or measured workplace results. A focused pilot is a way to evaluate how our game development experience fits your training needs.
A workplace problem, an intended audience and a subject matter expert who can review the scenario and feedback. Existing training materials, examples of difficult decisions and your current assessment approach are useful. Your team also needs to identify pilot participants and confirm any IT, accessibility and data requirements.
We agree success criteria before development. Depending on the objective, evaluation might combine scenario decisions, an assessment before and after the pilot, usability observations and employee feedback. Your team can assess later retention or workplace application. We scope the reporting needed; finishing a scenario alone does not prove competence.
We would assess your target learning management system, supported standards, reporting needs and test access before committing to an integration. If the learning concept can be evaluated without that connection, a standalone pilot may be a useful first step. If integration is essential to the pilot, its feasibility and cost need to be included from the start.
We agree the accessibility requirements, supported devices, hosting and data handling with your team. Requirements such as single sign-on, private hosting or editable scenarios need to be assessed and scoped explicitly. A content management system is an option to discuss, rather than a standard part of every pilot.
We provide a proposal after reviewing the scenario, available content, visual requirements, delivery environment and evaluation needs. The proposal includes the cost, schedule, review points and dependencies on your team. Each pilot is estimated against its agreed scope.
No. The pilot is a separately scoped engagement. At the review point, you can decide whether to refine it, commission further work or stop. Any wider rollout, additional content or ongoing support would need a separate agreement.

Museums & Cultural Heritage

View Industry Page →
We treat curators as the primary stakeholder. Early workshops map your collection’s key narratives to interactive mechanics. Curators review every content milestone and sign off on historical accuracy before development proceeds. Our team has prior experience working alongside curators and historians at London Museum and with pedagogical teams at Cambridge University Press through previous employment.
Yes. We design for the hardware museums actually use, including large-format touchscreens, kiosk PCs, iPads in secure enclosures, and visitor BYOD via QR codes. We test for continuous 8+ hour daily operation and build auto-restart and remote monitoring so your front-of-house team can manage the installation without developer support.
Yes. We are experienced with grant-funded projects and can provide milestone-based deliverables, impact measurement reports, visitor engagement analytics, and the documentation frameworks these funders require. Adam has prior experience delivering against EU Horizon 2020 grant frameworks (Navigo, during previous employment), and our team is familiar with the documentation, milestone reporting, and impact measurement requirements of major UK funders including Heritage Lottery Fund and Arts Council England.
This is one of our specialities. In a previous role, our director David Edgecombe rebuilt the Great Fire of London game for London Museum, taking it from obsolete Flash to modern HTML5 and preserving all of its content. Learn more about our full process on our legacy modernisation page.
We design for the full spectrum of museum visitors: children, elderly, wheelchair users, and visitors with visual or motor impairments. All projects include WCAG 2.2 AA compliance as a minimum, with adjustable text sizes, high-contrast modes, screen reader support, and touchscreen alternatives to fine motor interactions.
Yes. We can build companion web apps or mobile experiences that extend the gallery visit, letting visitors revisit content, share highlights, or explore deeper at home. This also provides valuable post-visit engagement data for your team and extends the return on your investment beyond the physical exhibition.
It depends on your goals. Gallery kiosk interactives are best for focused, in-gallery engagement with a specific exhibit, running on museum-owned hardware for short visitor interactions. Companion apps are better for extended engagement before, during, and after the visit, running on visitors’ own devices. Many museums benefit from both. We help you decide during the initial curatorial workshop based on your collection, visitor flow, and budget.
We choose the technology based on your project requirements. HTML5/WebGL is ideal for browser-based kiosk interactives and companion web apps that need no installation. Unity is better for complex 3D exhibits and projects that may later deploy to mobile app stores. Native mobile (iOS/Android) is best for companion apps with offline functionality and push notifications. We often combine technologies across a single project.
A focused gallery kiosk interactive typically takes 10–14 weeks from curatorial workshop to installation. A companion mobile app with deeper content takes 14–20 weeks. Legacy modernisation projects (e.g. Flash to HTML5) range from 6–12 weeks depending on the complexity of the original. We provide a detailed timeline after the initial curatorial workshop.

Still Have Questions?

Can't find what you're looking for? Get in touch and we'll be happy to help.

Ask Us Directly