Dlaczego Java nie jest szerzej stosowana do tworzenia gier? [Zamknięte]

Nie jestem twórcą gier ani nic takiego, ale wiem, że Java nie jest powszechnie używana do tworzenia gier. Java powinna być wystarczająco szybka dla większości gier, więc gdzie jest haczyk? Mogę wymyślić kilka powodów:

• Brak twórców gier z doświadczeniem w Javie
• Brak dobrych ram tworzenia gier
• Programiści nie chcą akceptować Java jako języka programowania gier. Większość akceptuje tylko C ++ jako taki?
• Brak wsparcia dla konsol do gier (choć rynek PC nadal istnieje)

Oczywiście może to być coś innego. Czy ktoś, kto zna ten biznes lepiej ode mnie, może wyjaśnić, dlaczego Java nie nabiera rozpędu, jeśli chodzi o tworzenie gier?

Kilka powodów:

• W dawnych czasach potrzebny był „bezpośredni dostęp” do wydajności i interfejsu użytkownika. To poprzedza języki VM, takie jak Java i C #.
• Większość konsol (np. 360, PS3) nie ma JVM, więc nie można ponownie użyć kodu z wersji na PC. Znacznie łatwiej jest skompilować kod C ++ do obsługi różnych urządzeń.
• Większość głównych silników gier (np. Unreal) ma powiązania z C ++. Istnieje kilka konektorów Java (np. Dla OpenGL), ale nic podobnego.
• W przypadku gier komputerowych DirectX nie ma tak naprawdę silnej obsługi języka Java (jeśli w ogóle).
• Gry internetowe działają w JavaScript lub Flash. Możesz pisać je w Javie, używając takich rzeczy jak GWT.
• IPhone działa w wariancie Objective-C.

Java jest obecnie używana głównie w grach na Androida, ponieważ jest to podstawowy język dla tej platformy.

Powody techniczne:

• Większość najlepszych silników gier 3D jest napisanych w C / C ++. To wielka sprawa, ponieważ większość twórców gier nie chce iść na kompromis w sprawie swojego silnika 3D, ale nie chce też pisać od zera. Java ma jMonkeyEngine, który jest open source i faktycznie jest naprawdę dobry, ale wciąż nie może konkurować z Unreal Engine .
• W niektórych bardzo rzadkich sytuacjach zaletą jest „zbliżenie się do metalu” w języku C lub asemblerze, szczególnie w celu uzyskania dostępu do specjalnych funkcji sprzętowych. Nie jest to obecnie tak ważne, ale profesjonalni twórcy gier wciąż lubią mieć opcję .....
• Java ma wyrzucane śmieci , zarządzane środowisko wykonawcze. W 99% przypadków jest to ogromna zaleta, z pewnością sprawia, że ​​kodowanie jest łatwiejsze i mniej podatne na błędy i jest jednym z głównych powodów, dla których Java jest tak popularna. Powoduje to jednak sporadyczne problemy z opóźnieniami w grach, ponieważ cykle wyrzucania elementów bezużytecznych mogą powodować zauważalne przerwy. Z nowszymi maszynami JVM o niskim opóźnieniu będzie to mniej problem, ale nadal stanowi problem w przypadku graficznie intensywnych gier, w których utrzymanie wysokiego FPS ma kluczowe znaczenie.

Powody nietechniczne:

• Profesjonalne domy rozwoju gier są mocno inwestowane w umiejętności i technologie C / C ++. To powoduje ogromną bezwładność .
• W dużej mierze irracjonalne postrzeganie, że Java jest powolna. Prawdopodobnie prawda w latach 90., teraz zdecydowanie nieprawda - na pewno możesz napisać dochodową, komercyjną grę 3D z Javą ( ktoś Runescape ? A może Minecraft ?)
• Całkiem uczciwe przekonanie, że Java jest bardziej skoncentrowana na aplikacjach biznesowych i Internecie niż na grach. To może się zmienić wraz z rozwojem Mobile i potrzebą dalszego rozwoju międzyplatformowego, ale z pewnością jest to obecnie prawdą.

Co ciekawe, istnieją również dobre powody, dla których twórcy gier powinni rozważyć Javę:

