DEV Community: unity source code

Building an Endless Runner in Unity: A Developer's Technical Breakdown

unity source code — Thu, 20 Aug 2026 17:35:13 +0000

Endless runners look deceptively simple from the outside. Swipe, jump, slide, collect coins, repeat. But if you've ever tried to actually implement one — procedural track generation, object pooling, collision handling, input responsiveness, and performance tuning for low-end Android devices all at once — you know the genre has more engineering depth than it lets on.

This article is written for developers, not marketers. We're going to walk through the actual systems that make an endless runner work in Unity: the architecture decisions, the common pitfalls, and the performance considerations that separate a smooth 60fps runner from a janky prototype that drops frames the moment three obstacles spawn at once.

Why Endless Runners Are a Good Engineering Exercise

Before diving into implementation, it's worth understanding why this genre is such a common starting point for Unity developers — and why so many teams choose to build on top of an existing source code rather than starting from a blank scene.

The core systems in an endless runner are reusable across dozens of other genres: object pooling, procedural spawning, state machines for player movement, and performance-conscious rendering. Once you understand how to build these systems well in a runner, you can carry that architecture into platformers, obstacle-course games, and even some puzzle formats.

A well-built reference implementation is genuinely useful here. The roundup of runner templates on the Unity Source Code blog is a good place to see how different teams have approached the same core loop — comparing tile-based level design against fully procedural generation, for example, or seeing how a chase-and-combat hybrid like Last War: Survival Battle layers combat systems on top of the standard runner architecture. Studying multiple implementations side by side is one of the fastest ways to understand which architectural decisions actually matter versus which ones are just stylistic preference.

Core System 1: Procedural Track Generation

The heart of any endless runner is the system that generates the world in front of the player indefinitely without eating memory or tanking performance. There are two common approaches:

Segment-based generation. The world is broken into fixed-length "chunks" (say, 20 units long) that are pre-authored or randomly assembled from a pool of prefab segments. As the player moves forward, new segments spawn ahead and old ones get recycled behind.

public class TrackSpawner : MonoBehaviour
{
    public GameObject[] trackSegments;
    public Transform player;
    public float segmentLength = 20f;
    public int segmentsAhead = 4;

    private Queue<GameObject> activeSegments = new Queue<GameObject>();
    private float nextSpawnZ = 0f;

    void Start()
    {
        for (int i = 0; i < segmentsAhead; i++)
        {
            SpawnSegment();
        }
    }

    void Update()
    {
        if (player.position.z > nextSpawnZ - (segmentsAhead * segmentLength))
        {
            SpawnSegment();
            RecycleOldSegment();
        }
    }

    void SpawnSegment()
    {
        GameObject prefab = trackSegments[Random.Range(0, trackSegments.Length)];
        GameObject segment = Instantiate(prefab, new Vector3(0, 0, nextSpawnZ), Quaternion.identity);
        activeSegments.Enqueue(segment);
        nextSpawnZ += segmentLength;
    }

    void RecycleOldSegment()
    {
        if (activeSegments.Count > segmentsAhead)
        {
            GameObject old = activeSegments.Dequeue();
            Destroy(old);
        }
    }
}

This approach is easier to control from a design perspective — you can hand-author interesting segment layouts and control difficulty precisely by weighting which segments are more likely to spawn as the game progresses.

Fully procedural obstacle placement. Instead of pre-built segments, obstacles and collectibles are spawned individually based on rules (minimum spacing, lane distribution, difficulty curve). This gives more variety but requires more careful tuning to avoid impossible or unfair obstacle combinations — like two full-width obstacles spawning too close together for the player to react.

Most production runners use a hybrid: segment-based track geometry (ground, ramps, turns) combined with procedural obstacle and collectible placement within each segment. This gives you the best of both — predictable level structure with unpredictable moment-to-moment gameplay.

Core System 2: Object Pooling (Non-Negotiable)

If there's one performance mistake that kills more endless runner prototypes than anything else, it's calling Instantiate() and Destroy() repeatedly during gameplay. Garbage collection spikes from constant allocation/deallocation are one of the leading causes of frame stutter in this genre, especially on mid- and low-tier Android devices.

Object pooling solves this by pre-allocating a pool of reusable objects and simply enabling/disabling them instead of creating and destroying them:

public class ObjectPool : MonoBehaviour
{
    public GameObject prefab;
    public int poolSize = 20;
    private Queue<GameObject> pool = new Queue<GameObject>();

    void Awake()
    {
        for (int i = 0; i < poolSize; i++)
        {
            GameObject obj = Instantiate(prefab);
            obj.SetActive(false);
            pool.Enqueue(obj);
        }
    }

    public GameObject GetObject()
    {
        if (pool.Count == 0)
        {
            GameObject extra = Instantiate(prefab);
            return extra;
        }
        GameObject obj = pool.Dequeue();
        obj.SetActive(true);
        return obj;
    }

    public void ReturnObject(GameObject obj)
    {
        obj.SetActive(false);
        pool.Enqueue(obj);
    }
}

Every obstacle, coin, power-up, and particle effect in your runner should go through a pooling system like this. It's the single highest-leverage optimization you can make early in development, and retrofitting it into a codebase that wasn't built with pooling in mind is significantly more painful than building it in from day one.

Core System 3: Input Handling and Responsiveness

Endless runners live or die on input responsiveness. A 100ms delay between a swipe and the character's lane change is enough to feel "off" to players, even if they can't articulate why.

A few practical guidelines:

Detect swipes on touch-start delta, not touch-end. Waiting for a full swipe gesture to complete before registering input adds unnecessary latency. Many production runners start evaluating swipe direction as soon as the touch has moved a minimum threshold distance.
Use a dedicated input buffer for jump/slide actions. Registering input a few frames before the player is technically able to act on it (and queuing that action) makes controls feel more forgiving without actually changing the underlying timing window.
Decouple input polling from physics updates. Poll input in Update(), but apply movement in FixedUpdate() using cached input state, so your control responsiveness isn't tied to physics tick rate.

private Vector2 touchStartPos;
private bool swipeDetected = false;

void Update()
{
    if (Input.touchCount > 0)
    {
        Touch touch = Input.GetTouch(0);
        if (touch.phase == TouchPhase.Began)
        {
            touchStartPos = touch.position;
            swipeDetected = false;
        }
        else if (touch.phase == TouchPhase.Moved && !swipeDetected)
        {
            Vector2 delta = touch.position - touchStartPos;
            if (delta.magnitude > 50f) // minimum swipe threshold
            {
                HandleSwipe(delta);
                swipeDetected = true;
            }
        }
    }
}

Core System 4: Difficulty Scaling

A static difficulty curve is one of the fastest ways to make a runner feel stale. Most production-grade runners scale difficulty dynamically based on distance traveled or elapsed time, adjusting:

