Przebranżowienie z Javy na Game Dev

Ktoś z was może przebranżawiał się na game dev z programowania "biznesowego"? Albo ktoś z waszych znajomych? Jakie macie doświadczenia z tym związane, jak to u was wyglądało? Osobiście wolałbym pracę przy większych produkcjach niż masowe wypuszczanie małych gierek w unity na smartphone'y nie podoba mi się też koncepcja HTML + JS. Nie wiem jakie przygotować sobie portfolio. Unity to C#, Unreal Engine to C++. Niektóre studia tworzą własne silniki do gier więc tutaj też C++. Co byłoby lepsze zrobić sobie kompletną grę w takim Unity czy Unrealu (nastawienie na konkretny silnik). Czy może w C++ jakiś silnik fizyki, grafiki np. z uzyciem Vulkan'a i przez to pokazać umiejętności jakie leżą u podstaw tworzenia gier?

Darth Bane napisał(a):

Osobiście wolałbym pracę przy większych produkcjach niż masowe wypuszczanie małych gierek w unity na smartphone'y

A programista świeżo po studiach chciałby zarabiać 20k...
Ty dopiero chcesz się przebranżowić, więc powinieneś być zadowolony jeśli gdziekolwiek Cię przyjmą.
A jeśli chcesz pracować przy większych produkcjach, to powinieneś mieć do tego odpowiedni background.

W Unity też powstają fajne gry PC. Np. SUPERHOT: https://store.steampowered.com/app/322500/SUPERHOT/

Darth Bane napisał(a):

Unity to C#

Dzięki czemu byłoby Ci blisko do Javy.

Darth Bane napisał(a):

Unreal Engine to C++.

Niekoniecznie.
Większość rzeczy lepiej zrobić blueprintami i mieć C++ głęboko w tyle.
Tak bezpieczniej, jeśli się nie umie za dobrze robić w C++.
Mniejsze ryzyko wycieków pamięci.

Darth Bane napisał(a):

Co byłoby lepsze zrobić sobie kompletną grę w takim Unity czy Unrealu (nastawienie na konkretny silnik).
Czy może w C++ jakiś silnik fizyki, grafiki np. z uzyciem Vulkan'a i przez to pokazać umiejętności jakie leżą u podstaw tworzenia gier?

Zależy co chcesz potem robić przy grach.
Jeśli chcesz pracować przy silniku u potencjalnego pracodawcy, to lepiej rób silnik.
Jeśli chcesz pracować przy gameplayu, to lepiej się wykazać, że potrafisz używać gotowego silnika i stworzyć w nim kompletną grę.
W większych firmach inny zespół pracuje nad silnikiem, inny nad gameplayem.

Myślę że musisz jednak zacząć od jakiegoś mniejszego własnego projektu. Dla javy jest bardzo fajny framework LibGDX - polecam, sam sporo w tym naklepałem

Jeśli chodzi o większe tytuły to faktycznie konieczna będzie jednak zmiana technologii i wejście w świat większych silników. Godot wydaje się niezłym startem, tak samo jak Unity.

Bez doświadczenia raczej nie ma szans na top firmy, chyba że w roli normalnego backenda - w końcu te gry też muszą mieć jakiś serwer, może firma ma własny sklep. Wtedy na zasadzie awansu poziomego możnaby szukać okazji, ale nie wiem czy tego szukasz

No i last but not least - gamedev to trudny rynek. Dużo pracy mało płacy

Cięzki moment na wejście do gamedevu teraz, wiele osób z doświadczeniem leży i kwiczy.
Obadaj sobie firmy w PL i ich ogłoszenia, większość ofert to Unreal lub Unity. Z Godota jeszcze niewiele.
Podstawy tworzenia / własny silnik - firm działających na własnym silniku w PL można policzyć na palcach; wiedza często przydatna (pomaga chociażby w optymalizacjach), natomiast nie kluczowa, raczej bym się na tym nie skupiał

