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.
Scope of work
- PC, mobile, and console
- Casual and hyper-casual
- Multiplayer networking and game servers
- AI-assisted asset and QA pipeline
- Serious games and simulations
Deliverables
- Game design and level design documents
- Client and server source code
- Source art assets
- Live-ops tooling and admin interface
- Store submission support and final builds
Technology
- Unity
- Unreal Engine
- C#
- C++
- Photon
- Steamworks
The problem
Where projects usually start
These situations recur in outsourced development. If any apply, we recommend talking to us before kickoff.
- 01
Rebuilt for every platform
Ship on PC first and bolt on mobile later, and controls and performance have to be redone from scratch.
- 02
Development that ends at launch
After release there is no way to see where players stop, so the next update is a guess.
- 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
Today
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
- 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.
- 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.
- 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.
- 01
Prototype
Greybox first, no art. This is where we decide whether the core loop actually works.
- 02
Art and production
The same level gets its art pass. AI-drafted assets shorten each iteration.
- 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
Work
What we built here
Projects GENIESOFT has delivered in this field.
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.
| Common problem | Our approach | What changes |
|---|---|---|
| Acceptance criteria need to be agreed before kickoff | Deliverables and acceptance criteria are agreed in writing before kickoff | Acceptance is checked against the agreed criteria |
| Working software and progress need regular review | We show working software every two weeks | Demo feedback informs the next development steps |
| The operations team needs reference documentation | Deployment procedures and incident runbooks are handed over with the code | Operating procedures are documented for reference |
| Some projects require several technical disciplines | XR, AI, web and app, and games sit in one organization | Schedules and integration scope are coordinated across disciplines |
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.
| Stage | GENIESOFT | Client | Deliverable |
|---|---|---|---|
| 01Scoping | Requirements analysis, feasibility review, scope and schedule estimation | Confirm priorities, share budget range | Proposal and quote |
| 02Design | Screen design, data modelling, prototypes for risky areas | Review and approve the design | Design document and prototype |
| 03Build | Two-week iterations, demo every other week, progress updates | Feedback on demos, hand over content and source material | Working build and source code |
| 04Acceptance | Acceptance testing support, defect fixes, staff training | Verify against acceptance criteria and sign off | Acceptance record and operations manual |
| 05Operate | Warranty support, incident response, maintenance | Assign an operations contact | Deployment procedures and incident runbooks |
- [email protected]
- PHONE
- 0507-1301-7163