I've opened a lot of Unity projects that weren't mine. Some from marketplaces, some inherited from teammates who left, some forked from old personal projects I barely remembered writing. After enough of these, you start recognizing the same handful of warning signs almost immediately, usually within the first ten minutes of scrolling through the script folder.
Here are the five I check for now, before I commit to building anything on top of someone else's code.
1. The God Object
You'll know it when you see it. One script, usually named something like GameManager or Controller, that's 800+ lines long and handles scoring, UI updates, audio, save data, and ad calls all in one place.
csharppublic class GameManager : MonoBehaviour
{
public int score, lives, level;
public Text scoreText, livesText;
public AudioSource bgMusic, sfx;
void Update()
{
// input handling
// UI updates
// ad timer checks
// win/lose conditions
// ...200 more lines
}
}
This isn't just ugly, it's a maintenance tax you'll keep paying. Every feature you add has to navigate around everything already crammed in here, and every change risks breaking something unrelated three sections down.
2. Singletons Everywhere, Dependency Injection Nowhere
GameManager.Instance.something showing up in forty different scripts is a sign that the codebase has no real boundaries. It's convenient to write and miserable to refactor, because everything is implicitly coupled to everything else, and you won't find out how coupled until you try to change one piece.
It's not that singletons are inherently bad. It's that when they're the only pattern used for accessing anything, you've got a fully tangled dependency graph with no clear ownership of state.
3. Ad SDK Calls Mixed Into Gameplay Code
This one's specific to mobile/Unity projects but it matters a lot. If you grep the project for AdMob or ShowInterstitial and find it scattered inside gameplay scripts instead of isolated in its own manager class, you're looking at a future headache. Ad SDKs get deprecated and updated on a forced schedule. When ad logic is tangled into gameplay, every SDK update becomes a project-wide hunt instead of a one-file change.
4. No Object Pooling on Anything That Spawns Repeatedly
Search for Instantiate( and Destroy( and see what's calling them during active gameplay, bullets, particles, enemies, popups. If there's no pooling and these are firing every few frames, that's a garbage collection spike waiting to happen on a real device, even if it runs fine in the Editor.
csharp// red flag pattern - spawning bullets every frame, no pool
void Fire()
{
Instantiate(bulletPrefab, firePoint.position, Quaternion.identity);
}
This runs fine for the first thirty seconds of testing. It does not run fine after five minutes of actual gameplay on a mid-range Android phone.
5. Magic Numbers With No Explanation
csharpif (score > 247) { TriggerBonus(); }
transform.position += Vector3.up * 0.0734f;
Numbers like this scattered through the code with zero context mean whoever wrote it either didn't plan for anyone (including future-them) to need to tune these values, or they were hardcoding values during a debug session and never cleaned it up. Either way, every tweak you want to make turns into archaeology.
Why This List Matters More Than How the Game Plays
A demo video or live build tells you almost nothing about what's underneath. The gameplay loop is the easiest thing to evaluate, you just play it. The architecture is what determines whether your next two weeks of customization are smooth or a slog of cascading bugs.
If you want a deeper technical breakdown of how to evaluate this stuff systematically, I wrote a longer piece on reading and evaluating pre-built Unity codebases that goes further into dependency graphs and coupling tests.
The Real Takeaway
None of these five things are dealbreakers on their own. Plenty of shipped, profitable games have at least one god object hiding somewhere. But finding two or three of these in the same codebase is a strong signal: budget extra time before you commit to a launch date, because you're not just adding features, you're going to be fighting the architecture while you do it.
What red flags have you run into in code you didn't write? Curious if others have patterns they check for that I'm missing.
Top comments (0)