Forward movement speed
Obstacle spawn frequency and density
Minimum gap between obstacles (which should never shrink below what's physically possible to react to)
Power-up spawn rate (often inversely related to difficulty, to give players relief valves during harder sections)

A simple linear or logarithmic curve tied to distance traveled works well as a baseline:

float GetCurrentSpeed(float distanceTraveled)
{
    float baseSpeed = 8f;
    float maxSpeed = 20f;
    float rampDistance = 2000f;
    float t = Mathf.Clamp01(distanceTraveled / rampDistance);
    return Mathf.Lerp(baseSpeed, maxSpeed, t);
}

The important engineering detail here is capping the maximum speed. Uncapped scaling eventually produces obstacle configurations that are mathematically impossible to react to at the player's input speed, which is a common (and easily avoidable) bug in amateur runner implementations.

Performance Optimization for Low-End Android

This is where a lot of otherwise well-built runners fall apart in production. Endless runners are particularly punishing on frame rate because of constant camera movement, particle effects, and procedural spawning — all happening simultaneously, every frame, for as long as the player keeps the app open.

Key optimization targets:

Draw call reduction. Batch static geometry where possible, and use texture atlases for obstacle and environment sprites to minimize material swaps.
Particle system budgets. Cap simultaneous particle emitters and use simplified particle effects on detected low-end devices via SystemInfo.systemMemorySize or a device-tier detection library.
LOD and culling. Even in a runner where the camera mostly faces forward, aggressive frustum culling on track segments behind the player prevents wasted rendering.
Physics simplification. Use simple colliders (box/capsule) over mesh colliders wherever possible, and avoid running full physics simulation on objects that only need trigger-based collision detection.

Because this genre is so sensitive to frame rate consistency across the fragmented Android hardware landscape, it's worth budgeting real testing time on actual low-end devices rather than relying on editor performance or high-end test phones, which will mask problems that only show up on budget hardware in the field.

Publishing Considerations: Platform-Specific Build Configuration

Once the core systems are built and optimized, the next engineering hurdle is platform-specific build configuration — and this is a step where a lot of developers underestimate the differences between Android and iOS.

Build settings, signing certificates, IL2CPP vs Mono scripting backends, texture compression formats (ASTC vs ETC2 vs PVRTC), and store-specific review requirements around ads and permissions all differ meaningfully between the two platforms. Getting these wrong doesn't just cause build errors — it can lead to store rejections that cost a full review cycle to fix.

For a detailed technical breakdown of these platform differences — including build configuration specifics and submission requirements — see this developer-focused walkthrough of Unity Android vs iOS publishing. It's worth reading before you lock in your build pipeline, since some of these settings (like scripting backend and API compatibility level) are much easier to configure correctly up front than to retrofit after a submission gets flagged.

Testing and Iteration Workflow

A practical testing workflow for a runner in active development typically includes:

Editor playtesting for rapid iteration on core mechanics and feel.
Device farm testing across a range of Android hardware tiers to catch performance regressions early.
Automated frame-rate logging during build QA, comparing average and minimum FPS across representative test devices.
Playtester feedback sessions focused specifically on difficulty pacing — this is subjective enough that it benefits from real human input rather than pure metrics.
Soft launch analytics once the build is live, tracking session length, retry rate, and drop-off points along the difficulty curve.

Treating difficulty tuning as an ongoing, data-informed process rather than a one-time decision before launch tends to produce noticeably better retention outcomes over the game's lifecycle.

Closing Thoughts

Endless runners reward strong engineering fundamentals more than most casual mobile genres. The mechanics are simple to describe but genuinely demanding to implement well — procedural generation that stays fair, object pooling that eliminates GC spikes, input handling tight enough to feel instant, and difficulty scaling that stays challenging without becoming impossible.

If you're starting a runner project, it's worth studying existing production implementations before writing your own systems from scratch. Comparing different architectural approaches — like the range of templates covered in the endless runner source code roundup — can save significant development time by showing you which patterns are proven versus which are still experimental.

The genre isn't going anywhere. Its technical demands are well understood, its player expectations are well established, and its engineering challenges — performance, responsiveness, and fair difficulty scaling — are exactly the kind of problems that make you a better Unity developer once you've solved them properly.

Unity Android vs iOS Publishing: A Developer's Technical Breakdown

unity source code — Wed, 19 Aug 2026 17:45:02 +0000

Cross-platform is one of Unity's biggest promises: write your gameplay once, deploy it to Android and iOS from the same project. That promise holds up reasonably well at the code layer. Where it breaks down is everywhere else — build tooling, signing, store review, monetization APIs, and performance behavior across wildly different hardware.

If you're a developer preparing your first dual-platform release, this is the technical rundown you need before you hit "Build." We'll go through the environment setup, store submission mechanics, IAP wiring, performance planning, and signing workflow for both platforms, along with the mistakes that trip up most first-time submissions.

Why "One Build, Two Platforms" Isn't Really True

Unity abstracts a huge amount of platform complexity for you. Input handling, rendering, physics, and most gameplay systems can stay platform-agnostic if you write them that way. But the moment you move past gameplay code into "how does this thing actually get onto a phone," Android and iOS stop looking like variations of the same process and start looking like two separate pipelines that happen to share a game engine.

Treating them identically — same build flags, same assumptions about testing, same submission timeline — is the single most common reason first submissions get delayed or rejected. Let's break down where the real divergence happens.

1. Build Environment and Tooling

Android

Unity Hub can install everything required for Android builds directly: the Android SDK, NDK, and OpenJDK. You can build and test an APK on Windows, macOS, or Linux without any special hardware, which makes Android the lower-friction platform to get your first build running on.

The Player Settings you'll actually care about:

Minimum API Level — the floor for how old a device can be and still install your app
Target API Level — Google raises the required minimum yearly, and enforces it strictly at submission
Scripting Backend — IL2CPP is effectively mandatory now for Play Store submissions due to 64-bit requirements
Target Architectures — ARM64 is required; ARMv7 is optional but still useful for older device coverage

A common pattern for separating Android-specific code from shared logic:

#if UNITY_ANDROID && !UNITY_EDITOR
    // Android-specific initialization, e.g. Play Billing setup
    InitializeAndroidBilling();
#endif

iOS

There's no way around this one: you need a Mac running Xcode to finish an iOS build. Unity generates an Xcode project as its iOS build output, and compiling, signing, and archiving all happen inside Xcode before anything reaches App Store Connect. Windows and Linux can get you 90% of the way there, but the final 10% requires macOS.

Key settings on the iOS side:

Target minimum iOS version
Signing & Provisioning Profiles, which require a paid Apple Developer Program membership
Architecture, which on current devices means ARM64 only

If you don't own a Mac, this becomes a real planning constraint — you're looking at either borrowing one, renting time on a cloud Mac build service, or budgeting to buy one before your iOS release date is realistic.

2. Store Review: Automated vs. Manual

This is where the day-to-day developer experience diverges most.

Google Play review is largely automated. Google is mainly checking for policy violations: malware, deceptive functionality, disallowed content, and privacy issues — particularly whether your Data Safety form actually matches what your app collects. Turnaround is typically a few hours to a couple of days, and results are fairly predictable if you've followed policy.

A few things have tightened recently: new developer accounts frequently need to run a closed test with a minimum tester count before they're allowed to go public, target API level requirements are enforced hard at submission, and the Data Safety section needs to be accurate, not just filled in generically.

Apple's App Store review is manual and human-reviewed, typically completed in 24–48 hours, but rejections on first submissions are common. Frequent causes include:

Incomplete or misleading metadata and screenshots
Crashes or obvious bugs found during the reviewer's pass
Violations of the Human Interface Guidelines
Missing or incomplete privacy "nutrition label"
In-app purchase implementation issues — Apple is particularly strict here

If your game has login functionality, expect to provide a working demo account. If you use ads or IAP, App Tracking Transparency has to be implemented correctly or you risk rejection.

Practical takeaway: build extra time into your schedule for iOS, especially for your first submission. Don't plan a launch marketing push around your very first App Store submission date — plan it around your first approved build instead.

3. In-App Purchases and Billing APIs

Monetization is one of the more technically fiddly parts of dual-platform publishing, mostly because Android and iOS use completely separate billing systems under the hood.

Android requires Google Play Billing for any in-app purchase. Unity IAP wraps this, but you still need to:

Create matching in-app products inside the Google Play Console
Keep product IDs identical between your Unity project and the Play Console
Track Billing Library version deprecations — Google periodically forces migrations

iOS uses Apple's StoreKit. App Store Connect follows a similar product-ID model, but with its own requirements: tax and banking details must be fully completed before IAP products can go live, and subscription products carry stricter rules than one-time purchases.

A typical Unity IAP initialization pattern that works across both stores:

void InitializePurchasing()
{
    if (IsInitialized()) return;

    var builder = ConfigurationBuilder.Instance(StandardPurchasingModule.Instance());
    builder.AddProduct("coins_pack_small", ProductType.Consumable);
    builder.AddProduct("remove_ads", ProductType.NonConsumable);

    UnityPurchasing.Initialize(this, builder);
}

The product IDs (coins_pack_small, remove_ads) have to match exactly on both the Play Console and App Store Connect side — a mismatch here is one of the most common causes of "purchases silently failing" bug reports.

Ad SDKs add another layer of platform difference. iOS requires the App Tracking Transparency prompt, and how users respond to it directly affects ad fill rate and eCPM. Android is more lenient on tracking permissions but strictly enforces its own content rating and ad placement policies.

4. Performance: Fragmentation vs. Consistency

If there's one technical factor that separates Android and iOS optimization work, it's hardware fragmentation.

Android spans everything from high-end flagship GPUs down to budget devices with limited RAM and older graphics hardware still in heavy use across many regions. A build running a smooth 60 FPS on a flagship can drop into single digits on a low-end device if you haven't planned for it.

Practical mitigation steps:

Use appropriate texture compression (ASTC, ETC2) and keep texture sizes sane
Batch aggressively and watch draw call counts
Scale particle effects and shadow quality based on a detected device tier
Test on real physical devices — emulators don't reliably reflect thermal and GPU behavior

iOS hardware, by contrast, is far more consistent. Apple controls both hardware and software, and at any given time there's a relatively small set of active device models. If your build runs well on a couple of representative iPhone models, you can be reasonably confident about the broader install base.

That doesn't mean iOS is performance-worry-free, though. iOS devices tend to have less thermal headroom for sustained heavy workloads, so long sessions with demanding shaders can trigger thermal throttling — worth explicit testing if your game leans on visual effects.

5. Signing and Certificates

Android apps are signed with a keystore file. Since 2021, Google Play requires Play App Signing, where Google holds your actual signing key and you upload builds signed with a separate upload key. This mostly eliminated the old failure mode where losing your keystore meant permanently losing the ability to update your app — but backing up your credentials is still essential practice.

iOS signing involves more moving parts: developer certificates, App IDs, and provisioning profiles for development, ad hoc, and distribution builds. Xcode's Automatic Signing handles most of this for solo developers, but CI/CD pipelines and larger teams often end up managing profiles manually, adding complexity that simply doesn't exist on Android.

6. Testing Pipelines

Google Play offers Internal, Closed, and Open testing tracks, letting you roll builds out to specific tester groups before a public release. As mentioned, many newer developer accounts are required to run a closed test with a minimum number of testers for a set period before production publishing unlocks.

Apple's equivalent is TestFlight, supporting up to 10,000 external testers per app. TestFlight builds go through a lighter version of Apple's review before external testers can install them, generally faster than a full App Store submission.

Use both pipelines seriously — not just to catch crashes, but to get early signal on your store listing itself (icon, screenshots, description), since first impressions have an outsized effect on install conversion on both stores.

7. Store Economics and Listing Requirements

Both stores take a standard 30% commission on paid apps and IAP, reduced to 15% for developers under certain annual revenue thresholds via Google's Play Media Experience Program and Apple's Small Business Program — eligibility criteria are worth verifying since they can change.

Listing requirements differ too: Google Play gives more flexibility around feature graphics, promotional video, and short/long descriptions, and supports staged update rollouts. Apple enforces stricter per-device screenshot sizing and tighter rules on app preview video content.

Pricing structure also differs — Apple uses fixed pricing tiers applied globally, while Google Play allows granular per-country pricing.

8. Post-Launch Updates

Android updates are typically reviewed within hours, and Google's staged rollout feature lets you release to a percentage of users first to catch issues before a full rollout. iOS updates go through the same full manual review as your original submission — typically 24–48 hours — though Apple offers an expedited review request for critical fixes (not guaranteed, and not something to rely on as standard process).

This matters most if you're running a live-ops style game with frequent balance or event changes — Android lets you iterate meaningfully faster.

Common Mistakes to Avoid

Treating the store listing as an afterthought instead of a conversion-critical asset
Skipping tests on real low-end Android hardware and getting hit with bad reviews post-launch
Overlooking Apple's privacy nutrition label, causing avoidable review delays
Scattering platform-specific logic instead of cleanly isolating it with #if UNITY_ANDROID / #if UNITY_IOS
Skipping IAP sandbox testing on both platforms before going live

Starting From a Working Project Instead of Zero

Configuring build settings, signing, IAP, and performance scaling correctly across both platforms is a real time investment, even for experienced developers. This is a big part of why many solo developers and small studios start from an already-built Unity project rather than assembling every system from scratch — the core mechanics, UI, and platform build configuration are already in place and tested, so your time goes into reskinning, tuning, and marketing.

For a concrete example of a casual, low-complexity game already structured for a dual-platform release, this House Cleaning Unity game source code is a useful reference point — a simulation-style casual title with the kind of lightweight performance profile that maps well to the fragmentation concerns covered above.

If you'd rather look at a more technically involved genre, this technical guide to building a crowd runner combat game in Unity walks through the architecture decisions behind a more systems-heavy project, which is worth reading if you're weighing how much gameplay complexity to take on before you start thinking about platform-specific build configuration.

Quick Reference Table

Factor	Android (Google Play)	iOS (App Store)
Build machine required	Windows, macOS, or Linux	macOS with Xcode only
Review process	Mostly automated, hours to ~2 days	Manual human review, ~1–2 days
Hardware fragmentation	High	Low
Signing	Keystore + Play App Signing	Certificates + provisioning profiles
IAP system	Google Play Billing	Apple StoreKit
Testing	Internal/Closed/Open tracks	TestFlight (up to 10,000 testers)
Update rollout	Staged rollout supported	Full re-review each time
Commission	30% (15% under threshold)	30% (15% under threshold)

Wrapping Up

Publishing a Unity game across Android and iOS isn't a single checklist — it's two separate operational pipelines that happen to share a codebase. Android rewards developers who can handle hardware fragmentation and want fast iteration cycles. iOS rewards polish, consistency, and strict adherence to review guidelines.

If you're new to dual-platform publishing, the fastest way to internalize these differences is to study a project that's already correctly configured for both — build settings, signing, and IAP hooks included — rather than debugging every platform quirk on a brand-new game built entirely from scratch.

Build a Crowd Runner Combat Game in Unity: A Technical Guide

unity source code — Sun, 16 Aug 2026 18:03:23 +0000

Crowd runner games have quietly become one of the most consistently profitable genres in mobile gaming. If you've spent any time browsing top charts on the App Store or Google Play, you've likely seen the pattern: players guide a growing crowd of characters through an obstacle course, gates multiply or divide their numbers, and the run culminates in some kind of climactic showdown. What started as a niche hyper-casual mechanic has evolved into a genre with real depth, especially when combat systems are layered on top of the core running loop.

In this article, we're going to dig into the technical and design fundamentals behind crowd runner combat games, using the mechanics found in survival battle-style Unity projects as our reference point. This isn't a marketing pitch. It's a breakdown intended for developers who want to understand how these systems actually work under the hood, why certain design decisions matter, and what technical challenges you'll run into if you try to build one yourself.

By the end of this post, you should have a solid mental model of the core systems involved: crowd management, gate logic, combat resolution, and the progression systems that tie it all together.

Why Crowd Runner Combat Games Are Worth Studying

Before getting into architecture, it's worth understanding why this genre has proven so durable. Crowd runner games succeed because they combine two very different psychological hooks into a single experience.

The running phase taps into the same "flow state" mechanics that make endless runners and rhythm games compelling: constant forward momentum, quick decisions, and immediate visual feedback. Every gate you pass either rewards or punishes you instantly, which keeps players locked into a tight feedback loop.

The combat phase, on the other hand, taps into something different entirely: payoff and consequence. All the decisions made during the running section, how many units were recruited, which upgrades were collected, which gates were avoided, culminate in a single dramatic confrontation. This creates a structure similar to a resource-management game compressed into sixty seconds, where preparation directly determines outcome.

Games like Last War Survival Battle are a good example of this hybrid structure in practice. Players build an army by making path decisions during the run, then watch that army clash with enemy forces in a battlefield sequence at the end of the level. Studying how a template like this structures its systems is genuinely useful for understanding the genre, regardless of whether you use it as a direct starting point or simply as a reference for your own architecture.

Core System 1: Crowd/Unit Management

The foundation of any crowd runner game is a system that tracks and visually represents a dynamically changing group of units. This sounds simple in concept, but it has real performance implications once your unit count climbs into the hundreds.

The naive approach — instantiating and destroying individual GameObjects every time the crowd size changes — works fine for prototypes but breaks down quickly at scale. Instantiate/Destroy calls are expensive, and doing them every frame as units are gained or lost during a fast-paced run will tank your frame rate on mid-range Android devices.

A better approach relies on object pooling. Pre-instantiate a pool of unit GameObjects at scene load, then activate/deactivate them as the crowd count changes rather than creating and destroying instances. Combine this with a formation system, typically a grid or radial layout algorithm, that recalculates unit positions relative to the player's transform as the crowd grows or shrinks. Units should lerp or spring toward their target formation position rather than snapping instantly, which produces the fluid, organic crowd movement players expect from this genre.

For very large crowds (several hundred units), some developers go a step further and use GPU instancing or Unity's DOTS/ECS stack to render units, since traditional GameObject-per-unit approaches become a bottleneck well before you hit visually impressive crowd sizes. Whether this level of optimization is necessary depends heavily on your target unit count and device tier.

Core System 2: Gate and Multiplier Logic

Gates are the primary interactive element during the running phase, and they need to be built as a modular, data-driven system rather than hardcoded level-by-level logic.

A clean implementation typically defines a GateEffect as a ScriptableObject or simple data class containing an operation type (add, subtract, multiply, divide) and a value. When the player's crowd collider intersects a gate's trigger volume, the gate applies its effect to the current crowd count and then deactivates or destroys itself.

The trickier design challenge isn't the collision logic, it's balancing gate placement and values so that risk and reward feel meaningful without becoming punishing. If a "divide by 2" gate appears too frequently relative to "multiply by 2" gates, players will feel like progress is arbitrary rather than skill-based. This is less a coding problem and more a data-tuning problem, and it's worth building a level editor tool (Unity's custom editor windows are great for this) that lets designers preview cumulative crowd growth across a full gate sequence before shipping a level.

Core System 3: Combat Resolution

The combat phase is where crowd runner games diverge most from simple endless runners, and it's also where the most interesting architectural decisions happen.

There are generally two approaches to resolving battlefield combat:

Simulated combat treats the encounter as a numbers-driven calculation. Your army size and stats are compared against the enemy's, a resolution formula determines the outcome, and the visual battlefield sequence is essentially a scripted animation representing that pre-calculated result. This approach is computationally cheap and easy to balance, but risks feeling disconnected from player skill if not designed carefully.

Live combat actually simulates individual unit-vs-unit encounters in real time, with units from both sides colliding, attacking, and being eliminated based on per-unit stats. This produces a more visually dynamic and satisfying battle sequence, but it's significantly more expensive computationally and harder to balance predictably, since emergent unit-level behavior can produce unexpected outcomes.

Most successful mobile crowd runner combat games use a hybrid: a lightweight, deterministic simulation runs behind the scenes to guarantee a fair and balanced outcome based on player stats, while a separate visual layer plays out an approximate, non-authoritative animation of units fighting on screen. This gives you the best of both worlds — predictable, testable game balance, plus a satisfying visual spectacle — without needing full physics-driven combat simulation.

Core System 4: Progression and Upgrade Architecture

Long-term retention in this genre depends heavily on a well-structured progression system. From an engineering standpoint, this typically means building a persistent player data layer that tracks unlocked upgrades, currency balances, and unit stat multipliers, separate from any individual level's runtime state.

A clean pattern here is to define upgrades as data assets (again, ScriptableObjects work well) with an ID, a cost curve, and a stat modifier. Your runtime unit stats are then calculated as a base value multiplied by whatever upgrades the player has unlocked, rather than hardcoding stat values per unit type. This makes balancing dramatically easier, since you can adjust a single upgrade's modifier value without touching unit prefabs or combat code.

It's also worth designing your progression system with monetization hooks in mind from the start. Rewarded ads that grant temporary stat boosts, currency multipliers, or extra army slots are common in this genre, and they work best when your upgrade system already has clean, event-driven hooks (OnUpgradePurchased, OnRunCompleted, etc.) that a separate monetization manager can subscribe to.

Performance Considerations Specific to This Genre

Crowd runner combat games have some performance characteristics that are worth calling out specifically, since they differ from more typical mobile game profiles.

Draw calls scale with crowd size. If every unit uses its own material instance, you'll hit draw call limits well before you hit interesting crowd sizes. Use material batching, GPU instancing, or a shared material with per-instance property blocks to keep draw calls manageable.

Physics can become a bottleneck fast. If every unit has its own Rigidbody and collider for gate detection, physics calculations can spike during large crowd scenes. Many implementations use simplified trigger checks based on distance calculations rather than full physics collision for gate interactions, reserving actual physics simulation for the combat phase where visual impact matters more.

Animation cost adds up. Hundreds of animated units on screen simultaneously can be expensive if each is running an independent Animator component. Techniques like animation texture baking or GPU-driven animation systems become worth considering once your crowd sizes get large enough.

A Note on Vehicle and Physics-Based Genres

It's worth noting that crowd runner combat games are just one example of a broader category of mobile games where core mechanics need to be layered with a secondary system, in this case, running plus combat. Other genres follow a similar "two systems working together" pattern, just with different underlying physics.

If you're interested in a deeper technical dive into a genre that leans much more heavily on physics simulation specifically, this breakdown on building realistic flight physics in Unity, covering aircraft simulation mechanics is a great companion read. It covers a very different technical domain, lift, drag, thrust calculations, and control surface simulation, but the underlying engineering discipline of balancing simulation accuracy against mobile performance constraints is a theme that shows up across almost every genre, including the crowd combat systems discussed here.

Practical Advice If You're Building This Genre

If you're a developer considering building a crowd runner combat game, here's a practical starting checklist based on the systems covered above:

Build your crowd management system with pooling from day one. Retrofitting object pooling into a project that already instantiates/destroys units directly is painful. Start with it.
Separate your combat resolution logic from your combat visuals. A deterministic, testable combat calculation layer will save you countless balance headaches compared to relying purely on emergent unit-vs-unit physics.
Make gates and upgrades data-driven. ScriptableObject-based configuration lets you (or a designer on your team) iterate on balance without touching code.
Profile early, especially draw calls and physics. Crowd-based genres hit performance walls in different places than typical 3D mobile games, so don't assume standard optimization advice will catch everything.
Study existing implementations before starting from scratch. Reviewing how an existing, working project like a crowd runner combat template structures its systems can save significant development time and help you avoid common architectural mistakes. For developers newer to Unity overall, it's also worth reviewing a broader list of recommended Unity projects for new developers, which covers genres and project types that are well-suited for building foundational Unity skills before tackling something as system-heavy as a crowd combat game.

Final Thoughts

Crowd runner combat games look simple from a player's perspective, tap gates, grow your army, watch a battle play out, but the systems underneath are genuinely interesting from an engineering standpoint. Crowd management demands careful attention to object pooling and formation logic. Gate systems benefit enormously from data-driven design. Combat resolution requires balancing deterministic fairness against visual spectacle. And progression systems need clean architecture to support both game balance and monetization.

If you're a Unity developer looking to build in this genre, the best approach is to treat each of these systems as a separate, testable module rather than tangling them together in a handful of monolithic scripts. Not only will this make your project easier to maintain and extend, it'll make it dramatically easier to balance and tune once real players start generating data.

Whether you're building from scratch or starting from an existing template, understanding these underlying systems will make you a more effective developer in this genre, and in mobile game development more broadly.

Building Realistic Flight Physics in Unity: A Technical Breakdown of Aircraft Simulation Mechanics

unity source code — Sat, 15 Aug 2026 17:45:37 +0000

