Domande frequenti

Cosa posso fare con Godot? Quanto costa? Quali sono le condizioni di licenza?

Godot è un software Libre/Open Source disponibile sotto la licenza MIT approvata dall’OSI

Ricapitolando:

  • Sei libero di scaricare e utilizzare Godot per qualsiasi scopo: personale, non-profit, commerciale o altro.
  • Sei libero di modificare e ridistribuire Godot secondo i tuoi gusti, per qualsiasi scopo, sia commerciali che non.

Tutti i contenuti della documentazione sono coperti dalla licenza permissiva Creative Commons Attribution 3.0 (CC-BY 3.0), con attribuzione a «Juan Linietsky, Ariel Manzur and the Godot Engine community»

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 maggiori dettagli, guarda i file COPYRIGHT.txt, LICENSE.txt e LOGO_LICENSE.txt nella repository di Godot.

Consultare anche “la pagina sulla licenza presente nel sito web di Godot <https://godotengine.org/license>`_.

Quali piattaforme sono supportate da Godot?

Per l’editor:

  • Windows
  • macOS
  • X11 (Linux, *BSD)

Per esportare i vostri giochi:

  • Windows (e UWP)
  • macOS
  • X11 (Linux, *BSD)
  • Android
  • iOS
  • Web

I binari a 32 e 64 bit sono entrambi supportati qualora abbia senso, con la versione a 64 bit di default.

Alcuni utenti hanno riportato di aver compilato e usato Godot con successo su sistemi ARM-based con Linux, come il Raspberry Pi.

Ci sono inoltre lavori fatti da terzi che permettono a Godot di funzionare su alcune console. Nulla di tutto questo però è incluso di default negli script di compilazione o nei template per l’export.

Per avere maggiori informazioni a questo riguardo, fare riferimento alle sezioni exporting.

Quali sono i linguaggi di programmazione supportati in Godot?

I linguaggi supportati ufficialmente per Godot sono GDScript, Visual Scripting, C# e C++. Vedere 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 ad 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. La nostra comunità di sviluppo amichevole e laboriosa è 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. La ricerca tra le discussioni sui problemi aperti <https://github.com/godotengine/godot/issues>`_ è un ottimo modo per iniziare la risoluzione dei problemi.

Per quanto riguarda le nuove lingue, il supporto è possibile tramite terze parti utilizzando i servizi GDNative / NativeScript / PluginScript. (Vedere domanda sui plugin qui sotto.) Attualmente sono in corso lavori, ad esempio, su binding non ufficiali per Godot e Python <https://github.com/touilleMan/godot-python>`_ e Nim.

Che cos’è il GDScript e perché dovrei usarlo?

GDScript è il linguaggio di script integrato di Godot. E” stato costruito da zero per massimizzare il potenziale di Godot nella minor quantità di codice, offrendo sia ai principianti che agli sviluppatori esperti di sfruttare al meglio i punti di forza di Godot. Se avete già scritto qualcosa in un linguaggio come Python allora vi sentirete subito a vostro agio. Per esempi, evoluzione e una panoramica completa delle capacità che GDScript offre, potete leggere GDScript scripting guide.

Ci sono diverse ragioni per usare GDScript, specialmente quando si sta prototipando, in stadi alfa/beta del progetto, o non si sta creando il prossimo titolo AAA, 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, riduceva la quantità di tempo necessaria per mettersi in funzione con Godot, dando agli sviluppatori un modo rapido di esporsi al motore con un focus sulla produttività; in secondo luogo, riduce l’onere complessivo della manutenzione, attenua la dimensione dei problemi, e permette agli sviluppatori del motore di concentrarsi sulla correzione dei bug e migliorare le funzionalità relative al motore, piuttosto che spendere molto tempo cercando di ottenere un piccolo insieme di nuove caratteristiche lavorando su un grande insieme di linguaggi.

Essendo Godot un progetto Open Source, era imperativo sin dall’inizio dare prioritá ad una esperienza il piú possibile integrata e fluida piuttosto che cercare di attirare piú utenti supportando i linguaggi di programmazione piú famosi, specialmente quando il supporto a tali linguaggi risulterebbe in un’esperienza peggiore. Capiamo se volete utilizzare un altro linguaggio in Godot (vedere la lista delle opzioni supportate sopra). Detto questo, se non avete ancora provato GDScript, provatelo per tre giorni. Esattamente come per Godot, una volta che avrete constatato quanto è potente, e quanto velocizza lo sviluppo, pensiamo che GDScript vi piacerá sempre di piú.

Ulteriori informazioni su come prendere mano con GDScript o altri linguaggi tipizzati dinamicamente possono essere trovate nel tutorial GDScript: An introduction to dynamic languages.

Perché creare GDScript?

