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:

  • Voit ladata ja käyttää Godotia vapaasti 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)

  • Web

  • Android (experimental)

Pelien viennissä

  • Windows (ja UWP)

  • macOS

  • X11 (Linux, *BSD)

  • Android

  • iOS

  • Web

Sekä 32- että 64-bittisiä binääritiedostoja tuetaan jos se on järkevää, oletuksena on käytössä 64-bittinen versio.

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 peliohjelmointia 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. Useimmissa skriptivirtuaalikoneissa ei ole hyvää luokkien laajennustukea, josta johtuen Godotin toimintatapaan mukautuminen on hyvin tehotonta (Lua, Python, JS).

  3. Useilla olemassa olevilla kielillä on kaamea rajapinta C++ liitäntää varten, mikä johtaa suureen määrään koodia, bugeja, pullonkauloja ja yleistä tehottomuutta (Lua, Python, Squirrel, JavaScript, jne.) Halusimme keskittyä mahtavaan pelimoottoriin, emme suureen määrään integraatioita.

  4. Natiivien vektorityyppien puute (vector3, matrix4, jne.), joka johtaa hyvin alhaiseen suorituskykyyn räätälöityjä tyyppejä käyttäessä (Lua, Python, Squirrel, JS, AS, jne).

  5. Roskienkeruu aiheuttaa pysähdyksiä tai tarpeettoman suurta muistinkulutusta (Lua, Python, JavaScript, ActionScript, jne.).

  6. Hankaluudet yhdistää koodieditoriin niin, että voitaisiin tarjota koodin täydennys, ajonaikainen editointi, jne. Kaikki tämä on hyvin tuettuna GDScriptissä.

GDScript suunniteltiin vähentämään sekä yllä mainittuja, että muitakin ongelmia.

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

Godotissa on siitä huolimatta hyvä Collada-formaatin tuki. Ole hyvä ja käytä OpenCollada vientityökalua täyden yhteensopivuuden saavuttamiseksi, jos käytät Maya tai 3DS Max -työkaluja. Jos käytät Blenderiä, vilkaise omaa Better Collada Exporter vientityökaluamme.

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.

How do I install the Godot editor on my system (for desktop integration)?

Since you don't need to actually install Godot on your system to run it, this means desktop integration is not performed automatically. There are two ways to overcome this. You can install Godot from Steam (all platforms), Scoop (Windows), Homebrew (macOS) or Flathub (Linux). This will automatically perform the required steps for desktop integration.

Alternatively, you can manually perform the steps that an installer would do for you:

Windows

  • Move the Godot executable to a stable location (i.e. outside of your Downloads folder), so you don't accidentally move it and break the shortcut in the future.

  • Right-click the Godot executable and choose Create Shortcut.

  • Move the created shortcut to %LOCALAPPDATA%\Microsoft\Windows\Start Menu\Programs. This is the user-wide location for shortcuts that will appear in the Start menu. You can also pin Godot in the task bar by right-clicking the executable and choosing Pin to Task Bar.

macOS

Drag the extracted Godot application to /Applications/Godot.app, then drag it to the Dock if desired. Spotlight will be able to find Godot as long as it's in /Applications or ~/Applications.

Linux

  • Move the Godot binary to a stable location (i.e. outside of your Downloads folder), so you don't accidentally move it and break the shortcut in the future.

  • Rename and move the Godot binary to a location present in your PATH environment variable. This is typically /usr/local/bin/godot or /usr/bin/godot. Doing this requires administrator privileges, but this also allows you to run the Godot editor from a terminal by entering godot.

    • If you cannot move the Godot editor binary to a protected location, you can keep the binary somewhere in your home directory, and modify the Path= line in the .desktop file linked below to contain the full absolute path to the Godot binary.

  • Save this .desktop file to $HOME/.local/share/applications/. If you have administrator privileges, you can also save the .desktop file to /usr/local/share/applications to make the shortcut available for all users.

Is the Godot editor a portable application?

In its default configuration, Godot is semi-portable. Its executable can run from any location (including non-writable locations) and never requires administrator privileges.

However, configuration files will be written to the user-wide configuration or data directory. This is usually a good approach, but this means configuration files will not carry across machines if you copy the folder containing the Godot executable. See File paths in Godot projects for more information.

If true portable operation is desired (e.g. for use on an USB stick), follow the steps in Self-contained mode.

Miksi Godot käyttää Vulkania tai OpenGL:ää Direct3d:n sijasta?

