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

In breve:

  • 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 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 <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 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. 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. 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. Nessun tipo nativo per i vettori (vector3, matrix4, ecc.), che risulta in prestazioni ridotte quando si usano tipi personalizzati (Lua, Python, Squirrel, JavaScript, ActionScript, ecc.).

  5. Il garbage collector produce rallentamenti o un uso della memoria inutilmente alto (Lua, Python, JavaScript, ActionScript, ecc.).

  6. Difficoltà nell'integrazione con l'editor di codice per fornire l'auto-completamento del codice, 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 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.

Perché Godot usa Vulkan o OpenGL invece di Direct3D?

Godot mira innanzitutto alla compatibilità multipiattaforma e agli standard aperti. OpenGL e Vulkan sono le tecnologie aperte e disponibili su (quasi) tutte le piattaforme. Grazie a questa decisione progettuale, un progetto sviluppato con Godot su Windows verrà eseguito immediatamente su Linux, macOS e altro.

Poiché Godot ha solo poche persone che lavorano sul suo renderer, preferiremmo avere meno backend di rendering da mantenere. Inoltre, l'utilizzo di una singola API su tutte le piattaforme permette maggiore consistenza e meno problemi riguardanti una piattaforma specifica.

Nel lungo termine, potremmo sviluppare un renderer Direct3D 12 per Godot (principalmente per Xbox), ma Vulkan e OpenGL rimarranno i backend di rendering predefiniti su tutte le piattaforme, incluso Windows.

Why does Godot aim to keep its core feature set small?

Godot intentionally does not include features that can be implemented by add-ons unless they are used very often. One exemple of this would be advanced artificial intelligence functionality.

There are several reasons for this:

  • Code maintenance and surface for bugs. Every time we accept new code in the Godot repository, existing contributors often take the reponsibility of maintaining it. Some contributors don't always stick around after getting their code merged, which can make it difficult for us to maintain the code in question. This can lead to poorly maintained features with bugs that are never fixed. On top of that, the "API surface" that needs to be tested and checked for regressions keeps increasing over time.

  • Ease of contribution. By keeping the codebase small and tidy, it can remain fast and easy to compile from source. This makes it easier for new contributors to get started with Godot, without requiring them to purchase high-end hardware.

  • Keeping the binary size small for the editor. Not everyone has a fast Internet connection. Ensuring that everyone can download the Godot editor, extract it and run it in less than 5 minutes makes Godot more accessible to developers in all countries.

  • Keeping the binary size small for export templates. This directly impacts the size of projects exported with Godot. On mobile and web platforms, keeping file sizes low is primordial to ensure fast installation and loading on underpowered devices. Again, there are many countries where high-speed Internet is not readily available. To add to this, strict data usage caps are often in effect in those countries.

For all the reasons above, we have to be selective of what we can accept as core functionality in Godot. This is why we are aiming to move some core functionality to officially supported add-ons in future versions of Godot. In terms of binary size, this also has the advance of making you pay only for what you actually use in your project. (In the meantime, you can compile custom export templates with unused features disabled to optimize the distribution size of your project.)

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

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.

Quando uscirà la prossima versione di Godot?

Quando è pronta! Vedi Quando uscirà la prossima versione? per maggiori informazioni.

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 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 radicali 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 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).

È possibile utilizzare Godot come libreria?

Godot è pensato per essere usato con il suo editor. Ti consigliamo di provarlo, perché molto probabilmente ti farà risparmiare tempo a lungo termine. Non ci sono piani per rendere Godot utilizzabile come libreria, in quanto renderebbe il resto del motore più contorto e difficile da usare per gli utenti occasionali.

Se si desidera utilizzare una libreria di rendering, considera invece l'utilizzo di un motore di rendering stabilito. Tieni presente che i motori di rendering di solito hanno comunità più piccole rispetto a quella di Godot. Ciò renderà più difficile trovare le risposte alle tue domande.

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, per molte delle attività che richiedono un alto carico prestazionale, internamente tenta di utilizzare la coerenza della cache nel miglior modo possibile, riteniamo che la maggior parte degli utenti non debbano essere costretti 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?

Vedi Ways to contribute.

Chi lavora a Godot? Come posso contattarti?

Visita la pagina corrispondente sul sito di Godot.