Game Development: Unity vs Unreal, and What Shipping Actually Takes

The Gulf games market, at a general level

Games have moved from a hobby industry to a policy priority in the Gulf. Saudi Arabia and the UAE have both made public commitments to build local games sectors, and there is visible investment in studios, esports venues, tournaments and publishing. You do not need a fabricated statistic to see the direction of travel — it is enough to note that governments here are actively funding an industry that was, a decade ago, mostly an import.

Practically, the supporting conditions are better than they were: local talent is easier to find, publishers and platform holders take the region seriously, and Arabic localisation is now expected rather than optional. It also means competition. A regional audience does not lower the bar; players in Riyadh and Dubai play the same global titles as everyone else and judge yours against them.

What a game is worth to a business

Not every game is a commercial game. Before the engine argument, be clear which of these you are building, because each has a different definition of success.

• A product. The game is the business. Revenue comes from purchases, subscriptions or advertising, and success is measured in retention and lifetime value.
• A marketing surface. A branded game that earns attention and dwell time no advertisement can buy. Success is measured in reach, brand recall and the cost per engaged minute compared with media spend.
• A training or simulation tool. Game engines are simply the best real-time 3D tooling available. Safety training, equipment simulation and process rehearsal all use the same technology, and success is measured in competence and reduced incidents.
• A sales instrument. Real-time configurators and walkthroughs for property, manufacturing or retail. This overlaps closely with the interactive work we do on custom applications and with property products like our real estate CRM.
• An engagement layer. Gamified progression inside an existing app. Cheaper than a game, and often the right answer when the objective is retention rather than revenue.

Naming this early prunes the decision tree. A training simulator does not need live ops. A branded marketing game does not need an economy. A live-service product needs both, designed in from day one, because retrofitting them is close to a rewrite.

Unity vs Unreal: an honest comparison

Both engines can build almost anything. The differences are about where the friction sits, and friction is cost. Here is how the two compare on the axes that have actually mattered on our projects.

Licensing terms for both engines have changed more than once in recent years, and both vendors reserve the right to change them again. Confirm the current terms against the vendor's published licensing page before you commit a budget — never against a blog post, including this one.

Our default heuristic: if it is a 2D or stylised 3D mobile game, start with Unity. If photoreal rendering on PC or console is the product, start with Unreal. If it is a simulation or visualiser where the client will judge it on how real it looks, Unreal. If it is a mid-core mobile title with heavy live ops, Unity, because the tooling around the game matters more than the pixels in it.

Mobile versus PC and console

The platform decision is bigger than the engine decision and often gets made by accident. Mobile is the largest audience and the harshest engineering environment: a thermal budget, a battery, a device matrix running from flagship silicon to three-year-old mid-range Android, and store review on both sides. A game that runs beautifully on the developer's iPhone and stutters on the phone most of your players actually own is a failed game. We treat a cheap Android device as the target, not a compatibility afterthought — the same discipline we apply to ordinary Android and iOS development.

PC and console reverse the constraints. The hardware is known, the thermal budget is generous, the fidelity ceiling is high. In exchange you take on platform certification — a real process with real timelines — and a market where players expect a complete experience rather than a first session that hooks them. Certification is a schedule risk to be planned as work, not treated as a formality at the end.

The art pipeline is the schedule

On most games that miss their date, the code was not the bottleneck. Art was. Art volume is what turns a six-month game into an eighteen-month game: every character, environment, animation and effect has to be modelled, textured, rigged, reviewed, revised, then optimised for the target device — and the optimisation pass is the one everyone forgets to budget.

Three things keep it under control. Fix the art style before production, and choose one your team can execute at volume — stylised art is not a compromise, it is a schedule decision, and it ages better than mid-tier realism. Build the pipeline as software: naming conventions, import automation, a validation step that rejects over-budget assets before they reach the build. And set polygon, texture and draw call budgets on day one, because retrofitting budgets onto a finished art set means redoing the art set.

Multiplayer and netcode reality

Multiplayer is the feature most often underestimated, usually because a prototype works on a local network and everyone concludes the hard part is done. It is not. The hard part is latency, packet loss, cheating, and the fact that two players will always disagree about what just happened.

