Często zadawane pytania

Co mogę zrobić z Godotem? Ile będzie mnie to kosztować? Jakie są warunki licencji?

Godot jest darmowym, wolnym i otwartym oprogramowaniem dostępnym na licencji MIT, zatwierdzonej przez OSI

W skrócie:

  • Możesz pobrać Godot i używać go w dowolnych celach: prywatnych, nie dających zysków, komercyjnych i innych.

  • Możesz dowolnie modyfikować i rozprowadzać Godota według własnego uznania, w jakichkolwiek celach, zarówno niekomercyjnie jak i komercyjnie.

Cała zawartość dokumentacji jest na liberalnej licencji Creative Commons Attribution 3.0 (CC-BY 3.0), z dopisikiem "Juan Linietsky, Ariel Manzur i społeczność the Godot Engine."

Logo i ikony są zazwyczaj objęte tą samą licencją Creative Commons. Zauważ, że niektóre biblioteki innych firm dołączone do kodu źródłowego Godota mogą mieć inne licencje.

Aby uzyskać szczegółowe informacje, zajrzyj do plików COPYRIGHT.txt oraz LICENSE.txt i LOGO_LICENSE.txt znajdujących się w repozytorium Godota.

Zobacz również stronę z licencją Godota.

Jakie platformy są wspierane przez Godota?

Dla wydawców:

  • Windows

  • macOS

  • X11 (Linux, *BSD)

  • Web

  • Android (eksperymentalne)

Eksport gier dla:

  • Windows (oraz Universal Windows Platform)

  • macOS

  • X11 (Linux, *BSD)

  • Android

  • iOS

  • Web

Zarówno 32- i 64-bitowe pliki binarne są wspierane tam, gdzie ma to sens, jednak 64-bitowe są domyślne.

Niektórzy użytkownicy również Informują że można używać Godot na systemach z Linuxem opartych na architekturze ARM, jak np. Raspberry Pi.

Niektórzy użytkownicy stworzyli port Godota na systemy ARM bazujące na Linuksie, takie jak Raspberry Pi. Istnieją również zewnętrzne projekty umożliwiające możliwość uruchamiania go na niektórych konsolach. Żadne z nich nie są jednak domyślnie wbudowane w edytor ani szablony eksportu.

Po więcej informacji, sprawdź rozdział o eksportowaniu i kompilowaniu Godota.

Jakie języki programowania wspiera Godot?

Oficjalnie wspierane języki w Godocie to GDScript, Visual Scripting, C# oraz C++. Więcej na temat danego języka znajdziesz w sekcji skryptów.

Jeśli zaczynasz swoją przygode z Godot albo nawet tworzeniem gier, GDScript jest zalecanym językiem do nauki i użycia gdyż jest on podstawowy dla Godot. Podczas gdy języki skryptowe mają skłonność do bycia mniej wydajnymi niż języki niskiego poziomu na dłuższą metę, w prototypowaniu i rozwijaniu gry minimalnie gotowej do wydania i skupianiu się na jak najszybszym jej wydaniu, GDScript zapewni szybki, przyjazny i użyteczny sposób do tworzenia twojej gry.

Zauważ że wsparcie jezyka C# jest względnie nowe, więc możesz napotkać problemy podczas użkowania. Nasza przyjazna i cieżko pracujaca spolecznosc programistów jest zawsze gotowa do rozwiazywania problemamów gdy tylko się pojawią, ale z racji że jestesmy projektem open-source, zalecamy najpierw własnoręczne zapoznanie sie z problemem. Szukajac w dyskusjach o otwartych problemach na <https://github.com/godotengine/godot/issues>`_ jest dobrym początkiem.

Jeśli chodzi o obsługę nowych języków, wsparcie dla nich jest możliwe poprzez zewnętrze wtyczki, z użyciem GDNative'a / NativeScripta / PluginScripta. Aktualnie użytkownicy pracują nad dowiązaniami m.in. do języków Python oraz Nim.

Czym jest GDScript i dlaczego powinienem z niego korzystać?

GDScript jest językiem skryptowym zintegrowanym z Godotem. Został stworzony od podstaw, by zmaksymalizować potencjał silnika używając jak najmniejszej ilości kodu, pozwalając zarówno doświadczonym jak i nowym programistom wykorzystać mocne strony Godota możliwie jak najszybciej. Jeżeli choć trochę programowałeś/aś np. w Pythonie, poczujesz się jak w domu. Przykłady, historię oraz kompletną dokumentację na temat możliwości GDScript znajdziesz w `Przewodniku po GDScript<gdscript_basics>`_.

