Czy Java jest dobrym wyborem dla gier wieloplatformowych? [Zamknięte]

13

Chcę stworzyć grę w Javie i chciałbym, aby działała na systemach Windows, Linux i Mac. Jestem prawie pewien, że C # jest złym wyborem do tego i nie mam wystarczającego doświadczenia w C lub C ++. Chcę trzymać się z dala od Flasha. Czy zatem Java jest dla mnie dobrym wyborem? Najczęściej używam C # i myślę, że Java jest podobna, więc zakładam, że nie będzie tak trudno się nauczyć. Ale czy jest wystarczająco szybki? Czy istnieje język bardziej odpowiedni dla moich potrzeb niż Java?

CommunistPancake
źródło
8
Zależy od stylu gry, który chcesz zrobić. W zależności od pożądanego stylu może być tak, że HTML5 i niektóre javascript będą dla ciebie działać, jeśli nie java.
Patrick Hughes,
Oddlab sprzedaje gry oparte na Javie, np. Tribal Trouble. Możesz zobaczyć szczegóły dotyczące ich silnika na stronie oddlabs.com/technology.php
5
Minecraft to świetny przykład wieloplatformowej gry napisanej w Javie. Kiedy nasz chłopak ma swoich przyjaciół na poważną sesję Minecraft, grają w OSX, Windows i Linux.
Kev
Dwa lata później C # jest teraz całkiem dobry do takich rzeczy za pomocą silnika Unity i / lub Monogame, które obsługują także iOS, Android i WP8.
Mag

Odpowiedzi:

28

Java jest wyjątkowo odpowiednia do pisania gier na wiele platform. Główne zalety:

  • Przenośność - ogólnie rzecz biorąc, możesz napisać grę Java i oczekiwać, że będzie działała bez zmian na większości platform. Jest to prawdopodobnie najbardziej przenośna opcja w dowolnym języku - C / C ++ jest drugą wysoce przenośną opcją, ale wymaga ponownej kompilacji dla każdej platformy, aw wielu przypadkach biblioteki mają specyficzne dla platformy funkcje, które ograniczają przenośność.
  • Wydajność - kod Java, jeśli jest dobrze napisany, będzie działał równie dobrze jak każdy inny język, w tym C / C ++. Kompilator JVM JIT jest wyjątkowo dobry. Możesz napisać najwyższej jakości, udaną grę w Javie (na przykład Minecraft).
  • Biblioteki - istnieje ogromna gama bibliotek dostępnych dla Javy, które obejmują prawie każdą funkcję, jakiej możesz potrzebować w grach, od sieci po grafikę, dźwięk i sztuczną inteligencję. Większość bibliotek Java jest oprogramowaniem typu open source.

Główną decyzją, którą musisz podjąć, jest to, jakiego środowiska GUI będziesz używać. Istnieje kilka różnych opcji, ale najważniejsze z nich to:

  • jMonkeyEngine - pełnoprawny silnik 3D. Jeśli chcesz stworzyć grę 3D, jest to prawdopodobnie najlepszy wybór - zawiera wiele funkcji silnika gry, takich jak wykresy scen, generowanie terenu itp.
  • LWJGL - biblioteka niskiego poziomu z bezpośrednim dostępem do OpenGL. Może Ci się spodobać, jeśli chcesz uzyskać maksymalną wydajność i nie masz nic przeciwko pisaniu dużej ilości silnika od zera.
  • Swing - ma tę zaletę, że jest wyjątkowo przenośny i znajduje się w środowisku wykonawczym Java, więc nie wymaga dodatkowej zależności. Jest dobry w przypadku nie wymagających graficznie gier 2D (gry strategiczne, gry karciane itp.)
  • Slick - biblioteka gier 2D oparta na LWJGL. Prawdopodobnie dobrze, jeśli chcesz napisać grę 2D, ale nadal potrzebujesz dobrej wydajności grafiki (strzelanki, przewijanie gier platformowych itp.)
  • JavaFX - zaprojektowany dla bogatych aplikacji internetowych, mniej więcej takich jak Flash. Ma wiele ciekawych funkcji, które byłyby dobre dla gier, chociaż nie widziałem, aby był jeszcze używany. Szczególnie JavaFX 2.0 wygląda dość obiecująco.

