Usein kysytyt kysymykset

Mitä voin tehdä Godotilla? Paljonko se maksaa? Millaiset lisenssiehdot ovat?

Godot on vapaa ja avoimen lähdekoodin ohjelmisto OSI-hyväksytyn MIT-lisenssin alaisuudessa. Tämä tarkoittaa, että se vapaa kuin "sananvapaus" ja ilmainen kuin "ilmainen olut."

Lyhyesti:

  • Olet vapaa lataamaan ja käyttämään Godotia mihin tahansa tarkoitukseen; henkilökohtaiseen, yleishyödylliseen, kaupalliseen tai muuhun.
  • Voit muokata, jakaa, levittää eteenpäin ja uudelleenyhdistellä Godotia sydämesi kyllyydestä, mistä tahansa syystä, sekä ei-kaupallisesti että kaupallisesti.

Kaikki tämän mukana tulevan dokumentaation sisältö on julkaistu sallivan Creative Commons Attribution 3.0 (CC-BY 3.0) lisenssin alla, liitteellä "Juan Linietsky, Ariel Manzur and the Godot Engine community."

Logot ja ikonit kuuluvat pääasiassa saman Creative Commons -lisenssin alle. Ota huomioon, että jotkin Godotin sisällyttämät kolmansien osapuolten lähdekoodit voivat kuulua toisentyyppisiin lisensseihin.

Täysiä yksityiskohtia varten, katso COPYRIGHT.txt sekä LICENSE.txt ja LOGO_LICENSE.txt tiedostoja Godotin koodikannassa.

Katso myös Godotin lisenssi-sivu.

Mitä laitealustoja Godot tukee?

Editorissa:

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

Pelien viennissä

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

Sekä 32-bittinen että 64-bittinen ovat tuettuja silloin, kun siinä on mieltä, 64-bittinen on oletus.

Jotkut käyttäjät ovat raportoineet kääntäneensä ja käyttäneensä Godotia onnistuneesti Linuxissa ARM-pohjaisilla järjestelmillä, kuten Raspberry Pi:llä.

Konsoleille on lisäksi tekeillä joitakin kolmannen osapuolen epävirallisia käännöksiä. Mikään tästä ei kuitenkaan toistaiseksi sisälly mukana tuleviin käännösskripteihin tai vientimalleihin.

Lisää tästä aiheesta vienti ja Godotin itse kääntö -osioissa.

Mitkä ohjelmointikielet ovat tuettuina Godotissa?

Godotin virallisesti tukemia kieliä ovat GDScript, Visual Scripting, C# ja C++. Katso jokaisen kielen alakategoria skriptaus luvusta.

Jos olet vasta aloittelemassa joko Godotin käyttöä tai pelikehitystä yleisesti, on suositeltua opetella ja käyttää GDScript-kieltä, sillä se on Godotin natiivikieli. Vaikka skriptikielet tahtovat olla pitkässä juoksussa suorituskyvyltään heikompia kuin matalan tason kielet, prototyypitykseen, Minimum Viable Product (MVP) kehitykseen ja Time-To-Market (TTM) fokusoitumiseen GDScript tarjoaa nopean, ystävällisen ja kyvykkään tavan kehittää pelejäsi.

Huomioi, että C# tuki on vielä suhteellisen uusi ja sellaisenaan saatat törmätä matkan varrella joihinkin ongelmiin. Ystävällinen ja ahkera kehitysyhteisömme on aina valmis taklaamaan uudet ongelmat sitä myötä, kun niitä ilmaantuu, mutta koska tämä on avoimen lähdekoodin projekti, suosittelemme, että teet itse ensin hieman pohjatyötä. Avoimet ongelmat -keskusteluiden läpikäynti on hyvä tapa aloittaa vianetsintä.