Zalezy jakie gry chcesz robic, jesli faktycznei chcesz sie z tym zwiazac i robic gry AAA szedlbym w Unreala. Unity to raczej do neico mniejszych/prostszych produkcji. Ew. firmy maja czasa jakeis wewnetrzne engine'y ale wtedy lockujesz sie na jedna firme. Ew. poszukalbym czego uzywa konretna firma ktora mnei interesuje i przygotowal sie pod nia. Do tego jesli dobrze ogarniasz jeden silnik + wiesz jak sie robi rozne rzeczy w gamedevie, ew. przelaczenie na cos innego bedzie wzglednie szybkie.

Pytanie po co chcesz isc do gamedevu ? Bo poza jednym kumplem z CDRED odnosze wrazenie ze ta branza masakrycznie wypala ludzi.

Moim zdaniem jak ktoś chce startować do GameDevu to najlepiej jakby miał background modderski. Do Fallouta 4 czy Skyrima masz CreationKit, do Wiedźmina 3 masz RedKita - do obu znajdziesz playlisty na Youtubie jak z tym pracować. Unreala czy Unity masz za darmo na start ale w tym przypadku, dochodzi Ci problem assetowy IMHO. W przypadku modowania gier, masz na start i assety i podgląd na np. system questów/dialogów - jak to jest zrobione.

Jeśli chcesz po prostu zrobić grę to jest też godot, który ma ponoć najmniejszy próg wejścia z tych trzech. Możesz pisać w GDScript, C++, C#, Python, Rust, Nim, Go i innych językach przez rozszerzenia.
Wydaje mi się że najwięcej pracy znajdziesz w unity, ale wiele umiejętności tworzenia gier jest uniwersalnych i łatwo przenieść na inne silniki. Czemu stawiać na jeden konkretny?

Nie polecam zaczynać od własnego silnika, ja kiedyś chciałem w ten sposób wejść w branżę gier i przez 2 lata pisałem swój "silnik" gier 3d w C++, trzeba przyznać że bardzo dużo się w ten sposób nauczyłem i było to ciekawe i zajmujące doświadczenie ale zupełnie imo bezużyteczne w branży. Żeby robić swój silnik najpierw warto bardzo dobrze poznać jakiś istniejący, inaczej to błądzenie we mgle i wynajdowanie dziwnych rozwiązań od zera.
Gotowa gra w portfolio moim zdaniem robi większe wrażenie niezależnie od silnika niż niedokończony autorski silnik. Wątpię żeby ktokolwiek dał nowicjuszowi pracować nad silnikiem gry nastawionej na szybki release i sprzedaż, to raczej zajęcie dla wyjadaczy z wieloletnim doświadczeniem lub z kilkoma grami na koncie, ale jak masz takie ambicje i więcej niż 2 lata na eksperymenty i naukę to próbuj.

Spine napisał(a):

Darth Bane napisał(a):

Osobiście wolałbym pracę przy większych produkcjach niż masowe wypuszczanie małych gierek w unity na smartphone'y

A programista świeżo po studiach chciałby zarabiać 20k...
Ty dopiero chcesz się przebranżowić, więc powinieneś być zadowolony jeśli gdziekolwiek Cię przyjmą.
A jeśli chcesz pracować przy większych produkcjach, to powinieneś mieć do tego odpowiedni background.

W Unity też powstają fajne gry PC. Np. SUPERHOT: https://store.steampowered.com/app/322500/SUPERHOT/

Darth Bane napisał(a):

Unity to C#

Dzięki czemu byłoby Ci blisko do Javy.

Darth Bane napisał(a):

Unreal Engine to C++.

Niekoniecznie.
Większość rzeczy lepiej zrobić blueprintami i mieć C++ głęboko w tyle.
Tak bezpieczniej, jeśli się nie umie za dobrze robić w C++.
Mniejsze ryzyko wycieków pamięci.

Darth Bane napisał(a):

Co byłoby lepsze zrobić sobie kompletną grę w takim Unity czy Unrealu (nastawienie na konkretny silnik).
Czy może w C++ jakiś silnik fizyki, grafiki np. z uzyciem Vulkan'a i przez to pokazać umiejętności jakie leżą u podstaw tworzenia gier?

Zależy co chcesz potem robić przy grach.
Jeśli chcesz pracować przy silniku u potencjalnego pracodawcy, to lepiej rób silnik.
Jeśli chcesz pracować przy gameplayu, to lepiej się wykazać, że potrafisz używać gotowego silnika i stworzyć w nim kompletną grę.
W większych firmach inny zespół pracuje nad silnikiem, inny nad gameplayem.

