agentleFS
Common-kaCommon-ka/ai-agent-unity-rules/.cursor/rules/code-organization.mdc

ai-agent-unity-rules / rules

Cursor rule40 starsChanged 12 months agoMITView on GitHub

The file

Show its rules and text

We split this code-organization.mdc into the rules it gives an agent

16 rules. About 0 are common, 16 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈16

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Follow Microsoft C# conventions:

    line 87
  2. Distinctive:

    Use PascalCase for all public identifiers (classes, methods, properties)

    line 256
  3. Distinctive:

    Use _camelCase for private instance fields

    line 257
  4. Distinctive:

    Use s_camelCase for static fields

    line 258
  5. Distinctive:

    Use camelCase for local variables and parameters

    line 259
  6. Distinctive:

    Use meaningful, descriptive names - prefer clarity over brevity

    line 260
  7. Distinctive:

    Avoid abbreviations except widely known ones (UI, FX, AI)

    line 261
  8. Distinctive:

    No Hungarian notation or type prefixes

    line 262
  9. Distinctive:

    Use Assembly Definitions to reduce compilation time

    line 266
  10. Distinctive:

    Use Addressables for content management with clear grouping strategy

    line 269
  11. Distinctive:

    Use ScriptableObject-based architecture for events and shared data

    line 272
  12. Distinctive:

    Use Assembly Definitions to enforce architectural boundaries

    line 274
  13. Distinctive:

    Create custom packages for reusable systems

    line 276
  14. Distinctive:

    Use separate assemblies for test code

    line 280
  15. Distinctive:

    Create TestUtilities assembly for shared test helpers

    line 281
  16. Distinctive:

    Write tests for critical gameplay systems

    line 282

≈ “Common” is an estimate: at least 1 in 5 of the 6,668 Cursor rule files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
code-organization.mdc
---
alwaysApply: true
---

# Code Organization

## Project Folder Structure

```
Assets/
├── !_Project/                   # Main project content (! keeps it at top)
│   ├── Art/
│   │   ├── Materials/
│   │   ├── Models/
│   │   ├── Textures/
│   │   └── Animations/
│   ├── Audio/
│   │   ├── Music/
│   │   ├── SFX/
│   │   └── Mixers/
│   ├── Prefabs/
│   │   ├── Characters/
│   │   ├── Environment/
│   │   ├── UI/
│   │   └── Effects/
│   ├── Scenes/
│   │   ├── Levels/
│   │   ├── Menus/
│   │   └── Test/
│   ├── Scripts/
│   │   ├── Runtime/           # Runtime code
│   │   │   ├── Core/          # Base systems
│   │   │   ├── Gameplay/      # Game logic
│   │   │   ├── UI/            # UI controllers
│   │   │   ├── Utilities/     # Helper classes
│   │   │   ├── DOTS/          # ECS implementation
│   │   │   │   ├── Components/    # IComponentData
│   │   │   │   ├── Systems/       # SystemBase/ISystem
│   │   │   │   └── Aspects/       # Aspects
│   │   │   └── Hybrid/        # Mixed MonoBehaviour + DOTS
│   │   ├── Editor/            # Editor scripts
│   │   └── Tests/             # Test assembly scripts
│   ├── ScriptableObjects/
│   │   ├── GameConfig/        # Game settings
│   │   ├── EventChannels/     # SO-based events
│   │   ├── Variables/         # Runtime shared data
│   │   ├── Sets/              # SO Sets for collections
│   │   └── Stats/             # Character/weapon data
│   └── Settings/              # Project settings
├── Packages/                  # Custom packages
│   └── com.yourcompany.core/  # Reusable modules
│       ├── Runtime/
│       ├── Editor/
│       ├── Tests/
│       └── Documentation~/
├── AddressableAssets/         # Addressables content
│   ├── Groups/                # Addressable Groups configs
│   ├── Settings/              # Addressable Settings
│   └── Content/               # Organized by strategy
│       ├── PerLevel/          # Concurrent usage strategy
│       ├── Characters/        # Logical entity strategy
│       └── Shared/            # Shared resources
├── Plugins/                   # Third-party plugins
├── Tests/                     # Test assemblies
│   ├── EditMode/
│   │   ├── Unit/              # Unit tests
│   │   └── Integration/       # Integration tests
│   ├── PlayMode/
│   │   ├── Functional/        # Functional tests
│   │   └── Performance/       # Profiling tests
│   └── TestUtilities/         # Common mocks and helpers
└── TextMesh Pro/              # TMP resources
```

## Asset Naming Conventions

### Modern Naming (No Hungarian Prefixes)
Organization through folders, not prefixes. Use PascalCase for all asset names.

### Prefabs
- Characters: `PlayerKnight.prefab` in `Prefabs/Characters/`
- Environment: `TreeOak.prefab` in `Prefabs/Environment/`
- UI: `MainMenu.prefab` in `Prefabs/UI/`
- Effects: `Explosion.prefab` in `Prefabs/Effects/VFX/`

