Metody wspierania

Godot Engine jest projektem non profit, kierowanym przez społeczność, wolnym i otwarto-źródłowym. Prawie wszyscy (oprócz głównego dewelopera Juana, więcej na ten temat poniżej) deweloperzy pracują pro bono w swoim czasie wolnym, z osobistego zainteresowania i z miłości do tworzenia wolnego i otwartego silnika o wyjątkowej jakości.

Oznacza to, że aby dobrze się rozwijać, Godot potrzebuje jak największej liczby użytkowników zaangażowanych we wspieranie silnika. Istnieje wiele sposobów, aby pomóc w tak dużym projekcie, dzięki czemu każdy będzie mógł wnieść do silnika coś pozytywnego, niezależnie od zestawu swoich umiejętności:

  • Bądź częścią społeczności. Najlepszym sposobem, aby przyczynić się do rozwoju Godota i pomóc mu stać się jeszcze lepszym jest po prostu używanie silnika i promowanie go ustnie, w napisach końcowych lub ekranie powitalnym Twoich gier, w postach na blogu, poradnikach, materiałach wideo, demach, na wydarzeniach związanych z gamedevem lub wolnym oprogramowaniem, poprzez wsparcie w Q&A, na forach, Czacie Wspierających, Discordzie, itp. Dołącz do nas! Bycie użytkownikiem i zwolennikiem pomaga rozpowszechniać informacje na temat naszego wspaniałego silnika, który nie ma budżetu na marketing i dlatego może polegać tylko na swojej społeczności, aby stać się bardziej popularnym.

  • Twórz gry. Nie jest tajemnicą, że aby przekonać nowych użytkowników, a w szczególności ogólnie pojętą branżę, że Godot jest istotnym graczem na rynku, potrzebujemy świetnych gier zrobionych w Godocie. Wiemy, że silnik ma duży potencjał, zarówno dla gier 2D jak i 3D, ale biorąc pod uwagę jego młody, wiek wciąż brakuje nam dużych produkcji, które zwrócą uwagę na Godota. Kontynuuj więc prace nad Twoimi wspaniałymi projektami, każda nowa gra zwiększa naszą wiarygodność na rynku gier!

  • Zaangażuj się w rozwój silnika. Może to być poprzez dodawanie kodu przez pull requesty, testowanie wydań deweloperskich lub bezpośrednio gałęzi master z gita, zgłaszanie błędów lub sugerowanie ulepszeń w issue trackerze, ulepszanie oficjalnej dokumentacji (zarówno referencji klas jak i poradników) oraz jej tłumaczeń. Kolejne sekcje obejmują każdy z tych "bezpośrednich" sposobów wspierania silnika.

  • Wesprzyj finansowo. Godot jest projektem non profit, ale do wielu rzeczy nadal może korzystać z darowizn od użytkowników. Poza zwykłymi wydatkami, takimi jak koszty hostingu lub materiały promocyjne na wydarzeniach, w razie potrzeby wykorzystujemy również pieniądze z darowizn do nabycia sprzętu (np. użyliśmy darowizn na zakup MacBooka Pro w celu wdrożenia obsługi Retina/HiDPI i różnych innych funkcji związanych z macOS). Co najważniejsze, pieniądze z darowizn przeznaczyliśmy również na zatrudnienie kluczowych deweloperów, aby mogli oni pracować przy silniku na pełnym etacie. Nawet przy niskich miesięcznych płacach, potrzebujemy stałego dochodu z darowizn, aby nadal tak robić, co do tej pory było dla projektu bardzo korzystne. Jeśli więc chcesz przekazać trochę pieniędzy na projekt, sprawdź naszą stronę, aby znaleźć więcej szczegółów.

Pisanie kodu silnika

Możliwość studiowania, używania, modyfikacji i redystrybucji modyfikacji kodu źródłowego silnika to fundamentalne prawa, które daje Ci licencja MIT Godota, czyniąc go wolnym i otwartym oprogramowaniem.

Skoro tak, to każdy jest uprawniony do modyfikacji kodu źródłowego Godota, oraz wysyłania tych modyfikacji z powrotem do pierwotnego projektu, w formie patcha (pliku tekstowego opisującego zmiany w gotowy do zastosowania sposób), lub - we współczesnym cyklu pracy, który wykorzystujemy - przez tak zwany "pull request" (PR), np. propozycję bezpośredniego połączenia jednego lub więcej commitów Gita (patchy) z główną gałęzią deweloperską.

