Unity Best Practices: Lessons from 8 Years

After 8 years of building games, VR experiences, and interactive applications with Unity, I've learned that the difference between a maintainable project and a nightmare often comes down to a few key practices. Here's what I wish someone had told me when I started.

Project Structure Matters

A clean project structure isn't just about aesthetics—it's about being able to find things six months from now when you need to fix a bug. Here's the structure we use at One Fox Studio:

Assets/
├── _Project/
│   ├── Scripts/
│   ├── Prefabs/
│   ├── Materials/
│   ├── Scenes/
│   └── UI/
├── Art/
├── Audio/
├── Plugins/
└── Resources/

The _Project folder with the underscore keeps your custom assets at the top. Everything from the Asset Store or external sources stays outside this folder, making upgrades painless.

The ScriptableObject Revolution

If you're still hardcoding values or using public fields for configuration, stop. ScriptableObjects changed how I approach game data entirely.

Why ScriptableObjects?

• Data lives outside scenes—no more merge conflicts
• Designers can tweak values without touching code
• Easy to create variations (different enemy types, weapon stats, etc.)
• Works great with version control

[CreateAssetMenu(fileName = "WeaponData", menuName = "Game/Weapon")]
public class WeaponData : ScriptableObject
{
    public string weaponName;
    public float damage;
    public float fireRate;
    public GameObject projectilePrefab;
}

Object Pooling is Non-Negotiable

Instantiate and Destroy are the enemy of smooth performance. For anything that spawns frequently—bullets, particles, enemies—use object pooling.

"The fastest code is code that doesn't run. The fastest allocation is one that never happens."

Unity's built-in object pooling (introduced in Unity 2021) is solid, but even a simple custom pool can eliminate those nasty GC spikes that cause frame drops.

Events Over Update()

Every Update() call has a cost. When you have hundreds of objects all checking conditions every frame, that cost adds up. Instead:

• Use C# events or UnityEvents for communication
• Consider a simple event bus for decoupled systems
• Only check what needs checking, when it needs checking

A Simple Event Bus

public static class GameEvents
{
    public static event Action<int> OnScoreChanged;
    public static event Action OnPlayerDied;

    public static void ScoreChanged(int newScore)
        => OnScoreChanged?.Invoke(newScore);
}

Assembly Definitions

For any project beyond a simple prototype, use Assembly Definitions. They reduce compile times dramatically by only recompiling what changed.

Our typical setup:

• Game.Core - Core systems, no dependencies
• Game.Gameplay - Game logic, depends on Core
• Game.UI - UI code, depends on Core
• Game.Editor - Editor tools, editor only

Version Control Tips

Unity and Git can work beautifully together if you set them up right:

• Use .gitattributes with Unity's YAML merge tool
• Force text serialization in Project Settings
• Use Git LFS for large assets (textures, audio, models)
• Never commit the Library folder

Final Thoughts

These practices have saved us countless hours of debugging and refactoring. They're not about being clever—they're about being kind to your future self and your teammates.

The best code is code that's boring. Predictable. Easy to understand. Save the creativity for game design, not architecture.

Got questions about Unity development? Get in touch—we're always happy to chat about game dev.