Является ли Java хорошим выбором для кроссплатформенных игр? [закрыто]


13

Я хочу создать игру на Java и хотел бы, чтобы она работала на Windows, Linux и Mac. Я почти уверен, что C # - плохой выбор для этого, и у меня нет достаточного опыта в C или C ++. Я хочу держаться подальше от Флэша. Таким образом, является ли Java хорошим выбором для меня? В основном я использую C # и думаю, что Java похожа, поэтому я предполагаю, что это не будет так сложно изучать. Но достаточно ли это быстро? Есть ли язык, более подходящий для моих нужд, чем Java?


8
Зависит от того, какой стиль игры вы ищете. В зависимости от желаемого стиля, может быть, что HTML5 и некоторый javascript будут работать для вас, если не java.
Патрик Хьюз

Oddlab продает игры на основе Java, например, Tribal Trouble. Вы можете увидеть детали их движка на oddlabs.com/technology.php

5
Minecraft - отличный пример кроссплатформенной игры, написанной на Java. Когда наш парень готовит серьезную сессию Minecraft, он играет в OSX, Windows и Linux.
Кев

Два года спустя C # теперь достаточно хорош для таких вещей с помощью движка Unity и / или Monogame, которые также поддерживают iOS, Android и WP8.
Магус

Ответы:


28

Java чрезвычайно подходит для написания кроссплатформенных игр. Основные преимущества:

  • Портативность. В общем, вы можете написать Java-игру и ожидать, что она будет работать без изменений на большинстве платформ. Вероятно, это наиболее переносимый вариант из всех языков - C / C ++ - это еще один очень переносимый вариант, но его необходимо перекомпилировать для каждой платформы, и во многих случаях библиотеки имеют специфические для платформы функции, ограничивающие переносимость.
  • Производительность - Java-код, если он написан хорошо, будет работать почти так же хорошо, как и любой другой язык, включая C / C ++. JVM JIT-компилятор очень хорош. Вы можете написать высококачественную, успешную игру на Java (например, Minecraft).
  • Библиотеки - существует огромный спектр библиотек, доступных для Java, которые охватывают практически все функции, которые могут потребоваться в играх, от сетевых подключений до графики и звука и искусственного интеллекта. Большинство библиотек Java имеют открытый исходный код.

Главное решение, которое вам нужно будет принять, - это то, какой графический интерфейс вы собираетесь использовать. Существует довольно много разных вариантов, но наиболее выдающимися из них являются:

  • jMonkeyEngine - полноценный 3D-движок. Если вы хотите сделать 3D-игру, то это, вероятно, ваш лучший выбор - содержит множество функций игрового движка, таких как графики сцен, рельеф местности и т. Д.
  • LWJGL - библиотека более низкого уровня с прямым доступом к OpenGL. Скорее всего, вам понравится, если вы хотите максимальной производительности и не возражаете написать большую часть своего движка с нуля.
  • Преимущество Swing в том, что он чрезвычайно переносим и включен в среду выполнения Java, поэтому не требует дополнительной зависимости. Это хорошо для 2D-игр без графики (стратегии, карточные игры и т. Д.)
  • Slick - библиотека 2D игр, основанная на LWJGL. Вероятно, это хорошо, если вы хотите написать 2D-игру, но все еще нуждаетесь в хорошей графической производительности (стрелялки, игры на платформе и т. Д.)
  • JavaFX - разработан для многофункциональных интернет-приложений, примерно как Flash. Имеет много полезных функций, которые были бы хороши для игр, хотя я еще не видел, чтобы они использовались. В частности, JavaFX 2.0 выглядит довольно многообещающе.

Основные недостатки Java для игр на самом деле связаны с «крайними случаями», которые, вероятно, не затронут вас, но имеют отношение к некоторым классам игр:

  • Доступность трехмерного движка - хотя перечисленные выше инструменты и движки хороши, они все еще не до уровня C / C ++ движков, таких как Unreal Engine, используемых профессиональными игровыми компаниями. Так что Java, возможно, не будет вашим первым выбором, если вы пытаетесь разработать крупный FPS с многомиллионным бюджетом - C / C ++ все еще выигрывает здесь.
  • GC латентность сборки мусора Java в целом является огромным преимуществом, но она может вызвать небольшие паузы, когда происходят циклы GC. Это становится намного лучше с новыми JVM с низкой задержкой, но все еще может быть проблемой для игр с очень низкими требованиями к задержке (возможно, шутеры от первого лица). Обходной путь - использовать библиотеки с низкой задержкой, такие как http://javolution.org/ , однако, похоже, они больше предназначены для высокочастотной торговли или систем реального времени, а не для игр.
  • Отсутствие возможности использовать низкоуровневую оптимизацию - хотя компилятор Java JIT невероятно хорош, он все же накладывает некоторые ограничения, которые вы не можете избежать (например, проверка границ для массивов). Если вам действительно нужно получить доступ на уровне машинного кода для оптимизации такого рода вещей, то, опять же, вы, вероятно, предпочтете C / C ++, а не Java.

