Attention: Here be dragons

This is the latest (unstable) version of this documentation, which may document features not available in or compatible with released stable versions of Godot.

Checking the stable version of the documentation...

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 zatwierdzonej przez OSI licencji: MIT. Co znaczy za darmo, jak w przypadku "wolności słowa” i "darmowego piwa.”

W skrócie:

• Możesz pobrać Godota i używać go w dowolnych celach: prywatnych, nie dających zysków, komercyjnych, czy jakichkolwiek 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ść tej towarzyszącej dokumentacji jest udostępniona licencji Creative Commons Attribution 3.0 (CC-BY 3.0), z przypisaniem autorstwa dla "Juan Linietsky, Ariel Manzur and the Godot Engine community."

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

For full details, look at the COPYRIGHT.txt as well as the LICENSE.txt and logo LICENSE.txt files in the Godot repository.

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

Jakie platformy są obsługiwane przez Godota?

Do tworzenia:

• Windows

• macOS

• Linux, *BSD

• Android (eksperymentalne)

• Przeglądarka (eksperymentalne)

Eksport gier dla:

• Windows

• macOS

• Linux, *BSD

• Android

• iOS

• Przeglądarka (HTML5)

Zarówno 32- i 64-bitowe pliki wykonywalne są wspierane tam, gdzie ma to sens, jednak 64-bitowe są domyślne. Oficjalne kompilacje na macOS obsługują natywnie zarówno Apple Silicon jak i x86_64.

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.

For information about console support, see the Godot website.

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

Informacja

Godot 3 miał także wsparcie dla Universal Windows Platform (UWP). Ten port platformy został usunięty w Godot 4 z powodu braku utrzymywania, i jest porzucone wsparcie przez Microsoft. Platforma jest ciągle dostępna w stabilnej wersji Godot 3 dla zainteresowanych użytkowników.

Jakie języki programowania wspiera Godot?

Oficjalnie wspierane języki w Godocie to GDScript, 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.

Note that C# support is still relatively new, and as such, you may encounter some issues along the way. C# support is also currently missing on the web platform. Our friendly and hard-working development community is always ready to tackle new problems as they arise, but since this is an open source project, we recommend that you first do some due diligence yourself. Searching through discussions on open issues is a great way to start your troubleshooting.

Jeśli chodzi o obsługę nowych języków, wsparcie dla nich jest możliwe za pomocą GDExtensions. (Zobacz: poniższe pytanie dotyczące wtyczek). Aktualnie użytkownicy pracują nad połączeniami z językami Python oraz Nim.

Czym jest GDScript i dlaczego powinienem z niego korzystać?

GDScript is Godot's integrated scripting language. It was built from the ground up to maximize Godot's potential in the least amount of code, affording both novice and expert developers alike to capitalize on Godot's strengths as fast as possible. If you've ever written anything in a language like Python before, then you'll feel right at home. For examples and a complete overview of the power GDScript offers you, check out the GDScript scripting guide.

There are several reasons to use GDScript, but the most salient reason is the overall reduction of complexity.

Pierwotny zamiar stworzenia ściśle zintegrowanego, niestandardowego języka skryptowego dla Godota był dwojaki: po pierwsze, skraca czas potrzebny na rozpoczęcie pracy z Godotem, dając programistom szybki sposób na poznanie silnika z naciskiem na produktywność; po drugie, zmniejsza ogólne obciążenie związane z konserwacją, zmniejsza wymiarowość problemów i pozwala programistom silnika skupić się na usuwaniu błędów i ulepszaniu funkcji związanych z rdzeniem silnika, zamiast spędzać dużo czasu na próbach uzyskania małego zestawu przyrostowych funkcji działających w dużym zestawie języków.