Istnieje kilka powodów, dla których warto korzystać z GDScript - szczególnie gdy prototypujesz, na etapie alfa/beta twojego projektu lub nie tworzysz kolejnego tytułu AAA-ale najbardziej istotnym powodem jest ogólna ** redukcja złożoności**.

Pierwotna intencja stworzenia ściśle zintegrowanego, niestandardowego języka skryptowego dla Godota była dwojaka: po pierwsze, redukuje ilość czasu potrzebnego do rozpoczęcia pracy z Godot, dając programistom szybki sposób na ujawnienie się z silnikiem z naciskiem na produktywność; po drugie, zmniejsza ogólne obciążenie związane z konserwacją, łagodzi wymiarowość problemów i pozwala twórcom silnika skupić się na eliminowaniu błędów i ulepszaniu funkcji związanych z rdzeniem silnika - zamiast spędzać dużo czasu próbując uzyskać mały zestaw przyrostowych funkcji pracujących w dużym zestawie języków.

Ponieważ Godot jest projektem o otwartym kodzie źródłowym, od samego początku konieczne było nadanie priorytetu bardziej zintegrowanemu i bezproblemowemu doświadczeniu, aniżeli próbie przyciągnięcia dodatkowych użytkowników dzięki obsłudze bardziej znanych języków programowania – zwłaszcza, gdy obsługa tych języków może pogorszyć doświadczenia użytkownika. Rozumiemy, jeśli wolisz używać innego języka w Godot (zobacz listę obsługiwanych opcji powyżej). Biorąc to pod uwagę, jeśli nie dałeś jeszcze szansy GDScript, wypróbuj go przez trzy dni. Podobnie jak w przypadku silnika Godot, gdy tylko dostrzeżesz, jak potężnym narzędziem jest i jak GDScript przyspiesza Twoją pracę, z pewnością się przyzwyczaisz.

Więcej informacji na temat komfortowego posługiwania się GDScriptem lub dynamicznie pisanymi językami można znaleźć w samouczku GDScript: Wprowadzenie do języków dynamicznych.

Jakie były motywy tworzenia GDScript?

W początkowym okresie silnik używał języka skryptowego Lua. Lua jest szybka, ale tworzenie wiązań do obiektowo zorientowanego systemu było skomplikowane i powolne oraz zajmowało olbrzymią ilość kodu. Po kilku eksperymentach z Pythonem, również się okazał trudny do poprawnej implementacji.

Głównymi powodami tworzenia niestandardowego języka skryptowego dla Godota były:

  1. Słaba obsługa wątków w większości skryptowych maszyn wirtualnych, a Godot używa wątków (Lua, Python, Squirrel, JavaScript, ActionScript, itp.).

  2. Słabe wsparcie dla rozszerzania klas w większości skryptowych maszyn wirtualnych i dostosowywanie do sposobu działania Godota jest wysoce nieefektywne (Lua, Python, JavaScript).

  3. Wiele istniejących języków ma okropne interfejsy do wiązania z C++, co skutkuje dużą ilością kodu, błędów, wąskich gardeł i ogólnej nieefektywności (Lua, Python, Squirrel, JavaScript, itp.). Chcieliśmy skupić się na świetnym silniku, a nie na dużej ilości integracji.

  4. Brak natywnych typów wektorowych (vector3, matrix4, itd.), skutkujący znacznym zmniejszeniem wydajności kiedy używa się własnych typów (Lua, Python, Squirrel, JavaScript, ActionScript, itd.).

  5. Odśmiecacz pamięci skutkuje przestojami i niepotrzebnie dużym zużyciem pamięci (Lua, Python, JavaScript, ActionScript, itd.).

  6. Trudności ze zintegrowaniem z edytorem kodu dla auto-uzupełniania, edycji w czasie rzeczywistym, itd. (każdy z nich). Funkcje te są bardzo dobrze wspierane przez GDScript.

GDScript został zaprojektowany tak, żeby zredukować te problemy i nie tylko.

Jakie typy plików 3D obsługuje Godot?