Uusille kielille tuki on mahdollista saada kolmansien osapuolien avulla, käyttäen GDNative / NativeScript / PluginScript suomia mahdollisuuksia. (Katso kysymys liitännäisistä alla.) Työn alla ovat esimerkiksi epäviralliset Python ja Nim liitteet Godotille.

Mikä on GDScript ja miksi minun pitäisi käyttää sitä?

GDScript on Godotin integroitu skriptikieli. Se rakennettiin perustuksista lähtien maksimoimaan Godotin mahdollisuuksia pienimpään mahdolliseen koodimäärään, antaen sekä aloittelevien että asiantuntevien kehittäjien hyödyntää Godotin vahvuuksia niin nopeasti kuin mahdollista. Jos olet koskaan aiemmin kirjoittanut mitään Pythonin kaltaisilla kielillä, tunnet olevasi kuin kotona. Nähdäksesi esimerkkejä, historiaa ja täyden katsauksen GDScriptin tarjoamaan tehoon, vilkaise :ref:`GDScript skriptausopasta <doc_gdscript>`_.

On useita syitä käyttää GDScriptiä – varsinkin, jos olet kehittämässä prototyyppiä, projektisi alfa/beta-vaiheessa, tai et ole kehittämässä seuraavaa AAA-peliä – mutta kaikkein keskeisin syy ylipäätään on monimutkaisuuden väheneminen.

Alkuperäinen tarkoitus tiukasti integroidun räätälöidyn skriptikielen luonnilla Godotiin oli kaksitahoinen. Ensiksi, se vähentää Godotin aloittamiseen ja sen kanssa liikkeellepääsyyn tarvittavaa aikaa, antaen kehittäjille nopean tien tutustua pelimoottoriin ja keskittyä tuottavuuteen. Toiseksi, se vähentää ylläpidon taakkaa, vähentää ongelmien ulottuuvuutta, ja sallii pelimoottorin kehittäjien keskittyä bugien liiskaukseen ja moottorin ytimeen liittyvien ominaisuuksien parantamiseen – sen sijaan, että paljon aikaa kulutettaisiin siihen, että yritetään saada pieni joukko lisäominaisuuksia toimimaan suurelle joukolle ohjelmointikieliä.

Koska Godot on avoimen lähdekoodin projekti, oli alusta saakka välttämätöntä keskittyä parempaan integraatioon ja saumattomaan kokemukseen, sen sijaan että houkuteltaisiin enemmän käyttäjiä tukemalla tuttuja ohjelmointikieliä – etenkin kun näiden tutumpien kielien tukeminen olisi johtanut huonompaan kokemukseen. Ymmärrämme jos mieluummin käyttäisit toista kieltä Godotissa (katso luettelo tuetuista vaihtoehdoista yllä). Siltikin, jos et ole vielä kokeillut GDScriptiä, kokeile sitä kolme päivää. Aivan kuten Godotin kanssa, kun huomaat miten tehokas se on ja kuinka nopeaa kehittämisestäsi tulee, luulemme että GDScript kasvaa osaksi sinua.

Lisää tietoa GDScriptiin tai dynaamisesti tyypitettyihin kieliin tutustumista varten löydät GDScript: An introduction to dynamic languages oppaasta.

Mitkä olivat vaikuttimet GDScriptin luomiselle?

Alkuun pelimoottori käytti Lua <https://www.lua.org> skripti kieltä. Lua on nopea, mutta liitoksien luominen objekti orientoidussa kielessä (fallback menetelmällä) oli hankalaa ja hidasta ja tarvitsi todella paljon koodia. Joidenkin kokeiden Python <https://www.python.org> kanssa, se osoittautui myös hankalaksi toteuttaa.

