Почему Java не более широко используется для разработки игр? [закрыто]

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

• Отсутствие разработчиков игр с опытом работы с Java
• Отсутствие хороших фреймворков для разработки игр
• Программисты не хотят принимать Java как язык программирования игр. Большинство принимает только C ++?
• Нет поддержки игровых приставок (хотя рынок ПК все еще существует)

Конечно, это может быть что-то еще. Может ли кто-то, кто знает бизнес лучше меня, объяснить, почему Java не набирает обороты, когда дело доходит до разработки игр?

Некоторые причины:

• В старые времена вам требовался «прямой доступ» для повышения производительности и пользовательского интерфейса. Это предшествует языкам ВМ, таким как Java и C #.
• Большинство консолей (например, 360, PS3) не имеют JVM, поэтому вы не можете повторно использовать код из версии для ПК. Гораздо проще скомпилировать код C ++ для поддержки различных устройств.
• Большинство основных игровых движков (например, Unreal) имеют привязки C ++. Есть несколько коннекторов Java (например, для OpenGL), но ничего подобного.
• Для игр на ПК у DirectX нет сильной поддержки Java (если вообще есть).
• Сетевые игры работают на JavaScript или Flash. Вы можете написать их на Java, используя такие вещи, как GWT.
• IPhone работает с Objective-C.

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

Технические причины:

• Большинство лучших 3D игровых движков написаны на C / C ++. Это большое дело, так как большинство разработчиков игр не хотят идти на компромисс в своем 3D-движке, но и не хотят писать его с нуля. У Java есть jMonkeyEngine, который является открытым исходным кодом и на самом деле действительно хорош, но он все еще не может конкурировать с Unreal Engine .
• В некоторых очень редких ситуациях есть преимущества в том, чтобы «приблизиться к металлу» на C или языке ассемблера, особенно для доступа к специальным аппаратным функциям. Это не так важно в наше время, но профессиональные разработчики игр все еще хотели бы иметь возможность .....
• У Java есть сборка мусора , управляемая среда выполнения. В 99% случаев это огромное преимущество, оно, безусловно, делает кодирование более простым и менее подверженным ошибкам, и это одна из основных причин популярности Java. Однако это иногда вызывает проблемы с задержкой в ​​играх, поскольку циклы сборки мусора могут вызывать заметные паузы. Это становится меньшей проблемой для новых JVM с малой задержкой, но все еще остается проблемой для графически интенсивных игр, в которых поддержание высокого FPS имеет решающее значение.

Нетехнические причины:

• Дома профессиональных разработчиков игр активно инвестируют в навыки и технологии C / C ++. Это создает огромное количество инерции .
• Во многом иррациональное восприятие, что Java медленная. Возможно, верно в 90-х, определенно не соответствует действительности - вы, безусловно, можете написать прибыльную коммерческую 3D-игру на Java ( кто-нибудь из Runescape ? Или как насчет Minecraft ?)
• Довольно справедливое представление о том, что Java больше ориентирована на бизнес-приложения и веб, чем на игры. Это может измениться с ростом Mobile и потребностью в кроссплатформенной разработке, но в настоящее время это действительно так.

Интересно, что есть и веские причины, по которым разработчики игр должны рассматривать Java:

• Портативность - по мере роста числа целевых платформ Java становится все более привлекательной благодаря уникальной способности создавать действительно кроссплатформенные двоичные файлы.
• Библиотечная экосистема - за очень важным исключением игровых движков 3D, Java обладает лучшим набором библиотек среди всех платформ. Сеть, звук, AI, обработка изображений, хранилище данных ключ / значение, вы называете тему и, вероятно, для нее есть библиотека Java с открытым исходным кодом.
• Разработка на стороне сервера - Java является отличной языковой платформой для сервера, и по мере того, как все больше игр содержат элементы, рассчитанные на несколько игроков, сторона сервера будет становиться все более и более важной. Java на Linux выглядит довольно убедительно в качестве платформы.
• JVM - это, пожалуй, лучшая в мире среда исполнения виртуальных машин с фантастической сборкой мусора, JIT-компилятором, поддержкой параллелизма и т. Д. Она будет только улучшаться, и, поскольку разработчики игр все чаще начинают использовать динамические языки в своих играх, они захотят наилучшая возможная среда выполнения.
• Другие языки JVM - Java - надежная рабочая лошадка, но настоящее новшество происходит с новыми языками JVM (в частности, Scala, Clojure). Эти языки получают все преимущества платформы Java / JVM, а также являются чрезвычайно мощными современными языками.

Хорошо, в этой теме много дезинформации.

Я очень хорошо знаю игровой бизнес , проработав в нем 25 лет. Я также очень хорошо знаю Java в играх, будучи техническим евангелистом Sun Java Game и лектором по программированию производительности Java.

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

