10 Essential Tips for Starting a Large Godot Project and Avoiding Costly Mistakes

Fat Earth Studios

Don't Blindly Trust Tutorials [0:33]

• Understand the underlying mechanics:
  • Many tutorials offer advice that works well for small prototypes but can cause significant problems as a project grows.
  • Copying patterns without understanding their implications can lead to deeply embedded issues that are difficult to fix later.
• Treat tutorials as learning tools:
  • Focus on grasping the "why" behind a solution, not just the "how."
  • This critical thinking is essential for building robust, scalable projects.

Sprite2D Offset vs Position [1:15]

• Key distinction for Sprite2D nodes:
  • Position: This property is inherited by the Sprite2D's children, affecting their relative coordinates. It represents "game truth" or real movement.
  • Offset: This property only affects the sprite's texture, not its children. It is primarily used for "animation fiction" or visual alignment without changing the game's physics.
• Practical example of the difference:
  • If a projectile spawn marker is a child of a Sprite2D and you move the Sprite2D using its position, the marker moves with it.
  • If you move the Sprite2D using its offset, the marker stays in its original "game truth" position, which is crucial for consistent projectile spawning.
  • Incorrect usage can lead to misaligned collision shapes or child nodes during animations.

    

• Core principle:
  • Never let visual convenience dictate physics truth; offset is for art, position for real game movement.

Add a Debug God Mode [2:33]

• Importance of debug tools:
  • Implementing a "god mode" for the player character is a powerful debugging tool that saves immense time during development.
• Features of a debug god mode:
  • New player state with faster movement.
  • Disabled gravity.
  • Disabled hurt box (invincibility).
• Benefits beyond debugging:
  • Allows rapid navigation and testing of any part of a level.
  • Can inadvertently spark new gameplay ideas, as developers experiment with enhanced player capabilities (e.g., a sprint mechanic initially for camera stress testing can become a core gameplay feature).

    

The Scaling Mistake That Killed My Project [3:54]

• The costly mistake:
  • Negatively scaling a parent node on the X-axis (multiplying scale.x by -1) to flip entities.
• Why it's problematic:
  • Godot's transformation matrices handle negative X scaling in 2D by applying a negative scale on the Y-axis and a 180-degree rotation when decomposed.
  • This negative scaling propagates to all child nodes, including physics components like Area2Ds, CollisionShape2Ds, RayCast2Ds, and offsets.
  • While visible collision shapes appear correct in the editor, their actual physics interactions occur elsewhere.
• Consequences:
  • Leads to hard-to-debug issues such as missed hits, unreliable raycasts, and flipped collision normals.
  • The physics world operates differently from the visual representation.

    

• Correct approach:
  • For visual flipping, use Sprite2D.flip_h.
  • For physics, explicitly reposition physics nodes or store and swap between local positions/transforms.
  • The golden rule: Never let visual convenience dictate physics truth.

    

Preload Memory Pitfalls [5:32]

• How preload functions:
  • preload acts like a global static reference, incrementing a resource's reference count.
  • If a scene is preloaded by a node that never leaves the scene tree (e.g., a main game manager), that scene and all its referenced assets remain in memory permanently, even if not active.
• Example of incorrect preload usage:
  • MainGame preloads MainMenu, MainMenu preloads OpeningCutscene, OpeningCutscene preloads Level_1. If MainGame persists, all these scenes and their assets stay in memory.

    

• Best practices for preload:
  • Use preload for small, reusable gameplay elements (e.g., projectiles preloaded by the player).
  • Keep preload statements as close as possible to where the resource is actually used.
  • The key is whether anything still references the resource, not just if it's in the scene tree.
  • This ensures intentional ownership of resources and prevents accidental memory leaks.

Enemy Spawning with VisibleOnScreenNotifier2D [7:08]

• Problem with direct enemy placement:
  • Placing enemies directly in the level can lead to them moving or interacting off-screen, consuming resources unnecessarily.
  • Enemies far from the player might activate and move before the player ever reaches them.
• Solution using VisibleOnScreenNotifier2D:
  • This node emits screen_entered and screen_exited signals when its rectangle enters or leaves the screen.
  • Connect these signals to enemy logic to control when enemies are active (e.g., enable processing when visible, disable when off-screen).

    