Pisanie oficjalnych zmian w kodzie silnika ma dwie duże zalety:

  • Twój własny kod będzie zrewidowany i ulepszony przez innych deweloperów i będzie dalej utrzymywany już bezpośrednio w głównym projekcie, więc nie będziesz musiał ponownie aplikować swoich własnych zmian za każdym razem, kiedy przenosisz się do nowszej wersji. Z drugiej strony wiąże się to z odpowiedzialnością, jako że Twoje zmiany muszą być wystarczająco ogólne, aby były przydatne dla wszystkich użytkowników, a nie tylko dla Twojego projektu; więc w pewnych wypadkach wciąż może być właściwe zachowanie swoich zmian tylko do własnego projektu, jeśli są one zbyt specyficzne.

  • Cała społeczność odniesie korzyści z twojej pracy, a inni wspierający będą zachowywać się w ten sam sposób, tworząc kod, który będzie korzystny dla ciebie. W czasie pisania tego tekstu, zmiany w kodzie silnika wprowadziło ponad 1000 deweloperów!

Aby zapewnić dobrą współpracę i ogólną jakość, twórcy Godota narzucają pewne zasady dotyczące pisania kodu, na przykład odnośnie stylu używanego w C++ (wcięcia, nawiasy itp.) lub sposobu pracy z Git i PR.

Dobry sposób, aby zacząć to wyszukanie na GitHubie problemów oznaczonych jako good first issue.

Zobacz także

Szczegóły techniczne na temat sposobu pracy z PR nakreślone są w odrębnej sekcji, Pull request workflow.

Szczegóły na temat wytycznych stylu kodu oraz narzędzia clang-format używanego do ich egzekwowania są nakreślone w sekcji Styl pisania kodu źródłowego Godota.

Wszystkie pull requesty, zanim zostaną zaakceptowane, muszą przejść przez proces rewizji. Zależnie od zakresu zmian, dokonanie przeglądu osobie odpowiedzialnej za zmodyfikowaną część silnika może zająć trochę czasu. Tymczasem cenimy wszystkich naszych wspierających i prosimy ich o cierpliwość, ponieważ można się spodziewać, że w projekcie otwarto-źródłowym, takim jak Godot, będzie dużo więcej wspierających, niż ludzi ich sprawdzających.

Aby upewnić się, że Twój czas i wysiłek nie pójdzie na marne, zaleca się najpierw zweryfikować pomysł przed jego implementacją i umieścić go do recenzji jako PR. W tym celu Godot posiada system propozycji. Zachęca się do jego użycia w celu zaplanowania zmian i omówienia ich ze społecznością. Na Czacie Wspierających Godota można także przedyskutować z innymi wspierającymi szczegóły implementacyjne.

Informacja

Propozycje są wymagane tylko w przypadku pracy nad udoskonaleniami i nową funkcjonalnością. W celu naprawy problemów wystarczą zgłoszenia błędów.

Testowanie i zgłaszanie problemów

Innym świetnym sposobem na udoskonalenie silnika jest testowanie wersji rozwojowych lub gałęzi rozwojowej i zgłaszanie problemów. Pomocne jest również zgłaszanie problemów wykrytych w stabilnych wersjach, tak aby w gałęzi rozwojowej i przyszłych wersjach użytkowych można je było naprawić.

Testowanie wersji deweloperskich

Masz kilka możliwości by pomóc z testowaniem:

  • Skompiluj samodzielnie silnik ze źródła, postępując zgodnie z instrukcjami dla Twojej platformy na stronie Kompilowanie.

  • Testuj oficjalne przedpremierowe wydania tuż po ich ogłoszeniu (zazwyczaj na blogu i innych platformach społecznościowych), takie jak kompilacje alfa, beta i kandydaci do wydania (RC).

  • Testuj "zaufane" nieoficjalne kompilacje gałęzi rozwojowej; po prostu zapytaj członków społeczności o wiarygodnych dostawców. Jeśli to tylko możliwe, najlepiej jest użyć oficjalnych plików binarnych lub jednak skompilować samemu, aby mieć pewność ich pochodzenia.

Jak wspomniano poprzednio, dobrze jest także mieć oczy szeroko otwarte na potencjalne błędy, które wciąż mogą być obecne w stabilnych wersjach, zwłaszcza podczas używania jakichś niszowych funkcjonalności silnika, które mogą być słabiej przetestowane przez deweloperów.

Zgłaszanie problemu na GitHubie

Godot, do zgłaszania błędów i sugerowania ulepszeń wykorzystuje narzędzie na GitHubie do śledzenia problemów. Aby być w stanie otworzyć tam nowe zgłoszenie problemu i kliknąć w przycisk New issue, będziesz potrzebował konta GitHub.