Flight simulation is one of the most technically demanding genres you can build in Unity. Unlike platformers or top-down games where physics can be simplified or faked, a flight sim lives or dies by how believable its aircraft feels to control — and that believability comes from getting a surprisingly deep stack of physics, input handling, and environment systems working together correctly.

In this article, I want to walk through the core engineering problems behind building a mobile flight simulator in Unity: how aircraft physics actually works under the hood, how to implement pitch/roll/yaw controls that feel responsive on a touchscreen, how mission systems are structured, and the performance considerations unique to rendering open-world environments on mobile hardware. I'll also point to a working reference implementation along the way for anyone who wants to see these systems in a completed project rather than just pseudocode.

Why Flight Physics Is Harder Than It Looks

Most gameplay physics in Unity relies on Rigidbody and built-in collision handling, and for many genres that's enough. Flight simulation breaks that assumption almost immediately, because an aircraft in flight is being acted on by multiple competing forces simultaneously:

Lift — generated by airspeed and wing surface, pushing the aircraft upward
Drag — resistance from air, scaling with speed and surface area
Thrust — forward force from the engine
Gravity — constant downward force
Torque from control surfaces — pitch (elevators), roll (ailerons), and yaw (rudder)

None of these forces exist in isolation. Increase thrust, and airspeed increases, which increases lift, which changes how the aircraft responds to control input. This interdependency is what makes flight feel "real" — and it's also what makes naive implementations feel floaty, unresponsive, or physically absurd.

A common beginner mistake is to directly manipulate the aircraft's transform.rotation based on input, without ever touching physics forces. This produces something that looks like flying but has none of the momentum, stall behavior, or inertia that makes flight simulation satisfying. The aircraft snaps to new orientations instantly instead of gradually rotating under torque, and there's no sense of speed affecting maneuverability.

Core Physics Setup: Forces Over Transforms

The right approach is to drive the aircraft through Unity's Rigidbody using AddForce and AddTorque, letting the physics engine handle the actual motion integration. Here's a simplified version of what that looks like:

public class AircraftController : MonoBehaviour
{
    [SerializeField] private Rigidbody rb;
    [SerializeField] private float thrustPower = 50f;
    [SerializeField] private float liftCoefficient = 0.05f;
    [SerializeField] private float dragCoefficient = 0.02f;

    private float throttleInput;
    private Vector3 controlInput; // x = pitch, y = yaw, z = roll

    void FixedUpdate()
    {
        ApplyThrust();
        ApplyLift();
        ApplyDrag();
        ApplyControlTorque();
    }

    void ApplyThrust()
    {
        rb.AddForce(transform.forward * throttleInput * thrustPower);
    }

    void ApplyLift()
    {
        float speed = rb.velocity.magnitude;
        float liftForce = speed * speed * liftCoefficient;
        rb.AddForce(transform.up * liftForce);
    }

    void ApplyDrag()
    {
        rb.AddForce(-rb.velocity.normalized * rb.velocity.sqrMagnitude * dragCoefficient);
    }

    void ApplyControlTorque()
    {
        rb.AddRelativeTorque(
            controlInput.x * pitchSensitivity,
            controlInput.y * yawSensitivity,
            -controlInput.z * rollSensitivity
        );
    }
}

The key design decision here is that lift scales with the square of speed. This is what produces the emergent behavior you actually want from a flight sim: a slow-moving aircraft generates almost no lift and will stall or fall out of the sky, while a fast-moving aircraft generates strong lift and climbs easily. You don't need to hand-script stall behavior — it emerges naturally from the force relationships if the coefficients are tuned correctly.

Drag scaling with the square of velocity is equally important. Without it, aircraft accelerate indefinitely under constant thrust, which breaks the sense of a realistic top speed and makes throttle management meaningless to the player.

Tuning Control Surfaces for Mobile Touch Input

Desktop flight sims typically use a joystick or keyboard combination for pitch, roll, and yaw. Mobile devices need touch-based equivalents that are precise enough to feel controllable but forgiving enough for casual play on a small screen. There are two common approaches:

Virtual joystick overlay — a fixed or floating on-screen joystick that maps drag distance and direction to pitch and roll input. This is the most common approach for arcade-leaning flight games because it gives players a consistent, learnable control scheme.

Tilt-based input — using the device's accelerometer or gyroscope to map physical device tilt to aircraft orientation. This can feel more immersive but requires careful dead-zone tuning, since raw accelerometer data is noisy and needs smoothing to avoid jittery control response.

void HandleTouchInput()
{
    if (Input.touchCount > 0)
    {
        Touch touch = Input.GetTouch(0);
        Vector2 delta = touch.position - joystickCenter;
        Vector2 normalizedDelta = Vector2.ClampMagnitude(delta / joystickRadius, 1f);

        controlInput.x = -normalizedDelta.y; // pitch
        controlInput.z = normalizedDelta.x;  // roll
    }
    else
    {
        // Auto-recenter controls when not touching
        controlInput = Vector3.Lerp(controlInput, Vector3.zero, Time.deltaTime * recenterSpeed);
    }
}

That auto-recenter behavior matters more than it might seem — without it, releasing the touch leaves the aircraft locked into its last control input, which feels broken to players used to a joystick returning to neutral.

Structuring Mission Systems Without Hardcoding Every Level

A flight simulator's mission system needs to support varied objective types — reach a checkpoint, land within a target zone, deliver cargo, survive an emergency scenario — without requiring a new script for every mission. A clean approach is to define missions as data rather than code, using a base MissionObjective class with polymorphic subtypes:

public abstract class MissionObjective : ScriptableObject
{
    public string objectiveDescription;
    public abstract bool CheckCompletion(AircraftController aircraft);
}

public class CheckpointObjective : MissionObjective
{
    public Transform checkpointTransform;
    public float triggerRadius = 20f;

    public override bool CheckCompletion(AircraftController aircraft)
    {
        float distance = Vector3.Distance(aircraft.transform.position, checkpointTransform.position);
        return distance <= triggerRadius;
    }
}

public class LandingObjective : MissionObjective
{
    public Transform runwayZone;
    public float maxLandingSpeed = 15f;

    public override bool CheckCompletion(AircraftController aircraft)
    {
        bool inZone = runwayZone.GetComponent<Collider>().bounds.Contains(aircraft.transform.position);
        bool safeSpeed = aircraft.CurrentSpeed <= maxLandingSpeed;
        bool grounded = aircraft.IsGrounded;
        return inZone && safeSpeed && grounded;
    }
}

Using ScriptableObject-based mission definitions means level designers (or you, wearing a level design hat) can create new missions entirely in the Unity Editor — dragging in checkpoint transforms and tuning trigger radii — without touching code. This is the same data-driven pattern worth using for any content-heavy game system, since it decouples level content from engine logic and makes iteration dramatically faster.

Performance Considerations for Open-World Mobile Rendering

Flight simulators are unusual among mobile game genres because they demand large, continuous, explorable environments rather than the small, contained levels typical of most casual mobile games. That creates rendering challenges that don't come up in a puzzle game or a platformer.

Level of Detail (LOD) systems are non-negotiable for open-world flight environments. Terrain, buildings, and distant objects need progressively simplified meshes as the aircraft's distance from them increases. Unity's built-in LODGroup component handles this reasonably well for static geometry, but terrain specifically benefits from a dedicated LOD terrain system that adjusts mesh resolution based on camera distance in real time.

Frustum and occlusion culling matter more in flight sims than almost any other mobile genre, because the camera is frequently pointed at wide-open sky with a large draw distance. Making sure Unity's culling systems are configured correctly — and that terrain chunks outside the view frustum aren't being processed unnecessarily — has an outsized impact on frame rate.

Draw call batching for repeated environment assets (trees, buildings, terrain tiles) should use GPU instancing wherever the art style allows it. A flight sim scene can easily contain thousands of repeated small objects across a large terrain, and without batching, draw calls become the primary bottleneck well before you run out of raw polygon budget.

Fog and atmospheric scattering aren't just visual polish in a flight sim — they're a legitimate performance tool. Using distance fog to obscure the furthest-rendered terrain lets you reduce draw distance and LOD detail at the horizon without it being visually obvious, since the player's eye reads the fade as atmospheric haze rather than as a rendering cutoff.

Handling the Camera: Why Flight Sim Cameras Are Their Own Problem

A chase camera that works fine for a car racing game usually breaks down in a flight sim, because aircraft rotate on all three axes simultaneously in a way ground vehicles never do. A naive camera that rigidly follows the aircraft's rotation will roll and pitch violently with every player input, which is disorienting rather than immersive.

The fix most flight sims use is a camera that lags behind the aircraft's rotation with smoothed interpolation, particularly on the roll axis:

void LateUpdate()
{
    Vector3 targetPosition = aircraft.position - aircraft.forward * followDistance + Vector3.up * followHeight;
    transform.position = Vector3.Lerp(transform.position, targetPosition, Time.deltaTime * positionSmoothing);

    Quaternion targetRotation = Quaternion.LookRotation(aircraft.position - transform.position, Vector3.up);
    transform.rotation = Quaternion.Slerp(transform.rotation, targetRotation, Time.deltaTime * rotationSmoothing);
}

Notice that the camera's "up" vector is locked to world-up (Vector3.up) rather than the aircraft's local up. This keeps the horizon roughly level from the player's perspective even as the aircraft rolls, which dramatically reduces motion sickness and disorientation compared to a camera that rigidly mirrors the aircraft's full rotation.

Where a Reference Implementation Helps

Reading through physics formulas and code snippets is useful, but there's a real gap between understanding the theory and seeing how all of these systems — flight physics, touch controls, mission structures, LOD terrain, and camera smoothing — are integrated into a single working, published-ready project. If you want to study a complete implementation of these systems rather than assembling them piece by piece, the Flight Simulator Game – Complete Source Code with Unity Assets is a full Unity project built around exactly this architecture — physics-driven flight controls, open-world exploration, mission-based objectives, and mobile-optimized rendering — with the complete codebase and asset structure available to inspect and extend.

Working from a complete reference project like this is a genuinely useful way to learn systems-level Unity architecture, since you can trace how each subsystem connects to the others in a way that isolated tutorials rarely show.

Applying These Same Physics Principles to Other Genres

Interestingly, several of the engineering patterns covered here — data-driven objective systems, careful input smoothing, and force-based movement instead of transform manipulation — show up again in genres that look nothing like flight simulation on the surface. Precision-based physics games, where careful force application and momentum determine success rather than raw reflexes, rely on many of the same underlying principles: tuning coefficients so the physics feels right rather than scripting outcomes directly.

If you're interested in how force-driven physics and precision mechanics translate to a completely different genre and control scheme, it's worth reading Building a 3D Slice/Precision-Style Mobile Game in Unity: Mechanics, Physics, and Performance, which covers a similar physics-first approach applied to a very different gameplay context, along with performance optimization strategies that overlap significantly with the mobile rendering concerns discussed above.

Beyond Flight: Puzzle Mechanics and the Value of Studying Different Genres

One habit worth building as a Unity developer is studying game systems outside your primary genre, since underlying architecture patterns — state machines, data-driven objectives, physics tuning — transfer across genres more than developers often expect. Sorting and logic-based puzzle mechanics, for example, involve their own interesting state management and win-condition validation problems that are worth understanding even if you primarily build simulation or action games.

For a look at how those systems are structured in a completely different genre, the Bird Sort Puzzle Game source code is a useful contrast case — a logic-driven puzzle template built around sorting mechanics and win-state validation, which approaches game state management from a very different angle than the physics-driven systems covered in this article, but shares the same underlying discipline of building clean, modular, data-driven Unity architecture.

Wrapping Up

Building a convincing flight simulator in Unity comes down to a handful of interconnected systems: physics driven by real force relationships rather than direct transform manipulation, control schemes tuned specifically for touch input, mission systems structured as data rather than hardcoded logic, and rendering optimizations suited to large open-world environments on mobile hardware.

None of these systems are individually exotic — AddForce, AddTorque, ScriptableObject-based data, and LODGroup are all standard Unity tools. The engineering skill is in how they're tuned and integrated together, and that integration work is where most of the real development time goes on a project like this.

If you're building a flight sim, a racing game, or any physics-heavy simulation title in Unity, I'd genuinely recommend starting by getting the force relationships right in isolation — lift, drag, and thrust in a bare test scene — before layering missions, UI, and rendering optimization on top. Get the physics feeling right first; everything else is easier to build once the core loop already feels good in your hands.

Building a 3D "Slice/Precision" Style Mobile Game in Unity: Mechanics, Physics, and Performance

unity source code — Wed, 12 Aug 2026 18:17:57 +0000

What makes the slice-and-precision genre deceptively hard to build well

If you've spent any time on the app stores in the last few years, you've run into the genre I'm going to call "slice/precision" games — the ones where the entire loop revolves around one clean physical action performed with split-second timing: slicing a rotating object cleanly in half, cutting through a stack of material at exactly the right depth, or splitting a moving shape into precise proportions. Titles built around this mechanic are everywhere on the charts because the core loop is instantly understandable and deeply satisfying to execute well.

What's less obvious from the player side is how much technical work goes into making that one action feel good. A slice that looks janky, a physics response that feels floaty, or a frame drop at the exact moment of the cut will kill the entire appeal of the genre, because the whole game lives or dies on that single moment of feedback. This article breaks down how these mechanics actually get built in Unity — the geometry approach, the physics considerations, the feedback systems that sell the moment, and the performance work that keeps it all running smoothly on the wide range of devices mobile players actually own.

I'll be using a published example of this genre, Perfect Slice 3D, as a reference point throughout, since it's a clean, focused implementation of exactly the mechanics discussed here.

The core problem: real-time mesh slicing

The technical heart of any slice-based game is runtime mesh manipulation — taking an existing 3D mesh and dividing it into two new, correctly formed meshes along a plane defined by the player's cut. This sounds simple conceptually and is genuinely fiddly in practice, because a naive implementation breaks in predictable ways: normals point the wrong direction after the cut, the interior "cut face" is missing entirely so the sliced object looks hollow, or the resulting mesh has degenerate triangles that cause visual artifacts.

The general algorithm most implementations converge on works like this: define the slicing plane in world space based on the player's swipe or cut gesture, iterate through the original mesh's triangles and classify each vertex as being on the positive or negative side of the plane, split any triangle that straddles the plane by computing new intersection vertices, and then cap each resulting half with a new triangulated face along the cut line so both halves read as solid objects rather than open shells. Unity doesn't include this out of the box, so most teams either write a custom mesh-slicing utility or adapt one of the several well-documented open-source approaches built around this same triangle-classification technique.

A simplified version of the classification step looks roughly like this in C#:

Plane cutPlane = new Plane(cutNormal, cutPoint);

for (int i = 0; i < triangles.Length; i += 3)
{
    bool a = cutPlane.GetSide(vertices[triangles[i]]);
    bool b = cutPlane.GetSide(vertices[triangles[i + 1]]);
    bool c = cutPlane.GetSide(vertices[triangles[i + 2]]);

    if (a == b && b == c)
    {
        // Triangle sits entirely on one side — assign to that half directly
    }
    else
    {
        // Triangle straddles the plane — compute intersection points
        // and generate new triangles for both halves
    }
}

The real complexity lives in that "compute intersection points" step, plus correctly recalculating UVs and normals for the newly generated vertices so the cut surface shades and textures correctly instead of looking flat or broken. It's worth budgeting real development time for this system specifically, because it's the one piece of the game that can't be faked with animation tricks — it has to actually work correctly across an enormous variety of object shapes and cut angles.

Physics: making the halves feel weighty, not floaty

