Attention: Here be dragons
This is the latest
(unstable) version of this documentation, which may document features
not available in or compatible with released stable versions of Godot.
Checking the stable version of the documentation...
Domande frequenti
Cosa posso fare con Godot? Quanto costa? Quali sono le condizioni di licenza?
Godot è Software libero e open-source disponibile sotto la licenza approvata dalla OSI MIT. Questo significa che è libero come in "libertà di espressione" così come in "birra gratis."
In breve:
Sei libero di scaricare e utilizzare Godot per qualsiasi scopo: personale, non-profit, commerciale o altro.
Sei libero di modificare, distribuire, ridistribuire e remixare Godot a tuo piacimento, per qualsiasi motivo, sia non commerciale sia commerciale.
Tutti i contenuti della documentazione che lo accompagna sono coperti dalla licenza permissiva Creative Commons Attribution 3.0 (CC-BY 3.0), con attribuzione a "Juan Linietsky, Ariel Manzur e la comunità di Godot Engine."
Loghi e icone sono in linea generale coperti dalla stessa licenza Creative Commons. Alcune librerie di terze parti incluse con il codice sorgente di Godot possono però essere coperte da diverse licenze.
Per tutti i dettagli, consultare il file COPYRIGHT.txt così come il file LICENSE.txt e LICENSE.txt per il logo nel repository di Godot.
Inoltre, vedi ` la pagina della licenza sul sito di Godot <https://godotengine.org/license>`_.
Quali piattaforme sono supportate da Godot?
Per l'editor:
Windows
macOS
Linux, *BSD
Android (sperimentale)
Web (sperimentale)
Per esportare i tuoi giochi:
Windows
macOS
Linux, *BSD
Android
iOS
Web
Gli eseguibili a 32 e 64 bit sono entrambi supportati qualora abbia senso, con la versione a 64 bit come predefinita. Gli eseguibili ufficiali di macOS supportano nativamente Apple Silicon e x86_64.
Alcuni utenti hanno riportato di aver compilato e usato Godot con successo su sistemi ARM-based con Linux, come il Raspberry Pi.
Per informazioni sul supporto per console, consultare il sito web di Godot.
Per saperne di più, vedi le sezioni su exporting e compilare Godot da solo.
Nota
Godot 3 supportava anche la piattaforma Universal Windows Platform (UWP). Questa piattaforma è stata rimossa in Godot 4 a causa di mancata manutenzione, nonché della sua deprecazione da Microsoft. È ancora disponibile nell'attuale versione stabile di Godot 3 per gli utenti interessati.
Quali sono i linguaggi di programmazione supportati in Godot?
I linguaggi supportati ufficialmente da Godot sono GDScript, C# e C++. Vedi le sottocategorie per ogni linguaggio nella sezione scripting.
Se si sta appena iniziando con Godot o lo sviluppo di giochi in generale, GDScript è il linguaggio consigliato da imparare e utilizzare dal momento che è nativo di Godot. Mentre i linguaggi di scripting tendono a essere meno performanti di quelli di livello inferiore nel lungo periodo, per la prototipazione, lo sviluppo di prodotti a basso costo (MVP), e concentrandosi sul time-to-market (TTM), GDScript fornirà un modo veloce, facile e funzionale di sviluppare i vostri giochi.
Si noti che il supporto C# è ancora relativamente nuovo, e come tale, si possono incontrare alcuni problemi. Inoltre, il supporto per C# è attualmente assente sulla piattaforma web. La nostra amichevole e laboriosa comunità di sviluppo è sempre pronta ad affrontare i nuovi problemi che si presentano, ma poiché questo è un progetto open-source, si consiglia di fare prima un po' di dovuta diligenza. Sfogliare tra le discussioni sui problemi aperti è un ottimo modo per cominciare a risolvere problemi.
Per quanto riguarda nuovi linguaggi, il supporto è possibile tramite terze parti con GDExtension. (Consulta la domanda sulle estensioni in seguito.) Attualmente sono in corso lavori, ad esempio, su binding non ufficiali per Godot e Python e Nim.
Cos'è GDScript e perché dovrei usarlo?
GDScript è il linguaggio di script integrato in Godot. È stato costruito da zero per massimizzare il potenziale di Godot nella minor quantità di codice, consentendo sia ai principianti sia agli sviluppatori esperti di sfruttare al meglio le capacità di Godot il più rapidamente possibile. Se si ha già scritto qualcosa in un linguaggio come Python allora ci si sentirà subito al proprio agio. Per esempi e una panoramica completa delle capacità che GDScript offre, consultare la guida di scripting di GDScript.
Ci sono diverse ragioni per usare GDScript, ma la ragione più saliente è la generale ** riduzione della complessità**.
L'intento originale di creare un linguaggio di scripting strettamente integrato e personalizzato per Godot era duplice: in primo luogo, riduce la quantità di tempo necessaria per apprendere Godot, con particolare attenzione alla produttività; in secondo luogo, semplifica la manutenzione, riduce la portata dei problemi, e permette agli sviluppatori del motore di concentrarsi sulla correzione di bug e migliorare le funzionalità fondamentali del motore, piuttosto che spendere molto tempo cercando di far funzionare un piccolo insieme di nuove funzionalità su un grande insieme di linguaggi.
Essendo Godot un progetto open-source, era imperativo sin dall'inizio dare priorità a una esperienza il più possibile integrata e fluida piuttosto che cercare di attirare più utenti supportando i linguaggi di programmazione più familiari, soprattutto quando il supporto per tali linguaggi risulterebbe in un'esperienza peggiore. Capiamo se si desidera utilizzare un altro linguaggio in Godot (consultare la lista delle opzioni supportate sopra). Detto questo, se non ancora fatto, si consiglia di provare GDScript per tre giorni. Esattamente come per Godot, una volta constatato quanto è potente, e quanto velocizza lo sviluppo, pensiamo che GDScript inizierà a piacere.
Ulteriori informazioni su come prendere mano con GDScript o altri linguaggi tipizzati dinamicamente possono essere trovate nel tutorial GDScript: Un'introduzione ai linguaggi dinamici.
Quali sono state le motivazioni alla base della creazione di GDScript?
All'inizio, il motore usava il linguaggio di scripting Lua. Lua può essere veloce grazie a LuaJIT, ma creare binding per un sistema orientato agli oggetti (attraverso alternative) fu complicato e lento e ha richiesto un'enorme quantità di codice. Dopo aver sperimentato con Python, anch'esso si era dimostrato difficile da integrare.
I motivi principali per la creazione di un linguaggio di scripting personalizzato per Godot sono stati:
Cattivo supporto ai thread nella maggior parte delle VM degli altri linguaggi, e Godot usa thread (Lua, Python, Squirrel, JS, AS, ecc.).
Non esiste un buon supporto per l'estensione delle classi nella maggior parte delle VM degli altri linguaggi, e adattarle al funzionamento di Godot è altamente inefficiente (Lua, Python, JS).
Molti linguaggi già esistenti hanno interfacce pessime per il binding in C++, e ciò risulta in una quantità enorme di codice, bug, colli di bottiglia e inefficienze in generale (Lua, Python, Squirrel, JavaScript, ecc.). Volevamo concentrarci su un ottimo motore, non su una grande quantità di integrazioni.
Nessun tipo nativo per i vettori (Vector3, Transform3D, ecc.), il che risulta in prestazioni molto ridotte quando si usano tipi personalizzati (Lua, Python, Squirrel, JavaScript, ActionScript, ecc.).
Il garbage collector produce rallentamenti o un uso della memoria inutilmente alto (Lua, Python, JavaScript, ActionScript, ecc.).
Difficoltà nell'integrazione con l'editor di codice per fornire l'auto-completamento di codice, modifiche in tempo reale, ecc.
GDScript è stato progettato per ridurre i problemi di cui sopra e altri ancora.
Quale linguaggio di programmazione è il più veloce?
Nella maggior parte dei giochi, il linguaggio di scripting in sé non è la causa dei problemi di prestazioni. Le prestazioni sono invece rallentate da algoritmi inefficienti (che sono lenti in tutti i linguaggi), dalle prestazioni della GPU o dal codice del motore C++ comune, come la fisica o la navigazione. Tutti i linguaggi supportati da Godot sono veloci abbastanza per lo scripting generico. La scelta di un linguaggio dovrebbe essere basata su altri fattori, come la facilità d'uso, la familiarità, il supporto della piattaforma o le funzionalità del linguaggio.
In generale, le prestazioni di C# e GDScript sono nello stesso ordine di grandezza, e C++ è più veloce di entrambi.
Confrontare le prestazioni di GDScript con C# è complicato, poiché C# può essere più veloce in alcuni casi specifici. Il linguaggio C# stesso tende a essere più veloce di GDScript, il che significa che C# può essere più veloce in situazioni con poche chiamate al codice del motore Godot. Tuttavia, C# può essere più lento di GDScript quando si effettuano numerose chiamate all'API di Godot, a causa del costo del marshalling. Le prestazioni di C# possono anche essere ridotte dalla garbage collection, che avviene a caso e imprevedibilmente. Ciò può causare problemi di stuttering in progetti complessi e non è un problema esclusivo a Godot.
Il C++, utilizzando GDExtension, sarà quasi sempre più veloce di C# o GDScript. Tuttavia, il C++ è meno facile da utilizzare rispetto a C# o GDScript, ed è più macchinoso da sviluppare.
È anche possibile utilizzare più linguaggi all'interno di un singolo progetto, con cross-language scripting, oppure utilizzando GDExtension e linguaggi di scripting insieme. Si tenga presente che questa soluzione presenta le sue proprie complicazioni.
Quali sono i formati per i modelli 3D supportati da Godot?
Puoi trovare informazioni dettagliate sui formati supportati, su come esportarli da software di modellazione 3D, e su come importarli in Godot nella documentazione Importare Scene 3D.
Sarà [inserire SDK proprietari come FMOD, Gameworks, ecc.] supportato in Godot?
Lo scopo di Godot è di creare un motore libero, open-source con licenza MIT, modulare ed estensibile. Non è previsto, da parte della comunità di sviluppo principale del motore, il supporto per SDK di terze parti, a closed-source o proprietari, in quanto integrarli andrebbe contro lo spirito di Godot.
Detto questo, essendo Godot open source e modulare, niente impedisce, a chiunque sia interessato, di aggiungere queste librerie come modulo e rilasciare un gioco con esse, come open source o closed source.
Per vedere come possa essere fornito il supporto per il SDK scelto, vedi la domanda sui Plugins poco sotto.
Se si conosce un SDK di terze parti che non è attualmente supportato da Godot ma che offre un'integrazione open source, si può considerare di iniziare a lavorare su un'integrazione personalmente. Godot non é di proprietà di una sola persona, appartiene alla comunità e cresce insieme a contributori ambiziosi, come te.
Come posso estendere Godot?
Per estendere Godot, ad esempio creando plugin per Godot Editor o aggiungere il supporto per ulteriori linguaggi, fai riferimento a EditorPlugins e ai tool script.
Consultare anche il post ufficiale sul blog di GDExtension, un modo per sviluppare estensioni native per Godot:
Puoi anche dare un'occhiata all'implementazione di GDScript, ai moduli di Godot e all'integrazione del motore di fisica Jolt per Godot. Questo sarebbe un buon punto di inizio per capire come le librerie di terze parti si integrano in Godot.
Come installo l'editor di Godot sul mio Sistema Operativo (per l'integrazione col desktop)?
Visto che non devi installare Godot sul tuo sistema per usarlo, l'integrazione col desktop non è automatica. Ci sono due modi per superare questo problema. È possibile installare Godot da Steam (tutte le piattaforme), Scoop (Windows), Homebrew (macOS) or Flathub (Linux). Questo eseguirà automaticamente i passaggi necessari per l'integrazione col desktop.
Alternativamente, puoi eseguire manualmente i passaggi che un installer eseguirebbe per te:
Windows
Sposta l'eseguibile di Godot in una posizione stabile (cioè fuori della cartella Download), così da non spostarlo accidentalmente e rompere il collegamento in futuro.
Fai clic con il pulsante destro sull'eseguibile di Godot e scegli Crea collegamento.
Sposta il collegamento creato in
%APPDATA%\Microsoft\Windows\Start Menu\Programs. Questa è la posizione specifica di ciascun utente per le scorciatoie che appariranno nel menu Start. Puoi anche bloccare Godot nella barra delle applicazioni cliccando con il pulsante destro sull'eseguibile e scegliendo Aggiungi alla barra delle applicazioni.
macOS
Trascina l'applicazione Godot estratta su /Applicazioni/Godot.app, quindi trascinala sul Dock se lo desideri. Spotlight sarà in grado di trovare Godot fintanto che si trova in /Applicazioni o in ~/Applicazioni.
Linux
Sposta l'eseguibile di Godot in una posizione stabile (cioè al di fuori della cartella Download), in modo da non spostarlo accidentalmente e rompere il collegamento in futuro.
Rinomina e sposta l'eseguibile di Godot in una posizione presente nella tua variabile d'ambiente
PATH. Di solito è/usr/local/bin/godoto/usr/bin/godot. Questo metodo richiede i privilegi d'amministratore, ma ti pemette di eseguire Godot da un terminale scrivendo``godot``.Se non puoi spostare l'eseguibile dell'editor Godot in una posizione protetta, puoi tenerlo da qualche parte nella tua cartella home e modificare la riga
Path=del file.desktoplinkato qui sotto andando a inserire l'intero percorso assoluto del file eseguibile Godot.
Salva questo file .desktop in
$HOME/.local/share/applications/. Se hai i privilegi d'amministratore, puoi anche salvare il file.desktopin/usr/local/share/applicationsper rendere il collegamento disponibile per tutti gli utenti.
L'editor Godot è un'applicazione portabile?
Nella configurazione di default, Godot è semi-portatile. Il suo eseguibile può partire da ogni luogo (incluso luoghi non scrivibili) e non richiede mai privilegi di amministratore.
Tuttavia, i file di configurazione verranno scritti nella configurazione a livello di utente o nella cartella dei dati. Questo di solito è un buon approccio, ma questo significa che i file di configurazione non verranno trasferiti tra le macchine se si copia la cartella contenente l'eseguibile Godot. Vedi Percorsi di file nei progetti di Godot per maggiori informazioni.
Se si è interessati a un funzionamento veramente portabile (ad esempio per l'uso su una chiavetta USB), seguire i passaggi in Modalità autonoma.
Perché Godot cerca di mantenere piccolo il suo set di funzionalità principali?
Godot non include intenzionalmente funzionalità che possono essere implementate da componenti aggiuntivi, a meno che non siano utilizzate molto spesso. Un esempio di ciò sarebbe una funzionalità di intelligenza artificiale avanzata.
Ci sono diverse ragioni per questo:
Manutenzione del codice e ricerca di bug Ogni volta che accettiamo nuovo codice nel repository di Godot, contributori già esistenti spesso si assumono la responsabilità di mantenerlo. Alcuni contributori però non rimangono sempre dopo che il loro codice sia stato accettato, il che può rendere difficile per noi mantenere il codice in questione. Ciò può portare a funzionalità non sufficientemente mantenute con dei bug mai risolti. Inoltre, la "superficie dell'API" che ha bisogno di essere testata e verificata per regressioni continua a crescere nel corso del tempo.
Facilità di contribuire Mantenendo il repository piccolo e ordinato, rimane facile e veloce compilare dalla risorsa principale. Questo rende molto più facile per i nuovi contributori iniziare con Godot, senza che devano acquistare hardware di alto livello.
Mantenere una dimensione piccola del file binario dell'editor. Non tutti hanno una connessione veloce a internet. Assicurarsi che chiunque possa scaricare l'editor di Godot, estrarlo ed eseguirlo in meno di 5 minuti rende Godot più accessibile agli sviluppatori.
Mantenere una dimensione piccola per i modelli di esportazione. Questo impatta direttamente la dimensione dei progetti esportati con Godot. Sulle piattaforme mobile e web, mantenere piccole le dimensioni dei file è molto importante per garantire un'installazione e un caricamento rapido anche su dispositivi con poca potenza. Anche in questo caso, ci sono molti paesi in cui la connessione a internet ad alta velocità non è disponibile. In più, in questi paesi generalmente ci sono severi limiti all'utilizzo dei dati.
Per tutte le ragioni dette precedentemente, dobbiamo essere selettivi sulle funzionalità fondamentali da accettare in Godot. Questo è il motivo per cui, in future versioni di Godot, stiamo puntando a spostare alcune funzionalità fondamentali in componenti aggiuntivi supportati ufficialmente. Per la dimensione di un eseguibile, ciò ha anche il vantaggio di includere solo quello che è usato nel tuo progetto. (Nel frattempo, puoi compilare modelli di esportazione personalizzati con le funzionalità non usate disabilitate per ottimizzare la dimensione di distribuzione del tuo progetto.)
Come devono essere creati i contenuti per gestire più risoluzioni e proporzioni?
Questa domanda si presenta spesso ed è probabilmente grazie al malinteso creato da Apple quando originariamente ha raddoppiato la risoluzione dei loro dispositivi. Ha fatto pensare alla gente che avere le stesse risorse in diverse risoluzioni fosse una buona idea, così tanti hanno continuato su quella strada. Inizialmente funzionava fino a un certo punto e solo per i dispositivi Apple, ma poi sono stati creati diversi dispositivi Android e Apple con risoluzioni e proporzioni diverse, con una gamma molto ampia di dimensioni e DPI.
Il modo più comune e corretto per ottenere questo è invece, usare una singola risoluzione di base per il gioco e gestire solamente rapporti d'aspetto diversi. Questo è soprattutto necessario per il 2D, poiché nel 3D è solo una questione di campo visivo orizzontale o verticale della telecamera.
Scegli una singola risoluzione di base per il tuo gioco. Anche se ci sono dispositivi che arrivano fino a 1440p e dispositivi che scendono a 400p, il normale ridimensionamento dell'hardware nel tuo dispositivo se ne occuperà, con un impatto minimo o nullo sulle prestazioni. Le scelte più comuni sono vicine a 1080p (1920x1080) o 720p (1280x720). Tieni presente che più alta è la risoluzione, più grandi sono le tue risorse, maggiore sarà la memoria occupata e maggiore sarà il tempo di caricamento.
Utilizza le opzioni di adattamento in Godot; una delle soluzioni migliori è allungare gli elementi canvas mantenendo il rapporto di aspetto. Consulta il tutorial Risoluzioni multiple su come ottenere questo risultato.
Determina una risoluzione minima e quindi decidi se vuoi che il tuo gioco si adatti verticalmente o orizzontalmente per i diversi aspect ratio, o se ce n'è una minima e vuoi invece che appaiano delle barre nere. Questo è anche spiegato nello step precedente: Risoluzioni multiple .
Per le interfacce utente, usa anchoring in modo da decidere dove i controlli dovrebbero essere e muoversi. Se la UI è più complessa, considera i Containers.
E questo è tutto! Il tuo gioco dovrebbe funzionare con più risoluzioni.
Quando uscirà la prossima versione di Godot?
Quando è pronta! Vedi Quando uscirà la prossima versione? per maggiori informazioni.
Quale versione di Godot dovrei usare per un nuovo progetto?
Consigliamo di utilizzare Godot 4.x per i nuovi progetti, ma a seconda delle funzionalità necessarie, potrebbe essere preferibile utilizzare la versione 3.x. Consultare Quale versione dovrei usare per un nuovo progetto? per ulteriori informazioni.
Dovrei aggiornare il mio progetto per utilizzare le nuove versioni di Godot?
Alcune nuove versioni sono più sicure da aggiornare rispetto ad altre. In generale, la decisione di effettuare l'aggiornamento dipende dalle circostanze del progetto. Consultare Dovrei aggiornare il mio progetto per utilizzare le nuove versioni del motore? per ulteriori informazioni.
Dovrei usare il renderer Forward+, Mobile o Compatibilità?
Si può trovare un confronto dettagliato tra i renderer in Panoramica dei renderer.
Vorrei contribuire! Come posso iniziare?
Stupendo! Essendo un progetto open source, Godot prospera attraverso l'innovazione e l'ambizione di sviluppatori come te.
Il modo migliore per iniziare a contribuire a Godot è usarlo e segnalare eventuali problemi che si potrebbero riscontrare. Una buona segnalazione di bug con chiare istruzioni di riproduzione aiuta gli altri contributori a risolvere i bug in modo rapido ed efficiente. Si possono anche segnalare i problemi trovati nella documentazione online.
Se ti senti pronto a inviare la tua prima pull request (PR), scegli un problema che ti interessa da uno dei collegamenti qui sopra e prova a risolverlo. Dovrai imparare a compilare il motore dai sorgenti o a compilare la documentazione. Dovrai anche familiarizzarti con Git, un sistema di controllo versioni utilizzato dagli sviluppatori di Godot.
Spieghiamo come lavorare con il codice sorgente del motore, come modificare la documentazione e quali altri modi ci sono per contribuire nella nostra documentazione per i collaboratori.
È possibile utilizzare Godot per creare applicazioni che non siano giochi?
Sì! Godot dispone di un ampio sistema di UI integrato, e la sua piccola dimensione di distribuzione può renderlo un'alternativa adatta a framework come Electron o Qt.
Consultare Creare applicazioni per maggiori informazioni.
È possibile utilizzare Godot come libreria?
Se hai intenzione di creare un gioco con Godot, tieni presente che Godot è stato progettato per essere utilizzato con il suo editor. Ti consigliamo di provarlo, poiché a lungo termine ti farà sicuramente risparmiare tempo.
Per applicazioni più specializzate, ha senso considerare di usare Godot come una biblioteca. Dalla versione di Godot 4.6, è disponibile una funzionalità sperimentale che consente di utilizzare Godot come una biblioteca statica o dinamica, detta LibGodot. Ciò è attualmente supportato su Windows, MacOS e Linux. È previsto supporto per Android e iOS in una versione futura.
È possibile trovare esempi di applicazioni che utilizzano Godot come libreria nel repository su GitHub migeran/libgodot_project.
Quale toolkit di interfaccia utente usa Godot?
Godot non usa un toolkit standard di GUI come GTK, Qt o wxWidgets. Invece, usa il proprio toolkit di interfaccia utente, che è renderizzato sempre tramite accelerazione hardware. Non esiste un'alternativa integrata in software, ma è possibile usare soluzioni esterne che emulano le API grafiche sulla CPU.
Questo toolkit è esposto sotto forma di nodi Control, che sono usati per renderizzare l'editor (che è scritto in C++). Questi nodi Control si possono anche utilizzare nei progetti da qualsiasi linguaggio di scripting supportato da Godot.
Questo toolkit personalizzato permette di beneficiare dell'accelerazione hardware e di avere un aspetto coerente su tutte le piattaforme. Oltre a questo, non ha a che fare con le limitazioni della licenza LGPL che vengono con GTK o Qt. Infine, questo significa che Godot sta "mangiando il suo stesso cibo per cani" poiché l'editor stesso è uno degli utilizzatori più complessi del sistema UI di Godot.
Questo toolkit UI personalizzato può essere incorporato in altre applicazioni (sperimentale). Tuttavia, il modo consigliato per utilizzarlo è usare Godot per creare applicazioni non di gioco con l'editor.
Perché Godot utilizza il sistema di compilazione SCons?
Godot utilizza il sistema di build SCons. Non ci sono piani per passare a un sistema di build diverso nell'immediato futuro. Ci sono molte ragioni per cui abbiamo scelto SCons rispetto ad altre alternative. Ad esempio:
Godot può essere compilato per una dozzina di piattaforme diverse: tutte le piattaforme PC, tutte le piattaforme mobili, molte console e WebAssembly.
Gli sviluppatori spesso devono compilare per diverse piattaforme allo stesso tempo, o persino per obiettivi diversi della stessa piattaforma. Non possono permettersi di riconfigurare e ricostruire il progetto ogni volta. SCons può farlo senza problemi, senza compromettere le build.
SCons non rovinerà mai una build, a prescindere dal numero di modifiche, configurazioni, aggiunte, rimozioni ecc.
Il processo di compilazione di Godot non è semplice. Diversi file sono generati da codice (i binder), altri sono analizzati (gli shader) e altri ancora devono offrire personalizzazione (moduli). Ciò richiede una logica complessa, più facile da scrivere in un linguaggio di programmazione vero e proprio (come Python), piuttosto che in un linguaggio basato principalmente su macro pensato solo per la compilazione.
Il processo di compilazione di Godot fa ampio uso di strumenti di cross-compilazione. Ogni piattaforma ha un processo di rilevamento specifico, e tutti questi si devono gestire come casi specifici, con codice specifico scritto per ciascuno.
Si prega di mantenere una mentalità aperta e di familiarizzarsi almeno un po' con SCons se si ha intenzione di compilare Godot da soli.
Perché Godot non usa STL (Standard Template Library)?
Come molte altre librerie (Qt ne è un esempio), Godot non fa uso di STL (con qualche eccezione come threading primitive). Noi crediamo che STL sia una magnifica libreria per uso generico, ma noi abbiamo bisogno di requisiti particolari per Godot.
I modelli STL creano simboli molto grandi, il che si traduce in un enorme codice binario di debug. Utilizziamo invece alcuni modelli con nomi molto brevi.
La maggior parte dei nostri contenitori soddisfa esigenze particolari, come Vector, che utilizza la copia in scrittura e che usiamo per passare i dati, o il sistema RID, che richiede tempo di accesso O (1) per le prestazioni. Allo stesso modo, le nostre implementazioni di mappe hash, sono implementate per integrarsi perfettamente con i tipi di motori interni.
I nostri contenitori hanno un tracciamento della memoria integrato, che aiuta a monitorare meglio l'utilizzo della memoria.
Per array di grandi dimensioni, utilizziamo la memoria in pool, che può essere mappata su un buffer preallocato o su una memoria virtuale.
Utilizziamo il nostro tipo String personalizzato, in quanto quello fornito da STL è troppo elementare e manca di un adeguato supporto all'internazionalizzazione.
Dare un occhiata ai tipi contenitori di Godot per alternative.
Perché Godot non utilizza le eccezioni?
Noi crediamo che i giochi non debbano "crashare", qualunque cosa accada. Se si verifica una situazione inaspettata si verifica, Godot genererà e stamperà un errore (che può essere ricondotto anche allo script), ma poi cercherà di gestirlo nel modo più armonioso possibile e andare avanti.
Inoltre, le eccezioni aumentano considerevolmente le dimensioni del file eseguibile e risultano in tempi di compilazione più lunghi.
Godot utilizza un ECS (Sistema di componenti di entità)?
Godot non utilizza un ECS e si basa invece sull'ereditarietà. Sebbene non esista un approccio universalmente migliore, abbiamo considerato che l'utilizzo di un approccio basato sull'ereditarietà ha portato a una migliore usabilità, pur rimanendo rapido abbastanza per la maggior parte dei casi d'uso.
Detto questo, nulla impedisce di utilizzare la composizione nel proprio progetto, creando nodi figlio con script individuali. Questi nodi si possono quindi aggiungere e rimuovere in fase di esecuzione per aggiungere e rimuovere dinamicamente vari comportamenti.
Ulteriori informazioni sulle scelte progettuali di Godot si possono trovare in questo articolo.
Perché Godot non obbliga gli utenti a implementare il DoD (Data-Oriented Design)?
Mentre Godot internamente tenta di utilizzare il più possibile la coerenza della cache, riteniamo non sia necessario obbligare la maggior parte degli utenti a usare le pratiche DOD.
DOD, è principalmente un'ottimizzazione della coerenza della cache che può fornire miglioramenti significativi alle prestazioni solamente quando si ha a che fare con dozzine di migliaia di oggetti che vengono elaborati ogni frame con poche modifiche. In altre parole, se si spostano poche centinaia di sprite o nemici per frame, il DOD non migliorerà le prestazioni significativamente. In tal caso, è consigliato considerare un approccio diverso all'ottimizzazione.
La stragrande maggioranza dei giochi non ne ha bisogno e Godot fornisce pratici aiutanti per fare il lavoro per la maggior parte dei casi in cui lo fai.
Se un gioco ha davvero bisogno di elaborare una tale quantità di oggetti, la nostra raccomandazione è di usare C+++ e GDExtension per le operazioni che richiedono alte prestazioni e GDScript (o C#) per il resto del gioco.
Come posso supportare lo sviluppo o contribuire a Godot?
Consultare How to contribute.
Chi sta lavorando su Godot? Come posso contattarvi?
Vedi la pagina corrispondente sul sito web di Godot.