Я не разработчик игр или что-то еще, но я знаю, что Java не очень широко используется для разработки игр. Java должна быть достаточно быстрой для большинства игр, так в чем же подвох? Я могу думать о некоторых причинах:
- Отсутствие разработчиков игр с опытом работы с Java
- Отсутствие хороших фреймворков для разработки игр
- Программисты не хотят принимать Java как язык программирования игр. Большинство принимает только C ++?
- Нет поддержки игровых приставок (хотя рынок ПК все еще существует)
Конечно, это может быть что-то еще. Может ли кто-то, кто знает бизнес лучше меня, объяснить, почему Java не набирает обороты, когда дело доходит до разработки игр?
java
game-development
Анто
источник
источник
Ответы:
Некоторые причины:
В наши дни Java в основном используется в играх для Android просто потому, что это основной язык для этой платформы.
источник
malloc
илиnew
, поэтому, если это проблема, вы собираетесь реализовать объединение независимо от того, что. Вне зависимости от этого, большая проблема с Java заключается в том, что он не поддерживает типы значений, в отличие от C #.Технические причины:
Нетехнические причины:
Интересно, что есть и веские причины, по которым разработчики игр должны рассматривать Java:
источник
Хорошо, в этой теме много дезинформации.
Я очень хорошо знаю игровой бизнес , проработав в нем 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 (написание слоя 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 для создания игр.
источник
Это интерпретируемый язык, то есть медленный. Вы имеете дело с графической и графической картой, которая является аппаратной. Какой хороший язык для работы с оборудованием? Ну, C ++, он довольно низкий, и вы имеете дело с указателями и прочим.
Если вы хотите прокачать сумасшедшую графику, такую как crysis, и все, что вы не собираетесь делать для нее Java.
Мало того, что Oracle владеет Java, мысль о том, что компания может подать на вас в суд, не смела. Особенно, если вы хотите создать свой собственный интерпретатор для JAVA, предназначенный для игр, не получая иск из-за фрагментации FUD.
источник