Обратите внимание, что есть также несколько вариантов развертывания:

  • Апплет - работает в браузере, очень удобно для пользователей, однако апплеты довольно ограничены в том, что они могут делать из соображений безопасности. Обратите внимание, что вы можете подписывать апплеты, чтобы получить дополнительные привилегии безопасности, хотя это вызовет у большинства пользователей немного пугающую подсказку.
  • Java Web Start - лучше для более сложных игр, требующих полной локальной загрузки и доступа к локальным системным ресурсам. Это также работает довольно независимо от платформы. Вероятно, лучший маршрут для игры среднего размера или чего-то, что должно избежать ограничений безопасности апплета.
  • Загрузка установщика - вы можете написать установщик для Java-игры, как и для любого другого языка. Конечно, настроить и протестировать немного больше, поскольку установщики, как правило, имеют некоторые специфичные для платформы функции.
  • Веб - вы можете написать веб-приложение на HTML5 и использовать преимущества Java исключительно на стороне сервера. Стоит задуматься о многопользовательской веб-игре.

Наконец, стоит также рассмотреть некоторые другие языки JVM - в них есть все преимущества платформы Java, перечисленной выше, но некоторые считают, что они являются лучшими языками, чем сама Java. Scala, Clojure и Groovy были бы наиболее известными, и все они могут использовать инструменты и библиотеки Java, перечисленные выше.


1
JWS на самом деле не добавляет много апплетов, кроме отделения вашего приложения от браузера. В обоих случаях я думаю, что вы захотите подписать свой код, если вы используете библиотеку OpenGL.
Питер Тейлор

2
Я бы сказал, что доступ к локальной системе - это действительно большое «ограничение» апплета для многих серьезных игр, особенно многопользовательских. HTML5 аккуратен, но он все еще крошечный малыш с нечеткой поддержкой и важными элементами, такими как GL и сокеты, отключенными во многих браузерах, плюс аудио еще не очень подходит для использования в играх.
Патрик Хьюз

1
@PatrickHughes, если вы хотите, чтобы локальный системный доступ осуществлялся из JWS без больших страшных диалогов, вам нужно будет подписать свой код - и подписанный апплет обычно также будет иметь доступ к локальной системе.
Питер Тейлор

Вы также можете использовать Inno Setup для распространения ваших Java-игр.
Махмуд Хоссам

1
Вы можете добавить LIBGDX в список пакетов, которые помогут вам в написании вашего собственного движка; он имеет настройки и JNI-оптимизацию для различных платформ и даже Android, вплоть до OpenGL ES.
Патрик Хьюз

4

Minecraft и Blocks that Matter созданы на Java, так что да, это очень хорошо для создания игр. Основная проблема, с которой вы столкнетесь при использовании Java, - это портирование на мобильные платформы, если вы решите пойти по этому пути и написать собственное приложение. Android является своего рода франкенштейном Java SE с отдельной библиотекой. Ежевика RIM использует Java ME. Теоретически iOS можно программировать с помощью Java, хотя Objective-C, вероятно, будет лучшим выбором для этой платформы.

Java в достаточной степени похож на C #. Я часто нахожу код C # понятным, несмотря на то, что знаю только Java. У них действительно есть другая философия дизайна, но поскольку они широко развертываются с минимальными хлопотами, оба отвечают всем требованиям. C # не является ужасным выбором для игр с любой натяжкой, хотя ваше мобильное развертывание будет сложнее, а развертывание на платформах, отличных от Windows, займет больше времени или затруднительно в зависимости от того, какие конкретные внешние библиотеки и т. Д. Вы планируете использовать.


1
Java для мобильных устройств: скомпилируйте один раз, отлаживайте везде: '(.
deadalnix

0

Наиболее очевидным и наименее устойчивым способом является использование HTML5 + комбо javascript. Любое приложение или игра, созданные с использованием этого, будут работать практически на всех устройствах и браузерах.

Преимущество : - Вам потребуется нулевая конфигурация для запуска игры на различных платформах и устройствах.

ПРИМЕЧАНИЕ: - Я видел несколько игр, которые построены с использованием вышеупомянутых технологий, но они были меньше ростом. Но, полагаю, если из молока можно сделать сливочное масло, то сыр не исключен.


0

Вы можете использовать Scala и Scheme Bigloo на Eclipse, чтобы использовать JVM для напряженного кода или параллельных действий в вашей игре Java.

С помощью Pattern Design и UML2 вы также можете защитить код с помощью OCL, все на Topcased.org.

Освоение этих инструментов требует времени, но они являются основой Java, основой, которая подтолкнет вас на вершину.