• Przenośność - w miarę rozprzestrzeniania się liczby platform docelowych, Java staje się coraz bardziej atrakcyjna dzięki niemal niezrównanej zdolności do tworzenia prawdziwie wieloplatformowych plików binarnych
• Ekosystem biblioteczny - z bardzo ważnym wyjątkiem silników gier 3D, Java ma najlepszy zakres bibliotek na ogół z dowolnej platformy. Praca w sieci, dźwięk, sztuczna inteligencja, przetwarzanie obrazów, magazyny danych o kluczach / wartościach, ty nazywasz ten temat i prawdopodobnie jest dla niego biblioteka Java typu open source.
• Rozwój po stronie serwera - Java jest świetnym językiem / platformą dla serwera, a ponieważ więcej gier zawiera elementy wieloosobowe, po stronie serwera będzie coraz ważniejsze. Java w Linuksie wygląda tutaj dość atrakcyjnie jako platforma.
• JVM - jest prawdopodobnie najlepiej zaprojektowanym środowiskiem do wykonywania maszyn wirtualnych na świecie, z fantastycznym wyrzucaniem elementów bezużytecznych, kompilatorem JIT, obsługą współbieżności itp. Będzie jeszcze lepiej, a ponieważ twórcy gier stopniowo zaczną używać dynamicznych języków w swoich grach, będą chcieli najlepsze możliwe środowisko wykonawcze.
• Inne języki JVM - Java to solidny koń roboczy, ale prawdziwa innowacja dzieje się dzięki nowym językom JVM (w szczególności Scala, Clojure). Te języki mają wszystkie zalety platformy Java / JVM, a ponadto są niezwykle wydajnymi nowoczesnymi językami.

Okej, w tym wątku jest dużo dezinformacji.

Znam działalność gra bardzo dobrze, będąc w nim przez 25 lat. Znam też Javę w grach, będąc ewangelistą technicznym Sun Game firmy Java i wykładowcą specjalizującym się w programowaniu wydajności Java.

Jeśli chodzi o szybkość obliczeń, Java pokonuje obecnie C ++ w wielu testach naukowych w dziedzinie obliczeń. Możesz napisać kod patologiczny w dowolnym języku, który źle sobie radzi, jeśli chcesz, ale przede wszystkim są one na równi i działały przez długi czas.

Jeśli chodzi o wykorzystanie pamięci, Java ma pewne narzuty. HelloWorld to program 4K w Javie. Ale ten narzut jest dość bez znaczenia w dzisiejszych systemach z wieloma GB. Wreszcie Java ma więcej czasu na uruchomienie. Nie polecałbym używania Javy do krótkotrwałych narzędzi, takich jak polecenia wiersza poleceń systemu Unix. W takich przypadkach start będzie dominował w Twojej wydajności. W grze jest to jednak dość mało znaczące.

Prawidłowo napisany kod gry Java nie ulega przerwom GC. Podobnie jak kod C / C ++, wymaga aktywnego zarządzania pamięcią, ale nie do poziomu C / C ++. Tak długo, jak utrzymasz wykorzystanie pamięci do obiektów długo żyjących (trwających przez cały poziom lub grę) i bardzo krótko żyjących (wektory i takie, przekazywane i szybko niszczone po obliczeniach) gc nie powinno być widocznym problemem.

Jeśli chodzi o bezpośredni dostęp do pamięci, Java ma to od dłuższego czasu; od Java 1.4 w formie Native Direct Byte Buffers. Kręcenie się bitów w Javie może być nieco irytujące z powodu braku niepodpisanych typów liczb całkowitych, ale wszystkie rundy pracy są dobrze znane i nie strasznie uciążliwe.

Chociaż jego prawdziwa Java nigdy nie miała powiązania Direct3D, to dlatego, że technologie Java dążą do przenoszenia. Posiada DWA powiązania OpenGL (JOGL i LWJGL) i OpenAL (JOAL) oraz przenośne powiązanie wejściowe (JInput), które łączy się pod maską z DirectInput w systemie Windows, HID Manager w OSX i powiązanie z Linuksem (nie pamiętam, które).

Prawdą jest, że żaden kompletny silnik do gry nie zawierał Java w taki sposób, jak powiedzmy Unity, ma C # i jest to słabość w niezależnej przestrzeni. Z drugiej strony były dwa dobre APIS na poziomie Scenegraph, które były całkowicie przenośne dla platform Windows, OSX i Linux. Oba napisane przez Josha Slacka, pierwsze nazwano silnikiem JMonkey, a drugie Ardor3D.

Górny plakat ma rację, że dwie największe rzeczy, które powstrzymały Javę w rozwoju gier, to uprzedzenia i przenośność. Ten ostatni był największym problemem. Chociaż możesz napisać grę Java i wysłać ją na system Windows, OSX i Linux, nigdy nie było konsoli VM. Było to spowodowane całkowitą nieudolnością średniego kierownictwa firmy Sun. Nieliczni z nas pracujący nad Javą w grach faktycznie mieli umowy z Sony nie mniej niż 3 razy, aby uzyskać maszynę wirtualną na Playstation i wszystkie 3 razy średnie kierownictwo Sun zabiło ją.

