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?

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. 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).
  3. L’interfaccia per il binding con C++ è orrible, e 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 su una grande quantità di integrazioni.
  4. Nessun tipo nativo per vettori (vector3, matrix4, ecc.), che risulta in performance ridotte quando si usano tipi personalizzati (Lua, Python, Squirrel, JS, AS, ecc.).
  5. Il garbage collector produce blocchi o un uso della memoria inutilmente alto (Lua, Python, JS, AS, ecc.).
  6. Difficoltà nell’integrazione con il codice dell’editor per fornire code completion, live editing e tutte le altre funzionalità. GDScript ha un ottimo supporto per questo.

GDScript è stato progettato per ridurre i problemi di cui sopra e altri ancora.

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

Godot supports Collada via the OpenCollada exporter (Maya, 3DSMax). If you are using Blender, take a look at our own Better Collada Exporter.

A partire da Godot 3.0 é supportato il formato glTF.

FBX is supported via the Open Asset Import library. However, FBX is proprietary so we recommend using other formats listed above, if suitable for your workflow.

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?

Potrebbe essere una grande tentazione portare nuove idee in Godot, per esempio alcune che potrebbero risultare in grossi cambiamenti nelle funzionalitá di base del motore, replicare funzionalitá di altri motori, o aggiungere workflow alternativi che vorresti avere nell’editor. Questo é fantastico e siamo grati di avere persone motivate che abbiano voglia di contribuire, ma l’attenzione maggiore del team di sviluppo di Godot é e sará sempre rivolta alle funzionalitá di base come delineato nella Roadmap, risolvere bug e altri problemi, e la conversazione con tra i membri della comunitá di Godot.

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)?

Mentre Godot internamente per molte delle pesanti attività legate alle prestazioni, tenta di utilizzare la coerenza della cache nel miglior modo possibile, riteniamo che la maggior parte degli utenti non debba essere costretta ad usare le pratiche DoD.

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.