Godot pyrkii ennen kaikkea eri alustojen väliseen yhteensopivuuteen ja avoimiin standardeihin. OpenGL ja Vulkan ovat tekniikoita, jotka ovat sekä avoimia että saatavilla (lähes) kaikilla alustoilla. Tämän suunnittelupäätöksen ansiosta Godotilla Windowsissa kehitetty projekti toimii Linuxissa, macOS:ssa ja muilla alustoilla.

Koska Godotilla on vain muutama henkilö kehittämässä sen renderöijää, suosisimme että meillä olisi vähemmän renderöinti backendejä ylläpidettävänä. Sen lisäksi, yhden API:n käyttäminen kaikilla alustoilla mahdollistaa paremman johdonmukaisuuden vähemmillä alustakohtaisilla ongelmilla.

Pitkällä aikavälilla saatamme kehittää Direct3D 12 -renderöijän Godotille (pääasiassa Xboxia varten), mutta Vulkan ja OpenGL pysyvät oletus renderöinti tekniikkana kaikille alustoille, mukaanlukien Windows.

Miksi Godot pyrkii pitämään ydintoimintojen kokoelman pienenä?

Godotista on jätetty tarkoituksella pois ominaisuudet, joita voidaan toteuttaa lisäosilla, ellei niitä tarvita hyvin usein. Esimerkkinä edistyneemmät tekoälyominaisuudet.

Tähän on useita syitä:

  • Koodin ylläpitäminen ja virheiden mahdollisuus. Joka kerta kun hyväksymme uutta koodia Godotiin, kehittäjät ottavat vastuun myös sen ylläpitämisestä. Jotkin osallistujat eivät jää projektiin sen jälkeen, kun heidän koodinsa on lisätty, joka voi tehdä vaikeaksi tuon koodin ylläpitämisen. Seurauksena voi olla heitteille jätettyjä ominaisuuksia ja ongelmia, joita ei koskaan korjata. Sen lisäksi rajapinta kasvaa koko ajan, ja siihen liittyvät tarkistukset lisääntyvät vastaavasti.

  • Osallistumisen helppous. Koska koodi on pieni ja siisti, sen kääntäminen on helppoa ja nopeaa. Tämän vuoksi uusien osallistujien on helppo alkaa kehittämään Godotia ilman kallista laitteistoa.

  • Editorin tiedostokoon pitäminen pienenä. Kaikilla ei ole nopeaa Internet-yhteyttä. Godotin lataaminen ja käyttäminen alle viidessä minuutissa tekee siitä helpommin saatavamman kehittäjille ympäri maailmaa.

  • Vientimallien pitäminen pienenä. Tämä vaikuttaa suoraan Godotilla tehtyjen sovellusten kokoon. Mobiililaitteilla ja selainalustoilla tiedostojen pitäminen pienenä on ensisijaisen tärkeää, että ne latautuu ja asentuu myös heikkotehoisemmilla laitteilla. On myös monia maita, joissa nopeat Internet-yhteydet eivät ole kaikkien saatavilla, tai niissä on tiukkoja datan käyttörajoituksia.

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

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.

Milloin Godotin seuraava versio julkaistaan?

Kun se on valmis! Katso lisätietoja: When is the next release out?.

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 muutospyynnön (PR) muutoksistasi.

Minulla on loistava idea Godotiin. Kuinka voin jakaa sen?

Saattaa olla houkuttelevaa haluta tuoda Godotiin ideoita, kuten sellaisia, jotka johtavat massiivisiin ydinmuutoksiin, jonkinlaiseen jäljittelyyn toisen pelimoottorin toiminnasta tai vaihtoehtoisiin työnkulkuihin, jotka haluaisit sisällyttää muokkaimeen. Nämä ovat hienoja ideoita ja olemme kiitollisia siitä, että näin motivoituneet ihmiset haluavat osallistua, mutta Godot keskittyy ja tulee aina keskittymään ydintoimintoihin, jotka on hahmoteltu etenemissuunnitelmassa <https://github.com/godotengine/godot-roadmap/blob/master/ROADMAP.md>, vikojen korjaamiseen ja ongelmien ratkaisemiseen <https://github.com/godotengine/godot/issues> ja Godot-yhteisön jäsenten välisiin keskusteluihin.

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

Onko Godotia mahdollista käyttää hyötysovellusten tekoon?

Kyllä! Godotissa on sisäänrakennettuna laaja käyttöliittymäjärjestelmä, ja sen pieni tiedostokoko tekee siitä varteenotettavan vaihtoehdon muille ympäristöille, kuten Electron tai Qt.

Kun teet muuta kuin peliä, käytä projektin asetusta low-processor mode, jotta sovellus käyttäisi säästeliäästi prosessoria ja näytönohjainta.

Emme kuitenkaan suosittele Godotia mobiilisovellusten tekoon, koska kyseistä virransäästöominaisuutta ei vielä tueta mobiilijärjestelmillä.

