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

77

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?

Anto
źródło
37
A teraz poczekaj na wszystkie odpowiedzi „Java jest wolna, C ++ jest szybka”, które naprawdę dotykają powierzchni problemu w zbyt szeroki i całkowicie poprawny sposób. Pamiętaj, że osoby odpowiadające w ten sposób prawie na pewno nie są profesjonalnymi twórcami gier.
Ed S.
20
W rzeczywistości Java jest używana do tworzenia gier; tj. na rynku mobilnym. Java ME, Android.
user281377,
21
Dlaczego warto go używać? Co Java oferuje twórcy gier, czego nie ma w bardziej popularnych językach? Java zapewnia twórcom aplikacji biznesowych niezwykle bogate ekosystemy, które przeważają nad swoimi niedociągnięciami jako językiem, ale jeśli chodzi o tworzenie gier, platforma Java oferuje niewiele narzędzi w porównaniu z wieloma alternatywami.
back2dos,
14
Co ciekawe, Minecraft jest oparty na Javie.
Uri,
5
@Coder Wygląda na to, że kod C ++ został mocno zoptymalizowany, ale kod Java nie. To nieprawidłowe porównanie.
Izkata

Odpowiedzi:

94

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.

Uri
źródło
14
+1 „Większość konsol (np. 360, PS3) nie ma JVM, więc nie można ponownie użyć kodu z wersji PC. Znacznie łatwiej jest skompilować kod C ++ do obsługi różnych urządzeń” Jeśli urządzenie nie ma środowiska wykonawczego , nie zobaczysz gier opracowanych na podstawie tego niedostępnego środowiska uruchomieniowego. Xbox 360 i Windows Phone zarządzały środowiskami uruchomieniowymi .Net, więc tworzenie gier przy ich użyciu jest możliwe i prawdopodobnie rośnie. Ponieważ jednak środowisko wykonawcze nie znajduje się na innych głównych platformach (PS3 i, w znacznie mniejszym stopniu, Wii), trudno jest uzasadnić całkowicie oddzielną bazę kodów. To naprawdę nie jest wcale problem z wydajnością.
JustinC,
2
Nazywa się XNA, który jest obecnie podzbiorem frameworku .Net 2.0. Istnieje kilka innych ciekawych frameworków na wolności: MonoXNA, MonoTouch i XnaTouch.
JustinC,
7
Przewidywanie wydajności nie jest możliwe w przypadku JVM.
Klaim
5
Bardzo dobre punkty. Dodam jednak fakt, że GC może powodować nieprzewidywalne przerwy / ładowanie. Jeśli nie jest to problem z aplikacjami serwerowymi, dotyczy to gry w czasie rzeczywistym. Jest to na przykład widoczne w grze Minecraft.
deadalnix
2
@Klaim Nie jest to również możliwe przy pomocy malloclub new, więc jeśli jest to problem, zamierzasz zastosować pooling bez względu na wszystko. Nie związany z tym punktem, duży problem z Javą polega na tym, że nie obsługuje typów wartości, w przeciwieństwie do C #.
Doval,
80

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.
mikera
źródło
19
Nie, ochrona nie jest lepsza w Javie w świecie gier wideo. Większość konsol nie ma JVM. Ze względu na przenośność C ++ jest preferowany w Javie w świecie gier wideo.
deadalnix
5
Dlaczego ekosystem biblioteczny jest dodatkiem do Java? Sieci, dźwięk, pary klucz-wartość - to nie jest rzecz; jest to obecnie dostępne wszędzie. W rzeczywistości argumentowałbym, że AI i przetwarzanie obrazu jest znacznie łatwiejsze w przypadku bibliotek C / C ++ (fann, OpenCV).
MrFox,
4
Ważniejsze niż FPS, może chciałbym podkreślić spójną liczbę klatek na sekundę. Mogę mieć moją grę działającą z prędkością 100 klatek na sekundę, ale jeśli niektóre z tych klatek zajmują pół sekundy, to po prostu się nie uda. Nawet jeśli GC jest szybki, jeśli powoduje zauważalne nieprawidłowości, nadal stanowi problem. (Nie dotyczy to w szczególności wydajności Javy, tylko ogólny problem, o którym należy pamiętać)
Gankro
1
Napisałem strzelankę FPS w Javie i nigdy nie miałem żadnych problemów ze śmieciarzem, nawet jeśli nie użyłem go z małym opóźnieniem. W każdym razie, gdy pamięć nie jest przydzielana na stercie Java, ode mnie zależy, czy poradzę sobie z nią bez modułu wyrzucania elementów bezużytecznych, a większość pamięci zajmie VBO. Innymi słowy, wyrzucanie elementów bezużytecznych nie stanowi problemu, ponieważ działa, gdy jest używane do tego, do czego jest przeznaczone i nie jest w stanie obsłużyć dużych obiektów na GPU lub na rodzimej stercie (! = Sterta Java). Nie obwiniaj kowadła za to, że nie jest skutecznym środkiem do mycia zębów.
gouessej
1
@deadalnix Świat gier wideo składa się nie tylko z konsol.
gouessej
27

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.