Once an object is split, what happens to the two halves matters as much as the split itself. This is where a lot of slice-genre prototypes feel unsatisfying even when the mesh-cutting math is technically correct — the resulting pieces either don't react to the cut at all, or react with generic physics that ignores the specifics of what just happened.

A few details separate a satisfying slice from a flat one. Apply an impulse to each half along the slicing plane's normal, proportional to the force or speed of the cut gesture, so faster or cleaner cuts visibly send the pieces apart with more energy. Recalculate each half's center of mass and collider after the cut rather than relying on the original object's collider, since an asymmetric cut should make an object tumble differently than a clean center cut. And stagger the physics response slightly rather than applying it in the same frame as the visual cut, since a one or two frame delay between the visual separation and the physics kick actually reads as more natural to players, even though it's technically "wrong" relative to a real-world simultaneous event.

Selling the moment: feedback systems

The slice-and-precision genre survives almost entirely on feedback quality, because the underlying action repeats constantly and needs to stay satisfying across hundreds of repetitions in a single session. The systems that do the heaviest lifting here are usually the least technically complex: a brief hitstop (freezing gameplay for a few milliseconds at the moment of a clean cut) sells impact far more effectively than any particle effect on its own; particle bursts along the cut plane, scaled to the precision of the cut, give the player instant visual confirmation of how well they performed; and audio layering — a distinct sound for a perfect cut versus a sloppy one — reinforces the skill feedback loop without requiring any UI at all.

None of these systems are expensive to implement, but they're easy to skip during a prototyping phase and then never circle back to, which is a mistake — for this genre specifically, feedback polish isn't a "nice to have" layered on top of the mechanic, it effectively is the mechanic from the player's perspective.

Where developers underestimate the genre: performance

Real-time mesh slicing generates new geometry constantly during gameplay, which creates a performance profile that's genuinely different from most other mobile genres. Every slice means new mesh data being allocated, new colliders being generated, and new physics bodies being simulated — and if a level has multiple slice-able objects on screen simultaneously, that cost compounds quickly.

The practical mitigations that matter most here are pooling and reusing GameObjects and mesh buffers for sliced pieces rather than allocating fresh ones every time, capping the number of active physics-simulated pieces on screen at once and transitioning older pieces to static or destroyed states once their visual moment has passed, and being deliberate about collision mesh complexity for the sliced pieces — a simplified convex collider is almost always sufficient and dramatically cheaper than a mesh collider matching the exact cut geometry.

This genre also tends to get built by smaller teams iterating quickly, which means performance testing frequently happens only on the developer's own device — usually a mid-range or newer phone — right up until release, at which point real-world reviews reveal stutter and slowdown on the wider range of hardware actual players own. Given how central smooth, responsive feedback is to this genre specifically, a dropped frame at the moment of a slice is far more damaging to the player experience here than in a genre with slower-paced mechanics. I've written a detailed technical breakdown of exactly how to approach this kind of optimization work for Android specifically — covering texture and shader settings, batching, and profiling methodology — that's directly relevant if you're building anything in this physics-heavy, real-time-mesh-generation space: Optimize a Unity Mobile Game for Low-End Android Devices. Given how heavily this genre depends on physics and dynamic geometry generation, treating device-range testing as a late-stage checklist item rather than an ongoing practice is one of the more common and costly mistakes teams make.

A related genre worth studying: puzzle-based precision games

Slice mechanics share a lot of DNA with another mobile genre that's currently having a strong moment — color-sorting and jam-style puzzle games, where the core skill is also about precise, satisfying manipulation of objects within tight spatial constraints, just without the destructive mesh-cutting element. If you're interested in how a related genre solves similar problems around satisfying interaction feedback, level design pacing, and mobile-appropriate physics and UI, I put together a full developer deep-dive into building a Color Block Jam–style 3D puzzle game in Unity, covering the grid logic, block movement systems, and level generation approach that genre depends on: Building a Color Block Jam-Style 3D Puzzle Game in Unity: A Developer's Deep Dive. It's a useful comparison piece if you're deciding between genres or want to see how similar design principles — clear feedback, tight controls, escalating difficulty — get implemented differently when the core verb is "sort" instead of "cut."

Putting it into practice

If you're prototyping a slice-based mechanic, the order of operations that tends to work best is: get a basic, even if crude, mesh-slicing implementation working first so you can actually play with the core loop early; layer in physics response and feedback systems as soon as the slicing works, since this genre lives or dies on feel and you want to be evaluating that feel as early as possible; and only after the core loop is genuinely fun should you invest heavily in level content and polish, since no amount of level design saves a slice mechanic that doesn't feel satisfying at the most basic level.

The technical challenge of runtime mesh slicing is real, but it's also well-trodden ground with solid reference implementations to learn from. The bigger risk in this genre isn't usually the geometry math — it's underinvesting in the feedback and performance work that determines whether the hundredth slice in a session feels as satisfying as the first one, and whether that satisfaction survives contact with the actual range of devices your players are using.

Building a Color Block Jam Style 3D Puzzle Game in Unity: A Developer's Deep Dive

unity source code — Tue, 11 Aug 2026 17:30:32 +0000

Block-jam puzzle games have quietly become one of the most reliable genres in the hyper-casual and casual mobile space. If you've spent any time browsing the top charts, you've almost certainly seen a title where the goal is simple: slide colored blocks out of a confined space before you run out of moves. The mechanic is easy to learn, satisfying to master, and — from a developer's perspective — genuinely interesting to build well.

In this article I want to walk through what it actually takes to build a 3D block-jam puzzle game in Unity, using a real, shipped-style template — Color Block Jam 3D Puzzle — as the reference point. I'll cover the core gameplay loop, the systems you need to get right (grid logic, movement, level design, monetization), the performance traps that catch mobile devs off guard, and a practical checklist for taking a template like this from "it compiles" to "it's on the store."

Whether you're building from scratch, evaluating a Unity asset to reskin, or just trying to understand why this genre performs so well, this should give you a solid technical foundation.

Why Block-Jam Puzzles Work So Well on Mobile

Before touching any code, it's worth understanding why this genre is so dominant in casual mobile gaming, because the design goals should drive your architecture.

Instant comprehension. A player understands the objective within two seconds of seeing the board — no tutorial wall of text required.
Short session length. Levels typically resolve in 15–60 seconds, which fits perfectly into ad-supported, session-based monetization loops.
High replay value through procedural difficulty. Because the core mechanic is spatial reasoning rather than reflexes, you can generate near-infinite levels algorithmically.
Natural ad placement points. Level completion and failure states are clean, non-intrusive moments to show interstitials or offer rewarded continues.

These four properties dictate almost everything about how you should structure your Unity project. Let's get into it.

Core Gameplay Loop: Grid, Blocks, and Exit Logic

At its heart, a 3D block-jam game is a constraint-satisfaction puzzle rendered on a grid. The fundamental building blocks (pun intended) are:

A grid/board representation — usually a 2D or 3D array tracking occupied cells
Block entities — each with a color, a shape footprint, and a fixed movement axis
Exit/collection points — where blocks of a matching color need to reach
Move validation — checking whether a block can legally slide given current occupancy

A minimal grid representation might look like this:

public class GridCell
{
    public Vector2Int Position;
    public bool IsOccupied;
    public BlockController OccupyingBlock;
}

public class GridManager : MonoBehaviour
{
    public int width = 8;
    public int height = 8;
    private GridCell[,] cells;

    void Awake()
    {
        cells = new GridCell[width, height];
        for (int x = 0; x < width; x++)
        {
            for (int y = 0; y < height; y++)
            {
                cells[x, y] = new GridCell { Position = new Vector2Int(x, y) };
            }
        }
    }

    public bool CanMoveTo(Vector2Int target)
    {
        if (target.x < 0 || target.x >= width || target.y < 0 || target.y >= height)
            return false;

        return !cells[target.x, target.y].IsOccupied;
    }
}

This is deliberately simple, but it's the backbone everything else hangs off. The template referenced above extends this pattern into a full 3D coordinate system, since blocks in Color Block Jam move along a constrained axis in 3D space rather than a flat 2D board — which changes your collision and raycasting approach meaningfully.

Handling 3D Movement Constraints

The "3D" part of these puzzle games isn't just a visual upgrade over 2D match-style games — it changes the interaction model. Each block typically has a locked movement axis (it can only slide forward/backward along one direction), which means your input handling needs to:

Raycast from touch/mouse input to detect which block was selected
Determine that block's allowed axis
Project drag input onto that axis
Validate the path is clear before committing the move
Animate the slide, then re-evaluate the board state (did the block reach an exit? Did it unblock another block?)

void OnDrag(Vector2 screenDelta)
{
    Vector3 axis = selectedBlock.MovementAxis;
    float projectedDistance = Vector3.Dot(screenDelta, axis);

    Vector2Int direction = projectedDistance > 0
        ? selectedBlock.PositiveDirection
        : selectedBlock.NegativeDirection;

    if (gridManager.CanMoveTo(selectedBlock.GridPosition + direction))
    {
        selectedBlock.Slide(direction);
    }
}

The important detail here is path validation, not just destination validation — a 3-cell-long block needs every cell along its path checked, not just the final resting cell, or you'll get blocks visually clipping through each other.

Level Design: Data-Driven, Not Hardcoded

If you're building (or extending) a puzzle game with any real content pipeline, hardcoding levels in the scene is a dead end after level 10. Every serious block-jam implementation uses a data-driven level format, typically JSON or ScriptableObjects, so that:

Level designers can iterate without touching code
You can procedurally generate levels and validate solvability offline
Live-ops teams can push new level packs post-launch without a full app update

A ScriptableObject-based level definition is usually the cleanest approach in Unity:

[CreateAssetMenu(fileName = "Level", menuName = "Puzzle/LevelData")]
public class LevelData : ScriptableObject
{
    public int gridWidth;
    public int gridHeight;
    public List<BlockDefinition> blocks;
    public int moveLimit;
    public float parTime;
}

[System.Serializable]
public class BlockDefinition
{
    public Vector2Int startPosition;
    public Vector2Int size;
    public BlockColor color;
    public MovementAxis axis;
}

This structure also makes it trivial to build a level editor tool inside Unity's Editor window, which is genuinely worth the half-day investment if you plan to ship more than a handful of levels. Designers dragging blocks onto a grid and hitting "Save" is dramatically faster than editing raw JSON.

Solvability: The Problem Nobody Talks About Enough

Here's something a lot of tutorials skip entirely: not every configuration of blocks on a grid is solvable. If you're procedurally generating levels, or even hand-placing them quickly, you need a solver pass that verifies a level can actually be completed before it ships.

The simplest reliable approach is a breadth-first search over the state space:

Each unique board configuration is a node
Each legal move is an edge
The goal state is "all target-colored blocks have exited"
If BFS from the initial state can reach a goal state within your move limit, the level is solvable

For small grids (8x8 or smaller with a handful of blocks) this is computationally cheap enough to run at build time or even at runtime for procedural generation. Skipping this step is the single most common reason indie block-jam clones ship with unsolvable levels and get torched in reviews.

Performance: Where 3D Puzzle Games Quietly Fall Apart

3D puzzle games look deceptively simple, but there are a few specific performance traps that hit this genre harder than others:

1. Draw calls from unique block materials. If every block color uses a separate material and shader variant, you'll rack up draw calls fast on a crowded board. Use a single shader with a color property (or a texture atlas) and batch via GPU instancing.

2. Physics-based sliding. It's tempting to use Rigidbody + physics collisions for block movement because it "just works" visually. Don't. Use kinematic, grid-based movement with tweened animation (DOTween or a simple coroutine lerp) instead — physics-driven puzzle logic is a constant source of edge-case bugs (blocks nudging each other out of grid alignment, floating point drift, etc.).

3. Overdraw from transparent UI and particle effects. Block-jam games love juicy VFX on level completion — confetti, particle bursts, glow trails. On mid-range Android devices, unoptimized overdraw from these effects is a common cause of frame drops right at the moment you most want the game to feel polished.

4. Garbage collection spikes from per-move allocations. If your move validation or pathing logic allocates new lists/arrays every single drag event, you'll get GC stutter during exactly the interaction that needs to feel buttery smooth. Pool your temporary collections.

Monetization Architecture

Puzzle games with clear level boundaries are genuinely well-suited to ad monetization, but the implementation details matter for retention:

Interstitials should fire on level completion, not level start — showing an ad before a player even sees the puzzle is a fast way to inflate churn.
Rewarded video works best as an opt-in unstuck mechanic — offering extra moves or a hint after a failed attempt, rather than being forced.
Banner ads, if used at all, belong on menu/level-select screens, never during active gameplay where they compete for touch input space.

Structuring your monetization calls behind an interface rather than calling AdMob/Unity Ads SDKs directly throughout your codebase will save you significant pain later:

public interface IAdService
{
    void ShowInterstitial(System.Action onComplete);
    void ShowRewarded(System.Action onReward, System.Action onFailed);
}

This lets you swap mediation providers, A/B test ad frequency, or add a mediation layer without touching gameplay code — something that matters a lot once you're running live-ops experiments on ad placement.

Reskinning: What Actually Needs to Change

If you're starting from an existing template rather than building from zero — which is a completely reasonable choice given how solved the core mechanics are for this genre — the real differentiation work happens in a fairly narrow set of places:

Visual theme: block materials, environment lighting, particle effects, UI skin
Meta progression: whether you add a level map, currency system, or daily rewards layer on top of the core loop
Difficulty curve: move limits, grid sizes, and the pacing of new mechanics (locked blocks, obstacles, special colors)
Monetization tuning: ad frequency and rewarded-ad placement, calibrated against your own retention data

Before you start layering changes onto any existing Unity codebase — whether it's your own six-month-old project or a template you've picked up — it's worth doing a proper audit first so you know what you're actually working with. I wrote a full checklist for this exact situation here: How to Audit a Unity Codebase Before You Reskin It. It covers dependency checks, asset bloat, deprecated API usage, and the kind of technical debt that turns a "quick reskin" into a multi-week rewrite if you skip it.

Publishing Checklist

A few things worth confirming before you push a build to the stores, specific to this genre:

[ ] Grid and block colliders don't leak physics jitter into visual position
[ ] Level solver pass has validated every level in your content set
[ ] Ad SDK calls are behind an interface and tested in both online/offline states
[ ] Draw calls per typical board state are profiled (Unity Frame Debugger) on a mid-tier device, not just your dev machine
[ ] Save/load system handles interrupted sessions (app killed mid-level) gracefully
[ ] Android back-button and iOS gesture navigation don't break mid-drag input
[ ] Localization strings are externalized, not hardcoded in UI prefabs

Wrapping Up

Block-jam puzzle games are a great genre to build in Unity precisely because the mechanics are well-understood but the execution quality still varies enormously between shipped titles. The difference between a forgettable clone and a chart-performing puzzle game usually comes down to the details covered above: clean grid logic, verified solvability, disciplined performance profiling, and monetization that respects the player's session.

If you want to see a complete, working implementation of these systems rather than building the grid logic, level format, and movement handling from scratch, the Color Block Jam 3D Puzzle Unity template is a solid reference point — it's AdMob-ready, optimized for both Android and iOS, and structured with clean, documented C# scripts that are straightforward to extend. It's also a good case study to pair with the audit checklist above if you're evaluating whether to build on top of it or use it purely as a learning reference.

For more Unity source code and game templates across other genres, the full catalog is browsable here: Unity Games Category.