Godot wpiera Collada poprzez OpenCollada exporter (Maya, 3DSMax). Jeśli używasz Blendera, sprawdź nasz Lepszy Eksporter Collada <https://godotengine.org/download>`_.

Dla Godot 3.0 istnieje wsparcie dla glTF.

FBX jest wpierane przez bibliotekę Open Asset Import. FBX jest jednak opatentowany, więc jeśli jest to odpowiednie dla Twojego sposobu pracy zalecamy użycie innych, wypisanych poniżej, formatów.

Czy w przyszłości zostanie dodane wsparcie dla [tu wstaw zamknięte SDK, takie jak PhysX, GameWorks, itp.]?

Celem Godot jest stworzenie darmowego i otwarto-źródłowego silnika opartego na licencji MIT, który jest modularny i rozszerzalny. Nie ma planów, aby społeczność rozwijająca rdzeń Godot'a wspierała jakiekolwiek SDK firm trzecich które posiada zamknięte źródła czy jest własnościowe. Integrowanie tego z rdzeniem Godot'a byłoby sprzeczne z jego etyką.

Ponieważ Godot jest open-source i modularny, nic nie stoi na przeszkodzie, abyś ty lub ktokolwiek inny zainteresowany dodał te biblioteki jako moduł i stworzył grę z ich pomocą – jako oprogramowanie z otwartym lub zamkniętym źródłem.

Aby sprawdzić, czy nadal dostarczane jest wsparcie dla wybranego przez Ciebie SDK, sprawdź pytanie o Wtyczki znajdujące się poniżej.

Jeśli znasz zewnętrzne SDK, które nie jest jeszcze wspierane przez Godota, a oferuje możliwość integracji zgodnie z licencją open-source, rozważ rozpoczęcie pracy nad integracją na własną rękę. Godot nie należy do jednej osoby. Należy do społeczności, a ona rozwija się dzięki ambitnym członkom, takim jak Ty.

Jak mogę zainstalować edytor Godot'a na moim systemie (dla integracji z pulpitem)?

Ponieważ nie musisz instalować Godota na swoim urządzeniu, aby móc go uruchamiać, integracja desktopowa nie jest wykonywana automatycznie. Są dwa sposoby na obejście tego. Możesz zainstalować Godota przy pomocy instalatora ze Steam (dla wszystkich platform), Scoop (dla Windows), Homebrew (dla macOS) or Flathub (dla Linux). Instalator sam wykona wszystkie kroki potrzebne dla integracji desktopowej.

Ewentualnie, możesz samemu wykonać wszystkie czynności, które miał wykonać za ciebie instalator:

Windows

  • Przenieś plik wykonywalny Godot'a do stabilnej lokalizacji (tj. poza folder Pobrane), aby przez przypadek nie przenieść go w przyszłości, co mogłoby uszkodzić wszystkie utworzone do niego skróty.

  • Kliknij prawym przyciskiem myszy na plik wykonywalny Godot i wybierz opcję Utwórz skrót.

  • Przenieś utworzony skrót do %LOCALAPPDATA%\Microsoft\Windows\Start Menu\Programs. Jest to miejsce, z którego system Windows pobiera skróty, które pojawią się w menu Start. Możesz również przypiąć Godot'a do paska zadań poprzez kliknięcie prawym przyciskiem myszy na plik wykonywalny i wybranie opcji Przypnij do paska zadań.

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.

Linuks

  • Przenieś pliki binarne Godot'a w bezpieczną lokalizację (np. poza folder "Pobrane"), by niechcący ich nie usunąć albo przenieść w przyszłości.

  • Zmień nazwę i przenieś pliki binarne Godot'a do lokalizacji widocznej w twojej wartości PATH środowiska. Wartość ta to zazwyczaj /usr/local/bin/godot lub /usr/bin/godot. Do zrobienia tego potrzebne są uprawnienia administratora, ale to również pozwoli Ci do uruchomienia edytora przy użyciu terminala.

    • Jeśli nie możesz przenieść plików binarnych edytora do bezpiecznej lokalizacji, możesz je trzymać gdzieś w folderze domowym i później zmodyfikować wartość Path= w pliku poniżej .desktop, który jest ma przechowywać całą (bezwzględną) ścieżką do plików binarnych Godot'a.

  • Zapisz plik plik.desktop <https://raw.githubusercontent.com/godotengine/godot/3.x/misc/dist/linux/org.godotengine.Godot.desktop> to $HOME/.local/share/applications/. Jeśli posiadasz uprawnienia administratora możesz rownież zapisać plik .desktop w lokalizacji /usr/local/share/applications by skrót był dostępny dla wszystkich użytkowników.