All’inizio, il motore usava il linguaggio di scripting Lua. Lua è veloce, ma creare binding per un sistema orientato agli oggetti (usando i fallback) fu complicato e lento e ha richiesto una grande quantità di codice. Dopo aver sperimentato con Python, anch’esso si era dimostrato difficile da integrare.

Le ragioni principali per creare un linguaggio di scripting ideato per Godot sono state:

  1. Cattivo supporto ai thread nella maggior parte delle VM degli altri linguaggi, e Godot usa thread (Lua, Python, Squirrel, JS, AS, ecc.).
  2. Poor class-extending support in most script VMs, and adapting to the way Godot works is highly inefficient (Lua, Python, JavaScript).
  3. Molti linguaggi già esistenti hanno interfacce orribili per lavorare in C++, e ciò risulta in una quantità enorme di codice, bug, colli di bottiglia e inefficienze in generale (Lua, Python, Squirrel, JS, ecc.). Volevamo concentrarci nel fare un ottimo motore di gioco, non una grande quantità di integrazioni.
  4. No native vector types (vector3, matrix4, etc.), resulting in highly reduced performance when using custom types (Lua, Python, Squirrel, JavaScript, ActionScript, etc.).
  5. Il garbage collector produce rallentamenti o un uso della memoria inutilmente alto (Lua, Python, JavaScript, ActionScript, ecc.).
  6. Difficulty to integrate with the code editor for providing code completion, live editing, etc. (all of them). This is well-supported by GDScript.

GDScript was designed to curtail the issues above, and more.

Che tipi di formati per i modelli 3D supporta Godot?

Godot supporta Collada tramite l”OpenCollada <https://github.com/KhronosGroup/OpenCOLLADA/wiki/OpenCOLLADA-Tools>`_exporter (Maya, 3DSMax). Se stai usando Blender, dai un’occhiata al nostro `Better Collada Exporter.

A partire da Godot 3.0 é supportato il formato glTF.

FBX è supportato tramite l’Open Asset Import library. Tuttavia, FBX è proprietario, dacché raccomandiamo l’uso di altri formati elencati sopra, se adatti al vostro flusso di lavoro.

Sarà [inserire SDK proprietari come FMOD, Gameworks, ecc] supportato in Godot?

Godot ha l’obiettivo di creare una motore per videogiochi libero, open source, modulare ed estensibile. Non é previsto, da parte della comunitá di sviluppo del motore, il supporto per SDK di terze parti, a codice chiuso o proprietari in quanto integrarli andrebbe contro lo spirito di Godot.

Detto questo, essendo Godot open source e modulare, niente impedisce a te, o a chiunque altro sia interessato, di aggiungere queste librerie come moduli e rilasciare il tuo gioco usandole, sia come progetto open source che closed source.

Per vedere come possa essere fornito il supporto per il SDK scelto, vedere la domanda sui Plugins poco sotto.

Se conosci un SDK di terze parti che non é attualmente supportato da Godot ma che offre un’integrazione open source, puoi considerare di iniziare a lavorare sull’integrazione. Godot non é un progetto di proprietá di una persona, appartiene alla comunitá e cresce attraverso il lavoro di ambiziosi contributori come te.

Come dovrebbero essere create le risorse per gestire risoluzioni grafiche multiple e diversi formati di schermo?

Questa domanda viene posta spesso, probabilmente grazie ad un’incomprensione creata da Apple quando hanno duplicato la risoluzione dei propri device per la prima volta: è stato fatto credere alle persone che avere le proprie risorse in diverse risoluzioni fosse una buona idea e tanti hanno continuato su questa linea. Questa soluzione all’inizio funzionò, fino a un certo punto e solo per i devices di Apple, poi però vennero creati molti devices, sia Android che Apple, con una grande varietà 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 le differenti proporzioni dello schermo. Questo è sopratutto necessario per il 2D, poiché nel 3D è solo una questione di Camera XFov o YFov.

  1. Scegli una singola risoluzione di base per il tuo gioco. Anche se ci sono dispositivi che vanno fino a 2K e dispositivi che hanno solo 400p, il normale ridimensionamento attraverso l’hardware del tuo dispositivo si prenderà cura di ciò ad un costo pressoché impercettibile. Le scelte più comuni sono solitamente 1080p (1920x1080) oppure 720p (1280x720). Tieni a mente che all’aumentare della risoluzione, aumenteranno la dimensione dei tuoi asset, la memoria da loro richiesta e il tempo necessario per il caricamento.
  2. Utilizza le opzioni di adattamento in Godot; l’allungamento 2D con il mantenimento dell’aspetto dà i migliori risultati. Controlla il Multiple resolutions tutorial su come ottenere questo risultato.
  3. 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: Multiple resolutions .
  4. 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.

Ecco qui! Il tuo gioco dovrebbe funzionare su risoluzioni multiple.