Wiem wiem, nie od razu wskoczę do gry wielkości GTA VI czy Cyberpunka. Znam Superhot dwa razy przeszedłem.

kiedys_mialem_lepszy_brzuch napisał(a):

Myślę że musisz jednak zacząć od jakiegoś mniejszego własnego projektu. Dla javy jest bardzo fajny framework LibGDX - polecam, sam sporo w tym naklepałem

Jeśli chodzi o większe tytuły to faktycznie konieczna będzie jednak zmiana technologii i wejście w świat większych silników. Godot wydaje się niezłym startem, tak samo jak Unity.

Bez doświadczenia raczej nie ma szans na top firmy, chyba że w roli normalnego backenda - w końcu te gry też muszą mieć jakiś serwer, może firma ma własny sklep. Wtedy na zasadzie awansu poziomego możnaby szukać okazji, ale nie wiem czy tego szukasz

No i last but not least - gamedev to trudny rynek. Dużo pracy mało płacy

Wiele rzeczy robiłem w Unity, jakieś projekty na studia na zaliczenie, też w wolnym czasie jakieś poce. Z libGdx kiedyś próbowałem, ale ciężko było zacząć bo nie ma graficznego interfejsu.

WhiteLightning napisał(a):

Zalezy jakie gry chcesz robic, jesli faktycznei chcesz sie z tym zwiazac i robic gry AAA szedlbym w Unreala. Unity to raczej do neico mniejszych/prostszych produkcji. Ew. firmy maja czasa jakeis wewnetrzne engine'y ale wtedy lockujesz sie na jedna firme. Ew. poszukalbym czego uzywa konretna firma ktora mnei interesuje i przygotowal sie pod nia. Do tego jesli dobrze ogarniasz jeden silnik + wiesz jak sie robi rozne rzeczy w gamedevie, ew. przelaczenie na cos innego bedzie wzglednie szybkie.

Pytanie po co chcesz isc do gamedevu ? Bo poza jednym kumplem z CDRED odnosze wrazenie ze ta branza masakrycznie wypala ludzi.

Robienie gier mnie zmotywowało do nauki programowania. Zawasze chciałem robić gry. Gdy szukałem pierwszej pracy (pierwszej wgl.) nie mając doświadczenia komercyjnego przez pół roku nie znalazłem pracy w gamedev. W Javie znalazłem po miesiącu. I tak zostało. Strasznie mnie to nudzi.

MrMadMatt napisał(a):

Moim zdaniem jak ktoś chce startować do GameDevu to najlepiej jakby miał background modderski. Do Fallouta 4 czy Skyrima masz CreationKit, do Wiedźmina 3 masz RedKita - do obu znajdziesz playlisty na Youtubie jak z tym pracować. Unreala czy Unity masz za darmo na start ale w tym przypadku, dochodzi Ci problem assetowy IMHO. W przypadku modowania gier, masz na start i assety i podgląd na np. system questów/dialogów - jak to jest zrobione.

Co do modowania gier to nie jestem przekonany. Assety to akurat nie problem, Unity ma swój asstet store, wiele jest darmowych a płatne też nie kosztują jakiś kosmicznych pieniędzy.

obscurity napisał(a):

Jeśli chcesz po prostu zrobić grę to jest też godot, który ma ponoć najmniejszy próg wejścia z tych trzech. Możesz pisać w GDScript, C++, C#, Python, Rust, Nim, Go i innych językach przez rozszerzenia.
Wydaje mi się że najwięcej pracy znajdziesz w unity, ale wiele umiejętności tworzenia gier jest uniwersalnych i łatwo przenieść na inne silniki. Czemu stawiać na jeden konkretny?

