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ć i używać Godota w dowolnym celu: prywatnym, komercyjnym, non-profit 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)

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.

Istnieją udane kompilacje Godot na systemach opartych o architekturę ARM na Linuksie, przykładowo 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 go używać?

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 swojego 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?

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

  1. Słaba obsługa wątków w większości maszyn wirtualnych skryptów, a Godot używa wątków (Lua, Python, Squirrel, JS, AS, itp.).
  2. Słabe wsparcie dla klas w większości skryptowych maszyn wirtualnych i dostosowanie do sposobu działania Godota jest wysoce nieefektywne (Lua, Python, JS).
  3. Wiele istniejących języków ma okropne interfejsy do wiązania z C++, co skutkuje dużą ilością kodu, błędów, bottleneck’ów i ogólnej nieefektywności (Lua, Python, Squirrel, JS, itp.). Chcieliśmy skupić się na świetnym silniku, a nie na dużej ilości integracji.
  4. Brak natywnego wsparcia dla typów wektorów (vector3, matrix4, itd.). sktutkuje znacznym zmniejszeniem wydajności kiedy używa się własnych typów (Lua, Python, Squirrel, JS, AS, itd.).
  5. Odśmiecacz pamięci skutkuje niepotrzebnie dużym użyciem pamięci (Lua, Python, JS, AS, itd.).
  6. Trudności ze zintegrowaniem z edytorem kodu funkcji auto uzupełniania, edycji w czasie rzeczywistym, itd. Są one bardzo dobrze wspierane przez GDScript.

GDScript został zaprojektowany tak żeby zminimalizować te problemy.

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

Godot wspiera pliki Collada przez`OpenCollada <https://github.com/KhronosGroup/OpenCOLLADA/wiki/OpenCOLLADA-Tools>`_ exporter (Maya, 3DSMax).

Jeśli korzystasz z Blendera zapoznaj się z stworzony przez nas Better Collada Exporter.

Dla Godot 3.0 istnieje wsparcie dla glTF.

FBX SDK has a restrictive license, that is incompatible with the open license provided by Godot. That being said, FBX support could still be provided by third parties as a plugin. (See Plugins question below.)

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, które jest third-party, posiada zamknięte źródło czy jest własnościowe. Integrowanie tego z rdzeniem Godot’a byłoby przeciwne etyce 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.

Żeby zobaczyć jak support Twojego wyboru SDK nadal są dostarczane , wejdź w zakładkę „wtyczki,, 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 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 tak wiele osób podążyło tą drogą. Początkowo działało to do pewnego stopnia i tylko na urządzenia Apple, ale następnie powstało kilka urządzeń z systemem Android i 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.

Chciałbym przyczynić się 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, zwłaszcza 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 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 wzmocnienie komunikacji między członkami społeczności Godot.

Większość deweloperów 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.
  • Co było trudne do zrozumienia podczas nauki Godota.
  • 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).

Dlaczego Godot nie używa STL (standard Template Library)

Like many other libraries (Qt as an example), Godot does not make use of STL. 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.
  • Most of our containers cater to special needs, like Vector, which uses copy on write and we use to pass data around, or the RID system, which requires O(1) access time for performance. Likewise, our hash map implementations are designed to integrate seamlessly with internal engine types.
  • Our containers have memory tracking built-in, which helps better track memory usage.
  • For large arrays, we use pooled memory, which can be mapped to either a preallocated buffer or virtual memory.
  • We use our custom String type, as the one provided by STL is too basic and lacks proper internationalization support.

Why does Godot not use exceptions?

We believe games should not crash, no matter what. If an unexpected situation happens, Godot will print an error (which can be traced even to script), but then it will try to recover as gracefully as possible and keep going.

Additionally, exceptions significantly increase binary size for the executable.

Why does Godot not enforce RTTI?

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

Why does Godot not force users to implement DoD (Data oriented Design)?

While Godot internally for a lot of the heavy performance tasks attempts to use cache coherency as best as possible, we believe most users don’t really need to be forced to use DoD practices.

DoD is mostly a cache coherency optimization that can only gain you significant performance improvements when dealing with dozens of thousands of objects (which are processed every frame with little modification). As in, if you are moving a few hundred sprites or enemies per frame, DoD won’t help you, and you should consider a different approach to optimization.

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

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

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.