Up to date

This page is up to date for Godot 4.2. If you still find outdated information, please open an issue.

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

Zespół Godota nie może zapewnić eksportu na konsole ze względu na warunki licencyjne nałożone przez producentów konsol. Niezależnie od tego, jakiego silnika używasz, wydawanie gier na konsole zawsze wymaga dużo pracy. Więcej na ten temat możesz przeczytać tutaj: Console support in Godot.

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 to zintegrowany język skryptowy Godota. Został stworzony od podstaw, by zmaksymalizować potencjał silnika, używając jak najmniejszej ilości kodu. Ma to pozwolić możliwie jak najszybciej wykorzystać mocne strony Godota zarówno przez doświadczonych jak i nowych programistów. Jeżeli kiedyś programowałeś 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 wczesnym etapie projektu lub gdy nie tworzysz kolejnego tytułu AAA. Najbardziej istotnym powodem jest ogólna ** redukcja złożoności**.

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.

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 jest potężny, oraz 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, 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.

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:

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

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.

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

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, 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ę, prawdopodobnie będziemy pracować nad silnikiem renderującym Direct3D 12 dla Godota (głównie na potrzeby Xbox'a) lecz Vulkan i OpenGL pozostaną domyślnymi renderującymi backend-ami na wszystkich platformach, wliczając Windowsa.

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?

Uruchamianie kodu w edytorze.

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

Rekomendujemy używanie Godot 4.x w przypadku nowych projektów, ale w zależności od zestawu funkcji, których potrzebujesz, czasem lepszym rozwiązaniem może okazać się użycie wersji 3.x. Zobacz doc_release_policy_ Which_version_should_i_use, aby uzyskać więcej informacji.

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.

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.

Wyjaśniamy, jak pracować ze źródłem silnika, jak edytować dokumentację i jakie są inne sposoby wnoszenia swojego wkładu, wszystko to znajdziesz w naszej dokumentacji dla autorów.

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.

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.

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.

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.

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.

Niemniej nic nie stoi na przeszkodzie, abyś preferował kompozycję ponad dziedziczenie w swoim projekcie, tworząc węzły podrzędne z indywidualnymi skryptami. Węzły te można później dodawać i usuwać w czasie działania gry, aby zmieniać powiązane z nimi zachowania.

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?

Zobacz Metody wspierania.

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

Zobacz stronę do kontaktu Kontakt - Godot.