Katso esimerkiksi avoimen lähdekoodin Godot-sovellukset Material Maker ja Pixelorama.

Onko mahdollista käyttää Godotin pelimoottoria itsenäisesti luokkakirjastona?

Godot on tarkoitettu käytettäväksi editorissaan. Suosittelemme kokeilemaan sitä, koska todennäköisesti säästät näin aikaa pitkässä juoksussa. Ei ole suunnitelmissa tehdä Godotista luokkakirjastoa, koska se tekisi muusta pelimoottorista monimutkaisemman ja vaikeamman käyttää tavalliselle käyttäjälle.

Jos haluat käyttää renderöintikirjastoa, tutustu sen sijaan vakiintuneeseen renderöintimoottoriin. Pidä mielessä, että renderöintimoottoreilla on yleensä pienemmät yhteisöt kuin Godotilla. Tämä vaikeuttaa vastausten löytämistä kysymyksiisi.

Mitä käyttöliittymä työkalupakkia Godot käyttää?

Godot ei käytä tavallista :abbr:'GUI (Graafinen käyttöliittymä)' työkalupakkia, kuten GTK, Qt tai wxWidgets. Sen sijaan Godot käyttää omaa käyttöliittymätyökalusarjaansa, joka on renderoitu OpenGL ES: llä tai Vulkanilla. Tämä työkalupakki näkyy ohjaussolmujen muodossa, joita käytetään muokkaimen hahmontamiseen (joka on kirjoitettu C ++-muodossa). Näitä ohjaussolmuja voidaan käyttää myös minkä tahansa Godotin tukeman komentosarjakielen projekteissa.

Tämä mukautettu työkalupakki mahdollistaa laitteistokiihdytyksen hyödyntämisen ja yhtenäisen ulkoasun kaikilla alustoilla. Lisäksi sen ei tarvitse käsitellä LGPL-lisenssisäännöksiä, jotka liittyvät GTK:hon tai Qt:hen. Lopuksi tämä tarkoittaa, että Godot "syö omaa koiranruokaansa" koska editori itsessään on yksi Godot'n käyttöliittymäjärjestelmän monimutkaisimmista käyttäjistä.

Tätä mukautettua käyttöliittymätyökalupakettia ei voi käyttää kirjastona, mutta voit silti käyttää Godotia muiden kuin pelisovellusten luomiseen käyttämällä editoria.

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.

  • Meidän konttimme sisältävät sisään rakennetun muistin tarkkailun, joka auttaa tarkkailemaan laitteen muistin käyttöä.

  • Suurille matriiseille käytetään yhdistettyä muistia, joka voidaan liittää joko valmiiksi varattuun puskuriin tai virtuaalimuistiin.

  • Käytämme omaa merkkijono-tyyppiä, koska STL:n tarjoama tyyppi on liian yksinkertainen ja siitä puuttuu kunnollinen kansainvälistämistuki.

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 tarjoaa oman tyypinvalintajärjestelmänsä, joka voi valinnaisesti käyttää RTTI:tä sisäisesti. RTTI:n poistaminen käytöstä Godotissa tarkoittaa sitä, että voidaan saavuttaa huomattavasti pienempiä binäärikokoja, mutta suorituskyky on hieman heikompi.

Miksi Godot ei pakota käyttäjiään toteuttamaan DoD-mallia (Data oriented Design, Tietokanta ensin-suunnittelu) ?

Vaikka Godot pyrkii sisäisesti käyttämään välimuistin koherenssia mahdollisimman hyvin monissa raskaissa suorituskykytehtävissä, uskomme, että useimpia käyttäjiä ei oikeastaan tarvitse pakottaa käyttämään DoD-käytäntöjä.

DoD on enimmäkseen välimuistin koherenssioptimointi, jolla voidaan saavuttaa merkittäviä suorituskykyparannuksia vain, kun käsitellään kymmeniä tuhansia objekteja (joita käsitellään joka kehys ja joita ei juurikaan muuteta). Toisin sanoen, jos siirrät muutamaa sataa spriteä tai vihollista ruutua kohden, DoD ei auta sinua ja sinun pitäisi harkita erilaista optimointitapaa.

Suurin osa peleistä ei tarvitse tätä ja Godot tarjoaa käteviä apukeinoja tehtävän suorittamiseksi kun tilanne niin vaatii.

Jos tarvitaan peliä, jonka on todella käsiteltävä näin suuri määrä objekteja, suosittelemme käyttämään C++:a ja GDNativea suorituskykyisiin osiin ja GDScriptiä (tai C#:a) muuhun peliin.

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.