Since Godot is an open source project, it was imperative from the start to prioritize a more integrated and seamless experience over attracting additional users by supporting more familiar programming languages, especially when supporting those more familiar languages would result in a worse experience. We understand if you would rather use another language in Godot (see the list of supported options above). That being said, if you haven't given GDScript a try, try it for three days. Just like Godot, once you see how powerful it is and how rapid your development becomes, we think GDScript will grow on you.

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, język ten 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. No native vector types (Vector3, Transform3D, etc.), resulting in highly reduced performance when using custom types (Lua, Python, Squirrel, JavaScript, ActionScript, etc.).

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 edytora kodu dla auto-uzupełniania, edycji w czasie rzeczywistym, itd. (każdy z nich).

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

Which programming language is fastest?

In most games, the scripting language itself is not the cause of performance problems. Instead, performance is slowed by inefficient algorithms (which are slow in all languages), by GPU performance, or by the common C++ engine code like physics or navigation. All languages supported by Godot are fast enough for general-purpose scripting. You should choose a language based on other factors, like ease-of-use, familiarity, platform support, or language features.

In general, the performance of C# and GDScript is within the same order of magnitude, and C++ is faster than both.

Comparing GDScript performance to C# is tricky, since C# can be faster in some specific cases. The C# language itself tends to be faster than GDScript, which means that C# can be faster in situations with few calls to Godot engine code. However, C# can be slower than GDScript when making many Godot API calls, due to the cost of marshalling. C#'s performance can also be brought down by garbage collection which occurs at random and unpredictable moments. This can result in stuttering issues in complex projects, and is not exclusive to Godot.

C++, using GDExtension, will almost always be faster than either C# or GDScript. However, C++ is less easy to use than C# or GDScript, and is slower to develop with.

You can also use multiple languages within a single project, with cross-language scripting, or by using GDExtension and scripting languages together. Be aware that doing so comes with its own complications.

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

Szczegółowe informacje na temat obsługiwanych formatów, sposobu ich eksportu z oprogramowania do modelowania 3D oraz importu do Godot, można znaleźć w dokumentacji Importowanie scen 3D.

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ń silnika wspierała jakiekolwiek SDK firm trzecich które posiada zamknięte źródła czy jest własnościowe. Taka integracja byłaby sprzeczna z etyką Godot'a.

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

Also, see the official blog post on GDExtension, a way to develop native extensions for Godot:

• Introducing GDNative's successor, GDExtension

You can also take a look at the GDScript implementation, the Godot modules, as well as the Jolt physics engine integration for Godot. This would be a good starting point to see how another third-party library integrates with Godot.

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 \ProgramData\Microsoft\Windows\Menu Start\Programy. 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

Przeciągnij wypakowaną aplikację Godot do /Applications/Godot.app, a następnie przeciągnij ją do Dock, jeśli chcesz. Spotlight będzie w stanie znaleźć Godot, o ile znajduje się on w /Applications lub ~/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.

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

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

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

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.

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

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

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

Istnieje ku temu kilka powodów:

• Utrzymanie kodu oraz wykrywanie błędów. Przy każdorazowej akceptacji kodu do repozytorium silnika Godot, istniejący kontrybutor bierze na siebie obowiązek jego utrzymania. Niektórzy kontrybutorzy nie zawsze biorą na siebie ten obowiązek, co może prowadzić do problemów z utrzymaniem dodanego kodu. To z kolei może prowadzić do słabo utrzymanych obszarów z błędami które nigdy nie zostają naprawione. Dodatkowo, "powierzchnia API" która musi być testowana i sprawdzana regresji która się zwiększa z czasem.

• Ł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.

• 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 important 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 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.

The most common and proper way to achieve this is to, instead, use a single base resolution for the game and only handle different screen aspect ratios. This is mostly needed for 2D, as in 3D, it's just a matter of camera vertical or horizontal FOV.

1. Choose a single base resolution for your game. Even if there are devices that go up to 1440p and devices that go down to 400p, regular hardware scaling in your device will take care of this at little or no performance cost. The most common choices are either near 1080p (1920x1080) or 720p (1280x720). Keep in mind the higher the resolution, the larger your assets, the more memory they will take and the longer the time it will take for loading.

2. Use the stretch options in Godot; canvas items stretching while keeping aspect ratios works best. Check the Wiele rozdzielczości tutorial on how to achieve this.

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.

