Godot Engine è passato da progetto di nicchia a alternativa seria a Unity e Unreal in meno di tre anni. La spinta decisiva è arrivata quando Mega Crit, lo studio dietro Slay the Spire, ha spostato lo sviluppo di Slay the Spire 2 da Unity a Godot dopo la controversia sulle tariffe runtime di Unity del 2023. Da allora la community italiana di sviluppatori indie ha adottato il motore in massa, complice una licenza MIT che non chiede royalty né abbonamenti. In questo tutorial installiamo Godot Engine 4.7.1, la versione stabile corrente ad agosto 2026, e costruiamo un piccolo platform 2D funzionante dall’editor fino all’esportazione su Windows, Linux, macOS e Web.
Non serve esperienza pregressa con altri motori. Servono però pazienza e una macchina che rispetti i requisiti minimi, perché Godot 4 usa Vulkan per il rendering Forward+ e questo esclude alcune GPU integrate datate. Copriamo 14 passi pratici, oltre 5 blocchi di codice GDScript pronti da incollare, gli errori più comuni di chi arriva da Unity o Unreal e una sezione dedicata alla risoluzione dei problemi con 8 casi reali.
Il codice sorgente di Godot vive su GitHub sotto organizzazione godotengine, dove la cadenza di rilascio è rimasta costante per tutto il 2026: dalla versione 4.7 di giugno alla patch 4.7.1 di metà luglio, con snapshot di sviluppo per la futura 4.8 già pubblici ad agosto. Questa velocità di iterazione, unita all’assenza totale di costi di licenza, spiega perché sempre più sviluppatori indie italiani ed europei stanno spostando i nuovi progetti su Godot invece di aprire l’ennesimo abbonamento a un motore proprietario.
Prerequisiti: cosa ti serve prima di iniziare
Godot Engine 4.7.1 gira su tre piattaforme desktop con requisiti minimi contenuti rispetto a Unreal Engine 5, ma le tre modalità di rendering (Forward+, Mobile, Compatibility) chiedono hardware diverso. Se il tuo portatile ha una GPU integrata di qualche anno fa, parti dal renderer Compatibility invece di Forward+: risparmi crash e schermate nere al primo avvio.
A differenza di Unreal Engine, dove i requisiti hardware crescono in fretta appena attivi Lumen o Nanite, Godot resta utilizzabile anche su portatili da ufficio di fascia bassa finché scegli il renderer giusto per lo scenario. Questo lo rende una scelta pratica anche per chi insegna programmazione di videogiochi in aule scolastiche o universitarie italiane con parco macchine eterogeneo, uno dei motivi per cui diversi corsi di game design lo hanno adottato come primo motore didattico negli ultimi due anni accademici.
| Requisito | Minimo | Consigliato |
|---|---|---|
| Sistema operativo | Windows 10 64-bit, Ubuntu 20.04, macOS 10.15 | Windows 11, Ubuntu 24.04, macOS 14+ |
| CPU | Dual-core 64-bit | Quad-core o superiore |
| RAM | 4 GB | 16 GB |
| GPU per Forward+ | Supporto Vulkan 1.0 | GPU dedicata con driver Vulkan aggiornati |
| GPU per Compatibility | OpenGL 3.3 / GLES3 | Qualsiasi GPU integrata recente |
| Spazio su disco | 500 MB per l’editor | 5 GB con export template e progetti |
| Versione Godot | 4.7.1 stabile (14 luglio 2026) | 4.7.1 con build C# se serve .NET |
Non serve installare un IDE esterno: l’editor di Godot include già uno script editor completo con syntax highlighting per GDScript. Se preferisci scrivere in C# scarica la build “.NET” separata dal sito ufficiale, perché quella standard non include il runtime Mono. In questo tutorial usiamo GDScript, il linguaggio nativo del motore, perché resta il più documentato e il più veloce da imparare per chi parte da zero.
Passo 1: scarica e installa Godot Engine 4.7.1
Vai su godotengine.org/download e scegli la build corretta per il tuo sistema operativo. Godot non ha un vero e proprio installer: scarichi un eseguibile portatile (o un file .app su macOS) e lo lanci direttamente, senza permessi di amministratore. Questo è uno dei motivi per cui l’editor pesa così poco rispetto a Unity Hub o Epic Games Launcher.
- Windows: scarica lo zip “Standard” (x86_64), estrailo in una cartella tipo
C:\Godot\ed eseguiGodot_v4.7.1-stable_win64.exe. - Linux: scarica il binario, rendilo eseguibile con
chmod +x Godot_v4.7.1-stable_linux.x86_64e lancialo dal terminale o da un launcher .desktop. - macOS: scarica il file .zip, estrai
Godot.appe trascinalo nella cartella Applicazioni. Alla prima apertura Gatekeeper potrebbe chiederti conferma nelle Preferenze di Sicurezza.
Se ti serve C# scarica invece la build “.NET” dalla stessa pagina: aggiunge circa 150 MB e richiede il .NET SDK installato a parte. Per verificare che l’installazione sia integra, apri un terminale nella cartella e lancia il binario con il flag --version: la risposta attesa è 4.7.1.stable.official.
$ ./Godot_v4.7.1-stable_linux.x86_64 --version
4.7.1.stable.official.[commit_hash]
Passo 2: avvia l’editor e configura il Project Manager
Al primo avvio vedi il Project Manager, la schermata da cui gestisci tutti i tuoi progetti Godot. È qui, non dentro l’editor, che scegli lingua dell’interfaccia, tema (chiaro o scuro) e cartella di lavoro predefinita. Vai su Editor Settings in alto a destra e imposta la lingua su Italiano se preferisci lavorare in italiano, anche se buona parte della documentazione ufficiale resta più aggiornata in inglese.
Controlla anche la sezione Network nelle impostazioni: Godot scarica gli export template al bisogno, e se sei dietro un proxy aziendale conviene configurarlo subito per evitare timeout più avanti durante l’esportazione. Il Project Manager mostra inoltre tutte le versioni di Godot installate in parallelo sulla stessa macchina: puoi tenere 3.6, 4.5 e 4.7.1 fianco a fianco senza conflitti, utile se mantieni progetti legacy.
Passo 3: crea il tuo primo progetto 2D
Clicca su Create New Project, dai un nome (per esempio “PrimoGioco”), scegli una cartella vuota e seleziona il renderer. Per un platform 2D come quello che costruiamo in questo tutorial, Forward+ va benissimo su hardware recente; se il tuo laptop ha solo una GPU integrata di qualche generazione fa, scegli Compatibility per evitare cali di frame rate inutili in fase di apprendimento.
Conferma con Create & Edit. Godot genera automaticamente un file project.godot nella cartella: è il cuore del progetto, contiene tutte le impostazioni (input map, autoload, rendering) in formato testo leggibile, il che lo rende perfetto per il versionamento con Git senza conflitti binari.
Passo 4: orientati nell’interfaccia dell’editor
L’editor si divide in quattro zone principali: il pannello Scene a sinistra con l’albero dei nodi, il Viewport centrale dove vedi e modifichi la scena, l’Inspector a destra con le proprietà del nodo selezionato, e in basso il FileSystem con tutti gli asset del progetto. In alto trovi i pulsanti per passare tra le viste 2D, 3D, Script e AssetLib.
Chi arriva da Unity riconoscerà subito il pattern: l’Inspector di Godot fa lo stesso lavoro del Component Inspector di Unity, ma qui le “componenti” si chiamano nodi e si organizzano in un albero gerarchico invece che come lista piatta su un GameObject. Questa differenza concettuale è la prima cosa da assimilare, perché tutto in Godot, compresi gli script, si aggancia a un nodo specifico dell’albero.
Vale la pena imparare qualche scorciatoia da subito: Ctrl+S salva la scena corrente, F5 avvia il progetto intero, F6 avvia solo la scena aperta e Ctrl+Shift+O apre la ricerca rapida per file, utilissima quando il progetto cresce oltre poche decine di script. Il pannello in basso ospita anche la tab Output, dove finiscono tutti i print() che scrivi nel codice, e la tab Debugger che riprendiamo più avanti in questo tutorial.
Passo 5: costruisci la scena con Nodi e Scene
In Godot ogni elemento di gioco, dal personaggio al pulsante del menu, è una Scena composta da Nodi. Per il nostro platform 2D crea una nuova scena (Scene > New Scene) e aggiungi come radice un nodo CharacterBody2D: è il nodo pensato apposta per personaggi controllati dal giocatore con collisioni fisiche gestite manualmente via script, a differenza di RigidBody2D che è pilotato dal motore fisico.
Aggiungi come figli del CharacterBody2D un nodo Sprite2D (per la grafica) e un CollisionShape2D (per la forma di collisione, tipicamente un rettangolo o una capsula). Salva la scena come player.tscn. Questa struttura a tre nodi è lo scheletro base di qualsiasi personaggio 2D in Godot 4, ed è identica sia che tu stia facendo un platform che un top-down.
Rinomina ogni nodo con un nome chiaro invece di lasciare i nomi generici assegnati automaticamente dall’editor (Sprite2D2, CollisionShape2D3): rende più leggibile l’albero delle scene quando il progetto cresce, e soprattutto rende più semplici i riferimenti $NomeNodo nello script, perché puoi leggerli a colpo d’occhio invece di andare a controllare la gerarchia ogni volta.
Passo 6: scrivi il tuo primo script in GDScript
Seleziona il nodo CharacterBody2D e clicca sull’icona dello script nell’angolo in alto del pannello Scene. Godot crea automaticamente un file player.gd e lo aggancia al nodo. GDScript ha una sintassi molto vicina a Python, con indentazione significativa e tipizzazione opzionale che aiuta l’autocomplete dell’editor.
extends CharacterBody2D
const SPEED = 300.0
const JUMP_VELOCITY = -400.0
func _physics_process(delta: float) -> void:
if not is_on_floor():
velocity += get_gravity() * delta
if Input.is_action_just_pressed("ui_accept") and is_on_floor():
velocity.y = JUMP_VELOCITY
var direction := Input.get_axis("ui_left", "ui_right")
if direction:
velocity.x = direction * SPEED
else:
velocity.x = move_toward(velocity.x, 0, SPEED)
move_and_slide()
Il metodo _physics_process gira a intervalli fissi, di norma 60 volte al secondo, ed è il posto giusto per la logica di movimento e fisica, mentre _process gira a ogni frame renderizzato ed è più adatto a UI e animazioni. La funzione move_and_slide() applica automaticamente la velocity calcolata rispettando le collisioni: non devi gestire manualmente lo scontro con il terreno.
Passo 7: aggiungi il movimento del personaggio con l’input
Lo script sopra usa le azioni predefinite ui_left, ui_right e ui_accept, già mappate su frecce direzionali, WASD e Spazio/Invio. Per un gioco reale conviene creare azioni personalizzate: vai su Project > Project Settings > Input Map, digita un nome tipo move_right e assegna il tasto D oltre alla freccia destra.
Salva la scena e premi F6 (o il pulsante Play Scene) per testare subito il personaggio senza dover caricare l’intero progetto. Se il personaggio non si muove, la causa più comune è aver dimenticato di assegnare uno Shape al CollisionShape2D: senza una forma definita nell’Inspector il nodo esiste ma non collide con nulla, e la console stampa solo un warning giallo, non un errore bloccante, quindi è facile non accorgersene subito.
Passo 8: gestisci collisioni con Area2D e CharacterBody2D
Per raccogliere oggetti come monete o power-up senza fisica solida usiamo Area2D invece di CharacterBody2D: rileva sovrapposizioni ma non blocca il movimento. Crea una nuova scena con radice Area2D, aggiungi Sprite2D e CollisionShape2D come prima, e salvala come coin.tscn.
extends Area2D
signal collected
func _on_body_entered(body: Node2D) -> void:
if body.name == "Player":
collected.emit()
queue_free()
Collega il segnale body_entered del nodo Area2D a questo script dal pannello Node > Signals, oppure trascinando la connessione dall’editor visuale. Quando il player entra nell’area, la moneta emette il segnale collected e si autodistrugge con queue_free(), il modo corretto per rimuovere nodi in Godot senza causare crash da riferimenti pendenti.
Per progetti con più tipi di collisione (nemici, proiettili, terreno, collezionabili) conviene configurare i Physics Layers in Project Settings invece di controllare i nomi dei nodi via codice come nell’esempio sopra. Assegna ogni tipo di oggetto a un layer dedicato e usa la matrice di collisione per decidere quali layer interagiscono tra loro: è più veloce a runtime e molto più facile da mantenere quando il numero di tipi di oggetto cresce oltre una manciata.
Passo 9: usa i Signal per far comunicare i nodi
I Signal sono il sistema di eventi nativo di Godot ed evitano riferimenti diretti tra nodi scollegati, un problema classico che in Unity si risolve con eventi C# o UnityEvent. Nella scena principale, ascolta il segnale collected emesso da ogni moneta per aggiornare un contatore punti:
extends Node2D
var score := 0
func _ready() -> void:
for coin in get_tree().get_nodes_in_group("coins"):
coin.collected.connect(_on_coin_collected)
func _on_coin_collected() -> void:
score += 1
$UI/ScoreLabel.text = "Punti: %d" % score
Nota il gruppo "coins": assegnalo a ogni istanza di moneta dal pannello Node > Groups per poterle recuperare tutte in un colpo solo, invece di tenere riferimenti manuali a ciascuna. È lo schema più comune per gestire collezionabili e nemici in scene con decine di istanze.
Passo 10: crea l’interfaccia utente con i nodi Control
L’interfaccia in Godot 4 si costruisce con nodi Control (Label, Button, ProgressBar) organizzati dentro un CanvasLayer, così restano ancorati allo schermo indipendentemente dalla telecamera di gioco. Aggiungi un CanvasLayer alla scena principale, poi dentro un nodo Label chiamato ScoreLabel: è il riferimento usato nello script del passo precedente.
Usa i Container (VBoxContainer, HBoxContainer, MarginContainer) invece di posizionare manualmente ogni elemento in pixel: si adattano automaticamente a risoluzioni diverse, un dettaglio cruciale quando poi esporti lo stesso gioco su desktop e Web con aspect ratio differenti. Aggiungi anche un nodo AudioStreamPlayer2D al player per l’audio del salto: assegna un file .ogg o .wav nell’Inspector e richiama $AudioStreamPlayer2D.play() nello script quando serve.
Passo 11: aggiungi animazioni con AnimationPlayer
Il nodo AnimationPlayer permette di creare timeline con keyframe direttamente dall’editor, senza scrivere codice: definisci una traccia “idle” e una “run” cambiando i frame dello Sprite2D o di un AnimatedSprite2D dedicato. Aggiungilo come figlio del CharacterBody2D e collega ogni traccia ai fotogrammi corrispondenti dello sprite sheet.
Un errore frequente qui è dimenticare di collegare l’AnimationPlayer alla logica di movimento: se non chiami $AnimationPlayer.play("run") quando direction != 0, il personaggio si muove ma resta visivamente fermo. Aggiungi questa chiamata nello stesso blocco _physics_process del Passo 6, dentro il ramo condizionale che gestisce la direzione.
Passo 12: esporta il gioco per Windows, Linux, macOS e Web
Vai su Project > Export e clicca Add per scegliere una piattaforma. Se è la prima volta, Godot ti chiede di scaricare gli Export Templates corrispondenti alla versione 4.7.1: senza questi file binari, circa 400-600 MB a seconda della piattaforma, l’esportazione fallisce con un errore chiaro in console.
| Piattaforma | Formato output | Note |
|---|---|---|
| Windows Desktop | .exe + .pck | Richiede icona .ico opzionale nelle impostazioni export |
| Linux/X11 | Binario eseguibile | Serve chmod +x dopo l’export sul sistema di destinazione |
| macOS | .app / .dmg | Firma del codice necessaria per distribuzione fuori dall’App Store |
| Web (HTML5) | .html + .wasm | Va servito da un web server, non apribile da file locale per via di CORS |
# Esportazione da riga di comando, utile per pipeline CI/CD
$ godot --headless --export-release "Windows Desktop" build/PrimoGioco.exe
$ godot --headless --export-release "Linux/X11" build/PrimoGioco.x86_64
Per il Web, dopo l’export testa il build con un server locale invece di aprire l’HTML direttamente dal filesystem: python3 -m http.server 8000 nella cartella di output basta per verificare che tutto funzioni prima di caricarlo su itch.io o un hosting statico.
Passo 13: testa il progetto e usa il debugger integrato
Prima di esportare, vale la pena imparare a usare il debugger di Godot, accessibile dal pannello in basso quando premi F5 per avviare il progetto completo (a differenza di F6, che avvia solo la scena aperta). Il pannello Debugger mostra errori runtime con lo stack di chiamate, un elenco di variabili live e un monitor delle prestazioni con FPS, memoria video e numero di nodi disegnati a schermo.
Per il debug rapido, la funzione print() resta lo strumento più usato dagli sviluppatori Godot, ma per casi più complessi conviene usare print_debug(), che aggiunge automaticamente il file e la riga da cui è stata chiamata: risparmia tempo quando lo stesso messaggio compare da più punti dello script.
func _on_coin_collected() -> void:
score += 1
print_debug("Moneta raccolta, punteggio attuale: ", score)
$UI/ScoreLabel.text = "Punti: %d" % score
Puoi anche impostare breakpoint cliccando accanto al numero di riga nello script editor: quando l’esecuzione li raggiunge, Godot mette in pausa il gioco e apre automaticamente il pannello Debugger con lo stato completo delle variabili locali, esattamente come un debugger di un IDE tradizionale. Questo è molto più efficace di disseminare il codice di print() temporanei, soprattutto quando il bug dipende dall’ordine in cui i segnali vengono emessi.
Passo 14: ottimizza le performance e scegli il metodo di rendering
Il monitor delle prestazioni nel Debugger (scheda Monitors) traccia in tempo reale FPS, tempo di frame in millisecondi, oggetti disegnati e chiamate draw call. Per un platform 2D semplice come quello di questo tutorial, restare sotto le 100 draw call e sopra i 60 FPS costanti è un buon obiettivo anche su hardware modesto.
Se le prestazioni calano, il primo intervento è quasi sempre cambiare renderer da Project Settings: Forward+ offre illuminazione dinamica avanzata ma costa di più in termini di GPU, Mobile è un compromesso pensato per smartphone e schede grafiche di fascia media, mentre Compatibility sacrifica alcuni effetti visivi per girare anche su GPU integrate datate o browser meno recenti in fase di export Web.
| Renderer | Target hardware | Compromesso principale |
|---|---|---|
| Forward+ | GPU dedicate recenti con Vulkan 1.0 | Massima qualità grafica, costo prestazionale più alto |
| Mobile | Smartphone e GPU integrate di fascia media | Buon equilibrio, meno effetti di post-processing |
| Compatibility | GPU datate, browser con OpenGL/GLES3 | Massima compatibilità, meno illuminazione dinamica |
Un’altra leva spesso trascurata è l’Occlusion Culling e il batching automatico degli sprite: Godot raggruppa automaticamente i draw call per texture condivisa, quindi usare uno sprite sheet unico invece di tante immagini separate riduce sensibilmente il numero di draw call in scene affollate, come quelle con molte monete o nemici a schermo contemporaneamente.
Il progetto completo: struttura finale delle cartelle
A fine tutorial la cartella del progetto dovrebbe avere questa struttura, che è anche lo schema consigliato dalla documentazione ufficiale per progetti 2D di piccole dimensioni:
PrimoGioco/
├── project.godot
├── icon.svg
├── scenes/
│ ├── main.tscn
│ ├── player.tscn
│ └── coin.tscn
├── scripts/
│ ├── player.gd
│ ├── coin.gd
│ └── main.gd
├── assets/
│ ├── sprites/
│ └── audio/
└── export_presets.cfg
Il file export_presets.cfg viene generato automaticamente dal Passo 12 e contiene tutti i profili di esportazione: tienilo nel controllo versione insieme al resto, così ogni collaboratore del team ripristina la stessa configurazione senza doverla ricreare da zero. Prima di considerare il progetto finito, verifica questa checklist minima: la scena principale è impostata correttamente in Project Settings > Application > Run, tutti gli export template scaricati corrispondono alla versione 4.7.1 dell’editor, e il file .gitignore esclude sia .godot/ sia la cartella build/ generata dalle esportazioni. Quando esegui il progetto dall’editor con F5, la console in basso mostra un output simile a questo, utile per confermare che tutto sia collegato correttamente:
Godot Engine v4.7.1.stable.official
OpenGL API 3.3 (Compatibility) - Using Device: llvmpipe
Player pronto. Nodi nel gruppo 'coins': 5
Punti: 1
Punti: 2
Errori comuni da evitare
- Confondere _process e _physics_process: mettere la logica di movimento in _process causa comportamenti diversi a frame rate diversi, perché non è sincronizzato con il motore fisico. Usa sempre _physics_process per movimento e collisioni.
- Dimenticare la CollisionShape2D: un nodo di collisione senza una Shape assegnata nell’Inspector non genera errori bloccanti, solo un warning silenzioso, ed è la causa più comune di “il personaggio attraversa i muri”.
- Usare percorsi assoluti fragili con $: riferimenti come
$"../UI/ScoreLabel"si rompono appena sposti un nodo nell’albero. Preferisci i gruppi o le variabili @export per collegare nodi in modo più robusto. - Non salvare la scena prima di testarla: Godot esegue l’ultimo stato salvato su disco, non quello visibile nell’editor. Modifiche non salvate vengono ignorate da Play Scene (F6), un comportamento diverso da Unity che genera confusione nei primi giorni.
- Ignorare gli Export Template mancanti: provare a esportare senza aver scaricato i template per la versione 4.7.1 esatta produce un errore nella console invece di un dialogo evidente in primo piano.
- Mescolare Forward+ e hardware datato: avviare un progetto Forward+ su una GPU integrata pre-2018 causa schermate nere o crash all’avvio invece di un semplice calo di prestazioni.
Risoluzione dei problemi: gli errori più frequenti
Ecco gli otto problemi più segnalati dalla community italiana e internazionale nei forum ufficiali e su Reddit r/godot durante l’apprendimento con Godot 4.7.1.
- “Failed loading resource” all’apertura del progetto: di solito indica un percorso di file rotto dopo aver spostato manualmente asset fuori dall’editor invece che dal pannello FileSystem. Usa sempre il FileSystem interno per rinominare o spostare file.
- Schermo nero al primo avvio con Forward+: la GPU non supporta Vulkan 1.0 correttamente. Vai su Project Settings > Rendering > Renderer e seleziona Compatibility.
- Il personaggio “vibra” contro il pavimento: spesso causato da
move_and_slide()chiamato più volte per frame o da collision shape sovrapposte tra loro. Verifica di avere una sola chiamata per ciclo di _physics_process. - Segnale connesso ma la funzione non viene mai chiamata: controlla che il nome del metodo nel pannello Signals corrisponda esattamente al nome della funzione nello script, GDScript è case-sensitive.
- Export Web che non parte nel browser: quasi sempre un problema di CORS per apertura da file locale. Serve un web server anche solo per test, come indicato al Passo 12.
- Autocomplete GDScript che non funziona: capita quando lo script non ha ancora la riga
extendscorretta in cima al file, oppure quando il progetto ha errori di sintassi altrove che bloccano il parser. - “Node not found” con riferimenti $: il percorso relativo tra i nodi è cambiato dopo una modifica alla gerarchia della scena. Riapri la scena e ricontrolla il percorso nell’Inspector o nello script.
- Crash durante l’esportazione per macOS da Windows o Linux: l’export cross-platform per macOS richiede strumenti aggiuntivi di firma codice non sempre disponibili fuori da macOS; per build di produzione conviene esportare direttamente da un Mac o usare un servizio di firma remoto.
Consigli avanzati per usare Godot come un professionista
Una volta superati i fondamentali, alcune pratiche fanno la differenza tra un prototipo e un progetto mantenibile nel tempo. Usa gli autoload (Project Settings > Autoload) per singleton globali come un GameManager che sopravvive al cambio scena: è l’equivalente Godot dei DontDestroyOnLoad di Unity, ma dichiarativo invece che via codice.
Per progetti che superano la singola persona, adotta le Scene ereditate (Scene > New Inherited Scene): permettono di creare varianti di un nemico o di un livello senza duplicare l’intera struttura di nodi, mantenendo i cambiamenti sincronizzati con la scena base. Se il tuo progetto cresce oltre GDScript puro, valuta il GDExtension per scrivere moduli in C++ ad alte prestazioni per il codice più critico, per esempio il pathfinding su mappe grandi, lasciando GDScript per la logica di gioco quotidiana.
Infine, integra Godot nel tuo flusso Git: il formato testuale di scene (.tscn) e risorse (.tres) si presta bene a diff e merge, a differenza degli scene file binari usati da altri motori. Aggiungi un .gitignore che escluda la cartella .godot/ generata automaticamente: contiene solo cache locale e non va versionata.
Per team che lavorano su più macchine, imposta anche Editor Settings > Text Editor > External se preferisci un editor esterno come VS Code al posto dello script editor integrato: Godot mantiene comunque il debugger e l’anteprima scena nell’editor principale, mentre la scrittura del codice passa al tool che preferisci. Questo flusso ibrido è comune nei team più grandi che vogliono estensioni linting e refactoring più avanzate di quelle disponibili nativamente.
Godot Engine, Unity o Unreal: quale scegliere nel 2026
La scelta dipende dal tipo di progetto più che da preferenze astratte. Per un confronto approfondito su prezzi e funzionalità dei tre motori, abbiamo dedicato un articolo a parte: Unreal Engine vs Unity vs Godot. Qui riassumiamo solo i punti che contano per chi sta decidendo se seguire questo tutorial oppure orientarsi altrove.
| Criterio | Godot 4.7.1 | Unity 6.3 | Unreal Engine 5.8 |
|---|---|---|---|
| Licenza | MIT, gratis senza limiti | Gratis con royalty condizionate | Gratis fino a 1 milione $ di ricavi |
| Linguaggio principale | GDScript, C#, C++ | C# | C++, Blueprint visuale |
| Dimensione editor | Sotto i 100 MB | Diversi GB con Hub | Oltre 30 GB con template |
| Miglior uso | 2D indie, prototipi rapidi, giochi mobile leggeri | Progetti cross-platform di team medi | AAA 3D, grafica fotorealistica |
Se punti a un platform 2D, un roguelike o un gioco mobile leggero, Godot è oggi la scelta più diretta: editor leggero, GDScript facile da imparare e nessuna royalty da monitorare mentre il progetto cresce. Per progetti 3D con ambizioni fotorealistiche, team più numerosi o pipeline cinematiche complesse, Unreal Engine resta il riferimento del settore, mentre Unity continua a convenire per chi cerca il bacino più ampio di asset commerciali pronti all’uso e integrazioni con servizi terzi già consolidate. Per approfondire gli altri due motori, abbiamo pubblicato tutorial dedicati: Unity 6.3 Tutorial e Unreal Engine 5.8 Tutorial.
Licenza, costi e community: perché Godot è gratis
Godot è distribuito sotto licenza MIT, una delle licenze open source più permissive che esistono: puoi usarlo per progetti commerciali, modificarne il codice sorgente e persino ridistribuire una versione personalizzata del motore stesso, senza dover pagare royalty né dichiarare i tuoi ricavi a nessuno. Lo sviluppo è coordinato dalla Godot Foundation, un’organizzazione no-profit finanziata da donazioni, sponsorizzazioni aziendali e grant, secondo quanto riportato dalla documentazione ufficiale del progetto.
Il codice sorgente completo è ospitato su GitHub, dove chiunque può proporre modifiche tramite pull request: è uno dei motori di gioco open source con la community di contributori più attiva, e questo si traduce in cicli di rilascio frequenti. Godot 4.7 è uscito a giugno 2026 con supporto HDR, area light e drawable texture, e la patch di manutenzione 4.7.1 è arrivata già il 14 luglio 2026 per correggere bug segnalati dagli utenti nelle prime settimane dopo il rilascio.
Questo modello di sviluppo aperto ha anche un rovescio della medaglia da conoscere prima di affidare un progetto commerciale a lungo termine al motore: la Godot Foundation non ha le risorse finanziarie di Epic Games o Unity Technologies alle spalle, quindi il ritmo delle nuove funzionalità dipende in buona parte da donazioni e dal tempo che i contributori volontari riescono a dedicare al progetto. Per la maggior parte dei team indie questo non è un problema pratico, ma vale la pena tenerlo a mente se stai valutando Godot per un progetto con un team numeroso e scadenze rigide.
Risorse per continuare a imparare dopo questo tutorial
La documentazione ufficiale di Godot resta il punto di riferimento migliore, con la sezione Step by Step che approfondisce ogni concetto toccato in questo tutorial, nodi e scene compresi. Per requisiti hardware dettagliati e note sulle GPU supportate, consulta la pagina ufficiale dei requisiti di sistema.
Per tutorial video strutturati, GDQuest è uno dei canali di formazione più citati dalla community, con corsi gratuiti e a pagamento pensati apposta per chi arriva da altri motori. Se vuoi vedere esempi di giochi commerciali reali costruiti con Godot, la voce Godot su Wikipedia mantiene un elenco aggiornato di titoli pubblicati, incluso il già citato Slay the Spire 2.
Un buon prossimo passo dopo questo tutorial è ricreare lo stesso mini-gioco in 3D, sostituendo CharacterBody2D con CharacterBody3D e Area2D con Area3D: la logica di script resta quasi identica, cambiano solo i tipi di vettore (da Vector2 a Vector3) e i nodi di collisione. È il modo più rapido per capire quanto la filosofia a nodi e segnali di Godot resti coerente indipendentemente dalla dimensionalità del progetto.
Domande frequenti
Godot Engine è davvero gratis al 100%?
Sì. La licenza MIT non prevede royalty, percentuali sui ricavi o abbonamenti, a differenza di Unity e in parte di Unreal Engine, che applica una royalty solo oltre 1 milione di dollari di ricavi lordi.
Conviene imparare GDScript o C# in Godot 4.7.1?
Per iniziare, GDScript: è più documentato, integrato nativamente nell’editor e più semplice da leggere. C# conviene se hai già esperienza con .NET o se il progetto richiede librerie esterne specifiche del linguaggio.
Posso pubblicare un gioco Godot su Steam?
Sì, esportando un build Windows, Linux o macOS come descritto al Passo 12 e caricandolo tramite Steamworks SDK, esattamente come faresti con un progetto Unity o Unreal.
Godot 4.7.1 supporta i giochi 3D oltre al 2D?
Sì, il motore condivide lo stesso editor per 2D e 3D, con il renderer Forward+ pensato apposta per scene 3D moderne con illuminazione dinamica, HDR e area light introdotte con la release 4.7.
Quanto tempo serve per completare questo tutorial?
Circa 90 minuti per chi segue tutti i 14 passi con calma, inclusi download e installazione degli export template. Chi ha già familiarità con un altro motore può completarlo in 45-60 minuti.
Serve una scheda video dedicata per usare Godot 4?
No per il renderer Compatibility, che gira su GPU integrate con supporto OpenGL 3.3/GLES3. Per Forward+ con effetti avanzati serve invece supporto Vulkan 1.0, presente sulla maggior parte delle GPU degli ultimi 6-7 anni.
Come faccio a passare da un progetto Godot 3 a Godot 4.7.1?
Non è una migrazione automatica: l’API è cambiata in modo sostanziale tra le due major version, per esempio KinematicBody2D è diventato CharacterBody2D. Godot include uno strumento di conversione parziale, ma per progetti complessi conviene pianificare una riscrittura mirata degli script più datati.
Esiste un modo per testare il gioco senza aprire l’editor completo?
Sì, con il flag --headless da riga di comando puoi lanciare test automatizzati o script di build in CI/CD senza avviare l’interfaccia grafica, utile per pipeline di integrazione continua.




