← Browse

@rodd-oss/gigabah

B

Godot 4.5 Game Development .cursorrules

rulescursor

Install

agr install @rodd-oss/gigabah --target cursor

Writes 1 file into .cursor/rules/, pinned to git-abb5ca57.

  • .cursorrules

Document

Godot 4.5 Game Development .cursorrules

Core Development Guidelines

  • Use strict typing in GDScript for better error detection and IDE support
  • Implement _ready() and other lifecycle functions with explicit super() calls
  • Use @onready annotations instead of direct node references in _ready()
  • Prefer composition over inheritance where possible
  • Use signals for loose coupling between nodes
  • Follow Godot's node naming conventions (PascalCase for nodes, snake_case for methods)

Code Style

  • Use type hints for all variables and function parameters
  • Document complex functions with docstrings
  • Keep methods focused and under 30 lines when possible
  • Use meaningful variable and function names
  • Group related properties and methods together

Naming Conventions

  • Files: Use snake_case for all filenames (e.g., player_character.gd, main_menu.tscn)
  • Classes: Use PascalCase for custom class names with class_name (e.g., PlayerCharacter)
  • Variables: Use snake_case for all variables including member variables (e.g., health_points)
  • Constants: Use ALL_CAPS_SNAKE_CASE for constants (e.g., MAX_HEALTH)
  • Functions: Use snake_case for all functions including lifecycle functions (e.g., move_player())
  • Enums: Use PascalCase for enum type names and ALL_CAPS_SNAKE_CASE for enum values
  • Nodes: Use PascalCase for node names in the scene tree (e.g., PlayerCharacter, MainCamera)
  • Signals: Use snake_case in past tense to name events (e.g., health_depleted, enemy_defeated)

Scene Organization

  • Keep scene tree depth minimal for better performance
  • Use scene inheritance for reusable components
  • Implement proper scene cleanup on queue_free()
  • Use SubViewport nodes carefully due to performance impact
  • Provide step-by-step instructions to create Godot scene(s) instead of providing scene source code

Signal Best Practices

  • Use clear, contextual signal names that describe their purpose (e.g., player_health_changed)
  • Utilize typed signals to improve safety and IDE assistance (e.g., signal item_collected(item_name: String))
  • Connect signals in code for dynamic nodes, and in the editor for static relationships
  • Avoid overusing signals - reserve them for important events, not frequent updates
  • Pass only necessary data through signal arguments, avoiding entire node references when possible
  • Use an autoload "EventBus" singleton for global signals that need to reach distant nodes
  • Minimize signal bubbling through multiple parent nodes
  • Always disconnect signals when nodes are freed to prevent memory leaks
  • Document signals with comments explaining their purpose and parameters

Resource Management

  • Implement proper resource cleanup in _exit_tree()
  • Use preload() for essential resources, load() for optional ones
  • Consider PackedByteArray storage impact on backwards compatibility
  • Implement resource unloading for unused assets

Performance Best Practices

  • Use node groups judiciously for managing collections, and prefer direct node references for frequent, specific access to individual nodes.
  • Implement object pooling for frequently spawned objects
  • Use physics layers to optimize collision detection
  • Prefer packed arrays (PackedVector2Array, etc.) over regular arrays

Error Handling

  • Implement graceful fallbacks for missing resources
  • Use assert() for development-time error checking
  • Log errors appropriately in production builds
  • Handle network errors gracefully in multiplayer games

TileMap Implementation

  • TileMap node is deprecated - use multiple TileMapLayer nodes instead
  • Convert existing TileMaps using the TileMap bottom panel toolbox option "Extract TileMap layers"
  • Access TileMap layers through TileMapLayer nodes
  • Update navigation code to use TileMapLayer.get_navigation_map()
  • Store layer-specific properties on individual TileMapLayer nodes

Trustgrade B

  • passBody integrity

    Whether the stored document is plausibly the kind of file the artifact declares, rather than something fetched by mistake.

  • passType matchnot applicable to this artifact type

    Whether the artifact is really the kind of thing its metadata claims it is.

  • passFreshness

    How long since the source repository was last pushed to.

  • passPrompt injection

    Scans the artifact's own text for instructions aimed at your agent rather than at you.

  • warnLicensecopyleft/unknown — index-and-link only

    Whether the source repository declares an SPDX license permissive enough to redistribute.

How the grade is calculated

Each check contributes 0 points when it passes, 1 when it warns, and 2 when it fails. The total maps to a letter:

  • Aevery check passed
  • Bone warning
  • Ctwo warnings
  • Dprompt injection or body integrity failed, or three warnings
  • Fone of those failed, and something else is wrong

These are automated hygiene checks, not a security audit, and not a dependency or vulnerability scan. A grade of A means nothing was flagged — not that the artifact is safe.

Versions

  • git-abb5ca5787962026-08-06