user430788
źródło
8

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

Graeme Wicksted
źródło
Nie musisz sam pisać JNI, wystarczy użyć JogAmp lub podobnej biblioteki.
gouessej
Słuszna uwaga. Użyłem JOGL i JMonkeyEngine w Javie. Bardziej aktualne w Użyłem XNA / MonoGame do DirectX i OpenTK do OpenGL z nvorbis / naudio / openal w C #. Doskonale sprawdzają się w małych i średnich grach, szczególnie podczas pracy z modułami cieniującymi. Duża poprawa wydajności w stosunku do C ++. Wtedy twoim jedynym prawdziwym problemem jest to samo, co każdy język oparty na GC: zapobieganie / łagodzenie GC. Okresowo blokuje szybkość klatek, więc będziesz potrzebować tablic o stałej wielkości, przydziałów statycznych lub długotrwałych buforów, które można rzucać, gdy gra zostanie zatrzymana (menu, ładowanie, zdjęcia).
Graeme Wicksted
Używam JOGL od 2006 roku i nie miałem tego rodzaju problemu nawet na bardzo słabym sprzęcie w środowisku stacjonarnym. Śmieciarz nie jest winny, ponieważ największe obiekty często znajdują się albo w pamięci RAM GPU, albo w natywnej stercie (zwykle w bezpośrednich buforach NIO), tym pierwszym nie zarządza „normalne” zbieranie śmieci, a drugimi nie są t zarządzany bezpośrednio przez „normalne” czyszczenie pamięci, ponieważ zajmuje się obiektami Java na stercie Java. Deweloper musi wydajnie zwolnić pamięć przydzieloną do natywnej sterty.
gouessej
Moim skromnym zdaniem problem wynika raczej z niektórych „optymalizacji” wyobrażonych przez programistów spoza mentalności Javy, które uniemożliwiają modułowi wyrzucania elementów bezużytecznych. Jeśli utrzymasz silne odniesienia do niektórych bezużytecznych obiektów Java powiązanych z niektórymi zasobami natywnymi, śmieciarz nigdy nie uzna ich za możliwe do odzyskania. Przydział off-heap może być przydatny w niektórych przypadkach, ale jeśli nadużyjesz go, twoje długowieczne zasoby pozostaną w pamięci i nie będziesz w stanie tworzyć nowych obiektów.
gouessej
Niektórzy programiści gier wolą początkowo przydzielać ogromne bufory, kroić je w czasie wykonywania i samodzielnie zarządzać pamięcią, ale prawdopodobnie zrobią to gorzej niż system operacyjny, a potem Java poświęci dużo czasu na zwolnienie miejsca na tworzenie nowych obiektów. Unikanie wycieku pamięci nie jest trudniejsze w Javie, a bardziej realnym rozwiązaniem jest śledzenie tylko obiektów, których pamięci nie przydzielono na stosie Java, w celu zwolnienia ich w odpowiednim czasie (podczas pauzy, podczas przełączania z poziomu na inny) , ...), nie ma to nic wspólnego z śmieciarzem.
gouessej
5

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ć.