• Simpler alternative: VisibleOnScreenEnabler2D:
  • Attaching this node as a child automatically disables processing for its parent node when off-screen, without requiring custom code or signals.
  • In Godot 4.5, a show_rect option allows hiding the rectangle in the editor while keeping the logic active.
• Advanced spawning with custom spawners:
  • Create custom spawner nodes that use VisibleOnScreenNotifier2D to control when enemies spawn, where they spawn, and under what conditions they respawn (e.g., spawn once, respawn only if killed and spawner is on-screen, continuous respawn at random intervals).

    

Resolution and Scaling Setup [9:09]

• Importance for pixel art games:
  • Proper resolution and scaling setup is critical early in development to avoid visual glitches, shimmering, and artifacting that can require extensive reworks.
  • Pixel art benefits from clean, whole-number scaling.
• Common base resolutions:
  • For modern pixel art, 640x360 or 320x180 are common choices.
  • These resolutions scale cleanly into standard modern aspect ratios using whole number multiples (e.g., x2 for 720p, x3 for 1080p, x6 for 4K).

    

• Project settings configuration:
  • Project Settings -> Display -> Window:
    • Viewport Width and Viewport Height: Set your game's native resolution (e.g., 640x360).
    • Default Window Size: (Advanced settings) Set a comfortable launch resolution (e.g., 1920x1080).
    • Scale Mode: Set to canvas_items or viewport.
    • Aspect: Set to keep to preserve the aspect ratio.
    • Integer Scaling: Enable for crisp pixel art scaling (disables fractional scaling which can cause artifacts).

      

• Key takeaway:
  • Decide on your base resolution and scaling strategy early and test frequently across different display resolutions.

Static Typing in GDScript [11:12]

• Dynamic vs. Static Typing:
  • GDScript defaults to dynamic typing (variables declared without a type).
  • Static typing involves explicitly declaring the variable's type (e.g., var health: int).
• Benefits of static typing:
  • Improved Editor Support: Provides cleaner autocompletion, allows control-clicking variables/functions to jump to definitions or documentation.
  • Earlier Error Detection: The editor can immediately identify incorrect usage, preventing runtime errors that are painful to debug in large projects.
  • Potential Performance Boost: The engine doesn't need to deduce variable types at runtime, offering a small performance gain.

    

• Enforcing static typing:
  • In Project Settings -> General -> Debug -> GDScript, set Untyped Declaration to warn to be notified of untyped variables.
  • This allows incremental adoption in existing projects.

    

Version Control with Git [12:42]

• Essential for game development:
  • Version control, particularly Git (often hosted on GitHub), is critical for managing project changes.
• How Git works:
  • Allows creation of "commits" (checkpoints) throughout the project's history.
  • Enables reverting to any previous working version.
• Problem without version control:
  • Spending hours developing a feature, then breaking it during refactoring, leading to re-solving already fixed problems.
• Solution with Git:
  • Commit working features immediately.
  • Always revert to the last known good state if issues arise.
  • Easily compare current code to previous working versions to isolate specific changes causing problems.

    

• Impact on development:
  • Significantly reduces stress during development.
  • Provides confidence to experiment, refactor, and improve code without fear of irreversible damage.

    

Quick Godot Tips [14:02]

• Global Time Scale: Use Engine.time_scale to slow down or speed up the entire game for debugging or special effects.
• Hardware Mouse Cursor: Explicitly control its visibility in your game.
• Alt + Right-Click in Editor: Select specific objects in the editor, especially useful when objects overlap. Ensure you are in select mode.
• MSDF Fonts: Enable Multi-channel Signed Distance Field (MSDF) in Project Settings -> GUI -> Theme -> Font, or on individual font resources, to ensure crisp, non-blurry fonts.

  

• Favorite Scenes and Folder Coloring: Right-click scenes in the file system to mark them as favorites for quick access. Color code folders and files to improve navigation in large projects.
• Limit Editor FPS: If the debug editor causes hardware noise, limit the FPS in Project Settings -> Physics -> Common -> Max FPS, as the engine might be rendering at extremely high frame rates. This should also be done for shipping games.

  

• Customize Editor Layout: Rearrange editor panels (File System, Scene, Inspector) to suit your workflow for optimal productivity.