Skip to content
All services

Game development

Game Development

Unity and Unreal across PC, mobile and console in parallel. Four of our own titles shipped on Steam, Meta Quest and Xbox.

Overview

What we deliver, and how

You find out whether a game is fun by building it. A design document will not tell you.

We have shipped four titles of our own: Chosun Zombie Defense and Dancing Arrow on VR, Midnight Study on PC and mobile, Dusty Derby on PC and console. They are on Steam, Meta Quest, Xbox, iOS and Android. We ran all of them from concept through release and live operation with no client above us.

Console certification separates studios that have passed it from those that have not, because the rejection reasons are not all written down. So we know where schedules slip and what review catches. Client work follows the same order. Greybox first with no art to confirm the core loop, then the build scope is fixed from there. Skip that order and you learn the game is not fun after it is finished.

We use AI in production — concept art drafts, repetitive QA, localisation, the stretches people used to sit on for weeks. Generated output is not delivered as-is. A person makes the final call.

Changing balance needs live-ops tooling, and running an event means changing values server-side. So the game and its operations tooling are designed together.

The problem

Where projects usually start

These situations recur in outsourced development. If any apply, we recommend talking to us before kickoff.

Check whether any of these apply to the project you are preparing.

  1. 01

    Rebuilt for every platform

    Ship on PC first and bolt on mobile later, and controls and performance have to be redone from scratch.

  2. 02

    Development that ends at launch

    After release there is no way to see where players stop, so the next update is a guess.

  3. 03

    Schedules that slip at certification

    Leaving store review and rating classification to the end means one rejection costs weeks.

How it works

Prove the core loop → Design for every platform → Ship and operate

01Today

  • Fun judged from a design doc

    You find out it is not, after it is already built

  • Rebuilt for each platform

    Controls and performance retuned from scratch

  • Certification left until the end

    One rejection pushes launch out by weeks

02What we deliver

  • Grey-box prototype

    Core loop checked before any art

  • Designed multiplatform from day one

    Input, resolution and certification decided at kickoff

  • Requirements checked every build

    Store rules and rating classification verified automatically

03After delivery

  • PC, mobile and console together

    Handled from one codebase

  • Operations driven by metrics

    Drop-off points and progression recorded

  • Balance changed from the server

    Events open without shipping a build

  • Unity · Unreal
  • Game servers
  • Four of our own IPs shipped

Built so you can still change it after launch

Our approach

How GENIESOFT responds

One response to each of the three situations above.

  1. Before
    Work split per platform
    After
    one project

    PC, mobile and console are planned as one project, with controls and resolution handled at design time.

  2. Before
    Updates decided by instinct
    After
    operations decided by what the data shows

    Drop-off points and progression are recorded, so you can see which stage is too hard and fix it.

  3. Before
    Certification prepared last
    After
    prepared while building

    Store requirements and rating criteria are settled at kickoff and checked automatically on every build.

Project flow

How a project runs

The actual sequence a project moves through, step by step.

  1. 01

    Prototype

    Greybox first, no art. This is where we decide whether the core loop actually works.

  2. 02

    Art and production

    The same level gets its art pass. AI-drafted assets shorten each iteration.

  3. 03

    Launch and live ops

    We ship to PC, mobile, and console and watch the metrics, with events and balance changeable server-side.

Typical projects

Where this applies

The kinds of projects we are most often asked to take on in this field.

  • 01

    Casual and hyper-casual

    Genres where the core loop must be validated fast. We read metrics from a prototype before fixing the build scope, using AI-drafted assets to shorten each cycle.

    Before
    Fun is unknown until it is finished
    After
    Validated by prototype metrics first
  • 02

    Multiplayer and game servers

    Projects hinging on concurrency, matchmaking, and sync. Server design decides the lifespan more than the client, so we fix load assumptions before starting.

    Before
    Servers buckle after launch
    After
    Load assumptions fixed before starting
  • 03

    PC and console

    Shipping one codebase across platforms means different input, resolution, and certification paths. Deciding which platform ships when — at kickoff — keeps the architecture stable.

    Before
    Rebuilt for each platform
    After
    One codebase across PC, mobile, and console

FAQ

Common questions

Questions we often receive while clients are evaluating a project.

Can we start without a design document?

Yes — we can start at the design stage. Scope tends to drift here, so we recommend validating the core loop with a prototype before fixing the build scope.

Do you handle operations after launch?

Yes. Because we design the live-ops tooling alongside the game, your team can run it after handover, or we can continue under a maintenance agreement.

Who handles store submission?

We handle review response and final builds. The store account must be in your company’s name, so account creation is on your side.

Principles

What is different

Problems clients commonly hit with outsourced development, and what we do about each.

What is different
Common problemOur approachWhat changes
"Done" means different things to each side, and it surfaces at handoverDeliverables and acceptance criteria are agreed in writing before kickoffNothing left to argue about at acceptance
Progress is reported on paper; the real thing appears only at the endWe show working software every two weeksA wrong turn is caught within two weeks
Once delivery is done, the vendor goes quietDeployment procedures and incident runbooks are handed over with the codeOperation continues even when staff change
Cross-domain work needs multiple vendors, and blame moves between themXR, AI, web and app, and games sit in one organizationOne contract, one party accountable

Responsibilities

Who does what

What we do at each stage, and what you confirm. Most delays come from late confirmation, so we make both sides explicit before kickoff.

Who does what
StageGENIESOFTClientDeliverable
01ScopingRequirements analysis, feasibility review, scope and schedule estimationConfirm priorities, share budget rangeProposal and quote
02DesignScreen design, data modelling, prototypes for risky areasReview and approve the designDesign document and prototype
03BuildTwo-week iterations, demo every other week, progress updatesFeedback on demos, hand over content and source materialWorking build and source code
04AcceptanceAcceptance testing support, defect fixes, staff trainingVerify against acceptance criteria and sign offAcceptance record and operations manual
05OperateWarranty support, incident response, maintenanceAssign an operations contactDeployment procedures and incident runbooks

Contact

Start your project

Requirements still taking shape? That's fine. An engineer reviews your inquiry and replies within two business days.

  • No brief needed
  • Scope and timeline reviewed first
  • Reply within two business days