DEV Community: Muhammad Talha Malik (Malik)

The Draw Call Mistake That Halved My Unity Mobile Frame Rate

Muhammad Talha Malik (Malik) — Sun, 16 Aug 2026 03:11:39 +0000

Skipping the "why mobile optimization matters" preamble — you already know Editor performance lies to you. The specific mistake worth flagging: material fragmentation.

200 trees, each with its own material instance (even when the only difference was a trivial color tint), meant 200 separate draw calls. Mobile CPUs handle draw calls far worse than desktop CPUs handle the same load. Switching all 200 to a single shared material with GPU Instancing enabled cut draw calls by more than half — same visuals, same tree count, completely different cost.

The actual profiling workflow, if you're guessing instead of measuring:

Window > Analysis > Profiler, with a Development Build + Autoconnect Profiler enabled on your actual target device — not Play Mode.
Click the frame spike, expand the CPU breakdown.
Physics.Processing dominating → too many active Rigidbodies or Mesh Colliders where a primitive collider would work.
Rendering/Camera.Render dominating → draw calls, overdraw, or shader complexity — check for the material-fragmentation pattern above first.
GC.Collect dominating → allocations inside Update(), usually new calls or LINQ creating garbage every frame.

One non-obvious setting worth checking explicitly rather than trusting platform defaults: Application.targetFrameRate — Unity mobile builds can default to 30 FPS unless you set it yourself at startup.

Full breakdown of build settings, batching, overdraw, and physics tuning for mobile: https://digitaltoolify.blogspot.com/2026/06/unity-mobile-optimization-complete.html

Curious what people are seeing for GPU Instancing gains on more complex meshes than trees — has anyone benchmarked it on skinned/animated instances?

Cut Your 2D Draw Calls With Sprite Atlas

Muhammad Talha Malik (Malik) — Sun, 16 Aug 2026 03:06:23 +0000

Every sprite pulling from a different texture counts as a separate draw call, even small ones like UI icons or repeated enemy sprites. On a 2D project with a decent number of assets, this adds up in ways that don't show up until you actually check the Profiler and wonder why draw calls are high for how simple the scene looks.

Sprite Atlas packs multiple sprites into a single texture at build time:

Window > 2D > Sprite Atlas > Create New Sprite Atlas
// Drag sprite folders into the "Objects for Packing" list
// Enable "Include in Build"

Once sprites share an atlas, Unity batches them into a single draw call instead of one per sprite, assuming they also share material and sorting layer. Visuals stay identical, draw call count drops.

Easy one to underestimate. It doesn't take a massive asset count before this actually matters, especially on mobile where draw calls are a bigger bottleneck than on desktop.

Why Your Unity NavMesh Agent Won't Cross That Gap

Muhammad Talha Malik (Malik) — Thu, 13 Aug 2026 03:53:00 +0000

Baked NavMesh only connects walkable surfaces that physically touch each other. The moment there's a gap, a drop to a lower platform, or a ledge, agents treat the edge as a wall and simply stop, even when the crossing is obviously possible from a design standpoint.

Off-Mesh Links solve this. You place one link point on each side of the gap and connect them:

csharp
// Runtime example: check if an agent is currently on an off-mesh link
if (agent.isOnOffMeshLink)
{
OffMeshLinkData data = agent.currentOffMeshLinkData;
// trigger a jump/climb animation, then call agent.CompleteOffMeshLink()
}

Once connected, the NavMesh treats that gap as traversable, and you control what actually happens when the agent crosses it, a jump animation, a drop, a climb, whatever fits the movement.

Easy to overlook because the NavMesh bake still succeeds without them, it just quietly excludes any area that needs one. If your AI is avoiding a route that should obviously work, this is usually why.

Stop Duplicating Prefabs. Use Prefab Variants Instead

Muhammad Talha Malik (Malik) — Sat, 08 Aug 2026 17:03:26 +0000

If you've ever duplicated a prefab just to tweak a few values, then manually updated every duplicate when the base design changed, Prefab Variants solve this directly.