BBlake
źródło
17
Pomijasz jeden z najważniejszych punktów; zdecydowana większość narzędzi i interfejsów API, których można by użyć, została napisana w C ++, a przepisanie ich do pracy z Javą lub innym językiem byłoby ogromną pracą. Ponadto uogólnienie, że „[Java jest] znacznie wolniejsze niż używanie C ++ / Assembly ” jest zbyt szerokie, aby było dokładne. Asembler nie jest używany tak często, jak myślisz w grach komputerowych, ponieważ dobry kompilator prawdopodobnie wygeneruje bardziej wydajny kod niż napisanie asemblera. Wymagane jest jednak deterministyczne wykorzystanie zasobów i umiejętność prawidłowego korzystania ze sprzętu.
Ed S.
15
Ktoś naprawdę musi stworzyć lepszy przykład możliwości Javy niż Minecraft. Dopóki ktoś nie będzie w stanie stworzyć odpowiednika WoW, C&C, MOH lub Starcraft w Javie lub C #, będę nadal trzymał się tego, co powiedziałem.
BBlake,
12
„Asembler nie jest używany tak często, jak myślisz w grach komputerowych, ponieważ dobry kompilator prawdopodobnie wygeneruje bardziej wydajny kod niż piszesz asembler”. To kolejne uogólnienie. Nie widziałem jeszcze kompilatora, który mógłby wygenerować lepszy język maszyny IA32 niż doświadczony programista asemblera IA32. Kompilatory generują kod dla abstrakcyjnej maszyny, która jest mapowana na maszynę docelową. Programista w asemblerze w pełni wykorzystuje procesor, w tym idiomy maszyn.
bit-twiddler
10
Nie zapomnij użycia pamięci. Wykorzystanie pamięci jest prawdopodobnie ważniejsze niż szybkość. Java nie jest przeznaczona do bezpośredniego sterowania pamięcią, jak C ++, a moduł czyszczenia pamięci oznacza, że ​​użycie pamięci jest zawsze znacznie wyższe niż C ++ dla tego samego zadania.
Mateusz
9
To nie jest 1985 rok. Mamy ponad 640k pamięci, więcej niż 50 procesorów mghz i ponad 1,44 Mb pamięci wymiennej. Wyzwanie twórców gier dzisiaj nie jest takie samo jak 25 lat temu. Śmiało i znajdź przykład ręcznie spreparowanego kodu x86 / lub ia64 dla nowoczesnej gry. Niektóre mity są po prostu błędne. Wyzwaniem jest przenośność i klienci niższego poziomu korzystający ze stosunkowo starych środowisk operacyjnych. Najmniejszy wspólny mianownik kontra przekonujące zanurzenie.
JustinC,
5

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.

użytkownik1249
źródło
1
oddlabs.com/technology.php - „ Opieraliśmy nasz rozwój na połączeniu LWJGL i Java, co pozwala na uruchomienie gry na dowolnej platformie obsługiwanej przez LWJGL bez modyfikacji i z prędkością porównywalną z zależnym od platformy rodzimym kodem”.
Jake2 przewyższał Quake2 ponad 10 lat temu. Nie jesteśmy już w 2002 roku.
gouessej
4

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).

dan_waterworth
źródło
4

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ę.