How to Audit a Unity Codebase Before You Reskin It (A Developer's Checklist)

unity source code — Sun, 09 Aug 2026 18:04:57 +0000

Reskinning a Unity project sounds simple on paper: take an existing game, swap the art, change the theme, ship it. In practice, whether that process takes three days or three weeks almost entirely comes down to one thing — how the original codebase was architected.

Most articles about Unity reskinning talk about this at a high level: "look for clean code," "check the folder structure," "make sure it's modular." That advice is true, but it's also vague enough to be nearly useless when you're actually staring at a .unitypackage you just imported and trying to decide whether it's worth your time.

This article takes a more concrete approach. Instead of general principles, we'll walk through a practical, code-level audit you can run on any Unity project in under thirty minutes — the specific files to open, the specific patterns to look for, and the specific red flags that predict a painful reskin before you've written a single line of code.

Why a Quick Audit Saves You Weeks

Every Unity developer has a story about a project that looked great in the asset store preview and turned into a nightmare once they opened it. Usually, the problem isn't the game design — it's structural decisions made early in development that make even simple changes difficult. A hard-coded path here, a tangled singleton there, and suddenly changing a sprite requires touching four different scripts.

The good news is that these problems are almost always visible within the first few files you open, if you know what to look for. A structured audit turns "does this project feel reskinnable?" — a vague, unreliable gut check — into a checklist you can run consistently across any project.

Step 1: Check How Assets Are Referenced

Open two or three of the core gameplay scripts and search for how they access sprites, prefabs, and audio clips. This is the single most important thing to check, because it determines how much of your reskin will require touching code versus simply dragging in new assets.

Red flag pattern:

public class BubbleSpawner : MonoBehaviour
{
    void SpawnBubble()
    {
        Sprite bubbleSprite = Resources.Load<Sprite>("Sprites/bubble_red");
        GameObject bubble = Instantiate(Resources.Load<GameObject>("Prefabs/Bubble"));
        bubble.GetComponent<SpriteRenderer>().sprite = bubbleSprite;
    }
}

This pattern hard-codes a specific file path directly into the script. To reskin this, you'd need to either rename your new assets to match these exact paths (fragile and confusing) or edit the script directly (extra work, and risky if you're not fully comfortable with the codebase).

What you want to see instead:

public class BubbleSpawner : MonoBehaviour
{
    [SerializeField] private Sprite[] bubbleSprites;
    [SerializeField] private GameObject bubblePrefab;

    void SpawnBubble(int colorIndex)
    {
        GameObject bubble = Instantiate(bubblePrefab);
        bubble.GetComponent<SpriteRenderer>().sprite = bubbleSprites[colorIndex];
    }
}

Here, every visual reference is exposed through the Inspector. Reskinning this component means dragging new sprites into a list — no code changes required. When auditing a project, open the Inspector for a handful of key GameObjects and count how many fields are actually exposed versus how much is buried in Resources.Load calls or hard-coded strings.

Step 2: Look for Data-Driven Configuration

The next thing to check is how game content — levels, item stats, difficulty curves — is defined. Projects that hard-code this information directly into scripts are far more painful to expand or rebalance than ones using external data structures.

Red flag pattern:

void SetLevelDifficulty(int level)
{
    if (level == 1) { spawnRate = 1.5f; enemyCount = 5; }
    else if (level == 2) { spawnRate = 1.2f; enemyCount = 8; }
    else if (level == 3) { spawnRate = 0.9f; enemyCount = 12; }
    // ...and so on, for every level
}

Every new level requires a new code branch. This doesn't just make reskinning harder — it makes any future content updates harder too.

What you want to see instead:

[CreateAssetMenu(fileName = "LevelData", menuName = "Game/LevelData")]
public class LevelData : ScriptableObject
{
    public float spawnRate;
    public int enemyCount;
    public string levelName;
}

With this pattern, level data lives as an asset that can be created, duplicated, and edited entirely inside the Unity Editor. A designer — or a developer doing a quick reskin — can create ten new level variants without opening a script editor at all. When auditing a project, search the codebase for ScriptableObject and see how much of the game's content is defined this way versus hard-coded in if statements or switch cases.

Step 3: Trace One Full Interaction End to End

Pick the single most important interaction in the game — the shot in a physics game, the swipe in a puzzle game, the tap in an arcade game — and trace it from input to outcome. This tells you more about the overall code quality than almost anything else you can check.

This step matters even more in physics-heavy games, where an interaction chain often involves input handling, force application, collision detection, and scoring logic all working together. A good example of what a clean version of this chain looks like is covered in this technical breakdown of building draw-to-solve puzzle mechanics in Unity, including line rendering, physics barriers, and level design. It walks through how a LineRenderer component, physics-based barrier detection, and level-loading logic are wired together in a way that keeps each responsibility isolated — which is exactly the kind of separation you want to look for when auditing an unfamiliar project. If you can read through an interaction like this and understand what each component is responsible for without cross-referencing five other scripts, that's a strong signal the project is well-structured.

If, instead, tracing a single interaction sends you jumping between a dozen loosely related scripts with unclear responsibilities, that's a signal the project may require significantly more time to safely modify, even if the end result would eventually look polished.

Step 4: Check for Singleton Overuse and Tight Coupling

Singletons are common in Unity projects — they're a convenient way to manage game state, audio, or UI — but overused or poorly implemented singletons can make a codebase surprisingly fragile when you start modifying it.

Watch for this pattern spreading everywhere:

public class GameManager : MonoBehaviour
{
    public static GameManager Instance;

    public int score;
    public int currentLevel;
    public AudioSource musicSource;
    public UIManager ui;
    public PlayerController player;
    // dozens of unrelated fields and methods
}

When a single "God object" like this ends up referenced throughout the entire codebase, even small changes can have unpredictable ripple effects, since so many systems depend on its internal state directly. This isn't necessarily a dealbreaker for a reskin — most reskins don't require deep refactoring — but it's a signal to be more cautious when adding new mechanics or making structural changes, since the blast radius of any given edit is harder to predict.

Step 5: Confirm UI Is Built to Scale

UI issues are one of the most common sources of last-minute bugs during a reskin, especially when new art assets have different proportions than the originals. Open the Canvas settings and check the Canvas Scaler component.

Look for a UI Scale Mode set to Scale With Screen Size, with a sensible reference resolution (commonly 1080×1920 for portrait mobile games) and a Match value that blends width and height scaling rather than relying on just one axis. Projects that leave the Canvas Scaler on Constant Pixel Size often look correct on the developer's test device but break on other aspect ratios — something that becomes especially noticeable once you start swapping in UI art with different dimensions.

Step 6: Skim the Monetization Integration

Finally, search the project for ad network SDK calls (AdMob, IronSource, Unity Ads, etc.) and in-app purchase logic. You don't need to fully understand the integration during an audit — you just need to confirm it exists, roughly where it sits in the code, and whether it's cleanly separated from gameplay logic or tangled directly into UI button handlers. Monetization code that's scattered across multiple unrelated scripts is a sign that UI reskinning could accidentally break ad triggers or purchase flows if you're not careful.

Putting It Together: A Thirty-Minute Audit Checklist

Here's the condensed version you can run on any new Unity project before committing to a reskin:

Open two or three core gameplay scripts — are assets referenced through Inspector fields, or hard-coded paths?
Search for ScriptableObject usage — is content data-driven, or buried in conditional logic?
Trace one core interaction from input to outcome — is the responsibility chain clear and isolated?
Search for singleton patterns — is state management centralized in a way that's manageable, or sprawling?
Check the Canvas Scaler settings — is UI built to scale across devices?
Locate the monetization integration — is it cleanly separated from gameplay and UI code?

None of these checks require deep familiarity with the specific game. They're structural questions that apply to almost any Unity project, regardless of genre, and running through them consistently makes it far easier to compare multiple candidate projects objectively instead of relying on how polished a demo video looks.

Where This Fits Into the Bigger Picture

This kind of code-level audit complements the higher-level evaluation criteria — genre fit, art requirements, monetization strategy — that usually come first when deciding what to reskin. A more general breakdown of what to look for across several template genres, including puzzle, physics-based, and simulation projects, is covered in this guide to the top Unity game templates that are easiest to reskin and publish, which is a useful starting point before you get into the kind of technical audit described here.

Once you've narrowed down a genre and a rough shortlist of candidates, running this checklist against each one — ideally by browsing a broader catalog of available Unity source code projects so you have more than one option to compare — helps you make a more informed, evidence-based decision instead of picking based on demo footage alone.

A Note on Reading Unfamiliar Codebases Efficiently

