Games, built as live services rather than as shipped products.

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.

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.

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.

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.

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.

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.

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.