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)

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

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.

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 intentionally does not include features that can be implemented by add-ons unless they are used very often. One example of this would be advanced artificial intelligence functionality.

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

  • Code maintenance and surface for bugs. Every time we accept new code in the Godot repository, existing contributors often take the reponsibility of maintaining it. Some contributors don't always stick around after getting their code merged, which can make it difficult for us to maintain the code in question. This can lead to poorly maintained features with bugs that are never fixed. On top of that, the "API surface" that needs to be tested and checked for regressions keeps increasing over time.

  • Ease of contribution. By keeping the codebase small and tidy, it can remain fast and easy to compile from source. This makes it easier for new contributors to get started with Godot, without requiring them to purchase high-end hardware.

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

Is it possible to use Godot to create non-game applications?

Yes! Godot features an extensive built-in UI system, and its small distribution size can make it a suitable alternative to frameworks like Electron or Qt.

When creating a non-game application, make sure to enable low-processor mode in the Project Settings to decrease CPU and GPU usage.

That said, we wouldn't recommend using Godot to create a mobile application since low-processor mode isn't supported on mobile platforms yet.

Check out Material Maker and Pixelorama for examples of open source applications made with Godot.

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.

What user interface toolkit does Godot use?

Godot does not use a standard GUI toolkit like GTK, Qt or wxWidgets. Instead, Godot uses its own user interface toolkit, rendered using OpenGL ES or Vulkan. 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.

This custom toolkit makes it possible to benefit from hardware acceleration and have a consistent appearance across all platforms. On top of that, it doesn't have to deal with the LGPL licensing caveats that come with GTK or Qt. Lastly, this means Godot is "eating its own dog food" since the editor itself is one of the most complex users of Godot's UI system.

This custom UI toolkit can't be used as a library, but you can still use Godot to create non-game applications by using the editor.

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.