Główne wady Java dla gier są naprawdę związane z „przypadkowymi przypadkami”, które prawdopodobnie nie wpłyną na ciebie, ale są istotne dla niektórych klas gier:

  • Dostępność silnika 3D - chociaż wymienione powyżej narzędzia i silniki są dobre, wciąż nie są na poziomie silników C / C ++, takich jak silnik Unreal Engine używany przez profesjonalne firmy z branży gier. Więc Java prawdopodobnie nie będzie twoim pierwszym wyborem, jeśli próbujesz opracować duży FPS z wielomilionowym budżetem - C / C ++ wciąż wygrywa tutaj.
  • Opróżnianie pamięci masowej Java z opóźnieniem GC jest ogólnie ogromną korzyścią, ale może powodować niewielkie przerwy w cyklach GC. W przypadku nowych maszyn JVM o niskim opóźnieniu sytuacja staje się znacznie lepsza, ale nadal może stanowić problem w przypadku gier o bardzo niskim opóźnieniu (być może strzelanki FPS). Obejściem tego problemu jest użycie bibliotek o niskim opóźnieniu, takich jak http://javolution.org/ , jednak wydaje się, że są one bardziej ukierunkowane na handel z wysoką częstotliwością lub systemy czasu rzeczywistego niż na gry.
  • Brak możliwości wykorzystania optymalizacji niskiego poziomu - podczas gdy kompilator Java JIT jest niewiarygodnie dobry, wciąż wymusza pewne ograniczenia, których nie można uniknąć (na przykład sprawdzanie granic tablic). Jeśli naprawdę potrzebujesz uzyskać natywny dostęp na poziomie kodu maszynowego, aby zoptymalizować tego rodzaju rzeczy, to prawdopodobnie wolisz C / C ++ niż Java.

Pamiętaj, że istnieje również kilka opcji wdrażania do rozważenia:

  • Aplet - działa w przeglądarce, bardzo wygodnej dla użytkowników, jednak ze względów bezpieczeństwa aplety są raczej ograniczone. Zauważ, że możesz podpisywać aplety, aby uzyskać dodatkowe uprawnienia bezpieczeństwa, chociaż spowoduje to nieco przerażające monity dla większości użytkowników.
  • Java Web Start - lepszy dla bardziej wyrafinowanych gier, które wymagają pełnego pobrania lokalnego, a także dostępu do lokalnych zasobów systemowych. Działa również w sposób dość niezależny od platformy. Prawdopodobnie najlepsza droga do gry średniej wielkości lub czegoś, co musi ominąć ograniczenia bezpieczeństwa apletów.
  • Pobieranie instalatora - Możesz napisać instalator gry Java, tak jak w każdym innym języku. Konfigurowanie i testowanie wymaga nieco więcej pracy, ponieważ instalatorzy zwykle mają pewne funkcje specyficzne dla platformy.
  • Internet - możesz napisać aplikację HTML5 i korzystać z siły Javy wyłącznie po stronie serwera. Warto rozważyć grę internetową dla wielu graczy.

Na koniec warto również rozważyć niektóre inne języki JVM - mają one wszystkie zalety platformy Java wymienione powyżej, ale niektórzy uważają je za lepsze języki niż sama Java. Scala, Clojure i Groovy byłyby najwybitniejszymi i wszyscy mogą korzystać z wymienionych powyżej narzędzi i bibliotek Java.

mikera
źródło
1
JWS tak naprawdę nie dodaje dużo ponad apletami poza oddzieleniem aplikacji od przeglądarki. W obu przypadkach myślę, że będziesz chciał podpisać swój kod, jeśli korzystasz z biblioteki OpenGL.
Peter Taylor
2
Powiedziałbym, że dostęp do lokalnego systemu jest naprawdę „znacznie większy” niż ograniczenia apletów dla wielu poważnych gier, szczególnie dla wielu graczy. HTML5 jest schludny, ale nadal jest bardzo dziwaczny z nieregularnym wsparciem i ważnymi bitami, takimi jak GL i Sockets, wyłączonymi w wielu przeglądarkach, a ponadto dźwięk nie jest jeszcze odpowiedni do użytku w grach.
Patrick Hughes
1
@PatrickHughes, jeśli chcesz mieć dostęp do systemu lokalnego z JWS bez dużych przerażających okien dialogowych, musisz podpisać swój kod - a podpisany aplet zwykle będzie miał również dostęp do systemu lokalnego.
Peter Taylor
Możesz także użyć Inno Setup do dystrybucji swoich gier Java.
Mahmoud Hossam
1
Możesz dodać LIBGDX do listy pakietów, które pomogą Ci napisać własny silnik; ma konfiguracje i optymalizacje JNI dla różnych platform, a nawet Androida i aż do OpenGL ES.
Patrick Hughes
4