Tärkeimmät syyt oman skriptikielen luomiselle Godotiin olivat:

  1. Useimmissa skriptivirtuaalikoneissa ei ole hyvää säikeistystukea ja Godot käyttää säikeitä (Lua, Python, Squirrel, JS, AS, jne.).
  2. Poor class-extending support in most script VMs, and adapting to the way Godot works is highly inefficient (Lua, Python, JavaScript).
  3. Many existing languages have horrible interfaces for binding to C++, resulting in large amount of code, bugs, bottlenecks, and general inefficiency (Lua, Python, Squirrel, JavaScript, etc.) We wanted to focus on a great engine, not a great amount of integrations.
  4. No native vector types (vector3, matrix4, etc.), resulting in highly reduced performance when using custom types (Lua, Python, Squirrel, JavaScript, ActionScript, etc.).
  5. Garbage collector results in stalls or unnecessarily large memory usage (Lua, Python, JavaScript, ActionScript, etc.).
  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.

Minkätyyppisiä 3D-mallien tallennusmuotoja Godot tukee?

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

glTF on tuettu Godotin versiosta 3.0 lähtien.

FBX on tuettu Open Asset Import libraryn kautta. Huomiotavaa, FBX on yksityisomistuksellinen joten suosittelemme käyttämään muita tuettuja formaatteja, jos se sopii sinun työnkulkuun.

Tuleeko [lisää tähän suljettu SDK kuten FMOD, GameWorks, tms.] olemaan tuettu Godotissa?

Godotin tavoitteena on luoda vapaa ja avoimen lähdekoodin MIT-lisenssoitu pelimoottori, joka on modulaarinen ja laajennettava. Pelimoottorin ydinkehitysyhteisöllä ei ole aikomuksia tukea mitään kolmannen osapuolen suljetun/omisteisen lähdekoodin SDK:ta, sillä sellaiseen integroituminen olisi Godotin eetoksen vastaista.

Siitä huolimatta, koska Godot on avointa lähdekoodia ja modulaarinen, mikään ei estä sinua tai ketään kiinnostunutta lisäämään noita kirjastoja moduulina ja julkaisemaan peliäsi niitä käyttäen, joko avoimena tai suljettuna lähdekoodina.

Nähdäksesi kuinka haluamallesi SDK:lle voidaan lisätä tuki, katso Liitännäiset kysymystä yllä.

Jos tiedät kolmannen osapuolen SDK:n, joka ei ole tuettu Godotissa, mutta joka tarjoaa vapaan ja avoimen lähdekoodin integraation, harkitse integraatiotyön aloittamista itse. Godot ei ole yhden henkilön omistama; se kuuluu yhteisölle ja kasvaa kaltaistesi kunnianhimoisten edistäjien toimesta.

Kuinka assetit pitäisi luoda ottaen huomioon useat näyttötarkkuudet ja kuvasuhteet?

Tämä kysymys pulpahtaa esiin usein ja siitä käy luultavasti kiittäminen Applen luoman väärinkäsityksen, kun he alun perin tuplasivat laitteidensa näyttötarkkuuden. Se sai ihmiset ajattelemaan, että samojen assettien käyttäminen eri näyttötarkkuuksilla oli hyvä idea, joten moni jatkoi sillä polulla. Se toimin alun perin tiettyyn pisteeseen saakka ja vain Applen laitteilla, mutta sen jälkeen on luotu monta Android- ja Apple-laitetta eri näyttötarkkuuksilla ja kuvasuhteila, hyvin laajalla joukolla eri kokoja ja kuvapistetiheyksiä.