One skill that makes this whole audit process faster over time is getting comfortable reading unfamiliar code without needing to understand every line. When you open a script for the first time, resist the urge to read it top to bottom like a book. Instead, scan for three things first: the public and serialized fields (these tell you what's configurable from the Inspector), the method names (these tell you what the class actually does), and any calls to other manager or singleton classes (these tell you how coupled this script is to the rest of the project).

This scanning approach is faster than a full read-through and, in practice, tells you almost everything you need for an audit. If a script's fields are mostly private with hard-coded values inside method bodies, that's already a signal before you've read a single line of logic. If the method names are vague (DoStuff(), Handle(), Update2()), that's a signal too — poorly named methods often correlate with poorly organized logic elsewhere in the same script.

Over time, this kind of fast scanning becomes intuitive. You'll start recognizing patterns — a well-structured spawner script, a tangled UI controller, a clean ScriptableObject-driven economy system — within seconds of opening a file, which makes the thirty-minute audit described above get faster with every project you run it against.

Common Objections to This Process

It's worth addressing a couple of objections that come up when developers hear about running a structured audit before starting a reskin.

"This feels like overkill for a small project." For very simple genres — a single-scene puzzle game, for example — a lighter version of this audit is fine. You might only need steps 1 and 3 (asset references and interaction tracing) to get a confident read on the project. The full checklist matters most for genres with more interconnected systems, like simulation, RPG, or physics-heavy games, where a structural problem discovered late is much more expensive to fix.

"I can just start and figure it out as I go." This works for developers with enough experience to recognize structural problems the moment they encounter them and adapt on the fly. For developers earlier in their reskinning journey, though, discovering a hard-coded path or a tangled singleton chain three days into a project — after you've already invested time in art direction based on assumptions about how easy certain changes would be — is a far more expensive way to learn the same lesson a thirty-minute audit would have taught you upfront.

Final Thoughts

A thirty-minute audit won't tell you everything about a project, but it will surface the structural issues that matter most for a smooth reskin: how assets are referenced, whether content is data-driven, how tightly coupled the core systems are, and whether UI and monetization are built to handle change gracefully.

Developers who run this kind of check consistently — rather than relying on gut feeling after watching a trailer — end up with far fewer surprises once they're a week into a project. It's a small upfront investment that pays for itself almost every time, and over multiple projects, it becomes second nature: open a handful of scripts, ask the right questions, and you'll know within minutes whether a codebase is going to work with you or against you.

Building Draw-to-Solve Puzzle Mechanics in Unity: Line Rendering, Physics Barriers, and Level Design

unity source code — Fri, 07 Aug 2026 18:00:35 +0000

Draw-to-solve puzzles are one of the most reliably engaging formats in mobile gaming. The concept is simple to explain in one sentence — draw a line to protect or guide something — yet the implementation touches almost every system in Unity: input handling, 2D physics, procedural mesh generation, and level design tooling. Games in this genre (protecting a character from hazards by sketching barriers, guiding a ball through a maze you draw yourself, or fencing off danger zones) share a common technical backbone, and that backbone is worth understanding in depth if you're building anything in this space.

This article breaks down how draw-to-solve mechanics actually work under the hood in Unity: converting a finger swipe into a physical object, managing limited "ink" as a resource, structuring levels so difficulty scales predictably, and avoiding the performance traps that show up once you have dozens of hand-drawn colliders on screen at once.

1. From Touch Input to a Physical Line

The first technical challenge is converting a raw touch gesture into something the physics engine can collide with. This happens in three stages: capturing input points, rendering the line, and generating a collider that matches it.

Capturing input points

You don't want to record every single touch event — on a modern phone that can be hundreds of points per second, most of which are redundant. Instead, sample points at a minimum distance threshold:

if (Vector2.Distance(lastPoint, currentPoint) > minPointDistance)
{
    linePoints.Add(currentPoint);
    lastPoint = currentPoint;
}

This keeps your line smooth without flooding your point list with near-duplicate positions, which matters both for rendering performance and for the next step.

Rendering the line

Unity's LineRenderer is the natural fit here. It takes your sampled points directly and handles width, corner smoothing, and material rendering without you needing to build custom meshes for the visual layer. The main tuning knobs are numCornerVertices and numCapVertices, which control how smooth curves and line ends look — worth bumping up slightly for thin, fast-drawn lines that would otherwise look jagged.

Generating a matching collider

This is the part that trips people up. LineRenderer is purely visual — it doesn't collide with anything. You need to generate an EdgeCollider2D (or a chain of small BoxCollider2D segments) that follows the same points:

EdgeCollider2D edgeCollider = drawnObject.AddComponent<EdgeCollider2D>();
edgeCollider.points = linePoints.ToArray();

EdgeCollider2D is generally the better choice over stitching together box colliders — it's lighter weight and handles arbitrary curved paths natively. The one caveat is that edge colliders are one-sided in terms of physics behavior in some configurations, so test collision response from both approach directions during development, not just the one you happen to test with first.

2. Treating Ink as a Resource, Not Just a Cosmetic Meter

Most games in this genre limit how much a player can draw, and that constraint is what turns "draw a line" into an actual puzzle rather than a trivial task. The naive approach is to track ink as "number of points drawn," but that ties your resource economy directly to your sampling rate, which is a mistake — change your point-distance threshold later and you silently rebalance every level.

The more robust approach is to track ink by cumulative line length:

float segmentLength = Vector2.Distance(previousPoint, newPoint);
currentInkUsed += segmentLength;
if (currentInkUsed >= maxInkAllowed)
{
    StopDrawing();
}

This decouples your resource budget from implementation details like sampling rate and screen resolution, which matters a lot once you're designing dozens of levels and need ink budgets to feel consistent across different device DPIs.

It's also worth exposing ink remaining as a normalized value (0 to 1) rather than a raw float, since your UI, difficulty curve, and any "undo" or "erase" mechanics will all want to reference it that way.

3. Structuring Hazards and Win Conditions Independently of Drawing

A recurring architectural mistake — similar to what shows up in physics-based sports and board games — is coupling win/loss detection directly to the drawing system. It's tempting to check "did the hazard's path get blocked" inside the same script that handles touch input. This works until you add a second hazard type, at which point the drawing script becomes a dumping ground for unrelated game logic.

A cleaner separation:

Drawing system — only responsible for capturing input, rendering the line, generating the collider, and tracking ink. It doesn't know or care what the line is protecting against.
Hazard system — each hazard (a bee, a falling object, a rolling ball) is its own component with its own movement and damage logic. It reacts to whatever colliders happen to be in its way, drawn or not.
Objective system — a separate controller watching win/loss state (e.g., "target survived for N seconds," "target reached the goal zone"). It listens to events from the hazard system rather than polling collision state directly.

This separation pays off the moment you want to introduce a new hazard type or a new win condition — you're adding a new component, not modifying a monolithic controller that already handles five unrelated responsibilities.

4. Designing a Difficulty Curve That Actually Escalates

Puzzle games live or die on their difficulty curve, and "escalating" doesn't just mean adding more hazards. There are several independent difficulty levers, and mixing them deliberately produces a much more interesting curve than cranking all of them up together:

Ink scarcity — reducing the ink budget relative to the space that needs covering forces more efficient, minimal solutions.
Hazard timing — a hazard that appears immediately is easier to plan around than one that spawns mid-level, forcing players to react rather than pre-plan.
Spatial complexity — more open space with multiple valid solution paths early on; tighter, more constrained geometry later that narrows the solution space.
Time pressure — a soft timer or a hazard that accelerates over time adds pressure without changing the core puzzle logic at all.

A practical technique is to build a simple internal scoring system per level — something like (hazard count × timing complexity) + (spatial complexity / ink budget) — and use it to sanity-check that your level order actually escalates in the way you intend, rather than relying purely on gut feel. It's easy to accidentally place a genuinely harder level before an easier one just because it "felt" like the next step during design.

5. Level Data as Configuration, Not Code

Because this genre lives or dies on having a large number of levels, hardcoding hazard positions and ink budgets in scene files scales badly. A ScriptableObject-based level definition is a far better fit:

[CreateAssetMenu(fileName = "LevelData", menuName = "Puzzle/LevelData")]
public class LevelData : ScriptableObject
{
    public float maxInk;
    public float surviveDuration;
    public HazardConfig[] hazards;
    public Vector2 targetStartPosition;
}

This has a few concrete benefits beyond just tidiness:

Designers (or you, wearing a designer hat) can tune values without touching scene hierarchies.
Levels can be loaded dynamically by index, which makes A/B testing difficulty curves trivial.
It's straightforward to build a lightweight in-editor level browser that instantiates any LevelData asset into a test scene, dramatically speeding up iteration.

If you eventually want server-driven levels (for live-ops style content updates without an app store release), the ScriptableObject structure also maps cleanly onto a JSON schema, since the fields are simple serializable types.

6. Performance Considerations Specific to This Genre

Draw-to-solve games look simple, but a few performance issues show up reliably once you're testing on real mid-range Android hardware rather than an editor or flagship device:

Collider count creep. If a player draws several long, winding lines across a level, and each becomes its own EdgeCollider2D, you can end up with more colliders active simultaneously than you'd expect. Since these are typically static once drawn, marking them appropriately and avoiding unnecessary Rigidbody2D components on drawn objects (a kinematic or static collider is usually sufficient) keeps physics step costs down.

Line renderer vertex count. Long, detailed lines with high corner vertex counts add up in render cost, especially with multiple lines active at once. A simple mitigation is to apply light point simplification (removing points that don't meaningfully change the line's direction) before finalizing the drawn line, rather than keeping every raw sampled point.

Garbage collection from per-frame allocations. It's common to see List<Vector2> allocations happening every frame during active drawing if you're not careful about reusing collections. Pre-allocating your point list with a reasonable capacity and clearing rather than reallocating between draws avoids unnecessary GC pressure, which matters more on this genre's target audience of budget and mid-range devices than it might for a higher-spec game.

Touch input smoothing cost. If you're applying smoothing algorithms (like Catmull-Rom interpolation) to raw touch points for a nicer-looking line, do it once when finalizing the line rather than recalculating the entire smoothed path on every new point added — that's an easy accidental O(n²) cost as lines get longer.

7. Testing Solvability

One issue specific to physics-based puzzle design that's easy to overlook: because your solution space is player-drawn geometry rather than a fixed set of moves, it's possible to accidentally design a level that's unsolvable with the ink budget you've assigned, especially after later tweaking hazard speed or spawn timing. A lightweight internal tool — even something as simple as an automated "bot" that tries a handful of heuristic drawing strategies and reports whether any of them succeed — can catch these regressions before they ship, rather than relying entirely on manual playtesting to catch a broken level.

8. Handling Undo, Erase, and Multi-Touch Edge Cases

Once a drawing mechanic ships, players immediately start testing its edges — drawing with two fingers at once, starting a new line before finishing the last one, or expecting to erase a mistake without losing their entire ink budget. A few patterns handle these cleanly:

Single active stroke enforcement. Most implementations restrict input to one active touch for drawing, ignoring secondary touch IDs rather than trying to support simultaneous multi-line drawing. This avoids a whole class of state-management bugs where two EdgeCollider2D objects are being built concurrently from interleaved touch events.

if (Input.touchCount > 0 && activeTouchId == -1)
{
    Touch touch = Input.GetTouch(0);
    activeTouchId = touch.fingerId;
}

Undo as object removal, not ink refund by formula. Rather than recalculating ink mathematically when a line is erased, it's simpler and less bug-prone to store the ink cost alongside each drawn line object when it's created, then simply refund that stored value and destroy the object on undo. This avoids drift between your ink tracking and what's actually on screen, which is a common source of "ink went negative" bugs.

Debounced erase gestures. If erasing is triggered by a gesture like a tap-and-hold on an existing line, add a short delay before triggering removal so that a quick accidental tap during normal drawing doesn't delete a line the player wanted to keep.

9. Cross-Device Input Consistency

Draw-to-solve games are unusually sensitive to input differences between devices, more so than many other mobile genres, because the entire mechanic is built on precise gesture capture. A few things worth testing explicitly rather than assuming they'll "just work":

DPI and screen size variance. A minPointDistance threshold tuned in editor on a desktop-simulated screen often feels too sparse or too dense on an actual device. Testing on both a small-screen budget phone and a larger flagship tends to surface this quickly.
Touch pressure and palm rejection. Some devices report phantom touch points from a resting palm during drawing, particularly on larger tablets. Filtering touches by a minimum distance from the primary touch, or simply capping to a single tracked touch ID, avoids most of this.
Editor mouse input vs. device touch input. It's easy to build and test an entire drawing system using Input.mousePosition in editor and only discover touch-specific quirks (multi-touch noise, different pressure curves) once you build to an actual device. Testing on hardware early, even with placeholder art, avoids late-stage surprises.

Closing Thoughts

Draw-to-solve puzzle mechanics look deceptively simple from a player's perspective, but a solid implementation touches input sampling, physics collider generation, resource management, and level configuration — each of which benefits from being kept as its own clearly bounded system rather than tangled together. Getting the ink-as-resource model right, decoupling hazards from the drawing system itself, and treating levels as data rather than hardcoded scenes are the three decisions that will save the most rework as your level count grows from a handful of prototypes to a full game.

These same principles — separating input capture from physics response, and treating game content as configurable data rather than code — apply broadly across mobile genres, including runner and arcade games where core loop tuning and difficulty pacing follow a similar pattern. This breakdown of building an endless roller game in Unity covers that side of the equation, including core loop structure and monetization pacing: Building an Endless Roller Game in Unity.

For a working reference implementation of the draw-to-protect mechanic covered in this article, a complete Unity puzzle rescue project is available here: Save The Dogs Unity Game Source Code.

Building an Endless Roller Game in Unity: Core Loop, Difficulty Curve, and Monetization

unity source code — Thu, 06 Aug 2026 17:56:40 +0000

Hyper-casual games live or die in the first 15 seconds. If a player doesn't understand the controls immediately and feel a pull to try "just one more run," they're gone. Few genres make this rule as obvious as the endless roller — the "control a ball as it falls through a shifting maze of platforms" format popularized by games like the original Rapid Roll on Java phones, and still alive and well on mobile app stores today.

I've spent the last few weeks digging into how these games are actually structured under the hood — not just playing them, but pulling apart the core loop, the difficulty curve, and the monetization layer that makes them commercially viable. This post is a breakdown of what I learned, aimed at anyone building (or reskinning) a hyper-casual roller game in Unity.

Why the Roller Sub-Genre Still Works

The endless roller format has three properties that make it a near-ideal hyper-casual template:

One input axis. You're either moving left/right (swipe or tilt) or you're not. There's no button mapping to learn, no tutorial screen required.
A single failure state. You fall off, you die, you restart. No health bars, no combo systems, no ambiguity about what just happened.
A score that only goes up during a run. Distance fallen or platforms cleared gives players an immediate, legible measure of "did I do better than last time."

These three properties combine into what game designers call a "tight core loop" — the shortest possible path from start to fail to retry, with nothing extraneous in between. When you're evaluating (or building) a roller game, almost every design decision should be judged against whether it protects or dilutes that loop.

The Core Loop, Broken Into Systems

If you strip a roller game down to its systems, you get roughly this:

Input system — reads swipe or tilt input and converts it into lateral ball velocity
Descent system — the ball (or camera) moves downward at a speed that increases over time
Platform generator — spawns platforms ahead of the ball and despawns them behind it
Collision/fail system — detects when the ball misses a platform or hits an obstacle
Score system — tracks distance or platforms cleared, persists a high score
Monetization system — shows interstitials on death, rewarded ads for revives or bonuses

Let's go through the ones that actually determine whether the game feels good.

Input: Swipe vs. Tilt

Most implementations offer swipe-to-move as the primary control, with tilt as an alternative for players who prefer motion controls. A minimal swipe handler in Unity looks something like this:

public class SwipeInput : MonoBehaviour
{
    [SerializeField] private float swipeThreshold = 50f;
    private Vector2 startTouch;

    void Update()
    {
        if (Input.touchCount == 0) return;

        Touch touch = Input.GetTouch(0);

        if (touch.phase == TouchPhase.Began)
        {
            startTouch = touch.position;
        }
        else if (touch.phase == TouchPhase.Moved)
        {
            float deltaX = touch.position.x - startTouch.x;
            if (Mathf.Abs(deltaX) > swipeThreshold)
            {
                MoveBall(Mathf.Sign(deltaX));
                startTouch = touch.position;
            }
        }
    }

    void MoveBall(float direction)
    {
        // apply lateral velocity to the ball's Rigidbody
    }
}

The important detail isn't the code itself — it's the threshold tuning. Too sensitive and players overshoot platforms on accident; too sluggish and the game feels unresponsive. This value should almost always be exposed as a serialized field so it can be tuned by feel during playtesting, not hardcoded.

Procedural Platform Generation

The platform layout is where most of the "feel" of a roller game actually comes from. A naive approach spawns platforms at fixed intervals with a random x-offset. That's fine as a first pass, but it produces layouts that feel random rather than intentional — sometimes trivially easy, sometimes unfairly narrow.

A better approach uses a small set of hand-authored "chunk" prefabs (straight gaps, staggered platforms, narrow bridges, moving platforms) that get selected and stitched together procedurally, weighted by the current difficulty tier. This gives you the variety of procedural generation with the readability of hand-designed level segments — you avoid the "impossible gap" problem that pure randomness tends to produce.

Difficulty Curve

The descent speed increase should not be linear. A curve that increases quickly at first and then flattens tends to feel better than a constant acceleration, because:

New players get a fair first 10–15 seconds to learn the controls
The mid-game ramp creates the tension spike that makes near-misses feel earned
The late-game plateau prevents the game from becoming physically unplayable (which just frustrates rather than challenges)

A simple approach is an exponential decay toward a max speed:

float currentSpeed = Mathf.Lerp(baseSpeed, maxSpeed, 1f - Mathf.Exp(-difficultyRamp * elapsedTime));

Tune difficultyRamp by feel, not by formula — this is one of those numbers you adjust after watching five real people play, not something you can derive theoretically.

Monetization Without Breaking the Loop

Hyper-casual games almost universally monetize through ads rather than IAP-heavy economies, and AdMob is the default choice for most Unity teams shipping to both Android and iOS. The two placements that matter most:

Interstitial on death — shown after the score screen, not instead of it. Never interrupt the moment of failure itself; let the player see their score first.
Rewarded video for a revive — offering "watch an ad to continue from where you fell" is one of the highest-performing rewarded placements in the genre, because it's opt-in and clearly valuable to the player.

The mistake I see most often in reskinned templates is over-frequent interstitials — showing one after every single run regardless of run length. A better heuristic is to gate interstitials behind either a minimum elapsed time or a run counter (e.g., every 2nd or 3rd death), which noticeably improves retention without sacrificing much revenue.

If you're planning to layer in-app purchases on top of ad monetization — cosmetic ball skins, an ad-removal purchase, or a starter bundle — it's worth understanding Unity's IAP receipt validation flow before you wire anything up, since getting it wrong is a common source of App Store rejections. I found this guide useful for getting the setup right the first time: Unity In-App Purchase Guide.

Where Roller Games Fit Among Other Hyper-Casual Loops

It's worth zooming out for a second. Endless rollers are one point on a spectrum of hyper-casual and casual core loops, and comparing them against other genres clarifies why certain design choices matter. I recently wrote about the opposite end of that spectrum — the core loop of an idle RPG clicker, where the challenge isn't split-second reflexes but pacing long-term progression, offline earnings, and boss-fight loot cadence over days rather than seconds. If you're deciding what genre to build next, or just want to see how differently "core loop" design plays out when the session length changes from 30 seconds to 30 minutes, it's a useful comparison: Designing the Core Loop for an Idle RPG Clicker in Unity.

Performance Considerations for Mobile

A few things matter disproportionately for a fast-paced mobile roller:

Object pooling for platforms. Instantiating and destroying platform prefabs every few seconds will cause GC spikes that are very noticeable in a game running at high speed. Pool and reuse instead.
Simple collision shapes. Box or sphere colliders only — mesh colliders on fast-moving objects are a common source of tunneling bugs at high descent speeds.
Fixed timestep tuning. If the ball uses Rigidbody physics, make sure Fixed Timestep in Project Settings is tight enough to avoid physics inconsistency at high speeds, but not so tight that it tanks frame rate on low-end Android devices.
Texture atlasing. Roller games typically use flat, minimal art — atlas everything into as few draw calls as possible, since this is one of the few genres where the frame rate ceiling actually affects playability, not just visual polish.

Reskinning vs. Building From Scratch

If you're evaluating whether to build a roller game from scratch or start from an existing template, the honest answer depends on your timeline. Building the systems above from zero — input handling, chunk-based procedural generation, a tuned difficulty curve, AdMob integration, and mobile-optimized rendering — is a solid one-to-two week project for a solo developer who's done it before, longer if it's your first time wiring up ad mediation.

That's the gap that pre-built templates are meant to fill. I looked at Rapid Roll, a Unity source template built around exactly this loop — swipe/tilt-controlled ball descent, chunk-based platform generation, a progressive difficulty ramp, and AdMob interstitial/rewarded placements already wired in. For a reskin project or a fast prototype to validate a theme before investing in original assets, starting from a working, tuned implementation like this is usually a faster path to a Play Store build than reimplementing all of the above from a blank Unity project — especially the ad mediation and difficulty tuning, which tend to eat the most iteration time.

Wrapping Up

The endless roller genre looks simple on the surface, and that's exactly the point — every system underneath is in service of keeping the core loop as short and legible as possible. If you're building one:

Keep input responsive and tune the swipe/tilt threshold by feel
Use chunk-based generation over pure randomness to avoid unfair layouts
Curve your difficulty ramp instead of scaling linearly
Gate interstitials by run count or time, not every single death
Pool your platforms and keep collision shapes simple for consistent frame rate on low-end devices

Whether you build the loop from scratch or start from a template, the systems above are what separate a roller game that feels good from one that just technically works. Happy building.

Designing the Core Loop for an Idle RPG Clicker in Unity: Boss Fights, Loot, and Offline Progression

unity source code — Wed, 05 Aug 2026 17:43:53 +0000

Idle RPG clickers look deceptively simple from the outside. Tap the screen, watch a number go up, defeat a boss, repeat. But if you've ever tried to actually build one, you know the real complexity isn't the tapping — it's the systems underneath it. Offline progression math, loot balancing, boss difficulty curves, and save-state integrity all have to work together, or the whole game falls apart the moment a player closes the app and comes back six hours later.

In this article I want to break down the core architecture behind a typical idle RPG clicker — boss battles, loot systems, idle/offline earnings, and progression scaling — the way you'd actually structure it in Unity with C#. I'll use patterns pulled from a shipped mobile template as a reference point throughout, because it's easier to reason about real systems than hypothetical ones.

Why Idle + Clicker Hybrids Are Harder Than They Look

A pure clicker game only has to solve one problem: make tapping feel good. A pure idle game only has to solve one problem: make numbers grow in a satisfying curve while the player is away. An idle RPG clicker has to solve both problems simultaneously, and then reconcile them so neither system undermines the other.

If your idle income scales too aggressively, active tapping becomes pointless and players stop engaging. If tapping scales too aggressively, idle income feels like a rounding error and your retention hook (the thing that brings players back after being offline) stops working. Getting this balance right is 80% of what makes these games either addictive or forgettable.

Core System #1: The Tap-Damage Loop

At the most basic level, you need a damage-per-tap system that feeds into a boss health pool. This sounds trivial, but the way you structure it determines how easy the rest of the game is to build on top of.

Here's a minimal but extensible version:

public class BossCombatController : MonoBehaviour
{
    public BossData currentBoss;
    private float currentBossHealth;

    public event Action<float, float> OnBossHealthChanged; // current, max
    public event Action<BossData> OnBossDefeated;

    private void Start()
    {
        currentBossHealth = currentBoss.maxHealth;
    }

    public void ApplyTapDamage(float baseDamage, float critMultiplier = 1f)
    {
        float finalDamage = baseDamage * critMultiplier;
        currentBossHealth = Mathf.Max(0, currentBossHealth - finalDamage);

        OnBossHealthChanged?.Invoke(currentBossHealth, currentBoss.maxHealth);

        if (currentBossHealth <= 0)
        {
            HandleBossDefeat();
        }
    }

    private void HandleBossDefeat()
    {
        OnBossDefeated?.Invoke(currentBoss);
        // Loot roll, next boss load, and reward calculation happen
        // in listeners subscribed to OnBossDefeated, not here.
    }
}

The key design decision here is keeping BossCombatController dumb on purpose. It doesn't know about loot tables, currency, or UI. It just tracks health and fires events. This separation matters more in idle games than most genres, because you'll eventually need the exact same "boss defeated" event to trigger loot drops, idle-rate recalculation, achievement checks, and save-state writes — all independently.

Core System #2: Loot and Reward Loops

The loot loop is what keeps the tap-damage loop from feeling repetitive. Every boss kill needs to produce some combination of currency, item drops, and upgrade materials, ideally with enough randomness that players don't feel like they're grinding a fixed script.

A simple weighted loot table looks like this:

[System.Serializable]
public class LootEntry
{
    public string itemId;
    public float dropWeight;
    public int minQuantity;
    public int maxQuantity;
}

public class LootTable : MonoBehaviour
{
    public List<LootEntry> entries;

    public List<(string itemId, int quantity)> RollLoot(int rolls = 1)
    {
        var results = new List<(string, int)>();
        float totalWeight = entries.Sum(e => e.dropWeight);

        for (int i = 0; i < rolls; i++)
        {
            float roll = UnityEngine.Random.Range(0, totalWeight);
            float cumulative = 0f;

            foreach (var entry in entries)
            {
                cumulative += entry.dropWeight;
                if (roll <= cumulative)
                {
                    int qty = UnityEngine.Random.Range(entry.minQuantity, entry.maxQuantity + 1);
                    results.Add((entry.itemId, qty));
                    break;
                }
            }
        }

        return results;
    }
}

Two things matter here that are easy to overlook:

Weighted, not fixed-probability, rolls. Fixed drop chances (e.g., "10% chance for X") get harder to balance as your loot table grows, because every new item changes the effective probability of every other item. A weighted system self-normalizes as you add or remove entries.
Loot rolling is decoupled from combat. LootTable has no idea a boss even exists. It just responds to "roll N times" and returns results. That decoupling is what lets you reuse the exact same loot system for chests, daily rewards, or event drops later without duplicating logic.

I found this same separation pattern in Lootscape Boss Mania, a Unity idle RPG clicker template that combines tap-based boss combat with an offline idle-earning system. Looking at how a shipped project structures the boundary between combat, loot, and progression is a good sanity check against over-engineering — or under-engineering — your own version of the same systems.

Core System #3: Idle and Offline Progression

This is the system that actually differentiates an "idle RPG" from a plain clicker, and it's also the one most beginners get wrong. The naive approach — just multiply idle-rate by elapsed real-world time — works, but it opens the door to two problems: clock manipulation exploits, and reward curves that don't feel intentional.

Here's a more defensible pattern:

public class IdleProgressionManager : MonoBehaviour
{
    private const float MAX_OFFLINE_HOURS = 8f;

    public float goldPerSecond;

    public void SaveExitTimestamp()
    {
        PlayerPrefs.SetString("last_exit_utc", DateTime.UtcNow.ToString("o"));
        PlayerPrefs.Save();
    }

    public float CalculateOfflineEarnings()
    {
        if (!PlayerPrefs.HasKey("last_exit_utc"))
            return 0f;

        DateTime lastExit = DateTime.Parse(
            PlayerPrefs.GetString("last_exit_utc"),
            null,
            System.Globalization.DateTimeStyles.RoundtripKind
        );

        TimeSpan elapsed = DateTime.UtcNow - lastExit;
        float elapsedSeconds = Mathf.Clamp(
            (float)elapsed.TotalSeconds,
            0,
            MAX_OFFLINE_HOURS * 3600f
        );

        return elapsedSeconds * goldPerSecond;
    }
}

A few implementation notes worth calling out:

Always store timestamps in UTC. If you store local time, you'll get silently wrong results the moment a player crosses a daylight-saving boundary or travels between timezones.
Cap offline earnings. An uncapped idle system either becomes exploitable (leave the game running for a week, come back absurdly overpowered) or forces you into diminishing-returns math that's harder to communicate to players. A hard cap with a clear UI message ("earning gold for up to 8 hours while away") is usually the simplest honest design.
Recalculate goldPerSecond from upgrades, not from a cached value. If you cache the idle rate at the moment the player exits, you lose the ability to retroactively apply upgrades or events that should affect offline earnings.

Core System #4: Progression and Difficulty Scaling

The last piece is tying boss difficulty, loot value, and idle rate together into a single progression curve. This is where a lot of idle games either flatten out (boring) or spike unpredictably (frustrating). A common, safe approach is exponential scaling with a tunable growth rate:

public static class ProgressionCurve
{
    public static float BossHealthForStage(int stage, float baseHealth, float growthRate = 1.15f)
    {
        return baseHealth * Mathf.Pow(growthRate, stage - 1);
    }

    public static float LootValueForStage(int stage, float baseValue, float growthRate = 1.08f)
    {
        return baseValue * Mathf.Pow(growthRate, stage - 1);
    }
}

Notice that boss health and loot value scale at different rates (1.15 vs 1.08 in this example). That gap is intentional — it's what creates the sense that later stages require real strategic investment (upgrades, better gear) rather than just more tapping. If both curves scale at the same rate, the game plateaus into a flat grind with no perceived progress.

Putting the Systems Together

None of these four systems — combat, loot, idle progression, and difficulty scaling — are complicated in isolation. The actual engineering challenge is keeping them loosely coupled enough that you can tune, replace, or extend any one of them without breaking the others. In practice that means:

Combat fires events; it doesn't call loot or save logic directly
Loot tables are content-driven (ScriptableObjects or JSON), not hardcoded
Idle earnings are recalculated from current stats, never cached
Progression curves are pure functions you can unit test independently of Unity's scene graph

This event-driven separation is a pattern that shows up constantly outside of idle clickers too. I covered a very similar architecture recently while building out a crowd runner combat system with army growth and battle phases — different genre entirely, but the same underlying principle: keep your state-changing systems dumb and event-driven, and let independent listeners handle the consequences.

A Note on Content-Driven Design

One thing that separates a shippable idle RPG from a tech demo is how much of the game lives in data rather than code. Boss stats, loot tables, upgrade costs, and stage requirements should all be defined in ScriptableObjects or external config files, not hardcoded into MonoBehaviours. This matters for two practical reasons:

Balancing becomes a spreadsheet problem, not a recompile problem. You want a designer (even if that's just you, wearing a different hat) to be able to tune a boss's health or a loot drop rate without touching C#.
Reskinning and content expansion become trivial. If your combat, loot, and progression logic never reference specific boss names or item IDs directly, adding a new boss or a new loot tier is a data change, not a code change.

This same content-driven philosophy extends naturally into adjacent genres. Idle mechanics aren't exclusive to RPG clickers — resource-accumulation and management games lean on nearly identical systems: production rates instead of gold-per-second, harvest cycles instead of boss timers, and upgrade trees that scale the same way. If you're exploring how these systems adapt to a slower-paced, management-style game, it's worth looking at how a title like Farm Village structures its resource and progression loop — the underlying math (rate-based accumulation, offline calculation, tiered upgrades) is strikingly similar to what an idle RPG clicker needs, just wrapped in a different theme and pacing.

Common Pitfalls to Avoid

A few mistakes I see repeatedly in idle/clicker prototypes:

Storing floats for currency past a certain scale. Idle games generate very large numbers quickly. Standard float precision starts breaking down well before you hit typical late-game currency values. Switch to double, or better, a custom big-number type (many idle games implement a simple mantissa/exponent pair) once your numbers regularly exceed a few million.

Recalculating idle rate inside Update(). Idle-rate math should only run when something actually changes it — an upgrade purchase, a stage completion, a boss defeat. Recomputing it every frame is wasted work and makes the system harder to reason about.

Tight coupling between UI and game state. If your boss health bar directly polls BossCombatController.currentBossHealth every frame instead of subscribing to OnBossHealthChanged, you'll eventually hit desync bugs the moment you add pause states, background processing, or save/load transitions.

No offline cap communication. If you cap offline earnings at 8 hours but never tell the player, you'll get support messages and negative reviews from people who feel cheated. Surface the cap in the UI explicitly.

Wrapping Up

Idle RPG clickers are a genuinely good genre to study if you're trying to get better at systems-level game architecture, because the constraints are unusually tight: everything has to work correctly even when the player isn't actively playing, every number has to scale predictably over potentially hundreds of stages, and every system has to stay loosely coupled enough to support ongoing content additions without a rewrite.

If you're building your own version of this loop, start with the four systems above — tap combat, loot rolls, offline progression, and difficulty scaling — get each one working in isolation with unit tests where possible, and only then wire them together through events. It's a slower start than jamming everything into one big GameManager class, but it pays off the moment you need to add your fifth boss, your tenth loot tier, or your first live event.

What patterns have you used for offline progression or loot balancing in your own projects? I'd be curious to hear how other people have handled the big-number precision problem in particular — that one tends to bite everyone eventually.

Bonus: A Simple Big-Number Type

Since it came up above, here's a minimal mantissa/exponent implementation you can drop into a project once your currency values start exceeding what double can represent cleanly (roughly 1e15 before precision loss becomes visible, and 1e308 before you hit a hard ceiling):

[System.Serializable]
public struct BigNumber
{
    public double mantissa;
    public int exponent;

    public BigNumber(double mantissa, int exponent = 0)
    {
        this.mantissa = mantissa;
        this.exponent = exponent;
        Normalize();
    }

    private void Normalize()
    {
        if (mantissa == 0) { exponent = 0; return; }

        while (Mathf.Abs((float)mantissa) >= 10)
        {
            mantissa /= 10;
            exponent++;
        }
        while (Mathf.Abs((float)mantissa) < 1 && mantissa != 0)
        {
            mantissa *= 10;
            exponent--;
        }
    }

    public static BigNumber operator +(BigNumber a, BigNumber b)
    {
        int expDiff = a.exponent - b.exponent;
        if (Mathf.Abs(expDiff) > 15)
            return expDiff > 0 ? a : b; // difference too large to matter

        double aligned = expDiff >= 0
            ? a.mantissa + b.mantissa / Math.Pow(10, expDiff)
            : a.mantissa * Math.Pow(10, expDiff) + b.mantissa;

        return new BigNumber(aligned, Math.Max(a.exponent, b.exponent));
    }

    public override string ToString()
    {
        return exponent < 6
            ? Math.Round(mantissa * Math.Pow(10, exponent), 2).ToString()
            : $"{mantissa:F2}e{exponent}";
    }
}

This isn't a full replacement for something like a proper arbitrary-precision library, but for the vast majority of idle games it's more than enough headroom, and it keeps your UI formatting (1.25e47 instead of an unreadable string of digits) clean without extra dependencies.

Testing the Loop Before You Build Content

One more practical tip: before you build out ten bosses and thirty loot items, get the four core systems running with placeholder data — a single boss, three loot entries, one upgrade — and play through several "sessions" manually, closing and reopening the game to simulate offline time. It's much cheaper to catch a broken progression curve or a save-state bug when you have one boss to debug than when you have thirty. Content is easy to add once the systems underneath it are solid; it's expensive to redo once you've built fifty stages on top of a shaky foundation.

Building a Crowd Runner Combat System in Unity: Army Growth, Formations, and Battle Phases

unity source code — Tue, 04 Aug 2026 18:25:50 +0000

Crowd runner games — the genre where you sprint down a lane collecting followers, then throw that crowd into a battle sequence — have quietly become one of the most consistent hits in mobile gaming. Think Last War: Survival, Zombie Run, Count Masters. The appeal is simple to describe and surprisingly tricky to implement well: a runner section that feeds directly into a combat section, where every decision in phase one visibly changes your odds in phase two.

I want to walk through the actual systems that make this genre work, with real C# code you can drop into a Unity project. We'll cover three core pieces:

A performant crowd/army system (using object pooling, not Instantiate spam)
A formation-following movement system for your crowd
A phase-transition state machine that connects the runner section to the combat section

By the end you'll have a working skeleton you can extend into a full game.

Why Crowd Runners Are Deceptively Hard to Build

The naive approach — spawn a GameObject for every unit, parent it to the player, and call it a day — falls apart fast. If your player is meant to command 50, 100, or even 300 units on screen simultaneously (which is normal for this genre), naive instantiation and per-frame Transform updates will tank your frame rate on mobile hardware within seconds.

The three problems you need to solve up front are:

Spawning and despawning hundreds of units without garbage collection spikes
Making a crowd move together in a way that looks organic, not like a single rigid block
Cleanly transitioning game state from "running" to "combat" without hacky flags scattered across your codebase

Let's tackle each one.

1. Object Pooling for Crowd Units

Every Instantiate() and Destroy() call allocates and frees memory. Do that 50 times a frame as your crowd grows and shrinks, and you'll see GC spikes causing visible stutter. The fix is a pool: pre-allocate your unit objects once, and recycle them.

using System.Collections.Generic;
using UnityEngine;

public class CrowdUnitPool : MonoBehaviour
{
    [SerializeField] private GameObject unitPrefab;
    [SerializeField] private int initialPoolSize = 200;

    private readonly Queue<GameObject> pool = new Queue<GameObject>();

    private void Awake()
    {
        for (int i = 0; i < initialPoolSize; i++)
        {
            GameObject unit = Instantiate(unitPrefab, transform);
            unit.SetActive(false);
            pool.Enqueue(unit);
        }
    }

    public GameObject GetUnit(Vector3 position, Quaternion rotation)
    {
        GameObject unit = pool.Count > 0
            ? pool.Dequeue()
            : Instantiate(unitPrefab, transform); // fallback if pool runs dry

        unit.transform.SetPositionAndRotation(position, rotation);
        unit.SetActive(true);
        return unit;
    }

    public void ReturnUnit(GameObject unit)
    {
        unit.SetActive(false);
        unit.transform.SetParent(transform);
        pool.Enqueue(unit);
    }
}

The key design decision here is the fallback Instantiate inside GetUnit. Your army size is variable — a player might recruit far more units than your initialPoolSize accounts for. Rather than hard-capping crowd size (which breaks the power fantasy of the genre), let the pool grow on demand, but always return objects to the pool instead of destroying them once they've been created.

2. Formation-Based Crowd Movement

A crowd that moves as a single rigid block reads as fake immediately. What actually sells the "army" feeling is loose formation logic: each unit has a target offset from the player, with some smoothing so units drift into position rather than snapping.

using System.Collections.Generic;
using UnityEngine;

public class CrowdFormationController : MonoBehaviour
{
    [SerializeField] private Transform player;
    [SerializeField] private float followSpeed = 8f;
    [SerializeField] private float spacing = 0.8f;
    [SerializeField] private int unitsPerRow = 6;

    private readonly List<Transform> units = new List<Transform>();

    public void AddUnit(Transform unit)
    {
        units.Add(unit);
    }

    public void RemoveUnit(Transform unit)
    {
        units.Remove(unit);
    }

    private void Update()
    {
        for (int i = 0; i < units.Count; i++)
        {
            Vector3 targetOffset = GetFormationOffset(i);
            Vector3 targetPosition = player.position + targetOffset;

            units[i].position = Vector3.Lerp(
                units[i].position,
                targetPosition,
                followSpeed * Time.deltaTime
            );
        }
    }

    private Vector3 GetFormationOffset(int index)
    {
        int row = index / unitsPerRow;
        int col = index % unitsPerRow;

        // Center the row so units fan out symmetrically behind the player
        float centeredCol = col - (unitsPerRow - 1) / 2f;

        return new Vector3(
            centeredCol * spacing,
            0f,
            -(row + 1) * spacing // stack rows behind the player
        );
    }
}

A few things worth calling out:

Vector3.Lerp with Time.deltaTime gives you smooth, organic-looking movement instead of units snapping to grid positions. This alone makes a huge visual difference.
Row/column offset math keeps your formation readable even at large crowd sizes, rather than units overlapping or clipping into each other.
Consider adding a small random jitter (Random.insideUnitCircle * 0.1f) to each unit's offset if you want an even more organic, less "grid-like" look.

For performance at very high unit counts (200+), you'd eventually want to move this off individual Transform updates and into Unity's Job System with Burst compilation, or use GPU instancing for rendering. But this CPU-based version comfortably handles a few hundred units on mid-range mobile hardware, which covers most crowd runner use cases.

3. The Run → Combat State Machine

This is the part that actually defines the genre. The running phase and the combat phase need to feel like two different games, but they need to share data cleanly — specifically, the size and strength of the army you built during the run.

A simple, explicit state machine keeps this manageable:

using UnityEngine;

public enum GamePhase
{
    Running,
    Transitioning,
    Combat,
    ResultsScreen
}

public class GamePhaseController : MonoBehaviour
{
    public static GamePhaseController Instance { get; private set; }

    public GamePhase CurrentPhase { get; private set; } = GamePhase.Running;

    [SerializeField] private RunnerController runnerController;
    [SerializeField] private CombatController combatController;
    [SerializeField] private ArmyData armyData;

    private void Awake()
    {
        Instance = this;
    }

    public void EnterCombatPhase()
    {
        if (CurrentPhase != GamePhase.Running) return;

        CurrentPhase = GamePhase.Transitioning;
        runnerController.StopRunning();

        // Hand off the army built during the run to the combat system
        combatController.InitializeBattle(armyData.CurrentUnitCount, armyData.AverageUnitPower);

        CurrentPhase = GamePhase.Combat;
    }

    public void EndCombatPhase(bool playerWon)
    {
        CurrentPhase = GamePhase.ResultsScreen;
        // Trigger UI, rewards, and progression updates here
    }
}

[System.Serializable]
public class ArmyData
{
    public int CurrentUnitCount;
    public float AverageUnitPower;

    public void AddUnit(float unitPower)
    {
        float totalPower = AverageUnitPower * CurrentUnitCount;
        CurrentUnitCount++;
        AverageUnitPower = (totalPower + unitPower) / CurrentUnitCount;
    }

    public void RemoveUnits(int count)
    {
        CurrentUnitCount = Mathf.Max(0, CurrentUnitCount - count);
    }
}

The reason to keep ArmyData as a plain serializable class rather than baking the numbers directly into your runner or combat controllers is reusability — you can persist it, feed it into a save system, or use it to drive a pre-battle "army preview" screen without your combat logic knowing anything about how the army was built.

Notice the explicit Transitioning state between Running and Combat. It's tempting to skip this and just flip straight from one to the other, but having a dedicated transition state gives you a clean hook for things like a camera pan, a "Battle Start" animation, or a short loading pause — all without cluttering your Running or Combat state logic with one-off timing hacks.

Connecting the Systems

Putting it together, your recruitment logic (picking up allies during the run) should call both CrowdFormationController.AddUnit() and ArmyData.AddUnit() at the same time:

public class RecruitGate : MonoBehaviour
{
    [SerializeField] private CrowdUnitPool unitPool;
    [SerializeField] private CrowdFormationController formation;
    [SerializeField] private ArmyData armyData;
    [SerializeField] private float unitBasePower = 10f;

    private void OnTriggerEnter(Collider other)
    {
        if (!other.CompareTag("Player")) return;

        GameObject newUnit = unitPool.GetUnit(other.transform.position, Quaternion.identity);
        formation.AddUnit(newUnit.transform);
        armyData.AddUnit(unitBasePower);
    }
}

This keeps a clean separation of concerns: the pool handles memory, the formation controller handles visual positioning, and ArmyData handles the numbers that actually matter for combat balance. When your combat phase starts, it only needs to read from ArmyData — it doesn't care how the army was visually assembled.

Performance Checklist Before You Ship

A few things worth double-checking once your core loop is working, especially if you're targeting lower-end Android devices:

Profile with the actual target device, not just the Unity Editor. Crowd rendering performance varies wildly between a flagship phone and a budget Android device.
Batch your unit materials. If every unit shares the same material and mesh, Unity can batch draw calls automatically (static or dynamic batching / GPU instancing). Mixing materials per-unit kills this optimization.
Cap active combat units on screen, even if your "army size" number is higher. Many shipped crowd runner games visually cap on-screen combatants at 40–60 and represent the rest abstractly in UI, because rendering hundreds of animated characters simultaneously in the combat phase is a much heavier cost than in the running phase.
LOD (Level of Detail) your unit models if your crowd count regularly exceeds 100 — distant or background units don't need full-resolution meshes.

Wrapping Up

The core technical challenge of a crowd runner combat game isn't any single system — it's making the pooling, formation, and phase-transition logic talk to each other cleanly without your codebase turning into a tangle of flags and special cases. Get those three systems solid, and the rest of the genre — upgrades, cosmetics, monetization hooks, level design — builds on top of a foundation that won't fight you later.

If you'd rather not build this stack from scratch, it's worth knowing that fully implemented versions of this exact system — pooling, formation movement, run/combat state handling, and progression — exist as ready-made Unity templates. I found a solid library of them, including crowd-combat and runner-genre projects specifically, while researching this piece: unitysourcecode.net/products. Even if you don't buy one, reading through a shipped implementation is a good way to sanity-check your own architecture against something that's already handled the edge cases.

If you build your own version of this system, I'd genuinely like to hear what approach you took for large-crowd performance — Job System, GPU instancing, or something else entirely. Drop it in the comments.

Unity Game Reskinning Explained: The Indie Developer's Shortcut to Shipping Faster in 2026

unity source code — Mon, 03 Aug 2026 17:45:17 +0000

If you spend any time in indie game Discord servers or subreddits, you've probably noticed the same question popping up over and over: "How do these solo devs keep shipping games so fast?" More often than not, the answer isn't some secret productivity hack. It's reskinning.

Reskinning has quietly become one of the most common ways solo developers and small studios get playable, monetizable games into app stores without spending a year (or a small fortune) building everything from the ground up. In this post, I want to walk through what reskinning actually is, why it's gained so much traction among indie devs, the real workflow behind it, and the mistakes that tend to sink an otherwise promising reskin.

What Reskinning Actually Means

At its core, reskinning is the practice of taking an existing, working Unity project — one that already has its gameplay loop, physics, UI systems, and core logic in place — and replacing the surface layer: art, audio, branding, and sometimes a few gameplay parameters. The code that makes the game function stays largely untouched. What changes is everything the player sees and hears.

A useful mental model: imagine buying a fully renovated house instead of building one from an empty lot. The plumbing, wiring, and foundation are done. You're choosing paint colors, furniture, and fixtures. You still get a home that feels like yours, but you skip months of structural work.

In practice, a typical reskin touches:

Sprites, 3D models, and animations
UI theme, fonts, and color palette
Character and environment art
Sound effects and music
App icon, splash screen, and store listing assets
Occasionally, difficulty curves or in-game economy tuning

The underlying scripts, gameplay mechanics, and architecture generally stay as-is, which is exactly what makes the whole process so much quicker than a from-scratch build.

Why This Approach Has Taken Off Among Indie Developers

It compresses timelines dramatically

Building a mobile game from zero routinely takes anywhere from a few months to well over a year, depending on scope. Reskinning an already-functional template can shrink that to a matter of days or weeks. For developers who want to test several game ideas quickly rather than betting everything on one long build, that speed difference is huge.

It lowers the cost of entry

You're not paying for a gameplay programmer, a systems architect, or months of QA on core mechanics — that work has already been done and (ideally) tested. Your budget shifts toward art, polish, and user acquisition, which are the levers that actually move downloads and revenue.

It reduces technical risk

Bugs and crashes are one of the biggest threats to a new release. Starting from a template that has already shipped once, or has at least been through some level of QA, means you're not debugging core systems from scratch — you're mostly validating your own additions.

It opens the door for non-programmers

Not everyone chasing a game release is a confident C# developer. Reskinning lets designers, marketers, and generally non-technical founders participate in publishing, since most of the hands-on work is asset replacement and configuration rather than systems programming.

It supports a portfolio strategy

A lot of successful indie publishers don't bet on a single title. They release several small games, watch the data, and double down on whatever gets traction. That kind of iterative, portfolio-based approach is only realistic if each release doesn't require a full development cycle — which is precisely what reskinning enables.

The Actual Workflow

Here's roughly what the process looks like end to end:

Pick a genre and template that fits the audience you're targeting (hyper-casual, puzzle, runner, survival, etc.)
Audit the code for cleanliness, documentation, and Unity version compatibility before you commit
Swap the art assets — this is where most of your creative time goes
Rebrand everything — app icon, splash screen, store metadata, in-game logos
Tune gameplay parameters where it makes sense (difficulty, rewards, progression pacing)
Wire up monetization — ads, IAP, or a hybrid model
Test across devices, not just your dev machine
Publish and iterate based on real player data

The genuinely useful part of this workflow, if you already have a solid engineering foundation, is that steps 3, 4, and 6 are where you spend almost all your time. That's a very different time allocation than a from-scratch build, where steps 1 and most of what would be "step 2" (building the actual systems) dominate the schedule.

Reskinning vs. Building From Scratch

Factor	From Scratch	Reskinning
Time to launch	Months to a year+	Days to a few weeks
Coding skill needed	Advanced	Basic to intermediate
Upfront cost	High	Low to moderate
Bug risk	Higher (untested systems)	Lower (pre-tested base)
Creative control	Full	High at the visual/branding layer
Best fit	Original, mechanically unique games	Rapid launches, portfolio building, learning the publishing pipeline

Neither approach is objectively "better." A fully original game can build a stronger long-term brand and defensible IP. But if your priority right now is getting real market feedback quickly, or you're still learning the mechanics of shipping and publishing, reskinning is a far more forgiving entry point.

Picking a Template Worth Reskinning

This is where a lot of first attempts go sideways. A messy, undocumented, or outdated codebase can end up costing you more time than building from scratch would have. Before committing to a template, it's worth checking:

Code readability — are scripts organized and reasonably commented, or is it a single 2,000-line GameManager.cs?
Unity version compatibility — is it built against a version you can actually maintain going forward?
Asset licensing — do you have clear rights to reuse and republish the assets commercially?
Modularity — can you swap systems (like ads or leaderboards) without rewriting core logic?

Genres with simple, modular structures tend to reskin the most cleanly. Hyper-casual, puzzle, endless runner, and crowd/combat-style games are common choices precisely because their systems are simple enough to adapt without deep architectural changes.

Features That Make a Reskin Feel Less Like a Reskin

The biggest risk with reskinning isn't legal or technical — it's that your game ends up feeling indistinguishable from every other reskin of the same base template. Differentiation matters, and a lot of it comes down to which extra systems you bother to add.

Retention-focused features are usually the highest-leverage additions. Two that consistently pay off:

Leaderboards and achievements. Competitive and completionist mechanics are proven retention drivers, and they're often missing from bare-bones templates. If your base project doesn't already have this wired up, this walkthrough on adding leaderboards and achievements to a Unity game covers the implementation in a genre-agnostic way, which is useful whether you're reskinning a runner, a puzzle game, or something more combat-focused.

Push notifications. Bringing lapsed players back into the app is often cheaper than acquiring new ones, and a well-timed notification system can meaningfully move your day-7 and day-30 retention numbers.

Small additions like these are usually a few hours of work on top of a reskin, but they're often the difference between a forgettable clone and something with actual staying power.

Don't Sleep on Platform-Specific Requirements

One area indie developers consistently underestimate is how different shipping to iOS is from shipping to Android — both in terms of Apple's review process and the technical checklist required before you can even submit a build. Provisioning profiles, App Store Connect setup, IDFA/tracking prompts, and Apple's stricter review guidelines all trip up first-time publishers, reskin or not.

If iOS is part of your release plan, it's worth reading through this iOS shipping checklist before you get anywhere near a submission: Shipping Your Unity Game to iOS: The Technical Checklist Nobody Gives You Upfront. It covers a lot of the small, easy-to-miss steps that otherwise turn into rejected builds or last-minute scrambling.

Monetization Once You've Shipped

Getting to market fast is only half the job — you still need a plan for turning downloads into revenue. Most reskinned games lean on some combination of:

Rewarded video ads for optional bonuses (extra lives, in-game currency, power-ups)
Interstitial ads at natural breakpoints like level completions or game-overs
In-app purchases for cosmetics, currency, or ad removal
Subscriptions, for games with an ongoing content cadence

Hyper-casual titles typically skew heavily toward ad revenue given short session lengths and high volume. More session-based, engagement-heavy games often do better with a hybrid ad-and-IAP model. There's no universal answer here — it depends on genre, audience, and how much friction your players will tolerate.

Common Ways Reskins Go Wrong

A few mistakes show up again and again:

Incomplete asset replacement. Leftover placeholder art, original branding, or unlicensed assets slipping through review is one of the most common (and avoidable) causes of store rejection.

Skipping device testing. A build that runs fine on your dev phone can chug or crash on a mid-range Android device. Test broadly before you launch, not after.

Ignoring App Store Optimization. Even a solid reskin underperforms if your title, keywords, icon, and screenshots aren't optimized for discoverability. Development is only step one.

Picking an oversaturated template with no differentiation. If dozens of other developers are reskinning the exact same base project with minimal changes, yours will get lost in the noise. Invest in art direction or bonus features that set it apart.

Treating launch as the finish line. Games that get regular updates — new levels, bug fixes, seasonal content — tend to hold onto their store rankings and reviews far better than games that ship and get abandoned.

Is Reskinning the Right Call for You?

Reskinning isn't a guarantee of success, and it's not meant to be a permanent substitute for original development. But it's a genuinely useful tool if:

You're new to publishing and want to learn the pipeline without betting a year on one idea
You're a solo dev or small team without deep engineering resources
You want to test multiple concepts and let player data decide what to scale
You're trying to build a portfolio of live, revenue-generating apps rather than one big swing

If your goal is a single, mechanically original game that carves out its own identity long-term, a custom build is probably the better investment. But if speed, lower risk, and real market feedback are what you're optimizing for, reskinning remains one of the most practical paths into mobile game publishing right now.

For a deeper breakdown of the reskinning workflow, including how to choose a base template and where the process tends to go wrong, the original write-up this post is based on is worth a read: What Is Unity Game Reskinning and Why Indie Developers Are Using It to Launch Faster.