Nie polecam zaczynać od własnego silnika, ja kiedyś chciałem w ten sposób wejść w branżę gier i przez 2 lata pisałem swój "silnik" gier 3d w C++, trzeba przyznać że bardzo dużo się w ten sposób nauczyłem i było to ciekawe i zajmujące doświadczenie ale zupełnie imo bezużyteczne w branży. Żeby robić swój silnik najpierw warto bardzo dobrze poznać jakiś istniejący, inaczej to błądzenie we mgle i wynajdowanie dziwnych rozwiązań od zera.
Gotowa gra w portfolio moim zdaniem robi większe wrażenie niezależnie od silnika niż niedokończony autorski silnik. Wątpię żeby ktokolwiek dał nowicjuszowi pracować nad silnikiem gry nastawionej na szybki release i sprzedaż, to raczej zajęcie dla wyjadaczy z wieloletnim doświadczeniem lub z kilkoma grami na koncie, ale jak masz takie ambicje i więcej niż 2 lata na eksperymenty i naukę to próbuj.

Dawno temu testowałem Godota. Miałem wrażenie że jest strasznie nie intuicyjny i zbugowany. Dałem sobie z nim spokój po jakimś czasie wróciłem i nie zmieniłem zdania. Co do silnika to brzmi sensownie to co piszesz. To tak jakbym się zastanawiał czy do portfolio startując na stanowisko Java Dev napisać aplikację z użyciem Springa czy zacząć pisać "własnego springa".

Kiedyś przez 2-3 miesięce robiłem z zespołem gierkę w javie - niestety projekt umarł (to miał być dodatek do jakieś kampani reklamowej której się umarło z powodu kryzysu 2008/2009).

Robiliśmy to na jmonkeyengine i było zajebiście:
to było sensowne programowanie wreszcie - np. programowanie shaderów, ulepszanie shadow map, proceduralny teren itp.
nawet jak nie robisz silnika to masz takie zagwózdki jak adoptowanie algorytmu A* do grupowego ruchu (bo jak masz ileś jednostek do ruszenia na raz z punktu a do b i każdej niezaleźnie przeliczysz A* to nie dość, że koszmarnie wolno to trwa, to jeszcze powstaje totalny chaos, jedne jednostki włażą w drogę innym - zaczyna się cofanie i bywa nawet, że przestają iść do celu (zresztą niektóre RTSy dokładnie na tym się wykladają). Ogólnie 10x wyższy poziom zabawy niż jakieś gówna dla banków - nawet blockchain i krypto się przy tym chowa.
Ogólnie gamedev to chyba jedyna naprawdę ciekawa działka programowania.

A co do javy - java się generalnie nie nadaje :-)
Z plusów:
a) jmonkeyengine jest zajebisty
b) lwjgl jest spoko
c) java jest w pytkę szybka jako taka

ALE
a) wywoływania opengl z javy są wolne (bariera JNI - nawet hakowałem własny JVM, żeby to przyspieszyć), to znaczy, że musisz optymalizować o wiele bardziej wywołania niż ktoś kto napiernicza np. w C++, engine dużo sam optymalizuje - ale nie wszystko,
b) ogólnie enginy javowe bazują na opengl, a opengl obsysa, a w zasadzie sterowniki opengl obsysają - co chwila okazywało się, że na jakimś laptopie sterownik deklaruje, że wspiera jakiś ficzer po czym gra się sypała, bo jednak sterownik nie wspierał (różne shadery itp)
c) GC - zasadniczo nie mieliśmy problemów, żeby na dobrym sprzęcie osiągać średnio 100, a nawet 200 FPS ŚREDNIO(!!!) (zależy oczywiście od tego co było na planszy), ale uzyskanie w miarę stabilnych 100 czy nawet 60 FPS, bez pauz to już była sztuka - trzeba się jebać z tuningowaniem GC - i mam wrażenie, ze w pewnym momencie poświęcałem temu tyle czasu, że pisanie gry w języku bez GC byłoby już szybsze. Generalnie jak ktoś ma średnio 100 fps ale co 10 sekund pauze nawet na 200 milisekund to gra - nawet strategiczna - staje się nieprzyjemna.

to było oczywiście 15 lat temu.
na pewno nowe JVMy mają poprawione JNI i nawet są jakieś nowe technologie ... ale nie korzystałem nie wiem,
na pewno pauzy w GC są teraz o wiele łatwiejsze do ogarnięcia.... ale nie wiem czy to nadal nie jest sztuka (czarna magia),
i strzelam, że ponieważ gry AAA nadal nie są robione na opengl to sterowniki opengl są nadal tak samo gówniane (ale nie znam się - jednak moje doświadczenie jest stare).

