--- title: Game Development and Interactive Media description: url: https://miracuves.com/industries/gaming-interactive date_modified: 2026-08-17 author: miracuves language: en_US --- # Games, built as live services rather than as shipped products. Core loop, netcode and economy engineered together, because a game that launches is a game that starts, and everything that decides whether it survives happens after that. We build for studios and we publish our own titles, which means we run these decisions on our own money as well as yours. [Talk to an engineer](https://miracuves.com/schedule-consultation/) [See the capability](#capability) How this sector is served **3**Dedicated practices **8**Operator types served **Scoped**Quoted in writing **6**Engine and immersive practices Engagement modelCustom, every time Source codeYours, in full EnginesUnity and Unreal Support, fixes, updates60 days, 6 and 12 months *We build for studios and publish our own* · the same team does both Custom engineering programme Where a product would normally sit Custom programme - scoped and quoted in writing Concept and engine Core loop Netcode Economy Live ops Certification No off-the-shelf track in this sector There is no ready-made track in this sector, so every engagement is a custom programme, scoped and quoted in writing before anything starts. Custom builds elsewhere on this site run two to eight weeks; work at this scale is quoted beyond that. Every figure on this page is defined on our [facts page](https://miracuves.com/facts/). ## What a game build actually contains The sequence below is where games are won or lost. Unlike most sectors on this site, none of it starts from a shipped product, and the page is written accordingly. The most expensive misunderstanding in this sector is treating launch as the finish line. A game that ships is a game that begins: the retention curve, the economy balance and the content cadence all start on day one and all decide whether the thing survives its first quarter. Studios that budget for a build and not for a year of operation produce games that work and then quietly stop being played. There is no shortcut track here. What varies is scope and platform, and both are settled in the first phase rather than assumed. At a glance Phases7 Shipped-product shortcutNone in this sector Launch isThe start, not the finish Budget forA year of operation **01**Weeks 1-4 ### Concept, engine and platform targets Engine choice is a real decision rather than a preference, and it is largely settled by what you are building. Unity suits mobile, mid-scale and rapid iteration, with a larger pool of developers and a lighter footprint. Unreal suits high-fidelity visuals and larger worlds, at the cost of a heavier pipeline and a narrower hiring market. Platform targets constrain everything downstream. Mobile means device fragmentation, thermal limits and store rules. Console means certification cycles measured in weeks and a submission process that will reject you for things unrelated to your game. Deciding to add a platform later is significantly more expensive than deciding now. The output is a technical direction with the engine chosen for stated reasons, target hardware named, and the certification calendar understood before anything is scheduled around it. Engine rationaleTarget hardwareStore rulesCertification calendar No shortcut. Engine and platform decisions propagate into every later choice, and reversing one mid-project is close to restarting. **02**Weeks 4-10 ### The core loop, playable early The single most useful thing a game project can produce early is a loop somebody can play. Not a vertical slice with final art, not a design document, but the thirty seconds a player repeats and either enjoys or does not. Everything else is decoration on top of that judgement. This phase exists to find out whether the loop is fun while changing it is still cheap. Studios that defer playability until art is finished discover their loop problems at the point where fixing them means discarding work. Feel is engineering rather than design polish: input latency, animation responsiveness and camera behaviour are what separate a game that feels good from one that reads well on paper. Playable loopInput latencyGrey-box iterationEarly testing **Capability**Engine engineering in Unity or Unreal, from prototype through production.[Unity 3D](https://miracuves.com/service/unity-3d-development/) · [Unreal Engine](https://miracuves.com/service/unreal-engine-development/) **03**Weeks 8-16 ### Netcode, and the assumption that the client lies Any game where players compete for something of value will be attacked, and the only defence that holds is architectural: the server decides, the client displays. A client that reports its own score, position or inventory is a client that will eventually report whatever its owner wants it to. Authoritative servers cost latency, which is the tension in this phase. Prediction and reconciliation hide that latency from the player while keeping the server as the source of truth, and getting the balance right is most of the engineering in a competitive game. Matchmaking, session management and reconnection belong here too. A player disconnected mid-match who cannot rejoin has lost more than a match, and in competitive play that determines whether they return at all. Server authorityPredictionMatchmakingReconnection **Capability**Multiplayer architecture with authoritative servers, prediction and session handling.[Game development](https://miracuves.com/service/game-development/) **04**Weeks 14-20 ### Economy, monetization and where regulation starts A virtual economy is a real economy with rules you set, and the same failure modes apply: inflation from unchecked currency generation, dead sinks, and secondary trading you did not intend. Economy design needs modelling before launch and monitoring afterwards, because a broken economy is difficult to repair without damaging the players who invested in it. Monetization is where legal exposure appears. Randomized paid rewards are regulated or banned in a growing list of jurisdictions, several require disclosed probabilities, and treatment differs sharply where minors can spend. This is a compliance question that belongs in design rather than a disclosure added before submission. Real-money gaming is a different category entirely, with licensing, age verification, responsible-play obligations and payment arrangements that resemble financial services more than games. If that is your model, say so in the first call. Currency sinksProbability disclosureMinor spendingLicensing position No shortcut. Monetization compliance depends on your jurisdictions and your audience's age, and both are yours to establish before design is finalized. **05**Weeks 18-24 ### Content pipeline and live operations The pipeline is what determines whether your team can ship content weekly without an engineer in the loop. Designers adding levels, items and events through tooling rather than through code is the difference between a live game and a game that receives occasional patches. Remote configuration matters as much. Tuning values, enabling events and adjusting drop rates without a store submission is essential, because store review time means a balance problem discovered on Friday cannot wait for approval. Telemetry is the other half: knowing which level players quit at, which item nobody buys and where the difficulty spike sits is what makes live operation a decision rather than a guess. Designer toolingRemote configTelemetryEvent scheduling **Capability**Content pipelines, remote configuration and telemetry for live operation.[Game development](https://miracuves.com/service/game-development/) **06**Weeks 22-26 ### Certification, store submission and player safety Store and console certification will reject a game for reasons unrelated to whether it is any good: metadata, age rating, accessibility declarations, crash rates on specific hardware, and handling of interrupted purchases. Building against those requirements from the start is far cheaper than discovering them at submission. Player safety is part of this rather than adjacent to it. If your game has chat, it needs moderation, reporting and blocking, and if minors can play, the standard is higher: default-restricted communication and no unlogged private channels between adults and children. Age ratingCrash thresholdsChat moderationMinor protections No shortcut. Certification runs on the platform holder's calendar, not yours, and building a schedule that assumes first-time approval is how launch dates move. **07**Weeks 26-28 ### Launch and the first live period Soft launch in a limited market with real players and real spending, because retention and monetization behaviour cannot be predicted from testing. The numbers from a soft launch decide whether the game is ready to scale or needs another cycle, and that decision is cheaper made before marketing spend. Day two here is the live period: the first event, the first balance change, the first exploit found by players who are better at finding them than any test team. Sixty days of dedicated support, six months of priority bug resolution, twelve months of updates. Soft launchRetention curveFirst eventExploit response No shortcut. A game is judged on its retention curve, and that curve only exists once real players have had a fortnight with it. Want any of these phases costed against your concept and platform targets? [Book a technical call](https://miracuves.com/schedule-consultation/) ## Why the server decides and the client only draws Every game where something of value can be won will be attacked, usually within days. The defence is not obfuscation or detection, it is deciding at the outset which machine is allowed to be right. At a glance TrustedThe server, only The client isUntrusted input and a display CostLatency, hidden by prediction Retrofit costClose to a rewrite **Client-server authority**What each machine is allowed to decide Player deviceYour servers Input sentIntent, never outcome Predicts locallySo it feels instant ReconcilesServer wins any disagreement Simulates and decidesPosition, score, inventory, reward Validates every actionWas this even possible? Records the authoritative stateThe only version that counts What a client-authoritative game learns, usually in week one Scores that cannot happen, inventories that were never earned, and a leaderboard nobody believes Client, untrustedServer, authoritative Prediction is what makes authority tolerable. The client shows the result immediately and corrects if the server disagrees, so the player gets responsiveness without the game trusting their machine. Building it the other way and adding anti-cheat later is close to a rewrite of the game loop. ### Why the economy needs sinks before it needs sources Every game economy starts by giving players currency, because rewarding people is the easy half. The half that gets deferred is removing it again, and an economy with generous sources and weak sinks inflates in exactly the way a real one does: prices rise, early rewards become meaningless, and new players arrive into a world where the currency they earn buys nothing. Sinks are the design problem rather than the engineering one, but the platform has to make them measurable. Knowing how much currency enters the world per day, how much leaves, and where it accumulates is what turns economy management into a decision. Without that instrumentation the first sign of trouble is usually a player forum explaining the problem to you. At a glance SourcesEasy, and usually generous SinksDeferred, and then urgent SymptomNew players earn nothing of value RequiredDaily in, out and held Want your netcode or economy model reviewed before it is built? [Talk to an engineer](https://miracuves.com/schedule-consultation/) ## Eight operators, eight different programmes "Games" is not one buyer. The regulatory position, the technical demand and the definition of success change completely between them. At a glance Operator types8 Served by a shipped productNone EngagementCustom, every one ### Mobile free-to-play Retention and monetization decide everything, device fragmentation constrains the technical ceiling, and the economy is the product as much as the gameplay is. Custom programme ### Premium and console Paid once, judged on finish quality, and gated by certification cycles measured in weeks. The business risk concentrates entirely at launch rather than spreading across a live period. Custom programme ### Real-money gaming Licensing, age verification, responsible-play obligations and payment arrangements closer to financial services than to games. A different regulatory universe, and one to declare in the first call. Custom programme ### Competitive multiplayer Authoritative servers, matchmaking quality and anti-cheat as continuous operations rather than features. Latency tolerance sets the architecture and the hosting footprint. Custom programme ### Social and casual Broad audiences, short sessions and social mechanics driving acquisition. Technically lighter, and unforgiving about friction anywhere in the first minute. Custom programme ### AR and location-based The physical world as the play space, with location accuracy, safety considerations and a battery budget that constrains what the game can do. Custom programme ### Virtual worlds Persistent shared spaces with user-created content, which brings moderation, storage and an economy that behaves like a marketplace rather than a game loop. Custom programme ### Simulation and training Games built to teach or assess rather than to entertain, where the buyer is an organization and success is measured by transfer to real performance. Custom programme None of the eight starts from an off-the-shelf product, because games are built rather than adapted. What we bring is engine engineering, multiplayer architecture and the live-operations capability below, applied to client titles and to our own. Not sure which of these you are, or you sit across two of them? [Book a scoping call](https://miracuves.com/schedule-consultation/) ## How the work actually runs Six stages. Unlike every product-backed sector on this site, there is no second track, so the stages describe the only path there is. At a glance Stages6 TracksOne Earliest real signalA playable loop 01Stage ### Scoping against platform, audience and money model We start from where it will be played, who is playing, and how it earns, because those three decide the engine, the architecture and the regulatory position before any creative preference does. A free-to-play mobile title and a real-money game share almost no assumptions beyond the word game. **Ends with**Written scope: engine and rationale, platform targets, monetization model and the regulatory position that follows from it. 02Stage ### Architecture around authority and iteration Server authority is decided here rather than discovered later, because retrofitting it is close to a rewrite of the game loop. Alongside it, the content pipeline is designed so designers can add and tune without an engineer, since that is what determines whether the game can be operated after launch. **Ends with**An authority model, a content pipeline designers can use, and remote configuration for anything that needs tuning live. 03Stage ### Build against real player conditions Games fail on conditions test environments rarely reproduce: a mid-range device three years old, a mobile connection that drops for eight seconds, a player who force-quits during a purchase, and another who is actively trying to break the economy. All of that is in the test profile, because the alternative is meeting it on launch day. Scope varies by platform **Ends with**Test coverage on mid-range hardware, unstable connections, interrupted purchases and adversarial player behaviour. 04Stage ### Compliance, safety and security validation Age rating, probability disclosure where randomized rewards are sold, spending controls where minors can play, and chat moderation where players can talk. Our work arrives with a VAPT and compliance document, so external review starts from a documented baseline. **Ends with**A VAPT and compliance document, age rating secured, disclosures in place and moderation proven before submission. 05Stage ### Soft launch and economy tuning A limited market with real players and real spending, watched for retention shape and economy behaviour. This is where the numbers decide whether to scale or to iterate again, and that decision is far cheaper before marketing spend than after it. **Ends with**A retention curve from real players, an economy observed under real spending, and a scale-or-iterate decision. 06Stage ### Launch and the first live period Store submission with certification time built into the schedule, then the live period: first event, first balance change, first exploit. Sixty days of dedicated support, six months of priority bug resolution, twelve months of updates. **Ends with**Sixty days dedicated support, six months priority bug resolution, twelve months of updates. Want this sequence mapped against your concept and launch window? [Book a technical call](https://miracuves.com/schedule-consultation/) ## What we bring to this sector There is no shipped game here, so this section replaces the product catalogue you will find on our other industry pages. These are the practices this work draws on, each one we staff rather than a capability we claim. There is no clone catalogue here because games are not adapted from a template the way a marketplace can be. What exists instead is a practice that both builds for studios and publishes its own titles, which matters more than it sounds: the decisions on this page about authority, economy design and live operations are ones we carry on our own releases, not only on client work. At a glance Dedicated practices3 Adjacent practices3 Own titlesPublished, and more in build ### Game development Core loop, gameplay systems, tooling and the live-operations infrastructure that keeps a game running after launch rather than merely shipping it. [Game development](https://miracuves.com/service/game-development/) ### Unity 3D Mobile, mid-scale and rapid-iteration work, with the broader developer pool and lighter footprint that suits most free-to-play and casual titles. [Unity 3D development](https://miracuves.com/service/unity-3d-development/) ### Unreal Engine High-fidelity visuals and larger worlds, where the heavier pipeline is justified by what is being rendered and the hiring market is narrower but deeper. [Unreal Engine development](https://miracuves.com/service/unreal-engine-development/) ### AR development Location and camera-based play in the physical world, with the accuracy, safety and battery constraints that come with leaving the screen. [AR development](https://miracuves.com/service/ar-app-development/) ### VR development Immersive experiences where comfort and frame stability are correctness requirements rather than quality settings, because failing them makes people ill. [VR app development](https://miracuves.com/service/vr-app-development/) ### Metaverse and virtual worlds Persistent shared spaces with user-created content, where moderation and economy behave like a marketplace rather than a game loop. [Metaverse development](https://miracuves.com/service/metaverse-app-development/) Want to know which of these your title actually needs? [Book a scoping call](https://miracuves.com/schedule-consultation/) ## Randomized paid rewards are a legal question before a design one Selling a chance rather than an item is regulated differently across markets, banned in some, and treated far more strictly wherever minors can spend. This belongs in design, not in a disclosure added before submission. At a glance Positions across markets4 Where minors can spendStricter, everywhere Decided inDesign, not submission Real-money gamingA separate universe **Monetization and the regulatory line**Where a model sits, and what each position requires Lower exposureHigher exposure Direct purchase You buy the item you see.Simplest position everywhere. Battle pass Known rewards on a knowntrack. Widely accepted. Randomized rewards Disclosure required in severalmarkets, banned in others. Real-money gaming Licensing, age checks,responsible play, KYC. What changes when minors can spend Parental controls and spending limits move from optional to expected Randomized purchases attract materially stricter treatment, and in places a prohibition Advertising and cross-promotion rules tighten, including what may be shown between sessions Age assurance stops being a checkbox and becomes something you must be able to evidence Choose the position deliberately; discovering it at submission means redesigning the economy StraightforwardRegulated, and varies by market We will build any of these, and we will tell you which markets a given model closes off. What we will not do is design an economy around randomized purchases for an audience that includes children without raising it first, because that is a conversation better had at concept than at certification. Want your monetization model checked against the markets you intend to launch in? [Talk to an engineer](https://miracuves.com/schedule-consultation/) ## What a custom programme covers Since there is no product to adapt here, this is the full scope rather than the exceptions. These are the capabilities a game programme typically includes. At a glance Capabilities6 Programme lengthScoped, quoted in writing ### Gameplay and engine work Core loop, systems and feel in Unity or Unreal, with the input latency and responsiveness that separate a game that plays well from one that reads well. [Unity 3D](https://miracuves.com/service/unity-3d-development/) ### Multiplayer architecture Authoritative servers, prediction and reconciliation, matchmaking and reconnection, built so the client is treated as untrusted from the first commit. [Game development](https://miracuves.com/service/game-development/) ### Economy design and instrumentation Sources, sinks and the daily measurement of currency entering, leaving and accumulating, so economy management is a decision rather than a reaction to a forum post. [Data engineering](https://miracuves.com/service/data-engineering-app-development/) ### Live operations tooling Designer-facing content pipelines, remote configuration and event scheduling, so the game can be tuned and extended without a store submission each time. [Game development](https://miracuves.com/service/game-development/) ### Anti-cheat and integrity Server-side validation, anomaly detection and the operational process behind them, since integrity is a continuous activity rather than a feature that ships once. [Game development](https://miracuves.com/service/game-development/) ### Immersive and location-based AR, VR and persistent shared worlds, where comfort, safety and battery constraints are correctness requirements rather than quality settings. [VR development](https://miracuves.com/service/vr-app-development/) Need something this list does not cover? [Ask about custom work](https://miracuves.com/schedule-consultation/) ## What we built, and what it delivered Three programmes in this sector, described by what was actually built rather than by a metric we cannot show you the working for. At a glance Programmes detailed here3 Competitive ### Authoritative multiplayer with prediction Server-side simulation with client prediction and reconciliation, matchmaking by skill and latency, and reconnection that returned players to a match in progress. Live operations ### Designer-driven content pipeline Levels, items and events authored without engineering involvement, with remote configuration so balance changes did not wait on store review. Immersive ### Location-based AR experience Camera and location play with accuracy handling, safety constraints on where play was permitted, and a battery budget that shaped the session length. We describe these by scope rather than by outcome metrics, because the numbers that matter to you are your own and we would rather model them with you than quote someone else's. Want to speak to a reference building something comparable? [Request a reference](https://miracuves.com/schedule-consultation/) ## Written on this sector Longer pieces on the problems above, written by the engineers who run these programmes. At a glance Articles4 [Netcode ### Why anti-cheat starts with server authority, not detection](https://miracuves.com/blog/) [Economy ### Sinks before sources, and the numbers to watch daily](https://miracuves.com/blog/) [Live ops ### Shipping content without an engineer in the loop](https://miracuves.com/blog/) [Compliance ### Randomized rewards, disclosure and where minors change everything](https://miracuves.com/blog/) If a question here is not covered, the fastest route to an answer is a call with the engineer who would run your programme. Want these as a briefing pack for your studio leadership? [Request the pack](https://miracuves.com/schedule-consultation/) We built the whole thing client-authoritative because it was faster. The leaderboard was meaningless in four days and fixing it meant rewriting the loop. The failure pattern this page is built around That gap is the whole reason this page exists. Forty client testimonials sit on the site with names, titles and companies attached, and none of them are invented. [Read all forty](https://miracuves.com/client-testimonials/) ## Questions studios actually ask The ones that come up in the first call, answered as we would answer them there. At a glance Questions answered12 Do you publish your own games? Yes, alongside client work, with more in build. It matters for a reason beyond credentials: the positions this page takes on server authority, economy design and live operations are ones we carry on our own releases, so they are opinions formed by operating games rather than only by building them. Do we own the source code? Yes, in full. No revenue share, no engine licence through us, no runtime dependency on our infrastructure. Unity or Unreal? Unity for mobile, mid-scale and fast iteration, with a broader hiring pool. Unreal for high-fidelity visuals and larger worlds. We recommend against choosing on preference, because the wrong choice is expensive to reverse mid-project. How do you stop cheating? By making the server authoritative from the first commit. Detection and obfuscation help at the margin; architecture is what actually holds, and adding it later is close to rewriting the game loop. Can our designers add content without engineers? That is a design goal rather than a nice-to-have, because a game that needs an engineer to ship an event will not be operated as a live service for long. Do you handle store and console certification? We build against those requirements from the start and support submission. Certification runs on the platform holder's calendar, so schedules assume it will take time rather than assuming first-time approval. What about loot boxes? We will build randomized rewards and tell you which markets that closes off, with probability disclosure where required. We will raise it early if minors can spend, because that changes the position significantly. Can you build real-money gaming? Yes, and it is a different regulatory universe: licensing, age verification, responsible-play obligations and payment arrangements closer to financial services. Declare it in the first call, because it changes the whole programme. How long until we can play something? A playable core loop in grey-box form within the first eight to ten weeks. Finding out whether the loop is fun while changing it is still cheap is the main purpose of that phase. Do you do live operations after launch? Yes, and we would encourage budgeting for it. Sixty days of dedicated support, six months of priority bug resolution and twelve months of updates, with longer arrangements available where a live title needs them. What if the soft launch numbers are bad? Then we say so and help you decide whether to iterate or stop. That decision is far cheaper before marketing spend, which is the entire reason for a soft launch. What if we are not ready to build yet? We will say so. If the core loop is not defined, engineering will make those decisions by default and they will be the wrong ones, so it is better to prototype the idea than to specify a game around it. Question not answered here? [Ask us directly](https://miracuves.com/schedule-consultation/) ## Tell us what you are building. Bring the concept and the platform. We will tell you honestly what it takes - including when the answer is prototype before programme. [Book a technical call](https://miracuves.com/schedule-consultation/) [Browse all services](https://miracuves.com/service/) A first call takes about thirty minutes and covers four things **01** ### The core loop What a player does repeatedly, and why they would do it again. **02** ### Platform targets Mobile, console or both, which sets engine and certification. **03** ### How it earns And whether that model is permitted in your intended markets. **04** ### Who plays Particularly whether minors can spend, which changes everything. Those four answers are usually enough for us to tell you what a first build would cover, roughly what it costs, and which regulatory position your money model puts you in. If the honest answer is that the loop needs prototyping before a programme is worth scoping, we will say that instead of quoting a game nobody has played yet.