Minecraft i bloki, które są ważne, są wbudowane w Javę, więc tak, jest to dobre do tworzenia gier. Głównym problemem, na który natkniesz się podczas korzystania z Java, jest portowanie na platformy mobilne, jeśli wybierzesz tę trasę i napiszesz natywną aplikację. Android jest rodzajem frankensteined Java SE z osobną biblioteką. RIM Blackberry używa Java ME. iOS teoretycznie można programować w Javie, chociaż Objective-C prawdopodobnie byłby lepszym wyborem dla tej platformy.

Java jest dość podobna do C #. Często uważam, że kod C # jest zrozumiały, mimo że znam tylko Javę. Mają inną filozofię projektowania, ale o ile są szeroko stosowane przy minimalnym wysiłku, oba są odpowiednie. C # nie jest strasznym wyborem dla gier pod żadnym względem, chociaż wdrożenie mobilne będzie trudniejsze, a wdrożenie na platformach innych niż Windows będzie bardziej czasochłonne lub trudne, w zależności od konkretnych bibliotek zewnętrznych i tak dalej.

Inżynier świata
źródło
1
Java na urządzeniach mobilnych: skompiluj raz,
debuguj
0

Najbardziej oczywistym i najmniej odpornym sposobem jest użycie kombinacji javascript HTML5 +. Każda aplikacja lub gra wykonana przy użyciu tego będzie działać na prawie każdym urządzeniu i przeglądarce.

Zaleta : - Do uruchomienia gry na różnych platformach i urządzeniach będziesz potrzebować zerowej konfiguracji.

UWAGA: - Widziałem kilka gier, które są budowane przy użyciu wyżej wymienionych technologii, ale były mniejsze. Ale przypuszczam, że jeśli można zrobić masło z mleka, ser nie jest niemożliwy

Pankaj Upadhyay
źródło
0

Możesz używać Scala i Scheme Bigloo na Eclipse, aby używać JVM do kodowania stresowego lub akcji równoległej w swojej grze Java.

Dzięki Pattern Design i UML2 możesz także zabezpieczyć kod za pomocą OCL, wszystko w Topcased.org.

Opanowanie tych narzędzi wymaga czasu, ale stanowią one tło Java, podstawę, która popchnie Cię na szczyt.

cl-r
źródło
-10

Krótka odpowiedź: nie.

Java nie generuje binarnego pliku wykonywalnego, ale tylko kod bajtowy, tak jak robi to C # (CLI), i to nie jest dobra rzecz dla poważnego biznesu w „otwartych środowiskach” z dwóch głównych powodów:

  • prawdopodobieństwo uwięzienia w inżynierii wstecznej jest bardzo wysokie, szczególnie w przypadku starych i naprawdę dobrze znanych języków, takich jak Java
  • nie masz pełnej kontroli nad wydajnością maszyny, w przypadku Javy dużą rolę odgrywa JVM, przejmując pełną kontrolę.

Oczywiście każdy język ma swoje własne biblioteki, ale ze względu na ich dużą liczbę dla każdego języka nie jest to prawdziwy problem i nie wydaje mi się, że jest to cel tego tematu.

Być może na poziomie profesjonalnym możesz znaleźć coś, co może złamać regułę, np. Dev-Kit, który może przetłumaczyć wszystkie instrukcje C # na kod asemblera dla maszyny z prawdziwego świata, ale jeśli tego rodzaju podejście nie znajduje się w kartach, jesteś zmuszony do tego weź pod uwagę tylko C i C ++ dla swojego rozwoju, gdy zamierzasz sprzedawać swój produkt w otwartym środowisku.