Podczas gdy Sun flirtował z technologiami klienckimi, faktem jest, że zarząd firmy Sun nigdy nie otrzymał produktów konsumenckich. Właśnie dlatego Java jako język klienta firmy Sun nigdy nie odniosła sukcesu w żadnej formie i dlaczego Google i Dalvik (wirtualna maszyna Java podobna do Java) sprawiły, że Java odniosła sukces wszędzie.

I dlatego dzisiaj koduję gry w C #. Ponieważ Mono poszło tam, gdzie kierownictwo firmy Sun odmówiło.

Java doskonale nadaje się do logiki biznesowej, serwerów i kodu niezależnego od platformy, który musi działać niezawodnie. Istnieje kilka czynników, dlaczego Java nie jest często używana w grach:

• sprawdzanie granic i inne mechanizmy bezpieczeństwa (obecnie marginalna różnica wydajności)
• konieczność konwertowania między strukturami danych C ++ a strukturami danych Java (nie można po prostu kopiować pamięci między buforami)
• wiele książek i samouczków podąża za tłumem, dlatego ciężko jest znaleźć informacje dla twórców gier innych niż C ++
• podstawowe biblioteki graficzne (DirectX i OpenGL) oraz wiele gotowych silników są oparte na C / C ++
• wiele gier stara się uruchamiać tak szybko, jak to możliwe, aby dodać więcej atrakcyjnych wizualnie funkcji

Nie jest łatwo pracować z bibliotekami C ++ z języków kodu bajtowego, takich jak Java (pisanie warstwy JNI) i .net (wiele atrybutów marshalling / unmarshalling, api / structure). Daje to sporo pracy przy niewielkich korzyściach.

Uwaga dodatkowa: niektóre serwery gier używają Java.

Podobny post tutaj : https://stackoverflow.com/questions/1034458/why-arent-video-games-written-in-java

Java nie jest wystarczająco szybka do większości gier. Jest znacznie wolniejszy niż użycie C ++ / Assembly, który jest standardem. Jest to ten sam powód, dla którego nie rozwija się więcej gier przy użyciu C # lub VB. Twórcy gier potrzebują i planują każdy ostatni cykl zegara, który mogą zdobyć, na potrzeby obliczeń fizycznych, logiki AI i interakcji środowiska.

W przypadku prostszych gier Java może być używana dość skutecznie. Jeśli chcesz utworzyć klon Tetris lub Bejeweled lub coś innego o takim poziomie szczegółowości, Java działałaby dobrze. Ale Java nie jest w stanie stworzyć gier takich jak Halo, Medal of Honor, Command & Conquer itp. I sprawić, że będzie można w nią grać. Przynajmniej tak, jak istnieje obecnie.

Powody, które podajesz w swoim pytaniu, są również ważne. Z wyjątkiem, jak sądzę, braku twórców gier ze znajomością języka Java. Wiele gier na telefony i inne urządzenia przenośne jest napisanych w Javie (w tym większość gier na Androida), a niektóre z nich są całkiem doskonałe. Myślę więc, że istnieje przyzwoita i stale rozwijająca się baza programistów gier ze znajomością języka Java.

Zmienia się myśl o możliwości używania tych języków wyższego poziomu w niektórych bardziej zaawansowanych grach. Na przykład jedna z moich ulubionych gier, Auran's Train Simulator, jest napisana z dużymi częściami w języku C # i działa całkiem dobrze. Baza rośnie, więc będzie ewoluować.

Nowoczesne gry polegają na grafice 3D na sprzęcie specjalnego przeznaczenia.

Nawet w 2002 r. Jacob Marner stwierdził w swoim raporcie „Evaluating Java for Game Development”, że Java jest całkiem użyteczna w grach, z wyjątkiem części najbardziej zależnych od wydajności, a ze względu na solidność języka i leżącą u jego podstaw JVM jest tańsza zrobić to w ten sposób.

http://java.coe.psu.ac.th/FreeOnline/Evaluating%20Java%20for%20Game%20Development.pdf

Osobiście uważam, że wraz z postępem, jaki się dokonał, zwłaszcza w grafice 3D, oraz ze świetnymi powiązaniami z OpenGL i innymi, ta wada jest obecnie znacznie mniej wyraźna.

Dlatego problem musi być gdzie indziej. Prawdopodobnym powodem jest rozmiar środowiska uruchomieniowego Java (co jest obecnie znacznie mniejszym problemem w przypadku gier na wiele płyt DVD), a kolejną przyczyną jest bezwładność istniejącego kodu. Praca z rodzimym kodem w Javie jest bardzo krucha. Trzecim powodem jest to, z czym znają się twórcy gier. Czwarta kwestia dotyczy tego, czy Java jest w ogóle dostępna na platformie.

Jedno jest pewne - większość gier staje się skryptowalna, a nie od samego początku wypalana w kodzie C, a Ty potrzebujesz najlepszego środowiska uruchomieniowego pod językiem skryptowym. W dzisiejszych czasach oznacza to zasadniczo CLR lub JVM.