a) wywoływania opengl z javy są wolne (bariera JNI - nawet hakowałem własny JVM, żeby to przyspieszyć), to znaczy, że musisz optymalizować o wiele bardziej wywołania niż ktoś kto napiernicza np. w C++, engine dużo sam optymalizuje - ale nie wszystko,

Nie zgodzę się. JNI ma bardzo niski overhead, rzędu kilku nanosekund. W skali wykorzystania przy OpenGL lub Vulkanie to jest zupełnie nieistotne. Mogłoby to boleć w roku może 2000, kiedy jeszcze używało się fixed pipeline i każdy atrib każdego vertexu to było jedno wywołanie do glXX, a GPU skinning było czymś ezoterycznym. Ale nie dziś i nawet nie przez ostatnie 15 lat.

Aczkolwiek są ludzie, którzy uparcie i nieugięcie klepali w fixed pipeline nawet w roku 2010, np Notch od Minecrafta. Może dla takich overhead JNI sprawiał jakieśtam problemy. Może nawet to byliście Wy :)

Niemniej jednak pisząc w "modern" OpenGL (czyli takim wydanym po 2005) wywołań jest stosunkowo mało.

b) ogólnie enginy javowe bazują na opengl, a opengl obsysa, a w zasadzie sterowniki opengl obsysają - co chwila okazywało się, że na jakimś laptopie sterownik deklaruje, że wspiera jakiś ficzer po czym gra się sypała, bo jednak sterownik nie wspierał (różne shadery itp)

W dzisiejszych czasach jest to problem tylko w przypadku starych zintegrowanych kart - czyli takich, które się do gier i tak nie nadają. OpenGL 4.1 to safe bet na każdym sprzęcie który ma mniej niż 10 lat, nawet zintegrowane. A każdy dedykwana karta NVIDIA/AMD ma gwarantowane pełne OpenGL 4.5

c) GC - zasadniczo nie mieliśmy problemów, żeby na dobrym sprzęcie osiągać średnio 100, a nawet 200 FPS ŚREDNIO(!!!) (zależy oczywiście od tego co było na planszy), ale uzyskanie w miarę stabilnych 100 czy nawet 60 FPS, bez pauz to już była sztuka - trzeba się jebać z tuningowaniem GC - i mam wrażenie, ze w pewnym momencie poświęcałem temu tyle czasu, że pisanie gry w języku bez GC byłoby już szybsze. Generalnie jak ktoś ma średnio 100 fps ale co 10 sekund pauze nawet na 200 milisekund to gra - nawet strategiczna - staje się nieprzyjemna.

Da się pisać kod w Javie tak by hot path nie produkował śmieci. Dziś jest nawet łatwiej, biorąc pod uwagę mechanizmy takie jak escape analysis / scalar replacement. A niedługo™ wchodzi Valhalla, będzie można w ogóle zapomnieć o GC przy ciężkich obliczeniach z użyciem wektorów, macierzy i tym podobnych.

skoro weszła dygresja o javie to się dołączę :) ale i tak ta dyskusja o javie w grach triple-a (albo chociażby zbliżonego kalibru) i tak jest na razie tylko teoretyczna, bo nikt takich projektów komercyjnie nie robi. wyjątkiem może jest minecraft i tyle (chociaż może i minecraft nie jest triple-a ale i tak stoją za nim duże pieniądze).

zamiast jni można w javie 22+ używać https://openjdk.org/jeps/454 JEP 454: Foreign Function & Memory API z projektu panama. do maksymalnego zredukowania narzutu na wywołania funkcji można użyć opcji https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/foreign/Linker.Option.html#critical(boolean) . ogólnie jednak niski narzut można uzyskać przez korzystanie z natywnych buforów danych (tzn. alokowanych poza stertą javową) z panamy (foreign api) i przesyłania wskaźników do nich do natywnych bibliotek, z których chcemy korzystać. te natywne bufory w panamie są bardziej elastyczne i wydajne niż direct byte buffery i zdecydowanie bardziej bezpieczne niż alokacja przez sun.misc.unsafe.

