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 supports Collada via the OpenCollada exporter (Maya, 3DSMax). If you are using Blender, take a look at our own Better Collada Exporter.

Dla Godot 3.0 istnieje wsparcie dla glTF.

FBX is supported via the Open Asset Import library. However, FBX is proprietary so we recommend using other formats listed above, if suitable for your workflow.

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)

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 spełnia specjalne potrzeby, na przykład Vector, który korzysta z funkcji kopiowania podczas zapisu i my używamy go do przekazywania danych, lub system RID, który wymaga czasu dostępu O (1) do wydajności. Podobnie, nasze implementacje hash map zostały zaprojektowane w celu płynnej integracji z wewnętrznymi typami silników.
  • Nasze kontenery posiadają wbudowane śledzenie pamięci, co pozwala na lepsze śledzenie zużycia pamięci.
  • W przypadku dużych tablic wykorzystujemy pamięć zbiorczą, która może być zmapowana do wstępnie przydzielonego bufora lub 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 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 znacznie zwiększają rozmiar pliku binarnego pliku wykonywalnego.

Dlaczego Godot nie wymusza użycia RTTI?

Godot dostarcza swój własny system rzutowania typów, który może opcjonalnie używać RTTI wewnętrznie. Wyłączenie RTTI w Godocie pozwala uzyskać znacznie mniejsze rozmiary plików binarnych, przy niewielkim spadku wydajności.

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

Podczas gdy Godot wewnętrznie, 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ękoszśc 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.