Z trzema kolegami zrobiliśmy w tydzień gierkę na Scream Jam 2025 na itch.io. Jest to pierwsza gra, którą stworzyliśmy i nie udało się zrobić wszystkiego, co zaplanowaliśmy, ale i tak się pochwalę. Daliśmy z siebie nawet troszkę więcej, niż 30%.
A ja z przyjemnością mogę oznajmić, że dopiero co wydaliśmy nową wersję Godot Rusta, o!
Głodot Rust to, w dużym skrócie, biblioteka która pozwala gadać z Godotem po rustowemu – skupiamy się na tym żeby szybko, efektywnie, bezpiecznie i przyjemnie dało się dostarczać ten słynny value, zamiast bezsensownie utykać. Zero boilerplate, zero rozkmin, większość abstrakcji ułożone tak jak w gdscripcie, siadasz i robisz co trzeba .
W tej wersji wpadły usprawnienia do eksportów, QoL ficzery do Godotowych Callable, `match_class!` do łatwego matchowania danego eventu, ostatnie szlify silnie typowanych sygnałów… i duuuuuuuuuuuużo innych usprawnień >:].
skupiamy się na tym żeby szybko, efektywnie, bezpiecznie i przyjemnie
To szybko i przyjemnie czy w Rustcie? Bo mi tu kolidują te słowa ze sobą xD.
A tak na poważnie bo nie jestem totalnie w temacie. Czy gry napisane w tym będą działać jakoś znacznie szybciej niż napisane w tym czym się domyślnie pisze w Godocie? No bo z tego co pamiętam to Godot używał czegoś podobnego do Pythona, no i to na pewno ma dużo mniejszy próg wejścia niż Rust, więc ciekawi mnie czy warto się męczyć z Rustem. Robił ktoś jakieś porównania wydajności, benchmarki itp?
@Catharsis Kolejna edycja będzie poświęcona wydajności (pozwolimy w końcu na warunkowe zdejmowanie safety checków: https://github.com/godot-rust/gdext/pull/1278 co oznacza prędkość taką jak w godot-cpp), to wtedy nabazgram parę benchmarków i porównań – ale krótko mówiąc zapierdala, GDScript jest tak wolny, że rust potrafi wycisnąć znacząco więcej nawet z wszystkimi safety checkami w debugu (...debug jest niezoptymalizowany, a safety checki drogie). W zależności od tego co robisz można spodziewać się że w release, bez safety checków, będzie od 20% do paru rzędów wielkości szybciej (w jednym skrajnym wypadku – pic rel – ktoś zobaczył speedup paru rzędów wielkości co jest absurdalne, kumpel z rogalem z 800 FPS przeszedł do 1400 FPS, https://github.com/Houtamelo/spire_enum bez checków jest w pewnych scenariuszach (interpolowanie zmiennych zdefiniowanych w klasach, nie skryptach czy shaderach) szybszy od natywnej implementacji) – im więcej rzeczy robisz w userspace (skryptach/swoich klasach) tym większa różnica na korzyść GDExtension.
ALE GDScript jest gut enuf do większości gier, gdzie tylko kawałki koniecznie trzeba robić w GDExtension czy modułach – osobiście korzystam z rusta bo przyjemniej mi się w nim klepie (rustowe enumy to powinien być standard, okołofunkcyjne rzeczy są deliszys, iteratory kocham, fearless concurrency to nie mem, no i silne typowanie jest bardzo przyjemne) i staramy się jak najbardziej usprawnić ergonomię. Dla kogoś kto nie klepie w ruście może to brzmieć dziwnie, rozumiem, bo sam reaguję tak na ludzi co lubią klepać w cpp :D.
No i klasy w GDExtension to też pełnoprawne klasy w rozumieniu Godota – więc można do nich normalnie doczepiać skrypty.
Myślę że wychodzi git, bo ludzie którzy przychodzą często nie porównują ergonomi godot-rusta z godot-cpp czy modułami, a właśnie z gdscriptem i C#, gdzie często wychodzimy na tym tle korzystnie.
Czy jest tu ktoś, kto używał SHADOW_VERTEX albo LIGHT_VERTEX w shaderach typu canvas_item w #godotengine ?
Chciałem zrobić aby cień na objekcie się układał zgodnie z height map. Problem jest taki, że odwzorowanie jest jakieś dziwne i cień mi się przesuwa razem z zoom i tego typu problemy. Myślałem, że to projekcja w canvas lub screen, ale używałem tych macierzy i nie uzyskałem dobrego wyniku. Testowałem prostymi ifami jakiego to rodzaju wartości i wygląda, że w pikselach bo maksymalna wartość to raczej nie 1, a bardziej kilka tysięcy.
Jak ja lubię pisać shadery Kiedyś pisałem coś podobnego na tilemap, ale okazało się, że nie da się pewnych rzeczy rozwiązać bez modyfikowania kodu #godotengine
Więc jeszcze raz, ale tym razem jest jeden sprite, a shader rysuje teksturkę, transfirnację do widoku izometrycznego no i modyfikuje wysokość. Liczy normal mapę na podstawie tekstury terenu i używa tego w LIGHT. Efekt na filmiku.
Nikt nie prosił i nikt nie potrzebował. Ale muszę przyznać, że lubię się bawić shaderami, szczególnie tymi do 2D. Po głowie chodzi mi taki co wygeneruje cały teren zamiast używać jakichś tam teksturek na sprity. Niezbyt to potrzebne bo w sumie jest pełno podobnych rozwiązań dla 3D opartych na VERTEX. Ja jednak bawię się tylko w malowanie. Domyślam się, że pojawią się problemy jak z_order i inne pierdoły przez to. Ale i tak podoba mi się gimnastyka dla głowy, gdzie trzeba wymyślić jak to powinno działać.
Podzieliłem całe UV na tile i tego ile ich jest jest sterowane pewnym parametrem. Zaś każdy tile może być początkiem trawy. Trawa zaś ma również pewnym parametrem ustawioną maksymalną wysokość w kaflach. Następnie nakładam pewien szum, dla określonej wartości "sadzę" trawę, a wszystkie kafle (do max wysokości trawy) powyżej muszą wykryć, że gdzieś tam w dole jest sadzonka. Jeśli jest to rysujemy uwzględniając siłę wiatru i kilka losowych parametrów jak przesunięcie trawy na osi X (aby się nie układały w rzędach) czy też wysokość i kolor. Efekt końcowy w filmiku. Jeszcze jest pewnie kilka rzeczy, które muszę tam dorobić, ale jak na kilka godzin zabawy wczoraj to i tak jestem zadowolony
Czasem w wolnym czasie lubię się pobawić w godot. Szczególnie lubię zabawę shaderami. W sumie to jeszcze nie wiem co dokładnie piszę, ale pewnie jakieś 2d ekonomiczne lub builder. Wymyśliłem sobie, że podoba mi się efekt jaki był w settlers 3/4 dla ukształtowania terenu. Nie wiem jak oni to zaimplementowali, ale postanowiłem zrobić tilemap + shader, który odpowiada za ustawienie wysokości vertexów poprzez sampler2d z ukształtowaniem terenu oraz dodatkowo modyfikuje kolory tak aby uzyskać efekt oświetlonych/zacienionych wzniesień. Wiem, że pewnie dałoby radę to zrobić łatwiej w 3D, ale jakoś spodobał mi się ten pomysł i nie chcę rezygnować. Jednak natrafiłem na pewien problem. Gdy zmieniam pozycję vertexów to nie wszystko się renderuje. Domyślam się, że chodzi o to, że godot nawet nie próbuje renderować tego co jest poza ekranem, a że ja w shaderze podniosłem teren o 100px to już go nie interesuje. Da się jakoś zmienić obszar jaki ma renderować? tak aby jeszcze dodatkowo kilka rządków renderował?
#gamedev #godotengine
@Eichen_Y sorki, że wołam, ale pewnie jesteś w stanie pomóc.
@dotevo - bawię się w Godota i bawię się w shadery - ale niestety nie wiem jak Twój problem rozwiązać (zwłaszcza, że nie mam teraz dostępu do swojego głównego kompa to nie mogę poeksperymentować).
Ale nie o tym chciałem...
Nie mogę przeboleć, że fajne techniczne posty, nawet niekoniecznie o gamedevie zdobywają na hejto coraz mniej piorunów i komentarzy
Unity odwalił samobója jak wykop. Teraz tysiące wymiataczy przyjrzało się godot engine co zaowocowało setkami materiałów i rozwiązań pod ten silnik. Puchnie mi folder z zakładkami, a o to kilka ciekawych wątków
Czy Godot nadaje się do tworzenia gier multiplayer:
@Aryo generalnie jak Akien i Julian podkreślają – Godot nie jest perfekcyjny, a 4.x ciągle jest w dość wczesnym stadium (niedo)rozwoju. C# to drugorzędny obywatel względem gdscripta (patrz: https://sampruden.github.io/posts/godot-is-not-the-new-unity/ ) i ma dużo dość kryczynych bugów (większość krytycznych ma być załatana w 4.2). 4.0 zostało zdecydowanie za szybko wydane – nie jest nawet w 10% tak źle jak przy 3.0, ale 4.1 ciągle ledwo nadaje się do dowiezienia prawdziwego produktu.
Niemniej dużo ludzi jest w stanie znieść lekkie niedociągnięcia i niedogodności, bo nagle zaczęło doceniać bycie właścicielem własnych narzędzi. Unity straciło na tyle dużo zaufania, że już raczej nie wróci do łask wśród indie devów – trzymanie swojej kariery w rękach bezdusznej korporacji to dość średni pomysł.
@DEAFCON_ONE Długa droga przed nim, chociaż ja przy nim siedzę od wersji 2.0 więc progres widzę ogromny. Jest jakoś 5-6 lat zacofany względem Unity, ale z nową falą użytkowników może to ulec szybkiej poprawie.
@Aryo ja zainteresowałem się krótko przed 3.0, bo znajomy kontrybutował do silnika (jeden z tych którzy trzasnęli drzwiami po niesłynnej kłótni z Julianem). I zgodzę się, że w ciągu tych 4-5 lat zrobili ogromny progress pod każdym możliwym względem.
@Aryo napisałbyś raz na jakiś czas update o Ukrainie, jak im idzie. Podsumowanie tygodnia, albo miesiąca... albo podaj linka do swojego bloga, bo zdaje się, że stworzyłeś coś na wordpress, nie?
Nie mogę sobie poradzić z pewną rzeczą w Godot4. Mam stworzoną scenę, która reprezentuje dowolną postać. Składa się z AnimatedSprite2D, kolizji, nawigacji i tego typu rzeczy. Chciałem, aby SpriteFrames ustawiało się na poziomie sceny z poziomem. Użyłem więc:
@export var sprite: SpriteFrames
i ustawiam .frames w ready. Ale edytor mi się cały czas pluje, że AnimatedSprite2D potrzebuje SpriteFrames na poziomie sceny postaci. W sumie logiczne bo skąd ma wiedzieć, że ustawiam to w ready. Jest jakiś inny sposób aby to zrobić? Tak aby powiedzieć, że parametr dla AnimatedSprite2D ustawia się na poziomie głównego węzła (rodzic w tym przypadku)?
Niewiem jak wy ale cięzko było przejść z Unity na GodotEngine.
Ten silnik ma wiele takich quirków i dziwnych ficzerów, co czasami trzeba stanąć na głowie by coś działało jak chcemy,
gdzie w unity to jest zrobione przejrzyscie.
Np.: jak chcemy zanimować tilesy do tilemapu, to żeby to szybko działało to trzeba stworzyć shader gdzie np będą 3 klatki dla wszystkich tilesów gdzie twoja tekstura jest podzielona na 3 rzędy kazda inna klatka. AnimatedTexture które reduz kiedyś na twitterze polecał by użyc do tilemapów to beznadzieja bo batching przy tym niedziała. Bo każda tekstura jest osobnym plikiem. A Atlasy w AnimatedTexture niedziałały. Naszczęscie w Godot 4 to jest to już rozwiązane i mozna robić animowane tilesety.
Albo też tekstury jak chcesz wybrać to pomiędzy WebP, Uncompressed, i Compressed. Nieidzie wybrać ze chce np mieć R4G4B4A4, bo wszystko tam jedzie na RGBA32. Gdzie w unity jest normalny wybór formatów tekstur.
Jak chcemy np stworzyć grafika na bazie palety 256. To musimy mieć najlepiej taki format jak R8, L8, A8 czy coś w ten deseń a tego nieda sie wybrać.
nie mam porównania bo w unity kiedyś jeden dzień się bawiłem. Ale właśnie ogarniam różne rzeczy w godot4 i pewnie animowane tekstury też będę robić niebawem. Miło, że jest zrobione już.
Dobra... wiem, że to co robię jest bez sensu bo mógłbym zrobić to szybciej i pewnie łatwiej w 3D, ale i tak efekt mi się podoba. Zrobiłem możliwość zmieniania wysokości kafli na tilemap (2D) przy pomocy shaderów. Dodatkowo jest tam wyliczanie nachlanie kafla do słońca, dzięki czemu mam tam kilka parametrów jak kierunek padania promieni słonecznych oraz kolor światła. Mała rzecz, a cieszy - był to też dobry trening dla mózgu
Siema, jestem programistą od 15 lat, a licząc, że zaczynałem programować w podstawówce to ze 25lat. W czasach gdy bawiłem się w tworzenie gier używało się SDL i wszystko pisało się z palca, te czasy są już daleko za nami i teraz chyba mało kto tak robi gry. Ostatnio postanowiłem, że napiszę prostą grę, którą będę sobie rozbudowywać w ramach nauki. Wybrałem silnik Godot i zacząłem wrzucać różne rzeczy. I ni c⁎⁎ja mi to nie idzie, po kilku godzinach udało mi się tilemapy porobić. Chyba jestem powoli na to za stary i łatwiej byłoby mi napisać to w C++.
Macie jakieś fajne poradniki do godot 2d? Te na YT są słabe, a dokumentacja zawiera za dużo informacji na początek. Chce zrobić prosty builder w 2d izometrycznym, a utknąłem już na tym jak zrobić proste wykrywanie kliknięcia na warstwie z tiles...
@dotevo Zamiast tutoriali polecam przeglądać opensourcowe projekty, szybciej się można IMHO nauczyć. Preferencyjnie przepisywać GDScript do C# (dużo lepsza kontrola nad kodem).
@Aryo założył tag #godotengine więc nie mogę nie wjechać również ze swoim side projektem który zacząłem niedawno w wolnym czasie klepać.
Szczerze póki co nie wiem co to jest xD ale celuję w coś a'la immersive sim.
Okodowany jako taki movement, podstawowy HUD, podnoszenie/upuszczanie przedmiotów, interakcje z obiektami (tu widoczny vent) i system notek które można sobie czytać. Świat oparłem na mapach w formacie Quake'a dzięki wykorzystaniu pluginu TBLoader (odpowiednik Qodota dla Godota 4.0) i edytora Trenchbroom.
Następny krok - wiele opcji interakcji per obiekt, a potem animowani NPC z jakimś wstępnym AI.
@Aryo Miło to słyszeć! nie wiem czy tak zostanie bo na konkretną tematykę jeszcze się nie zdecydowałem, ale na tę chwilę inspirowałem się m.in. przesaturowanymi peerelowskimi pocztówkami.
@pierogo Liczę na więcej filmików, bo to już teraz ma duży potencjał! Przesaturowane peerelowskie pocztówki w połączeniu z immersive simem przywodzi mi na myśli Peripetię (Post-Soviet Cyberpunk Poland) - https://store.steampowered.com/app/1437760/Peripeteia/
Mało osób wie, że jestem studentem informatyki. To będzie trzeci dyplom, jaki chcę zrobić. Aktualnie piszę mini grę na bazie silnika Godot Engine do swojej pracy Inżynierskiej.
Chwilowo tworzę prototyp proceduralnego generowania świata, zrobiłem animacje głównej postaci i logikę poruszania w GDScript, ale chyba przepiszę do C#
Zakładam więc tag #godotengine dla tego wspaniałego silnika do gier.
Wieczorowo, zaocznie? Nie planujesz się przebranżawiać dla lepszej kasy?
Geologia licencjat, magister
Infromatyka inż zaocznie - dzieci praca itd
Nie planujesz się przebranżawiać dla lepszej kasy?
Pracuję w IT od pierwszych dni studiów informatycznych, czyli z 3 lata już leci. Geologia, szeroko rozumiana informatyka, historia, języki obce to moje hobby. W każdym jestem średniakiem, ale lubię to, co robię. W kwestii $ to nie wypowiem się. Od lutego 2022 r. oszczędności przewalam na pomoc i wolontariat dla Ukrainy, więc podwyżek raczej bym nie poczuł
Bawię się godotem jakoś od ~półtorej roku, obecny projekt robię w gdnative i ruście – pierwszy raz podchodziłem przy wydaniu 3.0 i to był pożar burdelu (issue na githubie z jednego tygodnia zajmowały z pięć stron i to nie były problemy w stylu "ficzer nie działa", ale "edytor crashuje jak próbuję cokolwiek zrobić"; były podejrzanie pachnące pliki pełne magicznych liczb i długie na 5k linii; z kolei unit testy do samego silnika – SILNIKA! – dodano dopiero w 4.0…). Bardzo, bardzo dużo poprawiło się od tego czasu – ciągle da się nadziać na parę dziwnych zachowań (EKHE, mask/light2D), ale częściej narzekam na elementy znajdujące się między krzesłem a klawiaturą, niż na sam silnik.
(...) W kwestii 3D to Godot 4.0 sporo zmienia w tej kwestii, ale i projekty 2D łatwiej będzie prowadzić, bo np. całkiem przeprojektowano sposób tworzenia tilemap, ale ja nie buduję gry na "czwórce" tylko na wersji 3.5 bo do inżynierki lepiej na czymś stabilnym pracować
@Aryo 3.5 też bardzo dużo poprawiło – mamy nowy navigation server który w końcu pozwala sensownie robić jumplinki (a przy okazji dobrze działa, wspiera agent avoidance i łatwo z niego korzystać), mamy parę różnych occlusion nodes, dostaliśmy też physics Interpolation (dzięki czemu w końcu nie trzeba pisać masy boilerplate). Bullet – silnik fizyki godota 3 – czasami potrafi zrobić krzywdę (w jednym pobocznym projekcie męczyłem się 3 dni z przedmiotami wypadającymi przez ściany :P), ale ogólnie jest całkiem całkiem nieźle.
Może i wszystko wygląda jak gry z poprzedniej generacji, ale przynajmniej słabo działa!