Se davvero desideri che il tuo gioco funzioni anche su vecchi device con piccoli schermi (meno di 300 pixel in larghezza), puoi usare l’opzione di esportazione per ridurre la dimensione delle immagini, e impostarla per essere usata con schermi di determinate dimensioni nell” App Store o in Google Play.

Come posso estendere Godot?

Per estendere Godot, ad esempio creando plugin per Godot Editor o aggiungere supporto per ulteriori linguaggi, fai riferimento a EditorPlugins e ai tool script.

Vedere anche i post ufficiali sul blog su questi argomenti:

Puoi anche dare un’occhiata all’implementazione di GDScript, ai moduli di Godot e al supporto non ufficiale per Python per Godot. Questo é un buon punto di inizio per capire come librerie di terze parti si integrano in Godot.

Vorrei contribuire! Come posso iniziare?

Stupendo! Essendo un progetto open source, Godot prospera attraverso l’innovazione e l’ambizione di sviluppatori come te.

Il primo posto da cui iniziare é la sezione issues. Trova una issue che trovi particolarmente adatta a te, poi procedi alla guida Come Contribuire per imparare come fare fork, modifiche e inoltrare una Pull Request (PR) con le tue modifiche.

Ho una grande idea per Godot. Come posso condividerla?

It might be tempting to want to bring ideas to Godot, like ones that result in massive core changes, some sort of mimicry of what another game engine does, or alternative workflows that you’d like built into the editor. These are great, and we are thankful to have such motivated people want to contribute, but Godot’s focus is and always will be the core functionality as outlined in the Roadmap, squashing bugs and addressing issues, and conversations between Godot community members.

La maggior parte degli sviluppatori nella comunitá di Godot saranno più interessati ad apprendere cose tipo:

  • La tua esperienza nell’utilizzo del software ed i problemi che hai (ci preoccupiamo di questo molto di più che di nuove idee su come migliorarlo).
  • Le funzionalità che ti piacerebbe vedere implementate perchè ne hai bisogno per il tuo progetto.
  • I concetti che erano difficili da comprendere durante l’apprendimento del software.
  • Le parti del tuo processo di lavoro che vorresti vedere ottimizzate.
  • Le parti per le quali non riuscivi a trovare dei tutorial soddisfacenti o in cui la documentazione non era chiara.

Non credere che le tue idee per Godot non siano ben accette. Prova piuttosto a riformularle come problemi, per prima cosa, in modo che gli sviluppatori e la community abbiano delle fondamenta su cui basare le tue idee.

Un buon modo per iniziare a condividere le tue idee e problemi con la comunità è attraverso un insieme di situazioni di utilizzo. Spiega cosa stai cercando di fare, quale comportamento ti aspetti e quale comportamento hai effettivamente riscontrato. Inquadrare problemi e idee in questo modo aiuta l’intera comunità a concentrarsi sul migliorare l’esperienza degli sviluppatori in modo organico.

Meglio ancora se provvedi screenshot, numeri concreti, casi d’uso o progetti come esempio (se possibile).

Perchè Godot non usa STL (Standard Template Library)

Come molte altre librerie (Qt ne è un esempio), Godot non fa uso si STL. Noi crediamo che STL sia una magnifica libreria ad utilizzo generico, ma noi abbiamo bisogno di requisiti particolari per Godot.

  • I modelli STL creano simboli molto grandi, il che si traduce in enormi binari 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 si Stringa fatto su misura, in quanto quello fornito da STL è troppo elementare e manca di un adeguato supporto all’internazionalizzazione.

Perchè Godot non utilizza 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 significativamente le dimensioni del file binario per l’eseguibile.

Perché Godot non applica il RTTI?

Godot fornisce il proprio sistema di casting del tipo, che può facoltativamente utilizzare il RTTI internamente. Disabilitare RTTI in Godot, significa che è possibile ottenere dimensioni binarie considerevolmente più piccole, con un costo di prestazioni ridotto.

Perché Godot non obbliga gli utenti ad implementare il DoD (Data Oriented Design)?

While Godot internally for a lot of the heavy performance tasks attempts to use cache coherency as well as possible, we believe most users don’t really need to be forced to use DoD practices.

DoD, è principalmente un’ottimizzazione della coerenza della cache che può ottenere significativi miglioramenti delle prestazioni quando si ha a che fare con dozzine di migliaia di oggetti (che vengono elaborati ogni fotogramma con poche modifiche). Se stai spostando alcune centinaia di sprite o nemici per frame, il DoD non ti aiuterà e dovresti 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 GDNative per le parti che richiedono alte prestazioni e GDScript (o C#) per il resto del gioco.

Come posso supportare lo sviluppo di Godot o contribuire?

Dai un’occhiata a Ways to contribute.

Chi lavora a Godot? Come posso contattarti?

Visita la pagina corrispondente sul sito di Godot.