Kiedy zostanie wydana następna wersja Godota?

When it's ready! See Kiedy będzie wydana następna wersja? for more information.

Którą wersję Godota powinienem użyć w nowym projekcie?

We recommend using Godot 4.x for new projects, but depending on the feature set you need, it may be better to use 3.x instead. See Której wersji powinienem używać w nowym projekcie? for more information.

Czy powinienem zaktualizować swój projekt, aby korzystać z nowych wersji silnika Godot?

Nie zawsze uaktualnienie wersji jest bezpieczne. Ogólnie, to czy podnosić wersję zależy od specyficznych uwarunkowań Twojego projektu. Sięgnij do Czy powinienem zaktualizować mój projekt do nowej wersji silnika? po więcej informacji.

Should I use the Forward+, Mobile, or Compatibility renderer?

You can find a detailed comparison of the renderers in Overview of renderers.

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

Awesome! As an open source project, Godot thrives off of the innovation and the ambition of developers like you.

Najlepszym sposobem na rozpoczęcie współtworzenia silnika Godot jest korzystanie z niego i zgłaszanie wszelkich problemów, które możesz napotkać. Dobry raport o błędach z jasnymi krokami jak odtworzyć problem, pomaga innym współautorom szybko i skutecznie naprawiać silnik. Możesz także zgłosić problemy znalezione w dokumentacji online.

Jeśli czujesz się gotowy, aby zacząć wysyłać żądanie zatwierdzenia zmian do projektu (z ang. PR, skrót od Pull Request), wybierz dowolny problem, który Cię dotyczy, z jednego z powyższych linków i spróbuj go naprawić. Będziesz musiał nauczyć się, jak skompilować silnik ze źródeł lub jak zbudować dokumentację. Musisz także zapoznać się z Git, czyli systemem kontroli wersji, z którego korzystają programiści Godot.

We explain how to work with the engine source, how to edit the documentation, and what other ways to contribute are there in our documentation for contributors.

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

Zawsze czekamy na sugestie, jak ulepszyć silnik. Opinie użytkowników są główną siłą napędową naszego procesu decyzyjnego, a ograniczenia, które możesz napotkać podczas pracy nad projektem, są dla nas doskonałym punktem odniesienia przy rozważaniu ulepszeń silnika.

Jeśli masz problemy z używaniem Godot lub brakuje Ci jakiejś funkcji w aktualnej wersji, zacznij od omówienia tego z naszą społecznością. Mogą istnieć alternatywne, być może lepsze, sposoby osiągnięcia pożądanego rezultatu, które mogą zasugerować członkowie społeczności. Możesz także dowiedzieć się, czy inni użytkownicy doświadczają tego samego problemu i wspólnie z nimi znaleźć dobre rozwiązanie.

Jeśli masz dobrze zdefiniowany, dokładnie określony pomysł na rozwój silnika, nie wahaj się otworzyć proponowanego usprawnienia. Staraj się być dokładny i konkretny opisując swój problem oraz proponowane rozwiązanie — można brać pod uwagę tylko to, co da się zrobić. Jeśli chcesz to napisać i wdrożyć do silnika samodzielnie, zawsze jest to mile widziane (ale nie jest to wymagane)!

Jeśli masz tylko ogólny pomysł bez konkretnych szczegółów, możesz otworzyć propozycję dyskusji. Mogą to być cokolwiek co Cię interesuje i co umożliwia swobodną dyskusję w poszukiwaniu rozwiązania. Po znalezieniu takowego może zostać utworzone proponowane usprawnienie.

Proszę, zapoznaj się z dokumentem czytaj-mnie przed utworzeniem propozycji, aby dowiedzieć się więcej o procesie.

Czy jest możliwe używać Godota do tworzenia aplikacji innych niż gry?

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

See Creating applications for more information.

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

If you are looking to make a game with Godot, keep in mind Godot is designed 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.

For more specialized applications, it can make sense to look into using Godot as a library. Since Godot 4.6, there is experimental support for using Godot as a static or shared library in the form of LibGodot. This is currently supported on Windows, macOS, and Linux. Support for Android and iOS is planned for a future release.