-10

Краткий ответ: нет.

Java не генерирует двоичный исполняемый файл, а только байт-код, как это делает C # (CLI), и это не очень хорошая вещь для серьезного бизнеса в «открытых средах» по двум основным причинам:

  • вероятность попасть в ловушку обратного инжиниринга очень высока, особенно со старыми и действительно хорошо известными языками, такими как Java
  • Вы не полностью контролируете производительность машины, в случае Java JVM играет большую роль, беря полный контроль.

Конечно, у каждого языка есть свои библиотеки, но из-за большого количества их для каждого языка это не является реальной проблемой, и я не думаю, что цель этой темы.

Может быть, на профессиональном уровне вы можете найти что-то, что может нарушить правило, например dev-Kit, который может преобразовать все операторы C # в код сборки для реальной машины, но если такого подхода нет в картах, вы вынуждены практично Рассматривайте только C и C ++ для своего развития, когда вы собираетесь продавать свой продукт в открытой среде.

Для мобильных устройств все немного по-другому, потому что они являются «закрытой средой», даже если Android практически закрыт, учитывая тот факт, что исходные ПЗУ в реальном мире обычно не доступны для общественности. Android можно считать открытым исходным кодом, но 99 % ПЗУ на реальных устройствах нет. В этом случае вы не можете спорить слишком много, все уже настроено для вас, и у каждой платформы есть свой язык, который знают все.

В конце концов, если вы собираетесь продавать эти продукты в открытых средах, я могу предложить только языки, которые могут создавать скомпилированный и двоичный / ассемблерный код, в закрытых средах решение, как правило, легче принять по разным причинам.


7
Похоже, вы считаете, что скомпилированные двоичные файлы труднее реконструировать, чем двоичные файлы с байт-кодом. В этом может быть немного правды, но не так много. На самом деле, вероятно, больше людей могут работать с дизассемблером x86 и x64, чем с CLI или Java-байт-кодом, и вы будете удивлены, насколько полезным может быть такой инструмент, как IDA Pro (отказ от ответственности - я не использовал его, поскольку в бесплатной версии довольно много лет назад - наверное, сейчас еще проще). Обфусцированный файл байт-кода может быть даже сложнее для обратного проектирования, и, в любом случае, у большинства людей будет мало причин для заботы.
Steve314

2
Почему мало причин для заботы? Ну, сколько людей пишут свои собственные низкоуровневые игровые движки? И даже если вы это сделаете, каковы шансы, что кто-то предпочтет вас украсть (нуждаются в реверс-инжиниринге, отсутствии какой-либо документации и т. Д. - там тратится много времени, независимо от языка разработки), а не юридически использует хорошо документированный бесплатный движок с открытым исходным кодом? Пиратство полной программы - гораздо более вероятная реальная проблема, чем реверс-инжиниринг для кражи идей кода, и пираты не кажутся ничуть не сдерживаемыми нативным скомпилированным кодом.
Steve314

1
На уровнях абстракции инструкции JVM находятся на крайне низком уровне - не совсем так, как в аппаратном обеспечении, но в основном так же далеки от абстракции прикладного уровня. Если количество уровней абстракции находится в стандартных библиотеках Java, это означает, что между платформой и конечным приложением действительно мало слоев. За исключением того, что обычно происходит в C и C ++ в любом случае (зачем изобретать libpng и т. Д.) - большинство людей будут использовать общие библиотеки, которые эффективно образуют набор широко известных платформ, и хорошие инструменты обратного проектирования могут их распознать.
Steve314

3
Для удовлетворения требований весь код должен быть отправлен на ПЛИС и в эпоксидной смоле. Сюрприз, даже чип-пакеты «черного ящика» могут и постоянно пересматриваться. Тогда даже могущественные гиганты, такие как Intel, вносят ошибки в свои пакеты ЦП, поэтому ваш встроенный в эпоксидную смолу аппаратный черный ящик все еще будет страдать от воздействия аппаратных библиотек. Наконец, призыв к безопасности от неясности, это не работает. Reductio ad absurdum, я знаю, но таков и оригинальный ответ.
Патрик Хьюз

3
К сожалению, у меня недостаточно репутации, чтобы понизить вас. Все ваши аргументы несостоятельны. Есть люди, которые декодируют, декомпилируют и взламывают игры, созданные на C, C ++ или на любом другом языке, поэтому наличие бинарного пакета не обеспечит особой дополнительной безопасности. Кроме того, если ОП обеспокоен этим, есть много очень хороших Java-обфускаторов. Что касается полного контроля над производительностью машины, у большинства программистов на C и C ++ этого тоже нет, просто пишите хороший код, и компилятор оптимизирует то, что необходимо. И даже если это проблема, вы можете использовать JNI или JNA.
Виктор Стафуса
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.