### Scripts
Follow Microsoft C# conventions:

#### Classes and Methods
```
// PascalCase for classes, methods, properties, and public fields
public class GameManager { }
public class AudioManager { }
public class PlayerController { }
public void Initialize() { }
public int MaxHealth { get; set; }
```

#### Fields and Variables
```
// Private instance fields: _camelCase
private int _currentHealth;
private Transform _targetTransform;

// Static fields: s_camelCase
private static int s_instanceCount;
private static GameManager s_instance;

// Public fields: PascalCase (prefer properties)
public int MaxHealth;

// Local variables and parameters: camelCase
public void SetHealth(int newHealth)
{
    int previousHealth = _currentHealth;
    _currentHealth = newHealth;
}

// Constants: PascalCase
private const int MaxPlayers = 4;
public const string GameVersion = "1.0.0";
```

#### Interfaces
```
// Prefix with 'I' + PascalCase
public interface IInteractable { }
public interface IDamageable { }
public interface IPoolable { }
```

### Scenes
- Levels: `Level01_Forest.unity`
- Menus: `MenuMain.unity`, `MenuSettings.unity`
- Test: `TestPlayerMovement.unity`

## Assembly Definition Organization

### Core Assemblies
```
Scripts/Runtime/Core/YourCompany.Core.asmdef
Scripts/Runtime/Gameplay/YourCompany.Gameplay.asmdef
Scripts/Runtime/UI/YourCompany.UI.asmdef
Scripts/Runtime/DOTS/YourCompany.DOTS.asmdef
Scripts/Editor/YourCompany.Editor.asmdef
Scripts/Tests/YourCompany.Tests.asmdef
```

### Example Assembly Definition
```
{
    "name": "YourCompany.Core",
    "rootNamespace": "YourCompany.Core",
    "references": [],
    "includePlatforms": [],
    "excludePlatforms": [],
    "allowUnsafeCode": false,
    "overrideReferences": false,
    "precompiledReferences": [],
    "autoReferenced": true,
    "defineConstraints": [],
    "versionDefines": [],
    "noEngineReferences": false
}
```

## Scene Hierarchy Organization

```
Hierarchy:
--- SYSTEMS ---              # Persistent (DontDestroyOnLoad)
├── GameManager
├── AudioManager
├── InputManager
└── UIManager
--- LEVEL ---                # Level content
├── Environment
│   ├── Terrain
│   ├── Props
│   └── Lighting
├── Gameplay
│   ├── SpawnPoints
│   └── Triggers
└── UI
    ├── Canvas_HUD
    └── Canvas_Menus
--- DYNAMIC ---              # Runtime spawned objects
```

## Prefab Structure

```
Player
├── Model                    # Visual model
├── Colliders               # Physics colliders
├── Effects                 # Particles, effects
└── Audio                   # Audio sources
```

## DOTS/ECS Structure

### Component Example
```
// Components/HealthComponent.cs
using Unity.Entities;

namespace YourCompany.DOTS.Components
{
    public struct HealthComponent : IComponentData
    {
        public float CurrentHealth;
        public float MaxHealth;
    }
}
```

### System Example
```
// Systems/HealthSystem.cs
using Unity.Entities;
using Unity.Burst;

namespace YourCompany.DOTS.Systems
{
    [BurstCompile]
    public partial struct HealthSystem : ISystem
    {
        [BurstCompile]
        public void OnUpdate(ref SystemState state)
        {
            // System logic
        }
    }
}
```

### Aspect Example
```
// Aspects/CharacterAspect.cs
using Unity.Entities;
using Unity.Transforms;

namespace YourCompany.DOTS.Aspects
{
    public readonly partial struct CharacterAspect : IAspect
    {
        readonly RefRW<LocalTransform> _transform;
        readonly RefRW<HealthComponent> _health;
    }
}
```

## Best Practices

### Naming
- Use PascalCase for all public identifiers (classes, methods, properties)
- Use _camelCase for private instance fields
- Use s_camelCase for static fields
- Use camelCase for local variables and parameters
- Use meaningful, descriptive names - prefer clarity over brevity
- Avoid abbreviations except widely known ones (UI, FX, AI)
- No Hungarian notation or type prefixes

### Organization
- Organize assets by type through folder structure, not prefixes
- Use Assembly Definitions to reduce compilation time
- Separate Runtime and Editor code
- Group DOTS code separately from MonoBehaviour code
- Use Addressables for content management with clear grouping strategy

### Architecture
- Use ScriptableObject-based architecture for events and shared data
- Implement EventChannel pattern for decoupled communication
- Use Assembly Definitions to enforce architectural boundaries
- Separate concerns: Core, Gameplay, UI, Utilities
- Create custom packages for reusable systems

### Testing
- Organize tests by type: Unit, Integration, Functional, Performance
- Use separate assemblies for test code
- Create TestUtilities assembly for shared test helpers
- Write tests for critical gameplay systems

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.