You can find sample applications that use Godot as a library in the migeran/libgodot_project GitHub repository.

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

Godot does not use a standard GUI toolkit like GTK, Qt or wxWidgets. Instead, Godot uses its own user interface toolkit, which is always rendered using hardware acceleration. There is no built-in software fallback, although external solutions that emulate graphics APIs on the CPU can be used.

This toolkit is exposed in the form of Control nodes, which are used to render the editor (which is written in C++). These Control nodes can also be used in projects from any scripting language supported by 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.

This custom UI toolkit can be embedded into other applications (experimental). However, the preferred way to use it is to use Godot to create non-game applications with the editor.

Why does Godot use the SCons build system?

Godot używa systemu kompilacji SCons. Nie ma planów przejścia na inny system budowania projektu w najbliższej przyszłości. Istnieje wiele powodów, dla których wybraliśmy SCons zamiast innych alternatyw. Na przykład:

• Projekty w Godot można skompilować na kilkanaście różnych platform: wszystkie platformy PC, wszystkie platformy mobilne, wiele konsol i WebAssembly.

• Programiści często kompilują swoje produkty na kilka platform w tym samym czasie lub nawet różne konfiguracje dla celów tej samej platformy. Nie mogą sobie pozwolić za każdym razem na rekonfigurowanie wszystkiego i przebudowę projektu. SCons może to zrobić bez zająknięcia i bez niedziałających kompilacji.

• SCons nigdy nie zepsuje Twojej kompilacji, bez względu na liczbę zmian, konfiguracji, dodatków, usunięć etc.

• Proces budowania gry w Godot nie jest prosty. Kilka plików jest generowanych przez kod (binders), inne są parsowane (shaders), a jeszcze inne muszą umożliwiać dostosowywanie (modułów). Taką logikę łatwiej jest napisać w rzeczywistym języku programowania (takim jak Python), zamiast używać języka opartego głównie na makrach, przeznaczonego wyłącznie do budowania.

• Godot's build process makes heavy use of cross-compiling tools. Each platform has a specific detection process, and all these must be handled as specific cases with special code written for each.

Jeśli planujesz samemu konfigurować budowanie w Godot, postaraj się zachować otwarty umysł i przynajmniej trochę zapoznać się z SCons.

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

Like many other libraries (Qt as an example), Godot does not make use of STL (with a few exceptions such as threading primitives). We believe STL is a great general-purpose library, but we had special requirements for Godot.

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

Check out Godot's container types for alternatives.

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.

Additionally, exceptions significantly increase the binary size for the executable and result in increased compile times.

Czy Godot używa ECS (Entity Component System)?

Godot nie używa ECS i zamiast tego opiera się na dziedziczeniu. Chociaż nie ma podejścia, które można jednoznacznie określić lepszym, to odkryliśmy, że zastosowanie podejścia opartego na dziedziczeniu zapewnia lepszą użyteczność, a jednocześnie jest w większości przypadków wystarczająco szybkie.

That said, nothing prevents you from making use of composition in your project by creating child Nodes with individual scripts. These nodes can then be added and removed at runtime to dynamically add and remove behaviors.

Więcej informacji na temat wyborów projektowych w Godot można znaleźć w tym artykule.

Why does Godot not force users to implement DOD (Data-Oriented Design)?

While Godot internally attempts to use cache coherency as much as possible, we believe users don't need to be forced to use DOD practices.

DOD is mostly a cache coherency optimization that can only provide significant performance improvements when dealing with dozens of thousands of objects which are processed every frame with little modification. That is, if you are moving a few hundred sprites or enemies per frame, DOD won't result in a meaningful improvement in performance. In such a case, you should consider a different approach to optimization.

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.

If a game needs to process such a large amount of objects, our recommendation is to use C++ and GDExtensions for performance-heavy tasks and GDScript (or C#) for the rest of the game.

Jak mogę wesprzeć rozwój Godota?

See How to contribute.

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

See the corresponding page on the Godot website.