Classes & Inheritance

Learn extends, class_name, custom Node and Resource subclasses, and building an inheritance hierarchy in GDScript.

Introduction

You've been using classes since lesson 1 without necessarily calling them that — every GDScript file that starts with extends is defining a class. This lesson makes that explicit and shows how to build your own reusable class hierarchies.

What You Will Learn

Why every GDScript file is already a class definition.
How class_name lets you give a script its own reusable type name.
How to inherit from your own custom classes, not just built-in node types.
How to override a parent class's function.

Every Script Is Already a Class

extends CharacterBody2D, seen since lesson 1, means "this script defines a new class that inherits from Godot's built-in CharacterBody2D class." Every script you've written in this course has been a class definition — you just hadn't named it yet.

class_name: Naming Your Class

Use case: adding class_name Enemy to a script registers Enemy as a global type name, usable anywhere in the project — for variable type annotations, the Add Node dialog, and even a custom icon in the editor.

# enemy.gd
class_name Enemy
extends CharacterBody2D

var health: int = 50

func take_damage(amount: int) -> void:
    health -= amount

# elsewhere in the project
var goblin: Enemy = Enemy.new()
print(goblin.health)  # 50

Output

Click Run to see what this code prints.

Inheriting from Your Own Classes

Once a class has a class_name, other scripts can extend it directly, just like they'd extend a built-in Godot type — building your own inheritance hierarchies on top of the engine's.

# goblin.gd
class_name Goblin
extends Enemy

func _ready() -> void:
    health = 30  # Goblins are weaker than the base Enemy default

Overriding Functions

A subclass can redefine a function its parent already has, and use super() to still call the parent's version if needed — the same override pattern found in most object-oriented languages.

class_name Goblin
extends Enemy

func take_damage(amount: int) -> void:
    print("The goblin flinches!")
    super.take_damage(amount)  # still run Enemy's original logic

Output (when a Goblin takes damage)

Click Run to see what this code prints.

Custom Resources

Not every custom class needs to be a Node — extending Resource instead creates a data-only class, perfect for defining reusable data assets (like an item or a weapon's stats) that can be saved as .tres files and edited directly in the Inspector.

class_name WeaponData
extends Resource

@export var name: String
@export var damage: int
@export var attack_speed: float

A WeaponData resource can now be created, filled in, and saved entirely inside the Godot editor — no code required to define individual weapons, just to define the shape of what a weapon is.

Common Mistakes

Avoid These Mistakes

Forgetting class_name on a script you intend to reuse as a type elsewhere — without it, you can still extend the script by file path, but lose the cleaner named-type syntax.
Overriding a function and forgetting super.function_name() when you still need the parent class's original behavior too.
Making every custom type a Node subclass, even pure data — Resource is usually the better fit for data-only classes.

Best Practices

Add class_name to any script you plan to instantiate or reference by type from other scripts.
Use Resource subclasses for reusable data definitions (item stats, weapon data) rather than Node subclasses.
Keep inheritance hierarchies shallow — one or two levels deep is usually enough for most gameplay classes.

Frequently Asked Questions

Do I need class_name for every script?

No — many scripts, especially one-off scene-specific ones, work fine without it. Add it specifically when you want a script usable as a named type elsewhere.

Can a class inherit from more than one class at once?

No — GDScript, like most single-inheritance languages, only allows one direct parent class per script.

What's the difference between a Node subclass and a Resource subclass?

A Node subclass is meant to live in the scene tree and participate in lifecycle callbacks; a Resource subclass is meant to represent reusable, saveable data with no scene-tree presence of its own.

Key Takeaways

Every GDScript file is a class definition; extends declares its parent type.
class_name registers a globally usable type name for a script.
A class with class_name can be extended by other scripts, just like a built-in Godot type.
Resource subclasses define reusable, editor-editable data; Node subclasses define scene-tree behavior.

Summary

You can now build your own reusable class hierarchies on top of Godot's built-in node and resource types. Next, you'll cover GDScript's built-in vector, array, and dictionary types in depth.

Next Lesson →