Godot Resources Explained: Data Assets for Items, Stats, Abilities, and Tuning

Resources are one of the Godot features that sound abstract until you use them once. Then they become the clean answer to a common problem: where should item stats, enemy tuning, ability data, and reusable configuration live if you do not want hardcoded values scattered through scripts?

The Short Version

A Resource is a saved data object. Godot already uses Resources everywhere: textures, materials, fonts, animations, themes, meshes, and audio streams. You can also create your own custom Resources for gameplay data.

• Unity habit: custom Resources often feel like ScriptableObjects.
• Unreal habit: custom Resources can feel like Data Assets for smaller, editor-friendly data.
• Godot habit: scenes own behavior, Resources hold reusable data, and scripts connect the two.

Why Resources Matter in Production

Hardcoded values are fine for a five-minute test. They become painful when you are tuning ten enemies, twenty items, or several abilities. Resources move data out of scripts so you can reuse, duplicate, and tune it from the Inspector.

A Custom Item Resource

Create a script that extends Resource, give it a class_name, and export the fields you want to edit in the Inspector. Save it as something like ItemData.gd.

extends Resource
class_name ItemData

@export var display_name: String = "New Item"
@export var icon: Texture2D
@export var value: int = 1
@export var max_stack: int = 1
@export_multiline var description: String = ""

Now you can create .tres files from that type, such as health_potion.tres, silver_key.tres, or coin.tres. Each file has the same structure but different values.

Using Resource Data in a Scene

A pickup scene can export an ItemData reference. That scene handles collision and presentation. The Resource provides the name, icon, stack size, and value.

extends Area2D

@export var item_data: ItemData
@onready var sprite: Sprite2D = $Sprite2D

signal picked_up(item: ItemData)

func _ready() -> void:
    if item_data and item_data.icon:
        sprite.texture = item_data.icon

func _on_body_entered(body: Node) -> void:
    if body.is_in_group("player") and item_data:
        picked_up.emit(item_data)
        queue_free()

The useful part is that your pickup scene does not care whether it represents a coin, potion, key, or crafting item. Designers can duplicate Resource files and tune values without touching the collision script.

Good Resource Use Cases

• Items: names, icons, stack sizes, sell values, rarity, tags.
• Enemy stats: max health, speed, damage, detection range, loot table references.
• Abilities: cooldown, mana cost, projectile scene, damage curve, UI icon.
• Weapons: fire rate, spread, recoil, ammo type, sound references.
• Difficulty tuning: spawn weights, score multipliers, wave timing.

When Not to Use Resources

Resources are not a magic replacement for every data structure. Do not make a custom Resource for one value that never repeats. Do not use Resources as a hidden global state container. Do not store constantly changing save-game state in a shared Resource unless you know exactly how references and saving work.

• Use normal variables for temporary runtime state like current health.
• Use JSON or a save file format for player save data.
• Use scenes for reusable behavior and node composition.
• Use Resources for reusable definitions and tuning values.

Resource Files vs Built-In Resources

Godot can store a Resource as an external file or embed it inside a scene. External files are better when multiple scenes should share the same data. Built-in resources are fine when the data belongs only to one scene.

For example, a shared fireball_ability.tres should be an external file if the player, enemy mage, and tutorial UI all reference it. A one-off material override inside a single prop can stay built in.

A Practical Folder Setup

res://
  scripts/resources/ItemData.gd
  scripts/resources/EnemyStats.gd
  scripts/resources/AbilityData.gd
  resources/items/health_potion.tres
  resources/items/silver_key.tres
  resources/stats/slime_stats.tres
  resources/abilities/fireball.tres

That split keeps the Resource class scripts separate from the actual Resource instances. If you want the bigger folder picture, pair this with the Godot project structure guide, then practice in the Learning Hub.

The Habit to Build

When you catch yourself writing the same exported variables on several scenes, stop and ask if you are describing data. If yes, move that data into a Resource and let the scene focus on behavior. That small habit makes Godot projects easier to tune, easier to reuse, and easier to teach to your future self.