Czy edytor Godot jest aplikacją przenośną?

W domyślnej konfiguracji Godot jest częściowo przenośny. Jego plik wykonywalny może działać z dowolnej lokalizacji (w tym z lokalizacji tylko do odczytu) i nigdy nie wymaga uprawnień administratora.

Jednakże pliki konfiguracyjne będą zapisywane w katalogu konfiguracji użytkownika lub w katalogu danych. Zwykle jest to dobre podejście, ale oznacza to, że pliki konfiguracyjne nie będą przenoszone między komputerami, jeśli skopiujesz folder zawierający plik wykonywalny Godota. Zobacz File paths in Godot projects, aby uzyskać więcej informacji.

Jeśli wymagane jest prawdziwe działanie jako aplikacja przenośna (np. do użycia na pendrive'ie), postępuj zgodnie z instrukcjami w Self-contained mode.

Dlaczego Godot używa Vulkan API lub OpenGL zamiast Direct3D?

Godot dąży przede wszystkim do niezależności od platformy oraz do wspierania otwartych standardów. OpenGL i Vulkan są technologiami zarówno otwartymi jak i dostępnymi (niemalże) na wszystkich platformach. Dzięki tej decyzji projektowej, projekt rozwijany w Godot na Windowsie będzie działał od ręki na Linuksie, macOS i innych systemach.

Ponieważ nad silnikiem renderującym Godota pracuje tylko kilka osób, zależy nam na jak najmniejszej ilości renderujących backend-ów do utrzymania. Ponadto, używanie pojedynczego API na wszystkich platformach pozwala na większą spójność z mniejszą ilością problemów specyficznych dla jednej platformy.

Na dłuższą metę, możliwe, że będziemy pracować nad silnikiem renderującym Direct3D 12 dla Godota (głównie na potrzeby Xbox'a) lecz Vulkan i OpenGL pozostaną domyślnymi backend-ami renderującymi na wszystkich platformach (w tym także na Windows).

Dlaczego Godot dąży do tego ,aby jego podstawowe funkcje były niewielkie?

Godot celowo nie zawiera funkcji, które mogą być zaimplementowane przez dodatki, chyba że są one bardzo często używane. Jednym z przykładów może być zaawansowana funkcjonalność sztucznej inteligencji.

Mogły się wydarzyć następujące rzeczy:

  • Utrzymanie kodu oraz przestrzeń dla bugów. Przy każdorazowej akceptacji kodu do repozytorium silnika Godot, istniejący kontrybutor bierze na siebie obowiązek utrzymania kodu. Niektórzy kontrybutorzy, niestety, nie biorą na siebie tego obowiązku, co może prowadzić do problemów z utrzymaniem dodanego kodu. To z kolei prowadzić może do słabo utrzymanych obszarów z błędami które nigdy nie zostają naprawione. Dodatkowo, "szerokość interfejsu" biblioteki poszerza się z czasem, powodując powiększenie ilości funkcji potrzebujących testowania i utrzymania.

  • Łatwość kontrybucji. Trzymając bazę kodu małą i czystą, może ona być łatwiejsza i szybsza w kompilacji. To z kolei przedkłada się na łatwość rozpoczęcia pracy w Godot dla nowych kontrybutorów, bez wymogu kupna szybkiego i drogiego sprzętu.

  • Utrzymanie małego rozmiaru obiektowego dla edytora. Nie każdy ma szybkie łącze internetowe. Upewnienie się, aby każdy mógł pobrać edytor Godot, wypakować go i uruchomić w mniej niż 5 minut czyni Godota bardziej dostępnym dla deweloperów we wszystkich krajach.

  • Utrzymanie małego rozmiaru obiektowego dla szablonów eksportowania. Ma to bezpośredni wpływ na rozmiar projektów wyeksportowanych w Godocie. Na telefonach i platformach webowych, utrzymanie małych rozmiarów plików jest podstawowym sposobem zapewnienia szybkiej instalacji i ładowania na urządzeniach o słabej mocy. Znowu, jest wiele państw, w których szybki internet nie jest łatwo dostępny. W dodatku, w efekcie tego, w krajach tych często obowiązują ścisłe limity użycia danych.

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

Jak tworzyć assety by wspierały różne rozdzielczości i proporcje?

Pytanie to pojawia się często i prawdopodobnie wynika z niezrozumienia, jakie stworzyło Apple, który pierwotnie podwoiło rozdzielczość swoich urządzeń. Skłoniło to ludzi do myślenia, że posiadanie tych samych zasobów w różnych rozdzielczościach to dobry pomysł i wiele osób podążyło tą drogą. Początkowo w pewnym stopniu to działało na urządzeniach firmy Apple. Jednak później powstały podobne urządzenia z systemem Android oraz Apple o różnych rozdzielczościach i współczynnikach proporcji, z bardzo szeroką gamą rozmiarów i interfejsów DPI.

Najlepiej użyć jednej podstawowej rozdzielczości w grze, a obsługiwać różne proporcje ekranów. Dotyczy to głównie widoku 2D, ponieważ w 3D wystarczy dostosować XFov lub YFov kamery.

  1. Wybierz jedną podstawową rozdzielczość dla swojej gry. Nawet jeśli istnieją urządzenia o rozdzielczości od 400px do 2Kpx, skalowanie sprzętowe w Twoim urządzeniu zajmie się tym przy niewielkim lub żadnym koszcie. Najczęściej wybierane są rozdzielczości zbliżone do 1080p (1920x1080) lub 720p (1280x720). Pamiętaj, że im wyższa rozdzielczość, tym większe zasoby i tym więcej pamięci będą zajmować i dłużej się ładować.

  2. Użyj opcji 'stretch' w Godot; '2D stretching' wraz z utrzymaniem proporcji ekranu działa najlepiej. Sprawdź samouczek Wiele rozdzielczości by dowiedzieć się więcej.

  3. Określ minimalną rozdzielczość, a następnie zdecyduj, czy chcesz, żeby gra rozciągała się pionowo czy poziomo dla różnych proporcji, czy używała jednej proporcji i czarnych pasków. Jest to wyjaśnione w Wiele rozdzielczości.

  4. Dla interfejsu użytkownika, użyj anchoring aby określić gdzie powinny się znajdować i jak poruszać elementy sterujące. Jeśli interfejsy użytkownika są bardziej złożone, należy rozważyć zapoznanie się z kontenerami.

I to koniec! Twoja gra powinna działać w wielu rozdzielczościach.

Jeśli chcesz, aby Twoja gra działała również na archaicznych urządzeniach z niewielkimi ekranami (o szerokości mniejszej niż 300 pikseli), możesz użyć opcji eksportu by zmniejszyć obrazy, a następnie użyć tej wersji dla ekranów o określonych wymiarach w App Store lub Google Play.

Jak mogę rozbudować Godota?

Jeżeli chcesz rozszerzyć funkcjonalność silnika, np. poprzez stworzenie wtyczki do edytora lub dodając wsparcie dla kolejnego języka, poczytaj o tworzeniu wtyczek i skryptach narzędziowych.

Zapoznaj się również z wpisami na ten temat na oficjalnym blogu:

Możesz również przyjrzeć się implementacji GDScript, modułom, jak również nieoficjalnemu wsparciu Pythona. Dzięki temu dowiesz się jak inne zewnętrzne biblioteki integrują się z Godotem.

Kiedy zostanie wydana następna wersja Godota?

Uruchamianie kodu w edytorze.

Chcę się przyczynić do rozwoju Godota! Jak mogę zacząć?

Świetnie! Jako projekt open-source, Godot czerpie z innowacyjności i ambicji deweloperów takich jak ty.

Pierwszym miejscem do którego powinieneś się udać jest: issues. Znajdź problem, który rezonuje z Twoimi umiejętnościami a następnie zaznajom się z poradnikiem: `How to Contribute <https://github.com/godotengine/godot/blob/master/CONTRIBUTING.md#contributing-pull-requests>`_aby nauczyć się jak wykonać rozwidlenie, modyfikację i wysłać Pull Request (PR) z twoimi zmianami.

Mam świetny pomysł dla Godot'a. Jak mogę się nim podzielić?

Kusząca może być chęć dodawania do Godota nowych pomysłów, na przykład takich, które prowadzą do gruntownych zmian, w jakiś sposób próbujących imitować działanie innych silników do tworzenia gier lub alternatywnych rozwiązań, które chciałbyś umieścić w edytorze. To świetne pomysły i jesteśmy wdzięczni, że tak zmotywowani ludzie chcą nam wspomóc, ale w centrum uwagi Godota jest i zawsze będzie rozwój głównych funkcji określonych w Roadmap, pozbywanie się błędów i problemów <https://github.com/godotengine/godot/issues>`_, oraz komunikacja między członkami społeczności Godot.

Większość deweloperów społeczności Godot chętniej dowie się o takich rzeczach, jak:

  • Twoje doświadczenia podczas korzystania z oprogramowania i problemy, które napotkasz (to dla nas znacznie ważniejsze niż pomysły, co poprawić).

  • Funkcje, które chcesz, by zostały zaimplementowane, ponieważ potrzebujesz ich w swoim projekcie.

  • Pojęcia, które były trudne do zrozumienia podczas nauki Godot'a.

  • Elementy ograniczające płynność pracy, które chciałbyś, aby zostały zoptymalizowane.

  • Elementy, w których brakowało zrozumiałych poradników lub miejsca w których dokumentacja jest niejasna.

Nie odnieś wrażenia, że twoje pomysły nie są mile widziane. Spróbuj je najpierw sformułować jako problemy, dzięki czemu programiści i społeczność będą mieli odpowiednią podstawę do podjęcia dyskusji na ich temat.

Jeżeli chcesz dzielić się pomysłami i problemami ze społecznością, zapoznaj nas ze swoją sytuacją. Wyjaśnij, co chcesz osiągnąć, co według ciebie powinno się wydarzyć, a co wydarzyło się w rzeczywistości. Opisywanie problemów w ten sposób pomoże społeczności skupić się na wprowadzaniu usprawnień dla ogółu.

Dodatkowe punkty za zrobienie zrzutów ekranu, przedstawienie konkretnych liczb, sposobów testowania lub przykładowych projektów (o ile to możliwe).

Czy jest możliwe używać Godota do tworzenia aplikacji nie będących grami?

Tak! Godot oferuje rozbudowany system UI, a jego niewielki rozmiar dystrybucji może uczynić go odpowiednią alternatywą dla frameworków takich jak Electron lub Qt.

Przy tworzeniu aplikacji nie będącej grą, upewnij się by włączyć :ref: tryb niskiego wykorzystania procesora <class_ProjectSettings_property_application/run/low_precessro_mode> w Ustawieniach Projektu by zmniejszyć zużycie procesora oraz karty graficznej.

W związku z tym nie polecamy używania Godot by stworzyć mobilną aplikację, ponieważ tryb niskiego wykorzystania procesora jeszcze nie jest wspierany na platformach przenośnych.

Sprawdź Material Maker oraz`Pixelorama <https://github.com/Orama-Interactive/Pixelorama>`__ dla przykładów open-source aplikacji stworzonych z Godotem.

Czy jest możliwe używać Godota jako biblioteki?

Godot jest zaprojektowany tak żeby używać go z jego edytorem. Zalecamy sprawdzić go w użyciu ponieważ w dłuższej perspektywie zaoszczędzi wam czas. Nie ma w planach uczynienia Godota użytecznego jako biblioteki ponieważ uczyniłoby to resztę silnika bardziej zawiłą i trudną w użyciu dla przeciętnych użytkowników.

Jeżeli chesz użyć bibliotek renderowania, lepiej po prostu poszukaj silnika. Pamiętaj jednak że mają one zazwyczaj mniejszą społeczność w porównaniu do Godota. To może utrudnić znalezienie odpowiedzi na twoje pytania.

Jakiego zestawu narzędzi do obsługi interfejsu używa Godot?

Godot nie używa standardowego GUI zestawy narzędzi jak GTK, Qt czy wxWidgets. Zamiast tego Godot używa własnego zestawu narzędzi do interfejsu, renderowane używając OpenGL ES lub Vulcan. Te zestawy narzędzi są dostępne w postaci Węzłów kontrolnych, które są używane do renderowania edytora (napisanego w C++). Te Węzły Kontrolne mogą także być używane w projektach za pomocą każdego języka skryptowego wspieranego przez Godot.

Ten niestandardowy zestaw narzędzi umożliwia korzystanie z akceleracji sprzętowej i zapewnia spójny wygląd na wszystkich platformach. Co więcej, nie musi radzić sobie z zastrzeżeniami licencyjnymi LGPL, które są dostarczane z GTK lub Qt. Wreszcie, oznacza to, że Godot nie korzysta z zewnętrznych edytorów/narzędzi , ponieważ sam edytor jest jednym z najbardziej złożonych użytkowników systemu interfejsu Godota.

Ten niestandardowy zestaw narzędzi interfejsu użytkownika nie może być używany jako biblioteka, ale nadal możesz używać Godota do tworzenia aplikacji innych niż gry za pomocą edytora.

Dlaczego Godot nie używa STL (Standard Template Library)?

Jak wiele innych bibliotek (np. Qt), Godot nie używa STL. Uważamy, że STL jest świetną biblioteką do zastosowań ogólnych, ale mieliśmy specjalne wymagania dla Godot'a.

  • Szablony STL tworzą bardzo dużo symbolów, czego rezultatem są bardzo duże debug binaries. W zamian używamy szablonów w małą ilością nazw.

  • Większość naszych kontenerów jest dostosowanych do specjalnych potrzeb, tak jak Vector, który używa kopiowania podczas zapisu, zaś my używamy go do przekazywania danych, albo systemu RID, który wymaga wydajności czasu dostępu O(1). Również, nasze implementacje mapy hash są stworzone, by integrować się płynnie z wewnętrznymi elementami silnika.

  • Nasze kontenery posiadają wbudowane śledzenie pamięci, co pozwala na lepszą obserwację jej zużycia.

  • Dla dużych tablic, używamy puli pamięci, która może być zmapowana do wstępnie przydzielonego bufora, jak i do pamięci wirtualnej.

  • Używamy naszego własnego typu String, ponieważ ten wprowadzony przez bibliotekę STL jest zbyt prosty i brakuje mu wsparcia internacjonalizacji.

Dlaczego Godot nie używa mechanizmu wyjątków?

Wierzymy, że gry powinny działać stabilnie, niezależnie od wszystkiego. Jeśli wydarzy się coś niespodziewanego Godot wskaże błąd (który można prześledzić w skrypcie), ale potem spróbuje przywrócić program do prawidłowego działania, tak dobrze jak jest to możliwe.

Dodatkowo, wyjątki znacząco zwiększają rozmiar skompilowanego pliku wykonywalnego.

Dlaczego Godot nie wymusza użycia RTTI?

Godot zapewnia swój własny system konwersji typów, który opcjonalnie używa wewnętrznie RTTI. Wyłączenie RTTI w Godot pozwala na osiągnięcie znacznie mniejszego rozmiaru skompilowanego pliku przy małym spadku wydajności.

Dlaczego Godot nie zmusza użytkowników do implementacji DoD (projektowania zorientowanego na dane)?

Mimo, że wewnętrznie Godot dla wielu zadań wymagających dużej wydajności próbuje wykorzystać spójność pamięci najlepiej jak to możliwe, wierzymy, że większość użytkowników tak naprawdę nie musi być zmuszana do używania praktyk DoD.

DoD to głównie optymalizacja spójności pamięci, która daje znaczny wzrost wydajności tylko w przypadku, gdy ma do czynienia z dziesiątkami tysięcy obiektów (które są przetwarzane w każdej klatce z lekką modyfikacją). Jeśli więc poruszasz kilkaset obiektów w jednej klatce, DoD Ci nie pomoże i powinieneś spróbować innego podejścia do optymalizacji.

Znaczna większość gier nie potrzebuje tego i Godot zapewnia przydatne narzędzia dla większości przypadków, w których by to było potrzebne.

Jeżeli Twoja gra naprawdę musi przetworzyć tak dużą ilość obiektów, rekomendujemy użycie języka C++ lub GDNative dla części wymagających największej wydajności, zaś GDScript (lub C#) dla reszty gry.

Jak mogę wesprzeć rozwój Godota?

Zobacz Metody wspierania.

Kto pracuje nad Godotem? Jak mogę się z Tobą skontaktować?

Zobacz stronę do kontaktu Kontakt - Godot.