Turnkey Midcore Mobile Game Development from Scratch
We develop midcore games that handle real-time load on devices with Snapdragon 680 and 2GB RAM. When a client expects a meta-layer with progression, guilds, and seasonal passes, casual solutions don't work. Our job is to design an architecture that scales with monetization without rewriting code. Contact us for a project evaluation.
What problems does turnkey midcore game development solve?
The most common point of failure is a progression system designed as an Excel spreadsheet rather than code. Balance is stored in ScriptableObject or local JSON, the game launches, and three months later it turns out that adding a new unit type requires rewriting four systems. We've seen projects where UnitConfig contained 47 boolean flags and all logic was built through if (isElite && hasBuff && !isFrozen). That doesn't work with 200 unit types.
The second pain point is the network layer in PvP and co-op. Using simple HTTP REST for real-time combat leads to the client and server diverging by 3-4 steps at 150ms latency. Client prediction without server validation leads to cheats. Server validation without rollback leads to jitter. We need either Photon Fusion with its state synchronization, or a custom implementation on Mirror with deterministic physics (Deterministic Lockstep), where both clients reproduce the same commands in the same order.
The third problem is memory. Unity Addressables with improperly configured groups causes the entire previous scene to remain in memory when loading a new chapter. On an iPhone 12 that's tolerable. On Android low-end with 2GB RAM — OOM and crash. You need explicit lifecycle management via Addressables.ReleaseInstance and proper bundle splitting: UI atlases separately, characters separately, environment separately. The financial risk from such crashes is losing users during onboarding.
Ensuring Stable Performance on Android Low-End Devices
For midcore projects we use Entity Component System (ECS) through Unity DOTS or Arch for game simulation, and a separate MonoBehaviour layer for UI and visual representation. Game logic (stats, buffs, AI, projectile physics) runs in ECS — this provides determinism and performance on job threads. Everything Canvas, Animator, VFX stays in Mono. ECS outperforms MonoBehaviour by a factor of 10 on large numbers of objects: tests show 2ms vs 20ms for 1000 units.
The meta-layer (inventory, progression, social) is built as a separate domain with clear boundaries. Typical structure:
GameCore/ ECS/ -- combat simulation (DOTS) Systems/ -- GameplayLoop, SpawnSystem, CombatSystem Data/ -- ScriptableObject configs + remote config via Firebase Meta/ Inventory/ Progression/ -- XP, levels, unlocks Social/ -- guilds, leaderboards (Google Play Games SDK / GameKit) Network/ Photon/ -- real-time PvP REST/ -- meta operations (purchases, saves) Remote Config via Firebase is mandatory for balance. All numeric parameters: damage, upgrade cost, drop probabilities — should be in Remote Config, not in the build. This allows patching balance without store updates. Our experience shows this approach reduces critical bugs by 40%.
Monetization: Unity IAP for in-app purchases + ironSource or AppLovin MAX for ads with mediation. Important: on iOS you need to handle SKPaymentTransactionObserver correctly — pending transactions on interrupted internet should be restored at next launch, otherwise Apple may reject the app per guideline 3.1.1. We guarantee passing review.
Why ECS is Better for Midcore Games?
ECS provides determinism and performance. In one project — a midcore strategy with 50v50 battles — on budget Android devices the CPU overheated after 8 minutes of continuous battle. Profiler showed: 6ms per frame was spent on SkinnedMeshRenderer.Update for 100 units simultaneously. The solution — GPU Instancing for static meshes + replacing Skinned Mesh with GPU skinning via Compute Shader for distant units (distance > 15 units). Close units — normal skinned mesh. Distant units — billboard or simplified animation via vertex shader. As a result, CPU render time dropped from 6ms to 1.8ms, temperature stabilized. This optimization saved us weeks of redesign work.
From our practice: for another project we used Addressables with bundle splitting, which reduced cold start to 3 seconds and avoided OOM on 2GB devices. Read more in the official Unity Addressables documentation.
How to Start Midcore Game Development with Us?
- Idea and Concept Audit — analyze the market, define target audience, form requirements.
- Core Prototype — implement basic gameplay in 4-6 weeks.
- Alpha Version Development — connect meta-systems, network layer, prepare build for testing.
- Beta Testing and Polish — fill with content, balance, integrate monetization.
- Soft Launch and Iterations — analyze metrics, refine project for global release.
What's Included
| Stage | Deliverables |
|---|---|
| Pre-production | GDD, architecture, core prototype, risk assessment |
| Alpha | Basic mechanics, meta-layer v1, network layer, test builds |
| Beta | Content, balance, monetization, LiveOps infrastructure, analytics |
| Soft launch | Metric monitoring, D1/D7/D30 iterations, release preparation |
| Support | Balance patches, updates, technical support for 3 months |
Timelines and Process
A midcore game from scratch takes 6–14 months depending on meta-systems and content volume.
| Stage | Duration |
|---|---|
| Pre-production: GDD, architecture, core prototype | 4–6 weeks |
| Alpha: basic mechanics, meta-layer v1, network | 3–5 months |
| Beta: content, balance, monetization, LiveOps | 2–4 months |
| Soft launch + metric-driven iterations | 1–2 months |
Cost estimation is done after analyzing the GDD and technical requirements. It's especially important to understand the scope of multiplayer: real-time PvP vs asynchronous — the difference in labor is significant. Order turnkey midcore game development, and we will prepare a precise quote.
Typical Costly Mistakes
- Using
PlayerPrefsfor critical progression data. PlayerPrefs is not atomic — a crash between writes can lose state. You need either Cloud Save (Play Games SDK, Game Center) or your own server with idempotent operations. - Lack of analytics from day one. Firebase Analytics or GameAnalytics should be integrated before soft launch, otherwise there is no baseline for D1/D7/D30 retention.
- Hardcoded localization. If texts are baked into code, adding a new language is painful. Use Unity Localization Package with
LocalizedStringand tables. - Single build for all platforms. iOS and Android have different texture compression requirements (ASTC vs ETC2), different memory limits, and different store guidelines. Scripting Define Symbols and Platform-specific Asset Variants are not an option but a necessity.
Get a consultation to discuss your project and avoid these mistakes from the start.







