Mobile Card Game Development: From Prototype to Release
Imagine: a player plays a card with a poison effect, but on the opponent's screen, the target's health doesn't change. A sync bug — one of the most common reasons for negative reviews. In one of our projects with 50,000 DAU, such a bug led to a 15% user loss within a week. We've encountered this multiple times and developed a reliable solution: the Command pattern and strict server-side validation.
We build mobile card games from scratch: from mechanic design to store publication. Experience: 5+ years and 10+ projects. In this article, we break down key technical aspects: match state synchronization, balancing 500+ cards, smooth animations on low-end devices.
Technical Challenges
Card games are a genre highly dependent on data balance and match state reliability. In a fighting game, an animation bug might go unnoticed; in a card game, an incorrectly calculated card effect ruins the experience immediately.
- Real-time state synchronization: each turn must be a transaction. The game state must not remain "half-applied" on crash or connection loss.
- Balancing 500+ cards: 500+ unique cards with different effects require a metrics system and automated testing. We ran 10,000 automated simulations to detect imbalance early.
- Visualization and performance: card animations must not lag on budget devices (average FPS of 60, minimum 30).
- PvP mode: support for synchronous and asynchronous matchmaking.
Why Match State Synchronization Is the Key Problem?
Each turn is a transaction. Player plays a card → chain of effects → new board state. We implement it via the Command pattern. PlayCardCommand, AttackCommand, DrawCardCommand — each command has Execute and Undo. The entire turn is a stack of commands that either applies fully or rolls back. This also gives replay functionality for free: save the command stack + initial seed → get a reproducible match. Average turn takes 2.3 seconds including network latency.
For real-time, we use Photon Realtime. Photon Realtime ensures reliable message delivery for multiplayer games.
What to Choose: Real-Time or Asynchronous PvP?
The choice affects architecture and user experience.
| Criteria | Synchronous PvP | Asynchronous PvP |
|---|---|---|
| Turn time | Instant (real-time) | Delayed (hours/days) |
| Connection requirements | Stable Wi-Fi/LTE | Any connection (Push notifications) |
| Server load | High (real-time relay) | Low (only saving turns) |
| Suitable for | Tournaments, quick duels | Casual audience, mobile-first |
Synchronous PvP (both players online): use Photon Realtime with custom Room State. Turns are transmitted as events (RaiseEvent), server acts as relay. For validation — a separate server service that checks move legality before broadcasting to opponent.
Asynchronous PvP (Push & Pull): turn is saved to server, opponent receives FCM push notification. Works even with poor connection, more tolerant to mobile-first audience. For deck and balance — Firebase Firestore with security rules.
How to Achieve Smooth Animations on Low-End Devices?
Cards in Unity — Canvas with RectTransform for UI-based render or separate SpriteRenderer meshes for the game board. UI approach is more convenient for animation and drag-and-drop via IBeginDragHandler, IDragHandler, IEndDragHandler. DOTween for card playing effects: flyout from hand, glow, shake on attack. We use Object Pool for cards to avoid runtime allocations. Average frame time 16 ms (60 FPS).
Dynamic card art generation from template: RenderTexture + Camera in offscreen — render the 3D card model with needed parameters into texture, use as sprite. This allows having 500+ unique cards without 500 separate textures.
| Approach | Advantages | Disadvantages |
|---|---|---|
| UI Canvas | Simple animation, drag-and-drop | Overhead with many elements |
| Sprite Mesh | High performance | Complex animation, custom logic needed |
Typical Mistakes in Card Game Development
- Ignoring testing on low-end devices: animations may lag if not optimized.
- Lack of logging system for sync debugging: without logging, it's hard to reproduce bugs.
- Poor reconnection handling: player must return to match with restored state.
- Too frequent server requests: increase load and latency.
- Not using Object Pool: leads to frequent GC and FPS drops.
What Stages Does Development Include?
- Analytics and design: mechanic prototyping, card balance based on simulations (10,000 rounds), matchmaking design.
- Implementation: writing game logic in C# in Unity, Photon/Firebase integration, card system and animations creation.
- Testing: automated match simulations, testing on real devices (iOS/Android), server stress tests (handles 1,000 concurrent matches).
- Publication: build preparation, App Store and Google Play review, in-app purchases setup with StoreKit 2 and Billing 6.
- Support: 30-day warranty after release, updates for new OS versions.
Timelines and Cost
Single-player card game with AI opponent — 3–5 months. With PvP and deck-building mode — 5–9 months. Cost is calculated individually after requirements analysis.
What's Included in Our Work
- Full documentation package: technical specification, architecture diagram, game logic description.
- Access to the repository with code and CI/CD pipeline.
- Training your team to work with the project (2–3 sessions).
- First month of warranty support after release.
Contact us to discuss your project — we will prepare a commercial proposal with a detailed development plan. Order a consultation to estimate timelines and budget. Get a detailed development plan.