Zgłaszając błąd, powinieneś pamiętać, że proces ten jest podobny do wizyty u lekarza. Zauważyłeś symptomy, które sprawiają, że myślisz, że coś może być nie tak (silnik się zacina lub wyłącza, niektóre funkcje nie działają zgodnie z oczekiwaniami, itp.). Zadaniem zespołu zajmującego się znajdowaniem błędów oraz deweloperów jest pomoc w postawieniu diagnozy problemu, z którym się spotkałeś, tak aby można było zidentyfikować i zająć się faktyczną przyczyną błędu.

Dlatego zawsze powinieneś zadawać sobie pytanie: jakie istotne informacje należy przekazać, aby inni wspierający Godota mogli zrozumieć błąd, zidentyfikować go oraz, miejmy nadzieję, naprawić. Oto kilka z najważniejszych informacji, które zawsze powinieneś podać:

  • System operacyjny Czasami błędy są specyficzne dla danego systemu, tzn. zdarzają się tylko w Windowsie, lub tylko w Linuxie, itp. Jest to szczególnie istotne dla wszystkich błędów związanych z interfejsami systemu operacyjnego, takimi jak zarządzanie plikami, wejście, zarządzanie oknami, dźwięk, itp.

  • Sprzęt. Czasami błędy są specyficzne dla sprzętu, tzn. zdarzają się tylko na niektórych procesorach, kartach graficznych, itp. Jeśli jesteś w stanie, pomocne może być umieszczenie informacji o Twoim sprzęcie.

  • Wersja Godota. Jest to niezbędne. Niektóre problemy mogą być istotne w aktualnym stabilnym wydaniu, ale naprawione w gałęzi deweloperskiej, lub na odwrót. Możesz również używać przestarzałej wersji Godota i doświadczać znanego problemu naprawionego w późniejszej wersji, więc wiedza o tym od samego początku pomaga przyspieszyć diagnozę.

  • Jak odtworzyć błąd. W większości przypadków, błędy są powtarzalne, tzn. możliwe jest ich odtworzenie za każdym razem po wykonaniu pewnych czynności. Prosimy zawsze jak najdokładniej opisywać te czynności, tak aby każdy mógł spróbować odtworzyć problem i go potwierdzić. Idealnie jest utworzyć projekt demonstracyjny, który od razu odtwarza dany problem, spakować go i dołączyć do zgłoszenia (można to zrobić przeciągając i upuszczając). Nawet jeśli uważasz, że problem jest trywialny do odtworzenia, dodanie minimalnego projektu, który każdemu pozwala go odtworzyć to duża wartość dodana. Musisz pamiętać, że zgłoszone są tysiące problemów, a deweloperzy mogą poświęcić niewiele czasu na każdy z nich.

Kiedy klikniesz przycisk New issue, powinieneś otrzymać pole tekstowe, wstępnie wypełnione naszym szablonem problemu. Proszę postarać się go przestrzegać, tak, aby wszystkie zgłoszenia były spójne i dostarczały wymaganych informacji.

Wspieranie dokumentacji

W Godocie istnieją dwa oddzielne zasoby zwane "dokumentacją":

  • Referencja klas Jest to dokumentacja całego API Godota dostępnego dla GDScript i innych języków skryptowych. Można do niej sięgać offline, bezpośrednio w edytorze kodu Godota, lub online pod adresem Godot API. Aby wesprzeć referencję klas, musisz edytować odpowiadający klasie plik XML i zrobić pull request. Po więcej szczegółów zajrzyj do sekcji Contributing to the class referenceClass reference writing guidelines.

  • Poradniki i dokumentacja silnika oraz ich tłumaczenia To ta część, którą teraz czytasz, a która jest rozpowszechniana w formacie HTML. Jej zawartość jest generowana z plików tekstowych w formacie reStructured Text (rst), do których rozwoju możesz się przyczynić poprzez pull requesty w repozytorium GitHuba godot-docs. Po więcej szczegółów zajrzyj do sekcji Wskazówki do dokumentacji.

Wspieranie tłumaczeń

By uczynić Godota dostępnym dla wszystkich, włączając użytkowników, którzy mogą preferować zasoby w swoim ojczystym języku a nie w angielskim, nasza społeczność pomaga tłumaczyć na wiele języków zarówno edytor Godota jaki i jego dokumentację.

Więcej szczegółów znajdziesz w sekcji Editor and docs localization.