Kaikkein yleisin ja oikein tapa saavuttaa tämä on sen sijaan käyttää yhtä pohjanäyttötarkkuutta pelille ja käsitellä vain eri kuvasuhteet. Tätä tarvitaan lähinnä 2D:lle, koska 3D:ssä on kyse vain kameran XFov tai YFov arvoista.

  1. Valitse pelillesi yksi pohjaresoluutio. Vaikka onkin olemassa laitteita, jotka yltävät 2K tarkkuuteen, ja laitteita, joilla on niinkin alhainen tarkkuus kuin 400p, laitteesi tavallinen laiteistoskaalaus hoitaa tämän pienellä tai olemattomalla suorituskykykustannuksella. Yleisimmät valinnat ovat lähellä 1080p (1920x1080) ja 720p (1280x720) tarkkuuksia. Pidä mielessä, että mitä suurempi näyttötarkkuus, sitä suuremmat ovat assettisi, ja sitä enemmän muistia ne vievät sekä sitä kauemmin niiden lataus kestää.
  2. Käytä Godotin venytysvalintoja; 2D-venytys kuvasuhde säilyttäen toimii parhaiten. Tarkista Multiple resolutions oppaasta kuinka tämä saadaan aikaan.
  3. Määritä pienin näyttötarkkuus ja päätä sitten haluatko pelisi venyvän pysty- vai vaakasuunnassa eri kuvasuhteille, vai onko sen sijaan olemassa yksi kuvasuhde ja haluat mustien reunusten ilmestyvän. Tämä on selitetty myös osiossa Multiple resolutions.
  4. Käyttöliittymiä varten käytä ankkurointia määrittääksesi missä kontrollien pitäisi sijaita ja minne niiden pitäisi siirtyä. Jos käyttöliittymät ovat monimutkaisempia, harkitse Container-rakenteiden opettelua.

Ja siinä se! Pelisi pitäisi toimia useilla eri näyttötarkkuuksilla.

Jos on tarvetta saada pelisi toimimaan myös muinaisilla laitteilla ja niiden pikkuruisilla näytöillä (vähemmän kuin 300 pikseliä leveitä), voit käyttää vientivalintoja kuvien kutistamiseen ja asettaa tuon kyseisen käännöksen käytettäväksi tietyillä näyttöko'oilla App Store tai Google Play -kaupoissa.

Miten voin laajentaa Godotia?

Godotin laajentamiseksi, kuten Godot Editorin liitännäisten luomiseksi tai ylimääräisen kielen tuen lisäämiseksi, katso EditorPlugins ja työkaluskriptejä.

Katso myös viralliset blogikirjoitelmat liittyen näihin aiheisiin:

Voit myös vilkaista GDScriptin toteutusta, Godot moduuleja sekä myös epävirallista Python-tukea Godotille. Näistä lähtökohdista saat hyvin selville, miten jokin toinen kolmannen osapuolen kirjasto on integroitu Godotiin.

Haluan auttaa! Kuinka pääsen alkuun?

Mahtavaa! Avoimen lähdekoodin projektina Godot kukoistaa kaltaistesi kunnianhimoisten ja innovoivien kehittäjien ansiosta.

Ensimmäinen paikka, josta aloittaa on ongelmat. Etsi ongelma, joka herättää sinussa vastakaikua, ja etene sitten How to Contribute oppaaseen oppiaksesi kuinka haaroitat, muokkaat ja lähetät Pull Requestin (PR) muutoksistasi.

Minulla on loistava idea Godotiin. Kuinka voin jakaa sen?

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.

Useimmat kehittäjät Godotin yhteisössä ovat kiinnostuneempia oppimaan sellaisista asioista kuten:

  • Kokemuksista ohjelmiston käyttämisessä ja millaisiin ongelmiin olet törmännyt (välitämme tästä paljon enemmän kuin ideoista kuinka parantaa sitä).
  • Ominaisuuksista, joita haluaisit nähdä toteutettavan, koska tarvitset niitä projektissasi.
  • Käsitteistä, jotka oli vaikea ymmärtää opetellessasi ohjelmiston käyttöä.
  • Työnkulun osista, joita haluaisit nähdä tehostettavan.
  • Osista, joista et löytänyt selkeää opasta tai joissa dokumentaatio ei ollut selvä.

Älä suinkaan ajattele, että ideasi Godotiin eivät ole tervetulleita. Sen sijaan, yritä muotoilla ne ensin uudestaan ongelman muotoon, jolloin kehittäjillä ja yhteisöillä on käytännöllinen perusta johon pohjustaa ideasi.