С точки зрения использования памяти, у Java есть некоторые накладные расходы. HelloWorld - это программа 4K на Java. Но эти издержки довольно бессмысленны в современных системах с несколькими ГБ. Наконец, у Java больше времени запуска. Я бы не рекомендовал использовать Java для коротких служебных программ, таких как команды командной строки Unix. В этих случаях запуск будет доминировать в вашей производительности. В игре, однако, это довольно незначительно.

Правильно написанный код Java-игры не терпит GC-пауз. Как и код C / C ++, он требует некоторого активного управления памятью, но не до уровня C / C ++. Пока вы сохраняете использование памяти для долгоживущих объектов (сохраняющихся для всего уровня или игры) и очень недолговечных объектов (векторов и т. Д., Передаваемых и быстро уничтожаемых после расчета), gc не должно быть видимой проблемой.

С точки зрения прямого доступа к памяти, Java имела это в течение долгого времени; начиная с Java 1.4 в виде собственных прямых байтовых буферов. Переполнение битов в Java может немного раздражать из-за отсутствия целочисленных типов без знака, но рабочие циклы все хорошо известны и не слишком обременительны.

Хотя его настоящая Java никогда не имела привязки Direct3D, это потому, что технологии Java стремятся к переносимости. Он имеет две привязки OpenGL (JOGL и LWJGL) и привязку OpenAL (JOAL), а также переносимую привязку ввода (JInput), которая скрытно связана с DirectInput в Windows, HID Manager в OSX и привязку Linux (я забыл, какая).

Это правда, что ни один полноценный игровой движок не показал Java, как, например, Unity, показал C #, и это слабое место в независимом пространстве. С другой стороны, было два хороших APIS уровня Scenegraph, которые были полностью переносимы на платформу для Windows, OSX и Linux. Оба написаны Джошем Слэк, первый был назван движком JMonkey, а второй - Ardor3D.

Верхний постер прав, что две самые большие вещи, которые сдерживали Java в разработке игр, были предрассудки и мобильность. Последний был самой большой проблемой. Хотя вы могли бы написать игру на Java и поставить ее на Windows, OSX и Linux, консольной виртуальной машины никогда не было. Это было связано с полной неспособностью среднего звена Sun. Те немногие из нас, кто работал над Java в играх, на самом деле заключали с Sony сделки не менее 3 раз, чтобы получить виртуальную машину на Playstation, и все три раза средний менеджмент Sun убивал ее.

Хотя Sun заигрывает с клиентскими технологиями, факт заключается в том, что руководство Sun никогда не получало потребительские товары. Вот почему Java как клиентский язык от Sun никогда не преуспевала ни в какой форме, и поэтому потребовались Google и Dalvik (Java-подобная виртуальная машина Android), чтобы сделать Java платформой успешной в любом месте.

И именно поэтому я сегодня пишу игры на C #. Потому что Моно пошел туда, куда руководство Sun отказалось.

Java отлично подходит для бизнес-логики, серверов и платформно-независимого кода, который должен работать надежно. Есть несколько факторов, почему Java не часто используется в играх:

• проверка границ и другие механизмы безопасности (предельная разница в производительности в наши дни)
• необходимость преобразования между структурами данных C ++ и структурами данных Java (нельзя просто копировать память между буферами)
• многие книги и учебные пособия следуют за толпой, поэтому трудно найти информацию о разработчиках не-C ++ игр
• основные графические библиотеки (DirectX и OpenGL) и многие готовые движки основаны на C / C ++
• многие игры стараются работать как можно быстрее, чтобы добавить больше визуально привлекательных функций

Нелегко работать с библиотеками C ++ из языков байт-кода, таких как Java (написание слоя JNI) и .net (множество маршаллинговых / демаршаллирующих, атрибутов API / структуры). Так что это добавляет немного работы для небольшой выгоды.

Примечание: некоторые игровые серверы используют Java.

Подобный пост здесь : https://stackoverflow.com/questions/1034458/why-arent-video-games-written-in-java

Java не достаточно быстр для разработки большинства игр. Это намного медленнее, чем использование C ++ / Assembly, которое является стандартом. Это та же самая причина, по которой дальнейшая разработка игр не осуществляется с использованием C # или VB. Разработчики игр нуждаются в планировании каждого последнего тактового цикла, который они могут получить, для таких вещей, как физические вычисления, логика ИИ и взаимодействие с окружением.

Для более простых игр Java может использоваться довольно эффективно. Если вы хотите создать клон Tetris, Bejeweled или что-то еще с таким уровнем детализации, то Java будет работать нормально. Но Java не может создавать игры, такие как Halo, Medal of Honor, Command & Conquer и так далее, и сделать их играбельными. По крайней мере, так, как это существует в наши дни.

