├── LICENSE ├── README.md └── .cursorrules /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2025 BlueBirdBack ✨ 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | 2 | # Godot 4.4 Game Development `.cursorrules` for Cursor AI 3 | 4 | This repository contains a `.cursorrules` file designed to enhance your Godot 4.4 game development experience when using [Cursor AI](https://docs.cursor.com/context/rules-for-ai). 5 | 6 | ## What is a `.cursorrules` File? 7 | 8 | A `.cursorrules` file allows you to customize the behavior of Cursor AI to follow specific conventions and best practices for your project. As explained in the [Cursor documentation](https://docs.cursor.com/context/rules-for-ai): 9 | 10 | > Using rules in Cursor you can control the behavior of the underlying model. You can think of it as instructions and/or a system prompt for LLMs. 11 | 12 | While Cursor is moving toward a new system using `.cursor/rules` directory for project-specific rules, the `.cursorrules` file in your project root remains supported for backward compatibility. 13 | 14 | ## How to Use This File 15 | 16 | 1. Download the `.cursorrules` file from this repository 17 | 2. Place it in the root directory of your Godot 4.4 project 18 | 3. Cursor AI will automatically adjust its behavior to follow the Godot-specific guidelines when generating or editing code 19 | 20 | ## What's Included 21 | 22 | This `.cursorrules` file contains comprehensive guidelines for Godot 4.4 development, including: 23 | 24 | - Core development principles (strict typing, proper lifecycle implementation) 25 | - Code style standards 26 | - Naming conventions for files, classes, variables, and nodes 27 | - Scene organization best practices 28 | - Signal implementation guidelines 29 | - Resource management techniques 30 | - Performance optimization strategies 31 | - Error handling approaches 32 | - TileMap implementation for Godot 4.4 33 | 34 | ## Note on Cursor Rules Evolution 35 | 36 | According to the [Cursor documentation](https://docs.cursor.com/context/rules-for-ai): 37 | 38 | > For backward compatibility, you can still use a `.cursorrules` file in the root of your project. We will eventually remove .cursorrules in the future, so we recommend migrating to the new Project Rules system for better flexibility and control. 39 | 40 | Consider migrating to the newer `.cursor/rules` directory system in the future as Cursor evolves. 41 | 42 | --- 43 | 44 | *This repository is not affiliated with Godot Engine or Cursor AI.* 45 | -------------------------------------------------------------------------------- /.cursorrules: -------------------------------------------------------------------------------- 1 | # Godot 4.4 Game Development .cursorrules 2 | 3 | ## Core Development Guidelines 4 | 5 | - Use strict typing in GDScript for better error detection and IDE support 6 | - Implement \_ready() and other lifecycle functions with explicit super() calls 7 | - Use @onready annotations instead of direct node references in \_ready() 8 | - Prefer composition over inheritance where possible 9 | - Use signals for loose coupling between nodes 10 | - Follow Godot's node naming conventions (PascalCase for nodes, snake_case for methods) 11 | 12 | ## Code Style 13 | 14 | - Use type hints for all variables and function parameters 15 | - Document complex functions with docstrings 16 | - Keep methods focused and under 30 lines when possible 17 | - Use meaningful variable and function names 18 | - Group related properties and methods together 19 | 20 | ## Naming Conventions 21 | 22 | - Files: Use snake_case for all filenames (e.g., player_character.gd, main_menu.tscn) 23 | - Classes: Use PascalCase for custom class names with class_name (e.g., PlayerCharacter) 24 | - Variables: Use snake_case for all variables including member variables (e.g., health_points) 25 | - Constants: Use ALL_CAPS_SNAKE_CASE for constants (e.g., MAX_HEALTH) 26 | - Functions: Use snake_case for all functions including lifecycle functions (e.g., move_player()) 27 | - Enums: Use PascalCase for enum type names and ALL_CAPS_SNAKE_CASE for enum values 28 | - Nodes: Use PascalCase for node names in the scene tree (e.g., PlayerCharacter, MainCamera) 29 | - Signals: Use snake_case in past tense to name events (e.g., health_depleted, enemy_defeated) 30 | 31 | ## Scene Organization 32 | 33 | - Keep scene tree depth minimal for better performance 34 | - Use scene inheritance for reusable components 35 | - Implement proper scene cleanup on queue_free() 36 | - Use SubViewport nodes carefully due to performance impact 37 | - Provide step-by-step instructions to create Godot scene(s) instead of providing scene source code 38 | 39 | ## Signal Best Practices 40 | 41 | - Use clear, contextual signal names that describe their purpose (e.g., player_health_changed) 42 | - Utilize typed signals to improve safety and IDE assistance (e.g., signal item_collected(item_name: String)) 43 | - Connect signals in code for dynamic nodes, and in the editor for static relationships 44 | - Avoid overusing signals - reserve them for important events, not frequent updates 45 | - Pass only necessary data through signal arguments, avoiding entire node references when possible 46 | - Use an autoload "EventBus" singleton for global signals that need to reach distant nodes 47 | - Minimize signal bubbling through multiple parent nodes 48 | - Always disconnect signals when nodes are freed to prevent memory leaks 49 | - Document signals with comments explaining their purpose and parameters 50 | 51 | ## Resource Management 52 | 53 | - Implement proper resource cleanup in \_exit_tree() 54 | - Use preload() for essential resources, load() for optional ones 55 | - Consider PackedByteArray storage impact on backwards compatibility 56 | - Implement resource unloading for unused assets 57 | 58 | ## Performance Best Practices 59 | 60 | - Use node groups judiciously for managing collections, and prefer direct node references for frequent, specific access to individual nodes. 61 | - Implement object pooling for frequently spawned objects 62 | - Use physics layers to optimize collision detection 63 | - Prefer packed arrays (PackedVector2Array, etc.) over regular arrays 64 | 65 | ## Error Handling 66 | 67 | - Implement graceful fallbacks for missing resources 68 | - Use assert() for development-time error checking 69 | - Log errors appropriately in production builds 70 | - Handle network errors gracefully in multiplayer games 71 | 72 | ## TileMap Implementation 73 | 74 | - TileMap node is deprecated - use multiple TileMapLayer nodes instead 75 | - Convert existing TileMaps using the TileMap bottom panel toolbox option "Extract TileMap layers" 76 | - Access TileMap layers through TileMapLayer nodes 77 | - Update navigation code to use TileMapLayer.get_navigation_map() 78 | - Store layer-specific properties on individual TileMapLayer nodes 79 | --------------------------------------------------------------------------------