Rzeczy są nieco inne dla urządzeń mobilnych, ponieważ są one „zamkniętym środowiskiem”, nawet Android jest praktycznie zamknięty, biorąc pod uwagę fakt, że źródło ROM-ów w prawdziwym świecie nie jest zwykle publicznie dostępne, Android można uznać za open source, ale 99 % pamięci ROM na rzeczywistych urządzeniach nie jest. W takich przypadkach nie można za bardzo się kłócić, wszystko jest już ustawione dla ciebie, a każda platforma ma swój własny język, jak wszyscy wiedzą.

Ostatecznie, jeśli zamierzasz sprzedawać te produkty w otwartych środowiskach, mogę jedynie sugerować języki, które mogą tworzyć skompilowany kod binarny / asemblacyjny, w zamkniętych środowiskach decyzja jest zazwyczaj łatwiejsza z różnych powodów.

Micro
źródło
7
Wygląda na to, że uważasz, że skompilowane pliki binarne są trudniejsze do odtworzenia niż pliki binarne z kodem bajtowym. Może być w tym trochę prawdy, ale niewiele. W rzeczywistości prawdopodobnie więcej osób może pracować z deasemblerem x86 i x64 niż z kodem bajtowym CLI lub Java, i będziesz zaskoczony, jak pomocne może być narzędzie takie jak IDA Pro (zrzeczenie się - nie korzystałem z niego od czasu darmowej wersji całkiem sporo lata temu - prawdopodobnie teraz jest jeszcze łatwiej). Zaszyfrowany plik kodu bajtowego może być nawet trudniejszy do odtworzenia i, w każdym razie, większość ludzi nie będzie miała powodów, by się tym przejmować.
Steve314,
2
Dlaczego nie ma powodu, aby się tym przejmować? Ile osób pisze własne, niskopoziomowe silniki gier? I nawet jeśli to zrobisz, jakie są szanse, że ktoś wolałby ukraść twój (potrzebujący inżynierii wstecznej, brak jakiejkolwiek dokumentacji itp. - dużo czasu tam zmarnowane, bez względu na język programowania), zamiast legalnie używać dobrze udokumentowany darmowy silnik open source? Piractwo pełnego programu jest o wiele bardziej prawdopodobne niż inżynieria wsteczna w celu kradzieży pomysłów na kod, a piraci nie wydają się w najmniejszym stopniu zniechęceni przez natywny skompilowany kod.
Steve314,
1
Na poziomach abstrakcji instrukcje JVM mają bardzo niski poziom - nie dokładnie tak jak w sprzęcie, ale w zasadzie tak daleko od abstrakcji warstwy aplikacji. Tam, gdzie liczone są warstwy abstrakcji w standardowych bibliotekach Java, oznacza to, że naprawdę jest niewiele warstw między platformą a ostateczną aplikacją. Tyle że normalnie dzieje się to w C i C ++ (po co wymyślać libpng itp.) - większość ludzi będzie korzystać ze wspólnych bibliotek, które skutecznie tworzą zestaw powszechnie znanych platform, a dobre narzędzia do inżynierii odwrotnej mogą je rozpoznać.
Steve314,
3
Aby spełnić wymagania, cały kod musiałby zostać wysłany na FPGA i zamknięty w żywicy epoksydowej. Niespodzianka, nawet pakiety z czarnymi skrzynkami mogą i są cały czas poddawane inżynierii wstecznej. Wtedy nawet potężni giganci, tacy jak Intel, wprowadzają błędy w swoich pakietach CPU, więc twoja epoksydowa, sprzętowa czarna skrzynka nadal będzie cierpieć z powodu ekspozycji na biblioteki sprzętowe. Wreszcie wezwanie do bezpieczeństwa przez zaciemnienie, które nie działa. Reductio ad absurdum, wiem, ale taka jest pierwotna odpowiedź.
Patrick Hughes
3
Niestety nie mam wystarczającej reputacji, aby cię głosować. Wszystkie twoje argumenty są nieudane. Są ludzie, którzy dekodują, dekompilują i hakują gry produkowane w C, C ++ lub innym języku, więc binarny pakiet nie zapewni większego bezpieczeństwa. Ponadto, jeśli PO jest zaniepokojony tym, istnieje wiele bardzo dobrych obfuscatorów java. Jeśli chodzi o pełną kontrolę wydajności maszyny, większość programistów C i C ++ też tego nie ma, wystarczy napisać dobry kod, a kompilator zoptymalizuje to, co jest potrzebne. I nawet jeśli jest to problem, możesz użyć JNI lub JNA.
Victor Stafusa,