A Prefab Variant inherits from a base prefab but lets you override specific properties, a stat, a color, a component value, while staying linked to the original. Change the base prefab, and every variant that didn't explicitly override that property picks up the change automatically.

Right-click the base prefab in the Project window and select Create > Prefab Variant.

Where this actually pays off:

Enemy types sharing a base AI/movement setup with different stats
Weapon tiers sharing logic with different damage/range values
UI buttons sharing layout with different colors or icons

Instead of five disconnected prefabs you maintain by hand, you get one source of truth with small, tracked differences layered on top.

Using AI to Write Unity Code Isn't Cheating (Unpopular Opinion)

Muhammad Talha Malik (Malik) — Fri, 07 Aug 2026 12:26:51 +0000

I'll say the thing a lot of devs think but don't post: using AI to write parts of your Unity code isn't cheating. It's a tool, the same category as autocomplete, code snippets, or the asset store before it.

What separates a good developer from a bad one hasn't actually changed. Can you read the code it generates and tell when it's wrong? Can you debug it once it breaks in a way the model didn't anticipate? Can you architect a system well enough that AI-generated pieces slot into it cleanly instead of turning into spaghetti?

If yes, AI-assisted code is a faster first draft. If no, that gap was going to show up eventually anyway, with or without AI in the picture.

Where I draw my own line: boilerplate, utility functions, repetitive setup, sure. Game feel, balance, core architecture decisions, no. Those need a human who understands why the game should feel a certain way, not just what code compiles.

Curious how other devs split this. Where's your line?

Unity's New Input System: The Subscription Bug and Migration Trap Nobody Mentions

Muhammad Talha Malik (Malik) — Fri, 07 Aug 2026 12:07:45 +0000

Most Input System writeups cover the same ground — Action Maps, Bindings, PlayerInput setup. Two things worth knowing that don't show up until you're past the tutorial stage:

The double-subscription bug. With the direct script method, inputActions.Player.Jump.performed += OnJump in OnEnable() needs a matching -= OnJump in OnDisable(). Skip it, and if OnEnable() fires again — scene reload, object re-enable — you're subscribed twice, and one button press runs your jump logic twice. No error, no warning, just a subtly wrong behavior that looks like a physics bug until you check your event subscriptions.

The migration trap. If you're moving an existing project off the old Input Manager, Active Input Handling has a "Both" mode specifically for this — old Input.GetAxis() calls and the new system coexist while you migrate file by file. Switch to "Input System Package (New)" before every old call is gone, and you get a wall of null reference errors all at once, because the old API is now silently dead. Stay in "Both" until migration is actually complete, not "mostly complete."

One structural point worth internalizing early: Action → Binding → Action Map → Input Action Asset is the whole mental model. Your code only ever reads the abstract action ("Move", "Jump") — never which physical key or button caused it. Once that separation actually clicks, gamepad/keyboard/touch support stops being three separate code paths and becomes one.

Full setup with both the PlayerInput ("Send Messages") and direct-reference methods, plus the old-to-new migration table: https://digitaltoolify.blogspot.com/2026/06/unity-input-system-explained-complete.html

Anyone still on the old Input Manager for a shipping project, or has it fully replaced GetAxis/GetKeyDown for you at this point?

Using an AI Assistant Like a Colleague, Not an Oracle — Practical Prompts for Unity Dev

Muhammad Talha Malik (Malik) — Thu, 06 Aug 2026 02:35:23 +0000

The framing that actually matters here isn't "is AI good or bad for coding" — it's what kind of collaborator it is. Treating any current LLM as "always right" or "not worth using" are both wrong in the same way: they skip evaluating what it's actually consistently good at versus where it needs a second look, task by task.

What holds up in practice for Unity work:

Debugging with full context. Pasting the exact error plus the relevant script gets a specific diagnosis (e.g., a missing GetComponent() call or an unassigned Inspector field) instead of generic troubleshooting. Bare error text alone gets you a much weaker answer.
Open-ended review over yes/no questions. "Review this NavMeshAgent patrol script for bugs and mobile perf issues" surfaces things you didn't think to ask about — a GetComponent() sitting in Update() instead of cached, a missing null check. A yes/no prompt just answers the narrow question you asked.
First-draft content, not final content. Design docs, item flavor text, NPC dialogue — genuinely fast for a first pass, needs a real editing pass for voice and lore consistency before it ships.

What doesn't hold up: anything version-sensitive on very recent API changes without explicitly having it search first, and using it as your only reviewer on a team project rather than a first pass before a human looks at architecture and conventions.

Full prompt examples and a fair comparison against Copilot/ChatGPT for different parts of a dev workflow: https://digitaltoolify.blogspot.com/2026/06/claude-ai-for-game-developers-practical.html

Curious what other devs are actually using this for day to day beyond debugging — anyone building it into an actual CI step or internal tool via the API?

Speed Up Unity's Play Mode by Turning Off Domain Reload

Muhammad Talha Malik (Malik) — Thu, 06 Aug 2026 02:25:14 +0000

By default, every time you hit Play, Unity reloads the entire C# domain and the scene. On a small prototype it's barely noticeable. On a larger project, that wait adds up to real time lost across a work session.

Go to Edit > Project Settings > Editor > Enter Play Mode Settings and you can disable Domain Reload and Scene Reload independently. Turning off Domain Reload skips the full recompile-and-reload cycle, so Play mode starts almost instantly.

The trade-off to know before you flip it on: static variables no longer reset between Play sessions the way you're used to. Any static state that used to get wiped clean now persists, which can introduce bugs that only exist because this setting is on, not because your code changed.

Worth enabling on any project where iteration speed matters, just go in aware of what changes.

The Fastest Way to Jump From Unity Into Your Code Editor

Muhammad Talha Malik (Malik) — Thu, 06 Aug 2026 02:19:35 +0000

Right-click any script in the Project window and select "Open C# Project." It opens your IDE directly at that file, skipping the manual process of switching windows, waiting for the whole solution to load, and hunting through folders for the script you wanted.

Double-clicking the script does the same thing, but the right-click option makes it clear this is the actual intended path, not an undocumented shortcut.

If you're going back and forth between Unity and your editor dozens of times a session (which most people are, whether they notice it or not), this small habit removes a lot of dead time.

What's a small workflow habit that ends up saving you more time than expected?

Tags:

GitHub Actions for Unity: The GameCI Setup and the Runner Minutes Trap

Muhammad Talha Malik (Malik) — Sat, 01 Aug 2026 05:51:43 +0000

Skipping the "what is CI/CD" intro — if you're on dev.to you already know. The Unity-specific part worth documenting: Unity needs a license activated before it'll build anything, even headlessly on a CI runner, which is the one piece that doesn't map cleanly from a normal Node/Python Actions setup.

GameCI (game.ci) handles this. The activation flow is annoying but one-time: run a temporary workflow using game-ci/unity-request-activation-file@v2, download the .alf artifact, upload it to license.unity3d.com, get back a .ulf file, store its contents as a UNITY_LICENSE secret along with your email/password. Delete the temp workflow after. Free Personal licenses work fine with this.

The build workflow itself is straightforward once that's done — game-ci/unity-builder@v4 takes care of activation, headless build, and deactivation:

yaml
strategy:
matrix:
targetPlatform: [StandaloneWindows64, Android]
steps:

uses: actions/checkout@v4 with: { fetch-depth: 0, lfs: true }
uses: actions/cache@v4 with: path: Library key: Library-${{ matrix.targetPlatform }}-${{ hashFiles('Assets/', 'Packages/', 'ProjectSettings/**') }}
uses: game-ci/unity-builder@v4 env: UNITY_LICENSE: ${{ secrets.UNITY_LICENSE }} UNITY_EMAIL: ${{ secrets.UNITY_EMAIL }} UNITY_PASSWORD: ${{ secrets.UNITY_PASSWORD }} with: { targetPlatform: ${{ matrix.targetPlatform }} }