niskopauzowy gc wbudowany w oracle'ową javę (a ta nie ma na np. shenandoah gc) jest od javy 15 https://openjdk.org/jeps/377 JEP 377: ZGC: A Scalable Low-Latency Garbage Collector (Production), a od javy 21 ma zwiększoną przepustowość: https://openjdk.org/jeps/439 JEP 439: Generational ZGC. oczywiście, jeśli ktoś generuje śmieci szybciej niż gc jest w stanie odśmiecić, to wtedy tak czy siak następują pauzy (ale w zgc pauzowane są tylko wątki, które alokują, a reszta może dalej latać).

co do api graficznego to opengl jest bardzo przenośny, ale jest już przestarzały. jest jednak ciekawa opcja (choć jeszcze w powijakach). nowe webowe api graficzne wzorowane na vulkanie, apple metal i directx-ie 12 ma nadal status draft, ale jest już obsługiwane przez chrome'a na windowsie: https://caniuse.com/webgpu i można się temu przyjrzeć. mimo tego, że webgpu jest przygotowane pod weba, to jednak da się tego użyć w aplikacjach natywnych i wtedy od kopa jest obsługa wspomnianego vulkana, metala i directx 12.

koniec dygresji.

Wibowit napisał(a):

ta dyskusja o javie w grach triple-a (albo chociażby zbliżonego kalibru) i tak jest na razie tylko teoretyczna, bo nikt takich projektów komercyjnie nie robi. wyjątkiem może jest minecraft i tyle (chociaż może i minecraft nie jest triple-a ale i tak stoją za nim duże pieniądze).

Kiedyś na taki projekt trafiłem: https://store.steampowered.com/app/1693290/Skullstone/
Tutaj info o silniku: https://www.moddb.com/features/skullstone-rendering-and-optimizations-described
Czyli używają jMonkeyEngine.
AAA to pewnie zbyt dużo powiedziane, bo to raczej mała gra indie.
Na upartego wszystko się da. Ale nie jest to "industry standard"...

Gdyby ktoś zrobił środowisko do tworzenia gier dla Javy na odpowiednim poziomie, to wtedy zapewne byłaby bardziej konkurencyjna w GameDevie.
Na razie lista silników nie wygląda zbyt dobrze...

Spine napisał(a):

Gdyby ktoś zrobił środowisko do tworzenia gier dla Javy na odpowiednim poziomie, to wtedy zapewne byłaby bardziej konkurencyjna w GameDevie.
Na razie lista silników nie wygląda zbyt dobrze...

jeśli chodzi o stworzenie jakiegoś potężnego silnika, chcącego się zbliżyć do tych triple-a, to i tak obecna java sprawia kolejne problemy.

dla przykładu javy się generalnie nie odpali na konsolach typu playstation czy xbox, bo nie pozwalają one na uruchamianie kompilacji jit. co prawda jest graalvm native-image, ale ten np. nie obsługuje niskopauzowego gc (zgc):
https://github.com/oracle/graal/issues/8117#issuecomment-1985748779

Is including (Generational) ZGC in native-image in discussions at all?

It's listed as a non-goal of this roadmap item, so no this is not about making ZGC available in native-image. We currently don't have any plans to make ZGC available in native-image.

no i w ogóle graalvm native-image nie obsługuje kompilacji pod wspomniane konsole. być może https://openjdk.org/projects/leyden/ załatwi sprawę (gdyby openjdk oferowało pełne aot, to ktoś mógłby zrobić forka na konsole), ale to kolejne lata oczekiwania.

java ma duży apetyt na pamięć ram, zwłaszcza że nie weszły jeszcze typy wartościowe z https://openjdk.org/projects/valhalla/ i, dopóki się to nie zmieni, to kolejny powód by nie pchać się w javę na urządzeniach o ograniczonych zasobach.

brak możliwości wydania gry w wersji na konsole to potencjalnie duży uszczerbek na zarobkach, a to przy grach triple-a byłoby niedopuszczalne.

@Wibowit: Wiesz, w Unity kodzi się w C#, ale można użyć IL2CPP, co z tego co rozumiem, załatwia kompilację na platformy, które nie lubią C#...
https://docs.unity3d.com/Manual/IL2CPP.html

Tak jak już napisałem, na upartego wszystko się da. :]
Mogliby coś takiego zrobić/użyć dla Javy.
Ale to pewnie zabieg podobnego kalibru co HipHop for PHP, żeby Facebook jakoś działał...