Twórcy gier lubią być blisko metalu i często piszą swoje ciasne wewnętrzne pętle w asemblerze. Java nie oferuje tego samego poziomu możliwej wydajności, zarówno pod względem stałej szybkości, jak i wykorzystania pamięci (uruchamianie JIT ma swoje żniwo).

Myślę, że czynnikiem ograniczającym dla większości ludzi jest (brak) dostępności dobrych silników do gier. Aby dotrzeć bardzo daleko, musimy sprawdzić, dlaczego nie są one dostępne.

Przez chwilę patrzyłem na to z drugiej strony. Opracowanie silnika gry (na przykład) to dużo pracy. Kto by na tyle skorzystał z opracowania takiego, aby zainwestować czas i wysiłek, aby to zrobić?

Większość oczywistych kandydatów do tworzenia frameworków w / dla Java (np. IBM, Oracle) wydaje się nie mieć zainteresowania grami. Widoczni kandydaci do tworzenia gier (np. Id, EA) wydają się mieć prawie równie małe zainteresowanie Javą.

Prawie jedynym kandydatem, który mogę o tym myśleć, wydaje się być w ogóle rozsądny. Podstawowym językiem programowania dla Androida jest Java, a zachęcanie do tworzenia gier dla Androida może zapewnić prawdziwą korzyść dla platformy.

O ile wiem, nie zrobili tego (jeszcze?), Co pozostawia dość poważne ograniczenia dla prawie każdego innego. Bezproblemowe działanie nowoczesnych, wysokowydajnych silników gier do programowania w Javie oznacza sporo dodatkowej pracy, a (jak mi się wydaje) niewielkie szanse na uzyskanie wielu korzyści w zamian za tę dodatkową pracę.

Pytanie jest na równi z pytaniem:

Co lepiej zasilać samochód, silnik łodzi lub silnik odrzutowy.

Wszystko sprowadza się do skalowalności, unikania błędów, szybkości, sygnatury pamięci, modułowości i wielu innych rzeczy. Pytanie nie powinno dotyczyć tego, co jest lepsze jako standard branżowy, powinno brzmieć „co jest dla mnie lepsze”, jak w tym, co wiesz lub jak dobrze to wiesz. Jeśli to zrobi, to zrobi robotę, jeśli rzeczywiście możesz sprzedać pomysł, to zadziała i kto wie, że możesz zgiąć kilka łyżek.

Java nie została stworzona z myślą o tworzeniu gier, Java została stworzona jako język „dla Internetu”.

Jeśli chodzi o tworzenie gier, Sun tak naprawdę nie obsługiwał Java jako języka programowania gier, ponieważ Microsoft wspierał C #.

Myślę, że brak atrakcyjnych ram do tworzenia gier jest tym, co naprawdę zabiło Javę w tym aspekcie.

Łatwiej jest przykleić C bardziej bezpośrednio do zupełnie nowego niekonwencjonalnego sprzętu i sterowników. Im szybciej i bliżej programista gier będzie w stanie dotrzeć do sprzętu, tym lepiej będzie mógł wyprzedzić konkurencyjne gry. Późniejsi programiści trzymają się tej samej metodologii i narzędzi, co te wcześniej sprawdzone.

W przypadku gier, w których optymalizacja do najnowszego sprzętu jest mniej ważna, takich jak zwykłe gry na telefony komórkowe, użycie C w ten sposób jest mniej ważne niż większa przenośność Javy.

Dla niektórych osób powód nie ma nic wspólnego z prędkością, bibliotekami czy dostępnością. Jest to po prostu z powodu samego języka. Niektórzy ludzie po prostu nie lubią języka Java. Inni wolą używać swojego ulubionego języka programowania zamiast Java do tworzenia gier.

Oczywiście może to być coś innego. Czy ktoś, kto zna ten biznes lepiej ode mnie, może wyjaśnić, dlaczego Java nie nabiera rozpędu, jeśli chodzi o tworzenie gier?

Jest to język tłumaczenia, tzn. Powolny. Masz do czynienia z kartą graficzną i sprzętową. Jaki jest dobry język do radzenia sobie ze sprzętem? C ++, jest dość niski i masz do czynienia ze wskaźnikami i tym podobne.

Jeśli chcesz wypompować szaloną grafikę, taką jak crysis i cokolwiek innego, nie zamierzasz robić dla niej Java.

Mało tego, Oracle jest właścicielem Java, myśl, że firma może cię pozwać, nie jest odważna. Zwłaszcza, jeśli chcesz zbudować własny interpretator JAVA, aby celować w gry bez pozywania ze względu na fragmentację FUD.