The matrix strategy runs both platform builds in parallel, and caching the Library folder cuts significant time after the first run since Unity otherwise regenerates it from scratch.

Worth knowing before you set anything up: runner minutes aren't 1:1. Ubuntu is 1x, Windows 2x, macOS 10x. A build that costs 10 minutes on Ubuntu costs 100 on macOS — if you're doing iOS builds through Actions, your free 2,000 minutes disappear fast. Worth checking whether a self-hosted runner makes sense once build frequency scales up.

Full writeup with the secrets setup and common failure modes (license activation errors, cache key misses, YAML indentation issues): https://digitaltoolify.blogspot.com/2026/07/how-to-use-github-actions-automate-your.html

Anyone running self-hosted runners for Unity builds instead of GitHub-hosted? Curious what the actual cost/time tradeoff looks like in practice.

ElevenLabs for Game Dialogue: The Free Tier Trap and What Actually Breaks

Muhammad Talha Malik (Malik) — Wed, 29 Jul 2026 03:56:12 +0000

The quality is legitimately good now — calm NPC dialogue and narration are close to indistinguishable from a real recording. But there's a licensing gotcha worth knowing before you generate a single line: the free tier has no commercial rights. Anything you make on it requires attribution and can't go into a monetized game. Starter at $5/month is the actual floor for shippable audio, not the free tier most people default to first.

Two workflow notes that aren't obvious from the docs:

Voice Design vs cloning — Voice Design generates a synthetic voice from a text description ("gruff middle-aged man, slight Eastern European accent"), no recordings needed, and it's more stable across generations than a clone. Instant cloning needs 1-3 minutes of clean audio and works fine for short lines, but drifts slightly on long or unusual sentences. For a main character with hundreds of lines, that drift matters — worth testing across your actual dialogue range before committing to a voice for production.

Fantasy names are the recurring pain point. Anything outside standard English phonemes gets mispronounced inconsistently between generations. Spell it phonetically in the input text ("Xrathul" → "Zrathool") rather than fighting the model on the literal spelling.

What it's not good for yet: screaming, extreme emotional delivery, and singing. Those still sound strained or artificial — worth budgeting for a real recording session if your game has more than a couple of those moments.

Full pricing breakdown, the Stability/Similarity Boost settings that actually matter, and a batching workflow for generating dialogue at scale: https://digitaltoolify.blogspot.com/2026/07/how-to-use-elevenlabs-for-game.html

Has anyone compared ElevenLabs against Play.ht or Murf specifically for character work rather than narration? Curious if the gap is as big as it looks on paper.

Unity iOS Build Pipeline: The Apple-Side Gotchas Nobody Warns You About

Muhammad Talha Malik (Malik) — Sat, 25 Jul 2026 09:00:33 +0000

The Unity side of an iOS build is close to a non-issue — install the iOS Build Support module, switch platform, done. Every actual failure point is Apple's signing and provisioning system, not Unity.

The one that burns the most time: bundle identifier mismatches. It has to match exactly, case included, across Unity Player Settings, Xcode, and the Apple Developer portal. Set it before you do anything else — changing it later means updating three places in sync, and any drift between them throws "No profiles for [bundle identifier] were found."

Second gotcha: free Apple ID signing expires in 7 days. Fine for a quick test, useless for anything you're actively iterating on. If you're testing daily, the $99/year Developer Program removes the expiry and is worth it earlier than people expect.

Third: IL2CPP is the only scripting backend on iOS — Mono isn't supported due to Apple's JIT restrictions. Unity won't even let you pick Mono for this target, so this one mostly just explains an already-enforced constraint rather than something you can misconfigure.

For the actual "why won't this build" moments — the xcode-select path issue, the untrusted developer prompt, privacy usage description rejections — full error list with fixes here: https://digitaltoolify.blogspot.com/

Anyone building through Unity Cloud Build/Build Automation instead of a local Mac? Curious how much slower the iteration loop actually is in practice.