Hyvä tapa lähestyä ideoittesi ja ongelmiesi jakamista yhteisön kanssa, on sarja käyttäjätarinoita. Selosta mitä yrität tehdä, mitä toimintaa odotat tapahtuvan ja mitä toimintaa oikeastaan tapahtui. Ongelmien ja ideoiden asettaminen tähän tapaan auttaa koko yhteisöä pysymään keskittyneenä parantamaan pelikehittäjien kokemuksia kokonaisuutena.

Bonuspisteitä kuvakaappauksien, kouriintuntuvien lukujen, testitapausten ja esimerkkiprojektien toimittamisesta (jos mahdollista).

Is it possible to use Godot as a library?

Godot is meant to be used with its editor. We recommend you give it a try, as it will most likely save you time in the long term. There are no plans to make Godot usable as a library, as it would make the rest of the engine more convoluted and difficult to use for casual users.

If you want to use a rendering library, look into using an established rendering engine instead. Keep in mind rendering engines usually have smaller communities compared to Godot. This will make it more difficult to find answers to your questions.

Miksi Godot ei käytä STL:ää (Standard Template Library)

Kuten monet muut kirjastot (esimerkiksi Qt), Godot ei käytä STL-kirjastoa. Uskomme, että STL on hyvä yleiskäyttöinen kirjasto, mutta meillä oli erikoisvaatimuksia Godotille.

  • STL-templatet aiheuttavat hyvin suuria symboleja, jotka johtavat valtaviin debug-binääreihin. Me käytämme sen sijaan vain muutamia templateja erittäin lyhyillä nimillä.
  • Suurin osa konteistamme soveltuu erikoistarpeisiin, kuten Vector, joka kopioi datan ennen kirjoitusta (copy on write) ja kun siirrämme dataa paikasta toiseen, tai RID systeemi, joka varaa O(1) käyttöajan suoritusta varten. Kuin myös meidän hash map-toteutus on suunniteltu toimimaan saumattomasti pelimoottorin sisäisten tyypitysten kanssa.
  • Our containers have memory tracking built-in, which helps better track memory usage.
  • For large arrays, we use pooled memory, which can be mapped to either a preallocated buffer or virtual memory.
  • We use our custom String type, as the one provided by STL is too basic and lacks proper internationalization support.

Miksei Godot käytä poikkeuksia?

Me uskomme että pelien ei pidä kaatua, vaikka olisi mikä. Jos odottamaton tilanne tapahtuu, Godot tulostaa virheen (mikä voidaan seurata jopa skriptiin asti), mutta sen jälkeen yrittää toipua mahdollisimman sievästi ja jatkaa toimintaa.

Lisäksi, poikkeukset lisäävät huomattavasti binäärin kokoa suoritettavassa ohjelmassa.

Miksi Godot ei pakota RTTItä?

Godot provides its own type-casting system, which can optionally use RTTI internally. Disabling RTTI in Godot means considerably smaller binary sizes can be achieved, at a little performance cost.

Why does Godot not force users to implement 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 is mostly a cache coherency optimization that can only gain you significant performance improvements when dealing with dozens of thousands of objects (which are processed every frame with little modification). As in, if you are moving a few hundred sprites or enemies per frame, DoD won't help you, and you should consider a different approach to optimization.

The vast majority of games do not need this and Godot provides handy helpers to do the job for most cases when you do.

If a game that really needs to process such large amount of objects is needed, our recommendation is to use C++ and GDNative for the high performance parts and GDScript (or C#) for the rest of the game.

Miten voin tukea Godotin kehitystä tai olla avuksi?

Katso Ways to contribute.

Kuka työstää Godotia? Kuinka voin olla yhteydessä?

Katso aiheesta kertovaa sivua Godotin verkkosivustolla.