И причины, которые вы перечислите в своем вопросе, также действительны. За исключением, я думаю, отсутствия разработчиков игр с опытом работы с Java. Многие игры на телефонах и других портативных устройствах написаны на Java (включая большинство игр для Android), а некоторые игры довольно хороши. Так что я думаю, что есть неплохая и растущая база разработчиков игр со знанием Java.

Меняется мысль о возможности использовать эти языки более высокого уровня для некоторых из более продвинутых игр. Например, одна из моих любимых игр, Auran's Train Simulator, написана большими порциями на C #, и она работает довольно хорошо. Таким образом, база растет и будет продолжать развиваться.

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

Еще в 2002 году Джейкоб Марнер в своем отчете «Оценка Java для разработки игр» обнаружил, что Java вполне пригодна для игр, за исключением наиболее зависимых от производительности компонентов, а благодаря надежности языка и базовой JVM она дешевле сделать это таким образом.

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

По моему личному мнению, с прогрессом, который произошел с тех пор, особенно в 3D-графике, и с отличными привязками к OpenGL и др., Этот недостаток гораздо менее выражен в наши дни.

Следовательно, проблема должна быть в другом месте. Вероятной причиной является размер среды выполнения Java (которая в наши дни гораздо менее актуальна для игр с несколькими DVD), а также инерция существующего кода. Общеизвестно, что начинать работать с нативным кодом на Java очень непросто. Третья причина - то, с чем знакомы звездные разработчики, делающие игры. Четвертый вопрос - доступна ли вообще Java на платформе.

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

Разработчики игр любят быть ближе к металлу и часто пишут свои узкие внутренние петли в сборке. Java не предлагает одинаковый уровень возможной производительности, как с точки зрения постоянной скорости, так и с точки зрения использования памяти (запуск JIT берет свое).

Я думаю, что ограничивающим фактором для большинства людей является (отсутствие) наличия хороших игровых движков. Чтобы пройти очень далеко, нам нужно посмотреть, почему они недоступны.

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

Большинство очевидных кандидатов для разработки на Java в стиле фреймворков (например, IBM, Oracle), похоже, не интересуются играми. Очевидные кандидаты для разработки игр (например, Id, EA), кажется, почти одинаково мало интересуются Java.

Почти единственным кандидатом, о котором я могу подумать, что это вполне разумно, будет Google. Основным языком разработки для Android является Java, и поощрение разработки игр для Android может обеспечить реальное преимущество для платформы.

Насколько я знаю, они этого еще не сделали (пока?), Что оставляет довольно серьезные ограничения почти для всех остальных. Отсутствие на пути современных высокопроизводительных игровых движков использования разработки на Java означает немало дополнительной работы с (как мне кажется) малой перспективой для получения значительной выгоды в обмен на эту дополнительную работу.

Вопрос в том, чтобы спросить что-то вроде:

Что лучше для питания вашего автомобиля, лодочный двигатель или реактивный двигатель.

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

Java не была создана с учетом разработки игр, Java была создана как язык "для Интернета".

Что касается разработки игр, Sun на самом деле не поддерживала Java как язык разработки игр, поскольку Microsoft поддержала C #.

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

Проще приклеить С непосредственно к новому нетрадиционному оборудованию и драйверам. Чем раньше и ближе игровой программист сможет добраться до аппаратного обеспечения, тем лучше он сможет превзойти конкурирующие игры. Более поздние разработчики игр просто придерживаются той же методологии и инструментов, что и те, что были проверены ранее.

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

Для некоторых людей причина не имеет ничего общего со скоростью, библиотеками или доступностью. Это просто из-за самого языка. Некоторым людям просто не нравится язык Java. Другие люди предпочитают использовать свой любимый язык программирования вместо использования Java для создания игр.

Конечно, это может быть что-то еще. Может ли кто-то, кто знает бизнес лучше меня, объяснить, почему Java не набирает обороты, когда дело доходит до разработки игр?

Это интерпретируемый язык, то есть медленный. Вы имеете дело с графической и графической картой, которая является аппаратной. Какой хороший язык для работы с оборудованием? Ну, C ++, он довольно низкий, и вы имеете дело с указателями и прочим.

Если вы хотите прокачать сумасшедшую графику, такую ​​как crysis, и все, что вы не собираетесь делать для нее Java.

Мало того, что Oracle владеет Java, мысль о том, что компания может подать на вас в суд, не смела. Особенно, если вы хотите создать свой собственный интерпретатор для JAVA, предназначенный для игр, не получая иск из-за фрагментации FUD.