Roughly: turn-based and asynchronous games are cheapest and can often run on ordinary backend services rather than a game server. Real-time games need an authoritative server, because any logic you trust the client with will eventually be abused. Authoritative play then forces client-side prediction and server reconciliation — genuinely difficult engineering that touches every gameplay system you have already built. Netcode is an architecture decision, not a feature to add in month eight.

Geography matters more here than most teams expect. Players in Riyadh, Jeddah or Dubai connecting to a server in Frankfurt feel the round trip, and in a competitive game they feel it as unfairness. Hosting close to your players in UAE or Bahrain cloud regions is a gameplay decision disguised as an infrastructure one — where our AWS and Azure work overlaps directly with game delivery.

Live ops: the game starts at launch

For any commercial live-service game, launch is the beginning of the work rather than the end. Live ops is the ongoing practice of running the game: events, seasons, content drops, economy tuning, experiments and player support. It is what separates a game with a long tail from a game with a launch spike and a graph that only goes down.

• Remote configuration. Balance values, drop rates, event schedules and feature flags must be changeable without an app store release. If a balance fix takes a week of review, you cannot run a live game.
• A content pipeline that skips the client build. New events, offers and cosmetics should be data, delivered over the air.
• Analytics you actually trust. Funnels, retention cohorts, economy sinks and sources. Instrument this before launch — you cannot analyse events you never recorded. Our data analytics and business intelligence practice does exactly this work in other sectors.
• Experimentation. A/B testing infrastructure, so tuning decisions are evidence rather than opinion.
• Support tooling. Customer service needs to look up a player, see their inventory, and grant compensation. Without this, every incident becomes an engineering task.

Monetisation without wrecking the game

The models are well understood: premium purchase, in-app purchases, battle passes and subscriptions, advertising with rewarded video. What is less well understood is that the model constrains the design, so it must be chosen early. A premium experience does not become a free-to-play economy by adding a shop; the pacing, progression and session length are all different.

Two things worth saying plainly. First, regulation around loot boxes and randomised rewards is tightening in multiple markets, and the details vary by jurisdiction; if random rewards are central to your economy, take legal advice for each market you enter rather than assuming a global standard. Second, aggressive monetisation reliably shows up in retention before it shows up in revenue, and by the time it shows up in revenue the players are already gone. The economies that last are the ones where paying is an accelerant, not a toll gate. The same commercial plumbing — payments, entitlements, receipts, refunds — is the work we do on e-commerce and SaaS platforms, and it deserves the same rigour in a game.

How Inovsion helps

We are a software engineering company, and we are honest about that: we are not an art-led creative studio, and if your need is primarily art direction you should hire for it directly. What we bring is the engineering that sits under and around a game, plus a track record in interactive, real-time and device-connected systems.

That record is relevant in specific ways. ClueMaster is IoT-enabled software for managing escape rooms across multiple locations — real-time state, physical devices, live sessions, operators who need it to work with an audience in the room. FameKeeda connects fans with celebrities and influencers: engagement mechanics under load. OneTuch spans logistics, carpooling, transport and medical emergency workflows — real-time coordination where latency has consequences. None are games. All exercise the same muscles a game needs.

• Prototype first. We would rather build a small playable slice and let it tell you what the game costs than write an estimate against a document nobody has played.
• Engine advice you can check. A written Unity versus Unreal recommendation for your specific title, with the reasoning exposed, not a house preference dressed up as analysis.
• Backend and live ops. Accounts, inventory, economy services, remote config, event scheduling and support tooling — built on AWS or Azure in a region close to your players.
• Analytics and experimentation. Instrumentation, cohorts and dashboards, so live ops decisions have evidence behind them.
• Design and interface. Our UI/UX practice covers Arabic and right-to-left layouts, which matters for menus, stores and onboarding in this region.
• Release engineering. Build pipelines, device testing on real mid-range hardware, store submissions and the certification grind.
• Working alongside your team. A common shape is that you own design and art while we take the platform, the services and the release process.

We work with clients in the UAE, Saudi Arabia and India, and we are used to Saudi compliance requirements — we have delivered an ERP-integrated ZATCA e-invoicing solution, which matters if your game entity invoices in the Kingdom. If you want a straight answer about whether your idea is a three-month prototype or a three-year programme, tell us about it and we will say so.