Jerry Coffin
źródło
Myślę, że trafiłeś na ważny problem z silnikami gier - myślę, że jest to największy powód, dla którego Java nie dogoniła C / C ++. Możliwe jednak, że open source może nieco wyrównać szanse - jestem pod dużym wrażeniem jMonkeyEngine ( jmonkeyengine.com ).
mikera
i nie zapominaj, że twórcy gier są ogólnie bardzo konserwatywni (technicznie), a większość dużych (wpływowych) sklepów istnieje od dziesięcioleci i skupia się na C (++) / ASM, więc nie zamierzają inwestować w rozwój Java, ponieważ oznaczałoby to znaczną inwestycję czasu, pieniędzy i innych zasobów z góry, gdy cała architektura C (++) / ASM jest gotowa do wdrożenia.
jwenting
1

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.

Meh
źródło
0

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.

Mahmoud Hossam
źródło
3
Ale C ++ również nie został stworzony jako język gier, ale jako systemowy język programowania, podobnie jak C. A Sun faktycznie włożył trochę wysiłku w Javę jako język gier, myślę, że współpracowali z Sony, aby wprowadzić Javę na PS2 lub coś, ale to się nigdy nie wydarzyło ...
Anto
1
@Phobia: Ale został zaprojektowany do programowania systemów.
Anto
1
@Phobia: Mówię, że jest to język programowania ogólnego przeznaczenia , podobnie jak C ++. W swojej odpowiedzi mówisz, że Java nie została zaprojektowana jako język programowania gier, ale zapominasz, że C ++ nie jest tak zaprojektowany.
Anto
2
@Joe Blow: Ze strony Wikipedii na temat C: „Chociaż C został zaprojektowany do wdrażania oprogramowania systemowego , jest również szeroko stosowany do tworzenia przenośnych aplikacji”. Myślę, że to całkiem jasne, prawda?
Anto
2
@Fobia Przykro mi z powodu twoich osobistych preferencji, ale są one całkowicie nieistotne dla dyskusji. Co więcej, nie chcę kwestionować, że obecnie C ++ jest używany prawie wyłącznie w programowaniu aplikacji. Nie o to chodziło w tej dyskusji. Twoje twierdzenie, że Java została zaprojektowana z myślą o programowaniu internetowym. C ++ został zaprojektowany z myślą o programowaniu systemów. Mówi jego projektant. Koniec dyskusji.
Konrad Rudolph
-1

Ł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.

hotpaw2
źródło
-4

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.

Echo
źródło
brzmi to bardziej jak komentarz, patrz Jak odpowiedzieć
gnat
-8

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.

mityczny programista
źródło
1
Powinieneś poważnie przeczytać o kompilacji JIT i przyjrzeć się niektórym testom porównawczym, w których Java jest stosowana wobec C ++
Anto
1
Kto, do cholery, zagłosował na tę odpowiedź? Całe to pytanie staje się niesamowicie śmieszne! O jeny.
Fattie,
7
@Joe Odpowiedź jest nieprawidłowa. Java nie jest interpretowana.
Konrad Rudolph
3
@Anto Zapomnij o tych głupich testach. C ++ jest o rząd wielkości szybszy niż Java, gdzie się liczy, patrz programmers.stackexchange.com/questions/29109/29136#29136 i programmers.stackexchange.com/questions/368/13888#13888 .
Konrad Rudolph,
1
@Anto Na co mam patrzeć? Prędkość? C ++. Zużycie pamięci? C ++. Spójrz na Minecraft i spróbuj hostować serwer i zobacz, ile pamięci zajmuje ta gra. Java zużywa znacznie więcej pamięci w porównaniu do C ++. Wyobrażam sobie, że tworzenie gry online jest dość trudne w Javie. Każdy test, jaki do tej pory widziałem, Java zużywa więcej pamięci, teraz gra MMORPG, w której centralny serwer jest zakodowany w Javie, brzmi nieźle, tylko jeśli zignorujesz aspekt pamięci lub zmienisz definicję masywności w MMORPG.
mityczny programista